Summary: Agents in the pipeline
A pull request opens on a Friday afternoon. Eleven minutes later, review comments appear: real findings, with files, lines, and reasons, and nobody read the diff. The reviewer was Claude Code running headless in the pipeline. This lesson is about making that scene trustworthy, and its frame comes straight from the track spine: an unattended agent is the purest test of your architecture, because nobody is there to catch it. Every decision must be made in advance and written down.
Core ideas
Section titled “Core ideas”- Claude Code’s non-interactive mode is the print flag: run one prompt, print the result, exit. It reads standard input and writes standard output, so a diff can be piped in and findings redirected out, like any command-line tool.
- Nothing may wait for a human. Permissions are granted in advance with the allowed tools flag or a permission mode, and an action the run was never granted ends the run instead of hanging it. In a pipeline, a fast failure beats a silent wait.
- The prompt must carry everything, because a headless agent cannot ask a clarifying question. Instructions that work interactively become coin flips unattended.
- Output format flags make the run machine-readable. The JSON option returns structured JSON with the result, session ID, metadata, and the run’s total cost; a streaming option emits newline-delimited events. A schema flag goes further and fixes the shape of the findings themselves, which is lesson 3’s schemas-that-refuse-to-lie argument resurfacing as a command-line flag.
- The pipeline pattern: pipe the diff in, parse the JSON out, post each finding as a pull request comment through the code host’s ordinary API. The posting code is a dozen testable lines of script.
- The CI agent is the newest teammate. By default a headless run inherits the checked-in configuration layer from lesson 2: project memory, scoped rules files, review criteria, fixture conventions. The repository onboards every session that opens it, human or not. Standards living in one person’s home directory never reach the pipeline.
- A bare mode exists for scripts that need the same result on every machine; it skips implicit loading, so context is passed explicitly instead. Either way, what the CI agent knows stays versioned and reviewed, never pasted into a workflow file.
- Generator and reviewer are never the same instance. An instance reviewing code it just generated carries the assumptions that produced the mistakes and goes easy on itself, like an author proofreading their own draft. The reviewer is a separate invocation with fresh context: it sees only the artifact and the standards, not the reasoning. This is lesson 6’s independent-review principle turned into mechanics. Never bridge the two runs with the conversation-continuation flags.
- On re-runs, avoid duplicate noise: fetch the bot’s prior comments, include them in context, and instruct it to report only new or still-unaddressed issues. State lives in the pull request, where humans can see it, not inside the agent.
- Precision is a spec, not a mood. “Be conservative” gets reinterpreted on every run; explicit criteria with concrete examples, plus a list of what never to flag and permission to find nothing, pin the threshold. A false-positive flood gets the bot muted, and a muted reviewer has negative value.
- Cost and latency are architecture. A nightly batch job can be slow, wide, and forgiving; a blocking pre-merge check must be narrow, fast, and predictable, with a turn cap, a spend ceiling, and a timeout. One configuration for both is a design error.
- Neither job is a free-roaming agent. Both follow routes the team drew in advance, with the model doing focused work inside each step. Simplicity stays the default when nobody is watching.
What changes for you
Section titled “What changes for you”When an automated reviewer comments on your pull request, you can now read its design: is it precise, deduplicated, and fast, or is it flooding the thread and training everyone to scroll past? And when you build one, you know the checklist: permissions decided in advance, JSON out, standards inherited from the repository, an independent reviewer, prior findings carried into re-runs, criteria with examples, and a budget matched to who is waiting. The next lesson is the capstone: design, build, and defend a small agentic system of your own.