BEYWARE.
DE
← Back to blog

Engineering

Agentic CI/CD: How Our Software Factory Runs from Issue to Deployment

11 June 2026 · 7 min read

Agentic CI/CD: How Our Software Factory Runs from Issue to Deployment

Why a factory

We run many small and medium-sized projects at once: integration services, internal tools, products. Each of them needed a repository, a pipeline, a deployment, monitoring. At some point we noticed we were setting up the same things by hand for the fifth time – and slightly differently each time.

The answer was a versioned “factory”: a repository with workflow templates, runbooks for VM provisioning and a design specification that defines how a project gets from issue to running service. What is new about it is mainly that an AI agent takes the first step.

The flow

  1. Prompt or issue. An issue describes what is to be built. Well written, with acceptance criteria.
  2. AI agent. Claude Code or Codex takes the issue, works in the repository and opens a pull request. The agent follows the conventions defined in AGENTS.md or CLAUDE.md.
  3. CI. Tests, lint, security scan, build of a container image and push to the GitHub Container Registry.
  4. AI review plus human gate. A second agent reviews the PR. Then a human decides.
  5. CD. After the merge, a self-hosted runner in a Linux VM deploys the new image.
  6. Monitoring. Grafana, Prometheus and Loki, with Alloy as collector. Every service delivers metrics and logs, otherwise it does not count as finished.

AGENTS.md and CLAUDE.md: the conventions are the product

The agent is only as good as the context it gets. So most of the work is not in the pipeline but in the convention files. Per project they describe:

  • How the repository is structured and where things belong
  • Which commands apply for tests, lint and build
  • Which libraries are preferred and which are avoided
  • What commits and PR descriptions should look like
  • What the agent must not do – such as touching secrets or generating migrations without consultation

These files are living documents. Every time an agent does something stupid, we first check whether the convention was missing before blaming the model. Usually the convention was missing.

Planning documents come on top: for larger tasks the agent first writes a plan that we read before any code is produced. That costs minutes and saves hours.

CI is non-negotiable

Everything the agent produces goes through the same CI as human code – and it is deliberately strict:

  • Tests must pass, and the agent may not disable them
  • Lint and formatting are mandatory, not a recommendation
  • The security scan blocks known vulnerabilities in dependencies
  • The image is built and tagged with the commit hash so every state is reproducible

The point is: the agent produces faster than a human, so the automatic checks have to be harder, not softer.

What the human gate is for

The obvious question: if one agent writes the code and a second agent reviews it, why still a human? Our answer after a few months of operation:

The human gate is not there to check syntax. The tools do that better. It is there to answer three questions no agent answers reliably:

  • Is what was built what was meant? The agent solves the issue as written. Whether the issue was right, only the human knows.
  • Does the change fit the bigger picture? An agent sees the repository. It does not see that another department needs the same interface next week.
  • Do we want to operate this at all? Every change is also an operational commitment. That responsibility cannot be delegated.

The AI review before the gate ensures the human does not waste time on things a machine can find. The human gets a PR that is technically clean and concentrates on intent.

CD in a Linux VM

Deployment runs via a self-hosted runner in a dedicated Linux VM. We decided against hosted runners because the target environment – internal networks, own services – is only reachable from inside anyway. VM provisioning is documented as a runbook so it can be rebuilt in an hour.

Monitoring is part of the definition of “done”. A service that delivers no metrics to Prometheus and no logs to Loki is not considered complete. That sounds strict, but it has protected us from precisely the silent failures you otherwise hear about from users first.

Takeaway

Agentic CI/CD is not a replacement for engineers but a shift in their work: away from typing, towards formulating intent and conventions and deciding at the gate. The agent makes the factory fast. The conventions and CI make it safe. The human at the gate makes it meaningful.