Why Reading SQL Matters
You finished Chapter 21. The Budget Tracker is live on Neon. Alice and Bob exist. Categories exist. The agent is happy to write any query you describe in English. The schema is doing its job and rejecting bad writes at the boundary.
Then the boss sends you a Slack message at 9:42 on a Friday morning.
"Send me total Food spend per user for Q1. Need it for the board call at 11."
You forward the request to your agent. The agent writes a query, runs it, hands back four rows. You paste them into a doc, send the doc to the boss, and grab a coffee. At 10:55 the boss calls. The numbers do not match what finance pulled from the ledger. The board call is in five minutes. You have no idea why your numbers were wrong.
The agent re-runs the query. Same numbers. The agent rewrites the query. New numbers. The agent rewrites it again. A third set of numbers.
Which set is correct? You cannot answer that question by asking the agent. The agent has already shown you three different versions of the truth. The only way to know is to read the query yourself.
The Independent Path
In Chapter 21 you learned about verification. You ran a failure test. You read the row back in a separate query. You checked rollback. Those were all independent paths: each one used a different mechanism to confirm what the previous step claimed.
When the agent writes SQL and then runs SQL, it is one path, not two.
If the same agent writes the query, runs the query, and explains the query, that is not three checks. That is one check repeated three times in the same voice.
To verify a query, you need an evaluator the agent does not control. The cheapest one available to you is your own eyes plus a small set of patterns. The query is short. The keywords are limited. Reading it takes less time than reading a tweet.
Why SQL Earns the Effort
Two facts make this a good investment.
The first is that Postgres has won. CRMs, ledgers, ticketing systems, vector stores, internal tools, Workers running against shared state. The data your business depends on is in tables. Every report eventually comes from rows. The query that produces the report is the seam where the agent's claim becomes the company's answer.
The second is that SQL is declarative. You describe what you want. You do not describe how to compute it. That makes it readable in a way most programming languages are not. There is no control flow to trace. There is no recursion. The query is almost always a single sentence with a small number of clauses, each with one job.
| Clause | Job |
|---|---|
SELECT | What columns to return |
FROM | Which table to read from |
JOIN | What other table to attach, and how |
WHERE | Which rows to keep |
GROUP BY | How to bucket the kept rows |
HAVING | Which buckets to keep |
ORDER BY | What order to return them in |
LIMIT | How many rows to return |
That is most of the grammar you will ever need to read.
The Four Silent Failures
Wrong queries do not crash. They return numbers. The numbers look reasonable. They get pasted into decks.
The four most common reasons a wrong query looks right:
| Silent failure | What happens |
|---|---|
| Wrong WHERE | The filter is close but not right. The number is in the right ballpark, so nobody notices. |
| Wrong JOIN type | INNER JOIN drops rows that have no match. LEFT JOIN keeps them. Picking the wrong one changes the count. |
| NULL behaviour | Comparing against NULL with = returns no rows. The filter looks correct, but nothing matches. |
| Missing tenant filter | A query that should be scoped to one customer or one user runs across everyone's data. |
You can catch every one of these without writing any SQL. You read the query. You ask: which table, which filter, which join, which scope. If any of those four answers is missing or wrong, you reject the query and tell the agent why.
The Reading Posture
For the rest of this chapter, every agent-produced query goes through the same five questions before you let the number leave the room.
- Which table is this reading from? (
FROMclause) - What rows is it keeping? (
WHEREclause) - What other tables does it attach, and what happens if there is no match? (
JOINclause) - What scope is it limited to? (tenant, user, date range)
- What does the output mean in business terms?
Five questions. Roughly thirty seconds. Faster than rereading the email the boss sent.
A Worked Read
The agent gives you this query:
SELECT u.name, SUM(e.amount) AS total
FROM users u
INNER JOIN expenses e ON e.user_id = u.id
WHERE e.category = 'Food'
GROUP BY u.name;
Walk through the five questions in plain English.
- Table: Reading from
usersjoined toexpenses. Two tables on the table. - Filter: Keeping rows where the expense category is exactly the string
'Food'. Notice the single quotes. Notice the exact spelling. - Join:
INNER JOIN. Users who have no expenses at all do not appear in the result. Users who have expenses but none in Food also do not appear. - Scope: No tenant filter, no date filter. This sums every Food expense in the database, for every user, across all time.
- Meaning: Total Food spend per user, for users who have spent at least one dollar on Food, across the entire history of the database.
If the boss asked for "total Food spend per user for Q1," this query is wrong. It has no date filter. The number it produces will be larger than the answer the boss wants, and it will silently include Q4 of last year. You would reject the query and tell the agent: "Add a filter that limits expenses to the first quarter of this year."
You did that in thirty seconds without writing a single line of SQL.
Try With AI
Use these prompts in Claude Code or OpenCode with DeepSeek V4 Flash. The exact runtime does not matter for this lesson.
Prompt 1: Practice the Five Questions
Show me a sample SELECT query against a fake "orders" table that joins
to "customers". Do not explain the query. After you show it, I will
answer five questions about it: which table, what filter, what join,
what scope, what it means. Then you check my answers.
What you're learning: The reading posture. The first time you walk through the five questions, you do it with the agent watching. After that, the questions become a habit and you do them in your head.
Prompt 2: List Silent Failures from a Description
A junior wrote a report for me yesterday. It said "Total revenue for
the EU last month." The query used INNER JOIN on customers, filtered
on country = 'EU', and had no date filter. Without writing the query,
list every silent failure mode you can spot in that description.
What you're learning: You are practicing the pattern recognition before you read any SQL. By the time you see the query, you should already have a hypothesis about what could be wrong. That hypothesis is what your eyes are scanning for when the SQL appears.
Prompt 3: Reject and Rewrite
I will paste a SQL query. Do not run it. Tell me which of the four
silent failure modes (wrong WHERE, wrong JOIN type, NULL trap,
missing tenant filter) you think it has, and what one-line change
would fix it. Wait for my paste.
SELECT name FROM users WHERE last_login = NULL;
What you're learning: This query has a NULL trap. = NULL is never true. The fix is IS NULL. You are practicing the rejection-with-reason habit you will use for the rest of the chapter.
Checkpoint
- I can explain in one sentence why the agent that wrote a query is not the verification step.
- I can name at least three silent SQL failure modes from memory.
- I can walk through the five reading questions on a query without help.
- I am ready to start reading actual queries in the next lesson.