Human-in-the-loop development keeps a developer in three roles across a single task: architect while the plan is formed, supervisor while the agent implements, and reviewer before the change is committed. Matching the role to the risk of the task is what separates a rubber stamp from a bottleneck, and what keeps an unreviewed diff out of production.
It is 4pm and the agent has just rewritten your authentication module: fifteen files, 800 lines changed. It compiles, the tests pass, it looks plausible, so you accept all of it. Two weeks later you discover the rewrite silently dropped a CSRF check the original code had. Nobody caught it, because nobody was really reviewing.
The opposite extreme costs just as much. Approve every individual file write and you spend more time supervising the agent than writing the code yourself would have taken. Reading every generated line by hand made sense when a person wrote the diff; it does not survive contact with an agent that writes most of it.
So the answer is neither blind trust nor constant supervision. The teams shipping stable AI-assisted code concentrate at the gates — the accepted plan, the agent’s review findings, the merge, the production authorization — and let the session check its own work in between. Those gates are the ones the AI-native SDLC lays out; this page is about who stands at them and what they actually do there.
Your role shifts during a session, and each shift is a deliberate checkpoint rather than a vibe. Recognizing which one you are in saves time and catches problems while they are still cheap to fix.
1. Architect (planning)
Before any code exists you own the vision and the plan. You hand the agent high-level requirements, have it explore the codebase read-only, and critically evaluate the plan it proposes. Spend the most time here: architectural mistakes are the most expensive to fix, and your experience is what catches a missed requirement while catching it is still free.
2. Supervisor (execution)
The agent implements while you monitor. You break the approved plan into small steps, feed them one at a time, and scan the stream of changes for red flags — files it should not be touching, an approach nobody agreed to. You do not need to understand every line in real time, but you are the hand on the wheel, not a spectator watching an 800-line commit materialize.
3. Reviewer (verification)
The task is finished and you decide whether it ships. You are the gatekeeper of intent and risk, not of every generated line. Routine diffs get layered agent review first (REVIEW.md, Bugbot, claude-code-action, or Codex review); you read the plan, the PR summary, and whatever the agent flagged. Go line by line for regulated or critical code, or when a finding says the change can break behavior, leak data, or breach policy. The agent accelerates creation; merge and production are still yours.
Here is the loop on a real task — adding per-user rate limiting to a Next.js API route — with the prompt that operationalizes each role.
Architect: ask for a reviewable plan, not code.
In read-only mode (Cursor Ask, Claude Code plan mode, or codex --sandbox read-only), make the agent plan and mark its guesses before it touches anything. The “Assumptions” section is the part that earns its keep: it turns invisible guesses into a list you can correct in thirty seconds.
Supervisor: execute one step, then stop.
Approve the plan, switch to execution mode, and constrain the agent to a single step with a hard checkpoint so you review before it continues. This is the cheapest fix for reviewer fatigue: a diff you can actually read beats a diff you skim.
Reviewer: make the agent attack its own diff.
Before you accept anything, turn the agent into a skeptical reviewer of its own work, then do your own read on top. Naming the specific hazards in the prompt matters more than asking for “a review” — the concrete list is what pulls out findings a generic request never surfaces.
Not every moment deserves equal attention. The practical rule is that interruption is cheap early and expensive late, so spend it on signals rather than on every file write.
Intervene immediately when:
Monitor but do not interrupt when:
Review after completion when:
The risk of the task sets the default, and the default is worth writing down for your team:
| Risk level | Task type | Recommended approach |
|---|---|---|
| High | Auth changes, data migrations, security code | Approve every file write. Review diffs line by line. |
| Medium | New features, API endpoints, UI components | Let the agent work, review the complete change before commit. |
| Low | Formatting, renaming, documentation, test additions | Auto-approve or use headless mode. Review the commit message. |
The scope contract below is the cheapest version of all three lists: it makes the agent declare what it is about to touch, so “outside the agreed scope” becomes something you can actually check rather than something you notice afterwards.
The loop is the same everywhere; the mechanical gates that enforce it are not. Use the ones your tool already ships.
Open an agent session with the scope-contract prompt above — it is the fuller version of the “list the files you plan to modify” one-liner, and it also catches new dependencies and destructive edits.
Shift+Tab or claude --permission-mode plan) blocks all file modification, which is what makes the Architect phase safePreToolUse hook blocks edits to protected paths (migrations, .env, CI config), and a PostToolUse hook runs your linter or test suite after each edit so a failing change cannot quietly accumulateWhere the step-level prompt above stops after a plan step, this one stops after every file — useful when the plan step turns out to be bigger than it looked:
Implement the rate limiter from the plan. After each file you modify,stop and tell me what you changed and why. Wait for my approvalbefore moving to the next file.Implement the rate limiter. Show me the full diff when done.Do not push or merge until I review.Reviewing agent output is not reviewing human output. The agent does not get tired, cut corners, or have bad days — but it has systematic blind spots, and those are where your attention belongs.
git diff --stat gives you the shape of the change before you open a single file.Two prompts do different halves of this work. The self-review below inventories the change and flags what the agent is unsure about; the hostile-review prompt in the loop above attacks the same diff looking for what it got wrong. Run the inventory first, the attack second — the inventory tells you where to point the attack.
A third option removes the self-interest entirely: have one session write and a second, context-free session review. The reviewer has no memory of why a shortcut seemed reasonable at the time.
The most productive developers correct early. A nudge after the first file is cheaper than a rewrite after fifteen, and cheaper still than a revert after the merge.
Stop. The approach you're taking with the notification servicewon't work because it doesn't account for our message queue.
Let me redirect: instead of direct database writes, use theexisting event bus in @src/services/eventBus.ts. Read that filefirst, then revise your approach.If Cursor has gone too far down the wrong path, rewind to the last good checkpoint instead of unpicking the changes by hand.
Undo that last change. The notification service should use theevent bus pattern, not direct database writes. Readsrc/services/eventBus.ts for the pattern we use.If the session context is cluttered with failed approaches, /clear and start fresh with a better prompt. A clean context with a good prompt beats a polluted context with corrections every time.
In ChatGPT desktop, add a follow-up prompt to redirect:
Change approach: use the event bus pattern fromsrc/services/eventBus.ts instead of direct database writes.Revert the notification service changes and start over withthe event bus approach.With cloud threads you can abandon a thread entirely and start a new one from a revised prompt; the original thread’s work is discarded cleanly.
The agent is excellent at pattern-matching and generation. What it lacks is exactly what the three roles supply: