We all know the tagline: it’s 03:47, and PagerDuty wakes you up again. Only now it is 2027, and it isn’t the same as it was in 2026, and it is astronomically different from how it was in 2020. The code that broke was written by an AI agent. It was shipped by another AI agent. No human read the diff because no human needed to; it passed every test, sailed through CI, and was promoted to production without a single raised eyebrow.

It’s now 03:51. You’re awake and logged in. The SRE agent has tried to resolve the incident, but it couldn’t. It’s on you. What do you do? What should you have done to prepare for this moment? What do you need from the SRE agent now?

This scenario isn’t science fiction. Pieces of it are already true today, and the rest is arriving faster than most engineering orgs are prepared to admit.

The build side has already changed

Coding agents writing and shipping production code isn’t a novelty anymore. It’s a normal Tuesday at a growing number of companies.¹ The interesting part isn’t just that AI can write code now; it’s that the volume, speed, and quality of AI-authored changes are starting to outpace the human review processes that used to serve as the safety net. Consequently, we have to rely more on the AI to review the code. Will it be better? Will it be worse? Our prediction: AI review will be better on average and worse in the tail (even if it is coupled with a human review), and the tail is what pages you.

The run side is next

If coding agents are changing how software gets built, SRE agents will change how incidents get resolved. We’re already seeing agents that triage, correlate signals across systems, and summarize events faster than a human could scan five dashboards. Agents actually taking action to fix things will be here soon.

On the one hand, this is great; you will have fewer incidents to manage yourself.
On the other hand, it will cause issues. You will lose the “easy” reps that teach you how to resolve incidents and keep you familiar with the system.

Combined, this puts real pressure on a mantra we’ve lived by at PagerDuty for years: Code It, Ship It, Own It. It’s our version of DevOps and has been a powerful mantra for us because it forces us to own what we build and design for operations. But look at what’s happening to each piece of it: “Code It” and “Ship It” are increasingly automated. But “Own It”?

Part of that ownership will shift, but when real trouble hits, the responsibility remains. In fact, it will get harder because you will soon be on the hook for systems you never touched, with less practice than before.

We’ve run this experiment already

Here’s the reassuring part: this isn’t a new problem, and it isn’t even a new observation. In 1983, Lisanne Bainbridge published a paper called Ironies of Automation that reads like it was written about SRE agents. Her argument: automation absorbs the routine work and leaves the operator with whatever it couldn’t handle. Which is, by definition, the hardest part of the job. And, at the same time, it removes the practice that builds the skills the operator needs. Aviation has spent the last four decades learning this the hard way.

Autopilot didn’t remove the pilot. It changed what the pilot was for. The routine, predictable segments of a flight were automated, and the pilot’s value concentrated into the moments autopilot can’t handle: the edge cases, the unexpected, and the “something’s wrong and I need to figure out why, right now” moments. But this only works if the pilot knows how to handle the plane in those situations. A pilot who has just sat there watching the autopilot do its job for years will not be prepared to respond when an incident occurs. Earl Wiener, who spent a career studying cockpit automation, put it more bluntly: automation tends to reduce workload when workload is already low, and increase it when workload is already high.

Aviation didn’t solve this by hoping pilots would stay sharp on their own. It solved it by mandating simulator time and manual segments. Practice for the bad day isn’t optional, and it isn’t something you fit in when you have spare hours. It’s a requirement, built into how the job works.

Swap “pilot” for “responder” and “autopilot” for “agent,” and the parallel is almost uncomfortably direct. If we’re heading toward a world where agents handle most of the work, the responder’s value concentrates into the moments the agent can’t handle. Expertise for those moments doesn’t survive on its own just because someone used to be good at their job; it has to be practiced.

The analogy has a limit, and that matters

It would be tidy to stop there and “just add simulators, problem solved”, but that undersells the challenge. Real incidents aren’t scripted the way flight-sim scenarios are. They don’t repeat cleanly, the failure surface changes every time an agent gets a capability upgrade, and “practice” for an incident you’ve never seen before is much harder to design than practice for a known engine failure. Furthermore, we don’t yet have anything as good as a flight simulator to train on.

