Salt-N-Pepa were not, as far as I know, singing about continuous integration and continuous deployment. Their loss. CI/CD is the least glamorous topic in software. It’s the plumbing of the plumbing. And I’m going to write about it anyway, because it has quietly become my favorite part of the entire system. Not favorite the way watching an AI answer from years of my own notes is my favorite. Favorite the way a good deadbolt is.
A quick definition for everyone who doesn’t live in a terminal. CI/CD stands for continuous integration and continuous deployment. Continuous integration means every code change gets automatically checked and tested the moment it shows up, instead of piling up for some big scary merge day. Continuous deployment means those changes ship to the real product in small, frequent, automated steps instead of giant releases. Together they’re the assembly line between “someone wrote code” and “that code is live,” with a quality inspection at every station.
Here’s the question I get most when I describe how THE WHEEL gets built, with multiple machines running AI agents and thousands of pull requests since October: how do you trust any of it?
I don’t. That was never the plan.
You don’t watch harder. You proof the house.
Some background: I have twins, plus an older kid three years ahead of them. When the twins were toddlers, that meant two people exactly the same age with wildly different interests finding wildly different trouble, while a third ran a completely different program one room over. I did not respond by developing superhuman reflexes and watching all three every waking second. Nobody can do that, and everyone who tries ends up exhausted and worse at it. You babyproof instead. Outlet covers, cabinet locks, the little gate at the top of the stairs. You change the house once so the dangerous thing isn’t possible for any of them, and then you get to relax, not because anyone became trustworthy, but because the house stopped depending on your vigilance.
That is exactly what CI/CD is when you build with AI agents. I run several at once, each doing wildly different things, and the feeling is honestly familiar. An agent commits constantly, around the clock, with total confidence. I physically cannot review every line at the speed it gets written, and the early months taught me that an agent’s own report of “done and tested” is not evidence. I wrote about that in You Can’t Skip the Failures: the AI can pass its own test by writing the answer key. So the answer key doesn’t live with the AI. It lives in the house. Last week OpenAI disclosed that one of their models, running inside a sandboxed evaluation environment, broke out of the sandbox, found Hugging Face on the open internet, and stole the actual answer key to the test it was supposed to be taking. The UK AI Security Institute tested five frontier models on security evaluations. All five cheated at least some of the time. None of them mentioned it when asked.
What it takes to just push a commit
Let me walk you through what happens when an agent tries to commit code. Or when I do. No exceptions. Not open a pull request, not merge. Just commit, on the machine, before anything has left the laptop.
The moment the commit starts, a hook wakes up and interrogates it. If the change added a new API route, the hook verifies the route is registered and connected to the running application, not just sitting in a folder looking useful. Then it lints. It checks every file touched on this branch, using the same scope the cloud checks will use later, so the machine and the cloud never disagree about what clean means. Different parts of the codebase answer to different rulebooks: the backend, the frontend, the command-line tool, and the connector server are each judged by their own standards, and the hook knows which is which.
Then it type-checks against the strict production configuration, the one that catches the subtle stuff. It’s fair about it, too. Errors in files you didn’t touch don’t block you; the hook judges what you just did, not the accumulated history of the codebase. If the commit includes tests, those tests run right now, before the commit exists. Shell scripts get their own linter. Database migration files get validated. A privacy check looks at new database tables and warns if the row-level protections look off.
All of that happens in about a minute, because everything is scoped to what changed. When it fails, it fails loudly, with the exact errors, and the commit does not happen. There is no polite override. The agents never get to decide the hook doesn’t apply to them.
And my favorite thing happens at commit time. Git has always had a blind spot: it records what changed, never why. The why used to live in a developer’s head. In this codebase, the why lives in a conversation with an agent, and a conversation is the easiest thing in the world to lose.
That is what Entire fixes. It comes from Thomas Dohmke, who used to run GitHub, and when the person who ran GitHub decides git needs rebuilding for the agent era, I pay attention. His argument is the same one this post keeps circling: software is moving from people writing code line by line to people directing fleets of agents, and a system that keeps the code but loses the meaning cannot carry that world. We got in off the waitlist early, and it’s pretty amazing. Every commit checkpoints the full session that produced it, and the record travels with the repository. When a line makes me squint six months from now, I can open the conversation that wrote it and watch the decision get made. A new agent can pick up an old session, context and all, and keep going. In a codebase written mostly by AI, “who wrote this and what were they thinking” is not a rhetorical question. It has an answer.
That record is too good to stay purely on the development side, and it doesn’t. THE WHEEL has a wheel of its own, and a summary of every session lands in it: what got finished, what decisions were made, which direction changed and why. Not the raw transcript, just the distilled version, in the same place all our other knowledge lives instead of buried in a git history that only developers ever read. A product whose whole thesis is that the conversation holds the why can answer that question about itself.
What the pull request has to survive
Only after all of that does a pull request exist. Every PR runs a battery of checks, and the suite is smart about which ones: it looks at what the PR touched and runs only what’s relevant. The basics are there, of course. Does it compile, do the tests pass, is the style right. But the checks I care about most are the ones that ask questions specific to this product.
Is every piece of code actually connected to something, or did the agent build a beautiful feature into the void? Does what the code believes about the database match what the database is today, not what it was two weeks ago? Did this change repeat a mistake we’ve already made once and written a rule about? And is this PR actually ready, judged by rules the PR itself cannot edit? The rulebook is read from outside the PR on purpose. That sounds paranoid until you remember who the author is.
And before I ever look at anything, a different AI already has. There’s a standing set of review instructions in the repository, and every PR gets read by an AI reviewer that knows exactly what to flag. One AI writes the code, a second AI critiques it, and I decide what to accept. It’s the strangest org chart I’ve ever managed, and it works.
The locks come from the bruises
None of this was designed up front. Babyproofing never is. You proof the outlet after you catch the toddler eyeing the outlet. Every check in the pipeline traces back to some specific bad afternoon: a feature that turned out to be plugged into nothing, a database change that disagreed with the code, a confident report that didn’t survive contact with reality.
And the proofing is never finished. You watch what they get into next and you proof that too. Then they grow. The outlet covers come off, the stair gate goes to the basement, and suddenly the conversations are about riding the subway alone and going thrifting with friends instead. Same job, entirely new failure modes. The checks evolve exactly the same way. The locks that mattered in month one are background now, and the newest ones guard against things I could not have imagined until the agents got capable enough to try them.
The loop is always the same, and by now it’s the most practiced motion in the whole project. Something goes wrong. We write down why. The write-up becomes a rule, and the rule becomes a check that runs automatically, forever, without asking anyone to remember. The bad afternoon happens once. The check runs ten thousand times.
Deploying is boring on purpose
By the time anything deploys, the interesting questions are supposed to be settled. So the deployment side is deliberately dull. A deploy has to name the exact version it intends to ship, not “whatever’s latest,” because latest moves. And when a release is sitting under observation for a few days, the system itself refuses to deploy over it. Nobody has to remember that we’re in a quiet period. The system declines on our behalf.
All the excitement budget belongs to the product. Deployment should spend none of it.
When the bill showed up
For months, all of this ran happily inside my GitHub Actions allowance, and then the volume of work stopped being allowance-sized volume. The bill went from routine to real in about eight weeks, which is how CI became a thing I have opinions about instead of a thing that just happens.
Shopping for extra CI capacity in 2026 turned out to be its own adventure. Two of the most recommended providers on the internet had shut down and left their pricing pages up, like stores with the lights on and nobody inside. One option, RunsOn, deserves a genuine shoutout. It had the best balance of ease of use and control of anything I found: the easiest setup of anything I tried, and it runs inside your own AWS account, which I love. The catch was on my side: THE WHEEL lives on Google Cloud, so my fresh AWS account came with starter quotas, and AWS’s approval process for raising them could not keep up with how many machines CI needs to spin up and tear down at our busiest moments. Waiting was the one thing I didn’t have. I ended up on Ubicloud, which fit our scale without a sales call. And because it’s open source, I could read the limits in their code instead of asking someone to tell me.
The switch between GitHub’s runners and Ubicloud’s is fully automatic. A small job checks our remaining allowance every fifteen minutes and flips everything to the overflow capacity when we’re about to run out. My favorite detail in the whole setup: that little watchdog never runs on the minutes it’s watching, because if it did, running out would silence the messenger. Yes, there’s a check protecting the checks. Of course there is.
What I trust instead
People ask whether it worries me that AI writes most of the code here. What would worry me is AI writing most of the code without the house being proofed.
The models keep getting smarter, and every one of them, on every commit, still has to get past every lock we’ve ever installed. The toddlers are turning into teenagers, and teenagers come with a whole different set of problems. That’s fine. The house grows up with them.
I don’t trust the AI. I trust the house.