Фаза 8. Implementation: агент пишет код
Дошли до фазы, ради которой обычно и заводят разговор про AI в разработке, — до написания кода. И это единственная фаза курса, где провокация «человека нет» звучит буднично: агенты уже пишут код в проде, спорить не с чем. Поэтому статья не про то, что агент умеет кодить. Она про то, что при живом PM-агенте сверху (ф.7) и ревью-агенте сбоку (ф.9) вокруг самой задачи не остаётся ни одной точки, где человек обязателен.
Тонкость в единице работы. «AI пишет код» большинство представляет как ускоренного инженера: человек сидит в IDE, агент дополняет строки. Это помощник. ADLC-единица другая: не строка с автодополнением, а задача, которая сама превращается в готовый PR без человека в цикле.
Роль человека сегодня
Инженер-разработчик берёт задачу с доски, читает контекст, пишет код и тесты уровня задачи, коммитит, открывает PR, отвечает на замечания ревью. Классически AI живёт внутри этого цикла как автодополнение — ускоряет инженера, не выходя за границы его роли. Решение, коммуникация и ответственность остаются на человеке.
Если снять ускорение и посмотреть на суть, работа инженера на этой фазе — перевод задачи с критериями приёмки в код, проходящий тесты, в рамках заданной архитектуры. Это преобразование спецификации в реализацию — ровно тот класс задач, где агент силён и где его слабости лежат не внутри задачи, а на стыках между задачами.
Что передаём агенту
Агент-инженер держит задачу целиком. Он читает назначенную задачу из доски, разбирается в кодовой базе и контрактах, пишет код и тесты уровня задачи, коммитит, открывает PR и отвечает на замечания ревью-агента — без человека в цикле. Единица — «задача → готовый PR», а не «строка → следующая строка».
Меняется и то, что раньше держало инженера незаменимым: он был единственным, кто понимал свой кусок кода. В команде агентов с общей внешней памятью «владения куском» нет — контекст задачи, архитектура и ADR доступны любому агенту одинаково. Знание перестаёт быть личным капиталом инженера и становится общим состоянием.
Архитектура агента
State-machine фазы
Входы
назначенная задача (ф.7), architecture + ADR (ф.5), кодовая база, контракты API, стандарты проекта.
Агент держит роль
Инструменты: доступ к репозиторию; запуск сборки и тестов локально; работа с git и PR; чтение зависимостей и контекста кода; доступ к ADR как к обязательным ограничениям.
Артефакт
PR с кодом и тестами уровня задачи, привязанный к задаче на доске.
Передача дальше: PR → Code review (ф.9); статус задачи → обратно в Planning (ф.7). PR как единица — не деталь, а суть. Он атомарен, привязан к задаче, проверяем и отчуждаем от автора: неважно, какой агент его написал, — важно, что он проходит ревью и тесты. Это делает исполнителя взаимозаменяемым, а работу — прозрачной для контура сверху.
- Входы: назначенная задача (ф.7),
architecture + ADR(ф.5), кодовая база, контракты API, стандарты проекта. - Инструменты: доступ к репозиторию; запуск сборки и тестов локально; работа с git и PR; чтение зависимостей и контекста кода; доступ к ADR как к обязательным ограничениям.
- Артефакт: PR с кодом и тестами уровня задачи, привязанный к задаче на доске.
- Триггер: задача перешла в статус
assignedна доске (ф.7). - Передача дальше: PR → Code review (ф.9); статус задачи → обратно в Planning (ф.7).
PR как единица — не деталь, а суть. Он атомарен, привязан к задаче, проверяем и отчуждаем от автора: неважно, какой агент его написал, — важно, что он проходит ревью и тесты. Это делает исполнителя взаимозаменяемым, а работу — прозрачной для контура сверху.
Где ломается
Стыки между задачами. Слабость агента-инженера не внутри задачи, а между задачами. Несколько агентов пишут параллельно и незаметно расходятся в допущениях: один понял контракт так, другой иначе. Человек-инженер поймал бы дрейф «чутьём» на общий код, которым он владеет; у агентов этого чутья нет — им нужна явная синхронизация контрактов, иначе стыки поплывут.
Немой технический долг. Агент проходит тесты — и на этом его локальная цель выполнена. Но проходящий тесты код может накапливать решения, дорогие в поддержке: дублирование, обходные пути, размывание архитектуры. Тесты зелёные, долг растёт молча. Ловить это должен не сам автор, а ревью и governance.
Ответственность за код в проде. Лицензии скопированных паттернов, встроенные уязвимости, данные, утёкшие в логи, — за код, доехавший до прода, отвечает субъект. Агент написал; кто отвечает — вопрос не фазы 8, а контура над ней.
Что остаётся человеку
В самом цикле кодинга — в пределе ничего. Это первая фаза, где честный остаток человека пуст: задача входит, PR выходит, ни одна точка внутри не требует человека. Остаток не исчезает, а перемещается — в ревью (ф.9), где нужен независимый взгляд, и в governance (ф.14), где нужна ответственность за то, что доедет до прода.
остаток человека ≈ 46%
Провокация / тезис
Кодинг — фаза, где человек вымывается на практике уже сегодня, поэтому провокация здесь не в том, что агент пишет код. Она в том, что при PM-агенте сверху и ревью-агенте сбоку вокруг задачи не остаётся ни одной точки, где человек обязателен: постановку сделал один агент, исполнение — другой, проверку — третий. Инженер был незаменим не потому, что писал код, а потому, что владел контекстом своего куска. Общая внешняя память отбирает у него это владение — и вместе с ним последнее основание незаменимости.
«Витрина» на этой фазе
Платёжный бэкенд-агент берёт задачу «интеграция провайдера и идемпотентность транзакций». Он читает не только задачу, но и ADR из фазы 5 — тот самый, про неустойчивость к повторам вебхука, — и обязан ему следовать. Пишет код, тесты уровня задачи, открывает PR, привязанный к задаче на доске «Витрины». Параллельно фронт-агент делает экран оплаты, второй бэкенд-агент — каталог и корзину.
И здесь же проступает слабость на стыке: агент корзины и агент платежей по-разному поняли, в какой момент заказ считается «оплаченным» — до подтверждения вебхука или после. Внутри каждой задачи всё зелено, тесты проходят. Дрейф допущения живёт ровно на границе двух PR — и внутри фазы 8 его никто не видит. Его поймает ревью в фазе 9, потому что там стоит агент с другим взглядом и с доступом к обоим контрактам. Фаза 8 сдаёт два корректных по отдельности PR — и один скрытый конфликт между ними.
Как это устроено — инженерные разборы
Отдельные howto из практики, где фаза показана на работающем коде и артефакте.
- Cursor rules как governance: как держать планку качества, когда команда вайб-кодитКак держать планку качества, когда команда вайб-кодит.
- ML recommendation system вайб-кодингом: учебный проект production-уровняProduction-проект вайб-кодингом: кодинг агентом от задачи до артефакта.
Читать дальше
Строите AI-driven доставку у себя?
Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.
Написать на почтуДвижок перехода
Next Move Engine — система, которая доводит команду до автономного цикла доставки.
Next Move Engine →