Faster code generation should make room for better software, learning, and the people doing the work. What are we actually doing with it?

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.

Photo by Patrick Konior on Unsplash

A maturity model for shipping fast without breaking customer trust.

I made an earlier argument that deploying code and releasing a feature are not the same event, and that treating them as one causes unnecessary risk. That argument still holds. But the environment it was written for has changed.

AI-assisted development has made writing and shipping code dramatically cheaper. A change that used to take a sprint now takes an afternoon. That’s a genuine gain, but it doesn’t automatically make the judgment around releasing that change any faster or better. When the cost of producing change drops and the discipline around exposing change doesn’t rise to match it, the result is exactly what customers are describing: things move, break, or reappear differently, without warning, more often than they can absorb.

Someone asks you a question. You don’t know the answer off the top of your head, so you paste it into Claude, copy the response, and send it back.

That’s not a human interaction. That’s a very slow API call with extra steps.

I keep seeing this pattern, at work, on forums, in social communities, and it makes me wonder if we’ve completely missed the point. Not of AI. Of ourselves.