The smartest agent workflow this week happened before the first diff existed.
Most teams are still treating AI coding agents like very fast juniors: let them write, then inspect the pull request. That worked when the output was a small patch. It breaks when the agent edits across packages, runs tools, touches tests, and explains itself after the fact.
The thesis I would defend in a podcast is simple: plan review will matter more than code review for AI-written code. Not because code review disappears. Because by the time a bad agent plan becomes a clean-looking diff, the expensive mistake has already happened.
Baz Technologies raised a seed extension and framed Baz Planner as code review moved into the planning stage. Sonar is moving policy and remediation closer to autonomous code changes. Cognition’s Devin Security Swarm uses parallel repo analysis, exploit reproduction, and patching as one agentic loop. These are not the same product category, but they rhyme.
They all assume the intervention that matters happens upstream.
In a normal human PR, reviewers can infer intent from a diff. With an AI coding agent, the diff may be syntactically fine and still be strategically wrong. It may patch the symptom, skip the architectural boundary, add a test that blesses the wrong behavior, or choose a migration path that creates on-call pain next Thursday.
That is why the planner is becoming the new linter. A linter catches patterns the compiler accepts but the team rejects. A planner should catch plans the model can execute but the engineering system should refuse.
Code review used to be where the real engineering conversation happened. You read the patch, asked why a helper existed, challenged an abstraction, and forced the author to make tradeoffs visible.
Agent workflows invert that order. The author is now a system that can produce ten plausible patches in the time it takes a reviewer to open the RFC. If the first human judgment arrives after the patch lands in a PR, the team has already paid for exploration, execution, test generation, and review fatigue.
Cognition’s Security Swarm eval is the cleanest signal from the week. The company reports that its swarm found 36 of 50 real GHSA CVEs, including three no other tool caught. The number matters less than the shape of the work. Security Swarm does not merely scan a finished diff. It maps a repo, reproduces exploitability in a sandbox, and then patches. That is QA as workflow design, not QA as a red pen.
This is where many teams will get the first agent safety lesson wrong. They will add more post-write checks. More SAST. More PR comments. More required approvals. Some of that is necessary. But if the agent’s plan is wrong, every later check becomes a tax collector.
The forwardable line is this: the highest-quality agent output is the one your team prevented from being written in the wrong direction.
If plan review wins, the artifact engineers review changes.
Instead of “here is the diff,” the first reviewable object becomes: here is the task interpretation, affected files, risk map, test plan, rollback path, and reasons the agent rejected other approaches. For a refactor, that means the agent must name the boundary it intends to preserve. For an on-call fix, it must separate mitigation from permanent repair. For a security patch, it must say whether it reproduced exploitability or merely matched a pattern.
This is not ceremony for ceremony’s sake. It is how teams keep speed from becoming confusion.
The IDE-grounded version is mundane: before an agent edits your payment service, you should be able to review its plan with the same seriousness you review a database migration. Not because agents are fragile, but because they are fast enough to make wrong plans look productive.
I have changed my mind here. Six months ago, I thought the durable control point would be better diff review. Now I think diff review is becoming the receipt. The real control point is the plan, the tool permissions, and the test contract agreed before execution.
The teams that learn this will not ask, “How do we review more AI-written code?” They will ask, “Which plans are we willing to let an agent execute without waking a human?”
In 1969, Margaret Hamilton’s Apollo software team faced a problem that sounds familiar now: the computer could do only so much, and the wrong task at the wrong time could ruin the mission. During Apollo 11’s lunar landing, the guidance computer threw 1201 and 1202 alarms because it was overloaded. The system survived because the software had priority scheduling. It knew which work to drop and which work to keep.
That was not a prettier error message. It was pre-decision engineering. Hamilton’s team had already decided which kinds of work deserved trust under pressure.
AI coding agents need the same discipline. The win is not catching every bad line after generation. The win is deciding which plans deserve execution before the agent spends your review budget.
Good engineering rejects bad work before it becomes visible work.
Which category of change in your codebase should require human plan review before an AI coding agent can write the first line?
Newsletter • June 22, 2026
YOUR AGENT'S TOOL BELT IS NOW YOUR LARGEST ATTACK SURFACE
Newsletter • June 15, 2026
YOUR EVAL SUITE IS THE SOURCE CODE THAT MATTERS NOW
Newsletter • June 8, 2026
THE RUNTIME LAYER IS WHERE AI CODING GETS DEFENSIBLE
By Neeraj Khandelwal • Zencoder • https://zencoder.ai/newsletter