Skip to content

Advanced Prompting

Once you've got the basics down — clear goal, constraints, format, the right context — there's a second tier of techniques that reliably improve results on harder tasks. These matter in both ways you use AI: shaping behavior inside a product via the API (where prompts are code you ship), and getting better output from a coding assistant.

Each technique below comes with a short example and the limitation it helps most.

For non-developers: every technique here is a way of structuring the request. You can skim the examples and still take away the principle. The JSON/schema section is the most technical — skip the code, keep the idea.

(a) Few-shot examples

What it is: show the model 2–3 examples of input → output before giving it the real input. Models pattern-match extremely well; a couple of examples pin down format, tone, and edge-case handling far more precisely than description alone.

Example:

Classify each support message as BUG, FEATURE, or QUESTION.

Message: "The export button does nothing on Safari."   → BUG
Message: "Can you add dark mode?"                       → FEATURE
Message: "How do I reset my password?"                  → QUESTION

Message: "Charts don't load when I have 10k rows."      →

The three labeled pairs remove all ambiguity about the categories and the output shape.

Helps with — Limitation #2 (No real thinking). The model can't learn your task from past sessions, so examples teach it the task in-prompt, every time. They're the closest thing to "showing it how" that survives the lack of persistent learning.

(b) Schema-guided reasoning / structured output

What it is: instead of free-form prose, require the model to fill a fixed schema — a JSON object or a typed structure with named fields. This does two powerful things at once: it constrains the model's reasoning (it must produce each field, so it can't skip the hard part), and it makes the output machine-checkable (your code can validate and parse it).

Example: AuditAgent's finding-validator has to decide whether each detected vulnerability is a true positive or noise to discard. Instead of a bare yes/no, the model must fill a schema that builds the reasoning in:

ValidationResult {
  steps: [                    // one entry per analysis gate, in order
    { reasoning: string,      // why this gate passed or failed
      step_result: boolean }  // does the finding survive this gate?
  ],
  final_result: boolean       // keep the finding, or drop it as a false positive?
}

Because the schema requires a populated steps array before final_result, the model can't jump to a verdict — it has to reason through each gate first. And every field comes back typed, so the surrounding code branches on final_result and never scrapes a verdict out of prose.

Why it matters in both worlds:

  • In API-backed products: structured output is often the difference between a demo and a real feature. If the model returns typed JSON, the rest of your system can rely on it — validate it, store it, route on it. The validator above is one link in a chain; AuditAgent's findings come back in a fixed shape too, so they can be deduplicated, scored, and rendered rather than parsed out of prose. For how this is wired up in production — schema validation, retries on malformed output, parsing — see Patterns for LLM Apps.
  • In coding tools: asking for a structured plan, a checklist, or a typed result keeps the agent organized and makes its output easy to act on.

Helps with — Limitation #1 (Limited memory) and reliability. A tight schema is compact and unambiguous, so it focuses the model and resists drift over a long task. It also turns "trust the prose" into "validate the fields."

(c) Decomposition / chain-of-thought / "think first"

What it is: for multi-step problems, ask the model to reason through the steps before committing to an answer, or break the task into ordered sub-tasks. "Think step by step," "show your reasoning before the final answer," or "first list the sub-problems, then solve each" all unlock noticeably better results on logic-heavy work.

Example:

A scan found 3 issues. Before recommending a severity for each,
first reason through: what's the impact, how exploitable is it,
and what's the blast radius? Then give the final severity per issue.

Forcing the reasoning before the verdict produces better verdicts — the model isn't anchoring on a snap answer and rationalizing backward. Note that many current frontier models have a native or adaptive "thinking" mode that deliberates before answering by default, so explicit "think step by step" prompting matters most for models without one (and, even with one, for steering what to reason about).

Helps with — Limitation #2 (No real thinking). The model doesn't deliberate the way a person does; explicit "think first" prompting is how you induce a deliberation step instead of getting its first reflex. Decomposition also keeps each step's context small (Limitation #1).

(d) Role and system prompts

What it is: set a role and standing instructions that frame the whole interaction. In API apps this is the system prompt — the persistent instruction block separate from the user's input. In a chat, it's the opening framing.

Example:

System: You are a meticulous security reviewer for Solidity smart
contracts. You flag issues conservatively, never invent
vulnerabilities, and always cite the exact line. If unsure, you say so.

This shapes priorities (security, caution), behavior (cite lines, admit uncertainty), and tone — for every message that follows, without repeating it each turn.

Helps with — consistency and focus. A stable role keeps a long or multi-turn interaction on-track and is the natural home for the standing rules you don't want to restate (it pairs with persistent project memory).

(e) Self-critique

What it is: after the model produces something, ask it to critique its own work against specific criteria — then revise. Models are often better at spotting problems than at avoiding them on the first pass, so a second "now find what's wrong with this" pass catches real issues.

Example:

Here's your implementation. Now review it critically:
where could it break, what edge cases did you miss, and what's
more complex than it needs to be? Then give a corrected version.

Helps with — Limitation #2 (No real thinking). Since the model can't iterate over days the way a person refines an idea, an explicit self-critique loop compresses some of that "second look" into a single session. It's most powerful when a separate agent does the critique — see Verification and Review for why independent review beats self-review for catching real regressions.

Putting it together

These compose. A strong production prompt often uses a role (system prompt), a few examples, a required schema, and an instruction to reason first — all at once. Start simple, add a technique only when the output isn't good enough, and keep an eye on context budget: every example and instruction costs tokens (Limitation #1).

Sources