AI Engineer · Published 2026-08-20

The Era of Compound Engineering — Kieran Klaassen, Every/Cora

Open on YouTube ↗

Summary

Overview

  • Speaker: Kieran Klaassen
  • Channel: AI Engineer
  • Main topic: Compound Engineering: building products and systems using AI without writing code directly, focusing on judgment, taste, and workflow loops.
  • Purpose: To share a high-leverage workflow and conceptual framework for AI engineers and architects to compound their thinking, manage agents, and build complex software products efficiently as a solo engineer with AI support. Kieran Klaassen, founder of AI lab Every and creator of Cora (an AI email client), shares how he has not written a single line of code in a year while successfully shipping products used by thousands. He introduces the concept of compound engineering, emphasizing that implementation is largely solved by AI, while judgment, taste, and memory systems remain the true bottlenecks and levers for human architects.

Topic Map

Introduction and the Core Premise

  • Explanation: Kieran introduces himself and his bold claim of writing zero lines of code this year while shipping successful products like Cora.
  • Key claims:
    • Hasn't written a single line of code this year
    • Ships products used by thousands of people with strong trust
    • Aims to share workflows that outlive trends and set up success for larger AI models
  • Examples:
    • Cora: an AI email client built and maintained by a single engineer using AI systems
  • Terminology:
    • Compound Engineering
    • Cora
    • Every
  • Why it matters: Demonstrates that solo engineers can build full-scale production software by shifting focus from code writing to system architecture and prompt orchestration.

The Evolution of Bottlenecks: Code to Plans to Product to Memory

  • Explanation: Tracing how bottlenecks shifted over two years of building with AI: from bad code and hallucinations to plans, product definition, and finally memory systems.
  • Key claims:
    • Two years ago, code and hallucinations were the bottleneck
    • As code quality improved, making plans and deciding what to build became the bottleneck
    • To avoid repeating instructions, a persistent memory and compounding knowledge system was required
  • Examples:
    • Storing engineering knowledge in Markdown files, then evolving into a dedicated memory system
  • Terminology:
    • Compound Knowledge
    • Agents
    • Memory System
  • Why it matters: Highlights how AI shifts human effort up the abstraction stack toward strategy, product vision, and persistent context.

Implementation is Solved, Judgment Isn't

  • Explanation: Argument that writing code (implementation) is largely solved, whereas human taste, judgment, and knowing where to apply attention are the real challenges.
  • Key claims:
    • Implementation is mostly solved by AI tools and dark factories
    • Judgment and taste remain uniquely human bottlenecks
    • The real skill is knowing when to leverage models and where to apply human brains for iteration and brainstorming
  • Examples:
    • Comparing orchestration approaches with human judgment in product design
  • Terminology:
    • Judgment
    • Taste
    • Orchestration
  • Why it matters: Redefines engineering competency around curation, taste, and decision-making rather than syntax proficiency.

The Compound Engineering Loop and Plugins

  • Explanation: A breakdown of the workflow loop (Ideate -> Brainstorm -> Plan -> Work -> Review -> Polish -> Compound -> Repeat) and custom CLI commands.
  • Key claims:
    • The loop balances human taste at the start and end with AI execution in the middle
    • Spend 50% of time on features and 50% on teaching the system from mistakes
    • Custom plugins like /ce-ideate, /ce-doc-review, /ce-brainstorm, and /ce-polish automate the loop
  • Examples:
    • /ce-ideate for looking at open GitHub issues and generating structured ideas
    • /ce-doc-review for asking sharp questions on PRDs
    • /ce-polish for raising PRs with live testing and pre-loaded judgment
  • Terminology:
    • /ce-ideate
    • /ce-doc-review
    • /ce-brainstorm
    • /ce-polish
    • Compound Engineering Plugin
  • Why it matters: Provides actionable, repeatable CLI tooling and workflows that listeners can immediately adopt to automate their engineering processes.

