From Slack Message to Pull Request: Agentic Delivery Is a Guardrails Problem

When someone at Mechanical Rock wants a change to our website, they don't file a ticket. They ask donk, our Slack bot. What comes back is a pull request: a branch, a written summary of the change, and the same automated checks every human change has to pass. An engineer reviews it. If it's right, it merges and deploys. If it isn't, it doesn't.

Building that taught us something we now tell every client. The model is the easy part. Any of the frontier coding models can write a sensible change to a Next.js site. The hard part, and the part most organisations are underinvesting in, is the system around the agent: where requests come from, what the agent is allowed to touch, what it can spend, and who signs off.

This post walks through how we built our Slack-to-PR pipeline, the guardrails that make it safe to leave running, and what we'd tell a team that wants to do the same. If you're an engineer, the wiring is all here. If you lead a technology function, the argument is in the guardrails section.

Key takeaways

• Agentic delivery is a guardrails problem before it's a model problem.
• The biggest delays sit in hand-offs between asking and shipping, not in typing code.
• In 2025, DORA found AI amplifies whatever delivery system it lands in, good or bad.
• Start where requests already happen, and end at a human-reviewed pull request.

Isn't adopting AI mostly about choosing the right tool?

In 2025, Google's DORA research found that 90% of surveyed technology professionals already use AI at work (Google Cloud, Announcing the 2025 DORA Report). So the tool decision is, for most teams, already made. The open question is what you do with it.

The common view is still that adoption means picking a model and putting an assistant in every developer's editor. We understand why. It's easy to buy, easy to roll out, and developers like it. It also fits how software teams have always adopted tools: one engineer at a time, inside the IDE.

That view isn't wrong. It's incomplete. It treats AI as a faster keyboard for people who already write code, and it leaves the rest of the delivery system untouched. For a consultancy, that's the part we get paid to fix. Our approach to AI ways of working starts from the system, not the seat licence.

Why isn't individual speed the bottleneck?

Developer speed was rarely what held a change back. In 2025, DORA reported that AI adoption still has a negative relationship with software delivery stability (Google Cloud, Announcing the 2025 DORA Report). Faster typing into an unchanged system can make delivery shakier, not better. We see three reasons.

The hand-off is where the time goes

Think about how a small website change used to happen here. Someone in marketing spots a wrong label in the navigation. They mention it in Slack. An engineer says they'll look at it. It goes on a list. A week later, someone remembers. The fix itself took ten minutes. The waiting took the rest.

None of that delay lives in the editor. An AI assistant in the IDE only speeds up the ten minutes. The request still has to travel from the person who noticed it to the person who can fix it, and that journey is where small changes go to die.

Feeling faster isn't the same as being faster

In early 2025, METR ran a randomised trial with 16 experienced open-source developers across 246 real tasks. With AI allowed, they took 19% longer, yet afterwards believed AI had sped them up by 20% (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity).

Tools have improved since. METR's own February 2026 update says developers are likely faster with AI now, while noting its newer data is only weak evidence of how much (METR, We are Changing our Developer Productivity Experiment Design). The durable lesson isn't the slowdown. It's the gap between perception and measurement. If you can't see what the agent did, you can't judge it.

AI amplifies the system you already have

DORA's 2025 framing is blunt: "AI doesn't fix a team; it amplifies what's already there" (Google Cloud). Strong teams get stronger. Struggling teams see their problems intensify.

Trust tracks the same pattern. In the 2025 Stack Overflow Developer Survey, 46% of developers said they distrust the accuracy of AI tools, against 33% who trust it (Stack Overflow, 2025 Developer Survey: AI). Developers aren't wrong to be wary. So the question becomes: what system makes an agent's output easy to check?

How does a Slack message become a pull request at Mechanical Rock?

Our pipeline turns a Slack request into a reviewed pull request using tools most teams already own: Slack, GitHub Issues, GitHub Actions and an AI coding agent. Nothing reaches production without passing CI and a human review. Here's the flow for mechanicalrock.io, which runs on Next.js and Sanity.

1. Someone asks donk in Slack. No template, no ticket fields. They describe the change the way they'd describe it to a colleague.
2. donk files a GitHub issue through its own GitHub App. The issue becomes the written spec, and it stays on the record.
3. The new issue triggers a GitHub Actions workflow. It runs Claude Code, Anthropic's coding agent, through Anthropic's official claude-code-action.
4. The agent reads the codebase, makes the change, and runs our checks. That means linting and our regression suite, the same commands a human runs locally.
5. It opens a pull request. From there the PR enters the same pipeline as any human change: quality checks, then a preview deployment.
6. An engineer from our website admins group reviews it. Merge, request changes, or close.

