4 ms·

Gating integration behind code review is futile. I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Comp

by 4lx87 3mo ago

Gating integration behind code review is futile. I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile. I think all these platforms chasing code review are doomed. My LLM doesn't need any of this tooling. We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code). The future of software production is more like Replit – not GitHub.

tripleee 3mo ago
What's your job as an "engineer" in this post-automated world? QA?
- 4lx87 3mo ago
  Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
  - necovek 3mo ago
    Before LLMs, "organizations" have seen code review as multiple things: * Share knowledge about a particular area of the codebase between multiple people * Share overall engineering knowledge between the parties in the review * Ensure maintainability of the codebase long-term * Ensure readability of the code * Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change) * Ensure changes are small, self-contained, and as often as possible, reversible * Do some basic manual QA * Do comprehensive integration testing with a fully built-out system ... * And yes, catch bugs before they hit production. A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced. Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).
- roncesvalles 3mo ago
  The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones. Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself. A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
  - jdzikowski 3mo ago
    > The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones. Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.
20k 3mo ago
>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile. This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant The reason for human code review is: 1. So *you* understand what's going on, not the LLM, and people can ask you questions about it 2. Because LLMs are not that good at code review It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?
- dhorthy 3mo ago
  blake smith has a really good post on this - that mental alignment among the team is the primary purpose of code review - https://blakesmith.me/2015/02/09/code-review-essentials-for-software-teams.html https://blakesmith.me/2015/02/09/code-review-essentials-for-...
  - 4lx87 3mo ago
    That is a good post. Thank you for sharing. I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses). It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.
    - DaiPlusPlus 3mo ago
      > In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. Nope. To reduce it down to a single word, I'd say we do code-reviews to assess "taste". ----- Code-review is one part of a larger process (the SDLC!), and while review does help with "finding bugs" it is not the singular reason why we do it; and other parts of the SDLC are concerned with finding bugs in the first place, namely the various Test and QA steps in the process; when your code is in the (peer) code-review step then there's an expectation that the author already identified and resolved actual bugs/defects (i.e. where actual-program-behaviour deviates from the spec[1]), so a PR for new functionality is expected to include unit and integration tests to demonstrate that. Now Claude will gladly take a Jira ticket, write-up a plan/spec, write tests, implement the feature, verify the tests pass, address static-analysis issues, push branch, and submit the PR - and if-the-program-works then it's "correct" and so surely there's nothing really to review and so merging the changes should be a breeze... but I find myself rejecting these PRs all the time because these agents still "just don't get it"[2]. (But I'm sure they'll "get it" eventually; you can't stop progress). We can revisit this topic when we get there; but for now I'm going to reject an AI-authored PR that eschews it. Good taste is important. [1] I'm not going to pretend anyone actually writes any kind of spec (informal or otherwise) for the vast majority of software out there; but an unwritten-spec exists when you mentally combine a vague Jira ticket, platform-conventions and common-sense (and that's how Claude in an Agentic Loop works too, except it always has to write-out the Spec.md/Plan.md to disk first, whereas us humans keep things in our head). [2] I cannot define "it".
layer8 3mo ago
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. You’re arguing for experiment over logical proof or reasoning. That’s qualitatively a very different thing, and the former is no adequate replacement for the latter.
gabrieledarrigo 3mo ago
> Code (and specs) are going to fade into obscurity I'm always skeptical when I read absolute statements like this. Especially about specs. They drive and document how the software should work, behave, and under which conditions. In the same moment you write a prompt in natural language, you are writing a spec. Why should they disappear? For the same reasoning, we could no longer need books or manuals or documents (is it valuable to keep around that doc about F-22 specs?).
- abernard1 3mo ago
  Agreed. Specs are more important than ever. Constraints: types, contracts, protocols, schemas, APIs and such are what ground the boundaries of systems. Without them, code drift is a guarantee. Does anyone trust that a set of human sentences typed into a box is more reliable and precise than objectively exact descriptions of data? This is not to diminish the utility of these code factories. But surely, if anything provides resistance to drift, it's codebase consistency, standards, and things which must objectively be true for the software to function.