Core Principles of Compound Engineering

  • Explanation: Four foundational principles: Extract don't repeat, the middle runs without you, document thinking not code, and always maintain >= 50% extraction.
  • Key claims:
    • Extract, don't repeat: codify solutions so you never make the same call by hand again
    • The middle runs without you: autonomous execution should be boring and reliable
    • Document the thinking: reasoning compounds, code is just a temporary artifact
    • Always extract at least 50% of learnings back into the system
  • Examples:
    • Storing solutions in repository documents and token-efficient prompt structures
  • Terminology:
    • Extraction
    • Post-Mortem
    • Token Efficiency
  • Why it matters: Establishes a rigorous philosophy for long-term productivity and system scaling using AI agents.

Key Points

Shift from Coding to Judgment

  • Explanation: As AI handles implementation, human engineers must focus on taste, problem selection, and strategic decision-making.
  • Evidence: Shipped a full email client solo starting in January using Rails and React without writing individual lines of code.
  • Practical implication: Engineers should invest heavily in product sense and evaluation criteria rather than syntax memorization.

The 50/50 Extraction Rule

  • Explanation: Spend 50% of engineering effort building features and 50% extracting lessons, edge cases, and post-mortems back into the system.
  • Evidence: Storing solutions as reusable repo documents and token-efficient context files.
  • Practical implication: Prevents repetitive debugging and ensures AI agents become smarter with every iteration.

Automated CLI Workflows

  • Explanation: Using custom CLI commands like /ce-ideate, /ce-doc-review, and /ce-polish to standardize agent interactions across editors like Cursor and Claude Code.
  • Evidence: Plugin adoption by hundreds of thousands of users across open-source repositories.
  • Practical implication: Standardizes agent-driven development workflows and reduces cognitive overhead.

Frameworks, Models & Processes

The Compound Engineering Workflow Loop

  • How it works: A continuous loop where humans provide vision and taste at the beginning and end, while AI agents handle brainstorming, planning, execution, and review in the middle.
  • Components:
    • Ideate
    • Brainstorm
    • Plan
    • Work
    • Review
    • Polish
    • Compound
    • Repeat
  • When to use: When managing complex software development tasks with autonomous AI coding agents.

The Four Pillars of Compound Engineering

  • How it works: Core rules governing how knowledge and code are managed to ensure continuous compounding of agent capabilities.
  • Components:
    • Extract, don't repeat
    • The middle runs without you
    • Document the thinking, not the code
    • Always >= 50% extraction
  • When to use: When setting up personal or team AI engineering workflows and prompt architectures.

Examples & Case Studies

Building Cora (an AI email client) solo as a single engineer.

  • Illustrates: How compound engineering enables a single person to outperform traditional teams by leveraging AI agents.
  • Lesson: AI allows extreme leverage when paired with strong product judgment and persistent memory systems.

Using /ce-polish to catch duplicate logo marks in UI pull requests.

  • Illustrates: How automated review flows catch styling inconsistencies before human review.
  • Lesson: Codifying review learnings prevents agents from making the same mistake twice.

Actionable Takeaways

  • Immediate:
    • Install the open-source Compound Engineering plugin in your preferred editor (Cursor, Claude Code, Codex)
    • Adopt the 50% extraction rule for all debugging and post-mortem sessions
    • Use structured commands like /ce-ideate and /ce-doc-review in your daily workflow
  • Strategic:
    • Shift engineering focus from writing syntax to curating judgment and taste
    • Treat system prompts and memory repositories as the primary intellectual property
    • Design workflows where AI agents handle the middle execution loop autonomously
  • Questions to investigate:
    • How far can individual engineers push AI capability before scaling their team?
    • How can token efficiency be maximized in compounding knowledge bases?
    • What are the limits of automated judgment in complex system architecture?

Claims Worth Verifying

  • Kieran Klaassen has not written a single line of code in an entire year while shipping production software. (Personal productivity claim)
  • Hundreds of thousands of users utilize the Cora email client daily. (Product usage metric)

Notable Quotes

"I haven't written a single line of code this year." (at 0:23) "Implementation is mostly solved. Judgment isn't." (at 8:53) "Your brain is a fixed size. The system isn't — so keep extracting until the middle runs itself." (at 12:45)

