The End of Simplicity

For most of software's history, two forces have kept codebases lean: the cost of building features and the cost of using them. Developer time is expensive. Human attention is finite. These aren't just budget line items — they're invisible architectural forces. When every feature costs weeks of engineering, only the most valuable survive. When every option adds cognitive load, only the most essential get built.

Both constraints are now weakening simultaneously. And I'm not sure the industry — or my own instincts — have caught up.

The Cost Collapse

AI agents are collapsing the cost of software development. What took a team weeks can be prototyped in hours. Features that would never have survived a prioritisation meeting — too niche, too speculative, too low-ROI relative to engineering cost — suddenly become viable when the marginal cost of building them approaches zero.

This changes the economics fundamentally. In the old model, saying "no" to a feature was often a resource decision disguised as a product decision. We didn't build it because we couldn't afford to, and we rationalised that as keeping the product focused. Remove the resource constraint, and you're left with the honest question: should we build this?

I live with this tension daily. I founded sheepCRM, a membership CRM for professional associations, and simplicity has always been central to how we build it. But simplicity exists in tension with the features our customers need — and with whatever we imagine a competitor might offer. We're constantly weighing which features to build, how to build them, and which to leave out. Now imagine a mirror-image competitor with AI agents writing their code. They can say yes to every feature request, every integration, every edge case. What does it mean for us to say no — perhaps in the name of simplicity — while they say yes? In a feature-comparison spreadsheet, the kind procurement teams love, they win every time.

There is an almost gravitational pull toward feature proliferation, and the economic brake that used to resist it has been released. When is it right to stop? Not because you can't afford to build more, but because you shouldn't. That's a harder question than it sounds. Scarcity enforced discipline. Abundance requires it.

Agents as Users

The argument against feature bloat has always been rooted in a human user staring at a screen. Too many options? Confusing. Too many settings? Overwhelming. The best products, we've been taught, are the ones that do less.

This assumes the user is human. Increasingly, they're not.

Steve Yegge's Beads is a striking example that I use every day. Built as a task tracker for AI coding agents, it was 100% vibe coded — created by directing AI through a feverish four-to-five day sprint in October 2025. Yegge's original design target was fewer than 30 commands for "maintainable discoverability." Within three months, Beads had over 100 subcommands, each with multiple sub-subcommands, aliases, and alternate syntaxes. The codebase grew from roughly 15,000 lines of Go to over 200,000. Seventy-four releases in four months. Twenty-nine database schema migrations.

By any traditional measure, this is bloat. One external critic compared it to "470,000 lines of Go versus mkdir .tickets && vim." But Yegge's response is instructive. "The complicated Beads CLI isn't for humans," he wrote. "It's for agents."

His design philosophy follows what he calls "desire paths" — borrowed from landscape architecture, where you pave the trails people actually walk rather than the ones you planned. (I think it was Roger Loader, my senior lecturer at Reading, who first introduced me to this concept.) When agents hallucinated a flag or subcommand that didn't exist, Yegge treated it as a signal and implemented it. The result is a CLI that looks absurdly over-engineered to human eyes but is exactly what its actual users expect to find. Sixteen thousand GitHub stars suggest the approach is working.

This challenges the definition of bloat itself. An agent doesn't experience cognitive overload. It doesn't get confused by a settings screen with 200 toggles. It reads documentation — or source code — and uses exactly what it needs. If your users are agents, there may be no real cost to having more options. The UX constraint that kept software lean for decades simply doesn't apply.

Agents do have their own version of cognitive limits — context windows are the machine equivalent of working memory, and a sufficiently large codebase can exceed them. But these limits are expanding fast. Claude's latest model ships with four times the context window of its predecessor. The ceiling is rising faster than most codebases are growing.

The Codebase Question

The traditional case against large codebases is straightforward: they're hard for humans to understand, debug, and maintain. This has been a core argument for keeping things simple, for refactoring aggressively, for saying "no" to features that would push complexity beyond what a team can hold in their heads.

Modern AI agents can hold entire codebases in their working context. A codebase that would take a human developer weeks to fully comprehend can be absorbed by an agent in seconds. If the primary builders and maintainers of code are agents, "too complex for humans" loses its force as an argument against features.

This is where I find myself genuinely conflicted, because I've lived the problem microservices were meant to solve.

In 2013 I joined Historic Futures as Interim Technical Director. They had a monolith built for an earlier era of the business — a system that had made sense to the people who'd designed it, but those people had moved on. The knowledge had walked out the door with them. What remained was a codebase that nobody fully understood, powering a business that had outgrown its original assumptions. Microservices became the strategy to cut the chains. We broke the monolith into small, well-understood chunks of code. Each service could be reasoned about in isolation. Each one fit in a developer's head. It worked. The team could move forward again.

I carried that lesson through every role since. Small services, clear boundaries, single responsibilities. It became my default architecture — and honestly, something closer to a belief system.

But here's what unsettles me now: the monolith at Historic Futures was a problem because no human could hold it in their head anymore. The people who understood it had left, and no one who remained could absorb the whole thing. An agent could have. It would have read the entire codebase, understood the dependencies, traced the logic, and explained it back to us in an afternoon. The problem we spent years solving with careful decomposition might not have been an architecture problem at all. It might have been a comprehension problem — and comprehension is exactly what agents are good at.

Were microservices really about good architecture, or were they about making systems small enough for a human brain to hold? The ability to keep "what this service does" in your head, to reason about a component without being overwhelmed by everything it connects to — that's a cognitive accommodation, not necessarily an architectural truth. We drew boundaries where our comprehension ran out, then built a philosophy around those boundaries.

This isn't to say microservices were wrong. Independent deployment, team autonomy, fault isolation — these are real benefits that exist regardless of who reads the code. But the cognitive argument — that systems should be small enough for humans to understand — deserves honest re-examination when the primary readers of code aren't human.

And yet. There's a difference between what I can accept intellectually and what I'm ready for in practice. I'm quite comfortable having an agent fill in the details of a structure I've designed. I still understand the purpose of each service, each component. The shape is mine. The agent just does the typing.

But am I ready for an agent to introduce concepts I don't understand? To build structures that don't fit inside my own context window? To work with systems that are, in a very literal sense, bigger than my head?

As a CTO, as a technology leader, I've always been able to hold the whole picture — or at least a credible sketch of it. That's what leadership meant. Understanding the system well enough to make decisions about it, to know where the risks live, to call the architecture sound or unsound. What does that role become when the system outgrows not just any individual engineer but the leader whose job it is to see the whole?

I don't have an answer. I'm not sure anyone does yet.

Bloat for Whom?

My instinct toward simplicity still feels right. But I'm less certain it's a principle and more worried it's a preference — one forged in an era when humans were the bottleneck at every stage.

Beads went from zero to over 200,000 lines of Go in three months. It has 16,000 stars on GitHub. Agents use it happily. Humans look at it and recoil. Both reactions are valid. They just reflect different consumers with different capacities.

Perhaps the question isn't "how do we prevent bloat?" but "bloat according to whom?" When the builders are agents, the users are agents, and the maintainers are agents, the human preference for simplicity becomes exactly that — a preference, not an engineering requirement.

I still prefer simple software. I probably always will. But I'm starting to suspect that says more about me than about the software.