All of us are searching for the AI tools that are truly worth using and that actually solve real problems. So we recently tested three prominent coder bots (Codex, Cursor, and Factory) to evaluate their practical capabilities for reducing log volume and cloud expenditures to see which one is currently
APX is a Continuous Reliability platform built to proactively detect and resolve production issues that easily cost your team 30-40% of their engineering time. It seamlessly integrates with your existing tools, such as GitHub, Datadog, Sentry, and Postgres, providing fixes before problems lead to major production incidents. In this test,
We recently hosted an Ask-Me-Anything (AMA) session featuring Mark Burgess, creator of CFEngine and Promise Theory, focused on applying AI to reduce toil in production systems and improve reliability engineering practices. Mark started by defining "toil" clearly: it's repetitive, necessary work that does not build knowledge
OpenAI’s Codex has introduced a new wave of AI-assisted development, enabling engineers to turn natural language into functional code. But while Codex can generate good solutions, it still depends on high-quality inputs to be effective. That’s where StepChange’s APX comes in. 10x Faster Production Debugging Starts with
Many folks will be familiar with the "noisy alerts channels" phenomenon in Slack: every alert says urgent, yet very few are truly important. Engineering teams spend 30% of their time on toil already and noisy alerts don't help. We at StepChange realized that there is an
APX is a platform that deploys targeted AI agents to continuously monitor your production infrastructure. Think of it as a team of specialized engineers watching your systems 24/7, proactively detecting and fixing issues before they impact users. Our AI agents integrate with GitHub, Datadog, Sentry, and Postgres to identify
APX is an AI agents platform that monitors production infrastructure using your existing tooling to detect performance issues, and suggest targeted fixes. Our AI agents integrate with GitHub, Datadog, Sentry, and Postgres to identify problems and either push fixes directly or deliver high-impact recommendations. They work like a team of
Datadog cost surprises are more common than you'd think. I’ve written about how Datadog’s defaults can quietly spiral out of control, like when a GKE Autopilot user saw their Datadog bill increase 20x due to unexpected Prometheus scraping. The root cause? Overlapping defaults that not even
Deploying on a Friday afternoon is always a gamble. Last Friday, we pushed what seemed like a routine front-end update, until users started reporting errors. A null object slipped through, breaking part of the UI. Normally, this would trigger a bunch of Sentry alerts. But Sentry alerts are noisy, and
Spending on observability platforms has gotten out of control. It is often the number two cost behind a company’s main cloud vendor, representing up to 25% of the engineering team’s budget. I saw this firsthand when I was part of the engineering team at Coinbase, where I built
Imagine opening your Datadog bill and seeing a 20x increase. You dig deeper and discover thousands of “custom metrics” flooding into Datadog—metrics you didn’t configure, expect, or even recognize. That’s exactly what happened to a GCP user running workloads on GKE Autopilot. I’ve said this before,
Migrating from SQL Server to Postgres is a significant move for organizations looking to reduce costs, improve scalability, and future-proof their data infrastructure. But database migrations are costly and time consuming. They frequently run overtime, carry significant business risks, and are a significant opportunity cost. So if you’re going