The Ticket Is the Prompt Now

On 31 July, Jira Automation gained GitHub Copilot, Cursor and Claude as native action steps — coding agents sitting in the rule builder alongside "transition issue" and "send email."

Read that as a plumbing change and you'll miss it. What it removes is a person. A rule can now take a ticket the moment it's created and hand it to something that writes code, with nobody reading it in between (Fig. 1).

Which makes a question that used to be a matter of team etiquette into a matter of pipeline configuration: what, exactly, is in the ticket?

The asymmetry

Hand a junior engineer a ticket that says "fix login bug — see Slack thread," and something useful happens. They come back and ask what you meant.

That question is the system working. It costs ninety seconds and it arrives before any code exists — the ambiguity gets resolved at the point where resolving it is nearly free.

Hand the same ticket to an agent and you get no question. You get a pull request: well-formatted, confidently reasoned, and quite possibly wrong in a way that takes twenty minutes of reading to notice.

The ambiguity didn't go anywhere. It moved — from a ninety-second conversation before the work to a code review after it (Fig. 2).

Not because the agent is worse than the junior. Because it's optimised differently. It produces a plausible completion, and "I need more information" is rarely the most plausible completion. Faced with a gap, it fills the gap — reasonably, invisibly, and without marking which parts were your specification and which were its inference.

That's the expensive property, and it's worth being precise about it. The output doesn't come labelled. A reviewer can't separate "this is what we asked for" from "this is what it assumed we meant," so they have to reconstruct the intent from scratch in order to review against it. That reconstruction is the cost, and it scales with how much the agent had to invent.

Watch it narrow

Same bug, same agent, one field at a time (Fig. 3).

Nothing about the model changed between the first state and the last. The only variable was how much the ticket left to invention.

The claim, and the one I'm not making

Not claiming: that structured tickets make agent output reliable. They don't. A perfectly specified ticket can still produce wrong code, because a model can be wrong about things you specified correctly. Specification is not correctness.

Claiming: that structured tickets make agent output reviewable, which is different and more achievable. A reviewer holding explicit acceptance criteria is checking a diff against a list. A reviewer without them is inferring what the author probably wanted and then judging code against that guess. The second job is strictly harder, and it's the one most reviewers currently have.

There's related industry data — Sonar's State of Code survey of 1,100+ developers, published in January, found 96% don't fully trust AI-generated code while only 48% always verify it, and 38% say reviewing it takes more effort than reviewing a colleague's work. I'll cite that for the existence of a review-cost problem and no further. Nobody asked those developers about their backlog, so it doesn't establish that thin tickets are the cause. Any post telling you it does is borrowing authority it hasn't earned.

And the ROI is a hypothesis, not a finding. Structure costs real minutes to write. I haven't seen a study establishing that review time saved exceeds authoring time spent, and I'm not going to imply one exists. If you want to know for your team, the experiment is small: take one recurring class of work, write half the tickets to a four-field standard and half the way you write them now, and track review round-trips for a sprint. That's a real number about your codebase, which beats my argument about codebases in general.

Where it actually breaks

Everyone reading this already knew what a good ticket looks like. That was never the problem.

The problem is sprint planning at 4pm with thirty-eight tickets left, where the fourth field on the ninth ticket is where the discipline quietly dies (Fig. 4). "Write better tickets" has been failing teams for two decades for exactly that reason — it's a throughput problem misdiagnosed as a knowledge problem.

Which is the modest argument for templating. Most of what goes into a well-structured ticket is repeated: the same acceptance-criteria skeleton, the same constraint boilerplate, the same out-of-scope defaults for a given component. That isn't creative work, it's transcription — and transcription is where good intentions go to die.

Generate the repeated structure in bulk; spend your actual attention on the one or two fields genuinely specific to this piece of work. Which is what SuperTemplates does, and the reason it matters more this quarter than last is simply that Atlassian just wired the output of your ticket form to something that writes code.

Your tickets used to be notes for your colleagues. They're now also the specification an agent builds against — and increasingly, nobody reads them in between.

Same words. Considerably more weight.