AI Engineer

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

1991 summary words 9 min summary Watch video

Start with the signal

9 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: The durable advantage in AI-assisted engineering is not autonomous code generation itself but a compounding system that captures human judgment, product reasoning, and quality standards so each feature makes the next one easier to build.
  • Why it matters: It offers a concrete operating model for building agentic development workflows: reserve human attention for problem framing and final taste, automate the implementation middle, and turn every correction into reusable system memory.
  • Best use: Use it as a design reference for Ken's agent control plane and engineering workflow: especially the memory/extraction loop, long-running execution architecture, and separation of QA from high-standard product polish.

Executive Summary

Kieran Klaassen describes "compound engineering" as an operating system for a solo or small AI-native product team. His premise is that code generation has ceased to be the main constraint: models can increasingly plan, implement, test, and review. The remaining scarce resource is human judgment—deciding which problem matters, understanding users, setting product direction, and judging whether an output is genuinely excellent.

His workflow is a "human-AI sandwich." The human is deliberately active at the beginning, during ideation and problem framing, and at the end, during product polish and quality-bar setting. The AI occupies the middle: it plans, builds, tests, reviews, opens pull requests, dogfoods the result, and can run unattended for hours or overnight. This autonomy is not treated as a prompt trick; it is earned by improving the underlying workflow until it reliably runs without intervention.

The compounding mechanism is systematic extraction. Whenever the operator repeats a preference, corrects a mistake, answers a recurring product question, or learns something in a postmortem, that reasoning is stored as a retrievable solution document in the repository. Klaassen argues that this makes future work faster and potentially more token-efficient because the agent starts with relevant answers rather than rediscovering them, receiving repeated review feedback, or conducting broad external research.

The talk is particularly useful because it translates the philosophy into a practical command flow: prioritize work from issue and customer-feedback sources, review ambiguous product documents, brainstorm large initiatives using prior strategy and personas, execute long-running build loops, then conduct a separate human polish pass. The central standard is operationally sharp: after shipping a feature, the next feature should be easier—not harder—because the system has learned.

