devopsy.kinsta.cloud

Tag: ai

  • AI Raises the Stakes for Observability Engineering

    AI Raises the Stakes for Observability Engineering

    AI-assisted development has quietly changed which part of the software lifecycle is hardest. Writing code is no longer the bottleneck. Understanding what the resulting system is actually doing in production is. When agents and assistants can generate whole services in an afternoon, the ability to validate change, investigate incidents and reduce risk becomes the constraint that actually decides how fast a team can ship — and that puts observability engineering squarely at the center of the conversation.

    Alan Shimel talks with Liz Fong-Jones, Technical Fellow at Honeycomb, about what that shift looks like from the ground. Fong-Jones draws a sharp line between telemetry and observability that most teams still blur. Telemetry is the raw material: logs, metrics, traces describing what is happening inside a system. Observability is the broader property of being able to combine that data with human knowledge and process to actually understand the system and make better decisions. Her framing is that observability is a living quality of software — like testability or accessibility — and a team is never done with it.

    They get into how AI reshapes the observability loop itself. Fong-Jones sees real leverage in agent-assisted workflows that generate instrumentation code, sift through mountains of telemetry and help engineers move through investigations faster. The point is not that AI removes human judgment from the loop. It changes where humans spend their time, pulling them off toil and toward the interpretation and decision-making that only a person can do. The second edition of the O’Reilly book Fong-Jones co-authored reflects that shift — the field has moved past arguing whether observability differs from monitoring and into how it supports AI-driven software delivery.

    The bigger arc is that cloud native has become the default substrate for modern software, containers and Kubernetes are now assumed rather than debated, and OpenTelemetry sits underneath the whole picture as the standard everyone builds on. In that world, observability engineering is not a nice-to-have added on top of production. It is the thing that lets teams move faster with AI while keeping the risk of moving faster inside acceptable bounds — and the organizations that treat it as a first-class engineering discipline are the ones that get to keep shipping when everyone else is chasing incidents.

  • The Verification Gap Behind Every AI-Generated Release

    The Verification Gap Behind Every AI-Generated Release

    Code creation has never been faster, but the machinery around it has not sped up in step. AI coding tools can now produce more lines in a morning than a team used to ship in a sprint, while testing pipelines, review processes and device coverage still move at the pace they did two years ago. The result is a widening gap between how much software is being written and how much of it anyone can actually verify — and that gap is where production incidents live.

    Mike Vizard sits down with Prince Kohli, CEO of Sauce Labs, to work through what that imbalance is doing to release quality. Kohli’s framing is that leaders keep mistaking code velocity for product velocity. Generating an application in an afternoon is not the same thing as shipping one. Reviews still need to happen, tests still need to be authored, device coverage still needs to be real, user journeys still need production-like validation. Skip those layers and the AI advantage evaporates the first time a subtle defect makes it to customers.

    Kohli lays out a specific failure pattern engineering leaders should look for: using the same AI model to write the code and verify the code, which he compares to letting a student grade their own homework. Mature teams are moving to independent verification systems that evaluate application intent, author their own tests, run them in the right environments and troubleshoot the failures they surface. Human reviewers also carry a heavier cognitive load in this world, because developers now read a lot more code than they write and often lack the context behind the AI-generated architecture in front of them.

    Sauce Labs research puts numbers on the risk. Kohli says 80 percent of organizations have traced a production incident or outage back to AI-generated code, 90 percent reported serious business impact from those incidents, and 66 percent admit they compromised quality or testing standards to hit faster release deadlines. His pitch is not to slow AI down. It is to invest in verification at the same rate as generation, because the teams that treat testing as a second-class citizen in an AI-first pipeline are the ones already writing incident post-mortems they did not need to write.