CircleCI just analyzed 28 million CI/CD workflows. Twenty-eight million. And the results are genuinely alarming if you’re paying attention.
Daily workflow runs jumped 59% year over year. That’s the biggest throughput spike they’ve ever measured. AI is clearly generating more code than ever before. But here’s where it gets ugly. The top 5% of teams doubled their throughput. The median team? Up 4%. The bottom quartile? Literally zero improvement. And the median team’s main-branch throughput actually declined 7%.
Let that sink in. More code is being written. More workflows are running. But less code is making it to production for the average team. Success rates hit a five-year low. Recovery times are climbing. Martin Fowler nailed it when he said most organizations are treating AI as a coding tool rather than a systems transformation.
So what separates the teams that doubled their output from the ones treading water?
I think I know. And it’s not what most people want to hear.
The guardrails problem
What I’ve seen over and over again, across companies of every size, is that most teams don’t have the right structure to scale their code. They just throw in whatever works. Person A works on feature X, so they’re cramming logic into this class, that class, wherever it fits. No clear responsibilities. No structure. They don’t follow any of the well-known patterns. Transaction script, active records, domain models, hexagonal architecture, onion architecture, clean architecture. They don’t care. They just add the logic and move on.
It gets messier and messier. The team gets less and less comfortable rolling out changes. Product owners are unhappy. Team managers are unhappy. Velocity drops every sprint. Nobody really understands what’s going wrong.
And now AI is doing the exact same thing. It complies to the already existing codebase. If your codebase is a mess, AI will generate more mess. Faster. At scale. Congratulations, you’ve automated chaos.
This is exactly what the CircleCI study shows. The teams that were already terrible are still terrible. Only the best performing teams doubled their throughput. And one of the key reasons is they have the right guardrails. They have structure. They know which logic belongs where.
This is the part where humans still play a critical role. You need to enforce good software engineering patterns inside a codebase. Otherwise, things go downhill fast. AI won’t save you from bad architecture. It’ll accelerate you straight into the wall.
This isn’t new. AI just turned up the volume.
Here’s the thing. This was the same story before AI showed up. When juniors started developing like crazy, I saw the exact same pattern. Back in 2018, there was no AI assistance, and it was still a miserable place to be. I’ve seen files with 10,000 lines of code. No structure at all. No clear responsibilities. People were just getting paid to ship features. Nobody cared about software engineering because that’s not where you get rewarded.
But if you take a closer look, you’re shooting yourself in the foot every single time. And now AI is turbocharging that behavior. This is what we see in the data. The highest performing teams have good guardrails. That’s why they ship so fast. Not because they have fancier AI tools or bigger budgets. Because they have discipline.
Testing is where AI actually shines
The next thing that separates great teams from struggling ones is testing. Good teams aren’t afraid to ship new features because they have all the testing in place. Unit tests. Integration tests. End-to-end tests. Even performance tests. They ensure that with each feature, they don’t break existing behavior. And for new features, they add tests to confirm the logic they think they wrote is actually the reality.
This is where AI genuinely accelerates things. You don’t have to waste hours writing tests anymore. You write a prompt, review the results, check if the tests are doing what you expect, and if not, you correct them in plain English. Instead of burning hours on test boilerplate, you’re down to minutes. The test coverage goes up, the confidence goes up, and the team ships faster because they’re not terrified of breaking something.
But notice the prerequisite. You need clear boundaries to have testable code. If your codebase is a 10,000 line spaghetti monster, no amount of AI-generated tests will save you because there’s nothing clean to test against.
Deployment isn’t optional
Good teams have a staging environment, a development environment, and a production environment. Each of these environments runs the tests. They have a solid rollout process. Canary deployments. No big bang releases. Test on a couple of users first. Be comfortable. If something breaks, you roll it back with a very limited blast radius. This isn’t rocket science. It’s just discipline that most teams skip because they’re „moving fast.“
The culture piece nobody wants to talk about
From a managerial perspective, this part is huge. The best teams trust each other and review pull requests fast. They comply to the rules. They have all the linting in place. Maybe there are custom linters. They don’t waste time arguing about variable names or where to move some logic. They don’t care about that stuff because they already have the structure. They trust each other. They have the rules established. They review pull requests in less than 10 minutes once created.
So they can ship. And they’re comfortable shipping because they have the testing in place to back it up.
On the other side, I see low performing teams constantly arguing. „We can’t deliver this feature. We need a refactoring first. We need to move this logic over there.“ There are always excuses for not shipping code.
In one of my most recent experiences, I asked a team for a feature. Less than 50 lines of code. Literally just an if condition. The team said they were too uncomfortable to deliver it. „It doesn’t scale. We don’t want to add new features. We hate our lives.“ I’m not exaggerating. That was the energy.
And AI is only encouraging that dynamic. If your codebase is already painful and your team is already paralyzed, AI-generated code just makes the pile bigger without making it better. That’s why the low-performing teams in the CircleCI study saw zero benefit from AI. The guardrails weren’t right.
So what do you actually do?
If you want to be in that top 5% that doubled throughput, here’s the playbook. It’s not sexy. It’s not about picking the right AI model or the fanciest coding assistant.
First, enforce architecture. Pick a pattern and stick to it. Clean architecture, hexagonal, domain-driven design, whatever fits your context. Just pick something and make sure everyone on the team knows where logic goes. This is the single highest leverage thing you can do.
Second, invest in testing. Use AI to write your tests faster, not to skip them. The teams that ship fast are the ones that aren’t scared of deploying.
Third, fix your deployment pipeline. Staging environments, canary deployments, fast rollbacks. If deploying feels scary, you’ve already lost.
Fourth, build trust. Review PRs fast. Establish clear rules and stop having philosophical debates on every code review. If you’re spending 30 minutes arguing about naming conventions, your team has bigger problems.
The CircleCI data doesn’t lie. AI is a multiplier. It multiplies whatever you already have. If you have strong engineering practices, AI makes you fly. If you have chaos, AI gives you more chaos, delivered faster, with lower success rates and longer recovery times.
The question isn’t whether AI will transform software engineering. It already has. The question is whether your team has the foundation to actually benefit from it. For most teams right now, the honest answer is no. But it doesn’t have to stay that way.