Write SQL with AI against a schema it has never seen
How much schema to supply, and the checks that stop a plausible query returning wrong numbers.
Before you start
- Read access to a database
- Enough SQL to read a query
What you will be able to do
- Supply the schema context that actually changes output quality
- Catch the wrong-join and missing-filter failures before acting
- Validate a result against something you already know
The failure here is specific and dangerous: not an error, but a query that executes cleanly and answers a slightly different question than the one you asked.
Wrong joins and unstated filters do not announce themselves. They just produce a number that looks fine in a report.
Paste the real DDL, not a description
Column names, types, keys and a few sample rows.
Give it the actual CREATE TABLE statements for the relevant tables, plus three or four sample rows.
Sample rows carry information the schema does not: that status is stored as an integer, that dates are strings in one table, that a nullable column is null 90% of the time. Each of those changes the correct query.
Say the things the schema cannot
Soft deletes, test rows, and which of the four date columns you mean.
Every real database has conventions that no amount of DDL reveals: deleted_at must be null, internal accounts are excluded, "active" means one of three status values, and the date you care about is completed_at rather than created_at.
These are exactly the omissions that produce a confidently wrong number, because the query is correct for the question the model thought you asked.
- Forgetting the soft-delete filter. The query works, the number is inflated, and nothing looks broken.
Read the joins and the WHERE clause first
This is where wrong answers live. The SELECT rarely matters.
Check each join: is it on the right keys, and should it be a LEFT rather than an INNER? An inner join silently drops rows with no match, which is the classic cause of a total that is close to right and quietly low.
Then read every condition in the WHERE clause and confirm you meant it. Also watch for fan-out — a join to a one-to-many table duplicates rows and inflates any SUM, without a warning.
Validate against a number you already know
Run it for a period whose answer you can confirm elsewhere.
Before trusting a new query, run it over a window you have an independent figure for — last month's reported total, a count from another system.
If it matches, the joins and filters are probably right. If it is close but not equal, that gap is a real bug and is more informative than a wildly wrong answer, which you would have caught anyway.
- Run against a replica or with a LIMIT first. A generated query on a large table can be accidentally very expensive.
Give it the real schema, read the joins and the filters, and check the row count against something you already know. Every query, until it stops surprising you.
Common questions
Was this guide useful?
95% of readers found this useful
Read next
Build a RAG pipeline over your own documents
The demo takes an afternoon. Making retrieval return the right passage on the questions people actually ask is the entire project.
Analyse a spreadsheet with AI and check its work
AI data analysis is genuinely useful and silently wrong often enough that an unchecked number should never reach a decision.
Write tests first and let AI fill in the implementation
The hardest part of using AI for code is knowing whether the result is right. A test written before the code answers that question…
Build your first agent that does one thing reliably
Agent demos look magical and agent deployments mostly fail on the same three things: unbounded loops, unverified tool output, and…