Practice matters, but only if the practice is useful. This means we really have two problems, not one.

Two halves of the same answer

Getting through this needs both better tooling and sharper people, not one instead of the other.

Better tooling means:

• Absorbing the load where possible, allowing time for training and ensuring responders are fresh when the big one hits (resolve incidents before paging humans)
• Surfacing context faster, so a human coming into an incident cold isn’t starting from zero, and helping them as they take the lead (machine-speed searching of logs, searching of past incidents and workflows to resolve the incident)
• Using incident history to develop realistic training and improve response processes, not just logging it and forgetting it (better post-incident reviews, tooling to collate learnings across incidents)

Sharper people means:

• Working fluently with agents, not around them or in spite of them
• Practicing in low-stakes scenarios before the high-stakes one arrives
• Knowing how the tools (agents) fail, not just how they succeed. The agents’ failure modes are precisely where the human responder will earn their keep.

Neither half works without the other. Great tooling with untrained humans just means confused people staring at better dashboards. Well-trained humans with poor tooling means burnout, because you’re asking people to do manually what the tools should be doing for them. Skip either half and at 03:47 when the pager fires it gets worse, not better.

What are we doing about it?

Our SRE agent has been built to work as a standalone responder and as a copilot. It lives on your escalation policy ² ready to start investigating straight away and have the resolution ready for you when you log in. It also lives with you during the incident, it is in your incident call (with the Scribe agent) listening to your discussions and reacting to what you are finding, and by your side helping you to debug and get to a resolution faster.

Our redesigned Post Incident Reviews ³ take the toil out of learning from your mistakes. Combined with an SRE agent that has a memory and the ability to intelligently search through past incidents for clues to resolve this one, we have a system built to help you learn from your problems.

This is the beginning of a flight simulator for incident response: your incident history, structured well enough to rehearse against. We have built internal tooling to collate our incidents and look for patterns and trends before they become a major issue, helping us identify weaknesses, better manage our systems, and prevent future incidents from occurring.

What to do Monday morning

Three questions worth sitting with, borrowed straight from the flight deck:

1. What can you fly manually? As you become more and more dependent on your tooling, take an honest inventory of which parts of your incident response you could still do if the tooling failed. If the answer is “not much,” that’s useful information.
2. What’s your flight simulator? Do you have any low-stakes way to rehearse the incident you’re most afraid of, before it happens for real? Are you updating your mental model as the agents work on your services? If not, those are the gaps to close first.
3. How is your flight simulator programmed? Are you learning from real incidents? Conduct post-incident reviews, read about other companies’ experiences, and train against potential scenarios, especially the ones that scare you!

None of these questions has a fast answer. All three are worth having on the agenda this week rather than after the next incident makes the answer obvious the hard way.

Own it, especially at 03:47

The agents will Code It. The agents will Ship It. But, at the end of the day, no matter how good the SRE agent is, you will still Own It.

Ownership used to flow from authorship: you wrote it, so you understood it, so you owned it. That chain is now broken. What is left is narrower and harder. You didn’t write it; you don’t understand it the way an author would; but the responsibility is still yours. The responsibility to reason about it under pressure, the responsibility to take over when the agent can’t find the solution, the responsibility to make the call at 03:47, when everyone is looking to you.

The question isn’t whether this shift is coming. It’s whether you’ll be ready when it arrives. Are you?

References

¹ DX’s preliminary Q2 2026 data in AI-authored code has nearly doubled, but so has PR size, showing that AI-authored code now represents 51.9% of output across participating organizations. At PagerDuty, we are not letting agents ship code yet, but we are working towards it; see Before AI Ships Code, Show Me the Receipt for how we are approaching it.

² SRE Agent Enhancements: Faster Triage, Greater Access Controls, Deeper System Connectivity

³ From Incidents to Insight: Closing the Post-Incident Review Gap