Course overview/Set up the workspace2 of 4
What you can and cannot delegate
What you can and cannot delegate
Tell a loud failure from a silent one, and learn why you audit SQL you did not write.
Loud failures and silent failures
You know from the last lesson what a query is: a question written in SQL, sent to a database, answered with rows. The distinction the whole course turns on is 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. That is a loud failure: it stops, it complains, and you fix it before anyone sees a number. A query that runs, returns a number, and is quietly wrong can cost a quarter. That is a silent failure: it succeeds and returns the wrong answer, and 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.
An 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. On real company schemas, with hundreds of tables and columns whose names mislead, the same frontier models drop to around 20 percent. The gap is not syntax. The models still produce valid SQL. The failure is semantic: which column holds the revenue 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. This is why you audit SQL you did not write, even when it runs.
The same distinction, worked through an example from this dataset, ships in the project at docs/failure-modes.md - you will have that file on your machine after the next lesson's setup. 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.
Check your understanding
- 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.
Do it with your agent
This is a concept lesson - nothing to build yet. Say next lesson and your agent walks you through it and checks you followed with a few questions. Then say next lesson again to move on.