Somewhere in the last few years, "good at your job" and "good at your craft" quietly stopped meaning the same thing for software engineers, and almost nobody sent the memo.
AI coding assistants have made it possible to ship faster than ever before, whole functioning prototypes in a matter of minutes, tickets closed faster — and to look, by every metric a manager actually tracks, like a stronger employee than ever. But the thing that used to produce that output, the slow accumulation of debugging instinct, system-level intuition, and the ability to reason through an unfamiliar problem on your own — doesn't get built by output anymore. It gets built by struggle, and struggle is precisely what these tools are designed to remove. That part of your brain slowly deteriorates as those "muscles" go unused.
The result is a trade most engineers haven't consciously made, and one few organizations are equipped to notice: productivity is going up — but at what cost? The underlying skill that productivity used to signal is quietly eroding underneath it. This isn't a story about AI being bad, or a call to abandon it. It's an argument that we've been measuring the wrong thing — mistaking a spike in throughput for a sign of growth, when it may increasingly be evidence of the opposite.
The blurred line: productivity is not the same thing as getting smarter (duh)
I think we all know that the statement above is obvious. But is it, really? Now that AI agents are becoming a staple in every dev's repertoire and tech stack, it's worth pulling apart an assumption sitting underneath most "AI makes engineers more productive" conversations: the quiet assumption that productivity and cognitive development are the same curve, just measured differently. They aren't. They never really were — but AI is the first tool to make the gap between them wide enough to see.
Productivity measures throughput:
tickets closed
features shipped
lines of working code produced per hour.
Cognitive development measures something else entirely — the growth of your ability to reason through a novel problem you haven't seen before, without a tool doing the reasoning for you. These two things used to move together closely enough that you could use one as a proxy for the other. Shipping more, historically, meant you'd solved more — and solving more built the muscle. AI severs that link. You can now ship more while solving less, because the solving has been delegated.
And here's the part worth saying plainly, even though it cuts against the comfortable version of this story:
It's not just that AI-assisted work fails to build problem-solving skill at the rate unassisted work did.
It's plausible — arguably likely — that heavy reliance on it actively degrades problem-solving ability that already existed. Skills that go unused don't stay flat; they atrophy. An engineer who reflexively reaches for an AI suggestion the moment a problem gets uncomfortable is training themselves, repetition by repetition, to treat discomfort as the cue to hand off rather than the cue to dig in. That's not a neutral habit — it's the opposite of what deliberate practice looks like. Deliberate practice requires staying in the productive-struggle zone, and AI's entire value proposition is pulling you out of that zone as fast as possible.
Now what?
This is not going to turn into a piece where I end by telling you to stop using AI, LLMs, and agents to code. No — absolutely use them. It'd be absurd not to; technology advances and we adapt. There's a reason Assembly fell out of favor for higher-level languages. But I digress.
This is why "productive" is such a dangerous word in this context. It does a lot of quiet work to make the tradeoff invisible. A week where you shipped a lot feels like a good week, and by every visible organizational signal, it is a good week.
"I produced a lot" and "I got better at producing" can now diverge completely — you can have your most productive month on record and your most cognitively stagnant one at the same time, and nothing in your workflow will tell you that's what happened. There's no dashboard for it. The only signal is a slower, more personal one: do you notice, months later, that a class of problem you used to be able to reason through now makes you reach for the tool by reflex, before you've even tried?
That's the real risk hiding in the productivity narrative — not that AI makes you slower or worse at your job today, but that "worse at your job today" was never the right thing to measure in the first place.
Top comments (3)
The economic trap here is that management metrics track flow rather than capital stock. Closing tickets faster registers immediately as higher labor productivity, while the erosion of system intuition is an unbooked depreciation expense. Organizations effectively borrow against future incident response capacity to inflate current velocity. The cost only shows up during an outage or major refactor that lands outside the model's training distribution, when the firm suddenly discovers that nobody on call holds the actual state transitions in their head.
I agree that you can definitely get more tasks completed but at the prise of not actually knowing what was actually done looking at the bigger picture and you can easily lose focus and tracking your progress can get really "cloudy" because of using too much AI to multi-task everything.
This is a really interesting perspective. I especially agree with the difference between being productive and actually improving our engineering skills.
AI can help us move much faster, but if we always skip the struggle of understanding and debugging a problem ourselves, we may also skip some of the learning that comes with it.
Finding that balance is probably one of the most important skills for developers working with AI.