I’m reading “Incorruptible” by Eric Ries. It’s a really interesting book. One early takeaway is that investors are attracted to companies that lay off staff. It’s strange and kind of basic, but layoffs increase a company’s stock price.

This same logic seems to be driving AI adoption. AI means layoffs, means stock price increase. Yawn.

Look at where we are in software development. The world has gone somewhat crazy. Developers are feverishly handing over their livelihoods to vendor AI companies. Those same companies attract investment and business by promising to replace developers. Their expenditure dwarfs their income. This is compounded by a revenue model built on free-tier experimentation, while enterprise adoption lags behind the hype.

This has led companies worldwide to figuratively set their development culture on fire. Teams are being encouraged to let AI write the code, with humans reviewing it. This makes the review the bottleneck. So what’s the industry’s answer? Stop reviewing the code, of course. Industry luminaries such as Uncle Bob Martin and Vendor evangelists alike are spouting this advice.

Developers themselves are struggling to figure out where they fit. Many are desperate to signal compliance with the AI mandate and not be left behind. Some are dogmatically pushing back. Others are just happy AI will write the tests for them.

Meanwhile, students don’t know whether it’s even worth studying computer science, let alone pursuing it as a career, and so the career pipeline is broken.

The industry has failed at the one thing it believes it does well: solving problems. We’ve been optimising the wrong constraint.

The old problem

Let’s play “what if” for a moment. Think back to before LLMs entered the mainstream of software development. Developers would typically code a solution and raise a pull request. Another team member or two would stop what they were doing to review the PR. There might be feedback, a discussion, or a disagreement or two. There could be rework and re-reviews. All of this disrupts the team and the flow of work, but we managed it. Then someone else would finish their work, raise another PR, and cause more disruption.

It’s worth saying, this workflow didn’t work well. It wasn’t pleasant or fast. The usual approach to slow projects was to add more people. Obviously, though, look at the workflow. The bigger the team, the bigger the disruption. Something had to change.

Enter AI. Imagine if the first AI product pushed into software development wasn’t code generation, but code review. For a moment, think about what effect it would have had on the workflow described above. Imagine what it would’ve been like working on a team where the reviews were automated.

I’d argue our industry would be hands-down healthier, more productive, and more creative now with this alternative timeline.

There’s no way back

We can’t go back to the way things were, but honestly, would you even want to? It simply wasn’t working, but unfortunately I can’t say it’s working now either.

Vendor AI is a cul-de-sac for so many companies, and yet they’re all trying to crowbar it into their culture. Many companies aren’t comfortable sharing their data with vendor AI companies, let alone having commercial models trained on it.

Vendor AI companies still haven’t charged their paying subscribers the actual cost of using their models, so today’s prices are the lowest we can reasonably expect.

Regulated industries will almost certainly be blocked from using 100% AI-generated code in production, no matter who reviews it. New attack vectors, such as “slop-squatting”, mean we can’t simply dismiss code as an artefact.

And let’s not forget sovereignty. Today’s world is very splintered. Access to AI can be switched off seemingly at will. We saw this earlier this year with Mythos.

No, we can’t rely on Vendor AI in today’s world.

Accountability

To do that, we need to play to the strengths of humans and AI alike. And play against the weaknesses.

AI is excellent at reviewing code. It doesn’t suffer from attention decay or cognitive fatigue, no matter how many files are in the pull request. It doesn’t have the context-switching penalties either. It can keep the author honest by comparing the implementation to the spec and/or the tests. It can review the tests, evaluate any coverage holes, and even tell you whether there are too many tests.

By contrast, humans are predictable bottlenecks. They get bored, get tired, struggle to switch context, and the sheer volume of diffs and PRs predictably degrades review quality.

They can both write code. For the sake of discussion, assume the code is rigorous and high quality. Let’s say they both produce excellent code 99% of the time. AI is faster, and let’s assume it’s also cheaper. The issue isn’t the speed, it’s the 1%.

In software, that 1% isn’t just syntax errors. It’s specification misunderstandings, edge cases, architectural drift, and subtle logic flaws that only surface in production. It’s not simply that the 1% exists, it’s whether the human can reliably verify it. When AI generates the code, that verification becomes a guess.

