Stop typing. Don't stop understanding.

Here is the bet, and it is the one that makes engineers angriest: stop coding by hand. Typing speed, editor golf, the muscle memory of syntax. That skill is depreciating, fast, and the people who defend it are defending the wrong thing.

I still write that sentence knowing how it gets misread. The loud version going around, “never read code again, just accept the diffs, ship the vibes,” is where people wreck themselves. I mean stop hand-writing code as the default way you produce it. I do not mean stop being a programmer. So let me make the actual case, including the part that says exactly when this bet gets you fired.

What were you ever paid for?

Not typing. Nobody ever paid you to move your fingers. John Carmack, who has written more load-bearing code than almost anyone alive, put it flatly: “‘Coding’ was never the source of value… Problem solving is the core skill.”¹

The keyboard was always a means. For decades it was the only way to turn a decision into a running system, so it felt like the job. It was never the job. The job was deciding what to build, breaking it down, judging whether the result is any good, and owning it when it breaks. Typing was the tax you paid to do that.

The tax has been paid down before

We have done a version of this before, more than once, and the objection was always the same.

Through the early 1950s, real programmers wrote machine and assembly code, and they were good at it. John Backus, who then led FORTRAN, remembered them as people who “regarded their work as a complex, creative art that required human inventiveness to produce an efficient program.”² When FORTRAN’s compiler shipped in 1957,³ the assembly priesthood was sure no machine could match a human’s hand-tuned output. They had a point, for a while. Then the compilers got good enough that almost nobody writes assembly by hand anymore.

Each rung up the ladder, we stopped needing to think about the layer below by default. Assembly programmers stopped tracking raw opcodes. C programmers stopped counting registers. Most Python programmers stopped thinking about memory at all, until the day they have to. That was not a loss, because abstraction is not vagueness. Dijkstra put it well: “the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.”⁴ You did not get sloppier. You got precise about different, higher things.

Natural language is, the argument goes, just the next rung. IndyDevDan calls it plainly: “the prompt is the new fundamental unit of knowledge work & programming.”⁵ Karpathy, coining “vibe coding,” said the quiet part out loud: “I don’t read the diffs anymore.”⁶

Honesty forces a caveat here, because this is the strongest case for the bet and also its weakest point. The earlier rungs were deterministic. The compiler produced correct output every time, and you could trust it without reading its assembly. The model does not, and you cannot. Natural language is not yet a clean abstraction layer the way C sits over assembly. Right now it is closer to delegating the work to a fast, capable, unreliable collaborator. That difference is the whole reason the next section exists.

The part that is actually depreciating

So the strong, defensible claim is this. The skills that were pure tax are losing their value, and they are losing it quickly:

• Remembering whether it is Array.from or Array.of.
• Typing 120 words a minute.
• A twelve-plugin editor config that shaves seconds off a motion you will soon not perform.
• Holding an entire framework’s API surface in your head.

These were real skills. They separated good engineers from slow ones. They are becoming what knowing the Dewey Decimal System is to a librarian: a fading craft, not the value. Steve Yegge, not a lightweight, is blunt about the cost of clinging: “you are getting left behind if you do not adopt chat-based programming as your primary modality,” and the holdouts look “like one of those crusty old assembly-language holdouts still using asm in 1990.”⁷

I believe this. I make myself live it. I will get to how. But if I stopped here I would be selling you the dangerous half.

Where the loud version gets you fired

The failure mode is not “stop typing.” It is “stop understanding.” And there is a forty-year-old result that explains exactly why that kills you.

In 1983 Lisanne Bainbridge described the “ironies of automation.” Automate the easy part of a task, and you leave the human the hard part: monitoring the automation and taking over when it fails. Worse, “physical skills deteriorate when they are not used,” so the person you left in charge of catching the failure is losing the very skill needed to catch it. Her punchline scales straight into 2026: “the more advanced a control system is, so the more crucial may be the contribution of the human operator.”⁸

This is not theory. It shows up in the numbers as soon as you look.

