I'm joining this panel 👇 today and I'll be bringing a slightly uncomfortable perspective. 👀 Looking forward to an honest conversation with Jon Haddad, Michele Mancioppi, and Amy Tobey about what it takes to make agentic observability actually work.

📅 Today, Wed, 18 MAR 2026 🕘 10:00 AM PDT | 1:00 PM EDT | 6:00 PM CET A panel on agentic observability with @tomjohnson3.bsky.social, @rustyrazorblade.com orblade.com, @michele.dash0.com, and @renice.bsky.social Hosted by @dash0.com and @leaddev.com Save your spot: leaddev.com/event/a-blue...

System-first o11y has its function, but more and more devs are realizing that effective debugging requires a session-first approach with a single timeline that correlates: • User interactions • Console errors • Network req/res • Backend traces and spans

This chart should scare you👇. 96% of developers don't fully trust AI-generated code, yet only 48% always review it before it ships. Sit with that for a second.

First time speaking at a @cncf.io event. If you're going to be in Minneapolis, let's connect. ☕️👇 My talk will be all about the hard lessons from moving an MCP server into production and how to design for AI agents and effective debugging. Full schedule: observabilitysummitna26.sched.com

If your team isn’t discussing Spec-Driven Development or how your design decisions are documented, versioned, and shared, you’re undermining your AI tooling strategy.

AI agents (especially when running in parallel) don’t operate well on vague intent. They need precise, well-reasoned specifications to make consistent decisions.

Most engineers tune out when they hear “system design.” It feels like overhead. Until AI forces you to care about it.

If your data is scattered across tools, aggressively sampled, and missing payloads … AI can't magically correlate it for you. You're automating a broken workflow.

Reading and understanding someone else’s code is significantly harder than writing code yourself. AI-generated code is, in every meaningful sense, someone else’s code.

Adding AI to legacy observability practices won't make debugging faster. It'll just amplify the problem.

Built an MCP server recently? Did developers actually use it, or is it collecting dust? 😵 I'll be speaking at @leaddev.com (June 1-2) about why "connecting AI to everything" doesn't work and what actually does when building tools that move from assistants to autonomous agents. See you there? 🇬🇧

▶ Reading unfamiliar code is exhausting. Now imagine that code is coming from an LLM that writes faster than you can think and doesn't take lunch breaks ◀ The AI productivity paradox: code is written faster than ever, but humans can’t keep up with manually reviewing it (or debugging it)!

Debugging AI-generated code is annoying (and time consuming). Debugging AI-as-a-runtime-component is a completely different problem.

Teams that fix the data correlation problem ship faster and debug smarter. But what exactly is it? It’s when debugging (understanding what went wrong) takes longer than fixing because the information is in a bunch of different places: Sentry, Stripe, LogRocket and several APM tools.

Traditional software: `Input A → Output B` (always, reliably, debuggably) AI-generated software: `Input A → Output B... or B', or B'', or sometimes C` That’s why 👆 debugging AI-generated code is tricky.

Five screenshots. Three 'can you also send...' messages. Twenty minutes later, you finally have enough context to start debugging. Have you ever had (or witnessed) a similar conversation in Slack? 👇

Agreed. AI excels at pattern recognition (code review, static analysis) and iterative debugging when it has the *right context*. That's the key: what you feed them. AI debugging works when you give it complete context: user session replays, full traces, request/response data, runtime behavior.

AI debugging is great... until you hit the context bottleneck. In particular, you need runtime data: what the user did, what the backend processed, what came back, etc. Without that, you're indeed getting vibes, not diagnosis or solutions.

Marc Donner: “Of all my programming bugs, 80% are syntax errors. Of the remaining 20%, 80% are trivial logical errors. Of the remaining 4%, 80% are pointer errors. And the remaining 0.8% are hard.” This sentiment is surprising relevant for AI tools.

I’m joining a panel tomorrow on agentic observability and AI-powered troubleshooting. I’ll be speaking with: • Michele Mancioppi (Dash0) • Amy Tobey (Netflix)

We've been experimenting with AI coding tools at Multiplayer for the past year: Copilot, Cursor, Claude Code, Codex. All impressive. All with the same fundamental limitation. They excel at the "write code" part. They struggle with the "understand what's actually happening in production" part.

The correlation overhead is often underestimated. When you're debugging a race condition like the payment example here, the manual work of correlating timestamps across RUM, APM, and logs can easily add 30-45 minutes per issue. And that assumes you know what you're looking for.

