← Back to writing

Don't outsource the thinking

Developers are starting to refuse to work without AI. The tools were never the problem — handing over the part that thinks is.

Generated code in a terminal passing into a verification check

A small study made the rounds last month. Researchers wanted to measure how developers work with and without AI assistance, and they hit a wall: people didn’t want to take part, because the study meant coding without their tools for a while. Not “preferred not to.” Wouldn’t.

That detail stuck with me more than any benchmark. In a couple of years we went from arguing about whether AI belongs in the workflow to a point where some of us won’t sit down without it.

I’ll say up front that I’m one of the heavy users. I work with coding agents every day. The productivity is real. Surveys now put adoption north of 80%, with about half of us reaching for these tools daily, and those numbers match what I see in my own week. The old debate about whether to use AI is over. It’s a calculator. Nobody goes back to long division to prove a point.

So this isn’t a lecture about using less of it. It’s about a quieter line: there is a difference between using a tool and not being able to work without one. The first is leverage. The second is a dependency, and dependencies tend to charge interest later.

The thing worth protecting isn’t typing speed. It’s the thinking. By that I mean understanding the problem well enough to know what “correct” even looks like — holding the shape of the domain in your head, the rules, the states, the things that must always be true, so that when the model hands you forty plausible lines you can tell at a glance whether they’re right or just confident. I’ve written before that I model the domain before I touch a framework. That habit matters more now, not less. The agent is genuinely good at the second half of the job: scaffolding, wiring, boilerplate, the translation from intent to syntax. The first half — deciding what should be built and why — is still yours. Hand that over and you’re not driving anymore. You’re a passenger who can’t read the map.

Atrophy is the part nobody puts on the pricing page. Skills you stop using fade; it isn’t a moral failing, it’s just how skills work. If the whole loop becomes prompt, skim, accept, regenerate, the muscle that evaluates code quietly weakens. And evaluation is exactly the thing you can’t delegate to the tool that produced the answer. There’s a cost on the other side too. Code arrives faster than ever, but as one engineer put it, if you’re writing it twice as fast you’d better have halved the maintenance, or you’ve traded a short speed boost for a long obligation. Generated code is still code you have to own, debug at 2am, and explain to whoever inherits it.

I worry most about people starting out. One Stanford analysis found employment among developers aged 22 to 25 dropped nearly 20% between 2022 and 2025. Put the job numbers aside for a second and the deeper problem is this: the scaffolding that used to be how a junior learned the shape of a system is now done for them before they understand why it’s shaped that way. You can ship without ever building the model in your head. That works right up until something breaks in a way the agent can’t see, and nobody in the room has the map either.

None of this is an argument to slow down. It’s an argument to keep one foot on the ground. A few things I try to do, and would tell anyone earlier in their career:

  • Keep one thing you still build by hand. Doesn’t have to be work — a side project, a hard bug, anything where you do the whole loop yourself.
  • Read the diff like you’ll have to defend it in review, because you will.
  • Model the domain yourself before you prompt. The clearer the model you hand the agent, the better the code that comes back. Hand it a fuzzy model and you get confident nonsense.
  • Let the compiler and the tests hold the rules — not your memory, and not the model’s.
  • Vibe, then verify. Generate fast, then slow down and actually read what came back.

The goal was never to use AI less. It’s to stay the kind of engineer who can tell whether the AI is right — and to still be that person on the day the tool is down, or the model is confidently wrong about something that matters. Use the tools, all of them. Just don’t hand over the part that makes you worth listening to.