Agentic coding shines at app scale. At 500 million lines of code, correctness compounds against you and the math is unforgiving.
We are in a strange moment: at the same time a first wave of disillusionment and a fresh wave of hype about what LLMs with agentic coding can achieve. In one and the same news cycle we read that Claude Fable 5 sets new records on coding benchmarks and Stripe reports it completed a migration in their 50-million-line codebase in a day, work estimated at more than two months for a full team and that “vibe coding” will take over software development. And we read that Ford rehired 350 veteran “gray beard” engineers after its AI-driven quality systems failed to deliver the expected quality.
Both stories are true. They just describe opposite ends of a spectrum. To understand what is really going on, we have to differentiate between categories of software.
1. Not All Software Is the Same
At one end of the spectrum is the app world: mobile apps, IoT devices, small tools — typically a few thousand lines of code (LoC), sometimes up to 100,000.
At the other end is truly complex software. When I became Chief Architect for SAP ERP and the SAP Business Suite in the mid-2000s, the codebase had about 400 million lines of code. When I handed the role over, it was 700 million. And that is not counting the 40,000 database tables used to configure the software for more than 20 industries and company types or the monthly stream of legal changes that must be implemented and delivered to thousands of customers.
For readers who do not think in lines of code, here is a comparison: the app domain is like organizing a big event for example a birthday party. Many topics, many constraints: location, program, travel, guests. The complex-software domain is like organizing a country of 100 million people: housing, traffic, food supply, a legal system, government. That is not something a single person can think through at all levels.
AI agentic coding is already very good in the app domain. The question is: how far can it get into the other category?
2. The Math Is Not on Our Side
Let me illustrate the problem with a deliberately simplified statistical argument.
Assume we could decompose a complex system into fully independent modules of 100,000 LoC each (app-sized pieces). Assume further that AI coding gets each module 99.9% right. That is already heroic: in practice, it is extremely hard to get even the requirements 95% right.
In this simplified extreme, correctness multiplies:
Correctness of the complex system = (correctness per module) ^number of modules
- 1,000 modules at 99.9% each: ≈ 37%
- 5,000 modules at 99.9% each: ≈ 0.7% — less than 1%
An ERP system with 500 million LoC, decomposed into 100,000-LoC modules, gives you 5,000 modules. So even with a perfect decomposition, perfectly described requirements, perfectly specified interfaces and 99.9% correctness per module the probability that the whole system is correct is below 1%.
Turn the question around and it gets even more sobering: to have just a 95% chance of a correct system at that scale, every single module would need to be 99.999% correct.
(This illustration follows a talk by Bertrand Meyer, based on a remark by Edsger Dijkstra in “Structured Programming”, 1970.)
3. The Trust Gap: We Still Read the Code
There is a useful historical benchmark for trust in generated code: the compiler.
When you develop in a high-level language like Python, you almost never look at the generated machine code, the intermediate code, or the byte code running in the processor. We trust compilers and interpreters so completely that we only look underneath in very rare cases like strange errors close to the hardware.
With AI-generated code, most developers still want to read the output. That tells you exactly where we stand: nowhere near compiler-level trust. And until we get there, a human remains in the loop and does reading, judging, and takes responsibility.
4. More Agents Was Never the Answer (Neither Were More Developers)
The practical path today is looping, specialized agents: a single developer orchestrating fewer than 15 agents that generate, test, review, and repair code. That works, and it will get better.
Now compare this setup with a 10,000-person development organization full of specialized roles. The interesting point is not that such an organization could never be “rebuilt” with 10,000 specialized AI development agents, each itself consisting of a few looping agents. Technically, instantiating 100,000 agents is not the bottleneck.
The point is that the software and the organization co-evolved over decades: starting from a smaller organization building a less complex product. You can watch this fail in the human world: whenever a large company simply puts thousands of developers together in a new organization, the expected output does not materialize for many years. It was never a headcount problem. And it will not be an agent-count problem either.
5. Rebuilding Is Not Building
Will a system of AIs one day develop something like an ERP? Yes, maybe. There is a vast amount of documentation and institutional knowledge about what an ERP system does. Re-doing a known system is far less difficult today than it was to invent it in the first place in the 1970s.
This, by the way, is why the most spectacular AI coding results so far are migrations and rebuilds: the Stripe example above is a migration: the target is fully specified by what already exists. Building a complex system that has never existed before, where the requirements themselves must first be discovered, is a totally different task.
6. Hockey Stick or Plateau?
Looking back at 60 years of AI, the pattern repeats: a breakthrough occurs: expert systems, computational intelligence, the machine learning renaissance, deep learning followed by a hockey-stick forecast promising that everything will be solved within a few years. And each time, the hockey stick turned into a plateau.
The current wave will certainly progress beyond apps with a few thousand lines of code; it may become reliable enough for considerably more complex systems. But the key question remains:
Will the current approach plateau before we have solved the organization and training of 100,000 agents working together on one complex software system?
Final Thoughts
The limiting factor is not the intelligence of the individual coding agent. It is that correctness compounds multiplicatively across thousands of interdependent modules and that large software and the organizations that build it grow together over decades. AI will replace a lot of coding long before it replaces software engineering at enterprise scale.
I would be interested in your view: where will the plateau hit this time? Feel free to connect or reach out; especially if you are wrestling with the quality and security of AI-generated code in large or regulated systems.