Work

RepoWarden

Autonomous code review and refactoring agents

In developmentGitHub

Python · LangGraph · LangChain · FastAPI · MongoDB · React 19 · Vite · Monaco

The problem

An LLM agent that can review and refactor a codebase is only as safe as its prompt, unless something structural stops it from writing changes it hasn’t been authorized to make. Prompt instructions can be argued with; a missing tool can’t.

The approach

A two-agent system built as two compiled LangGraph StateGraphs behind a FastAPI backend. Roughly ten custom tools span directory listing, file reads, code search, and dedicated security, performance and code-quality analysers, all operating over a sandboxed filesystem layer. Results stream token-by-token over Server-Sent Events as structured events — tool calls, analysis results, proposed edits — and MongoDB backs both a LangGraph checkpointer for thread-scoped conversation state and a custom store for cross-session project memory, so nothing needs to be replayed from the client.

Reviewer StateGraphList dirRead fileCode searchSecurity checkPerf checkQuality checkPropose editWrite file — not boundHumanauthorizationproposed editsapprovedEditor StateGraphconstructed only after the gate aboveList dirRead fileCode searchWrite fileNothing is written to disk until the gate is passed.

The interesting decision

Capability-based agent isolation. The Reviewer agent’s toolset structurally omits the write tool — it cannot modify the workspace regardless of how it’s prompted, because the capability simply isn’t bound to it. Nothing is written to disk until a human approves the proposed changes; only then is a separate, write-capable Editor agent constructed and granted the write tool. Safety is enforced through tool binding, not through instructions telling the model what not to do.

What I’d do differently

The evaluation is currently a pytest suite run against a fixture directory of deliberately flawed code — solid for regression coverage, but narrower than real-world repository diversity. Broadening it against a wider range of real open-source codebases, and adding a diff-review surface in the UI rather than relying on structured edit proposals alone, are the two next steps that would matter most.