Yesterday I finally got around to posting Minimum Specs, Maximum Vibes which was a draft I had kicking around for a while but hadn't finished. It was about my side project experiment of seeing how far I could get with coding agents on auto. I got a lot further than I thought, and a lot further than I could get just a few months ago.

Then, later that evening a friend pointed out Dex Horthy's Why Software Factories Fail post. I had also heard Dex make this argument on Gergely's Pragmatic Engineer podcast. It is a very strong case for reading the code, and I had just written about how far I got by not doing so.

"Minimum Specs, Maximum Vibes" and "Why Software Factories Fail" look like opposing positions. But Dex (via Addy Osmani) carves out the exception that a side project and a production system have very different constraints. Like I said in my post, maximum vibes is an experiment I only run on side projects.

Why I don't work like this at work

Three reasons:

  • Compliance. SOC 2 / ISO 27001 means review isn't optional, it's audited.
  • Respect for the team. Software development is a team sport, and I'm not going to start throwing slop at colleagues.
  • Scope. This was greenfield. Bigger than what I'd have called "small" a year ago, but not a decade of legacy.

Dex's argument is that agents can't maintain and improve codebase quality over time without a substantial amount of human steering. So producing maintainable long-term codebases is not possible with AI at the moment.

My experiment shows that vibes can work for new builds, but says nothing about long-term maintainability. It produced a real result that I can't ignore. It demonstrates a genuine capacity increase with minimal spec. I'm proceeding with cautious optimism, based on what I'm seeing in work and play.

The evidence from serious work

Even inside the reviewed, compliant, team-sport context of serious work, I am getting results I would not have believed possible a year ago.

Recently I completed a batch of work I'd have specced at 3+ months a year ago, done in 2 weeks. The biggest chunk of the work was review and validation. But it's still a step-change in throughput. AI coding really works, but human review is the constraint.

Build software informed by AI's strengths

Dex argues the lights-off factory fails while human-in-the-loop works. And he suggests this is a model-training problem. The evaluations the models are trained against are coding problems, and so it's no surprise that what the models are good at reflects this. It's really hard to evaluate for long-term maintainability. Until we get benchmarks that measure that, we won't get models that are trained for that.

Instead of asking "how do we make agents produce maintainable 10-year codebases?" what if we make systems that don't need to last 10 years?

Dex's estimate is that fully AI codebases start to struggle after 3-6 months.

If that's the case, that raises two questions:

  1. What factors differentiate the 6-month codebases from the 3-month ones? Is there something that doubles the lifespan of a codebase and can we do more of that?
  2. If we know it will degrade, why not design for that?

What if we plan to regenerate rather than maintain? For decades, we have dismissed engineers' calls to deal with technical debt by rebuilding the system, forced under business and product pressures to continue maintaining the legacy. And not without good reason. The history of software development is full of stories of failed rebuilds and mismanaged modernisation programmes. But to rebuild is cheap now. AI can extract a spec from a running system, tweak it, and rebuild.

Smaller, replaceable systems play to what models are demonstrably good at (greenfield, one-off problems) and route around what they're bad at (long-horizon quality maintenance).

But not microservices

I know it sounds like I just said "more smaller systems" and that sounds suspiciously like microservices. I'm explicitly not recommending that. We already learned that decomposition doesn't solve complexity, it just makes it someone else's problem.

So this is an open question, not a recommendation: is regenerate-over-maintain a genuinely new trade-off enabled by cheap code generation? I don't know yet. That's what side projects are for.

What's next

I'm with Dex on still reading the code. For now. For all the reasons I mentioned above (team sport, compliance, etc) and for long-term maintainability. But not for verifiability. I still think our job now is largely working to make agents more efficient and that means giving them (or helping them build) better guardrails.

Better guardrails include better testing. That's why I'm working on a follow-up on testing methodology. I gave a talk at TestCon EU a few years ago about tech debt and making systems more testable. That material needs updated for agentic coding. I'm working on that and some experiments and will post the results of that soon.

I think the leverage will turn out to be in verification. Harness engineering and loop engineering that shift trust from reading lines to trusting checks. But only if the models can improve in producing long-term maintainable code, or we reduce the need for long-term maintainability.

Either:

  1. The models get better at producing long-term maintainable code (But this requires fixing the "there are no good benchmarks for maintainability" gap Dex talks about)
  2. Systems stay small enough that they are easy to understand (But this requires them to compose well and not just move complexity elsewhere)
  3. We replace/regenerate before they become unmaintainable (But this limits the lifespan of a system)