The Understanding Advantage

Back in 2014, during a business development class at Carleton University, my mentor Dr. Tony Bailetti told me something that stayed with me. He was the director of the Technology Innovation Management (TIM) program, and he argued that while you can outsource tasks or general thinking in business, you can never outsource understanding. He saw understanding as the core driver of critical thinking and real value creation. Tony passed away this past February, but his insight feels more urgent than ever. A decade later, Andrej Karpathy put nearly the same idea in front of a much larger audience, arguing that you can outsource thinking to AI, but you cannot outsource understanding. If understanding is the one thing we cannot delegate, then we should judge every AI tool by a simple test: does it help us understand, or does it just help us skip the work?

The default path is laziness. Ask the model, copy the answer, move on. That workflow treats AI as a vending machine: insert prompt, receive output. It works fine for tasks where you never needed to understand the answer in the first place (formatting a date in Python, generating a boilerplate config). But for anything that matters, skipping understanding is borrowing against a debt you will eventually pay, usually at the worst possible time.

The person who uses AI to skip learning ends up dependent. The person who uses AI to accelerate learning ends up dangerous.

The difference between knowing and understanding

Bloom's taxonomy, a framework from 1956 that still holds up, organizes cognition into layers. At the bottom: remembering facts. At the top: creating new things from what you know. Between them sit understanding, applying, analyzing, and evaluating. Most people use AI at the bottom layer. They ask it to recall facts or summarize documents. That is the equivalent of hiring a research assistant and never reading the brief yourself.

Understanding lives one floor up. It means you can explain why something works, predict where it will fail, and adapt it when conditions change. A developer who understands a caching strategy can decide when to break the pattern. A developer who only knows the pattern will apply it everywhere, including places where it causes harm. Karpathy's point is that the second developer cannot improve by outsourcing more. The gap is internal.

AI as a compression tool for understanding

Here is where I disagree with the pessimistic reading of Karpathy's quote. AI does not only automate thinking. It can also compress the time it takes to build understanding, if you use it that way.

Consider how an engineer learns a new codebase. The traditional path: read the docs, grep through the source, set breakpoints, trace call stacks, build a mental model over days or weeks. With an AI agent that has full codebase context, you can ask targeted questions and get answers grounded in the actual code. "Why does this service retry three times before failing?" "What happens if the cache misses here?" Each answer, when you verify it and connect it to what you already know, compresses hours of reading into minutes of directed inquiry.

The verification step matters. If you accept the answer without checking, you got information, not understanding. If you read the relevant code after the AI points you to it, you built a mental model twice as fast as you would have alone. The AI did not understand for you. It shortened the path to understanding.

Three ways to use AI for deeper learning

The first is Socratic interrogation. Instead of asking AI for the answer, ask it to challenge your answer. "I think the bottleneck here is the database query. What am I missing?" The model can point out that the bottleneck might actually be serialization overhead, because the query result set is small but the objects are deeply nested. That exchange forces you to think harder than you would have alone, because you now have a sparring partner who can check your reasoning against patterns from a very large corpus.

The second is multi-perspective simulation. When preparing for an architecture review, you can ask an AI to argue against your design from the perspective of an SRE, a security engineer, and a product manager. No single colleague has all three viewpoints. The AI's responses will not be perfect, but they will surface blind spots faster than waiting for the review meeting. You prepare better. You understand your own design better. The AI did not replace your judgment; it stress-tested it.

The third is accelerated pattern recognition. Reading 50 incident reports takes a week. Asking an AI to extract the common failure modes, then reading the five reports that are most representative, takes an afternoon. You still read the primary material. But the AI helped you find the signal instead of reading all the noise. This is how a researcher uses a literature review tool: not to skip the papers, but to find the right papers faster.

The discipline problem

None of this works without discipline. The natural tendency is to let AI do the thinking and skip to the output. Every productivity metric in a corporate environment rewards that behavior. Tickets closed. PRs merged. Emails sent. Nobody measures whether the person who closed the ticket actually understood the system they changed.

That measurement gap is where the real risk lives. A team that ships faster because AI handles the boilerplate is stronger. A team that ships faster because nobody on it understands the codebase anymore is a disaster waiting for a novel failure mode that the AI has never seen.

The distinction is subtle from the outside. Both teams look productive. The difference shows up six months later when something breaks in a way that requires understanding to fix, not just pattern matching against prior incidents.

What leaders should do

1. Require engineers to explain, in their own words, the system behavior behind any AI-generated fix before it merges. Code review should test understanding, not just correctness.
2. Build "understand first" into onboarding: new team members spend their first week using AI to ask questions about the codebase, but must write their own architecture summary before touching production code.
3. Track the ratio of AI-assisted learning activities (Socratic prompts, design challenges, failure analysis) to AI-assisted doing activities (code generation, summarization). If the second number is ten times the first, the team is outsourcing understanding.
4. Create a rotation where senior engineers use AI to teach, not just to produce. Have them build prompt sequences that guide a junior engineer through a concept, then measure whether the junior can solve a related problem without AI help.