I've worked at a large enterprise that have a "Change Advisory Board", that you need to convince when you want to bump the major version on your linter. It has the effect of velocity slowing down to a crawl. Changes have to large, since otherwise it wouldn't be approved by the CAB. A slow mess.
At my current place we have to loudly declare "I CONFIRM COMPLIANCE" in every PR description. I'm not sure that anyone knows why, but it keeps the bureaucrats happy. Shrug
High trust is high trust until someone exploits it, and the likelihood of encountering an exploit (embezzlement, fraud, political speech, etc.) approaches 100 as the total number of staff hours increase.
Minor, medium, major change category depending on potential impact with documented guidelines when each apply.
First release of a service always recommend to be major. (They are few vs daily changes and can be redtaped more to get many stakeholders requirements. Functional and non functional) Author of the change and his team decide the category.
- Minor need one more reviewer outside author. Team decide everything.
- Medium need min one more, and usually QA team or other affected team.
- Major change need CAB meeting with all major stakeholders to sign off.
CAB is responsible for the process and high level monitor the program, see if any cheating goes on, performance metrics such as number of changes per category etc. Help support people what could be considered minor vs major changes.
Overall rel flexible and balanced. Pushes people towards making smaller changes with less risk and at the same time increase velocity while still protect reasonable against bad actors, mistakes etc.
It is not perfect, medium changes tends to be more difficult to coordinate, some changes are missclassified etc but that is okey. It is not only about the process, communication matters and ci/cd have to be robust etc.
This balanced approach works for many.
I'm pretty unclear how approvals are ensured in your system?
Authorisation and recording are pretty much out-of-the-box with a version control system, CI can guarantee testing, but how are we demonstrating approval without any evidence of change reviews?
I've been trying to explain to compliance employees that if the majority of PR reviews anyway is just "LGTM - Just merge" (I don't care), what's the actual value of PRs? It's just facade.
On a different note, we're looking into artifact attestations and admissions through Sigstore, which is solves many of the same challenges but through different means.
But how do they review each other's work? Prs are indispensable for collaboration...
And I am guessing you'll extend that high trust to your agents/'orbs' next. And I am sure you'll find an auditor who'll go with it coz frankly most don't care.
I am not surprised there are folks willing to do this, but I am surprised that you feel you must brag about it. And you ARE bragging when you title the post the way you did. Good luck.
So what do you do? You engage and some 3rd party 1800-need-soc2 clowns which will hold your hand and implement all the cookie cutter solutions they know will make auditor happy (oh and btw, they know the auditor personally).
"We don't know why we're doing it - it's just mandatory".
We...just read the commits, and talk to each other.
We're also pretty trigger happy with the Huddle button in Slack.
Nobody on the team would go back to mandatory PRs
What is the alternative? Bumping a dependency in a PR and getting a LGTM can also introduce a backdoor.
That's another form of high trust: your trusting the publisher of the dependency.
High trust comes with high responsibility, which is easier to enforce when the trusted party is an individual on your team with generally aligned incentives, rather than an organization or unpaid individual on the internet serving many.
In a 20 people startup it's very likely that most engineers have access to production anyway and can inject malicious stuff directly, so PRs stop no one really.
The better way is that for each policy you look at what do you actually want to do and how you want to do it, and then write that down as the policy. Now the policy makes sense because it's how you wanted to do it anyway.
I've set up policies and processes from the ground up for SOC2 audits in startups, that's how I do it.
Will Dollman//August 13, 2026
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.