Use case
PR review against a running stack.
Load related PRs on one computer with your real services, run tests, browse the app, and post review comments without local setup.
Why this is hard
A diff hides the interesting failures
Reading a patch tells you whether the code is reasonable. It does not tell you whether the page still loads, the migration applies, or the endpoint answers.
You need to see it break, not read about it
A comment that says checkout fails still sends you back to reproduce. A recording of the failure on a running stack is what lets you merge or reject without another hour of setup.
A diff-only review misses integration failures
Patch comments can flag a risky import or a missing null check. They cannot tell you the API contract changed under the call site, the migration never ran, or the page still renders the old flow.
What happens when a PR opens
The branch is checked out on a live stack
Not a container with the repo in it. The services boot, migrations run, and the app is reachable.
The agent exercises what the diff touched
It reads the change, works out which behavior is at risk, and goes and tries it against the running app.
It runs the suite plus the paths tests miss
Existing tests run as usual, and the agent probes the edges around the change where coverage tends to be thin.
It comments with evidence
Findings arrive on the pull request with the request, response, log line, or recording that produced them, so you can judge them quickly.
What you get back
- PR comments with evidence
- Test results
- Reproduction steps
- Recording when a flow breaks
What a diff cannot tell you
The branch checked out on your real stack
Migrations run, services boot, and the agent exercises the diff against a reachable app — same deps and config as your laptop.
Findings arrive with the repro attached
Comments include the request, log line, or recording that produced them so you can merge or push back without re-running setup.
Who runs this
The moment I could trust that what comes back actually works and my only job was merging the PR, that was a huge change for us.
Matan KleymanCEO, ObertRead the full story →
So we can basically double or triple our development capacity. We processed 300+ client compliance docs, and work we used to estimate at a month by hand now takes about 10 minutes.
Immanuel SegolCEO, MadupayAll customer stories →Setting up was seamless and I love the experience.
Shay DahanTech Lead, Public software companyAll customer stories →
I created a new use case with Islo that every day reads all the fresh PRs opened by Kargo, reviews them, and eventually sends a Slack notification explaining its findings. Saves me tons of time!
David MarkVP Platform, IncredibuildAll customer stories →
Where teams go next
Common questions
Can an agent test two related PRs together?
Yes. Load related PRs on the same computer so the agent can test interactions across changes in a single running stack.
Does PR review run my actual dependencies and services?
Yes. The computer runs the same repo, deps, services, browser, config, and env vars as your laptop.
Will the review agent comment directly on GitHub?
Agents post comments and status back to GitHub on the PRs they reviewed.
Can the agent click through the app while reviewing a PR?
Yes. The review computer includes a browser and the running services, so the agent can verify user-visible behavior instead of relying only on unit tests.
Does Islo merge the PR after review?
Islo posts findings and verification evidence back to GitHub. Your repository rules and approval workflow still decide whether the pull request can merge.