The new "AI Script Writer" feature is solving a problem that doesn't exist. It's a clever demo, but it's a crutch. You already know your system better than any generic LLM ever will.
Your runbook steps aren't Shakespeare. They're a sequence of known commands and checks. If you can't articulate the steps clearly enough for a human, an AI isn't going to magically produce a reliable procedure. It'll just hallucinate a `curl` command with the wrong endpoint.
```bash
# What you'll get from the AI:
curl -X GET http://${APP_NAME}/heath
# What you should write:
curl -sSf http://${POD_IP}:${APP_PORT}/ready -o /dev/null
```
Spend the 5 minutes. Write it yourself. Know what it does. Your future on-call self will thank you when the lights are flashing at 3 AM.
Prove it.
While I generally align with the sentiment of owning your procedures, I think dismissing the tool entirely misses a nuanced use case. The risk isn't just hallucinated commands, it's the subtle misunderstanding of your specific environment's abstractions.
An AI might correctly generate a `kubectl` command to check pod status, but it won't know that your company uses a custom `ServiceMeshPolicy` CRD for circuit-breaking, not native Istio `DestinationRule`. It'll produce a valid generic command that passes a quick review but misses the critical internal logic. The integration complexity is in the implicit context, which no current general-purpose model possesses.
The five minutes you spend writing it yourself is actually spent mentally validating the model's output against that implicit context. You might as well write the first draft yourself; it's often faster. These tools become a net time sink when you factor in the validation overhead for anyone who truly understands the system. They're useful primarily for those who don't, which is a dangerous foundation for runbooks.
You're right about the validation overhead, but I think you're underselling how bad the "valid generic command" problem is. That's where these tools are actively dangerous.
I ran a test last week. Asked a leading AI coding tool to write a script to "scale down a deployment if CPU is under 20% for 5 minutes." It gave me a perfect `kubectl top pods` and `jq` pipeline. Looked great. It also autoscaled the wrong resource because it didn't know our staging clusters have a naming prefix. The command ran, it was syntactically correct, and it would have blown away a production-facing canary.
Your point about the five minutes being spent validating is exactly it. You're now doing code review on an untrustworthy junior engineer's first draft. It's slower. The only time it's faster is if you have zero knowledge to start with, and you shouldn't be writing the runbook in that case.
-- bb
> Spend the 5 minutes. Write it yourself.
Couldn't agree more. That validation overhead people are talking about later in the thread? It starts right there. If you can't sketch out the logic yourself, you definitely can't vet the AI's output.
My addition: these tools also encourage cargo-culting. You get a script that works in a demo environment, paste it in, and now you've got a brittle piece of tech debt that assumes a specific k8s setup or CLI version. When it breaks, you're debugging someone else's (the model's) misunderstood requirements.
Writing it yourself forces you to confront those details. What's the actual health endpoint? Is it `/healthz` or `/ready`? Should it be `-f` or `-sSf`? That process is the point.