How We Think About Speed

It starts with a person, not an alert: a page feels slower than it should, or a number moved the wrong way. We write the hunch down as a plain question, like why the admin feels slow, and resist naming a cause before we have measured one.

Before a line of code changes, Claude establishes where the time actually goes. On our own admin that meant pulling live database row counts and indexes: every table was under a thousand rows, so the database was answering in microseconds. The real cost was elsewhere, in redundant round-trips and oversized payloads. Measuring first is what stops you from indexing a table that was never slow.

The review splits into independent lenses: over-fetching, request waterfalls, caching, client bundle weight, database indexes, and repeated queries. Each reviewer sees only its own lens, so nothing hides in the gap between two people's assumptions. Every finding cites the exact file, line, and the offending code.

Every finding is handed to a skeptic whose job is to refute it. Is the code really doing what the finding claims? Does it run on a hot path, or is it cold code that rarely executes? Would the fix change behavior or weaken a guarantee? Only findings that survive earn a fix. Plausible-but-wrong is the most expensive kind of wrong, and this is where it dies.

A person decides which fixes ship now, which wait, and which touch something sensitive enough to need a careful review of its own. On our admin, the change to the authentication path was pulled into its own reviewable unit precisely so a human could weigh the tradeoff before it shipped. AI proposes, a person decides.

Fixes ship as small pull requests grouped by theme, not piled into one. Each is type-checked and built before it can merge, and each is reversible on its own. Small and verified keeps a fast system a working system. Big-bang rewrites are how you trade a slow product for a broken one.

Then we measure again, and the numbers have to move. Round-trips per page, bundle size, time to first byte, before and after, side by side. On this admin the authentication round-trips per request dropped from three to one, the busiest page shed almost a third of its startup code, and the dashboard stopped waiting on an outside service to draw. A change that cannot show its before and after did not improve anything.