Есть неприятная иллюзия: если модель стала сильнее, ей можно дать больше свободы. В кодинге это быстро выходит боком. Агент пишет много, уверенно, иногда даже красиво. Потом ты открываешь diff и понимаешь, что вместе с полезным кодом туда попало… ну, назовём это решениями, которые ты сам никогда бы не принял.
У меня после нескольких таких заходов появилась простая граница.
AI может предлагать. Мержу я.
Не потому что я не верю в модели. Наоборот, я ими пользуюсь каждый день и довольно агрессивно. Просто кодинг-агент не отвечает за последствия своих решений. Он быстро пишет код и звучит уверенно, но не умеет остановиться там, где «похоже работает» уже недостаточно. Человек может это поймать, если в процессе есть явная точка, где он принимает решение.
Поэтому вся моя история с map-framework — не про «как сделать агента умнее». Модель я не улучшаю. Я улучшаю среду, в которой её вывод можно безопасно довести до прода.
Где проходит граница
В моём процессе агент не принимает финальное решение.
Он может предложить spec, разложить задачу, написать тесты, написать код, собрать аргументы для review, зафиксировать уроки. Но переходы между стадиями остаются под контролем человека. Особенно последний: merge в основную ветку.
Это звучит как мелочь, пока не начинаешь измерять последствия. Если агент сам двигает задачу дальше, он начинает оптимизировать не то, что нужно. Он не злонамеренный. Он просто упрощает себе жизнь (агент! упрощает себе жизнь! звучит да? :)).
Мне не нужен режим, где агент сам продолжает задачу без проверки. Нужен инструмент для тяжёлой части работы, с явной человеческой точкой решения.
Отсюда и название: AI предлагает, мержу я.
Как это выглядит в работе
Формально это SPEC → PLAN → TEST → CODE → REVIEW → LEARN. На практике я не веду длинный регламент; держу несколько правил.
До кода фиксирую инварианты и критерий готовности. Для рискованного куска сначала нужен тест или хотя бы проверяемый сценарий. Потом агент пишет реализацию.
Review я отдаю отдельной роли: обычно это отдельная консоль с чистым контекстом, чтобы агент в ревью не протащил возможные ошибочные предположения, которые сделал кодинг-агент.
Если проверка упала, план пришлось менять на ходу или понадобилось ручное вмешательство, после этого должен остаться тест или правило. Иначе следующая сессия повторит ту же ошибку.
Что я агенту не разрешаю
Самый важный запрет уже был: агент не мержит сам.
Есть ещё несколько, и они появились не из любви к регламентам. Каждый запрет — реакция на конкретную проблему.
С production secrets граница не в том, что агент никогда не читает файл. Иногда без этого задача не решается. Граница в другом: значения не должны попадать в ответ, transcript, log, markdown-артефакт, diff или любое место, где они переживут саму сессию.
Зелёный CI — не рекомендация. Без него нет merge. Если CI красный, рассуждения агента о том, что «изменение локальное», меня не интересуют.
Невалидный вывод блокируется автоматически. Если monitor видит обрезанный JSON, отсутствующий artifact или нарушение контракта, прогон должен остановиться.
И ещё одно, менее очевидное: каждый прогон пишет артефакты в .map/ — по файлу почти на каждый шаг: spec и план, прогон тестов, отчёты ревью и финальной проверки, список замечаний, зафиксированный урок. Это скучные файлы, но именно они потом отвечают на вопрос «что произошло?». Без артефактов обсуждение быстро превращается в пересказ по памяти и красивую реконструкцию задним числом (помните, что агенты прекрасно и убедительно галлюцинируют?).
Это не значит «тяжело всегда»
Я не хочу тащить весь workflow в каждую правку README.
У меня есть лёгкий режим: короткий план, реализация, проверка, review, запись урока только если он правда есть. Есть полный режим с TDD и отдельными ролями, когда код рискованный. Есть промежуточный вариант, где TDD применяется только к одной подзадаче.
Общая часть одна: закрытие задачи не должно оставаться внутри чата. Нужен явный accept, artifact и проверка, по которой понятно, почему задача считается сделанной.
Иначе в конце есть уверенный ответ агента, но нет результата, который можно проверить.
Почему я вообще полез в эту сторону
map-framework вырос из простой проблемы: кодинг-агенты быстро дают дифф в 10к строк, но как это ревьювить? Как понять, что агент сделал именно то, что ты хотел, а не просто уверенно закрыл задачу?
Свежий пример: замечания ревьюера по IngressConfig в Kubernetes-операторе. Нужно было перенести поля под settings.{nginx,contour}, обновить тесты и CRD/deepcopy, не занести в Go-код служебные метки из плана. Вышло девять коммитов; финальный verifier прогнал gofmt, go vet, go build, func-тесты, сверил CRD-инварианты и нашёл одно не блокирующее замечание: старый комментарий в тесте ещё говорил spec.nginx.enabled, хотя код уже писал в Spec.Settings.Nginx.Enabled. Глазами на ревью такое легко пропустить — а в findings-артефакте это записано. Без него от агента остаётся только слово «готово».
После перехода на такой workflow на боевой Go-платформе с кодовой базой больше миллиона строк за полгода примерно в 1,8 раза вырос объём кода, который пережил review и доехал до main. Считал грубо, по строкам. Метрика не идеальная: строки кода не равны продуктивности. Но для меня это был достаточный сигнал, что процесс стоит разбирать как инженерный механизм. Что выдержало проверку большим кодом — разберу дальше. Что не выдержало — тоже.
Что будет дальше
Это вводная, без глубокой методологии и без схем на пол-экрана. Дальше пойду по местам, где у меня реально ломалось: слишком длинная инструкция для Claude, границы задачи до кода, лишний контекст, память между сессиями. Отдельно разберу, что из arXiv доехало до прода, а что пришлось выбросить. И — чем всё это пересекается и расходится с готовыми наборами вроде GitHub Spec Kit и superpowers: дисциплина агента не новость, вопрос в том, где у каждого граница и enforcement.
Мне интересно не «заменит ли AI разработчиков». Слишком общий вопрос. Мне интересно другое: какие инженерные практики делают кодинг-агентов предсказуемыми настолько, чтобы их можно было пускать в серьёзный код и потом не краснеть на ревью.
Код map-framework открыт — github.com/azalio/map-framework, если хочется посмотреть, как это устроено внутри.
А у вас где проходит граница? Агент может сам мержить, или последний accept всё-таки остаётся за человеком?