# Review should help you ship.

We built Arcanist to verify your code, so you can ship faster with confidence in what you’re putting into production.

Shivam Pandey and Josiah Parappally, co-founders of Arcanist

## We felt the bottleneck ourselves.

We adopted coding agents early because they let us build more. As generating code became easier, checking it became the constraint. We could produce changes faster than we could confidently ship them.

At one point, we were spending about $5,000 a month on code reviewers. Whatever verdict they returned, we still had to inspect and test the code ourselves before we trusted it enough to merge. We kept asking what the spend had actually enabled us to do differently.

We wanted review to give us enough confidence to make progress. Another list of possible problems left the verification work with us.

## Coding changed. Review has to follow.

With coding agents, a review comment is often the start of another round of work. The agent makes a change, tests run again, and the result comes back for review. The reviewer helps determine what the team spends its time doing.

A good reviewer has to distinguish a real blocker from something that could be improved. Correctness matters, but so does knowing when a change is good enough to ship.

## We choose speed and depth.

We think about review as a tradeoff between breadth, depth, and speed. More breadth means looking for more kinds of issues. That sounds useful, but you pay for it with your attention and time.

A stream of P2s, nits, and minor improvements leaves you sorting comments instead of shipping. Even a correct finding needs a decision about whether it matters. If an agent acts on it, you have another change to check and another CI run to wait for. Moving it into a follow-up ticket still leaves someone responsible for it.

We choose speed and depth: focus on the problems that should actually stop you from merging, investigate them thoroughly, and give you an answer quickly.

Speed: Get to an answer quickly.

Depth: Prove the blocker is real.

Breadth: Leave out the distractions.

Depth means doing enough investigation to establish that an important failure is real. A finding should explain what breaks, why it matters, and the evidence behind it. The engineer should be able to understand it and act without starting the investigation again.

That is the judgment we want engineers to trust: if we raise a blocker, it deserves their attention.

## A comment creates work.

The cost of review includes everything that happens after the comment appears. Someone has to assess it. An agent changes the code, tests run, and the PR comes back for review. Depending on the CI process, addressing comments and rerunning checks can add 10 to 30 minutes to a merge-ready PR. Multiple rounds compound that delay.

Our goal is to maximize flow state for developers and agents by making each interruption count. A bug that breaks something important deserves a fix and another CI run. A minor correction may not.

## Judge review by what it enables.

Finding more bugs and getting more comments resolved can look like success while slowing the team down. We care about whether review helps people ship high-quality code with greater confidence and fewer unnecessary interruptions.

We’re building review that lets you merge agent-written code with confidence. That means identifying the most relevant blockers, verifying that they’re real, and leaving out distractions you don’t care about.

Merge agent-written code. With confidence.

[See Arcanist](https://www.tryarcanist.com/)