Using AI to learn faster, not just to type faster
Almost all the discourse about AI coding tools is about output — lines written, PRs opened, tokens saved. The most underrated use is the opposite: input — how fast a good model gets you to understanding something you didn't know this morning. Treated as a tutor instead of a typist, it's the highest-leverage and least-discussed thing these tools do.
The techniques that actually work
- "Explain this codebase / system to me." Point a long-context model at an unfamiliar module and ask for the map before you dive in — the data flow, the load-bearing parts, the surprising bits. Twenty minutes of orientation that used to take a day of spelunking.
- Teach-back (the Feynman move). Explain the concept to the model and have it find the holes in your understanding, or ask it to quiz you. Generating-and-checking your own explanation is how you find out you didn't actually understand the thing you were about to ship.
- "What am I missing?" After you've formed a plan, ask for the failure modes, the edge cases, the thing experienced people know that you don't. It's a cheap pre-mortem against your own blind spots.
- Map before you commit. Before touching unfamiliar territory — a new framework, a gnarly subsystem — have it sketch the landscape so you're navigating with a map instead of by feel.
The tool's best trick isn't writing the code you know how to write. It's collapsing the time between "I have no idea how this works" and "okay, I can reason about this."
The trap, named plainly
Learning is exactly where confident-wrong is most dangerous, because the whole point is that you can't yet tell. When you're using a model to write code you understand, you catch its mistakes. When you're using it to learn something you don't, you have no error-correction — its fabricated API, its plausible-but-wrong mental model, its subtly off explanation all land as "facts."
So the discipline:
- Use it to orient, verify against primary sources. Let it get you to the right questions and the right docs fast; confirm the load-bearing facts against the real documentation, not its summary.
- Don't outsource the understanding you actually need. If you'll have to maintain it, debug it at 3am, or defend it in review, you need the model in your head, not just on your screen. Use the tool to get there faster — not to skip the trip.
- Cross-check across sources when it matters. Disagreement between the model and the docs is a signal to dig, not a coin-flip.
Information work, same rules
Beyond code, the same pattern applies to the reading-and-synthesis half of the job: summarize a long spec, extract the decisions from a thread, cross-reference a design doc against the implementation (long context shines here). Enormous time savings — with the same non-negotiable caveat that judgement stays yours. The model drafts the understanding; you own whether it's right.
The skill that compounds
Here's the quiet payoff: the meta-skill of learning well with AI — asking sharp questions, then verifying the answers — is the same skill that makes you good at directing agents. Both are about specifying precisely and checking rigorously. Get good at using these tools to learn, and you're getting good at the thing the next decade of software work rewards most: knowing what to ask, and knowing when the confident answer is wrong.
Inspired by the personal-AI-workflow and accelerated-learning writing at tomaskubica.cz.