Ticket to deploy: redesigning the dev loop around agents

Most teams that adopt coding agents keep the development workflow they had and wedge the agent into it. The ticket is still two lines of prose. Review still means one senior reading everything. Deploy still waits for whoever feels responsible that day. Then the gains look thinner than the demos promised, and the tooling takes the blame. The real problem is that the loop was designed around one assumption, that typing is the slow part, and that assumption is gone.

Redesigning the AI development workflow means changing four things: what a ticket is, how work maps to branches, how review is tiered, and what CI enforces without asking. The human touchpoints that remain are fewer, and each one carries more weight than before.

The AI development workflow, before and after

Before: a ticket says "Add rate limiting to the public API". An engineer picks it up, spends half a day finding out which gateway, which limits, which error format, writes the code over two days, opens a 600-line PR, waits a day for review, answers three comments that are really requirements surfacing late, merges, deploys. Elapsed: a week. The actual specification never existed anywhere except in heads and review threads.

After: the ticket names the service and the middleware layer, sets the limits and the response contract, points to the config conventions, states the boundaries (no new dependencies, do not touch authentication) and gives the command that verifies the behavior. An agent runs it on its own branch. CI applies the same gates it applies to everything. A human reads the diff for intent and design rather than for missing null checks, and merges. Elapsed: a day, much of it queueing for review. And the specification now exists, in the ticket, where the next similar ticket can copy it.

Tickets become task definitions

The redesign starts at the ticket, because agents execute exactly what they are given. A good agent-executable task has four parts: context (which service, which modules, which conventions apply), acceptance criteria concrete enough to check mechanically, the command that proves success, and boundaries (files not to touch, dependencies not to add). A useful rule of thumb: if a new hire could misread the ticket, an agent will.

Writing tickets this way is not extra work. It is the same clarification engineers always did after pickup, silently and unshareably, moved to the front and made visible. That shift is what makes real delegation to an agent possible at all, and it is the part teams underestimate most.

One branch per agent run

Every agent run gets its own branch, ideally its own disposable worktree, and nothing reaches a shared branch except through the pipeline. This buys two things. Failed runs become cheap: delete the branch, sharpen the task, run again, with no archaeology. And parallel work becomes normal, one engineer supervising several runs at once instead of babysitting one.

Add a diff size limit, hard or advisory. Agents happily produce an 800-line change, and no reviewer reads 800 lines, they skim them. Smaller merges are the cheapest review-quality improvement available.

Review tiers and guardrails in CI

Everything mechanical belongs in CI guardrails: tests required on changed lines, static analysis at full severity, security scanning, conventions expressed as lint rules. The same gates apply to every change regardless of author, which is exactly why they keep holding when volume triples.

Human review then gets tiered by risk instead of treating every diff the same. Tests, documentation and internal tooling get a light pass or an agent pre-review with spot checks. Product logic gets a real read. Sensitive paths (authentication, payments, data deletion, migrations) get a named owner and a slow look, enforced through CODEOWNERS. Without tiers, review absorbs every hour the agents saved, and becomes the bottleneck of the whole system, usually within a month of rollout.

The touchpoints that stay human

Four survive, and they were always the actual engineering. Writing the task: deciding what to build and what done means. Checkpointing long runs: for risky work, the agent stops at a plan or a first draft and waits for a yes. Judging the result: does this change solve the right problem, does it fit the architecture, would we defend it in six months. Owning the deploy: a person decides that this ships now, with a rollback path they trust.

Notice what is not on the list: typing, boilerplate, wiring, the fourth similar CRUD endpoint. Engineers do not leave the loop. They move to its two ends, where judgment lives.

Where to start

Do not redesign everything at once. Pick one squad. Rewrite their next ten tickets as task definitions, give agents their own branches, add the diff limit and the changed-lines test gate, tier the review. Measure cycle time before and after, over weeks rather than days. This ticket-to-deploy redesign is the core of our agentic engineering work, and one squad at a time is exactly how we roll it out.