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

Krishna Khandelwal — Mon, 13 Jul 2026 03:05:00 +0000

This is a submission for Weekend Challenge: Passion Edition

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.

Demo

Demo Video

Code

KKhandelwal1733 / resolvo

Agentic pipeline that turns a GitHub issue into a tested pull request — no local clone required. Built with LangGraph.

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.

DEV Community: Krishna Khandelwal