Key Takeaways

  • Claim: AI-native engineering should optimize for compounding judgment rather than merely faster code generation. | Evidence: Klaassen says his bottleneck moved from bad generated code, to planning, to deciding what to build, and then to repeatedly communicating the same product and engineering knowledge. He built a memory system after simple Markdown-based storage became too large. | Implication: Ken should treat agent memory as a first-class operating asset: capture decision rationale, preferences, constraints, and outcomes rather than only retaining code and prompts. | Caveat: This is a practitioner account from one product and workflow, not a controlled comparison proving that the approach will outperform conventional teams in every environment.
  • Claim: The right division of labor is human judgment at the start and finish, with agents handling the implementation middle. | Evidence: Klaassen calls this the "human-AI sandwich": humans frame the problem, brainstorm, and apply taste at the end; the machine performs planning, implementation, review, testing, and related execution work. | Implication: Design agent workflows with explicit human gates for intent formation and acceptance-quality review, rather than expecting an autonomous loop to supply strategy or taste by itself. | Caveat: He explicitly warns against delegating initial understanding of the problem to AI; automation depends on a correctly set-up process and meaningful human framing.
  • Claim: Teams should spend roughly as much time teaching the system as shipping the immediate feature. | Evidence: His stated rule is 50% of effort on whether the feature delivered its intended value and 50% on converting errors, corrections, and discoveries into system knowledge for the next run. | Implication: Budget explicit post-task learning work into agent operations—failure analysis, rule updates, retrieval/document changes, and evaluation improvements—rather than treating these as optional cleanup. | Caveat: The 50/50 split is a heuristic, not an empirically justified universal allocation; its feasibility will vary with delivery urgency and workflow maturity.
  • Claim: Store the reasoning behind decisions, not merely the implementation artifact. | Evidence: Klaassen stores solution documents inside the repository and argues that postmortems should trace which human or agent decision produced an incident, then turn that decision into a changed behavior for future work. | Implication: For Ken's systems, retain decision traces and outcome-linked lessons alongside technical artifacts so agents can generalize policy and product intent rather than imitate prior code mechanically. | Caveat: Stored reasoning can become stale or contradictory without curation, retrieval discipline, ownership, and mechanisms to supersede old guidance.
  • Claim: Long-running autonomous work is a reliability test of the workflow, not the end goal of automation. | Evidence: The /LFG loop can run for hours or overnight, performing planning, coding, review, testing, PR creation, dogfooding, attempted fixes, and before/after screenshots or video in the pull request. Klaassen says that if the operator is still needed throughout the middle, the team should improve that middle manually until it becomes boring and dependable. | Implication: Autonomy should be introduced as a graduated capability with clear evidence artifacts and failure feedback, not as unrestricted background execution without an audit trail. | Caveat: He treats a broken result during the final polish phase as a failure of the automated loop; that standard requires robust tests, observability, and constrained execution that are not detailed in the talk.
  • Claim: Product polish is distinct from QA: a functioning result may still fail the desired quality bar. | Evidence: In the example, the generated interface technically worked but displayed a logo mark twice. The human reviewer did not simply fix that instance; they expressed the general design rule—only one mark per page—and ran the compounding step so future design work retrieves it. | Implication: Separate functional verification from a taste/brand/product review layer, and encode reusable standards with context labels instead of relying on one-off PR comments. | Caveat: Taste rules can be context-dependent; turning every visual preference into a global rule can overconstrain future design unless knowledge is scoped and tagged appropriately.
  • Claim: Compound engineering can extend beyond coding into product management, design, and knowledge work when operational knowledge is connected to strategy. | Evidence: The plugin's ideation command can ingest Linear, GitHub issues, Slack, and Intercom; structure open work; argue for priorities; and score ideas against OKRs, past experiments, repository knowledge, and strategy documents. A document-review command asks sharp questions on PRDs, and answered questions can be compounded for later reuse. | Implication: Ken can apply the same memory-and-evaluation pattern to GTM, research, and operating decisions, provided source authority, strategy alignment, and human decision rights are explicit. | Caveat: The talk demonstrates outputs and workflow claims but does not provide measured prioritization quality, adoption outcomes, or examples of the system rejecting a plausible but strategically wrong recommendation.

Detailed Brief

The demonstrated Compound Engineering command flow

  • Claims: CE ideate turns disconnected operational inputs into a reasoned prioritization artifact rather than merely summarizing tickets.; CE doc review is intended to surface unresolved assumptions in PRDs and other documents; its answers become durable organizational context.; CE brainstorm is deliberately a human-focused session for initiatives too large or ambiguous to specify directly, using existing product versions, personas, and stored knowledge.; CE polish is an orientation and judgment layer for reviewing agent-produced changes, especially when the operator did not personally follow the full implementation path.
  • Evidence: Ideation produces a shareable HTML page and can be pointed at OKRs; Klaassen mentions users turning it into a presentation with an XY-style prioritization matrix.; The brainstorm example concerns migrating users from Cora version 1 to version 2; Klaassen favors asking only the minimum useful number of questions over lengthy question lists.; For polish, he runs the flow in Cursor with an explanation of what an LFG run introduced on one side and the resulting product on the other.; He also feeds video recordings into the execution flow for analysis of what went wrong.
  • Caveats: The transcript provides no architecture for source permissions, conflict resolution across Slack/Linear/Intercom, or safeguards against sensitive customer information entering repository memory.; The commands are examples from an open-source plugin, not requirements for adopting the underlying method.
  • Implications: A useful control plane should produce inspectable decision artifacts—prioritization rationale, plans, change explanations, and visual evidence—not only code diffs.; Question-asking should be optimized for decision quality and information gain, rather than maximizing the appearance of deliberation.

