Taking the training wheels off your merge button

Remember learning to ride a bike? Someone ran beside you with a hand on the seat, ready to catch you if you wobbled.

Most engineering teams still ship code that way. A coding agent writes the change, a review bot comments on it, and the tests pass. Then a person has to press merge, and carry the responsibility that comes with it.

“There’s a mental load in actually performing that action,” says Opher Vishnia, Principal Engineer at Hud, who helped shape its auto-review and auto-merge. “It puts a lot of responsibility on the shoulders of the developer to say: I’ve checked everything that needs to be checked, and I’m confident it’s not going to break anything.”

That’s the job Hud’s auto-review and auto-merge were built for. Not to take people out of the loop everywhere, but to show you where it’s safe to let go of the seat.

Why the merge button became the bottleneck

Coding agents changed the math. “There’s way more code generated per developer per day than ever before,” Opher says. Writing code got faster. Reviewing and validating it didn’t.

So the bottleneck moved from writing code to trusting it. Before auto-review, every change in Opher’s area, trivial or not, sat waiting for a second pair of eyes.

That wait costs more than time. It spends a reviewer’s attention, the scarcest thing on the team, on changes that never needed it.

What auto-review and auto-merge do

The Hud Reviewer gives every pull request a verdict: safe to merge, review required or high risk. Two settings decide what happens next:

• Auto-approve PRs. Hud acts as a GitHub approver, the same way a person would. If your policy requires one approval, a safe-to-merge verdict can count as that approval.
• Merge when approved (auto-merge). Once a PR is approved, by Hud or by a person, and every other check passes, Hud merges it.

Opher describes it as doing two jobs at once. On risky changes it adds “good friction,” a pause that makes someone else look. On routine ones it “fast-tracks things,” so you can merge without pulling another person in.

How Hud decides a PR is safe to merge

A safe change is one that carries little risk to production. These are the areas where Hud is more likely to ask for a human reviewer:

• Infrastructure: Terraform, DevOps changes, databases, routing.
• Changes you can’t take back: database migrations and anything else destructive. A frontend change can be reverted. A dropped column can’t.
• Paths everyone goes through: endpoints like login that every user hits.
• Sensitive areas, where they apply: payments, PII, authentication, encryption.

Some rules make sense for every company, like flagging migrations. Others depend on what you build, so each team can add its own rules to the mix. Teams can also make some of them mandatory in their GitHub policy. On our own repo, CI workflows, Terraform and migrations always need a code owner, whatever Hud says.

What the diff can’t tell you

Reading the code and using tools like static analysis catch a lot of this. But Hud also sees how the changed code behaves in production, and that changes the verdict:

• Traffic: how many requests hit the endpoint you changed.
• Invocations: how many services call the function you changed. Opher’s example is a small helper function that looks harmless, “but actually, like 90% of the system runs through it.”
• Latency: a change is riskier if the endpoint is already slow, or if it would make a fast one slower.

When Hud has no production data for part of a PR, it says so. It doesn’t guess “safe.” For a PR that spans several areas, it reports on each one separately.

A gate, not another bot

Most PR checks are built to advise. Review bots comment and flag issues; you can configure some to block a merge, but that’s not what they’re designed for. Tests can block a merge, but they don’t see production. The Hud Reviewer is designed as a gate from the start, with the verdicts, approvals and audit trail a gate needs.

It runs as a GitHub policy check. If your policy says a risky PR needs a human approval, GitHub won’t merge it until that approval arrives. “You can’t physically merge it,” Opher says.

[Screenshot: PR 8654, Review required, with Hud Approval Policy “Waiting on one of ‘code owner approved’, ‘Hud Reviewer safe to merge’”]

It doesn’t replace your other layers; it builds on them. You can set the gate to pass only once your tests and other checks are green.

Every decision leaves a trail. Hud posts a comment on each PR with its verdict and the reasons behind it: what’s safe, and what deserves a closer look. The gate keeps a log of what happened, and you can filter PRs in GitHub by approver to see everything Hud approved.

[Screenshot: PR 8191, the Safe to merge comment with Hud Reviewer and Hud Approval Policy both green]

What happened when we ran it on ourselves

We built auto-review alongside Hud itself and ran the proof of concept on our own monorepo. The goal was to learn its limits on real PRs: when it should run, how long it takes, and what counts as noise versus a useful signal. “It’s not something you can easily achieve with mock data,” Opher says.

