↓Skip to main content
  1. Posts/

PREPAIR Gate: How I Assembled My Own Workflow for Developing with AI Agents

·10 mins
A flaw found on a paper plan before a gate leading to a finished structure
Table of Contents

Planning mode is now a standard feature of coding agents. An agent does not have to start changing files as soon as it receives a task: it can first inspect the project and propose an approach. While working with agents, however, I gradually realized that a plan alone does not solve one important problem.

The same agent often explores the project, creates a plan, implicitly judges that plan to be sound, and implements it after approval. There may be a pause between design and code changes, but there is no genuinely separate review.

I therefore started separating these responsibilities. First, refine the problem and prepare the assignment. Then have the coding agent explore the real project and create a plan. Put that plan into a separate AI context whose job is to find faults rather than defend the proposal. Return the findings to the plan’s author and let a human approve only the revised version for implementation.

Once this process had settled into a repeatable form, I gave it a name: PREPAIR Gate.

My own name, not a new universal methodology #

PREPAIR Gate is not an established industry standard or a generally recognized methodology. It is my working name for a particular arrangement of several existing principles: plan-first development, codebase research before design, the critic-agent pattern, evaluator–optimizer loops, human-in-the-loop control, and approval gates.

The building blocks themselves are not new. What is mine is their specific combination into a workflow that separates understanding the problem, designing the technical solution, criticizing that design, and granting permission to change the code.

The name PREPAIR maps to the individual phases:

  • P — Problem refinement,
  • R — Requirements / Prompt,
  • E — Exploration,
  • P — Plan,
  • A — AI Review,
  • I — Iterate,
  • R — Ready.

They are followed by the Gate: explicit human approval. Ready therefore means ready for implementation, not ready for release.

flowchart TD A["Problem refinement"] --> B["Requirements and prompt"] B --> C["Project exploration"] C --> D["Implementation plan"] D --> E["Independent AI review"] E -->|"material findings"| F["Revise the plan"] F --> E E -->|"no material issues"| G["Ready for implementation"] G --> H{"Human Gate"} H -->|"approved"| I["Implementation"] H -->|"return"| F I --> J["Tests, code review, and release"]

Start with the problem, not the prompt #

The first phase does not belong in the repository yet. Its purpose is to determine what actually needs to change.

Brainstorming separates the objective from the first proposed solution. It clarifies scope, behavior that must remain intact, possible edge cases, and questions that require a human decision. A request to “disable a field in the form” may merely be a premature technical description of the real rule: “once an invoice has been issued, the customer on the order must no longer be changeable.”

This refinement becomes the assignment for the coding agent. A good prompt explains the objective, the reason for the change, the constraints, and the expected output. It also states clearly that the agent must not implement anything yet: it must explore the project and produce a plan.

The prompt should not prescribe specific files or architecture without good reason. That would mean making decisions based on an imagined version of the project. The technical design should emerge only after confronting the repository as it actually exists.

The plan must come from the codebase #

During Exploration, the coding agent determines where the functionality really lives and how it fits into the existing system. It looks for established patterns, similar solutions, models, services, controllers, components, database relationships, and potential side effects.

That is the difference between a generally sensible design and one suited to a particular project.

The related Research–Plan–Implement approach places the same emphasis on a distinct research phase before planning. In its discussion of advanced context engineering for coding agents, HumanLayer describes an experiment in which a plan created without the research results led toward a different intervention than one grounded in the codebase’s actual behavior. PREPAIR Gate adopts this principle, but it does not stop when the plan has been written.

Exploration produces a concrete implementation plan: what will change, where, why the approach was selected, the order of the steps, and what must be verified. A plan is more than a checklist of files. It should capture technical decisions, risks, preserved behavior, and test scenarios.

The plan’s author should not be its only critic #

The key difference from ordinary planning mode is AI Review. The completed plan goes to a second AI role in a separate context. Its task is not to politely confirm the plan, but to compare it with the original problem and look for reasons it might fail.

The reviewer might ask:

  • Did the plan’s author understand the requirement correctly?
  • Did it miss another path through which the same data can be changed?
  • Does it enforce a new rule only in the UI instead of the business layer?
  • Is there a simpler or already established solution in the project?
  • Does the plan expand the scope without justification?
  • Which edge cases and regressions are missing?

This is not merely self-review within the same chain of thought. The reviewer receives a different role, a separate assignment, and a clean context focused on criticism. It does not have to be a different model or vendor. This “independence” is not mathematical: another model can repeat the same mistake. It is still more useful than allowing the plan’s author to become its approver without interruption.

The mechanism resembles the evaluator–optimizer workflow, which Anthropic describes as a loop where one model produces an output and another evaluates it and provides feedback. The important part is not the number of agents, but their different responsibilities and the opportunity to revise the design in response to criticism.

