Ask for a parser and you often get a plugin registry, a strategy pattern, and three config options nobody requested. That gap between what you asked and what you received has a cost, and it lands on you, not the tool.
The Details:
The model is not showing off, it is guessing. With no signal about scope, it pattern matches against the average codebase it has seen, and that average leans toward production systems built to last years and serve many teams. Your one-off script gets dressed in architecture meant for someone else's five-year roadmap.
Three facts change the output more than any clever phrasing. State the code's lifespan, since a throwaway migration and a shipped parser need opposite designs. Show the one call site that will actually use it. Name what you explicitly do not want, because unstated boundaries are doors the model walks through by default.
Fixing a wrong foundation costs almost nothing in the first minute and a lot after three files and a test suite sit on top of it. The habit that works: scan the diff for every new class, interface, or config key, then ask if any current requirement actually uses it. If the answer is unclear for more than one, reject the whole draft rather than editing line by line.
Team culture quietly rewards the wrong instinct. A clever abstraction reads as senior work in review, while a boring inline function gets a shrug, even though the inline version is usually the one that survives. Treat a pull request that deletes two hundred lines as a feature, since safe deletion requires actually understanding the system.
Bottom Line: Every detail you leave unspecified gets filled in with imagined requirements that you will maintain forever, so scoping the problem precisely is the real engineering work, not the paperwork before it.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
