Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to walkthrough shows a fluent LEFT JOIN double-counting two orders into 1,830 when the right answer was 1,330. The check that catches it costs two statements.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A row count comparison tells you a join fanned out. It does not tell you what the fan-out cost. Here the join added two rows to eleven, an 18 percent increase in rows [1], and the answer came back 500 too high against a correct 1,330, an overstatement of about 38 percent [8][2]. The gap between those two percentages is the whole problem with treating the count as a severity score. Error is priced by which rows duplicated, not how many. The two orders that each matched two refund rows were worth 250 apiece against an average completed order of about 146, roughly 1.7 times average size [3]. Duplicate one large customer and you outrun fifty duplicated rows from the tail.
The two mistakes worked through in the piece fail at very different volumes. The NOT IN query against a lookup table holding one NULL returned NULL from zero rows [11], which nobody ships: an empty result argues with itself. The fan-out returned 1,830 [8], which survives a read-through, rounds to 1.8k and lands in a slide. That asymmetry is why the source puts a single row count first [4], two COUNT(*) statements returning 11 and 13 [10], ahead of anything that requires reading the SQL closely.
The same dataset produces a quieter trap. The corrected staff-exclusion query returns 1,395 [12], and that query sums amount with no refunds join in it at all [14], so 1,395 is gross minus staff while 1,330 is net of refunds. Gross completed value is 1,605 [7]. Three numbers, all valid SQL, all answerable to the word "revenue", differing by the population counted and by whether refunds come off. The staff accounts alone are 210, about 13 percent of gross completed value [4], a correction large enough to matter and one that hid behind the NULL for as long as an empty result read as "no staff orders here". None of the three is flagged by the engine, because the engine checks spelling of tables and nothing about arithmetic [2].
Fluency is what makes the procedure necessary. The aliases are tidy and the formatting looks like a careful person's work [5], so a reviewer reading for craft finds nothing to object to and stops reading. The counter in the source is not aesthetic judgement but two habits: open the row counts before the query body, and for every column a filter touches, ask what that filter does when the column is NULL [13]. Behind both sits a one-line test that is worth more than the five checks it summarises. The number is right when the rows, the filters and the denominator match the question that was asked [1]. Everything expensive in review is the argument about what the question was.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The page offers five checks that take about two minutes, need no tools beyond the database already in use, and catch the four mistakes AI-written SQL actually makes.
The checks are ordered cheapest first: the first costs a single row count and the last costs a short conversation. Most wrong queries fall to the first two.
A query that runs has only passed a grammar check; the number is right when the rows, the filters and the denominator match the question you asked.
Grammar is the entire list of what the database checks: a misspelled table name errors, but summing the wrong column, joining in a way that doubles rows, or filtering after grouping when the question needed it before all return a clean result set with a wrong number. Every mistake covered in the piece is valid SQL.
AI-written queries are fluent: tidy aliases, clean formatting, the shape of something a careful person wrote. Fluency reads as correctness and is not the same thing; the advice is to treat an AI query as a first draft from a new colleague, with the row counts open.
The demonstration dataset holds thirteen July orders and five customers, with a refunds table in which two orders were each refunded in two parts. Eleven of the thirteen orders are completed, one refunded, one pending. A staff_accounts table lists internal accounts and contains one NULL row.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Reproducible on a synthetic dataset, single-source
The core mechanism is unusually well evidenced for a single article: queries are quoted verbatim, the dataset is fully specified (13 orders, 11 completed, two orders refunded in two parts, one NULL staff row), and every figure reconciles by hand - 1,605 minus 275 equals 1,330, 2,105 minus 1,605 equals the 500 of double-counted value, 11 rows becoming 13. What holds the score down is that this is one publisher, one author-constructed toy dataset, no independent replication, and a supplied body truncated part-way through the final check.
No adoption signal in the sources
The single source is an explanatory walkthrough. It contains no release, deployment, usage disclosure, benchmark or telemetry of any kind - nothing about how widely AI assistants are used to write production SQL, how often they make these errors, or whether any team has adopted this five-check review. Adoption cannot be scored without inventing facts.
Mechanism solid, generalisation overstated
The demonstrated mechanics are not hyped - they are arithmetic. The overstatement sits in the framing around them: 'the four mistakes AI-written SQL actually makes' and 'most wrong queries fall to the first two' are asserted with no error-rate data, no assistant named, and no workload beyond a hand-built thirteen-row table, while the headline 38 percent is an artifact of that specific dataset rather than a general magnitude. The article also presents its staff-exclusion rewrite as the reviewed answer when that query is gross and never subtracts refunds, so the checklist slightly oversells its own rigour.
Low commercial pressure, mild self-referral
Nothing is being sold: no vendor, product, model or sponsor is named, no tooling is recommended beyond the reader's existing database, and no AI assistant is credited or criticised by name. The only visible incentive is authorial audience-building on a developer publishing platform, including internal pointers to the author's companion pieces on NULL in SQL and GROUP BY and HAVING, which nudges toward series continuation rather than toward any particular conclusion about the numbers.
Verifiable mechanics, single voice, no adoption base
Confidence is moderate. The claims that matter are checkable arithmetic on a fully disclosed dataset, and standard SQL semantics support both the fan-out and the NOT IN NULL behaviour, so the mechanism is unlikely to be wrong. But the cluster has one publisher and one source, the body is truncated before the final check completes, and there is zero adoption or frequency evidence, so any statement about how much this matters in practice rests on judgement rather than data.
build
Cost per customer is an allocation policy, not a warehouse project1 distinct publisher
build
The date bug that only misfires when the day is 13 or higher1 distinct publisher
build
The dangerous cell in your state machine is the one nobody filled in1 distinct publisher
build
Scheduling a prompt is not monitoring: keep the LLM upstream of the cron1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026