Issue to PR
When a bug or task gets filed, an AI agent gathers the context, drafts the code fix, runs the tests, and opens a proposal — for a human to review, never to merge on its own.
Think of an apprentice in a repair shop. A job comes in, the apprentice pulls the file, does the standard prep, and lays the proposed repair out on the bench — then the master mechanic inspects it before anything goes back to the customer. The agent is the apprentice; the pull request is the bench.
The problem, in plain words
An issue gets filed — a bug, a small task. Then it sits. Days pass between 'filed' and 'someone actually looks at it'. And most issues follow patterns your team has fixed a hundred times: update a dependency, calm a flaky test, add a missing log line, document a field nobody documented. Each one still costs an engineer the same ramp-up — read the issue, find the right files, remember the conventions, write the fix, run the tests — before the actual thinking even starts.
What we set up
The agent gets tools to work with your code host (GitHub or GitLab, through MCP tools with tightly scoped access — it can only touch the repositories it has been given). It searches the codebase and recent commits for context, and when the issue came in through monitoring, it reads the trace — the recording of the failing run. Then it drafts the fix as a pull request (a proposed change that must be reviewed before it joins the code), runs the test suite first, and posts a summary explaining what it changed and why. A human reviews and merges, requests changes, or closes. And when the honest fix isn't code at all — a documentation gap, a missing runbook step — the agent says that instead of forcing a code change.
How it works, step by step
- An issue is filed
A bug report, a small task, or an alert coming out of monitoring.
- The agent gathers context
The relevant files, recent commits in the area, and the trace when the issue arrived through an alert.
- It drafts a fix
A small, focused pull request. When code isn't the right answer, it proposes the documentation or runbook change instead.
- Tests run before anyone looks
The test suite runs first, so a red result never lands in a reviewer's queue.
- It explains itself
A summary of what changed and why is attached to the proposal — the reviewer starts with the reasoning, not just the diff.
- A human decides
Review, merge, request changes, or close. Nothing joins your codebase unattended.
What changes for you
Before: routine issues waited days for an engineer's first look, and every fix started from a blank page. After: a credible first attempt is often waiting when the engineer arrives, review starts from a draft, and pull requests trend smaller and easier to review. Issues that were really documentation gaps get named as such early, instead of dragging through engineering. What it won't do: it will not merge its own work — the human review gate is the point, not a limitation — and the gnarly, novel problems still belong to your engineers.