Copilot Is Training Wheels You Should Eventually Remove
The Freeze
The thing that worries me isn’t developers using AI tooling. It’s what happens when it isn’t there.
The network drops, or the service is down, or the problem is novel enough that the suggestions come back as confident nonsense. And some people simply stop. Not “this is slower now”, but a genuine stall, because the first move was always to start typing and see what got offered, and without that there’s no second move.
That’s the tell. The tool hasn’t made them faster, it’s moved into the space where their process used to be.
What Good Looks Like
The developers I rate most use these tools constantly and it doesn’t appear to cost them anything. The pattern is fairly consistent:
- They read what gets suggested before it goes anywhere near a commit
- They could have written it themselves, and know roughly how
- They point it at the boring work and keep the interesting work
- They treat every suggestion as a draft from somebody unreliable but fast
That last one is the whole thing. Not distrust exactly, just the ordinary scepticism you’d apply to code from a stranger who is often right and occasionally spectacularly wrong, with no change in tone between the two.
The Muscle You’re Outsourcing
Here’s what I think actually withers, and it isn’t typing.
It’s the sit-with-it muscle. The willingness to stare at something you don’t understand, form a theory, test the theory, and be wrong four times before you get there. That process is genuinely unpleasant, and it’s also the only way anyone builds a mental model deep enough to handle problems nobody has written about yet.
Tab-accepting is a way of skipping it. And it works, right up until you hit something novel, at which point you find out you never built the thing that would have got you through.
Which is why I’d push anyone early in their career to write the hard parts by hand even when they don’t have to. Not for purity. You’re buying judgement, and judgement is what makes you worth hiring in five years.
Maybe This Skill Stops Mattering
The honest counterargument, and it isn’t a weak one.
Nobody laments losing the ability to code without autocomplete. Or without version control, a package manager, a debugger. We built abstractions, the skills underneath became specialist rather than universal, and the world carried on perfectly well. Perhaps “writing code unassisted” joins that list and this post ages like milk.
There’s also something tiresome about gatekeeping real programming. If somebody ships working, maintainable software that solves an actual problem, arguing about how they got there is mostly ego.
Where I Might Be Wrong
I’m assuming the tools stay roughly as they are. If they get reliably good at genuinely novel situations then the understanding layer I’m defending matters much less, and this reads as nostalgia.
Depth also depends on the job. Someone building custom systems from scratch needs to understand every layer. Someone assembling well-documented services to solve a business problem legitimately doesn’t, and pretending otherwise is snobbery with extra steps.
The goal is AI-augmented skill, not AI-dependent incapacity.
How to Keep the Muscle
- Turn it off occasionally. A morning a week is plenty. Notice what you reach for
- Understand before accepting. If you can’t explain why it works, don’t merge it
- When it’s wrong, work out why it was wrong. That’s free debugging practice
- Learn the concept underneath, not the shape of the suggestion
- Do something in an unfamiliar language by hand now and then. It’s uncomfortable, which is the point
- Read far more code than you generate
The people I’ve watched grow fastest use these tools to move quickly, then deliberately slow down to understand what they just shipped. The slow step is the one that compounds, and it’s the one everybody skips.
Until next time, happy coding!