Let's start by admitting the scary part is true, because the whole argument falls apart if I pretend otherwise.
AI can build an enormous amount of software now, fast, for almost nothing. You can vibe-code a working app over a weekend. Clone a SaaS product's whole front end in an afternoon. Generate the CRUD endpoints, the forms, the standard UI, the glue code, the "make it look like this" — all of it, in minutes of prompting, at a quality that a few years ago would've been a week of a junior's time.
That's not hype. It's real, and if you've felt the floor shift under you because of it, you're not imagining things. So the fear makes sense: if building software is nearly free now, what's left for the people whose job was building software?
Here's the thing that question quietly assumes, though — and it's wrong. It assumes the building was where the value lived. It wasn't. And once you see what AI actually made free, and what it conspicuously didn't, the panic turns into something closer to a map.
What AI actually made free
Let me be specific and generous about how much AI really took, because downplaying it just sounds like denial.
It took the happy path. The first version. The part of the work that's been written down ten thousand times in tutorials, Stack Overflow answers, and open-source repos — which is exactly why the model learned it so well. The standard login flow, the typical dashboard, the ordinary API, the form that validates an email, the component that looks like every other component. The commodity layer of software engineering, the stuff that was technically "skilled work" but was really pattern-matching against a million prior examples.
That's maybe 90% of the volume of what gets typed in a day. And it genuinely did fall. A huge amount of what used to be billable, time-consuming, résumé-worthy engineering is now a prompt and a glance. Pretending that's not true helps no one, least of all you.
Concede the whole 90%. The argument doesn't need it.
What it conspicuously did not touch
Now the part nobody put in the demo.
AI did not learn how to make a webhook idempotent when Stripe times out mid-transaction and you have no idea whether the charge went through. It didn't learn to tune cgroup memory limits when a background worker quietly OOMs at 3am and takes the queue down with it. It has no feel for the passkey signCount desync that silently locks your paying customers out of their own accounts — the bug that generates zero errors and a pile of furious support tickets. It can't do the data migration that has to move fifteen years of real users' files without losing a single byte or breaking one weird edge case someone created in 2013.
Notice what all of those have in common: none of them show up in a demo, and none of them were written down anywhere for the model to learn from.
That's not a coincidence — it's the whole explanation. AI got extraordinary at the 90% because the 90% is the part that's documented everywhere, done the same way a million times, sitting in the training data in bulk. The 10% is hard precisely because it isn't written down. It's the failure modes, the edge cases, the what-happens-when-it-breaks-at-scale — knowledge that doesn't live in tutorials because it's only ever learned the expensive way: by getting burned, at 3am, on a real system, with real users yelling.
You can't prompt your way to that, because the thing you'd need to prompt doesn't exist in text. It exists in scar tissue.
The counterintuitive part: the 10% got more valuable
Here's the move most people miss while they're panicking.
When the easy 90% was expensive, its cost hid the value of the hard 10%. It was all bundled together and called "engineering," and the bill for the boilerplate and the bill for the 3am expertise came out looking like the same kind of money. The commodity work subsidized and camouflaged the rare work.
Now that the 90% is free, that camouflage is gone — and the 10% stands exposed as the only remaining scarcity. And value always concentrates wherever the scarcity is.
So AI didn't flatten the value of expertise. It flattened the value of the commodity part of expertise, and shoved all the remaining value into the rare part. The person who can do the 3am work didn't get less valuable when AI arrived — they got more valuable, because now everyone can do the easy part, and almost nobody can do theirs. The scarcity sharpened. The premium went up.
That's the whole reframe, and it's why the title isn't a motivational lie: AI making your easy work free is exactly what made your hard work worth more. It stopped being hidden inside the cost of the boilerplate.
The market is already proving it
You don't have to take the argument on faith — go look at the vibe-coded clone wave happening right now.
People are using AI to clone paid apps by the thousands: creative tools, CRMs, SaaS products, whole suites. The first versions appear fast and look impressive. And almost all of them die in alpha.
Why? Not because the code was bad. Because the makers could generate the 90% and either couldn't or wouldn't do the 10%. The clones that survive — the rare ones — are precisely the ones where somebody pushed through the unglamorous hard part: the maintenance, the edge cases, the reliability, the trust that gets built one answered support ticket at a time. "Cloning the surface of software is now free" is the exact reason depth became the moat. The market responded to free building with a graveyard of surfaces and a premium on substance. That's the thesis, already playing out, in public.
So what do you actually do with this?
Honest direction, no false comfort:
If you're early in your career and the 90% is most of what you can do right now — that's the part that got commoditized, so the move isn't "learn to prompt faster." It's to deliberately go after the 10%: debugging, systems thinking, how things fail, what happens at scale, reading code you didn't write, operating things in production. I'll be straight that this is genuinely harder than it used to be, because the easy work that used to teach you the hard stuff — the grunt tasks juniors cut their teeth on — is exactly what's being automated away. That's a real problem, and it deserves honesty rather than a slogan. But the direction is clear: chase the part that doesn't demo.
If you're experienced — your value didn't drop, it got concentrated. The years you spent getting burned are now the scarce thing, not the overhead. Stop apologizing for being "slow" at the boilerplate AI does instantly, and lean into the part it can't touch, because that part is now the whole job.
For everyone: stop competing on the layer AI does for free. There's no winning there — it's free, and you can't underbid free. Compete on the layer it can't reach.
The takeaway
"AI can build anything" is true and misleading in the same breath. It can build the 90% that was always the commodity. It can't build the 10% that was always the point.
The value didn't leave software. It moved — from the writing to the making-it-actually-work, from the demo to the dependability, from "can you build it?" to "can you keep it alive when it breaks at 3am?" For an engineer who can do the hard part, that's not a worse world. It might be the first time in a long while that the hard part is clearly, visibly the valuable part — instead of being quietly hidden inside the bill for the easy part.
Your easy work became free. That's not what makes you replaceable. That's what finally made the rest of you worth paying for.
A personal note, since this is the thing I've been chewing on the most: I've ended up building in this space myself — a workspace where the whole point is to put the real effort into the hard part (the reliability, the guardrails, the trust around what gets built), rather than just the fast generation everyone already has. It's called Xenition. I'm genuinely not pitching it here — this piece stands on its own and I'd have written it either way. But if any of this resonated and you're curious what "building for the hard 10%" looks like in practice, you're welcome to take a look. Mostly I just wanted to think the idea through out loud, and the comments are where I actually want to be.
So — the contestable version, and I want the real disagreement: do you think the hard 10% stays safe, or does AI eventually eat that too? And for the experienced folks: what's your 10% — the thing you do that no demo ever shows and no prompt ever quite gets right? I'll start: anything involving what happens after the happy path fails.
Top comments (5)
I agree with the main idea, but I'd move the value somewhere else.
If you have to wake up at 3 a.m. to fix something, that usually means the system wasn't tested well or wasn't designed well. Fixing a broken system is fine — but honestly, give an agent the error report and it will fix it perfectly, and faster than you. What it can't do is predict where the error will come from before it happens.
And sometimes the failure doesn't even produce an error report. A real example: my bank lets me issue a virtual card. I paused the card, then a subscription tried to renew on it — and after that, every payment from the card is declined, even though the balance is sufficient. Support is an AI agent with no option to reach a human. It politely answers and nothing changes.
I'm sure their app has all green tests, and their backend too. Nothing crashed, nothing went to the error tracker. From the system's point of view this is just "some problems with customers, it's normal, no need to worry" — no need to even wake a programmer at 3 a.m.
That's the part I think is becoming more valuable. It's less about fixing things at night and more about thinking through state combinations nobody wrote a test for (paused card + subscription retry). It also means building the system so that a silent failure becomes visible to a human. Your passkey-desync example is exactly this kind: it locks paying users out and throws no errors. Agents are great at fixing what they can see. Someone still has to decide what the system should be able to see.
You’ve relocated the value more precisely than I did, and I think you’re right. The 3am-fix framing was the wrong emphasis — you’re correct that fixing a reported break is increasingly the agent’s job, and often it’ll do it faster and cleaner than a tired human. Hand it the stack trace and it’s genuinely good. The scarce human skill was never the fixing. It’s two things upstream of the fix: predicting where the failure will come from before it exists, and deciding what the system is even able to see.
And your bank example is the sharpest illustration of the real problem anyone’s given me, because it’s a failure with no error report at all. Paused card + subscription retry → every subsequent payment silently declined, balance fine, nothing crashed, nothing in the error tracker, support is an AI that politely changes nothing. From the system’s point of view that’s not a bug — it’s “normal customer friction,” invisible, un-pageable, nobody woken because nothing reported itself as wrong. That’s worse than the 3am break, because the 3am break at least announced itself. This one is a correct-looking execution of a broken intent, and it’s exactly the passkey-desync shape: valid state transitions composing into a silent catastrophe that generates zero signals and a pile of quiet, furious users.
So the thing that’s actually becoming valuable is the two moves an agent structurally can’t make for you. First, thinking through the state combinations nobody wrote a test for — paused-card-plus-retry, the interaction of two features that were each fine alone — because that’s not pattern-matching on documented failures, it’s imagining the failure that isn’t in any training set yet. And second, building the system so a silent failure becomes visible at all — deciding what gets instrumented, what counts as “wrong,” what should trip an alarm versus pass as normal. Agents are superb at fixing what they can see; someone still has to decide what the system is able to see, and that decision is made before any error exists, by a human imagining the ways their own system could lie about being fine. That’s a better statement of the hard 10% than mine. Going in with credit — “agents fix what they can see; someone decides what it sees” is the line.
Thanks, that's a better compression of it than mine. The part I keep running into is that "deciding what the system should see" lives in one engineer's head until something goes silent. The bank case was the third time I'd hit that exact shape, and each time it was a different team, learning it from scratch. Writing those down, with the check that would have caught it, is most of what I do now.
Really insightful and genuinely moving. This article left a strong impression on me. Great work!
Thanks brother!