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.
The Trap Is Comfortable
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.
The Gap These Tools Hide
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.
The Teacher You Fired
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.
Common Is Not Good
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.
You Are the Variable
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.
Top comments (1)
Exactly why my recommended architecture is to make AI a senior dev only tool. Juniors should spend their time: 30% studying a niche, 20% support tickets, 50% code-review, with monitored AI usage, to make sure they dont just run claude and call it half a day's tea break... Senior developers can spot patterns, identify risks and scope tasks structurally sound, so the AI while diluted in skill vs them, can produce production ready code by the time they commit.
This flips the paradigm of the manager + brick layers, to a factory + QA test line, where the QA will eventually scale to be their own factories with their own respective QA lines.
Not only does it provide a speedup, but it makes the switch from junior to senior all the more monumental, because that's the day you stop finding and fixing and start creating. But you do so with expert level knowledge in your domain and years of experience distilled into you from reviewing the seniors' code. You will see how they spec the task, you will understand why they did it that way and you will learn to spot the difference between production ready code and a leak.
In the current environment, it's the only sustainable way to use AI, because 100 monkeys on typewriters with auto correct still produce garbage 99% of the time.