Agentic workflows: governing what you can’t read

The fourteen files you didn’t know were touched

You hand an agent a real task: “refactor the auth module to support OAuth.” You let it run. It comes back with fourteen changed files, and the happy path works. The interviewer (or your reviewer) points at a file you didn’t know was in scope and asks what one change does. You can’t say — you’ve never seen it.

Predict, before reading on: at what scale did the loop break? Not at “the agent is bad” — the code mostly works. It broke when the work exceeded what you could preregister and review per unit, and you were still using single-function habits on a repo-sized change.

The loop at repo scale

The fix is not a different loop — it’s the same six stages applied to units of work instead of lines of code. You clarify and preregister the whole task up front (the plan, the interfaces between parts, the invariants that span them); then you let the agent execute one unit; then you review and verify that unit before the next. Two stages get promoted:

• The plan becomes the preregistration. For a single function you commit invariants and tests; for a multi-file change you commit the decomposition, the interfaces between units, and the cross-cutting invariants — the standard the whole change is held to.
• Checkpoints become the gates. Instead of one gate at the end, you gate between units: a place you read the diff, run the gate, and decide go/no-go before the agent continues.

Same discipline, coarser grain. The skill is choosing the grain.

Scope and checkpoints

Carving the task is the move. Break an agentic job into units each small enough to review and verify on its own, with an explicit checkpoint between them. The highest-leverage version: when the agent will do something repetitive (migrate 30 call-sites, update every handler), have it do one representative unit end-to-end, review and verify that, then let it apply the verified pattern to the rest. You gate the pattern before it’s stamped thirty times — catching a systematic error once instead of thirty times.

The un-one-shottable problems in modern rounds (Canva’s deliberately ambiguous, realistic tasks) are built to reward exactly this: they can’t be vibe-prompted in a single shot, so they reveal whether you can decompose a problem into verifiable pieces and hold the line on scope. Predict the governing move in each case:

The thread: gate the pattern on one unit, hold the agent to the committed scope, and never let a change grow past what your checkpoints can cover.

Governing what you can’t read

Sometimes the change is genuinely too large to read every line — and reading all of it isn’t the senior move anyway; it doesn’t scale and it spends your attention uniformly when risk isn’t uniform. Govern by four levers instead:

• The seams. Read the changed interfaces and contracts deeply — that’s where integration bugs live and where one unit’s correctness meets another’s.
• The gate. An automated test/invariant suite covers, mechanically, what you can’t eyeball across fourteen files (this is the next chapter — the gate has to grow up into real evaluation).
• Risk-weighted reading. Deep-read the two or three riskiest units (auth, money, data-loss paths); sample the rest. Attention follows risk.
• Plan adherence. Did the agent do what you scoped — and only that? Scope creep is unreviewed change.

This is how senior engineers actually review large AI-assisted changes, and naming it out loud is the interview signal for agentic competence: you govern the change, you don’t pretend to have read it all.

How this is graded

Trade-off Awareness is this chapter’s weighted dimension — scoping and checkpoint placement are trades against risk:

• Trade-off Awareness (weighted) — you carve the work and place checkpoints by where risk and architecture live, rather than running the agent unsupervised or reviewing everything uniformly.
• Evaluation Rigor — the gate covers what you can’t read, and you verify per-unit before proceeding.
• Technical Correctness — you read the seams, where integration bugs between units actually live.
• Communication — you narrate the scoping and gating, demonstrating governance of an autonomous tool.

Industry variation

• Startups — agents are a velocity multiplier; the discipline is gating the pattern before it’s applied broadly, so one systematic mistake doesn’t propagate across the codebase.
• Big tech — agentic changes land in huge repos behind CI and code review; blast radius and review culture make checkpointing and seam-review mandatory, not optional.
• Regulated (fintech, health) — every unit needs accountability; an agent can’t leave files no one can explain, so per-checkpoint review is also a provenance requirement.
• Frontier labs — agents on research code; checkpoint the method (is the experiment still valid?), not only whether the code runs.

Stretch: when the gate has to grow up

You leaned on “the gate” to cover what you couldn’t read. But for a fourteen-file change — or for AI that produces output at volume — a few hand-run tests aren’t a gate anymore; you need a real evaluation harness. Before the next chapter: if an agent generated 200 outputs (or 500 tests), how would you check them when reading even a fraction isn’t enough?

Next: Chapter 10 — Evaluating AI-assisted output, where verification scales into evaluation, and this guide meets the evaluation discipline of Guide #1.