From issue to pull request: automating the dev workflow with AI

The distance between "here is a bug" and "here is the fix, reviewed and merged" is where most engineering time actually goes. Not in the typing, but in the surrounding work: reproducing the issue, finding the relevant code, understanding it, making the change, running the tests, fixing what broke, and writing it up for review. Automating the journey from issue to pull request is the clearest, most concrete thing an autonomous AI engineering agent does. This article walks through that journey step by step.

It starts with an issue, not a prompt

The first shift is the input. A coding assistant waits for you to be in the editor and tell it what to write. An agent starts from the same place your team already starts: an issue. A bug report with a stack trace, a feature request with acceptance criteria, an alert from your monitoring tool. The agent takes that artifact as its goal, which means it slots into your existing workflow instead of demanding a new one.

This matters because the issue is where intent lives. A well-written issue already contains what needs to happen and how you will know it worked. The agent reads it the way a human engineer picking up the ticket would.

Reproduce and locate

Before changing anything, the agent has to understand the problem. For a bug, that means reproducing it: running the failing path, confirming the symptom, and pinning down where in the code it originates. For a feature, it means locating the right place to build and understanding how the surrounding system works.

This investigation stage is unglamorous and essential. A change made without understanding the system is how you fix one bug and introduce two. A capable agent spends real effort here, reading across files, tracing data flow, and building a model of the relevant slice of the codebase before it touches a line.

Make the change

Now the agent writes. Because it has a plan and an understanding of the system, the edit is coherent: it touches the handler, the helper, the config, and the tests together, keeping the change consistent rather than scattering disconnected fragments. The change is scoped to the issue, not an excuse to rewrite half the module, which keeps it reviewable.

Scope discipline is underrated. A focused diff that does exactly what the issue asked is fast to review and safe to merge. A sprawling change that "also cleaned up a few things" is where review fatigue and hidden regressions creep in. A good agent stays on task.

Test and iterate

Code that has not been run is a hypothesis. The agent runs the existing suite to catch regressions and adds tests for the new behavior, then reads the results. A failure is not the end; it is the next input. The agent adjusts, runs again, and repeats until the suite is green and the new behavior is covered.

This iteration is where the agent does work that humans find tedious and time-consuming. Reading a stack trace, forming a hypothesis, tweaking, and rerunning is slow for a person and fast for an agent. By the time the work is done, it has already passed through several rounds of self-correction.

Verify against the original issue

Green tests are necessary but not sufficient. The agent steps back to the issue and checks: does this actually resolve what was reported? Does the fix address the root cause or just the symptom? Does the feature meet the acceptance criteria as written? This verification against intent is what keeps the agent from technically passing while practically failing.

Open the pull request

Finally, the agent opens a pull request, and this is deliberately where it stops and hands off. The PR is scoped, tested, and accompanied by a description of what changed and why, with a reference back to the issue it resolves. A human reviews and approves the merge. Everything up to this point was reversible and ran autonomously; the merge is not, so a person signs off.

The result is that the human's involvement is concentrated at the highest-leverage point: reading a clean, coherent change and deciding whether it ships. They are spared the reproduction, the search, the iteration, and the write-up, and they keep the decision that actually matters.

And then it watches

The workflow does not truly end at merge. After deploy, the agent watches production for regressions tied to the change. If something goes wrong, that signal becomes the next issue, and the loop begins again. The path from issue to pull request is one lap of a larger cycle that keeps running.

When you run more than one of these at a time, watching them matters. Desktop tools like DevMesh show every agent's progress from issue to pull request on a live kanban board, so you can steer or pause without losing the thread.

Conclusion

Automating the journey from issue to pull request is the most tangible value an autonomous engineering agent delivers. It takes the work your team already tracks, reproduces and locates the problem, makes a focused change, iterates against real tests, verifies against the original intent, and hands you a clean PR to review, then watches production after it ships. The mechanical journey is automated; the judgment stays with you.

Aion runs this exact path, from issue to reviewed pull request and into production monitoring, with human approval at the merge. See it in action at aionagent.app.