AI dev agent: tickets go in, pull requests come out.
An AI dev agent is a system that takes an engineering ticket, works out what code has to change, writes that code and its tests, and opens a pull request for a person to review. The agent Paul Rahme built at a US marina-management software company, runs this in production on its marina-management software: a Linear ticket labelled ai-task goes in, and a compiled, self-tested pull request comes out for a human to approve, with ticket-to-PR turnaround twice as fast as before.
Scale model of the system
Scale model of the AI dev agent: a Linear ticket is read, scoped, coded with tests, and opened as a review-ready pull request.
Why boilerplate tickets eat senior engineering time
Most backlogs carry a long tail of tickets nobody argues about: a new field, a validation rule, a config flag, a report column. The scope is small and the code is obvious to anyone who knows the repo. It still costs an engineer hours of setup and typing: pull the branch, re-read the ticket, find the files, write the change and the test, compile, open the PR.
None of that is judgment, but because each ticket is small it never gets treated as a problem. It gets spread across the team one context switch at a time, and the roadmap work that needs a senior brain waits behind it. Ticket to pull request automation removes that tail. The engineer keeps the one part that matters: reading a finished PR and deciding whether it ships.
A review-ready PR, not a code suggestion
How ticket to pull request automation runs, step by step
n8n orchestrates and holds the queue; GitHub Actions does the coding. Every stage writes its result back to the Linear ticket as a label or state, so the ticket is the audit trail.
Intake
A scheduled poll, capped at ten tickets a day, or a Linear webhook picks up tickets labelled ai-task. Nothing enters without that label.
Triage
A freshness guard drops stale tickets, a clarity check returns vague ones as ai-needs-detail, and a duplicate check tags repeats ai-duplicate. What passes is queued; what should wait is ai-deferred.
Dispatch
One ticket at a time. The dispatcher maps the ticket's project to its repositories and branches and respects a per-repo cap on open AI pull requests.
Work
A GitHub Action clones the repo, plans the change, implements it, reviews its own diff, generates and runs tests, and opens the pull request. The ticket becomes ai-pr-open.
Build gate
The desktop app is compiled on Windows. A red build triggers ai-build-retry: the agent reads the errors, fixes, and rebuilds, for at most two passes. Still red, and the ticket becomes ai-needs-human.
Review and merge
The PR-done callback sets the ticket to AI Review and pings the assigned tester on Teams. A person reads the diff and the tests, then approves, requests changes, or closes it as ai-pr-closed. Only a human merges.
QA and watchdog
Once merged, the ticket moves to QA Review with a tester assigned. Every 30 minutes a watchdog flags anything stuck for more than 60 minutes.
What the AI dev agent is built from: n8n, GitHub Actions, and the coding worker
Orchestration, queueing, state, and notifications live in n8n. The coding runs as short-lived GitHub Actions workers, one per ticket, that borrow a Claude-class coding model through OpenCode and then disappear. State never lives in a chat window; it lives on the ticket.
Why an AI coding agent needs human review and a build gate
An AI coding agent that can merge is a liability. This one cannot. It can open a pull request, and that is the end of its authority. A person reads the diff and the tests the agent wrote, and decides. The agent's self-review is a first filter, not a substitute.
The build gate is the second wall. For a desktop product, code that looks right in a diff and breaks on Windows is worse than no code. So every PR is compiled before a reviewer sees it. Red builds get at most two repair passes; after that the ticket is labelled ai-needs-human and handed to a person. At every earlier stage the same rule applies: when unsure, the agent labels and stops rather than guesses.
What changed once developers reviewed instead of built
Built and running at a US marina-software company, a marina-management product with a .NET desktop application and web repositories. Developers now review instead of build.
Rounded from production data at a US marina-software company, 2025–2026; definitions and measurement notes are on each case study.
Teams with a backlog of clear tickets and a review culture
The agent fits product teams that run their work through Linear and GitHub, ship regularly, and carry a tail of well-specified tickets that experienced people keep doing by hand. It is at its best on repositories with tests in place and a build that runs in CI, including desktop products that need a Windows compile. It does not replace engineers who know the domain; it hands them finished diffs instead of blank branches.
Going in, you need a ticketing tool with labels, a GitHub organisation, and one engineer willing to review. The Automation Audit maps your backlog and repositories, a written Automation Map arrives within 48 hours, and if it fits, a fixed-scope, fixed-price proposal for the first pipeline follows. Scope, guardrails, and the first repository are agreed before a line is written.
Questions CTOs ask about AI dev agents
Does the AI dev agent merge code on its own?
No. The agent can open a pull request and that is where its authority ends. A human reviews the diff and the tests and decides whether it merges. Every merge in the production pipeline has a person behind it.
What happens when the agent gets a ticket it does not understand?
Triage catches it before any code is written. A clarity check labels vague tickets ai-needs-detail so a person can add what is missing, and a duplicate check tags repeats ai-duplicate. The agent only builds what it can read clearly.
How does the build gate work for a desktop application?
Every pull request is compiled on Windows before a reviewer sees it. A red build is labelled ai-build-retry and the agent reads the errors, fixes them, and rebuilds, for at most two passes. If it is still red, the ticket becomes ai-needs-human and a person takes over.
Why use n8n and GitHub Actions instead of a single coding tool?
Because orchestration and coding are different jobs. n8n owns the queue, the state, the notifications, and the watchdog, so the pipeline stays visible and controllable. GitHub Actions runs each ticket as a short-lived worker with the coding model inside it, so nothing persistent needs babysitting and every run leaves a log.
Does the agent test its own changes?
Yes. For every change it generates and runs tests inside the same GitHub Action run, then messages the assignee to review. Combined with the build gate, that is what makes the pull request review-ready rather than a draft.
Related pages
Hand the boilerplate to a machine.
The free Automation Audit maps your backlog, repositories, and review process — and tells you honestly which tickets a system could turn into pull requests. 30 minutes, written Automation Map included.