We Need to Talk About Pull Requests

Project management is just removing one bottleneck after another. You get a group of people together, set some goals, and then watch for whatever makes them spin wheels or blocks their progress. For a long time writing code and tests was a major bottleneck, and I don’t know if you’ve heard, but the situation has changed somewhat. So what is the next boulder that slows down the stream? The graph above gives us a hint.

It shows the number of pull requests our team produced on just one major repository. Each of these changes has to go through stages before it’s released:

• CI runs unit/e2e tests and lints the code
• Sonarqube checks for code complexity or style errors
• Claude runs a PR review
• A teammate approves the PR
• The PR is merged and we run a big suite of integration tests

All of these steps are automated except #4: a human still needs to review the PR and stamp approval or request changes. Not surprising then that this step takes the most time and team effort, given the number of PRs we are dealing with these days. Recently the flood of changes got to the point that we really needed to sit down and have a talk about them. How do we ensure that we control the pace of change, keep the quality high, track architecture drift, and still have a reasonably high pace of delivery required by todays business?

Why not just approve and move on

Remember the good old days? You get a +100 lines PR, you get a fresh cup of coffee and prepare to argue about variable names or performance implications. Occasionally you get a +7248 lines refactoring monster, and that’s just LGTM right off the bat. Who would have thought that a few years later constant 5k line changes will DOS your team for the good part of the day?

And the worst thing is that you can’t even fallback on your trust in your teammate’s ability to code, because of course they haven’t written all that code, they had no time. That’s why you get 5k lines, and not 500.

“I didn’t have time to write a short letter, so I wrote a long one instead.”

— Mark Twain

But you’re being paid to deliver high quality code, and your professional self-respect doesn’t allow you to just rubber stamp each PR without reading. On the other hand, no sane human will be able to read all that code in reasonable time. What do you do?

I can’t promise I have the answers, but I can share my own observations and thoughts.

Why not just give it to AI to review

The first obvious thing that comes to mind these days is - just kick it back to AI. Let the clanker check the PRs another clanker wrote. Why should a human be involved? Well, that kind of solves one problem: local code quality. The “kind of” does a lot of work here though.

Todays coding agents are great at spitting out pages of code faster than a printer possessed by a demon. They are not equally great at pruning the code or reflecting on the complexity of it. That’s the thing that leads to enormous PRs, but it also leads to AI focusing on the wrong thing when reviewing them. Maybe wrong is not quite fair, they are still good at pointing out where your code deviates from the spec (if they have a spec to look at). But no clanker is going to suggest that your PR doesn’t have to change 50+ files, it could have changed 2 if you just take a step back and think again about your goals or try to find a more elegant solution. The robot treats the scope of the PR as a given.

So AI review is a good step in the pipeline, but far from the only thing necessary to approve a change. And what about other problems: updating the team on the change and keeping architecture from sprawling into insanity?

Why not just read the code

I sort of glossed over this, but really, we are responsible for the code we ship, so we should know and approve every line, right? Bite the bullet and just do it.

Part of the problem is (see the previous section) that the agents cannot make small changes. They love nothing else in the world more than touching 30+ files, adding layers upon layers of defensive code, and don’t get me started on the comments. But it’s just a technical side of the issue, and as engineers we are used to solving technical challenges.

Lines added and deleted per week, shown as an eight-week rolling average. Deletions appear below zero.

The scarier part of this, and the one that no engineer has solved yet, is the market and its forces. Business can smell opportunity for optimization from 10 miles away, like a shark smells blood in the water. If there is a rumor that the competition delivers faster than you do, you’re going to have to match their speed. If it means that you cannot read every line of code anymore, that’s the price the business is willing to pay.

Why not just rely on tests and CI

We have relied on automated tests for decades now, and gotten pretty good at writing them: unit tests, end to end tests, browser automation UI tests, even the exotic but beloved property tests. Why not just cover our code in such a multitude of checks that no bug can slip through?

I think you see the problem already: tests are code too. All the same problems we are discussing apply to them too.

It is very likely (and I hope that it’s true) that in the future we will be able to rely on verification to test our code to the point that it’s mathematically proven to be correct. Even so, the verification code is still code, and is subject to the same market forces.

Why not just add a doc describing the change in English

OK if our goal now is to stop the bleeding in our eyes from reading all the AI generated code, can we just require each PR to have a good long description or some mixture of ADRs/design docs committed with the code?

It seems like a good idea until the first time you have to read a 4 page doc littered with “load-bearing”, “but here is the part most people miss” and other Claudish nonsense we all know and love now. Why is it always “most people” being wrong? Every second sentence reads like a headline from a marketing homepage, and you never knew some words could even be used in the context of software design. Seriously, “seam”? “Soft gate”? WTF

Yes, the problem with requiring docs is that by default most people (now Claude got me doing it) will just - again - kick the can to the clanker. It will happily repeat all the nonsense changes it did in the code, just in another form optimised for marketing copy.

The most advanced among us are already asking the agent to use “standard technical English” or using language humanization skills. Imagine explaining this one to anybody in 2005. It helps somewhat with readability but doesn’t help much with the content. If the agent wrote stupid code because it lacked context, it will also write stupid prose explaining that code. Worse, it will be very persuasive when doing so.

Why not talk between us humans

If you’re getting tired of reading AI generated code or AI generated text, or talking to your agent all day about a change you’re planning, there is one more thing left to try.

Walk over to your teammate, invite them for a chat and bounce your ideas off of them. Come up with the new design together, share experience and knowledge, let them know all about your change before you even start implementing it.

Invite your team out for lunch, sit down and (after some smalltalk) ask them - how can we humans still operate well in the new reality with these new constraints. Come up with some ideas together.

Or I guess write a long rambling post in the hope that people will read it and reach out with their own approach to solving the problem and reducing the stress that is by now reported in hundreds of YouTube confessions from engineers like yourselves. We’ve solved harder problems as an industry, I think we can overcome this one too.