“Increasingly, organizations also aim to prevent incidents, as well as quickly recover and learn from the ones that do occur.”
Redeployed is a weekly newsletter that breaks down one important AI story at a time for product builders and engineering leaders. Every issue explores what the shift means for technology companies and how leaders can respond.
AI is helping engineering teams ship software faster. Keeping that software running is becoming a different challenge.
On November 3, PagerDuty introduced Paige, an AI site reliability engineering (SRE) agent designed to investigate incidents, identify likely causes, and help resolve production problems. Paige can assist engineers during investigations, recommend fixes, and autonomously handle certain well-understood incidents within configured permissions. PagerDuty says Paige is generally available.
Also on November 3, Honeycomb announced a preview of its AI SRE Team Agents, designed to monitor deployments, detect regressions, and identify reliability problems before customers encounter them.
Both announcements point toward an important shift in engineering productivity. The next major gain may come from reducing the operational work engineers have to deal with, rather than helping them produce more code.
The Hidden Cost of Shipping Faster
Every software release adds something engineering teams must maintain. More features can introduce new dependencies, monitoring requirements, and opportunities for unexpected failures.
AI-assisted development is accelerating that process. According to a forthcoming Honeycomb survey, 76% of respondents reported that AI-generated code was growing faster than their teams' ability to review and monitor it. The finding is company-reported, but it highlights a potential imbalance between development speed and operational capacity.
When production breaks, developers interrupt planned work to investigate logs, coordinate with other teams, and sometimes revisit problems they have encountered before. Preventive maintenance also competes with product development, leaving known reliability issues unresolved until they cause another interruption.
That is the opportunity AI SRE agents are targeting: reducing the operational burden that consumes engineering capacity after software ships.
When Every Incident Makes the Next One Easier
PagerDuty's approach is particularly interesting because Paige is designed to build operational memory from previous incidents.
After an investigation, the system can retain information about the failure and its resolution, creating shared context that can support future responses. Teams can keep humans responsible for approving remediation or authorize autonomous actions within defined boundaries.
Consider a recurring database connection failure. An engineer might spend time examining logs, comparing recent deployments, and checking whether the issue resembles an earlier incident. An agent with access to relevant telemetry and incident history could perform much of that investigation before escalating the problem.
If the same failure appears repeatedly, the agent could help identify the underlying pattern and recommend a permanent fix. But recognizing a recurring incident is different from preventing it. Someone still needs to validate the root cause, implement the remediation, and confirm that the problem has been resolved.
Honeycomb is pursuing a related approach through agents that continuously inspect production telemetry and deployments. Rather than waiting for an alert, these systems aim to identify regressions and reliability debt while engineers still have time to address them.
Neither announcement establishes that AI agents can reliably prevent incidents across production environments. The direction is nevertheless significant: operational knowledge could become something engineering systems continuously accumulate and reuse, instead of something teams reconstruct during every incident.
Reliability Becomes an Engineering Capacity Strategy
For CTOs, the business case extends beyond faster incident resolution.
A production incident can interrupt several engineers, delay releases, and consume time that never appears in feature-delivery metrics. A shorter incident is valuable, but preventing repeated investigations, reducing unnecessary escalations, and protecting uninterrupted engineering time could have a larger effect on what teams actually ship.
That suggests a different way to evaluate engineering agents. Instead of measuring generated code, completed tickets, or the number of automated investigations, teams should track repeat incidents, mean time to recovery, unnecessary escalations, and engineering hours diverted from planned work.
The goal is to understand whether reliability automation is returning meaningful development capacity, not simply making incident workflows faster.
There are important limits. Automated remediation can make failures worse when an agent misdiagnoses a problem. Continuous investigation also requires reliable telemetry, scoped permissions, audit trails, and clear ownership when an automated action causes an unexpected result.
A sensible starting point is bounded automation around recurring, well-understood incidents. Agents can gather evidence, compare historical failures, recommend remediation, and escalate uncertain cases. Autonomous fixes should be introduced only when teams can demonstrate that the actions are safe, observable, and recoverable.
This issue of Redeployed is brought to you by Tecla Labs: As companies move from experimenting with AI to deploying it in real workflows, they need systems that integrate with existing tools, operate reliably, and deliver measurable business value. Tecla Labs helps companies identify high-impact AI opportunities, develop custom AI solutions, and integrate intelligent automation into their operations, turning AI capabilities into practical, production-ready systems.
The Best Incident Is the One That Never Happens
PagerDuty and Honeycomb are early examples of a broader opportunity: applying AI to the engineering work that happens after software ships.
For years, engineering productivity has largely been discussed in terms of how quickly teams can build and release features. But shipping faster creates limited value if teams spend an increasing share of their time investigating failures and maintaining unstable systems.
Engineering leaders should start by identifying the operational problems that repeatedly interrupt development. Incident investigation, deployment monitoring, and recurring reliability issues are practical places to test whether AI can reduce that burden without introducing new risks.
The strongest results will come from systems that help teams recognize recurring problems, address their root causes, and prevent avoidable disruptions. That means fewer emergencies, less repeated investigation, and more uninterrupted time for engineers to build.
A good engineering agent might save an hour during an incident. A great one could help prevent the interruption altogether.
Connect With Other Technology Leaders
If you want to exchange practical ideas with senior technology and product leaders navigating the AI era, check out the upcoming GILD Forums. They bring together experienced operators for peer discussions around the technology and business decisions they are working through right now.
More to come…
– Gino Ferrand, Founder @ Tecla Labs