Prompt Engineering for Data Analysis (2026)

Read this section first, because the order is deliberate:

We open with the non-negotiable: why you verify everything, and what 'verify' actually means for queries versus numbers. Then four task sections — generating SQL against a known schema, explaining and sanity-checking results, specifying charts precisely, and framing testable hypotheses — each paired with its verification step.

After the tasks: notes on the current model landscape and which tier to use, a comparison table of where AI accelerates analysis versus where it endangers it, an FAQ, and a 'Sources & further reading' section.

The single sentence to internalize: an LLM is a fast, fluent analyst who will never tell you when it's guessing. Your job is to make it show its work and then check the work — not to outsource judgment to it.

Before any prompt, the discipline. Large language models produce confident output whether or not it is correct, and in data work the failure modes are specific and dangerous:

**Hallucinated columns and tables.** A model will happily reference an `orders.region` column that doesn't exist in your schema, producing SQL that's syntactically perfect and immediately broken — or worse, that silently joins the wrong thing.

**Plausible-but-wrong aggregations.** It may average a pre-averaged column, double-count through a fan-out join, or apply a filter that quietly changes the denominator. The result looks reasonable, which is exactly why it's dangerous.

**Invented numbers.** If you ask 'what's our churn?' without giving it the data, a model can produce a specific-looking figure with zero basis. Never accept a number you didn't compute from real data.

What 'verify' means in practice: run every generated query against the real database and inspect the row count and a sample; recompute any headline number a second way; and never paste a model's number into a report without tracing it to a query you ran. Treat the model as a draft generator for queries and explanations, and treat your database — not the model — as the source of truth.

The biggest mistake in AI-assisted SQL is asking for a query without giving the model your schema. Without it, the model invents plausible column names — and you get confident, wrong SQL. Always paste the relevant table definitions.

``` You are writing SQL for a [Postgres / BigQuery / etc.] database. Schema (use ONLY these tables and columns): [paste CREATE TABLE statements or column lists for the relevant tables] Task: [describe the question in plain English] Rules: - Use ONLY columns and tables in the schema above. If you need something not present, STOP and tell me what's missing instead of inventing it. - Explain each join and each filter in a one-line comment. - Note any assumption you made (e.g. how you defined 'active user'). - Do not guess at data values. ```

The 'stop and tell me what's missing' instruction converts a silent hallucination into a useful question. The inline comments and stated assumptions are what let you verify the logic, not just the syntax — because the query can run perfectly and still answer the wrong question.

Verification step for SQL: (1) read the comments and confirm the join keys and filters match your intent; (2) run it and check the row count is in a sane range; (3) for any aggregate, spot-check one group by hand. For drafting the prompt scaffold itself, the Code Prompt Builder helps structure the request.

Models are good at translating a result set into plain-English narrative — and at sanity-checking your own work if you ask them to be skeptical. The trick is to give them the actual numbers, not ask them to recall any.

``` Here is a query result (real data I pulled): [paste the actual rows or a representative sample] The query was answering: [the question] Do two things: 1. Summarize what the data shows in plain English, citing only the numbers above. 2. Play skeptic: list any reasons this result might be misleading (selection bias, a join fan-out, a filter that changes the denominator, an outlier driving the average, a time-zone or date-boundary issue). Do not introduce any number that isn't in the data above. ```

The skeptic prompt is where a model genuinely adds value — it surfaces the analytical traps you stopped seeing, the same way a careful colleague would in review. The hard constraint ('do not introduce any number not above') keeps the summary anchored to what you actually pulled.

Verification step: every number in the model's summary should be traceable to a row you pasted. If a figure appears that isn't in your data, discard the summary — it's contaminated.

Models are strong at translating an analytical intent into a precise chart specification — chart type, encodings, axes, aggregation — which you then build in your tool of choice. The key is to ask for a spec, not a vague 'make a chart.'

