Coding Agents in CI and Code Review

Everything in this module so far has had you in the loop: watching the agent work, approving commands, reviewing diffs as they appear. The next step is to take yourself out of the loop for the routine parts. Picture a review comment waiting on every pull request before a human looks at it, new issues labeled within a minute of being filed, and a draft fix opened automatically when the build breaks on main.

That's what running coding agents in CI (continuous integration, the automated pipeline that builds and tests your code on every change) gives you. It also removes the person who would have noticed something going wrong. This lesson covers headless runs with Claude Code and Codex, three proven CI jobs (automated review, issue triage, and fix-the-build), and the guardrails that keep an unattended agent from becoming an unattended incident.

What changes when nobody is watching#

An agent in CI is the same agent you use at your desk, with four important differences:

• No one approves anything. There's no human to click "allow," so every permission has to be decided in advance, in configuration.
• The input is untrusted. Pull request descriptions, issue bodies, commit messages, and code from contributors can all contain text written to manipulate the agent. This is prompt injection, covered in depth in Prompt Injection, and CI is one of its favorite targets.
• Secrets are nearby. CI jobs hold API keys and tokens with real power over your repository.
• Mistakes repeat. A misconfigured job runs on every pull request, every issue, every night, and each run costs money.

So the design principle for CI agents is simple: the agent proposes, deterministic code and humans dispose. The agent reads, analyzes, and drafts. It posts comments, emits structured data, or produces a patch. Separate, boring, predictable steps (or people) decide what actually happens to the repository.