You’ve felt it. You prompt the AI, it spits out a perfectly formatted function, and you hit enter. The tests pass. The dopamine hits. But as you move on to the next ticket, a quiet, uncomfortable question lingers in the back of your mind: Do I actually know how any of this works?
We are trading the deep, hard-earned mastery of our craft for the cheap dopamine of a completed sprint.
The promise of AI coding assistants was that they would make us 10x developers. They would handle the boilerplate, we would handle the architecture. But the reality is far more insidious. By removing the friction from our daily workflows, we are systematically dismantling the very mechanism that creates senior engineers.
Think about how you learned to code. You didn’t learn by reading documentation. You learned by staring at a broken pointer for six hours. You learned by tracing a memory leak through a labyrinth of spaghetti code until you finally found the one missing semicolon or the off-by-one error. That struggle wasn’t just an annoying hurdle; it was the forge that built your mental models of how systems actually operate.
Friction isn’t a bug in the learning process; it’s the entire mechanism. You don’t build muscle by watching someone else lift the weight.
Today, when an AI assistant instantly generates a complex algorithm or an entire API route, the developer is robbed of the productive struggle required to understand it. We are producing a generation of developers who can ship code at lightning speed, but who lack the foundational understanding to debug that code when the AI inevitably hallucinates or the edge cases hit production.
I’ve seen it firsthand. A junior dev recently asked me to help debug an issue. I asked them to walk me through the logic of the function throwing the error. They stared at me blankly. “I didn’t write it,” they said. “Copilot did. I just told it what I wanted it to do.” They had a working feature for a day, and an unfixable mess for a week.
This is the paradox of efficiency versus mastery. When you remove all resistance from coding, you accelerate production, but you completely prevent the formation of problem-solving skills. Programming is slowly being downgraded from a discipline of deep understanding to a skill of mere orchestration. We are becoming prompt engineers—middle managers for language models.
If you can’t debug the code without the AI, you aren’t a programmer anymore. You’re just a very expensive middle manager for a language model.
Some will argue that AI is just a tool, like the compiler was before it. That’s a false equivalence. A compiler translates your logic into machine code; it doesn’t invent the logic for you. When you offload the actual problem-solving to an AI, you offload the cognitive load that makes you an expert.
The most effective tools for expertise aren’t the ones that remove all resistance. They are the ones that introduce productive struggle. We need tools that force us to think, to question, and to understand. Because when the system goes down, when the network is severed, and when the AI can’t reach the server to save you, the only thing left to run the code is the mental model in your head. Make sure it’s actually there.
FAQ
Q: Isn't AI just a tool like calculators were for math?
A: Calculators automated arithmetic; AI automates architecture. Arithmetic doesn't teach you how to build a bridge, but struggling with structural engineering does. When AI invents the logic, it steals your cognitive load.
Q: So should I stop using AI for coding?
A: No, but use it for boilerplate, not for solving core logic. If you don't understand the algorithm the AI wrote, delete it and write it yourself. The struggle is the point.
Q: Won't AI just create a new type of expertise?
A: It creates 'orchestration' expertise, not engineering expertise. But orchestration without foundational understanding is just blind guesswork. When the AI fails, the orchestrator is helpless.