Pre2Prod

Inspiration

I keep getting the same kind of job.

Someone builds a promising product with AI in a few days. The demo works. The buttons are clickable. The happy path is happy. Everyone is excited.

Then somebody asks:

“Can we put it into production?”

And suddenly the room becomes very quiet.

Behind the shiny demo there is usually a familiar collection of surprises: duplicated code, missing tests, optimistic error handling, questionable architecture, forgotten debug logs, dependencies nobody remembers adding, and one enormous file that appears to contain the entire company.

My real work often begins where vibe coding ends. I take fast, experimental PoCs and turn them into maintainable MVPs that can survive real users, real failures, and real developers joining the project later.

In highly simplified engineering notation:

💩 → 🍭

The problem is that this transformation is not one task. It is a long sequence of engineering reviews and improvements, and the order matters.

If you add strict rules and hundreds of tests before fixing the architecture, you may simply make the wrong architecture harder to change.

After repeating roughly the same senior-engineering workflow many times, I decided to encode it into a tool.

That tool became Pre2Prod.

What it does

Pre2Prod is a Codex-native CLI that takes an existing repository through a structured production-readiness workflow.

npx pre2prod

It currently contains 41 focused expert reviews across 9 production-readiness stages:

Foundation
→ Architecture
→ Correctness
→ Product
→ Testing
→ Operations
→ Security
→ Cleanup
→ Delivery

The reviews examine questions such as:

• Is the architecture still appropriate for the product?
• Are types, contracts, and invariants strong enough?
• Are critical paths actually tested?
• Are errors observable and recoverable?
• Are secrets, permissions, and dependencies handled safely?
• Is there dead, duplicated, temporary, or overengineered code?
• Can the project be built, checked, packaged, and released reliably?

Pre2Prod uses two agent roles.

A persistent GPT-5.6 Reviewer studies the repository and keeps its understanding throughout the workflow.

For every expert review, it separates findings into:

• material blockers that justify another change cycle;
• optional improvements that can wait.

When blockers are found, Pre2Prod forks a temporary Codex Worker from the exact review context.

The Worker first creates a concrete implementation plan and then executes it in the repository.

Afterwards, the original Reviewer independently examines the changed repository again.

The core loop is intentionally simple:

Review → Plan → Implement → Re-review

The Reviewer does not blindly trust the Worker, because “the agent says the agent did a great job” is not a particularly strong quality gate.

Users can run the complete workflow, select particular readiness stages or individual reviews, exclude irrelevant ones, and provide additional project-specific instructions.

The goal is not to generate as much code as possible.

Sometimes the correct production improvement is adding code. Sometimes it is deleting code. Sometimes it is removing a dependency, simplifying an abstraction, or finally admitting that a “temporary compatibility layer” has been temporary for three years.

How we built it

Pre2Prod is written in TypeScript and uses Codex App Server as its execution runtime.

The implementation uses:

• persistent Codex threads;
• exact-turn thread forks;
• GPT-5.6 for repository review and implementation work;
• structured outputs through JSON Schema;
• streamed command and file-change events;
• configurable YAML review workflows;
• local redacted diagnostic logs;
• automated tests, CI, packaging, and release checks;
• npm distribution as a standard CLI tool.

The orchestration engine is deliberately small.

It does not contain hardcoded logic for every programming language, framework, or deployment platform. Most of the engineering knowledge lives in the ordered review prompts.

This keeps the implementation simple while making the workflow extensible.

The built-in reviews are stored in YAML, so teams can replace them, reorder them, add their own standards, or create completely different improvement workflows without rewriting the engine.

We also designed the CLI to be non-interactive. It can run unattended using command-line parameters, making it suitable for local development, scripts, and future CI integrations.

Challenges we ran into

The hardest challenge was context management.

Starting a completely new agent for every review loses important knowledge about the repository.

Keeping every review and implementation inside one endless conversation creates the opposite problem: the context fills with low-level implementation details, and the Reviewer becomes biased toward decisions it already participated in.

The final design keeps one long-lived Reviewer but creates short-lived Workers from exact review turns.

This preserves high-level project understanding while isolating implementation noise.

Another challenge was deciding when a review should stop.

