Learning Without AI
In this mode the AI does not write solution code. It may ask questions, explain a concept, review your reasoning, give a hint, or point at the documentation — everything except the part that would replace your attempt. The rule is about what is delegated, not about the tool.
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 want to learn to build things, and you have a tool that will build them for you. How do you use it so that you end up able to build the next one — and how would you know whether you can?
You have shipped three features this month with the assistant writing most of the code, and each worked. Yesterday a colleague asked why the cart uses a session id rather than a user id, and you realised you did not know — the assistant had chosen it, you had accepted it, and the store had run. You could not have written the cart yourself, and you are not sure you could explain it.
Ask for the full thing and read it carefully. Reading the generated code is learning; you will absorb the patterns by seeing them, and it is faster than fumbling through a first attempt that will be worse anyway. Understanding comes from exposure.
Reading a solution produces recognition, not the ability to produce one. You can follow the cart code and agree with it; asked to write the checkout from a blank file, nothing comes, because nothing was ever retrieved from your own head — only checked against someone else's.
- Reading a solution produces recognition, not the ability to produce one. You can follow the cart code and agree with it; asked to write the checkout from a blank file, nothing comes, because nothing was ever retrieved from your own head — only checked against someone else's.
- The decisions inside the code were made by the tool and inherited by you. Session id versus user id was a design decision with consequences for guest checkout; you have the consequence and not the reason, so when the requirement changes you have nothing to revise from.
- Three working features look like three units of learning and are zero. The store progressed; you did not. That gap is invisible in every measurement of the project and appears only when the tool is absent, wrong, or asked a question outside its training.
- You cannot review what you cannot produce. The tool's output is checked by the tool's reputation, and the day it is subtly wrong — a checkout that creates the order before the payment is confirmed — nothing in you is positioned to notice.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Separate what the tool may do from what it may not, by what would be delegated. It may ask you questions you have not asked yourself; explain a concept you have named; review reasoning you have written; give a hint when you have made an attempt; point at the documentation you should read. It may not produce the solution code before your attempt exists, because that is the one act that replaces understanding instead of accelerating it (Understanding Is Not Delegable).
- Put your attempt first, every time, however bad. The value of the tool as a reviewer is proportional to how much of your own reasoning there is to review; with no attempt there is nothing to correct, only something to copy (No AI on the First Attempt).
- Ask for help in rungs, not in one step. A conceptual direction first; then the relevant abstraction; then pseudocode; then a partial implementation; then, last, the reference. Each rung leaves you more of the work than the one after, and stopping at the earliest rung that unblocks you is how the attempt stays yours (The Hint Ladder).
- Make "understanding" testable rather than felt. Can you explain it back without the code in front of you, rebuild the core from memory, and say where you hesitate? Those are checks, and the lessons that follow are each one of them (Explain It Back, Build From Memory, The Feynman Check).
What the tool does in this mode, and what it does not
The line is drawn by delegation, not by tool. The comparison is the same problem — build the cart — with the tool used two ways. In the worse column the store gains a cart and you gain a file; in the better column the store gains a cart a little later and you gain the reasons in it.
Prompt: "write a shopping cart for my store". Output: a cart keyed by session, persisted in a table, with add, remove and merge-on-login. It works. You read it and agree with it. You could not write it tomorrow and do not know why it merges on login.
Your page first: who owns a cart, why not user id, persistence. Prompt: "review this; ask me what I have missed; do not write code". Output: a question about login-merge, a pointer to session docs, a note that add-twice needs a quantity. You revise the page, then write the cart. Slower; yours.
In the second column every decision passed through your reasoning before it entered the code, so each can be explained, revised and defended. In the first, the decisions entered the code directly and you inherited them, and inheritance is not understanding.
The same request, three ways
The request you make of the tool decides what you get back and what you keep. The ladder shows one need — being stuck on checkout — asked at three levels; the best form asks for the least, which is the counter-intuitive centre of the module.
why The best form makes answerable the one thing you cannot answer yourself — the missing concept — while leaving you the attempt, the revision and the code. The vague form answers a question you did not ask and takes the attempt with it; the better form invites a rewrite rather than a hint.
Where the mode leaves you
The mode produces a working feature and a set of things you now know, and it produces a third thing the reflex never does: a list of what you still do not know, sharpened. The board is the cart's, after the mode; the unknowns are questions you can now research or attempt, and the tool may help with any of them at the appropriate rung.
- ✓A cart belongs to a session so guests can shop; it is persisted so it survives a refresh.
- ✓Adding the same product twice increments a quantity rather than adding a row.
- ✓On login, carts merge, guest cart winning on conflict — a decision made on the page, with the reason written.
- ~A session lasts long enough for a normal shop; the expiry is the framework default and has not been chosen.
? Concurrency on the cart.
becomes If the same session sends two add requests at once, can the quantity end up wrong, and does the store care enough to prevent it?
experiment Two concurrent adds against one cart row; read the quantity; decide with the invariant in hand.
? Stale prices in the cart.
becomes When an admin changes a price after an item was added, which price does checkout use, and where is that rule enforced?
experiment Add an item, change the price in admin, check out; write what the total should be before running it.
? Session expiry.
becomes What happens to a cart whose session expired before checkout, and should it be recoverable?
experiment Set a short expiry, shop, wait, return; write what the customer should see.
Each unknown is now a question you can attempt before asking for a hint. The mode did not remove the tool from these; it put your attempt in front of it.
How to do it
Most important first.
- Before asking the tool anything about a problem, write your understanding of it, your decomposition and a first pseudocode. The tool's first job is to review that page, not to replace it.
- Tell the tool the mode explicitly: questions, concepts, review, hints and documentation pointers; no solution code until asked for the reference. Most tools honour a stated constraint, and the act of stating it is a commitment to yourself.
- When stuck, ask for the lowest rung: "which concept am I missing?" before "how do I do this?" before "write it".
- After any code exists — yours or, at the last rung, the reference — close it and explain the design back in plain language. If you cannot, the learning has not happened yet, whatever the store does.
- Keep a note of what you learned and where you needed which rung; a learner who always needs the fourth rung on the same kind of problem has found the concept to study (The Engineering Notebook).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The cart, in this mode. Your page: "a cart belongs to whoever is shopping; guests can shop; so it cannot be keyed by user id; key it by a session token stored in a cookie; persist it so it survives a refresh". The tool reviews: it asks what happens when a guest later logs in — do two carts merge? — and points at the session documentation. You had not thought of the merge; you now own both the decision and the question. No code was written by the tool.
- The checkout, one rung at a time. Attempt: create the order, then charge. Hint one, on request: "think about who is authoritative for whether the order is paid". Your revision: create the order as pending, charge, mark paid on the provider's confirmation. Hint two, on request: "what identifies an attempt so a retry does not charge twice?" You add an idempotency key. The reference, shown last, differs in detail and agrees in shape — and you can say where and why.
- The colleague's question, answered. Why session id? Because guests must shop, and a cart keyed by user id cannot exist before login. What about a guest who logs in? Carts merge, the guest cart winning on conflict — a decision made on your page after the tool's question. The answer is yours, and the next time the requirement moves, so is the revision.
- The mode applied to reading. "Explain what a webhook is" is allowed and useful; "write my webhook handler" before an attempt is not. The explanation gives you a concept to attempt with; the handler gives you a handler.
How you know it worked
What now exists that did not before, and what question you can now ask.
- For every feature, there is a page in your words — understanding, decomposition, pseudocode — that existed before any tool output.
- You can name which rung of help each hard part needed, and the number is going down on problems of a kind you have seen.
- Design decisions in the code are ones you can explain, including the ones the tool suggested, because you accepted them on a reason.
- You have caught the tool being wrong at least once, on the strength of your own attempt.
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 have I written down about this problem that the tool could review, rather than replace?
- ?Which is the lowest rung of help that would unblock me — a concept, an abstraction, pseudocode, or a partial implementation?
- ?For each decision in this code, can I give the reason — or only the fact that it was there?
- ?If the tool were wrong about this, what in my own understanding would let me notice?
What can go wrong
- The mode becomes abstinence. No tool, no documentation, no search, and a week lost rediscovering what a paragraph would have explained. The rule is about the solution code before your attempt; explanations, questions and pointers are the tool doing exactly what it should.
- The attempt is a token gesture — a blank file with a comment — so that the "rules" are satisfied before asking for everything. The attempt has to contain your reasoning or the review has nothing to work on.
- The rungs are climbed without stopping. Hint one is read, hint two is requested immediately, and the reference arrives within five minutes. The ladder only teaches if you attempt again between rungs.
- Understanding is judged by feeling. The code makes sense when read, so it must be understood; the checks — explain, rebuild, find the hesitation — are skipped because they are uncomfortable, which is the reason they work.
- The first attempt is slower than the generated answer, and worse. On a deadline the cost is real, and sometimes the right call is to take the reference and schedule the understanding for after — written down as a debt.
- Refusing the solution code means the store progresses at the speed of your learning, not the tool's output, and to anyone measuring the store that looks like a slowdown.
- The mode requires honesty with yourself about what counts as an attempt, and that is not free either.
- "Learning without AI means not using AI." It means not delegating the attempt. Questions, explanations, reviews, hints and pointers are the tool being used well; the manifesto's line is between accelerating understanding and replacing it.
- "Once I can build a cart, the mode is over." The mode is for whatever you cannot yet build. The next unfamiliar thing — realtime, a queue, a search index — puts you back at the first rung, and the mode with it.
- "Professionals do not work this way." Professionals who understand their systems work this way on the parts they do not yet understand, and use the tool freely on the parts they do. The mode is scoped to the gap, not to the career.
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.
- GENERALWhat is delegated, not which tool, is the question for any learner on any problem; the same line divides a tutorial you copy from one you attempt, and a colleague who tells you the answer from one who asks you a question.
- TEAM-SPECIFICA solo learner sets the mode for themselves and is the only one who can tell whether the attempt was honest. On a team under deadline the mode is applied to the parts the engineer must own — the checkout logic — and relaxed on the parts nobody needs to understand deeply; a senior reviewing a junior can hold the mode for them by asking rather than telling.
- CONTESTEDSome practitioners hold that this is nostalgia: that reading many good solutions is how every craft has always been learned, that the first attempt without help is a slower path to the same place, and that the ability to specify, review and verify generated code is the skill that now matters, not the ability to produce it from a blank file. Their strongest form: understanding is demonstrated by catching the tool's mistakes, and you learn to catch mistakes by seeing many correct examples, not by making your own. That view is strongest for engineers who already have deep understanding in a neighbouring area and weakest for a learner with nothing yet to compare the output against.
- ILLUSTRATIVEThe three shipped features, the colleague's question and the cart-merge decision are invented to show the shape of the mode; no real project or tool 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 states the principle; this lesson is its working practice, and the lab at /thinking/without-ai runs it on a project.
- — The manifesto's "review the LLM's answer" at /manifesto/review is the same mode from the other side: the attempt is what makes review possible.