Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by sashank_1509 - > 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.
by sfjailbird - What's a weird argument? Did you read this article?
She's arguing that most code reviews aren't necessary. Some can be automated if they are deterministically predictable (eg. formatting, lint, standardization changes). Others should be reviews of design before the coding phase.
She gives a few specific examples of when code reviews should be maintained.
by thephyber - 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%).
- So, you just replied to the title and didn't read the piece, eh?by thephyber
- >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.
by tayo42 - 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.by levl289
- > “ Shift the judgment left …shorten feedback loops.[…] Take the things we say code review gives us. If we want to explore alternative solutions […] If we want knowledge transfer […] If we want junior engineers to learn how experienced engineers think […] If we want collective ownership, […] If we want architectural alignment […] And if we’re reviewing code for formatting, linting, known security problems or things that can be deterministically tested […] Review by exception None of this means nobody ever reviews code.”
I don’t program as a “hired programmer”, but rather use programming in my work. That said, reading this list i’m at a different takeaway— I’m thinking “code review” is a catchphrase for a bunch of reasonably different tasks.
by xtiansimon - 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!by wgreenberg
- I genuinely enjoyed the game of "where's waldo" that
> easily identifiable problems
sent me down. as soon as I parsed that line I stopped reading, and I tabbed back over to spot them
by wpasc - how is the lego structure impossible? it is unstable because it's made only of 1-stud bricks. and there are some non existent multi colored bricks in use, but those could theoretically be produced. also while the wheels are not connected, you could stack pricks on top. so it's improbable, but not impossible.
just drink a cup of NO and you'll be fine.
by em-bee - 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.by ramshanker
- Care to share a link?by an0malous
- 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.
by Arainach - I did it full-time for 3 months and it was exhausting. I found it useful for learning a new framework (Ruby on Rails at that time) but in general I did not find it compatible with how I think and work.by foundart
- In the last company I worked at, when a project was major enough (read, long-running and full of tricky details) to require two devs' full-time attention, they'd hole up in a flex room for weeks at a time.[0] "The cave" basically became their temporary office until they'd re-emerge ~a month later.
I spent a few weeks in the cave and it was surprisingly chill, not nearly as oppressive as it sounds. (Although, I was much more energetic a decade ago and maybe it wouldn't be quite as fun these days :-P.) I still have a picture of my madness-induced, Git hook–infested scribblings....
[0] The team's usual room was an open floor plan, which was fine with good headphones, but naturally that solution doesn't work for pair programming.
by BalinKing - In my experience, pair programming is amazing as a teaching tool. Pairing a (very) experienced dev with a much more junior one will do wonders in upscaling the technical skills of the latter and - more often than not - interpersonal skills and even humility of the former.
- Fascinating; I find myself a lot more stressed and overstimulated when facing a problem alone than with a friend.by sssilver
- I imagine it would become a different job altogether, more in the style of buddy cop movies: you'll be spending all your work hours doing every project with your partner, sometimes they code, sometimes you do, but you become a single unit for all intents and purposes.
I'd also hate it with every cell of my body, but for some it's just another way of life.
by makeitdouble - “It doesn’t scale” and “it’s unreasonably difficult for many people” aren’t the same thing.
It scales fine to 400+ engineers. You do have to be willing to hire specifically for pairing tolerance.
by natbennett - > Pair programming once in a while can be incredibly valuable.
> a world of stress and overstimulation
yeah so I think the thing here is that one of these is an objective outcome of pairing, and the other one is a personal preference. Which is a valid preference, but it does nothing to refute the fact that pair programming is a great solution for the issues laid out in the article.
I don't particularly like writing tests, but that doesn't stop me from doing so. I think we should think about pair programming like we think about tests: a necessary part of the process, and something most companies don't do enough.
- Then you've never actually Pair Programmed. It's not "someone looking over your shoulder", it's literally two people writing the code together, one person at the keyboard and the other person saying what's next. Two brains working in tandem on the same problem space.
It works really well, but it is exhausting, and difficult to sell.
by jameskilton - > 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.
by singpolyma3 - I think with the velocity of AI generated code, that's not even an option. There's no way code reviews can scale. We will need better tools for AI reviews, but also a direction that I think will become critical - knowing how to drive human attention where it is really needed. This seems to me one of the major parts that are missing today. We should know when a review is critical and when we can skip it.by margolis20