The Skill I Never Had to Lose

I don't code.

I've shipped a portfolio of apps on the App Store, and built and maintain a handful of unpublished apps and websites. None of the syntax in any of them came from me. When something breaks, I open a review, we figure out what went wrong, we fix it, the work moves on.

That's the data point I keep returning to whenever I read another piece arguing AI is making developers worse. I can't argue those pieces don't reflect a truth. Seniors and juniors alike report losing fluency, and some of that atrophy is probably real for people who have handed AI deliverables that used to be theirs. What I keep noticing, though, is a tension running through the same pieces: AI is not good enough to replace programmers, but it is somehow good enough to degrade their skillset in a shockingly short timeframe. Both can be partly true at once. Holding them together suggests the view is partial — that something else is happening that the framing doesn't quite reach.

This is a follow-on to last month's post on the coworker metaphor. That one argued the language we use for AI shapes the architecture we build. This one runs on a parallel axis: the language we use about skill shapes which loss we notice. The discourse keeps noticing the wrong one.

The Skill That Was Never Mine

What I do, when I'm building, isn't coding. It's a different kind of work entirely. Deciding what to build. Choosing what to keep and what to throw out. Knowing when something feels off while running tests and pilots. Knowing when to run a review pass and when to ship. Reading the result of a review and deciding which findings actually matter. Holding a portfolio of half-formed ideas, picking the ones that are ready to pursue, abandoning the ones that aren't.

That layer of work hasn't suffered any atrophy. It got room to operate. The syntax never being mine to lose meant it never had to compete with the work I was already doing — work where, at least for now, I'm providing a skill the model isn't close to fluent in. Birthing an idea. Iterating on it. Deciding which attributes to keep, and — more important still — which constraints to both work and deliver within.

I want to be careful here. I'm not saying the people worried about atrophy are wrong. I'm saying the worry presupposes an arrangement that doesn't describe every operator. From inside the arrangement — where the keyboard skill is yours and AI is being asked to share or take it — the loss is real, immediate, and worth defending against. From outside it — from a position where the keyboard skill was never the operator's in the first place — the question changes shape. It stops being how do I preserve this skill? and becomes is the apparatus around the work reliable enough that the work can be trusted?

That second question turns out to be the one that's been running the show all along. The skill question is downstream of it.

What the Trajectory Looks Like

Every abstraction transition I know about has roughly the same shape.

Two generations ago, owning a car meant being able to do basic work on one. Oil. Brakes. Fuses. Bulbs. The threshold for can I keep this thing running myself? was set somewhere most adults could reach. Today most car owners cannot. Modern drivetrains pushed even professional mechanics into something closer to operating diagnostics computers. The carburetor-tuning skill the previous generation took for granted has, for almost everyone alive now, simply gone away.

Nobody serious argues that today's drivers are worse drivers for it.

The early years of personal computing required syntax. To use a computer at all you needed to know commands, paths, sometimes a config file. The skill was load-bearing — without it, the machine was inert. Today nobody outside a small geeky subculture has any of it. We don't worry that ordinary users have lost something essential. The computer got reliable enough at the layer below that paying attention there stopped being where the value was.

And management, which is the most obvious case and somehow the least often invoked. A manager manages people doing work the manager themselves cannot do. We don't expect the head of engineering to be the best engineer in the room. We expect them to set direction, judge outputs, know when something is wrong without necessarily being able to fix it themselves. The competence sits one layer up from the production work, and we have an entire profession that exists at that layer without anyone seriously arguing it shouldn't.

In each of these three cases the cohort with the lower skill mourned its loss. The next cohort never had it and didn't notice. What stabilized the transition wasn't preserving the lower skill. It was something else.

What Carries the Upper Layers

Several things carry the upper layers. The one that keeps doing most of the work, across every transition I can think of, is a verification surface.

Cars don't require their owners to be able to tune the engine because warning lights, diagnostic codes, and inspections catch failures that owners used to catch by feel. The surface is mature, redundant, and adversarial enough that you can drive a modern car without ever knowing what's happening under the hood. If the surface ever stopped catching things — if cars started failing silently and dangerously — the whole arrangement would unravel. It doesn't, so it didn't.

Computing went the same way. The thing that made it safe for ordinary users to stop knowing commands wasn't that someone preserved their syntax skill on their behalf. It was that the layer underneath got reliable enough to ignore, and when it did fail, the failure showed up in ways the user could route around.

Management runs on the same principle. The reason it works for a manager to direct work they can't themselves do is that the work itself produces a steady stream of legible outputs — shipped features, missed deadlines, customer signals, team morale. A non-practitioner can read those and respond. Take away the legibility and management collapses into theater. Keep it intact and the lower skill becomes optional.

