Phase 6: Quality Gates & CI/CD for AI Code · 40 min · Git · GitHub Actions · Python

Spec-Code Drift Gates in CI

A drift-check script someone might run is a discipline. A required CI status check that structurally disables the merge button is a control.

Hiring signal: Knowing that a CI check must be configured as a required status check to actually enforce anything — not just exist in the pipeline — is the exact configuration detail that separates real enforcement from a check nobody's forced to respect.

What you will learn

Distinguish an advisory CI check (informational, bypassable) from a required status check (structurally blocking)
Explain why wiring the drift gate into CI turns it from a discipline into an enforced control
Identify the specific configuration detail (required status check) that determines whether a failing gate can be bypassed
Simulate a CI merge attempt against both a required and a non-required drift gate configuration

Introduction

Spec-Code Drift Gates in CI

A team built the drift gate script from c12-01-4 — it works, it correctly flags a business-logic change that isn't matched by a spec update. For three months it catches real drift, every time someone remembers to run it locally before opening a PR. In month four, someone in a hurry skips it, ships a change that silently diverges from the spec, and the team is back to exactly the failure mode this course opened with in c12-01: a spec quietly lying about what the code does, because the one thing standing between "shipped" and "checked" was a person's memory on a busy day. The script was never the problem. Where it lived was.

From discipline to control

A check that exists as a script someone can choose to run is a discipline — useful when followed, silently absent when it isn't, and entirely dependent on nobody being in a hurry on the day it matters most. The same check wired directly into CI, running automatically on every single pull request with no human decision involved in whether it executes, is a control: it runs whether anyone remembers or not, on every PR, without exception. This is the exact same distinction c12-04-4 drew between an instruction ("don't touch production during the freeze") and a structural control (environment separation) — a drift gate that depends on someone choosing to run it is an instruction with extra steps, not a real control, no matter how well the underlying logic works.

Wiring the check into CI is necessary, not sufficient
Adding the drift-gate script as a CI job is a real improvement over a local-only script — it now runs on every PR automatically. But CI running a check and CI enforcing a check are two different things, and the gap between them is one specific configuration setting most teams get wrong the first time.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The setting that actually enforces anything, Same-commit enforcement, now automated, What "required" actually costs, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.