The previous lesson taught recovery: how to spot drift, stop, summarize, and reset. This lesson teaches prevention. The goal is guardrails that stop the worst tangents before they start — without tightening the AI down so far that it cannot do useful work.

What a rail is

A rail is a useful constraint that tells the AI three things: what it may inspect and change, what it must preserve, and what proof it needs before claiming success. Rails are not distrust theater. They are the same thing a good work order gives a contractor: the job, the boundaries, the things to leave alone, and how you will check the result. Without rails, every task is an invitation to drift. With too many, nothing can move. The art is a small set of rails that answer the questions drift exploits.

The bounded-change request

The core rail is the bounded-change request. Write it before the AI touches code:

Notice what each field prevents. The goal defeats vague inference — there is one outcome, not four. The allowed area defeats file-list growth. The preserve list defeats "helpful" side repairs to authentication nobody asked for. The do-not list defeats the library-migration reflex from the previous lesson. The proof defeats confident claims without evidence: the work is not done when the code looks right, but when the dated and undated previews render and the export check still passes.

Keep the request short enough to fit at the top of the session. If it needs two pages, the task is too big — split it.

File boundaries: inspect wide, edit narrow

The second rail is file boundaries — enforced by reading the diff, the readable record of what changed between two versions of your files. Make reviewing that record a habit: before you accept any AI work, look at which files changed and what exactly moved inside them. Giving an AI permission to inspect the whole repository may be appropriate for orientation; the agent often needs broad reading to find the right pattern. Permission to edit should usually be narrower until there is a reason to widen it. Name the files or directories the agent may change, and name the ones it must not touch.

In practice this sounds like: "You may read anything in the repository to understand the citation pattern, but change only the citation component and its mapping function. Do not touch authentication, navigation, export, or the database schema." If the agent discovers it genuinely needs a wider edit, it must propose that first — which turns silent drift into a visible decision you approve.

Plan first, then implement

Treat "plan first, then implement" as a productive two-pass conversation. In pass one, the AI produces a plan only — no edits. A real plan lists proposed files, dependencies, data changes, user-visible behavior, risks, and verification steps. It does not just say "I will update the component." In pass two, after you approve the plan, implementation begins inside the approved boundaries.

Challenge the plan before approving it. Four questions catch most drift early:

• "What assumption would make this plan wrong?"
• "What existing pattern are you following?"
• "What are you deliberately not changing?"
• "Can this be done without a new dependency?"

That last question deserves emphasis. New dependencies are the most common drift payload: a date library for one format call, a state library for one field, a framework where a function would do. Force the agent to justify every addition against what the project already has.

Routing: the right model for the job

A third rail is model routing — deliberately assigning different models to different jobs based on capability, cost, speed, and observed quality. Not every task needs the strongest reasoning model. Copy drafting, repetitive test generation, and simple transformations may run well on a fast, cheap model; architecture decisions, security-sensitive code, and independent review may justify the slower, stronger one.

Keep a lightweight MODEL-NOTES.md record as you work:

## 2026-09-01 — Export summary copy
- Task type: marketing copy draft
- Model: fast-cheap-model
- Cost/time: low / 40s
- Quality: good, minor edits
- Major correction needed: no

Over a few real tasks, this becomes evidence for a project-specific model map: which model drafts copy well, which one reasons through code best, which is useful as an independent reviewer, and which is cheap enough for repetitive work. The durable lesson is to evaluate with a representative task and observed output — then refresh the decision when the work or the available models change. Model names, prices, capabilities, and interfaces move quickly; your notes keep the routing decision grounded in evidence rather than brand loyalty or last month's recommendation.

Connect routing to CLI orchestration: in a terminal-based coding setup, you can launch separate bounded sessions against different models, give each a narrow input/output contract, and compare their work side by side. One session drafts, another reviews, a third runs tests. This is safer and clearer than mixing several roles and models inside one swollen conversation, where review, implementation, and planning all contaminate each other — the exact swollen-session problem the previous lesson taught you to reset.

The decision log: a preview of durability

Introduce one more durable habit now: the decision log. In plain language, it is a short dated Markdown record of decisions that should not be reopened by accident — which date utility the project uses, which access model "shareable" means, which schema is frozen. Do not build Part X's full specification system here; this is a preview of why a durable decision is useful. When the next session proposes reopening a settled question, the log answers it in one line. Drift often enters through re-decided decisions; the log closes that door.

A tangible example: timezones without a new library

Make the narrow constraint concrete. The event finder needs dates displayed in the local user's timezone. The rail is one sentence: reuse the project's existing date utility; do not introduce another date library. That sentence prevents an entire category of drift — a new dependency, a second formatting convention, conflicting timezone logic — while leaving the AI fully free to solve the actual problem: find every display site, route it through the shared utility, and prove it with morning and evening examples across two timezones. Rails remove the wrong freedom and protect the right freedom.

Exercise: mark every line before implementation

Pick one real feature and write a bounded-change request for it. Have the AI produce a plan only. Then mark every line of the plan as approved, question, or out of scope before allowing any implementation. Anything marked question gets an explicit decision written into the brief; anything out of scope gets moved to a separate task or deleted. Save the result as CHANGE-BRIEF.md with four sections: goal, constraints, approved plan, and verification list.

Finish line: a CHANGE-BRIEF.md whose verification list a second person — or a fresh AI session — could execute without asking what "done" means.

When rails fail: too many, too contradictory

Rails have their own failure mode: constraints become so long and contradictory that nobody can tell what matters. A brief with fourteen musts, six must-nevers, and three "use your best judgment" clauses is not a rail — it is fog, and the AI will infer its way through the fog exactly as the previous lesson described.

Recovery is a compression exercise. Restate the brief as one primary outcome, three non-negotiables, and a short out-of-scope list. Everything else becomes a question for later or is deleted. For the citation-date task: outcome — every source shows its publication date or a clear "date unavailable" state. Non-negotiables — no schema change, no new dependency, export behavior unchanged. Out of scope — navigation, authentication, redesigns. If a constraint does not fit in that frame, it probably was not load-bearing.

Check your understanding

• What three things must a rail tell the AI?
• Why should edit permission usually be narrower than inspection permission?
• What should a plan list before you approve implementation?
• What goes into MODEL-NOTES.md, and why must the model map be refreshed over time?

You now have both halves of drift control: the previous lesson's reset for drift that already happened, and this lesson's rails for keeping the next session bounded from the start. Class 39 follows naturally — because drift changes the task, while the next failure mode accumulates when successive bounded changes still leave the system with no understandable shape.