6. Prompting Basics for Code (Without Prompt-Engineering Theater)
Overview and links for this section of the guide.
On this page
What this section is for
This section teaches prompting basics for producing usable code consistently. Not “magic words.” Not rituals. Just practical communication patterns that:
- reduce missing requirements,
- reduce hallucinated architecture,
- reduce messy diffs and rewrites,
- increase repeatability and correctness.
By the end of Section 6, you should be able to write prompts that reliably produce a small, runnable implementation with clear “done” criteria—and you should know how to correct the model quickly when it drifts.
What “prompt-engineering theater” looks like
Prompt-engineering theater is anything that:
- makes you feel like you’re doing something sophisticated,
- but doesn’t measurably improve your ability to ship correct software.
Common examples:
- giant “roleplay” prompts that don’t specify constraints or acceptance criteria,
- copy/pasting huge system prompts into every conversation without a reason,
- asking for “best practices” instead of defining a concrete outcome,
- tuning clever wording instead of shrinking scope and adding tests.
If a prompt technique doesn’t help you get to runnable + verifiable faster, it’s probably theater.
The real prompting skills for builders
Builders get consistent results by doing a few simple things extremely well:
- Ask for a plan before code when ambiguity is high.
- Define constraints (runtime, libraries, style, file boundaries).
- Define “done” with acceptance criteria.
- Use examples as mini-tests to anchor edge cases.
- Force explicit assumptions so you can correct them early.
A reliable prompt structure for code
When you’re building software, a good default prompt structure looks like:
- Goal: one sentence outcome.
- Constraints: language, runtime, libraries, style, file scope.
- Acceptance criteria: observable conditions (tests, examples, commands).
- Interfaces: inputs/outputs, boundaries, public API.
- Process: ask for plan first; diff-only changes; confirm assumptions.
- Context: only what’s needed (files, errors, logs).
If you can’t summarize your prompt on one screen, it’s usually too big. Shrink scope until it’s crisp.
Section 6 map (6.1–6.5)
- 6.1 Ask for a plan before code
- 6.2 Define constraints: language, runtime, libraries, and style
- 6.3 Define “done” with acceptance criteria
- 6.4 Use examples as “mini tests”
- 6.5 Use a “stop and confirm assumptions” step
Where to go next
Explore next