10x Faster Change Management. Compliance Included. — Mirage Engineering<br>← back to archive<br>posts / 10x-change-management.md

infrastructure

In the last year we increased the throughput of code changes by 146%, adjusted for headcount. You don’t break that kind of sound barrier without a few things breaking. We had to revamp our architecture, development process, release tooling, and more.

After doing all of that, one problem remained: human review.

As part of SOC 2 CC8.1, we need an auditable change management process. Changes must be authorized, tested, approved, and deployed in a controlled way. In practice, that means human review, or at least controls that prove no single person can unilaterally ship risky changes to production.

SOC 2 CC8.1

“The entity authorizes , designs, develops or acquires, configures, documents, tests , approves , and implements changes to infrastructure, data, software, and procedures to meet its objectives.”

Our default pre-AI policy was simple: an engineer signs off on every pull request. As our throughput nearly doubled, that became a real bottleneck. We were shipping faster than ever, but the approval queue meant PRs sat waiting for a human to context-switch, review, and click the green button.

So we asked ourselves: is there a better way? One that maintains compliance, that we actually feel good about, and that doesn’t slow us down?

After working through it with our auditors at Richey May, we landed on a policy and technical plan:

Define which parts of our codebase are high-risk and which are low-risk.

Low-risk changes get reviewed by an AI code reviewer and can merge when there are no remaining blockers.

High-risk changes still require a human reviewer who is not the PR author.

Every AI-approved merge gets retroactively reviewed by a human on a weekly basis, covering the full population (not a sample). This acts as a catch-all in case there are gaps in automation that we then use as feedback to iterate on our tooling.

All of this is codified in CI/CD scripts so the process is auditable and not prone to human error.

Below is a redacted version of our change management policy, the classification logic, and the GitHub Actions workflows that enforce it.

How Risk Classification Works

The core idea: not all code changes carry the same risk. A copy change to a dashboard label is different from modifying authentication middleware or network infrastructure.

We use dorny/paths-filter action to classify every PR at open time and as the PR evolves. If the changed files touch any of the paths on our high-risk list, the entire PR is classified as high-risk and requires human approval. Everything else is low-risk.

Here’s a condensed version of our classification criteria:

high-risk:<br>- '**/*.tf' # Infrastructure<br>- '.github/workflows/**' # CI/CD pipelines<br>- '.github/CODEOWNERS' # Access control<br>- '**/Dockerfile' # Container definitions<br>- '**/env.ts' # Environment config<br>- 'packages/tokens/**' # Auth tokens<br>- 'packages/contract/src/**' # API contracts<br>- 'packages/shared/drizzle/**' # Database migrations<br>- 'services/api/src/http/middleware/**' # Request middleware<br>- 'services/api/src/modules/Organizations.ts' # Tenant boundaries<br>- 'services/api/src/modules/CustomerEncryption/**'<br>- 'services/identity/**' # Identity service<br>- '**/package.json' # Dependencies<br>- 'pnpm-lock.yaml' # Supply chain

The classification criteria script and workflow are classified as high-risk. Changing what counts as high-risk requires human approval.

The SDLC Gate

Once classification happens, a CI workflow called sdlc-gate enforces the approval policy before merge.

The logic is straightforward:

For high-risk PRs:

Require an approving review from a human who is not the PR author, which is enforced via branch protection

Label the PR human-review

Remove any ai-approved label from previous runs

For low-risk PRs:

Require at least one approving review (human or AI reviewer)

If the AI reviewer approved, label the PR ai-approved

The labels matter. They create the audit trail that feeds into the weekly retrospective.

The AI Code Review

We use Claude Code Action running Claude Opus as our AI reviewer. When it runs on a PR, it reads the diff, leaves inline comments on anything it flags, and posts a summary comment with a recommendation: ✅ Approve or 🚫 Request Changes.

A separate step then reads that summary and submits a formal GitHub review on behalf of a dedicated reviewer bot. This is important for SOC 2: the approval needs to be a proper GitHub review event, not just a comment. The bot’s review is what the SDLC gate checks.

If the AI’s recommendation is ambiguous, “Conditionally Approve,” or anything other than a clear ✅ Approve, the system defaults to REQUEST_CHANGES. We’d rather require human review of a clean PR than let a questionable one through.

The Weekly Retrospective

This is the control that validates everything else.

Every Friday, a scheduled GitHub Action queries all merged PRs...