Compound engineering applied to a personal site
Five real pull requests from this site's own git history (a build, a review, a three-line fix, an extraction, and a compliance rule) show what compounding actually looks like when a fix from one PR gets applied automatically three PRs later without anyone repeating the instruction.
Five real pull requests from this site's own history, in the order they landed: a build, a review, a three-line fix, an extraction, and a rule that got reused three PRs later without anyone repeating it.
01 Ship
The first Thinking piece shipped with two fixes already caught before merge, not after. The homepage's bottom link grid repeated three destinations already in the persistent nav; review cut it down to the one link that wasn't already there, the garden. The pointer-driven camera sway was too wide — 3x horizontal, 1.2x vertical — and came down to 1.1x and 0.45x with softer damping, so a mouse move reads as ambient parallax instead of a wide pan. Neither fix took more than a few lines. What mattered is that they landed in the same pull request as the build, not in a bug report filed a week later.
02 Review
The second pull request was a review, not a build. It read the piece that had just shipped and found problems that were about to get copied into the other nineteen: every specimen sat inside a bordered, rounded card, fighting the site's flat, no-chrome rule. The lighting demo used a synthetic torus knot instead of the real generated rock model already sitting on the homepage. There was no spine — no ordering, no closing quote. None of that was a bug in the sense of broken code. It was drift, the kind that costs nothing in one file and a rewrite of twenty.
03 Fix
Two pull requests later, a smaller thing slipped through anyway: a raw hex color and a text-shadow glow in one specimen, both banned by the site's flat rule on their own terms — 1px borders and CSS variables, no glows, no gradients, no hardcoded color. Three lines, caught and reverted before it could set a precedent. This is the actual diff.
<spanstyle={{- color: broken ? '#4a4d52' : 'var(--ink-dim)',- textShadow: broken ? '0 0 24px rgba(255,255,255,0.08)' : 'none',animation: broken ? 'kit-glitch 2.6s ease-in-out infinite' : undefined,}}>
a hex color and a text-shadow glow, swapped for var(--ink-faint) and removed entirely — the exact three-line change from the real commit.
04 Extract
The pattern under the last two fixes was the same one: the two-column magazine grid, the optional stage number, the optional margin note — all of it lived inside a single file, written once for a single piece. Four more pieces were about to need the identical layout. Instead of rewriting it a second time with small drift already baked in, it moved into a shared component that every later piece imports rather than redefines slightly differently. The paragraph you are reading now is laid out by that same import.
05 Compound
Two pull requests after that, a compliance pass found project copy and a code comment naming specific third-party AI products by brand — a hard constraint here, not a style preference, since this site is written by someone who can't publicly endorse a competitor's model while working at Google. The rule got written down once. It did not get re-explained. The very next pull request — four more Thinking pieces, built by isolated agents in parallel — turned up one draft that had named an LLM by brand in three places, and it was caught and rewritten before merge, same rule, zero new instructions. That's the actual claim under "compound engineering": not that agents get smarter, but that a fix, once written down as a standing rule instead of a one-off patch, keeps paying out on work nobody has started yet. This piece is itself an instance of it — the same grep ran against this file before it shipped.
A rule that has to be re-explained every time isn't a rule, it's a request. Compound engineering is just what you call it once the second request never has to be made.