The AI Training Guide

Every morning at 2:00, a script wakes up

It files yesterday's quiz answers and updates a review schedule. It asks Claude to write today's lecture — two to three thousand words on one topic — plus ten new questions. It picks today's review questions from a bank of everything taught so far, using spaced repetition. Then it emails the lecture with a self-contained quiz page attached.

You wake up and answer Part 1 before reading. You will get most of it wrong; that is the point. You read the lecture. You answer Part 2 — review drawn from earlier editions. You tap one button to send your results back. Tomorrow morning the script files them and schedules the ones you missed to come back sooner.

Once a week there is a spoken teach-back: explain a concept out loud, no notes, and get graded honestly.

It is not a chatbot conversation. That distinction is the whole document.

Why it's built this way

Every design choice traces to a finding in the learning-science literature. The short version:

And the honest scope line, kept in the design doc verbatim so nobody oversells it: sixty to a hundred and twenty hours buys conversational expertise and interview-credible articulacy, not researcher depth.

The one rule that makes it work

This is the load-bearing idea. Everything else is implementation.

A language model is excellent at writing a lecture on quantization. It is terrible at remembering that you got question 7 wrong eleven days ago and it is due again on Thursday. If you make the model hold the schedule — in its context, in a chat history, in a "memory" — it will drift, and you will not notice until week five, when the whole thing has quietly become a content feed with no idea what you actually know.

So: deterministic state lives in flat files that a plain script owns. The model is called for exactly one thing — write today's content — and its output is merged into the bank by code. The scheduler is a pure function of items plus history. It can be unit-tested. It cannot hallucinate.

If you build one thing from this document, build that boundary.

Five files do all the work

None of them are large.

Plus one cron entry to fire the runner daily.

The cycle, start to finish

1. 02:00
   Cron fires the runnerTakes a lock file. Never two runs at once.
2. +0s
   Drain the inbox into historyYesterday's answers get filed. If today is already sent, exit here.
3. +1m
   Call Claude — the only model callResearch, write, generate ten questions, verify them. Produces the lecture and the new items. Nothing else.
4. +12m
   Merge new items into the bankGiven ids like e12-3. Append-only.
5. +12m
   Compute what's dueA pure function over history. No model involved. Build today's quiz and a manifest mapping question number to item id.
6. +13m
   SendLecture email, quiz page attached. Write a sent-marker. Log the cost. Bump the edition counter.
7. morning
   You answer Part 1 blind, read, answer Part 2One tap sends a single line of results back.
8. next 02:00
   That line gets filedMisses return tomorrow. Correct answers move further out.

The human loop is one tap. Section 10 is about what happened to those taps.

The formats are deliberately boring

Every one of them can be read, fixed, or reconstructed by hand at eleven at night without a debugger.

QUIZ-2026-07-19: 1✓ 2✓ 3✗ 4✓ 5✓ 6✓ 7✗ 8✓ ... 16✓

The prefix is arbitrary — pick anything greppable and then never change it, because the parser and every line you have already sent depend on it. Numbering is global across both parts: questions 1 to 4 might be new material, 5 to 16 review. A separate manifest maps {"7": "e3-4"} so the runner knows question 7 was item e3-4. The parser accepts several tick and cross glyphs, because you will be tapping this on a phone.

{"id":"e1-1","edition":1,"topic":"The transformer, end to end",
 "q":"...","a":"...","kind":"explain","pretest":true,
 "created":"2026-07-14"}

e1-1	2026-07-14	1
e3-4	2026-07-19	0

Item, date, and 1 for correct. The entire schedule is derived from that file. Append-only means a bad run cannot corrupt it — worst case you get a duplicate row.

The quiz page is a single self-contained HTML file built from a fixed string template. Not written by the model. It works offline from an email attachment, reveals answers with native <details>, and generates the result line for you.

Seven prompts

These are written for Claude Code — the agent that reads and writes files — because the thing you are building is a set of files, not a conversation. Each prompt is one work session. Substitute your own subject wherever it says [your subject].

Building it with IBM Bob instead

The design has exactly one model-shaped hole in it. Everything else — scheduler, bank, history, sender, quiz page — is plain Python that has never heard of a vendor. That is what makes the port small.

Bob is IBM's coding agent, generally available since 28 April 2026, replacing Watsonx Code Assistant. It has three modes — Ask for questions, Plan for strategy, Agent for read, write, and execute — an IDE integration and a CLI called Bob Shell, MCP support, subagents, and a Skills system for reusable instruction sets. Rather than exposing one model, it routes each task across Claude, Mistral, Granite, and fine-tuned models by accuracy, performance, and cost.

The one command that matters

bob run --format json --max-cost 30 --max-turns 40 \
    "$(cat prompts/edition.md)" > out/edition.json

bob run is the non-interactive session. Piping works (echo "…" | bob run), @path references pull files into context, and output redirects normally. Critically, in non-interactive mode all tools are pre-approved — it will not sit at 2 AM waiting for someone to confirm a file write.

