Sean Goedecke wrote a piece I keep thinking about: AI makes weak engineers less harmful. The argument is simple. Engineering output is heavy-tailed. The best people ship far more than average, and the worst can be net-negative, creating messes other people clean up. AI tools raise the floor under those weak engineers, so the messes get smaller. He's right. I want to add what it looks like from the chair I actually sit in: reviewing the pull requests.
Here's the short version of what changed, and the part nobody likes saying out loud. If your whole contribution is pasting tickets into Claude and pasting the answer back, you just became the cheapest line item on the team. That's not a threat. It's arithmetic.
What "net-negative" actually meant before AI
I lead engineers. Some weeks the hardest part of the job had nothing to do with code. It was making sure the load-bearing work landed with people who wouldn't break it.
A net-negative engineer isn't lazy or stupid. Usually they're out of their depth on this particular system, moving fast, and confident. The output looked like work. A pull request would show up that couldn't possibly run, or that would quietly corrupt something in production three weeks later. So you'd review harder. You'd sit on their shoulder. You'd hand them the safe pieces and route the scary ones elsewhere. Whole management styles exist to absorb that one person.
That tax was real. It just never showed up on any dashboard.
The floor moved. I can feel it in review.
Then coding agents got good, and the bottom of the distribution lifted.
The worst PR I see now is a standard LLM pull request. Wrong in places. Baffling in others. But it runs on the line-by-line level, and it's not the kind of obvious broken that anyone could spot in two seconds. For the weakest engineer on a team, that's a massive jump in baseline quality.
You can test this yourself. Try to make a dumb mistake on purpose with a coding agent. Cache user data under a key that isn't user-specific. Write a loop with no exit. Leave a file handle open. The agent fights you. It pushes back on the obvious stuff before you can ship it. What it still misses is the subtle thing: the bug that only makes sense if you understand three other parts of the codebase it never read. I wrote a whole method for catching those: how to fix any bug with the repro-first approach. The agent is good at local correctness and blind to system context. So is the engineer leaning on it.
So my review load shifted. Fewer "this can't possibly work" rejections. More "this works, and it's wrong in a way that takes me twenty minutes to explain."
Working with the engineer is now working with Claude over Slack
Goedecke nails the weird part. Working with the least effective engineers now feels like talking to a Claude instance over Slack. Sometimes it literally is. You send a question, your colleague pastes it into Claude Code, and pastes the reply back to you.
It's a worse interface than just using Claude yourself. You wait hours for a response instead of seconds. You get none of the reasoning, none of the back-and-forth, just the final answer landing in your DMs. But on the margin it still helps. More compute on the problem beats less. You already work with a dozen LLM instances every day. This is one more, wearing a name badge.
One thing genuinely changes: how you talk. I'm polite to the models anyway, so nothing shifts for me. If you're the type who's curt or rude to an LLM to save keystrokes, you have to drop it here. A human reads those messages, even when a machine writes the reply. There's no upside to being sharp with someone who's really just forwarding your text to a tab.
The trap: you've turned yourself into a wrapper
Here's where I'd push the point harder than the original piece does.
If the tool now writes your work, and you're not adding judgment on top, you've made yourself a wrapper around Claude. I've written before about the difference between wrapper tools and foundation tools, and the same logic applies to people. A wrapper has no moat. It's a thin layer of UI over someone else's engine, and anyone can rebuild it in an afternoon.
A person can become a wrapper too. Ticket goes in, AI answer comes out, no value added in between. The company is paying a full salary and getting a Copilot subscription it's probably also paying for separately. Right now everyone's obsessed with what value AI adds to engineers. The next question is colder: what value does this engineer add to the AI? If the answer is "nothing, they just forward the prompt," that role is the easiest cut on the org chart. Not because anyone's cruel. Because the math is obvious to anyone who looks.
And the engineer loses twice. They're shipping more, but learning far less than if they'd made their own bad calls and felt the consequences. Bad decisions you own teach you something. Bad decisions you outsource to a model teach you nothing.
Strong engineers never fall into this
The pattern only catches one kind of person. No strong engineer becomes a thin wrapper around a coding agent.
Even a lazy senior on a bad day has enough taste to catch the obvious AI mistakes before they go out. They use the agent like a power tool: fast for the boring 80 percent, watched closely on the 20 percent that matters. They know the codebase well enough to feel when the model is confidently wrong. That feel is the actual job. It's also the thing the wrapper doesn't have. This is the same gap I keep coming back to in using Claude Code well: the tool is only as good as the judgment steering it.
So AI didn't flatten the distribution. It lifted the bottom and left the top alone. The gap between a strong engineer and a Claude wrapper is now the entire difference between the two of you, and it's more visible than ever, because you're both using the same model.
What to do if you're worried this is you
If any of this stings, that's useful. Here's the honest path out.
Stop forwarding. Read what the agent gives you before anyone else does, and form a real opinion on it. Catch one mistake it made and understand why it made it. When you reach for the model, watch where it does better than you would have, and steal that. That's how relying on AI becomes learning instead of decay: pay attention to the gap, don't just paste over it.
The engineers who survive this aren't the ones who use AI the most or the least. They're the ones adding judgment the model doesn't have. Build that, and you're using the tool. Skip it, and the tool is using you, until someone notices they can cut out the middle layer. Which is you.
If you want the foundation that judgment is built on, what technical debt actually is is a good place to start, because spotting the cost AI can't see is most of the job now.
