In software, the four-eyes principle requires that two people sign off before something ships. In regulated industries like fintech, it can be a legal requirement. Outside of regulation, plenty of software teams still use it. Depending on how you implement it, the constraint has real benefits.
A poor implementation will hurt you though.
Code review is a common approach. Typically, a pull request gets raised and someone responsible approves. This is how most open source contributions work.
The process itself isn't the problem. The problem is what happens when it's the only mechanism for meeting the principle's requirements.
The waiting isn't ideal. You finish your work, raise a pull request, and wait. You could be making a change to a codebase owned by a different team, with their own workload and their own priorities. In large organisations, each team owns multiple services. A review crossing a boundary means waiting on people who are deep in their own work.
Waiting on another team is one thing, but waiting on your own team is another. This implementation of the four-eyes principle regularly ends up with everyone working on their own projects. This is when knowledge silos begin to form and the bus factor climbs.
And now AI has increased PR volume dramatically.
Existing bottlenecks, already under strain for years, are seriously cracking. People are noticing — the volume of code is much higher — and everyone wants a quick fix.
One popular proposal is to allow any engineer to approve pull requests, regardless of whether their team owns the service. Eyes are eyes, right?
I understand the instinct. The gates are jammed. Let's open them up!
But those gates were installed for a reason. Poorly installed, but for a reason.
An engineer approving a PR on a service they own is a strong signal. They know what the service does, they understand the change, and they're saying it's correct. That's what makes the approval mean something.
Ownership comes with accountability. If something breaks at 2am and someone gets woken up, it's usually the person who owns the service. Dilute ownership and you dilute who's going to care when things go wrong.
This was a problem before AI arrived. The issue isn't the review process. It's too many projects in-flight, no WIP limits, no shared initiatives. It's everyone working in isolation. It's the fact the review process is when the third and fourth eyes arrive.
Pair programming merges development and review into the same step. You don't write code and hand it to someone for approval. You write it together. Four eyes from the first keystroke. The person who understands the service is there while the change is being made, not reading it fresh afterwards.
But I want to end this by playing devil's advocate.
Things are moving fast. Being open to experimentation is right. But experimenting without thinking from first principles is reckless.
Someone needs to understand the original tradeoffs and the options available before blazing a new trail. The new trail might be right. I doubt it. But it might be. Someone needs to be watching — not to say "I told you so" in six months, but to see what the change is actually doing to code quality.
What would help: a real conversation. Decide if you wanna experiment, time-box it, and agree upfront what you're monitoring. What does success look like? What does quietly-degrading quality look like? We're in a turbulent period. Experimenting is fine. Just make sure someone knows what failure looks like before you start.