# Revu – Code review in times of AI > Source: > Published: 2026-11-11 17:39:48+00:00 ## Want a code review? We read agent-written and vibe-coded codebases for a living, and leave you with the harness as well as the report. Revu is the tool we do it with — free, open source, yours. `npm install -g @enspirit/revu` ## The job changed under us A year ago the work was writing software. Today a growing part of it is answering a harder question about software somebody else's agent already wrote: *is this safe to run?* The projects arriving at our door have a shape in common. A founder with no engineering background has vibe-coded a product that demos beautifully and now holds real customer data. A team has shipped in three weeks what would have taken six months and cannot say which parts are load-bearing. A codebase has a hundred green tests, none of which fail when you break the business rule on purpose. Every time, we are handed a repository **nobody on our side wrote**, that no one person ever held in their head. That is the new job, and it is not going away: read code you did not write and did not watch being written, well enough to put your name on it — then leave a harness behind, so the next thousand agent-written lines cannot quietly break what matters. ## Review by diff is dead Code review as practised for fifteen years rests on three assumptions: the change is *small*, the author is a *colleague* who can explain their reasoning, and both of you know the *base*. All three are now false. - **The diff is the whole repository.** Six hundred files in an afternoon is a normal day for an agent. A three-hundred-file pull request is not a review, it is a wall. - **The author cannot be questioned.** An agent will explain anything you like, fluently, after the fact. The explanation is generated, not remembered — so asking does not converge. - **You do not know the base.** What you need is not "what changed" but "what*is* here, and where do I look first". ## "The agents will review it" is a dead end The tempting answer is to point a second agent at the first one's output. We tried, repeatedly. It fails for reasons that have nothing to do with how good the models get. - **A generated review is more text to read.** You end up reviewing the review, and that text is optimised for sounding thorough. The pile grows; the understanding does not. - **Accountability cannot be delegated.** Asked whether a system can go in front of customers, you owe a signature, not a probability. Signing what nobody has read is the problem we are hired to fix — it cannot also be the method. - **The decisive judgements are not in the repository.** Whether the code does the right thing for the business, whether a risk is acceptable, whether this is even the system the client needs — none of it can be read off the source, at any model size. So humans will look at the code. The open question is *with what* — and our honest answer was: nothing built for this. We were reading agent-written repositories in an editor, keeping the map in our heads, and writing feedback into a chat window that lost it by morning. AI writes, humans validate — but only while validating stays **cheaper** than writing. Every tool we build is measured against that inequality. Agents stay excellent at the part they are genuinely good at: *pointing*. Run the linter, the type checker, the grep for a rule your project decided on. An instrument, not a judge — which is exactly how Revu uses them. ## So we built Revu **A reading surface for code you did not write.** Point it at a repository, read it in your browser, say things about specific lines, and get back **one markdown text** for whoever writes the next change — a colleague, or the agent. ### Scopes, not a file tree A tree of six hundred files is not a question anybody has. The left panel is a list of *scopes*: sets of files that share a property, entered one at a time, stacking as you go. Pick one, read what is in it, say things about the lines that deserve it. | The last commit | what the agent just did, before you lose track of it | | On this branch | everything it has that `main` does not | | Changed, not committed | the working tree, right now | | Longest documents | the verbose markdown an agent turns out by the bucket | | Largest sources | files that have grown past reading | | No test names it | where the green suite is not actually looking | | Named nowhere else | written, then forgotten: nothing so much as mentions them | | Unlinked documents · Uncited decisions | prose and records nothing points at | | Broken links · Left for later | drift, and what was postponed | | Moving most | where the churn has been, these N days | Each one is a cheap, honest signal. None of them claims a defect; they claim a place to look. You declare which your project offers, and on what numbers, in a small `.revu.yml` — what counts as a large file is a question about your project, not about our tool. And anything that prints a location becomes a scope of its own: ``` scopes: - use: largest min: 400 # your call, not ours - title: Lint run: npm run --silent lint -- --format=compact || true - title: Says deploy, not publish run: git grep -n -i deploy -- '*.md' ``` Output is read in the format every tool already speaks: `path:line: message`, tsc's `path(line,col): message`, or a bare path. Lines naming a file the project does not have are dropped, so banners and stack frames fall away on their own. ### An agent can write that file Which linter, which coverage report, which thresholds — that is a reading job, so hand it over. `revu --skill` prints the instructions: find the harness rather than guess it, prefer the project's own task names, *run every command before writing it down*, take the numbers from this codebase's own distribution of file lengths, and report what was skipped and why. ``` bash $ mkdir -p .claude/skills/revu-setup $ revu --skill > .claude/skills/revu-setup/SKILL.md ``` ### Remarks that come back as requirements Click a line number, press `c`, say what should change. Each remark is anchored to its lines, quotes them, and carries a tag — `must-fix`, `question`, `scope`. The export is one markdown document, addressed to whoever writes next, opening with the only instruction that matters: *treat a remark as the requirement, not as a suggestion to paraphrase back.* ### What it refuses to do It **never writes to the project under review** — remarks live outside it, so a review can span days without touching a branch. And there is **no AI inside Revu**, deliberately. The judgement is the product; the tool's job is to make reading cheap enough that the judgement actually happens. About two thousand lines, three dependencies, no build step. A tool, not a platform. ## Where it comes from We build with agents every day, and we have the scar tissue. [o=f(i)](https://ofi.dev) — a formula as a service, where a small program answers at a URL — is largely agent-written, specification first, and reviewing it is what made the gap obvious. [Klaro Cards](https://klaro.cards), our project-management product, is where the same practices meet years of history and real customers. Revu was built in a day out of that frustration, and the first thing we did was point it at itself — which is how the remark in the screenshot was written. ### [Enspirit](https://enspirit.dev) Software engineering, done with agents and signed by humans. ### [Klaro Cards](https://klaro.cards) Project management that reads like a deck of cards, not a spreadsheet. ### [o=f(i)](https://ofi.dev) A formula as a service. You publish a calculation; it answers at a URL. ## Use it, or ask us to Revu is **open source** under the MIT licence. It runs locally, binds to `127.0.0.1`, and sends nothing anywhere. ``` bash $ npm install -g @enspirit/revu $ revu ~/code/the-project-you-inherited ``` That is the whole installation. It opens in your browser on `127.0.0.1:7777`; with no path it reads the directory you are standing in. ## Want a code review? That is our day job. We review vibe-coded products before they meet real users, put test and deployment harnesses around agent-built codebases, and hand back the harness as well as the report — not just an opinion. Tell us what you have inherited. If Revu is useful to you and you would like the open-source work to continue, you can [sponsor Enspirit on GitHub](https://github.com/sponsors/enspirit). Issues and pull requests are welcome on [the repository](https://github.com/enspirit/revu); the thing we most want to hear about is the scope you wished existed while reading somebody else's code.