Solo-builder economics and the strategic bet

  • Claims: Klaassen built Cora, an agent-native email client used by thousands, as the primary engineer while receiving design and specialist database support.; He intentionally chose not to scale a conventional engineering team after seeing a capability shift with Claude Sonnet 3.5.; His strategic bet is that implementation keeps getting cheaper while judgment and taste remain comparatively scarce.
  • Evidence: Cora is described as operating across desktop, phone, CLI, and Codex/MCP-style environments; its version-2 rebuild began in January and uses Rails/Ruby on the backend and React on the frontend.; He characterizes the plugin as usable in Codex, Claude Code, Cursor, and more than ten other tools, while emphasizing that the core practice could be implemented with ordinary files.
  • Caveats: The one-engineer claim includes support for design and difficult database problems, so it should not be interpreted as complete independence from specialized human expertise.; The talk does not address organizational, regulatory, or reliability limits that can make a solo-agent model unsuitable for some production systems.
  • Implications: The relevant unit of scale may increasingly be a high-judgment operator plus a well-instrumented learning system, but specialist escalation paths remain part of the model.; Ken should evaluate AI leverage in terms of reduced coordination and repeated-context costs, not just raw coding throughput.

Notable Concepts & Terms

  • Compound engineering: A workflow in which each feature, correction, decision, and postmortem becomes reusable context that improves future agent work.
  • Human-AI sandwich: The proposed division of labor: humans frame the problem and set the final quality bar; AI executes the planning-to-implementation middle.
  • Brain-on work: Deliberate human-attention stages such as ideation, brainstorming, and polish, where judgment should not be passively outsourced.
  • Solution documents: Repository-stored documents containing answers, rationale, and learned rules, intended to reduce repeated research and correction.
  • CE compound: The plugin action that extracts a new lesson or preference into retrievable system knowledge after a correction or answered question.
  • /LFG: A long-running automation loop that handles planning, implementation, review, testing, PR creation, dogfooding, fixes, and visual evidence.
  • CE polish: A post-execution human review mode focused on raising product quality and encoding taste rules, not basic functional QA.
  • Agent-native: Klaassen's description of Cora as a product where actions available to a user are also available to an agent across multiple interfaces.

Operator Notes / Why Ken Should Care

  • Define a mandatory learning-output artifact for significant agent runs: decision rationale, failure mode, reusable rule, scope/tags, owner, and supersession date or condition.
  • Implement two distinct acceptance gates in agent workflows: functional verification before handoff and human product/taste review after handoff.
  • Pilot an unattended build loop only with required evidence outputs—test results, change summary, PR, and before/after visual capture—and measure how often human intervention is still needed in the execution middle.
  • Create a strategy-aware prioritization experiment that grounds recommendations in approved OKRs, past experiments, customer signals, and explicit source provenance.
  • Establish memory hygiene before broad rollout: retrieval scoping, conflict handling, expiration of stale guidance, and access controls for customer/support data.

Source/Metadata

  • Title: The Era of Compound Engineering — Kieran Klaassen, Every/Cora
  • Transcript words: 5408
  • Duration seconds: 1238
  • Timestamp note: No timestamps or chapter markers were present in the supplied transcript; the latter portion substantially repeats earlier material.
Search this video Resume transcript at 0%
Full transcript 3127 words · 24 min read
0:13

Hello, hello everyone. Welcome. I want to start by saying I haven't written a single line of code this year. Maybe I haven't even looked at most of it. Yet I do ship. I have a product I built that thousands of people use and trust with their email inbox, which is amazing. I'm actually proud of the code I ship. And I'm proud of the product I ship. I've been doing this for two years and trying to extract my thinking and my taste into a system that compounds. And I'm going to share how I do that.

0:44

Lots of stuff you hear is, "Oh, you should use this, the factory, dark factory, do that, blah, blah, blah. All the new, high, hip, cool things." What I'm trying to do is not that today. I'm going to just show you how I work and hopefully share something that you can bring to your workflow that will outlive trends and really set yourself up for success for newer models, bigger models.

0:51

There are two halves in this talk. One is why it's so important to compound, how I got here. So this is for people that maybe are not at the end of the trajectory. It's interesting to see how to get there. And then stuff you can run yourself. You can use it day to day to ship, to build, to research, to do knowledge work even. Hello. I'm Kieron. I work at Every. Every is an AI lab for the future of work. And we ask ourselves the question, "What's next?" And we write about it. We teach about it. We build. And we have a studio where we have mostly single-engineer teams that take a problem they really care about and use AI to build a product out and really leverage that.

1:05

