Thread

1. metalspot · 1790563007 · focus · HN ↗

   The true reason why code review is universal is that it provides a liability shield for negligence. Negligence is interesting. It has nothing to do with whether or not you ship something broken. As long as you follow a process that attempts to not ship something broken, then you are not negligent.

   Engineers played along with this farce because code review served valuable team collaboration, coordination and management functions, about which the author of the article is correct.

   Understanding a system by reading code is harder than understanding a system by writing code.

   If AI can generate code at 100X, 1000X, or 10000X human capacity (no ceiling here), and you are gated on code review as your mechanism for system understanding, then a team's productive output will barely increase.

   If companies want to compete in the world of AI generated code, human code review has to go. The only question is, what replaces it?

   Continuing to apply human code review to AI generated code is negligent, if you are shipping at AI generation speed, with that as your only gate, and no other systems and processes to validate correctness and limit risk.

   On the engineering side we can adapt easily.

   Code review was never about finding bugs. When we do code review the first thing we check is: "do the tests pass?" Then we look at the change and the test coverage added for it and ask: "does the test coverage adequately demonstrate the functionality of the code?" The we ask: "What is the scope and potential impact of this change?" "What is the deployment and rollback plan and how will we monitor and detect defects after deployment?"

   Code review was never about the code. It made the lawyers happy and provided a vehicle for doing the things that actually make systems work.

   1. jillesvangurp · 1790586199 · focus · HN ↗

      People forget that pull requests and doing code reviews in the context of those is still a fairly recent thing. People did some code reviews before that of course but nowhere near as strictly. Same with testing practices, static code analysis, etc. Most of that wasn't all that common until beginning of this century. I remember using findbugs with Java around 2004. It actually found bugs in my code the first time I used it. No review had caught those. And we got lucky not finding them in production. But they were definitely bugs. Our system didn't have unit tests; it was all manual. Junit was a fairly recent system that hadn't been around for that long yet. Our build was done with Ant. There was no test phase. Our tech lead would of course check my work and correct & educate me (I learned a lot). But a lot of bugs slipped through as well.

      Git did not exist either, I migrated out cvs to a beta release of Subversion. We only used branches for releases. We'd cut a branch just before a release. Test it (manually) and then ship. That was a process I helped put in place actually. After release, master would diverge quickly so back porting fixes was not really a thing. We'd support releases for as long as our customers used them. Often that involved just upgrading them to the recent version. We shipped when things were good enough.

      I think the notion of people reviewing any meaningful amount of generated code is simply delusional. As you say, we do need alternative means to replace those checks. And a lot of that is going to be AI driven as well. AI driven testing, code reviews, and all the rest. Essentially all the stuff we used to do manually (poorly).

      And we do have an important new tool as well: clean room code replacement. That used to be prohibitively expensive but now it's not. If you have something that is well specified through documentation, APIs, specifications, tests, etc. replacing it is fairly straightforward now. There are some early examples of people using LLMs to generate functioning replacements for things like Postgresql, browsers, compilers and similarly large and complex systems. While not perfect, these things seem to work, pass their tests, and generally not be completely horrible. It's only going to get better from here.

      The notion that people are going to ever manually review code that was generated for such systems in mere hours/days is beyond imagination. How? When? Who? Why? It simply does not scale. It's only going to be more and more code. The amount of code no person will have ever looked at will soon dwarf the amount of code that is still manually inspected/created pretty rapidly.

Unofficial Hacker News client; not affiliated with Y Combinator.