Most small teams have a backlog full of tickets that are almost ready. The title is clear, the description is half there, and nobody has asked the three questions that would let someone start.
Coding agents can help with that backlog. But most of them live in an editor or a chat window. Someone has to open it, paste the ticket in, answer its questions and watch it work. That is a person babysitting a tool, not a tool doing work.
My advice: let the agent start where the work already lives. It should pick up the ticket, ask its questions in the ticket thread, post a spec for someone to approve, and only then open a draft pull request. Each step is small, visible and reviewable.
Why the ticket is the right place
The ticket already has the context: who asked, why, what it links to and what the team said about it. It is where people look when they want to know the status. It is where decisions get recorded.
When an agent works somewhere else, all of that gets split. The questions and answers live in a chat log only one person saw. The reasoning behind the change is in someone's head. A month later, nobody can tell why the code changed.
When the agent works in the ticket, the history stays in one place. Anyone on the team can see what it asked, who answered and what it planned to do.
Step one: ask before you build
A good engineer reads a ticket and asks questions before writing code. An agent should do the same.
The questions should be specific. Not "can you clarify the requirements?" but things like:
- Should this apply to existing records, or only new ones?
- The ticket says "admins." Does that include team owners?
- What should happen if the export is empty?
The agent posts them in the thread and waits. A teammate answers when they have a minute, in the same place they would answer a person. Nobody has to open a separate tool.
This step alone is worth having. Many tickets stall because the questions never get asked. An agent that asks them on day one moves the work forward, even before it writes any code.
Step two: write the spec and get approval
Once the questions are answered, the agent writes a short spec and posts it in the ticket. I would keep the format fixed:
- Summary: what will change, in plain words.
- Files: which parts of the codebase it expects to touch.
- Tests: what it will add or change to prove it works.
- Risks: what could break, and anything it is unsure about.
- Open questions: anything still unclear.
A person reads it and approves it, or replies with changes. This is the cheapest point to catch a misunderstanding. Fixing a sentence in a spec takes a minute. Fixing a pull request built on the wrong idea takes much longer.
I have written before that the spec comes before the code. That is just as true when the coder is an agent.
Step three: open a draft pull request
Only after the spec is approved does the agent write code. It opens the pull request as a draft, so nobody mistakes it for finished work.
The draft should link back to the ticket and the approved spec. It should run the same checks as any other pull request. And it should go to the same reviewers a person's change would go to, based on who owns that part of the code.
The agent does not merge. A person reviews the code, asks for changes or approves it, exactly as they would for a teammate.
Keep control in the thread
People need a way to steer the agent without leaving the ticket. Simple commands in the thread work well: pause this, rerun with this feedback, stop, use a different model, raise or lower the budget.
That keeps every intervention visible. If someone stopped a run, the ticket says so and says who.
Set limits before you start
An agent that runs on its own needs limits that don't depend on someone watching.
I would set:
- A budget per ticket, in tokens or cost, so one confusing ticket can't run up a bill overnight.
- A monthly cap for the team, visible to everyone.
- Draft-only pull requests, enforced by permissions, not by trust.
- Branch protection, so nothing reaches the main branch without review.
- A trigger label, so the agent only picks up tickets someone chose for it.
The label matters more than it looks. It means a person decided this ticket was a good fit. Agents do well on small, clear changes and badly on vague, cross-cutting ones. Choosing tickets on purpose keeps them in the first group. There is more on this in the rules my coding agents work under.
Measure what it actually saves
Track a few things honestly:
- how many tickets reach a merged pull request;
- how long from label to draft pull request;
- how many pull requests are merged without major changes;
- tokens used per merged pull request;
- how often the spec had to be corrected.
If pull requests keep getting rewritten in review, the tickets are too big or the specs are too thin. Fix that before you widen it.
The short version
- Start the agent from the ticket, not a separate window.
- Have it ask specific questions in the thread.
- Have it post a short, fixed-format spec for approval.
- Only then open a draft pull request, reviewed like anyone else's.
- Let people steer it with commands in the thread.
- Set budgets, draft-only permissions and a trigger label before day one.
I built a rough prototype of this flow, Spec to PR. It walks a mock ticket through questions, a teammate's reply, a spec and a draft pull request, step by step. Try the demo. It's a scripted mock: nothing connects to a real ticket system or code host.
Where does your coding agent ask its questions today, and who sees the answers? If you have a setup that works, email me.
#AI #AIAgents #ProductDevelopment #ProductRequirements