And compounded knowledge is a big way we do that. Lots of loops, shipping faster and faster. And Cora is mine. It's where I invented compounded engineering. And it's a complete AI email inbox. It's agent native. So that means whatever you can do, the agent can do. It runs on your desktop, phone, CLI, inside Codex, like MCPs. And I'm rebuilding it as version 2. So soon, beta access. If you want access, just DM me. Talk to me.

1:09

The cool part is it's one engineer. And I have support. I have design support. I have some database hardcore engineering problem support. You need some support. But I built a full email client alone. And I've only started building this in January, this new rebuild. I use Rails on the back end. I love Ruby. React on the front end. And I own products fully. So I talk to people. When something goes down, I'm the one responsible.

1:15

And it's set up like this on purpose. I'm an ex-VP of engineering and founder. And I know how to hire, grow teams, all of that stuff. But I wanted to do the opposite. With Sona 3.5, I just felt there was something new that was unlocked. And I wanted to see how far AI can go before I actually need to grow the team. And I'm still alone with some support, which is cool.

1:23

So I built Cora. And this is what I learned. Two years ago, I started. And the bottleneck back then was code. So it kept moving, and my job changed over the years. But first, there was bad code. Hallucination, just stuff that didn't work. I added agents. I added skills, just reviewing it. So, okay, code got good. The plan was the bottleneck because it could do things, but larger things. So whenever I have a good plan set out, it would do bigger things than just code changes. Okay, plans got good.

1:37

The next bottleneck was deciding what to build. Talking with users, really understanding problems you're solving. This is why it's so good that you use your own product. You love what you're building for. And that got really good as well. The scope got bigger. AI could help write plans. And I kept repeating myself. And that was annoying. So I figured out there needs to be some kind of memory system. So every time I repeat myself, I can say, "Hey, can you make sure to store this knowledge in some way?" I started with storing this in ClothMD. But at some point, that became too large. So I built a system that remembers. And that's really where compound engineering came from.

1:51

And you see me go away from typing more toward judgment and taste. And I think implementation is mostly solved, even though you see many people that do orchestration, dark factories. It works, which is cool. But the thing that doesn't work is our judgment and our taste.

1:59

And for me, it's really where do I turn my brain on versus when do I leverage the model? And it's where you make judgments and where you add taste. So where you think, where you iterate, where you jam, where you brainstorm, I extract that into a system. And if it's extracted into the system, you can move on to bigger problems. Because the next time the AI will come up with a brainstorm, it will already include that thinking. So you can go on for the next one. And I see that one engineer with a compounding system just beats teams, full teams that use AI that don't.

2:15

And the real trick here is on both ends. It's the human-AI sandwich, where the human is the bread and the AI is the middle part. And the brain is on the ends. So the start, brainstorming, where you have to decide what to work on, what the problem is, and really understand what you're trying to do. And at the end, where your taste comes in, where you decide this looks very good, makes me very happy, or we need to raise the bar, we need to do better, we need to make it more snappy, we need to go optimistic, or whatever that is, delight.

2:22

And throughout here, especially in the brain-on parts, it's important to extract the learnings to compound. So that's the loop. You cannot run the middle if it's not set up correctly. And it's very important to be able to let go and let the machine rip overnight for many hours in parallel. And the only way to be able to do that is making sure you spend time on that system.

2:30

So my rule is 50% should go into creating the feature, just making sure, did it build the feature, did it deliver the value you set out to do. But 50% of the time should go to teaching the system. For anything that it did wrong, can we learn something? Can you teach the system something? And this is something that is hard, but it's very important because it will make the next time better.

2:37

One bonus is because of this extraction, I store all of this knowledge inside my repository as solution documents. And people say, "Oh, but tokens." And in my research, it's actually more token efficient because if you have the right answers and the right solutions already within the token, you don't need to do review. You don't need to correct. You don't need to do deep research across the internet because the token's already there. So it's actually more token efficient in the long term, which is cool. Less research, finding things faster.

2:43

