How I built an agentic workflow that turns Jira tickets into pull requests
A working agentic development workflow that turns Jira tickets into reviewed pull requests, using Cursor agents for the boilerplate while a human approves every plan.
Most of my week used to run on the same loop. Pick up a Jira ticket, read the acceptance criteria, work out what it means, write the React components, add the tests, open a PR, wait for review. Then do it again.
All of that work has to happen. A decent chunk of it is mechanical though, and that’s the part that started to bother me. Wiring up a form, following conventions the team settled on months ago, writing the baseline test coverage that every change needs. It’s necessary work that quietly eats the hours I’d rather spend on the ambiguous requirements, the edge cases nobody wrote down, and the architectural calls that are actually hard.
So I built something to handle the repeatable parts, with one rule: I approve the plan before any code gets written. What follows is how that agentic development workflow is put together, and where I decided the human still has to sit.
What the pipeline actually does
It’s a local web UI called ai-automation-app that orchestrates an agentic workflow against the project codebase, and it connects three systems I already use every day:
- Jira Cloud, as the source of truth for tasks
- Cursor SDK, which runs the AI agents locally inside the project repo
- GitHub, for the branch, commit, push and pull request
Tickets go through one at a time, in a fixed sequence:
- Jira fetch – load the ticket details and description
- Context – I add implementation notes, so design decisions, gotchas, links
- Plan – a developer agent proposes an approach and the list of files it wants to change
- Approve – I approve, or reject with feedback and the agent revises until I’m happy
- Implement – the agent writes production code on a new branch
- QA – a separate QA agent writes Vitest tests against the changed files
- Quality gate – linting and tests run, and a failure kicks off a debug loop that retries up to three times
- Commit and PR – commit, push, open a PR against dev, and drop the PR link back on the Jira ticket as a comment
The approval step at number four is the whole design. Everything before it is preparation and everything after it is execution, and the one decision that determines whether the output is any good sits in the middle with a human making it.
Everything before step four is preparation and everything after it is execution. The one decision that determines whether the output is any good sits in the middle, with a human making it.
Why three agents instead of one
I didn’t want a single general-purpose agent trying to hold every job in its head at once, so the pipeline splits the work across three roles:
- Senior frontend dev – plans and implements against project conventions
- QA tester – writes co-located Vitest tests with React Testing Library and MSW
- Commit summariser – generates a concise commit message from the diff
Each one runs with its working directory set to the local project checkout, and I watch the output in real time through the run log and stage stepper in the UI. Splitting the roles also means the QA agent comes at the changed files without the developer agent’s assumptions about what the code was supposed to do, which catches things a single agent tends to talk itself past.
How it handles features
The plan review is where I add the most value on new feature work.
The agent reads the Jira description alongside whatever context I’ve added, which is usually something like “reuse the existing modal pattern from settings” or “this touches the Zustand store, not local state”. Tickets almost never carry that kind of intent on their own. Then I look at the proposed approach and the file list before a single line gets written, and if the direction is wrong I reject it with feedback rather than letting it write code I’m going to throw away.
Once the plan is approved, implementation runs against the project’s real stack: React 19, Vite, TanStack Router and Query, HeroUI, Tailwind 4 and Zustand. The agent follows a set of project rules the team defined, so what comes out matches how we already write code instead of arriving in some generic house style that then needs translating. That’s the same discipline we apply when coding with an AI assistant on client work.
How it handles bugfixes
Same flow, usually faster.
Bug tickets tend to point at a specific area already, and my context narrows it further with something like “regression since the auth refactor” or “only happens on mobile viewport”. The QA agent then writes tests that cover the fix and guard against the regression coming back, which is the step I’m most likely to rush when I’m doing it by hand and under pressure.
The agents draft and I direct.
What I deliberately kept for myself
The workflow was never meant to be fire and forget, and four steps always come back to me:
- Injecting context. Jira tickets rarely capture full intent, and my notes close that gap.
- Approving the plan. Architecture and scope decisions stay with me.
- Reviewing the PR. The pipeline opens it, then I read the diff, run manual checks and merge.
- Edge cases and judgement calls. Agents handle the happy path well, while subtle bugs, UX nuance and anything cross-cutting still need a human looking at it.
That division of labour is the point of the whole thing. The agents draft and I direct.
What changed
Since I started running feature and bugfix work through this, the time from picking up a ticket to having a PR ready for review has dropped a long way. The boilerplate implementation and the baseline test writing happen in the background now, while I’m in a design discussion or working on something that needs more thought.
The friction around engineering judgement is what’s gone. The judgement itself is still mine, and it now gets more of my day than it used to. Worth noting that speed on its own is a poor scorecard here, which is something we’ve written about in the AI productivity paradox.
If you’re working on a mature codebase with consistent conventions and a steady stream of Jira-driven work, something like this is worth building. The value comes from keeping humans in the loop at the points where the decisions are hard, and getting them out of the loop everywhere the work is just typing. If you want a hand designing that for your own team, our agile delivery and product teams do this inside client codebases every week, and you can always talk to us about where to start.
Frequently asked questions
What is an agentic development workflow?
An agentic development workflow uses AI agents to carry out multi-step engineering tasks, rather than answering one prompt at a time. In this pipeline the agents read a Jira ticket, propose an implementation plan, write the code and tests, then open a pull request, with a human approving the plan before any code is written.
Can AI agents write production code safely?
They can when the workflow has gates around them. This pipeline requires human plan approval before implementation, runs linting and automated tests before anything is committed, and still puts every change through normal human PR review before it merges.
What is the difference between an AI coding assistant and an agentic pipeline?
An assistant responds to prompts inside your editor while you drive. An agentic pipeline runs a defined sequence of steps end to end, so it fetches the ticket, plans, implements, tests and raises the PR, pausing at the points where a human decision is needed.
Why use separate agents for development and QA?
A separate QA agent evaluates the changed files without carrying the developer agent’s assumptions about what the code was meant to do. That separation catches issues a single agent working on both jobs tends to miss.
What kind of codebase does this work best on?
Mature codebases with consistent conventions and a steady flow of well-described tickets. The agents follow documented project rules, so the clearer those conventions are, the more reliable the output.
Related articles
Real outcomes, for real Australian organisations.
How we built AI-powered personalisation and retail media for one of Australia’s largest supermarket chains.