Skip to main content
Concept #124

Prompt Engineering Basics

The concrete techniques that actually change output quality โ€” and the ones that don't.

Educational content for accountants learning AI โ€” not technology advice or a substitute for professional judgment. Always verify AI outputs against primary sources before relying on them in client or firm work.

Why This Matters

Two people ask the exact same AI tool to review a client's trial balance for anomalies. One gets a generic, hedge-everything response that misses the actual problem. The other gets a focused, useful answer that flags the exact account that needs attention. Same model. Same data. The only difference was the prompt.

This lesson is deliberately different from a lot of what's published on this topic. It is not going to tell you to "just be clear and specific" and call it a day โ€” that advice is true but useless without concrete mechanics. Instead, this lesson covers exactly what changes model behavior, why it changes it, and โ€” just as important โ€” which popular "tips" are outdated or don't hold up. If a technique doesn't have a specific, testable reason behind it, it isn't in here.

By the end of this lesson, you'll know five techniques that measurably change output โ€” and which 2023-era tips to stop using.

The One Idea Everything Else Builds On

THE MODEL HAS NO ACCESS TO YOUR INTENT โ€” ONLY YOUR WORDS

Every limitation covered in the previous lesson comes back to one root fact: the model predicts the next token based on statistical patterns in text. It cannot read your mind, infer unstated context, or know what "good" means for your specific situation unless you tell it.

Prompt engineering is not about tricking the model or finding magic phrases. It is about reducing the gap between what you actually want and what you've put into words โ€” because that gap is exactly where bad, generic, or wrong output comes from.

Technique 1: Role and Task Framing

Telling the model who it should act as and what specific job it's doing narrows the range of statistically likely responses toward the ones relevant to that role.

Without Role Framing

"Review this expense report."

Generic, could go any direction, may miss what actually matters for your purpose.

With Role Framing

"You are reviewing this expense report as a controller checking for policy violations before approval. Flag any line item that lacks a receipt, exceeds $75 for meals without a business purpose noted, or falls outside pre-approved categories."

Gives the model a specific lens to filter through, which measurably changes what gets surfaced in the output.

Best practice: Keep the role concise and directly tied to the task. State it at the start of the prompt. Overly elaborate backstories ("You are a 20-year veteran CPA who grew up in...") add length without adding useful signal โ€” they're noise, not instruction.

Technique 2: Few-Shot Examples (The Highest-ROI Technique)

Rather than only describing what you want, showing the model 2โ€“5 concrete examples of the exact input-output pattern you're looking for is consistently one of the most effective techniques available.

Zero-Shot (no examples)

"Categorize this transaction: 'AMZN MKTPLACE $340.12'"

Model has to guess the categorization scheme you use.

Few-Shot (examples provided first)

"Categorize these transactions using our chart of accounts:

Transaction: 'STARBUCKS #4471 $12.50'
Category: Meals & Entertainment

Transaction: 'UBER TRIP $34.20'
Category: Travel

Transaction: 'STAPLES OFFICE SUPPLY $87.65'
Category: Office Supplies

Transaction: 'AMZN MKTPLACE $340.12'
Category: ?"

The examples establish the exact format, category naming convention, and level of specificity โ€” without a single sentence of abstract instruction.

Why this works better than you'd expect

Research on few-shot prompting found that the diversity and format consistency of your examples matters more than whether every individual example label is perfectly correct โ€” even prompts with some randomly mislabeled examples still substantially outperform giving no examples at all.

Don't agonize over finding perfect examples. Prioritize covering the range of formats and edge cases you actually expect to see.

Best practice: 3โ€“5 examples, consistent formatting, covering the range of cases you expect โ€” not just the easy ones.

Technique 3: Chain-of-Thought Prompting

For tasks involving multi-step reasoning or calculation, explicitly instructing the model to work through its reasoning step by step โ€” rather than jumping straight to a final answer โ€” measurably improves accuracy on hard problems.

Without Chain-of-Thought

"A client's current ratio is 1.8 and quick ratio is 0.6. Is there a liquidity concern?"

May jump directly to a surface-level answer without examining the actual gap between the two ratios.

With Chain-of-Thought

