Here's a question nobody in the AI industry wants to ask: what happens to software engineering as a discipline when the tools that are supposed to make us better actually make us worse?
Not worse in the sense of lazy. Worse in the sense of *structurally less capable* — unable to function without autocomplete, unable to debug without an AI suggesting fixes, unable to reason through a problem without first asking a language model to scaffold it for them.
I think about this a lot because I see it happening in real time, and it's not subtle.
When you lean on an AI coding assistant for every non-trivial task, you stop building the mental models that make you a real engineer. You know the destination, but you never learned the map. The AI fills in the gaps so seamlessly that you mistake its assistance for your own understanding.
This is the crutch problem. Crutches are useful when you're injured. But if you use one long enough and no one forces you to put it down, your legs atrophy. That's not a failure of the crutch — it's a failure of the rehab plan. And right now, there's no rehab plan.
Junior developers who started their career with GitHub Copilot or Claude Code in their loop have never *not* had a co-pilot. They don't know what they don't know. They can't tell the difference between understanding a system and having an LLM summarize one. When the AI is right, they ship. When the AI is wrong, they're helpless — because they never built the intuition to catch the mistake.
Here's the uncomfortable math: AI coding assistants absolutely improve short-term productivity. You ship more features, close more tickets, move faster. Every metric looks better.
But those metrics are measuring output, not capability. And over time, the relationship between output and underlying skill decouples. You can have a team that ships constantly but has no idea what their code actually does — because they've always had an AI to bridge the gap between intention and implementation.
Then one day the AI has a bad day. A model deprecation, a rate limit, a subtle regression in the model quality. And suddenly your team is stranded. They can ship when the copilot works, but they can't think without it.
There's a myth that good engineering is about writing code. It's not. It's about knowing *which* code to write, understanding *why* it needs to be there, and catching it when it's wrong. That judgment comes from struggle — from spending hours staring at a segfault, from refactoring a system that painted you into a corner, from making mistakes that taught you *why* the right approach was right.
AI assistants skip the struggle. They hand you the solution before you've formed the question. And in doing so, they short-circuit the learning process that turns a junior engineer into a senior one.
The engineers who will thrive in the next decade aren't the ones who know how to prompt an LLM. They're the ones who know *when* to trust it, how to verify what it produces, and critically, *when to ignore it entirely*. Those skills only come from doing the hard things that AI now does for you.
I use these tools. I find them genuinely useful. But I use them like a calculator — a tool that amplifies what I can already do, not a replacement for the underlying ability.
The problem is that most developers don't use them that way. They use them as a surrogate for thinking. And that distinction is everything.
We need to be honest about what we're trading away when we let AI take the wheel on the hard parts of our job. Not because the trade isn't worth it — maybe it is — but because pretending there is no trade is how you end up with an industry full of people who can ship but can't think.
And when the AI eventually fails, and it will, that's when we'll realize how much we needed those skills after all.