An agentic dev pipeline is the shared path every agent-written change follows from idea to production. It answers a question engineering leaders keep asking: if coding agents now write much of our code, what makes the result trustworthy?
Neither of the usual answers holds up at volume. "Humans read every line" collapses once agents produce changes faster than people can read them, and "the agent's tests passed" fails because the agent wrote the tests and the code from the same understanding. The method in these essays splits the work instead. People review the design, the interfaces and the risky parts. Everything else is proven by evidence the agent can't produce for itself.
The core method has six parts:
- Spec first. Data contracts, interfaces and acceptance criteria for each milestone are written before the build, and a model from a second family reviews the plan adversarially.
- Hooks for zero-exception rules. Rules that allow no exceptions live in hooks, not instruction files. For example, "done" is blocked while the type check fails, and state stays on disk so the next session can resume.
- Held-out acceptance. A person runs acceptance and click tests the agent never saw on each milestone slice.
- A gate that reads what ran. The gate checks executed, skipped and filtered counts, and a planted fault must turn it red.
- Measured review. Reviewers are measured with planted bugs. Finding 3 of 5 planted bugs alongside 12 real ones suggests about 20 real bugs in total, so about 8 are still hidden.
- Respect for compounding merge risk. Ten changes at 5% risk each give about a 40% chance that something breaks, so changes ship in small slices from isolated worktrees, behind CI gates, canaries and automatic rollback.
Start here
- The spec, the reviewers and the evidence ledger
- Turn engineering standards into agent execution contracts
- Your hook ran; did the forbidden action stay blocked?
- Why agents cannot grade their own work
- A merge gate must prove the tests ran
- Landed is not done: define done before agents report it
- Check that each git worktree resolves to itself
- Parallel branches need one owner for the migration index
- Separate probabilistic development from deterministic shipping
- The release gate is the product
Questions this topic answers
- What does a delivery pipeline for coding agents look like when you still need to trust the output?
- Which parts of agent-written code should people review, and which should tests prove?
- Which rules belong in hooks instead of instruction files?
- How do you check that "tests passed" means tests actually ran?
- How do you estimate how many bugs your review is missing?
- Why does merging many agent changes increase the chance of breakage, and how do you contain it?
If you are building or standardizing a pipeline like this, connect with me on LinkedIn to compare notes and discuss what your gate reads.