Arbor is deterministic PR blast-radius analysis. It parses the repo, builds a call graph, walks changed paths, and comments with what the graph can reach — without an LLM in the risk path.

Can AI coding agents use Arbor?

Yes. Arbor produces a compact PR brief with risky paths, likely side effects, unknown edges, and the first test to write so agents can keep edits scoped.

Does Arbor work with GitHub pull requests?

Yes. Arbor installs as a GitHub App, analyzes pull requests, and comments with the breakage path reviewers should inspect.

Back to Arbor

Examples

Real ways small teams use Arbor.

Arbor is built for the people who feel PR review pain immediately: solo devs, tiny teams, maintainers, and agent-driven workflows where context has to be tight or the next edit gets messy.

Solo founder shipping fast

Current pain: A one-line fix touches checkout, auth, and a background job. There is no senior reviewer to ask, and context switching kills the day.
Arbor wedge: Arbor comments with the downstream path, the likely side effect, and the first test worth running before merge.

Two-person product team

Current pain: Both people are writing features, reviewing PRs, and answering customers. Manual code spelunking does not survive a busy week.
Arbor wedge: Arbor gives each PR a compact map so review starts from the risky path instead of the whole repository.

Open-source maintainer

Current pain: Drive-by PRs change internals, but maintainers do not have time to trace every call path by hand.
Arbor wedge: Arbor points maintainers at the files, entrypoints, and unknown edges that deserve a closer look.

Agent-heavy dev loop

Current pain: Agents can edit quickly, but they need a scoped brief before they safely touch unfamiliar code.
Arbor wedge: Arbor becomes the pre-edit context source: path, likely break, unknowns, first test, and stop condition.

Customer Discovery

The questions we ask before claiming proof.

These prompts keep Arbor honest. If the pain is not repeated, active, and easy to name, the product should not overstate the story.

Walk us through the last PR where a small change broke something unexpected downstream.
What do you ask yourself before merging a PR that touches auth, billing, data writes, or background jobs?
Where would an AI agent need more context before editing your codebase?
What would make a PR comment useful enough that you would actually read it before merging?

Be a design partner.

If you review PRs in a repo where auth, billing, background jobs, or data writes matter, we will run Arbor on your repo and show the exact path map.

Talk to Arbor