Prompt engineering playbook for programmers

Confusion, Non-determinism, and Inconsistency

• Several programmers describe LLM behavior as disorienting: small wording changes yield different answers, results vary run-to-run, and model updates break previously “good” prompts.
• This randomness makes it hard to justify heavy upfront “prompt engineering” as a reliable process.

Utility vs Overhead for Programmers

• Many say they’d rather just write the code: by the time a long prompt is crafted, refined, and run, the task could be done manually.
• LLMs are seen as most useful for quick documentation lookup, simple refactors, boilerplate, and debugging when you paste actual code or stack traces.
• Agentic tools are criticized for burning money/tokens and sometimes mangling codebases.

Are Prompt Guides Really Needed?

• One camp: guides are mostly hype; you learn “prompt fu” quickly through use, similar to early “Google-fu” books.
• Another camp: many users won’t systematically experiment, so curated tips and watching experts can meaningfully improve results and reveal non-obvious tricks.

Long vs Short Prompts, Context, and Iteration

• Multiple commenters report that shorter, focused prompts plus iterative refinement outperform long, intricate ones.
• Irrelevant detail is seen as harmful; relevant, structured context (markdown specs, project structure, style guides) can help.
• Some feel verbose prompts just get echoed back and give a false sense of control.

Specific Prompting Techniques Discussed

• Widely cited “real” techniques:
  • In-context examples (few-shot).
  • Chain-of-thought / step-by-step reasoning (less critical on newer “reasoning” models).
  • Structured output (JSON or schemas, sometimes via two-stage prompts).
  • Role / framing prompts (expert vs junior, critic vs collaborator).
• Using domain-specific jargon and expert vocabulary can noticeably change answers.

Debate Over “Prompt Engineering” as a Concept

• Strong pushback against calling this “engineering”: it’s described as trial-and-error, craft, or just clear technical writing/communication.
• Others argue that once you systematically test, version, and benchmark prompts—especially in pipelines and API workflows—it starts to resemble engineering practice.
• There’s concern that the focus on prompting is displacing core programming skills, though some see “native language as a programming language” as an inevitable shift.

Limits and Need for Better Tooling

• Consensus that if a task is beyond current LLM capability, no prompt will fix it; you must decompose into subtasks.
• Some argue that IDEs/agents should handle low-level prompt optimization, with developers focusing on clear requirements and tests rather than micromanaging prompts.