Good Tool Use
Problem → Think → Form Question → Use Tool → Understand Answer → Apply → Verify. The tool is in the middle of the sequence, not at the start of it — because a question you have not formed produces an answer you cannot judge.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You have an AI assistant open next to the editor and a problem you do not understand. What is the sequence that uses the tool well, and how do you tell it apart from the one that only looks like it?
The checkout has to handle a payment that fails after the order was created. You open the assistant, type "how do I handle failed payments in checkout", get a long, confident answer with a code block, and paste it in. It compiles. You cannot say whether the order is now in a state anyone intended.
Ask first, think later. The assistant is fast and articulate, and asking costs nothing; it feels wasteful to spend twenty minutes thinking about something it can explain in twenty seconds. The answer arrives, it looks right, and the problem appears to have moved.
The answer is to a question you did not ask. "How do I handle failed payments" has no store in it — no order state, no invariant, no provider — so the assistant answered the generic version, and its code handles a failed payment in a system that is not yours.
- The answer is to a question you did not ask. "How do I handle failed payments" has no store in it — no order state, no invariant, no provider — so the assistant answered the generic version, and its code handles a failed payment in a system that is not yours.
- You cannot verify what you cannot state. Without a prediction of what the code should do, "it compiles" and "it looks right" are the only checks available, and both are satisfied by code that leaves the order paid-but-unpaid.
- The vague question stays vague. The assistant filled the gap with plausible defaults, so "what is the order's state when payment fails?" — the actual unknown — was never asked, never answered, and is now buried in pasted code.
- The next time the same problem appears, the same sequence runs. Nothing about payment failure was learned; only that the assistant will produce something when asked. That is a dependency, not a skill (Tutorial Dependency).
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Put the tool in the middle of a sequence, never at the front: Problem → Think → Form Question → Use Tool → Understand Answer → Apply → Verify. Each step before the tool produces something the tool needs — a stated problem, a first attempt at an answer, a question specific enough to be wrong — and each step after it produces something only you can: an explanation in your words, a prediction, a check.
- Think before asking, but only long enough to form a question. The purpose of the Think step is not to solve the problem alone; it is to find out what you already know, what you believe the answer is, and where exactly the gap is. A question formed from that gap is narrow, and a narrow question gets an answer you can judge (Question Quality).
- Treat the answer as a claim, not a result. Read it until you can say what it does in your own words and what you expect to happen when you run it. If you cannot, you are not at Apply yet; you are at Understand, and the next question goes back to the tool (Explain It Back).
- Verify against your prediction, not against the absence of errors. The Verify step is what turns a pasted answer into evidence: it ran, it did what you said it would, and where it did not, you now have a specific question rather than a working mystery.
Two sequences that produce the same code block
The reflex sequence is short and the good one is longer, and both end with code in the editor. The pipeline below is the longer one, with what each step produces and how it is usually skipped. Notice that the tool step is in the same place in both; what differs is everything before and after it.
- 1Problem
What has to be true when this is done, in your system's terms.
fails by Starting from the symptom — "payments are broken".
- 2Think
What you already believe the answer is, and where the gap is.
fails by Skipped, because the tool will answer anyway.
- 3Form Question
A question narrow enough to be wrong, containing your entities and invariants.
fails by "How do I handle failed payments?"
- 4Use Tool
The answer — treated as a claim from a well-read stranger.
fails by Treated as a result.
- 5Understand Answer
What it does, in your words, with the answer closed.
fails by Reading it twice and nodding.
- 6Apply
The smallest piece you understand, put into the system.
fails by The whole block, pasted.
- 7Verify
The prediction, checked by running something.
fails by "It compiles."
The reflex is Problem → Use Tool → Apply → Hope. It is not a shorter version of the sequence; it is a different sequence that skips every step only you can do.
The question that goes into the tool
The step that decides everything downstream is Form Question. The ladder below shows the same need at three levels of precision; the best form is what the Think step produces, and it is the only one whose answer you could check.
why The best form makes the answer checkable: it names the states to look for, the authority to defer to, and an invariant — one state change per notification, however many arrive — that a test can be written against. The vague form can only be answered generically, and a generic answer cannot be verified against a specific store.
What the answer is, and what it is not
The answer from the tool is an input to Understand, not an output of the sequence. The comparison shows the same answer handled both ways: once as a result to apply, once as a claim to understand and test. The code is identical; the engineering is not.
Paste the block. It compiles. Move the ticket. When a customer is charged for an order marked failed, open the assistant again and ask why.
Close the block and say what it does: a pending state, a transition on confirmation, a check for an already-applied notification. Predict: two identical notifications, one transition. Run it. Where the prediction fails — the second notification also transitions — the follow-up question is exactly about that check.
The claim version produces an explanation and a prediction, and those are what let the code be changed and debugged later without the tool. The result version produces code and a dependency, and the dependency is invisible until the code is wrong (Understanding Is Not Delegable).
How to do it
Most important first.
- Before typing into the assistant, write one sentence saying what you think the answer is, even if it is "I think the order should go back to unpaid, but I do not know who decides". The sentence is the question's raw material and the later prediction.
- Make the question contain your system: the entity, the state, the invariant, the external party. "In a store where the order is created before payment, what should the order's state be when the provider reports failure, and which system is authoritative?" (Asking Better Questions).
- When the answer arrives, close it and write what it does from memory. Where you cannot, reopen it and ask the tool about that part specifically — the gap is the next question.
- Apply the smallest piece you understand, run it, and compare with the prediction. A mismatch is the most valuable output of the whole sequence (Prediction Before Execution).
- Once a week, pick something the tool wrote and reproduce the core of it without the tool (Build From Memory). If you cannot, the sequence has been skipping Understand.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The failed-payment question, run through the sequence. Think: the order exists before payment; a failure must not leave it looking paid; the provider is outside the system, so its answer may be late or duplicated. Question: "given an order created before payment, what states should it have, and how should a late or duplicate failure notification be handled?" Answer, understood: a payment-pending state, a transition on the provider's confirmation, idempotent handling of the notification. Prediction: two identical failure notifications leave exactly one state change. Verify: send two; observe one.
- The same question, run the reflex way, for contrast. "How do I handle failed payments in checkout" → a generic try/catch around a charge call, setting the order to failed on exception. Applied, it handles a synchronous failure and does nothing about the provider's asynchronous confirmation, which is how this provider actually reports. Nothing in the answer was wrong; the question just had no store in it.
- The chat app: "how do I do read receipts" → the reflex answer is a boolean on the message. The sequence answer starts from Think: "read" per user, per device, or per conversation? The question becomes "how should read state be modelled when a user has several devices and a conversation has several members?", and the answer — a per-member last-read pointer — is one the vague question could not have produced.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every question you send contains a noun from your system and a belief you already hold about the answer.
- You can close the assistant's answer and say what it does; where you cannot, you know which part and have a follow-up question about that part only.
- Applied code comes with a prediction, and the prediction has been checked at least once by running something.
- The same class of problem, met again, takes less tool use than last time, not the same amount.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What do I already believe the answer is, and where exactly is the gap I am asking about?
- ?Does my question contain my system — its entities, its states, its invariants, its external parties — or would it fit any system?
- ?Can I say what this answer does with the answer closed?
- ?What do I predict will happen when I run this, and what would show me it did?
What can go wrong
- Think becomes a gate: nothing is asked until the problem is fully understood, which defeats the tool. The Think step is over when a question exists, not when the answer does.
- Understand is performed rather than done. Reading the answer twice is not the same as being able to reproduce its core; the test is what you can say with the answer closed.
- Verify checks that it runs. Running is not the prediction. If the prediction was "two notifications, one state change", the check has to send two notifications.
- The sequence is applied to lookups. "What is the flag to make this library log to stderr?" needs no Think step and no prediction; the sequence is for problems, not for reference questions.
- The sequence is slower per question than the reflex, and on a trivial question it is slower for nothing. The gain is per class of problem, not per question.
- Forming a narrow question means committing to a belief that may be wrong, and being wrong in writing is less comfortable than being vague. The discomfort is the point; the belief is what the answer can correct.
- Verifying against a prediction sometimes means building a small harness — two notifications, one row — that the pasted answer would have let you skip.
- "So I should use the assistant less." No — you should use it later in the sequence and more precisely. Someone running the sequence well often asks more questions than the reflex does; they are just narrower.
- "Think means solve it yourself first." Think means find the gap. Five minutes of writing what you believe is usually enough; an hour of solitary struggle before asking is a different lesson (No AI on the First Attempt) and has a different purpose.
- "If the answer runs, Verify is done." Running tests the syntax. Verify tests the prediction, and a prediction about state under a duplicate notification is not tested by the code compiling.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe sequence is the same whether the tool is an assistant, a search engine, documentation or a colleague: form the question, understand the answer, verify. What changes with an assistant is how easy it is to skip the first step, because it will answer a question that has not been formed.
- TEAM-SPECIFICA solo learner should run the sequence on almost everything, because the understanding is the product. A senior on a deadline can skip Think on problems they have solved before — the belief already exists — and the sequence collapses to question, answer, verify.
- ILLUSTRATIVEThe failed-payment question, the chat app read receipts and the specific answers are invented to show the shape of the sequence; no real assistant transcript is quoted.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto states the principle this sequence practises: tools accelerate understanding and must not replace it. The delegation cards at /manifesto/delegating are the "what am I handing over?" question, asked of a tool instead of a library.