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?â

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:

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.main, which makes the author on every commit verifiable.main.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.

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.