AI PR Automation: The Git Workflow Around Your Coding Agents

When an agent works directly on main — or on one long-lived branch shared with you — its changes mix into yours with no boundary. You lose the ability to review a coherent unit, to run CI against just that change, or to revert it cleanly when it turns out wrong.

A PR per story restores all three. The diff maps to one intention, CI verdicts attach to one change, and git revert undoes one story instead of an afternoon. It also unlocks parallelism: PRs from isolated worktree branches can land in any order. This is the difference between using agents casually and engineering with them.

The objection is overhead — and for hand-made PRs it's real. The whole point of AI PR automation is that branching, pushing, describing, and pre-reviewing cost you nothing. The PR stops being ceremony and becomes the cheapest safety boundary in the workflow.

Here is the pipeline as AIDEN runs it — each step also works standalone with plain git and gh if you assemble it yourself.

1. 1

   Branch per story, named from the story

   When you approve a spec, AIDEN creates a worktree and branch named after the story slug (e.g. feature/csv-export). Predictable names make in-flight work legible: branch list equals story list, no mystery branches.
2. 2

   Commit hygiene by convention

   The agent commits as it works — small commits with imperative messages scoped to the story. Best-effort, not enforced by git itself, but agents follow the convention reliably when the spec states it, and it makes the PR's history skimmable.
3. 3

   PR description generated from the spec

   On completion, AIDEN opens the PR with the approved spec as its description: scope, acceptance criteria, exclusions. The reviewer gets the intention, not a paraphrase of the diff. See spec-driven development for why this framing matters.
4. 4

   LLM review pass before human review

   An optional model pass reads the diff against the spec and flags deviations, dead code, and suspect logic as comments. It's a filter, not a verdict — it makes your review faster, it doesn't replace it.
5. 5

   CI as the arbiter

   Your existing pipeline — tests, types, lint — runs on the PR like on any human branch. Agents can run tests locally and iterate before pushing, but CI is the neutral referee both you and the agent answer to.
6. 6

   Human review and merge

   You read the spec, then the diff, then decide: merge, request changes, or reject and re-spec. This step is deliberately not automated.

GitHub's Copilot coding agent runs an adjacent version of this loop in the cloud — assign an issue, get a PR back. The trade-offs against a local-first setup are covered in our Copilot coding agent comparison.

Review is the bottleneck in any agent workflow, so tactics matter. The goal is not to read less code — it's to read it with a frame of reference so judgment is fast.

The same honesty applies to the pipeline's soft steps: agents running tests, clean commit history, and the LLM review pass are conventions that work well, not guarantees. The hard guarantees in this workflow are git's — branch isolation and the approval gate before implementation. Build on those; treat the rest as strong defaults.

In AIDEN, this whole pipeline is the last step of the story loop inside an agentic IDE: story, spec approval, isolated implementation, one-click PR with review pass. Scaling it across several simultaneous agents is covered in the spec-driven development guide and the multi-agent workflow guide.