The real reason why this works is my brain is fixed and AI isn't, or is less fixed. And my philosophy is keep extracting until the complete middle runs itself and is so freaking good that it will surprise you. Let me show you how this works. So I have a plugin called the compound engineering plugin that you can install in whatever tool you use, Codex, Cloud Code, Cursor, plus ten others. And I just built this while building Cora, shared it at some point, and now hundreds of thousands of people use it daily. So thank you all for using it if you did. I'm honored. I never decided this should be something like hype. It's just me using my plugin, shipping code.

3:00

You can install it wherever. You can also create your own version of this, which could be just storing information in files, however you do it. But let me show you the plugin. So compound engineering became compound product as well. I have a lovely co-contributor, Trevon Chow, who has a very good product sense and product background. So he brought a lot of product thinking. And I think compound engineering is really for engineers, PMs, designers, even people that do knowledge work. Within Every, a lot of people use compound engineering. It's such a universal concept of compounding knowledge. It doesn't have to be used for engineers. But that's where it came from.

3:17

So the first demo is it's here to activate your brain. So this is called CE ideate, and you can run it. And here I run it in—it's maybe a little bit small—but I say, "Hey, I have Cora version 1. I want to upgrade people to version 2." And come up with—oh no, actually, this is "look at all my open tickets, tell me what to do next." It's a great command. It will just go through all your issues. And you can link Linear, open source issues on GitHub, Slack, Intercom. What it will do is it will generate structure from all this mess and will make arguments about what is good to work on versus not good to work on.

3:23

And the cool part is it will reason about this. And the output here is a clean HTML page that you can share with the team, that you can be inspired by. So this is generation of ideas. And the cool part is you can point it to your OKRs. You can get ideation aligned to your strategy. And that's how it compounds. So if you have past experiments or past learnings in your repository, or a strategy document, which you can create with CE strategy, it will score these ideas against this knowledge already, which is really cool.

3:32

And I've seen people dump this document inside Cloud Design and say, "Create a PowerPoint." And you get a beautifully designed PowerPoint with an XY matrix of where the sweet spot is for what to do for your OKRs, which is very little effort for you and very impressive to bring to your team.

3:38

Next one is a very simple one. It's called CE doc review, but it's very useful. If someone hands you a PRD or some kind of document, run doc review on it, and it comes back with very sharp questions. I always like the questions. I'm like, "You can't do that." So either you relay this to your colleague or you ask them to answer. You can then compound that knowledge after answering with CE compound so that the next time this answer is already baked in and it wouldn't ask you. It would already know the answer because it's already embedded in the system.

3:44

You can share this with people. You can say, "Oh, you can actually run this yourself as well." This runs anywhere, so you can do it in cowork as well. It doesn't need to be in Cloud Code. It's a very simple thing that we spend a lot of effort on to make very good, and it's part of our flow. This is my most used one. It's when the idea is too big to describe. So this was the example of Cora version 1 to version 2. I say, "CE brainstorm." This is a brain-on command. I know I need to get into the zone. I block off time. I'm not going to multitask or anything like that. And I run this.

3:56

So it pulls in compound knowledge. It looks at the difference between Cora 1 and 2, and it looks at the personas I've set up, so it will see, "Hey, certain people need certain things," and it will ask me questions. And it doesn't ask me a lot of questions. It's dialed in to ask you just the right amount of questions it needs to do the work. It's very easy to get 30 questions and feel, "Wow, I did so much." But in the end, the goal is not to answer questions. In the end, it's to get the absolute best work out of it. And I think other libraries might over-question. I think there's a balance to be found there.

4:10

So out comes a plan, a brainstorm document, stored and compounded. And then my favorite is just /LFG, which is the loop, the automation loop. And if you like vibe coding, /LFG something is great as well. It will run for hours. It will do planning, work, review, testing, open a PR, it will dogfood, it will try and fix things. It will then do a before-and-after video screenshot in the pull request. Makes it super easy for you to then see what happens.

4:16

Last, if it comes back—so this is overnight, you can do parallel—there's polish. This is the brain-on again. CE polish, you give it the pull request. And what it will do is it will show you—so I like to run it in Cursor. And on the left side, I like to run this, and it will tell me, "Hey, this was introduced with this LFG flow." And on the right, it will show the product.

4:24

