Learning vs leveraging
Use AI for the boring parts. Struggle through the hard ones. The talk says this in 30 seconds — this page is the longer version, with concrete rules for when to lean on the agent and when to keep it closed.
Why this matters
Skill is built by struggling at the edge of what you can do — psychologists call this desirable difficulty. Memory consolidates when you have to reach for the answer; it doesn't when the answer arrives instantly. An agent that solves your problem in 3 seconds is taking that struggle away from you.
That's fine for routine work. It is not fine for the things you're trying to learn. Reviewers can tell within five minutes of a code review whether someone has internalised a concept or has been outsourcing it. The people who get hired pull both levers — they ship fast on what they already know, and they slow down when they're learning something new.
Use AI freely for
- Boilerplate. CRUD endpoints, config files, test scaffolding, type definitions. Nothing is being learned by typing the 47th database connection.
- Translation. Convert this Python to TypeScript. Convert this REST call to gRPC. The skill is in knowing the destination, not in the keystroke labour.
- Lookup. What's the syntax for X in framework Y? Faster than docs for things you already understand conceptually.
- Refactoring at scale. Rename across 40 files, extract a function, change a signature. The agent is more accurate than you here.
- Debugging when you have a hypothesis. "I think the bug is in X — find me the line." You're driving, the agent is doing the search.
Slow down (or go agent-free) for
- The first time you encounter a concept. First time touching async/await, first React app, first SQL JOIN. Type it out badly, see it fail, fix it. That's the loop your brain learns from.
- Algorithm and data-structure interview prep. The agent will solve every LeetCode problem instantly. You won't pass the interview that way. Practice without it.
- Reading other people's code. Don't ask the agent to summarise — read it yourself. Code-reading is a skill that decays without practice.
- Debugging without a hypothesis. If you hand the bug to the agent before you understand it, you'll skip the diagnostic skill. Form a hypothesis first, even a wrong one.
- Architecture and design choices. Trade-offs come from experience. Agents will plausibly recommend something — that's not the same as understanding why.
The 70/30 rule for someone learning
A rough heuristic: if you're early in your career, aim for ~70% of your hands-on time in agent-augmented mode (shipping things) and ~30% in agent-free mode (deliberately practising fundamentals). The 30% is what makes you sharper next year. The 70% is what gets you promoted this year.
If you're senior, the ratio inverts for new domains and stays at 90/10 for your home domain. The principle is the same: you grow at the edge.
How to tell whether you've learned something
- Could you have produced this code without the agent's help, given enough time?
- Could you explain the choices to a colleague, including what you rejected and why?
- If a similar problem appeared next week, would you reach for the same approach?
Three yeses → you've actually learned it. One or zero → you've leveraged the agent for delivery, which is fine, but don't confuse it with skill.