Three skills
understanding, stating, checking
What it is
The whole book is built around three skills. This is not a neat diagram but the actual shape of the contents: chapters 2, 3 and 4 are the three skills, one chapter each.
| Skill | What it means | Chapter |
|---|---|---|
| Understanding | reading code, knowing the terms, seeing a project's structure | 2 |
| Stating | framing a task so that what you had in mind comes out | 3 |
| Checking | making sure it worked, catching errors, rolling back | 4 |
The other chapters are applications of these three: process and tools (5), architecture (13), the practicum (14), the stack chapters.
Why they are needed together
The skills are not independent. Each leans on the others, and a gap in one brings down the whole thing.
Without understanding, checking does not work. You cannot be sure code does the right thing without reading it. A run checks exactly one case — the one you ran.
Without stating, understanding is wasted. You can see the solution is wrong but cannot explain which one you need — and the next attempt comes back the same.
Without checking, the first two are useless. Read it, framed it, got the code — and never ran it. Everything before that was for nothing.
That is why the working cycle in article 1.2 looks like a cycle: the three skills are applied in turn on every lap.
Where to start
If you develop them one at a time, the order is this:
Stating first. It pays off fastest: a good prompt saves an hour the first time you use it, and it can be learned in an evening. That is exactly why chapter 3 was written first.
Understanding second. The largest skill and the slowest to acquire, but without it you hit a ceiling: you can improve prompts forever, yet control will not appear until you read the result.
Checking third. It comes quickly once the first two are there. Partly it is just a set of habits: run it, look at the diff, run the tests.
What to tell the AI
The skills can be practised inside ordinary work, by adding one sentence to ordinary tasks.
For understanding:
Before I accept this code: explain line by line what it does.
I want to understand it, not just paste it.For stating — feedback on your own prompts:
I stated the task like this: <prompt>. What was unclear in
that wording? What did you have to fill in yourself?For checking:
Which three cases should I check by hand to be sure
this works? Include at least one failing case.The second prompt is especially useful. It turns every failed attempt into a lesson: instead of irritation you get a concrete list of what was missing.
What to look for
Leaning too far into stating. It looks like collecting tricks: ever newer ways to ask, while the result still goes unread. The ceiling arrives fast.
Leaning too far into understanding. Picking apart every line, including the ones you never meant to change. Reading is a means, not an end; enough is enough (article 2.1).
Checking postponed "until later". The most expensive imbalance: errors pile up and are all found at once, exactly when they are hardest to find.
Cheat sheet
Three skills: understand · state · check. Chapters 2, 3, 4.
Without understanding there is no checking; without checking the first two are useless.
Start with stating — it pays off fastest.
Understanding is the slowest skill and the most important.
Redoing it three times — stating. Afraid to touch the code — understanding.
Ask: "what did you have to fill in from my wording?"