Why Good SREs Feel Like Wall Builders

Sun, 04 Oct 2026 00:00:00 +0000

Someone pinged me at 4:40 on a Friday: “need a new Postgres instance, going live Monday, should be quick.” I asked what the read/write ratio looked like and what happens to the checkout flow if the instance falls over for ten minutes. But, they hadn’t thought about either one, because nobody had ever asked them to.

Working with a bad SRE team is frustrating for all the obvious reasons: things break, deploys fail, and nobody answers the page.

Working with a good one is frustrating for a totally different reason, we ask the questions you weren’t ready to answer.

How many reads per write? What happens when the cache is empty? Can service A deploy while service B is down? None of those questions are a no, they’re how we figure out how deep the foundation has to go before you put a building on top of it. But from the other side of the request, it looks a lot like someone building a wall.

And that’s been true for about as long as there have been ops teams. What is rapidly changing is how fast the building goes up.

One engineer with an agent can now produce in a weekend what used to take a small team a quarter. Ask for “a scalable user service” and you can have two services, a Postgres instance, a Redis cache, and the Terraform to stand it all up before lunch. The code usually works, but, the problem lies in everything that didn’t happen on the way to code completion.

On a normal team, code passed through people. A senior engineer reviewing the PR asks why there are two services. A tech lead in a design review asks what growth looks like. Someone who has been paged for this kind of thing before asks what happens when it falls over. Those conversations were slow and, honestly, occasionally annoying, but they were where most of the operational questions actually got asked. Even then, few organizations I’ve worked in wanted to talk about users per hour, how much data they’d be moving, or latency targets before there were even mockups of the new UI.

When one person and an agent build the whole thing, those conversations don’t happen. The agent was asked for something that works, and it delivered exactly that, but nobody asked it for something that survives.

So the first time anyone asks those questions is when the request lands on the platform team, and the reaction is predictable:

“I built this in two days. Why is the infra review taking three?”

Look, I get it. From where they’re sitting, we’re the slowest step in the pipeline by a kilometre (mile). We’re also the first step where anyone has bothered to ask how the thing behaves under load.

I wrote about the release side of this in Release Discipline in the Age of AI-Accelerated Development. This is the same gap, just one layer down.

I see the same three patterns land on the platform team, over and over, and I’d bet most of you have seen at least one of them this year.

The default database. The agent stands up Postgres with default settings and generated migrations. It works fine in dev. Nobody has asked about the read/write ratio, how big the largest table will be in a year, or how long the data needs to be kept. The one that usually bites first is connections. Every pod opens its own pool, autoscaling adds pods during a traffic spike, and Postgres runs out of connections at exactly the moment you need it most.

The cache that became a database. Redis goes in front of a slow route to “make it faster.” There’s no eviction policy, no TTL, and no plan for what happens when Redis restarts or gets flushed. A cache is fine as long as the service can live without it. Once the service falls over on a cold cache, it isn’t a cache anymore, it’s a primary data store that nobody chose, nobody sized, and nobody is backing up (and don’t get me started on backups).

The distributed monolith. The prompt said “microservices,” so you got two of them, in separate repos with separate pipelines (no monorepo huh?). But A can’t do anything without B, they have to deploy together, and there are no timeouts, retry budgets, or fallbacks between them (did we even connect the network segments?!). You’re paying for microservices (network hops, distributed tracing, two pipelines) and getting none of the benefits (independent deploys, failure isolation). It’s just a monolith that talks to itself over the network.

It’s tempting to blame the developer(s) here, but, that’s not right, and honestly it doesn’t help anyway.

An agent does what the prompt says(this part may age poorly). Ask for “a service that reads from Postgres and caches in Redis” and that’s what you’ll get, built competently. It probably won’t stop to ask what happens to database connections when autoscaling kicks in, how A behaves if B takes fifteen seconds to respond, or whether this needed to be two services at all. Most agents will happily work through those questions if you ask them to, very few will raise them on their own.

I wouldn’t call that a flaw in the model, it’s more of a gap in experience. Operational instincts come from getting paged for something you built, and the model has never been paged. Plenty of the people prompting it haven’t been either, which is fine, that’s what the rest of the team used to be for.

So the platform team ends up being the first place in the pipeline that carries that context. To someone moving that fast it feels like a wall, but from our side we’re just checking the ground before the concrete goes in.

I’m not interested in slowing anyone down (most Platform Engineers aren’t either), the speed is real and it’s useful. What I want is for the operational questions to get asked earlier, by the developer and the agent, so they aren’t all landing on us at the end.

If you’re building with agents, prompt for day two. Put operational constraints in the prompt, not just functionality.

Instead of:

Build a user service with Redis caching.

Try:

Build a user service with Redis caching. If Redis is unavailable, fall back to Postgres and keep serving. Set explicit TTLs and a memory cap with an eviction policy. Add timeouts and a circuit breaker on downstream calls.

It’s three more sentences, and it gets you something the review will mostly wave through.

If you’re on a platform team, put your rules where the agent can read them. A twenty-page review process is a good way to teach people to route around you. Write your operational defaults (connection limits, required metrics and alerts, cache TTLs, timeout budgets) into an AGENTS.md in your repo templates. The agent picks it up, and the first draft lands closer to what you’d have asked for anyway. Then give people Terraform modules that are already sized sensibly and already have monitoring, scaling bounds, and backups wired in. The paved path has to be the easiest path for the agent too, otherwise nobody’s going to use it.

The napkin spec

Before the build starts, or at the latest before the infra request goes in, answer five questions. It fits on a napkin, and it covers most of what a review would ask anyway.

Failure: If this service or its database goes down completely, what does the user see?
Scale: What do memory, storage, connections, and throughput look like at 3x today’s load?
Coupling: Can this deploy while its dependencies are deploying or down?
State: Where does the data live, how long is it kept, and has anyone actually restored it from a backup?
Ownership: What tells you it’s broken, and who gets paged? (If the answer is “nobody,” that’s its own problem.)

“I don’t know” is a perfectly fine answer to any of these, and it’s a lot cheaper to find that out here than in an incident channel.

The service in the intro? It went live Monday, more or less on schedule. But, the base image was built in the wrong account, the prod environment was missing the database password, and nobody had put the new service’s URL into config management, so checkout was down for the first four hours while three of us traced it live on a call that was supposed to be someone’s lunch. Once the “oops, we forgot about those configuration items” were fixed, the application scaled out so far and so fast that it saturated our connection pool and completely locked up the database and took several more hours to stabilize, but, we still don’t have a clean answer on the read/write ratio. Sadly, we got our answer on what happens to checkout when the instance isn’t there: it breaks, loudly, and the week after launch wasn’t spent on anything in the quarterly plan. It was spent rightsizing the thing that should have been sized on Friday.

Reliability on Coffee or Blog

Why Good SREs Feel Like Wall Builders

The napkin spec