Software Is Cheap Now

Published in February 2026

I am the bottleneck now by Thorsten Ball (@thorstenball).

Thorsten shared a story about receiving a bug report on Slack. He took a screenshot, uploaded it to Codex, and had the fix completed in 5 minutes. The code looked solid, all tests passed, and he pushed.

Then he realised he was the bottleneck. The process could have gone directly from Slack to Codex to a review thread, without him in the middle.

His point is that ticketing, triage, and sprints exist because human engineers are costly and have limited time. If that goes away, the whole process needs to change.

I agree with the general idea, but saying "I'm the bottleneck" feels like an exaggeration.

Even if the LLM eventually becomes smarter than me, which seems likely, it still lacks morals, taste, and real-world consequences.

When a human ships a bad deployment, they worry about it afterward.

You’re not really a bottleneck; you’re the only one in the process who faces the consequences.

Humans will still be part of the process, maybe in a different role, but they’ll still be there.

The economic point is the one I agree with most.

For decades, the industry has focused on making the most of limited engineering time through practices like agile, sprint planning, velocity tracking, and story points.

All of these methods assume that writing software is expensive. If that cost drops to almost nothing, we’ll need to rethink these approaches.

Ironically, when I began my career, everyone was pushing for agile and criticizing waterfall methods.

Writing specs before any code felt old-fashioned.

How can you write a specification if you haven’t explored the problem by coding first?

Agile just felt right.

It also helped reduce risk: you write some code, make some progress, and then decide whether to roll back or keep going.

With waterfall, you only find out about bad decisions at the end.

But things are different now. The cost of writing software is approaching zero, and you can iterate much faster and discard versions easily, as Thorsten points out in the video.

So, should we go back to writing more detailed app specs?

I think yes.

Nicholas Zakas uses a similar approach, spending a lot of time creating enterprise artifacts (PRDs, ADRs, TDDs) and updating them as the project changes. At first, I thought it was overkill, but now I’m rethinking that.

Picture this instead.

You write the specification, and the model builds the app.

But the app isn’t quite what you wanted.

Instead of fixing the app, you update the spec, adjust the architecture, and rebuild it from scratch.

If you think of the model as a compiler, then the input is all that really matters.

In three years, I probably won’t care about NPM dependencies or which framework version I used.

All I’ll need is my old specification to rebuild everything.

Writing detailed specs up front and keeping them up to date actually makes sense.

It could end up being the only thing that really lasts.

The code is disposable. The specification is the product.

But what form should the specification take?

Alex Jones, a Principal Engineer at AWS and creator of K8sGPT, argues that we need more than the usual verifiers.

As agentic systems become more autonomous, we’ll need invariants, constraints, and properties supported by mathematical proofs.

It’s not enough to just have observability or policies.

He calls this idea "Provable Autonomy."

There's a whole world of formal specification languages: TLA+, Event-B, Dafny, Alloy, Gherkin. But from what I've seen, specs without verification sit in an unstable middle.

They’re structured enough to be a maintenance burden.

But they’re not verified enough to guarantee anything, so you end up with text that the model might just ignore.