В какой-то момент мне стало интересно не “умеет ли агент писать код”, а другой вопрос: можно ли провести заметную инженерную задачу так, чтобы продуктовый код руками не писать вообще. То есть совсем. Человек формулирует задачу, задаёт ограничения, пишет тест кейсы, ревьюит результат и проводит финальные проверки. Все изменения в коде делает агент.
У OpenAI есть материал про Harness Engineering: там разбирают похожий по духу эксперимент, только в гораздо большем масштабе. Идея, что человек задаёт рамки — постановку, правила, проверку результата — а объёмную реализацию берёт на себя агент, меня вдохновила именно эта история.
Harness Engineering (OpenAI): что это за подход
По материалу OpenAI Harness в названии — не случайное слово: harness в их подаче это не «ещё один фреймворк», а контролируемое окружение вокруг модели: совокупность правил, контекста, инструментов и контуров обратной связи, в которых агент может безопасно набирать объём кода. Важным становится не строчка в редакторе, а качество среды: как устроен репозиторий, что считается допустимой архитектурой, как ловят регрессии, как документируют поведение.
Роль инженера смещается к проектированию и поддержанию окружения: постановка задачи, ограничения, ревью, эволюция процесса, а реализацию всё чаще пишет агент. В статье описан их внутренний эксперимент в таком режиме, на порядки крупнее по охвату, чем описанная мной задача, но логика та же: проверить, как это работает, когда «продуктовый код руками» почти не пишется.
Полная картина, цифры и детали процесса — в статье по ссылке выше, здесь я лишь аргументировал почему пошел проверять похожую гипотезу у себя.
В индустрии уже публично обсуждают сдвиг от «печатаю каждую строчку сам» к тому, что основной объём кода создаёт ИИ при человеческом надзоре.
Индустрия: публичный контекст про ИИ в разработке
В Anthropic CPO Mike Krieger на Cisco AI Summit описывал ситуацию, когда продукты компании по сути пишет Claude («Claude writing Claude»); CEO Dario Amodei в интервью называл долю ИИ-сгенерированного кода порядка 90% и подчёркивал, что люди всё равно нужны на сложных участках.
Meta связывает внутренние цели с «AI-native» разработкой и высокими долями ИИ-ассистируемых изменений — см. разбор утёкших документов и целей по командам.
Amazon через внутреннее письмо, которое цитирует Reuters, продвигает собственный инструмент Kiro и сужает поддержку сторонних ИИ-инструментов для разработки.
Отдельно — масштаб у стартапов: TechCrunch передаёт слова партнёра Y Combinator о том, что у заметной части когорты Winter 2025 кодовая база почти целиком сгенерирована LLM.
Это не тезис, что «ручной код исчез», это ощутимый контекст, почему проверять режим «агент пишет, человек задаёт рамки» на реальной задаче уже более чем уместно и давно пора.
Критическое мышление подсказывает, что бездумно переносить выводы пусть и уважаемых компаний на свой проект бессмысленно. Разумно проверить, насколько это применимо к нашей кодовой базе: большому легаси-проекту высоконагруженной системы, а не к mvp или проекту возрастом несколько месяцев.
Чтобы было ясно, о каком «легаси» идет речь и насколько это применимо к похожему классу проектов:
Порядок величин: наш монорепозиторий
Показатель | Порядок величины |
|---|---|
SBT-модулей в монорепозитории | 25 отдельных подпроектов (плюс корневой aggregate) |
Объём исходников | ~310 тыс. строк в отслеживаемых |
Дополнительно | ещё ~10 тыс. строк в SQL и Python (миграции, тесты, утилиты) |
История в git | около восьми лет непрерывной разработки |
Что вы узнаете из статьи
На каких задачах режим “ни строчки кода руками” уже практически применим.
Как готовить контекст для агента, чтобы он не гадал, а работал в заданном направлении.
Почему тесты здесь нужны не для галочки, а как язык управления агентом.
Где агент реально экономит часы рутины, а где только создаёт иллюзию скорости.
Что такое согласованные ошибки и почему зелёные тесты могут вас обмануть.
Почему после такого эксперимента у разработчиков могут остаться разные выводы.
Где находятся границы применимости такого подхода при нынешнем уровне моделей.
1. Условия эксперимента
Правила были простые. Продуктовый код руками не писать. Вообще.
Роль человека в этом режиме
Моя роль в этом режиме выглядела так:
задать архитектурные границы задачи
разложить работу на этапы
сформулировать требования и ограничения
определить тестовые сценарии
ревьюить промежуточный результат
руками проверить финальное поведение
Роль агента в этом режиме
Роль агента была другой:
создавать и менять код
переносить и адаптировать существующие части
писать значительную часть тестов по заданным сценариям
собирать вспомогательную инфраструктуру
исправлять найденные дефекты
2. Почему эта задача вообще подошла
Во-первых: типовая инженерная работа
Во-первых, это была относительно типовая инженерная работа. Не изобретение новой архитектуры с нуля, не исследовательская разработка, не прыжок в неизвестную предметную область. Уже существовал рабочий кусок системы, который нужно было аккуратно выделить в отдельный сервис, не поломав поведение.
Во-вторых: образцы похожих решений в кодовой базе
Во-вторых, в кодовой базе были образцы похожих решений. Это резко снижает пространство фантазии. Агенту не нужно “придумывать как правильно”. Ему нужно смотреть на уже работающий паттерн и повторять его в новом месте.
В-третьих: механическая часть задачи
В-третьих, в задаче было много механической работы: перенос файлов, адаптация зависимостей, подстройка wiring, сборка тестовой инфраструктуры, повторяющиеся изменения по образцу. Это именно тот тип нагрузки, где агент сейчас даёт самый заметный выигрыш.
В-четвёртых: проверяемость через тесты и ручной прогон
В-четвёртых, задачу можно было проверять через тесты и через финальную ручную интеграционную проверку. То есть у нас был способ быстро отличать “похоже работает” от “действительно работает”. Без этого весь эксперимент быстро превращается в генерацию уверенного, но недопроверенного кода.
3. Как был устроен процесс
Рабочая схема в итоге оказалась довольно прозаичной:
Документация внезапно перестаёт быть бюрократией и становится интерфейсом управления
Самое полезное наблюдение здесь в том, что документация внезапно перестаёт быть бюрократией и становится интерфейсом управления. Пока у агента нет нормального контекста, он не программирует, а угадывает. Как только у него появляется внятная рамка, качество резко меняется.
Разбиваем задачу на этапы.
Я разбивал задачу на этапы. Не “сделай весь сервис”, а “подготовь каркас”, “перенеси существующую логику без изменения поведения”, “добавь тесты на такие-то сценарии”, “собери e2e-контур”, “разбери вот этот сбой”. Такой темп оказался заметно лучше одной большой постановки.
Тесты становятся средством управления
Тесты здесь тоже работали не как ритуал, а как средство управления. Когда заранее определены сценарии и критерии готовности, агенту проще двигаться к проверяемому результату. Когда этого нет, он начинает очень правдоподобно достраивать недостающую реальность у себя в голове. На короткой дистанции это выглядит эффектно. На длинной вылезают сюрпризы.
Ниже — типичные фрагменты: как выглядел «контекст для агента» до того, как он трогал код, и как звучали промты по этапам.
Пример: фрагменты ADR и плана
ADR и план
# ADR-42: вынести обработку вебхуков канала X из монолита ## Контекст Канал X сейчас обрабатывается внутри ядра. Остальные каналы уже живут отдельными сервисами за брокером сообщений. ## Варианты 1. Тонкая обёртка: перенести существующий код с минимальными правками (пакеты, wiring). 2. Переписать обработчик «по-новому» на другом стеке. 3. Оставить как есть. ## Решение Вариант 1: меньше всего неявного поведения теряется при переносе; архитектура выравнивается с остальными каналами. ## Последствия + единый паттерн для всех каналов − временное дублирование кода; рефакторинг — отдельной задачей
# PLAN.md — план работ ## Этап 0. Документация - SPEC: форматы сообщений в брокере, ошибки, критерии приёмки. ## Этап 1. Тесты на чистые куски - Вынести разбор события вебхука в функцию без изменения ветвлений. ## Этап 2. Модуль адаптера - Новый артефакт сборки, копирование файлов из ядра, только пакеты/импорты до `compile`. ## Этап 3. E2E - Поднять брокер, БД, мок внешнего HTTP API; сценарий «вебхук → сообщение в брокере».
Промты для нескольких этапов одной задачи
Промты по этапам
Этап — архитектурный чертёж
Изучи, как устроены адаптеры каналов A и B: как они подписываются на брокер и публикуют входящие события. Найди в монолите обработку вебхуков канала X. Напиши ADR с тремя вариантами: обёртка / переписать / оставить в ядре. Рекомендуй обёртку и опиши последствия. Файлы положи в architecture/adr/, код пока не меняй.
Этап — тесты как контракт
В классе WebhookHandler есть ветвление по типу чата. Вынеси его в чистую функцию routeEvent(...). Поведение не улучшай — копируй ветки as-is. Напиши unit-тесты: личный чат, группа, неизвестный тип, пустое тело. Критерий: `sbt test` для модуля зелёный.
Этап — новый модуль
Создай sbt-модуль channel-x-adapter по SPEC из ADR-42. Скопируй перечисленные файлы из монолита; меняй только пакеты, импорты и зависимости до успешной компиляции без `dependsOn(core)`. Запрет: не рефакторить бизнес-логику сообщений в этом этапе.
Этап — e2e-контур
Добавь каталог e2e/ на pytest + testcontainers: контейнер брокера, PostgreSQL, мок внешнего API на отдельном порту. Напиши один тест: POST вебхука с текстом "ping" → в брокере на ожидаемом subject появилось событие с text=ping.
4. Где агент реально дал выигрыш
Агент не поразил меня внезапными архитектурными открытиями. Зато он очень хорошо отработал на объёмной инженерной рутине.
Лучше всего сработали такие куски работы
Лучше всего сработали такие куски работы:
перенос и адаптация уже существующего кода
повторение известных паттернов по образцу
генерация boilerplate и связующего кода
построение тестовой инфраструктуры
выпуск серии однотипных правок после обратной связи
То, на что руками обычно уходит много внимания просто из-за объёма, агент отлично закрывает. Особенно если четко заданы границы: ничего не улучшай, поведение не меняй, вот образец, вот критерий готовности.
Отдельно удивило, насколько полезным оказался агент в поднятии e2e-контура. Это не самая интеллектуально красивая часть задачи, но она часто откладывалась, потому что муторная.
Пример e2e-сценария
E2E: pytest + брокер + мок внешнего API
# фикстуры: контейнер брокера, адаптер, мок внешнего HTTP API def test_incoming_webhook_publishes_to_broker(e2e): e2e.http.post("/webhook/channel-x", json={"message": {"text": "hello", "chat": {"id": 42}}}) msg = e2e.broker.await_message("inbound.channel-x", timeout_s=5) assert msg["text"] == "hello" assert msg["chat_id"] == 42 def test_outgoing_command_reaches_external_api(e2e): e2e.broker.publish("outbound.channel-x", {"chat_id": "42", "text": "hi"}) calls = e2e.external_mock.wait_for_requests(method="POST", path_contains="sendMessage") assert any(b"hi" in c.body for c in calls)
Идея: проверить не только «код компилируется», а что собранный сервис в связке с инфраструктурой ведёт себя ожидаемо.
5. Ограничения
А дальше началась самая интересная часть: ограничения.
Первое: агент не принимает архитектурные решения
Первое: агент не принимает архитектурные решения в том смысле, в котором их принимает инженер. Он может сравнить варианты, пересказать паттерны, помочь оформить решение. Но выбор границ, допустимых компромиссов и порядка изменений всё равно остаётся на человеке.
Второе: зелёные тесты не гарантируют, что агент понял систему
Второе: зелёные тесты не гарантируют, что агент понял систему. Самый неприятный сбой в этом эксперименте как раз вырос из ситуации, когда код, мок внешнего API и e2e-тесты были согласованы между собой, но согласованы вокруг неверного предположения. Всё зелёное. А на реальной интеграции сбой.
Это важный класс проблем, я для себя называю его согласованной ошибкой.
Что такое согласованные ошибки и почему зелёные тесты могут вас обмануть
Один и тот же агент порождает одну и ту же модель реальности сразу в нескольких артефактах. Из-за этого тесты начинают подтверждать не соответствие реальному контракту, а внутреннюю согласованность выдуманной версии мира.
Коротко: код, мок и тест согласованы друг с другом, но все трое не совпадают с реальным контрактом внешней системы. Тогда прогон зелёный, а интеграция ломается.
Ниже — упрощённый пример: клиент ходит за файлом не по тому пути, мок подтверждает тот же неверный путь, тест проверяет «файл дошёл», а настоящий API живёт под другим префиксом.
Согласованная ошибка: клиент, мок и тест
Клиент (Scala) — агент «узнал» из контекста задачи путь /files/{id}, без сверки с документацией ядра:
def fileDownloadUrl(apiBase: String, id: String): String = s"${apiBase.stripSuffix("/")}/files/$id"
Мок внешнего API (Python) — тот же префикс, тесты проходят:
@app.get("/files/{file_id}") def serve_file(file_id: str): return FileResponse(path=f"/tmp/e2e-store/{file_id}")
Фрагмент теста — проверяем, что адаптер сходил за файлом и что-то опубликовал. Контракт с реальным ядром мы не проверяли:
def test_outbound_with_attachment(e2e, tmp_path): fid = "doc-1" (tmp_path / fid).write_bytes(b"data") e2e.register_file(fid, tmp_path / fid) # мок отдаёт по /files/doc-1 e2e.broker.publish("outbound", {"file_id": fid, "chat_id": "1"}) e2e.run_adapter_until_idle() sent = e2e.external_mock.last_request_matching("/files/doc-1") assert sent is not None # всё согласовано — и с ошибкой в URL тоже
В проде же ядро отдаёт файлы, например, по /api/v1/files/{id}. Пока вы не сравнили путь с реальным сервисом, e2e может быть зелёным весь день.
Схематично:
сервис ----GET /files/id----> мок /files/id (e2e: OK) сервис ----GET /api/v1/files/id----> реальное ядро (в бою: 404, если клиент не тот)
6. Почему мнения могут разделиться
По итогу эксперименту было две точки зрения.
Одна позиция примерно такая: выигрыш уже заметен
Одна позиция примерно такая: выигрыш уже заметен. На задачах с понятной структурой агент снимает большой пласт механической работы, ускоряет движение по этапам и позволяет инженеру держать фокус не на наборе кода, а на решениях и проверке.
Другая позиция звучит осторожнее: скорость выросла, но вырос и риск ложного ощущения готовности
Другая позиция звучит осторожнее: да, скорость местами выросла, но вместе с ней вырос и риск ложного ощущения готовности. Нужно много ревью, много перепроверки, а часть времени уходит на контроль самого процесса. Если задача нетиповая, с плохими контрактами или дорогой ошибкой, такой режим пока выглядит опасно.
Обе позиции, на мой взгляд, нормальные. Это не спор между “технооптимистами” и “ретроградами”. Это обычная инженерная разница в оценке trade-off’ов.
7. Где границы применимости
Подход “ни строчки кода руками” лучше всего работает там, где задача относительно типовая. Есть рабочие примеры. Есть понятные интерфейсы. Есть что проверять тестами. Есть много механической работы и мало исследовательской неопределённости.
Как только задача уходит в зону плохо описанной предметной области, новых архитектурных решений, нестабильных внешних контрактов или дорогих неочевидных ошибок, ценность агента не исчезает, но режим полной делегации начинает проседать. Там уже хочется либо сильнее сужать этапы, либо возвращать часть реализации человеку.
Короче, это не универсальная модель разработки. Это рабочий режим для определённого класса задач. И уже это довольно много.
8. Вывод
Меняется разделение труда. Человек всё меньше занят механической реализацией и всё больше занимается постановкой, ограничениями, проверкой и выбором компромиссов.
Но делать из этого окончательный вывод рано. Эксперимент скорее подтвердил, что подход уже практически применим, чем доказал, что он универсален. Через год границы могут сдвинуться. А могут и не так быстро, как сейчас многим кажется.
На типовых инженерных задачах такой подход уже реально полезен. На сложных и слабо определённых задачах человек всё ещё необходим.
9. Поделитесь опытом !
Я написал статью чтобы обменяться опытом и получить от сообщества живую обратную связь.
Мне интересно узнать от вас, по возможности в комментариях:
пользуетесь ли вы на реальных проектах таким же или похожим подходом: «код пишет агент, человек задаёт рамки и проверяет»;
или хотя бы отдельными частями — тесты как контракт, поэтапные промты, жёсткий запрет на «перепиши всё красиво» без задачи;
насколько вы скептически к этому настроены и что именно вас смущает больше всего: качество, безопасность, скорость, ревью, юридические моменты, что угодно.
Если коротко: расскажите, как у вас, — мне как раз не хватает этой картины из разных команд и стеков.
Огромная благодарность тем, кто дочитал статью до конца. Предложу зайти ко мне в канал в Telegram о разработке в стартапах. В нем рассказываю ещё больше интересного и делюсь опытом, заходите, обязательно найдете полезные кейсы!
Удачных всем релизов!
