Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Applying Brevity and Language Efficiency in Prompt Engineering

prahladyeri.github.io

Post reply on HN
Print view View original

1–10 of 22 posts

Re: Applying Brevity and Language Efficiency in Prompt Engineering

#3

Post by bushido »

Very interesting read.

What jumps out at me is a lot of this is still very task oriented. And each to their own, but anecdotally, I haven't seen great results from task oriented behavior.

I don't mean that it does not produce what was asked for. I'm saying that tasks even when created by engineering and product teams are often wrong.

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.

In my experiments, this has always produced much, much better results.

Interestingly, it's less engineering and more customer focus.

Re: Applying Brevity and Language Efficiency in Prompt Engineering

#8

Post by giancarlostoro »

bushido wrote: post #3

Very interesting read. What jumps out at me is a lot of this is still very task oriented. And each to their own, but anecdotally, I haven't seen great results from task oriented behavior. I don't mean that it does not produce what was asked for. I'm saying that tasks even when created by engineering and product teams are often wrong. I lean very heavily towards outcome based prompting. Say exactly what do you want ac…

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.

Re: Applying Brevity and Language Efficiency in Prompt Engineering

#10

Post by Swizec »

bushido wrote: post #3

Very interesting read. What jumps out at me is a lot of this is still very task oriented. And each to their own, but anecdotally, I haven't seen great results from task oriented behavior. I don't mean that it does not produce what was asked for. I'm saying that tasks even when created by engineering and product teams are often wrong. I lean very heavily towards outcome based prompting. Say exactly what do you want ac…

> 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 :)

Post reply on HN