RepairLoop

RepairLoop introduces the Runtime Repair Loop (RRL), a local-first AI-assisted engine that detects runtime failures, proposes safe repairs, verifies recovery, and keeps developers in control.

Comment

RepairLoop

RepairLoop introduces the Runtime Repair Loop (RRL), a local-first software reliability workflow that detects execution failures, proposes safe repairs, and verifies recovery automatically.

RepairLoop is a local-first runtime repair engine for Python that helps developers recover from execution failures safely and automatically.

Instead of generating an entirely new project, RepairLoop focuses on what happens after code fails to run. It detects runtime failures, analyzes common error patterns, proposes controlled repairs, and verifies whether the program can execute successfully again.

We call this workflow the Runtime Repair Loop (RRL):

Run
  ↓
Capture Error
  ↓
Diagnose
  ↓
Repair
  ↓
Verify

Inspiration

Modern AI coding assistants generate code quickly, but developers still spend significant time fixing runtime failures. I wanted to build a tool that focuses on reliability after code generation rather than replacing developers.

How it works

  • Detects runtime failures
  • Analyzes error messages
  • Applies safe repair strategies
  • Verifies the repaired program
  • Generates structured reports

Built with

  • Python
  • CLI
  • Rule-based repair engine
  • Local-first architecture

Future

RepairLoop aims to evolve into a general Runtime Repair Loop platform for AI-generated and traditional software.

Build Week Contribution: Verified Repair Benchmarks

During OpenAI Build Week, GPT-5.6 was used as an engineering assistant to audit RepairLoop's existing local-first architecture, identify the gap between the benchmark plan and runnable evaluation, and implement a new Verified Repair Benchmark Framework.

This contribution is deliberately separate from RepairLoop's pre-existing repair engine. It adds a repair-loop benchmark command that runs each fixture in an isolated temporary copy, applies only existing safe repair rules, reruns the original failing command, and emits versioned JSON metrics for verification status, repair time, expected versus observed repair kind, and file-level patch size.

GPT-5.6 accelerated the engineering workflow by helping turn the benchmark design into a narrow, backward-compatible implementation: deterministic no-network fixtures, machine-readable assertions, regression tests, and a clearer demo. The key product decision was to measure verified recovery, not just whether a repair suggestion looks plausible.

The first benchmark suite covers three deterministic recovery paths: missing local configuration files, a missing Python syntax colon, and a missing SQLite users table. The final validation completed with 33 tests passing and 3/3 benchmark cases passed and verified. The original RepairLoop core remains local-first, rule-driven, and safe by default; this extension makes its reliability claims reproducible.

Built With

Share this project:

Updates