jeremyjh 3mo ago
This entire article is about the fact that the codebase deteriorates over time when you work this way. If they are correct, it will take longer and longer to develop PRs, and more and more cycles to QA them. Eventually the code will be unsalvageable and it might get there before anyone notices a problem. I don’t know if they are right but I know codebases can get there with humans at the helm - and the humans can adapt and learn. This is not a certain fate but it sure looks likely and is a serious risk. Some software is so low stakes that you can get away with it I’m sure - there are always trade offs.
- satvikpendem 3mo ago
  The bet is that models get better faster than code gets worse. Looks like so far it's correct, as Fable can already write better code than me and most others on average.
  - dhorthy 3mo ago
    the thesis of the post is that this is not true. fable can solve more problems but for complex systems it is not sufficiently diligent that you can turn the lights off.
    - satvikpendem 3mo ago
      They turned the lights off in 2025. The post is simply not accurate to today, they even say so, stating that apparently no one has proof of better models in 2026 improving codebases over time. I've seen it happen but the author hasn't apparently, so it's a game of "you said I said", not anything concrete.
      - dhorthy 3mo ago
        (op here btw) - the question isn't "can models make code better" - its "left fully unattended, will they turn your codebase to slop over time" from the footnotes (sorry if this got a little buried) > yes of course you can get gpt-5.5 xhigh to do BRILLIANT refactors. But you had to tell it to do that. And to tell it to do that you had to understand your codebase well enough to know it needed doing. We're here talking about why lights-off wont work i suppose this would also be a good place to ask if you fall in the "high stakes production systems" camp > If you love vibe coding, please, go on vibing. I still vibe code lots of things, I just also maintain lots of production software (and through HumanLayer, help 1000s of other engineers do the same), so the rest of this is aimed at folks solving hard problems in complex codebases.
dmurvihill 3mo ago
Wow, good to know. Can you tell me what company you work for so I can make sure it's not part of my stack?
- satvikpendem 3mo ago
  It's many if not most companies now doing automated PR review.
  - 20k 3mo ago
    Asserted confidently without a shred of proof
latentsea 3mo ago
Entropy is not your friend.
majormajor 3mo ago
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code). Ok, sure, if your software can be easily exhaustively re-tested on every change. But in that case, why were you ever doing PR's in the first place? Cargo cult?
NateEag 3mo ago
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. "Program testing can be used to show the presence of bugs, but never to show their absence!" -- Edsger W. Dijkstra
- RamblingCTO 3mo ago
  And it doesn't take into account maintainability, complexity, security etc. I think the commentator above you is not a SWE. No one could be that ignorant

by 4lx87 3mo ago

tripleee 3mo ago

What's your job as an "engineer" in this post-automated world? QA?

4lx87 3mo ago
Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
- necovek 3mo ago
  Before LLMs, "organizations" have seen code review as multiple things: * Share knowledge about a particular area of the codebase between multiple people * Share overall engineering knowledge between the parties in the review * Ensure maintainability of the codebase long-term * Ensure readability of the code * Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change) * Ensure changes are small, self-contained, and as often as possible, reversible * Do some basic manual QA * Do comprehensive integration testing with a fully built-out system ... * And yes, catch bugs before they hit production. A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced. Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).
roncesvalles 3mo ago
The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones. Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself. A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
- jdzikowski 3mo ago
  > The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones. Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.

20k 3mo ago

>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile. This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant The reason for human code review is: 1. So *you* understand what's going on, not the LLM, and people can ask you questions about it 2. Because LLMs are not that good at code review It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?

dhorthy 3mo ago
blake smith has a really good post on this - that mental alignment among the team is the primary purpose of code review - https://blakesmith.me/2015/02/09/code-review-essentials-for-software-teams.html https://blakesmith.me/2015/02/09/code-review-essentials-for-...
- 4lx87 3mo ago
  That is a good post. Thank you for sharing. I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses). It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.
  - DaiPlusPlus 3mo ago
    > In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. Nope. To reduce it down to a single word, I'd say we do code-reviews to assess "taste". ----- Code-review is one part of a larger process (the SDLC!), and while review does help with "finding bugs" it is not the singular reason why we do it; and other parts of the SDLC are concerned with finding bugs in the first place, namely the various Test and QA steps in the process; when your code is in the (peer) code-review step then there's an expectation that the author already identified and resolved actual bugs/defects (i.e. where actual-program-behaviour deviates from the spec[1]), so a PR for new functionality is expected to include unit and integration tests to demonstrate that. Now Claude will gladly take a Jira ticket, write-up a plan/spec, write tests, implement the feature, verify the tests pass, address static-analysis issues, push branch, and submit the PR - and if-the-program-works then it's "correct" and so surely there's nothing really to review and so merging the changes should be a breeze... but I find myself rejecting these PRs all the time because these agents still "just don't get it"[2]. (But I'm sure they'll "get it" eventually; you can't stop progress). We can revisit this topic when we get there; but for now I'm going to reject an AI-authored PR that eschews it. Good taste is important. [1] I'm not going to pretend anyone actually writes any kind of spec (informal or otherwise) for the vast majority of software out there; but an unwritten-spec exists when you mentally combine a vague Jira ticket, platform-conventions and common-sense (and that's how Claude in an Agentic Loop works too, except it always has to write-out the Spec.md/Plan.md to disk first, whereas us humans keep things in our head). [2] I cannot define "it".

