What you can and cannot delegate

A wrong number that looks right

You know from the last lesson what a query is: a question written in SQL, sent to a database, answered with rows. Now the distinction the whole course turns on - the two ways a query can fail.

A syntax error - a typo, a misspelled column, a missing comma - costs you a minute. The database refuses to run the query and tells you where the problem is. A query that runs, returns a number, and is quietly wrong can cost a quarter.

Data teams increasingly separate two kinds of mistake. A loud failure is a query that errors: it stops, it complains, and you fix it before anyone sees a number. A silent failure is a query that succeeds and returns the wrong answer. Nothing warns you. The number lands in a report, someone acts on it, and the mistake surfaces weeks later.

Loud failures are cheap because the tool finds them for you. Silent failures are expensive because only a person who can read the query will catch them. Becoming that person is the point of this course.

The same distinction, worked through an example from this dataset, ships in the project repository at docs/failure-modes.md - you will have that file on your machine after the next lesson's setup. The repository and this course teach the same material.

What agents are good at, and where they fail

An AI agent writes correct SQL syntax faster than you can. On textbook schemas - a schema is the full layout of a database: which tables exist and what columns each one has - current models answer plain-English questions correctly more than 90 percent of the time. That number is real, and it is why learning to delegate SQL is worth your time.

On real company schemas, with hundreds of tables and columns whose names mislead, the same frontier models drop to roughly 20 percent. The gap is not syntax. The models still produce valid SQL. They fail because they do not know what the data means: which column holds the number you want, which rows to leave out, and which join quietly doubles a total.

An agent cannot know that net_price is the revenue column and unit_price is not, unless something tells it. It cannot know that an order may have a missing status, or that two tables join one row to many. Those facts live in your head, in the data, and in the files you hand the agent.

What this course asks of you

Section 2 has you write SQL by hand, before you delegate anything. Not because typing SQL is the job, but because you cannot audit what you cannot read.

After that you bring in an agent and learn the loop that makes it safe: ask, read the SQL, interrogate it, verify the answer a second way, then accept or reject. By the end you will trust a number because you checked it, not because it looked plausible.

Checkpoint

You should be able to answer these in your own words:

• What is the difference between a loud failure and a silent failure?
• Why does a query that runs successfully still need review?
• Name one thing an agent cannot know about your data unless you tell it.