The AI Decision Stack

Your team just finished a sprint planning session. The roadmap is aggressive. Someone suggests rolling out a new AI coding assistant to the whole team. Everyone nods. Three months later, velocity is up — and so is something else. Senior engineers are disengaging. Junior engineers can't debug without AI. The team's collective sense of craft is quietly eroding. Nobody planned for that.

This is the AI Decision Stack failure mode: teams adopt AI tools the way they adopt project management software — procure, roll out, measure velocity. But AI coding tools are categorically different. They don't just change how fast your team works. They change how your team thinks, learns, and relates to their craft. And those changes compound over time in ways that are easy to miss until the damage is done.

The AI Decision Stack is a framework for evaluating AI coding tools across four layers that most teams never consider until it's too late.

The Four-Layer Stack

Before you evaluate specific tools, you need a decision framework. The AI Decision Stack evaluates each tool across four layers, from most immediate to most insidious:

No AI coding tool wins on all four layers. The best you can do is make the tradeoffs explicit and conscious — and align them with your team's specific composition, goals, and risk tolerance.

Layer 1: Cognitive Cost

Cognitive cost is the most immediate and measurable layer. When an engineer uses an AI coding tool, how much mental overhead does it add?

The answer isn't obvious. AI tools feel like they reduce cognitive load — they handle the tedious parts, suggest the boilerplate, catch the obvious bugs. But the research on cognitive load tells a different story. AI tools add cognitive cost in ways that are easy to miss:

• Context-switching cost: Every time an engineer sends a prompt to AI and receives a response, they're switching mental contexts. Gloria Mark's research at UC Irvine found that after a single interruption, it takes an average of 23 minutes and 15 seconds to fully return to deep focus. AI tools that suggest code mid-session create micro-interruptions that compound throughout the day.
• Verification overhead: AI output must be read, understood, evaluated, and often corrected before it's usable. This "last mile" cognitive work — understanding what the AI generated well enough to verify it — is real mental effort that doesn't show up in velocity metrics.
• Decision fatigue: Choosing which AI suggestion to accept, which to modify, and which to reject requires continuous micro-decisions. Kahneman's research on decision fatigue shows that each micro-decision depletes the same limited cognitive resource as major decisions. Teams don't account for this because it's invisible.
• Monitoring load: When an AI is running in the background (Copilot-style suggestions appearing in real time), the brain's attentional system has to partially monitor it even when you're not actively engaging. This is cognitive load you can't turn off.

Different tools have radically different cognitive costs:

What to measure: Track engineers' self-reported focus quality weekly. Use a simple 1-5 scale: "I was able to sustain deep focus for most of today." If the team average is declining after tool rollout, cognitive cost is too high.

Layer 2: Skill Preservation

Skill preservation is the most consequential long-term layer — and the one most teams completely ignore at adoption time.

Here's the uncomfortable truth: most AI coding tools are optimized to make engineers feel productive in the short term while eroding their capabilities in the long term. This isn't a bug in AI tools — it's a fundamental property of any system that removes the friction necessary for skill development.

Erik Harrell and K. Anders Ericsson's research on deliberate practice is unambiguous: expertise develops through effortful engagement with problems at the edge of current ability. When you encounter a novel problem, struggle with it, fail, recalibrate, and eventually solve it — that's when neural pathways strengthen and mental models deepen. AI tools systematically bypass this process for the problems they're best at solving.

The consequence is a specific pattern researchers call competence illusion: engineers who use AI tools heavily can produce sophisticated, working code while having lost the ability to produce the same code without AI assistance. They can evaluate whether AI output is correct, but they can't generate it independently. Their apparent competence is actually AI competence wearing a human mask.

Not all AI tools erode skills equally:

Evaluate any AI tool's skill preservation impact with this question: If my team used only this tool for 12 months and then the tool was removed, would they be more capable or less capable than they are today?

Tools that score well on skill preservation typically:

• Show reasoning and context, not just code (so engineers learn the why, not just the what)
• Leave parts of the problem for engineers to solve (partial suggestions rather than complete implementations)
• Offer to explain rather than always generating
• Have a "no-AI" mode for deliberate practice sessions

Layer 3: Team Dynamics

AI coding tools don't just affect individual engineers — they reshape how teams interact, share knowledge, and develop collectively. These dynamics are harder to measure but just as consequential.

Code review as a learning vector

Well-functioning engineering teams use code review as a primary knowledge transfer mechanism. Senior engineers review junior code and share patterns, reasoning, and institutional knowledge. Junior engineers learn by seeing how senior engineers think. This bidirectional knowledge flow is a critical — and often underappreciated — team asset.

When AI generates code that engineers review and approve, the knowledge transfer vector inverts. The AI may have senior-level output but zero ability to explain why. Junior engineers reviewing AI-generated code learn less because the code they're reviewing doesn't encode the reasoning they'd get from a senior peer's explanation. And senior engineers reviewing AI-generated junior code can't calibrate whether the code came from genuine understanding or prompt-following.

Signs your AI tool is disrupting team learning dynamics:

• PR descriptions increasingly read like AI output and lack decision rationale
• Code review comments shift from "here's why this approach is better" to "this looks fine"
• Junior engineers can't explain the code in their own PRs without AI assistance
• Architecture discussions are increasingly rare as AI "solves" architectural questions
• Seniors report feeling like their institutional knowledge isn't being valued

Skill heterogeneity amplification

AI tools amplify the gap between experienced and inexperienced engineers in ways that are hard to see early. Senior engineers use AI tools to move faster while maintaining their expertise. Junior engineers use AI tools to produce senior-level output while building senior-level dependency. Over time, the junior engineer's independent capability grows more slowly than it would without AI — while appearing, on surface metrics, to keep pace.

This creates a dangerous team dynamic: the team becomes dependent on AI to sustain its apparent capability level, but that dependency is unevenly distributed. When AI is wrong, insufficient, or unavailable, the team fractures between those who can navigate without it and those who can't.

This dynamic is further explored in The AI Dependency Trap.

Norm collapse

Teams without explicit AI usage norms develop informal, uneven norms organically — and the organic norm is almost always "use AI as much as possible." Engineers who try to use AI thoughtfully feel pressure to match the output volume of colleagues using AI without restraint. This norm collapse is invisible until it shows up as burnout, disengagement, or exodus of experienced engineers who feel their craft is devalued.

Layer 4: Long-Term Sustainability

The sustainability layer asks: if your team uses this tool at current intensity for 12 months, what is the trajectory of your team's collective capability, engagement, and health?

Sustainability is the hardest layer to evaluate because its effects are slow, diffuse, and easy to attribute to other causes. By the time AI-related sustainability problems become visible, the root cause is often months in the past and difficult to diagnose.

Track these signals quarterly:

If any of these four signals is declining while velocity is stable or improving, you have a sustainability problem that velocity gains are masking. This is the most dangerous state: short-term wins obscuring long-term decay.

For holistic team sustainability practices, see Developer Wellbeing.

The AI Decision Stack Worksheet

Before adopting any AI coding tool team-wide, score it across the four layers. Be honest — the goal is not to find a tool that scores well everywhere, but to make tradeoffs explicit and align them with your team's actual situation.

Practical Adoption: How to Roll Out AI Tools Without Breaking Your Team

Scoring tools is the easy part. The hard part is the rollout. Here's what teams that successfully integrate AI tools differently from those that don't:

1. Start with norms, not tools

Before you adopt any tool, establish explicit team norms for AI use. These should answer:

• When is AI appropriate? (green field, exploration, boilerplate, learning)
• When is AI not appropriate? (novel problems without backup, safety-critical code, architectural decisions without team input)
• What must always be verified by a human before merging?
• How do we document AI's role in decisions that matter?
• How do we create protected time for no-AI practice to maintain skills?

Teams that skip this step develop informal norms by default — and the informal norm is always "more AI, more often."

2. Senior engineers first, with intention

Don't roll out AI tools uniformly. Senior engineers are in the best position to use AI tools effectively while managing the skill preservation risk. They have the context to verify AI output, the pattern recognition to spot AI errors, and the career stability to not feel threatened by AI-assisted junior engineers.

Let seniors develop usage patterns first, then use their experience to shape the norms junior engineers follow.

3. Monitor the four signals from day one

Set up quarterly retrospectives specifically for AI tool impact. Track senior retention, onboarding speed, skill assessment scores, and team satisfaction. Don't wait for problems to become obvious — by then, they're entrenched.

4. Invest in explanation over generation

Train your team to use AI's explanation capabilities as much as its generation capabilities. When an AI generates code that engineers don't fully understand, the correct response is not to ship it — it's to ask the AI to explain the reasoning, then learn from that explanation. Tools that support this pattern preserve more skills than tools that optimize purely for generation speed.

5. Protect no-AI time deliberately

Schedule regular (weekly or bi-weekly) no-AI coding sessions for the whole team. Not because AI is bad, but because the friction of working without AI is itself the training signal that builds and maintains expertise. Athletes deliberate practice this way. So should engineers.

If You're Already in the Sustainability Problem

Many teams reading this will recognize their situation: they've been using AI tools for months, velocity looks good, but the four signals are declining. What do you do?

The answer is uncomfortable but clear: the intervention is a deliberate reduction in AI dependency, not an expansion.

This runs counter to the organizational pressure to keep velocity high. That's why it's hard. But teams that have done this — reduced AI usage deliberately to recover skill, engagement, and sustainable velocity — report that the short-term velocity dip is smaller than expected, and the recovery in team quality and engagement is faster than expected.

For team-level strategies, see Engineering Managers & AI Fatigue.

Practical steps:

• Audit current AI usage: Where is AI being used most heavily? Where is it least necessary? Start by reducing in the low-value areas.
• Introduce no-AI days or blocks: Even one no-AI day per week begins rebuilding the deliberate practice signal.
• Redesign code review to require explanation: AI-generated code should be accompanied by the engineer's own explanation of how it works. If they can't explain it, they shouldn't be merging it.
• Run skill assessments: Before and after intervention. Make the invisible visible so you can track whether you're recovering.
• Check in with senior engineers specifically: They are the most likely to have already noticed the problem. Ask them directly what's broken.