Review creates another version, not a verdict #

The findings go back to the coding agent, which prepares another version of the plan. If the review reveals a fundamental misunderstanding, more exploration or a human decision may be necessary. If it finds only missing tests or edge cases, the plan can simply be expanded.

The loop may be as simple as:

Plan v1 → Review → Plan v2 → Review → Ready

The number of iterations is neither the goal nor a quality metric. One round may be enough for a clear problem. A complicated change may need two or three. Iteration ends when another review no longer adds material value, not when a predetermined count has been reached.

General guidance for agentic systems also warns that additional roles and model calls introduce overhead. In its guide to choosing agentic design patterns, Google Cloud recommends considering latency, cost, and the need for human judgment. PREPAIR Gate should therefore not be applied mechanically to every small change.

Gate: the final decision remains human #

When the review finds no material issues, the plan is Ready. Implementation still does not begin automatically.

A human checks whether the plan addresses the right problem, respects the scope, and matches the required business decisions. The human can approve it, reject it, or return it for revision. Only approval opens the Gate and allows the coding agent to modify the project.

This is a concrete form of the human-in-the-loop principle. Contemporary agent tools provide similar technical mechanisms: for example, the OpenAI Agents SDK can pause execution before selected tool calls and resume only after a person approves or rejects them. In PREPAIR Gate, however, the checkpoint does not protect only one sensitive tool call. It separates the entire planning phase from intervention in the codebase.

Example: the customer on an invoiced order #

Consider this requirement:

Once an invoice has been issued, a user must no longer be able to change the customer on the order.

At a superficial glance, a coding agent may find the edit form, disable the field, and add controller validation. The plan looks reasonable until testing reveals that the customer can also be changed through an API, an import, or another administration screen.

Exploration may reveal that all these entry points ultimately use the same business service. The correct plan then places the rule in one central location and adjusts each UI only to give the user clear feedback.

The review AI may also identify a question the plan’s author missed: what should happen after the invoice is cancelled, or when a credit note is issued? That is no longer a technical detail but a business decision for a human.

The division of responsibilities is visible in this example:

  • exploration found the correct intervention point,
  • review found the missing case,
  • the human decided the rule,
  • the coding agent then received a stable plan to implement.

A mistake is cheaper to fix in the plan #

If an incorrect assumption is discovered in the plan, the remedy may be no more than rewriting a few points, adding a condition, or choosing a different application layer. There is no diff yet.

After implementation, the same mistake may have spread across the database, backend, API, frontend, tests, migrations, and documentation. The fix is no longer a change to one idea but coordinated rework across several finished components. It may also be harder to admit that the direction was wrong after substantial work has already been invested in it.

PREPAIR Gate therefore deliberately pays a modest price up front: more thought, more AI interactions, and some latency. It makes economic sense wherever that overhead is lower than the likely cost of implementing the wrong solution.

When to use the workflow—and when not to #

For a typo, an isolated copy change, or a trivial bug fix, the full process might cost more than the fix itself. Ordinary planning mode, a quick review, or direct implementation followed by a test may be sufficient.

PREPAIR Gate is most useful for changes that:

  • span multiple files or application layers,
  • alter business logic,
  • involve several entry points and edge cases,
  • affect architecture or a public API,
  • take place in an older or complicated codebase,
  • could cause expensive rework if designed incorrectly.

Even on a suitable task, AI review does not guarantee correctness. Models may share the same blind spots, the reviewer may have incomplete context, and the human may approve a flawed plan. The workflow reduces particular risks; it does not eliminate the need for verification.

Gate is not a release gate #

PREPAIR Gate addresses only the part of the lifecycle before implementation. Once the gate opens, the coding agent changes the code, but the work is not finished. Automated tests, manual verification, code review, another AI review of the implementation, fixes, refactoring, a pull request, deployment, and finally a release may still follow.

The correct shorthand is therefore not:

plan → approval → done

but:

plan → approval → implementation → validation → release

Separating roles matters more than adding more AI #

I did not assemble PREPAIR Gate to add as many agents or steps as possible. It grew out of a need to separate powers that easily blur together in one agentic process: understanding the problem, proposing a solution, judging that proposal, and executing it.

The name is new; most of the principles beneath it are not. What matters is their order and their separate roles. The coding agent knows the codebase and creates the technical plan. The review AI tries to challenge it. The human owns the objective, the scope, and the final decision.

The intended result is neither a perfect plan nor error-free implementation. The goal is more modest and practical: move as many mistakes as possible into the phase where they still exist only as sentences that are cheap to revise.

Sources and Further Reading #