Agent-run software delivery
Agents do the work. The gates are not negotiable.
CIAN runs software delivery as a ten-phase pipeline staffed by coding agents. Two of those phases are hard gates, enforced by the state machine that owns the pipeline — not requested in a prompt, and not something an agent can argue its way past.
The watch bar: what the supervisor sees. Amber means a human is needed — the only colour in the product that means you.
- 10 phases every change moves through
- 2 hard gates, enforced in the rules layer
- 0 override flags — there is no bypass to find
- 1 human approval, required on every revision
The problem it is built around
An agent that can write code can also talk itself out of a rule.
Ask an agent nicely not to ship code with a known vulnerability and it will usually comply — until the instruction is long, the context is full, the change is urgent, or the agent decides the finding is a false positive. A policy that lives in a prompt is a suggestion.
CIAN's answer is to move the rules that matter out of the prompt entirely. The two that matter most are enforced by the state machine that owns transitions between pipeline stages. An agent cannot argue with them because it is not the one being asked.
What that buys you
The gates apply to every path into a protected stage — an agent's request, a direct API call, a replayed webhook, or an edited project manifest. They are tested against each of those bypasses, including the subtle one: evidence from an earlier revision being reused for a later one.
How a change moves
Ten phases, agents doing the work at each one, and two points where the pipeline stops until something real has happened.
-
Intake and batching
Work is pulled from the tracker you already use and ordered so that changes which build on each other are not started in parallel and merged into conflict.
-
Build and test
An agent implements the change in an isolated worktree. Tests run under a structured contract — results are recorded as data the pipeline acts on, not prose an agent summarises.
-
Security gate
Static analysis, dependency audit and configuration review. An unresolved Critical or High finding on the current revision stops the work here and refuses the transition into review.
-
Human acceptance gate
You review the deployed change and approve or reject it. Without a complete approval record for that exact revision, the work does not reach done. No timeout ever approves on your behalf.
Why teams put a gate in the machine
-
Security findings block, they do not warn
A Critical or High finding on the current revision refuses the transition into code review. There is no override flag, and a clean scan of an earlier revision does not count for a later one.
-
A human signs off, or it is not done
Reaching done requires a recorded approval — identity, timestamp, device attestation and the exact revision reviewed. Approvals do not carry forward to the next build.
-
The gates reach your repository
Both gates write GitHub check runs, so a blocked change is blocked on the pull request itself — not just inside CIAN's own board, where it would be advisory text next to a merge button.
-
Supervision that fits a spare ten minutes
The iPad control room is built around the parts a human is actually needed for: reviewing a change, approving or rejecting it, and seeing what happened while you were away.
-
Compute you do not have to bring
Each project gets its own managed development container, provisioned for you. There is no server to rent, harden or keep patched, and no SSH key to hand over.
-
No public door to your workspace
A project's container has no hostname, no DNS record and no open port. It is reachable only from CIAN's own control plane, over an internal binding that never crosses the public internet.
See it on your own pipeline
Tell us what you are building and we will be in touch.