CI is already a pipeline. A push lands. Jobs run. A status shows up on the pull request. People trust that status because it is boring: lint, typecheck, tests, maybe a build. When it is red, there is a log. When it is green, you are allowed to talk about merge.
Putting AI in CI means a model becomes one of those jobs. That can help a small team. It can also turn the status row into a mood. The rule is simple. A CI job must have an owner and a definition of red. If you cannot say what a failure means, it should not be a required check.
Three jobs that belong in CI
A review job that comments, then goes green. The model reads the diff and leaves comments. The job fails only if the model could not run: auth, timeout, quota. It does not fail because it found a nit. Comments are the output. The status means “the first pass ran.”
This is the job most small teams actually want. It is also the one people implement backwards. They make “model found something” a red X. Then authors pad the prompt or split PRs into dust to keep the build green. You wanted a reviewer. You built a slot machine.
A test-suggestion job. The model proposes cases for the new behavior. It can open a comment with a snippet. It should not push to the branch unless your team already likes bots that commit. Someone still adds the test they believe in. CI’s real test job remains the gate.
A flake note, not a flake judge. On a failed run, a model can summarize the log: “this looks like the same timeout in suite B.” That saves a tired author twenty minutes. It should not auto-rerun forever and it should not mark the failure as flaky without a human. Small teams do not have a flake committee. They have one person who knows the suite is haunted.
Jobs that do not belong there yet
Generating the entire test suite on every push. Asking the model to approve the architecture. Blocking merge on “security score.” Running a long agent that browses the repo for half an hour while the author waits to see if they may ping a reviewer.
Those can be research. They are not CI. CI has to finish while the author still remembers the change. For a small team, that usually means minutes, not an overnight batch, and not a bill that shows up as a surprise because a busy repo re-ran an agent on every typo.
A concrete setup
Repo: a TypeScript API. Host: GitHub Actions. Existing checks: lint, unit tests, a small integration job against a disposable database. PRs are the only way to main.
You add one job, ai-review, on pull_request. It runs after checkout. It sends the diff — not the repo tarball — to the review tool you already chose. It posts comments. It exits 0 unless the tool is down.
You do not mark that job required. Lint and tests stay required. The review comments are the useful artifact. If the vendor is down, the PR is not stuck. The author can still get a human.
You set a time budget: if the job is not done in ten minutes, it fails as “tool timeout,” not as “code is bad.” You set a spend budget if the vendor charges per run. A small team should know the monthly ceiling before the first busy week.
That is enough. You now have AI in CI. You do not also need a nightly “audit the company” workflow in week one.
Comments versus statuses
A comment is a conversation. A status is a gate. Most model output wants to be a comment. Most teams make it a status because statuses feel official.
Use a status when the question is mechanical and stable: “did the secret scanner run,” “did we upload the SBOM,” “did the review job finish.” Use a comment when the question is judgment: “is this a bug,” “is this a missing test,” “is this a bad cache key.”
If you want both — a first-pass review and a required human — keep them as two seats. The CI job reports that the pass ran. The human reports that the change may merge. Mixing them is how you get a red build over a suggestion to rename a variable.
The review seat itself is described in add AI to your review pipeline. CI is just the trigger that makes that seat reliable.
Cost, latency, and the small-team constraint
A ten-person company can afford a model on every PR. They cannot afford a model that rewrites the world on every push to a draft. Limit the trigger. Skip drafts if your host allows it. Skip automated dependabot PRs unless you actually read those reviews. Skip docs-only changes if you can detect them cheaply.
Latency matters more than people admit. If the first-pass comments arrive after the human already reviewed, you have two reviews that do not talk to each other. Aim for comments before the author pings. That is usually “a few minutes,” not “by tomorrow.”
If the vendor cannot meet that, run the model on open, not on every commit, and let the author request a re-run. A button is better than a slow mandatory job.
Mistakes
Blocking merge on the model. Covered above. It trains people to hide work from the bot.
No owner for a red AI job. When the job fails because of quota, nobody knows who pays or who retries. Put a name in the workflow comments. Rotate it like on-call if you must. Do not leave it as “platform.”
Logs that are a novel. If the job prints the full chain of thought, nobody will read a real failure. Keep the log short: input size, duration, comment count, error. Put judgment on the PR.
A second CI copy of the same review. GitHub app comments plus an Actions job that says the same things. Pick one trigger. Two seats with the same scope is how you get duplicate threads and a team that mutes both.
Using CI to avoid a merge habit. Green checks feel like progress. They are not a ship. If PRs still sit, the model did not fail. The habit did. That problem is described in what is an AI code pipeline.
What to do this week
List your required checks. If you cannot explain a red on each of them, fix that first. Then add at most one AI job. Comments, not a gate. A time budget. An owner.
Run it on the next real PR, not a toy repo. If the comments are late or loud, fix trigger and scope before you add another job. If they are useful, leave CI boring. Boring is the point.