• METR ran a real randomized trial with experienced open-source developers in early 2025. With AI tools, they were 19% slower. They had forecast a 24% speedup; afterward they still believed they were 20% faster.⁹ They could not even feel the loss.
• GitClear measured 211 million lines of changed code. Refactoring, the sign of someone understanding and improving a codebase, fell from 25% of changes in 2021 to under 10% in 2024, while blocks with five or more duplicated lines rose eightfold. More code is being generated and pasted; less of it is being read back and consolidated.¹⁰
• Google’s 2024 DORA report found that a 25% rise in AI adoption tracked with a 7.2% drop in delivery stability.¹¹
• Veracode found that nearly half of the AI-generated code it tested, 45%, introduced a security vulnerability.¹²
• Replit’s agent, mid-task, deleted a live production database, ignored the code freeze it was told to respect, then misrepresented what it had done.¹³ Google’s Gemini CLI destroyed another user’s files during a botched move operation.¹⁴

Simon Willison, who coined the responsible framing, draws the line where it belongs: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”¹⁵ Addy Osmani names the debt you take on when you skip that. AI gets you the first 70%, and the last 30% is where the returns diminish;¹⁶ and, as he puts it, “if your ability to ‘read’ doesn’t scale with the agent’s ability to ‘output,’ you’re not engineering anymore. You’re hoping.”¹⁷

Stop typing. Move your judgment up and out.

Put the two halves together and the honest bet is narrower than the slogans, and I think correct. Drop the keystrokes. Keep the judgment. Build the system that catches wrong before it ships.

Your understanding moves in two directions at once. It moves up, away from syntax and boilerplate and toward what good looks like: the architecture, the constraints, the failure modes, the answer to “is this the right thing, built the right way.” And it moves out, into a verification system you own and trust, so that catching a mistake stops depending on you having hand-read every line.

That second direction is the part most “keep understanding” takes miss. I often cannot see what is wrong with a piece of code by staring at it. But I can point a stronger model at it, and it finds the bug I would have walked past, and fixes it. A capable reviewer model, a real test suite, types, a staging environment, backups, a one-command rollback: these are not a discount on rigor. They are where the rigor now lives. The question stopped being “do I personally understand this line” and became “does something I trust check it before it can hurt anyone.” And that trust has to be earned, not assumed. A verifier is worth delegating to only once you have watched it catch the things you would have caught, and learned where it goes blind. An unvalidated reviewer, human or model, is not a safety net. It is a second guess. Lose that whole apparatus and you are not fast, you are just wrong at scale with nothing to catch it.

Even the people furthest out on this hold the line somewhere. IndyDevDan, whose whole brand is automating himself out of the keyboard, still keeps a principle called “stay close to the metal.”¹⁸ The move was never ignorance. It is relocation. Attention goes up, from how do I type this to is this the right thing, built the right way, and how will I know when it breaks.

Stop typing, and you get faster. Stop understanding, and you get wrong at scale.

The real question is not whether you understand the code

It is whether, if the code is wrong, something you trust catches it before it reaches anyone who matters. Reading it yourself is one way to catch wrong. It is not the only way, and for a lot of work it is no longer the best one.

So the line that decides how much care a change needs is not blast radius alone. It is blast radius minus your safety net. A large blast radius with backups you have actually restored from, a staging environment, a stronger model reviewing the diff, and a one-command rollback is survivable. A small-looking change straight to production with none of that is not, however carefully you read it.

This is why most of the real work on production systems is not reading diffs. It is making the system verifiable and the damage survivable: good DevOps, backups you have tested, sandboxes, canaries, staged rollout, the checks that stop a bad change before it ships. You are not paid to understand every line. You are paid to understand the system that ships the lines, and to make sure a wrong one cannot quietly take down production. Skip that and you get the Replit story: an agent with production access, no guardrails, and nothing to undo it.

The trap is thinking the net is optional because the model sounds confident. It is the reverse. The more of the typing you hand off, the more the net is the job.

The bet, and how I run it

I force myself off the keyboard on purpose. Not because typing is beneath me, but because the old habit is sticky, and the only way I found to build the new muscle, directing and judging and wiring up the checks instead of hand-crafting, was to take the crutch away. When I catch myself reaching to hand-edit, I stop, make the loop do it, then verify: my own read, a stronger model’s review, the tests, the staging run.

That is the skill I am compounding: specify precisely, judge ruthlessly, define done, and build the system that makes a wrong answer cheap to catch and cheap to undo. The typing was never the moat. The judgment is, and so is the machine you build around it.

The verification story is not finished, and I could be early; early has felt identical to wrong before, for uncomfortably long. But I would rather build this muscle now, while typing still feels like a loss, than keep defending a craft that is turning into calligraphy. Beautiful. Optional. Not the job.