The Last Abstraction

ICode may become an intermediate representation

There is a ladder that runs through the entire history of software:

Machine code → Assembly → C → Java → Python → AI-generated source → Intent

Each rung moved programmers further from the hardware and closer to the problem. Each was treated with suspicion by at least some people on the rung below. Then it became ordinary.

The next useful abstraction may not be another language. It may be intent. Instead of writing for (i = 0; i < n; i++), you write: "Build a billing system with OCR, role-based access, audit logs, and Stripe." The machine produces the thousands of lines. Eventually it may skip source altogether. Whether that takes five years or twenty doesn't much matter — the argument was never about binaries. It's about which layer humans work at.

Source code may become more like assembly: still present, still load-bearing, but inspected directly by fewer people, less often.

I don’t think that automatically makes engineers less useful. Earlier abstractions changed the work and created new specialties, even as some older skills became less common. The useful question for me is simpler: if implementation gets cheaper, what becomes the harder part of the job?

I'll be honest about how that landed. The realisation was uncomfortable. I had spent years getting better at writing software, and the possibility that writing software was becoming the less valuable part of the job forced me to ask whether I had been optimising for the wrong thing. It took me a while to decide that the right response was to move rather than to defend.

I may be wrong about the timeline. History rarely unfolds exactly as anyone predicts, and I'd treat anyone claiming to know the schedule with suspicion. But I'm confident about the direction. Every major abstraction shift has pushed humans away from implementation and closer to intent. I don't see why this one would be different.

I’ve started organising my work around that possibility.

IIMy work had already been moving that way

Looking back, my own work had been moving away from individual screens and toward whole products long before I had a theory for it. It wasn’t a plan. The questions simply kept getting wider, even when the titles did not.

Six roles, one direction. The only thing I have done consistently is refuse to stay on my side of the handoff — and somewhere along the way I noticed the questions themselves were the real trajectory: screen → feature → product → platform → industry. The record carries the titles and the dates, including the ones that read sideways.

IIIWhere value may move as building gets cheaper

The economics of software are changing.

For a long time, the rough pipeline was idea → expensive engineering → product. Code was often the bottleneck, so implementation carried a large share of the value.

The emerging version looks more like idea → cheaper AI-assisted engineering → product → difficult distribution. As building gets easier, earning attention and trust matters more.

I keep coming back to six areas where human judgment still seems especially important.

Problem selection. A model can help build what you ask for. It cannot decide why this problem deserves years of somebody’s life, or whether solving it will matter to anyone.

Product judgment. Not "build feature X" but why does X exist? Why do users leave? Why is onboarding broken? The machine executes; someone still has to interrogate.

Taste. Generating options is getting cheap. Recognising the one that fits the product, and being able to explain why, is not.

Systems thinking. The kind of engineering I’m moving toward coordinates agents, databases, compliance, security, and deployment into one coherent whole. The typing is only one small part of that.

Human understanding. Products live inside psychology, incentives, trust, and culture. Models can suggest features; people still have to notice what another person actually needs.

Distribution. Good products still lose when nobody hears about them or trusts the person selling them. Brand, community, storytelling, and network effects become more important as building gets cheaper.

The common thread is judgment and reach. Syntax matters, but it is no longer the whole job.

IVThe strongest evidence against this

An argument that only collects its own supporting evidence is not an argument. So here is the finding I keep in front of me, and it cuts against everything above it.

A controlled trial of experienced developers, working in codebases they knew well, found them measurably slower with AI assistance — while predicting beforehand that they would be faster, and still believing afterwards that they had been. That last clause is the part that should trouble anyone making my case. The people in that trial could not feel the direction of their own productivity, and I have no particular reason to think I am the exception.

So the simple version of this thesis — building is becoming free, therefore everyone builds faster — is not supported. AI assistance does not uniformly make developers faster. On familiar code, in experienced hands, it can do the opposite.

What survives is narrower, and I would rather state it in its weakened form than its flattering one. Cheap execution does not remove the bottleneck; it moves it — to knowing what to build, and to judging which of the ten plausible options the model just produced is the right one. That is a claim about where the work goes, not a claim that the work gets faster. If everything above is wrong, this is the direction it will be wrong in.

The result is a constraint on the argument rather than a footnote to it, which is why it sits in the middle of the essay and not at the end.

A note on this citation, because the standard the rest of this site holds to requires one. The finding is part of my own recorded evidence and it has changed what I build. The original source link is no longer in my records, so you cannot verify it from this page, and I am not going to reconstruct an author, a date or a URL from memory to make the paragraph look better sourced than it is. Treat it as the weakest-cited claim on this site until I find the reference again and put it here.

VRules I’m trying to work by

A few lessons I’m trying to put into practice.

New abstractions tend to reward the people willing to learn them, not the people defending the old boundary.

Learn the next layer early. I don’t need to abandon the layers underneath, but I also don’t want pride in doing things manually to stop me using a better abstraction.

Compound fundamentals, not tools. Frameworks have a half-life of months; judgment compounds for decades. I'd rather be six months behind on the newest agent library and ten years ahead on knowing which problems are worth solving.

Trust the ability to learn. I’ve entered enough unfamiliar domains to value a good learning loop alongside current expertise. Both matter; one ages better.

Choosing matters as much as learning. It has become easier to begin in an unfamiliar domain. The harder discipline is deciding what deserves attention and what can wait.

"Can we build this?" and "should this exist?" belong to the same decision. I have lost the ability to ask one without the other, which is the responsibility I am deliberately growing into.

VIWhat I'm building toward

My working bet is that small teams with clear judgment, rigorous verification, and capable tools will be able to take on more than their headcount suggests. It is a hypothesis I am testing, not a forecast about every company.

That's the kind of organisation I'm building at Vaulth AI, and the kind of operator I'm deliberately becoming: fewer hours on syntax, more on distribution, decisions and people. The question is not whether that ratio is universally right; it is whether it makes this product more useful and more trustworthy.

VIIWhy this direction feels right for me

My background isn't accidental, though it took me a while to see the shape of it.

I started in design, where I learned empathy — that a product is a claim about how someone will feel at 11pm when something has gone wrong. I moved into engineering, where I learned systems, and that the elegant answer and the answer that survives contact with production are frequently different answers. I moved into product, where I learned trade-offs, and that the hardest skill is deciding what not to build. Today I build AI systems, where all three converge and none of them is optional.

I’m most useful when I can connect the user, the product, and the system instead of treating them as separate rooms.

That is the direction I’m choosing. I’m not trying to out-engineer every engineer or out-design every designer. I want to be the person who can keep the user, the architecture, and the business in view at the same time.