Developing Your Intuition

Thirty-one lessons have handed you rules. Clear between tasks. Plan before coding. Be specific. Give it something to verify. Keep the memory file short.

Every one of those is a good default, which is not the same thing as a law. They are the settings that work most of the time for most people on most tasks, which means each of them is wrong somewhere. This last lesson is about finding those places yourself, because that is what the difference between following advice and being good at something actually consists of.

Three rules, and where they break

Sometimes let context accumulate

The rule says clear between tasks, because stale context degrades output and costs money.

Now picture a genuinely difficult bug. You are four hours in. Claude has tested and discarded five theories, and the reason the sixth idea is any good is that it is informed by the five failures. Clearing here does not give you a clean session; it gives you a session that is about to suggest theory number two again.

The rule was never really about age. It was about relevance. Irrelevant history is noise you pay for; relevant history is the reason the next step is possible. What you are actually asking is not "how long has this been open" but "if I threw this away, would I have to rediscover it".

Sometimes skip the plan

Planning pays when the approach is uncertain, when the change touches several files, or when you do not know the code being modified. That is three conditions, and the useful move is to check whether any of them hold rather than to plan reflexively.

The test that cuts through it: if you could describe the resulting diff in one sentence, there is nothing to plan. Adding a log line, renaming a variable, fixing a typo in a string. Asking for a plan there produces a paragraph describing a decision you had already made, and you pay for it in both tokens and attention.

Sometimes be vague on purpose

"Be specific" is the single most reliable prompting advice there is, and it assumes you know what you want.

When you do not, vagueness is the point. "What would you improve in this file?" is a bad instruction and a good question. So is "read this module and tell me what surprises you". You are trading precision for coverage, deliberately, because the thing you most want to find is the thing you did not think to ask about. Then you get specific, once you know what you are aiming at.

Learning to notice

The feedback you need is already in your sessions. It just goes past unlogged.

claude

1. WhyA session that went unusually well. The task was a tricky cache invalidation bug, and it was fixed in one pass. Worth two minutes to work out why, because a session like this is data.

2. >You typed: The stale-cache bug is fixed. Before we move on — from your side, what in how I set this up made it go quickly?

3. Claude replied: Three things. You gave me a failing test first, so I never had to guess what correct meant. You said the bug was somewhere in the invalidation path rather than asking me to find it in the whole cache layer, which cut the reading by a lot. And when I suggested widening the lock, you said no and explained why in one line, so I did not spend a turn defending it.

4. WhyNone of that is flattery, and none of it is new advice — it is lessons 10, 9 and 12 respectively. What makes it useful is seeing them attributed to a specific outcome in your own work rather than read in a list.

5. WhyDo the same after a bad session, and be blunter: what would have made this go better. The answer is usually context you had and did not pass on. Notice which kind, because it will be the same kind next time.

Ask after the good ones as well as the bad ones. Failures are conspicuous and get examined anyway; successes are the ones that slip past, and the reason a thing worked is the more transferable half.

The /insights command does a version of this across your recent sessions, producing a report on where the friction is. It is worth running occasionally. It is not a substitute for the two-minute version, because it can tell you that you often have to repeat yourself, and only you know what you were trying to say.

What you know now

You started this course not knowing what an agent was.

You now know that it is a model with tools and the ability to read what those tools returned, which is what lets it act, check and correct without you carrying every result between steps. You know how to stay in control of one: permissions, checkpoints, and the habit of stopping it the moment it goes somewhere wrong.

You know the daily craft, which is mostly about two resources. Context, which fills up and degrades as it does, so you keep it clean and relevant. And verification, which is the only thing that separates code that looks right from code that is right — a test, a build, a screenshot, anything that returns a pass or a fail without an opinion.

You know how to make it yours: a memory file for what applies always, skills for what applies sometimes, hooks for what must happen every time, MCP for reaching other systems, and subagents for work whose output you do not want in your main conversation. And you know how to pick between them, which is the part that actually takes judgement.

And you know how to scale past one session: non-interactive runs in scripts and pipelines, worktrees so parallel sessions do not tread on each other, CI, the levers that control cost, and the boundaries that matter when nobody is watching.

That is a complete working knowledge of the tool. What remains is mileage.

Keeping up

An honest warning to close on. Claude Code changes weekly, and some of the specifics in this course will drift. A flag gets renamed, a research preview becomes a default, a command grows an option that makes an old workaround unnecessary. That is what a fast-moving tool looks like from the inside.

Two places carry the changes. The documentation has a What's new section: a weekly digest of the features most likely to change how you work, each with an example and a link to the full page. Alongside it is a changelog for the smaller fixes, which is where to look when something behaves differently from last week and you want to know whether it was you. claude --version tells you what you are running, and claude update moves you forward.

The concepts move much more slowly than the flags. Context is a finite resource, plausible is not the same as correct, and an unattended agent needs a boundary rather than good intentions — none of that is going to be untrue next year. When a detail here stops matching what you see on screen, trust the screen and keep the idea.

What to take away

The rules in this course are defaults, not laws, and each one exists to answer a question that outlasts it. Let context accumulate when the history is the reason the next step is possible. Skip the plan when you could describe the diff in a sentence. Be vague on purpose when you are looking for the thing you did not think to ask about. The way you find the rest of these exceptions is by noticing: ask, after a session that went unusually well or unusually badly, what you did differently, and take the answer seriously. That habit is the whole of expertise with this tool, and it is not something any course can hand over.

That is the end of the Claude Code Masterclass. You know what an agent is, how to direct one, how to verify what it produces, how to configure it for your project, and how to run it beyond a single session without losing control of it.

Two things to do next. Sit the Claude Code Certification while the material is fresh — it is written to test judgement rather than recall, so it will show you which of these ideas you have actually absorbed, and there is a free practice paper if you would rather find out before paying. And if you have been running an agent over code you cannot fully read yourself, the JavaScript Masterclass is the obvious companion: reviewing what Claude writes is a skill that rests entirely on understanding the language it is writing in.

Thank you for reading this far. Go and use it on something real.