If you haven't yet, I highly recommend checking this collection of reference implementations for the Model Context Protocol (MCP). 👇

Most “session replay” tools show you what happened in the browser. Multiplayer shows you what happened across your entire stack.

I had the chance to speak at API World 2025 last week on a topic I’ve seen frustrate teams for years: API documentation. Because let’s face it: most developers don’t want to read static docs. Outdated Postman collections and PDF references slow everyone down.

Dashboards are great at showing symptoms: CPU is spiking, latency is up, error rates crossed a threshold. But when you need to understand why dashboards alone don’t cut it. 🧵

What’s more expensive: developing a new API or fixing a bug?

I wrote a feature that auto-generates a test script from a bug. Basically: run the bug once, never write that test from scratch again.

Most monitoring tools give you summary data about a crash. Very few help you see it in detail as if you had a dash cam.

Reproduced a bug that’s haunted us for weeks. Watching it unfold in a single timeline, with traces + request/response payloads + screens in one place… Is this what closure feels like?

I’m giving away $195. No catch. No crypto wallet required. Yes, it sounds like a scam. No, it’s actually a free pass to API World in Santa Clara, Sept 3–5. Want it?

Heisenbugs don’t disappear. They wait for demos.

Great API monitoring is knowing that when something breaks, you’ll know where, why, and how to fix it.

99% of debugging time is just trying to get the system to confess.

Is there a better compliment for an engineering manager?

If you only sample at the beginning of a request (head-based sampling), you might miss the error that happened at the end. Tail-based sampling is heavier, but smarter and increasingly worth the cost on critical paths.

The worst part of a flaky test isn’t that it fails. It’s that no one trusts it when it passes.

Hooked up a full-stack session replay to Cursor. Watching it suggest a fix with actual request/response data was… kind of magic.

The moment a bug enters production, every missing trace becomes a tax on your time.

Spent yesterday afternoon breaking the demo app in different ways and recording how we fix it with full-stack replays and AI-assisted suggestions. It was fun! 😆

In every system I've worked on, API integrations start out deceptively simple: a few endpoints here, a webhook there. But scale, uptime requirements, and changing business needs reveal the cracks fast. Here’s the summary of key API integration best practices I recommend every engineering team adopt

In distributed systems, the hardest part of debugging isn’t finding the bug. It’s figuring out whose responsibility it is to fix it.

An example of how established media gets things COMPLETELY wrong thanks to journalists not understanding what they write about. No, an "AI agent" you spun up is not by any means "employee." Do they have credentials (to eg allow accessing systems?) Sure! So do CI/CD services, infra services etc

Teams don’t lose as much time to bugs as to *debugging them*: • Context switching • Grepping through logs • Reproducing flaky issues

Multiplayer: "Don’t worry, we recorded their machine for you.” ▸ Here’s the full-stack session replay with the bug. ▸ Here’s the test script that reproduces it. ▸ Here’s what your AI tool suggests. ▸ Here’s how to fix it.

“Given enough eyeballs, all bugs are shallow.” That assumes two things: 1. Everyone can see the bug 2. Everyone sees the same thing In modern systems, both are not guaranteed.

The hardest part of debugging isn’t spotting the bug. Well, it is. But it’s not JUST that. It’s reproducing it. Understanding it. Explaining it.

Distributed systems obey three fundamental laws: 🔧 Murphy’s Law: If there is a wrong way to do something, then someone will do it. 🔥 Sod’s Law: If something can go wrong, it will 💀 Finagle’s Law: Anything that can go wrong, will, at the worst possible moment.

With this browser extension, we give engineering teams a fast entry point into distributed debugging: anyone can capture a bug directly from the browser, with full frontend and backend context.

I’ve seen first hand how much engineering time gets lost trying to reproduce bugs. What Multiplayer just shipped shortens the feedback loop between discovery and resolution, and it makes hard-to-reproduce bugs testable, explainable, and shareable. 👇 Check it out

How do you cope with the mounting pressure to reshape your technology roadmaps in response to AI?

Julian: If somebody says, "Oh, we're not releasing that because the documentation is not up to date," will the rest of your teammates laugh at you? Tom: Sure. Julian: I'm being sarcastic. Tom: But you've hit upon something …

Debugging distributed systems shouldn’t be this hard. At @gotocon.com Unscripted, I spoke with @julianwood.com about why it’s still such a pain and what we can do to fix it.

What can I say.. I'm subtle like that 😅

A slide from our latest webinar: our CTO @tomjohnson3.bsky.social subtly indicating his opinion on manual documentation 😆

Draw io doesn’t care that `auth-service`, `authService`, and `Auth` are the same component. Multiplayer does. System design isn’t just rectangles and arrows.

Every integration starts simple: 'It’s just a POST request!' And ends with 4 retries, 3 feature flags, 2 dead-letter queues, and 1 existential crisis.

The part I agree with is both devs, PMs and ever other techie does themselves a favour by using these tools yourself and getting hands-on experience on how they help you. And keep at it because they change (usually improve, rarely regress). And you want to become an expert on when to use them!

Your docs say one thing. Your system says another. Guess who’s lying?

Come for the AI talk, stay for the memes. 😆

If your diagramming tool can’t tell that `auth-service` and `authService` are the same component… …it’s not a system design tool.

My take on Kernighan’s Law: If debugging is (at least, but likely more) twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it without the right tools to help?

🧵Where should you invest: AI, Platform Engineering, or Developer Experience? Before you commit budget, start with a harder question: What does success actually look like? Let’s break it down👇

When you skip system design and go straight to shipping 😆

You’ve got 10 tabs open: one for traces, one for repro steps, one for the “docs” … sound familiar? I’m hosting a webinar in a few weeks on distributed systems - and I’m calling on the BlueSky community for some help. What are your biggest pain points with: 📚 System Documentation? 🪲 Debugging?

Friendly reminder: all complex systems that work evolved from simpler systems that worked.

Your Favorite Open-Source Project Might Be in Trouble #SuggestedRead #devopsish www.howtogeek.com/op...

Proud of the team for achieving SOC 2 Type I compliance. As a platform that touches everything from architecture diagrams to real-time debugging, we deal with an enormous amount of data for our clients. This milestone reflects the level of rigor we’ve built into every layer of the product. 👀

All software design is trade-offs. The trick is making ones your future self won’t hate.

Quick tip for anyone building a collaborative / multiplayer dev tool: sometimes real-time editing doesn’t work. For example, we had to switch back to renaming entities in a modal window, rather than inline.

My team is split on whether you should say please and thank you in your AI prompts. What does the BlueSky community think? [1] Yes. AI mirrors the tone in the prompts. [2] Yes. It’s the nice thing to do. [3] Yes. In case they remember during the AI uprising. [4] No. Why waste time.

Kubernetes is incredible. But you don’t realize what you’re taking on… until you do.