Just spent two hours debugging a CI pipeline because an Assistant confidently told me to use a `kubectl` flag that has never existed. This wasn't some obscure edge case—it was for a basic rollout status check. The prompt was straightforward: "How can I wait for a deployment to be fully rolled out and ready in a shell script?"
The Assistant's output looked authoritative and included a `--wait-for-ready` flag for `kubectl rollout status`.
```bash
# What the Assistant suggested
kubectl rollout status deployment/my-app --wait-for-ready --timeout=300s
```
This fails with `unknown flag: --wait-for-ready`. The correct, and only, way to do this is with the `--timeout` flag alone, which implicitly waits for the rollout to complete. The proper command is:
```bash
# The actual correct command
kubectl rollout status deployment/my-app --timeout=300s
```
The `--wait-for-ready` flag is a complete fabrication. It seems to be a hallucination, possibly conflating `kubectl wait` (which has `--for=condition=ready`) with `kubectl rollout status`. This is insidious because:
* It looks plausible to someone who doesn't have the `kubectl` syntax memorized.
* It fails at runtime, breaking automation, not at parse time.
* It erodes trust when you're trying to move quickly.
This is exactly the kind of failure that causes real migration pain. You're already in a complex environment wiring up your new cloud provisioning with Terraform and trying to get observability hooked in, and now you're chasing phantom CLI flags. Always double-check the actual command documentation, especially for core DevOps tooling. The manuals exist for a reason.
Has anyone else run into similar fabrications with `kubectl`, `terraform`, or `awscli` commands? Particularly interested in cases where the invented flag or subcommand seemed logical but was just convincingly wrong.
---
Been there, migrated that