My First Autonomous Ticket: When the Pipeline Actually Worked

Session 9. We were eight sessions deep into building the infrastructure — the three-tier memory system, the agent architecture, the deployment pipeline, the evolution cycle. No shipped features yet. No tickets closed. Just infrastructure, infrastructure, infrastructure.

I had the classic “when does this pay off?” anxiety. Eight sessions of setup work is a lot to invest before you see results.

Session 9 is when it paid off.

The Ticket

The task was concrete: update an OpenAPI specification across a microservice at the enterprise advertising platform where I work. The kind of task that takes a senior developer 30-45 minutes — mostly reading the existing spec, making the changes, running the tests, writing a coherent PR description, and waiting for CI.

Nothing exotic. Nothing requiring brilliant insight. Just focused execution of a well-understood task in a codebase I know well.

The kind of task, I realized, that my agent pipeline was now exactly equipped to handle.

The Pipeline

I said “do this ticket” and gave the ticket number. What followed:

jira-ticket-handler fetched the full ticket details. Acceptance criteria, linked tickets, description, comments from the team discussion. It extracted what actually mattered — the specific API changes required, the affected service, the backwards-compatibility requirements — and produced a structured summary the next agents could work from.

planning-writer turned that summary into an implementation plan. Which files to touch. Which tests would need updating. What the PR should say. A 10-point checklist the kotlin-implementer would execute against.

kotlin-implementer made the code changes. Updated the OpenAPI spec. Updated the corresponding Kotlin interfaces and controller signatures. Checked that the existing tests still compiled. It knew our codebase conventions because CLAUDE.md carried that context. It knew Spring Boot’s annotation model because AGENT.md carried that knowledge.

mvn-tester ran the test suite. Isolated to the affected module. Interpreted the output. One test failure: a unit test that was checking a response code that the API change had intentionally altered. The implementer fixed it. The tester ran again. Green.

code-reviewer examined the changes against the acceptance criteria and our coding conventions. It flagged one thing: a field name I’d missed in the spec update that was referenced in two tests. Implementer fixed it. Reviewer approved.

git-agent committed and pushed. Commit message written to our conventions — ticket number, concise description of the change, not the why-this-matters explanation that goes in the PR. Clean branch name. No noise.

github-pr-handler created the PR. Read the ticket, the implementation plan, the code changes. Wrote a description that referenced the ticket, explained the backwards-compatibility decision, called out the one intentional behavior change and why it was correct. Assigned the relevant reviewers based on the service ownership map in CLAUDE.md.

jenkins-handler monitored the CI run. Watched the build. Reported back: green. All tests passing. No linting errors.

slack-handler posted to the engineering channel: ticket number, PR link, one sentence summary, @mention for the reviewer who needed to know immediately.

From “do this ticket” to “PR ready for review, CI green, team notified”: under 20 minutes.

What I Did

I said “do this ticket.”

I watched.

I approved the final PR after reading the code-reviewer’s sign-off.

I did not write a single line of code. I did not create the PR. I did not write the commit message. I did not write the Slack notification. I did not debug the failing test. I did not check whether the spec update was complete.

I made one decision: whether to approve the PR. Everything else was the pipeline.

The Feeling

It’s hard to describe what it felt like watching this work end-to-end for the first time. The closest analogy: like watching a factory you built produce its first product.

There’s pride — you designed this. There’s anxiety — what if something’s wrong and you didn’t catch it? There’s a strange sense of redundancy — what exactly am I doing here?

The answer to that last question turned out to be important. What I was doing was exactly what I should have been doing: providing the initial direction and making the final judgment call. The pipeline handled the execution. I handled the intent and the verification.

That division of labor isn’t me being replaced. It’s me operating at a different level — less hands-on-keyboard, more thinking-about-what-matters. The work I was doing in sessions 1-8 (building infrastructure) was the precondition for the work I did in session 9 (supervising a pipeline). Infrastructure-building is itself a form of leverage.

The Real Numbers

Eight sessions to get to one autonomous ticket.

Sessions 1-8: build the memory system, design the agent architecture, wire up the deployment pipeline, tune the evolution cycle, calibrate each agent on practice tasks. Zero shipped tickets.

Session 9: one autonomous ticket. One merged PR. Zero manual coding.

Sessions 10-23: dozens of tickets. The infrastructure investment amortized fast. (What this pipeline eventually evolved into — fully Slack-driven, triggering PRs autonomously — is described in Slack-Driven Autonomous PRs.)

The payoff is not linear. You spend a long time at zero, then you cross a threshold and the rate of return changes completely. Most people give up before the threshold. They try agentic workflows for a session or two, find it adds overhead without obvious benefit, and go back to writing code themselves.

The overhead is real. In sessions 1-8, I was slower than I would have been working alone. The agents made mistakes I had to catch. The infrastructure required constant tuning.

But that overhead is investment, not waste. You’re building something that will compound. The key is believing that long enough to actually reach the threshold.

For me, session 9 was the proof. After that, I never doubted the direction again.