How to give coding agents a backlog they can execute
A coding agent working from a good issue produces a reviewable pull request. The same agent working from "improve the export flow" produces a confident pull request that improves the wrong thing. The difference is never the agent; it is whether the issue could be executed by someone with no access to the hallway conversations behind it.
That is a higher bar than most backlogs meet, because human engineers paper over vague tickets by asking questions. Agents mostly don't — they fill gaps with plausible assumptions and keep going. An executable backlog is one where the assumptions are already written down. Here is how to build one.
“export fails on big workspaces”
“CSV export times out for us”
“exports broken since Tuesday”
a coding agent
PR openedreviewed by a human1. Start from evidence, not from ideas
An issue an agent can execute starts with the problem as customers actually stated it. Before anything else, the raw material has to exist in one place: the Slack thread where three customers described the bug, the Zendesk tickets, the sales call where the prospect explained what "export" means to them. If that material is scattered, fix intake first — feedback aggregation is the prerequisite, and deduping matters doubly here, because an agent handed two tickets that are secretly the same request will build two overlapping fixes.
Disclosure where it's relevant: we build Modem, which automates this step — it captures and dedupes feedback across channels, files issues with the customer evidence attached, and exposes that context to agents over MCP so Claude Code or Cursor can pull the "why" while working the ticket. What the agent queries is a context graph — topics, customers, and quotes linked across sources — so getting the full picture costs one MCP call, not a re-read of every source thread. We compared that landscape in the best MCP servers for customer feedback. You can also do this step by hand; it just has to be done.
2. Write the issue as a contract, not a reminder
A human's ticket is often a note-to-self. An agent's ticket is a contract, and the parts that matter are the ones teams habitually skip:
- The problem, with a real quote. "Acme's ops lead: 'we re-enter this data into our billing system every Friday'" constrains the solution space in a way "users want export" does not.
- Reproduction or current behavior. What happens now, concretely, with the steps.
- Acceptance criteria. Observable statements a reviewer can check: "a CSV downloads containing the filtered rows; columns match the table view; empty states export headers only."
- Explicit non-goals. Agents over-deliver by default. "No XLSX, no scheduled exports, don't touch the PDF path" saves a reviewer from a 2,000-line diff.
- Pointers into the code. The relevant module or a similar past PR, so the agent doesn't rediscover your architecture from scratch.
Surveys of how agents fail point at the same root: agents lose or lack context across large tasks and fill the gaps badly — see the survey of agentic programming challenges and VentureBeat on brittle context windows. The issue body is where you supply what the context window won't find on its own.
3. Slice to one context window per issue
The most practical sizing rule in circulation comes from Backlog.md, a tool for human-agent backlogs: one task, one context window, one PR. If an issue needs the agent to hold the whole payments system in mind, it is an epic wearing a ticket's clothes — decompose it, and put the sequencing in the parent.
A useful test before assigning: could a competent contractor, hired this morning with repo access and this issue, start without a meeting? If not, the issue is not done being written. This also means "investigate why sync is slow" and "make export fast" are not agent tickets — spikes and open-ended performance work still need a human to convert findings into contracts first.
4. Route deliberately — not everything goes to an agent
An executable backlog still needs a routing decision per issue. Good agent candidates: well-reproduced bugs, small features in established patterns, test coverage, migrations with clear mechanical rules. Keep for humans: anything touching auth or billing without close review, architectural choices, and work where the acceptance criteria can't be written because the team hasn't decided what it wants — that last category is a deciding problem, not a building problem, and we've argued elsewhere that deciding is now the bottleneck.
Which issues deserve agent capacity at all is the prioritization layer above this guide — evidence-ranked, not loudest-first — because cheap execution makes building the wrong thing cheaper too.
5. Budget for review, and close the loop
Every agent PR gets a human review, and review becomes the constraint once agents multiply your diff volume — engineering leaders have been writing about review as the new bottleneck since agents arrived. Two things keep it manageable: the non-goals from step 2 (small diffs) and the acceptance criteria (the reviewer checks a list, not a vibe).
When the PR merges, the issue's requester list is what lets you tell the customers who asked — the step that makes the whole pipeline visible to the people funding it. Mechanics at close the loop.
The smallest version this week
Don't rewrite the backlog. Pick three real issues, rewrite them to the step-2 contract — quote, current behavior, acceptance criteria, non-goals, code pointer — and hand them to whatever agent your team already runs. Compare those three PRs to the agent's usual output. The rewrite takes ten minutes per issue, and it's the cheapest way to find out whether your bottleneck is the agent or the backlog.
