Typing was never the bottleneck

Lately I notice that writing code by hand has become a statement. Some developers proudly declare that they still type their own code, and others dismiss them as dinosaurs, like lumberjacks who still swear by the axe. The opposite camp calls AI output unmaintainable slop and predicts that handmade code will become the new mark of quality.

Both camps miss the point, I think. In my experience, the real question is not who types the code, but who does the thinking.

Thinking is the slow part

Typing code was never the slow part of my work. Thinking was, and still is. The more of that thinking I hand to a tool that has no persistent memory of my project and no stake in its future, the harder it becomes to do that thinking myself when it really matters. Going all-in on agents does not automatically make me faster; on complex work I find it can even slow me down.

After thirty years in this field, I know where the hours in a project go. Never into the keystrokes. They go into understanding the problem, choosing between approaches, and figuring out why something that should work doesn't. AI can make the keystrokes nearly free. It does not make the thinking free. It only makes it easier to skip.

AI makes trade-offs without asking you

I have learned that an LLM will make trade-offs without consulting me. Sometimes that is convenient. Often it is a bug waiting to happen, because a decision made up front can have consequences that only surface months later. And on complex tasks, I have seen a model report that it implemented something that, once I read the code, it clearly had not.

This is exactly where experience earns its keep. Knowing which trade-offs matter, spotting the decision that will hurt you in six months: that is thinking work, and it stays our job.

Where AI does shine

None of this means I want to go back to a pre-AI world. I use AI for brainstorming, reviewing my own code, prototypes and one-off experiments. The workflow that works best for me: I design the architecture myself, ask the LLM to find flaws in it before any code is written, and only then let it implement the plan. The thinking comes first and stays mine; the typing gets delegated.

I also like to write the edges between modules by hand, the interfaces and public function signatures, and let AI fill in the rest. The parts that encode my design decisions are the parts I want to own.

No logging company clears a forest by hand when a harvester is available. But the lumberjack still needs his axe, for the tree leaning over a house or the one standing too close to a railway track. The skill is not choosing between the axe and the machine; it is knowing when to switch.

Keep your thinking muscles in shape

I have noticed that the further I get from writing code, the worse I become at reviewing it. After a stretch of only prompting and reviewing, a codebase starts to feel alien, even when I guided and approved every change. Skills do not disappear overnight, but they do quietly fade.

That is the real risk as I see it. Not that AI writes bad code, but that we slowly lose the understanding needed to tell good code from bad. To me, the best indicator of a strong developer is not writing skill but debugging skill: the ability to step through code, understand what it actually does and find where it goes wrong. You only keep that skill by staying close to the code.

Slow down where it counts

In a previous blog, Slowing down to speed up, I argued that clean code is not a luxury, and that AI makes this more important rather than less. Use AI to go fast where it is safe: boilerplate, prototypes, a second pair of eyes. But keep the design decisions, the trade-offs and the understanding in human hands. Write the parts that matter yourself when that helps you think.

The question is not whether you type the code or a model does. The question is whether you still understand, and still decide, what your software does. Typing was never the bottleneck. Thinking is, and that is exactly the part worth protecting.