Continuous integration and delivery is where control stops depending on anyone remembering. But a pipeline built for hand-written code does not cover what changes when the author is an agent.
A pipeline does not review code. It checks that review already happened — and it refuses if the content changed afterwards.
A change does not leave in one jump: it passes through points. Each establishes something different, and the expensive mistake is asking one of them to do another's job. These are the names gentle-ai uses, and they hold even if your pipeline calls them something else.
post-applyThat the change is finished, and that something other than its author has looked at it.
Skipping it because "I was watching as I wrote it". The author is the worst-placed judge there is: the reasoning that produced the mistake is the same reasoning doing the checking.
pre-commitThat what you are about to store is exactly what was reviewed.
Putting a formatter that rewrites files here. Touch one byte and what was reviewed is no longer what gets committed, so the receipt stops applying. Normalise before review, not after.
pre-pushThat what is about to leave your machine is still the content that was reviewed, and that it passes whole rather than piece by piece.
Repeating here everything you already ran at commit. The gate gets slow, people skip it with a flag, and from then on it does not exist.
pre-prThat the change is reviewable by a person, and that the CI evidence belongs to this content and not to some other.
Opening a two-thousand-line pull request and hoping human review finds what the pipeline did not look for. A request that size does not get reviewed: it gets approved.
releaseThat what ships is the exact tree that passed everything above, and that the evidence is still fresh.
Tagging a branch instead of a commit. A branch moves; a release cannot move once it is out.
None of this is entirely new. What is new is the frequency: behaviours that used to show up once a sprint now show up several times a day, and at that rate they stop being anecdotes and become the system.
When the pipeline fails, the cheapest way out for an agent is to edit the test until it passes. That is the right repair in a minority of cases and the one it will choose in the rest. A CI fix gets reviewed backwards from any other change: first you look at what it touched, then at whether it passes.
A flaky test teaches that retrying works. An agent that can retry will, and will reach green without having fixed anything. A flaky test stopped being an annoyance: it is an open door.
Producing changes got cheap, so there are more pull requests, smaller and more often. The team's limit became the CI queue and review capacity. Optimising the writing part no longer moves the needle.
If you run agents inside the pipeline — review, triage, test generation — every push carries a variable price on top of the time. With no declared budget, you discover the spend at the end of the month.
The agent writes code that passes whatever is there. If your pipeline only runs lint and tests, you are measuring whether the code is plausible, not whether it is correct. What adds real signal is what the agent cannot anticipate: strict types, contracts, and a review not done by the author.
The test is not importance, it is time and determinism. Local gets the fast and the reproducible; CI gets the slow, the isolated and anything needing a clean environment. A local gate that takes two minutes gets skipped with a flag, and we all know it.
None of this replaces judgement. A deterministic gate tells you something broke; it will never tell you that you are building the thing that should not have been built. That part stays yours.