RevEngine sits between a proposed code change and the person deciding whether to merge it. It runs as a GitHub Action: a maintainer requests a review, a language model reads the repository, and the Action returns comments and advice. It does not merge the change. The surrounding software—the harness—chooses what the model can read, how findings are checked and which comments reach the contributor.
That last part is becoming the interesting story. In an October 20 change, RevEngine’s developer described an awkward loop: the reviewer kept raising project-fit concerns after a maintainer had answered them. The advice still asked for a decision. Another patch documented the opposite failure: duplicate suppression hid a new problem because an older comment occupied overlapping lines.
A reviewer can find more issues and still spend human attention badly. RevEngine’s public implementation makes that tradeoff inspectable—and increasingly configurable.
A review has a memory problem.
Follow the same pull request through three situations. An earlier answer should survive another review; a different defect should still get through.
First review: the model raises a project-fit question. A maintainer still needs to answer it.
The code may work, but accepting it would add a responsibility the project has not agreed to carry.
The question remains open. A model cannot supply the missing project decision.
Keep the project-fit question separate from the list of technical defects.
When the maintainer answers, a later review should carry that answer forward unless the change has moved beyond it. When a different defect appears near an old comment, the new finding should remain reportable. Closing a thread alone does not establish that the code is fixed.
Schematic based on the October 20 fit-answer change and duplicate-comment correction. These are explanatory situations, not a recorded review or measured time savings.
Headlong brought the review problem home.
In the October 19 launch post, Nick Jalbert traces RevEngine to outside contributions arriving after Laude released Headlong, its persistent-agent harness. For a small research team, checking whether each contribution worked, belonged and introduced risks competed with the research itself. That is Laude’s account of the pressure behind the tool.
The resulting project is Apache-licensed and can run in a repository’s own GitHub workflow. Its useful distinction is control over review policy. A team can inspect the prompts, choose the model, set comment thresholds and encode its design expectations in versioned documents. The model service remains a separate dependency; open harness code does not make the model local.
This is also a concrete reason to write down a project’s scope. A reviewer can search for a defect in code. Deciding whether a new capability belongs requires some account of what the project is trying to be.
The model reads beyond the patch. The program controls the report.
The review instructions tell the model to understand the system, trace callers and inspect tests before submitting findings. Separate lenses cover correctness, compatibility, security, completeness and maintenance. The software supplies file, search and diff-reading tools. It does not give the reviewer a general shell for executing the contribution.
Project instructions come from the base revision—the code before the proposed change—so a contribution cannot replace the rules used to judge itself. The pull request’s title, description and code are explicitly treated as material to examine. Those instructions help define the trust boundary; they do not establish immunity to prompt injection.
A second model pass assesses proposed findings. The implementation then handles verdicts, removes duplicates and ranks surviving findings by severity and model-reported confidence. That confidence is a model’s assessment, not a calibrated probability.
The word “verify” needs care here. This is code reading, not a reproduced failure or executed test. The orchestration can skip verification when time runs short and preserves unverified findings if that pass fails. Default lenient handling also keeps uncertain findings. A posted comment is therefore a claim for a maintainer to inspect.
Finally, a separate fit assessment asks whether the contribution belongs within the project’s stated purpose and maintenance obligations. It runs after the findings and cannot rewrite their list. It can change the displayed merge advice. This assessment is on by default in the GitHub Action, but requires a configured model in a bare-container invocation; it can be skipped if its remaining budget is insufficient.
Remember the answer without declaring the code innocent.
The October 20 work makes a review a continuing conversation. RevEngine collects decisions by people with write or administrator access on the same pull request and passes them into later reviews. It distinguishes a finding rejected as wrong from one deferred, marked fixed or partly fixed, or marked resolved. This is bounded history for one contribution, not a model learning a repository’s preferences permanently.
The first implementation needed an almost immediate correction. A follow-up commit nine minutes later says resolved threads had been treated like incorrect findings, potentially silencing problems that remained in the code. Under the revised rules, a fixed, partly fixed or resolved concern can return when inspection finds it still present. A concern declined or deferred needs a relevant change to justify raising it again.
Fit answers received their own memory. The later patch carries forward up to three rounds of maintainer answers. It addresses a different failure from missing a bug: repeatedly asking someone to authorize a direction they already authorized.
Meanwhile, comment suppression became more selective. Overlapping lines alone had hidden a different medium-severity defect behind an older, fixed issue. The patch compares content as well as location and exempts resolved or decided threads from that suppression.
These corrections expose the actual engineering question. Silence can mean a respected decision, a repaired defect or a missed problem. Counting fewer comments cannot distinguish them. RevEngine’s history collection is also best-effort: a collection failure leaves the next review without those earlier decisions.
A strong detection result has a specific denominator.
The public ReviewBench results checked October 21 put RevEngine first on the displayed grounded-F1 comparison. Its reported full run covered 219 pull requests over three rounds: 59.6% grounded F1, 83.6% grounded precision and 46.3% grounded recall. Mean successful review invocation took about three minutes. The result belongs to the registered image built from commit b7d795c, not all subsequent versions.
“Grounded” is consequential. The benchmark methodology excludes unmatched findings from both sides of the grounded-precision calculation. The 83.6% figure does not mean that 83.6% of every comment the tool produces is correct. Recall concerns known issues in the benchmark’s reference set, which cannot contain every possible defect. Neither metric measures minutes of maintainer attention.
Laude’s smaller experiment is useful for a different decision: how to spend on the model and harness together. On 25 pull requests, it reports these results:
| Model | Diff-only call | Full harness |
|---|---|---|
| Opus 5.5 | 47.7% · $0.22 | 58.7% · $0.91 |
| Sonnet 5.5 | 44.1% · $0.12 | 57.8% · $0.45 |
The comparison makes Sonnet worth testing within this workflow. It does not establish full-benchmark parity. Those 25 PRs were also the documented tuning subset, and the harness comparison adds repository access, rules, checking and more inference together. It cannot identify which component caused the gain. Token cost also excludes setup, infrastructure and the human work of evaluating the review.
There are inspectable alternatives. Block’s Apache-licensed review tool uses parallel lenses, a coordinator that challenges findings and a different-model judge that can restore mistaken rejections. It runs through a shell-capable Goose workflow with a different execution boundary. RevEngine’s attraction is not exclusive ownership of second-pass checking; it is the particular combination of restricted reading, project-specific judgment and configurable reporting.
Test whether the next round gets easier.
The current Action requires an OpenRouter key and a GitHub token able to post reviews. A person with write or administrator access can request a review with /review; forks are skipped unless enabled. Its defaults select up to ten medium-or-higher findings for comments; findings outside the diff appear in the summary, and remaining findings go into a collapsed section. Those choices determine how much of the model’s thoroughness occupies the conversation.
A useful trial would include more than the first pass. Pick a handful of already-understood pull requests, record which findings matter, record a fit answer in the supported review-evaluation format, then ask for another review after a change. Ordinary conversational replies need not be collected as fit answers. Check whether the answer survives, the fixed concern disappears and a different problem remains visible. Track accepted fixes and review minutes alongside false alarms and missed defects. This is a proposed evaluation, not one we ran for this article.
RevEngine’s own evaluation documentation is moving in that direction. It separates who reported a finding from who judged it, and tests severity, fit, merge advice and known false positives. It explicitly asks for missed findings from human reviews, fix commits and other tools: a test set built only from the reviewer’s own discoveries cannot establish what it misses.
The next result worth watching is whether this makes real review rounds shorter without letting defects escape. Laude says it is still collecting that evidence. The source already establishes something useful: review quality depends on how software carries human decisions forward, as well as how well a model reads a diff.
Source inspection is pinned to RevEngine commit 88b722f5, October 21, 2026. Scripted upstream tests for findings, review orchestration, comments, decisions, fit and prior history passed locally. We did not run a live model review, reproduce the benchmark or measure production review savings.
