AI code runs clean but breaks: 101 DB calls, 7-day tokens

The article's framing is that writing code has taken less time over the past year, while the time spent reading output and deciding whether it is acceptable has not become any easier. The five examples are chosen for a single shared property: none of them raises an exception, fails a test, or surfaces in local development. The code shown uses Promise.all for parallelization, signs a JWT with a seven-day expiry, formats a date with toISOString(), marks a user row with a deletedAt timestamp, and maps over a user array to send welcome emails — each of which looks clean on the page. The author's point is that the missing information lives outside the code: how many rows the array will hold in production, whose timezone the date is for, whether a deleted email address may be re-registered, and how many operations may run at once.

The author is careful to note this is not an AI-only problem, recounting a Stripe sandbox-to-production switch where two users produced 22 customer records, and a follow-up fix that broke payment screens by referencing a customer ID that no longer existed on Stripe's side. The argument is that what has changed is the quantity of code, not the species of bug, and that suspicion — spotting where things are likely to break — is not something tooling speeds up. The five patterns covered in the piece each have a dedicated longer article, with a free format that starts from an incident, works through diagrams, and ends by asking the reader how they would decide.

The stakes here hinge on whether teams adopt the short question list the author proposes — production row counts, immediate lockout paths, timezone boundaries, post-deletion re-registration, and concurrency caps — since those answers come from whoever owns the feature requirements rather than from reading the code. Whether that habit actually spreads is likely to depend on how much review capacity teams are willing to spend, and on whether reviewers already know which spots in their own systems are the risky ones.