Operations | Monitoring | ITSM | DevOps | Cloud

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.

Before I ever ran Claude in my terminal, I thought I already understood AI tools pretty well. Like most people, I had used ChatGPT, Google Gemini, and Perplexity for everyday tasks. Such as helping with schoolwork, organizing ideas, summarizing information, or getting through something faster when time was tight. They were useful, but they still felt separate from how real work happened.

Part of the motivation for this post is how cloud API economics are shifting: Anthropic is moving large enterprise customers toward per-token, usage-based billing (unbundled from flat seat fees), which makes “always call the API” a moving cost line for teams at scale. A hybrid or local layer is one way to keep spend bounded while you still use premium models where they matter.

The terminal is a developer’s most trusted tool. It sees your source code, your secrets, the commands you run in production. When a terminal adds AI and cloud features, it’s worth asking what it’s doing on the network.

The alert fires at 2 AM. Your observability platform’s synthetic test just failed. Login is broken. So you open your laptop, pull up the dashboard, and stare at a single red dot: the browser test. You know the problem is somewhere in the stack, but not where. Is it the auth service? The token validator? The user profile API? The API gateway timing out? You’re now about to spend the next 45 minutes correlating traces, tailing logs, and manually hitting endpoints until you find it.

The biggest risk to your product isn’t AI-generated code that doesn’t work. It’s generated code that seems fine. AI doesn’t optimize for correctness. It creates something passable. Something that passes the smell test. And when everybody in the industry is pushed to move faster and do more with less, you end up shipping software that looks correct. It passed your quick visual check. It passed all the tests. But no one ever fully understood it.

Every week there is another model drop, another agent framework, and another workflow tweak you are supposed to evaluate. Meanwhile, the largest companies, the ones operating at the highest scale and leaning hardest on AI, are also the ones making headlines for reliability strain: capacity limits, outages, and services that buckle under load.

Last week, a fleet of autonomous robotaxis in China suddenly stopped working—at scale. Over a hundred vehicles stalled across a city, stranding passengers in traffic and raising immediate concerns about safety, reliability, and trust in autonomous systems. This wasn’t just a bad day for self-driving cars. It was a distributed systems failure, one that happened in the physical world, not just in dashboards.