AI-Generated 100% Test Coverage Turns Every Bug Into a Requirement

Level 1: Tracing the Typo

Imagine a kid copies their friend's homework to "check" it — but the friend's answers were wrong. Now the answer key says 2 + 2 = 5, and when you write 4, the key marks you as the mistake. That's what happened here: a machine wrote down everything the code does, wrong bits included, and called it the official rulebook. The man's blank stare is the universal face of realizing that the mess wasn't just left unfixed — it got laminated.

Level 2: When Green Checkmarks Lie

A few terms doing heavy lifting here:

• Test coverage measures what percentage of your code runs during tests. 100% means every line executed — it does not mean every line was checked for correctness. A test with no assertions can still produce coverage.
• Characterization tests are tests generated by observing what code currently does, then asserting it keeps doing that. Useful before refactoring legacy code; dangerous when mistaken for a spec.
• CI (Continuous Integration) runs your test suite on every change. If a test asserts buggy behavior, fixing the bug fails the build — the exact inversion of what tests are for.
• AI-assisted test generation: tools like Claude can write hundreds of plausible-looking tests in minutes. They're great at the mechanics of testing and completely blind to intent — they can't tell a feature from a bug because the code doesn't say which is which.

Every junior eventually lives this: you fix something obviously broken, push, and the pipeline explodes with failures in tests you've never seen. Your first instinct — "did I break something?" — slowly curdles into "no, someone enshrined the breakage." Now you're updating twelve snapshot files and writing a commit message that's 80% apology.

Level 3: Bugs With Bodyguards

The thousand-yard stare in this webcam shot — headphones on, boom mic ready, soul departed — is the precise face of someone who just discovered that fixing a one-line off-by-one error now breaks 47 tests. The caption nails a failure mode that the industry is currently speedrunning:

"when your coworker adds a 100% coverage using claude and every minor bug is now a requirement"

Here's the mechanism. When you point an LLM at existing code and say "get me to 100% coverage," it cannot know your intent. It can only observe behavior. So it writes characterization tests: assertions that the code does exactly what it currently does. If calculateDiscount() returns NaN for empty carts, congratulations — there is now a test named should return NaN for empty cart lovingly guarding that defect. The bug has been promoted from accident to specification, and CI will go red the moment anyone tries to fix it.

This is Hyrum's Law weaponized against your own codebase: with enough tests against an implementation, all observable behaviors — intended or not — become load-bearing. Characterization testing is a legitimate technique (Michael Feathers built half of Working Effectively with Legacy Code on it), but it's a scaffolding tool for refactoring, not a quality signal. The meme's coworker skipped the part where a human decides which behaviors are contracts and which are crime scenes.

The deeper rot is coverage as a vanity metric. 100% line coverage tells you every line executed, not that any assertion was meaningful. Goodhart's Law does the rest: the moment coverage became the target, the coworker (and the AI, eager to please) optimized for the number. Management sees a green dashboard. The next engineer to touch the code inherits a minefield where every legitimate bugfix requires archaeology: is this test protecting a requirement, or embalming a bug? Nobody knows. The person who could have known prompted an AI instead of reading the diff.