AI Jira Coding Agent: From Ticket to Pull Request
- What it is: a self-contained AI Developer agent that pulls a story from a Jira board, writes the implementation, runs it through automated quality gates, and opens a GitHub pull request for a human to merge.
- Why it matters: it is a working demonstration of the house thesis — AI relocates the constraint from writing code to verifying it. The gates and the review are the interesting part, not the code generation.
- Where accountability sits: the agent has none. It supplies capacity. A person authors the acceptance criteria, reviews the pull request, and owns the merge.
- The teaching beat: the first run is designed to fail a gate. The fix is to improve the prompt specification, not to hand-patch the machine's code.
- Stack: Python 3.11+, Jira Cloud REST API v3, an OpenRouter model chain with fallbacks, pytest + coverage + ruff + bandit as gates, the GitHub API for the pull request, and Docker for isolation.
Watch the full run: ticket pulled, code generated, gate failed, prompt spec adapted, pull request opened.
What the AI Jira coding agent does
Most demonstrations of AI coding stop at the moment the model produces code. That is the easy half. The hard half — the half that decides whether an organisation can actually ship the output — is everything that happens after: does it meet the acceptance criteria, does it pass the tests, is it safe, and who is answerable for it once it merges?
This agent runs that whole loop. It pulls a real story from a real Jira board, generates an implementation, subjects it to the same automated quality gates a human developer would face, transitions the ticket through the workflow, comments its own working back onto the issue, and — only once every gate is green — opens a pull request against a GitHub repository. A person then reviews and merges it.
It is built as a reference implementation for the AI-Augmented Scrum approach rather than as a product. Every design decision in it exists to make one of the framework's principles concrete enough to argue with.
How it maps to AI-Augmented Scrum
The AI-Augmented Scrum Guide makes a series of claims about how agents belong inside a Scrum Team. Each one shows up somewhere in this build as a design choice you can point at:
| Guide concept | Where it shows up in this build |
|---|---|
| Agents are capacity, not members | The agent holds no accountability. It writes code; a person owns the merge and answers for the Increment. |
| Separate human and machine lanes | Jira statuses split the work explicitly: To Do → AI Generated → Human Review → Done. |
| Automated quality gates operationalise the Definition of Done | Tests, coverage, lint and security scanning all block a ticket from reaching Done. The DoD stops being a wiki page and becomes an exit code. |
| Humans own acceptance criteria | The acceptance test is human-authored, committed to main, and fixed. The agent must pass it; it cannot negotiate with it. |
| Adaptation means fixing the prompt and context | Run 1 fails a gate. The human edits the prompt specification — not the generated code — and re-runs. Run 2 passes. |
| Verification is the constraint, not generation | The gates and the review are the centre of the demo. Code generation takes seconds and is the least interesting step. |
The workflow: human and machine lanes
The Jira board is where the separation between the two lanes becomes visible to everyone on the team, including people who never read a line of the code. Four statuses, two of them new:
Solid = human lane · Dashed = machine lane
Transitions need to be flexible in both directions. After a failed gate the ticket sits in Human Review, and a re-run has to move it back to AI Generated. A team-managed Scrum project supports this once you allow any status to move to any status. If a transition is missing, the agent prints the transitions that are available so the board can be fixed rather than guessed at.
The lifecycle, step by step
One command runs the whole loop. Here is what happens between pressing enter and a pull request appearing:
The agent fetches the story from Jira Cloud over the REST API, flattens the Atlassian Document Format description into plain text, and reads the human-authored acceptance criteria.
An OpenRouter model chain — primary plus fallbacks — returns source and docs as structured JSON, honouring every constraint in the prompt specification.
The ticket transitions to AI Generated and the agent comments which model produced the code, so the board tells the truth about who did what.
Inside a clean workspace — ideally a container — the code faces the human-authored acceptance test, a coverage floor, a lint check and a security scan.
Pass or fail, the ticket lands in Human Review. On a failure the agent comments which gates broke and why, and stops. It never marks its own homework.
All green, and the agent commits to a branch, opens a PR against main, and drops the link into a Jira comment. The merge button stays human.
The quality gates: a Definition of Done with an exit code
A Definition of Done that lives in a Confluence page is a shared belief. A Definition of Done wired into a gate is a fact. These four run on every generation, and any one of them failing blocks the ticket:
Acceptance tests
A human-authored pytest suite committed to main before the agent ever runs. It encodes the ticket's acceptance criteria and is not negotiable by the model.
Coverage
Enforced at --cov-fail-under=80. Generated code that quietly leaves branches untested does not reach Done on a technicality.
Lint
ruff check holds the generated source to the same standards a human contribution would face. Kept deliberately lenient here so the scripted failure stays a single clean beat.
Security
bandit -r src scans for common insecure patterns. Speed of generation is worthless if it accelerates the arrival of vulnerabilities.
The failure is the point
The demo is rigged to fail — honestly, and on the first run. The seed ticket asks for a calculate_average(numbers) function with three acceptance criteria: the mean of [2, 4, 6] is 4, an empty list returns 0.0 without crashing, and a non-numeric item raises a clear TypeError.
The first prompt specification is deliberately thin. It asks for the arithmetic mean and says nothing about empty lists or type checking. So the agent does exactly what you would expect: it writes sum(numbers) / len(numbers), which is correct, idiomatic, and divides by zero on the second acceptance criterion. The test gate fails. The ticket lands in Human Review with a comment explaining what broke.
The fix isn't to patch the code — it's to give the agent the constraint it was missing.
The human adds two lines to the prompt specification: return 0.0 for an empty list, never divide by zero; raise TypeError on a non-numeric item. Nothing in the generated code is touched by hand. Run 2 regenerates from the improved context, all gates pass, the pull request opens.
This is the whole argument in one loop. Hand-patching the agent's output feels faster and teaches the system nothing — the next ticket makes the same mistake. Improving the specification makes the failure structural rather than incidental. In Scrum terms, the retrospective's action item is a better prompt, not a bug fix.
Architecture and stack
Deliberately small. Nine files, no framework, nothing you cannot read in an afternoon — because the goal is a demonstration people can rebuild, not a platform they have to trust.
- Python 3.11+ with a flat module layout:
config,jira_client,agent,gates,github_client,orchestrator. - Jira Cloud REST API v3 over basic auth with an API token — fetch issue, list transitions, transition, comment.
- OpenRouter model chain with automatic fallback, matching the pattern used across the rest of the agent network.
- pytest, pytest-cov, ruff, bandit as the four gates, each invoked as a subprocess returning a pass/fail and its output.
- GitHub API for branch creation, file commits and the pull request — with graceful handling when a PR already exists.
- Docker for isolation, with secrets injected via
--env-filerather than baked into the image.
The GitHub step is optional. Skip it and the core loop still runs end to end — it just stops at "gates green, ready for review" instead of opening a real pull request.
Security discipline
The gates execute code a language model wrote. For a seeded demo the risk is low, but the habit matters more than the risk, so the build assumes container isolation by default and treats every credential as disposable.
- Every key — OpenRouter, Jira, GitHub — is created fresh for the run and rotated or deleted the moment it is finished with.
- The GitHub token is fine-grained and scoped to a single repository, with write permission on contents and pull requests only. Nothing more.
- Secrets live in
.env,.envlives in.gitignore, and no code path in the agent ever prints a token. - Generated code executes inside a container, so a bad generation cannot reach the host filesystem.
- If you record the run, frame-check the final cut before publishing — scrub for tokens, credentials and account screens.
None of this is specific to AI agents. It is ordinary key hygiene. It is worth stating plainly because agentic workflows multiply the number of credentials in play and make it easy to lose track of which ones are still live.
What this agent is not
Being clear about the limits is what makes the demonstration honest:
- It is not autonomous delivery. Every run ends at a pull request awaiting a human. That boundary is the design, not a missing feature.
- It is not a product. It handles one ticket, one function, one repository. Real backlogs bring ambiguity, cross-cutting changes and legacy context that this loop does not attempt.
- It does not judge quality. The gates check what can be automated. Whether the solution is the right one for the user is still a human call, and always will be.
- It does not remove the need for craft. Someone has to write the acceptance test well. A weak test lets bad code through the gate — the agent will happily satisfy a low bar.
Built by: Ayush Bisht
Ayush Bisht is a Content Engineer and AI Tools Specialist at AgileWoW. He built and instrumented the agent described on this page, including the Jira integration, the model chain and the quality gate harness.
Want to run this pattern on your own board?
AgileWoW runs AI Training for Scrum Masters and AI Training for Product Owners, led by Sanjay Saini, Professional Scrum Trainer (Scrum.org). We also help teams stand up human and machine lanes, automated quality gates, and the governance around them. Reach out on any channel below.
Frequently asked questions
It is an AI Developer agent that reads a story straight from a Jira board, generates an implementation from the ticket's acceptance criteria, runs that code through automated quality gates, and opens a pull request once every gate is green. The agent moves the ticket through the workflow itself and comments on what it did — but a human reviews and merges. The agent supplies capacity; the person keeps the accountability.
No. In AI-Augmented Scrum, agents are capacity, not team members. The agent writes code; a human authors the acceptance criteria, reviews the pull request, and owns the merge. Accountability for the Increment stays with the Developers, because accountability cannot be delegated to a tool.
Through the Jira Cloud REST API v3, using an Atlassian API token over basic auth. It fetches the issue, flattens the Atlassian Document Format description into plain text for the prompt, checks the available workflow transitions before moving the ticket, and posts a comment back to the issue at each stage of the run.
Four checks that operationalise the Definition of Done: a human-authored acceptance test run by pytest, a coverage threshold enforced at 80%, a ruff lint check, and a bandit security scan. If any gate fails, the ticket cannot reach Done. The gates are what make the agent's output trustworthy — because verification is the constraint, not generation.
The first prompt spec is deliberately thin — it omits the empty-list and type-checking rules, so the agent writes a naive mean calculation that fails the acceptance test. The point is the fix. The human doesn't hand-patch the generated code; they add the missing constraint to the prompt spec and re-run. Adapting the context rather than the output is what makes AI-augmented delivery repeatable.
Run it in a container. The gates execute code the model wrote, so the agent ships with a Dockerfile and expects secrets to be passed in through an env file rather than baked into the image. Every credential should be least-privilege, kept out of version control, and rotated as soon as the work is finished.
A team-managed Scrum project with four statuses: To Do, AI Generated, Human Review, Done. The middle two are the split between the machine lane and the human lane. Transitions need to be flexible enough for a ticket to move back from Human Review to AI Generated, because that's the path a re-run takes after a failed gate.