Systems | Development | Analytics | API | Testing

We’ve gotten used to understanding our applications through signals, summaries, and traces. Tiny little bits of information about how the app really works. Not because that’s the best way to do it, but because it’s been too hard to get the real thing. The real information exists. It’s on the network. How people called your app and what your code did. What other systems it called, the database queries it made, and the result sets that came back.

Every enterprise contract I’ve signed in the last two years has the same clause. “Vendor will not use Customer Data to train machine learning models.” Sometimes it’s a paragraph. Sometimes it’s a whole section. The language varies but the intent is identical: don’t feed our production data into your AI. I get it. I sign the same clause as a vendor. But here’s what’s been bothering me: that clause is a promise, not an architecture.

Spring Boot version upgrades—whether moving from 2.x to 3.x, 3.x to 4.x, or even minor bumps like 3.2.5 to 3.3.1—regularly introduce subtle, breaking changes that unit and integration tests miss. JSON serialization shifts, autoconfiguration reordering, and transitive dependency conflicts can silently alter your API contract.

The rise of AI-assisted coding has transformed how software is built. With tools generating entire features in seconds, the bottleneck is no longer writing code—it’s verifying it. Because AI can generate boilerplate and handle API integrations instantly, more service changes are being pushed into authentication logic, API calls, and configurations. Teams desperately need a way to verify these changes before merging, especially when the code touches external dependencies.

Here’s a problem I run into constantly: something breaks in production, I can see the 500 errors in my logs, but I can’t reproduce it locally. The trace shows me the dependency graph but not the actual request that failed. This is especially painful in microservices. I was looking at a CNCF example the other day (a simple demo app, like 4 pods) and it already had so many cross-service dependencies that understanding what broke required looking at the whole system at once.

Everyone wants an AI agent factory in 2026. Autonomous agents fixing bugs and shipping features while you sleep. I’ve been building toward that myself. But the error rates don’t support the fantasy. The best AI coding agents in the world fix about 50% of real bugs on SWE-bench verified. Half the time they fail. And AI-generated code produces 1.7x more issues than human-written code.

The Observability Gap shows up the moment you try to reproduce a production bug locally. Your traces tell you a request was slow. Your logs tell you which line printed. Neither tells you what was actually on the wire: the headers, the JSON body, the surprise field your client started sending last Tuesday. Until now, closing that gap meant SSHing to a node, attaching a debugger, or shipping a sidecar through change review.

We’ve been building an AI agent that can take a production bug, find the root cause in captured traffic, write a fix, and validate it before a human reviews it. We call it Agent Factory. Last week we ran it on ourselves, against a real bug in our own production service. The first thing we did was get the workflow wrong.

This is Part 2 of the AI Software Factory series. In Part 1, we established that the Agile methodology is buckling under the weight of “elastic code.” When AI agents can generate functionality in seconds, two-week sprints and manual task management become organizational bottlenecks. We introduced the concept of the AI Software Factory: a shift from managing human tasks to managing business intent through a “Funnel of Increasing Trust.” But a factory requires infrastructure.