The Explanation Requirement: Why AI-Era Engineers Must Learn to Articulate

There's a quiet skill that AI has been systematically eroding: the ability to explain what you need. Not the ability to write code, debug, or architect — but the more fundamental act of articulating a problem clearly enough that someone (or something) else can help you solve it.

This isn't obvious at first. AI tools are fluent. They respond to vague prompts as readily as precise ones. You can type half a sentence and get a complete answer. That courtesy comes at a cost: it masks the degradation of your own explanation skills, and it does so gradually enough that you don't notice until the gap between what you can think and what you can articulate becomes embarrassingly wide.

Engineers who understand this — who invest in their explanation requirement — are pulling ahead. Everyone else is quietly falling behind, unable to get real value from increasingly capable tools.

What the Explanation Requirement Actually Means

Every tool has an interface. The interface defines what inputs it accepts, how those inputs are interpreted, and what outputs you can expect. AI tools, more than any tool before them, are sensitive to the quality of the input. Not because the model is brittle, but because clarity of input and quality of output are correlated in a meaningful way.

The explanation requirement is the minimum threshold of articulacy needed to get a useful answer from an AI tool. Below that threshold, the tool will produce something — but the something won't be quite right. It'll be a plausible-sounding answer to a vaguely-articulated question. It'll be fast. It'll be wrong in subtle ways.

Consider the difference between these two prompts:

// Prompt A (under-specified)
What's the best way to handle auth in a Node app?

// Prompt B (well-specified)
We have a Node/Express API with multiple clients (web SPA + mobile). We need
session-based auth with refresh tokens. Our DB is Postgres. Requirements:
1. HttpOnly cookies for the session token
2. Short-lived access tokens (15min) + longer refresh tokens (7 days)
3. Rotation of refresh tokens on each use
4. Ability to revoke all sessions for a user on password change
What's a production-ready approach using passport.js or similar?

Prompt A will return a generic answer: JWT vs sessions, some code snippets, a paragraph about security considerations. Prompt B will return an architecture decision with specific package choices, code structure, and security rationale. The difference isn't the AI's capability — it's the explanation quality. And over time, engineers who consistently use Prompt A-style inputs are training themselves to think less precisely, because they no longer need to.

Three Mechanisms of Explanation Atrophy

1. The Abstraction Gradient

When you can ask an AI to handle the specifics, there's less pressure to develop detailed mental models. You don't need to know exactly how a refresh token rotation works — you can ask and get code. But the engineers who understand the mechanism deeply are the ones who catch the security edge cases, who spot the implementation bugs before they ship, who make the right architectural calls when the AI's generic answer doesn't fit the specific situation.

The abstraction gradient is the gap between "I understand this conceptually" and "I can articulate the specific implementation details." AI reduces the penalty for staying at the conceptual level, which means engineers who don't consciously maintain their detail-level understanding will gradually drift up the abstraction gradient — confident in their high-level comprehension but unable to do the low-level work when the situation demands it.

2. The Decomposition Disuse Problem

Decomposing a large problem into smaller, articulable pieces is a skill. It requires practice. When you work with an AI that can handle a large, messy prompt and produce a structured response, you stop practicing decomposition. The AI does the structural work for you — and in doing so, it removes the practice opportunity.

This matters because decomposition is not just a communication skill. It's a thinking skill. The act of breaking a problem down forces you to understand its parts. When you outsource decomposition to an AI, you're not just outsourcing communication — you're outsourcing the thinking that decomposition requires. Engineers who decompose well think clearly. Those who've stopped practicing will find their thinking getting murkier, even in conversations with colleagues.

3. The Feedback Loop Compression

Good explanations get better with feedback. You try to explain something, it doesn't land, you adjust, you try again. This is how explanation skills develop. AI tools compress this feedback loop: they produce an answer instantly, and if that answer isn't right, you iterate. But the iteration is often at the level of the prompt modification, not the explanation. You change words until you get the output you want, rather than thinking harder about what you actually need.

Who It's Hitting Hardest

The explanation requirement isn't hitting everyone equally. There are identifiable cohorts that are more vulnerable.

Mid-career engineers are the most exposed. They have enough experience to have developed real skills — and enough fluency with AI tools to be depending on them daily. When those skills start eroding, they don't always notice immediately, because the AI outputs are plausible. The skill loss is masked by tool capability. Until it's not.

The Diagnosis: Can You Articulate Without the Tool?

Here's a simple self-test. Take a problem you've been working on — something you're actively debugging or designing. Without using an AI tool, write out:

1. The exact problem you're trying to solve
2. Why it's a problem (what's the cost of not solving it)
3. The constraints that make it hard
4. What you've already tried and why it didn't work
5. What a good solution would look like

If you can do this clearly and specifically, your explanation skills are intact. If you find yourself wanting to open a chat window before writing — that's a signal.

The Recovery Protocol: Rebuilding Your Explanation Skills

The explanation requirement is recoverable. It requires deliberate practice — not practice with AI tools, but practice with the underlying skill. Here's a structured approach:

The key principle: you need to experience the friction of articulation without AI assistance. That friction is where the skill develops. AI tools remove that friction — which is great for productivity, terrible for skill-building.

The Organizational Dimension

Individual explanation skill matters, but it also has a team-level dimension. When engineers can't articulate problems clearly to AI tools, they also can't articulate them clearly to colleagues, to managers, to designers, to anyone. The explanation requirement is a proxy for thinking clarity. Organizations that recognize this — and build practices that reinforce explanation skills — will develop stronger technical cultures. Those that don't will find their engineering teams increasingly dependent on tools they can't fully evaluate or direct.

The teams that are thriving right now are the ones where engineers regularly practice explaining things: design docs, RFC discussions, async written updates, retrospective write-ups. These aren't just communication habits — they're the friction that keeps thinking sharp. When that friction disappears because AI handles the hard part of articulation, the thinking gets sloppier. Not immediately. But gradually.

The Long View

The explanation requirement is not about rejecting AI tools. It's about being deliberate about which cognitive skills you let atrophy and which you actively maintain. The engineers who will thrive in the AI era are the ones who treat explanation as a core skill — who write before they prompt, who decompose before they delegate, who can walk a colleague through a problem without opening a chat window.

These are the engineers who get better answers from AI tools, because they ask better questions. They're also the engineers who stay sharp when tools change, who can evaluate outputs critically, who can do the work when the tools don't exist or aren't available. The explanation requirement isn't a constraint on AI tool use — it's the foundation that makes AI tool use genuinely powerful.