Переписать код с помощью ИИ-агентов — не теория, а практика: в июле 2026 года автор треда на Hacker News собрал агентный пайплайн planner→coding→reviewer над 15-летним SaaS с миллионом строк на C#/React и получил MVP за четыре недели. Разбираем его процесс, цифры и грабли — плюс второй кейс, где агенты перед релизом нашли баг с потерей данных.
Это перевод-адаптация двух первоисточников: треда Ask HN: How would you harden AI changes to a 1M-line legacy SaaS before review? (автор thegreatkahuna, 25.07.2026) и поста Симона Уиллисона sqlite-utils 4.0rc2, mostly written by Claude Fable (05.07.2026). Если термины «агентный кодинг» или AGENTS.md встречаются впервые — сначала лучше прочитать статьи «Что такое агентный кодинг» и «AGENTS.md».
Зачем переписывать легаси агентами
Автор кейса сразу честно оговаривает свою позицию: он не software-инженер, и именно поэтому взялся за эксперимент — проверить, может ли агентный пайплайн собрать полезный прототип поверх существующей кодовой базы. Цифры, с которыми он работал:
- 1М+ строк кода, 15 лет, основной стек C# и React;
- хостинг — Azure, SaaS-продукт для клиентов;
- ни одного разработчика на полную занятость — только редкая помощь по конкретным техническим вопросам;
- прототип должен быть готов к тестированию клиентами в сентябре;
- в августе инженер должен оценить, насколько AI-код можно довести до продакшена — «ближе к copy-paste, чем к переписыванию с нуля».
Ключевое решение, на котором стоит весь кейс, — изоляция:
The prototype is being developed in a separate branch, deployed to a separate internal environment, and connected to its own database and schema.
«Прототип разрабатывается в отдельной ветке, разворачивается в отдельном внутреннем окружении и подключён к собственной базе данных и схеме.» (HN 49045271)
Так агенты работают с реальным кодом, но ни одна ошибка не ломает продуктивную среду. Это же позволяет гонять пайплайн почти без присмотра — самая частая ошибка новичков в обратную сторону: запускать агента на рабочей ветке.
Устройство пайплайна: роли агентов
Пайплайн автора — классическая схема «фабрики» из трёх агентов, где каждый делает только свою работу и передаёт результат следующему.
Планирование (до кода):
1. Интервью с клиентами в июне → MVP-спецификация.
2. PRD (product requirements document) — требования на естественном языке.
3. LLM превращает PRD в архитектурный документ, который рецензирует архитектор.
4. Продуктовые дизайны — скриншоты экранов + markdown-файлы с деталями взаимодействия и edge cases (сгенерированы с Claude Design).
5. Отдельный агент разбивает работу на эпики, используя PRD и архитектурный документ как ограничители (guardrails).
Эпики — самый мелкий артефакт планирования, который автор и архитектор ревьюили вручную. Всё ниже этого уровня делают агенты.
Разработка — три роли:
| Роль | Что делает | Результат |
|---|---|---|
| Planner | превращает эпики в story-файлы .md и задачи в Jira | декомпозиция задачи |
| Coding | реализует стори вместе с тестами, открывает PR | пул-реквест |
| Reviewer | ревьюит PR, запрашивает изменения, мержит в ветку прототипа | принятый код |
Coding-агент сам опрашивает PR на предмет ревью-комментариев и может эскалировать вопросы обратно планировщику. У всех агентов есть список «stop and ask» — решения, которые им принимать автономно запрещено (например, изменение схемы БД). Такие эскалации решал автор, изредка — инженер, а каждый день вручную прогонял накопленные изменения end-to-end.
Самая интересная деталь — второй ревьюер из другой модели. Основную реализацию и первичное ревью делали агенты на Claude, а для рискованных PR автор подключал Codex:
Most implementation and initial review were done with Claude-based agents. For riskier PRs, I also used Codex as a reviewer. The second-model review found substantially more relevant issues in the Claude-generated code, but token quotas limited the use.
«Основную реализацию и первичное ревью делали агенты на Claude. Для более рискованных PR я использовал Codex как ревьюера. Ревью второй моделью находило заметно больше релевантных проблем в коде, сгенерированном Claude, но токен-квоты ограничивали это применение.» (HN 49045271)
Плюс отдельные прогоны refactoring и harden — агентные сессии, где код специально переписывали и укрепляли перед сдачей инженеру. Это отдельный этап, а не часть основной разработки.
Цифры и сроки
Результаты кейса автор свёл в четыре числа:
- 2 недели — планирование, настройка окружения и самого агентного флоу;
- 2 недели — агенты собрали весь MVP;
- 13 000 строк функционального кода;
- ещё 13 000 строк тестов.
Итого четыре недели от идеи до прототипа, готового к клиентскому тестированию. Ни один разработчик не писал код — автор тестировал, ревьюил артефакты планирования и решал эскалации.
Важная оговорка, которую автор делает сам: MVP — это не продакшен. Задача была «максимально приблизить AI-код к production-grade до августа», а не «заменить инженера». Комментаторы в треде считают такую постановку правильной, но с оговорками (см. раздел «Когда такой подход оправдан»).
Ревью перед релизом: агенты вместо ручной проверки
Второй кейс — про то, что делать перед релизом, когда код уже написан. Саймон Уиллисон, автор sqlite-utils, решил довести релиз 4.0rc2 до стабильного состояния силами агента Claude Fable, потому что подписка Max давала ему доступ к модели ещё несколько дней. Задача была сформулирована одним промптом:
Final review before shipping a stable 4.0 release — very important to spot any last minute things that would be a breaking change if we fix them later
«Финальное ревью перед выпуском стабильного релиза 4.0 — очень важно найти любые мелочи в последний момент, которые станут ломающими изменениями, если мы исправим их позже.» (Simon Willison, 05.07.2026)
Агент подготовил отчёт, в котором нашёл 5 «блокеров релиза» — проблем, которые автор сам не встретил. Худшая из них — баг с потерей данных:
- delete_where() never commits and poisons the connection (data loss)
Table.delete_where() runs its DELETE via a bare self.db.execute() with no atomic() wrapper… The connection is left in_transaction=True, so every subsequent atomic() call takes the savepoint branch and never commits either.«1. delete_where() никогда не коммитит и отравляет соединение (потеря данных). Table.delete_where() выполняет DELETE через голый self.db.execute() без обёртки atomic()… Соединение остаётся в состоянии in_transaction=True, поэтому каждый последующий вызов atomic() идёт в ветку savepoint и тоже никогда не коммитится.» (тот же пост)
Уиллисон воспроизвёл баг end-to-end: после закрытия и повторного открытия базы удалённые строки, новая вставка и даже отдельная таблица исчезали. Если бы релиз вышел таким — данные молча терялись бы у пользователей.
Дальше — самое ценное. Уиллисон прогнал работу в обратную сторону: финальное ревью сделал агент другой модели, Codex Desktop с GPT-5.5. Его скепсис был таким же, как у многих:
I used to think that the idea of having one model review the work of another was somewhat absurd—it felt weirdly superstitious. The problem is it really does work—I’ve started habitually having Anthropic’s best model review OpenAI’s work and vice versa, because I’ve had that turn up interesting results often enough to be valuable.
«Раньше я считал, что идея ревью работы одной модели другой — абсурд, что-то в духе суеверий. Проблема в том, что это реально работает: я уже привычно заставляю лучшую модель Anthropic ревьюить работу OpenAI и наоборот — потому что такие прогоны достаточно часто давали интересные результаты.» (тот же пост)
Промпт был коротким:
Review changes since the last RC. Also confirm that the changelog is up-to-date.
«Просмотри изменения с последнего RC. Также подтверди, что changelog актуален.»
GPT-5.5 нашёл два бага уровня P1 в новой логике db.query() — один из них делал запись в базу до проверки SQL и «съедал» изменения. Уиллисон вставил находки в свежую сессию Fable, тот подтвердил проблемы экспериментами и исправил.
Сводка по второму кейсу:
| Показатель | Значение |
|---|---|
| Промптов | 37 |
| Коммитов | 34 |
| Изменений | +1 321 / −190 строк в 30 файлах |
| Оценка стоимости | $149,25 (подписка Claude Max $200/мес) |
| Найденных «блокеров» | 5, включая data-loss баг |
Вывод Уиллисона: агент «написал» релиз, но ценность была не в генерации кода, а в ревью перед релизом — когда агент выступил придирчивым рецензентом, который нашёл то, что автор не заметил.
Грабли: тесты, контекст, стоимость
Оба кейса сходятся в трёх проблемных зонах.
Тесты — главный инструмент, но и главная ловушка. Автор легаси-кейса планировал давать написание тестов отдельному агенту, чтобы кодинг-агент не мог «подогнать» тест под свою реализацию:
The idea behind having a separate agent create the tests is that then the coding agent couldn’t get functionality to work or fix bugs by weakening the test.
«Идея отдельного агента для тестов в том, чтобы кодинг-агент не мог добиться работоспособности функциональности или исправить баги, ослабляя тест.» (HN 49045271)
Комментатор harikshore добавляет обязательное условие: «агент может сгенерировать тест-кейсы, но валидность тестов всё равно должен проверить человек». Боб Мартин, на которого ссылается автор, вообще перестал ревьюить AI-код и сосредоточился на массированном QA — из-за того, что в легаси «скрыто больше причуд, чем можно представить» (комментарий krembo).
Контекст деградирует на длинных задачах. Второй кейс показывает, как это обходят: Уиллисон работал с агентом в течение двух недель пошагово — 37 промптов на небольшие куски, а не один гигантский «сделай всё». Каждый шаг — маленькая задача с проверяемым результатом.
Стоимость и лимиты. Уиллисон оценил сессию в $149,25 «в несубсидированном варианте» — это основная сессия Fable ($141) плюс субагенты-ревьюеры ($2–3 каждый). На подписке это почти бесплатно, по API — ощутимо. Автор легаси-кейса упёрся в токен-квоты именно при использовании Codex как второго ревьюера. Вывод простой: ревью второй моделью — самое дорогое звено пайплайна, включайте его выборочно, на рискованных PR, а не на каждом.
Отдельно Уиллисон отмечает неожиданный плюс долгих сессий:
A weird thing about coding agents is that harder tasks like this one actually provide more opportunity to do other things at the same time, since the agent sometimes needs 10-15 minutes to churn away on a new task.
«Странная вещь в кодинг-агентах: на сложных задачах вроде этой у тебя появляется больше времени на другие дела, потому что агенту иногда нужно 10–15 минут, чтобы переварить новую задачу.» (Simon Willison)
Он даже сходил на парад в честь Дня независимости, изредка проверяя прогресс с телефона.
Когда такой подход оправдан
Комментарии к треду — готовый чек-лист «да/нет».
Оправдан, если:
— у вас есть детальный артефакт планирования — PRD, архитектурный документ, эпики. Комментатор harikshore: «архитектурный документ должен быть источником истины, тогда инженер при ревью знает, что искать и что помечать». Для этого же годятся регрессионные тесты с документированным статусом pass/fail;
— есть изоляция — отдельная ветка, окружение и БД;
— есть человек-валидатор, который ежедневно гоняет end-to-end и решает эскалации. Даже автор кейса признаёт: «агенты могут давать полезные результаты, просто люди должны валидировать их и нести за них ответственность»;
— задача — конвертация с известной спецификацией. Комментатор scaredreally предлагает превратить код в чёрный ящик: «дайте детальный набор спецификаций и критериев успеха — и код перестанет быть активом, а станет бизнесом, который его использует». Двухфазный подход: сначала конвертация, потом доработки.
Не оправдан (или требует скидки), если:
— «production-grade» определяется буквально. Комментатор taleodor: «если вы планируете выводить это в продакшен — всё, что вы делаете вне привлечения квалифицированного специалиста, скорее всего, пустая трата времени»; его совет — мыслить категориями «что может пойти не так», а не «готов ли код к продакшену»;
— нет никакого инженерного ревью впереди. Кейс сработал именно потому, что в августе приходит инженер, а агенты лишь «приближают» код к готовности;
— речь о безопасности. Автор честно отвечает на идею «чёрного ящика»: «безопасность — единственное, где моя компания точно потребует заглянуть под капот».
Российские реалии
Оба инструмента из кейсов — Claude-агенты (Claude Code, Claude Fable) и Codex — для России доступны с оговорками:
- Установка Codex CLI и Claude Code из РФ работает штатно: GitHub, npm и Homebrew не блокированы (гид по Codex CLI на Habr).
- Вход и работа: OpenAI ограничила доступ с российских IP ещё в декабре 2022 года — для входа в ChatGPT/Codex нужен VPN с иностранным IP («ChatGPT: как пользоваться нейросетью в России»). Claude Code аналогично требует зарубежную точку входа.
- Оплата: российские Visa/Mastercard и Mir не принимаются. Рабочие схемы — виртуальные зарубежные карты, карты банков Казахстана/Грузии/Армении или посредники; детали и личный опыт — в статье «Как оплатить подписку ChatGPT из России в 2026 году».
- API-ключи: platform.openai.com для России не работает — ключ создаётся с аккаунтом на зарубежный номер и карту. Если ключ уже есть, Codex CLI работает с ним на уровне API.
- Локальная альтернатива: Codex CLI можно переключить на российский инференс — на Хабре есть разбор подключения к API Яндекса через Responses API («Агентность на практике: Codex CLI и российский AI-ландшафт»).
- Свежее сравнение Codex, Claude Code и Kimi на одной задаче — Habr, 4 августа 2026.
Прямых кейсов «переписал легаси агентами» в рунете пока немного — тема свежая, и этот материал, по сути, один из первых разборов на русском. Механика пайплайна при этом от страны не зависит: изоляция, артефакты планирования, ревью второй моделью и ежедневная ручная валидация работают с любым провайдером, доступным из РФ.
Дальше по серии «Агентный кодинг для программистов»: общая вводная — «Что такое агентный кодинг», установка и настройка агента из кейса — «Codex CLI от OpenAI», артефакты планирования и правила для агентов — «AGENTS.md», генерация документации по коду — «ИИ для документации кода».
