AI Assistant Usage Policy

Ten rules, each with the failure it prevents and the mechanism that enforces it.

The premise: an AI assistant can produce a working HNSW index in ninety seconds. If you accept it, you have a working index and you have learned nothing, and the 34 months become a very expensive way to acquire code you could have downloaded. The rules exist to keep the assistant on the side of the work that is not the point, and away from the work that is.

The single sentence version: AI may accelerate everything except the step where you would have had to think.

Table of Contents

• The Commitment
• Rule 1 — Design Before Asking
• Rule 2 — Predict Before You Run
• Rule 3 — Debug Before Asking
• Rule 4 — Adversarial Use Is Encouraged
• Rule 5 — Understand Before Accepting
• Rule 6 — Manual Central Mechanism
• Rule 7 — Libraries For Periphery, Not For The Mechanism
• Rule 8 — Never Accept An Unexecuted Number
• Rule 9 — Record Material Influence
• Rule 10 — Periodic Unassisted Rebuilds
• What AI Is Genuinely Good For Here
• The Self-Audit
• References

The Commitment

Copy this into notebook/000-ai-commitment.md, date it, and commit it before week 1.

I am doing this to develop capabilities, not to produce artifacts. Where the two conflict, capability wins. I will not accept generated code I cannot explain, I will not report a number I have not executed, and I will hand-write the central mechanism of every project. When I break one of these rules I will record it rather than hide it, because a policy I cannot audit is a policy I do not have.

The last clause is the one that matters. You will break these rules — at 11pm, on a Tuesday, when a segfault has beaten you for two sessions. The policy is not damaged by that. It is damaged by not writing it down.

Rule 1 — Design Before Asking

I write the initial design before requesting an AI-generated design.

Prevents: the loss of step 3 of the loop — the reconstruction skill that is the entire point of the journey. Once you have seen a good design you cannot un-see it.

Mechanism: notebook section 4 is written and committed before any design conversation. The commit timestamp is the enforcement.

What is allowed after your design exists: asking for a critique of yours; asking what the canonical approach does differently; asking what you have not considered. All of these are more valuable after your design, and they are the highest-return use of an assistant in this whole program.

Rule 2 — Predict Before You Run

I predict experiment outcomes before running experiments.

Prevents: hindsight bias, and the erosion of calibration. You cannot get better at predicting system behaviour if you never record a prediction that could be wrong.

Mechanism: notebook section 5, committed before the run. Applies to AI-suggested experiments too — if the assistant proposes an experiment, you predict its outcome before running it.

Corollary: never ask an assistant "what will this experiment show?" before you have written your own answer. Ask afterwards, and compare — that comparison is free calibration data.

Rule 3 — Debug Before Asking

I attempt debugging before requesting the complete fix.

Prevents: the loss of debugging skill, which is the single most transferable thing in this entire journey and the one that degrades fastest when outsourced.

Mechanism: a 45-minute rule. Before asking for a fix you must have spent 45 focused minutes and be able to state:

1. What you expected to happen
2. What happened instead
3. The smallest input that reproduces it
4. Two hypotheses you have ruled out, and how

If you can write those four things, you have done the work that debugging teaches, and asking is now a time optimisation rather than a substitution.

Note that step 3 usually solves it. Minimising a reproduction is most of debugging, and it is the part an assistant cannot do for you because it requires access to your system.

Exempt: environment and toolchain problems. Fighting a linker script teaches nothing about operating systems. Ask immediately — and in P12 the whole week-3 decision rule exists because toolchain time is pure waste.

Rule 4 — Adversarial Use Is Encouraged

I may ask AI to critique assumptions and generate adversarial tests.

This is not a restriction — it is the use that has the highest value and the lowest risk, and it is under-used.

Prompts worth having ready:

• "Here is my design and my reasoning. What assumption is doing the most work, and under what conditions is it false?"
• "What input would break this? Give me the ten nastiest cases including degenerate and adversarial ones."
• "Here is my experimental setup. What confounds it? What am I failing to measure?"
• "Here is my conclusion and the data. Argue that the conclusion does not follow."
• "What is the strongest version of the argument against this design choice?"

The fourth is the most valuable in this program. Systems people are good at building and bad at attacking their own results, and an assistant will produce a more honest attack than you will.

Note the asymmetry. Asking for a solution substitutes for your thinking. Asking for an attack forces more of it. Use the second freely.

Rule 5 — Understand Before Accepting

I must understand and explain generated code before accepting it.

Prevents: a codebase you cannot debug, extend, or defend — which is fatal in a program whose deliverable is your own understanding.

Mechanism — the explanation test. Before committing generated code, write in the commit message (or a comment) what it does and why it is correct. Not what it is called — why it works. If you cannot, do not commit it.

Stronger form, for anything non-trivial: delete it and retype it from your understanding. You will change things, and the changes are where the learning is.

Red flags that you have violated this rule without noticing:

• You do not know why a particular line is there
• You would not be able to modify it for a slightly different requirement
• You cannot predict what it does on an edge case
• A test fails and your first instinct is to ask rather than to read

Rule 6 — Manual Central Mechanism

I must manually implement the central mechanism of every project.

This is the most important rule and the least negotiable. Each project page names its mechanism; the list:

"Manually" means: you typed it, from your understanding, and you can rederive it. It does not mean you never looked anything up.