Compressed Summary

  • Implementation is solved by AI; judgment, taste, and system architecture are the new developer skills.
  • The compound engineering loop balances human vision at the start and end with autonomous AI execution in the middle.
  • Always extract at least 50% of learnings back into persistent documentation to prevent repeating mistakes.
  • Custom CLI tools like /ce-ideate, /ce-doc-review, and /ce-polish systematize agent workflows.
  • Keywords: compound engineering, ai agents, workflow loops, software architecture, developer productivity
  • Core insight: As AI makes code implementation cheap, developer leverage comes from compounding judgment, taste, and persistent memory systems into automated engineering loops.

Core insights

6
Mental Modelmedium noveltymoderate evidence

The engineering bottleneck migrates up the abstraction stack as model capability improves: from code/hallucinations, to plans and product definition, to a persistent memory and compounding-knowledge system. Each solved layer exposes the next constraint rather than eliminating work.

Why it matters

Tells architects where to invest next: once codegen and planning are adequate, the marginal returns move to persistent context infrastructure rather than better prompting or bigger models.

Generalization

For any agentic system, expect the binding constraint to shift from execution → decision-making → context/state persistence as capability improves; instrumentation should track which layer is currently binding.

Two years ago, code and hallucinations were the bottleneck
Open source video
As code quality improved, making plans and deciding what to build became the bottleneck
Open source video
To avoid repeating instructions, a persistent memory and compounding knowledge system was required
Open source video
Practicehigh noveltyweak evidence

A hard allocation invariant: ~50% of engineering effort goes to building features and ~50% to extracting lessons, edge cases, and post-mortems back into the system. This is framed as a minimum floor (>=50% extraction), not a one-time investment.

Why it matters

Treats knowledge capture as a recurring operational cost with a numeric target, making agent-improvement measurable and forcing a deliberate budget tradeoff against feature throughput.

Generalization

Any system that relies on accumulated context to reduce repeated human intervention needs an explicit, enforced budget for writing back learnings, otherwise context debt compounds silently.

Spend 50% of time on features and 50% on teaching the system from mistakes
Open source video
Always extract at least 50% of learnings back into the system
Open source video
Mechanismhigh noveltymoderate evidence

Memory content policy inverts conventional artifact storage: persist reasoning and decision rationale, not code, because code is a disposable, regenerable output while reasoning is the compounding asset.

Why it matters

Defines what the memory/context layer should store, which is the difference between a useful long-term agent context and a redundant copy of the repository.

Generalization

Context stores should hold decisions, constraints, and rationale (things a model cannot cheaply re-derive) and be token-efficient; synthesized artifacts like code should not be cached as knowledge.

Document the thinking: reasoning compounds, code is just a temporary artifact
Open source video
Extract, don't repeat: codify solutions so you never make the same call by hand again
Open source video
Storing solutions as reusable repo documents and token-efficient context files
Open source video
Architecturemedium noveltymoderate evidence

The workflow loop concentrates human involvement at the two ends (ideation and polish) while agents run brainstorm/plan/work/review autonomously in the middle, with the explicit goal that the autonomous middle be boring and reliable.

Why it matters

Places the human-in-the-loop boundary deliberately at setup and acceptance rather than at every step, which is the condition under which long autonomous runs are safe to trust.

Generalization

Split agent pipelines into human-owned framing/verification stages and agent-owned execution stages; design the middle for monotonous reliability and relegate judgment to the boundaries.

The loop balances human taste at the start and end with AI execution in the middle
Open source video
The middle runs without you: autonomous execution should be boring and reliable
Open source video
Mechanismmedium noveltymoderate evidence

Standardized slash-commands act as the interface layer between a human and coding agents, encoding intent and pre-loaded judgment as reusable, shareable CLI entry points (ideate from open GitHub issues, adversarial review of PRDs, PR-raising polish with live testing).

Why it matters

Shows a concrete packaging pattern for agent workflows: named, composable commands rather than ad-hoc prompting, which reduces cognitive overhead and makes process portable across editors.

Generalization

Agent workflows become infrastructure when encoded as versioned, invocable commands with embedded judgment, enabling distribution and standardization across teams and tools.

Custom plugins like /ce-ideate, /ce-doc-review, /ce-brainstorm, and /ce-polish automate the loop
Open source video
/ce-ideate for looking at open GitHub issues and generating structured ideas
Open source video
/ce-polish for raising PRs with live testing and pre-loaded judgment
Open source video
Predictionmedium noveltyweak evidence

