When I ask the assistant to write SQL, I first give it not the whole task but a small slice of data: the table schema and a few rows, including edge cases.
Then I ask it to do two things: manually show the expected result on these rows, and only then write the query.
Here is the schema and 8 rows of data. First compute the result manually as a table. Then write the SELECT. Explain which rows might be duplicated by the JOIN.
This catches a typical AI mistake: the query looks convincing but changes the meaning of the data. For example, one order gets multiplied when joined with the line items table — and suddenly you’re counting revenue twice.
A small dataset works like a test example in math: you can check the answer by eye. If the SQL doesn’t match the manual calculation, we discuss the logic instead of trying to guess where the error is in a long query.
For a simple filter on one table the technique is overkill. But for aggregations, dates, statuses and multiple JOINs it saves far more time than it takes.