CLAUDECODE101 · chapter 3 of 21 · free to read
This is the whole chapter, not a sample of it. Nothing is shortened for the showcase and nothing here is recorded — no account, no cookie, no reading history. Every chapter of this ladder was signed by a named person before it was served; this one by Capt Anil Sharma.
There is a belief that working well with these tools is about clever phrasing — magic words, a good opening line, a trick that unlocks better output. CodeAI101's capstone already said otherwise, when it listed the seven things you must supply that AI cannot: notice what is not on that list — clever prompts.
What actually decides the outcome is much less mysterious and much less fun: whether you said what you meant precisely enough that only one reading of it is possible. That is not prompting. It is specification, the oldest skill in software wearing a new coat.
THE MODEL IS NOT GUESSING WHAT YOU WANT BECAUSE IT IS STUPID — IT IS GUESSING BECAUSE YOU LEFT IT A CHOICE.
Consider a task you might genuinely give it.
A: "Clean up this file."
B: "In this file, remove the three commented-out functions at the bottom, and add a one-sentence comment above each remaining function. Change nothing else."
Both are grammatical. Both are things a colleague would understand. In a loop they behave completely differently.
A has no end state. There is no moment at which "cleaned up" is demonstrably achieved, so the loop cannot know it is finished — and Day 4 told you what an agent does when it cannot recognise completion.
A also does not say what not to do. "Clean up" plausibly includes renaming things, reformatting, restructuring. If you did not want those, you did not say so.
B has an end state you could check with your eyes: three functions gone, one comment above each remaining one, logic unchanged.
Not a formula to recite — a checklist you run in your head in about ten seconds.
THE END STATE. What is true when this is done? If you cannot describe it in a sentence, the loop cannot recognise it either.
THE SCOPE. Which files, which folder, which part. Left unsaid, the scope is everything in reach — which is why chapter 1 spent so long on the directory you start in.
THE FENCES. What must not change. This is the highest-value sentence you will write, and the most commonly omitted.
HOW YOU WILL KNOW. What you would look at to confirm it worked. If nothing would settle it, you have written a wish rather than an instruction.
A REAL CASE: THE FENCE THAT WAS NOT WRITTEN
This one is from the building of this course.
Chapter 4 of this ladder teaches the six permission modes. One of them is auto, which decides for itself when to ask. While the lab for that chapter was being built, a row was written claiming a definite behaviour for it — entirely reasonable, since a mode called auto plausibly proceeds automatically. It was also not something anyone had confirmed.
The row now reads depends, and the lab says plainly that the help text does not state the rule.
What caught it was not somebody being careful. It was a sentence written down in advance, before the lab was built: this lab must not state behaviour that is not documented. A fence, written before the work, doing its job while nobody was watching.
What would change this decision: if the behaviour were documented somewhere citable — release notes, help text, an official reference — the row could state it and cite that.
Notice what the fence cost to write. One sentence, before any work. Notice what its absence would have cost: a fabricated claim shipped inside a course about not fabricating claims.
They are written in the same grammar and behave completely differently.
"Prefer smaller functions" is a preference. Ignored, you get something you like slightly less.
"Do not change the database schema" is a fence. Crossed, you have a problem a review might not catch and a rollback might not fix.
A PREFERENCE COSTS YOU TASTE. A FENCE COSTS YOU A MORNING, OR WORSE.
So the ten seconds you spend on an instruction should go into the fences, not the phrasing. And the reason fences get omitted is always the same: it was obvious to you. You are not the one carrying it out.
Here is a test that costs nothing. For each thing you did not say, ask what happens if it is done anyway. If the answer is that you would be mildly annoyed, it was a preference and you can let it go. If the answer is that you would have to undo something, it was a fence and it needed a sentence.
A SECOND REAL CASE: PRECISE, CONFIDENT, AND WRONG
The first case was an instruction with a gap. This one had no gap at all and was still wrong — which is the failure people do not expect.
While building the checking machinery for this ladder, a rule was specified: every command block in a chapter must be followed, within eight lines, by a line saying what you should see. Precise. Checkable. It has an end state, a scope, and evidence. It went straight into a check, and the check immediately failed two chapters that were not wrong.
The specification was exact about a number and wrong about the thing. "Within eight lines" was never what was meant. What was meant is that the verification belongs to that command — which runs to the next command or the next section, not to a line count.
The rule now runs to that boundary instead of counting lines, and the two chapters pass, because they were never wrong.
What would change this decision: if chapters were generated to a fixed template rather than written by a person, a line count would be fine.
The lesson is uncomfortable and worth having. PRECISION IS NOT THE SAME AS CORRECTNESS, and a precise wrong specification is harder to spot than a vague one — because it looks like care.
A reasonable objection: if I specify everything, why use the tool at all? Isn't leaving room for its judgement the point?
There is something real in that. Yes — there are tasks where you genuinely want proposals rather than execution. "What are three ways this could be structured, and what does each cost?" is a good instruction.
But notice what it still has: a clear end state (three options, with trade-offs), a scope (this structure), and an implicit fence — you are asking for options, not for the change to be made.
The failure mode is not being open. It is being vague about the task while expecting precision in the result, and then treating the mismatch as the tool's fault.
OPEN-ENDED ABOUT THE SOLUTION IS A CHOICE. VAGUE ABOUT THE GOAL IS AN OMISSION.
Sometimes you cannot write a good instruction because you do not yet understand the problem. That is ordinary, and there is a move for it.
Chapter 4 covers the permission dial, and one of its six positions is plan — the tool works out what it would do and shows you, without touching anything. That position exists for exactly this case. You get a proposal to argue with before any file changes, and the argument is where the specification gets written.
Working out what you want by reading a proposal is a legitimate technique, not a sign you should have thought harder first.
Keep one thing in proportion, because it prevents a common frustration.
Chapter 5 covers what a session already contains before you type — instruction files loaded automatically, sometimes thousands of words of standing rules. So if the tool consistently does something you did not ask for, the cause may not be your wording at all. Something else in scope may be telling it to.
Rephrasing an instruction that is competing with a standing rule is the most frustrating loop a beginner can get into, precisely because the wording is not the problem.
The useful part of this skill is testable anywhere, and it transfers to instructing people.
Take any task you would give someone and ask the four questions. What is true when it is done? What is in scope? What must not change? How would I know it worked?
Most instructions people give each other fail at least two of those and get away with it, because a human colleague asks. A loop does not ask.
Before sending any instruction to any agentic tool:
Could I recognise "done" if I saw it? If not, neither can it. What have I left in scope that I did not mean to? What am I assuming will not change — and did I say so? For each unsaid thing: annoying, or a morning lost — because only the second kind needs to be in the sentence. And what would I accept as evidence, rather than as a report?
THE GAP IN YOUR INSTRUCTION DOES NOT PRODUCE A QUESTION — IT PRODUCES A CONFIDENT GUESS, AND YOU WILL FIND OUT WHICH ONE LATER.
Chapters 1, 2 and 4 also cost nothing. Enrolling is what carries your record; there is no payment for those.