Blind code review approvals.
A symptom of an emerging problem in any organization adopting coding agents. Behind the blind approver there's a software engineer who is tired, frustrated, or careless.
Blindly approving a PR might be a short-term solution. I understand. We don't want to be somebody else bottleneck. Might be pressure from management. Everyone is doing it anyway.
But this action, in the long run, obscures a problem. It validates a (now) dysfunctional software process.
The amount of code produced has increased a lot. Reviews are becoming a bottleneck. But they shouldn't be.
The bottleneck of reviewing code is not reading it — it's understanding what it does. Can reviews really become a bottleneck if everyone who is supposed to build a PR should already understand it? If they can ship it fast, it should be possible for others to review it fast.
This is not always the case. And we have evidence that people might not understand what they ship. I've seen it happen. You probably have seen it too. One simple question about the code. The author had no answer. Their own code.
We talk a lot, as ICs, about how we should adapt to all the changes in software engineering. But perhaps it's also time to think about how leadership will adapt to this emerging problem.
Why do we review code in the first place? Knowledge sharing? Collective accountability? Collective ownership? Quality? We have a contradiction between the values of code reviews and the push toward automated code generation as it is today.
I'm afraid the problem isn't the coding agents. It is just a tool. It can be used in many different ways.
Some leaders don't care, or, they don't know how to deal with the problem right now.
We have, in many teams and organizations, an incentive problem.
The merits of shipping features are individual. The debt of bad code is shared collectively with the team.
This problem has always existed, but it was counterbalanced by code reviews and a strong engineering culture. This was before coding agents.
I'll reserve judgment here.
I'm pragmatic, not idealistic. This is too big to stop.
I have no intention of fighting this new status quo.
But I believe we should adjust the rules of the game. I believe it is possible to do that.
No bureaucratic reviews. No "just for show" reviews. No hollow "collective ownership.". Maybe no reviews at all.
Let's put names on things. Let's make accountability real and personal.
Parts of codebases, modules or even entire projects must be owned by persons.
Not a team. Not a committee. A person.
You changed it last? Now you own it.
You shipped it? You keep it!
Top comments (0)