AI Dev Podcast #8: контролируемая автономия

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

Команда Владимира начала с вайб-кодинга, а затем взяла за основу AIDLC от Amazon. Облачную привязку и набор инструментов убрали, добавили внутреннюю инфраструктуру, правила оформления кода и собственные ограничения. Методология превратилась в набор подключаемых навыков: правила проекта, этапы жизненного цикла и проверки управления. Это важно не только для качества результата. Небольшие навыки загружают нужный контекст, поэтому агенту не приходится одновременно держать в памяти весь процесс и все документы.

На этапе постановки исходное намерение превращается в пользовательскую историю, нефункциональные требования, риски и измеримый результат, после чего работа делится на небольшие единицы. Владелец продукта должен подтвердить сгенерированные формулировки, хотя на практике эту роль пока часто берёт аналитик. Этап конструирования связывает доменную модель с архитектурными решениями, кодом, клиентами API и инфраструктурой как кодом. В эксплуатации система развёртывается и наблюдается; SRE-агент уже анализирует Grafana и Prometheus и предлагает реакцию на подозрительные сигналы, но автоматически исправлять промышленную систему ему пока не разрешают.

Рабочий контекст перенесли из Confluence в Git рядом с кодом: там живут пользовательские истории, архитектурные решения и внутренняя документация. В общей базе остаются материалы для взаимодействия с другими командами — например, схемы развёртывания и описания API. Такая граница сокращает расходы токенов, делает изменения версионируемыми и даёт агенту единый источник истины. Технически процесс собран из двух крупных агентов: один формирует требования и решения, другой реализует их; проверки могут выполнять подагенты. Более сильные модели направляют на доменную модель, а простые справляются с постановками и декомпозицией.

Автономию удерживают четыре проверки. Проверка ADR требует зафиксировать значимое решение, сверяет его с внутренними правилами и предыдущими решениями; при конфликте выбор возвращается человеку. Матрица трассируемости связывает исходную историю, рабочие единицы, ADR, реализацию и эксплуатационные метрики. Проверка безопасности ищет нарушения базовых правил и секреты в коде; защита, специфичная для LLM, ещё развивается. Итоговая проверка оценивает не доступность приложения, а целостность AIDLC-процесса: пройдены ли обязательные этапы, не потеряны ли решения и трассируемость.

На момент записи два проекта полностью дошли до промышленной эксплуатации, ещё один приближался к запуску, а обратную связь дали около пятнадцати пользователей. В показательном случае один инженер за две недели подготовил первую версию переноса админки с Java на Python; после подключения ещё двух коллег работу завершили менее чем за два месяца. Этот опыт уменьшил размер ADR, уточнил внутренние правила и вернул в процесс трассируемость. Однако проверка шла в основном на небольших репозиториях. Крупная унаследованная система с двадцатью разработчиками ещё впереди: там критичны ограниченный контекст, постепенная загрузка знаний, простота онбординга и независимость процесса от одного энтузиаста.