Last night I read an article that Kent Beck had shared about AI marking the end of code reviews. Mere hours before I read this, apparently Amazon was telling all developers that “Junior and mid-level engineers will now require more senior engineers to sign off any AI-assisted changes”*

Code Review (as a quality mechanism) was dead well WELL before AI. The best team I ever worked on was doing Trunk Based Development (commits straight to trunk with no review) in the 20-preteens, and we didn’t go down. What we had, though, was a robust set of automated guardrails** that prevented bad code from going to production. On my first day with that team I was writing code that was set to go into prod as soon as I committed it! (it didn’t, because I failed the linting step of the pipeline, but my second commit did…)

When I read that article about the death of code reviews, I was forming an opinion that the revelation wasn’t the important part, but that the bringing people along was. That’s doubly true now.

Code Review Mandates, especially “you must be this tall to review” type mandates, cost [management] nothing to implement, and all of their actual costs are hidden. They push people into all sorts of other anti-patterns:

• “Get someone else to review first” (1 review takes ~1 hr, 2 reviews take ~1 day)

• “Here’s my dedicated daily time for review, I will not review outside these hours” (again ~1 day lead time)

• Junior devs putting more into their PRs to “save review time” (larger changes introduce more risk into the system)

• Junior devs learning helplessness because the senior always “fixes” it in review (no shared ownership over the codebase)

The problem we still face, even in the age of AI, is that good modern Software Engineering practices intentionally make the costs visible. To trust your code, you need to build pipelines with guardrails**, which are the only path to production. You need to exercise those pipelines. You need to bake your system’s designs and opinions into code, so the pipeline can fail when they are violated. Even today, we cannot snap our fingers and have it all in place (if only because we must still make the decisions about the tradeoffs on each piece). Building this foundation requires a bit of lead time, and therefore leadership who will allow for that time.

The frustrating part about this is that when a market leader makes such a declaration, people listen. And I very much doubt that there will be as much public coverage when (not if, when) this mandate causes many more problems in the months to come.

I still agree with the first article, that LLMs are yet another nail in the coffin of Code Reviews, but I believe that particular ghost will continue to haunt us for decades to come, unfortunately.

• You should read that statement as “more senior engineers are required to sign off on ALL changes” because 1. we don’t have the tooling to tell if the change was “AI-assisted” or not. 2. What code is not “AI-assisted” these days anyway? and 3. Convincing someone not to review something is a review of its own.

** Guardrails is currently undergoing semantic drift where it might mean “extra suggestions you give to the AI” these days. When I say guardrails, you should hear: “pipeline steps that that must pass to allow further progress to production”