I never thought I’d say this, but I miss being an SRE in the Old Days:tm:1.

No matter how much code agents write for me today, I’m still the directly responsible individual for every bug. So when things go wrong, I still have to crack open my laptop2.

But unlike the old days, I don’t know every line of code! I’m more like a manager on call – yikes.

On call with AI: slower, more stressful

  1. Get paged in Slack
  2. Ack the page
  3. Immediately copy+paste the page into my coding agent with “omg what is happening!!”
  4. Agonize as it methodically investigates the issue
  5. Steer random context into the chat as it goes

A chat with a coding agent: the user says "omg our site is down please figure out what's happening!!" and the agent starts methodically investigating, listing repo contents and grepping for the production URL make no mistakes

Generally with enough tokens and time the agents resolve the outage, but:

  • Outage comms are worse. I’m just pasting random hypotheses from my agent into the Slack thread. I don’t have as good of a sense of the ETA to resolution.

  • The agent doesn’t work in outage mode by default. The default coding agent behavior is to investigate, then make a speculative forward fix. That’s the wrong approach during an outage! We should mitigate first with the lowest-risk change – roll back! turn off the flag! – rather than shipping more new code with less testing.

A timeline diagram of two responses to an outage: applying a generic mitigation halts user impact early, while investigating first lets the damage continue until the perfect fix ships. A cartoon volcanic island decorates each timeline, and its islander is much happier in the mitigate-early one

Source: Generic Mitigations by Jennifer Mace, O’Reilly Radar

After a few sweaty incidents, we’ve changed how we build to make being on call easier with agents.

Feature flag everything

The simplest tip I got from Alon to ship faster was to feature flag everything and test in prod. When starting a new project I build feature flag support right away. Feature flagging is an acknowledgment that I know so little about the code that I need a big red switch to manage it.

This was mostly a mindset change to remember to prompt “…and put this behind a flag”. Beyond that, a line in AGENTS.md like “we use PostHog for feature flags” and a file called features.ts are enough.

We don’t ask the agents to decide what to feature flag themselves yet. Do you? Should we?

Write a doc/skill explaining how you do release management

We built the Napkin Math iOS and Android apps in the YC Spring 2026 batch using Expo with React Native.

Expo’s magic trick is the “over-the-air update” – a React Native app is built with a native layer and an update layer of JavaScript and assets that can be updated over-the-air (OTA) without the user needing to visit the App Store.

Expo update layers

Source: How EAS Update works, Expo Docs

OTAs can be super useful to mitigate an outage if done right!

More on how we did Expo updates

We generally followed Expo OTA best practices.

We used the Expo appVersion policy with the release branch pattern from trunk-based development. There’s one Git branch per runtime version.

Suppose main targets runtime version 1.0.17 and a PR lands a breaking native change:

  • The PR with the breaking native change bumps the app version to 1.0.18.
  • Right before merging, we branch 1.0.17-ota off of main and push a final OTA to 1.0.17 users.
  • Merge the PR. After the merge, updates published from main target 1.0.18.
  • If there’s a JavaScript bug introduced in 1.0.17 we need to mitigate for users on both versions, we fix it on main, cherry-pick it onto 1.0.17-ota, and then push OTAs from both branches.

After I explained this release management system to agents mid-outage a few times, it was helpful to just write a doc into the repo. I’d recommend you do the same! Everyone’s release process is a different special snowflake, so it’s probably not just In The Weights.

Recursive self-improvement: postmortems and runbooks

I confess: we haven’t done this one yet! Have you?

A few times now we’ve “fixed” a bug, only to have it crop up again. The agents fixed some narrower version of the issue or didn’t test the right thing before declaring victory.

In a repeat outage it’s stressful to watch the agent plod down the same investigation/discovery path, wasting tokens and time. I don’t want them to root-cause the same issue twice!

I’m thinking of adding a simple recursive self-improvement loop for the repo where we have:

docs
├── postmortems
│   └── 2026-08-18-photo-upload-failed-....md
└── runbooks
    └── expo-updates.md

I’m not sure what threshold for notability I’d use to warrant a postmortem or runbook except “when I say so”. But I’d want these to be primarily agent-readable (not explicitly designed to be human-readable) docs.

Is this cope?

How much should we change how we build software to adapt to coding agents, and how much should we just wait for the next model release?

My thought is:

  • if it’s generically making the agent “code better”, it’s probably gonna be in the weights. That’s why I won’t write a generic “on-call” skill which would basically be “follow the Google SRE book”.
  • if it’s about how your specific team/company does things, might as well make it legible to agents by writing it down

I still hold tightly (too tightly?) to some aspects of software development.

Maybe someday soon AI will replace my SRE job and we’ll delete all the docs and walk into the sunset building freely :)

I read these after writing the above post. These writers are thinking along similar lines!

  1. Pre-AI. ↩

  2. Or chicken farm on my phone ↩