AI is shipping code faster than most engineering teams know how to operate it. At Intuit, that tension is front and center — and Akshay Pratinav, Senior Staff Software Engineer, is helping figure out what to do about it.
Pratinav works on AI-driven incident management and cloud resilience at scale. His focus: making sure that as AI accelerates the pace of development, the systems underneath don't quietly come apart.
The Manual Era Is Over (Mostly)
Not long ago, incident management at Intuit looked like what you'd expect at most large engineering organizations. Engineers correlated alerts from multiple monitoring systems by hand, confirmed whether something warranted an incident, then manually set up a collaboration bridge, opened a Slack channel, and notified the right people. It worked, but it was slow and operationally expensive.
That shifted when Intuit standardized on service health metrics — defined thresholds that, when breached, automatically trigger incident creation, provision a Slack channel, and notify stakeholders. Engineers could start troubleshooting almost immediately instead of spending the first 20 minutes on logistics.
But root cause analysis stayed manual. Engineers were still sifting through logs, metrics, and traces by hand — a tedious process during the worst possible moments.
That's the gap AI is now filling.
"AI is now analyzing metrics, logs, traces, historical incidents," Pratinav said. "Instead of on-call engineers manually searching through thousands of signals, AI is able to summarize incident context and help responders understand what changed and where to begin investigation much faster."
The specific advantage is pattern recognition across disconnected data sources. A recent deployment, an infrastructure configuration change, and an uptick in latency across dependent services may each seem unrelated in isolation. AI can surface that correlation quickly. Humans under pressure often miss it.
A New Category of Production Failure
A couple of years ago, most production incidents traced back to bugs in manually written code. Engineers had time between deployments to understand system behavior before the next wave of changes arrived.
AI has compressed that window significantly.
"The bottleneck has shifted from writing code to operating code safely in production," Pratinav said.
The failure modes have shifted too. Configuration drift is more common — AI-generated infrastructure or deployment configurations that look syntactically correct but are operationally incomplete. Unexpected interactions between independently generated components. Deployment velocity that makes it harder to connect an incident to a recent change.
Pratinav described a specific pattern worth watching. An AI assistant generates a microservice, including the application code and deployment configuration. The code passes unit tests. It passes integration tests. But the generated deployment omits resource limits, uses incorrect autoscaling thresholds, skips resiliency configurations like retries or circuit breakers, or introduces inefficient dependency calls that only become visible under real production load.
"This isn't exactly a coding bug," he said. "It's more of an operational design gap that only surfaces at scale."
Building Systems That Can Fail Gracefully
At Intuit's scale, resilience can't rely on a few engineers who remember the recovery playbook. The platform has to encode recovery patterns and automate repeatable actions.
Pratinav's team built a cloud-native disaster recovery orchestration platform that moves away from manual runbooks — documents that different teams maintained differently, that only certain engineers could execute, and that were error-prone under pressure — toward a declarative recovery model.
"Engineering teams can share their intent for disaster recovery, and the platform executes it," he said.
They validate it through regular game days, with a deliberate goal: make recovery boring. No heroics. No guesswork. Just predictable execution.
One game day exposed a gap they hadn't anticipated. The automated recovery workflow completed successfully from an infrastructure perspective. Compute recovered. The database promoted. Traffic shifted. Monitoring showed core platform components were healthy.
But one downstream dependency hadn't fully initialized before traffic arrived. Every individual component appeared healthy in isolation. The application wasn't ready to serve customer requests.
"Recovering infrastructure is only one part of disaster recovery," Pratinav said. "True recovery means the entire application ecosystem is ready — including dependent services, caches, databases."
The fix: dependency-aware recovery workflows with readiness gates and health validation that verify the full stack is actually ready before traffic moves.
Where AI Is Saving Real Time in Incident Response
Detection has improved most visibly. Standardized health metrics combined with AI correlation have reduced alert noise significantly. Instead of flooding engineers with hundreds of alerts, the system makes meaningful determinations about which alerts are related and which are redundant.
Triage has followed. AI has access to metrics, logs, and traces simultaneously, and can summarize incident context quickly — cutting the time engineers spend collecting information so they can spend more time solving problems.
"That's the big paradigm shift," Pratinav said. "Focus on solving the problem rather than collecting information."
Root cause analysis has accelerated too. Engineers receive prioritized areas to investigate rather than starting from scratch across disconnected dashboards.
Remediation is the next frontier. Most mature organizations already have automation for failover and disaster recovery. Pratinav sees AI-assisted remediation — what he calls an SRE co-pilot — as the natural evolution, helping on-call engineers make difficult decisions and take action faster.
The Alert Storm That Changed How They Think About Scale
One incident shaped how Pratinav's team approaches large-scale operations. A failure in a critical service triggered a cascade of alerts across dozens of dependent services. Every downstream service reported elevated latency and failed requests. Within minutes, the monitoring system had generated a large number of alerts.
Under traditional incident management, those alerts created multiple separate incidents. Different service teams began triaging independently. Multiple bridge calls started. Engineers spent time investigating symptoms instead of the source of the failure.
"We weren't just duplicating alerts," Pratinav said. "We were duplicating engineering effort."
The solution was an intelligent correlation engine that analyzed service dependency telemetry to determine whether multiple alerts traced back to the same underlying event. Instead of separate incidents, the platform collapsed them into a single incident representing the primary failure — with all affected services linked, giving every responder one place to collaborate and one root cause to chase.
The result: fewer parallel investigations, clearer blast radius visibility, and engineers focused on resolution rather than symptoms.
One Practical Step for Engineering Leaders
With AI accelerating deployment velocity, operational risk is growing — not because AI writes worse code, but because more changes are reaching production. Pratinav's team introduced deployment risk assessment to address this directly: instead of treating every deployment equally, each change is scored based on size and scope, service criticality, infrastructure modifications, and historical deployment outcomes.
High-risk changes get flagged early. Operational concerns move earlier in the development cycle — before production becomes the place where problems surface.
But if there's one thing Pratinav would recommend to engineering leaders planning their next quarter, it isn't another AI tool.
"Standardize your operational data before investing in more AI," he said. "AI doesn't create observability — it amplifies it. If your operational data is fragmented, AI scales that fragmentation. If it's standardized, AI becomes significantly more effective."
If every team uses different logging formats, different metrics, and inconsistent alerting, AI has very little useful context to work with. Build the foundation first, then let the AI do its job.