A blog where knowledge grows

One standard for accepting or rejecting AI-written TypeScript: pin down what the types own, drop the over-engineering, and leave compiler evidence behind.

How to review an AI that produces different code every time by layering deterministic instruments — tests, linters, scripts — and splitting the work into small reviewable units through modularity, explained step by step

Why AI-written code goes quietly wrong, and the three pillars that fix it: reproducing correctness as tests, engineering the harness, and adding self-feedback plus an independent reviewer

What I learned deriving a sort-key union from a column array and passing a per-domain row type all the way down into compound component parts — and the variance rabbit hole that kept showing up along the way

Writing the judgment criteria down before handing work to a code generation tool, demoting code, screens, and reviewer opinions to evidence, and stopping when confidence runs out

A note on requesting writes through message-based RPC in separated extension contexts, then using change signals and query invalidation so other screens re-read the single source of truth

Which of the three layers — assertNever, satisfies Record, pattern matching libraries — to reach for and when, and why a catch-all default branch hides what you missed

Patterns where the type promises something the implementation never guarantees: the totality Record implies, type predicates that check nothing, ReturnType on wrappers that run later, and excess property checks mistaken for sanitizers

The order to follow: don't store what you can derive, don't copy a union the library already owns, and turn only what's left into a client-state union — plus why actions don't belong inside state