Where Bob is genuinely better for this

Where it will fight you

Four changes that make it portable

Each of these improves the project regardless of which agent you use — which is the tell that they are the right changes.

1. Extract a provider adapter. One module, one function: generate_edition(edition, topic, sources) returns a lecture and a list of items. One environment variable picks the backend. Nothing else in the codebase ever learns which agent you use.
2. Sequence, do not fan out. Replace the four-agent workflow with four ordinary calls the runner makes in order — research, write, generate, verify. Portable to any CLI, cheaper, and far easier to debug when edition 23 comes out wrong.
3. Demand JSON; never scrape prose. Make the adapter's contract "returns a validated object" and every backend has to meet it. Bob hands you --format json for free; others need a schema in the prompt.
4. Put the budget ceiling in the adapter. Bob enforces cost and turns natively; for backends that do not, enforce it in the runner. What you are willing to spend should not be a property of which vendor you picked.

Practical setup notes

API-key authentication for CI/CD arrived in 1.0.3 — use that for the scheduled job. The OAuth tokens in ~/.bob/settings/auth-secrets.json are for humans at keyboards and will strand an unattended run. Standing instructions go in AGENTS.md, loaded hierarchically from your home directory, the project root, and subdirectories; if you already keep a CLAUDE.md, that is where its contents move. Settings live in ~/.bob/settings/settings.json, where session.maxTurns defaults to 50 and session.subagents to true — set both deliberately before the first overnight run. Telemetry is on by default and collects usage patterns rather than prompt or file content; turn it off there if your team requires it.

Codex, and everything after it. The same adapter absorbs them. If swapping backends means touching more than one file, the boundary is in the wrong place — which is section 03 arriving from a different direction.

Sources IBM Bob product site and Bob Shell documentation, including the non-interactive session reference, configuration reference, and changelog (bob.ibm.com/docs/shell); IBM newsroom, 9 July 2026, on multi-agent capabilities and the premium modernization packages; TechTarget and DevOps.com coverage of the 28 April 2026 general-availability release. Verified 13 August 2026 — check the changelog before relying on any flag here.

These all cost real time

They are yours for free.

Gmail strips JavaScript from attachments.

The first quiz page revealed answers with a JS click handler. It worked perfectly on the desktop and was completely inert on the phone — which is the only place it was ever used. Native details/summary survives. Test on the surface you will actually use, not the one that is convenient.

Copy that promises what the state cannot deliver.

Editions 1 and 2 both said "now go do Part 2." There was no Part 2 — under the original rules the first review items did not come due until edition 3. The scheduler was working exactly as written; the copy was lying. Nothing was broken and it felt broken, which is worse. Make user-facing text conditional on actual state.

Pretest guesses counted as recall.

Four lucky day-one guesses pushed those items straight to a three-day gap, skipping their first real review entirely. Guessing before instruction is priming; it is not retrieval practice of studied material, and the gap intervals are calibrated on the latter. Record pretest marks, schedule on nothing but real reviews.

A review cap that is too low breaks the thing you promised.

With ten new items a day and a cap of eight, the queue saturates. Then "oldest debt first" means a freshly missed item — the one you most need to see tomorrow — sorts behind a month of old backlog. The expanding-gap schedule silently degrades into FIFO. Raise the cap above inflow, and log the queue depth so saturation is visible.

Unverified generated questions are wrong about a fifth of the time.

Adversarial verification stage. Not optional.

Two agent fleets in one rate window is a cost multiplier.

If you run more than one of these, stagger them by an hour. And never run the content fleet inside an interactive session "just to test it" — that is how a ten-minute experiment becomes a genuinely startling invoice.

The bill, and the one thing that broke

Those last two figures are the whole lesson. The quizzes were answered daily. Only three sets of answers ever reached the history file.

The ingestion step was the weak point, and it was weak for a specific reason: it asked a model to perform a deterministic write. The result line arrived in a chat thread, and the agent reading that thread was instructed to append it to a file. When it acknowledged the message without doing the append, the answers were simply gone — no error, nothing to notice at the time. A prefix mismatch between the documented format and what the parser actually accepted quietly ate more of them the same way.

The fix is small and worth building on day one. Have the delivery surface write the result line to a file directly, or give the runner a parser it owns end to end — and make an unparseable line loud rather than a warning nobody reads. A scheduler that never sees your answers is an expensive newsletter, and it will not tell you that is what it has become.

If you only take three things

1. The runner owns the schedule and the writes; the model only makes content. Deterministic state in flat files, one pure function you can unit-test, and no step that matters left to something that might merely say it did the thing.
2. Retrieval, not reading. Guess before, recall after, short answers only, expanding gaps, out loud once a week.
3. Build the pause switch, the health check, and the honest copy on day one. They are cheap now and expensive at week five.