The Illusion of Compliance
How Modern Code Reviews Are Failing Regulatory Compliance
It’s time for government and regulators to rebel.
Across healthcare, finance, automotive, and aviation, we’ve built an elaborate system of compliance documentation that looks impressive on paper whilst failing spectacularly in practice. This is safety-theatre, pure and simple.
Regulators ask for verification and validation, and the industry responds with pull request approval statistics and merge policies. We’ve collectively agreed to measure the wrong things, audit the wrong artefacts, and mistake process documentation for actual safety assurance.
If regulators truly care about patient safety, financial security, and critical infrastructure protection, they need to stop accepting our theatrical performances and demand evidence of real verification. The current system isn’t protecting anyone. It’s just protecting our ability to say we followed a process.
We have a problem in software engineering, and it’s hiding behind a green checkmark and an “LGTM.”
For organisations in regulated industries (healthcare, finance, automotive, aviation), code reviews aren’t just best practices. They’re regulatory requirements. FDA guidance, PCI DSS, ISO 26262, DO-178C, and IEC 62304 all demand verification and validation throughout the development lifecycle.
Yet here’s what actually happens in most organisations: A developer finishes their feature at 4:47 PM on Friday. They open a pull request. Within minutes, sometimes seconds, approvals start rolling in. “LGTM.” “Looks good!” Maybe someone leaves a comment about a semicolon. The PR merges. Everyone feels productive. The compliance checkbox gets ticked.
But was the code actually reviewed?
Studies consistently show that most code reviews catch only superficial issues. The average PR review takes under 10 minutes, regardless of complexity. Reviewers often scan for style rather than logic, security vulnerabilities, or architectural concerns. We’ve created theatrical compliance: a performance of diligence that satisfies our process documentation whilst fundamentally missing the point.
The Inspection Fallacy
W. Edwards Deming taught us decades ago that we cannot inspect quality into a product. His third principle explicitly states: “Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.”
Yet this is precisely what we’ve done with pull-request-based workflows in regulated environments. We’ve moved quality assurance to the end of the development process, treating it as a gate rather than a foundation. We write code in isolation, throw it over the wall, and hope someone catches the problems before they reach production.
This approach violates everything we know about effective quality systems:
Quality cannot be inspected in. It must be built in from the first line of code. When quality assurance becomes a checkpoint at the end rather than a continuous discipline throughout development, we’ve already lost. By the time code reaches a pull request, the architectural decisions are made, the technical debt is embedded, and the cost of change has multiplied exponentially.
End-stage inspection creates a false sense of security. That approved PR badge becomes a liability shield rather than a quality signal. When auditors ask, “How do we ensure code quality?” we point to our approval percentages and merge policies. But those metrics measure theatre, not effectiveness. We’ve optimised for the appearance of compliance whilst the actual quality varies wildly based on who happened to review the code and how much coffee they’d had.
Gated quality reviews slow down everything except the problems. Bugs, security vulnerabilities, and design flaws slip through with approved PRs every day, whilst well-intentioned review bottlenecks paralyse teams. We’ve created a system that’s simultaneously too slow and too ineffective: the worst of both worlds.
What Regulators Actually Require
When FDA guidance requires “verification and validation throughout the software development lifecycle,” they don’t mean a cursory glance at a diff before clicking approve. When PCI DSS mandates code reviews for custom code, they expect meaningful examination of security implications. When ISO 26262 requires safety analysis, they mean systematic evaluation of failure modes.
These regulations understand something fundamental: quality is a continuous process, not a discrete event.
The spirit of these requirements demands:
Continuous collaboration during development, not post-hoc examination
Shared ownership of quality across the entire team
Real-time feedback that prevents issues rather than catching them late
Documentation that reflects actual verification, not checkbox compliance
A Different Approach
What if quality assurance wasn’t something that happened after code was written, but whilst it was being written?
Imagine development practices where:
Pair programming and ensemble programming build quality in real-time through continuous review
Automated testing provides immediate feedback on every change, shifting quality left
Architecture discussions happen before code is written, not after it’s complete
Compliance and security expertise flows throughout development, not just at approval gates
Documentation emerges naturally from the development process rather than being reverse-engineered from completed code
This isn’t radical. It’s Deming applied to software. It’s what “shift left” actually means when taken seriously.
For regulated industries, this approach doesn’t just improve quality. It better satisfies the actual intent of regulatory requirements. Continuous verification throughout development is more aligned with FDA guidance than end-stage PR approval theatre. Real-time collaboration provides better audit evidence than retroactive approval stamps.
Auditing Without Pull Requests: What Evidence Actually Matters
Here’s the concern I hear most often: “But what do we show the auditors if we don’t have pull requests?”
This question reveals our fundamental misunderstanding. Auditors don’t care about our pull requests. They care about verification. The FDA doesn’t require GitHub approvals. PCI DSS doesn’t mandate merge request workflows. These regulations require evidence that verification happened, not evidence that a particular tool was used.
In a world built on trunk-based development, test-driven development, shift-left practices, and social coding, the audit trail looks different, and often better:
Continuous Integration Logs become our primary evidence. Every commit triggers automated tests, security scans, and compliance checks. Unlike a PR approval that might have taken 30 seconds, our CI pipeline provides timestamped, reproducible evidence of exactly what verification occurred. When a test fails, the pipeline stops. No human override. No “approve anyway because we’re in a hurry.”
Pair and Ensemble Programming Sessions generate rich audit evidence. Screen recordings, session notes, and commit metadata show who collaborated on what code and when. Instead of a single “LGTM” from a reviewer who might have spent three minutes glancing at diffs, we have evidence of real-time collaboration between multiple engineers throughout development. Many teams maintain logs of pairing sessions, recording who worked together on which features, capturing the continuous review that happened during development rather than after.
Test Coverage and TDD Artefacts demonstrate verification at the most granular level. When tests are written before code, the test commits provide evidence of design thinking and verification criteria being established upfront. Our test suite becomes our specification, our verification plan, and our regression safety net, all timestamped and version-controlled. Mutation testing reports show not just that tests exist, but that they actually verify meaningful behaviour.
Security Scanning Integration shifts left into the development process. Instead of hoping a reviewer spots a SQL injection vulnerability in a PR, tools like static analysis, dependency scanning, and secret detection run on every commit. The evidence isn’t someone’s approval. It’s automated verification results, traceable to specific commits, showing exactly what was checked and what was found.
Architecture Decision Records (ADRs) and design documentation become more important than retroactive PR descriptions. When architectural review happens before implementation, we have timestamped documents explaining the design rationale, alternatives considered, and safety/security implications evaluated. This is far more valuable to auditors than PR conversations that happen after the code is already written.
Traceability from Requirements to Code becomes explicit and automated. In trunk-based development with good tooling, every commit references the requirement or story it implements. Our version control history becomes a direct, unbroken chain from regulatory requirement through implementation to verification. No PR needed to establish that link.
Deployment Gates and Release Approvals provide the control points that matter. Instead of approving individual code changes, we approve releases that have passed comprehensive automated verification. The evidence package for a release includes: all tests passed, all security scans clear, all required pair programming sessions completed, all acceptance criteria met. This is where human judgement should focus: on the fitness of a complete, verified release, not on reviewing individual diffs.
When an auditor asks “How do we verify code quality?” the answer becomes:
“Every line of code that reaches our main branch has been developed collaboratively through pair programming, has comprehensive automated tests written before the implementation, has passed static analysis and security scanning, and has been continuously integrated and verified. Here are our CI logs, pairing session records, test coverage reports, and release verification checklists. We don’t rely on end-stage human review because we build verification into every step of development.”
That’s a stronger compliance story than “Someone clicked approve on the PR.”
The shift is from inspection artefacts (PR approvals) to verification artefacts (tests, scans, collaboration evidence). Auditors who understand modern software development recognise that comprehensive automated verification plus real-time collaborative development provides far stronger evidence than post-hoc manual review.
The Path Forward
Let’s be clear: pull requests are not a valid teamwork model for building quality software in regulated environments. The entire premise of writing code in isolation and throwing it over the wall for post-hoc review contradicts everything we know about effective collaboration and quality assurance. PRs might have a narrow role for external contributions from untrusted sources, but for core team development, they represent a fundamentally flawed approach that optimises for the appearance of rigour whilst delivering neither quality nor compliance.
We must recognise that clicking “approve” on a PR is not the same as building quality into our software, and checking a compliance box is not the same as satisfying regulatory intent.
The answer requires shifting from quality-as-gate to quality-as-foundation:
Invest in social programming
Shorten quality feedback loops via Continuous Integration and Continuous Delivery
Embrace test-driven development and implement comprehensive automated testing that runs continuously
Create architectural review practices that happen before implementation
Build cross-functional collaboration into daily development workflow
Train teams on the actual regulatory requirements, not just the process checkboxes
Measure effectiveness of verification, not just completion of review steps
Regulators don’t care about our LGTM count. They care whether our software is safe, secure, and fit for purpose. It’s time our development practices reflected that reality.