That's the apparatus I'm running on. When I ship an app, the verification surface around it is mature. Even as a non-developer, I intuitively reached for — and built — frameworks and guardrails to work inside. Integration tests catch categories of errors along the way. App Review catches others. Real use by real people on real devices catches others still. When all of that lets something through, I have a structured review pass I can run to find what slipped. The chain isn't perfect. It doesn't need to be. It needs to be reliable enough that attention can sit one layer up and trust most of what's coming through.

The atrophy story names a real threat, but I think it locates it one layer too low. The thing most in danger when AI starts producing the lower-layer work isn't only the operator's syntax skill. It's the verification surface around the lower-layer work. Build that surface — test it, harden it, make sure it catches the failure modes AI introduces — and the atrophy of the syntax skill stops mattering, in the same way and for the same reason it stopped mattering for carburetors. Skip building it, and no amount of write more of the code yourself really rescues you. You'll just be performing the lower skill while denying yourself a proper chance to build the necessary skills at the upper ones.

About the Current Prescription

There's a respectable position in the current discourse that goes roughly: leveraging AI is fine, but demote its role. Use it for planning more than for production. Write a meaningful share of the code yourself. Never ask the model to do what you couldn't do yourself.

I read that as the right move during a verification gap — and I think it's much of the right move, much of the time. It reads to me as transitional advice rather than permanent advice. When the surface around AI-produced work isn't yet reliable — when you can't yet trust review and tests and observability to catch the failure modes the model introduces — staying close to the keyboard makes sense. You become the verification surface, manually applied, until the real one is built.

What I'd be careful of is reading transitional advice as a permanent posture. The atrophy worry is real in the gap. It also tends to be self-correcting outside the gap, the way every prior abstraction transition seems to have been. The lower skill atrophies; the verification surface picks up the work the skill used to do; competence stabilizes at the layer above. Reading the gap-period prescription as a permanent law of how humans should relate to AI risks freezing the field at the worst moment of every transition — the moment before the surface is mature enough to trust.

The Middleground

The verification surface is uneven across domains. That's the part of this argument I want to hold open rather than close.

For shipped consumer apps with integration tests, manual use, store review, and an established review apparatus — mature enough that I trust it with my livelihood, and have for some time now. For static websites with the same kind of review chain — mature enough. For ad-hoc scripts and internal tooling that runs once and disappears — mature enough, because the cost of a failure is small.

For other domains it's thinner. High-stakes infrastructure. Anything safety-critical. Anything where the failure mode is silent corruption you only catch much later. The verification surface in those domains still needs to be built up around AI-produced work the way it was once built up around human-produced work — and in the meantime, that might mean making sure developers don't end up atrophying the skills the surface hasn't yet replaced.

The right question, in any domain, may not be should we let the lower skill atrophy? It might instead be is the verification surface around this work mature enough that attention can safely move up? Sometimes yes. Sometimes not yet. The answer changes domain by domain and year by year, and choosing how much to lean on AI in each case looks to me like a verification-surface question wearing the costume of a skill question.

The Inversion

The atrophy framing asks: what skill are we losing? It's a fair question to ask if your competence sits at the layer being abstracted. It's a smaller question if you're trying to understand what's happening to the work overall.

The question that matches the work overall is the inverse. The relocation question. What is the upper-layer skill being asked of us, and have we built it?

Because the load doesn't disappear under amplification — it moves up. It does so for the experienced developer who's offloaded the syntax, and it does so for someone like me, who never had the syntax to offload. The move through abstraction layers to what I've been calling upper-layer work is hard. It surfaces things you haven't yet had reason to expand into. It has no syntactic answer to look up. And it isn't automatically present just because the lower work got easier. Building it is the actual job.

From inside the atrophy worry, that question barely registers, because the framing has located the loss elsewhere. From the position of having skipped the skill being outsourced, it becomes hard to look away from. None of this is to claim that every abstraction transition has been clean, or that progress is the right word for everything that has followed one. Often it isn't, and we'd be foolish to pretend otherwise. What I'm saying is something narrower: the work that actually compounds tends to be waiting one layer up. Some of us were already there, working with what we could see from where we stood. Some are arriving now from below. Either way, the question we share is the upper one — not which skill we kept, but which one we're about to need.

---

What I cannot tell you from here is how this looks for someone who did have the syntax skill and is watching it go. That loss is real in a way I have no access to. What I can tell you is that the apparatus on the other side of the transition exists, that it works, and that the competence it asks of you is older and stranger than the skill being mourned.

---