В какой-то момент мне стало интересно не “умеет ли агент писать код”, а другой вопрос: можно ли провести заметную инженерную задачу так, чтобы продуктовый код руками не писать вообще. То есть совсем. Человек формулирует задачу, задаёт ограничения, пишет тест кейсы, ревьюит результат и проводит финальные проверки. Все изменения в коде делает агент.
У OpenAI естьматериал про Harness Engineering: там разбирают похожий по духу эксперимент, только в гораздо большем масштабе. Идея, что человек задаётрамки— постановку, правила, проверку результата — а объёмную реализацию берёт на себя агент, меня вдохновила именно эта история.
Поматериалу OpenAIHarnessв названии — не случайное слово:harnessв их подаче это не «ещё один фреймворк», аконтролируемое окружениевокруг модели: совокупность правил, контекста, инструментов и контуров обратной связи, в которых агент может безопасно набирать объём кода. Важным становится не строчка в редакторе, а качество среды: как устроен репозиторий, что считается допустимой архитектурой, как ловят регрессии, как документируют поведение.
Роль инженера смещается кпроектированию и поддержанию окружения: постановка задачи, ограничения, ревью, эволюция процесса, а реализацию всё чаще пишет агент. В статье описан ихвнутренний экспериментв таком режиме, на порядки крупнее по охвату, чем описанная мной задача, но логика та же: проверить, как это работает, когда «продуктовый код руками» почти не пишется.
Полная картина, цифры и детали процесса — в статье по ссылке выше, здесь я лишь аргументировалпочемупошел проверять похожую гипотезу у себя.
В индустрии уже публично обсуждают сдвиг от «печатаю каждую строчку сам» к тому, что основной объём кода создаёт ИИ при человеческом надзоре.
- В Anthropic CPOMike Krieger на Cisco AI Summit описывалситуацию, когда продукты компании по сути пишет Claude («Claude writing Claude»); CEODario Amodei в интервью называлдолю ИИ-сгенерированного кода порядка 90% и подчёркивал, что люди всё равно нужны на сложных участках.
- Meta связывает внутренние цели с «AI-native» разработкой и высокими долями ИИ-ассистируемых изменений — см. разборутёкших документов и целей по командам.
- Amazon черезвнутреннее письмо, которое цитирует Reuters, продвигает собственный инструмент Kiro и сужает поддержку сторонних ИИ-инструментов для разработки.
- Отдельно — масштаб у стартапов:TechCrunch передаёт слова партнёра Y Combinatorо том, что у заметной части когорты Winter 2025 кодовая база почти целиком сгенерирована LLM.
Это не тезис, что «ручной код исчез», это ощутимый контекст, почему проверять режим «агент пишет, человек задаёт рамки» на реальной задаче уже более чем уместно и давно пора.
Критическое мышление подсказывает, что бездумно переносить выводы пусть и уважаемых компаний на свой проект бессмысленно. Разумно проверить,насколько это применимо к нашей кодовой базе: большому легаси-проекту высоконагруженной системы, а не к mvp или проекту возрастом несколько месяцев.
Чтобы было ясно, о каком «легаси» идет речь и насколько это применимо к похожему классу проектов:
Показатель
Порядок величины
SBT-модулей в монорепозитории
25отдельных подпроектов (плюс корневой aggregate)
Объём исходников
~310 тыс. строкв отслеживаемых*.scala,*.javaи*.sbt
Дополнительно
ещё~10 тыс. строкв SQL и Python (миграции, тесты, утилиты)
История в git
около восьми летнепрерывной разработки
- На каких задачахрежим “ни строчки кода руками” уже практически применим.
- Как готовить контекстдля агента, чтобы он не гадал, а работал в заданном направлении.
- Почемутесты здесь нужны не для галочки, а как язык управления агентом.
- Где агент реально экономит часы рутины, а где только создаёт иллюзию скорости.
- Что такоесогласованные ошибкии почему зелёные тесты могут вас обмануть.
- Почему после такого эксперимента у разработчиков могут остатьсяразные выводы.
- Где находятсяграницы применимоститакого подхода при нынешнем уровне моделей.
1. Условия эксперимента
Правила были простые. Продуктовый код руками не писать. Вообще.
Моя роль в этом режиме выглядела так:
- задать архитектурные границы задачи
- разложить работу на этапы
- сформулировать требования и ограничения
- определить тестовые сценарии
- ревьюить промежуточный результат
- руками проверить финальное поведение
Роль агента была другой:
- создавать и менять код
- переносить и адаптировать существующие части
- писать значительную часть тестов по заданным сценариям
- собирать вспомогательную инфраструктуру
- исправлять найденные дефекты
2. Почему эта задача вообще подошла
Во-первых, это была относительно типовая инженерная работа. Не изобретение новой архитектуры с нуля, не исследовательская разработка, не прыжок в неизвестную предметную область. Уже существовал рабочий кусок системы, который нужно было аккуратно выделить в отдельный сервис, не поломав поведение.
Во-вторых, в кодовой базе были образцы похожих решений. Это резко снижает пространство фантазии. Агенту не нужно “придумывать как правильно”. Ему нужно смотреть на уже работающий паттерн и повторять его в новом месте.
В-третьих, в задаче было много механической работы: перенос файлов, адаптация зависимостей, подстройка wiring, сборка тестовой инфраструктуры, повторяющиеся изменения по образцу. Это именно тот тип нагрузки, где агент сейчас даёт самый заметный выигрыш.
В-четвёртых, задачу можно было проверять через тесты и через финальную ручную интеграционную проверку. То есть у нас был способ быстро отличать “похоже работает” от “действительно работает”. Без этого весь эксперимент быстро превращается в генерацию уверенного, но недопроверенного кода.
3. Как был устроен процесс
Рабочая схема в итоге оказалась довольно прозаичной:
Самое полезное наблюдение здесь в том, что документация внезапно перестаёт быть бюрократией и становится интерфейсом управления. Пока у агента нет нормального контекста, он не программирует, а угадывает. Как только у него появляется внятная рамка, качество резко меняется.
Я разбивал задачу на этапы. Не “сделай весь сервис”, а “подготовь каркас”, “перенеси существующую логику без изменения поведения”, “добавь тесты на такие-то сценарии”, “собери e2e-контур”, “разбери вот этот сбой”. Такой темп оказался заметно лучше одной большой постановки.
Тесты здесь тоже работали не как ритуал, а как средство управления. Когда заранее определены сценарии и критерии готовности, агенту проще двигаться к проверяемому результату. Когда этого нет, он начинает очень правдоподобно достраивать недостающую реальность у себя в голове. На короткой дистанции это выглядит эффектно. На длинной вылезают сюрпризы.
Ниже — типичные фрагменты: как выглядел «контекст для агента» до того, как он трогал код, и как звучали промты по этапам.
Пример: фрагменты ADR и плана
Промты для нескольких этапов одной задачи
Этап — архитектурный чертёж
Этап — тесты как контракт
Этап — новый модуль
Этап — e2e-контур
4. Где агент реально дал выигрыш
Агент не поразил меня внезапными архитектурными открытиями. Зато он очень хорошо отработал на объёмной инженерной рутине.
Лучше всего сработали такие куски работы:
- перенос и адаптация уже существующего кода
- повторение известных паттернов по образцу
- генерация boilerplate и связующего кода
- построение тестовой инфраструктуры
- выпуск серии однотипных правок после обратной связи
То, на что руками обычно уходит много внимания просто из-за объёма, агент отлично закрывает. Особенно если четко заданы границы: ничего не улучшай, поведение не меняй, вот образец, вот критерий готовности.
Отдельно удивило, насколько полезным оказался агент в поднятии e2e-контура. Это не самая интеллектуально красивая часть задачи, но она часто откладывалась, потому что муторная.
Пример e2e-сценария
Идея: проверить не только «код компилируется», а чтособранныйсервис в связке с инфраструктурой ведёт себя ожидаемо.
5. Ограничения
А дальше началась самая интересная часть: ограничения.
Первое: агент не принимает архитектурные решения в том смысле, в котором их принимает инженер. Он может сравнить варианты, пересказать паттерны, помочь оформить решение. Но выбор границ, допустимых компромиссов и порядка изменений всё равно остаётся на человеке.
Второе: зелёные тесты не гарантируют, что агент понял систему. Самый неприятный сбой в этом эксперименте как раз вырос из ситуации, когда код, мок внешнего API и e2e-тесты были согласованы между собой, но согласованы вокруг неверного предположения. Всё зелёное. А на реальной интеграции сбой.
Это важный класс проблем, я для себя называю его согласованной ошибкой.
Один и тот же агент порождает одну и ту же модель реальности сразу в нескольких артефактах. Из-за этого тесты начинают подтверждать не соответствие реальному контракту, а внутреннюю согласованность выдуманной версии мира.
Коротко:код, мок и тест согласованы друг с другом, но все трое не совпадают с реальным контрактом внешней системы.Тогда прогон зелёный, а интеграция ломается.
Ниже — упрощённый пример: клиент ходит за файлом не по тому пути, мок подтверждает тот же неверный путь, тест проверяет «файл дошёл», а настоящий API живёт под другим префиксом.
Клиент (Scala)— агент «узнал» из контекста задачи путь/files/{id}, без сверки с документацией ядра:
Мок внешнего API (Python)— тот же префикс, тесты проходят:
Фрагмент теста— проверяем, что адаптер сходил за файлом и что-то опубликовал. Контракт с реальным ядром мы не проверяли:
В проде же ядро отдаёт файлы, например, по/api/v1/files/{id}. Пока вы не сравнили путь с реальным сервисом, e2e может быть зелёным весь день.
Схематично:
6. Почему мнения могут разделиться
По итогу эксперименту было две точки зрения.
Одна позиция примерно такая: выигрыш уже заметен. На задачах с понятной структурой агент снимает большой пласт механической работы, ускоряет движение по этапам и позволяет инженеру держать фокус не на наборе кода, а на решениях и проверке.
Другая позиция звучит осторожнее: да, скорость местами выросла, но вместе с ней вырос и риск ложного ощущения готовности. Нужно много ревью, много перепроверки, а часть времени уходит на контроль самого процесса. Если задача нетиповая, с плохими контрактами или дорогой ошибкой, такой режим пока выглядит опасно.
Обе позиции, на мой взгляд, нормальные. Это не спор между “технооптимистами” и “ретроградами”. Это обычная инженерная разница в оценке trade-off’ов.
7. Где границы применимости
Подход “ни строчки кода руками” лучше всего работает там, где задача относительно типовая. Есть рабочие примеры. Есть понятные интерфейсы. Есть что проверять тестами. Есть много механической работы и мало исследовательской неопределённости.
Как только задача уходит в зону плохо описанной предметной области, новых архитектурных решений, нестабильных внешних контрактов или дорогих неочевидных ошибок, ценность агента не исчезает, но режим полной делегации начинает проседать. Там уже хочется либо сильнее сужать этапы, либо возвращать часть реализации человеку.
Короче, это не универсальная модель разработки. Это рабочий режим для определённого класса задач. И уже это довольно много.
Меняется разделение труда. Человек всё меньше занят механической реализацией и всё больше занимается постановкой, ограничениями, проверкой и выбором компромиссов.
Но делать из этого окончательный вывод рано. Эксперимент скорее подтвердил, что подход уже практически применим, чем доказал, что он универсален. Через год границы могут сдвинуться. А могут и не так быстро, как сейчас многим кажется.
На типовых инженерных задачах такой подход уже реально полезен. На сложных и слабо определённых задачах человек всё ещё необходим.
9. Поделитесь опытом !
Я написал статью чтобыобменяться опытоми получить от сообществаживую обратную связь.
Мне интересно узнать от вас, по возможности в комментариях:
- пользуетесь ли вы на реальных проектахтаким жеилипохожимподходом: «код пишет агент, человек задаёт рамки и проверяет»;
- или хотя быотдельными частями— тесты как контракт, поэтапные промты, жёсткий запрет на «перепиши всё красиво» без задачи;
- насколько выскептическик этому настроены и что именно вас смущает больше всего: качество, безопасность, скорость, ревью, юридические моменты, что угодно.
Если коротко:расскажите, как у вас, — мне как раз не хватает этой картины из разных команд и стеков.
Огромная благодарность тем, кто дочитал статью до конца. Предложу зайти ко мне вканал в Telegramо разработке в стартапах. В нем рассказываю ещё больше интересного и делюсь опытом, заходите, обязательно найдете полезные кейсы!
Удачных всем релизов!
