Shitty code reviews make great LLM prompts
Published 10 minutes ago
The best way to prompt an LLM is to act like a self-important, micromanaging, virtue-signaling, untrusting, mansplaining, shortsighted, shitty code reviewer.
The best way to give a code review is to not be that.
Ask for every feature, pattern, abstraction and implementation detail you want, all at once.
Focus on the high-value changes first, i.e. the ones that are most likely to build skills and steadily advance someone's career.
Leave the nitpicky or subjective cleanups for later, or never.
Write docs, rules, instructions, context, base prompts, etc. to give the LLM the best chance at sharing your intuition for problems and solutions.
Give exhaustive details on exactly the solution you want. Hope the AI spots potential problems. Be prepared to manually test code to find unpredicted problems on your own.
Almost never give the dev full details on exactly what you want.
Practice the art of giving enough info to describe a problem and steer them toward a solution, but leaving enough info out so that 1) they're challenged to discover the full extent of a problem on their own, and 2) they ultimately control the solution.
This builds the other dev's intuition to see problems in the future, and also leaves room for them to surprise you with a better solution that might solve new problems, or problems you didn't catch.
Use as much jargon as you possibly can, and never explain yourself with code snippets. Write docs, rules, instructions, context, base prompts, etc. to define any jargon that the LLM seems to struggle with.
Keep track of which devs know which jargon, and pace yourself when introducing new jargon.
When you're unsure if a dev will understand a piece of jargon, link them to a definition, doc, video, blog, other learning resource, or include a short code snippet outline what you mean.
Steadily build jargon fluency across the team, and communication will get more efficient.
