Your AI agent just said "it's done." What actually checked that?

Mik Bry · 2026-08-25 · ~7 min read · KB · Launch Readiness

Your AI coding tool says "done." It fixed the bug, added the field, pushed the change — done. That word is doing a lot of work in that sentence, and none of it is something you can verify just by reading it.

"Done" usually means the agent believes the change matches what you asked for. It doesn't usually mean that something else — separate from the agent's own account of its work — reran the project's checks and confirmed nothing broke.

Along with version history, this is one of the first things I look for when I review an AI-built app: is there a mechanism that reruns the known checks on the changes that matter, automatically, whether or not the agent thinks to mention it. Not because your agent is lying to you. Because "it's done" is a claim made in conversation, and a claim is not the same thing as a rerun.

01 — What is it?

CI stands for Continuous Integration. The name is unhelpful, so set it aside and hold onto the mechanism instead: CI is a separate, repeatable process that automatically runs configured checks when relevant code changes are pushed or proposed. Those checks may include building, type-checking, linting and tests. It repeats whatever checks you've configured — usually on a server somewhere, not on your agent's own machine. Martin Fowler, who has been writing about this since the 1990s, puts the core of it plainly: an automated build, "including test," that verifies every change to "detect integration errors as quickly as possible."

Here's the correction I want to make before this goes any further, because it's the one existing explainers tend to skip: CI is not an independent reviewer looking over your agent's shoulder. The same agent that wrote the code may well have written the tests CI runs, and the configuration that tells CI what to check. CI doesn't add a second opinion. What it adds is narrower, and still genuinely valuable — repeatability. The same known checks, run the same way, on the changes that matter, whether or not a human or an agent remembers to run them by hand.

Think of a pilot with ten thousand hours in the air, still running the pre-flight checklist before every single flight. Not because that pilot distrusts their own judgment — because a checklist that only sometimes gets read isn't a checklist, it's a suggestion. CI is the part of the process that never skips the checklist, because it can't get busy, forget, or decide "this change is small, it'll be fine."

And CI's job stops there, deliberately. Fowler makes this point too: whether to actually release what CI verified is, in his words, "a business decision" — a separate step, made by people, informed by what CI found. CI doesn't decide to ship. It just makes sure that whoever does decide is deciding with the checks actually rerun, not just a conversational "it's done."

02 — Why should you care if you don't code?

Because your agent can say "done," mean it sincerely, and still be wrong — and without CI, the first time anyone reruns the actual checks might be the moment a customer's card gets declined, not the moment before you shipped.

Build vs tests, another article in this series, covers the gap between a build that compiles and a product that actually works: a green build proves the checks that build included passed, nothing more. CI is the piece that closes that gap in practice — it's the thing that actually reruns those tests, automatically, on the changes that matter, instead of once when someone happened to write them and never again.

Without CI, checking becomes a rare, dreaded event: something that only happens right before a big release, under time pressure, when everyone's least equipped to deal with what it finds. With it, checking becomes a non-event — something that happens quietly, the same way, dozens of times a week, so small enough that nobody has to brace for it. That shift, from occasional and stressful to routine and boring, is most of what CI is actually buying you.

03 — What does good look like?

You don't need to read a line of configuration to check this. Look for:

• It runs automatically on the changes that matter — for example when code is pushed or a pull request is opened.
• It reruns checks that already exist — the build, the tests already written for this project. CI doesn't invent new judgment; it's only as good as what it's been told to check.
• The result is visible without reading code — a green checkmark or a red cross next to each change, the kind of status GitHub Actions shows on every pull request.
• It runs somewhere other than one person's laptop — so "it works on my machine" isn't the final word on whether it works.
• A failure is something people actually see, not a red status nobody's watching.

If your project has none of this, that's not automatically a crisis — a very early prototype might not need it yet. But once real users are involved, this is the difference between finding a broken change in a few minutes and finding it from a support email.

Reference: Red Hat's overview of CI/CD is a good next read if you want the fuller picture beyond what one article can cover.

04 — What can you safely ask your AI agent?

You don't need to find any of this yourself. Ask your AI coding tool to show you — and the exact wording matters, because "I didn't find anything" is not the same claim as "there is nothing." If your agent can't find a CI setup, the honest answer is that it couldn't find one, not that none exists. Paste this in as-is:

Read the answer before acting on it. If your agent lists a real, automated pipeline that reruns builds and tests on the changes that matter, that's what good looks like from section 3, confirmed. If it comes back empty, that's not proof nothing exists — but it's a real starting point, and one worth understanding before the next change ships on top of it.

This is one article in the Launch Readiness KB series that walks through what a Trust Report scan actually looks for before you launch, hire, or raise on an AI-built app — one concept per article, always ending in something safe to ask your agent, never something that changes your code.