Feeling vs understanding

AI is brilliant at making your team feel like they understand the system. Whether they actually do is a different question, and you tend to find out at the worst possible time.

A senior engineer told me about something he caught on his team a few months ago, and it has stayed with me because it is so easy to miss.

A junior developer would come into code review confident. Articulate. Ready to defend every decision. The code looked clean. The explanations sounded solid. Everything you would normally read as a sign that someone knows what they are doing.

Then something would break in production. And the same developer who had defended every line an hour earlier would go completely quiet. Not because they froze under pressure. Because they had never actually understood what they built. They understood what the AI had told them about what they built. Those are not the same thing.

He said it was the most unsettling thing he had seen in a long career. Not incompetence, which you can spot and coach. Confident incompetence. And it stayed invisible right up until the moment it could do the most damage.

I keep coming back to the distinction underneath that story, because I think it is the quiet risk of this entire era.

There is the feeling of understanding, and there is understanding. They used to travel together. Now they have come apart.

AI is extraordinarily good at producing the feeling. It explains what the code does in clean prose. It justifies the approach. It answers your follow-up question immediately and with total confidence. By the end of that exchange you feel like you understand the system, because every signal your brain uses to register understanding has been satisfied. The explanation was coherent. Your questions were answered. Nothing pushed back.

But feeling like you understand something, and being able to hold it in your head, change it, and predict how it fails, are completely different states. The first one is cheap now. The second still costs what it always did.

Real understanding comes from friction. From writing something wrong and figuring out why. From the edge case you did not see coming. From the debugging session at midnight where you finally find the root cause and, in finding it, understand the whole system a little better. AI removes that friction so efficiently that the confidence forms but the foundation underneath it never does.

Here is why this should worry you if you lead a team, and not only the people on it.

Every proxy you have ever used to judge whether someone understands their work has just been compromised. Can they explain it clearly? AI made everyone able to explain it clearly. Does the code look clean? AI writes clean code. Do they sound confident in review? Confidence is free now. Do the tests pass? Tests pass on code nobody understands all the time.

The signals you have trusted for years to tell you "this person has a handle on this" have been quietly decoupled from the thing they were supposed to measure. You can no longer read fluency as competence, because fluency is exactly what AI hands out for nothing.

And the gap does not announce itself. It surfaces at the worst possible moment. The 2am incident where the person who owns the code cannot reason about it. The security audit that asks a question nobody on the team can answer. The investor who asks how the system actually works and watches your strongest engineer hesitate. By the time the gap is visible, it is already expensive.

So what do you do about it, short of banning the tools, which is neither realistic nor smart?

You change the test. Stop asking people to explain what the code does, because explanation is the cheap part now. Ask them to change it. Ask what breaks if this input doubles. Ask them to walk you through what happens when this dependency fails at the wrong moment. Understanding lives in the ability to modify and predict, not to narrate, and those are exactly the questions AI cannot answer on someone's behalf while they sit in front of you.

You also have to protect the struggle on purpose, especially for junior people. The debugging session AI could solve in nine seconds is sometimes the entire point. If every hard moment gets smoothed away, the foundation never forms, and you end up with a team that is fluent and fragile. Decide which problems your people should sit inside rather than skip past, and then let them sit there.

And on anything that matters, start tracking the difference between code you shipped and code your team actually understands. Those used to be the same number. They are not anymore, and the space between them is your real risk surface.

AI gives you the feeling of competence before it gives you the thing itself. For an individual that is a trap. For a team, it is a liability that compounds quietly until the day it does not.

The engineers and leaders who come out of this strong will not be the ones who used AI the least. They will be the ones who never let the feeling of understanding stand in for the real thing, and who built ways to tell the two apart before production did it for them.

So, honestly. How would you know, today, which of your engineers understand the systems they own and which ones only feel like they do? If you are not sure, that uncertainty is the work.

Reply and tell me. I read every one.