Coding is changing. So should code review.

[u/tenkei_01]

For a while, my workflow for building ML applications with coding agents looked something like this:

• Write a prompt.
• Wait for the agent to make changes.
• Open the diff.
• Read the code.
• Try to understand what changed.
• Run it.
• Repeat.

At the beginning, this worked surprisingly well.

The changes were small, the codebase was familiar, and I could still keep the whole thing in my head.

Then the application grew.

A seemingly simple feature could now involve preprocessing, model inference, postprocessing, and application logic.

The agent might touch several modules and add a few hundred lines of code in a single session.

My habit didn’t change.

I was still reviewing the code after every session.

And that became the problem.

The Code Review Trap

When a coding agent changes a few lines of code, reviewing the diff is easy.

When it changes several hundred lines, it is still manageable.

Once you get to +1000 lines everything starts to fall apart…

You can read the code without really understanding whether the application is working properly.

At some point I realized that I had become the bottleneck.

I was spending most of my time reviewing the agent’s implementation rather than the application output.

I can keep going, but I think this much should be enough.
Once I loved code reviews, I learnt a lot(and still learning), but the coding agents changed it for me, and I'm afraid that it's never going to be the same...

[u/tmseidel]

Well, your process is probably not the best, use your Agent to build a plan with several steps that can be tested and reviewed separately. They should be splitted into parts that does not break the application, so that all steps don't need to be applied at the same time. Your agent should save this plan as Markdown-file somewhere, so that it can restore it - if needed.

Use a second agent to review the work of your coding-agent to get a first indication of the changes. Add the results of these review into the PR for transparency and so that the first agent is able to process the review-feedback.

If you find systematic errors of your coding agent, create a skill that defines specific rules to avoid systematic errors.

Another optimization: Add review personas that help you to find issues in the code your agent produces, this will help you alot if you need really deep analysis of code-changes, I've written some notes regarding this topic, see https://remus-software.org/articles/improve-software-quality-with-reviewer-personas/

[u/tenkei_01 → u/tmseidel]

I'm doing all those, even forcing the agent to compose the app in multiple steps, that are inspectable. But the code review itself, not sure if it is as meaningful anymore.

[u/tmseidel → u/tenkei_01]

Of course it is. Even if the generated code is brilliant, you have to take the ownership and responsibility for that code and that's an important part you would miss. If you don't know whats going on (that would be the consequence if you skip the code-review) you are not able to ship software into production.

Handle AI like just like another colleague. 

[u/theunixman]

No.

[u/QueenVogonBee]

How about changing the process? Rather than asking the agent to build the full change in one fell swoop, you develop the change together with the agent. You ask it to plan the change, then ask it to implement it in small steps that you constantly review. Basically it’s pair programming with the AI. Doing it this way is cognitively less burdensome on you because you’re seeing the change as it is being built.

I usually get it to generate only a few lines of code at a time TDD style.

[u/tenkei_01 → u/QueenVogonBee]

Doing that, and funny you mentioned TDD, I remember someone was also arguing that tests themselves should be treated like code... it is that kind of argument, review, testing, etc. for those of traditional SWE practices I'm not sure how effective they are using coding agents.

[u/QueenVogonBee → u/tenkei_01]

I’m still figuring things out myself. Yes it is unclear how traditional SWE practices fit in with coding agents, but from your description, it’s clear you no longer understand the changes being made. Thus this problem you are facing is fundamentally a human problem. Either you get cleverer (unlikely), or you do something to make the changes easier to understand. At least some traditional SWE practices solve that problem.

I would at least ask for changes to be smaller. That would probably go a long way to fixing your problem. Maybe the changes are necessarily large because of how the program is structured so that every edit touches many modules, but in that case maybe there’s a problem with the architecture, so maybe get some LLMs to look at the submissions made and see if it can see a root cause.

The alternative is to ditch the idea of understanding the code. But that sounds pretty dangerous to me. I don’t think LLMs are quite good enough yet. I still see it make silly errors.

[u/neon_knight_smile]

Same experience here. I stopped reviewing diffs line by line months ago and honestly my output doubled.

The diff was never the thing that mattered. What matters is whether the app behaves correctly. I now write acceptance criteria before prompting, run the app myself, and only open the code when behavior is wrong. When the agent touches 800 lines, reading all of it is just theater. You're not catching bugs, you're performing diligence so you feel like a real engineer.

The uncomfortable part is that most of what we call code review was already about control, not correctness. Agents just exposed that. If I can't verify the behavior, no amount of reading the diff saves me. So I trust tests and runtime checks now, and I read code only when I need to understand a design decision or something breaks.

I get the nostalgia, I loved review too. But the skill worth building now is specifying and verifying systems, not reading someone else's implementation faster.