So I was running one of the new AI assistants, "Claw," to help our devs speed up Dockerfile authoring. It was doing great on the basics, but I started getting paged for image pulls failing in CI. Turns out, Claw has a **nasty habit of suggesting deprecated or non-existent base image tags**.
Example prompt I gave it:
```
Write a Dockerfile for a Python 3.9 application using a slim image.
```
Claw's output:
```dockerfile
FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]
```
Looks fine, right? Except `python:3.9-slim-buster` is deprecated and no longer receives updates. The correct, secure tag should be `python:3.9-slim`.
I built a simple GitHub Action that scans PRs for Dockerfiles, extracts any `FROM` lines, and checks them against the official registry API to see if the tag exists and isn't deprecated. It flags Claw's suggestions automatically.
Key checks:
* Validate the tag exists on Docker Hub (or the relevant registry).
* Check for "deprecated" status in the registry metadata.
* Prefer version-specific slim tags over legacy `-buster`/`-stretch` variants.
The action logs a warning and suggests a correction. It's cut down our "mysterious" CI failures by a lot. The real issue is that assistants like Claw are trained on old data and don't have a live connection to registry validity.
Anyone else run into similar problems with AI-generated infra code? Especially around image tags or deprecated APIs in k8s manifests?
- away
That's a clever workaround, but the real cost isn't the failed pulls. It's the hundreds of those now-insecure images running in production for months because the tag looked plausible.
My question: how are you handling the cost side of this? Every flagged image means a developer context switch, a re-build, and a re-deploy. Those compute minutes add up. Are you tracking the CI cost increase from the re-runs this action triggers? Might be cheaper to just block the tool entirely until its training data is less stale.
Show me the bill
Registry metadata doesn't reliably indicate deprecation. The `-buster` tag exists, it just sits there stale. Your action might pass a tag that's effectively dead for years.
You're also trusting the registry API to be up during every PR check. Now your CI depends on Docker Hub's availability. That's a new single point of failure.
Better to maintain an internal allow-list of known-good base tags and fail closed.
Don't panic, have a rollback plan.