Compound Engineering

Most AI-assisted workflows focus on output. Compound engineering focuses on residue. What remains after the feature ships? Was a plan written that another agent could execute without guessing? Did review uncover a class of problem that can now be prevented? Did the team save the lesson anywhere a future session could retrieve it?

That is why the philosophy is more demanding than “use AI to code faster.” Faster coding by itself is cheap. It can recreate the same old mistakes with more impressive throughput. The compounding part is what makes the system improve rather than merely accelerate.

Kieran Klaassen’s cleanest line is still the best one: a human would remember; the AI would not. The whole system exists to close that gap. Plans should remember the repo’s patterns. Reviews should remember the failure modes you care about. Compound artifacts should remember the bugs and tradeoffs that would otherwise vanish into chat logs and pull request comments.

The loop is easy to memorize and easy to flatten into a slogan. The interesting part is where the time and rigor go. Planning is not a preamble. Review is not etiquette. Compound is not an optional archive step.

Brainstorm is upstream work for when the idea is still vague. Once the requirement is clear, planning should run without you. That is one of the sharpest practical ideas in the Every workflow: planning is where most of the thinking belongs.

Work becomes execution against a reviewed blueprint instead of improvisation. Review becomes multiple perspectives running in parallel instead of one person scanning a diff alone. Compound is the move that turns a solved problem into future leverage, and it should happen while the context is still fresh.

The brainstorm documents do something simple but important: they compare paths before implementation. The CI foundation brainstorm preserved the choice between minimal guardrails, phased monorepo CI, and full compliance upfront. The later Paylocity reporting brainstorm preserved a second shape of decision: standalone repo, monorepo MVP, or near-real-time scope from day one.

From there, the Paylocity reporting-sync plan turned scope, runtime, repo placement, and deployment ownership into a staged execution sequence. It did not just say "build reporting." It constrained the first slice to time-entry pull, validation, sync observability, and dev-before-prod proof.

The valuable part is what happened next. Real payload validation then exposed a contract mismatch around open punches. That did not stay trapped in debugging. It became a reusable solution document: nullable end times for true open punches, mapper rules that do not fabricate closed shifts, stable fallback keys, and reporting views that expose OpenPunchCount honestly.

Most teams stall at Stage 2 because line-by-line supervision feels safer. It is also the point where the human becomes the bottleneck. Stage 3 is where plans harden enough that the human can stop hovering over every line and start evaluating whether the output matches the plan, works in reality, and respects the team’s standards.

That is why the jump from Stage 2 to Stage 3 feels uncomfortable. The workflow changes, but so does the emotional model of control. The right move is not to jump straight to a swarm of autonomous agents. It is to build enough trust in planning and review that the system becomes easier to rely on than your old habits.

The wrong way to adopt compound engineering is to imitate the most advanced version of the system on day one. The right way is to remove one repeated tax forever and then repeat.

Start with your instruction file. Tighten AGENTS.md or CLAUDE.md until it reflects your actual standards, not vague aspirations. Then pick one review tax you pay every week and make the system own it. Then save one solved problem into a searchable document.

The Every team has a useful forcing function for this: the $100 rule. When something fails that should have been prevented, feel the sting once and spend it on the permanent fix: a test, a rule, a monitor, or an eval. That is how a failure turns into a better system instead of another recurring tax on attention.