Automation & Agents

A Week of Front-End Refactoring in One Day: Swap One AI for a Team, and Never Let the Writer Check Its Own Code

An AI saying 'done' doesn't mean it's done. This note gives you a four-role setup that takes about 30 minutes once and is reusable on every project. The core is one rule: the AI that writes never verifies its own output.

10/01/2026 ｜ 3 min read

One Core Idea

Verify, don’t self-check: the AI that writes code (or anything) must not sign off on its own output. An AI that shared the implementer’s context inherits its blind spots; a fresh-context verifier can only go by evidence. It’s an old software-engineering principle, and it works even better on AI because an AI never minds being asked to double-check.

Step by Step (about 30 minutes to set up)

Step 1 | Get a tool that supports sub-agents

This note uses Claude Code (a command-line AI engineer) as the example. Just ask the AI how to install it:

I'm a complete beginner on Windows / Mac (pick one). Walk me through installing Claude Code and logging in, one step at a time, waiting for my reply before the next step.

Step 2 | Set up four roles

• Researcher: before any work, looks up what traps others have hit doing this, and returns only conclusions and sources.
• Implementer: starts only with a clear spec, and must run its own work once before reporting.
• Verifier: a fresh conversation. Give it three things only: the acceptance criteria, the file paths, and one line, “check each item, report pass/fail with evidence”.
• Lead (you plus the main conversation): sets acceptance criteria, reads reports, makes decisions, writes no code.

Step 3 | Write acceptance criteria before starting

Without criteria, you’ll argue afterward about whether it counts as done. Make them checkable:

• ❌ “The page should look fine”
• ✅ “Open http://localhost:8420; all 8 routes return 200; clicking the sidebar switches pages”

Step 4 | Dispatch the researcher (10 minutes up front saves half a day)

I'm building [goal] with [tech stack]. Research it online: 2-3 recommended approaches and 2-3 common traps, with source links. Conclusions only, no long tutorials.

Step 5 | Dispatch the implementer, with the research pasted into the spec

Goal: ... Acceptance criteria: ... (paste Step 3). Watch out for: ... (paste the traps from Step 4). Test it yourself when done and report: which files changed, what you tested, and the result.

Step 6 | Dispatch the verifier (the key step, in a fresh conversation)

You are the verifier and don't need to know how it was built. The project is at [path]. Check each of these acceptance criteria: ... (paste Step 3). Requirements: actually run it and read the real files; "the code looks right" doesn't count; report pass/fail plus one line of evidence per item (command output / file path / number).

Step 7 | If it fails, go back to the implementer with the full failure evidence

If the same criterion fails three times in a row, stop and change approach or look yourself. Endless retries only burn money.

A Real Result

A 1,435-line single-file HTML video workbench became a React dual-mode console (a live monitoring room plus four real-API workbenches plus a guided wizard) in one day and 7 commits. The verifier noticed monitoring events arriving in pairs and traced it to FastAPI 0.137 behavior: router-level startup events were run twice by the lifespan merge. You can’t see that by reading the code.

Traps You Will Hit

1. The AI’s training data is stale, so new framework syntax changes everything. After a major CSS framework release, for example, the AI keeps writing the old syntax. Fix: have the Step 4 researcher look up the current syntax and migration guide, then paste the findings into the spec.
2. The AI reports “done” when it means “written”, not “working”. Put an explicit “run it” action in the acceptance criteria (start the service, hit the API, open the page), and the verifier trusts only what actually ran.
3. When AI output is poor, check the pipeline before blaming the model. “The AI’s images don’t match the script” broke down into three engineering problems: prompts translated one sentence at a time with no full-text context, the system silently falling back to the original text on failure, and browser cache holding stale data from the last run. When you see this, ask the AI:

Audit this output pipeline: where does the input come from, is there any silent fallback in between, and is the front end holding stale cache. Show me the actual data at each stage.

One-Line Summary

In the AI era, quality comes from process, not trust. One rule, “the writer doesn’t verify”, blocks most fake completions.

When You’re Stuck: A Universal Rescue Prompt

I'm a complete beginner working on [step]. My system is [Windows/Mac + version]. I ran [paste command] and got this error: [paste full error text]. Diagnose the cause and walk me through the fix one step at a time, waiting for my reply before the next step.