The bottleneck theory of approaching a software singularity

For years software development was constrained by one dominant bottleneck: writing code. Everything else arranged itself around that constraint, because that is where the hours went. As AI systems improve, that bottleneck is disappearing.

So the interesting question is no longer whether AI can write code. It is what becomes the next bottleneck, and the one after that.

If every bottleneck can eventually be automated or reduced, software production stops being a fixed-capacity activity and becomes a system that improves itself. That is what I mean by approaching a software singularity. Not the technological singularity, and no claim about machine consciousness — just the point where software production begins accelerating itself.

Two things about that loop matter more than the size of any single jump. Each plateau arrived faster than the one before it, and each one became the new normal instead of a temporary burst.

What we could see from the outside was more features delivered, substantially fewer defects, much shorter iteration cycles, and drastically less frustration.

That last one is not a mood. Frustration is where cognitive friction shows up in a person, and a sharp drop usually means the system stopped asking humans to hold things it should have been holding itself.

Here is the strongest objection, and it is a good one. A productivity spike is not evidence of exponential growth. It may just be accumulated friction finally disappearing — years of technical debt, bad tooling and manual steps clearing out at once. Removing debt produces the appearance of acceleration without changing the long-term curve at all.

That criticism is valid, and it is the one I keep coming back to. It means the honest question is not how much faster things got. It is which of the two things happened: am I removing friction, or am I increasing leverage?

The platform crossed an architectural threshold, and the difference is not that the AI got better. It is that the AI stopped writing arbitrary code.

Agents here do not invent implementations. They assemble systems out of formal components that already exist, already have types, already have tests, and already encode the rules the platform enforces. When something genuinely new is needed, producing it is a separate governed act, not something that happens by accident in the middle of a feature.

That changes what is being scaled. Instead of scaling code generation, the platform scales composition.

There is a neutral representation in the middle of the process, and it is the part doing the work. Discovery produces a blueprint. The blueprint drives agent orchestration. The agents assemble formal components. The components run as a system.

The blueprint holds intent, not implementation. It says what should exist and what it has to do, in terms a customer can argue with. Everything downstream of it is translation, and translation is the part that can be automated without anyone losing control of the outcome.

The implementation stays constrained by building blocks the platform already validated. An agent cannot invent a new architecture in the middle of a Tuesday feature request, because there is nothing for it to invent with.

Traditional code generation produces entropy, and it does it quietly. Different developers solve identical problems differently. Different agent runs solve identical problems differently, which is worse, because there are more of them and they are faster. The system fragments a little with every delivery until nobody can say how anything works.

In a component architecture that cannot happen by accident. Agents assemble validated pieces, so every generated system inherits the same architecture as the last one. The complexity does not vanish — it moves out of implementation and into component design, where there is far less of it and where it is somebody's actual job.

Once implementation is automated, component creation becomes the obvious constraint. That is the honest consequence of the previous section: the complexity moved, it did not disappear.

Component production can be industrialised too, and the process is unremarkable — a formal specification, a guided AI implementation, automated verification, automated tests, an architectural review, then publication into the library. Every step except the review is already machine work.

What changes is what the senior people do with their day. They stop writing every feature and start governing the architecture: deciding what a component is allowed to be, and refusing the ones that should not exist.

The standard criticism of any component library is that it collapses under its own weight. Duplicates appear. Slight variations accumulate. Two things do almost the same job, nobody can tell which one to reach for, and the library becomes a museum with a search box.

That risk is real and I have watched it happen in codebases with far fewer moving parts than this one. The bet is that governance can be continuous instead of occasional: agents inspecting the library for duplicates, overlapping responsibilities, obsolete components and architectural inconsistencies, on a schedule rather than in a cleanup project.

A cleanup project competes with feature work for attention, which is why it always loses. Continuous governance competes with nothing. It either runs, or the claim in this section is wrong.

The same shift applies to refactoring, which used to be the most expensive maintenance we had. Agents do it now: horizontal sweeps across a pattern, vertical work down one stack, dependency cleanup, consistency passes.

Every change triggers the same cycle — automated verification, end-to-end tests, automatic repair when they fail, redeployment, another verification pass. Refactoring stops being an initiative somebody has to argue for and becomes part of the production system.

That holds exactly as long as verification is genuinely automatic. Change a thousand call sites with nothing but a test suite between you and production, and the test suite is now the thing the whole approach rests on.

Push this far enough and implementation stops being the hard part. Understanding what should be built takes its place, and it does not respond to the same treatment.

Customers rarely know exactly what they want. Their ideas change the moment they see working software, which is the correct reaction to seeing working software and not a defect in the customer.

So discovery cannot be a phase that ends before building starts. It becomes a loop: discovery, blueprint, generated system, customer feedback, updated blueprint, updated system. That loop is only worth running because iteration became almost free — when a change costs a morning instead of a sprint, showing somebody the wrong thing is a cheap way to find out what the right thing was.

There is a harder version of this that took me longer to see. The difficult part is not extracting requirements from a customer who already knows what they want. Very often the intent does not exist yet.

It gets produced by the conversation. Somebody describes their business, sees a consequence they had not considered, changes their mind, and now there is an intent that was in nobody's head twenty minutes earlier.

AI can facilitate that conversation, and it is already good at it. It cannot remove it. As long as humans decide what should exist, discovery stays human-centred.

The obvious objection is that a process requiring humans is not a scalable process. That objection is wrong, and it is worth being precise about why.

SaaS requires humans too. Every customer clicks buttons, configures things, makes decisions and asks support questions. Nobody looks at that and concludes SaaS cannot scale. The presence of human interaction is not the limiting factor.

The metric that decides it is supplier effort per delivered outcome. If discovery effort stays roughly constant per customer while implementation cost trends toward zero, the economics keep improving no matter how many people are in the conversation.

The claim that there is no limit here is not evidence. It is an intuition, and intuitions about exponential curves have an unimpressive track record. The useful question is what would falsify it.

So this is the list I actually watch. If any of these turn out to be true, the argument in this article is wrong, and I would rather find that out early than defend it.

None of those are exotic failure modes. Most of them would first show up as something small and easy to explain away: one more new component than expected, one governance pass that found nothing because it was looking in the wrong place, one customer whose discovery took three times as long as the last one.

If none of them happen across years of operation and a growing number of customers, confidence in the architecture should go up. Not before.

Singularity is a dramatic word and it implies infinite acceleration, which is probably not what is happening. The more precise description is a self-accelerating software production system: one that keeps removing its own bottlenecks, where each improvement raises the rate at which the next improvement can be made.

The acceleration comes from leverage rather than effort. You can tell those apart by asking what happens when you stop pushing.

Every mature production system has a bottleneck. Improving the system means moving that bottleneck somewhere else. None of that is new — it is how manufacturing has worked for a century.

What is new is that moving the bottleneck is itself becoming automated. Once that happens, improvement compounds instead of arriving in projects.

Not that software writes itself. Not that AI replaces engineers. Engineering becomes the design of systems that improve themselves, and that is a different job than writing code faster.