This is important. Sometimes I don't even know what was built because I also have video recordings that I dump into LFG that it will then process and analyze and see what went wrong. So sometimes I don't even know what it was solving for. So it's a good primer to know, okay, this is where we are, this is what it's solving, this is how it solved it, and you tell me, what do you think?

4:32

And this is not QA. This is raising the bar. It should work. If it doesn't work here, your LFG flow failed. But you can see here, in this example, there is a mark of a logo mark twice, which is not technically wrong, but I don't want two marks on one page. So in this case, I can say, "Hey, there are two marks here. Can we just make sure we only ever have one?" And run CE compound. So it will extract that knowledge, make sure next time when I do design work, it's tagged correctly. It will find that file and know not to do that. So that's closing the loop. You merge it, and you learn something.

4:48

So why does compound engineering resonate with people? I think it's not a very new concept. It's just something how we do software engineering. It's just now, instead of working with teams, we use AI and we leverage that. And AI is very good at specific things, especially with large amounts of knowledge and doing the right thing, especially with the latest models.

4:57

So if you want to do this yourself, if you don't want to use my plugin, make sure to extract. Never repeat. If you see yourself repeating yourself, make sure to extract it somehow. Make sure it doesn't happen again. Make sure that there is a middle that can run without you, that does the planning, work, and reviewing, and it should be boring. It should just work. You should not be needed. If you're still needed in the loop, spend time on the middle, do it manually, feel where it's off, and iterate until you can actually let it go. And if you are at a point where you just run something and it runs for three hours and it's always good, you know you're there.

5:12

It's important to document the thinking, not the code. This is also very anti-developer-y. It's like, yeah, the documentation shouldn't mean the code, and the code is the artifact itself. But I am of the opinion that, to generalize, you need reasoning behind why you did something. And all these traces, even though they're bad, could lead to things like, "Hey, something happened in a postmortem. What decision was made by whom or what agent that led to this? Can we then turn that into a learning so we change that behavior for the next time?" And I've seen it work very well, especially with postmortems.

5:25

And again, every interaction, spend 50% of your time to make it better the next time. So make sure to build the system that will remember. Instead of "was this good," make the system better and make the system know. And I know it's hard. It's just hard to do for myself. And we all know we need to do it. But it's awkward. And it's like, "Eh, it works. It's great. Let's just move on." But it's very important. And you can see the system really go if you do that a lot.

5:33

So the bet is implementation is only getting cheaper and judgment is not. And the future models and systems need to be set up so they have access to this judgment that we have, our taste, to have more leverage. So that is the bottleneck. And remember, brain at the ends. Really activate your brain. Make sure you really understand what you're doing at the start. Don't overload the thinking to the AI. Make sure you truly feel, understand what you're doing, the problem. And let the AI go. And at the end, raise the bar. Make sure you don't fix things. It should be very good at the end. But make sure to raise the bar because we're not shipping shitty code.

5:48

And your standard should be: the next feature should be easier because you shipped this one. If the next feature is harder because you added complexity, which is normally how engineering works, we're flipping that. The next feature should be easier to build because you shipped this one. I'm Kieron. Check out the plugin. It's open source. Please contribute. PRs welcome. I love PRs from everyone. Go build your orchestration system. Go build your personal knowledge base that compounds. And thank you. I'll be hanging around if you have questions. And enjoy the rest of your day. you can move on to bigger problems. Because the next time the AI will come up with a brainstorm,

6:21

it will already include that thinking. So you can go on for the next one. And I see that one engineer with a compounding system just beats teams, like full teams that use AI that don't.

6:45

And I see that one engineer with a lot of people that use the same thing. And the real trick here is on both ends. It's kind of the human AI sandwich, where the human is the bread and the AI is the middle part. And the brain is on the ends. So the start, brainstorming, where you have to decide what to work on, what the problem is, and really understand what you're trying to do. And at the end, where your taste comes in, where you decide this looks very good, makes me very happy, or we need to raise the bar, we need to do better, we need to make it more snappy, we need to go optimistic, or whatever that is, like delight.

7:26

