A Blueprint for AI Coding Workflows: Phases, Checkpoints, and Independent Reviewers
Solo AI coding loops drift without oversight; this pattern gives teams a concrete structure to stop model self-delusion, keep AI-assisted changes auditable, and force human sign-off at decision points instead of trusting occasional model competence.
Directly asking a language model to 'implement this' or 'fix this bug' often degenerates into a loop: generated code drifts from requirements, then gets patched, then drifts again. The design described here attacks the root causes: missing context constraints, unclear decision boundaries, and the model's own confirmation bias when it reviews its own work.
The workflow defines six phases, each with a specific role: Context Analyst, Planner, Coder, independent Reviewer, Tester, and Delivery Coordinator. A state machine gates progress with three checkpoints: background approval, solution approval, and implementation verification. Two hard rules stand out: review and verification failures pause after three consecutive strikes (rework doesn't reset the counter), and entering delivery requires actual evidence, not 'looks fine'.
The architecture also separates task organization from work responsibilities. A Main Agent maintains core context and drives the state machine; an independent Reviewer uses a separate context to avoid defending the Coder's own conclusions; a SubAgent handles heavy evidence gathering (logs, screenshots) in isolation and returns only structured summaries. The author also argues for pairing the workflow with project-specific 'skills' that encode patterns like popup writing, Figma-to-Compose conversion, and API-to-request mapping, so the AI doesn't improvise lower-level implementations.
The three-strike rule for review and verification is the most consequential guardrail; it stops silent infinite repair loops and forces human intervention, a simple mechanism many agent pipelines lack.
Separating work responsibilities (Coder, Reviewer) from task organization (Main Agent, SubAgent) is a useful conceptual distinction; it clarifies that independence is about context and perspective, not just spawning an extra agent.
The author's note that this article is AI-generated with human oversight mirrors the workflow's own philosophy: the human reviews and gates each phase, which is exactly the checkpoints the design advocates.
I agree with splitting into phases, especially that Coder and Reviewer shouldn't be the same self-review. What easily fails is: if the review side can still see the reasoning behind the implementation and the same conversation, confirmation bias just moves to a new location. Now I give the reviewer only three things: frozen acceptance criteria, the diff, and the failing checks, not the "why I wrote it this way." Also, for human approval gates like background approval, when people get tired they just click approve. What can stop drift is machine-decidable invariants, like compilation, contract tests, or failing immediately if files outside the scope are touched — not calling another model to say "pass."
1. The independent Reviewer Agent gets the proposal, acceptance criteria, and diff; it collects necessary context itself, like requirements and current implementation. It operates independently of the main agent, as a review role, not depending on the main agent's environment context, making the reviewer more accurate. This is written in section 4.2, Phase 3. 2. Currently my design has 3 places where "pass" is needed, but I think all of them require human engineer involvement. The first is background analysis: because with AI writing lots of code, human engineers can no longer remember the original requirements, and might give completely wrong directions, so the background of the change needs to be explained. The second is proposing a solution: the proposal gives how to change, which files will be affected, file risk levels, and the technical approach, to avoid AI mis-modifying or wrong technical approach or wrong files. The third is confirming the code implementation: at this step AI has finished writing the code, but many models have their own flaws, like GPT's over-defensive programming; here the human engineer can step in and modify, or if they don't want to review or change, they can pre-enter a confirmation. All 3 of these came from lessons learned. The later phases are all auto-executed by AI.
This workflow also has some auxiliary things, for example: 1. Background analysis reads the AI-generated requirements document combined with the code implementation; 2. The technical solution and code are combined with project-encapsulated detailed skills, such as page UI, dialogs, network requests, basic page construction, code quality checks, etc. The foundational work must be solid, constraining code quality within a controllable range according to the project architecture.