"A client's current ratio is 1.8 and quick ratio is 0.6. Walk through your reasoning step by step: (1) what does each ratio measure, (2) what does the gap between them suggest, (3) what's the most likely explanation, (4) what follow-up question would confirm it."

Forcing intermediate reasoning steps produces measurably better results on logic, arithmetic, or multi-part analysis โ€” one benchmark found a 19-point accuracy improvement on a challenging reasoning test.

Important 2026 caveat โ€” don't apply this blindly

Newer "reasoning" models (like OpenAI's o-series, Claude's Extended Thinking mode, and Gemini's Thinking Mode) already perform this step-by-step reasoning internally, automatically, before answering. Explicitly adding "think step by step" to a prompt for one of these models is redundant at best, and some AI providers' own documentation warns it can actually hurt performance in certain cases.

Practical rule: Use explicit chain-of-thought instructions for standard/fast models on genuinely hard reasoning tasks. Skip it for models explicitly marketed as "reasoning" or "thinking" models โ€” they're already doing it.

Technique 4: Structure and Placement โ€” Where Information Goes Matters

This is the technique most people never learn, and it has real experimental backing: it's not just what you put in a prompt, but where.

THE "LOST IN THE MIDDLE" PROBLEM

Research (Liu et al., 2024) tested how accurately models retrieve and use information depending on WHERE in the prompt it appears. The result was a consistent U-shaped curve across every model tested: accuracy is highest when critical information appears at the very beginning or the very end of the prompt โ€” and drops by over 30% when the same information is buried in the middle.

Practical rule: Put your most important instruction or question either FIRST or LAST. Never bury the one thing you actually need answered in the middle of a long block of background context.

Weak Structure

"Here is our complete general ledger for Q3 [long data dump]. Also here's some background on our chart of accounts [more text]. By the way, please identify any unusual entries above $5,000. Here's additional context about our vendor list [more text]."

The actual task is buried in the middle, surrounded by context that competes for the model's attention.

Strong Structure

Identify any unusual entries above $5,000 in the general ledger data below. [General ledger data] Flag anything unusual above $5,000 and explain why.

The critical instruction appears at the beginning AND is restated at the end โ€” bracketing the data instead of burying the ask inside it.

Length matters too: Research found LLM reasoning performance measurably starts degrading around 3,000 tokens of prompt length, well below most models' technical maximum context window. The practical sweet spot for most everyday tasks is roughly 150โ€“300 words of actual instruction โ€” forcing genuine specificity rather than exhaustive, unfocused detail.

Technique 5: Constraints and Output Format

Telling the model exactly what form you want the answer in โ€” not just what content โ€” removes an entire category of unusable responses.

Without Format Constraints

"Summarize this contract's payment terms."

Could return a paragraph, a list, or a rambling explanation depending on how the model interprets the task that particular time.

With Format Constraints

"Summarize this contract's payment terms in exactly 3 bullet points, each under 20 words, covering: (1) payment due date, (2) late payment penalty, (3) accepted payment methods. If any of these three items isn't specified in the contract, say 'Not specified' for that item."

Constrains the format and pre-empts hallucination โ€” asking the model to say when something isn't there, rather than inventing an answer to fill the gap.

Best practice: Specify format, length, and what to do when information is missing or uncertain โ€” all three, every time for anything going into a work product.

Before / After Prompt Lab

Toggle between weak and strong versions of the same accounting ask. Notice how role, format, and placement change what the model is likely to surface.

Weak

Review this expense report.

Strong

You are reviewing this expense report as a controller checking for policy violations before approval. Flag any line item that lacks a receipt, exceeds $75 for meals without a business purpose noted, or falls outside pre-approved categories.

What Doesn't Work Anymore (Or Never Did)

Prompt engineering advice from 2023 has aged unevenly. Some once-common tips are now outdated, and some were never well-supported to begin with. Calling these out matters as much as the techniques that work.

โœ—

All-caps and excessive urgency language

Writing "IMPORTANT!!!" or "YOU MUST" repeatedly does not reliably improve compliance in current-generation models the way some early guides claimed. It adds length without adding the specific information the model actually needs.

โœ—

Elaborate fake personas

"You are the world's greatest expert with 50 years of experience..." โ€” flattering the model does not make its underlying knowledge more accurate. What actually helps is a concise, task-relevant role, not a dramatic one.

โœ—

"Think step by step" on every single prompt

This genuinely helps standard models on hard reasoning tasks โ€” but is redundant or counterproductive on dedicated reasoning models, and adds no value on genuinely simple factual questions.

โœ—

Maximally long, exhaustive prompts

The instinct to cover every possible edge case in one giant upfront prompt tends to produce worse results than starting simple and adding only what's actually needed based on what went wrong. Performance measurably degrades well before most context window limits are reached.

โœ—

Treating all models identically

Different model families respond differently to structure โ€” some prefer clearly delimited sections, others perform better with plain conversational instructions. A prompt tuned for one tool won't necessarily transfer perfectly to another without adjustment.

The Practical Workflow: Start Simple, Fix What's Actually Wrong

The single most useful habit in prompt engineering isn't a technique โ€” it's a process, and it directly contradicts the instinct to write an exhaustive prompt on the first attempt.

THE ITERATIVE WORKFLOW

STEP 1

Write the shortest prompt that describes your actual intent. No hedging, no exhaustive edge-case coverage โ€” just the core task.

STEP 2

Run it. Read the output critically.

STEP 3

Identify SPECIFICALLY what's wrong or missing โ€” not "it's not good enough," but "it didn't specify which account the anomaly is in" or "it used a format I can't paste directly into the memo."

STEP 4

Add ONLY the instruction that fixes that specific gap. Not a wholesale rewrite โ€” one targeted addition.

STEP 5

Repeat until the output reliably does what you need.

A prompt built this way is lean, and every instruction in it is there because it fixed a real, observed problem. A 500-word prompt written all at once is much harder to debug later โ€” when output quality drops, you can't easily tell which of twenty instructions is actually responsible.

A Complete Worked Example: Building a Real Accounting Prompt

Let's apply every technique above to one realistic task, iteration by iteration. Notice what didn't change: no all-caps, no fake persona, no unnecessary length. Every addition fixed one specific, observed problem.

Iterative Prompt Builder

Task: draft client-facing language explaining a change in estimated useful life for depreciation. Step through the iterations โ€” each one adds only what fixed a real, observed problem.

Iteration 1: Bare minimum

Explain why we changed the useful life on equipment from 7 years to 5 years.
Problem observed: Output was accurate but written like an internal technical memo โ€” too dense and jargon-heavy for a client email.

Step 1 of 3

Key Takeaway

Prompt engineering works by closing the gap between what you actually want and what you've put into words โ€” not by finding magic phrases. Role and task framing narrows the model's response toward what's relevant; few-shot examples establish exact format and categorization patterns more reliably than abstract description; chain-of-thought instructions measurably improve accuracy on hard reasoning tasks for standard models (but are often redundant for dedicated reasoning models); information placed at the very beginning or end of a prompt is retrieved far more accurately than information buried in the middle; and explicit format constraints eliminate an entire category of unusable output. Equally important: some once-popular advice โ€” all-caps urgency, elaborate personas, maximal exhaustive prompts, "think step by step" on everything โ€” has aged poorly or was never well-supported. The most reliable process is iterative: write the shortest prompt that captures your intent, identify specifically what's wrong, and add only what fixes that gap.

Test Your Understanding

Lost-in-the-middle placement, reasoning-model caveats, and the iterative workflow โ€” check your answers below.

Question 1: Research on prompt structure found that model accuracy follows a "U-shaped curve" based on where critical information is placed. What does this mean in practice?

Question 2: A firm is using a dedicated "reasoning" model (one explicitly marketed as performing internal step-by-step thinking) for a complex tax scenario. Should they add "think step by step" to their prompt?

Question 3: According to the recommended iterative prompting workflow, what should happen after running a first, simple version of a prompt and finding the output unsatisfactory?

Ready to Practice?

Apply accounting fundamentals in the Practice Lab while you build the AI fluency this course develops โ€” judgment first, tools second.

Try the Practice Lab

What's Next?

Agentic AI and AI Agents โ€” Now that you can write clearer prompts, the next lesson covers systems that don't just answer โ€” they plan, use tools, and complete multi-step work with far less hand-holding.

Related Concepts

Up Next

Agentic AI and AI Agents