The Era of Compound Engineering

Kieran Klaassen presents compound engineering as a way to make each agent-assisted delivery improve the next. Drawing on his Cora rebuild, where he is the primary engineer with design and specialist database-engineering support, he recommends keeping human judgment at the beginning and end, automating the repeatable middle, and storing corrections and decision rationale for later runs.

Keep the Human Brain at Both Ends

• The bottleneck moved from code to plans, product choices, and memory: Klaassen describes a two-year progression in which model output first needed code review, then better plans, then better decisions about what to build. Repeating the same guidance led him from an oversized CLAUDE.md file to a system for retaining reusable knowledge 03:48–05:29(opens in a new tab).
• Use human judgment where it changes direction or quality: His “human–AI sandwich” puts people in the brainstorming stage to understand the problem and in the polishing stage to apply taste and raise the bar. Planning, implementation, and review form the automatable middle 05:29–07:26(opens in a new tab).
• Treat workflow improvement as part of delivery: Klaassen’s 50/50 rule is to spend half the effort delivering the feature and half teaching the system from anything it did wrong. This is a personal allocation heuristic, not a measured optimum 07:26–08:16(opens in a new tab).
• Store solutions where future runs can retrieve them: He keeps solution documents in the repository and argues that known answers can reduce repeated research, correction, and review. The talk does not compare token use or maintenance cost against a workflow without this memory 08:16–09:19(opens in a new tab).

Turn Decisions and Corrections Into Workflow Inputs

• IDEATE turns scattered demand into a ranked decision artifact: The demonstration gathers open tickets from systems such as Linear, GitHub, Slack, and Intercom, then relates possible work to stored strategy, objectives, and earlier experiments. It produces an HTML artifact that a team can inspect rather than silently choosing the next task 10:22–12:23(opens in a new tab).
• DOC REVIEW converts unanswered questions into retained context: The command critiques a product requirements document with targeted questions. Once people answer them, COMPOUND stores the resulting knowledge so a later review can use the answer instead of asking again 12:23–13:20(opens in a new tab).
• BRAINSTORM is deliberately interactive: For an idea too large to specify directly, Klaassen blocks focused time, loads product differences and personas, and answers a small set of questions. The desired output is a better plan and a retained brainstorm, not a high question count 13:20–14:25(opens in a new tab).
• LFG automates the middle and leaves review evidence: The longer-running command plans, implements, tests, dogfoods, fixes issues, opens a pull request, and adds before-and-after video or screenshots. Klaassen runs these jobs for hours and in parallel, but the talk does not show failure rates or independent quality results. He also says he sometimes reaches POLISH without knowing what the run built or which problem it addressed, exposing a tension with his “brain at both ends” prescription 14:25–16:22(opens in a new tab).
• POLISH captures taste, not basic correctness: In the example, the implementation works, but Klaassen rejects a page containing two logo marks. He records the one-mark preference through COMPOUND so later design work can apply it without repeating the correction 15:29–16:22(opens in a new tab).

Make the Next Feature Easier

• Extract repeated guidance even without the plugin: Klaassen’s portable rule is “never repeat”: store recurring corrections in a form the agent can retrieve, and keep refining the middle until planning, work, and review can run predictably without supervision 16:22–18:02(opens in a new tab).
• Document why a decision happened: Code records the result, but Klaassen argues that generalization needs the reasoning behind it. He recommends using traces and postmortems to identify the decision that caused a failure and convert that explanation into changed behavior for the next run 17:11–19:08(opens in a new tab).
• Judge compounding by future work, not present output alone: His closing standard is that shipping a feature should make the next feature easier rather than merely adding complexity. That requires understanding the problem before delegating and applying taste after the automated loop returns 19:08–19:56(opens in a new tab).

Explore the Compound Engineering repository on GitHub(opens in a new tab).

Watch the full talk on YouTube(opens in a new tab).