Systems | Development | Analytics | API | Testing

For years, the Kubernetes sidecar pattern has been a practical way to capture observability data. Running a collector alongside each application pod gave us deep visibility into traffic, including full request and response payloads across supported protocols. However, as cloud-native environments have grown more complex, the limitations of sidecars—such as resource overhead, operational complexity, and scaling challenges—have become more apparent.

When discussing the process of testing an API, one of the most common sets of terms you might encounter are “mocks” and “stubs.” These terms are quite ubiquitous, but understanding exactly how they differ from one another - and when each is the correct method for software testing - is critical to building an appropriate test and validation framework. In this blog, we’re going to talk about the differences and similarities between mocks and stubs.

The dust has settled on Las Vegas. We saw transparent TVs, cars that drive sideways, and enough “AI-powered” toothbrushes to confuse a dentist. CES is incredible at selling the dream of hardware. The demos are slick, the lighting is perfect, and everything works on the showroom floor. But as engineers, we know the dirty secret of CES: The hardware is the easy part.

Modern LLM coding agents are great at reading code, but they still make assumptions. When something breaks in production, those assumptions can slow you down—especially when the real issue lives in live traffic, API responses, or database behavior. In this post, I’ll walk through how to connect an MCP server to your LLM coding assistant so it can pull real production data on demand, validate its assumptions, and help you debug faster.

API mocking plays a crucial role in modern software development allowing developers to simulate external API endpoints. It’s an effective way to isolate your application for testing and ensure that code changes don’t inadvertently break critical dependencies. Essentially, API mocking helps you create robust, reliable software by allowing you to test how your application interacts with external services.

Modern DevOps observability tools are excellent for monitoring system health, tracking distributed traces, and aggregating metrics. However, they lack the fidelity needed for full-text search across application traffic. While observability platforms excel at showing what happened and when, they often fall short when you need to find where a specific piece of data (like an email address, user ID, or transaction token) appears as it flows through your entire application stack.

Everybody knows working with Kubernetes is really hard. It’s highly complicated. You have to know how to work with YAMLs, there’s lots of stuff to deal with. The classic developer experience with YAML. But what if you could get complete visibility into your Kubernetes workloads and run realistic load tests without touching a single YAML file or running kubectl commands?

Every technology cycle comes with hype, backlash, and eventually… utility. AI is shaping up to be no different. As we head into 2026, the conversation is already shifting from “AI will replace everything” to “why isn’t this paying off yet?” This shift is heavily influenced by evolving market trends, as businesses and technologists respond to changes in customer behavior, operational patterns, and broader market conditions that shape expectations around AI.

I recently tried using AI to create a digital twin of myself. I uploaded a photo, expecting a futuristic, slightly improved version of me… and what did I get in return? A picture of Kim Jong Un. Clearly, AI has a sense of humor—or a very different definition of “twin.” Forget Arnold Schwarzenegger and Danny DeVito.

Picture this: You’ve spent hours perfecting your React component. The animations are smooth, the responsive design works flawlessly, and you’re ready to test the user flow. You click “Submit” and… nothing happens. Or worse, you get a cryptic CORS error. The problem? Your backend isn’t running. Again.