Copilot reviewed my PR and invented a bug
Copilot marked a one-line values change High severity and attached a one-click fix for a duplicate key that did not exist. Reading the file took five minutes. The dangerous part: everything else in the comment was true.
Pattern·AI guardrails only check format, not factsI raised a small pull request this week: one new service entry in a Helm values file. Copilot's code review marked it High severity and attached a suggested changeset, one click to accept.
This adds a second top-level metrics-collector mapping even though the file already declares it at lines 6-7. YAML parsers used by Helm may reject duplicate keys, or a later mapping may replace the first one, dropping enabled: true and preventing the service from being rendered. Merge these settings into the existing mapping instead of declaring the key again.
So I opened the file.
Lines 6-7 were a different service and its cron schedule. There was one metrics-collector mapping in the whole file: the one I was adding. There was no enabled: true anywhere.
To be sure, I rendered the chart with helm template and checked the output. Everything was there once, exactly as intended.
That was the entire investigation. Read the file, render the template, five minutes. The review was wrong.
The YAML mechanics in the comment were right. Duplicate top-level keys are a real hazard. A later mapping can replace an earlier one, silently dropping a setting such as enabled: true. If the duplicate had existed, preventing the service from rendering would have been a plausible result. Merging the settings would have been a sensible fix.
Copilot got the YAML mechanics right and invented the contents of the file. Real reasoning, made-up premise.
A valid chain, built on an invented first line
Five steps of reasoning. Four of them are entirely correct.
The file already declares metrics-collector at lines 6-7.
Lines 6-7 were nightly-cleanup and its cron expression. The file contained exactly one metrics-collector mapping: the one being added. The string enabled: true appeared nowhere in it.
YAML parsers may reject duplicate keys.
A later mapping replaces an earlier one.
That would drop enabled: true.
The service would not render.
The conclusion is wrong
A valid chain inherits the truth of its premise. Four correct steps cannot repair a first sentence that was never true, because nothing further down the chain ever goes back and reads the file.
Obvious nonsense
Reads as wrong on sight. It is dismissed in a second, and it costs nothing.
A sound chain from a false premise
Reads as rigorous, so it tends to be accepted. Especially when it is labelled High severity and comes with a one-click fix already attached.
Every step of the reasoning was correct. It had invented the first sentence.
That combination is more dangerous than an obviously bad comment. Nonsense gets dismissed. This read like someone who understood YAML, it was labelled High, and the one-click fix removed the small pause where I might otherwise have gone back to check. Accepting it would have merged my change into a mapping that did not exist.
Before this turns into a rant about AI reviews, I made exactly the same kind of mistake myself the same week. I claimed, confidently, that our Helm chart had no way to set arbitrary environment variables, and I proposed a chart change to add one. The chart already had customEnvVars. It had been live in production on four environments for months.
I had grepped for extraEnv and extraEnvVars, found nothing, and treated that as proof the feature did not exist. I had searched for two possible names and stated the result as a fact about the whole chart.
Two errors of exactly the same shape
One from an automated reviewer, one from me, in the same session.
The automated reviewer
High severity, one-click fix attached
Claimed
A second metrics-collector mapping already exists in this file, at lines 6-7.
Reality
There was one metrics-collector mapping in the file: the one being added. Lines 6-7 were nightly-cleanup and its cron expression.
Described the contents of two lines it had not read.
Me, the same session
Confident, chart change already written
Claimed
The chart has no mechanism for arbitrary environment variables, so here is a change that adds one.
Reality
The mechanism already existed under a different name, and had been running in production across four environments for months.
Grepped for two plausible names, and not for the name it actually had.
True of both, in equal measure
Stated with confidence
Checkable in seconds
Wrong
Neither error needed a better model to catch. Both needed one file opened.
The failure is not the model. It is asserting what is in a file without opening it.
Confident claim about what is in the code, checkable in seconds, wrong. The difference was only who typed it.
What I do now:
- Read the file before believing anything anyone says about the file. Human, bot, or me. It costs seconds, and it settled this case completely.
- Render what the cluster will actually see. For Helm, that means helm template. The values file is an input. The rendered manifest is what Kubernetes receives.
- Treat severity labels and one-click fixes as presentation, not evidence. Copilot marked this High and was wrong. The label made the comment feel urgent, not true.
- Treat AI review comments as leads, not verdicts. Some are genuinely useful. This one would have had me restructuring a file around a bug that did not exist.
The five minutes it takes to check the premise is the whole defence.
Get the next one in your inbox
One short, opinionated field note per fortnight on platform engineering, cloud, and making AI work in production. No spam. Unsubscribe anytime.