And throughout here, especially in the brain on parts, it's important to extract the learnings to compound. So that's basically the loop. You cannot run the middle if it's not set up correctly. And it's very important to be able to let go and let the machine rip overnight for many hours in parallel. And the only way to be able to do that is making sure you spend time on that system. So my rule is 50% should go into creating the feature, just making sure, like, did it build the feature, did it deliver the value you set out to do. But 50% of the time should go to teaching the system for anything that

8:14

they did wrong. Can we learn something? Can you teach the system something? And this is something that is kind of hard, but it's very important because it will make the next time better. One bonus is because of this extraction, I store all of this knowledge inside my repository as solution documents. And people say, oh, but tokens. And in my research, it's actually more token efficient because if you have the right answers and the right solutions already within the token, you don't need to do review. You don't need to correct. You don't need to do deep research across the internet because the token's already there. So it's actually more token efficient in the long term,

8:58

which is cool. Less research, finding things faster. The real reason why this works is my brain is fixed fixed and AI isn't or less fixed. And my philosophy is keep extracting until the complete middle runs itself and is so freaking good that it will surprise you. Let me show you how this works. So I have a plugin called the compound engineering plugin that you can install in whatever tool you use, codex, cloudcode cursor, plus ten others. And I just built this while building Quora, shared it at some point, and now hundreds of thousands of people use it daily. So thank you all for using it if you did.

9:46

I'm honored. I never decided this should be something like hype. It's just me using my plugin shipping code. You can install it wherever. You can also create your own version of this, which could be just storing information in files, however you do it. But let me show you the plugin. So compound engineering became compound product as well. I have a lovely co-contributor, Trevon Chow, who has a very good product sense and product background. So he brought a lot of product thinking. And I think compound engineering is really for engineers, PMs, designers, even people that do knowledge work within every love

10:30

of to use compound engineering. It's such a universal concept of compounding knowledge. It doesn't have to be used for engineers. But that's where it came from. So the first demo is it's here to activate your brain. So this is called CE ideate, and you can run it. And here I run it in it's maybe a little bit small, but I say hey, I have Cora version 1. I want to upgrade people to version 2. And come up with oh, no, actually, this is look at all my open tickets. Tell me what to do next. It's a great command. It will just go through all your issues. And you can link linear open source issues on GitHub,

11:15

Slack intercom. What it will do is it will generate structure from all this mess, and we'll make arguments about what is good to work on versus not good to work on. And the cool part is it will reason about this. And the output here is a clean HTML page that you can share with the team that you can be inspired by. So this is generation of IDs. And the cool part is you can point it to your OKRs. You can get ideation aligned to your strategy. And that's kind of how it compounds. So if you have past experiments or past learnings in your repository or a strategy document, which you can create with CE strategy,

11:57

it will score these IDs against this knowledge already, which is really cool. And I've seen people dump this document inside cloud design and say create a PowerPoint. And you get a beautifully designed PowerPoint with like XY matrix of where the sweet spot is for what to do for your OKRs, which is very little effort for you and very impressive to bring to your team. Next one is a very simple one. It's called CE doc review, but it's very useful. If someone hands you a PRD or some kind of document, run doc review on it, and it comes back with very sharp questions. I always like the questions. I'm like,

12:42

you know, you can't do that. So either you relay this to your colleague or you ask them to answer. You can then compound that knowledge after answering with CE compound so that the next time this answer is already baked in and it wouldn't ask you. It would already know the answer because it's already embedded in the system. You can share this with people. You can say, oh, you can actually run this yourself as well. This runs anywhere, so you can do it in co-work as well. It doesn't need to be in cloud code. It's a very simple thing that we spend a lot of effort in to make very good, and it's part of our flow.

13:20

This is my most used one. It's when the ID is too big to describe. So this was the example of Cora version 1 to version 2. I say, C brainstorm. This is a brain on command. I know I need to get into the zone. I block off time. I'm not going to multitask or anything like that. And I run this. So it pulls in compound knowledge. It looks at the difference between Cora 1 and 2 and it looks at the personas I've set up so it will see, hey, like certain people need certain things, and it will ask me questions. And it doesn't ask me a lot of questions. It's dialed in to ask you just the right amount of questions it needs to do the work.

14:06

