Session 1. Configure the assistant and the repository instructions — Mon 14 Sep

Configure the assistant and the repository instructions

Monday, September 14, 2026 · 2h · Thread: harness engineering

Outcome

You leave with a coding assistant that reads this repository's policy before it edits, a scoped instruction set you wrote (AGENTS.md as the canonical file, CLAUDE.md and .cursor/rules/*.mdc pointing at it), the acceptance checks that decide when a change is done, and one record of the inspect → plan → edit → test → review loop with a change you refused. Day one also carries the orientation: the request → context → model → tool → verification mental model, and the capstone you build over three weeks.

Contract and threat boundary
Input A repository, an assistant that reads project files (Claude Code, Cursor, or another), and one small feature: an optional tags filter on search_documents, worked in a scratch copy.
Output Scoped project instructions with their acceptance checks written in, and a task-loop record: the plan you approved, the diff you inspected, one rejected change with its reason, and the remaining risks.
Budget One feature. One file, src/bootcamp_agent/tools.py. No new dependency. uv run bootcamp check ch01 and uv run ruff check . decide "done" — tests/ is not in your copy, so the check is your suite.
Failures this session must handle An ambiguous instruction. The assistant asks, or it guesses and you catch the guess. Either way the missing sentence lands in AGENTS.md. An unauthorized file change. You ask for an edit outside the allowed files. The assistant refuses, or it produces a diff and you reject it.

The threat is not a hostile model. It is a helpful one with no boundary: it invents an architecture, touches five files, adds a dependency, and writes a test that asserts the mock. The boundary is yours to write.

Session flow

  1. Warm-up and diagnostic (10m). Preflight cell green on every screen. One FakeLLM.complete call with nothing around it, then the same question through uv run bootcamp-agent --trace "..." to preview the capstone.
  2. Contract and threat boundary (15m). The mental model: request → context → model → tool → verification. Where the model is probabilistic, and what you control instead. The contract table above, read aloud.
  3. Concept and live implementation (30m). Weak prompt versus project-aware prompt on this repository, in one assistant. Then the policy files: what goes in, the canonical-file pattern, the builder-kit as the worked example. Then the full loop on the tags filter: plan, restrict, smallest diff, tests, reject one thing, risk summary.
  4. Guided lab (35m). In your own assistant, with the notebook as the logbook: the same feature, the same loop, your own rejection.
  5. Failure injection (15m). Give the assistant one ambiguous instruction and record what it did. Ask for a change outside the allowed files and record the refusal, or the diff you rejected.
  6. Evaluation and artifact receipt (10m). Fill the loop record, run check("ch01-e1", loop), then review("ch01"). Rejected changes read aloud. The best rejection wins.
  7. Exit ticket (5m). One thing that works, one thing that is unclear, your next action. Homework: fix the instruction that let the assistant assume wrong, and read docs/guides/harness-engineering.md.

Evidence

This session is assistant-driven. The notebook's first cell carries # manual-run:, so CI does not execute it and the CLI reports it as manual:

uv run bootcamp check ch01                    # prints the manual reason; run the notebook in Jupyter
uv run bootcamp submit ch01 --github <you>    # hands in the notebook as it stands, no re-run, no marks

The scorecard is the review("ch01") cell in Jupyter. It reads your loop record, not the assistant's summary of it.

Previous: Data structures for agents · Next: Call a model through the adapter

← Topic 12. Data structures for agentsDay one: the mental model, then two prompts →