Check AI-Generated SQL Before It Touches Real Data

An assistant can write a query that runs and still be wrong: the wrong join, the wrong grain, or a scan you did not mean to pay for.

Treat the SQL as a draft from a fast new teammate who has not seen your schemas before. The steps below take a few minutes and will catch the usual expensive mistakes.

1. State the question and the grain

Before you paste a prompt, write one sentence: what you want back, at what grain, and for which period or filter. "Active users" is not enough. "Weekly unique logged-in accounts in 2026, excluding internal staff, one row per week" is.

Give the assistant the relevant table and column names if you have them. If you only describe the business terms, it will invent a plausible schema, or join the wrong fact table, and the query may still run.

2. Read the SQL, don't just run it

Look at four things:

• Joins. Are they on the keys you expect? An easy join on user_id can duplicate rows if one side is not unique.

• Grain. Does the GROUP BY match the question? A query that groups by day when you needed by week will look tidy and still be the wrong number.

• Filters. Are deleted rows, test accounts, or cancelled orders excluded the way your team usually excludes them? Watch for a missing filter as much as an extra one.

• Measures. Is this a COUNT, a COUNT(DISTINCT …), a sum of a column that can be null, or a ratio that can divide by zero? Small differences here change the result a lot.

If you cannot explain each clause, do not run it on production data.

3. Try it on a safe copy first

Run the draft against a development database, a snapshot, or a limited sample. Check three things: the row count is in a believable range, a few rows look right when you spot-check them against a known example, and the query does not take an unreasonable time.

If you must run it near production, add an explicit LIMIT while you look, and avoid UPDATE or DELETE until a SELECT of the same predicate looks right. Do not let a tool auto-run a write.

A five-check pass

• The question and grain are written down, and the SQL matches them.

• Joins, filters and measures make sense in your schema, not only in the abstract.

• You have run it on a safe copy, or on a limited read, and spot-checked rows.

• The cost or runtime is acceptable for where you will use it.

• A person who owns the data could explain the query without the chat history.

When you are choosing a helper, compare tools on whether they show the SQL clearly and let you edit it before it runs. The SQL assistant category on Toolbit collects the main options, and this overview of AI SQL tools is a useful starting point. In every case, read the query.

Takeaway

Treat AI-generated SQL as a draft. Read it, test it on a safe copy, then run it. A query that returns a number is not the same as a query that returns the right number.