The claim that implementation is effectively solved (via AI tools and 'dark factories') while judgment and taste remain the sole human bottleneck implies the scarce skill is selecting what to build and where to intervene, not producing code.

Why it matters

If accurate, engineering evaluation and hiring should weight problem selection and evaluation criteria over implementation fluency, and tooling should optimize for judgment transfer rather than code throughput.

Generalization

As generation capability commoditizes, the differentiation moves to problem framing, taste, and evaluation design across domains beyond software.

Implementation is mostly solved by AI tools and dark factories
Open source video
Judgment and taste remain uniquely human bottlenecks
Open source video
Hasn't written a single line of code this year
Open source video

Deep dives

4

Memory content policy and lifecycle for compounding agent context

Research question

If memory should store reasoning, decisions and constraints rather than code, what write/evict/validate policy keeps a token-bounded context store from bloating, going stale, or encoding lessons that later become wrong?

Why

This is the write path of the entire compound-engineering loop: getting the content policy wrong yields either a redundant copy of the repository or a context store that silently poisons future agent runs. Pass 1 identifies no eviction, validity, or correction mechanism, so the compounding asset is also the compounding liability.

Document the thinking: reasoning compounds, code is just a temporary artifact
Open source video
Extract, don't repeat: codify solutions so you never make the same call by hand again
Open source video
Storing solutions as reusable repo documents and token-efficient context files
Open source video
Source video

Measuring the ROI and saturation point of the 50% knowledge-extraction budget

Research question

Does extraction volume measurably reduce the recurrence of previously-extracted mistakes and human interventions per task, and at what extraction share do marginal returns fall to zero?

Why

The 50/50 allocation is the only numeric target in the framework and it removes half of shipping capacity, yet pass 1 offers no metric, baseline, or counterfactual. Without instrumentation the rule is unfalsifiable doctrine rather than an operating budget, and teams cannot tell context debt from context investment.

Spend 50% of time on features and 50% on teaching the system from mistakes
Open source video
Always extract at least 50% of learnings back into the system
Open source video
Source video

Instrumenting the migration of the binding engineering constraint

Research question

Can the currently binding layer (execution, decision-making, or context persistence) be detected from telemetry, and does deliberately improving one layer demonstrably shift the bottleneck upward?

Why

The bottleneck-migration claim is the framework's central mental model and the basis for where architects should invest next. If it is only an ordinal narrative, teams may over-invest in memory systems while codegen quality is still their real constraint; if it is measurable, investment sequencing becomes an engineering decision rather than a hunch.

Two years ago, code and hallucinations were the bottleneck
Open source video
As code quality improved, making plans and deciding what to build became the bottleneck
Open source video
To avoid repeating instructions, a persistent memory and compounding knowledge system was required
Open source video
Source video

Escape rates from an unattended autonomous middle with boundary-only human checks

Research question

When human review exists only at ideation and polish, what fraction of defects survives plan/work/review, and which verification mechanisms substitute for intermediate inspection?

Why

Solo shipping of a production product depends entirely on the middle being boring and reliable, but pass 1 states this as a design aspiration with no failure data. Quantifying escape rates tells architects how much automated verification (live testing, pre-loaded judgment) must be pushed into the unattended segment before it is safe to trust.

The loop balances human taste at the start and end with AI execution in the middle
Open source video
The middle runs without you: autonomous execution should be boring and reliable
Open source video
/ce-polish for raising PRs with live testing and pre-loaded judgment
Open source video
Source video

Article ideas

3

Stop Caching Your Code: Agent Memory Should Store Decisions, Not Diff

Storing generated code as knowledge is a category error — code is regenerable output while rationale is the only asset a model cannot cheaply re-derive, so memory stores should enforce a reasoning-only ingestion policy with an explicit token budget.

Angle

Take the content-policy claim from a solo practitioner and turn it into an enforceable ingestion rule plus the failure modes it prevents (repo duplication, stale code masquerading as knowledge, context bloat).

Source video

