How to Learn SQL in the Age of AI: Review the Query, Not Just the Syntax

Quick answer: learning SQL is still worth it, but memorising syntax is no longer the point. An AI agent can produce a valid select statement in seconds. The useful skill is knowing whether that query answers the question, reviewing its assumptions, and pushing back when the number looks suspicious.

Want to learn this way? Start the free SQL in the Age of AI course at Bruin Academy. Your coding agent acts as the tutor, then reviews the SQL you write and the SQL it writes.

That means SQL education has to change too.

The old pattern was: learn the syntax, write hundreds of queries, and eventually develop an instinct for what looks right. The new pattern is more like this: learn enough SQL to read the work, write enough SQL to understand the mechanics, then spend a lot of time reviewing and questioning what the agent produced.

I think this is a better way to learn. It is also a little less comfortable at first, because the agent is very good at producing a query that looks finished before you have decided what "revenue" or "active customer" actually means.

SQL syntax is becoming a smaller part of the job

SQL syntax is not disappearing. You still need to know what where, join, group by, and a window function do. Otherwise, you cannot tell whether the agent used them correctly.

But syntax memorisation as the primary skill is becoming useless. It is a dying skill because the typing is cheap now. An agent can remember whether a warehouse uses date_trunc('month', order_date) or date_trunc(order_date, month) faster than you can look it up, and it can draft the first version while you are still opening the editor.

The expensive part is not the first draft. It is deciding whether the draft deserves to run.

Consider a simple question: "What was our monthly revenue by country?"

An agent can write a query quickly. It might even run without an error. But before you trust it, you still need to ask:

• Does revenue exclude refunds and test orders?
• Is the query using the settled orders table or an order-events table?
• Can one order have multiple payment rows and inflate the total?
• Which date does the month use: order date, payment date, or shipment date?
• Are the countries coming from the billing address or the shipping address?

None of those questions are syntax questions. They are questions about meaning, grain, ownership, and evidence.

The new SQL skill is review

When an agent writes SQL, start by treating the output like a pull request from a junior teammate. It may be perfectly reasonable. It may also be confidently wrong. Your job is to find out which one.

A proper SQL review usually checks five things:

The first question catches a surprising number of mistakes. If the agent says the result is one row per customer but joins to a table with many events per customer, you already know where to look. If it says one row per month but groups by country as well, the explanation and the SQL disagree.

This is why learning SQL still matters. You do not need to type every query from memory, but you do need to understand what each clause does to the data as it moves through the query.

Learn with an agent, not from a pile of syntax exercises

An interactive agent can do more than answer "what does left join mean?" It can teach the concept, ask you to explain it back, give you a small task, run your query, and review the result.

That is the model behind Bruin Academy's SQL in the Age of AI programme. The programme is free, runs locally, and uses your coding agent as the tutor. You start with Ask the Data, write SQL by hand against a small local dataset, and then bring the agent into the workflow.

The loop is simple:

1. Tell the agent next lesson.
2. Read the explanation and answer its questions.
3. Write the task yourself, before asking for a solution.
4. Say review my work and let the agent run your query against the test data.
5. Ask why it gave the result it did, then decide what to change.

The agent is doing the teaching and the mechanical work. You are building the judgement.

That distinction matters. If the agent writes every query from the beginning, you can get a lot of correct-looking output without learning how to inspect it. If you write every query forever, you are practising a task that automation will keep making cheaper.

The useful middle is to write enough SQL to build a mental model, then use the agent as a tutor and reviewer.

Socratic questioning is the skill agents cannot supply for you

An agent will often explain its query if you ask. That is helpful, but an explanation is not proof. The agent may use the same wrong assumption in the explanation that it used in the SQL.

You need to keep the conversation moving with specific questions. For example:

What is the grain of each CTE? Show me with one sentence per CTE.

Which join can increase the number of rows, and what evidence do we have
that the join key is unique on that side?

What definition of revenue did you use? List the included and excluded
statuses, and tell me which table documents that definition.

Give me a small counterexample that would make this query wrong.

Suggest a separate query or check that could verify the result.

Those are not magic prompts. They are questions you would ask another analyst in a review. The difference is that the agent can answer quickly, run the query, inspect the data, and revise its work while you keep control of the decision.

The best question is often: "What would have to be true for this answer to be correct?" Once the assumptions are visible, you can check them.

A small example of reviewing an agent's SQL