• Volume: as of late October, Hud had judged 452 PRs on our monorepo: 228 safe to merge, 204 review required and 20 high risk. It auto-approved 112 of them, with no second reviewer needed.
• The safe rate follows the risk: 83% of PRs that stayed inside dev tooling, tests and ephemeral environments were safe to merge. Frontend-only PRs came in at 94%. Even though backend changes could be potentially dangerous, 39% of those still got the safe-to-merge stamp from Hud. The areas the risk rules target sat lower still: auth at 33%, Terraform at 31% and migrations at 28%.
• Wait time: safe PRs went from tens of minutes, sometimes a day, to minutes. “If you get safe to merge, then that’s it. You’re merged.”
• Misses: in the weeks it’s been running, Opher hasn’t heard of a single incident traced back to a PR marked safe to merge.

Letting go of the seat

For some teams, auto-approve is as far as they’ll go at first. Hud approves their PRs, but a person still presses the button.

The technology isn’t what’s holding them back. Picture the full loop: an agent writes a PR, Hud approves it, and it merges in under a minute while the author is at lunch. Every step is already possible. What’s left is the question of who answers for it if something goes wrong, and the answer is never the tool.

“There’s a psychological element to this. It’s not just a technical one,” Opher says. “If something might get pushed to production without you knowing when it happened, it pulls away your sense of control.”

That’s the moment the parent lets go of the seat. Most kids can ride before they believe they can; the wobble is in the head, not the legs. Opher sees the same pattern with coding agents: “At the beginning, we all felt the same about using agents. And now it’s second nature.”

Trust here doesn’t mean believing the reviewer works. It means getting comfortable not holding on, and evidence is what gets you there. How many hours has auto-approve saved your team? How many PRs would have gotten a quick “LGTM” but were flagged as risky, so someone took a proper look? “The data will answer the question,” Opher says.

Training wheels come off one route at a time

Should your team turn on auto-merge? “It all boils down to the cost of a mistake,” Opher says. Ask three questions about each area of your code:

1. How bad is a mistake? Leaked data, damaged data or an outage for customers rules it out.
2. How easy is it to undo? A quick revert keeps the worst case small.
3. How fast would you know? You need a dashboard or alert that flags a failure right away.

If the answers are “not bad,” “easy” and “fast,” auto-merge is a good fit. If not, keep a hand on the seat. Some routes, like payments, may never be bike paths, and that’s fine.

Getting started

1. Turn on the reviewer, nothing else. “Just turning it on without auto-merge is safe,” Opher says. “There’s nothing risky about it.” Check Hud’s verdicts against your own judgment. Pick a repo you know well, that’s instrumented with Hud and has real traffic.
2. Add auto-approve. Hud approves the safe PRs, and you still press merge.
3. Add merge when approved, one area at a time. Only where a fall is cheap, easy to undo and quickly noticed.

A few settings make this work:

• Your own risk rules. Add your high-risk areas in plain text in Hud’s settings. “If you have high-risk domains in your code, add them to the policy.”
• A ready label. Run the review only when a PR carries a label you choose, so work in progress doesn’t merge mid-push.
• GitHub setup. Configure your GitHub policy to recognize the Hud Reviewer as an approver; without it, the reviewer can’t act as a gate. Auto-review works with GitHub today. [Link to setup docs]

Here’s a simplified version of the policy on our own monorepo. Either a code owner or a green Hud Reviewer check can approve a PR. CI workflows, Terraform and migrations always need a code owner, and so does any PR with “WIP” in the title.

# A green Hud Reviewer check approves the PR. It doesn't merge it.

approval_rules:

  - name: code owner approved

    requires:

      count: 1

      users: [alice, bob, charlie]

  - name: Hud Reviewer safe to merge

    if:

      no_changed_files:        # these paths always need a code owner

        paths:

          - '(^|/)\.github/workflows/'

          - '^\.policy\.yml$'

          - '^terraform/'

          - '(^|/)migrations/'

      title:

        not_matches: ['(?i)\bwip\b']

    requires:

      conditions:

        has_status:

          conclusions: [success]

          statuses: [Hud Reviewer]

policy:

  approval:

    - or:

        - code owner approved

        - Hud Reviewer safe to merge

Even confident riders wear a helmet

No review, human or automated, can know everything before a merge. Sometimes a change is fine on its own and breaks only when it meets the rest of the system. “Stuff happens. That’s life,” as Opher puts it.

That’s why the merge isn’t the end of the story. Watching how the new code behaves in production once it ships is the helmet: protection for the falls nobody saw coming.

Today, someone holds the seat on almost every PR. Auto-review shows you where you can already let go.