I asked Claude to provision infrastructure and deploy my app. Cheap as possible. I told it straight up: I know how Kubernetes works, I know how VMs work, you pick the approach. It came back with Hetzner, one VM, K3s on top. Reasonable. Cheap. It ran the deploy, everything came up green, and it told me we were done.
Then I asked one question. Is this app highly available? What happens when we ship an update?
„Oh yes, that’s a real gap. You cannot do that. Should I fix it?“
That’s the whole problem in one sentence. It knew. The information was in there. It just never volunteered it, because I never asked, and nothing in its training makes it care whether my users get a 502 during every deploy.
the part that should scare you
Think about who else is running that exact prompt right now.
Someone who has never operated a service in production asks for „the cheapest way to deploy my app,“ gets a single-node K3s box, and ships it. It works. It genuinely works, for a while. They get their first users. Maybe their first paying customers. And then they push an update on a Tuesday afternoon and the app goes dark for ninety seconds, and nobody knows why, and there’s no second node to catch the traffic because there was never a second node. Or the VM has a bad day at Hetzner and the whole product is just gone until someone wakes up.
There was zero resiliency in that setup. Not „some.“ Zero. And the deploy report said everything was fine.
I want to be precise about what I’m blaming here, because this is not a „Claude is bad“ post. Claude did what I asked. I asked for cheap and I asked for deployed. I got cheap and deployed. The model optimized my stated objective perfectly and ignored every unstated one, which is exactly what these things do. The gap wasn’t in the model. The gap was in my prompt, and I only noticed because I’ve been on call for systems like this and I know what 3am feels like when the only node is on fire.
it happened again, and worse
Different project. I asked it to build resilience patterns into my application. Broad ask, on purpose, I wanted to see what it reached for.
It came back with retries and timeouts and some health checks. Fine. Real things. But it missed rate limiting entirely. It missed circuit breakers. It missed graceful shutdown, which is the one that actually bites you in Kubernetes, because without it every rolling update drops in-flight requests on the floor and your error rate spikes on every single deploy and you spend two weeks blaming the load balancer.
If I hadn’t known what „resilience patterns“ is supposed to mean, I would have shipped a checklist with three of the six boxes filled in and felt good about it. That’s the dangerous failure mode. Not the obvious wrong answer. The confident partial answer that looks complete.
So I asked for the rate limiter explicitly. And it wrote me a sliding window. In memory. In the app process.
Let me tell you why that’s garbage. In-memory means the limit lives inside one replica. Scale to three pods and your „100 requests per minute“ quietly becomes 300, because each pod is counting on its own. Nobody is enforcing anything. You’ve built a rate limiter that reports beautiful metrics and stops nothing.
So I pushed. What happens with more than one replica? Is a sliding window even the right shape here? Are there better algorithms?
And then, of course, it gave me the good answer. Token bucket, backed by Redis, with a burst allowance so legitimate traffic spikes don’t get punished for existing. That’s what I wanted from the start. That’s what I would have written myself. It took three rounds of me knowing exactly which questions to ask to get there.
That’s the whole thing. The good answer was available the entire time. It was gated behind knowing enough to demand it.
the harshest reality
These tools do not care about your system. They don’t care about resiliency, or replication, or what your on-call rotation looks like in six months. They have no stake in the thing you’re building. They complete the task you described, at the quality level your prompt implied, and then they stop.
That’s not a bug and it’s not going away with the next model. Even if the reasoning gets better, the model still doesn’t know that your traffic triples on Black Friday, or that your compliance team needs audit logs, or that the last outage got you a very uncomfortable meeting with your CEO. You know that. Only you know that. And if you can’t articulate it, it doesn’t get built.
In the right hands, this stuff is an absurd accelerant. I ship things in an afternoon that used to take me a week, and they’re good, because I know what good looks like and I keep pushing until I get it. In the wrong hands, it’s a very fast way to build something that survives contact with a demo and dies on contact with real users.
A fool with a tool is still a fool. The tool just makes the mess arrive faster and look more professional on the way in.
everyone can build the toy now
Here’s what actually changed. The floor went up. Anyone can build a small, working app now, and that’s genuinely great. That barrier being gone is good for the world.
But the ceiling didn’t move an inch, and the ceiling is where the money is. The distance between „it runs on my laptop“ and „it runs for ten thousand people who will absolutely notice when it doesn’t“ is the same distance it’s always been. Load. Failure modes. What happens at the p99. What happens when the database gets slow and every request starts piling up behind it. What happens when a dependency times out and you have no circuit breaker so the whole thing cascades.
None of that shows up in a demo. All of it shows up in production. And AI will help you with every single piece of it, but only if you can name the piece.
so go get sharp
The takeaway isn’t „don’t use AI.“ That’s stupid advice and I’d be a hypocrite. I use it constantly.
The takeaway is that your value moved. It’s not in typing the code anymore. It’s in knowing what to ask for, and knowing when the answer you got is not good enough. That’s a knowledge problem, and knowledge is the one thing you can’t prompt your way around, because you have to know the thing exists before you can ask about it.
So build the skills. Learn how distributed systems actually fail. Learn what a token bucket is and why it beats a sliding window when traffic is bursty. Learn why graceful shutdown matters and what SIGTERM does to your pod. Learn enough operations to have opinions about deployment topology. There is more free material for this than has ever existed, and you can absolutely use AI to build yourself a learning path and quiz you along the way, which is honestly one of the best things it’s good for.
Then take all of that and point it at the tools. Because someone who knows the craft, holding a model like this, ships better software faster than anyone could five years ago. That combination is legitimately unfair.
Just don’t be the other guy. The one whose app works perfectly right up until the moment someone uses it.
Peace, nerds.