AI Code CI/CD Gating: A Decision Tree for Blocking, Flagging, and Passing

You are the staff engineer on a team where AI-assisted commits now account for roughly half the pull requests. You have inherited a CI pipeline that was designed when every commit was hand-authored. The pipeline treats all PRs the same — same reviewers, same checks, same merge criteria. It is the wrong pipeline for the world you are in now.

The right pipeline has a triage layer at its entry point. Every commit gets routed, based on a small number of signals, into one of three lanes: pass (the default, cheap), flag (extra review, non-blocking), or block (no merge until specific conditions met). The goal is not to slow AI-assisted commits down. The goal is to spend reviewer attention where it has the highest marginal value — which is not uniformly distributed across commits.

This post is the decision tree for that triage. It assumes you already have provenance data on commits (see the trailer spec) and a SAST ruleset tuned for AI output (ruleset here). If you do not have those, start there first; the gating logic below is downstream of both.

The Four Inputs

Every commit entering the pipeline carries four signals the gate can read:

1. Provenance. From the AI-Assisted, AI-Tool, AI-Review-Confidence trailers. Present on every commit if you enforced the spec at commit-msg hook.
2. Blast radius. Derived from file paths and import graph. Does this PR touch the payment path, the auth path, a public endpoint, or a leaf-level utility?
3. Test signal. Unit test delta, integration coverage delta, and — critically — whether the tests themselves were AI-generated (from trailers on test files).
4. Ruleset findings. Output of the AI-tuned SAST ruleset, categorized by rule severity.

The gate logic below combines these four. You can implement it as a script reading the PR metadata, as rules in your existing platform (Reviewbot, Graphite, native GitHub Checks), or as a dedicated bot. The control flow is what matters; the implementation is whatever your team can maintain.

The Decision Tree

  Commit enters pipeline
           │
           ▼
  ┌──────────────────────┐
  │ AI-Assisted: true?   │
  └──────────────────────┘
           │
     yes ──┴── no ──► pass (standard review)
           │
           ▼
  ┌──────────────────────┐
  │ Ruleset ERROR finding│
  │ unresolved?          │
  └──────────────────────┘
           │
     yes ──┴── no
           │         │
           ▼         ▼
       [BLOCK]  ┌──────────────────────┐
                │ Blast radius = HIGH? │
                │ (auth / billing /    │
                │  public endpoint)    │
                └──────────────────────┘
                          │
                    yes ──┴── no
                          │         │
                          ▼         ▼
                  ┌───────────┐  ┌─────────────────────┐
                  │ Review    │  │ Review-Confidence:  │
                  │ Confidence│  │ low?                │
                  │ = low?    │  └─────────────────────┘
                  └───────────┘             │
                          │            yes ─┴─ no
                    yes ──┴── no          │      │
                          │         │     ▼      ▼
                          ▼         ▼   [FLAG]  pass
                      [BLOCK]    [FLAG]

Four decision points, three outcomes. The tree is intentionally small — every added decision halves the reviewer’s ability to predict outcomes, which erodes trust in the gate.

The Three Lanes

Pass. Standard review, no AI-specific gate. Applies to hand-authored commits and to low-risk AI-assisted commits (small blast radius, high confidence, no rule findings). Pass lane should be ~70% of AI-assisted PRs on a healthy team. If it is below 50%, your gates are over-tuned and reviewer fatigue will follow.

Flag. Merge-able but marked. Adds one specific reviewer (usually the code-owning team lead), adds a PR comment listing the reasons, and increments a per-developer metric so patterns surface at retro. The flag lane is where most of the signal lives — these are the commits that compile and test fine but whose prior warrants a second look. Target ~25% of AI-assisted PRs.

Block. Cannot merge until the blocking condition is resolved. Resolution always requires a code change or an explicit override by a named human (who takes on-call responsibility for the commit). Block lane should be ~5% — any higher and developers route around the gate; any lower and the gate is providing no uplift over pass.

What Goes in Each Lane

Always block

• Any unresolved R-001, R-002, R-003, R-004, R-005, R-009, R-010 finding (see the ruleset post for definitions). These have no legitimate passing case.
• Any commit touching the auth or billing path with AI-Review-Confidence: low. A developer who said they weren’t sure about the code shouldn’t be pushing it into the highest-consequence blast radius without a second author.
• Any commit adding a new dependency flagged as CVE-affected (R-008 ERROR tier).
• Any commit where tests are AI-generated AND the code under test is AI-generated AND blast radius is HIGH. This is the “self-marking homework” case — no independent verification anywhere in the loop.

