# I Built an AI That Turns GitHub Issues Into Pull Requests — No Local Setup Required > Source: > Published: 2026-07-13 03:05:00+00:00 *This is a submission for *[Weekend Challenge: Passion Edition](https://dev.to/challenges/weekend-2026-07-09) ## 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](https://drive.google.com/file/d/10i-YiVGiO4Ed25_T5tF5hNb3T2FExDei/view?usp=drive_link) ## Code ### 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: 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.