When AI Code Fails Review, Fix the Loop

Dev Leader Weekly 162

Dev Leader

Oct 26, 2026

TL; DR:

Fix the rules, not just the patch.
Guide good behavior. Gate bad behavior.
Separate unfinished code from blocked verification.
No live stream this week! Sorry about that 😦

The Agent Wrote It. The Reviewer Said No.

What do you do when an agent writes the code, puts it up for review, and a human says, “We can’t integrate this”?

I got a submitted question about exactly that. How do you correct the process? How do you stop the same assumptions from carrying into the next change?

My answer isn’t just to tell the agent to try harder.

I want to understand how it got there. Did it miss a rule? Was the rule ambiguous? Did my checks leave a gap? Or did it spend all its time fighting the process instead of finishing the work?

Those aren’t the same problem. And I’ve been running into both.

You can check out my full thoughts on this in the video below:

And the irony of all of this? I am pretty sure it was a bot that submitted the anonymous question in at Code Commute... But still a good topic!

First, Was This Supposed To Be Mergeable?

Sometimes I give Copilot a high-level architecture task because I want to see how the pieces could fit together.

I’m not necessarily expecting a production-ready result. I want something concrete to read. Show me the structure. Show me where these responsibilities might live. Then I can decide what I agree with.

That’s different from handing over a small feature with clear acceptance criteria.

If I asked for an exploratory prototype, I’m not going to get upset that I can’t immediately press merge. But I still want to learn from the parts that don’t fit. There are many situations that I find myself having an easier time digesting the concept once I see it applied to the codebase, and since code is cheap... why not? It doesn’t mean I have to merge it though -- that was not the goal.

For delivery work, I want a much tighter boundary. My walkthrough of a bounded change with Claude Code is an example of defining the behavior you want while keeping existing contracts intact.

Actionable Tip: Before delegating, say whether you want an exploration or a change ready for review. Don’t leave the agent to guess which finish line matters.

Working Code Can Still Break Your Architecture

A lot of my projects use vertical slices or plugin-based architectures. Those boundaries matter to me.

I’ve had agents produce something that works, but does it by making plugins know about each other or share code in ways I don’t allow.

From the agent’s perspective, it connected the pieces. From mine, it cheated. In one case, I was positive I already had instructions and tests preventing the pattern. So I went back to the session and asked about it! I was confident that this should have been borderline impossible to even happen.

The explanation was interesting: the guidance and tests existed, but this particular variation didn’t fall into what they covered.

The rule in my head was broader than the rule in the repository.

That’s useful information. Fixing only the generated patch would leave the same opening for the next task.

Instead, I wanted a separate, focused PR to close that gap: update the guidance, extend the tests, and update the analyzer where appropriate.

Guide Good Behavior And Gate Bad Behavior

I try to approach this from two directions.

First, give the agent enough guidance to build things the right way.
Second, put checks in place to catch the things it gets wrong anyway.

Only having instructions means I’m depending on the agent to follow them. Only having checks can mean it spends a bunch of time building something before discovering that the approach was never allowed.

Neither side is perfect. I want both. And I try to aggressively get these added into the repository if I am spending any time reviewing and adding feedback.

For my .NET projects, Roslyn analyzers are useful for rules I can express mechanically. Analyzer diagnostics can be configured as errors, giving the agent build feedback rather than waiting for a human to spot the violation. That doesn’t mean an analyzer understands every architectural decision. The rule still has to exist and cover the offending pattern.

This is the same reason I emphasize repository-specific conventions in my Copilot CLI workflow. The agent needs more than a feature description.

Actionable Tip: Take one repeated review comment and ask two questions: “How do we explain the preferred approach?” and “What check would catch this violation?”

Your Teammate’s Agent Needs The Context Too

I’ve also hit this working with a colleague on BrandGhost.

He was using Claude Code. I had been creating guidance for Copilot, but I hadn’t properly synchronized it for his setup. His fault for not using the Microsoft product though, right?!

The resulting PR included patterns I couldn’t accept. But the agent hadn’t received the guidance I expected it to follow, and I didn’t have checks catching those patterns either.

That’s not a fair situation to turn into “Why did you build it wrong?” -- that’s very easy to happen when you aren’t operating under the same guidance.

I had to take responsibility for the missing context. Holding back the PR was still the right call. Blaming my colleague for instructions his agent didn’t have wasn’t.

If your team uses different tools, check what each one actually receives. Don’t assume guidance written for one setup automatically reaches another. A reviewable repository workflow starts with making those expectations and boundaries visible.

The Code Wasn’t The Only Thing Getting Stuck

I had a working prototype built with Claude Code in roughly ten minutes. I gave it to Copilot to integrate into a hosted environment. Copilot tried it and reported that it could use it.

Heck yeah. Time to rock and roll!

About 72 hours elapsed while I kept giving it work on that integration. That wasn’t 72 hours of me sitting there continuously, but it was still a frustrating amount of time for something I’d already seen working. How could we be multiple days into this when I had literally handed over the working code?

When I inspected the remaining work, six items weren’t the features or fixes I’d asked for.

They were about the infrastructure and process being used to prove the work was done.

For example, it needed screenshot evidence for a before-and-after comparison, but it had run into trouble on the CI host. It was spending time investigating that instead of delivering the evidence.

I suspected waiting and retrying the job might have been enough. I hadn’t established the exact infrastructure cause. That’s a different failure from violating a plugin boundary.

Was the implementation incomplete? Or was the implementation ready to inspect while verification was blocked? I needed those separated, not flattened into one list of “things left.”

I’ve talked before about agent review loops expanding beyond the useful work. More activity isn’t automatically more progress.

In this case, the agent was busy working hard, but it was spending time on things that simply did not matter.

Review The Session, Not Just The Diff

My next step was to go through that session with a reflection skill and ask what went wrong.

I didn’t have the answer yet. Maybe my instructions were misleading. Maybe I hadn’t supplied guidance for recovering from those blockers. Maybe the session would reveal something else.

But asking it to “finish by morning” clearly wasn’t enough. We were several mornings in and I was still feeling the pain.

For your own workflow, I’d start by separating:

Implementation gaps: Which requested behaviors are still missing?
Verification gaps: Which claims still need evidence?
Process blockers: What is preventing that evidence from being collected?

Then decide what a useful next attempt looks like and when it should stop and report the blocker. That’s not permission to call unverified work complete. It’s a way to make the actual problem visible.

I’ve found the instructions-and-checks loop repeatable and useful. Refining the agent’s development process is something I’m still figuring out. That’s the harder part of delegating bounded work to an agent: I want it to navigate the work, not just keep moving.

Actionable Tip: On your next rejected agent PR, don’t stop at “fix this code.” Find the missing guidance, missing gate, or unproductive loop that helped produce it.

That’s the improvement I want to carry into the next task.

Dev Leader Weekly

Discussion about this post

Ready for more?