Tools 4 faster Code-Reviews (English)

🇩🇪 Zur deutschen Version dieses Artikels

Since coding agents started writing the code, software development teams have a new main problem: the code review bottleneck. I explicitly mean teams, not individual developers running a one-man show. Other teams at our company report the same. (Teams tend to be too large anyway these days – but that is a different topic.)

The Code Review Bottleneck

The bottleneck has two causes.

Cause 1: Reviews were made for small changes

In teams, it has long been common practice to review each other’s merge requests (MRs). In the past, an MR had at most a few dozen to a hundred lines. You could check that amount in about an hour: you read every line and looked for bugs and other flaws.

Cause 2: Agents create merge requests with thousands of lines

Today, merge requests often have 1,000 or 5,000 lines. The old approach does not work for that. No developer can stay focused for days and check every single line of code for bugs.

Approach: Review by Coding Agents

The best solution I knew so far: the coding agent does the code review itself. For this, you create skills. These skills describe exactly which kinds of bugs the agent must look for, and where.

This actually works quite well. But it means: the developer no longer looks at the code at all. They only start the review agent and accept its result.

Many developers still feel very uncomfortable with this. They do not want to hand over the responsibility to the coding agents one hundred percent.

And as long as the client expects the team to take “responsibility” for “code ownership”, teams should perhaps not (yet) delegate this completely to coding agents – no matter how good their review skills are.

Victor Rentea’s Idea: Condense and Visualize the Changes

Victor Rentea is surely one of the best speakers (and trainers?) in the Java community. He made many very good and entertaining YouTube videos on all kinds of software topics, mainly in the Java space. Meanwhile, he too has shifted his focus away from Java. He now talks mainly – and rightly so – about AI-assisted software development, which is known to be fairly language-agnostic.

In a new video, he presents an idea that I find extremely exciting:

Condense the code changes and visualize them so that you, as a developer, can grasp even large changes in a short time. Then you can decide for yourself whether the changes are okay or not.

For this, he built a whole set of tools. He presents them in this video:

• Video: https://www.youtube.com/live/H-z5mrBOD48

He moves quite fast through the individual ideas. That is why I am watching the video again and again, to understand all the details.

There is also a demo page that goes with the video. It shows the concept live on a sample merge request:

• Demo: https://victorrentea.github.io/human-review/demo/review.html

My First Attempt: the API Diff

To really understand the ideas, I have to work with them hands-on. The concept has seven or eight pillars. Yesterday I picked one of them, added it to my team’s current project on a trial basis, and experimented with it a bit: the API diff.

• Demo of the API diff: https://victorrentea.github.io/human-review/demo/review.html#api

I have to say: I am thrilled!

Outlook: Bleeding Edge

For the other pillars, Victor Rentea himself says that some things are still half-baked. He invites the audience to help develop the tools further. In my view, this is truly bleeding edge – and that is exactly why it is worth starting now.