``` I want to visualize this result: [describe the data shape and what you're trying to show] Recommend a chart specification: - Chart type and WHY it fits this question (not just what's pretty) - X and Y encodings, including aggregation and units - Whether to use color/series, and for what dimension - Sort order and any annotations that aid reading - One alternative chart type and the tradeoff Flag any way this chart could mislead (truncated axis, dual axes, cherry-picked range). ```

Asking 'why it fits' and 'how it could mislead' is what separates a useful spec from a default bar chart. The misleading-chart flag is especially valuable — truncated y-axes and dual axes are the classic ways a technically-correct chart tells a false story.

Once you have the spec, build the chart in your real BI or notebook tool against verified data. The model specified it; the data behind it must be the data you actually queried.

Before you query, models help structure the question — turning a vague 'why did revenue drop?' into specific, testable hypotheses ranked by how cheaply you can check them. This is genuinely useful upstream work where there's no number to get wrong yet.

``` We observed: [the surprising pattern, with the real numbers]. Context: [what changed recently — releases, seasonality, campaigns]. Generate 5-7 testable hypotheses for what's driving this. For each: - State it as something a query could confirm or rule out - Name the specific data/query that would test it - Rate how cheap it is to check (quick query vs. needs new data) Order them by cheapest-to-test first. Don't speculate beyond what a query could verify. ```

This is a low-risk, high-value use because the output is a research plan, not an answer. You still run every query and check every result — the model just made sure you're testing the right things in a sensible order. Chain-of-thought framing helps here; see the chain-of-thought guide for the technique.

As of June 2026, frontier reasoning models are markedly better at multi-step SQL logic than the fast tiers, which matters because data work is where subtle logic errors hide. Do not reach for the cheapest model on a query whose correctness drives a decision. Prices below are per million tokens; verify on the live pages.

For complex queries, multi-table joins, and result reasoning, a strong reasoning model — Claude Opus 4.8 at $5 in / $25 out or Sonnet 4.6 at $3 / $15, GPT-5.5 at $5 / $30, or Gemini 3.1 Pro at $2 / $12 up to 200k context — is worth the cost given the stakes. For simple, well-scoped queries against a small schema, a cheaper tier like GPT-5.4-mini ($0.75 / $4.50) or Gemini 2.5 Flash ($0.30 / $2.50) is fine — as long as you still verify.

Note OpenAI also ships a coding-tuned tier, gpt-5.3-codex at $1.75 / $14, which is well-suited to SQL and data-transformation code. Whatever the tier, the verification discipline does not relax — a more expensive model hallucinates less often, not never. Estimate cost with the AI Prompt Cost Calculator.

The split for data work is sharper than for most domains, because the cost of a confident error is higher.

AI accelerates: drafting SQL against a schema you provide, explaining a result set you pulled, specifying charts, and framing hypotheses. These are draft-and-verify tasks where the model saves real time and you can always check the output against ground truth.

AI endangers: any task where you'd be tempted to trust a number you didn't compute. Asking 'what's our churn rate?' with no data, accepting an aggregate without spot-checking, or letting a model-generated chart ship without verifying its underlying query — these are how a fabricated or subtly-wrong figure ends up in a board deck.

The defining habit of good AI-assisted analysis in 2026: the model writes the query and the narrative; your database produces the truth; and you personally trace every published number back to a query you ran. There is no shortcut around that last step.

- DAIR.ai, Prompt Engineering Guide — https://www.promptingguide.ai/ (accessed June 2026) - OpenAI, Prompt Engineering Guide — https://platform.openai.com/docs/guides/prompt-engineering (accessed June 2026) - Anthropic, Prompt Engineering Overview — https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview (accessed June 2026) - OWASP, LLM Top 10 (2025) — https://genai.owasp.org/llm-top-10/ (accessed June 2026) - Wei et al., 2022, Chain-of-Thought Prompting — https://arxiv.org/abs/2201.11903 - Anthropic API pricing — https://claude.com/pricing and https://platform.claude.com/docs/en/about-claude/pricing (accessed June 2026) - OpenAI API pricing — https://developers.openai.com/api/docs/pricing (accessed June 2026) - Google Gemini API pricing — https://ai.google.dev/gemini-api/docs/pricing (accessed June 2026)