The problem isn’t authorship but ownership. Accountability for who wrote the code, and potentially for any bugs, is key. Who understands the code? Who will maintain it? Who will take responsibility for it? These are difficult questions to expect a human to answer if an AI wrote the code. It’s a gamble. The company is betting that AI did a good enough job.

And let’s be honest. If a human approves a PR another human wrote and a bug gets pushed to production, the author is on the hook for that bug. If the author is AI, the human reviewer is on the hook. If both the author and the reviewer are AI, a human is still expected to take full accountability for the work. Not credit. Accountability.

And yet this is the best we have. “Human in the loop”. It’s a thankless, joyless workaround role. If this is your role, I empathise. This isn’t the evolution of a software engineer’s role. It’s just a compliance task that requires an engineer’s sign-off. In reality, the human isn’t genuinely in the loop to understand what the AI has done. They’re only there to absorb liability.

The company gets the speed, the Vendor gets the tokens, and the human pays the price. Not credit, just accountability.

This system cannot lead to success.

Let me offer another way

As I detailed in Artisans, Painters & Decorators, this isn’t simply about preference. Rather, it’s about preventing the developer from becoming a redundant middleman in a waterfall process.

Peter Naur wrote a 1985 paper called “Programming as Theory Building”. The gist of this is that the output of programming isn’t simply code, but understanding. We build our knowledge of a domain by exploring solutions through code. It’s actually a benefit that this takes time. That is why authorship matters.

So it’s important that the human writes the code.

As I stated earlier, I’m very much in favour of the AI reviewing the code. Pull requests are disruptive and annoying. They ruin the “flow” of writing code, and they can destroy a team’s productivity. And they don’t scale well. Add more people, and productivity gets worse, not better.

AI can hold a developer to their own standards (or the team’s). We’re not limited to having a non-deterministic machine review the code. We can use deterministic commands to ensure standards like code coverage, formatting, and linting meet our requirements.

The AI can evaluate whether the test cases are logical and whether the code is well-documented. It can ensure the PR stays on topic for the spec it addresses.

And this isn’t just about review, it’s about control. We can use Decision models to decide whether to merge a PR or deploy a release. These models act as deterministic gates based on criteria under our control. Code coverage thresholds, linting rules, spec adherence, etc. If the checks aren’t good enough, we can improve them. If they’re too strict, we can refine them.

If a developer writes code using disciplined techniques such as Test-Driven Development, and the AI reviews the code against those tests… where is the problem? This is certainly faster than our old workflow, and it is certainly more pleasant. There is no accountability gap. We are taking full advantage of AI. We aren’t losing knowledge, and we still need developers joining the industry.

And the best part is, you don’t need massive models to achieve this. Local, open-weight models have improved vastly over the years. Today’s local models run very well on relatively modest machines in a build pipeline. Developer machines can also take advantage of them, and plug them into their local development tools. When the AI is local, privacy and data concerns disappear.

This is what “good” looks like, and it scales.

I call this “AI in the loop”, and it’s the workflow that I believe the industry would have arrived at if the technology was offered rather than prescribed.

Should all companies adopt this workflow?

No, I don’t think they should. Not all companies need rigorous engineering practices. It might not matter much if a bug or bugs made it into production. If your product is a simple website, or even a relatively trivial app, you may be fine letting AI handle all the tasks. You don’t need the expense or overhead of hiring an engineering team, and you can enjoy the speed and lower cost. I still believe you’re better off ignoring Vendor AI though. Your use case is simple enough to be solved with local AI, and you don’t risk leaking your data.

Companies that do need rigorous engineering practices, though, should look at this workflow. Regulated industries, companies that pride themselves on a strong engineering culture. They can’t afford to surrender their engineering to AI.

Unfortunately, they’ve spent the last few years setting their engineering culture on fire. Recovering it will be costly, and they’ll face even tougher decisions. They’ve sacrificed a lot of faith, partly because they blindly followed Vendor AI rhetoric. My advice is to just be honest about where you are and where you want to be. This kind of disruption wastes everyone’s time, and a lot of work remains.

We’re still in the medieval era. The Renaissance, where accountability and automation actually align, is yet to come.