It took a little bit to gain traction after it’s release but the MCP saw a boom in adoption last year. But it’s not all roses, in fact, most MCP servers are collecting dust. Here's what we learned building Multiplayer's MCP server after watching this play out: 🧵

If you tried Multiplayer but didn’t finish setup, I’d love to learn why. I’m building the only tool that gives teams full-stack session replays out of the box. All correlated, all AI-ready. But if getting there feels harder than it should, that’s on me.

[1/] This year our engineering team leaned into one conviction: AI will only be as good as the context it’s given. If my background in neural nets has taught me anything it’s that data is everything. That’s why our 2025 focus was about capturing the right data in the right structure:

Where are AI tools ✦augmenting✦ our work, and where are they ✦undermining✦ the craft that makes engineering effective? As CTO of a startup building with AI, I keep coming back to this question. I shared my thoughts in this LeadDev article 👇 leaddev.com/ai/are-smart...

Most teams already test their code, UI, and infra. But ask when they last tested their APIs (thoroughly) and you’ll get a hesitant pause. Bad news: that pause is expensive. Good news: this is preventable. Better news: what makes your APIs testable also make your systems more observable.

Logs aren't dead - they just need some love. Some excellent advice in this article:

Jules Verne might as well have been talking about debugging when he said: “Science, my lad, is made up of mistakes, but they are mistakes which it is useful to make, because they lead little by little to the truth.”

I’m joining a LeadDev panel tomorrow on a topic many teams are struggling with right now: how to bring AI into your systems without creating chaos, security holes, or unexpected costs.

Monitoring will always have its place. But modern distributed systems require more: you need immediate, surgical and complete visibility *across your stack* to fully understand system behavior.

A tiny bug. A big bank. Hours lost. Internal tools don’t get the same love as customer-facing products, but the pain of debugging them is just as real.

APIs are the front doors to our systems, and users expect them to just work. Automated API testing is how we guarantee that at scale. Here are a few proven best practices: 🧵

“Ambiguous screenshots”. It says it all, doesn’t it? @farisaziz12.bsky.social is describing the nightmare that of debugging vague support tickets, with blurry photos, no reproduction steps, and endless back and forth.

Does debugging support tickets look like this for you? If yes, share the latest rabbit hole you fell into.

I’ve spent the better part of the past year working with the OpenTelemetry Collector to ensure our full-stack session recordings include automatically correlated backend traces. Here are the lessons I’ve learned (sometimes the hard way) about configuring the Collector 👇

👇 @farisaziz12.bsky.social describes the pain of customer support perfectly. It’s always exciting to see Multiplayer show up in real-world stories like this, as part of how engineers actually solve problems. Seeing it used to cut through the “screenshot chaos” is exactly why we built it.

"Effective debugging isn’t about speed. It’s about visibility and understanding. When AI has access to complete context, it becomes a real collaborator in that process." 👆 This is exactly why we built Multiplayer. 🤩

Optimizations don’t have to be flashy or complex and a 5-minute fix to our CI/CD pipeline saved us 5hr a day. This is a reminder that even the most obvious optimizations can hide in plain sight when you’re heads down building the next big thing.

A sneak peak of my presentation for tomorrow’s MCP demo night 👀 If you’re in New York - come say hi!

Claude Code error or human error? From the latest Anthropic blog post: variable names don’t match (red)…misspelling of urgent (blue) … unnecessary second check (second yellow line)

🧵 What is an “AI Engineer,” really? It’s one of the hottest job titles of 2025 but also one of the most misunderstood. Let’s unpack what the role actually means (and why it matters).

When your AI confidently ‘fixes’ production. Don’t worry, I’m sure it learned from this. 😅

Sometimes the frontend data isn’t enough. Sometimes (okay, always) you also want to know what happened in the backend.

This is a good time to remind everyone of the AI Darwin Awards. 😆

Devs: I’ll just make a small change. QA tickets: 🐶🐶🐶🐶🐶🐶🐶🐶

MCP servers are everywhere right now. But most are collecting dust. The key lesson we’ve learned at Multiplayer: scope matters. 🧵

I repeat. DON’T UPVOTE. I don’t care about that. I just want to hear your feedback: 👉 Would you use this mainly for debugging, testing, or feature development? 👉 Have you tried session replays before? What worked, what didn’t?

I repeat. DON’T UPVOTE. I don’t care about that. I just want to hear your feedback: 👉 Would you use this mainly for debugging, testing, or feature development? 👉 Have you tried session replays before? What worked, what didn’t?