Your AI agent creates PRs faster than the team can review them: what to change in CI and releases

When faster coding does not produce faster releases

An AI agent creates PRs faster than the team can review them. More proposed changes accumulate in the queue, but releases do not happen sooner. The cause is not necessarily how people work: only one stage became faster, while the rest of the process remained unchanged.

The useful measure is not the number of PRs. It is the time required for a valuable change to reach production safely. If review, CI, or deployment cannot handle the increased flow, one of those stages begins to limit the whole process.

Cloudflare calls its engineering proposal the Agent Development Lifecycle (ADLC). It is not an industry standard or a reason to migrate platforms. The practical takeaway is simpler: alongside code generation, teams need to improve review, reproducible test environments, visibility into a change’s path, and deployment controls.

Trace the path of one change

Do not start by adding more automation. Begin with several recent changes. For each one, record when the PR opened, when the first human review started, when CI started and finished, and when deployment occurred. If a failure occurred, add the time required to restore service.

Check four measures:

• how many PRs are waiting for a first review and for how long;
• how long CI takes and how often a rerun is required;
• what share of deployments failed;
• how long recovery took after a failed deployment.

Do not search for one attractive headline number. Compare the stages. If a PR waits a day while CI runs for ten minutes, faster tests will not solve the main problem.

Move from simple controls to system changes

1. Limit active PRs

Set a limit on the number of PRs the agent may keep open at once. The agent should start another task when an earlier change has been merged or closed and a slot is available under the limit. Smaller PRs are also easier to review, test, and roll back.

2. Assign a responsible team member

Every PR needs a person who understands its purpose, assesses its risks, and can stop the deployment. A green CI status means only that the configured checks passed. It does not prove that the change meets a user or business need.

3. Stabilize CI first

Fix flaky tests—tests that pass or fail even though the code has not changed. Shorten long manual operations and remove dependencies on shared resources that other runs can modify. Otherwise, additional PRs will only produce more reruns and a longer queue.

For dependency changes, retain security check results and a software bill of materials (SBOM), an inventory of software components and dependencies. Docker’s article about the Docker-sponsored Omdia report presents component inventory as one way to manage risks from third-party and AI-generated code, not as a guarantee of security.

4. Give automation minimal permissions

Where appropriate, replace manual operations with controlled API calls. Use separate credentials for automation, only the permissions it needs, and a log of its actions. High-risk changes should wait for human approval.

5. Isolate testing and connect events

Create a separate temporary preview environment for each change. Do not copy production secrets or customer data into it. Connect the task identifier, commit—the recorded version of the change—CI run, and deployment with one identifier.

Structured events and OpenTelemetry traces can show the sequence of a change without requiring people to match unrelated logs manually.

6. Define when to stop deployment and how to roll back

Write down which failures block deployment, who makes the decision, and how to return to the previous working state. Test the procedure before the first incident instead of trying to understand it during a failure.

How to use AI without exposing unnecessary data

AI can group anonymized stage-duration data, identify long waits, and suggest hypotheses. Give the model only a diagram of the stages, anonymized metrics, and short log excerpts. Remove tokens, user identifiers and addresses, and request content.

The model does not know about undocumented manual actions, cannot see whether every event reached the metrics and traces, and does not understand how critical a particular service is. Verify its conclusions against CI history, OpenTelemetry traces, and a manually reconstructed timeline for one change.

Run a small pilot

Choose one low-risk repository. Compare similar changes before and during the pilot, and write down the success criteria in advance.

A successful pilot reduces time in the identified bottleneck. At the same time, CI reruns and failed deployments should not become more frequent, every change should be traceable from task to deployment, and the stop conditions and rollback procedure should work in practice.

Only after that verification should you increase the number of concurrent changes or include more repositories. The goal is not the largest possible number of PRs. It is a predictable path that delivers a useful change to users.

Sources

• Cloudflare: https://blog.cloudflare.com/agent-development-lifecycle/
• Docker summary of the Omdia report: https://www.docker.com/blog/software-supply-chain-security-omdia-2026-report/