DEVBOOK

Prompt Engineering

10 min read

EditReport

Prompt engineering turns an intention into a task the model can execute and the system can test. Small changes in wording or generation settings can shift output quality because an LLM samples from a probability distribution rather than following a fixed program.

In production, the prompt is part of the system interface. It needs explicit behavior, version control, and evaluation like any other executable contract. This hub covers the basic mechanics. Its child notes handle in-context learning, reasoning, prompt composition, and automated optimization in more depth.

Prompt Anatomy

Four elements cover most prompt contracts:

  • Instruction names the exact task.
  • Context supplies domain facts or constraints.
  • Input data contains the material to process now.
  • Output indicator defines the required answer shape.

The following prompt uses all four:

Instruction: Extract security risks from the incident note.
Context: You are helping a SOC analyst. Keep findings actionable and concise.
Input data: "API keys were stored in plain text logs for 3 days in staging."
Output indicator: Return JSON with fields risk, impact, mitigation.

Each element removes a different ambiguity. The instruction narrows behavior, context guides interpretation, input anchors the current case, and the output indicator constrains the result.

LLM Settings

Prompt text describes the task. Generation settings control sampling and output limits.

  • Temperature raises or lowers sampling randomness.
  • Top-p restricts candidate tokens to a cumulative probability mass. Lower values narrow the set.
  • Max tokens caps generated length and therefore limits part of the cost and latency.
  • Stop sequences terminate output when the model emits a specified string.

These starting ranges are heuristics. Production values need task-specific evaluation on the chosen model.

Task typeTemperatureTop-pMax tokensStop sequences
Creative writing0.8-1.00.9-1.0600-1200Optional section markers
Classification0.0-0.20.1-0.420-80Label boundary, newline
Code generation0.1-0.30.8-1.0200-800``` or custom delimiter

A simple starting policy is to tune temperature first and leave top-p near its default until an evaluation shows that both need adjustment.

Instruction Prompting

Instruction prompting states the task and result format directly. It works when the requested behavior is specific enough to observe and test.

A useful instruction usually contains:

  • A task verb such as classify, extract, summarize, or transform.
  • An explicit format such as a JSON schema, table columns, or a fixed label set.
  • Relevant constraints on length, forbidden content, confidence, or tone.

Example 1 (name normalization):

Convert the person name to this format: <Last name>, <First name>.
If suffix exists, keep it after first name.
Input: "Nikita Reshetnik"
Output:

Example 2 (PII redaction):

Redact all personal data from the email.
Replace names with [NAME], phones with [PHONE], and emails with [EMAIL].
Return only redacted text.
Input: "Hi John, call me at 410-805-2345."

When outputs drift, tightening the output indicator is usually cheaper than adding another prompting technique.

Role Prompting

Role prompting supplies a perspective that changes style, depth, or framing. The role modifies task execution. It does not replace the task.

  • It fits tasks where voice or audience matters.
  • Accuracy boundaries still need to be explicit.
  • Concrete roles work better than vague personas.

Illustrative contrast:

Standard: Write a review of this pizza place.
Role-based: You are a food critic writing for a city newspaper. Write a review of this pizza place in 120-150 words, focusing on crust texture, sauce balance, and service.

The second version gives the model a concrete perspective and observable review criteria. The role alone would not provide those constraints.

Choosing a Technique

This flow is a useful first pass:

flowchart TD
    A[Start with task goal] --> B{Simple direct task}
    B -->|Yes| C[Use instruction or zero shot]
    B -->|No| D{Need strict output shape}
    D -->|Yes| E[Use structured output or schema; add examples for semantics]
    D -->|No| F{Needs deeper reasoning}
    F -->|Yes| G[Use reasoning scaffolding plus verification]
    F -->|No| H{Multiple dependent steps}
    H -->|Yes| I[Use prompt chaining]
    H -->|No| J[Use role plus instruction]
    C --> K[Evaluate and iterate]
    E --> K
    G --> K
    I --> K
    J --> K

Strict output shape needs structured output or schema validation. Examples can clarify semantics that the schema cannot express. A task that cannot fit one instruction may need Prompt Composition. In both cases, representative evaluation matters more than eliciting hidden reasoning traces; meta prompting is only one way to generate candidate instructions.

Pitfalls

  • Indirect prompt injection from retrieved content. A document, web page, or tool result may contain malicious instructions that the model mistakes for trusted guidance. Mitigations keep trusted instructions separate from untrusted data, restrict tools by policy, and validate outputs.
  • Correct shape, wrong content. JSON can pass schema validation while carrying invented values. Semantic checks for ranges, required relationships, and source-grounded claims catch what the schema cannot.
  • Token budget collapse. Long context and verbose generations can crowd out critical instructions or examples. Input and output budgets are controlled together, and truncation is monitored instead of assuming the model saw everything.

Questions

References

4 items under this folder.