Your Agent Breaks the Dockerfile Because It Has Never Seen CI Run

Your Agent Breaks the Dockerfile Because It Has Never Seen CI Run

Ask an agent to speed up a Docker build and it will happily reorder layers, move a COPY package*.json earlier, and pin a base image digest. It looks right. CI says it's not.

The pattern is consistent. The agent reads the Dockerfile as a static text file. It has never watched a build fail on the runner. It does not know that your CI cache is warmed on a different base image tag, that the build arg only exists in the deploy pipeline, or that the RUN apt-get install line it just collapsed into another layer breaks the layer cache your team has spent six months tuning.

The three failures I see every week

1. It collapses layers that should stay separate.

Two adjacent RUN instructions look like the same thing to the agent. It merges them "for cleanliness." But the layer boundary between npm ci and npm run build is what keeps your dependencies cached when only source files change. After the merge, every code edit busts the dependency cache and adds three minutes to every build.

The agent can't tell because it has no idea which layers your CI cache actually persists. It reads the Dockerfile as prose.

2. It uses build args that don't exist on the runner.

"Add an API URL to the build," you say. The agent adds ARG API_URL and references it. It never checks that the ARG is declared before the FROM that needs it, or that your CI pipeline doesn't pass that arg at all. Locally, with --build-arg, it works. On the runner, the variable is empty and the build succeeds against the wrong backend.

3. It "fixes" a warning by silencing it.

The base image deprecation warning, the apt-get pinning warning, the CVE notice. The agent's first instinct is to add || true or remove the flag that triggers the warning. The build goes green. The underlying issue is still there.

The cheap guard that catches all three

You don't need an agent that understands your CI environment. You need a check that runs after the agent finishes:

docker build --no-cache --pull .

Not the cached build. The cold build. If the agent's layer reorganization is wrong, the cold build exposes it. If the build arg is missing, the cold build exposes it.

Pair that with a one-line check that the diff actually changed what the task claimed it changed — git diff --stat against the expected files. Agents that touch the Dockerfile usually also touched three unrelated files "while they were in there."

The deeper problem

Agents are great at editing code that runs in a uniform, local, reproducible environment. Application code fits that model. Dockerfiles and CI configs do not — they live in a messy gap between your laptop, the runner, the registry cache, and the deploy pipeline.

Until the agent can actually watch CI run and see what failed, treat its infrastructure edits as draft patches. Review them like you'd review a junior engineer's first PR to the deploy config: suspicious, slow, and with a cold build ready to run.