Chapter 1 — Reps

Ten reps to make Week 1 muscle, not memory. They move from inventorying your own work, to catching AI hallucinations by tool and by eye, to writing the governance that keeps a copilot honest. The keyboard is the gym. Do not read these — run them.

Ground rules

• Type it yourself. No copy-paste from the chapter or from a copilot. Your fingers learn what your eyes skim.
• Run everything. Every command, every script. A rep you did not execute is a rep you did not do.
• Predict before you measure. Before you run a linter, a script, or a model, write down what you expect to happen. Then compare. The gap between prediction and result is the learning.
• AI policy (Phase 1): You may use an AI copilot, but you must do or check the work yourself first. Every rep that uses AI ends with an honest one-line AI usage note: what you asked, what it got wrong, what you verified. The human owns the verdict.
• Keep a reps.txt. One short written reflection per rep. This is graded thinking, not busywork.

Reps 1–3: Map the work and the autonomy

Rep 1 — Inventory your own toolchain

List five tasks you (or an admin you know) do regularly — e.g. “restart a stuck service,” “rotate a log,” “add a user,” “review firewall rules,” “summarize an incident.” For each, write one sentence: could an AI do the first draft, and what is the failure mode if it is wrong?

Reflection: Which of your five is the most tempting to automate and the most dangerous to get wrong? Those are usually the same task. Say why.

Rep 2 — Place each task on the autonomy ladder

Take your five tasks from Rep 1 and assign each a rung from the ladder in §1.5 (0 observe / 1 suggest / 2 act-with-approval / 3 autonomous). Justify each placement in a sentence.

| Task                | Rung | Why this rung (one line)                       |
|---------------------|------|------------------------------------------------|
| restart stuck svc   | 2    | reversible, audited, but needs a named approver|
| ...                 |      |                                                |

Reflection: Did any task land at rung 3? If so, defend it: what makes it reversible and bounded enough? If none did, say what would have to be true for one to.

Rep 3 — Pick the right model for three jobs

Using the tier table in §1.3, choose a Claude tier (Haiku 4.5 / Sonnet 4.6 / Opus 4.8 / Fable 5) for: (a) summarizing 50,000 log lines an hour, (b) drafting one runbook, (c) an agent reasoning across six tools to plan a migration. Note your reasoning and the output-token cost implication.

Reflection: Output tokens cost several times input. Which of the three jobs is output-heavy, and how would that change your tier or your prompt? (Flag any price as a “mid-2026 snapshot.”)

Reps 4–6: Catch the hallucination

Rep 4 — Run the linter against the AI draft

Run the shipped linter against the shipped AI runbook. Predict the number of flags first.

python3 code/verify_runbook.py code/ai-drafted-runbook.txt

Reflection: How many did you predict vs how many fired? Name one dangerous line in ai-drafted-runbook.txt that the linter did not catch (hint: a wrong identifier), and explain why a regex linter structurally cannot catch it.

Rep 5 — Diff the AI draft against the verified script

Open code/ai-drafted-runbook.txt and code/restart-web-service.sh side by side. List every place the verified script does something the AI draft got wrong or skipped — especially confirm the unit exists, capture state before changing, and verify health (not just “started”).

Reflection: The verified script’s pattern is confirm → capture → change → verify. For each of those four, quote the line in the script that implements it.

Rep 6 — Break the linter on purpose, then fix it

Add one new hallucinated line to a copy of the AI runbook that the current linter would miss (e.g., systemctl enable --now nonexistent.target). Then add a rule to code/verify_runbook.py that catches it, and re-run.

# add to the DANGER list in verify_runbook.py
(r"enable\s+--now\s+\S+\.target",
 "Enabling a .target as a service — verify the unit type with `systemctl cat` first."),

Reflection: You just made the machine catch one more mechanical trap. Name one class of hallucination that no regex rule could ever catch, and explain why that residue is exactly where the human stays in the loop.

Reps 7–9: Build the verified runbook and its governance

Rep 7 — Harden and test the verified script

Copy code/restart-web-service.sh. Point SERVICE and HEALTH_URL at a real (non-production) service on your lab box — even a local nginx or a dummy systemd unit. Now make it fail correctly: temporarily make the health endpoint return a 500 and confirm the script exits non-zero and escalates rather than reporting success.

# In one terminal, serve a deliberately-broken health endpoint:
python3 -m http.server 8080   # /healthz will 404 -> health check fails as intended
# then run your hardened copy and confirm exit code 2
./restart-web-service.sh; echo "exit=$?"

Reflection: Why is “the service started” not the same as “the service is healthy”? Give a concrete failure where a service starts and the health check still (correctly) fails.

Rep 8 — Draft, then dismantle, your own AI runbook

Pick a procedure you actually run. Ask a copilot to write the runbook. Then dismantle it: go line by line and mark each line verified, wrong, or unsafe, with a one-line reason. Keep both the raw AI draft and your annotated version.

Reflection: What fraction of lines did you change? Was the AI more dangerous on identifiers (paths, unit names, flags) or on judgment (order, when-to-escalate)? Tie your answer back to §1.6. End with your AI usage note.

Rep 9 — Write your team’s AI usage policy

Adapt code/copilot_policy.yaml into a policy for a small real or imagined team. Change at least three task→rung mappings to fit your context, and fill in the required_in_every_change block so it names an accountable human, not a team alias.

Reflection: Defend one rung choice where you went more conservative than the starter (moved a task down a rung). What failure were you protecting against, and who would have answered for it?

Reps 10: Run the lab

Rep 10 — Score yourself on the Hallucination Spotter

Use the Hallucination Spotter widget embedded below the chapter. Score yourself cold (no linter, no notes) on the first pass and record your number. Then run code/verify_runbook.py, and on a second pass hunt only for what the linter could not catch.

Reflection: What was your cold score, and which lines did you miss? Were the ones you missed mechanical (a value, a directive) or semantic (a wrong name, a wrong order)? What does that tell you about where to spend your verification effort for the rest of the course?

Done? One Last Thing.

A miniature of Project 1, end to end. Pick one real procedure. Produce three files in a folder:

1. runbook-verified.txt — the procedure, written and verified by hand, in the confirm → capture → change → verify shape.
2. runbook-ai.txt — a copilot’s draft of the same procedure, unedited, with a header noting the tool and model (e.g. “Claude Sonnet 4.6 (claude-sonnet-4-6), mid-2026”).
3. verdict.txt — a one-page table: every line where the two differ, marked verified/wrong/unsafe, with the human’s final call and your name as the accountable steward.

If you can do this for one procedure tonight, you can do Project 1. That is the whole job in miniature: the AI drafts, you verify, you sign.

Up next: Project 1 — Project 1: From Runbook to Copilot.