We’ve been sharing more about how we work: building Amp with Amp, orbs, killing features, no pull requests. And the most common reaction isn’t about the AI workflows or whatever kind of loop graph engineering is flavor of the week. It’s this:

Wait, you don’t use pull requests? You push to main? How? That’s not SOC 2 compliant.

Except it is.

Skipping pull requests was a deliberate choice from the first commit. It’s a big part of how we build and why we can ship continuously.

So when we started working toward SOC 2, we took that question straight to our auditors: “you need PRs for that… right?”

Controls

SOC 2 doesn’t require pull requests. It requires that you think about your risks.

That’s the real answer we came away with. Auditors, and SOC 2 itself, are more flexible than you might assume. Ours didn’t ask us for pull requests; they asked what our change process was, and worked with us on a set of controls that fit it.

The Trust Services Criteria never mention git or pull requests. What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that.

Here are the controls we landed on:

• Restricted push access. Access to main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why.
• Signed commits. Pushing already requires authentication, but commit authorship is just metadata. GitHub enforces verified signatures on main, which makes the author on every commit verifiable.
• Automated CI. Every change runs through the full validation pipeline: tests, infrastructure checks, security checks. Bad changes block main.
• An audit trail that’s as good as a PR’s. Commits link to the Amp threads that produced them, so the record isn’t just a diff, it’s everything that led up to it. From there, CI/CD records the path from commit to deployment.

None of this is exotic. But it isn’t the standard process with a step deleted, either. It’s a system designed on purpose, and it gives an auditor the same thing a PR workflow gives them.

And no, code review isn’t on the list. The criteria don’t say a second human has to stare at a diff.

Does this scale?

We’re 20 people, mostly engineers, and everyone is close to the code. Being small and high-trust is our advantage, and we aren’t going to give it away for a process we don’t need. When writing code is fast, slow process becomes what you’re actually waiting on. But we’re not going to pretend a 2,000-person company should let everyone push to main.

What does scale is think about your risks, because risk isn’t uniform inside a company either. Amp is customer-facing production software, and we ship it this way. Meanwhile, plenty of code at bigger companies carries less risk than that, yet every change goes through the same process, calibrated to the scariest system the company runs.

And you don’t have to overhaul the whole company to fix that. Pick one system and ask: “What risks are our pull requests actually managing here?” Then ask how else you could manage them.

The answer doesn’t have to be pull requests.