An AI coding assistant does not reason toward the simplest fix. It pattern-matches against whatever showed up most often in its training data, and popularity is not the same thing as correctness for your specific problem.
The Details:
Training data rewards volume, not fit. "Parse a date" becomes a full date library because that pattern appears in thousands of tutorials, not because a standard library call would fail. The model surfaces the loudest match, and loud usually means old conventional wisdom baked in from years of Stack Overflow answers, some of it already outdated.
Size mismatch is the tell. When a full validation package shows up to check that one field is not blank, or a date framework arrives to format a single timestamp, the tool is bigger than the job. That gap between effort and need is the signature of a dependency that is decorative rather than load-bearing.
The fix belongs before generation, not after. Reviewing dependencies during code review means the complexity is already wired in and expensive to remove. Telling the assistant upfront, no new package without justification, changes what comes back in the first draft. Some teams push further with a hard cap on new dependencies per quarter, which forces developers to notice that the twenty-line utility they almost imported is, in fact, twenty lines.
Durability is the wrong goal. Code meant to last forever tends to calcify into something nobody wants to touch. The better target is legible and swappable: understandable without reverse-engineering three abstraction layers, and built so the pieces likely to age, like an HTTP client or date library, sit behind a seam you can replace in an afternoon.
Bottom Line: The tax on unnecessary complexity gets paid later, at 2am, six months out; the only way to avoid it is to reject the first answer before it becomes the only answer.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
