Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP

Последнее время мне регулярно приходится разбирать проекты, созданные примерно по одному сценарию.

За несколько дней с помощью AI собирается работающий PoC. Интерфейс открывается, кнопки нажимаются, основной сценарий проходит. После этого возникает вопрос:

А теперь это можно выкатывать в прод?

И тут обычно выясняется, что за красивым демо скрываются дублирование логики, слабая типизация, отсутствующие тесты, случайная архитектура, забытые debug-логи и один файл на несколько тысяч строк, внутри которого, вероятно, находится вся компания.

В упрощённой инженерной нотации задача выглядит так:

? → ?

Обычно именно на этом этапе начинается моя работа: превратить экспериментальный PoC в поддерживаемый MVP, который можно безопасно передать тестировщикам, другим разработчикам и первым пользователям.

Проблема в том, что команда «сделай production-ready» работает плохо. Production readiness — это не одна задача, а последовательность разных инженерных проверок.

Так появился Pre2Prod — CLI-инструмент, который прогоняет репозиторий через структурированный workflow ревью, планирования, исправления и повторной проверки.

Быстрый старт

Сначала можно посмотреть доступные параметры:

npx pre2prod -h

Проверить окружение и список встроенных ревью:

npx pre2prod doctor
npx pre2prod --list

Запустить полный workflow:

npx pre2prod

Запустить только отдельные стадии:

npx pre2prod -p architecture,correctness

Или одно конкретное ревью:

npx pre2prod \
  -p foundation-immediate-risk-triage \
  --max-iterations 1

Pre2Prod изменяет исходный код, поэтому запускать его стоит только в чистом Git-репозитории и обязательно проверять итоговый diff.

Что делает Pre2Prod

Встроенный workflow включает 41 специализированное ревью, объединённое в девять стадий:

Foundation
→ Architecture
→ Correctness
→ Product
→ Verification
→ Operations
→ Assurance
→ Cleanup
→ Delivery

Проверки охватывают архитектуру, типы, runtime-контракты, тесты, observability, безопасность, зависимости, CI, документацию и готовность релизного артефакта.

Порядок важен. Если сначала обложить проект строгими тестами и delivery-gates, а потом менять архитектуру, можно просто сделать неправильную архитектуру ещё дороже в изменении.

Список ревью хранится в YAML и может быть переопределён под конкретный проект или команду.

Почему не один агент

Самый очевидный вариант — открыть одну длинную сессию агента и попросить его последовательно исправить всё найденное.

У такого подхода две проблемы.

Во-первых, агент, который сам предложил изменение и сам его реализовал, склонен считать результат хорошим.

Во-вторых, длинная история постепенно забивается командами, ошибками, промежуточными решениями и деталями реализации. Высокоуровневое понимание проекта тонет в шуме.

Противоположный подход — создавать нового агента для каждого шага — тоже неидеален: каждый раз приходится заново изучать репозиторий.

В Pre2Prod используются две роли.

Persistent Reviewer

Один Reviewer работает на протяжении всего запуска и сохраняет высокоуровневый контекст проекта.

Результат каждого ревью структурирован:

{
  "blockers": [],
  "non_blockers": []
}

В blockers попадают только проблемы, ради которых оправдан ещё один цикл изменений. Остальные предложения складываются в non_blockers и не запускают Worker.

Это важно: AI-ревьюер способен находить улучшения бесконечно. Если критерием завершения сделать идеальный код, рано или поздно он попытается переписать Linux.

Disposable Worker

Если Reviewer нашёл blocker, Pre2Prod форкает Worker от того самого turn, в котором проблема была обнаружена.

Worker:

1. получает найденные blockers;

2. в read-only режиме составляет план;

3. CLI сохраняет план в PREPROD_PLAN.md;

4. Worker получает write-доступ;

5. выполняет план;

6. больше не используется.

После этого исходный Reviewer заново читает изменённый репозиторий.

Транскрипт Worker не копируется обратно в Reviewer. Reviewer видит результат в файловой системе, а не объяснение Worker о том, почему всё получилось прекрасно.

Получается простой цикл:

Review → Plan → Implement → Re-review

Как это реализовано

Pre2Prod написан на TypeScript и работает через Codex App Server.

Используется небольшой набор методов протокола:

initialize
thread/start
thread/fork
thread/goal/set
thread/goal/clear
turn/start

Reviewer запускается в read-only sandbox и возвращает структурированный результат по JSON Schema.

Worker сначала планирует без права записи, после чего отдельный execution-turn запускается с workspace-write.

Сам orchestration engine намеренно небольшой. Он не содержит отдельных реализаций для React, Rust, Solidity или Kubernetes. Основные знания находятся в review prompts.

Благодаря этому тот же движок можно использовать и для других последовательных workflows: security hardening, modernization, compliance preparation или cleanup старого репозитория.

Git и безопасность

По умолчанию Pre2Prod:

• требует чистый Git working tree;

• создаёт отдельную ветку;

• делает checkpoint commit после каждой стадии;

• не выполняет reset;

• не очищает пользовательские изменения;

• не делает deployment;

• даёт write-доступ только execution-turn Worker.

Есть и более осторожный режим:

npx pre2prod \
  -p foundation-immediate-risk-triage \
  --no-commit

Так можно провести одно ревью, изучить diff и принять решение вручную.

Dogfooding

Первым полноценным подопытным стал сам Pre2Prod.

Это была полезная проверка гипотезы:

Может ли инструмент для очистки вайбкодерских проектов пережить запуск на собственном репозитории?

Просветления он не достиг, но работу нашёл.

В Git-истории появились commits, созданные во время ревью unit tests, integration, contracts, end-to-end, observability и reliability.

Во время dogfooding стало особенно заметно, что production engineering — это не только добавление кода.

Агенты любят создавать новые abstraction layers, adapters, wrappers и конфигурацию. Но иногда лучший production-ready код — тот, который был удалён.

Поэтому cleanup стал отдельной полноценной стадией:

• dead code;

• duplication;

• временные compatibility paths;

• debug-артефакты;

• неиспользуемые зависимости;

• спекулятивные абстракции.

Тестирование workflow

Ключевой интеграционный тест запускает полный цикл через mock App Server:

Reviewer finds blocker
→ Worker is forked
→ plan is generated
→ repository is modified
→ Reviewer re-checks it
→ phase passes

Также есть тесты на аварийное завершение App Server, очистку Worker goal, JSON-RPC transport, CLI, Git, YAML, logging и structured review results.

Перед публикацией выполняется release gate:

pnpm run release:check

Он включает formatting, typecheck, lint, coverage, build, dependency audit, создание npm tarball, чистую установку пакета и smoke test установленного CLI.

Что получилось и чего пока нет

Сейчас Pre2Prod — опубликованный npm CLI с:

• конфигурируемым YAML-workflow;

• persistent Reviewer;

• disposable Workers;

• structured blockers;

• Git checkpoints;

• локальными логами;

• тестами и release validation.

Но это не магическая кнопка «сделать прод».

Инструмент:

• не гарантирует отсутствие багов;

• не гарантирует безопасность;

• не выполняет deployment;

• не отменяет code review;

• не знает бизнес-контекст лучше владельца проекта.

Его задача практичнее: автоматизировать повторяющуюся часть senior engineering работы и привести репозиторий в существенно более пригодное состояние для staging и финальной человеческой проверки.

Попробовать

npx pre2prod -h

Исходники:

https://github.com/vv-bogdanov/pre2prod

Страница проекта на OpenAI Build Week:

https://devpost.com/software/pre2prod

Vibe code the idea. Pre2Prod the product.