Flag (don’t block)

• AI-assisted commits touching high blast radius with AI-Review-Confidence: medium or high. These want an extra pair of eyes but the author has signaled confidence.
• AI-assisted commits with AI-Review-Confidence: low in any blast radius. Low confidence is the single highest-signal per-commit indicator — always worth a second look, even on low-risk paths.
• Commits adding AI-generated tests for human-written code, or human-written tests for AI-generated code — but not both being AI. One independent side is usually enough; flag rather than block.
• R-006 (error leak) or R-007 (missing validation) findings — review-gated rather than block-gated.
• First AI-assisted commit from a developer who hasn’t produced one before. One-time flag so reviewers can calibrate to the pattern.

Pass (route through standard review)

• Everything else. Especially: AI-assisted commits with small blast radius, high confidence, no rule findings, and independent tests. This is the modal AI commit on a well-run team and should not be distinguished from a hand-authored commit at this stage.

Blast Radius in Practice

“Blast radius” is the term that does the most work in the tree and the one most likely to rot if not defined concretely. For this gate:

HIGH = touches any file in the auth module, the billing/payments module, the session/token handling path, a public API endpoint (anything routable from the internet), a cryptographic primitive, or a file marked CODEOWNERS: security-team.

MEDIUM = touches shared internal libraries, infrastructure-as-code, CI/CD pipeline definitions, or any file in a module marked CODEOWNERS: platform-team.

LOW = leaf-level features, UI-only changes, documentation, test-only changes, and internal tooling.

Code-owners-based classification is the most durable because it outsources the decision to the teams who know their own module’s criticality. Path-based heuristics (“any file in /auth/”) work on day one but drift as the codebase evolves.

Compute blast radius in the gate from the list of changed files plus their direct import dependents one level deep. Going deeper adds noise; stopping at zero misses the “this utility is imported by the auth service” case.

Override and Accountability

Every block lane must have an override path, because uniformly blocking on rule findings without human judgement will eventually stall a legitimate hotfix. The override has three requirements:

1. Named human. The override commit carries a Gate-Override-By: trailer identifying the person.
2. Written justification. Minimum one sentence. Appended to the PR, stored with the commit.
3. On-call exposure. The override-er is automatically added to the on-call rotation for that commit’s blast radius for 48 hours. If the override was wrong and breaks in production, they are the one who gets paged.

This is the accountability loop that makes the gate credible. Without it, overrides become performative and the block lane collapses back into the pass lane within a quarter.

What This Replaces

Teams often build one of two shapes of AI gating before converging on something like the tree above:

The permissive shape. “AI-assisted commits just need an extra reviewer approval.” This scales linearly with PR volume, eats a disproportionate share of the senior reviewer’s day, and provides no differential signal — everything gets the same second look, including the ~70% that didn’t need it.

The restrictive shape. “AI-assisted commits can’t touch prod paths without a security team sign-off.” Looks rigorous; in practice, developers learn to omit the provenance trailer. The gate’s input signal degrades to zero over a few weeks, and you’re back to the human-authored baseline with worse morale.

The decision tree above sits between these. It uses provenance as a routing signal, not a punishment signal. High-confidence low-risk AI commits flow through at the same speed as hand-authored ones. The commits that warrant attention get attention, calibrated to the actual prior, with override paths that preserve velocity when the prior is wrong.

Pairing with Your Quality Gates

The decision tree above is an AI-specific overlay on top of your standard CI/CD quality gates. Those gates still fire for everyone — lint, type check, unit test pass, coverage threshold, no flaky tests, semantic versioning on public APIs. The AI triage layer runs after those gates pass, and only for commits with provenance indicating AI involvement.

Keep them separate. A merged gate where “coverage below threshold” and “AI-assisted with low confidence” both raise the same signal makes both harder to interpret. Two gates in series, each with a clear remit, stays legible as the system grows.

The dial you tune quarterly is not the tree itself — the tree stays stable — but the thresholds: which rules are ERROR vs WARNING, which paths are HIGH blast radius vs MEDIUM, and what the override rate tells you about whether the gate is helping or hurting. Those numbers move; the structure does not.