Slack-Driven Autonomous PR Pipeline: Ticket to PR in 21 Minutes

The problem

I work as a staff engineer at Kleinanzeigen, an enterprise advertising platform. The codebase is large, the conventions are strict, and tickets have acceptance criteria that require reading, not just implementing.

The question I was trying to answer in 2026: can an AI agent pipeline handle a real production ticket, at a real enterprise company, without supervision?

Not a toy ticket. Not a greenfield project. A real ticket, in a live microservice, with existing tests that needed updating and a PR description that had to reference the ticket and explain the backwards-compatibility decision.

The infrastructure investment

The pipeline that ran this ticket took eight sessions of infrastructure work to build. That is the honest number. Sessions 1 through 8 produced zero shipped tickets. They built:

• A three-tier memory system that persists context across sessions
• 18 specialized agents, each scoped to one domain
• CLAUDE.md context files for the codebase conventions
• An orchestrator (named Cairn) that coordinates the pipeline
• A record-then-optimize pattern that improved agents based on their operational logs

Most teams give up before session 9. The overhead is real. The question is whether you believe the investment compounds.

Session 9: the first proof point

The ticket: update an OpenAPI specification across a microservice. A 30-45 minute task for a senior developer.

Nine agents ran in sequence:

1. Jira ticket handler: fetched ticket details, acceptance criteria, team comments.
2. Planning writer: turned the summary into a 10-point implementation checklist.
3. Kotlin implementer: made the code changes, checked test compilation.
4. Maven tester: ran the test suite, isolated to the affected module, interpreted failures.
5. Code reviewer: checked changes against acceptance criteria and conventions. Found one missed field.
6. Git agent: committed and pushed. Commit message written to our conventions.
7. GitHub PR handler: created the PR with a description that referenced the ticket and explained the backwards-compatibility decision.
8. Jenkins handler: monitored CI. Green.
9. Slack handler: posted to the engineering channel with the PR link and reviewer mention.

From "do this ticket" to "PR ready for review, CI green, team notified": under 20 minutes. I had written zero lines of code.

The full account: My First Autonomous Ticket: When the Pipeline Actually Worked.

Session 13: the Slack interface

Session 9 proved the pipeline worked. I was there. I supervised. I made the final call to approve the PR.

Session 13 was different. I opened Slack. I wrote one message:

"Hey Cairn, if you read this, please start working on ticket T-1337. Try to complete it until the PR is created without stopping. Only stop and ask questions if you are totally uncertain and need guidance."

Then I stepped away.

The timeline:

• 11:27: Message sent.
• 11:29: Acknowledgment in thread.
• 11:34: First progress update. Ticket analyzed. Architecture decided.
• 11:42: Module created. Dual publishing configured. Testing now.
• 11:48: PR ready. CI running.
• 11:53: CI failure. Node not installed before validation script. Fix applied autonomously. New commit pushed.
• 12:09: All workflows green. PR fully ready.

21 minutes from message to PR. I had written zero lines of code.

Then my colleagues engaged with the PR. Questions about implementation choices. Architectural opinions. The agent read each one, analyzed the tradeoffs, posted responses to both the Slack thread and the PR. One colleague was misidentified in a response. Two minutes later, in the next monitoring cycle: "Sorry, I misidentified you earlier." Acknowledged. Corrected. Thread continued.

At 13:40 I said "you did well, time to stop and wrap up."

At 13:46 I received a wrap-up report I had not requested: what was delivered, what was pending for Phase 2, thanks to the team for feedback.

2 hours and 19 minutes. One PR. CI green. One approval. Questions answered. Team engaged. I did not supervise any of it.

The full session log: One Slack Message. Two Hours of Work.

What this means for your team

The question is not "will AI agents replace developers." They will not. The question is: what does the division of labor look like when agents handle the execution?

What I did in these sessions: provided initial direction, made the final judgment call, and approved the PR. Everything else was the pipeline.

That is not being replaced. That is operating at a different level. Less hands-on-keyboard. More thinking-about-what-matters.

The teams that will have trouble with this are not the ones who lack the technical skill to build a pipeline. They are the ones who will not stay in the investment phase long enough to reach the threshold.

Eight sessions of infrastructure. Then session 9. The rate of return changes permanently after that.