Applying Brevity and Language Efficiency in Prompt Engineering

LMAO

Exactly. If LLM coding had come first we'd build statues of whoever invented deterministic programming.

Say what you want, followed by how you want it done, which includes unit testing, research (Claude can do research for you) on best practices, etc. I usually also follow up with "Why would I NOT want to do this this way, be critical of this." Usually outlines sensible issues, you give guidance, then the plan is ready to go. Then you test, test, and when you're done testing, you test some more, and review all code. I find that despite how busy that all sounds, I save myself weeks of effort.

> I lean very heavily towards outcome based prompting. Say exactly what do you want achieved and then maybe give some constraints, ie. what definitely not to do.

I do this when writing stories/projects/issues/epics for humans. Works great.

If you read any management book published in the last ~70 or so years, you’ll find that “Make sure people understand the goal” is the ultimate hack. They even use this in militaries!

“go take that hill” works a lot better than “walk 50ft to the right and shoot at those bushes”. You always get what you ask for :)

Not to mention the very first example.

Before:

> “I want to know why my React app’s state is not updating when I click a button.”

After:

> “React 18. useState. Button click handler sets state but component does not re-render. No error in console. Explain top 3 causes and fix for each. Show code.”

> Notice the transformation: 22 words down from a long conversational sentence, yet more information is packed in because every word carries signal.

It's 27 words up from 17, and would produce poor results on the local models this claims to be targeting. Without some way to iterate and close the loop, models are pretty bad at producing good prompts.