I Built the Same Feature Three Ways to See Which Prompt Style Wins

There's an endless debate about how to prompt Claude Code. One camp swears by short, punchy prompts - just tell it what you want and let it work. Another insists on writing a detailed spec so there's no ambiguity. A third says always make it plan first. Everyone's confident and nobody has evidence. So I stopped arguing and ran an actual experiment: build the exact same feature three times, once with each style, and see which one produced the best result with the least back-and-forth.

The feature was a CSV import - take an uploaded spreadsheet, validate the rows, map them to the right fields, and save them, with sensible handling for the messy real-world cases. Big enough to have decisions in it, small enough to build three times in an afternoon. Same codebase, same starting point, same desired end state. Only the prompt style changed.

First run: 'Add a CSV import that validates rows and saves them to the database.' One sentence, let it go. This is the style people love because it's fast and low-effort, and to be fair, it moved quickly. Claude produced a working import in minutes.

The trouble was everything it decided for me. It picked a validation approach I didn't want, made assumptions about the file format, and handled errors in a way that didn't match the rest of the codebase. None of it was wrong in isolation. All of it was drift - dozens of small decisions I then had to notice, question, and correct. The one-liner was fast to send and slow to finish, because the speed up front turned into a long tail of corrections. The less you say, the more Claude decides, and the more you review.

Second run, opposite extreme: I wrote a full spec before touching Claude. The exact validation rules, the field mapping, how to handle empty rows, duplicates, and malformed data, the error format, where to save. A solid page of detail. Then I handed the whole thing over.

This produced a much cleaner result than the one-liner. Claude followed the spec closely and the drift mostly vanished, because I'd made the decisions in advance instead of leaving them open. But it cost me real time up front - writing that spec took longer than the terse run took to build and correct. And it was rigid: a couple of my spec decisions turned out to be slightly wrong once I saw the feature working, and because I'd committed them so firmly, Claude built exactly what I'd specified rather than the better thing it might have suggested. I'd traded drift for a different problem - I front-loaded every decision, including the ones I wasn't yet qualified to make.

Third run: I described the feature at a middle level of detail and then asked Claude to write a plan and confirm it with me before writing any code. Not a one-liner, not a full spec - a clear description of what I wanted, followed by 'show me your plan first.' Claude came back with its approach: how it would validate, how it would map fields, how it would handle the messy cases.

That plan was where the magic happened. I could see the decisions before they became code. Two of them I adjusted in one line each - a validation choice and how duplicates were handled. The rest I approved. Then Claude built it, and because we'd aligned on the plan, the result came out clean on the first pass with almost nothing to correct. I got the alignment of the detailed spec without pre-writing every rule, and I got to fix the wrong decisions while they were still cheap - in the plan, not in the code.

Plan-first won, and not narrowly. It beat the one-liner on quality by a wide margin and beat the spec on both effort and flexibility. The one-liner's speed was an illusion that the correction tail erased. The spec's rigor was real but overpriced and inflexible. Plan-first landed in the middle on effort and came out ahead on the thing that actually matters - a clean result I trusted, with the wrong decisions caught while they were still cheap to change.

You don't need a ritual. Describe the feature at a reasonable level of detail - more than a one-liner, less than a full spec - and then add one instruction: 'Write your plan and let me confirm it before you write any code.' Read the plan, adjust the decisions you disagree with in a line each, approve it, and let Claude build. That single habit gave me the best result of the three styles on real work, and it's now my default in the desktop app for anything with actual decisions in it.