How I verify

Anyone can ship a feature now. What is harder — and what I think is actually worth showing — is catching the thing that is subtly wrong with code that already compiles, already passes its tests, and already got reviewed.

These are real defects from my own production code. Several are mistakes I made myself and found later. Every one links to the write-up in the repo it came from, so none of it has to be taken on trust.

KhataGO

A test that asserted nothing for months

What it looked like: A green integration test scraping a rendered invoice for its GST figures.
What it actually did: An i18n change split one text node into several, so React inserted HTML comment separators into the markup. The probe matched nothing, and a missing value read as zero — the test read the tax as zero against a stored ₹152.54.
What it taught me: A test that reaches through a framework's rendered output is coupled to that framework's rendering decisions, and it fails silently by matching nothing.

Read the full write-up →

KhataGO

A lock with no way out of it

What it looked like: A correct atomic claim: one conditional UPDATE, two concurrent deliveries, only one winner.
What it actually did: There was no path back out. A process that died mid-run left the record claimed forever, and nothing could distinguish an abandoned claim from one still legitimately running.
What it taught me: Mutual exclusion and liveness are different properties. Passing tests for the first say nothing about the second — a lock without an expiry is a deadlock waiting for a crash.

Read the full write-up →

EduScale

An idempotency guard that was not one

What it looked like: Documented as idempotent, and idempotent in every sequential test.
What it actually did: A read-then-write with no unique constraint behind it. Two concurrent requests both missed the read and both made a paid LLM call. The tell was already in the code — it ordered results by date, which only matters if duplicates can exist.
What it taught me: Code that copes with a condition is evidence someone knew it could happen. Prevent it at the constraint, and let the read be a fast path.

Read the full write-up →

EduScale

A safety guard whose allow-list matched production

What it looked like: A guard I had just written to stop tests touching the production database.
What it actually did: I allow-listed the database name "postgres" because it is the default for a CI container. Production is also named "postgres" — so the check would have waved it straight through.
What it taught me: An allow-list whose most permissive entry matches the thing you are guarding against is not an allow-list. This one is mine, found the same week I wrote it.

Read the full write-up →

KhataGO + EduScale

Migrations that never ran

What it looked like: A build script that generates the database client on every deploy.
What it actually did: Generating the client rebuilds types from the schema; it never touches the database. Deploys shipped code whose types knew about columns that did not exist. One repo had four unapplied migrations in production.
What it taught me: Before making every deploy run migrations I checked what production's migration table actually contained, and found rows with no matching files. Reproducing that drift locally first is the only reason the fix did not break every deploy.

Read the full write-up →

BALLAST

Six bugs, half of them in the checker

What it looked like: A verification harness finding bugs in the system under test.
What it actually did: As many of them were in the harness. One invariant fired on correctly-refused operations because the checker was consuming the system's own account of what it had done — a checker that trusts the thing it is checking is not a checker.
What it taught me: The most useful thing deterministic simulation taught me was to distrust the oracle as much as the implementation.

Read the full write-up →

Written up at length

Three of these have full write-ups, with the diagnosis rather than just the conclusion.

A passing test only proves the test passes
Five cases where a green suite was checking something the running code never did — and the question that finds them.
My mutation score was 100%. That's how I knew something was wrong.
A mutant is killed when the suite fails — so if the suite already fails, every mutant is killed.
Why we didn't use Redis for webhook deduplication
SETNX splits the claim from the truth. A crash between them leaves the event permanently claimed and unretryable.

The thing they have in common

Most of these were invisible to the type system and to the test suite, and several looked more correct in their broken form than the fix does. A lock with no expiry looks simpler than one that handles staleness. A build step that generates a database client looks like it handles the database.

What found them was not a tool. It was asking, of code that was already passing: what would have to be true for this to be wrong, and is anything checking that?