Процесс внедрения агентов в разработку обычно проходит следующие этапы зрелости:

1. LLM as autocomplete: подсказывает продолжение кода прямо в редакторе. Системы вокруг не видит, между запросами ничего не помнит. Помогает с локальным кодом.
2. Agent as a coding partner: агент пишет код, разработчик формулирует задачу, направляет, контролирует результат. Но каждый запуск начинает с чистого листа: проектные инварианты и связи между файлами приходится снова загружать в промпт. Иногда ломает работающий код, потому что не понимает, почему он так написан.
3. Agentic development pipeline: агенты больше не работают поодиночке, а собраны в пайплайн с разделением ролей. У них есть общее знание о системе в виде спеков. Человек смещается из роли «писать код» в роль «одобрять ключевые решения».
4. Agentic SDLC: пайплайны накрывают не только разработку, а весь жизненный цикл: от появления задачи до инцидентов в продакшне. Человек включается только на самом верхнем уровне: стратегия и приёмка.

Большинство команд, которые активно используют AI, сейчас на этапах 2–3. Мой личный процесс разработки сейчас на уровне 3. Вот как он устроен.

Идея в трёх слоях.

Specs driven dev. Сначала спеки, потом план, потом код. Строго в таком порядке. Агент знает, как работает система, только потому что у него есть спеки. Это даёт ревьюеру способ ловить «агент написал больше, чем ему сказали»: всё, чего нет в требованиях, считается багом, даже если код корректный. И наоборот: любое изменение кода, противоречащее существующим требованиям, тоже баг. Спека сначала задаёт задачу, а потом становится критерием приёмки.

Оркестратор и агенты на шаги. Один агент правит спеки и составляет план. Второй реализует по плану: пишет код и тесты. Третий ревьюлит. Оркестратор сам ничего не пишет, только смотрит, чья сейчас очередь. У каждого агента свой набор инструментов, свои промпты и свои запреты. Это принцип минимизации радиуса поражения: ошибка агента не выходит за его зону ответственности. Самый яркий случай — ревьюер. У него вообще нет write-инструментов, поэтому он буквально не может сломать ни строчки в проекте. Только оставить комментарий.

Синхронизация через PR в GitHub. Состояние пайплайна живёт в лейблах PR. Переписка разработчика с агентами и агентов между собой идёт в инлайн-тредах. Отдельный канал координации между агентами не нужен. Лейбл — source of truth для оркестратора. Он по лейблу решает, какого агента запустить, и сам же выставляет новый лейбл, когда шаг закончен. Сам оркестратор stateless: между запусками он не помнит ничего, фазу определяет по лейблу. Из-за этого его можно прервать и перезапустить в любой момент. Задача продолжится с нужного места.

Разработчик в этой схеме остаётся в двух точках: одобряет изменения в спеках и плане, и принимает результат. Это контрольные шлюзы, через которые оркестратор не проходит сам. Всё остальное автоматизировано так, чтобы у него осталось ровно два момента влияния.