The Ticket-to-PR Agent: Which Half of the Job It Does Well
The split wasn't by difficulty — some intricate tickets went fine and some trivial ones went badly. One question predicts it, and acting on it improves something other than your agent.
A team wired an agent to their issue tracker: pick up a ticket, produce a pull request. Within weeks it was handling a real share of the queue, and the pattern in what it handled well was sharp enough to be predictive.
The split wasn't by difficulty. Some of what it did well was genuinely intricate; some of what it did badly was trivial. The split was by how completely the ticket specified the work.
What it handled well
Tickets with a worked example. "When status is cancelled, the total should exclude shipping — see order 8821 for a case that's currently wrong." Concrete input, concrete expected output, verifiable.
Tickets naming the location. "In billing/reconcile.py, the FX rounding uses banker's rounding; it should match the ledger's half-up." Nothing to discover.
Repetitive changes with an existing precedent. "Add the same rate-limit decorator to the six endpoints in admin/." One example in the codebase and the rest follows.
Anything with a failing test attached. The strongest signal available. A reproduction converts the whole task into iterating against an oracle, which is the shape agents are best at.
What it handled badly
Tickets describing a symptom. "Checkout is sometimes slow for enterprise customers." The work is investigation — forming hypotheses, checking them, narrowing. The agent produced plausible optimizations to code that wasn't the bottleneck, which is worse than nothing because it looks like progress.
Tickets with an implied scope. "Clean up the notification service." Everyone on the team knew this meant three specific things and explicitly not the fourth. That understanding was nowhere in the ticket.
Anything requiring a product decision. "Users are confused by the export dialog." Whether to relabel, restructure, or remove is a decision, and the agent made one silently.
Tickets whose premise was wrong. Someone reported a bug that wasn't a bug — the behavior was intentional and documented elsewhere. A human would have pushed back. The agent changed the behavior.
⚠️ That last category is the one to watch. Agents are strongly inclined to accept the framing they're given, so a wrong ticket becomes a confident wrong change rather than a question.
The predictor, and what to do with it
The pattern reduces to: can someone unfamiliar with the team's unwritten context do this ticket correctly from the ticket alone? If yes, the agent probably can. If no, the agent will produce something plausible and wrong.
Which makes the practical intervention obvious and slightly annoying: the leverage is in ticket quality, not in the agent.
✅ Route by ticket, not by difficulty. Tag which tickets are agent-eligible during triage — a few seconds of judgment per ticket that saves reviewing plausible wrong work.
✅ Make eligibility a checklist, not a vibe: expected behavior stated concretely, location identified or discoverable, scope bounded explicitly, no product decision embedded, and ideally a failing test.
✅ Have the agent write the reproduction first. For anything bug-shaped, requiring a failing test before a fix converts investigation tasks into oracle-driven ones — and if it can't produce the reproduction, that's a clean, early signal it should escalate.
✅ Let it decline. "This ticket doesn't specify X, which changes the correct implementation" is the most valuable output it can produce on an underspecified ticket, and it only happens if declining is an available and rewarded action.
💡 The second-order effect nobody expected
Ticket quality across the team improved, because badly specified tickets now failed visibly and quickly rather than being absorbed by an engineer who quietly filled the gaps from context.
That absorption was invisible work — and valuable, and it was hiding a systemic problem with how work was specified. Making it visible was uncomfortable and useful, in that order.
The takeaway
Ticket-to-PR works in proportion to how completely the ticket specifies the work, not to how hard the work is. Triage for agent-eligibility with an explicit checklist, require a failing reproduction before any bug fix, and make declining an underspecified ticket a first-class outcome. Then expect the real finding: a large share of your tickets were never specifications at all, and the humans were quietly making up the difference.