AI Won't Make You a Better Developer

A developer argues that AI coding assistants like Claude Code can make developers faster but not better, warning that the tools remove the friction necessary for deep learning and skill development. The developer contends that AI outputs the 'common' rather than 'good' code, and that relying on it can prevent engineers from building the understanding needed to handle complex problems.

The AI tool doesn't know what good looks like. It knows what common looks like. If you're thinking clearly about the problem, it'll help you build the right thing fast. If you're not... it'll help you build the wrong thing fast. Same tool. The difference is you. That's the uncomfortable version. And it's the whole point of this post. You sit down with Claude Code, describe what you want, and twenty minutes later there's a working feature on your screen. It feels incredible. It feels like you just got better at your job. That feeling is the trap. Something did get better in that moment. It just wasn't you. Your output got better. Your speed went through the roof. But speed is not skill, and output is not understanding. You moved faster across ground you didn't actually learn. It's the difference between driving to the top of a mountain and climbing it. You get the same view in the photo. Only one of you can find the way back in the dark. There's an idea from Ira Glass — he calls it the gap. When you start out, your taste is good before your skill is. You can tell that your own work isn't as good as the thing you admire, and that gap, that frustration, is what pulls you forward. You close it by doing the work, over and over, badly, until one day it isn't bad anymore. Now look at what AI does to that picture. It doesn't close the gap. It hides it. It produces work at a level your taste can recognize as decent — but your hands could never have reached on their own. So the frustration that used to drive you disappears, and the daily reps that used to close the gap... you just stop doing them. The output looks like a senior wrote it. You did not become a senior. And the thing that would have made you one is the exact thing you skipped. Most of my education came from my own mistakes. Fifteen years in, almost everything I actually know, I know because I broke it first. I wrote the slow query that took the site down. I built the abstraction that everyone hated. I shipped the bug, traced it for two days, and finally understood the thing I thought I'd already understood. The struggle wasn't in the way of the learning. The struggle was the learning. When the AI removes the friction, it doesn't just save you time. It quietly removes the teacher. The hard part — the part where you sit there confused and have to build the model in your own head before the code will work — that part is doing something to you. Skip it every time, and yeah, you'll ship faster this quarter. But the version of you that could have handled the gnarly problem two years from now never gets built. You optimized away your own apprenticeship. Back to that first line, because it's the load-bearing one. The model knows what common looks like. Not what good looks like. Common is genuinely useful — the most common way to do a thing is usually fine, often even right, and getting "fine" in twenty seconds is a real gift. I use it every day. But picture what the model actually is. It read a planet's worth of code and learned the average of it. When you ask it for something, it hands you back the middle of the distribution. The median answer. Good code — the code you actually admire — almost never lives in the middle. It's a deviation. It's somebody who understood this specific domain well enough to do the uncommon thing on purpose, because the common thing was wrong here . The model can't make that call. It doesn't know your domain. It's pulling toward the average while the whole point of expertise is knowing exactly when to leave it. If you can't tell common from good, you will ship common forever, and you'll think it's good, because it compiles and the tests pass and it looks like everything else you've ever seen. So if the tool won't make you better, what will? Two things. Same two things the good developers were already doing before any of this showed up. The first is understanding over producing. Stop measuring yourself by how much you shipped and start measuring yourself by how much of it you could explain, out loud, to a skeptical room. Read the code the AI gives you like you're going to be quizzed on it — because someday you will be, probably at two in the morning. Trace why it made the choices it made. Use the tool to go fast on the things you already understand cold, and force yourself to do the hard part by hand on the things you're still learning. That's not nostalgia. That's just keeping the teacher employed. The second is thinking clearly before you open the chat window. Domain-Driven Design, Clean Architecture, the SOLID principles — I think of all of it less as a set of rules and more as a way of getting honest about the problem before you let the machine run at it. Because an amplifier makes whatever you feed it louder, and it does not care whether what you fed it was any good. Feed it muddy thinking and you get a beautiful, fast, well-tested mess. Feed it a clean model of the problem, in the language the business actually uses, and the same tool is suddenly building exactly the right thing. Same tool. You're the variable. You were always the variable. Watch the full episode — visuals, the specific framework I use before starting any AI session, and the question I'm asking in the comments: The Thinking Engineer — one channel, one bet: AI can write the code now, but somebody still has to understand it. That somebody is the job that isn't going away.