At Renuo we work on many projects at the same time and, like many other companies, we are facing a code review problem. Every team, and every single person in it, is constantly asked to review code.
AI has clearly accelerated this. If people produce ten times the code they produced last year, there are ten times as many code reviews to do.
I recently shared two articles with the team: What are code reviews even for? by Brian Houck and Maybe We Shouldn’t Be Reviewing All This Code by Rachel Laycock. Both made me stop and ask a simple question: why do we do code reviews at all?
What we already automate
We already started working on this with the “perfect pull request” initiative, where a large part of the work is checked automatically before a human even looks at it (if at all).
I think Renuo is already very advanced on this front. We require 100% line coverage, and on some projects even 100% branch coverage. We have linters, auto-formatters, RuboCop, and plenty of automatic checks. In the past we even had tools that took screenshots of the application during the review, to verify autonomously that no visual differences had been introduced.
All of this is automated.
So the question still stands: why do we do code reviews?
Why we review code
I agree with the articles. The main reason is the exchange of information between the members of a team working on the same project. In a team of two, three or four people, everyone needs to be aligned and aware of what is going on.
Here I think there are two very different situations to consider: seniors and juniors. People with a lot of experience in the architecture of software projects, and people who are still learning the craft.
For a senior, a code review is a moment of confirmation. As a senior myself, I ask for a code review mostly in the difficult moments, or when an important architectural decision is being taken, to get a second opinion from another senior. The second reason is to share my plan with the rest of the team: “This is the architecture I am considering, please have a look at my pull request. This is where we are going!”.
Most likely the plan was already discussed beforehand, because this is something we have always emphasised at Renuo: when an important architectural decision comes up, make a call, sit around a table and align, so that the whole team moves in the same direction. Don’t wait for the Code Review for that: is already too late.
For a junior, the pull request is a moment of exchange with someone more experienced. They get feedback on their work, they verify that it follows the guidelines they were given, and they also pick up things that are less critical but still matter: the coding style of the project, and the small habits and preferences of the senior who leads it. That’s how I grew in my personal carrier: looking at other seniors, listening, learning, and cherry-picking what was good for myself.
Let me give two examples of what I usually check during a code review. Test coverage is fine, but which kind of tests? Are they the right tests? I much prefer slightly slower tests with less stubbing and mocking, so that we cover more parts of the application. From my personal experience, this pays off. On the contrary, for system tests (which start a real browser and are therefore extremely slow) I ask myself at least twice whether this really needs to be a system test, or whether a much faster kind of test would fit. For every system test I require at least two or three interactions between the user and the browser. Otherwise it should be an integration test.
Our projects are medium/small
All of this, together with the two articles, made me reflect on something fundamental about Renuo as a company and as a web agency: most of the projects we have worked on are small or medium sized. The largest projects we had at Renuo never involved more than five or six people at the same time.
We are all managers now
So here is the point I want to make. With agentic development, do we now have a completely different way of working? Or rather, should we?
As a software engineer I now spend most of my time not focused on a single task, but managing three or four agents that work in parallel on different things. This is what allows a single engineer to be more productive, which brings us back to the problem we started from.
And here something does not add up. If I produce ten times the code, then I have become a manager, right? Back in 2023 we were already saying it: one day we will all be managers of fleets of AI developers. It did not take long. Things certainly stalled between 2023 and 2025, but it is 2026 now, and it has happened.
So if I am already managing a team, why should we build another layer on top of it? I manage a team, my colleague on the same project manages another team, and then we turn to each other and say: “Look, my ten developers made these ten pull requests, could you please check them?” And they do the same: “My ten made these other ten, could you check them?”.
When did we ever need this kind of scale, where two team members are the equivalent of twenty people working on a project? We never did. Do we suddenly need it now? I don’t think so.
Especially since I expect that each Engineer already reviewed the code produced by his ten Agents. This is particularly hilarious to me, because I noticed an incredibly bad behavior, and I caught myself doing the same of course: an engineer completes a feature with an Agent, opens a Pull Request and does not even take a look at it! Why should they if our process requires them to anyway give it to yet another person to review? The exponential increase of time to get a feature done the more people you involve does not pay off at all.
One senior, one project
This is why I think one of the big revolutions we can bring into the company is this: one senior software engineer per project.
This senior engineer can still ask other seniors in the company for a review in the difficult moments. But that is not really a code review. It is more of a “let’s talk about my idea for a moment. I would like to take it in this direction, and I think we should do it this way. What do you think?” Half an hour, maybe an hour, spent together at a table thinking it through. And oh yes, I absolutely expect people to have this conversation with a frontier agent first.
The actual work is delegated to agents, and the senior engineer has already reviewed it. That’s it.
The need of “exchange” is gone, if there’s no team anymore. Now, this has of course consequences. If the Senior Engineer is gone, who takes care of it?
Where juniors fit
Next to this senior we can then place a junior. Why? To help them grow, learn the craft and become seniors themselves, as we have always done.
The junior works alongside the senior. There are moments of exchange, the usual meetings we have always had, code reviews, and so on. The junior does the same job the senior does, managing virtual employees, but on smaller parts of the project. Maybe with a tool that, as one of the articles suggests, measures the risk of a change and how much of the system it touches. Fundamentally, the senior coaches the junior.
Conclusion
The big revolution I think we should bring is projects carried forward by a single person, because that is what allows a person to go as fast as they possibly can. And going as fast as possible, does not mean anymore to make a compromise with quality! That’s the big difference and the big revolution that Agentic Engineering is bringing to the table. You can have both!
I see it in my personal projects, where I move at the speed of light. It has always been like that: in the small side projects you do at home there are no constraints, and you have always been much faster. But now this advantage has grown beyond all proportion, and you don’t have to compromise quality for that.
If everything I produce, or rather everything my ten Agents produce, has to pass through the bottleneck of a second person, it will never work. It does not work. And not only does it not work: it is not necessary. I have already verified that work.
One person projects with the one person framework. Today it is absolutely possible.