Разработчик за вечер собирает работающий прототип с помощью Claude или Cursor. Код делает ровно то, что нужно - демонстрирует гипотезу, проходит happy path, убеждает заказчика. Но внутри это мешанина из дублирующихся функций, отсутствующих тестов, захардкоженных ключей API и обработки ошибок через print(). Попытка превратить этот прототип в production-ready MVP одной командой «сделай код чистым» проваливается: AI-агент теряет контекст на пятой итерации, начинает исправлять то, что уже работало, и генерирует новые баги вместо устранения старых.
Pre2Prod решает эту проблему структурно. Это CLI-инструмент на базе Codex, который заменяет абстрактную команду «приведи в порядок» на конвейер из 41 специализированного ревью, разбитого на девять стадий. Двухролевая модель - постоянный Reviewer и временные Workers - изолирует контекст каждой задачи и предотвращает накопление ошибок в истории диалога. Результат: воспроизводимый, контролируемый переход от вайбкод-прототипа к поддерживаемому MVP с метриками качества, которые можно проверить.
Почему «сделай production-ready» - провальная стратегия для AI-агентов
Типичный сценарий выглядит так. Разработчик получает от AI-ассистента прототип на 2000 строк - всё в одном файле, SQL-запросы собраны конкатенацией строк, конфигурация размазана по коду. Он открывает новую сессию и пишет: «Подготовь этот код к продакшену». Агент начинает работу. Первые три изменения выглядят разумно: выносит конфигурацию в переменные окружения, добавляет пару try-catch. На пятой итерации он переписывает функцию, которая уже была исправлена на третьей. На седьмой - добавляет библиотеку, конфликтующую с той, что предложил на второй. К десятой итерации кодовая база разрастается на 40%, но цикломатическая сложность не снижается, а количество багов растёт.
Корень проблемы - в архитектуре длинных агентных сессий. Каждое новое сообщение добавляется в контекст, и модель начинает переоптимизироваться под историю диалога, а не под исходную задачу. Это явление называют context bias: агент «запоминает» свои предыдущие решения и стремится их продолжать, даже если они ведут в тупик. Одновременно растёт зашумление истории - ранние наблюдения о коде теряют актуальность после первых правок, но остаются в контексте и влияют на следующие решения. Через 15-20 итераций агент тратит больше токенов на обработку истории, чем на анализ кода.
Pre2Prod разрубает этот узел двухролевой моделью. Постоянный Reviewer хранит высокоуровневое видение проекта - архитектурные границы, приоритеты качества, критические уязвимости. Он не пишет код, а формирует конкретные задачи для временных Workers. Каждый Worker получает узкую задачу и чистый контекст: только тот фрагмент кодовой базы, который нужно исправить, без истории предыдущих исправлений. После выполнения задачи Worker уничтожается вместе со своим контекстом. Reviewer проверяет результат и либо принимает изменения, либо отправляет на доработку новому Worker'у с уточнённой задачей.
Эта модель воспроизводит паттерн, хорошо знакомый по управлению разработкой: архитектор (Reviewer) не пишет код за джуниоров, а ставит им изолированные задачи и проверяет результат. Разница в том, что здесь обе роли выполняют AI-агенты, а процесс идёт без участия человека. Проблема когнитивной ловушки AI-агентов - когда скорость генерации кода обгоняет способность команды его осмыслить - решается на архитектурном уровне: Worker не может создать лавину изменений, потому что его контекст жёстко ограничен одной задачей.
Архитектура Pre2Prod: двухролевая модель и 41 ревью за 9 стадий
Pre2Prod работает как CLI-инструмент, которому передаётся путь к репозиторию с прототипом. Инструмент подключается к Codex API и запускает конвейер из девяти стадий. Каждая стадия содержит от трёх до семи специализированных ревью - всего 41 проверка, покрывающая весь спектр задач по превращению прототипа в поддерживаемый код. Стадии выполняются последовательно: результаты предыдущей стадии фиксируются в репозитории перед началом следующей, что исключает конфликты изменений.
Reviewer и Workers: разделение контекста для борьбы с шумом
Reviewer - это долгоживущий агент, который инициализируется один раз при запуске Pre2Prod и существует до завершения всего конвейера. При старте он получает полный дамп кодовой базы и строит её ментальную карту: граф зависимостей между модулями, список точек входа, критические пути выполнения. Эта карта не хранится в текстовом контексте - Reviewer использует её для формирования задач, но не передаёт Worker'ам. Когда Reviewer обнаруживает проблему (например, функцию с цикломатической сложностью выше 15), он не пытается исправить её сам, а создаёт задачу: «Снизить цикломатическую сложность функции process_order в файле orders/service.py, выделив валидацию и расчёт скидки в отдельные функции».
Worker получает три вещи: формулировку задачи, содержимое конкретного файла (или нескольких связанных файлов) и набор правил для этого типа ревью. Никакой истории предыдущих исправлений, никаких обсуждений архитектуры. Worker выполняет задачу и возвращает diff. Reviewer применяет diff к своей копии кодовой базы и запускает перепроверку - не сломалось ли что-то ещё. Если проверка пройдена, изменения принимаются. Если нет - создаётся новый Worker с уточнённой задачей и контекстом, включающим результат неудачной попытки.
Механизм форка и перепроверки - ключевой элемент надёжности. Каждое изменение Worker'а применяется к отдельной ветке репозитория. Reviewer запускает на этой ветке тот же набор проверок, который проходила исходная кодовая база. Только после успешного прохождения всех проверок изменения вливаются в основную ветку. Это предотвращает ситуацию, когда исправление одной проблемы создаёт две новых - классический сценарий при ручном рефакторинге и главный источник регрессий в длинных агентных сессиях.
9 стадий трансформации: от прототипа к поддерживаемому коду
Конвейер Pre2Prod выстроен так, чтобы каждая следующая стадия опиралась на результаты предыдущей. Нельзя начинать оптимизацию производительности, пока код не отрефакторен - иначе оптимизируешь то, что будет удалено. Нельзя писать тесты на код, который ещё изменится при рефакторинге безопасности.
Стадия 1: Анализ кодовой базы. Четыре ревью строят карту проекта: граф зависимостей, точки входа, критические пути, захардкоженные значения. Reviewer формирует общее представление о том, с чем предстоит работать. Worker'ы на этой стадии не вносят изменений - только собирают информацию.
Стадия 2: Структурный рефакторинг. Шесть ревью разбирают монолитные файлы на модули, выделяют переиспользуемые компоненты, устраняют циклические зависимости. Это самая агрессивная стадия - здесь прототип теряет свою «вайбовую» структуру и приобретает архитектурные границы.
Стадия 3: Чистота кода. Пять ревью наводят порядок внутри модулей: переименование переменных, форматирование, удаление мёртвого кода, снижение цикломатической сложности, вынос магических чисел в константы.
Стадия 4: Обработка ошибок. Четыре ревью заменяют print() на логирование, добавляют кастомные исключения, внедряют retry-логику для внешних вызовов, проверяют граничные условия.
Стадия 5: Безопасность. Семь ревью - самая объёмная стадия. Проверка на инъекции, утечки секретов, небезопасную десериализацию, отсутствие rate limiting, слабую аутентификацию, открытые эндпоинты, CORS-уязвимости. Worker'ы на этой стадии работают с чек-листом OWASP Top 10, адаптированным под язык проекта.
Стадия 6: Тестирование. Пять ревью генерируют тесты: unit-тесты на чистые функции, интеграционные на взаимодействие модулей, smoke-тесты на критические пути. Reviewer проверяет, что тесты действительно тестируют заявленное поведение, а не просто вызывают функции.
Стадия 7: Документирование. Три ревью добавляют docstrings, README с инструкциями по развёртыванию, комментарии к неочевидным решениям. Worker'ы не пересказывают код в комментариях - Reviewer отбраковывает комментарии вида «складываем a и b».
Стадия 8: Конфигурация и развёртывание. Четыре ревью выносят конфигурацию в переменные окружения, создают Dockerfile, docker-compose для зависимостей, скрипты миграций БД. На выходе - проект, который можно развернуть одной командой.
Стадия 9: Финальный аудит. Три ревью проходят по всему проекту и проверяют, что ни одна стадия не оставила артефактов: нет рассинхронизации между кодом и тестами, документация соответствует реальным сигнатурам функций, конфигурация не содержит дефолтных значений из прототипа.
Каждая стадия занимает от 2 до 15 минут в зависимости от размера кодовой базы. Полный прогон для проекта на 5000 строк укладывается в 40-60 минут. Это сопоставимо с временем, которое опытный разработчик потратит на ревью такого кода, но Pre2Prod не устаёт, не пропускает проверки и не идёт на компромиссы из-за дедлайна. Сравнение one-shot и мультиагентных подходов подтверждает: структурированный конвейер даёт более предсказуемый результат, чем попытка решить всё одной моделью за один проход.
Dogfooding Pre2Prod: как инструмент улучшил собственный репозиторий
Команда Pre2Prod применила инструмент к его собственному коду - классический приём dogfooding, когда разработчики используют свой продукт для разработки этого же продукта. Исходный репозиторий Pre2Prod был типичным прототипом: 3400 строк Python, собранных за две недели экспериментов с Codex API. Код работал, но содержал всё то, с чем инструмент должен бороться у пользователей.
Прогон занял 47 минут. За это время Pre2Prod выполнил все 41 ревью, создал 23 форк-ветки, отклонил 4 изменения Worker'ов (они ломали существующую функциональность) и принял 19 pull request'ов. Reviewer пять раз отправлял задачи на доработку новым Worker'ам, когда результаты не проходили перепроверку.
Метрики успеха: что изменилось после прогона Pre2Prod
До прогона кодовая база содержала 17 функций с цикломатической сложностью выше 10, три из них - выше 20. После: ни одной функции выше 10. Дублирование кода снизилось с 12% до 3% (измерено через jscpd). Количество захардкоженных строк (ключи API, URL'ы, магические числа) сократилось с 34 до нуля - все вынесены в переменные окружения с валидацией при старте.
Покрытие тестами выросло с 0% до 78%. Стадия тестирования сгенерировала 43 unit-теста и 8 интеграционных. Reviewer отклонил 5 тестов, которые проверяли тривиальные утверждения (например, что конструктор класса не падает), и отправил их на доработку с требованием проверять бизнес-логику. Безопасность: найдено и устранено 6 уязвимостей - две инъекции в SQL-запросах, один небезопасный eval(), три эндпоинта без проверки прав доступа.
Наибольший эффект дали стадии структурного рефакторинга и безопасности. Структурный рефакторинг разбил три монолитных файла (более 800 строк каждый) на 11 модулей с чёткими границами ответственности. Безопасность нашла проблемы, которые не были бы обнаружены при ручном ревью - разработчики фокусировались на функциональности, а не на векторах атак.
Ограничения, выявленные при dogfooding: инструмент не справился с архитектурным решением, которое требовало знания внешнего API Codex. Worker предложил абстракцию, несовместимую с реальным поведением API - Reviewer не мог проверить это без доступа к живой системе. Проблему решили ручной правкой, но кейс показал границу применимости: Pre2Prod работает с кодом, но не с внешними контрактами, которые требуют интеграционного тестирования на реальном окружении.
Pre2Prod против ручного рефакторинга: когда AI-агенты выигрывают
Ручной рефакторинг прототипа из 5000 строк силами middle-разработчика занимает 12-16 часов. Стоимость при ставке $40/час - $480-640. Pre2Prod выполняет ту же работу за 40-60 минут, потребляя токены Codex на сумму $12-18 (оценка на основе данных dogfooding). Разница на порядок по времени и в 30-40 раз по стоимости. Но это сравнение не вполне честное: разработчик за 16 часов может принять архитектурные решения, которые AI-агент не способен сформулировать.
Pre2Prod выигрывает на рутинных задачах, где качество определяется полнотой покрытия, а не креативностью. Проверить каждый эндпоинт на CORS-заголовки, каждый SQL-запрос на параметризацию, каждую функцию на цикломатическую сложность - это работа, которую человек выполняет с вероятностью пропуска, растущей с каждой следующей проверкой. Инструмент не устаёт и не теряет фокус. Архитектура самописных AI-агентов демонстрирует тот же принцип: правильно спроектированный конвейер из специализированных проверок надёжнее одного универсального агента.
Инструмент наиболее полезен для проектов на Python и JavaScript/TypeScript объёмом от 1000 до 15000 строк. Это диапазон, в котором прототип уже достаточно сложен, чтобы ручной рефакторинг был затратным, но ещё не настолько велик, чтобы контекст Reviewer'а переполнялся. Для микросервисов на Go или Rust эффективность снижается - строгая типизация и компилятор отлавливают часть проблем, которые Pre2Prod ищет ревью. Для легаси-монолитов на 50000+ строк инструмент требует доработки: Reviewer'у не хватает контекстного окна для построения полной карты кодовой базы.
Pre2Prod не заменяет архитектурные решения. Он не скажет: «Вы используете синхронные вызовы там, где нужна очередь сообщений». Но он приведёт в порядок тот код, который уже написан - и сделает это быстрее и дешевле человека. Аналогия: Pre2Prod - это не архитектор, а бригада отделочников, которая заходит после строителей и доводит объект до жилого состояния.
Как начать использовать Pre2Prod: интеграция в ваш CI/CD
Pre2Prod распространяется как pip-пакет. Установка:
pip install pre2prodДля работы требуется API-ключ Codex с доступом к модели codex-reviewer. Ключ передаётся через переменную окружения CODEX_API_KEY или флаг --api-key. Минимальная конфигурация - указать язык проекта и путь к репозиторию:
pre2prod init --lang python --repo ./my-prototypeКоманда init создаёт файл .pre2prod.yaml с настройками: какие стадии включить, пороговые значения для метрик, исключения из проверок. После настройки конфигурации запускается полный конвейер:
pre2prod runPre2Prod поддерживает инкрементальный режим: если конвейер прервался на стадии 6, повторный запуск начнётся с неё, а не с нуля. Результаты каждого ревью сохраняются в директории .pre2prod/artifacts/ - диффы, отчёты Reviewer'а, метрики до и после. Это позволяет аудировать решения инструмента и при необходимости откатывать изменения.
Интеграция в CI/CD строится вокруг команды pre2prod check, которая возвращает ненулевой код выхода, если метрики качества не достигли пороговых значений. Типичный сценарий для GitHub Actions: разработчик создаёт прототип в feature-ветке, Pre2Prod запускается на PR, применяет изменения и добавляет их в тот же PR. Разработчик проверяет дифф и принимает или отклоняет изменения. Это сохраняет контроль над кодовой базой, но снимает с разработчика рутину по наведению порядка.
Поддерживаемые языки на текущий момент: Python 3.10+, JavaScript/TypeScript (ES2022+). Экспериментальная поддержка Go и Rust доступна через флаг --experimental - стадии структурного рефакторинга и тестирования для этих языков работают с ограничениями. Автономные AI-агенты вроде Google Antigravity показывают схожий тренд: инструменты движутся от помощи в написании кода к автономному выполнению задач, и Pre2Prod занимает нишу пост-генерационной обработки - того, что происходит после того, как код написан.
Будущее автоматизации разработки: за пределами вайбкодинга
Pre2Prod - это реализация идеи о том, что AI в разработке должен не заменять разработчика, а забирать те задачи, которые разработчик делает плохо. Никто не любит проверять 41 аспект качества кода перед релизом. Никто не делает это хорошо после восьми часов кодинга. Инструменты вроде Pre2Prod сдвигают границу: разработчик принимает архитектурные решения и пишет прототип, а конвейер AI-агентов доводит результат до стандарта, который команда считает приемлемым.
Двухролевая модель Reviewer-Workers - архитектурный паттерн, применимый шире, чем рефакторинг кода. Та же схема может работать для автоматического аудита безопасности в продакшене, для миграции кодовых баз между версиями фреймворков, для генерации и поддержания в актуальном состоянии документации. Ключевой инсайт - не в количестве ревью, а в разделении контекста: долгоживущий агент с полной картиной и короткоживущие агенты с чистыми задачами.
Развитие Pre2Prod идёт в трёх направлениях. Первое: поддержка новых языков через систему плагинов для Reviewer'а - сообщество сможет добавлять правила ревью для специфичных экосистем. Второе: интеграция с альтернативными моделями (Claude, Gemini) для снижения стоимости и повышения доступности. Третье: переход от реактивного рефакторинга к проактивному - инструмент будет запускаться не разово, а висеть в CI/CD и автоматически поддерживать метрики качества на заданном уровне, предотвращая деградацию кодовой базы.
Вайбкодинг никуда не денется - скорость создания прототипов через AI-ассистенты продолжит расти. Но вместе с ней должна расти и скорость приведения этих прототипов в состояние, пригодное для эксплуатации. Pre2Prod показывает, что эту задачу можно автоматизировать не менее эффективно, чем саму генерацию кода.