Rahul Verma: My Petty Bits

Following is a list of some heuristics for a better experience while prompting an LLM. The mileage might vary, we are not talking exact science here. I am going to type what comes to my mind, as I don’t have a fixed goal of coming up with THE X-number of suggestions which can change the world :-). These are some ideas for you to think about and explore.

1. Be polite. Say “please”. Be appreciative when you like something. Be constructive when you don’t.
2. Avoid negatives: Instead of saying “Don’t respond with a long response”, try “Be terse.”. Not always possible/sensible.
3. Don’t give a large problem to solve in one go. Break it down. Take assistance from the LLM to break it down, if it helps.
4. By letting LLM ask clarifying questions, improve your understanding of the problem.
5. Direct it towards the kind of response you will like with focused prompts. Negotiate.
6. Decide on the input and output formats which work the best.
7. Prefer structural representation wherever possible.
8. Start from less elaborate, idea-like responses and then expand on the details.
9. Ask not to criticise but critique: always ask it to evaluate what’s good and what needs improvement especially in self-evaluation of its own output.
10. Understand yourself in relation to the LLM during initial experiments. Create custom instruction set for various situations: e.g. when you are writing a story vs when you are coding – add them upfront as a root prompt in a chat or in system prompt (user accessible configuration).
11. Experiment with multiple personas for the LLM as well as the audience.
12. Extract, develop and use checklists.
13. Identify when a part of the problem is coding-dominated.
14. Use numbered steps and other markdown constructs to instruct the LLM follow a procedure and bring its attention to parts of the prompt.
15. Practice prompting to generate prompts.
16. Never cram prompts, although it is valuable to create a personal prompt database to keep a track of what works for you.
17. Identify input/output mechanisms, think integration.
18. Be in-charge. An LLM is a tool. You are the one who is responsible for solving the problem. So, do proper context building, never consume responses from an LLM blindly – understand the background technology so that you are not led by hype, and put them in use where they can add value.
19. When the prompts increase in complexity, which they will, beyond basic experiments, think Custom-GPTs or equivalent.
20. (Note for me): Prompt engineering should be about how to move major part of the prompting to auto-prompting, to maintain a state of simple prompting for the user. Think API, multi-LLMs and corresponding architecture.