The design choice we'd defend hardest is step 3, routing everything through an issue. It would be simpler to have the bot push code directly. But the issue gives every change a readable origin: who asked, what they asked for, and what the agent produced in response. When a reviewer asks "why does this PR exist?", the answer is one click away.

What guardrails does an autonomous coding agent need?

An autonomous coding agent needs limits on who can start it, what it can spend, how long it can run, which commands it can execute, and who approves its output. In 2025, 87% of developers surveyed by Stack Overflow said they were concerned about the accuracy of information from AI agents (Stack Overflow, 2025 Developer Survey: AI). Guardrails turn that concern into something you can check.

Here's what we put around ours:

Most of this fits in a few lines of workflow configuration:

on:
  issues:
    types: [opened]

jobs:
  claude:
    # Only donk's GitHub App can start a run.
    if: github.event.issue.user.login == 'your-bot[bot]'
    timeout-minutes: 30
    concurrency:
      group: claude-issue-${{ github.event.issue.number }}
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          allowed_bots: "your-bot[bot]"
          claude_args: >-
            --max-turns 60
            --allowedTools "Bash(pnpm install --frozen-lockfile),Bash(pnpm lint),Bash(pnpm test:quality),Bash(gh pr create:*)"

Notice what isn't on the list. The agent never holds deployment credentials. Those live in a separate workflow that runs only after a pull request exists. The agent can propose a change. It can't ship one. That single separation does more for safety than any choice of model.

If you've read our earlier piece on GitHub branch protection and environments, this is the same principle: put the controls where the code can't route around them.

Meet people where they already ask

The second lesson is about people, not pipelines. Requests already happen in Slack. Every extra step between "I noticed this" and "someone fixed it" is a place for the request to stall. So we stopped asking people to move to the engineering workflow, and brought the workflow to them.

This changes the shape of the work on both sides:

• Requesters describe outcomes in plain language. They don't need to know which file holds the navigation, or how Sanity schemas work.
• Engineers shift from writing every small change to specifying and reviewing them. The pull request becomes the contract between the person who asked and the agent that answered.
• Leaders get an audit trail for free. Every change has a request, an issue, a diff and a named reviewer.

Is that a smaller role for engineers? We'd argue the opposite. Review is where judgement lives. Moving engineers there puts their experience where it matters most.

How do you start building your own request-to-PR pipeline?

Start with one repository, one trigger and one reviewer group, then widen it. You don't need a platform team or a new product. Here's the order we'd follow with a client:

1. Pick a low-risk repository with decent tests and CI. A marketing site or internal tool is ideal. Quick win: a day or two.
2. Make the issue the only entry point. Have your chat bot, or a form, create issues. Restrict the agent's trigger to that one author.
3. Give the agent its own budget and identity. A separate API workspace and a dedicated GitHub App make spend and actions traceable.
4. Allowlist commands, don't blocklist them. Start with lint, test and "open a PR". Add to the list only when a real request needs it.
5. Keep deploy credentials out of the agent's job entirely. Then route every PR to a named review group.

Measure the system, not the feeling. Track time from request to merged PR, the share of agent PRs merged without rework, and how many get closed. Those numbers tell you whether the pipeline is earning its keep.

Not sure how ready your delivery system is for this? Our AI maturity assessment is a good first step.

What should you plan for before you scale it?

This works best for small, well-described changes in a codebase with good automated checks. It's not a replacement for design work, architecture decisions or anything that needs a conversation first.

We use the same request-to-PR pattern beyond our own website, and two things decide whether it scales. The first is review capacity. If agents open pull requests faster than people can review them, the bottleneck just moves, so size the reviewer group alongside the scope of requests. The second is the codebase. An agent is only as good as the code it reads, and strong tests and clear structure give it something to stand on.

Both of those are properties of the system, not the model. Which is the point.

It's time to make the shift

Agentic delivery succeeds or fails on the system around the agent. Choose your model, by all means. Then spend most of your effort on where requests start, what the agent can touch, what it can spend and who signs off.

We think the organisations that get value from coding agents over the next few years won't be the ones with the cleverest prompts. They'll be the ones whose delivery systems were already disciplined enough for an agent to plug into: clear entry points, strong CI, separated credentials, and engineers who review with care.

That's the work we do with clients through enterprise DevOps and AI ways of working. If you want to put an agent on your backlog without putting your production systems at risk, let's talk.

---

Sources

• Google Cloud, Announcing the 2025 DORA Report: State of AI-Assisted Software Development, 24 September 2025, retrieved 2026-11-05, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• Stack Overflow, 2025 Developer Survey: AI, retrieved 2026-11-05, https://survey.stackoverflow.co/2025/ai
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025, retrieved 2026-11-05, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• METR, We are Changing our Developer Productivity Experiment Design, 24 February 2026, retrieved 2026-11-05, https://metr.org/blog/2026-02-24-uplift-update/