What SRE did to operations

Vercel published a repo of React performance rules for coding agents. Supabase published one for Postgres. Both are good, and almost nothing in either is new. Waterfalls were bad in 2019. Indexes mattered in 1998. The advice existed, in conference talks, in a senior engineer’s head, in the review comment you got once and remembered.

What changed is that scattered advice is now expensive in a way it wasn’t before. An agent doesn’t absorb your team’s conventions by sitting in standup for six months. If the rule isn’t written down, it isn’t applied. So the rules are finally getting written down, and the thing everyone is calling an AI advance is mostly a documentation advance that AI created the incentive for.

This already happened once

Operations went through exactly this. Before SRE, keeping systems up was a craft: tacit, individual, resistant to being written down, and defended as such. The response wasn’t better sysadmins. It was making the practice legible. Error budgets instead of “is it healthy”. Runbooks instead of the one person who knows. Postmortems instead of remembering. Infrastructure as code instead of a server nobody dares reboot.

None of that was new knowledge either. It was the same knowledge, made explicit enough that it could be reviewed, versioned, argued with, and handed to somebody else. The gain wasn’t insight, it was that the practice stopped living exclusively in people’s heads.

Software engineering is getting the same treatment now, for the same reason, and it will produce the same second-order effect: once the tacit part is written down, it becomes contestable. A rule in a repo can be shown to be wrong. A senior engineer’s instinct, expressed as a review comment at 6pm, mostly can’t.

Underneath the vocabulary

The names have churned fast enough to be funny: prompt engineering, then MCP, then rules files, then context engineering, then agent skills. Each arrived as a category shift and each is roughly the same move, which is deciding what the model can see when it starts working.

Strip the vocabulary and what’s left is that an agent is a language model in a loop with tools and a stopping condition. That is not a diminishment; loops are how most useful things get built. But knowing it is the loop tells you where the leverage is. It isn’t in the phrasing of the instruction. It is in what goes into the context, what the tools actually return, and how the loop decides it’s finished.

Which is why the best-practices repos are the interesting artifact of this period and the prompt-engineering threads mostly aren’t. One is a durable, reviewable statement of how a codebase wants to be worked on. The other is a technique for talking to a model that will be obsolete when the next one ships.