Skip to content
AI Developer Toolkit

The Human in the Loop: The Developer's Evolving Role

The human in the loop is the developer who directs, constrains, and reviews AI-generated code rather than typing it directly, moving through three roles across a task: architect during planning, supervisor during execution, and reviewer during verification. Each role maps to a review gate specific to the tool in use — Cursor checkpoints, Claude Code hooks, or Codex pull-request review. Skipping any role lets an unreviewed diff reach production.

It is 4pm and the AI has just generated a 600-line diff that refactors your Next.js checkout flow. It compiles. The tests pass. It looks plausible. The only question that matters is the one no model can answer for you: do you actually understand what it changed enough to put your name on the commit?

That moment is the whole job now. Adopting AI assistants doesn’t make the developer obsolete — it moves your work up a level, from typing code to directing, constraining, and reviewing it. The teams shipping stable AI-assisted code aren’t the ones who type fastest; they’re the ones who never let the AI close the loop on its own.

What the Plan-Execute-Review Loop Gives You

Section titled “What the Plan-Execute-Review Loop Gives You”
  • A concrete plan-execute-review loop that keeps a human decision at each handoff
  • A planning prompt that forces the AI to surface assumptions before it writes code
  • A supervision prompt that constrains execution to one reviewable step
  • A reviewer prompt that turns the AI into a hostile critic of its own diff
  • The per-tool review gates (Cursor checkpoints, Claude Code hooks, Codex PR review) that catch what tired human eyes miss

The Three Hats

Section titled “The Three Hats”

In a human-in-the-loop workflow you wear three hats in sequence. Each one is a deliberate checkpoint, not a vibe.

1. The Architect (Planning)

Before any code is written, you own the vision and the plan. You give the AI the high-level requirements, have it explore the codebase in read-only mode, and critically evaluate its proposed plan. Your experience is what catches architectural flaws and missed requirements while they are still cheap to fix.

2. The Supervisor (Execution)

During implementation you break the approved plan into small steps and feed them to the AI one at a time. You review each diff before the next step starts. You are the hand on the wheel, not a spectator watching a 600-line commit materialize.

3. The Reviewer (Verification)

Finally, 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 what the agent flagged. Go line-by-line only for regulated or critical code, or when a finding says the change can break behavior, leak data, or breach policy. The agent accelerates creation; you still own merge and production.

The Workflow: Plan, Execute, Review

Section titled “The Workflow: Plan, Execute, Review”

Here is the loop applied to a real task — adding rate limiting to a Next.js API route — with the prompt that operationalizes each hat.

  1. Architect: get a reviewable plan, not code. In read-only mode (Cursor Ask, Claude Code plan mode, or codex --sandbox read-only), force the AI to plan and flag its assumptions before touching anything.

  2. Supervisor: execute one step, then stop. Approve the plan, switch to execution mode, and constrain the AI to a single step with a hard checkpoint so you review before it continues.

  3. Reviewer: make the AI attack its own diff. Before you accept anything, turn the AI into a skeptical reviewer of its own work, then do your own read on top.

Per-Tool Review Gates

Section titled “Per-Tool Review Gates”

The plan-execute-review loop is the same everywhere, but each tool gives you different mechanical gates to enforce the Reviewer hat. Use them.

Review the AI’s plan in Ask mode before switching to Agent. During execution, Cursor writes a checkpoint before each set of edits — if a step goes wrong you restore to any prior state instead of untangling a half-applied change. Accept or reject each diff per hunk in the review pane rather than bulk-accepting, so nothing off-plan slips in.

Why Your Expertise Matters More Than Ever

Section titled “Why Your Expertise Matters More Than Ever”

The AI is excellent at pattern-matching and generation, but it lacks the judgment the three hats supply:

  • It doesn’t know your business context. It can’t know that a “harmless” change violates a billing rule or breaks a downstream consumer.
  • It makes confident, subtle mistakes. Code that is 99% right with an off-by-one, a race condition, or a missing auth check is more dangerous than code that is obviously broken.
  • It can’t make strategic trade-offs. Performance vs. readability, ship-now vs. build-to-scale — these need a human who owns the consequences.

Where the Plan-Execute-Review Loop Breaks Down

Section titled “Where the Plan-Execute-Review Loop Breaks Down”
  • Reviewer fatigue on large diffs. A 600-line AI diff defeats line-by-line review. Fix it upstream: constrain execution to small steps (the Supervisor prompt) so each diff is small enough to actually read.
  • Rubber-stamping. Once the AI is right ten times, you stop reading the eleventh. That’s the one that ships the bug. Keep the hostile self-review prompt in the loop and lean on automated gates (hooks, CI) that don’t get tired.
  • Losing the plan. Long sessions drift from the approved plan. Re-paste the numbered plan and ask “which step are we on, and what changed from the plan?” before continuing.
  • Trusting green tests. AI-written tests can be tautological. Spot-check that tests actually fail when the implementation is broken.

Where to Go Next With the Human-in-the-Loop Discipline

Section titled “Where to Go Next With the Human-in-the-Loop Discipline”

Written by

See what's new on the platform.

Privacy Policy Terms of Service Cookie settings