No AI on the First Attempt
Problem → your understanding → your decomposition → your pseudocode → your attempt → then ask for help. The order is the lesson: help given after an attempt corrects it; help given before one replaces it.
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 are facing a problem you have never solved and a tool that would solve it in seconds. What do you produce before you ask, in what order, and why does the order matter more than the quality of what you produce?
You have to build the checkout and you have never built one. The blank file is unpleasant. You know that within a minute you could have a plausible checkout on screen, and you also know that last time you did that, you spent the following week unable to change it because you did not understand it.
Get a starting point from the tool and then make it yours. A generated checkout is a draft; you will read it, modify it, and by the end it will be as good as understood. Starting from something is easier than starting from nothing, and easier is faster.
The draft sets the shape, and the shape was the decision. Whether the order exists before the charge, where the total is computed, what a retry does — all decided by the draft, and every later modification is inside that shape. You never chose it and you cannot see outside it.
- The draft sets the shape, and the shape was the decision. Whether the order exists before the charge, where the total is computed, what a retry does — all decided by the draft, and every later modification is inside that shape. You never chose it and you cannot see outside it.
- "Make it yours" never happens because there is nothing to make it from. Modification requires a model of what the code should do; the draft supplied the code and not the model, and reading it produced agreement, not a model.
- The attempt that would have found your misunderstanding was never made. You would have created the order after the charge; the draft did it before; you accepted the draft's order without ever noticing that yours was different, so the misunderstanding is still there, dormant.
- A week later the requirement moves — guest checkout, or a second provider — and the code has to change in a way the draft's shape resists. The change is hard because the shape was never yours.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Produce four things before asking anything, in this order: your understanding of the problem in your own words; your decomposition into pieces you could test; your pseudocode for the core; your attempt at code. Each is allowed to be wrong. Their purpose is not to be right; it is to exist, so that help has something to correct (Pseudocode Before Code).
- Treat the order as the mechanism, not a ritual. Understanding before decomposition because you cannot split what you have not described; decomposition before pseudocode because pseudocode needs a piece to be about; pseudocode before code because syntax hides logic; attempt before help because help is a diff against an attempt, and with no attempt the diff is the whole solution (Decomposing a Problem).
- Ask for help at the point of the specific difficulty, with the four artefacts attached. "Here is my understanding, decomposition and pseudocode; here is where my attempt fails; what concept am I missing?" The help that comes back is aimed at a gap you found, which is the only kind that closes it (The Hint Ladder).
- Keep the attempt when the reference arrives, and compare. The places where they differ are the places where your model was wrong, and each one is a specific thing learned. An attempt discarded on the arrival of the reference has taught only that references exist (Build From Memory).
The order, and why each step comes where it does
The sequence is the lesson, so it is given as an order with the reason beside each step. The alternative is the worked-example-first sequence from the contested scope, and it is a real alternative for a real kind of learner; the device carries it so the reader can choose rather than inherit.
- 1Your understanding: the problem in one paragraph, in your words
because You cannot decompose what you cannot describe, and a description in someone else's words hides whether you have one.
- 2Your decomposition: pieces you could test
because Pseudocode has to be about a piece; a whole checkout is too large to sketch honestly.
- 3Your pseudocode: inputs, outputs, state, branches including failure
because Logic before syntax — the retry and the sold-out case are visible here and hidden in code.
- 4Your attempt: code from the pseudocode, until it fails somewhere specific
because The failure point is the gap; without it, help can only be a solution.
- 5Ask: artefacts attached, gap named, lowest rung first
because Help aimed at a named gap closes it; help aimed at "checkout" replaces the attempt.
- 6Compare the reference with the attempt and write the differences
because The differences are where the model was wrong; this step is where the learning is stored.
The pseudocode that found the gap
This is the third artefact for the checkout, as written before any code. It is wrong in two places — no idempotency, order created after the charge — and both wrongnesses are visible on the page, which is what made the attempt able to fail somewhere specific instead of everywhere at once.
1checkout(cart, customer):2 for item in cart:3 if stock(item.product) < item.quantity: return error("sold out", item)4 total = sum(item.captured_price * item.quantity)5 result = provider.charge(total, customer.payment_method)6 if result.ok:7 order = create_order(cart, total, status = "paid")8 send_confirmation(order)9 return order10 else:11 return error("payment failed", result.reason)What to notice: nothing identifies this attempt, so a retry charges again; and the order does not exist when the provider is called, so a confirmation that arrives later has nothing to attach to. The attempt surfaced the first in test mode; the comparison with the reference surfaced the second.
What the attempt turned into questions
The attempt's value is the unknowns it produces. Before it, "payments" was a word; after it, three specific things are unknown and each has an experiment, and the tool can be asked about any of them at the first rung. The board is what was handed to the tool, and it is why the tool could answer with a hint.
- ✓Validation against stock and total from captured prices work as written.
- ✓A slow provider plus a second click charges twice; the pseudocode has no notion of an attempt.
- ✓The provider sends a confirmation after the charge, asynchronously — observed in test mode.
? Double charging.
becomes What identifies one checkout attempt so that a retry of the same attempt does not produce a second charge, and who generates it?
experiment Add a key per attempt; send the same request twice in test mode; observe one charge.
? Who says it is paid?
becomes Should the order be marked paid on the synchronous response or on the asynchronous confirmation, and what state is it in between?
experiment Create the order as pending before the charge; log both the response and the confirmation; see which arrives first and what each contains.
? Sold out during payment.
becomes If stock reaches zero between validation and the charge, what should happen, and where is that enforced?
experiment Two checkouts of the last unit in test mode; observe whether one is charged for something it cannot get.
None of these could have been asked from a blank file, and all three would have been silently answered by a draft. The attempt is what made them askable.
How to do it
Most important first.
- Set a time box for each artefact — enough to produce something, not enough to polish. The understanding paragraph and the decomposition should take less time than you want to spend on them.
- Write the pseudocode with the four things §43 names: inputs, outputs, state that changes, branches including failures. A checkout pseudocode without a failure branch is a happy-path sketch (Inputs, Outputs, State, Branches).
- Attempt the code from the pseudocode, not from memory of tutorials. When you are stuck on syntax, look it up — that is documentation, not delegation. When you are stuck on logic, that is the point at which to ask.
- When asking, attach the artefacts and name the gap. A request that says where you are stuck is answerable with a hint; one that does not is answerable only with a solution.
- After the reference, write three lines: where it agreed with my attempt, where it differed, and what I now believe that I did not (The Engineering Notebook).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The checkout, four artefacts. Understanding: "a customer with a cart pays and gets an order and a confirmation; the store must never charge twice or sell what it does not have". Decomposition: validate cart against stock; compute total from captured prices; create order; take payment; record payment result; confirm. Pseudocode: validate → total → charge → if ok create order paid else show error. Attempt: written from the pseudocode, runs in test mode.
- The gap, found by the attempt. In test mode a slow provider response and a second click produced two charges. The pseudocode had no idempotency, and the attempt made that visible in a way the draft never would have — the draft would have had an idempotency key you did not know you needed. Help requested at this point: "my attempt charges twice on a retry; what concept am I missing?" Hint: an idempotency key per checkout attempt. Revision made by you.
- The comparison with the reference. The reference creates the order as pending before the charge; the attempt created it after. That difference is a real disagreement about who is authoritative for "paid", and working through it — the order must exist so the provider's confirmation has something to update — is a lesson that would have been invisible inside a draft that had it right from the start.
- The URL shortener, as a contrast in scale. Understanding: "a long URL becomes a short code; the code redirects; clicks are counted". Decomposition: generate a code; store the mapping; redirect; count. Pseudocode and attempt in well under an hour. Help needed: none, until the question of code collisions, which the attempt surfaced when two URLs got the same code in a test. The tool was asked one question, at the right point, about the right thing.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Four artefacts exist for the problem, in your words, dated before any tool output.
- The help you asked for was about a gap your attempt found, and it came back as a hint rather than a solution.
- The reference and your attempt differ in places you can list, and each difference has become a sentence you now believe.
- The next problem of the same kind needs fewer rungs of help than this one did.
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.
- ?Can I state the problem in my own words, and split it into pieces I could test, before anyone helps me?
- ?What does my pseudocode do on the failure branches — and does it have any?
- ?Where exactly does my attempt fail, and what concept would a hint at that point need to name?
- ?Where does the reference differ from my attempt, and what did I believe that made me write it my way?
What can go wrong
- The artefacts become a ceremony. An hour on the understanding paragraph, a decomposition with fourteen leaves, pseudocode as detailed as code. The artefacts exist to make the attempt possible; when the attempt is possible, make it.
- The attempt is abandoned at the first difficulty and the tool asked for everything from that point. The move says to ask at the difficulty, with the artefacts, for a hint; not to hand over the rest.
- Applied to problems already understood. A developer who has built five checkouts does not need four artefacts for the sixth; the move is for the gap, and pretending to have a gap is its own delegation of judgment.
- The reference replaces the attempt in the codebase without the comparison. The store gets the better code; you get nothing, because the difference — the only place learning lives — was never examined.
- The attempt is slower and worse than the draft, and on a problem you will only ever solve once, the learning may not pay back the time.
- Attempting first can entrench a wrong model if the comparison with the reference is skipped; the move has a second half and the second half is the part people drop.
- Time-boxed artefacts on a hard problem may be too thin to attempt from, and the honest response is a hint at the first rung — which looks like breaking the rule and is not.
- "No AI on the first attempt means no documentation either." Documentation, search and a colleague's explanation of a concept are inputs to the attempt. The rule is about the solution, which is the output.
- "If my attempt is bad, I wasted the time." A bad attempt that found a gap — two charges on a retry — did the one thing it was for. Quality of the attempt is not the measure; what it surfaced is.
- "First attempt means the attempt must be finished." It must exist far enough to fail somewhere specific. An attempt that reaches the charge and stops with a question is an attempt.
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.
- GENERALUnderstanding, decomposition, pseudocode, attempt, then help — the sequence applies to any problem you have not solved before, in code or out of it; what shrinks on a familiar problem is the time each artefact takes, not the order.
- CONTESTEDA serious opposing view holds that the first attempt is the wrong place to spend a learner's time: that novices lack the schema to make a productive attempt, that studying worked examples before attempting is better supported by the evidence on how skills are acquired, and that the attempt-first rule produces frustration and entrenched misconceptions rather than learning. Their strongest form: read several good checkouts, then attempt, then compare — the attempt still happens, but not first. That view is strongest for a beginner with no neighbouring knowledge at all and weakest for anyone who has built something adjacent.
- ILLUSTRATIVEThe double charge in test mode, the code collision in the shortener and the week of resisted changes are invented to show what an attempt surfaces; no real project is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's Build Without AI page at /manifesto/without-ai is the principle behind this order; the lab at /thinking/without-ai runs it — understanding, decomposition, pseudocode, attempt, then the ladder.
- — /manifesto/review argues that reviewing an answer requires an attempt to review it against; that is the sixth step above.