Агент гонял цикл 40 часов: как встроить ИИ в разработку без регрессий

Споры о том, нужны ли разработчики в эпоху вайб-кодинга, обычно упираются в эмоции. Автор разбора на Habr вместо этого показывает, что происходит на практике, когда агенту дают задачу и не дают рамок.

Где вайб-кодинг ломается

В пет-проекте Xenodrift, который переделывали несколько раз, при новых правках переставали соблюдаться прежние решения. Возникали регрессии, а часть фич просто исчезала. Причина банальна: требования нигде не были зафиксированы, и проверять их соблюдение было нечем. Агент каждый раз работал с текущим куском контекста и не помнил, что договорились раньше.

Но плохое качество кода не неизбежно. В демо банковского приложения DemoBank автор задал требования к производительности, переиспользованию фич и дизайн-системе, а архитектуру намеренно не диктовал. Получилась модульная feature-first структура с элементами Clean Architecture, BLoC/Cubit для состояния, идемпотентность и retry в сетевом слое. Фича оплаты штрафов работает и внутри приложения, и как самостоятельное, не таща лишних зависимостей.

Производительность проверяли на реальном недорогом realme RMX3760: на минутной прокрутке 12 000 операций доля кадров сверх бюджета 16,7 мс составила 0,25% при критерии менее 1%. Автор честно оговаривает, что это один девайс и один сценарий.

Скорость не равна готовности

На DemoBank ушло около 27 часов суммарной работы Codex и около 19 часов фактического времени с учётом параллельности, плюс 2–3 часа самого автора. Особенно дорогими оказались прогоны перфоманс-тестов на телефоне. Метрика для команды должна быть не «как быстро сгенерировали», а «сколько от постановки задачи до принятого изменения», включая ревью и доработки.

Harness, quality gate и ответственность

Под AI Harness автор понимает рабочее окружение агента: контекст проекта, инструменты, ограничения действий, автоматические проверки и порядок передачи результата человеку. Ключевые идеи:

• Проверки, от которых зависит приёмка, должны запускаться автоматически и блокировать слияние. Фраза «запусти тесты» в промпте этого не гарантирует.
• Цикл «продолжай, пока проверки не пройдут» нужно ограничивать. Один из проектов автора крутился 40 часов, пока он не остановил его руками. Нужны лимиты по времени и деньгам, а при повторяющейся ошибке без прогресса агент должен остановиться и отчитаться, что пробовал.
• После принудительной остановки надо чинить процесс, а не просто править код: возможно, агент неверно понял задачу, карта проекта устарела или модель слишком слабая.
• За каждое решение должен быть понятный ответственный: поведение согласуют продакт и аналитик, контракты модуля проверяет его владелец, трактовку задачи агентом разработчик смотрит до написания кода.

Контекст, контракты и домены

Большое контекстное окно не гарантирует правильного использования информации: исследование Lost in the Middle показало зависимость качества от позиции данных в контексте. Поэтому нужны карта модулей, актуальные контракты и ADR. Автор предлагает хранить API-контракт в одном источнике, например в TypeSpec, а OpenAPI, документацию и клиентский код генерировать, проверяя согласованность в CI. Устаревшие ADR помечать как superseded.

Но контракт не заменяет поведенческие тесты: ключ идемпотентности можно описать в схеме, а отсутствие двойного возврата денег проверяется только отдельным сценарием. Пример из e-commerce: при плохой карте проекта агент может вызвать API платёжного провайдера прямо из модуля заказов, и возвраты не попадут в журнал платежей. Здесь пригодится DDD и архитектурные правила, проверяемые автоматически, плюс ревью другой моделью.

Что делать

Ограничения: это опыт одного автора на небольших проектах, без независимого аудита кода. Но выводы переносимы. Фиксируйте требования в спецификациях (OpenSpec, Spec Kit, BMAD, Kiro), делайте quality gate обязательным, ставьте бюджеты на циклы агента и закрепляйте владельцев за контекстом. Роль разработчика смещается от набора кода к постановке рамок и приёмке результата.