The Explanation Requirement
The Moment You Stopped Learning
Here's something that used to happen constantly, and almost never happens anymore.
You'd be mid-conversation — debugging a gnarly bug, thinking through an architecture problem, trying to explain to a colleague why a particular approach made sense — and you'd hit a wall. Not a code wall. A thinking wall. The moment where you realize you can't actually explain what you think you understand.
That moment was always uncomfortable. But it was also the real learning moment. The gap you just ran into was exactly where your understanding stopped. The explanation demand had exposed a flaw in your mental model, and now you had to either fix it or live with not understanding it.
We used to call this the rubber duck moment. Now we call it asking ChatGPT.
The Hidden Function of Explanation
There's a reason explaining something to someone — or even to yourself — has always been a core part of learning. It's not just communication. It's compression.
When you try to explain something, your brain has to do several things simultaneously: retrieve the relevant pieces, organize them into a coherent sequence, translate from internal understanding to external representation, and fill in any gaps between what you think you know and what you can actually articulate.
Any gap in that chain shows up immediately. You can't fake an explanation to a person the way you can fake understanding in your own head. The act of externalizing forces you to test whether your internal model is accurate.
This is why Feynman was onto something when he said if you can't explain it simply, you don't understand it. The simplicity isn't aesthetic. It's diagnostic.
What AI Did to This
When AI coding tools arrived, they made the explanation available instantly. You can ask any question — "why does this code work this way?" — and get a complete, coherent explanation in seconds. Formatted. Clear. Correct.
That's remarkable. It's also quietly devastating for learning.
Because the explanation used to be the reward for struggle. You'd bang your head against something for an hour, try three wrong approaches, look at five Stack Overflow answers that almost fit but not quite, and then — finally — you'd have the insight that let you explain it to someone. That moment of insight was where understanding was consolidated. Not just acquired, but integrated.
Now you can skip the struggle and get the explanation directly. And here's the problem: your brain registers the explanation as yours. You read it. You understand it. The tests pass. But the consolidation that came from the struggle — the part where you had to reconstruct it from your own understanding — never happened.
You have the explanation without having the understanding. And your brain can't tell the difference.
The Specific Skill That's Being Lost
The engineers who notice this first are usually the ones who had to learn things the hard way — bootcamp grads who built projects from scratch, self-taught developers who debugged obscure errors for hours, senior engineers who learned systems by breaking them.
They're also often the ones who notice the most when something feels off: reading code they didn't write, understanding explanations that didn't cost them anything, feeling like they're following along without building anything. There's a specific metacognitive skill that used to develop automatically and is now atrophying: the ability to know when you don't understand something.
Not when AI tells you the code is wrong. When you personally know — from the inside — that there's a gap between your confidence and your actual understanding.
This is what the explanation requirement was training. Every time you had to explain something and found you couldn't, your brain was recalibrating. Updating its confidence estimate. Marking the edge of what you actually knew versus what you were just familiar with.
That recalibration is becoming rare. And the engineers who've noticed are trying to figure out how to put it back in.
The Friday Explanation
Once a week, write down — in plain language, not in documentation format — what you worked on this week. Not what you shipped. Not what the code does. What you understand now that you didn't understand before.
Three sentences minimum. Five is better. The constraint: you have to be able to explain it to someone who knows programming but not your specific problem. If you find yourself writing "it works because of X" without being able to say why X applies, that's the gap. Mark it.
Do this every Friday for a month and you'll have a clear picture of where the gaps are. More importantly, you'll start to notice when you're reaching for an explanation instead of building understanding — because it will show up as friction on Friday.
The goal isn't to avoid AI. It's to notice when you're trading the hard thing (understanding) for the easy thing (explanation) — and to choose deliberately instead of by default.
The Question Worth Sitting With
This week's question: what do you understand now that you understand how to explain — but couldn't have explained three months ago?
If the answer comes easily, you probably didn't build that understanding from first principles. The things worth knowing take friction to consolidate. That's not a bug. That's how learning actually works.
If you can't think of anything that cost you genuine effort to understand in the last three months, that might be worth sitting with.
If you want a more structured read on the explanation requirement and how to rebuild it deliberately:
Read the Full Guide →