Compound engineering is an AI-native approach to software development in which each unit of work makes future work easier. Instead of codebases growing more complex over time, systems accumulate reusable patterns, eliminate entire classes of bugs, and become easier to understand, modify, and trust. The result is that a single engineer, augmented by AI, can build and operate products that once required full teams. The concept is outlined by Kieran Klaassen, general manager of Cora, Every's email product. # Channel Presentation Observations: "Compound Engineering Explained" ## Intended Audience - **Software developers adapting to AI-assisted workflows.** The video walks through "beliefs to let go" like *"code must be written by hand"* and *"every line must be reviewed"* — framed as mindset shifts for engineers. - **Non-coders building software ("vibe coders") are explicitly addressed as a secondary audience:** *"what if you're not an engineer you can also use this plug-in and this philosophy just to make better code. Uh we have many people at every that use the compound engineering plug-in as non-coders."* - **Teams, not just solo builders:** a section covers *"Team collaboration... If you work in a team it's different than solo... there's some like etiquette."* - **Beginners asking how to start:** the creator states the guide was made because *"lots of people were asking still like hey what is this like how do I start."* ## Claimed Scope - The creator positions the channel/content around a named methodology — **"compound engineering"** — self-described as originating from their own work: *"compound engineering is something I started when I was building Kora which is uh email assistance using AI."* - Scope includes: - A **Claude plug-in** with claimed adoption: *"that plugin has now lots of tens of thousands of users."* - A **companion guide document** covering philosophy, plug-in commands, beliefs, and maturity stages: *"this is a very long document with just me throwing all my thoughts out."* - Adjacent topics: agent-native environments, planning ("plans are the new code"), user research, copywriting, product marketing, design/vibe coding. - Content is presented as **both human- and machine-readable**: *"it's made for humans and for machines so you can read it or uh you can just skip it... and dump it in somewhere and say hey can you help me understand this concept?"* ## Explicit Self-Description Evidence - **First-person originator claim:** *"I created a plug-in for it"* (referring to an Anthropic plug-in capability); *"it slowly started to grow and at some point we titled it compound engineering."* - **Personal experience as authority:** *"I had to relearn things every time. This is over the last three years for me."* - **Self-assessed maturity stage:** *"I'm like I'm doing stage five but I'm also doing stage three."* - **Opinionated philosophy framing:** *"we have to rethink what software development is"*; *"writing code is actually going to be shift[ed]... planning and brainstorming... is your job function now."* ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Tutorial/walkthrough format:** the video is structured as a live tour of a document, with the creator narrating sections in order ("So these are kind of stages... this is the last thing I'll do now"). - **Opinion-listicle structure:** clearly enumerated "beliefs to let go" (hand-written code, line-by-line review, first-attempt perfection, code as self-expression, typing equals learning) and "beliefs to adopt" (extract taste into the system, 50/50 rule, trust the process, agent-native environment, parallelization). - **Practical, prescriptive guidance with named heuristics:** e.g., the **50/50 rule** (*"50% of time should be worked on the actual feature and 50%... on making sure the meta layer is there"*) and an **80/20 planning rule**. - **Staged maturity model:** stages zero through five described for AI development adoption (manual → chat-based → agentic → plan-first PR review → idea-to-PR → fully parallel autonomous). - **Cross-promotion of ecosystem content:** references a plug-in, a guide URL, and external recommendations (*"There's a agent native guide uh from Dan as well. I highly recommend reading that one too"*; *"I wrote an article about [plans]"*). - **Iterative/work-in-progress framing:** acknowledges imperfection on screen — *"there's a bug here with the with this size. We we'll fix it"* — and open-endedness: *"I will be adding stuff to this guide."* ## Notable Distinctions - **Claims vs. demonstration:** plugin user counts ("tens of thousands") and the three-year experience are **creator claims**, unverifiable from this material alone; the pedagogical structure, philosophy content, and audience targeting are **directly demonstrated** by the transcript. - No channel name, upload metadata, or subscriber information is present in the source material; identity observations are limited to what this single video's title and transcript show. # Delivery Observations: "Compound Engineering Explained" ## Tone & Overall Style - **Conversational and low-formality**: The speaker uses casual fillers and hedges throughout — "uh," "um," "like," "yeah" appear constantly. > "So basically compound engineering is something I started when I was building Kora which is uh email assistance using AI" - **Self-positioned as a fellow learner, not an authority lecturing**: "I had to relearn things every time. This is over the last three years for me." - **Encouraging rather than prescriptive**: Suggestions are softened — "you can just also let go of that belief," "make sure to push yourself." ## Recurring Phrases & Verbal Habits - **"Let go"** as a recurring framing device for abandoning old beliefs: > "we have to let some things go like we have to rethink" / "just let it go. Like it's fine" / "you can just also let go of that belief" - **Repeated use of "like"** as a general connective, often in clusters: > "But like if you're in in like a team or like a larger code base" - **"So" as a paragraph opener** to introduce nearly every new topic: > "So basically compound engineering..." / "So these are some challenges..." / "So there's a rule about 80% planning..." - **Repetition for emphasis or self-repair**: "and it it's get better," "you you think this is," "in a in a in a bit." ## Teaching Structure & Habits - **Anchors the lesson in personal origin story first**, then pivots to a resource: > "I created a guide. So if you go to... you can see here this is a very long document with just me throwing all my thoughts out" - **List-driven teaching**: Heavy reliance on enumerated concepts ("beliefs to let go," "beliefs to adopt," "stages," "principles"), each introduced and briefly glossed. - **Cites external resources and other authors**: "There's a agent native guide uh from Dan as well. I highly recommend reading that one too." Also: "Plans are the new codes. Like really make sure your plan is really really good." - **Uses concrete examples to ground abstractions**: > "is it pure CSS is it till one is it shed CN is it reals is it type grid like whatever makes you happy" - **Acknowledges imperfection live** rather than editing around it: > "And so there's a bug here with the with this size. We we'll fix it." - **Explicitly scopes the ending and signals closure**: "Okay, so like I mean the stages it is the last thing I'll do now." ## Rhetorical Patterns - **Direct address to the viewer's anxieties**, naming fears then rebutting them: > "many people fear that if you don't type you don't learn. Uh I think understanding is probably better." - **Quoted inner-voice objections** used as a teaching device: > "like hey what is this like how do I start" / "hey I have an idea and it just runs all the way through" - **Punchy imperative-style maxims**: "Don't go don't fly blind. Don't merge without monitoring." ## Uncertainty Notes - Humor delivery is hard to assess from transcript alone; phrases like "So this is just me making the plug-in for example" may carry a joking tone but this is not directly verifiable. - The stages taxonomy (stage zero through five) is presented as personal observation, not a formal framework — the speaker hedges: "I think for me I'm like I'm doing stage five but I'm also doing stage three." # Observation Document: "Compound Engineering Explained" ## Overview - Single, unnamed speaker (creator of the guide/plugin) walks through a new article/guide on **compound engineering**, a workflow philosophy he developed while building **Kora**, an AI email assistant. - Named the approach "compound engineering" because of a **compounding loop**: every piece of work makes the next one easier; learnings accumulate inside the system. - He built a plugin when Anthropic released plugin support; it now has "tens of thousands of users." - Guide location stated as roughly "every.2guide/... compact engineering" (transcript garbled). ## Beliefs to Let Go (speaker's stated positions) - **"Code must be written by hand"** — no longer true; fine if AI writes it. - **"Every line must be reviewed"** — must be released. - **"Solutions must originate from the engineer."** - **"Code is the primary artifact"** — the focus shifts to the system that creates code. - **"Writing code is the core job function"** — planning and brainstorming are now the core job. - **"First attempt should be good"** — most attempts won't be correct first try. - **"Code is self-expression"** — acknowledged as partly true, but ego attachment to code should be released in team/large-codebase contexts; personal projects are fine. - **"More typing equals more learning"** — speaker notes some possible truth but argues **understanding** matters more; reading/reviewing more code lets you develop faster. He concedes this is "a little bit contradictory" and advises finding a balance. ## Beliefs to Adopt - **Extract your taste into the system** — encode preferences (e.g., pure CSS, Tailwind, shadcn, Radix, Typegrid) to enjoy the work. - **50/50 rule** — 50% of time on the feature, 50% on the meta layer so learnings compound. (Speaker also notes a separate rule: 80% planning / 20% building; he flags the guide as "a little bit confusing" on this.) - **Trust the process** — trust the AI, but build **safety nets**; don't merge without monitoring; trust builds gradually as things work and don't break. - **Agent-native environment** — everything you can do by clicking should have a CLI equivalent, with guards (e.g., no production database access). He recommends a separate **agent-native guide by Dan**. - **Parallelization** — lean into it. - **Plans are the new code** — brainstorm command first to understand intent, then a detailed technical plan; if both are good, the feature is normally good. ## Stages of AI Development (speaker's framework, last three years) - **Stage 0:** Manual. - **Stage 1:** Chat-based (ChatGPT copy-paste, Cursor command-K). - **Stage 2:** Agentic — Cursor Composer as a precursor, Windsurf first truly agentic, then Claude Code "started the agentic wave." - **Stage 3:** Plan-first, PR-only review — plan, compare plan vs. PR, learn from differences, compound. - **Stage 4:** Idea-to-PR — via the **SLFG command**; "it's a machine." - **Stage 5:** Parallel, off your machine — monitors pick up bugs and the system runs end-to-end without you. - **Position:** Speaker says he's doing stage five but also stage three — movement between stages is normal. He recommends **stages 3–5 as a target** and urges pushing to reach stage 3. ## Additional Guide Contents Mentioned - Agent-native architecture; **skip permissions**; design guidance. - **Vibe coding as a best practice** — non-engineers at "every" use the plugin successfully. - **Team collaboration** — different from solo; etiquette and communication guidance. - **User research** before brainstorming; **data patterns** (extracting from support docs); copywriting and product marketing sections. - Guide is "made for humans and for machines" — readable directly or fed to an agent; speaker plans to keep adding to it. ## Qualifications and Tensions Preserved - Speaker contradicts/qualifies himself on typing vs. learning ("you need to like learn as well. So find a balance"). - Acknowledges confusion in the guide between the 50/50 rule and the 80/20 planning rule. - Notes a **bug in document sizing** to be fixed. - Stage positions are not fixed — "it's not like you're here or there." # Speaker Attribution & Provenance Record ## Video - **Title:** Compound Engineering Explained - **Video ID:** `01a0f15a-ad47-7186-aa84-1808d4dea2e0` - **Metadata:** No curated metadata supplied; speaker identity inferred only from transcript self-statements. ## Speakers & Roles ### Primary (sole) Speaker - **Role:** Creator / presenter - **Evidence:** Opens with "Hello everyone. This is a new article and guide. So I want to walk you through it" and speaks continuously in first person throughout. - **Self-identified context (creator's own claims, unverified):** - Founder/practitioner of **compound engineering**, a methodology they say they developed while building **Kora**, described as "email assistance using AI." - Creator of a **plug-in** (built after "Anthropic released a way to create a plug-in") claimed to have "tens of thousands of users." - Author of the referenced guide document. - **No other speakers, guests, or narrators appear.** ## Referenced Sources & Third-Party Claims - **Anthropic** — referenced as having released a plug-in capability; the creator built a plug-in for it. - **Claude / "cloud code"** — mentioned as tools/platforms in the workflow ("you can read it with cla", "cloud code... started the agentic wave" — transcript is garbled here; exact referent uncertain). - **Dan** — mentioned by first name only: "There's an agent native guide from Dan as well. I highly recommend reading that one too." No further identification given. - **Tools/platforms named:** ChatGPT, Cursor (command K, Composer), Windsurf ("first to being agentic" — speaker's claim). - **Guide URL:** Mentioned but garbled in transcript ("every.2guide/compateng to SLGUI/CM compact engineering") — cannot be reconstructed reliably. ## Promotional Segments - **Guide promotion:** The video explicitly promotes the creator's own guide document and plug-in ("I created a guide... you can check the plug-in as well"), including instructions on how to use it. - **Plug-in adoption claim:** Promotion includes the "tens of thousands of users" figure (speaker's own unverified claim). ## Comment Availability - **Not stated** in transcript or metadata — unknown. ## Uncertainty Notes - Speaker name is not given anywhere in the source; identity is unknown. - Several tool names and the guide URL are phonetically garbled in the transcript (e.g., "till one," "shed CN," "reals," "type grid," "claw"); interpretations like Tailwind, shadcn, Vercel, Claude are plausible but **not explicit in the source** and are not asserted here. - Historical claims about tools (e.g., Windsurf being "first agentic") are the speaker's assertions, not verified facts. Hello everyone. This is a new article and guide. So I want to walk you through it a little bit and uh yeah see see what this is about. So basically compound engineering is something I started when I was building Kora which is uh email assistance using AI and I just figured out ways to build with AI that were working better for me with uh with prompts and flows and sub agents and it slowly started to grow and at some point we titled it compound engineering because of a loop. Um, it has where every piece of work you do makes the next one easier and you kind of uh compound uh the learnings inside the system itself. And whenever Anthropic released a way to create a plug-in, I created a plug-in for it. And that plugin has now lots of tens of thousands of users, which is really amazing. But lots of people were asking still like hey what is this like how do I start like all these questions and um I created a guide. So if you go to every.2guide/compateng to SLGUI/CM compact engineering. You can see here this is a very long document with just me throwing all my thoughts out and uh you can read it with cla you can copy it for your agent. You can uh check the the plug-in as well. And this is this is meant for you to uh yeah like really see if you have questions like hey how do I start or what what is this? What is the philosophy? And it goes over uh like how the philosophy of the plug-in is how the philosophy of the compound engineering is. It goes over the commands of the plug-in, but also it goes a little bit um yeah, it goes through beliefs and things because we have to rethink what software development is. And so there's a bug here with the with this size. We we'll fix it. Um yeah, we have to let some things go like we have to rethink. And I I've gone through different stages here and the stages are also named here um in a in a in a bit. But I want to go through these a little because these are kind of important like apart from the uh the plug-in itself. I think if you just use the plug-in without understanding why or what you're doing, it's kind of hard. So things beliefs to let go is the code must be written by hand. like that's just it's not true anymore. Like sure you can, but uh like just let it go. Like it's fine if the AI writes it. Uh the second is every line must be reviewed. That's also something you need to let go. If you still think I need to review every line, read this here and see how you can move towards uh not uh thinking like that. Solutions must originate from the engineer. Um that's also something like the the idea like I I need to be the one that comes up with how it goes. Uh code is the primary artifact. Um and yeah like it it's it's not about the code only. It's about like the system how you create a code more and more. uh writing code is the core job function and actually planning is way more important like you planning and brainstorming I think is more important that is your job function now writing the code is actually going to be shift so uh that's one first attempt should be good is also not true like if you let the AI do something and you you think this is well what you do correct in the first try maybe if you're very very good and all of that but like most uh won't do that in one try. Uh code is selfexpression. I mean it is but also if if your identity comes from the code you write is really hard to let go of the other things. Um and like code was always part of a bigger thing. Yeah, sure. Your personal projects, go write your code. But like if you're in in like a team or like a larger code base, um you can just also let go of that belief that it's your ego uh connected to the code because if you don't write it uh I mean it's it's not you and your ego might feel hurt. Uh more typing equals more learning. Uh I mean maybe there's some truth to it but many people fear that if you don't type you don't learn. Uh I think understanding is probably better. So if you understand the code um sure you can you can still uh write but if you look through and see more code you can develop faster because you you just do more. So if you type you can do less and you can do more if you uh yeah if you if you uh spend more time understanding and looking at uh not every line of code it's a little bit contradictory but you you need to like learn as well. So find a balance. So these are some challenges um beliefs to adopt uh extracting your taste into the system which is like the compound loop. So it's like making sure that uh whatever you feel is what you want to build what what makes you happy uh like things like that like what gives you energy uh is it pure CSS is it till one is it shed CN is it reals is it type grid like whatever makes you happy like it doesn't really matter anymore what you use so like what are your uh tastes and use use that especially just to feel happy because you like it. Okay. Uh 50/50 rule. Um yeah. So there's like uh like plan. So there it's a little bit confusing here. There are two rules but like there is a rule about 80% planning 20% building. I think there's another rule 50/50 rule which is 50% of time should be worked on the actual feature and 50% of the time should be worked on making sure the meta layer is there. So you compound the learnings and the next time uh it it's get better. So this is like the invest in the system while building uh as well. This is just me making the plug-in for example. Um, trust the process. This is a little bit like you just need to trust that the the AI will do the right thing and if it doesn't, you build safety nets. Just make sure to build more safety nets. Don't go don't fly blind. Don't merge without monitoring. But uh just trust that if you went through the review and and this can take some time uh like to really start building that trust. But like if you start seeing things that work and don't break that you slowly start to build trust and keep building that that's good. Uh making your environment agent native. So uh like if you uh deploy something and you need to click a button somewhere, make sure that there's a CLI that can do that as well. So like your claw should be able to do exactly the same as you obviously make sure that you cannot run like connect to production database things uh like mess things up but like it should do most things. So for example if you have a customer support uh place or need to debug things like just those things it should be doing for you and make sure it's it's set up. There's a agent native guide uh from Dan as well. I highly recommend reading that one too. Parallelization, lean into it. Uh plans, I wrote an article about that. Plans are the new codes. Like really make sure your plan is really really good. There's a brainstorm command to even understand what you want to build. Then the plan is to create a more uh like detailed more technical version of that. If those are good, normally the feature will be very good. Um, some principles. Okay, so like I mean the stages it is the last thing I'll do now. This is interesting. So these are kind of stages you go through when doing AI development and you're somewhere in these stages and I'll give you a little bit overview. I had to relearn things every time. This is over the last three years for me. But like stage zero manual, stage one chat based with with like chat GPT copy pasting or cursor with command K agentic. So this came last year I think maybe cursor composer. It wasn't really agentic but it started there and then uh wind surf started as the first to being agentic and then obviously cloud code came um and started the agentic wave um then it's the plan first uh PR only review which means letting go and trusting the system more where uh there's the realization of like hey like why are we just like yoloing things why don't we just plan and lean into what we always did as a software developer. So making sure that you really spend time on planning and then seeing what the plan versus the PR is and then learning from the differences and making sure to compound and and and see what can be learned for the next time when you do the plan what what was missed. Um then there's ID to PR which is just like hey I have an idea and it just runs all the way through and there's the SLFG command uh in compound engineering. This is like I have an idea run it all the way through and all the systems are set up and learned and injected like it's it's a it's a machine. So stage three you need to get right. If that works and you see everything works, you can let it loose even more. You can say, "Yeah, just do the whole thing." And then the next stage is doing that in parallel and not on your own machine. So if a bug comes in or like if something happens or if a monitor catches something, it will just be picked up uh and it will just go through and does the whole thing uh without you even doing anything. And that's the last I I think for me I'm like I'm doing stage five but I'm also doing stage three. So it's not like you're here or there like for certain things you can you can go back and forth. So I think stage three, four, five is a good aim to be at. If you are not at stage three, make sure to push yourself and you can see how to level up. So here I saw what to do if you want to go from one to the other and what is the compounding move here. Um there's some more things there's some agent native architecture uh section here a little bit about skip permissions which is good a little bit about what to do for design which is also vi coding like what if you're not an engineer you can also use this plug-in and this philosophy just to make better code. Uh we have many people at every that use the compound engineering plug-in as non-coders and just say well it's just easier or like catches things better. So V coding is a is a best practice. Team collaboration there's like a shift. If you work in a team it's different than solo. So there's some like etiquette and like what should you do, how should you communicate. Um there's some user research. So what if you are before even brainstorming? What if you're talking to users like how can you structure that how can that work uh data pattern so like extracting things from like support docs uh some about copywriting product marketing and yeah that's that's all for now I will be adding stuff to this guide um you don't need to read this all it's made for humans and for machines so you can read it or uh you can uh just skip it but the yeah you can hear read and dump it in somewhere and say hey can you help me understand this concept? Um yeah enjoy um hopefully you like it.