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 "whatis 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.
$ 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
Software engineering, done with agents and signed by humans.
Klaro Cards
Project management that reads like a deck of cards, not a spreadsheet.
o=f(i)
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.
$ 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.