CI/CD in the era of agents

I'm watching with great interest as the engineering processes and tools we've grown accustomed to over decades are being reimagined for an AI-native approach. For example, classic CI/CD built around pull requests and the pace of human development is poorly suited for a world where code is increasingly written by agents.

Before working with agents, the development cycle looked like this: a person writes code slowly → creates a PR → CI runs linters, tests, and builds → another person reviews the changes → changes land on the main branch.

In this paradigm, long CI pipeline runtimes were often expected and tolerated, because the biggest delay was always on the team's side: a developer would spend hours or days writing code, reviews also took hours or days to complete, and PRs stayed open for a long time.

With agents, everything is changing: code is generated quickly and relatively cheaply → the number of tasks grows → branches with changes multiply faster → PRs become too slow and inconvenient as a unit of work → change validation needs to be moved inside the agent cycle.

But CI/CD is very unlikely to disappear. Rather, it will stop being the framework around which change work takes place, and will transform into a low-level layer for fast verification of changes inside the agent cycle. Why is that?

Current CI/CD was designed for a world where humans are the primary agents.

A person holds a certain intention in mind: for example, "I want to add an order checkout button". Then they go through the cycle: intention → code → pull request → CI → code review → merge. At each stage, there may be a rollback:

• PR does not follow the accepted format → back to code

• Tests failed → back to code

• Reviewer asked to change the API → back to code

• Merge queue shows the branch is behind main → back to code

This is already an agent cycle, only the agent used to be a human. And in this cycle, the role of the harness (the guiding setup for the agent) was also performed by the person: the developer focused on the goal themselves, wrote code, ran checks, processed feedback from colleagues and tools, and brought the change to merge.

When code is written not by a human, but by an agent, the scale of operations changes:

• Many agents can work in parallel

• Many short-lived branches are created

• The number of PRs grows

• Frequent fixes become a normal part of the agent cycle

The problem is not just that CI will be slow in this paradigm. The problem is that the merge process itself becomes a bottleneck.

If you compare git to a change log, all agent-generated changes have to be added to it sequentially. This is starting to resemble a problem from the database world: transactions, locks, the order of applying changes (the infamous serializable isolation level). When there are few team members and they work slowly, the merge window can be long. When agents generate batches of changes in parallel, the main branch is constantly updated, and the chance that a working branch will quickly become outdated rises sharply.

Now, as coding agents are increasingly becoming a standard tool for teams, the development cycle is transforming into roughly the following workflow:

Goal + plan
      ↓
Agent cycle:
  code generation
  internal validation: build, tests, linters
  external validation: human or specialized agents
  fixes based on feedback
      ↓
Merge Queue
      ↓
Repository

It seems the next step will be reducing human involvement in the fast agent cycle. That is, developers will no longer have to review every iteration of changes and every PR. Specialized agents will be introduced for this purpose. It is easy to imagine an agent team like this:

• core coding agent

• security review agent

• performance review agent

• testing agent

• architecture agent

• agent that evaluates the functional correctness of the implementation against requirements

People will no longer need to read every diff as they did before. They will be able to focus on a higher level:

• this was the goal

• here is what was delivered

• here is the summary of changes

• here are the results of the security checks

• here are the risks

• here is a working demo

Only after that will they make a decision: approve, reject, or “changes required”.

I also bet that the very concept of the merge queue will change. A standard queue for merging changes won’t be enough. If many agents modify the same code in parallel, the system will have to do more than just run tests before a merge: it will need to group changes, resolve conflicts, check compatibility, and establish a safe order for applying them.

The environments for agent checks will also change. They will become more stateful: with pre-configured dependencies, warmed caches, local context, and preserved state between iterations. Otherwise the agent cycle will be too slow.

In the end, we won’t just get a CI job after a git push, but something closer to continuous compute: a computing environment that constantly operates around intent, code, validation, and candidate changes for merging into the main branch.