Scaling Without Complexity in the Age of AI

In 2024, I wrote Scaling Without Complexity. The argument was simple: most startups do not fail because their infrastructure could not scale. They fail because they did not build something enough people wanted. Kubernetes, microservices, and elaborate cloud architecture often solve imaginary future problems while the actual bottleneck is customer demand.

AI has made that argument more important, not less.

The new temptation is no longer only “we should build infrastructure like Google.” It is “we can build anything.” An agent can turn an idea into working code before a team has properly discussed whether the idea deserves to exist. The implementation cost has collapsed, so the question “should we do this?” gets skipped.

That is the AI engineering trap.

Agents make it cheap to generate software. They do not make software cheap to own. Every feature still creates product surface, support questions, security boundaries, migrations, tests, analytics, documentation, edge cases, and interactions with everything already there. Complexity remains complexity even when a model wrote it in ten minutes.

Cheap Code Makes Judgement More Valuable

Before coding agents, a weak idea at least had to survive the friction of a planning session, an estimate, and an engineer pointing out the consequences. That process could be painfully slow, but the cost forced some prioritisation.

Now a founder can have a thought in the morning and see it working before lunch. That feels like extraordinary leverage—and it is—but speed creates its own distortion. A visible prototype looks like evidence of value even when it only proves that the feature can be built.

“Can we build it?” and “should this become part of the product?” are completely different questions.

Once a feature enters production, users have to understand it. Support has to explain it. Sales has to position it. Engineers and agents have to preserve it while changing adjacent flows. If it creates a new permission, state, background job, preference, or exception, that concept becomes part of the permanent reasoning burden of the system.

This is how vibe coding turns into technical debt. Not because all generated code is bad, but because the ability to produce code outruns the discipline required to reject ideas.

The same problem appears on the customer side. A product that can do everything becomes difficult to explain and difficult to use. Every extra option competes with the action the customer actually came to perform. I previously called this Death by a Thousand Features: products slowly lose their identity through individually reasonable additions.

AI accelerates that failure mode. The cuts are cheaper, so teams can make many more of them.

Agents Do Not Remove the Cost of Complexity

There is an idea that complex systems are less dangerous now because an agent can search the repository, explain the architecture, and repair problems for us. Better tools certainly help, but they do not cancel the underlying cost.

Agents still have limited effective context. They can search large repositories extremely well, but they must decide which files, conventions, and dependencies matter to the current task. In a focused monolith, the path from an interface to a business rule and database write is usually inspectable. In a system spread across many services, queues, event schemas, infrastructure repositories, feature flags, and deployment targets, the agent has to reconstruct more hidden contracts before it can make a safe change.

Complexity also creates more plausible patterns to copy. If a codebase contains three ways to validate input, four background-job conventions, and two half-completed architecture migrations, an agent cannot infer one obvious standard from the code. It may select a locally consistent pattern that makes the global inconsistency worse.

AI therefore increases the value of boring architecture. Consistency gives the agent a narrower search space, fewer competing truths, and a better chance of understanding the consequences of a change.

Put a Value Gate Before the Prompt

The most important AI engineering workflow happens before the agent receives a task.

For every proposed feature or infrastructure change, I want a concrete answer to four questions:

• Which customer problem does this remove?
• What evidence shows that the problem is frequent or expensive?
• What existing behaviour could we simplify or remove instead?
• How will we know that the change created value after release?

AI is excellent for prototyping because it makes experiments fast and inexpensive. That should let us test more ideas, not quietly turn every experiment into a permanent feature. A prototype exists to create evidence; only the ones that solve a real customer problem and demonstrate real value should survive into the product.

If those answers are vague, generating the implementation faster is not progress. It is a way of converting uncertainty into maintenance.

I also separate prototypes from product decisions. An agent can build a disposable experiment to help users react to an idea. That is useful. The dangerous step is silently turning the experiment into production architecture because the code already exists. A successful prototype should return to the value gate before it earns migrations, permissions, monitoring, support, and a permanent place in the interface.

The question after every agent demo should be: “What did we learn?” Not: “How quickly can we merge it?”

AI Does Not Change the Final Question

AI changes the economics of implementation. It does not change the economics of attention.

Customers still have limited time. Teams still have limited focus. Codebases still become harder to reason about as concepts and interactions accumulate. Agents can help us move through that complexity, but they can also produce it at a speed no human team could previously sustain.

The scarce engineering skill is no longer only knowing how to build. It is knowing what not to build, what to remove, and where simplicity creates more value than another feature or service.

We can build almost anything now.

That makes “should we?” the most important technical question in the room.

In the practical companion to this article, How I Keep the Technical Stack Simple in 2026, I explain the small production architecture I use to put this principle into practice.