Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
И самое интересное это то, что не до конца знаешь что будешь дальше после такой агентой разработки и оркестрации
Я кодил довольно сложные штуки до эпохи ИИ, и могу сказать, что раньше было то же самое. Проекты росли без гарантий. Фичи тоже работали то так, то эдак, и всё это было довольно-таки непредсказуемо.
Все мы сталкивались с историями глобальных задержек разработки или что всё пошло не туда и надо всё переделывать и так далее.
если ты в промпте четко и подробно формулируешь требования, анализируешь затем полученный код, и главное понимаешь его )) то сюрпризов быть не должно
... другое дело когда "разработчик" просит сделать то что сам не понимает )
А как вы анализируете код, который пишет ИИ? Я обычно запускаю другого агента на ревью, потом вношу предложенные правки — и на этом всё. Проверять всё своими глазками уже не получается: объём кода запредельный.
Я задаю доп. контроль в AGENT.md, независимое ревью 3 саб-агентами(или больше меньше в зависимости от объема) перед коммитом, после правок также обратно им относит изменения, ну и конечно полный прогон тестов. Если по ходу дела агент находит какие-то баги не по задаче или у него есть предложения какие-то, он записывает это в bugs.md или в todo.md, баги по контексту задачи сразу исправляет. Периодически вручную или с помощью других агентов разгребаю что там накопилось в записях и действительно ли стоящие проблемы. Раз в неделю можно запустить аудит на мертвый код или какое то искусственное дублирование классов или методов. Это конечно мнимый контроль, но то, что код не сваливается в совсем legacy это факт. Также стоит не лениться и составлять небольшой план перед большими правками(другим агентом или самому) и уже готовый план кормить агенту, так хотя бы будешь в курсе всех правок.
если у вас не получается глазками всё делать, значит у вас задачи не соответсвуют "производственным ресурсам" ))))) это уже проблемы организации труда,
когда вы не можете полностью весь код проконтролировать, то закладывает потенциальную тамбомбу,
иишке нельзя доверять на 100%, у неё глюки случаются в самых неожиданных местах, и рано или поздно там будет прикол который другая иишка не выявит,
всё конечно зависит от того что за проект, но если достаточно критичный то чёрных ящиков не должно! читать то код всё-же куда быстрее чем его писать,
главное что-бы код был оформлен так что бы его было легко читать и понимать,
при постановке задачи пытайтесь добиться на выходе не только того что-бы просто выдавала какие-то удовлетворяющие задаче результаты, но и что-бы то что она накодила было проще анализовать,
т.е. в описании задачи подробно прописывать каких архитектур и паттерновов придерживаться в конкретных случаях, точно перечислить какие методы за что должны отвечать, и каждый отдельный реализовать как отдельную подзадачу, описывать требования к каждому отдельному методу
.... это конечно куда больше времени займёт чем взять и настрочить здоровенный промпт и пусть сама иишка разбирается, но и значительно быстрее чем кодить полностью вручную
очень поверхностно описал схему, вряд ли что-то новое открыл кому-то )
Не хочу устраивать файт, но всё-таки с современными моделями, такими как Opus 5.5, Astra, уже принято писать по-другому, и харнессы работают абсолютно в другом ключе.
Я понимаю, что, быть может, вы работаете в банке и там требования безопасности, но это узкая сфера проектов, и для 90% проектов безопаснее писать с ИИ, проверять ИИ, потому что ручная проверка оставит больше дыр.
Вся мировая практика уже к этому пришла, и очень многие довольно крутые компании не проверяют код.
Мой друг — крутой безопасник, победитель всяких конкурсов и так далее — прямо говорит, что для средних проектов, когда это не банк, а, допустим, 5–10 программистов, ИИ делает код безопаснее, чем его делают вручную, и что подобных дыр, как были раньше, в проектах с ИИ уже нет.
конкретно в моих задачах безопасность и детерминируемость превыше всего, это верно, такой подход конечно же не навязываю,
потому что в большинстве задач важнее скорость разработки и минимизация издержек
>> и очень многие довольно крутые компании не проверяют код.
практика то, точнее тенденция - очень плохая,
банк не банк, а всякие дыры это всегда было следствием недосмотра или неквалифицированности разрабов
уменьшениее дырявости в иишном коде, это скорее следствие того что современные ии куда более экспертны чем Средне-статистический разраб,
и в большинстве не очень серьёзных проектов всякие дыры появляются ну по очень банальным причинам
в задачах же посерьёзный, пока ещё требуется очень серьёзный человеческий контроль, а вот что будет дальше посмотрим ... либо действительно можно будет расслабиться, либо всё упрется в технологический тупик
Согласен на 100%, и будет интересно ещё через полтора года написать новую статью.
мне нравится ваше исследование и сейчас глядя на голосовалку кой какая картина начинает вырисовываться
большая часть ответов это либо код полностью ии пишет, либо с чатом (что я считаю мало чем отличается от просто написания кода с подгугливанием непонятных моментов, например на том же stackoverflow)
а подход который я описал не так уж и популярен ....
Ну стопроцентного контроля не бывает даже с живыми сеньорами на ручном коде) Для этого и строят изолированные контуры, мониторинг и постепенный выкат фичей
Куда надежнее прогонять диффы через строгие статические анализаторы и юнит-тесты чем надеяться на вторую сетку, автотесты хотя бы выдают воспроизводимый результат без галлюцинаций
Как раз с этим в агентном программировании тоже нет проблем, потому что тестами покрывается всё гораздо шире и у нас правило, что любая бага, когда фиксится, создаётся тест. Единственное, раз в Х дней приходится проводить уборку уже неактуальных тестов, потому что они копятся и узким местом разработки становится CI.
Мы прошли похожий путь: начинали с копипасты между веб-интерфейсом ChatGPT и классическим VS Code, а сейчас перебрались в Antigravity. Разница в скорости и автономности колоссальная, но иллюзий не осталось: без чёткого понимания архитектуры проекта вся эта агентская мощь — просто шаг в никуда. Если ты не понимаешь, какие модули за что отвечают и как устроены потоки данных, агент сгенерирует идеальный по синтаксису коммит, который развалит систему на следующем шаге. Базовая инженерная насмотренность никуда не делась — просто фокус окончательно сместился с набора кода на архитектурный контроль.
Интересно, чем был обусловлен выбор Антигравити? Мы его даже с самой последней моделью Google agy --dangerously-skip-permissions --model “Gemini 4 Argon (High)”
используем только для побочных задач сторонних фич, потому что качество страдает.
Рабочая связка — Opus 5.5 и GPT Astra, которые проверяют друг друга на определённые фичи: допустим, дизайн, архитектура — Opus, внедрение кода — Astra, ревью — Opus, делать после ревью — Astra и так далее.
Главный фактор — бюджет. Доступ к моделям Google сейчас получается кратно дешевле топовых альтернатив, если брать длительный план (про на 18 месяцев), а для моих текущих объёмов этого пока достаточно. Сравнить качество «в лоб» не смогу — другие связки и IDE просто не гонял, поэтому опираюсь только на свой опыт в Antigravity.
Синтаксис нейросетки отлично выучили, а вот распределенные блокировки и идемпотентность они не понимают в принципе, во тут без базовых инженерных знаний архитектора ловить нечего
Да, агент с радостью закоммитит красивейший вызов стороннего сервиса внутри распределённой транзакции и даже напишет на это зелёный тест. Нарисовать синтаксис — это 5% задачи, а вот понимать, что произойдёт, когда на половине пайплайна моргнёт сеть и прилетит дубль события — это как раз то, почему архитекторов пока рано отправлять на пенсию.
Если архитектор не держит в голове связи между сервисами, никакой рой субагентов проект не спасет - они просто нагенерят гору внешне красивого мусора с нестыкующимися контрактами
У меня ощущение, что разработка еще дальше сместилась в сторону "Тимлид для ИИ", основным занятием стало генерирование / проверка спецификаций и доков и ревью кода. Тяжело сказать, где будет достигнут компромисс, насколько надо зарываться, неизбежно пропускаешь все больше, читаешь все невнимательнее знаешь меньше деталей.
Возможно нужны новые методологии проврки - архитектурные репорты от ИИ, специальные ИИ устойчивые архитектуры (по аналогии к дуракоустойчивым архитектурам, где определяешь безопасные места для расширения, чтобы у джуна было всегда явное место, где создать новый класс и шаблон для примера).
IDE пока открывается регулярно - в нем привычнее делать ревью. Сложно сказать, насколько
На работе использую клод/дома Pi с запретом на коммиты, а ревью изменений и коммиты продолжаю делать в Емаксе. И это будет и дальше продолжаться, потому что только я отвечаю за то, что нагенерили агенты
Статья заинтересовала тем, что при чтении вообще не возникло ощущения, что она написана нейросетью. Неужели вы вручную писали статью?
Спасибо, но нет, это как раз пример настроенного харнес с глубокими ревью и автоматическими проверками.
Я выдаю ИИ свои замечания, живые фразы прямо в чат и компануется статья.
Мы, кстати, этот проект выложили в OpenSource, там не только это, а куча всего другого интересного.
https://github.com/awaik/direct-mcp-ai-project
Там посмотрите скиллы, они каскадом применяются, и последний из них Human Editorial Pollish (Если правильно помню).
И, кстати, второй секрет — это использование программы для диктовки, что когда можно ИИ очень много всего надиктовывать, и он ваш стиль подхватывает. Мы используем опять-таки свою публичную программу Lidfly Glas (Но куча других есть для диктовки, плюс можно свою быстро накодить. Так как мы на Хабре, то я думаю, многие предпочтут свою накодить)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я перестал использовать редакторы кода на основе ИИ — 2026 (взгляд на апрель 2025)