layer8 3mo ago

> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. You’re arguing for experiment over logical proof or reasoning. That’s qualitatively a very different thing, and the former is no adequate replacement for the latter.

gabrieledarrigo 3mo ago

> Code (and specs) are going to fade into obscurity I'm always skeptical when I read absolute statements like this. Especially about specs. They drive and document how the software should work, behave, and under which conditions. In the same moment you write a prompt in natural language, you are writing a spec. Why should they disappear? For the same reasoning, we could no longer need books or manuals or documents (is it valuable to keep around that doc about F-22 specs?).

abernard1 3mo ago
Agreed. Specs are more important than ever. Constraints: types, contracts, protocols, schemas, APIs and such are what ground the boundaries of systems. Without them, code drift is a guarantee. Does anyone trust that a set of human sentences typed into a box is more reliable and precise than objectively exact descriptions of data? This is not to diminish the utility of these code factories. But surely, if anything provides resistance to drift, it's codebase consistency, standards, and things which must objectively be true for the software to function.

jeremyjh 3mo ago

This entire article is about the fact that the codebase deteriorates over time when you work this way. If they are correct, it will take longer and longer to develop PRs, and more and more cycles to QA them. Eventually the code will be unsalvageable and it might get there before anyone notices a problem. I don’t know if they are right but I know codebases can get there with humans at the helm - and the humans can adapt and learn. This is not a certain fate but it sure looks likely and is a serious risk. Some software is so low stakes that you can get away with it I’m sure - there are always trade offs.

satvikpendem 3mo ago
The bet is that models get better faster than code gets worse. Looks like so far it's correct, as Fable can already write better code than me and most others on average.
- dhorthy 3mo ago
  the thesis of the post is that this is not true. fable can solve more problems but for complex systems it is not sufficiently diligent that you can turn the lights off.
  - satvikpendem 3mo ago
    They turned the lights off in 2025. The post is simply not accurate to today, they even say so, stating that apparently no one has proof of better models in 2026 improving codebases over time. I've seen it happen but the author hasn't apparently, so it's a game of "you said I said", not anything concrete.
    - dhorthy 3mo ago
      (op here btw) - the question isn't "can models make code better" - its "left fully unattended, will they turn your codebase to slop over time" from the footnotes (sorry if this got a little buried) > yes of course you can get gpt-5.5 xhigh to do BRILLIANT refactors. But you had to tell it to do that. And to tell it to do that you had to understand your codebase well enough to know it needed doing. We're here talking about why lights-off wont work i suppose this would also be a good place to ask if you fall in the "high stakes production systems" camp > If you love vibe coding, please, go on vibing. I still vibe code lots of things, I just also maintain lots of production software (and through HumanLayer, help 1000s of other engineers do the same), so the rest of this is aimed at folks solving hard problems in complex codebases.

dmurvihill 3mo ago

Wow, good to know. Can you tell me what company you work for so I can make sure it's not part of my stack?

satvikpendem 3mo ago
It's many if not most companies now doing automated PR review.
- 20k 3mo ago
  Asserted confidently without a shred of proof

latentsea 3mo ago

Entropy is not your friend.

majormajor 3mo ago

> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code). Ok, sure, if your software can be easily exhaustively re-tested on every change. But in that case, why were you ever doing PR's in the first place? Cargo cult?

NateEag 3mo ago

> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. "Program testing can be used to show the presence of bugs, but never to show their absence!" -- Edsger W. Dijkstra

RamblingCTO 3mo ago
And it doesn't take into account maintainability, complexity, security etc. I think the commentator above you is not a SWE. No one could be that ignorant