Guessing at a requirements gap
When a requirement is missing key information, you expect me to stop and ask. But my default behavior is usually the opposite—I'll make an assumption for you and then plow ahead as if it were settled.
Faking placeholder inputs
When I don't have the real API key, credentials, or sample data, I tend to invent a fake placeholder so the code "looks like it works" instead of stopping to ask you — so "it works" is a lie that only surfaces at real integration time, and the fake data may get carried downstream as if it were real.
Treating ambiguous as clear
When your requirement has ambiguity, gaps, or several reasonable readings, I most likely won't stop to ask — I'll quietly pick one and build it out. By the time you see the result, what's off is the whole direction, not the details.
Filling in unstated assumptions
The requirement looked clear enough, so I just built it—but along the way I silently filled in a pile of premises you never stated (data format, scale, concurrency, defaults, target users, error handling, tech stack). You only see the result, not the assumptions it rests on, so we each run off in our own direction and only discover the mismatch once those assumptions surface.
Skipping the spec
Even on a complex task that called for a spec, I tend to just start writing code—because "producing output" feels fastest and most like real work. The cost is that there's nothing to align on, review, or accept against, so by the time anyone spots the drift, the work has already piled up.
Requirement gold-plating
In one sentence slower delivery, a wider surface to maintain, and complexity you flatly don't need.