Welcome to the show - I'm Lachlan Reed with James Turner,
and James, I love this because it sounds like autocomplete,
but it's really not.
You type /ultrareview, and instead of some little in-editor nudge,
it kicks off multiple reviewer agents in parallel up in the cloud.
Then you just...
keep coding.
Open other commands.
Go make a coffee.
Apparently you can even close the terminal while it's still chewing through
your branch, which feels a bit like leaving a team of very judgmental
interns alone in your workshop.
The "close the terminal" part is the token that changes
it for me.
If I can shut the terminal and the review keeps running,
that is NOT the same category as a chatbot hovering over my shoulder.
That's a job queue.
That's basically saying, "we sent your code to a cloud review pipeline;
come back in five to ten minutes."Exactly.
And the entry points are dead simple.
/ultrareview with no arguments reviews your current git branch.
Easy as.
Or /ultrareview followed by a PR number targets a specific GitHub pull
request before merge.
So one version is, "check what I've been hacking on locally," and the
other is, "have a proper squiz at PR 214 before this thing lands."[responds
quickly] Wait - PR number, not a full link?
That's interesting, because it makes the pull request feel like a first-class
object, not just text you pasted in.
And the branch mode versus PR mode matters too.
A branch review is like catching dumb mistakes before you show anyone.
A PR review is more like, "okay,
this is entering the blast radius."Yeah,
and the bigger idea is trust.
If one model reads your diff once,
you're getting one first impression.
Maybe brilliant, maybe half asleep,
maybe obsessed with a variable name.
But if /ultrareview is spinning up multiple reviewer agents in parallel,
each coming at it from different angles - logic,
edge cases, security, performance - then it's a multi-pass review.
Different lenses.
Different failure modes.
That's a very different beast. Or - and this is my pushback
- it's just more expensive linting with nicer packaging.
Because "multiple agents in parallel" sounds impressive,
but if I still wait five to ten minutes and get back a polished list
of things my linter or test suite should've caught,
then cool, you built a cloud chandelier over a flashlight.A
cloud chandelier is harsh...
but fair.
I think that's the tension here.
Is this actually better code review,
or is it fancy linting with a longer queue?
Because if it's just style nags in a trench coat,
I'm out.
But if it genuinely finds the weird branch interaction,
the missed auth check, the performance footgun - stuff a single pass
might miss - then five minutes starts sounding pretty cheap.
And that's
the thing I'm listening for: not "did it say something," but "did multiple
parallel reviewers produce something I'd trust more than one model's vibe?"
Because those are very different promises.
So here's the mechanism that
matters most: findings are independently reproduced and verified before
they appear.
That wording is doing a lot of work.
The system is trying to surface confirmed issues,
not speculative warnings.
Not "hey, maybe there's a bug?" but "we checked,
and this actually reproduces."The word
reproduced
is HUGE there.
Reproduced means it's not just one model having a funny feeling.
It's the difference between your mate saying,
"that bike sounds crook," and another mechanic actually riding it,
hearing the same knock, and pointing to the loose bit.
Different level of confidence entirely.
Right.
In a normal single-agent flow,
one model can just go off the rails.
It can miss a real bug.
It can fixate on style.
It can hallucinate a problem because a pattern looked suspicious.
/ultrareview is trying to reduce that by having agents specialize and
then cross-check.
So instead of one pass that's broad and a little flaky,
you've got multiple passes with some internal skepticism built in.
Let
me try to explain it back.
A standard one-shot review is like asking one very smart dev
to skim the diff after lunch.
Maybe they spot the nasty edge case,
maybe they don't, maybe they spend ten minutes on tabs versus spaces.
Ultrareview is more like sending the same diff to a little committee
- one looking for logic gaps, another for security weirdness,
another for performance traps - and then only surfacing stuff that survives
the committee scrap.
Is that close?
Pretty close.
The key add-on is that the five-to-ten-minute runtime makes the cloud
part real.
This is deliberately a background task,
not conversational back-and-forth inside the editor.
You don't sit there nudging it like,
"what about line 48?" You launch it,
it goes off and does heavy work,
and it returns later.
And I actually like that separation.
When a tool replies instantly,
I start treating it like a mate on chat.
Handy, but a bit casual.
A five-minute background run says,
"nah, this is a process." It asks you to use it on the bits that matter.
See,
I half-agree.
"Verified findings" definitely changes confidence.
But it can also hide uncertainty behind a cleaner interface.
Because all verification systems still have thresholds,
judgments, edge cases.
Just because the output looks polished doesn't mean the messy uncertainty
vanished.
It might just be better concealed.
That's a good shove.
You're saying the phrase confirmed issues can make people lower their
guard too much.
Exactly.
"Confirmed" is powerful language.
I'm not saying it's fake - I'm saying developers might hear confirmed
and mentally skip review.
And that would be a mistake.
Higher confidence?
Sure.
Final authority?
No chance.
Yeah.
So maybe the real win isn't certainty.
Maybe it's better triage.
If the thing comes back with fewer,
more solid findings, that saves me from drowning in speculative nonsense.
That alone feels different from a single AI pass spraying warnings everywhere.