SQL + AI — Your New Data Co-Pilot

By now you've written queries, filtered rows, grouped them, and joined tables. You can read a query and trust the result. That puts you in a rare and valuable position — because here's the reality of 2026: AI can write SQL, and it's getting scary good at it.

This post is about how to use that power without getting burned. It's the difference between AI as a co-pilot and AI as an autopilot you should never, ever trust with your numbers.

AI can turn English into SQL — and it's genuinely impressive

Let's be honest about what ChatGPT, Claude, and the other assistants can do. You type a plain-English question, and they hand back a working query. Watch:

You: "We have a customers table and an orders table. Show me each customer's name and their total order value, but only for customers who've spent over 15,000, sorted highest first."

In a couple of seconds, you get back:

SELECT customers.name, SUM(orders.amount) AS total_spent
FROM customers
INNER JOIN orders ON customers.customer_id = orders.customer_id
GROUP BY customers.name
HAVING SUM(orders.amount) > 15000
ORDER BY total_spent DESC;

That's correct. It's the exact query from our joins post. And here's the thing — if you've followed this series, you can now read every single line of it. Six posts ago that block would have been gibberish. Now you can verify it in ten seconds.

That's the entire point of this post: the value of your SQL knowledge in the AI era is not writing every query by hand. It's being able to read what the AI wrote and know whether to trust it.

When AI gets it wrong

Here's where it gets dangerous. AI doesn't fail loudly — it fails confidently. It will give you a wrong query with the same certainty as a right one. Let's look at a real class of mistakes.

Suppose you ask:

"Show me all customers and how many orders they've placed."

A naive AI answer might be:

SELECT customers.name, COUNT(*) AS order_count
FROM customers
INNER JOIN orders ON customers.customer_id = orders.customer_id
GROUP BY customers.name;

Looks reasonable, right? But remember Umoja Gifts — the customer with zero orders. The INNER JOIN silently drops them. So your "all customers" report is missing a customer, and you'd never know unless you could read the join and ask, wait, where's Umoja?

The correct query uses LEFT JOIN:

SELECT customers.name, COUNT(orders.order_id) AS order_count
FROM customers
LEFT JOIN orders ON customers.customer_id = orders.customer_id
GROUP BY customers.name;

Two subtle differences — LEFT JOIN instead of INNER JOIN, and COUNT(orders.order_id) instead of COUNT(*) so empty matches count as zero, not one. Both are exactly the kind of thing you only catch if you understand joins and aggregates. The AI will not flag this for you.

Other classic AI failures:

• Wrong date range — it grabs last 7 days when you meant last 30.
• Case sensitivity — it matches 'nairobi' when your data says 'Nairobi'.
• Double-counting — a join that produces duplicate rows, inflating every sum.
• Wrong granularity — totals by month when you needed by day.

None of these look "wrong." They look like perfectly good numbers. The only defense is a human who can read the query.

How to prompt AI for SQL

Since you are going to use AI (you'd be silly not to), here's how to get good results:

1. Describe your tables precisely. AI works far better when it knows the columns. Paste the schema or describe it:

"The orders table has columns: order_id, customer_id, amount, status, order_date. The customers table has customer_id, name, city."

2. State the exact columns you want back. "Show me customer name and total spend" beats "tell me about customers and orders." Be specific about the output.

3. Ask for the plain-English translation alongside. A great habit:

"Give me the SQL, then explain in plain English what each clause does."

This forces the AI to reason through the query, and gives you a second artifact to check against your own understanding.

4. Ask it to flag assumptions. "If you're making any assumptions, list them first." This surfaces the guesses it would otherwise bury.

5. Verify against a known answer. Before trusting the query on real data, run it on a small sample where you can eyeball the answer. If you can't predict roughly what the result should be, you can't tell when it's wrong.

One more thing, and it matters: be careful what you paste into AI. Public assistants can use what you type to improve their models, so don't drop real customer names, phone numbers, or financial figures into a public chat tool. Describe your tables with made-up column names and sample values, or use a private tool your company has approved. You can learn everything from fake data — the skill transfers, the risk doesn't.

The verification loop

Here's the workflow that makes AI + SQL genuinely safe:

1. Ask your question in plain English.
2. Read the SQL the AI returns — line by line, using what you've learned in this series.
3. Spot-check the logic: is the join the right type? Is the filter on the right column? Is the date range correct?
4. Run it on a small, predictable slice of data.
5. Sanity-check the result against your intuition. If it says your average order is 1.2 million shillings, something's wrong.

That last step is the one nobody skips twice. A number that violates common sense is a number that's wrong, no matter how confidently it was produced.

Why your SQL knowledge is the moat

There's a common worry that learning SQL is pointless because AI will just do it for you. That gets it exactly backwards.

Think of it like a calculator. When calculators arrived, we didn't stop teaching arithmetic — we stopped drilling long division by hand and instead taught number sense, so kids could look at a calculator's answer and know if they'd fat-fingered a digit. The calculator made mental math more about judgment, not less.

SQL + AI is the same. The AI handles the typing; you handle the judgment. The person who can read the query and catch the INNER JOIN that should be a LEFT JOIN is worth ten people who can only paste prompts and hope. Your SQL knowledge is the verification layer — and in a world where AI produces plausible numbers at scale, the verifier is the most valuable person in the room.

A note from experience

Here's the honest summary: we use AI to draft SQL at River constantly. It saves real time. But every single query gets a human once-over before it touches a decision, because we've all seen AI produce a beautiful, wrong number. The skill you've built in this series — reading SELECT, WHERE, GROUP BY, and JOIN like a sentence — is what lets you be that human.

Try it yourself

Open your AI assistant of choice and try the loop:

1. Describe the employees table from this series (name, department, salary, city).
2. Ask: "Show me the average salary per department, but only departments with more than one employee, sorted highest average first."
3. Read the SQL it returns and check each clause against what you'd write yourself.
4. Ask it: "What assumptions did you make?"

If you can read its answer and point at exactly what it got right — and what you'd do differently — you're officially no longer a beginner. Which brings us to the final post: where to go from here.