The 50% Extraction Tax: Treating Knowledge Capture as an Operating Cost

Framing post-mortems and lesson extraction as a fixed >=50% of engineering capacity makes agent improvement measurable, but only if the return is instrumented through recurring-error and intervention rates — otherwise the rule is a cost with no visible counterfactual and will be quietly abandoned.

Angle

Convert a practitioner heuristic into a budget line with a metric, a saturation point, and an argument for why teams under-invest in write-back until context debt becomes visible.

Source video

Move the Human to the Boundaries: Why Agent Pipelines Should Have a Boring Middle

Long autonomous runs become trustworthy only when human judgment is deliberately concentrated at ideation and acceptance and the middle is engineered for monotonous reliability, which means verification must be pushed into automation rather than distributed across human review steps.

Angle

Reframe human-in-the-loop as a placement decision for the human, and treat 'boring' reliability in the unattended segment as the precondition for solo-scale shipping.

Source video

Project ideas

3

Context Ledger

new

A token-bounded context store that ingests only decisions, constraints, and rationale (never generated code) and applies staleness and conflict detection will reduce repeat human interventions per task compared with an append-only Markdown knowledge base of the same size.

Proof of concept

Wrap an agent loop with a write-back API that rejects code artifacts at ingestion, tags each entry with the decision it encodes and a validity predicate, and prunes under a hard token budget; run the same feature backlog against both this store and a flat Markdown file store.

Measurement

Human interventions per completed task, recurrence rate of previously-captured mistakes, and context tokens consumed per session across two matched arms.

Source video

Extraction ROI Meter

movement-lab

Extraction effort exhibits diminishing returns: above roughly half of session time, each additional extraction hour produces no further measurable reduction in recurring-error or rework rates.

Proof of concept

Instrument agent sessions to log every extracted lesson and every subsequent failure, classify failures as previously-extracted versus novel, and sweep the extraction budget share across a series of comparable tasks.

Measurement

Recurring-error rate and rework hours plotted against the fraction of session time spent extracting, to identify where the curve flattens.

Source video

Boundary Gate Harness

gatehouse

Fault injection against long autonomous agent runs guarded only by boundary-level checks (task framing and final polish/PR acceptance) will show a measurable escape rate that falls predictably as live-testing and pre-loaded judgment are added to the automation, not to human review steps.

Proof of concept

Seeded-defect generator that injects plausible plan, implementation, and review-stage faults into a brainstorm/plan/work/review pipeline configured with no intermediate human inspection; run with and without automated live-test gates.

Measurement

Defect escape rate to the final acceptance gate in each configuration, plus false-rejection rate added by each automated gate.

Source video

Architectural implications

3

Persistent memory migrates from incidental Markdown files into an explicit subsystem of the development process.

Before

Engineering knowledge lives in scattered Markdown files and in the developer's head, re-explained per session.

After

A dedicated memory/knowledge system is a first-class component that agents read from and write to as part of the loop.

Consequence

Context/state persistence becomes an engineered artifact with its own content policy, token budget, and maintenance cost rather than a byproduct of documentation.

Source video

Code is repositioned as a temporary, regenerable artifact while reasoning is the durable asset.

Before

The repository is the primary store of value; the code is the deliverable.

After

The repository's durable value is the record of decisions and extracted solutions; code is regenerated or rewritten by agents.

Consequence

Review, versioning, and knowledge-retention practices must be redesigned around rationale capture, since code churn is high and code diffs carry less signal.

Source video

Human responsibility moves to the boundaries of the agent pipeline rather than distributed through it.

Before

Humans review and intervene at each implementation step, acting as the loop's verification gate throughout.

After

Humans own ideation and polish; agents own brainstorm, plan, work, and review as an autonomous middle.

Consequence

Verification and trust must be pushed into automation (live testing, pre-loaded judgment) because the human no longer inspects the intermediate steps.

Source video

Tradeoffs and failure modes

3

Extraction overhead vs. feature throughput

Benefit

Half of effort diverted to post-mortems and codifying solutions makes agents progressively self-correcting and prevents repeated debugging.

Cost or risk

Half of engineering capacity is removed from shipping features, with delayed and hard-to-attribute payoff.

