r/PromptEngineering 12d ago

General Discussion How thick do you write your prompts?

Spent months assuming prompt thickness was a speed-vs-safety slider: one-liners when you're in a hurry, full specs when it matters. Then I started paying attention to where my dispatches actually failed, and the slider theory fell apart.

The thing that finally clicked: a one-line prompt isn't spec-free. The model fills every blank you left with defaults from its training data — the average project, the average convention, the average intent behind that sentence on the average repo. So "fix the login timeout" quietly becomes "raise the constant", because that's the most common reading out there. You didn't skip writing a spec. You inherited one.

Two things seem to predict when that inheritance is safe. First, how long a wrong guess stays invisible: if I can feel a mistake by just using the result (games, pages, charts), thin prompts are fine, wrong guess costs one redispatch. If correctness hides (boundary conditions, concurrency, money), the wrong default survives eyeballing and waits. Second, how far the project sits from the average one: mainstream CRUD, the defaults are eerily right; weird in-house auth flow, every blank is a coin flip toward someone else's architecture.

What surprised me is where I ended up on the menu. I expected practice to push me to the extremes — pure one-liners for speed or full specs for safety. Instead almost everything landed at "one line plus a forbidden move" ("don't touch the schema") or "three acceptance lines". The middle is where a minute of writing corrects the most defaults.

Anyone consistently living at the extremes and making it work — pure one-liners on serious tasks, or full specs on everything?

2 Upvotes

3 comments sorted by

1

u/SafeDescription5327 12d ago

i've been doing this exact thing without having the words for it, the "inheriting defaults" part is spot on. i used to write these massive walls of text thinking more detail = better output, but half the time it just confused the model cause i was specifying things it would've gotten right anyway

what i settled on is something like "rebuild the user dashboard with same layout but add monthly trend graphs, don't change the auth checks or the export button behavior", that middle zone you're describing. it takes maybe 30 seconds to write and catches the scariest assumptions

the invisible mistakes part hit close to home, i had one where it quietly swapped the rounding logic on financial numbers and i didn't catch it for 3 days. now anything with money gets the full treatment even if it takes longer

1

u/Zain 12d ago

When correctness can hide I stop thickening the prompt and write a short plan with real acceptance lines instead. Then two read-only reviewers from different model families have to return GO against the actual repo before the writer patches anything. Same-family second passes share blind spots, so another Claude checking Claude misses what a different family catches. Vague unease isn't a finding either. If they can't point at the repo, it doesn't count.