Common fallacies behind the AI productivity paradox
Three fallacies that keep teams shipping bugs as fast as they ship code
👋 Hi, I’m Thomas. Welcome to a new edition of Beyond Runtime, where I dive into the messy, fascinating world of distributed systems, debugging, AI, and system design. All through the lens of a CTO with 20+ years in the backend trenches.
QUOTE OF THE WEEK:
“it is comparatively easy to make computers exhibit adult level performance on intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception and mobility” - Moravec’s Paradox
We’re shipping code faster than ever. We’re also shipping bugs faster than ever.
That’s the AI productivity paradox. I’ve cited the research on this in previous posts, change failure rates doubling as coding agent adoption grows, so I’ll skip the charts this time. This one is for anyone who doesn’t need the data because they’ve watched the same failure pattern play out on their own (or someone else’s) team, over and over.
Here’s the pattern:
→ Auto-instrument everything via OTel.
→ The collector samples and filters some of it. Store what’s left.
→ A developer notices a bug. They copy-paste the error into a chat window, or query it through an MCP server, or fire up whatever proprietary AI companion came with their observability tool.
→ The AI gets incomplete, noisy context. It suggests a fix based on partial data.
→ A human reviews it. The code looks plausible. Deploy.
→ Discover the edge case the fix didn’t address. More bugs in production.
Every step in that chain feels reasonable. The outcome is a loop where AI writes code fast and fixes bugs badly, and the gap between those two speeds is where the paradox lives.
The loop persists because of a few fallacies that almost every team falls into.
Fallacy one: all you need is logs
This is the belief that volume substitutes for quality. Drop a thousand log lines into context and let the AI figure it out.
It won’t, because it isn’t a search engine. Agents don’t retrieve, they reason, and reasoning degrades fast when the input is noise. A model processing a thousand log lines gives equal weight to the garbage and the one line that matters. A human debugging the same issue brings years of context: they know which services are noisy and where in the stack the problem probably likely lives. The agent has none of that.
Fallacy two: fill the context window
This is the belief that bigger context equals better answers. Context windows keep growing, so the temptation is to use them: scrape everything, send everything, let the model sort it out.
In practice, most of the telemetry you scrape is statistically irrelevant. It will never explain a failure. Sending it to an agent gives it more to get lost in, and models demonstrably perform worse when the relevant signal is buried in the middle of a giant context. You’re paying for that degradation too. Models charge per token processed, and a firehose of telemetry is an expensive way to make your agent dumber.
Fallacy three: the MCP server solves it
This is the newest one, and it’s the belief that access equals curated data. Wire your observability stack to an MCP server, point your coding agent at it, done. The agent can query anything now.
However, an agent with API access to your observability stack inherits every limitation that stack was built with: sampled traces, missing request/response content, correlation that stops at service boundaries. It also inherits a new problem, which is that it now has to figure out what to query, in what order, with what parameters, across data that was formatted for dashboards and human eyes.
We learned this building our own debugging agent. The version with access to everything called the wrong tools, burned tokens, and produced fixes that missed the root cause. I wrote about what fixed it in the data curation post: the answer was doing the work of grouping, deduplicating, scoping, and formatting the data before the agent ever saw it.
Final thoughts
AI is inherently probabilistic. It predicts, infers, synthesizes. That’s exactly what makes it powerful for debugging: it can reason across a complex failure sequence in seconds where a human might take hours. But that same probabilistic nature means it needs something solid to reason against. Nondeterminism has to be anchored to something concrete, or you get confident fixes built on guesses.
An agent is only as good as the environment it operates in, and traditional observability platforms weren’t built for a world where humans and machines debug side by side. They were built as passive storage: dump the telemetry, sample to manage costs, query it when something breaks.
That paradigm is dead. The telemetry layer has to become an active participant instead: capture full-fidelity, pre-correlated session data at the source, cache it locally, decide dynamically what’s worth keeping when an anomaly hits, and structure it for machine consumption without losing clarity for the human reviewing the fix. That’s the architecture that closes the bug-to-fix loop, and it’s where observability is heading whether the incumbent platforms like it or not.
The fallacies above all share one assumption: that the data you already have is good enough, and the AI just needs better access to it. It isn’t, and it doesn’t.
💜 This newsletter is sponsored by Multiplayer.app, the debugging agent for developers.
📚 Interesting Articles & Resources
“What is “loop engineering?”” - Gergely Orosz
A full deep dive into this new trend, useful to determine if loops are (and will continue to be) genuinely useful to developers or if they are just a temporary hack while the harnesses added the ability to do the same from a single prompt.
“How to ship software with confidence - The Pillars” - Marcos F. Lobo 🗻🧭
Although I slightly disagree on how to actively fix bugs, I fully agree that “[…] when something is already broken, you need clarity more than anything else”. This is a good reminder to check foundational best practices within your team.
Thanks for the shout out!