What Would It Take for You to Never Read Your Code Again?

There have been so many perspectives on the future of AI and its effect on the human race, spanning the full spectrum from pessimism to optimism. However compelling the arguments behind any one of these perspectives are, one must not forget that they are, after all, just a perspective — formed in a limited context, and subjective. We are yet to invent the LLM that can act as an oracle. That’s why the future may turn out differently than any of us expect.

One thing, though, is for sure: these perspectives give us a likely trajectory in which AI is heading. I take them as exactly that, and nothing more — a beacon, not a map.

Recently I listened to an episode of the Thoughtworks Technology Podcast — AI-generated code: What has to be true for us to trust it without looking at it? (hosted by Ken Mugrage, with Principal Consultant Razin Memon and Principal Caer Sanders as guests, Aug 2026). I don’t buy everything said in that episode. But it’s worth thinking over, and it gave me a sharper way to state something I’ve been arguing with myself about for a while.

The debate

The question on the table was whether an LLM will be able to generate the software we actually want, straight from a specification — with writing code becoming optional, and the compiled binary becoming the real target — provided the right “harness” is in place to keep it honest.

Razin was the proponent. His claim, stated plainly on the episode, is that code stops being relevant to how we build software somewhere around 2028 — not because LLMs get smarter in some vague sense, but because the tooling around them (what he and others are now calling harness engineering) matures to the point where a spec can go to binary with acceptable trust, and the code in between becomes an ephemeral implementation detail nobody needs to look at or even not getting written at all.

Caer was the skeptic. Her position isn’t “AI can’t code” — she’s clear that AI-generated code gets the job done in the vast majority of cases. Her line is narrower and, I think, more defensible: for safety-critical systems, or anything where downtime costs real money, she still reads the code, and she doesn’t see that changing soon. Ownership still stays with the engineer — the same stance I took in my last article.

If you ask me, I find myself inclined toward Razin’s view — but only if two things hold: tokenomics keeps improving, and we get thorough enough at capturing requirements as specifications, with the harness enforcing the functional behaviour we actually meant. As always, this is my view, and you’re welcome to disagree. Tell me where, if you do.

The Tokenomics Hurdle

The first bet I’m making is that tokens keep getting cheaper. On the surface, 2026 makes that look unrealistic — GPU and memory prices spiked hard this year, largely because AI buildout is competing with itself for the same supply. But that’s the cost of buying hardware, not the cost of using it. Per-token cost has kept falling anyway, on the back of better chips and smarter serving software, and it’s fallen sharply again this year, continuing a run that’s been going for a while now.

So, the premise holds. What I’d flag is that the pace is slowing a bit, and more importantly — whether providers keep passing those savings on once the subsidised-pricing phase of this industry ends. That’s the real question mark, and it’s a business call, not an engineering one. Everyone knows what business would choose.

There’s also the local-hosting angle Razin leaned on — running open-weight models yourself instead of paying per API call. That’s real – many enterprises are actively pursuing it and it’s growing. But it’s not the free lunch it’s sometimes made out to be: the hardware you’d need to do it well is exactly what got expensive this year, so for most teams the breakeven point moved further out, not closer.

The Spec Illusion

This one I find less convincing, and it comes down to how we actually work. Our specifications today don’t capture everything we need — a lot of it lives as tacit knowledge, in people’s heads, never written down anywhere. Caer put it well: harness engineering is essentially asking teams to finally put all of that on paper. If we can, it works. That “if” is doing a lot of the heavy lifting.

There’s a good illustration of just how much, from the same episode: a colleague rebuilt a large legacy application and cut his token spend by over 80%, simply by breaking the refactor into stages himself instead of trusting the tool end-to-end. The tool could split code into functions fine. It couldn’t split it by logic. That’s premise two in a nutshell.

This is where the harness is supposed to step in — though I’ll admit that’s asking the harness to do exactly what the spec is failing to do on its own. For this piece, harness just means a testing layer that checks the generated software actually does what was asked, functionally and otherwise.

With that in place, I do think a harness industry and an LLM industry split apart from each other — Razin argued almost exactly this on the podcast, and I find it plausible. Where I differ with him is the leap from there to AI writing complete software with nobody in the loop. That still feels like the low-code/no-code wave to me (my comparison), and we all know how that story went.

The bet on spec-to-binary is possible — just further off than people think.

Earning the Trust

This all comes down to trust, and here I lean towards Caer. Her bar is simple: if she could go months without being let down by a hallucinated requirement, and if her specs were solid enough that she could delete the whole repository and regenerate the same behaviour from scratch — that’s when she’d trust it. It’s her own threshold, not a universal proof, but it’s a real one, not a vibe.

One thing worth sitting with, though and the real danger right now is psychological: we already trust AI output over human output by default, even when the AI is wrong more often. Caer had a telling anecdote for this — leaders overruling their own team by saying “Claude said this, I trust Claude, not you,” no matter what the human had actually found. That asymmetry is on us, not the model.

Placing my bet

AI is going to change how software gets built. That was never really in question. What’s actually in question is when, and on what terms — and there I’d push past Razin’s 2028, probably by a few years for the full code-free version. The harness-versus-LLM split, though, I think happens well before that. Call me a glass-half-full person, leaning cautious. Feel free to hold me to the date.