Turo lets AI agents read live production data to find outages in 60 seconds

Faster code, new bottlenecks

Turo runs a large peer-to-peer car sharing marketplace on cloud infrastructure, microservices (many small programs that each do one job) and Kubernetes clusters (software that manages those programs across many machines). When generative AI tools arrived, the company gave every engineer a local AI coding assistant.

Writing code got faster, but the slowdown moved elsewhere. According to New Relic's account, bottlenecks soon appeared in code review and release pipelines. On-call engineers also struggled with alerts from microservices they did not normally work on, which meant more toil and a longer time to resolve incidents (the metric called MTTR).

The piece comes from a fireside chat between New Relic's VP of Developer Relations, Jemiah Sius, and Turo's VP of Engineering, Victor Mora. As newrelic.com reported, the core lesson is that the job shifts from simply writing code to defining the problem accurately.

The paradox in the numbers

New Relic backs the story with its 2026 State of AI Coding Report, which draws on 200 technology leaders. In it, 67% said AI now generates or significantly refactors between 51% and 75% of their organization's weekly code.

The same report shows a tension:

• 94% of leaders rate AI-generated code as higher quality at first review.
• 78% report a surge in production incidents after shipping it.
• 86% say senior engineers are doing more firefighting.

New Relic's explanation is that coding tools can see the code itself but not what happens when it runs: live traces, dependencies and the state of the application. Code can look fine on review and still fail in production. Keep in mind that New Relic sells monitoring software and wrote this report.

How the agents see production

Turo's fix was to give its AI agents live context. It streams cloud infrastructure data, Kubernetes metrics, application logs and deployment events into New Relic, so there is one place to look.

Cloud-hosted agents then connect to that data through an MCP server. MCP, short for Model Context Protocol, is a standard way to let an AI assistant use outside tools and data. Here it lets an agent ask questions in everyday language, rather than an engineer writing queries in NRQL, New Relic's query language.

New Relic also tracks feature flag toggles (switches that turn a feature on or off) and deployment events as they happen. That tells an agent whether a recent change might have caused a problem.

The midnight incident

The headline example is one critical incident at midnight. Normally an alert like that pulls an engineer out of bed to work out which service failed. In this case, the account says, the agent got there first.

Within the first 60 seconds after the alert fired, the agent queried New Relic, analyzed how services connected and where the logs led, identified the root cause and produced a diagnostic report ready to act on. All of this reportedly happened before the engineer had logged on. The team then fixed the problem right away.

The post says this sharply reduced MTTR and protected the customer experience. It gives no figures for that, and it describes a single incident, so we cannot say how often this works.

What to take from it

The pattern is simple: more AI-written code means more need for visibility into running systems. The post ends by promoting New Relic's Ground Truth, which it calls an operational context layer that feeds data to agents through MCP tools. Its argument is that you cannot control AI agents without complete observability, meaning the ability to see what your systems are doing.

The piece also mentions spec-driven development and automated canary testing (a way to release changes gradually) as ways to keep release pipelines moving. It does not explain them in detail. For small teams, the lesson matches our earlier note: grow monitoring and alerting as fast as your code output.