Case study
Three days away, eleven release-pipeline tickets, one Claude Code session as the orchestrator. What I set up, what broke, and what changed afterwards.
I own the release pipeline for a cloud broadcast console: Jenkins, the release engine behind it, and a roadmap of 25 tickets in six phases. In late September 2026 the phase that moved production onto checksummed composition deploys had eleven tickets left and a production canary booked for the following week. I was going to be away for two of the five working days. The tickets were well specified, mostly Groovy and Node, each with acceptance criteria and a contract test suite. That is the shape of work that agents handle well, as long as nothing they do can reach production.
One long-lived Claude Code session acted as orchestrator. It did not write code. It planned, dispatched one background agent per task into its own git worktree, verified every result against live sources, relayed my decisions, and reported in one Slack thread. The evening before, it smoke-tested every capability the agents would need (Jenkins reads, Jira comments and transitions, Bitbucket, pushing a throwaway branch from a worktree, posting to Slack), then made one subagent run the same checks, because subagents inherit tools but not assumptions.
The plan went into two files the agents could read: the dependency graph and schedule, and one self-contained brief per task with the file and line to start from, the design decision already made, and the known traps. Agents handed the prior-art location finished faster and made fewer wrong turns than agents told to go and find it. A cron job in the session kicked off each day's phase, checked the thread hourly, and posted an end-of-day summary. The hourly check posted only when something had changed or a question was waiting; "still running" is noise.
Every brief carried the same hard rules. None of them is theoretical; most were written after something went wrong in the two weeks before the run.
Agents self-review and move the ticket to "PR review". Hooks block
pushes to protected branches and the --no-verify bypass.
A person merges, in a written merge order.
No build triggers, no bucket or IAM writes, no aborts. Read-only requests are fine. Anything live becomes a numbered question for me.
Two weeks earlier, merging a PR whose description mentioned two related tickets had made the Jira automation close one of them: a ticket with no commits, no branch and no code, marked Done. Agents now phrase cross-references without the key.
A hand-typed submodule hash with one wrong hex digit had failed five consecutive builds at checkout, with an error that looked like a git fault. Hashes are captured from git commands and checked against the remote before any commit.
The mutation check reverts with git checkout, which
cannot restore an untracked file. A mutant stayed on disk until
someone noticed.
Two parallel agents overwrote each other's mutation script in a shared scratchpad.
Links to merged-branch builds die when the branch is deleted. The quote outlives the link.
The orchestrator watched the pipeline's own trigger events, not only its tasks. A routine merge-back build exposed a real regression: the version marker was stripping the composition identity on release-cutting builds, so the nightly environment lost its metadata and the deployment record failed closed. It was found and fixed the same day. It was not on the ticket list, and it would have waited for a human to read a console.
Independent review agents earned their keep too. They caught a restore step writing back on a different executor and a test that did not pin the call site it claimed to cover. Asking an agent to question its own plan surfaced a canary blocker (a first-migration confirmation hard-coded to false) before the canary ran.
develop every worktree push was refused. The
workaround was to build the commit with
git commit-tree and hand me a one-line push to run from
my phone. The guard was later fixed to read the pushed repository's
branch.
cmd | tail reports the
pipe's status, which masked a build that never ran. Capture the real
exit code.
On the Friday I asked the orchestrator to act as the DevOps engineer and walk me through the pull requests one at a time: why each was needed, what changed file by file, how it was proven, what to look at closely, and the post-merge proof it owed. It also listed eight decisions it had deliberately left to me. Nine of the ten agent pull requests merged that day in the written order; the tenth, a documentation change, merged after team review. The following week the work carried its first production canary through the new path, and all three production regions followed the next day.
Every surprise above went back into the skill that owns unattended runs, as a rule with the incident that produced it, so the next run starts from the lessons rather than rediscovering them. The same playbook now runs the bug-board sweep: the team opts a bug in with a label, an agent assesses and builds it in a worktree, proves it in a browser, opens a pull request, and a person merges. Its first seven pull requests all merged within the week.
If I were starting this at another company I would do it in the same order: the gates first (hooks, branch protection, a pre-push gate the agent cannot skip), then the evidence rules, then one opt-in workflow with a person at the end of it. The agents are the easy part.
Dates, counts and incidents come from the run's plan, Slack thread, ticket comments and git history. Ticket keys, colleague names and internal hostnames are left out. Back to the portfolio.