AI Agents Are Fast. Your Code Review Process Isn't Ready for Them.

Last month, I watched one of my teammates spin up Cursor with an agentic workflow on a moderately complex feature. The agent shipped four PRs in two days. By Wednesday, they were still sitting in review because nobody on the team had bandwidth to actually read them—and worse, we had no confidence they were doing the same thing.

That's when I realized something uncomfortable: we didn't have a process problem. We had a specification problem.

Our tickets were vague. Our acceptance criteria were loose. Our code review checklist was basically "does it look right?" And for the past five years, that worked fine because humans naturally fill in ambiguity as they implement. An agent doesn't fill in ambiguity—it guesses. And a guess buried in 500 lines of diff is a nightmare to untangle.

The Real Bottleneck Has Shifted

Before AI agents, the slowest part of shipping was writing the code itself. Everything we optimized for—async code review, fast CI, automated testing—was designed to move implementation faster.

But agents broke that assumption. Implementation stopped being the constraint. Now it's decision-making and validation.

I think about it this way: when one person writes a feature, their mental model becomes the spec. They know what they were trying to build. When an agent writes it, that mental model doesn't exist anywhere. It's trapped in a chat history, scattered across prompts, or worse—it doesn't exist at all because the agent extrapolated.

Two agents solving related problems will solve them differently if they don't share the exact same specification. And a code reviewer trying to validate 500 lines of generated code against "let admins retry failed exports" is just hoping the agent guessed right.

The Five-Stage Workflow Actually Works

The workflow I encountered in the article isn't revolutionary, but it's pragmatic. It forces specifications to exist in files before implementation starts. That matters.

Stage 1 is the one teams want to skip. You write a proper spec packet: goal, non-goals, acceptance criteria. The non-goals matter most because they're where agents hallucinate. "No schema changes, no new dependencies" sounds obvious until an agent decides a new table makes the implementation cleaner.

Stage 2 is task splitting. One coherent task per agent. Not "build retry feature," but "add retry endpoint with idempotency checks." Three things: description, write scope, acceptance criteria. This is the hard part because you have to think clearly about what you're building.

Stage 3 is where parallelism actually becomes safe. If agent A touches exports/retry.ts and agent B touches console/exports/Button.tsx, they don't conflict. Write scopes prevent quiet decisions like renaming functions or adding columns that nobody asked for.

Stage 4 is my favorite: agents have to produce evidence. Not "all tests pass"—the specific test names and the actual output. An agent that can't produce test: export_retry_idempotent PASS simply hasn't finished. This kills hallucination stone dead.

Stage 5 is review, but now it's fast because you're not validating the entire specification—you're validating that the diff matched what you already agreed on.

Where I'm Skeptical

This workflow assumes your team actually writes good specs, and most teams don't. They write tickets. There's a difference. Writing a real spec takes time, and time is what we're trying to save.

I also wonder about maintenance. If every feature requires a spec packet, tasks.md, evidence.md, and a properly structured review, does this system create more overhead than it saves? On small features, maybe. On complex ones, absolutely.

The other thing: this assumes disciplined agents. The instruction "modify only these files" works until it doesn't, and we're still in an era where agent behavior is unpredictable. That stop-and-report mechanism in stage 3 is doing heavy lifting.

My Actual Next Step

I'm implementing this next sprint. Not perfectly—we'll start with spec packets and proper task splitting, skip the evidence.md for now, and see where it breaks. I'll report back.

What I'm genuinely curious about: have you tried this? Does the overhead of writing detailed specs actually feel lighter than unraveling bad agent diffs?

Source: This post was inspired by "Your AI Agents Ship Code Faster Than You Can Review It. Here's the Workflow That Fixes That" by Dev.to. Read the original article