Suppose you ask an agent for customers who placed an order in the last 30 days. It writes:

select
  c.customer_id,
  c.email
from customers c
join orders o on o.customer_id = c.customer_id
where o.order_date >= current_date - interval '30 days'

The query may be correct for a list of recent orders. It is not necessarily correct for a list of customers. A customer with five orders appears five times, and the query does not say whether cancelled orders count.

This is where a review catches more than a syntax error. You might ask the agent to state the grain, then ask it to return one row per customer and explain how it handles duplicates:

select distinct
  c.customer_id,
  c.email
from customers c
join orders o on o.customer_id = c.customer_id
where o.order_date >= current_date - interval '30 days'
  and o.status = 'paid'

Or you might prefer exists, depending on the warehouse and the rest of the model. The important part is not that one version is always right. It is that you can see the decision and question it.

An agent that can explain the difference between "one row per matching order" and "one row per matching customer" is useful. An agent that gives you a polished answer while hiding the difference is a liability.

What to learn first, and what to practise next

If you are starting from zero, learn these concepts in roughly this order:

• selecting columns and filtering rows with select, from, and where
• counting and aggregating with count, sum, avg, and group by
• joining tables while tracking the grain on both sides
• using CTEs to name and inspect stages of a query
• handling nulls, dates, duplicates, and boundary cases
• reading a query from the output backwards to the source rows

Do not rush past joins. A lot of SQL mistakes are really grain mistakes wearing SQL syntax as a disguise.

Once those foundations feel familiar, practise review tasks rather than only writing tasks:

• Find the clause that can double count revenue.
• Explain why a left join became an inner join after a filter was added.
• Identify which date column controls the reporting month.
• Ask the agent for a counterexample and check whether the query handles it.
• Reconcile the result with a second query that uses a different route through the data.

This is closer to the work people do in real data teams. Nobody is rewarded for remembering every function name while a metric quietly counts the same order twice.

The course I wish more people had access to

We recently launched SQL in the Age of AI at Bruin Academy because the normal course format no longer matches how SQL work gets done.

It has three courses. The first teaches the basic mechanics and the review loop. The second focuses on model design, metric definitions, joins, and the patterns agents get wrong. The third moves into pipelines, tests, incremental updates, failures, and operating SQL with an agent.

You do not need a warehouse or a cloud account to start. The beginner course creates a small practice dataset locally, and the agent walks you through the setup. You can read the course pages as a reference, but the agent is the one teaching the lesson, asking the questions, and reviewing your work.

That is the part I care about most. Education becomes much more useful when the feedback arrives next to the work, while you still remember why you wrote the query. You do not have to wait for an instructor to find your mistake three days later, and you do not have to pretend that a green result means the logic is right.

Learn SQL so you can disagree with the agent

The goal is not to beat the agent at typing. It is to know when to accept its answer, when to ask for evidence, and when to stop it before a plausible number becomes a company decision.

Syntax will still help you. It is the vocabulary. But review is the actual conversation, and the conversation is where the value is.

If you want to learn that way, start with Ask the Data and let an agent teach you the first lesson. Then make it defend the query. What would you ask it to prove before you trusted the number?

FAQ

Is learning SQL still worth it when AI can write queries?

Yes, but the goal has changed. You still need enough SQL to understand tables, joins, filters, aggregations, and query results. The more valuable skill is reviewing the SQL an AI agent writes, spotting wrong assumptions, and asking questions that lead to a defensible answer.

Can AI teach me SQL?

Yes. An AI coding agent can act as an interactive SQL tutor by explaining a concept, asking questions, setting a task, running your query, and reviewing it against a rubric. You learn more when you write some SQL yourself and then compare it with the agent's approach.

What is the best way to learn SQL with AI?

Use a two-part loop: write SQL by hand so you can read it, then ask an agent to write a version and review both queries. Question the agent about grain, joins, filters, nulls, date boundaries, and how you can verify the result independently.

What should I learn first in SQL?

Start with select, from, where, group by, aggregates, joins, and common table expressions. Practise each concept against a small dataset, then learn how those choices affect row grain, duplicates, missing records, and the meaning of a metric.

Where can I take an interactive SQL course with an AI tutor?

Bruin Academy's SQL in the Age of AI programme teaches SQL interactively with your own coding agent. The free programme starts with Ask the Data, where you write SQL by hand and then audit the SQL your agent writes for you.