Building a Repository-Aware AI Coding Loop in Rust A developer built Loop Engine, an open-source Rust CLI that runs a repository-aware AI coding workflow of plan, edit, verify, review, and reflect against a local codebase. The tool uses OpenRouter for model access, allows a different model per phase, detects build systems like Cargo, Go, npm, and pytest for verification, and uses optimistic concurrency to prevent agents from silently overwriting developer changes. Most AI coding examples stop after generating code. The model receives a prompt, returns a proposed implementation, and the application prints the result. That is useful for experimentation, but it is not a complete engineering workflow. Code is only useful after it has been written to the repository, compiled, tested, and reviewed. I built Loop Engine https://github.com/anggadb/loop-engine to explore a more practical approach: plan → edit → verify → review → reflect Loop Engine is an open-source Rust CLI that runs this workflow against a local repository. It uses OpenRouter for model access and allows a different model to handle each phase. A normal run performs the following steps: The loop only reports completion when: A model cannot complete the workflow merely by returning the word COMPLETE . The engine executes file operations and local verification commands, so predictable behavior matters. Rust gives the project: The engine also uses optimistic concurrency for file updates. An existing file must be read before it can be written. Immediately before writing, the engine confirms that the file still matches the version the agent read. This prevents the agent from silently overwriting a change made by the developer during the run. Clone the repository: git clone https://github.com/anggadb/loop-engine.git cd loop-engine Install the CLI: cargo install --path . --locked Create your local settings: Copy-Item .env.example .env Copy-Item loop-engine.json.example loop-engine.json Add an OpenRouter API key to .env : OPENROUTER API KEY=your-openrouter-key OPENROUTER HTTP REFERER=your-localhost-url OPENROUTER X TITLE=Loop Engine The environment file and local model configuration are excluded from Git. Each phase can use a different OpenRouter model: { "models": { "plan": "openai/gpt-4.1-mini", "implement": "openai/gpt-5.1-codex", "review": "openai/gpt-4.1-mini", "reflect": "openai/gpt-4.1-mini" }, "requests": { "timeout seconds": 600 }, "execution": { "max tool calls": 30, "timeout seconds": 120, "checks": } } For free experimentation, the phase models can be replaced with an available free model: { "models": { "plan": "qwen/qwen3-coder:free", "implement": "qwen/qwen3-coder:free", "review": "qwen/qwen3-coder:free", "reflect": "qwen/qwen3-coder:free" }, "execution": { "max tool calls": 30, "timeout seconds": 120, "checks": } } Free models have stricter rate limits and may be less reliable. The exact list of available models can also change. Before sending repository content to a model, inspect the generated snapshot: loop-engine --repo "C:\projects\my-app" --inspect This command does not load the API key or make an OpenRouter request. The snapshot is bounded and excludes hidden entries, common dependency directories, generated output, symlinks, binary files, and credential-like filenames. It still cannot guarantee that source files contain no sensitive values, so reviewing the snapshot remains important. Loop Engine detects common build systems from files in the target directory: | Repository marker | Verification | |---|---| | Cargo.toml | cargo test | | go.mod | go test ./... | | package.json | Available test , typecheck , and build scripts | | Pytest configuration | python -m pytest | You can preview the selected checks without running them: loop-engine --repo "C:\projects\my-app" --inspect-checks Example output for a Go repository: { "source": "detected", "checks": { "program": "go", "args": "test", "./..." } } Explicit checks override detection: { "execution": { "max tool calls": 30, "timeout seconds": 180, "checks": { "program": "go", "args": "test", "./..." } } } The model cannot invent arbitrary shell commands. It can request verification, but the engine only executes commands resolved from trusted configuration or fixed detection rules. To run the engine against a repository: loop-engine --repo "C:\projects\my-app" --env-file "C:\tools\loop-engine\.env" --config "C:\tools\loop-engine\loop-engine.json" "Remove the deprecated endpoint and update its tests" --iterations 3 During implementation, the coding agent can request these operations: The engine always runs authoritative verification again after the final edit. Exit code 0 means the work passed the completion rules. Exit code 2 means the iteration or tool budget ended before verified completion. Other nonzero codes indicate execution errors. Every run creates a .loop-engine directory inside the target repository: .loop-engine/ run-