AI code isn't the problem. How you run it is.

The problem usually isn't the model. Directing a large, fast team of agents is a management and process skill, and in my experience, most of the complaints about AI-generated code are really complaints about work that was never managed.

I've been in software for over 30 years. The teams I see getting good results from AI are doing what good engineering organisations have always done: setting standards, giving context, measuring output and reviewing where the risk is. The teams calling it rubbish are often judging a new kind of team by an old way of working.

Bad code is older than AI

People write rubbish code. They always have. I've reviewed plenty of it, and I've written some of it. Bad code predates AI by decades, so a model producing some is no surprise. The useful question is what was missing around it: the context, the standards and the checks.

We built these models in our own image

Language models look and behave a lot like a person. HR people, look away for this bit. A person is a function that takes a need and turns it into code. An LLM is a function that takes a need and turns it into code. So think about how you would manage a person on an engineering team. You wouldn't sit a new graduate at a desk with no context, no standards and no idea what the system does, then complain when their first pull request is a mess. The bigger the team, the more important the guidelines become.

Plenty of teams are doing exactly that with AI. They skip the onboarding they would never skip for a new grad. If that's what happened, the problem was never the model.

The edge is judgment

These models were trained on almost every corner of software, systems and engineering management. They already understand far more than you'd expect from a junior. On common, well-documented ground, they often know more than a very senior engineer does.

So the comparison isn't model versus senior developer. It's a model plus a human who directs it, versus a human working alone. The senior's remaining edge is judgment: what to build, what to skip, and what the organisation actually needs.

Speed changes the problem

Models write code faster than any person can. The real problem is quantity. You now get vastly more code in a much shorter time. If you intend to hand-review every line the way we used to, you generate faster but still review at the old speed, and that bottlenecks everything. Review has to change. It shifts from reading every line to sampling, trusting automated gates, and diving deep only where the risk is high.

Quality was always partly a machine job

Quality has always been partly a function of tools. Linters, cyclomatic complexity measures and coding standard checks exist because relying on a person alone for those things never made sense. You want output that is statistical, verifiable and machine-checkable.

A language model can read that output and act on it, exactly the way a CI pipeline does. The quality toolchain was already half machine. The model is just another consumer of it.

Eight lines a day, eight lines a second

You can have a person review every generated line. Nothing stops you. It will just slow everything down a great deal.

Around 1994, on a large, complex defence system, the metric we used to turn size into effort was eight source lines of code per day. That was delivered code, including the full review cycle, not code typed. That metric is long dead and buried. With AI, I'd put it at eight lines a second or more, per agent, and you can run hundreds of agents at once. That's generation, not delivered code, but even after review the gap is enormous. By my rough maths, eight a day to eight a second is about four orders of magnitude, and with hundreds of agents it's six or more. No review culture built for the old number survives it intact. The question stops being "can we review it all?" and becomes "which parts actually deserve eyes on them?"

Running agents is running a team

Organising a team of agents is like organising a team of people. It's a complex problem. You need guidelines, acceptance criteria, quality checks, automated tools, quality reviewers, and a framework that lets a bigger team execute at speed.

There's an old rule here: if you don't trust your people, you lean on process. With agents, you need more process and better-calibrated trust, not one instead of the other.

The CMM question

In the 1990s, CMM level 5 was the holy grail of engineering process. The Capability Maturity Model (CMM) described organisations moving from unmanaged and uncontrolled, through measured, up to level 5, where you act on measurement proactively and the process becomes predictable. Underneath the levels is a closed loop: plan, do, check, act. You measure, act on the measurement, and measure again.

Total quality management (TQM), Lean and Six Sigma share the same backbone. Each defines what good looks like and builds feedback into the work itself, so problems surface in the work, not when someone happens to notice.

Motorola's Bangalore centre and a handful of others got there, but very few software organisations did. A big part of the reason was cost. Running that loop properly took people, measurement and process overhead most teams couldn't justify.

AI lets the loop run continuously, at machine speed, instead of waiting for periodic reviews. In factory terms, you're automating quality control, the checks that catch faults and feed corrections back, not just the production line.

I think a good manager can now run something close to a level 5 organisation with a small team. I haven't measured that, and a real level 5 rating still needs an independent appraisal. But the expensive part was never the judgment. Someone still sets the goals, picks the measures and acts when the numbers are uncomfortable. The expensive part was the measuring, and that cost has mostly gone. If I'm wrong, we'll see it soon enough in teams that automate every metric and still can't predict when they'll deliver.

So people don't disappear from this picture. Management skill becomes far more valuable, because one person's choices now steer a much larger and faster system.

Who this actually threatens

If you're a software engineer who isn't used to managing people, isn't used to managing thousands of lines of code, and doesn't review or understand architecturally what matters and where the risk sits, AI is going to be hard on you. If management, project, product and systems engineering, built on strong software skills, isn't your skill set, a model will outpace you.

The engineers who come through this are the ones who already knew what good looked like before the machine showed up.

Some of the frustration comes from teams that never leaned on automated quality checks for their own code either. AI didn't create that gap. It just made it visible faster.

The expectation hasn't caught up

There's also a trust problem. We trusted compilers because they were deterministic and boring. Same input, same output, every time. A language model is stochastic and sometimes surprising, and that's exactly what review, testing and automated gates are for. The standard moved, but nobody updated the expectation.

Torvalds has seen this before

Linus Torvalds has maintained one of the largest, fastest-moving codebases in the world for over three decades, and he's lived through this kind of shift. At the 2026 Open Source Summit North America, he said that when people claim 99% of their code was written by AI, "I pretty much guarantee that 100% of their code is written by compilers, but they never say that." He grew up writing machine code, "the numbers", and said: "I figured out compilers were good, and these days I'm figuring out that AI tools are good, too."

He also put it in proportion: "You will all use, well, not maybe all of you, but a lot of people will use AI to generate the code that the compilers use to generate the code that the assemblers then use to generate the machine code." And he still reads the assembly that comes out the other end, because on anything maintained long term "you need to understand not just your prompts, but you need to understand your end result".

Each step on the way handed more of the typing to tools. Machine code gave way to assemblers, then compilers. Then editors learned to understand code as you wrote it, through language servers and autocomplete that finishes the line for you. Agents are the next step on that same path.

If you think this is a fad, look at who is saying it. Torvalds is famously hard to impress, and he has spent decades rejecting code that isn't good enough. He went from writing machine code by hand to trusting compilers, and he now puts AI tools in the same line. Nobody today argues that compilers were a fad.

The tool changed. Understanding the result, and running the work properly, is still our job.

Source: Dirk and Linus discuss AI and kernel development, LWN.net, 25 May 2026