Coding agents can produce useful software quickly. The engineering problem is deciding when their work is safe to trust. Ratchetloop is the control system I built around that problem.
task → isolated coder → checks → scoped commit → independent review → result.json → human mergeWhat It Does
Give Ratchetloop a bounded change or an idea. A coding agent works in an isolated Git worktree. Deterministic checks judge the resulting tree. Ratchetloop commits only the verified paths, then asks a reviewer from a different model family to judge the diff. The result is a branch and a run record, not an automatic merge.
The public snapshot validates Grok, Codex, and Claude providers and includes the source, tests, contract, example task and idea files, model policy, CI, and pinned-runtime deployment scripts.
Controls That Matter
- Isolation: each run gets its own worktree; worker Git transport is disabled.
- Scope enforcement: HEAD, Git metadata, and changed paths are checked before commit.
- Deterministic gates: task-defined commands must exit successfully before review.
- Independent review: reviewer and coder must come from different model families.
- Bounded review: at most two rounds; the second is a fix-check, not an endless debate.
- Crash recovery: branch, worktree, events, and result files are the resumable state.
- Evidence: run records capture disposition, usage, cost when available, changed lines, test additions, findings, and wall time.
- Human promotion: Ratchetloop never merges, pushes, or deploys the target repository.
Why I Built It
The design is a response to failure modes I hit in earlier AI-delivery systems: blocked reviewers being misread as approval, empty checks passing, workers touching the wrong checkout, process groups outliving a run, environment leakage, unbounded review loops, and cost data that could not be reconstructed later. The public failure-mode record maps those problems to explicit controls.
Used in Practice
leetcode-python is a compact public consumer: ten representative algorithm implementations produced through Ratchetloop, then validated with focused unit tests, deterministic reference oracles, independent review, and CI.
The same pipeline pattern is used across private software work where the task shape is suitable: bounded change, explicit acceptance criteria, executable checks, independent review, and a human-owned promotion decision.
Design Position
Ratchetloop is deliberately small: one Python CLI, files and Git for state, no database, no daemon, and no workflow-engine dependency. More machinery is justified only when the workflow actually requires branching, parallel joins, live scheduling, or another demonstrated need.
Public repository · AI engineering methodology · Public work sample
Generated output stats available on request.