5 ms·

Maybe we shouldn't be reviewing all this code

47 points by ingve 1mo ago

deleted 1mo ago
[deleted]
hungryhobbit 1mo ago
>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.
- joshgachnang 1mo ago
  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.
- em-bee 1mo ago
  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.
- natbennett 1mo ago
  > 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.
  - hungryhobbit 1mo ago
    I've done pair programming (at an Extreme Programming shop). There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on. But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot. Pair programming is not about getting more done, it's about getting less done (but done better).
- grebc 1mo ago
  If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.
- Rapzid 1mo ago
  You must not be familiar with Thoughtworks. Even before AI they were happy to bill you 5x more consultant hours than necessary.
ares623 1mo ago
just ship it, full steam ahead. hesitation is defeat. i am paid to prompt, not to care.
Arainach 1mo ago
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.
- jameskilton 1mo ago
  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.
  - keyle 1mo ago
    +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.
  - Arainach 1mo ago
    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.
    - deleted 1mo ago
      [deleted]
edu 1mo ago
Are we going back to waterfall?
- dgabriel 1mo ago
  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.
- thephyber 1mo ago
  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.
eatsyourtacos 1mo ago
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%).
- thephyber 1mo ago
  So, you just replied to the title and didn't read the piece, eh?
sfjailbird 1mo ago
> 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.
- thephyber 1mo ago
  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.
wgreenberg 1mo ago
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!
- em-bee 1mo ago
  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.
  - wpasc 1mo ago
    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)
    - em-bee 1mo ago
      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)
synalx 1mo ago
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.
- em-bee 1mo ago
  AI may reduce the cost of code production, but it raises the cost of ownership.
  - Tanoc 1mo ago
    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.
    - em-bee 1mo ago
      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.
- ed_mercer 1mo ago
  Fable-class models IMO are now capable enough to maintain your code as well.
ramshanker 1mo ago
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.
- an0malous 1mo ago
  Care to share a link?
  - ramshanker 1mo ago
    https://github.com/ramshankerji/Vishwakarma https://github.com/ramshankerji/Vishwakarma
    - demibabs 1mo ago
      Engineering buildings with vibecoded software? Sign me up
      - glouwbug 1mo ago
        I guess this is what you call software architecture
- horizonwingtech 1mo ago
  [flagged]
tayo42 1mo ago
>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.
the_real_cher 1mo ago
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.
humbleharbinger 1mo ago
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.
flerchin 1mo ago
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.
RobDAWG209 1mo ago
[flagged]
singpolyma3 1mo ago
> 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.
sashank_1509 1mo ago
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.
levl289 1mo ago
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.
knighthacker 1mo ago
[flagged]
sublinear 1mo ago
> 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.
deterministic 1mo ago
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.
grebc 1mo ago
I certainly wouldn't want to review anything with Martin Fowler's name attached thanks anyway.
continuous_lex 1mo ago
[flagged]
xtiansimon 1mo ago
> “ 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.
javonet 1mo ago
[flagged]
graftcodecom 1mo ago
I would propose slightly different solution, I was doing software development for 30 years learning first patterns from Martin articles and what always felt strange was the fact that we had top 20 programming languages living in kind of silos. I stride to address that by implementing runtime bridge for Java and .net and it was quite successful but only in niche use cases where somebody badly needed to use jar in .net or other way. One of funny achievement was that we managed to allow our customers use wpf user controls inside Java jframe! And it was living nicely in the UI and was binding events allowing to call methods etc.. That led me to though why if we take unzip library in Java we just add it as dependency via maven but if we call the same remotely or want to use unzip from Nuget we suddenly host it on separate node, write either rest, gRPC, subscribe queue via sdk or use thrift and then we write client for that and call it through those artificial layers up to unzip(string:filename) methods we wanted to call. WHY? And therefore looking how to broaden our runtimebridge market we tried a crazy idea to allow any tech use any other tech by simple calling their public methods regardless if it’s in memory or remotely. It took building runtime bridge for 143 tech pairs supporting clr, jvm, python, ruby, php, c++, go, node (js/ts), browsers js/ts etc… NEXT we made it possible so they can call each other in memory and remotely. Than we made that strongly typed interface is obtainable via simple package manager call. And now users can take any module write just public methods and host it on our gateway running in their container/vm/machine and immediately they get api browser with commands for any package manager to get strongly typed client on the fly that always stays up to date. Whenever anyone uses the module obtained (we call it graft) and calls any method it gets routed via any channel based on runtime config i.e. via env var and it can go http2, WebSocket, tcp/ip, any queue/event bus etc, or in memory! And the system design is super simple just public methods and classes using them. It fits 1:1 what we see in OOP uml, code is fully decoupled from integration method, so we can change architecture in runtime even extracting logic to microservices from monolith. All services clearly reference their dependencies and get always up to date strongly typed client. All of that makes AI, understand such system much better, use much less tokens, use much more efficiently context, and makes pull request review much easier! The team either before or after code is written has much better control through simple OOP design. It’s still evolving but we already achieved enterprise readiness and have many great POCs including IBM. We support full open telemetry, authentication, standard encryption of underlying channels purely removing the difference from same tech, cross tech, remote or local calls. Now everything feels like local method calls. You think it would help to solve the issue of reviewing that code? @martinfowler?
margolis20 21d ago
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.
- othmanosx 21d ago
  That's the pitch I'm trying to make with https://pyor.review https://pyor.review The only way to scale reviews is by using AI to skip rather than add more walls of text

