Nobody Learns to Ride With the Wheels Bolted Down

Last summer I built an AI chatbot almost entirely in Claude Code. It worked. I never pushed it to GitHub. I felt that putting my name on a public repo felt like making a claim I couldn't back up.

There is a particular kind of quiet that follows building something you don't feel entitled to. No matter how rewarding the project feels, somewhere behind your ribs a voice says: you didn't actually do that. If you've felt it, you already know the argument I'm about to make against.

The stigma, stated fairly

The criticism deserves better than a strawman, so here it is at full strength. Skill comes from struggle. When you sit with a bug for three hours, you're not just fixing the bug - you're building a mental index of how this kind of thing breaks. The frustration is the encoding mechanism. Hand the struggle to a model and you get the fix without the index. Do that a thousand times and you've shipped a thousand features while learning almost nothing, and you won't find out until the day the model is wrong and you have no idea it's wrong.

There's a second, harsher version: that AI-dependent developers are pricing themselves as engineers while functioning as typists, and the industry hasn't caught up yet.

I think both of these are pointing at something real. I just think they've misidentified the cause.

The real failure mode

Here's the honest part, and I want to say it before the defense, because a defense that skips it isn't worth much. AI absolutely can make you worse. I've watched it happen, and I've done it.

The mechanism is specific: you accept output you haven't read. That's it. That's the whole failure. Not "using AI" - accepting without reading. It's seductive because it works. The code runs. Nothing punishes you. You get a small hit of progress and you move on, and the debt is invisible because the thing you failed to learn doesn't announce itself. You only meet it later, usually at 11pm, when something breaks in a layer you never looked at.

A developer in that loop isn't a weak coder using a strong tool. They're a person who has outsourced the part of the job that was the job. So yes. The critics are describing a real animal. But look at what they're describing: passivity. Not assistance.

Why training wheels are the right metaphor - and why most people use it wrong

People reach for the training-wheels comparison constantly, and they almost always use the lazy version: you start with support, then you take it off, happy ending.

The interesting thing about training wheels is that they're a genuinely mediocre teaching tool when used badly. They don't teach balance. They teach pedaling and steering while actively preventing the thing that matters. A kid whose wheels stay bolted at the same height for three years does not slowly become a cyclist. They become very good at riding a four-wheeled vehicle. Take the wheels off and they fall over exactly as hard as on day one.

The reason training wheels ever work is that a parent raises them. Half an inch at a time. The bike gets tippier, the kid gets uncomfortable, and the discomfort is the point - it's the balance loop finally getting a signal to learn from.

That's the whole argument, and it's not "AI is fine." It's this: AI is a support that only helps if you keep raising it. Bolt it at one height and it will quietly hold you at the skill level you had when you started.

What raising the wheels actually looks like

Concrete, because the abstract version is useless. These are the rules I've converged on. They cost time - that's not a bug, it's the entire price of the thing.

• Read every line before you accept it. Non-negotiable, and it's the one that does most of the work. Not skim - read. If you hit something you can't explain, you've just found the most valuable thirty seconds of your day.
• Ask "why this and not the obvious thing." Models produce the shape of an answer without the reasoning that selected it. Make it show its work. "Why a queue here instead of a direct call?" The answer is where the actual learning is, and sometimes the answer reveals the suggestion was wrong.
• Write the hard part first, then compare. Before asking, take your own swing at it. Even a bad swing. Then diff your version against the suggestion. This is the single highest-yield habit on this list, and the one people skip, because it's the only one that requires being wrong in front of yourself.
• Rebuild it from memory later. A few days after, close everything and implement the same thing cold. You'll discover fast whether you learned a pattern or just witnessed one.
• Pick a no-AI zone. Something small and regular - a side project, one category of task, a weekend. Not out of purity. Because you need a place where you find out what you can actually do, without the safety net telling you a comfortable story.
• Notice what you stop struggling with. Keep a rough sense of it. The things that used to require help and now don't - that's the wheels coming up. If nothing has moved in six months, you're bolted down.

None of these are about using AI less. They're about staying in the loop the learning happens in.

Where you actually land

Here's the part the metaphor gets slightly wrong, and I'd rather say it than sell you a tidy ending. You don't end up riding a bare bike. Nobody does. Adults who ride seriously have gears, clipless pedals, a power meter. What changed isn't that they use less equipment - it's that every piece of it is now serving their judgment instead of substituting for it.

That's the destination. Not "I no longer need AI." It's: the model does the work I've already proven I can do. Boilerplate. The fourth CRUD endpoint. The regex I understand perfectly and refuse to hand-write ever again. Migration scaffolding. Test fixtures. Volume, not judgment.

And the difference between that developer and the dependent one is invisible from the outside. Same tools. Same output, roughly. The difference is entirely in what happens when the model is confidently wrong - whether you catch it in four seconds or ship it. That's the only skill that ever mattered, honestly. It's just that now there are two ways to fail to build it: never using the tool, and never raising it.

If you're at the start of this

You're allowed to use the training wheels. Being a weak coder with a strong tool is not a moral failing, it's a starting position, and the people making you feel bad about it mostly learned in an era where the alternative to struggling alone was struggling alone.

But treat the support as temporary by design. Raise it deliberately, on a schedule, before you feel ready - because you will never feel ready, that's what makes it a balance problem. The goal was never to ride without help. It was to be the one steering.