На монорепозитории с 25 SBT-модулями, ~310 тыс. строк на Scala и Java и восьмилетней историей разработчик провёл эксперимент: вынести обработку вебхуков из монолита в отдельный сервис, не написав ни одной строки продуктового кода вручную. Всё, что менялось в репозитории, создавал ИИ-агент. Человек формулировал задачу, задавал архитектурные ограничения, определял тестовые сценарии и проводил финальную интеграционную проверку.
Отправной точкой послужил материал OpenAI о Harness Engineering — подходе, при котором инженер проектирует и поддерживает управляемое окружение вокруг модели: правила, контекст, инструменты, контуры обратной связи. Агент в этой схеме набирает объём кода, человек отвечает за качество среды. Публичный контекст к моменту эксперимента уже сложился: CPO Anthropic Майк Кригер на Cisco AI Summit описывал ситуацию, когда продукты компании по сути пишет Claude; CEO Dario Amodei называл долю ИИ-сгенерированного кода порядка 90%. Партнёр Y Combinator, по данным TechCrunch, говорил, что у заметной части когорты Winter 2025 кодовая база почти целиком сгенерирована LLM.
Автор намеренно выбрал задачу, которая подходила для такого режима по нескольким признакам. Во-первых, это типовая инженерная работа — выделение существующего куска системы в сервис, а не исследовательская разработка с нуля. Во-вторых, в кодовой базе уже были образцы похожих решений: агенту не нужно было изобретать паттерн, достаточно повторить работающий. В-третьих, задача содержала много механической работы — перенос файлов, адаптация зависимостей, повторяющиеся изменения по образцу. Именно здесь агент даёт наиболее ощутимый выигрыш по времени. В-четвёртых, результат можно было проверить через тесты и ручной прогон, что отделяло «похоже работает» от «действительно работает».
Роль человека — постановка задачи, архитектурные ограничения, тест-сценарии и финальная проверка; агент писал и менял весь код.
Процесс строился на двух принципах. Первый: задача разбивалась на небольшие этапы — «подготовь каркас», «перенеси логику без изменения поведения», «добавь тесты на такие-то сценарии», «разбери вот этот сбой». Одна большая постановка работала заметно хуже. Второй принцип: документация перестала быть бюрократией и стала интерфейсом управления. ADR с описанием контекста, вариантов и принятого решения, PLAN.md с разбивкой по этапам — без этого агент не программировал, а угадывал. Как только появлялась внятная рамка, качество результата менялось.
Автор фиксирует несколько нетривиальных наблюдений. Тесты в этом режиме работают не как ритуал, а как язык управления агентом: заранее определённые сценарии и критерии готовности дают агенту проверяемую цель. Без них агент начинает достраивать недостающую реальность — на короткой дистанции это выглядит убедительно, на длинной вылезают сюрпризы. Отдельно выделена проблема «согласованных ошибок»: зелёные тесты могут создавать иллюзию корректности, если тесты и реализация содержат одно и то же неверное допущение.
Эксперимент намеренно проводился не на MVP и не на молодом проекте — именно чтобы проверить применимость подхода к тому классу систем, где большинство реальных инженерных задач и живёт. Автор не делает универсального вывода о том, что ручной код исчез или что агенты готовы к любой задаче. Вывод скромнее: на задачах с высокой долей механической работы, понятными паттернами и проверяемым результатом режим «агент пишет, человек задаёт рамки» уже практически применим — при условии, что инженер умеет готовить контекст и не доверяет зелёным тестам безоговорочно.
