Why We Built Ballast

Over the course of two months in late 2025, every one of our clients went all in on AI in their development lifecycles. In every case, they dismissed our advice to take a cautious approach to the rollout. It's hard to blame them. Pointing Claude Code at a codebase and telling it to get to work feels like standing on the gas pedal. It's exciting and addictive, and in the moment it feels like it's worth pretty much any risk.

It didn't take long for the road to get bumpy. The clients who initially held tight to the ritual of manual code review found themselves with dozens of giant PRs stacked up for weeks. The clients that went straight to YOLO mode saw skyrocketing error rates, performance problems, and long-stable features suddenly failing in hard to explain ways. It was a busy time for us. Nobody wanted to take their foot off the gas, so our job was to try to find ways to keep the car on the road.

We built tooling and workflows that put more emphasis on planning, research, and quality control. We plugged in more robust error tracking and app analytics to keep a virtual eye on as much of the code as we possibly could. It helped. Things began to stabilize. The projects weren't as stable as they wre before the adoption of AI, but the failure rates and types became a reasonable price to pay for the increased velocity.

When we had some time to slow down and breathe, we started to wonder how much of the AI revolution in software development was real and how much was illusory. Are teams really moving faster in terms of useful, shipped features? Large companies like Uber were starting to question it themselves, in light of the skyrocketing cost. We started to wonder how we could actually measure it. Our exploration kept circling back to the old addage that good software is easy to change. We could fool ourselves into thinking we're shipping features fast if we didn't take into account how long it took them after we shipped them to become stable. Durable code is easy to change. New features hit production and stick the landing. Fragile code doesn't take change well. New features get reworked in QA tickets for weeks after they land.

Ballast started as a question on a white board in March: "Does shipping faster with AI always lead to more fragile code?" We sought out ways to measure fragility. Our criteria were simple: 1. It had to be deterministic and 2. It had to be back-testable. We wanted to be able to take something to our clients that would demonstrate that they were, in fact, introducing fragility into their applications by going all in on AI and, just as importantly, that the work that we were doing to mitigate that was working. Both statements felt right intuitively, but we didn't have actul data to back it up.

We landed on relative churn as the target of what we'd measure. In a 2025 paper, Microsoft found that higher relative code churn correlated to increased defect density. Our observation, when AI started becoming mainstream, was that work was taking longer to land. A feature would be shipped to production and the sprint closed out, but the code in that feature would continue to churn for weeks or months while the bugs were worked out. So we wanted to see if high relative churn could be used to predict future rework. In June, we got a Python scoring engine built that could do the job. It could crunch through the entire git history of any project, no matter how big or old, and score it at every moment of that history, checking that score against the rework that followed. We ran it against 70 popular open-source repos across several stacks and it held up. Higher relative churn is, in fact, predictive of future rework. And importantly, increased velocity does not always result in lower durability. We published the study and got to work on bundling it as a tool.

Ballast assigns a score on the FICO scale (300 to 850). We chose this scale because just like a FICO score is inversely related to the cost of borrowing money (the higher your score, the lower your interest rate), Ballast score is inversely related to the cost of changing code. The lower your Ballast score, the more expensive it will be in developer hours (and tokens, assuming you're using AI) to change your code.

Ballast also provides a map to the places in a codebase where changes struggle to stick the landing. Because it's fully deterministic and reads git history rather than the code itself, this map isn't swayed by human or AI judgment about the wisdom of a particular module's architecture. It just knows that the code that lands there bounces around a lot before it becomes stable. This gives us a huge advantage in rebuilding the stability of the app, because the problems it points us toward are often counterintuitive. Someetimes the problems lie in parts of the code that were lovingly crafted by hand. They're the parts of the app that we would be instinctively inclined to skip when seeking out detrimental technical debt. Which points to an uncomfortable truth: Human developers and AI agents are not slowed down by the same things, so the way we have always defined and thought about technical debt has to change if we're going to rely on AI heavily to build and maintain our software.

We've adopted Ballast as a core piece of our offering with clients. A fresh score is generated every time code is merged into the default branch, allowing us to identify when stability is starting to slip. We've built an MCP server that makes the risk map available to their coding agents, making it easy to plan targeted refactors on the parts of the application where code is struggling to settle. One of our ongoing projects is setting up an automation that will continuously monitor the risk map and propose work to improve durability, putting our clients' technical debt on auto-pay.

We still urge caution when clients propose adopting new AI tools and techniques in their development workflows, but with tools like Ballast, OurCVEs, Laravel Nightwatch or our open-source alternative Hone, we feel more confident in our ability to support our clients in their transition to this new way of working. We were early adopters and vocal skeptics of AI, and we think that combination has served us and our clients well. I've long said that we can't manage what we don't measure, and with Ballast in our toolkit, I feel like we're finally getting a really good handle on measuring the impact of AI on our codebases.