+1: Introducing Approvability

Eng teams have a poorly kept secret: a meaningful share of human code review time is purely ceremonial.

Someone updates user-facing copy, adds a unit test, or fixes a broken link, and a teammate gets pulled out of deep work to open a diff, confirm it's what it says it is, and +1. Thirty seconds of review, thirty minutes of lost context. This was true before agents started writing code. It's even more true now, and soon it'll be exacerbated to the point where it's neither possible nor sensible for humans to review them all. Teams operating on the bleeding edge are buried beneath a growing mountain of review work.

We're releasing a new Macroscope check called "approvability." For the PRs that don't need a human in the loop, Macroscope can give the approval — saving you the trouble of pulling someone out of whatever they're actually working on.

But automatic approvals only work if we're precise about which PRs qualify, and conservative about everything else. If a PR has any correctness issues, or is otherwise deemed ineligible, it won't qualify.

The shape of eligibility

Macroscope's default eligibility guidelines are detailed below, but keep in mind that you can add your own policy in macroscope_approvability.md. If you do, Macroscope will use it as the highest priority criteria to follow.

When someone opens a PR, Macroscope researches the changes, evaluates the author's track record, and checks against your organization's customizable policy to make a determination if the change is eligible to be auto-approved. The default criteria is purposefully conservative.

Changes Macroscope typically approves

PRs that don't impact runtime behavior are the clearest case. Documentation updates, unit tests, code behind a feature flag that isn't turned on. These changes literally cannot affect what's running in production. There's nothing to break.

Next are simple, low-risk, self-contained changes. Updating copy, adding a new endpoint that follows an existing pattern, tweaking an error message. These are the kinds of changes where the intent is obvious, the scope is narrow, and the change is consistent with what's already there.

Straightforward bug fixes also qualify. Fixes where the intent is clear, the scope is limited, and the resolution is obvious. For example, a null check that was missing, an off-by-one error, or a conditional that was inverted.

Changes Macroscope escalates to humans

Complexity is the first signal, because large changes are inherently harder to reason about, and the surface area for unintended consequences grows with every file touched.

For example, schema changes — major database migrations or API contract modifications — often get escalated because their blast radius extends well beyond the diff. A column rename that looks simple might break downstream consumers you can't see in the PR.

Macroscope escalates anything with significant runtime behavior changes outside of small, self-contained bug fixes. If the change alters how the system behaves in production in a meaningful way, a human should look at it.

Major side effects are another trigger — whether clearly observable, like breaking changes to a public interface, or subtle but implied, like toggling a feature switch that changes behavior for a subset of users. Major refactors get escalated, as do changes to production deployment and infrastructure.

And anything touching security, billing, authentication, or sensitive data is very likely to be escalated.

For everything else, the rule is simple: if Macroscope has any doubt as to the scope or potential side effects, defer to a human.

A note on compliance

For many teams, approving a PR without a human reviewer means updating SOC II guidance.

Most policies were written when humans were the only ones writing and reviewing code. The idea of an agent reviewing code — let alone doing it more thoroughly than a person — wasn't on the table. But that's where we are. Macroscope's agentic review pipeline already catches bugs at a rate that exceeds what human reviewers typically find, especially the subtle ones that cause real production damage.

The future we're moving toward — quickly — is one where humans are in the loop on what matters, but agents are doing the heavy lifting on both writing and reviewing code. Compliance policies will need to reflect that. Not because the bar should be lower, but because the mechanisms for meeting that bar are changing.

What matters most to us is this: whatever policy your team decides is appropriate, Macroscope should be able to enforce it automatically. The system is built to evolve with your constraints.

Approve and escalate

We see a future where Macroscope can correct, approve or escalate. This comes up all the time when we talk to customers — I need help knowing where best to focus my review time. When you think about it, they're two sides of the same coin. One PR might be eligible for automatic approval while another merits extra attention. Macroscope should handle the routine changes automatically while surfacing the ones that actually deserve your focus.

The goal isn't to remove humans from code review. It's to make sure that when a human looks at a PR, it's because the PR actually needs a human — not because the process demands one.

Approvability is now available to try out for any customer today. You can also read more about how it works in our Docs.