By Apollo Raines

A lot of people claim "AI can't write fully working code end-to-end." These are generally devs who ask one model for code and then:

1. Copied it
2. Pasted it
3. It failed
4. Declared AI illegal in 47 states
5. Wrote posts titled "Why I'm Going Back to Notepad"

What they usually mean is: a single model, working alone, will eventually build something that looks complete but isn't. It compiles on a good day, fails in edge cases, skips tests, hand-waves production details, or quietly swaps real logic for "demo-ish" scaffolding.

The fix isn't "a better prompt." The fix is the same thing that makes human engineering teams reliable: role separation, accountability, and review pressure.

This article explains a practical, repeatable workflow for getting near-production-grade output from AI by using collaboration as a correctness mechanism.

The Core Idea: "One model writes. Two models doubt."

You run AI like a software team:

• Human = Orchestrator (you run the plan, enforce the rules, decide what ships)
• Model_1 = Implementation (writes/edits code, tests, scripts, configs)
• Model_2 = Primary Code Review (first reviewer: correctness, security, edge cases)
• Model_3 = Secondary Code Review (hostile QA/QC -- assume the code is wrong, assume I'm wrong, assume the prod is spoiled milk)

And you rotate models on each job so no model gets comfortable in one role. Rotation prevents "style lock-in" and forces each model to experience review pain, which improves behavior across the board.

The Collaboration Contract

This workflow depends on a shared workspace:

• /collab/ is where models put large deliverables
• collab.md is the shared ledger

Think of collab.md as the team's PR description + changelog + QA plan, in one place.

This solves the #1 failure mode of multi-model work: lost context. Models don't "remember" reliably. Files do.

Why Single-Model Coding Breaks (and why this fixes it)

A single model has predictable weaknesses:

• Premature completion: it declares "done" once the main path works
• Demo-code temptation: it swaps production logic for toy examples
• Silent omissions: missing error handling, edge cases, config, packaging, migrations
• Integration blindness: changes compile locally but break other modules
• Testing gaps: no tests, weak tests, or tests that don't fail when they should

The collaboration workflow prevents this by force:

• Model_1 is incentivized to move fast
• Model_2 is incentivized to find flaws
• Model_3 is incentivized to find what Model_2 missed
• Human Orchestrator is incentivized to enforce "no merge without proof"

That combination produces a simple dynamic: lazy code gets called out and must be corrected.

The Exact Workflow

Step 1: Orchestrator creates a "Task Ticket" in collab.md

Before any model writes code, write a short ticket in collab.md:

• Goal (one sentence)
• Files involved
• Constraints (production-grade, no placeholders, no demo stubs)
• Definition of Done (DoD)
• Required tests / verification steps

Example DoD checklist (adapt it per task):

• All functions implemented (no TODOs / placeholders)
• Edge cases handled (invalid input, nulls, empty sets)
• Errors are explicit and actionable
• Unit tests added/updated
• Integration points updated (imports, configs, docs)
• No regressions in existing tests
• collab.md includes exact changes + verification steps

This ticket becomes the standard reviewers enforce.

Step 2: Model_1 implements and commits the "evidence trail"

Model_1 works in /collab/ and updates collab.md with:

• What files were created/modified (exact paths)
• What logic was added (high-level, but specific)
• What assumptions were made
• How to run tests / reproduce behavior
• Known limitations (if any)

This is critical: Model_1 must prove it worked, not just claim it did. If Model_1 can't provide a verification path, the work is not done.

Step 3: Model_2 performs Primary Review (attack mode)

Model_2 reads the changes and tries to break them. Responsibilities:

• Correctness: does it match the ticket?
• Completeness: are parts missing or stubbed?
• Error handling: what happens on failure?
• Security: secrets exposure, injection vectors, unsafe defaults
• Tests: do tests actually validate behavior, or just "exercise" code?
• Production readiness: config-driven, predictable behavior, logging, performance basics

Model_2 writes a review section in collab.md:

• "Blockers" (must fix)
• "Concerns" (should fix)
• "Nice-to-haves" (optional)
• Explicit instructions to Model_1 for fixes

Primary review should be harsh. It's cheaper to be mean in markdown than in production.

Step 4: Model_1 fixes and updates the ledger again

Model_1 addresses blockers and updates: what was fixed, what changed, what tests now cover, and any new risk introduced by the fix.

No arguing in circles. The ledger is the arbiter: either the DoD is satisfied, or it isn't.

Step 5: Model_3 performs Secondary Review

Model_3 focuses on what Primary Review may miss:

• Cross-module integration
• Regressions (a fix that breaks something else)
• Inconsistent style/architecture
• Hidden assumptions
• Performance traps
• "Works on my machine" issues
• Docs drift (README/config/examples no longer match behavior)

Model_3 also validates the verification steps in collab.md: if the steps are vague or incomplete, it flags that as a blocker.

Step 6: Orchestrator merges only when proof exists

The Orchestrator checks: DoD is satisfied, reviewers have no blockers, verification steps are present and reasonable, and the final state is documented in collab.md.

If anything is fuzzy, it loops back to Model_1.

This is where the workflow wins: it replaces "AI confidence" with "team proof."

Rotation Rule: Why swapping roles matters

Rotating models per job is not a gimmick. It prevents systemic failure:

• If the same model always implements, its blind spots become permanent.
• If the same model always reviews, it learns the implementer's patterns and misses novel failures.
• Rotation forces each model to adapt to scrutiny and internalize what "complete" actually means.

Also: reviewers become better implementers after they've had to write brutal reviews.

Practical Rules That Make This Work

• No "demo code" unless explicitly requested. If Model_1 ships "example logic" inside production paths, reviewers flag it as a blocker.
• No "done" without verification steps. "It should work" is not a test plan.
• Everything big goes into /collab/. Chat is for instructions and summaries; /collab/ is for artifacts.
• collab.md is the single source of truth. If it isn't documented there, it isn't real.
• Blockers must be explicit. Reviewers should write: "Change X in file Y; add test Z; update config Q."
• Definition of Done is non-negotiable. When the AI tries to declare victory early, the DoD is the receipt that says "nope."

Why this produces "code perfection" more reliably

Perfection isn't magic. It's process.

This workflow works because it introduces:

• Adversarial checking: reviewers are incentivized to find failures.
• Artifact persistence: shared files prevent context loss.
• Forced accountability: implementation claims are validated by independent reviewers.
• Iteration pressure: lazy shortcuts get exposed, then corrected.
• Integration awareness: the second reviewer specifically hunts regressions.

People saying "AI can't finish 100% of a project" are usually describing a world where: one model writes, nobody reviews, and nobody enforces proof.

With collaboration, you're not trusting a single model's completeness. You're using multiple models to manufacture completeness.

Minimal Template for collab.md

Scaling Up: When the Project Is Huge

If the codebase is massive and you genuinely want every line inspected, upgrade the chain:

• Model_1 = Implementation
• Model_2 = Primary Code Review
• Model_3 = Hostile QA
• Model_4 = Orchestrator (runs the workflow, assigns tasks, enforces the Definition of Done, manages the ledger)

And you become the Overlord (translation: final authority, scope controller, and "nothing merges without proof" enforcer).

At large scale, the hardest part isn't coding -- it's coordination. A dedicated Orchestrator model breaks big work into bite-sized tickets, prevents overlap, keeps collab.md clean, ensures reviews are actually completed, and maintains consistency across modules.

Meanwhile, you stay out of the weeds and focus on the only job that truly can't be delegated: deciding priorities, approving tradeoffs, enforcing standards, and calling "ship it" or "nope, try again."

The Overlord rule: If Model_4 says a ticket isn't ready, it isn't ready. Period. If Model_4 and reviewers disagree, you decide -- but you should demand evidence either way.

Congrats. You now have an AI software org chart. You're basically running a tiny company, except nobody asks for PTO and the coffee budget is exactly $0.

---

Simple. Repeatable. Brutally effective.

If you run this consistently, the "AI can't ship fully working code" comments stop being a law of nature and become what it always was: a lack of engineering process.

Those grouchy old devs can finally relax. The codebase has... supervision now.

~Apollo