Are we training our engineers to be faster — or just more dependent?
The Witchcraft Metaphor
A growing conversation in the industry compares AI-assisted coding to witchcraft. Developers repeat incantations in prompt files and construct elaborate rituals to summon working code, without necessarily understanding what emerges. It is a provocative metaphor, but it points to something real.
Working code is appearing in pull requests faster than ever. The question is whether the people opening those PRs could explain what the code does, why it was structured that way, or what would happen if a key assumption changed.
What Aviation and Surgery Already Learned
Automation-induced deskilling is well documented in aviation and nuclear safety. Pilots who rely too heavily on autopilot lose the ability to fly manually when systems fail. Surgeons who skip practice for four weeks show measurable skill decay. Software engineering is not immune to this pattern.
The mechanism is the same in every field: when a tool reliably handles a task, the underlying skill atrophies. That is fine when the tool never fails. It becomes dangerous the moment it does.
The Measurement Problem
Here is the concern. We are measuring velocity without measuring comprehension.
Teams report two to five times throughput gains with AI coding tools, which is impressive. But throughput is not the same as capability. When the AI generates a subtle architectural flaw, does your team have the depth to catch it? When an agent hallucinates a dependency, does anyone notice before production?
The metrics most engineering organizations use were never designed to answer those questions. They count outputs. They do not measure whether the people producing those outputs could reproduce them, defend them, or recognize when something is quietly wrong.
How Other High-Stakes Fields Solved This
Industries that solved this did not reject automation. They evolved their frameworks.
Aviation created Crew Resource Management — structured practices that keep human pilots actively engaged even when autopilot is doing most of the work, plus mandatory manual-flying time to preserve skills. Surgery mandated simulation practice and skill maintenance requirements that hold regardless of how much robotic assistance is available.
The principle is the same in both cases: when a tool reduces the practice opportunities for a critical skill, the organization deliberately creates new ones.
What Engineering Leadership Needs
Engineering leadership needs an equivalent. We need metrics — and practices — that capture not just how fast teams ship, but how well they understand what they are shipping.
Concretely, that means asking:
- Can the engineer who submitted this PR explain it without referring to the prompt? If not, comprehension is decoupled from delivery.
- Are reviewers actually reading AI-generated code, or rubber-stamping it? Review depth, not just review throughput.
- When something breaks in production, who can diagnose it? If it is always the same two senior engineers, the rest of the team is becoming dependent.
- Are juniors building real architectural intuition, or learning to prompt around problems they never fully understood?
Speed Without Comprehension Is Just Sophisticated Technical Debt
Code that ships fast but is not understood by anyone on the team is technical debt with a faster compounding rate. It looks like productivity in this quarter's metrics and turns into incident response in next quarter's.
The engineering organizations that handle the AI transition well will be the ones that treat comprehension as a first-class measurement — not an afterthought to velocity. They will not slow down. They will make sure their speed is built on understanding, not on tools they have stopped being able to question.