Spend 50% of time on features and 50% on teaching the system from mistakes
Open source video
Source video

Persistent memory vs. token efficiency

Benefit

A compounding memory system removes the need to repeat instructions and preserves engineering knowledge across sessions.

Cost or risk

Accumulated context consumes token budget and can degrade as stored knowledge grows, requiring token-efficient structures.

Storing solutions as reusable repo documents and token-efficient context files
Open source video
Source video

Trusting an autonomous middle

Benefit

Planning, execution, and review run without the human, enabling solo shipping of a full product.

Cost or risk

If the middle is not uniformly reliable, defects pass unreviewed; the design goal of 'boring and reliable' is an aspiration, not an established guarantee.

The middle runs without you: autonomous execution should be boring and reliable
Open source video
Source video

Open questions

4

How is the return on the 50% extraction investment measured, and at what point does additional extraction stop paying off?

Why unresolved

The summary asserts the rule and its rationale but provides no metric, baseline, or counterfactual for extraction ROI.

Research direction

Instrument agent sessions to track recurrence of previously-extracted mistakes and measure defect/rework rates against extraction volume.

Source video

What keeps a compounding memory system from bloating, going stale, or encoding wrong lessons?

Why unresolved

The summary describes storing solutions and token-efficient context files but no eviction, validity, or correction mechanism.

Research direction

Study context-store lifecycle policies: staleness detection, conflict resolution when a stored solution is later invalidated, and pruning under a token budget.

Source video

Which failures occur when the autonomous middle runs without human review, and what verification replaces human inspection?

Why unresolved

The reliability of the middle is stated as a design goal rather than an observed property, and the summary gives no failure data.

Research direction

Run fault-injection studies on long autonomous agent runs with only boundary-level human checks to quantify escape rates.

Source video

Is the claim that implementation is solved generalizable beyond the speaker's Rails/React single-product context, or an artifact of one stack and one engineer?

Why unresolved

The evidence is a single personal case study with no comparative data across stacks, team sizes, or domains.

Research direction

Replicate the zero-handwritten-code approach across differing stacks and product complexities, tracking rework and maintenance burden over time.

Source video

Key claims

7
factualVerification needed

Kieran Klaassen has not written a line of code in a year while shipping products used by thousands.

Evidence

Hasn't written a single line of code this year

Question

Can the codebase history and commit authorship confirm zero hand-written code while still attributing shipped functionality to the speaker?

Source video
factualVerification needed

A full email client was shipped solo starting in January using Rails and React without writing individual lines of code.

Evidence

Shipped a full email client solo starting in January using Rails and React without writing individual lines of code

Question

What fraction of commits, fixes, and maintenance work were agent-generated, and how much human post-editing occurred?

Source video
causalVerification needed

As code quality improved, planning and deciding what to build became the bottleneck, and persistent memory became necessary to avoid repeating instructions.

Evidence

As code quality improved, making plans and deciding what to build became the bottleneck

Question

Does the bottleneck demonstrably shift upward under controlled improvement of codegen quality, or is this an ordinal narrative?

Source video
causalVerification needed

Spending 50% of time extracting lessons, edge cases, and post-mortems back into the system improves agent performance on subsequent iterations.

Evidence

Always extract at least 50% of learnings back into the system

Question

Does extraction volume correlate with reduced recurring errors or reduced human intervention per task?

Source video
opinionVerification not requested

Implementation is mostly solved by AI tools and dark factories, leaving judgment and taste as the remaining human bottlenecks.

Evidence

Implementation is mostly solved by AI tools and dark factories

Source video
factualVerification needed

The compound engineering plugin achieved adoption by hundreds of thousands of users across open-source repositories.

Evidence

Plugin adoption by hundreds of thousands of users across open-source repositories

Question

What are the plugin's install/download counts and are they distinct active users or cumulative installs?

Source video
causalVerification needed

Standardized CLI commands for ideation, doc review, and polish reduce cognitive overhead and standardize agent-driven workflows.

Evidence

Standardizes agent-driven development workflows and reduces cognitive overhead

Question

Do teams using standardized agent commands show measurably lower context-switching or rework than teams prompting ad hoc?

Source video

Connections

4