It's very easy to get 30 questions and feel, wow, I did so much. But in the end, the goal is not to answer questions. In the end, it's to get the absolute best work out of it. And I think other libraries might over question. I think there's a balance to be found there. So out comes a plan, a brainstorm document stored and compounded. And then my favorite is just slash LFG, which is basically the loop, the automation loop.

14:36

And if you like vibe coding, slash LFG something is great as well. It will run for hours. It will do planning, work, review, testing, opens a PR, it will dog food, it will try and fix things. It will then do a before and after video screenshot in the pull request. Makes it super easy for you to then see what happens.

15:01

Last, if it comes back. So this is overnight, you can do parallel, there's polish. This is the brain on again. See polish, you give it the pull request. And what it will do is it will show you, so I like to run it in cursor. And on the left side, I like to run this and it will tell me, hey, this was introduced with this LFG flow. And on the right, it will show the product. This is important. Sometimes I don't even know what was built because I also have video recordings that I dump into LFG that it will then process and analyze and see what went wrong. So sometimes I don't even know what it was solving for.

15:40

So it's a good primer to know, okay, this is what we are, where we are, this is what it's solving, this is how I solved it, and you tell me, what do you think? And this is not QA, this is raising the bar. Like, it should work. If it doesn't work here, your LFG flow failed. But you can see here, like, this works only in this example, there is a mark of a logo mark twice, which is not technically wrong, but I don't want two marks on one page. So in this case, I can say, hey, there are marks, two marks here.

16:11

Can we just make sure we only ever have one? And run C compound. So it will extract that knowledge, make sure next time when I do design work, it's tagged correctly. It will find that file and know not to do that. So that's closing the loop. You merge it, and you learn something. So why does compound engineering resonate with people? I think it's not a very new concept. It's just something how we do software engineering. It's just now instead of working with teams, we use AI and we leverage that.

16:49

And AI is very good at specific things, especially with large amounts of knowledge and doing the right thing, especially with latest models. So if you want to do this yourself, if you don't want to use my plugin, make sure to extract. Never repeat. If you see yourself repeating yourself, make sure to extract it somehow, make sure it doesn't happen again. Make sure that there is a middle that can run without you that does the planning work in reviewing and it should be boring. It should just work.

17:18

You should not be needed. If you're still needed in the loop, spend time on the middle, do it manually, feel where it's off and like iterate until you can actually let it go. And if you are at a point where you just run something and it runs for three hours and it's always good, you know you're there. It's important to document the thinking, not the code. This is also very anti-developer-y. It's like, yeah, the documentation shouldn't mean the code and like the code is the artifact itself.

17:47

But I am of the opinion to generalize, you need reasoning behind why you did something. And all these traces, even though they're bad, could lead to things like, hey, something happened right at postmortem. What decision was made by whom or what agent that led to this, can we then turn that into a learning so we change that behavior for the next time. And I've seen it work very well, especially with postmortems. And again, every interaction, spend 50% of your time to make it better the next time. So make sure to build the system that will remember instead of was this good, make the system better and make the system know.

18:32

And I know it's hard. Like, it's just hard to do for myself. And we all know we need to do it. But it's kind of awkward. And it's like, eh, it works. It's great. Let's just move on. But it's very important. And you can see the system really go if you do that a lot. So the bet is implementation is only getting cheaper and judgment is not. And the future models and systems need to be set up so they have access to this judgment that we have, our taste, to have more leverage.

19:06

So that is the bottleneck. And remember brain at the ends. Really activate your brain. Make sure you really understand what you're doing in the start. Don't overload the thinking to the AI. Make sure you truly feel, understand what you're doing, the problem. And let the AI go. And at the end, raise the bar. Make sure you don't fix things. It should be very good at the end. But make sure to raise the bar because we're not shipping shitty code.

19:35

And your standard should be the next feature should be easier because you ship this one. If the next feature is harder because you added complexity, which is normally how engineering works, we're flipping that. The next feature should be easier to build because you ship this one. I'm Kieron. Check out the plug-in. It's open source. Please contribute. PRs welcome. I love PRs from everyone. Go build your orchestration system. Go build your personal knowledge base that compounds. And thank you. I'll be hanging around if you have questions. And enjoy the rest of your day.

20:35

I'll be right back.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note