CI/CD Was Already the Point. AI Just Raised the Stakes.
Ask a team if they have CI/CD, and almost everyone says yes. Ask a follow-up question: "Does a red build actually stop a merge, or does someone click through it when they're in a hurry?" and the answer gets a lot less consistent.
That gap didn't matter as much when every change in the pipeline was written and reviewed by a person who understood the system. It matters now. If a meaningful share of your commits are AI-authored, or AI-assisted, your CI pipeline isn't a nice-to-have anymore. It's the only mechanical thing standing between a plausible-looking regression and production, because the human review step that used to catch it is exactly the step AI-assisted development tends to compress.
I built an EKS-based CI/CD pipeline for a real-time Linux C++ codebase in my last role: GitHub Actions triggering Docker containers with a Clang-based build environment, running the unit test suite automatically on every pull request. Nothing exotic about that setup. What made it worth building was the discipline behind it, every PR ran the same gate, nobody merged around a failure, and flaky tests got fixed or removed rather than tolerated. A pipeline that people route around when it's inconvenient isn't a safety net, it's a formality.
Where this actually breaks
Three ways I've seen CI/CD stop functioning as a safety net, all of them more dangerous now than they were five years ago:
Flaky tests get muted instead of fixed. Once a test fails intermittently for reasons nobody's chased down, the team's trust in the whole suite erodes, and eventually someone adds a re-run-until-green step or just skips it. Every skipped test is a blind spot an AI-generated change can walk straight through.
Coverage is wide but shallow. A suite that exercises every function once but never checks the actual behavior that matters (timing, ordering, edge conditions, the stuff a human reviewer used to catch by knowing the system) will happily go green on a change that's subtly wrong.
The pipeline gates the build, not the deploy. Tests don't pass, but nothing stops a bad merge from reaching production before anyone notices. In a codebase where the software is driving physical equipment, that gap is not theoretical.
None of this is new advice. It's the same advice good engineering practice has given for twenty years: automate the gate, make it authoritative, don't let anyone, or anything, merge around it. What's new is who's asking to merge. An AI coding assistant will generate a fix that satisfies a shallow test suite just as easily as a rushed human will, and it'll do it faster and more often. The pipeline that used to be a best practice is now the thing actually doing the reviewing when nobody has time to read every diff.
If you're not sure whether your CI/CD setup would actually catch a bad AI-generated change before it merged, that's a reasonable thing to find out before you lean harder on AI-assisted development, not after.