It hardly seems possible, but according to the calendar I’ve been writing software professionally for 40 years. But until recently, I had never worked anywhere that treated reading every line of code as the first line of defense for quality. At Sun Microsystems (and every other company) we spent maybe an hour a week on code review. Nobody thought that was reckless, because by the time anyone wrote much code, the real scrutiny had already happened: several teams had reviewed the architecture, a team had reviewed the design, and the test plan had been reviewed as carefully as either, since it was the document that defined what “correct” meant. The code got spot-checked. The thinking got inspected.

That process produced Solaris, an operating system that ran banks, telecom networks, and a good part of the early internet. Sun’s architecture review committees examined every significant interface before it shipped, and the same culture gave us Java, NFS, and DTrace, all still influential decades later. None of that came from two people approving each other’s pull requests.

Over the last 15 to 20 years the industry’s attention drifted from the design and test plans to the diff. Agile trimmed the formal architecture and design reviews, and written test plans quietly went extinct at a lot of shops. GitHub made pull requests so cheap and automatic that requiring a review on every change became a checkbox in the repository settings. Compliance frameworks like SOC 2 piled on, because “a second person approved every change” is wonderfully easy to show an auditor. The pull request became the one checkpoint left standing, and it inherited a job it was never built to do. The industry went from automated testing capable of shipping a bullet-proof operating system to a manual, error-prone, human code inspection process.

The research says it isn’t very good at that job. A 2013 Microsoft Research study of code review at Microsoft found that finding defects was the reason developers gave for doing it, but most of the comments they actually wrote were about readability, style, and sharing knowledge. Line-by-line review is a fine way for a team to learn its own codebase. It’s a poor substitute for an architecture review.

Now with AI-driven development there’s far more code, and it arrives faster than anyone can read it. Faros AI, which sells engineering telemetry, tracked about 22,000 developers over two years and compared each organization’s periods of low and high AI adoption. At peak adoption, the median time a pull request sat waiting in review went up 441%. That isn’t a quality process. It’s a queue.

The fix isn’t to read faster. Code is no longer the scarce resource; judgment is, and judgment gets applied upstream, in the architecture, the design, the spec, and the test plan the AI works from. A clear spec produces good code. A vague one produces confident nonsense at remarkable speed.

Now I also use AI to check AI. Every spec, design, plan, and pull request goes through an adversarial review by three models, all from different model families than the one that wrote the work, so they don’t share its blind spots. A model tends to overlook its own family’s mistakes, much like asking an author to proofread their own novel. Three outsiders arguing with each other do much better, and in the benchmarks I’ve seen they find bugs at a far higher rate than human reviewers. (The full workflow and the research behind it are here.)

Engineers still decide which findings are real, settle disagreements between the models, and choose what to change. That’s engineering. Scrolling through a 2,000-line diff is not.

Junior engineers are worried that AI is taking their jobs, but it’s only taking the coding, which was always the part anyone could learn. Engineering as a discipline (deciding what to build, how it fits together, and how to prove it works) is still the limiting skill, and AI teaches it faster than the old path did. When a junior writes a vague spec, the AI’s output shows it within the hour, so the link between spec quality and output quality takes days to learn instead of the years it used to take, back when you had to be senior to write specs at all. That only works if juniors are in the room, so every architecture, design, and test-plan review should include junior, mid-level, and senior engineers.

The industry spent two decades focused on lines of code, and AI just made lines of code nearly free. The discipline that built Solaris is valuable again, and the people who learn it now will be the ones still employed in ten years.