Somewhere right now, a finance manager is building the reconciliation tool she’s wanted for eleven years.
She’s asked for it every planning cycle. It never made the cut, because it was three weeks of engineering time for a problem only she and four colleagues had, and there were always bigger problems. So she did it by hand, every month, for over a decade — and she knew, in precise detail, exactly what the tool should do. She just couldn’t make it exist.
This week she made it exist. It took a Thursday afternoon.
That is the story. Not the failure modes, not the security incidents, not the discourse — the story is that the distance between knowing what should exist and making it exist has collapsed for millions of people who were previously locked out. Ideas that died in backlogs are getting built. Problems too small to justify a sprint are getting solved by the people who actually have them. This is one of the genuinely good things to happen to software, and we should say so clearly before we say anything else.
Now, the harder part: what do we build around it so it lasts?
The word we gave it
We called it vibe coding — describe what you want, let the model write it, ship without reading the code — and the discourse turned on it almost immediately.
“That’s not real engineering.” “You’ll get hacked, fined, broken in production.” Even Andrej Karpathy, who coined the term, has moved on to preaching agentic engineering. And the critics have a point worth conceding: code produced this way does fail in the ways they describe. It looks professional and buckles when it meets real users, real load, or a mildly creative attacker.
But the response to that has mostly been to police the boundary. To argue about who gets to call themselves an engineer. Which is both unwinnable and beside the point, because the barrier isn’t going back up. The useful question was never how do we keep people out. It’s what does everybody need in order to do this well.
The next rung
Because people don’t stay at vibe coding. They climb.
Watch what happens after a few months. They stop just generating output and start performing the role. They open pull requests. They talk about architecture. They ask the agent to add some tests. They pick up the rituals, the vocabulary, the artefacts.
I’ve heard this being called pretendgineering, It’s a rung up above vibe coding. Someone reaching for the shape of good engineering is someone who has worked out that shape matters, which is genuinely further along than not knowing it exists.
It’s just worth being clear-eyed about one thing: this rung is harder to see from the outside. Vibe-coded output announces itself. Pretendgineered output is convincing — it passes the eye test, it clears review, it looks like judgment right until you find the place where it was pattern-matching. Not a character flaw. A visibility problem, and visibility problems are solvable.
The ceremony of engineering
Here’s the part I’d want the finance manager to know, and it isn’t a warning, it’s an inheritance.
Every ritual in software was once a scar. Code review exists because someone shipped something a second pair of eyes would have caught. Tests exist because someone broke in week nine what they’d built in week one. Design docs, RFCs, staged rollouts, the boring commit message. Each one is hard-won judgment that got crystallised into a repeatable form, specifically so the next person wouldn’t have to earn it the same painful way. Decades of people getting it wrong, distilled into practices you can follow.
That’s an extraordinary gift to be handed. It’s also, unavoidably, a form you can follow without yet understanding and AI is very good at producing the form. It will write the tests, open the PR, generate the architecture decision record, and use the vocabulary of rigour fluently. The shape is learnable. The judgment underneath took the industry forty-plus years.
Which means the signals we relied on need rethinking, not the people. A passing test suite was trustworthy because writing tests used to be nearly as hard as writing the code. Now a suite can be generated from the same misunderstanding as the code it’s testing, assert confidently that the code does what the code does, and go green while catching nothing. That’s not someone cheating. That’s a measurement we inherited quietly losing its meaning, and it’s on us to notice.
The right response isn’t to guard the ceremony jealously. It’s to teach what’s underneath it and to build systems that supply the judgment while people are still acquiring it.
The ladder we actually climb
There’s a sixty-year-old learning model that fits this: the four stages of competence.
You begin at unconscious incompetence — you don’t know what you don’t know. Then conscious incompetence, where you’ve sensed the gap and start performing the practices while you acquire them. Then conscious competence, where you can do it but it takes deliberate effort. Then unconscious competence, where it’s second nature and the real tell shows up: you can teach it.
Vibe coding sits at the first. Pretendgineering is the second and the second stage is, in the model’s own terms, the learning stage. Mistakes there aren’t failure, they’re the mechanism. Every senior engineer I know spent years mimicking the people above them, reproducing the shape of good work long before they grasped the reasons. You perform the role before you own it, with feedback and under pressure, until one day the performance and the reality converge and you notice you’re not pretending anymore. To me this is the form of imposter syndrome that all engineers experience at least once in their careers.
The model does assume one thing AI has changed: that output and understanding rise together. They used to be locked — you couldn’t produce stage-four work until you’d become a stage-four person, which is why the work was a fair proxy for the worker. That proxy has come apart. Stage-four output is now available from stage-one understanding, at least on the surface or at a glance.
That’s not a scandal. It’s just new, and it has one consequence worth designing for: climbing has always been powered by mistakes you felt. If the tooling silently absorbs every error, it can also absorb the lesson, and someone can sit comfortably on rung two for years — shipping fine work, learning nothing. The answer isn’t to let things break. It’s to make sure that when the system catches something, it shows you what it caught. Guardrails that teach, not just guardrails that save.
We have empirically rediscovered that experts are experts
For a while this was all vibes about vibes.
Anthropic recently analysed around 400,000 real coding sessions: people of every profession directing an AI that will cheerfully attempt almost anything. It’s the closest thing we have to an experiment on what’s valuable when execution becomes free. And the headline finding, stripped of hedging, is this: experts are experts. shocking, I know!
The detail is better than the joke, and it’s the most encouraging thing in this whole piece. Success had almost nothing to do with coding ability and almost everything to do with domain command. People decide what to build; the agent decides how. Occupation barely moved the needle, most professions succeeded at close to the rate of professional software engineers. What mattered was whether the person genuinely understood the problem.
Our finance manager, who has never written a line of Python but knows precisely which reconciliation rules must hold and spots the edge case the model fumbles at month-end close, is by the only definition that counts an expert. The tools didn’t make her one. They just stopped requiring her to be a different kind of expert first.
The mechanism is the thesis. The advantage is steering: framing the ask precisely, knowing which parts to verify, catching the model at the exact moment it becomes confidently wrong. When a session goes sideways, novices abandon it at several times the rate of experts — not because they can’t type, but because they don’t yet know what wrong looks like or which question unsticks it. The most valuable skill turns out to be knowing what you don’t know, and asking the educated question anyway.
So: we built a universal execution engine, ran the largest natural experiment in the history of knowledge work, and rediscovered expertise. Congratulations to us all. Joking, kind of.
Solving isn’t shipping
That finding is a claim about solving the problem. Which is the first 70% and the reason to bring in the second expertise, not to dismiss the first.
Every problem worth deploying eventually stops being a finance problem, or a research problem, or a marketing problem, and becomes a systems problem. The moment it runs for many users, needing updates, changes, in production, over time, a new set of questions arrives that has nothing to do with the original domain: what happens under concurrency, where state lives, how identity works, what happens when two people do the same thing at once, how it fails, how it recovers, how it’s secured, who maintains it at 2am. That’s the last 30%, and it’s now most of the cost. We are seeing the move from build vs. buy, to build vs. operate.
This is where the discipline that decades of engineers built earns its keep, because those questions are made of invisible requirements, the ones nobody thought to specify. The model will generate a login form in seconds. It won’t think to ask whether two people can register the same email, or warn you that a password reset might then hit both accounts. That gap never shows up in a demo. It shows up six weeks later as an incident.
And here’s the honest read of the research: it measures success within the session — a passing test, a commit, “that worked”. The authors are upfront that they can’t see whether the code survives, gets used, or is quietly thrown away. Much of that success sits on work that never reaches the production cliff: analyses, scripts, prototypes. The data doesn’t contradict the last-30% problem. It doesn’t test it.
So both things are true, and neither cancels the other. There are two expertises in this room. The tools democratised the first spectacularly. The second is exactly where it was — hard-won, still scarce, and now needed by far more people than it can personally reach.
Stronger floors, not higher walls
Which brings the real work into focus, and it isn’t the builders' work. It’s ours.
That second expertise has always lived in technology roles, the senior engineer who knows the login form needs a unique constraint, who asks about the duplicate reset, who has seen this one before. That was fine when only those people could ship. It doesn’t scale to everyone, and it never did scale well: it was expensive and slow to grow.
So it has to move. Out of individual heads and into the system into guardrails, security posture, governance and validation that hold whether or not the person building knows why they’re there. Not as bureaucracy, and emphatically not as a gate. As the substructure that makes an open door survivable.
This is the inversion I think we’re mispricing. The instinct says more builders means higher walls to keep the unqualified out. It’s the reverse: more builders means stronger floors. Automated testing, policy-as-code, security scanning, deployment gates, observability, and governance designed around a simple assumption — that the person shipping is a real expert in a field with nothing to do with the one they’re about to touch. The more people we invite in, the more the system has to carry what they haven’t learned yet.
For a while I’ve been saying that AI lowers the barrier of entry, but it does not raise the ceiling of excellence.
That isn’t a brake on any of this. It’s the only thing that lets it scale and, done properly, it’s how the last 30% finally gets taught to more than the few thousand people who learned it the hard way.
Final Thoughts
So let them build. Let the finance managers and designers and researchers and curious pretendgineers climb their way up the ladder, because that’s how the next generation of experts has always been made, and because the ideas are worth building and always were.
But be clear about what changed. The hard part didn’t vanish — it moved. It moved from writing the code, which is now nearly free, to making the code survive contact with the real world, which never was and isn’t now. Everyone can build. That’s the good news.
Which leaves one fork, and it has nothing to do with whether we let people build. In one version, they build anyway and throw it over a fence at a platform team who never asked for it, and everyone loses slowly. In the other, the same person on the same weekend walks the same idea onto a marked ramp, gets it checked, learns something on the way through, and ends up with something that actually runs. Same builder. Same enthusiasm. The only variable is whether we did our part first.
The job was never the code. The job is knowing what you’re doing, knowing what you don’t, and building the floor sturdy enough that everyone else can find out safely.