How to review agent-written code without piling up tech debt

Reviewing agent-written code means checking intent, scope, and design instead of syntax. Let automated checks handle correctness, then confirm that the change solves the stated problem, touches only what it should, and fits the way your codebase is built.

The more you use agents, the more code lands in front of you. If you read every line the way you used to, you become the bottleneck. In this article, I share how I review agent code, what I check after the tests pass, and which patterns create tech debt.

Why is reviewing agent code different?

A human author usually explains why a change exists and keeps it focused. An agent produces plausible code quickly, and plausible is not the same as right. The volume is also higher.

The good news is that you already know most of the skills. When I started reviewing more agent code, it felt familiar. It is exactly how I reviewed the pull requests of colleagues at WeTransfer. The same discipline applies, and so does the same optimization. When I leave the same comment two or three times, I turn it into a lint rule or a formatting config. Tools should catch the repeated things, so my review can focus on logic and architecture.

What should you check after the tests pass?

1. Does it solve the stated problem?
   Compare the diff to the original request, not to what the agent says it did.
2. Is the scope right?
   Look for unrelated edits, renamed files, or “while I was here” refactors.
3. Does it fit the codebase?
   Check that it uses your existing patterns and utilities instead of adding a parallel way of doing the same thing.
4. Are the tests meaningful?
   A test that cannot fail, or that mirrors the implementation line by line, proves nothing.
5. What did it not do?
   Missing error handling, edge cases, and accessibility are common gaps.

Which patterns create tech debt?

• Duplicated helpers.
  The agent writes a new utility because it did not find the existing one.
• Overbuilt solutions.
  More abstraction or code than the task needed. When I ran the same task across four models, some did far more than needed, and the code could be simplified a lot.
• Silent behavior changes.
  A fix in one place that quietly alters another.
• Dead code.
  Left behind after the agent changed direction mid-task.
• Weakened checks.
  Tests deleted or loosened to make a failure go away. Read any change to a test, linter rule, or config closely.

How do you make review easier?

• Review the plan first.
  I would rather spend more time on the plan before the agent executes than review all the code afterwards. In a plan, you can see which component the agent wants to change, and you can reject the wrong one before any code exists.
• Keep changes small.
  Ask for one focused change per session, so each diff is easy to judge.
• Build a validation loop.
  Trivial errors then never reach you. See validation loops.
• Write your conventions down.
  Put them in AGENTS.md, so the agent starts from your patterns.
• Use a second pair of eyes.
  A subagent without the task context reviews without bias. Tools like GitHub Copilot can review pull requests in a similar way. Let your main agent, which knows the context, decide which feedback to apply.

Who is accountable?

You are. The agent writes the code, but you decide what ships. I prefer to see it like this: the agent adds speed, and your checks and review make that speed safe.

Conclusion

Review agent code for intent, scope, and design. Move mechanical checks to tools, review the plan before the code, and keep changes small so each diff is easy to trust.

If you want a repeatable way of working with agents, join the waitlist for the AI Fundamentals course. You can also start with the free token cleanup prompt. Feel free to contact me or tweet me on Twitter if you have any additional tips or feedback.

Thanks!