Prompt engineering basics: how to get better answers from AI

AI Engineering

Prompt Engineering in Practice: Moving Beyond "Act Like an Expert"

InformaticsOS 7 min read

Most public discussions around prompt engineering swing between useless mysticism and superficial advice like "tell the AI it has 20 years of marketing experience." In production engineering, prompting isn't about casting incantations. It is about conditioning the probability space of a non-deterministic transformer model so its output converges reliably on the exact structure and logic you need.

Large language models predict the next most likely token based on self-attention across your context window. When your prompt is vague, the probability distribution widens, and the model fills the ambiguity with generic training cliches. Quality prompts eliminate those alternate branching paths before generation even begins.

Context Window Conditioning

An LLM does not possess intent or intuition. It operates strictly on textual conditioning. If you don't constrain the format, execution boundaries, and evaluation criteria upfront, the model defaults to median internet text—which is wordy, cautious, and mediocre.

Prompting is fundamentally about constraint design. The tighter your boundaries on inputs, edge cases, and output schemas, the less room a model has to hallucinate plausible nonsense.

Conditioning the context window with structural delimiters produces deterministic, production-ready outputs

Technique 01

Use Structural Delimiters to Isolate Inputs

Raw text prompts often suffer from instruction leakage, where the model confuses your instructions with user-supplied data. Wrapping distinct sections in Markdown blocks or XML tags (<context>, <instructions>, <payload>) forces clear semantic boundaries.

❌ Unstructured Stream

Summarize this customer review and tell me if they are mad: The delivery was late and the box was completely smashed open.

✓ Delimited Payload

<task>Extract sentiment and core issue.</task>
<review>
Delivery was late and box was smashed.
</review>
<format>JSON: {sentiment, issue}</format>

Technique 02

Few-Shot Demonstrations Over Paragraphs of Rules

Describing what you want in natural language leaves room for stylistic divergence. Providing 2 to 3 direct input/output pairs (In-Context Learning) conditions the model's token probabilities far more effectively than three paragraphs of descriptive adjectives.

❌ Descriptive Prompting

Extract all tech stacks from this bio. Make it concise and only return the names separated by commas with no extra conversational filler.

✓ Few-Shot Grounding

Input: "Dev building in Go and Redis."
Output: Go, Redis

Input: "Full-stack Python/Django engineer."
Output: Python, Django

Input: [TARGET_TEXT]
Output:

Technique 03

Force Step-by-Step Scratchpads (Chain of Thought)

Transformers calculate output tokens sequentially. If you force an LLM to state its final answer immediately on a complex reasoning problem, it has zero computation tokens to work through dependencies. Directing the model to evaluate constraints in a scratchpad block before generating the final verdict drastically reduces logical errors.

❌ Immediate Verdict

Is this regex safe against catastrophic backtracking? Answer yes or no.

✓ Scratchpad Reasoning

Analyze the regex: ^(a+)+$
1. Identify nested quantifiers in <scratchpad>.
2. Calculate worst-case complexity.
3. Output final verdict in <verdict>.

Technique 04

Strict Schema Enforcement

Unless you are writing creative prose, avoid open-ended responses. Mandating a strict schema (JSON, YAML, or strict Markdown tables) forces the output into a predictable interface that can be parsed directly by downstream automation code without breaking.

❌ Loose Format

Give me the server specs and costs for three VPS providers.

✓ Schema-Bound

Return a valid JSON array of objects with keys: "provider", "vCPU", "ram_gb", "monthly_usd". Output raw JSON only. No markdown fences.

A Production-Grade Prompt Blueprint

Here is a battle-tested structural framework designed for reliable execution across real-world API workflows and complex tasks:

[SYSTEM / ROLE]
You are a backend security auditor evaluating code against OWASP Top 10 vulnerabilities.

[CONTEXT & CONSTRAINTS]
- Target environment: Node.js / Express with PostgreSQL.
- Do not invent hypothetical flaws; evaluate only the code provided.
- Assume parameterized inputs unless proven otherwise.

[INPUT PAYLOAD]
<source_code>
{{INPUT_CODE}}
</source_code>

[OUTPUT SCHEMA]
Return a Markdown table with columns: Vulnerability, Severity (Low/Med/High), Line Number, Remediation.

Where Prompting Hits Its Hard Limits

Prompt engineering is not a substitute for architectural engineering. If an LLM doesn't have access to proprietary data, no prompt will prevent hallucinations—you need Retrieval-Augmented Generation (RAG). If a model struggles with arithmetic, you shouldn't prompt it harder—you should connect it to an external tool or calculator via Function Calling.

Treat prompt engineering as interface design between fuzzy human natural language and deterministic code: define boundaries, enforce schemas, and never trust unverified output in production.

Key Takeaways

• Prompting is constraint design: eliminate ambiguous branching paths to minimize model hallucination.
• Use XML tags or Markdown delimiters to strictly separate instructions from user input.
• Few-shot input/output examples yield higher accuracy than long paragraphs of descriptive rules.
• Chain-of-thought scratchpads give models the computational tokens required to reason before deciding.
• When prompting hits factual boundaries, rely on RAG and Function Calling instead of more prompt words.