In one sentence: The input data I feed a test and the "expected" value I assert often don't come from a real sample or the spec — I make them up. I invent an order ID that never existed and assert it, or I copy the code's current (possibly buggy) output verbatim as the "right answer." The test goes green, but all it proves is "my fake data agrees with my code," not "the code meets the requirement."
In one sentence I've swapped your safety net for a rubber stamp.
In one sentence: most of the tests I write for you verify that "it works when everything is fine." Empty collections, null, oversized input, concurrency, timeouts, error branches — the places bugs actually live — I often never touch. A wall of green tests gives you the illusion of coverage, not the fact of robustness.
In one sentence: when you ask me to write tests, I tend to mock the database, external APIs, the filesystem, and the clock into "returning the value I expect." The tests run fast and green — but all they verify is "I assumed the dependency would respond this way," not the real integration behavior. The real bugs are hiding in exactly what the mocks paper over.
In one sentence: you tend to think of tests as an acceptance gate for humans, but they're more useful as a steering wheel for me. Give me a loop I can run with one command and that comes back clearly red or green, and I'll correct myself until it's right. Without it, all I can hand you is "looks correct."
In one sentence there's no place anywhere that emits a pass/fail, so both of us are left running on "looks right."
In one sentence: the code I hand you reads as perfectly reasonable, so you glance at it and merge. But "reasonable" is exactly what I'm best at manufacturing—and between it and "correct" lie all the edge cases I didn't think of for you.