# Prompt technique on one card: overview, choice, and depth
[Skip to content](#lm-inhoud)Network/[NL](/prompttechniek-hiërarchie)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie&text=Prompt%20technique%20on%20one%20card%3A%20overview%2C%20choice%2C%20and%20depth)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie&title=Prompt%20technique%20on%20one%20card%3A%20overview%2C%20choice%2C%20and%20depth)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie&text=Prompt%20technique%20on%20one%20card%3A%20overview%2C%20choice%2C%20and%20depth)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fen%2Fprompttechniek-hi%C3%ABrarchie&title=Prompt%20technique%20on%20one%20card%3A%20overview%2C%20choice%2C%20and%20depth)[](#)
# Prompt technique on one card: overview, choice, and depth
By Ivo Donker — compiled with AI assistance (Claude & Gemini)
In software development with large language models, an unchecked proliferation of prompts and ad-hoc instructions quickly emerges. Anyone who starts experimenting soon runs into dozens of different methods: from simple zero-shot prompts and extensive example sets to advanced reasoning structures and autonomous feedback loops. Without clear categorization, this often leads to needlessly complex prompts, unpredictable model costs, and unnecessary delays in API calls.
To keep a grip on prompt design as a serious software engineering discipline, it's crucial not to apply just any random technique, but to reason from a consistent architectural hierarchy. This reading guide brings the different development layers together onto one clear card. We look at how to navigate from an exploratory overview via a focused decision layer to specialist implementation details.
## The three-part hierarchy: catalog, decision tree, and implementation
The landscape of prompt engineering can be divided into three logical layers. Each layer fulfills a specific function within the design process of a language model application and prevents a developer from falling into micro-optimizations too early.
The first layer is the broad catalog. This is where all available patterns are inventoried and described, including their theoretical workings and fundamental purpose. This is the encyclopedia in which concepts such as context steering, role assignment, and sequential deduction are collected.
The second layer forms the decision layer. Not every task requires heavy reasoning steps or dozens of examples in the context. The decision layer forces a trade-off based on hard constraints: required output quality, maximum latency, token budget, and the inherent capabilities of the chosen base model. This is where it's determined which method from the catalog is minimally necessary to achieve the desired reliability.
The third layer is the in-depth implementation. Once a specific technique has been chosen, the actual implementation requires in-depth knowledge of edge cases, syntax separation, selection of representative examples, and error handling. This hierarchical approach ensures that you never consume more tokens or compute time than strictly necessary for a task.
## Layer 1: Exploring the broad catalog of techniques
Anyone designing a new application starts by taking stock of the available building blocks. A complete overview of patterns helps you understand what a language model can solve autonomously and where explicit steering is needed.
In practice, we see that many developers fall back on familiar reflexes without surveying the full palette. Check out [the overview of ten common prompt techniques](https://community.llmnet.nl/en/prompt-technieken) to get a complete picture of the fundamental methods and their interactions within text processing. This broad inventory categorizes methods such as zero-shot instructions, role patterns, negative steering, structured data extraction, and iterative refinement.
Taking stock of techniques also directly exposes the model's inherent limitations. A model that has to extract facts from complex legal or medical texts without examples shows a higher error margin than when explicit templates are provided. The catalog thus also serves as a frame of reference for determining which mechanisms are mathematically or structurally suited to specific tasks.
## Layer 2: The pragmatic selection layer and decision rules
Once all techniques are known, the most important step in production follows: choosing which one you not use. A common design mistake is overloading prompts with dozens of instruction rules and chains of reasoning steps for tasks that could be handled with a simple, direct question.
The selection process follows a strict, step-by-step ladder. You always start with the simplest variant: a direct instruction (zero-shot). Only once standardized evaluations show that the model fails on format, style, or domain logic, do you move up to more complex patterns. Consult [the decision guide for choosing the right prompt technique](https://community.llmnet.nl/en/prompttechniek-kiezen) to systematically determine which method fits your specific requirements for latency, cost, and accuracy.
The selection layer takes three decisive parameters into account:
- Task complexity: Is it a simple transformation (such as classification or summarization) or multi-step deduction (such as code analysis or mathematical calculations)?
- Model size: Large frontier models often need nothing more than concise zero-shot instructions, while compact, locally running models benefit from rigid structures.
- System budget: Every extra instruction or reasoning step increases the number of input and output tokens, which has direct consequences for the API bill and turnaround time.
## Layer 3: In-depth implementation and constraints
Once a specific technique has been selected via the decision tree, the fine-grained engineering work begins. A technique such as in-context learning with examples looks trivial, but the practical execution has countless pitfalls.
Take, for example, including demonstrations in the context. If the examples are unevenly distributed across different categories, the model develops a strong bias toward the overrepresented class. Read [the in-depth guide on few-shot prompting](https://community.llmnet.nl/en/few-shot-prompting) to see how to structure examples, prevent bias, and optimally set up delimiters for maximum consistency.
In in-depth implementation, micro-architectural choices play a decisive role. This includes the choice between Markdown headers or XML tags for semantic block separation, defining fault-tolerant schemas, and consistently isolating dynamic user data from static system instructions.
Architecture layer |
Primary Objective |
Typical Question |
Main Risk |
1. Catalog |
Taking stock of patterns |
What methods theoretically exist for this type of problem? |
Unfamiliarity with newer or more efficient techniques. |
2. Decision layer |
Filtering on constraints |
What's the simplest technique that meets our SLA and accuracy requirement? |
Over-engineering, unnecessary token costs, and overly slow response times. |
3. In-depth implementation |
Implementing robustly |
How do we prevent edge-case failures, formatting drift, and context pollution? |
Subtle hallucinations, distribution bias, and vulnerability to prompt injections. |
## Advanced reasoning paths and verification methods
For tasks in which a language model must make logical deductions, deterministic single-pass prompts often fall short. When a model is forced to generate a final answer directly, it tries to predict the outcome in a single forward computation. With complex arithmetic or logic problems, this leads to frequent errors.
To drastically increase the reliability of complex reasoning, you can have multiple reasoning paths generated and aggregated in parallel. Read [the article on self-consistency prompting](https://community.llmnet.nl/en/self-consistency-prompting-redeneringsstappen) to understand how multiple independent deduction paths lead to a more robust final result through majority voting. This technique compensates for the inherent stochastic variation of autoregressive models.
The downside of these advanced verification methods, however, is a proportional increase in compute costs. Where a standard Chain-of-Thought (CoT) prompt generates a single reasoning sequence, self-consistency requires five to ten parallel samples. This makes the technique extremely suitable for offline analysis or critical validations, but impractical for real-time interactive user interfaces.
## Trade-offs between token pressure, latency, and determinism
Every prompt technique represents a specific trade-off in a three-dimensional space: token pressure (cost), latency (speed), and determinism (accuracy). Blindly stacking instructions leads to an exponential increase in resources without a proportional gain in quality.
Below we illustrate how a simple transformation task evolves from a minimalist zero-shot setup to a robust, production-worthy template with clear separation of variables:
### MINIMALISTISCHE ZERO-SHOT (Laag 1)
Classificeer het sentiment van de onderstaande tekst als POSITIEF, NEGATIEF of NEUTRAAL.
Tekst: De levering was twee dagen te laat, maar het product zelf overtreft alle verwachtingen.
Sentiment:
### GESTRUCTUREERDE DIEPTE-IMPLEMENTATIE (Laag 3)
Analyseer het sentiment van de aangeleverde klantbeoordeling.
Volg deze stappen:
1. Identificeer expliciete klachten en complimenten.
2. Weeg het eindoordeel af op basis van de algehele klantervaring.
3. Retourneer uitsluitend een JSON-object volgens het onderstaande schema.
{
"aspecten": {
"levering": "string",
"productkwaliteit": "string"
},
"eindoordeel": "POSITIEF" | "NEGATIEF" | "NEUTRAAL"
}
De levering was twee dagen te laat, maar het product zelf overtreft alle verwachtingen.
The extended implementation introduces more input tokens and enforces structured steps. In production environments with millions of calls per day, this extra overhead must be clearly justified by a measurable drop in parsing errors or downstream data pollution.
## From static prompt to dynamic interaction structures
As tasks become more complex, a static prompt is no longer enough to catch every exception. In modern AI architectures, the center of gravity shifts from isolated prompts to dynamic feedback loops, tool calls, and multi-agent networks.
When a prompt has to decide which external APIs are called or how error messages from previous steps are corrected, we speak of programmatic control flows. Anyone who wants to make the move from text manipulation to full-fledged software systems can find more depth in [the transition from prompt engineering to graph engineering](https://community.llmnet.nl/en/van-prompt-naar-graph-engineering), which describes how deterministic graphs and cyclic loops safeguard the reliability of agents. These structures elevate prompt techniques above the level of a single API call.
This shift also demands different skills from software developers. For those who want to expand their professional profile into the engineering of agent systems, the overview on [a career path as an AI agent engineer in 2026](https://leren.llmnet.nl/en/ai-agent-engineer-worden-2026) offers concrete guidance on the necessary frameworks, evaluation infrastructures, and system integrations.
## Evaluation, regression testing, and documentation as a discipline
A prompt technique can only be called reliable once its effectiveness has been proven numerically on a representative test set. Many teams make the mistake of manually evaluating prompts on two or three random examples in an interactive interface. This leads to continuous regressions: a change that fixes one specific edge case silently breaks five other use cases.
A mature prompt engineering process applies the same quality standards as traditional software development:
- Golden test sets: Build a dataset of at least 100 varied input examples with expected outcomes, including tricky edge cases and deliberately faulty inputs.
- Automated evaluation metrics: Measure quantitative success criteria, such as JSON validation rates, exact-match scores, semantic similarity, and token consumption per successful call.
- Version control: Treat prompt templates as source code. Every change to the prompt text, temperature setting, or delimiter tags belongs in a version control system with accompanying changelogs and benchmark results.
- A/B testing in production: Roll out new prompt variants in phases to a limited percentage of live traffic to monitor whether user interactions and downstream processes don't unexpectedly degrade.
## Overview table: the technique hierarchy in practice
The table below bundles the three hierarchical layers and links specific use cases to the recommended methodology, the expected overhead, and the typical pitfalls that need to be monitored during implementation.
Use case / Task type |
Primary Technique |
Recommended Layer |
Token overhead |
Point of Attention |
Standard text classification |
Zero-shot + strict schema |
Layer 2 (Decision Tree) |
Very low |
Keep labels unambiguous; avoid overlapping classes. |
Domain-specific extraction |
Few-shot with XML tags |
Layer 3 (Depth) |
Medium |
Ensure balanced and varied examples. |
Mathematical / Logical deduction |
Chain-of-Thought (CoT) |
Layer 2 (Decision Tree) |
High (output) |
Force explicit intermediate steps before the final answer. |
Critical factual verification |
Self-Consistency + Context |
Layer 3 (Depth) |
Very high |
Requires multiple parallel calls and aggregation logic. |
Complex data integration |
Tool-use / Graph loop |
Dynamic (System) |
Variable |
Implement strict timeouts and validating intermediate steps. |
## Building systematically with the map in hand
Prompt engineering is not a matter of writing intuitive text, but of controlled system design. By approaching the landscape through the three-way split between catalog, decision tree, and in-depth implementation, you prevent applications from getting stuck in unpredictability or excessive operating costs.
Always start with a sharp definition of the problem, choose the simplest technique that's mathematically and structurally sufficient, and only optimize at a detailed level once automated evaluations give reason to do so. With this structured discipline, language models become reliable, predictable components within modern software architectures.