47 points by ingve 1mo ago

deleted 1mo ago

[deleted]

>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.

joshgachnang 1mo ago
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.
em-bee 1mo ago
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.
natbennett 1mo ago
> 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.
- hungryhobbit 1mo ago
  I've done pair programming (at an Extreme Programming shop). There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on. But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot. Pair programming is not about getting more done, it's about getting less done (but done better).
grebc 1mo ago
If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.
Rapzid 1mo ago
You must not be familiar with Thoughtworks. Even before AI they were happy to bill you 5x more consultant hours than necessary.

ares623 1mo ago

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

Arainach 1mo ago

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.

jameskilton 1mo ago
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.
- keyle 1mo ago
  +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.
- Arainach 1mo ago
  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.
  - deleted 1mo ago
    [deleted]

edu 1mo ago

Are we going back to waterfall?

dgabriel 1mo ago
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.
thephyber 1mo ago
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.

eatsyourtacos 1mo ago

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%).

thephyber 1mo ago
So, you just replied to the title and didn't read the piece, eh?

sfjailbird 1mo ago

> 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.

thephyber 1mo ago
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.

wgreenberg 1mo ago

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!

em-bee 1mo ago
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.
- wpasc 1mo ago
  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)
  - em-bee 1mo ago
    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)

synalx 1mo ago

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.

em-bee 1mo ago
AI may reduce the cost of code production, but it raises the cost of ownership.
- Tanoc 1mo ago
  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.
  - em-bee 1mo ago
    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.
ed_mercer 1mo ago
Fable-class models IMO are now capable enough to maintain your code as well.

ramshanker 1mo ago

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.

an0malous 1mo ago
Care to share a link?
- ramshanker 1mo ago
  https://github.com/ramshankerji/Vishwakarma https://github.com/ramshankerji/Vishwakarma
  - demibabs 1mo ago
    Engineering buildings with vibecoded software? Sign me up
    - glouwbug 1mo ago
      I guess this is what you call software architecture
horizonwingtech 1mo ago
[flagged]

tayo42 1mo ago

>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.

the_real_cher 1mo ago

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.

humbleharbinger 1mo ago

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.

flerchin 1mo ago

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.

RobDAWG209 1mo ago

[flagged]

singpolyma3 1mo ago

> 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.

sashank_1509 1mo ago

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.

levl289 1mo ago

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.

knighthacker 1mo ago

[flagged]

sublinear 1mo ago

> 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.

deterministic 1mo ago

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.

grebc 1mo ago

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

continuous_lex 1mo ago

[flagged]

xtiansimon 1mo ago

> “ 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.

javonet 1mo ago

[flagged]

graftcodecom 1mo ago

I would propose slightly different solution, I was doing software development for 30 years learning first patterns from Martin articles and what always felt strange was the fact that we had top 20 programming languages living in kind of silos. I stride to address that by implementing runtime bridge for Java and .net and it was quite successful but only in niche use cases where somebody badly needed to use jar in .net or other way. One of funny achievement was that we managed to allow our customers use wpf user controls inside Java jframe! And it was living nicely in the UI and was binding events allowing to call methods etc.. That led me to though why if we take unzip library in Java we just add it as dependency via maven but if we call the same remotely or want to use unzip from Nuget we suddenly host it on separate node, write either rest, gRPC, subscribe queue via sdk or use thrift and then we write client for that and call it through those artificial layers up to unzip(string:filename) methods we wanted to call. WHY? And therefore looking how to broaden our runtimebridge market we tried a crazy idea to allow any tech use any other tech by simple calling their public methods regardless if it’s in memory or remotely. It took building runtime bridge for 143 tech pairs supporting clr, jvm, python, ruby, php, c++, go, node (js/ts), browsers js/ts etc… NEXT we made it possible so they can call each other in memory and remotely. Than we made that strongly typed interface is obtainable via simple package manager call. And now users can take any module write just public methods and host it on our gateway running in their container/vm/machine and immediately they get api browser with commands for any package manager to get strongly typed client on the fly that always stays up to date. Whenever anyone uses the module obtained (we call it graft) and calls any method it gets routed via any channel based on runtime config i.e. via env var and it can go http2, WebSocket, tcp/ip, any queue/event bus etc, or in memory! And the system design is super simple just public methods and classes using them. It fits 1:1 what we see in OOP uml, code is fully decoupled from integration method, so we can change architecture in runtime even extracting logic to microservices from monolith. All services clearly reference their dependencies and get always up to date strongly typed client. All of that makes AI, understand such system much better, use much less tokens, use much more efficiently context, and makes pull request review much easier! The team either before or after code is written has much better control through simple OOP design. It’s still evolving but we already achieved enterprise readiness and have many great POCs including IBM. We support full open telemetry, authentication, standard encryption of underlying channels purely removing the difference from same tech, cross tech, remote or local calls. Now everything feels like local method calls. You think it would help to solve the issue of reviewing that code? @martinfowler?

margolis20 21d ago

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.

othmanosx 21d ago
That's the pitch I'm trying to make with https://pyor.review https://pyor.review The only way to scale reviews is by using AI to skip rather than add more walls of text