Which Tickets Should You Give an AI Coding Agent?

Every agent demo uses a fresh repository and a well-behaved task. Real backlogs are not that. They contain tickets written by different people at different times, some of them vague, against a codebase with years of accumulated decisions that were never written down.

This article is about triage: which of those tickets an agent handles well, which it handles badly, and how to tell them apart before you find out the expensive way. We are describing the failure modes these tools consistently exhibit and how to design around them — not publishing measurements from a controlled trial.

The triage rule

The single most useful filter is this: could you hand this ticket to a competent contractor who knows nothing about your company, and expect a correct result?

That question captures almost everything that matters. A contractor with no context needs the acceptance criteria written down, needs the affected area to be verifiable, and cannot make decisions about what your product should do. Those are exactly the three conditions under which an agent performs well.

Ticket shape	Give it to an agent?	Why
Add a field end to end — migration, type, form, test	Yes	Mechanical, verifiable, clear finish line
Rename a concept across many files	Yes	Tedious, well-defined, easy to review as a pattern
Convert a module from callbacks to promises	Yes	Local, mechanical, existing tests constrain it
Fix a validation rule with a stated expected behaviour	Yes	Acceptance criteria are unambiguous
Change behaviour that spans two or more subsystems	Usually not	Review cost exceeds the writing cost
"Improve the onboarding flow"	No	An unmade product decision wearing a ticket's clothes
Anything touching auth, billing or data deletion	No	Failure is expensive and tests rarely cover the edges

What agents are genuinely good at

Mechanical work with a clear finish line. The value is not that an agent does it better than you — it is that it does it without getting bored, which is where humans introduce errors on the fortieth file of a rename.

They are also consistently thorough at pull request descriptions and commit messages, which is a small thing that makes review meaningfully faster. Every changed file gets mentioned; the reasoning is spelled out. Most human pull requests are not written that carefully.

That same fluency is a trap, which is the next section.

The failure mode that matters most: ambiguity becomes a decision

Give a human developer a ticket where the intended behaviour is genuinely unclear and they will usually reply asking which behaviour you want. Give the same ticket to an agent and it will pick an interpretation, implement it confidently, and write a description that presents its choice as though it had been specified.

A junior developer who is unsure asks. An agent that is unsure commits. That difference is the entire risk profile.

This is manageable once you know it happens. Adding an explicit instruction to ambiguous tickets — "if the expected behaviour is unclear, stop and ask rather than choosing" — generally works. But agents do not do it unprompted, and the tickets where it matters most are the ones nobody realised were ambiguous. The more durable fix is upstream: a ticket that would need that instruction is a ticket that is not ready.

The second failure mode: green tests read as proof

An agent that changes behaviour, runs the suite, and sees green will report that nothing behavioural changed. The suite is green because the behaviour it changed had no test.

// a change of exactly this shape is easy to make and easy to miss
- if (user.plan === "trial" && daysLeft <= 0) return blocked();
+ if (user.plan === "trial" && daysLeft < 0) return blocked();
// tests: all passing. also: trials no longer expire on their final day.

A human might make the same edit. But a human who touched an expiry condition would usually feel a flicker of doubt and go looking for the test. An agent feels nothing, finds green, and writes "no behavioural change expected" — a sentence that is simultaneously honest and wrong.

The practical defence is to treat coverage as a gate rather than a nice-to-have: if the area a ticket touches has no meaningful tests, either write them first or do the work yourself.

Where the time actually goes

Review, and this is the number most productivity claims quietly omit.

On simple tickets, reviewing an agent's pull request is faster than writing the code. On complex ones it is slower, because you are reconstructing intent from a diff rather than holding it in your head as you write. Reading unfamiliar code is a different and harder task than writing familiar code, and a large diff you did not author is unfamiliar code by definition.

A workable heuristic for the crossover: more than two files you have not read recently. Above that line, doing it yourself is usually faster, and the gap widens with the complexity of the change rather than its size.

How to measure it honestly on your own team

If you want to know whether an agent is helping rather than whether it feels like it is helping, track four things for two weeks:

• Tickets assigned, and their shape against the triage table above.
• Outcome per ticket: merged with minor changes, needed substantial rework, or abandoned.
• Review minutes, timed rather than estimated. This is the number everyone skips and the one that decides the answer.
• Rework minutes, counted against the agent rather than against whoever fixed it.

Then compare the total against your honest estimate of writing the same tickets yourself. Two patterns are worth watching for. First, the merge rate will look better than the time saving, because merges are visible and review time is not. Second, the abandoned tickets are usually the most informative: an agent that abandons three tickets in a fortnight has typically identified three places where your team had not actually decided what the product should do.

A working policy

• Give it well-specified, well-tested, locally-scoped tickets, and nothing else.
• Add an explicit instruction to stop and ask when a specification is ambiguous — and treat needing that instruction as a signal the ticket is not ready.
• Require existing test coverage around the area being changed, or write it first.
• Review the diff, not the description. The description reflects intent; only the diff reflects behaviour.
• Keep anything with an unmade product decision inside it out of the queue entirely.
• Keep auth, billing and data deletion off the list regardless of how well specified the ticket looks.

Used that way, a coding agent is a genuine help — roughly equivalent to a fast contractor with no context and no judgement, available at any hour and never bored. That is a real and useful thing to have on a team. It is also a considerably narrower thing than the demos are selling, and the gap between the two is where most disappointment with these tools comes from. Choosing which assistant to point at those tickets is a separate question — we compared two of them here.