Quality Gates¶
The Assembly Line¶
Imagine a factory that produces medical devices. Every device that comes off the line goes through a series of quality checks before it can be shipped. One station verifies dimensions. Another tests electrical safety. A third scans for contaminants. If a device fails any check, it does not ship. It goes back for rework.
Nobody at that factory argues about whether quality checks are worth the time. The question is never "should we have checks?" It is "what checks do we need, and are they catching everything that matters?"
Software works the same way. Before any code change reaches production, it passes through an automated pipeline of quality checks. In the software world, this pipeline is called continuous integration and continuous delivery (CI/CD), and the concept is identical to the factory line: every change goes through the gates, and if it fails any gate, it does not ship.
What Goes Through the Gates¶
You can configure any number of quality checks on this pipeline. Here are the ones that matter most:
| Gate | What It Checks |
|---|---|
| Automated tests | Does the software behave the way the acceptance criteria say it should? Catches bugs, regressions, and broken features. |
| Security scanning | Does the code contain known vulnerabilities, exposed secrets, or insecure patterns? Catches security flaws before they reach users. |
| Code quality | Does the code meet minimum quality and maintainability standards? |
| Evals | If AI is making decisions inside your application, is it producing the right outputs? |
If every gate passes, the software moves to production. If any gate fails, it stops. There is no "let's ship it anyway and fix it later." The pipeline enforces the standard, automatically, every time.
This is how you take the bottleneck of reviewing the work from Lesson 1 and automate it. Instead of relying on a person to catch every issue, you define what the gates should check, and the pipeline handles the rest. You are establishing what must be true before software can leave the assembly line and reach your users' hands.
Why This Matters in Your Environment¶
In Making Speed Safe, we talked about how the best organizations in the world do not move slowly. They move quickly, with discipline. One of the key disciplines is establishing the bar for what is allowed to leave the assembly line, and the pipeline is what enforces it.
When your organization deploys software that people depend on for critical operations, the question is not "can we afford to have quality gates?" It is "can we afford not to?" Security scans detect vulnerabilities. Automated tests catch defects. Evals verify AI behavior. These are not optional extras. They are the mechanism that gives you confidence in what you ship.
And because these gates are automated, they scale with the velocity. When AI helps your teams produce changes faster, the pipeline keeps up. It checks every change, at the same standard, with the same rigor, regardless of whether a person wrote the code or AI did. That is the point: the quality standard stays constant even when the speed goes up.
The most advanced technology companies in the world have proven this works at scale. Organizations where AI produces the majority of the code still run every change through the same automated pipeline: tests, security scans, quality checks, and human approval gates. The pipeline is what makes it safe to move fast.
Wire Your Tests into the Pipeline
Mob | ~5 minutes total | Same machine that added the testing rules to the context file. Everyone contributes.
On the last page, you told your AI assistant to write automated tests for every feature. But when AI builds your testing framework, you do not control exactly how it sets things up. It might choose different tools, different file structures, or different test runners depending on your project. Those tests only help if they actually run before code reaches production. This prompt is your verification check.
Part 1: Verify your tests are wired into the pipeline. Send your AI assistant this prompt:
I just added rules to my context file telling you to write tests. Can you
make sure that all of our testing, both code logic checks and end-user
simulation verifications, is covered in our CI/CD pipeline? I do not want
any code to make it into production if tests fail.
Your AI assistant will review your pipeline configuration against whatever testing approach it set up on the last page. It may find everything is already connected, or it may find gaps and fix them. Either way, you now know.
Part 2: Understand what is already in place. Now send this follow-up:
Walk me through what is already in our pipeline. What checks run before
code reaches production? Explain each one, including any security
vulnerability scanning.
Take a few minutes to read through what your AI assistant reports. You will likely see automated tests, security scanning, code quality checks, and deployment steps already configured.
What you just did: We already built the pipeline infrastructure for this lab. Security scanning, code quality checks, and deployment automation are in place. What you just did was verify that the testing approach your AI assistant chose is actually checked by that pipeline. Now you have a complete assembly line: your acceptance criteria drive tests, your tests run in the pipeline, and nothing ships unless everything passes. You set the rules. The system enforces them. If something does not pass a gate during Sprint 2, that is not a failure. That is the system working exactly as designed.
Key Insight
Quality gates are how you ensure that only tested, secure, and verified software reaches production. Every automated test, every security scan, and every eval becomes a gate on the assembly line. Nothing ships until everything passes. The pipeline never takes a day off, never skips a check, and never lets something through because it is in a rush. That is how you make speed safe: not by slowing down, but by automating the discipline.