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.
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.
Physical placement isn't important. Psychologically, it's the same. What it means is that for the entire duration there is someone paying close attention to (and potentially judging) everything I do. No downtime, no zoning out, focus and performance for an extended period.
IM notification from an old teammate pops up complaining about my boss? Seen.
Switch to a window with my personal email and they can see that thing I just bought or that recruiter I've been talking to? Seen.
I type a stupid thing that will never work? In the 5-30 seconds before I realize it, seen.
It doesn't matter if I trust my pair. That's not how the brain works.
As someone who pair programmed 8 hours a day for 10+ years, it’s important to note that there is an ebb and flow. Sometimes we were collaborating fully. Sometimes one of us got up to make coffee and looked at Instagram on their phone for 20 minutes while the other tried to get tests to pass. Then we reunited and caught each other up. It’s easy to dwell on the intense part of pairing, but it’s just as important to purposefully acknowledge your humanity and expect to take real actual breaks and go sit in a comfy chair and zone out for a short while or go to a doctor appointment or chat up another person at the water cooler for a bit.
8 hours a day pairing means that pairing is the default, but it’s not the only thing that ever happens.
also: 8 hours/day pairing meant 16 hours/day not working at all in my case. Really really really not working. Not checking Slack. Not trying out some crazy idea. Not working at all.
Well you won't have IM or email open while pairing :) you'll be focured on the conversation you're having with your pair. They're not watching you you're collaborating
I've never pair programmed. How can one achieve concentration for "deep focus" or "deep thought"? I'm only able to do that alone. Is it a me problem, or are some people able to focus deeply with others talking to them?
There have been (extensive) discussions on this topic here [1]. I don't seem to be alone in the inability to think clearly with interruptions.
you are not being interrupted. your partner is thinking with you and is paying close attention to what you are doing. they will know you well enough to not interrupt you while you are focusing on something specific. they will wait for the right moment to speak up if they have something to add, and even then they will not change the focus to some other part of the task if they know that this would disrupt you.
this takes time to learn of course. and individuals handle this differently. i to can't handle interruptions, but when i am focusing a piece of code, and my partner telling me or asking me something about that same piece of code, then for me that's not an interruption. interruptions are notifications and being asked to change the focus on something different. that should not happen when pair programming.
another aspect not mentioned yet, when there is an actual interruption from the outside, one of the people in the pair can handle that interruption, while the other continues to focus. the interrupted one can then jump back in much faster than you would if you were interrupted while alone.
> you are not being interrupted. your partner is thinking with you
As the many examples in that discussion show, this is your subjective experience, with others build different than you.
To me, those two sentences side by side are in complete contradiction with how I experience the world, where the knowledge of a persons attention is distracting, like a glaring light.
But, for learning a new language/framework/codebase, I think it would work very well. The quickest, and most enjoyable, "ramp ups" I've ever experienced were just sitting next to someone and bouncing questions off of them as I explored.
I’m all for talking through things and getting a second opinion, but when it comes time to actually crafting things, I need my own space, maybe I’m just weird
Pair programming worked well for me in college because my peers had about the same level of background knowledge and the goal was well defined. At my day job, pair programming doesn’t work as well, since the knowledge gaps in different parts of the system are too great. We don’t have a cohesive skill set.
But that's the entire point. Pair programming isn't for producing more working code in this session faster. It's that it empirically is the fastest way to erase knowledge gaps because the two of you are working on a shared artifact.
> one person at the keyboard and the other person saying what's next
My understanding is that there is no one person saying what's next but what's next gets decided by both people. Otherwise, the other person is just a typist.
That’s the ideal, but if you have the person at the keyboard doing too much of the planning then it’s really easy for the other person to just check out mentally.
> 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.
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.
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.
In our current environment using AI, individual development also "doesnt scale", so this "doesnt scale", 2X.
I think these proponents of AI have a very large burden on them to not just make this palatable for developers, but to actually make it "scale" as you say.
The human code review process for AI generated code will simply die due to lack of interest. Its up to the organization to find a suitable replacement or continue to pretend that half asleep disinterested developers are going to fix all this trash.
research has shown that the longer work in one day the lower your performance gets. meaning that eg in the first 4 hours i get 60% of my work done and in the remaining 4 hours 40% simply because i get tired later in the day. (numbers made up for illustration purposes only)
4 hours of pair programming per day can therefore possibly be enough to make up for the increased loss of performance in the rest of the day.
The world is full of examples of companies that reward people who are more productive in a few hours by letting them go home instead of raising expectations and working them to death, I assume.
i get where you are coming from, but i suspect that the company that does that would also exhaust people without pair programming. bad work environments exist, and yeah, those are probably not the places where you want to introduce pair programming.
The person "watching" should be actively engaging and helping to build the "theory of the program" (in the Naur sense) through questions and conversations. If they're just sitting there silently they aren't doing the practice. (Also, I prefer to work with both developers having a keyboard and mouse. You still should have one person driving, but the other person can jump in and directly make changes instead of having to use the other person as a puppet.)
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.
Is this not what programming alongside or with an AI agent is these days? Brainstorming, reviewing, debugging. The only difference is there's no second human building a working knowledge of the code being written.
They're not human. When I interact with AI, it's an emotionless chat bot computer program. When I interact with a human, a whole other sections of my brain necessarily light up, because they do have emotions, they do judge me and I care about those opinions about me, and they have long term memory, all thanks to the millions of years of evolution around social interactions with other humans.
To me pair programming is outdated. I did it for a year, and I understand that it can have some strengths, sometimes for some software. In the LLM age though, I haven't seen it, and don't think we ever will again. The stress, overstimulation, and exhaustion were real costs that the business just does not care about. "You are engineer, you not have feelings, bang keyboard harder with other Engineer."
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!
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.
Look at the base of the structure on the right side, and you'll see that in the same plane there are the bumps present and bumps hidden by the same flat plane in a way they shouldn't be. then the left side, the bump visibility doesn't make lego sense
(i agree that maybe OP pointing that out is nitpicking, but to steelman the case, such inaccuracies are what code review would find and are the subtle bugs that might pass a code review and break prod)
you mean the white bump on top of the purple brick that should not be there? well, i saw that as a marking on the brick because if it was a bump it would be purple. and on the left side whether that looks right or not depends on the angle.
(we are nitpicking the nitpicking, it's nits all the way down. my last line in the previous comment was also based on the image. to shatter your steelman, picking on the illustration of the article that is just there to add some color is at best like a code review complaining about style or indenting. with endless bikeshedding opportunities, not something a code review should be focusing on. if the picture were of central importance then that would be different. btw, i am not complaining, i am having good natured fun here)
> 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.
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.
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.
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.
>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.
I write a bunch of features. Most are pretty boring. A junior isn't going to learn much by pairing. But occasionally, I do big architecture changes. Those ones are perfect for early collaborative design, pairing, and discussion. The whole team benefits from understanding the architecture better and juniors get to see how seniors think about it. Then you can pair with juniors on the prompting or, more likely, the implementation plan to hand to the agents. That's maybe once a week.
my performance goes up when i pair program. therefore velocity is not cut in half. depending on the pair, the velocity may even be higher than the combination if the two people working individually.
also if pair programming means saving time on code reviews then that's a further increase in velocity.
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.
Not just the cost of ownership, but the cost of disposal. Removing parts becomes much harder if you have to look through a lot more pieces to determine how they connect to everything else and what still relies on them. Programmers sometimes forget that they aren't just adding and making new things all the time, but that their job also requires digging through multiple older layers to excise obsolete unneeded things.
absolutely, for me that's included in the cost of ownership. just like the cost of ownership of physical items includes the cost of disposal of those items once they are no longer useful.
She's just arguing that most of the purposes of code reviews should be done before the typing part of coding instead of after. Identifying the best design before investing in typing / tokens.
Waterfall has to do with the size of the loop and when the customer gets to provide consumable feedback. She's not proposing changes to the size of that loop.
I mean, we certainly are in a lot of cases. Spec driven development is waterfall, and we're all in the midst of a new experiment to see if it works. I'm not sold, but consultants love it.
>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.
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%).
> 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.
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.
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.
Physical placement isn't important. Psychologically, it's the same. What it means is that for the entire duration there is someone paying close attention to (and potentially judging) everything I do. No downtime, no zoning out, focus and performance for an extended period.
IM notification from an old teammate pops up complaining about my boss? Seen.
Switch to a window with my personal email and they can see that thing I just bought or that recruiter I've been talking to? Seen.
I type a stupid thing that will never work? In the 5-30 seconds before I realize it, seen.
It doesn't matter if I trust my pair. That's not how the brain works.
As someone who pair programmed 8 hours a day for 10+ years, it’s important to note that there is an ebb and flow. Sometimes we were collaborating fully. Sometimes one of us got up to make coffee and looked at Instagram on their phone for 20 minutes while the other tried to get tests to pass. Then we reunited and caught each other up. It’s easy to dwell on the intense part of pairing, but it’s just as important to purposefully acknowledge your humanity and expect to take real actual breaks and go sit in a comfy chair and zone out for a short while or go to a doctor appointment or chat up another person at the water cooler for a bit.
8 hours a day pairing means that pairing is the default, but it’s not the only thing that ever happens.
also: 8 hours/day pairing meant 16 hours/day not working at all in my case. Really really really not working. Not checking Slack. Not trying out some crazy idea. Not working at all.
Well you won't have IM or email open while pairing :) you'll be focured on the conversation you're having with your pair. They're not watching you you're collaborating
+1 for exhausting. Also my experience. Very valuable when you have to write business logic or a complex feature the business will rely on.
Definitely not good for long running work and chasing bugs.
I've never pair programmed. How can one achieve concentration for "deep focus" or "deep thought"? I'm only able to do that alone. Is it a me problem, or are some people able to focus deeply with others talking to them?
There have been (extensive) discussions on this topic here [1]. I don't seem to be alone in the inability to think clearly with interruptions.
[1] https://news.ycombinator.com/item?id=22059601
you are not being interrupted. your partner is thinking with you and is paying close attention to what you are doing. they will know you well enough to not interrupt you while you are focusing on something specific. they will wait for the right moment to speak up if they have something to add, and even then they will not change the focus to some other part of the task if they know that this would disrupt you.
this takes time to learn of course. and individuals handle this differently. i to can't handle interruptions, but when i am focusing a piece of code, and my partner telling me or asking me something about that same piece of code, then for me that's not an interruption. interruptions are notifications and being asked to change the focus on something different. that should not happen when pair programming.
another aspect not mentioned yet, when there is an actual interruption from the outside, one of the people in the pair can handle that interruption, while the other continues to focus. the interrupted one can then jump back in much faster than you would if you were interrupted while alone.
> you are not being interrupted. your partner is thinking with you
As the many examples in that discussion show, this is your subjective experience, with others build different than you.
To me, those two sentences side by side are in complete contradiction with how I experience the world, where the knowledge of a persons attention is distracting, like a glaring light.
But, for learning a new language/framework/codebase, I think it would work very well. The quickest, and most enjoyable, "ramp ups" I've ever experienced were just sitting next to someone and bouncing questions off of them as I explored.
I’m all for talking through things and getting a second opinion, but when it comes time to actually crafting things, I need my own space, maybe I’m just weird
Pair programming worked well for me in college because my peers had about the same level of background knowledge and the goal was well defined. At my day job, pair programming doesn’t work as well, since the knowledge gaps in different parts of the system are too great. We don’t have a cohesive skill set.
But that's the entire point. Pair programming isn't for producing more working code in this session faster. It's that it empirically is the fastest way to erase knowledge gaps because the two of you are working on a shared artifact.
> one person at the keyboard and the other person saying what's next
My understanding is that there is no one person saying what's next but what's next gets decided by both people. Otherwise, the other person is just a typist.
That’s the ideal, but if you have the person at the keyboard doing too much of the planning then it’s really easy for the other person to just check out mentally.
the other person is a typist that thinks through the ideas they hear and critiques them while they are typing.
> 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.
“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.
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.
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.
Fascinating; I find myself a lot more stressed and overstimulated when facing a problem alone than with a friend.
In our current environment using AI, individual development also "doesnt scale", so this "doesnt scale", 2X.
I think these proponents of AI have a very large burden on them to not just make this palatable for developers, but to actually make it "scale" as you say.
The human code review process for AI generated code will simply die due to lack of interest. Its up to the organization to find a suitable replacement or continue to pretend that half asleep disinterested developers are going to fix all this trash.
Have fun with that!
my performance goes up when i pair program. even if the partner is a junior, simply because i am more focused.
Intense focus increases performance right up until the point where burnout or exhaustion causes performance to absolutely collapse.
research has shown that the longer work in one day the lower your performance gets. meaning that eg in the first 4 hours i get 60% of my work done and in the remaining 4 hours 40% simply because i get tired later in the day. (numbers made up for illustration purposes only)
4 hours of pair programming per day can therefore possibly be enough to make up for the increased loss of performance in the rest of the day.
The world is full of examples of companies that reward people who are more productive in a few hours by letting them go home instead of raising expectations and working them to death, I assume.
i get where you are coming from, but i suspect that the company that does that would also exhaust people without pair programming. bad work environments exist, and yeah, those are probably not the places where you want to introduce pair programming.
That's why breaks exist.
Pair programming is one person coding, and one person watching.
The person "watching" should be actively engaging and helping to build the "theory of the program" (in the Naur sense) through questions and conversations. If they're just sitting there silently they aren't doing the practice. (Also, I prefer to work with both developers having a keyboard and mouse. You still should have one person driving, but the other person can jump in and directly make changes instead of having to use the other person as a puppet.)
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.
Is this not what programming alongside or with an AI agent is these days? Brainstorming, reviewing, debugging. The only difference is there's no second human building a working knowledge of the code being written.
They're not human. When I interact with AI, it's an emotionless chat bot computer program. When I interact with a human, a whole other sections of my brain necessarily light up, because they do have emotions, they do judge me and I care about those opinions about me, and they have long term memory, all thanks to the millions of years of evolution around social interactions with other humans.
> 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 suspect this is a simple social anxiety you could train away.
To me pair programming is outdated. I did it for a year, and I understand that it can have some strengths, sometimes for some software. In the LLM age though, I haven't seen it, and don't think we ever will again. The stress, overstimulation, and exhaustion were real costs that the business just does not care about. "You are engineer, you not have feelings, bang keyboard harder with other Engineer."
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!
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.
Look at the base of the structure on the right side, and you'll see that in the same plane there are the bumps present and bumps hidden by the same flat plane in a way they shouldn't be. then the left side, the bump visibility doesn't make lego sense
(i agree that maybe OP pointing that out is nitpicking, but to steelman the case, such inaccuracies are what code review would find and are the subtle bugs that might pass a code review and break prod)
you mean the white bump on top of the purple brick that should not be there? well, i saw that as a marking on the brick because if it was a bump it would be purple. and on the left side whether that looks right or not depends on the angle.
(we are nitpicking the nitpicking, it's nits all the way down. my last line in the previous comment was also based on the image. to shatter your steelman, picking on the illustration of the article that is just there to add some color is at best like a code review complaining about style or indenting. with endless bikeshedding opportunities, not something a code review should be focusing on. if the picture were of central importance then that would be different. btw, i am not complaining, i am having good natured fun here)
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
> 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.
Care to share a link?
https://github.com/ramshankerji/Vishwakarma
Engineering buildings with vibecoded software? Sign me up
I guess this is what you call software architecture
[flagged]
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.
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.
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.
If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.
I didn't read this as "pair program every line".
I write a bunch of features. Most are pretty boring. A junior isn't going to learn much by pairing. But occasionally, I do big architecture changes. Those ones are perfect for early collaborative design, pairing, and discussion. The whole team benefits from understanding the architecture better and juniors get to see how seniors think about it. Then you can pair with juniors on the prompting or, more likely, the implementation plan to hand to the agents. That's maybe once a week.
> The vast vast majority of shops are not going to adopt Extreme Programming
True!
> and cut their velocity in half
That’s not how pair programming works.
my performance goes up when i pair program. therefore velocity is not cut in half. depending on the pair, the velocity may even be higher than the combination if the two people working individually.
also if pair programming means saving time on code reviews then that's a further increase in velocity.
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.
Fable-class models IMO are now capable enough to maintain your code as well.
AI may reduce the cost of code production, but it raises the cost of ownership.
Not just the cost of ownership, but the cost of disposal. Removing parts becomes much harder if you have to look through a lot more pieces to determine how they connect to everything else and what still relies on them. Programmers sometimes forget that they aren't just adding and making new things all the time, but that their job also requires digging through multiple older layers to excise obsolete unneeded things.
absolutely, for me that's included in the cost of ownership. just like the cost of ownership of physical items includes the cost of disposal of those items once they are no longer useful.
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?
This has nothing to do with the article.
She's just arguing that most of the purposes of code reviews should be done before the typing part of coding instead of after. Identifying the best design before investing in typing / tokens.
Waterfall has to do with the size of the loop and when the customer gets to provide consumable feedback. She's not proposing changes to the size of that loop.
I mean, we certainly are in a lot of cases. Spec driven development is waterfall, and we're all in the midst of a new experiment to see if it works. I'm not sold, but consultants love it.
>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%).
So, you just replied to the title and didn't read the piece, eh?
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.