A Pattern I Keep Seeing
I am in the third engineering coaching engagement this quarter where the same scene has played out. A senior engineer — competent, respected, ten to fifteen years in — describes a recent code review or design review where they accepted an AI's recommendation. The recommendation was wrong in a subtle way. A colleague caught it. The senior, in the conversation with me, says some version of the same sentence:
"I would have caught that two years ago. I do not know when I stopped catching things like that."
This sentence is the symptom. What it points to is not a productivity problem. It is an identity problem, and underneath the identity problem is an emotional intelligence problem that most engineering organizations are not yet diagnosing, let alone addressing.
The Empirical Floor
The data is now too strong to argue with. A randomized controlled trial conducted by Anthropic with 52 professional developers learning an unfamiliar Python library found that AI-assisted workers scored 17% lower on comprehension assessments of code they had just written, with the largest gap appearing in debugging tasks (Cohen's d = 0.738). The work shipped. The understanding did not.
GitClear's analysis of 211 million changed lines of code reports that 2024 was the first year in which copy/pasted code exceeded refactored code, with an eight-fold increase in code duplication. A Harvard-Microsoft study of more than 180,000 developers using GitHub Copilot found individual coding activity rose 12.4% while peer collaboration fell nearly 80%.
These are not findings about bad engineers. They are findings about good engineers operating inside an augmented work environment that quietly rewards a kind of cognitive outsourcing — and they are findings about what happens to a profession when the muscle of judgment is no longer the muscle being exercised.
What Is Actually Being Lost
When I work with engineers in this state, the deficit is not technical. They can still read code. They can still draw block diagrams. What has thinned is harder to name: the reflexive scepticism that used to flag an inconsistency before it became a defect, the felt sense that "something is off here" before the engineer could articulate what.
The clinical term is verification capacity. The engineering term is taste. Both refer to the same thing — the integrated, partly tacit, partly emotional apparatus by which an expert recognizes when a plausible answer is not the right answer.
Verification capacity is not stored in the head. It is rehearsed through practice. Every time an engineer chases down a confusing test failure, sits with an ambiguous requirement, or argues with a colleague about a design trade-off, the capacity is being maintained. When the AI takes over the chasing, the sitting, and the arguing, the capacity does not get a workout. Within twelve to eighteen months, the engineer who used to catch things reflexively is the engineer in my office, asking when they stopped catching things.
The medical analogue is instructive. A 2024 study of endoscopists who used AI polyp-detection tools found that their adenoma detection rates were 28% with the AI — and 22% without it, after a period of routine use. Their independent capability had degraded below their pre-AI baseline. The tool had not made them worse at detection; their reliance on the tool had.
Five Trajectories Engineers Are On
In the work I have done with engineering teams over the last eighteen months, I have come to recognize five fairly consistent behavioural trajectories. Engineers do not pick these consciously. The trajectory emerges from the interaction between the individual's identity-anchor, the team's reward system, and the calibration of the AI tools they are using. They are worth naming because they predict, with uncomfortable accuracy, who is going to be valuable in three years and who is going to be invisible.
The Amplified Craftsman treats the AI as a force multiplier for work they care about. They check its suggestions against their own judgment. Their output rises and so does their depth.
The Cognitive Outsourcer treats the AI as a substitute for thinking. Output rises; judgment atrophies. After twelve to eighteen months they cannot do the work without the tool.
The Audit Adversary optimizes their behaviour around the recorded trail rather than the engineering. The work product looks defensible. The thinking behind it is theatre.
The Quiet Resister continues working in Excel, in their head, in side conversations. The platform records nothing because the work is not flowing into it. Over time they become invisible to their own organization.
The Orchestrator realizes — usually around month six to nine — that their job has changed in kind, not in degree. They are no longer producing outputs; they are managing a workflow in which AI agents propose, specialists fill in, and they make the consequential calls. They begin caring about the quality of the system they are operating in. This is the rarest trajectory and the most valuable.
The most important thing about these trajectories is that the engineer cannot reliably self-diagnose which one they are on. The Cognitive Outsourcer feels productive. The Audit Adversary feels diligent. The Quiet Resister feels principled. Only the Amplified Craftsman and the Orchestrator have any internal signal that they are on a sustainable path, and even they are sometimes wrong.
Why This Is an EQ Problem
A traditional skills audit will not surface any of this. The Cognitive Outsourcer's code compiles, ships, and passes review. The Audit Adversary's documentation is exemplary. The Quiet Resister's individual contributions are competent. The deficit is not in any deliverable; it is in the relationship between the engineer and their own judgment.
The capacities that determine which trajectory an engineer lands on are, almost without exception, emotional intelligence capacities:
- Self-awareness — can you tell when you accepted a suggestion you do not actually understand?
- Self-regulation — can you tolerate the friction of working out a problem yourself when an AI would give you an answer in seconds?
- Calibrated confidence — can you hold the difference between "I am confident" and "the AI is confident, and I have adopted its confidence as my own"?
- Relational courage — can you tell a colleague their AI-generated solution is wrong without the recorded trail to back you up?
- Identity flexibility — can you let your professional identity migrate from the person who produces the design to the person who decides what gets designed and validates that it is correct without experiencing it as a demotion?
None of these are technical. All of them are coachable. None of them appear in the engineering performance review you ran last quarter.
The Question That Matters
Most engineering organizations are still asking the wrong question. They ask: Are our engineers using AI productively? The answer is almost always yes, and the metric that justifies that answer is throughput.
The right question is harder. It is: In eighteen months, will our engineers be capable of the work they are doing today without the AI in the room?
If the honest answer is no, the organization is on a trajectory that productivity dashboards will not catch until a recall, an audit finding, or a customer-discovered defect forces the issue. By then the verification capacity required to recover has thinned across the whole team, not just the engineer who shipped the defect.
This is not an argument against AI tools. It is an argument for taking the human side of the augmentation as seriously as the technical side. The engineers who are going to thrive in the next decade are not the ones who can prompt best. They are the ones who can preserve, deliberately, the capacities that make their prompts worth trusting in the first place.
Where to Start
If you are an engineering leader, the first move is diagnostic, not prescriptive. You cannot coach what you have not measured. Our EQ Frontier assessment is built specifically for this question — it measures the emotional and cognitive dimensions of AI readiness in engineering roles, including the early-warning signs of verification capacity erosion that conventional performance reviews miss.
For engineering teams specifically, we have written more about the structural side of this transition on our engineers solutions page — what the new role looks like, how to design for the Orchestrator trajectory rather than the Outsourcer one, and what coaching can and cannot do.
The engineers in my office did not get to that conversation through carelessness. They got there through the slow, invisible erosion of a capability that nobody on the team was responsible for protecting. The work is to make someone responsible for protecting it — and then to give them the tools to do so.
Want to know which trajectory your engineers are on? Start with the EQ Frontier assessment, or read more on our solutions for engineering teams. This piece is part of our broader synthesis on the AI Anxiety Stack — the three-layer model of how AI fear actually operates inside organizations.