The Last Abstraction

ICode is becoming 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

Every rung moved the programmer further from the hardware and closer to the problem. Every rung was dismissed as "not real programming" by the people standing on the rung below. And every rung won anyway.

The next abstraction isn't another language. It's 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 won't die. It will become what assembly became — still present, still load-bearing, inspected by a small priesthood of specialists, and invisible to everyone else.

Here is the part most people get wrong: this is not a threat. No abstraction in computing history has ever destroyed engineers. It has only destroyed excuses. Assembly programmers became systems architects. Compiler writers became language designers. Web developers became product engineers. The layer beneath you always commoditizes — that was never the question. The question is whether you're already standing on the next rung.

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 organised my career around that direction.

III didn't read about this shift. I climbed it.

Looking back, I realise my own trajectory mirrored the direction the industry was already moving. That wasn't a plan. It became one. The years below are the questions I was working on rather than a sequence of promotions — the titles moved a good deal less often than the questions did.

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 goes when building becomes free

The economics of software are inverting.

The old pipeline was idea → expensive engineering → product. Code was the bottleneck, so coders captured the value.

The new pipeline is idea → cheap AI engineering → product → expensive distribution. When everyone can build, attention becomes the scarce resource. And scarcity — not effort — is what sets price.

So where does value concentrate next? I keep arriving at six places, all of them stubbornly human.

Problem selection. AI will build anything you ask. It has no opinion about what's worth asking. Most startups don't die of bad engineering; they die of irrelevant excellence.

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. Massively underrated. AI generates ten thousand options; taste selects one. Apple isn't Apple because they could code. Jobs wasn't writing Objective-C — he was choosing.

Systems thinking. Tomorrow's engineer coordinates twenty agents, three databases, a compliance regime, a security posture, and a deployment pipeline into one coherent whole. That isn't typing. That's architecture.

Human understanding. Businesses exist because humans exist. Psychology, incentives, trust, culture. AI can generate features endlessly; it cannot inherently know which ones people will love.

Distribution. The best product loses. The best-distributed product wins. Brand, community, storytelling, network effects — these get more valuable every time building gets cheaper.

Notice what's on that list: decisions, judgment, and reach. Notice what isn't: syntax.

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.

VOperating principles

A few beliefs I've paid for, and now run on.

Technology has never rewarded the people who used the previous abstraction the longest.

Master the next abstraction first. Hand-written assembly lost to C. Hand-written C lost to higher-level languages. "Real engineers write every line themselves" will lose too — to people who define problems precisely and direct machines ruthlessly.

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.

Learning velocity beats current expertise. I've made the trip from "I know nothing about this domain" to "let's argue about the architecture trade-offs" enough times to trust the loop more than any single credential.

The constraint is no longer learning — it's choosing. I can learn almost anything now. The discipline is deciding what to ignore, and allocating attention like the scarce capital it is.

"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 I'm betting my career here

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 don't believe the future belongs to specialists who never leave their domain. I believe it belongs to integrators.

That's the bet. Not that I'll out-engineer the engineers or out-design the designers — but that when implementation stops being the constraint, the people who can hold the user, the architecture and the business in the same head at the same time become the ones worth having in the room.