An AI reviewer can always find one more improvement. If perfection is the exit condition, the workflow never ends and eventually attempts to rewrite Linux.

Pre2Prod therefore separates material blockers from non-blocking suggestions.

A review passes when there is no issue serious enough to justify another automated change cycle—not when the repository has reached theoretical perfection.

We also had to find the right balance between automation and safety.

Reviewer turns are read-only. Workers receive write access only when material blockers are found. Pre2Prod requires a clean Git repository, creates review checkpoints, stores local logs, and avoids destructive Git operations.

Time was another challenge.

For the hackathon, I deliberately chose a CLI instead of building a polished interactive interface. The important part of Pre2Prod is the workflow and context architecture, not another dashboard with a progress bar saying “AI is thinking.”

Accomplishments that we're proud of

The most important accomplishment is that Pre2Prod is not just a concept or a collection of prompts.

It is a working, npm-distributed CLI built on Codex App Server.

It includes:

• 41 expert reviews;
• 9 ordered production-readiness stages;
• one persistent Reviewer;
• exact-turn Worker forks;
• structured blocker results;
• read-only planning before implementation;
• configurable YAML workflows;
• streamed execution output;
• Git checkpoints;
• local redacted diagnostics;
• automated tests and release validation.

I am especially proud that I used Pre2Prod to improve Pre2Prod itself.

The public Git history contains commits produced during its own reviews, including work on testing, observability, reliability, cleanup, and delivery.

This was both dogfooding and a useful philosophical experiment:

Can a tool designed to clean up vibe-coded software survive being pointed at its own repository?

It did not achieve enlightenment, but it did find real work.

The project gained stronger tests, clearer safety boundaries, better diagnostics, cleaner structure, and more reliable release checks.

I am also proud that cleanup is treated as a first-class production-readiness stage.

Production engineering should not only add more code, abstractions, and machinery. It should also remove dead code, duplication, obsolete dependencies, debug artifacts, and speculative complexity.

Sometimes the most production-ready line of code is the one you delete.

What we learned

The biggest lesson was that production readiness is not a single prompt.

“Make this production-ready” sounds convenient, but it hides dozens of different engineering concerns and gives the model no clear order, stopping criteria, or review discipline.

A structured sequence works better because each review has a narrow purpose and clear context.

I also learned that the order of work is critical.

Architecture should stabilize before the project is surrounded by rigid tests and delivery constraints. Correctness should improve before security assumptions are hardened. Cleanup should happen throughout the workflow, not only when the repository becomes painful to open.

Another lesson was that separating review from implementation improves quality.

A Worker naturally becomes attached to its own solution. Returning control to the original Reviewer creates a more independent verification step.

Context should also be preserved selectively.

High-level repository understanding is valuable and should survive across reviews. Detailed implementation history often becomes noise and should remain isolated inside temporary Workers.

Finally, “production-ready” should not mean “perfect.”

A useful tool needs practical stopping criteria. Pre2Prod aims for material improvement and staging readiness while keeping final judgment with a human.

What's next for Pre2Prod

The current version focuses on a strong default workflow and a reliable CLI experience.

The next steps include:

• workflow presets for different project types;
• community-created expert review packs;
• richer before-and-after reports;
• team-specific engineering standards;
• CI and pull request integrations;
• running only reviews affected by a particular change;
• reusable workflows beyond production readiness.

Because the orchestration engine is generic, the same architecture could later support workflows such as:

• security hardening;
• dependency modernization;
• legacy cleanup;
• compliance preparation;
• release readiness;
• repository onboarding.

Pre2Prod does not promise to make software magically bug-free, perfectly secure, or ready for production without human judgment.

Its purpose is more practical:

take the repetitive senior-engineering work that normally begins after the vibe-coded demo, automate as much of it as reasonably possible, and leave the repository in a much better state for staging and final human review.

Built With

• ai-agents
• automation
• ci/cd
• cli
• code-review
• codex-app-server
• commander.js
• developer-tools
• eslint
• git
• github-actions
• gpt-5.6
• json-schema
• node.js
• npm
• open-source
• openai-codex
• prettier
• security
• software-testing
• typescript
• vitest
• yaml
• zod