Understanding Is Not Delegable
Documentation, search, AI, books, examples, libraries and frameworks all accelerate understanding, and the line is that none of them can replace it. The good tool-use loop, the Problem → Ask AI → Copy → Hope loop, and how to tell which one you are in.
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 every tool — docs, search, an AI assistant, a framework that does most of it — and the problem is still yours. What do the tools do for you, what can they not do, and how do you use them without ending up unable to work without them?
The checkout endpoint needs to handle a payment webhook. You ask the assistant for the handler, paste it, and it works in test mode. You could not explain what it does if the webhook arrived twice, and you have a feeling the assistant would give a different answer if you asked again.
Ask for the whole thing. The assistant is fast, its code compiles, and the alternative is reading a provider's documentation you do not yet understand. Delegating the implementation feels like what the tool is for, and it is what everyone around you appears to be doing.
The handler works and the understanding does not exist. When the webhook arrives twice — and it will — nobody on the team can say whether the order is paid twice, because nobody wrote the code with that question in mind, and the assistant was not asked it.
- The handler works and the understanding does not exist. When the webhook arrives twice — and it will — nobody on the team can say whether the order is paid twice, because nobody wrote the code with that question in mind, and the assistant was not asked it.
- The answer cannot be reviewed because there is nothing to review it against. Without your own model of what the handler must do, "looks right" is the whole review, and "looks right" is what wrong code looks like too.
- The next problem starts from zero. The understanding a first attempt would have built — what a webhook is, what idempotency means here, who is authoritative — is not there to reuse, so the refund handler is another delegation, and the one after that.
- You have become the bottleneck you were avoiding. Every change now routes through the assistant, because the code is not yours to change; the tool has stopped accelerating and started substituting.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Split the work into the part that produces understanding and the part that produces artefacts, and delegate only the second. Understanding what a payment webhook must do — what arrives, when, possibly twice, and which system is authoritative for "paid" — is the part the problem requires you to own. Writing the handler once that is known is the part a tool can speed up.
- Run the good loop, in order: think first, form a specific question, use the tool, understand the answer, verify it. Each stage guards the next. Thinking first means you have a model to compare the answer against; a specific question means the answer is checkable; understanding it means you can change it; verifying means you know it works here, not just in the tool's example.
- Recognise the bad loop by its shape: Problem → Ask AI → Copy → Hope. The tell is the absence of a question — the problem was handed over whole — and the absence of a verification step that could fail. If nothing you did could have shown the answer wrong, you did not use the tool; you hoped at it.
- Read "if you are nothing without the tool, you should not have it" constructively: it is a test, not an insult. Ask what you could do about this problem with the tool removed — sketch the handler, say what it must never do, name the failure cases — and if the answer is "nothing", that is the understanding to build before delegating any more.
Two loops with the same tools
The two loops use the same assistant, the same documentation and the same framework. What differs is whether a question and a verification exist. Read the worse column as a sequence of reasonable-seeming steps — each one is what a busy person would do — and notice that at no point could it have discovered it was wrong.
Paste the ticket into the assistant. Take the handler. It runs in test mode. Ship. When the duplicate arrives, paste the bug into the assistant.
Sketch what must happen and what must never happen. Ask how to make the paid transition idempotent under retries. Read the answer and the provider's page on retries. Explain it back: event id stored, transition conditional. Send the event twice; check the order is paid once.
The better loop has two places where being wrong becomes visible — the comparison with the sketch and the duplicate-event test — and the worse loop has none. Correctness in the worse loop is a property of the tool's mood; in the better one it is a property of the verification.
The good tool-use loop, stage by stage
Each stage exists to make the next one possible, and each has a way of being skipped that looks like using the tool well. The failsBy column is the checklist: if any of those describes what you just did, the loop was not run.
- 1Think first
A rough answer of your own: the cases, the invariant, a sketch. Gives the tool's answer something to be compared against.
fails by Handing the problem over whole because "the tool will know".
- 2Form the question
A question with a verb and a scope, about the case that carries the risk.
fails by "Write the handler" — a task, not a question, so the answer cannot be checked against anything.
- 3Use the tool
Docs, search, the assistant, an example — whichever answers fastest; often more than one, and they should agree.
fails by Taking the first answer from the first tool as settled.
- 4Understand the answer
Explained back in your own words, including what it does in the failure case.
fails by "It looks right" — which is also what wrong code looks like.
- 5Verify
A check that could fail: the duplicate event, the malformed payload, the concurrent request.
fails by Running the happy path in test mode once and calling it verified.
The loop is not slow once it is habit; the sketch takes minutes and the verification is the test you would have needed anyway. What it costs is the illusion that the first answer was the end.
Which tool, for which part
Not every part of the problem is delegated the same way. The decision below sorts the webhook work by what it produces, and says what kind of tool use fits each and what the tool cannot be trusted with there. The last option is the one the domain exists for.
For this part of the work, which tool use accelerates without replacing?
when You need facts about a system you do not control.
cost Documentation, read for the specific question; an assistant summary is a starting point, not an authority, because it may describe last year's API (Reading Documentation With a Goal).
when This is the part that carries the risk.
cost Yours to state, in one sentence, before any tool. A tool can check your statement; it cannot supply the intent (What Must Never Break).
when The shape is clear and the typing is the slow part.
cost Assistant or example, then explain-back and the duplicate-event test. Cheap to delegate because you can now review it.
when The framework or SDK does it and has for years.
cost Delegate fully; still read the paragraph on what it does when verification fails, because that is a failure case of yours (Webhook Idempotency).
when Never as a first move.
cost Handing the problem over whole is the bad loop by definition: nothing remains to compare the answer against, so nothing can show it wrong (The AI Dependency Check).
How to do it
Most important first.
- Before asking any tool, write what you think the answer is, even roughly. Pseudocode, a sentence, a sketch of the cases. The tool's answer is then compared against yours, and the difference is where you learn (No AI on the First Attempt).
- Ask the tool a question with a verb and a scope, not a task. "How should this handler behave if the same event arrives twice?" rather than "write the webhook handler".
- Before using an answer, explain it back in your own words, including what it does in the failure case you care about. If you cannot, you do not have the answer yet; ask the follow-up (Explain It Back).
- Verify with something that could fail: run the duplicate, send the malformed payload, check the database state. A verification that cannot fail is a ritual.
- Use the same discipline with documentation, examples and libraries: the framework handles routing so that you do not have to, and you still need to know what it does with a request that repeats (What You Still Own).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The webhook, run through the good loop. Think first: "the provider will POST an event when a payment settles; it may retry; my order must become paid exactly once; the provider is authoritative for whether money moved." Question: "how do I make an order-paid transition idempotent when the same event can arrive twice?" Tool: docs and the assistant, both. Understand: the event carries an id; store it; make the transition conditional on not having seen it. Verify: send the same event twice against a test order and check that it is paid once and the second call is acknowledged without a second transition.
- The same webhook, through the bad loop. "Write me a webhook handler for this provider." The code arrives, is pasted, and marks the order paid on every event. In test mode with one event it works. The duplicate arrives in production, the order is paid twice, and the fix is another delegation because nobody can say what the handler should have done.
- The framework as a delegation. Routing, sessions and form parsing are handed to the framework, correctly — those are artefacts. What is still yours: what happens when the session expires with a cart in it, and what the framework does with a double-submitted checkout form. Reading the two paragraphs of the docs that answer those questions is understanding being accelerated; not reading them is the same bad loop with a different tool.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Before every tool use there is a rough answer of your own, and afterwards you can say where the tool's answer differed and why you took it.
- Every accepted answer has been explained back, including its behaviour in the failure case that matters here.
- Verification exists that could have failed, and sometimes did.
- With the tool removed, you could still sketch the handler, name its failure cases and say what it must never do — slower, but not from nothing.
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.
- ?Which part of this is understanding I have to own, and which part is an artefact a tool can produce once I own it?
- ?What do I think the answer is, before I ask?
- ?What verification could show this answer wrong — and have I run it?
- ?If the tool disappeared, what could I still do about this problem, and is that enough?
What can go wrong
- The move becomes tool refusal. Writing a payment SDK from scratch to "really understand it" is not understanding; it is a different delegation — to your own time — and the SDK author has already handled cases you will not think of. Delegate the artefacts.
- Understanding is checked once and assumed forever. Tools change, providers change their event shapes, and the handler you understood in the spring is a different handler after a year of pasted patches.
- The first attempt is written and then ignored. If the tool's answer is taken without comparison to yours, the first attempt was a ritual too.
- The move is applied to trivia. Nobody needs to own their understanding of a date-formatting call; the discipline is for the parts of the problem that carry its risk, and spending it on everything is how it gets dropped where it matters.
- The good loop is slower per answer than the bad one. The first webhook handler takes an afternoon instead of a minute; the bet is on the second, third and fourth handler, and on the incident that does not happen.
- Writing a first attempt before asking is work that is often thrown away when the tool's answer is better — and it usually is. The value was in the comparison, and comparisons do not show up in the commit.
- Verifying with something that could fail means building the duplicate-event test, the malformed payload, the concurrent request — infrastructure the bad loop never pays for.
- "So do not use AI for real code." Use it for real code, after the question is formed and before the verification runs. The manifesto's line is about understanding, not about typing; the tool can do a great deal of the typing.
- "The first attempt has to be good." It has to exist. A wrong first attempt still gives you something to compare the tool's answer against, and the wrongness is often where the understanding is.
- "Frameworks and libraries are different from AI." They are the same delegation with a longer track record. A framework you cannot explain the request lifecycle of is a pasted answer with a logo (Framework Independence).
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 split — own the understanding, delegate the artefacts — applies to every tool, from a search result to a framework to an assistant, and to every domain; what counts as the understanding that carries the risk is domain-specific.
- DOMAIN-SPECIFICIn payments, identity and anything with an invariant, the failure case is the whole point and the good loop is not optional. In a throwaway internal dashboard the artefacts are nearly everything and a pasted chart component is a fine trade. The line moves with what a wrong answer costs.
- CONTESTEDA serious opposing view holds that this understates how much the tools have changed the job: that for most application code, understanding at the level of intent and tests is enough, that demanding a first attempt on everything is a nostalgia tax, and that the engineers who ship fastest are the ones who delegate the most and verify the hardest. On that view, the discipline should be almost entirely in verification, and "think first" is optional overhead outside the risky core.
- ILLUSTRATIVEThe webhook, the provider, the double payment and the afternoon are invented to show the two loops; no real provider's event format is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto states the principle this lesson is the working form of: don't delegate understanding.
- — The delegation cards at /manifesto/delegating list, for a payment SDK and others, what the tool handles and what stays yours; /manifesto/review is the explain-back discipline applied to an LLM's answer; /manifesto/without-ai is the removal test as a practice.