What Rewind’s AI approval system teaches every team shipping faster

This is an analysis of a public engineering post. Rewind is not a Hybrid customer and did not use Hybrid. Everything below comes from their own write-up, linked throughout.

On June 1, 2026, Dave North at Rewind published a post whose title does most of the work: "Review is the bottleneck now: How we let AI approve pull requests (safely)". It is a 22-minute read about an internal tool with a Star Wars name. It is also the clearest public account I have found of a team deciding, in writing, which changes can ship without a senior engineer looking at them, and then defending that decision to an auditor.

If you run a product and wonder why a copy change takes two weeks, this post is worth your time. Here is what it says, and what it means for teams that will never build their own version.

The problem: forty PRs a day, one pool of attention

Rewind describes merging "on the order of forty PRs a day across our GitHub organizations," which they put at "well over a thousand a month, and climbing." Agents had made writing code cheap. Review had not scaled with it. A typo fix and a tenant-isolation change waited in the same line, for the same senior engineers.

That is the shape of the problem at every size of company. The writing is no longer the slow part. The waiting is.

What they built, in plain English

The tool is called Diff Vader. It comments on every pull request, and for a bounded set of low-risk changes it is the only reviewer a PR needs. Three pieces make it work.

A council of specialist reviewers. More than a dozen AI reviewers run in parallel, each with one job: correctness, security and tenant isolation, test adequacy, blast radius, revertibility, database migrations, and so on. They are told to ignore style nits, and they skip themselves when a diff gives them nothing to look at.

A risk grade for every change. Each PR is graded LOW, MEDIUM or HIGH based on what the reviewers found, not on how many lines changed. One high-blast-radius finding escalates a PR regardless of its size.

A verdict engine that is not AI. The findings go into what North calls "a small, unit-tested, boringly deterministic piece of code" that turns them into a decision: approve, request changes, or needs a human. An approval is a posted review, not a merge. Branch protection and every other gate the team already had still apply.

What made it trustworthy

Three choices did the heavy lifting, and none of them were about model quality.

Rules decide, opinions inform. The post is explicit about "keeping the judgment (AI) and the gate (deterministic code) separate." The AI can be wrong, inconsistent, or differently opinionated tomorrow. The code that decides what to do with its findings is tested, reviewable, and gives the same answer every time. Beside it sits a policy file per repository, protected by CODEOWNERS, with hard rules the verdict engine cannot override.

Sensitive areas always go to a person. Changes to "paths that touch authentication, authorization, secrets, encryption," infrastructure, governance files, and "anything that changes who is allowed to approve future changes always require a human." No agreement score and no streak of good behaviour moves those categories. Any engineer can also pull any PR back to human review with a slash command.

An audit trail the auditor would accept. North writes that "we brought our GRC lead in at the start, not the end." The result was a controls mapping and a formal risk assessment. Separation of duties maps to SOC 2 CC8.1.2: an AI-authored PR can be reviewed by Diff Vader but cannot be merged without a human. Every AI-approved PR is labeled and queryable with its evidence, mapped to CC8.1.3. The same mapping covers ISO 27001 and ISO 42001, with 13 failure modes rated and mitigated.

There is one more detail I would not skip. Engineers react to the bot's comments with a thumbs up or down, a weekly digest goes to a rotating lead, and that person makes changes through ordinary pull requests. The bot never edits its own prompts or policy. Suppressions expire after 90 days unless someone re-justifies them. The system learns, but humans steer.

The design decision everything else depends on: the AI gives findings, and ordinary tested code gives the verdict.

The results, with their caveats

The numbers cover a shadow week plus the first week of live operation, and the post is careful to say so.

• About 40% of PRs auto-approved, at the top of a 30 to 40% target band.
• About 99% human agreement on bot-approved PRs that also received a human review. The bar for going live was 90%.
• Zero reverts and zero incidents linked to bot-approved PRs.
• Well under a dollar per PR on average.

The caveats are theirs: "Read them as directional (small sample, still expanding), not a final verdict." The 40% is inflated by "gem bumps," mechanical version bumps of internal libraries where the real review already happened upstream, and they expect the rate to settle toward the middle of the band as coverage widens.

Rewind is not alone. In April 2026, Intercom's engineering and GRC leads wrote that over 19% of PRs on their two main codebases are auto-approved with no human reviewer. They engaged their auditor, Schellman, before scaling, and every AI-approved PR is logged with its review comments, the approval decision, test results and the merge event. Their revert comparisons are uncontrolled and they say so, but the pattern matches: evidence first, auditor early, humans on request.

Lessons for teams without a platform team

Rewind had engineers to spare, a GRC lead, and the time to build this. Most teams asking "why does a small change take two weeks" have none of those. The lessons transfer anyway.

1. The decision has to be deterministic. An AI reviewer that gives an opinion is a helpful colleague. It is not a gate. The gate is a rule you can read, test, and show to an auditor.
2. Write the always-human list first. Authentication, secrets, money, infrastructure, and anything that changes who can approve. Agree it before a single change ships on its own.
3. Shadow before you trust. Rewind ran the bot beside real reviews and set a 90% agreement bar before switching it on. Do the same, and count the disagreements.
4. Keep the evidence. Label and log every change that shipped without a human. That record is what the auditor asks for, and what you reach for when something goes wrong.
5. Start with the boring categories. Rewind's first wins were dependency bumps. Yours might be copy, colours, and settings.

Where Hybrid fits

Hybrid is this pattern for teams that are not going to build it. The Rulebook is the policy file: your engineers write down what is sensitive, such as payments, login, pricing and user data, and the verdict on every change is a deterministic function of those rules, not a model's opinion. Anything that touches a sensitive area goes to an engineer with a ready-to-build spec. Every change carries a filmed before and after and a record. And it starts in approve-everything mode, so your engineers decide when a category has earned the express lane, and can pull it back whenever they like.

Rewind closed their post with a line that belongs on every engineering wall: "The writing got cheap. It's time the reviewing caught up."

See how fast your team could be moving.