RedGreen
RedGreen is a JetBrains plugin that turns the IDE into a self-healing runtime.
Core trick
Runs four LLM agents in parallel under different hypothesis prompts, filtering each patch through cross-test and regression gates.
Description
RedGreen is a JetBrains plugin that turns the IDE into a self-healing runtime. When the PyCharm debugger trips a runtime exception, RedGreen races four models in parallel — each steered by a different "hypothesis lens" (null bug? wrong input shape? race condition? config drift?) — to produce a failing test, a patch, and a rationale.
Every candidate has to survive four automated gates before it can reach the developer: Runner (pytest in a Docker sandbox — does the test reproduce the bug and the patch flip it?), Peers (the patch is re-run against every other agent's test — hacks that only pass their own test are filtered out), Regression (the patch runs against the repo's existing test suite — if it fixes the target bug but
breaks an unrelated feature, it's disqualified), and Review (a small LLM picks the most idiomatic survivor based on code-review principles). The winning patch surfaces as a gutter inlay — one click to apply.
Every episode writes to a per-codebase leaderboard. Later episodes read history and bias (hypothesis, model) assignments toward known winners — so the tool gets faster and more accurate the more you use it on the same project.
The problem: every developer loses hours to the inner debug loop. RedGreen compresses that loop to 30 seconds, with three independent layers proving the fix is real before a human has to look at it.
README excerpt
# RedGreen **The IDE catches its own bugs and learns which model to trust.** A JetBrains plugin that, when the debugger trips an exception, races up to 4 models in parallel from a catalog of 12 hypothesis lenses. Every patch has to survive four layers of defense: 1. **Runner** — pytest inside Docker. Did the patch compile and pass a test? 2. **Peers** — cross-validation. Did the patch also pass the *other* agents' tests? 3. **Regression** — the repo's own existing test suite. Did the patch break anything that already worked? 4. **Review** — a quality judge (small LLM call) picks the most idiomatic survivor — rejects "hacks" like literal-value swaps that silence the crash without addressing the cause. Every episode logs to Supabase. A per-codebase leaderboard reweights the agent pool over time — episode 1 shuffles randomly, episode 20 reads history and picks the model that won on *this codebase* first. ## Stack - **Models:** GPT-5 mini (OpenAI), Llama-3.3-70B, Qwen3-32B, DeepSeek-V3.2-fast (Nebius Token Factory) — shuffled across lenses per episode - **Router:** exception-type + frame-keyword scorer (`backend/router.py`) picks the top 4 of 12 hypothesis lenses per episode - **Referee:** pytest inside a Docker sandbox — no mocks - **Judge:** GPT-5 mini again, called once per episode on survivor patches, 12s hard timeout - **Backend:** FastAPI with async background tasks - **Plugin:** JetBrains Platform (Kotlin), target PyCharm 2024.3+; PSI fallback for SyntaxErrors; inlin