Dan Shipper and Kieran Klaassen present compound engineering, the engineering process developed at Every where 100% of the code is written by AI agents. The core principle is an inversion of complexity: in traditional engineering, each feature makes the next one harder; in compound engineering, each feature makes it easier, thanks to a learning loop that documents every bug, failed test, and insight for future agents.
The process breaks down into four steps. Plan (~40% of the time) begins with thorough research of the codebase, git history, and external best practices, after which the agent produces a complete planning document including the objective, proposed architecture, code examples, and success criteria. Work (~10%) is the simplest part: the agent executes the plan step by step, using MCP protocols like Playwright to test the application like a real user and iterate until satisfied. Assess (~40%) combines linters, unit tests, manual tests, and a system of 12 parallel subagents that evaluate the code from different perspectives (security, performance, complexity, architecture). Compound (~10%) is "the magic step": the lessons from each cycle are summarized by the agent and stored for future use.
Compound engineering works in practice at Every: five software products (Cora, Spiral, Sparkle, Monologue, and others), each primarily built and maintained by a single person, are used by thousands of users daily. The productivity estimate is that a well-equipped developer today does the work of five developers from a few years ago.
The primary tool is Claude Code, but the approach is tool-agnostic (Factory Droid and OpenAI Codex CLI are also used). Every has released an open-source plugin for Claude Code that implements the complete workflow, including the 12 review subagents.
The compounding mechanism is the key differentiator: the lessons learned live in the codebase as prompts, making every developer — including new hires — as well-informed as a veteran. Cora's agent, for example, must systematically ask itself where to place a feature within the system and whether a reusable precedent already exists.
The authors conclude that this approach renders many established practices obsolete: manually writing tests, exhaustive code documentation, no-internet coding interview exercises, and technology lock-in caused by legacy systems.