AsyncReview

The trait that decides it is how little there is to set up. One command with a pull request URL and a question, and you have a review, with no application to install on your organisation and nobody new granted access to anything. For evaluating a review agent at all, that is the shortest path on this board.

It is also a very small project, so expect the rough edges of one. Pick it to answer a specific question about a specific change. Pick cubic when you want continuous coverage without thinking about it.

The confinement is a function call. Generated code runs in a read-evaluate loop where certain calls are caught and translated into repository requests, which is elegant and is not a security boundary in the sense that a container is. No process separation, no resource limits and no capability list appear in the documentation.

What it does right is staying out of your tree. It reads through the hosting platform's interface rather than cloning into your working directory, so nothing it does can disturb work in progress.

1. This is the right architecture for the failure everyone complains about, which is a reviewer inventing a method that does not exist. Because retrieval happens through executed calls, a citation is a value the run obtained, not a token the model produced.

2. Recursion also lets a finding be checked before it is reported, which single-pass reviewers cannot do. 3. No precision measurement is published: no false-positive rate, no comparison set, and no accounting of how many iterations a typical review consumes.

Review is the most contested segment on this board and this entry has no revenue, no hosted offering and no distribution beyond a repository. The engineering idea is better than the commercial position by a wide margin, which is a pattern that usually ends with the idea appearing inside somebody else's product.

Moat: none. Likely path: the recursive verification approach gets adopted by a funded reviewer while this remains a reference implementation. Position: use it, learn from it, and expect to be buying the same idea from someone else within a year.

Zero licence cost and a pipeline-capable run mode is a good starting position, and running it in our own automation means no third party is granted access to the organisation.

The credentials are the conversation. It needs a model provider key and, for anything private, a token with read access to our repositories, both of which live in whatever runs it. That is a secrets-management design, not a checkbox, and there is no console giving me visibility of where those keys ended up. Approved with conditions: short-lived tokens, one repository, and rotation on a schedule.

The permissive licence and the zero-install invocation are exactly right for a tool I want to try on somebody else's repository from a machine I do not own. The source is small enough to read in an evening, which is the real test.

Then the model layer disappoints. One provider's key is the documented credential and the row records no alternative, so I cannot route this at a cheaper model or at my own endpoint without editing the source. The licence says I may, and that is the only reason this does not score lower.