From GitHub Issue to Pull Request with AI Coding Agents

Handing GitHub issues to an AI coding agent is one of the most practical ways to use one: the work is already written down, scoped, and tracked. It is also where teams lose control fastest, because an issue that is clear enough for a colleague is often not clear enough for an agent, and the agent will not ask. This guide walks through the workflow from issue to merged pull request and what to get right at each step.

Pick issues an agent can finish

Agents do best on work that is well-defined, local, and checkable. Good first candidates:

• bug fixes with a clear reproduction;
• small features that follow a pattern already in the codebase ("add a filter like the existing status filter");
• dependency upgrades with a test suite to catch breakage;
• adding tests for existing, untested code;
• refactors with a mechanical rule ("replace every call to the deprecated helper").

Poor candidates are issues that need a product decision, span several services, depend on context that lives only in someone's head, or cannot be verified by running anything. Those are better split, clarified, or kept by a person.

Write the issue for the agent

The agent reads the issue literally. The fastest way to improve results is a short template:

## Problem
Exporting a report with more than 10,000 rows times out.

## Expected
The export finishes and downloads, for any number of rows.

## Acceptance criteria
- Exports of 50,000 rows complete in under 30 seconds locally
- Existing export tests still pass; add one for a large export

## Pointers
- Export logic: app/Reports/CsvExporter.php
- Similar streaming code: app/Invoices/InvoiceDownload.php

## Out of scope
- Changing the export format
- The PDF exporter

The two sections that matter most are acceptance criteria, which tell the agent — and the reviewer — what "done" means, and out of scope, which stops the agent from "improving" things nobody asked it to touch.

Trigger work with a label

Use a dedicated label, such as ai-task, to hand an issue to the agent. Labels are visible, easy to remove, and recorded in the issue's history. Keep two rules:

• Only people on the team should be able to apply it — on GitHub, applying labels needs at least triage access.
• Re-applying the label to an issue that already has work in progress should not start a second, competing run.

Review the plan before the code

Before writing anything, the agent should produce a plan: the steps, the files it expects to change, the commands that will verify the work, the risk, and how to roll back. Reading it takes a minute. Check three things:

• Did it understand the issue? The plan's summary should match what you meant, not just what you wrote.
• Is the blast radius right? A fix to one exporter should not plan changes to shared base classes.
• Will the checks prove it? If the plan does not include a test that would fail without the change, ask for one.

If something is off, send it back with instructions rather than rejecting it outright. "Do not change the base class; stream rows in CsvExporter only" usually produces a good second plan.

Execute on a branch, one step at a time

The agent should work on a fresh branch created from the default branch, never on the default branch itself, and commit each step separately with a message that says which step it was. Small, ordered commits make the eventual review easier and make it possible to see exactly where something went wrong. Only one run should work on a repository at a time, so two agents never fight over the same files.

Validate before the pull request exists

Run the repository's own install, lint, typecheck, test, and build commands after each step, in an isolated environment, and only open the pull request once everything passes. We cover the setup in detail in How to validate AI-generated code before merging.

Open a pull request a reviewer can trust

An agent's pull request should explain itself better than a human's, because the reviewer cannot ask the author what they were thinking. A good description has:

• a summary linked to the issue;
• what changed, step by step;
• which validation commands ran, and their result;
• a testing checklist for the reviewer;
• how to roll the change back;
• a link to the full history: the plan, who approved it, and every check.

Then review it like any other pull request — our review checklist for AI-generated pull requests covers what to look for. A person merges; the agent never does.

Measure whether it is working

After a few weeks, look at the numbers per repository: how many agent pull requests were merged, how many review comments they needed, how many were reverted, and which kinds of issues failed. That tells you which issues to keep handing to agents and which to write better — or keep for people.

How Dualzo handles this

Dualzo runs this whole workflow: label an issue (or write a prompt), review the plan in email or chat, and get a validated pull request with all the sections above, linked to an append-only audit trail. See how Dualzo turns GitHub issues into pull requests.