This approach doesn't scale.

Pair programming once in a while can be incredibly valuable. I am glad to meet with anyone and talk over their code in person, brainstorm designs, run through a debugger together investigating it.

But if you asked me to do that for most of an 8 hour day - much less most of the time in general - I would quit the job faster than you could fill out the paperwork. Constantly having someone looking over your shoulder is a world of stress and overstimulation that I (and I suspect many others) will not stand for.

i do find it deeply funny that a polemic against peer review has an AI generated header image with easily identifiable problems (notebook contents upside down, one child is about to cut her hand with scissors, the other is building a geometrically impossible "lego" structure). if only it had been reviewed by someone else before publishing!

> If we want to explore alternative solutions, I’d rather do that before implementing one of them.

Sounds cute. But you won't know what any of them really are until you've built at least one of them. You can write specs and have meetings for years and you'll still miss something fundamental about the approach that will be discovered in the first hour of building.

For a second I thought this was Fowler posting but it's actually the CTO. Look if not reviewing code works I'm sure we'll see startups and new companies pushing it to the max.

I'm at a startup myself and we make judicious decisions about what to review and what doesn't need review. Our core systems go through code review - alignment is always built up early anyways.

At this point, I haven't even read around 30% of the code base in my open source project. I know our works by my manual testing. AI keeps writing tests for itself, even though I don't explicity ask for it, and I am not complaining.

Code review for CRUD apps is largely something you can hand off to a council of sub agents. Code review for a system whose business logic is not obvious within the codebase? Currently none of the prescribed steps in TFA solve for a peer looking at it with fresh eyes.

> significant lines of code per human-landed diff

Claude would be proud.

That said, code reviews have never worked well, and it's a weird argument for wanting to preserve them.

Pairing is great and under-utilized. On one hand it's a hard sell to managers (let's use two people to do one person's job) and from the developer's point of view, it's intense and exhausting.

How about we just hire humans and let them code without AI, then we don't have this issue! Every piece of valuable software to date was written this way.

In before, “you’ll be left behind crowd”, I agree, most of what we call SWE in 2026 will probably just be done by agents, at which point I’m not sure why humans are even reading it. Stop bottlenecking your agent when it’s building the nth slop website.

But if you agree, we will still need human intelligence for some tasks, then in my experience it is best used as a generator, not reviewer and ideally unmolested by LLM Intelligence. The amount of creativity you should delegate is 0.

The counter argument linked in this posting rings true to me. Use an LLM to surface the meat of an MR, and better software can be produced by involving a human with experience and judgement.

I certainly wouldn't want to review anything with Martin Fowler's name attached thanks anyway.

>If we want to explore alternative solutions, I’d rather do that before implementing one of them.

>If we want knowledge transfer, pair. Sitting next to someone, physically or virtually, while they reason through a problem teaches you far more than reading their completed solution afterwards.

>If we want junior engineers to learn how experienced engineers think, let them work with experienced engineers while they’re thinking. Pairing comes to mind again here, but teams could also do design sessions collectively with a whiteboard before they write (or instruct the agent to write) anything.

>If we want collective ownership, organise teams so people actually build and operate software collectively rather than relying on a pull request to tell everyone what somebody else has already built. For this again use pairing, mob programming, or team design sessions around whiteboard.

...

So in short, talk to people about decisions before you code (obvious advice, but plenty of shops don't do it) ... and replace all other functions of code review with pair programming!?!?

I mean, seriously, the answer to "what do we do with so much code to review" in this article is moronic! The vast vast majority of shops are not going to adopt Extreme Programming, and cut their velocity in half, by using twice as many programmers as they needed yesterday to get the same amount of work done!

The author frames the whole thing as an argument between her and some other guy, but I don't even know what the other guy's argument is (she left it out). Still, her argument so incredibly tone-deaf and awful, I'm definitely on his side.

Imo, the article misses the main point of code review. It's not about finding bugs or spreading around knowledge, but about maximizing value vs maintenance costs. Code is expensive, not to produce but to maintain. Every line of code added to a codebase must be read and understood many times over its lifetime, and therefore imposes a burden on future maintainers. We review code in order to weigh its value against that high cost of ownership. High quality, maintainable code is code which maximizes that value delivered while minimizing the cost of its future maintenance.

AI is changing the game here not by increasing (or decreasing) the value of code, but by reducing its cost of ownership. When it's significantly cheaper to understand, modify, and replace code, the balance point shifts significantly. It's the definition of "maintainable" that's changing.

I’m not convinced code reviews add much value, unless most of your co-workers are less capable and you’re trying to improve overall quality.

That said, I get a lot of value from talking to experienced developers before writing any code.

Are we going back to waterfall?

>My question is: why are we waiting until code review to do all of those things? > > I’ve never particularly liked pull requests as the centre of the software development process. Not because engineers shouldn’t look at each other’s code, but because I’ve always struggled with the idea that we should build something, finish it, package it up, throw it over to somebody else and then have the important conversation about whether we built the right thing in the right way.

I didn't think this is a controversial take (except for some of the solutions proposed) design and high level implementation shouldnt be happening in code review. that's way to late in the process.

How about.. "it depends" ?

I review things that I know are "important".. but I've learned that there are many things that I don't care how it works at this point- they aren't critical in terms of I know it's not going to cascade and break other things (that's where us senior engineers know what to look for).

But there's no way in the hell I can review all the code that is being generated for so many things that just don't need reviewing. They work- that's honestly good enough for a lot of use cases. I review the code that touches sensitive areas and I know aren't very straightforward (which, I would put at only 10%).

just ship it, full steam ahead. hesitation is defeat. i am paid to prompt, not to care.

> My question is: why are we waiting until code review to do all of those things? I’ve never particularly liked pull requests as the centre of the software development process.

This is a strawman. Who is writing code professionally without planning ahead?

> Perhaps that’s what AI is exposing. ... It worked, sort of, while humans could only produce code so quickly.

Huh? This doesn't make any sense to me either for the exact same reason. Are the kinds of people who always sucked at planning finally getting slightly better at it with AI? Is this a breakthrough for people with ADHD, or what? Do these people really like seeing lots of text scroll by so much that they can't have a few simple meetings?

I'm still confused what any of this is really about. To me it reads like another AI copout blog post. I want to understand the author's idea of a productive workflow.

[flagged]

[flagged]

[flagged]

There also shouldn't be QA on air planes. What's the big deal?

Also we can get rid of that nurse keeping track of surgical instruments during a surgeries.

What's the big deal if a surgeon leaves a a scapel inside of someone?

This article flies so wildly in the face of good engineering and scientific practices it feels like a subtle troll post to get views.