The Most Confident Voice in the Room
AI is wrong in exactly the same tone it uses when it's right. That's survivable if you have twenty years of scar tissue. It's a much bigger problem if you're six months in.
I use AI every day. Not as an experiment, not as a novelty, just as part of how the work gets done now. And the thing I’ve come to find most difficult about it isn’t the hallucinated package names or the code that doesn’t compile. Those are easy. They announce themselves.
It’s that I have to argue with it.
It happens most weeks. I’ll say something is wrong and get back a confident, well structured, entirely incorrect explanation of why it’s fine. Not hedged. Not uncertain. Confident, in exactly the same tone it uses when it’s right, because the tone doesn’t change with the accuracy.
Usually I win those arguments, and I want to be clear about why. It isn’t because I reasoned better in the moment. It’s that I have twenty something years of scar tissue telling me when something smells wrong, and a stronger prior built out of every previous time I’d seen that shape of mistake. I held my position long enough to go and prove it.
That’s a daily, ordinary part of using these tools. It’s fine when you have the background to push back. Then I thought about what that same conversation looks like for someone six months into their career, and I’ve been uneasy about it ever since.
Confidence Is Not a Signal Anymore
For most of my career, confidence carried information.
If you asked a senior developer a question and they said “definitely, it’s the connection pool,” you could weight that differently to “hmm, maybe check the connection pool?” The hedging was data. People sound less sure when they are less sure, most of the time, and you learn to read it. Team meetings, code reviews, pairing sessions, all of it runs on that signal.
An LLM breaks the link entirely. The output is fluent whether or not it’s correct. There’s no tell. No pause, no “actually, hang on,” no getting quieter as it reaches the edge of what it knows. It will invent a function that doesn’t exist in a library and describe its parameters with the same steady authority it uses for the parts it has genuinely seen ten thousand times.
If you’ve been doing this long enough, you’ve already decoupled confidence from correctness. You’ve worked with the guy who is certain about everything and right about half of it. You’ve been that guy occasionally. You have other signals to fall back on.
A junior developer hasn’t built those yet. They’re being handed a tool that sounds exactly like the most senior person they’ve ever spoken to, and it sounds like that all the time.
How People Actually Learned Before
Being a junior developer used to involve a lot of being stuck.
You’d hit a problem, flail at it for two hours, try four things that didn’t work, and eventually either get there or go and ask someone. The flailing felt like waste. It wasn’t. That was the part where you built the model. Every failed attempt taught you something about how the system actually behaves, and the frustration is what made it stick.
Then you’d raise a PR, and someone more experienced would tell you why your approach was going to cause a problem in six months. That stung a bit and it was also the fastest learning available anywhere. You’d carry that comment for years.
Both halves of that loop are under pressure now.
The stuck part largely disappears. You describe the problem, you get something that works, you move on. Nothing gets built in your head because nothing needed to be. Speed goes up, understanding goes sideways.
The review part is thinner too, because when a diff looks tidy, has sensible variable names and passes its tests, reviewers skim. I’ve watched it happen. The reviewer isn’t lazy, there’s just no visible reason to look harder, and the code doesn’t have the usual junior tells that make a senior slow down and read properly.
So you end up with a junior who is shipping more, being corrected less, and learning at a fraction of the rate, while every visible metric says they’re doing great.
The Argument Nobody Warns Them About
The bit I keep coming back to is the disagreement.
At some point the tool will tell a junior developer that their instinct is wrong. Maybe their instinct actually was wrong, which is fine and normal. But sometimes they’ll be right, and they’ll get a paragraph of confident, well organised, plausible reasoning explaining why they aren’t.
What happens then?
They’re six months in. They’re already braced to be the least knowledgeable person in the room. They’ve spent every previous conversation learning that when someone explains something clearly and confidently, the correct move is to update. So they update. That’s not a character flaw, it’s exactly the instinct you want in a junior most of the time.
The problem is they have no way to tell this case from the ninety others where deferring was right. They have no priors. Priors are built from having been burned, and being burned takes time and mistakes, which is precisely what the shortcut removes.
So they defer, the wrong thing goes in, and it works well enough that nobody finds out for months. And they learn a small false lesson: that their instinct was wrong, when it wasn’t. Do that a hundred times and you haven’t just failed to build judgement. You’ve actively trained it out.
The Pipeline Problem
There’s a business version of this that I think gets underrated.
The tasks AI handles most convincingly are, almost exactly, the tasks we used to give juniors. The small self contained ticket. The CRUD endpoint. The bit of glue between two systems. The tidy up. Those tasks were never about the output. They were the training ground where somebody spent two years failing safely and turning into a mid, and then a senior.
If you delete the training ground because a tool can produce the artefact faster, you get a short term win and a medium term hole. Every organisation still needs people who can hold a system in their head, judge blast radius, and tell when something is confidently wrong. Those people are currently made by doing the boring work badly for a while and being corrected. Nobody has shown me another way to make them.
You can’t hire your way around it either, at least not for long. Everyone is drawing from the same pool of experienced developers and nobody is refilling it. That’s fine for a couple of years. It isn’t fine for ten.
If You’re the Junior
I don’t want this to read as “you’re doomed,” because you aren’t. The people who come out of this era with real judgement will be the ones who were deliberate about it, and being deliberate is entirely available to you.
Struggle on purpose, sometimes. Not always, you have work to do. But pick things and try them yourself first, with the assistant closed, and give it a proper go before you ask. The discomfort is the mechanism. If you never feel it, nothing is being built.
Ask it to explain, then check the explanation against the actual code. The explanation and the code disagree more often than you’d expect, and the gap is where the bugs live. Doing this also forces you to read the code, which is the whole game.
When you disagree, get to a fact. Don’t argue in prose, because you will lose an argument in prose against something that generates prose for a living. Run it. Write a test. Check the documentation directly. Move the disagreement onto ground where being right is demonstrable rather than persuasive.
Keep a note of every time you were right and it was wrong. This sounds petty and it isn’t. That list is how you calibrate. It’s the fastest available substitute for the years of scar tissue you don’t have yet, and it will be longer than you expect.
Get your work read by a human who will be honest with you. Actively ask for it. A reviewer who tells you why your approach will hurt in six months is worth more to your career than any amount of shipped tickets, and that kind of review is getting rarer, so go and ask for it directly.
If You Lead a Team
Two things, and neither is complicated.
Review juniors’ code properly, especially when it looks good. The old signals for “this needs a careful read” don’t fire anymore. Tidy formatting and green tests used to correlate with care. Now they correlate with nothing at all, so you have to spend the attention deliberately rather than waiting to be prompted by something looking off.
Protect some work as learning work. Accept that a junior doing a task by hand is slower than the alternative and do it anyway, on purpose, on tasks where slow is affordable. You’re not buying the ticket. You’re buying the developer they turn into, and that has always been the actual return on hiring juniors.
The Bit That Worries Me
The tooling produces the most confident voice in the room, and it hands that voice to the person least equipped to challenge it.
Learning to code has always meant being wrong a lot and finding out why. If the finding out gets replaced by an authority that’s wrong about as convincingly as it’s right, the loop breaks quietly, from the inside, in a way that looks like productivity the whole time it’s happening.
The answer isn’t to keep juniors away from these tools. That’s neither possible nor useful. It’s to be honest with them about what the tools are: enormously capable, genuinely useful, and completely incapable of sounding unsure when they should.