I Built an AI That Turns GitHub Issues Into Pull Requests - No Local Setup Required
DEV Community

I Built an AI That Turns GitHub Issues Into Pull Requests - No Local Setup Required

What I Built

resolvo is an agentic pipeline that takes a GitHub issue and a repo URL and hands you back a working pull request - with tests already passing and a review already done.

The "passion" here isn't a stretch for me - it's the actual origin story. I kept losing weekend hours to the same loop: read an issue, dig through an unfamiliar codebase to find the right files, write the fix, write tests, second-guess the diff, open the PR. I love writing code, I don't love being the API glue between "here's a bug" and "here's a merge."

So I built a system that treats that whole loop as a multi-agent job: explore the repo, plan the change like a senior engineer would, implement it, test it in a sandbox, review it adversarially, and only then open the PR.

It's less "AI writes your code for you" and more "AI does the tedious 80% around your code with the same rigor a careful human would" - this solution cuts issue turnaround time by 85% by allowing anyone to resolve lightweight bugs. The goal is to democratize basic maintenance and remove bottlenecks. It's built for modern, fast-moving teams that need to keep their senior talent focused on high-impact projects.

How I Built It

resolvo is built on LangGraph, structured as a StateGraph with a fairly deep multi-agent pipeline:

GitHub Issue + Repo URL
โ”‚
โ–ผ
PreClassifier โ†’ fast intent/confidence check before expensive work
โ”‚
โ”Œโ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”
ExploreLite ExploreFull โ†’ tree-sitter parse, symbol graph, architecture summary
โ””โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”˜
โ”‚
PlannerAgent โ†’ enrichment โ†’ BM25 + Cohere rerank retrieval โ†’ plan
โ”‚
โ”Œโ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”
FastTrack Standard / Critical
โ”‚โ”‚
ReviewLite Implement โ†’ Test โ†’ Review โ”€โ”€(retry / human)โ”€โ”€โ”
โ”‚โ”‚ โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜โ—„โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
โ”‚
GeneratePRMeta โ†’ GitHub PR

A few decisions I'm most proud of:

  • Routing by confidence, not by default. A PreClassifier decides how deep exploration needs to go, and the PlannerAgent chooses one of three pipeline paths - fast_track, standard, or critical - so a one-line typo fix doesn't pay the same cost as a cross-module refactor.

  • Splitting reasoning work by strength, not by convenience. I used Gemini Flash models for the two critical steps that need the most contextual judgment - final implementation planning and adversarial code review - while Google's lite models handle enrichment, per-file implementation, and test generation. Same model ecosystem, different reasoning depth for different stakes: the adversarial reviewer gets full diffs, test results, and pre-check findings; the lite reviewer (used on the fast track) gets diff summaries only. That tiering is really the heart of the "diff reasoning modes" idea - cheap, fast reasoning where the risk is low, deep reasoning where it isn't.

  • Grounding, not just guessing. I wired Grounding with Google Search into the Gemini calls so planning and review aren't limited to whatever the model memorized during training. When a fix depends on something that moves - a library's current API surface, a framework's latest breaking change, a security advisory - Gemini pulls in live web results instead of confidently proposing a fix built on a deprecated signature. That distinction matters for a code-fixing agent specifically: a plan built on stale knowledge doesn't fail loudly, it fails silently until the test run catches it.

  • Real execution, not vibes. Tests run inside an E2B sandbox against a real shallow clone of the repo, with pytest-json-report parsed back into structured results - so "the fix works" is a fact, not an LLM's opinion.

  • Retrieval that isn't just embeddings. The planner fuses five signals - raw-issue BM25, enriched-query BM25, Cohere rerank-v4.0, symbol-name matching, and one-hop dependency expansion - via Reciprocal Rank Fusion before Gemini ever sees a prompt, so the plan is grounded in the actual dependency graph of the repo, not just semantic similarity.

Prize Categories

Best Use of Google AI - Gemini Flash powers the two highest-stakes reasoning steps in the pipeline (final implementation planning and adversarial code review), deliberately reserved for the moments where deeper reasoning matters most, while lighter-weight models handle the rest of the pipeline. On top of that, Grounding with Google Search is wired into those Gemini calls so the model can reason against current, real-world information - up-to-date library APIs, framework changes, advisories - rather than relying solely on training-time knowledge.

Comments

No comments yet. Start the discussion.