What is allowed alongside: an assistant may help with the code around the mechanism — CLI parsing, plotting, test scaffolding, build configuration, data loaders. That code is not what you came for.

The test: could you rewrite the mechanism from scratch in a week, without assistance? If not, rule 10 applies.

Rule 7 — Libraries For Periphery, Not For The Mechanism

I can use libraries for peripheral concerns, but not to hide the mechanism being studied.

The line is drawn per project on its page. The principle:

Comparison is always allowed. Using hnswlib as an external baseline in P02's E12 is required. Using it inside your index is forbidden. The distinction is whether it is the thing you are measuring or the thing you are measuring against.

When in doubt, ask: does importing this remove a decision I would otherwise have to make? If yes, it is the mechanism.

Rule 8 — Never Accept An Unexecuted Number

AI-generated benchmark results are never accepted without execution.

Assistants produce plausible numbers. Plausible numbers are worse than no numbers, because they are not obviously wrong and they propagate into your report.

Mechanism: every number in every report traces to a script in the repository and a raw data file. No exceptions, including for numbers that "everyone knows".

This applies to the numbers in this track too. Every measured figure in these pages was produced by running the named script — and reproducing them on your machine in week 1 is milestone 1 of Project 1. Several will differ from what you expect.

Extend the rule to any factual claim about system behaviour. "A context switch costs about a microsecond" is a claim that varies by two orders of magnitude across machines and definitions. P12 measures it at ~1,676 ns on one specific laptop under one specific definition, and even that number comes with the caveat that a ping-pong benchmark misses the cache-pollution cost entirely.

Rule 9 — Record Material Influence

I must record when and how AI materially influenced a design.

Prevents: a portfolio you cannot honestly describe, and — more importantly — losing track of which parts of your understanding are real.

Mechanism: an AI-LOG.md in every project repository.

## AI-LOG

| Date | Where | What | My design before | Why I accepted it |
|---|---|---|---|---|
| 2026-08-14 | Beam search stopping condition | Suggested checking the worst held result rather than a fixed hop count | I had a fixed hop limit | Mine terminated early on clustered data; theirs is the standard and I verified why |
| 2026-08-22 | Test suite | Generated 12 edge cases for the tokenizer | I had 4 | Pure additive coverage, no design content |

Material means it changed a design decision, an algorithm, or a conclusion. Routine completion, syntax lookup, and boilerplate do not need logging — logging everything means logging nothing.

Why this matters beyond honesty: when you re-read a project two years later and cannot remember why a design choice was made, the log tells you whether it was yours. That is the difference between a design you can defend in a review and one you can only describe.

Rule 10 — Periodic Unassisted Rebuilds

I should periodically rebuild important components without AI assistance.

Prevents: the slow substitution of recognition for recall. You can read code and think "yes, that's right" long after you have lost the ability to write it — and recognition feels exactly like understanding from the inside.

Mechanism — the rebuild drill. At each stage review, pick one component from the stage and rebuild it from scratch in one session (3 hours), with no assistant, no notes, and no reference to the original. Then diff.

Suggested targets, one per stage:

Scoring the drill: if you produce something working in 3 hours, you own it. If you produce something that does not work but whose bugs you can find, you mostly own it. If you cannot start, you never owned it — and you should schedule a proper re-read, because a component you cannot rebuild is a component you cannot defend.

The drill takes 15 hours across the whole journey. It is the cheapest insurance in the program.

What AI Is Genuinely Good For Here

Stated positively, because a policy that is only prohibitions gets ignored.

Notice that most of these are after your own attempt, or outside the mechanism. That is the whole shape of the policy.

The Self-Audit

At each stage review, answer these five in writing. They take ten minutes and they are the only thing that keeps the policy real.

1. Which mechanism in this stage could I not rebuild from scratch? Name it. That is your rebuild drill target.
2. Where did I ask before doing the 45 minutes? Count the times. A rising count is the signal.
3. Is there code in my repositories I cannot explain? Find it. Read it or delete it.
4. Did any number reach a report without being executed? Check one at random and re-run it.
5. Has my AI-LOG.md gone quiet? Either you stopped using assistance, or you stopped logging. It is almost always the second.

Question 5 is the canary. A log that stops mid-project has never once meant the assistant stopped being used.

References

• Bjork, R. A., Bjork, E. L. Desirable Difficulties in Theory and Practice. Journal of Applied Research in Memory and Cognition 9(4), 2020. Why difficulty during acquisition improves retention and transfer — the theoretical basis for rules 1, 3, and 10.
• Roediger, H. L., Karpicke, J. D. Test-Enhanced Learning. Psychological Science 17(3), 2006. Retrieval practice beats re-study; the rebuild drill is retrieval practice.
• Karpicke, J. D., Blunt, J. R. Retrieval Practice Produces More Learning than Elaborative Studying with Concept Mapping. Science 331(6018), 2011.
• Koriat, A., Bjork, R. A. Illusions of Competence in Monitoring One's Knowledge. Journal of Experimental Psychology 31(2), 2005. Why recognition feels like recall — the empirical basis for rule 10.
• Feynman, R. P. Cargo Cult Science. Caltech, 1974. Rule 8, in essay form.
• Bainbridge, L. Ironies of Automation. Automatica 19(6), 1983. The classic result that automating the easy parts of a task degrades the operator's ability to handle the hard parts — written about process control, exactly applicable here.