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

AI Engineer · 20 min · 227 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:13Hello.
  3. 00:14Hello everyone.
  4. 00:18Welcome.
  5. 00:22I want to start with saying I haven't written a single line of code this year.
  6. 00:28Um, maybe I haven't even looked at most of it yet.
  7. 00:34I do ship.
  8. 00:35Uh, I have a product I built that thousands of people use and trust with their email inbox, which is amazing.
  9. 00:44I'm actually proud of the code I ship and I'm proud of the product I ship.
  10. 00:51I've been doing this for two years and trying to extract my thinking and my taste into a system that compounds.
  11. 00:59And I'm going to share you how I do that.
  12. 01:02Lots of stuff you hear is like, "Oh, you should use this the factory dark factory do that blah blah blah all the new hip cool things."
  13. 01:11Uh, what I'm trying to do is not that today.
  14. 01:14I'm going to just show you how I work and hopefully share something that you can bring to your workflow that will outlift trends and really set yourself up for success for newer models, bigger models.
  15. 01:29Uh there are two halves in this talk.
  16. 01:31One is why it's so important to compound how I got here.
  17. 01:37So this is for people that maybe are not at the end of the the trajectory.
  18. 01:42It's interesting to see how to get there.
  19. 01:44And then stuff you can run yourself, you can use uh day-to-day to ship, to build, uh to research, to do knowledge work even.
  20. 01:55Hello, I'm Kiran.
  21. 01:57I work at every is an AI lab for the future of work.
  22. 02:01And we ask ourselves the question, what's next?
  23. 02:05And we write about it, we teach about it, we build.
  24. 02:10And we have a studio se uh studio um where we have mostly single engineering teams that take a problem they really care about and use AI to build a product out and really leverage that and
  25. 02:25compounded knowledge is a big way we do that lots of loops shipping faster and faster and core as mine is where I invented compound engineering and it's a complete AI email inbox
  26. 02:39it's agent native.
  27. 02:40So that means whatever you can do the agent can do.
  28. 02:44H it runs on your desktop phone CLI insight codeex like uh MCPS and I'm rebuilding it as version two.
  29. 02:53Uh so soon beta access if you want access just DM me talk to me.
  30. 03:00The cool part is it's one engineer and I have support.
  31. 03:04I have design support.
  32. 03:06I have some like database hardcore engineering problem support like you need some support.
  33. 03:13Um but I built a full email client alone and I've only started building this in January this new rebuild.
  34. 03:23I use reals on the back end.
  35. 03:24I love Ruby React on the front end and I own products fully.
  36. 03:30So I talk to people when something goes down I'm the one responsible and it's set up like this on purpose.
  37. 03:39I'm an ex VPB of engineer and founder and I know how to hire grow teams all that stuff.
  38. 03:44But I wanted to do the opposite with sonnet 3.5. I just felt there was something new that was unlocked and I wanted to see how far can AI go before I actually need to grow the team.
  39. 03:57And I'm still alone with some support which is cool.
  40. 04:00So I built Kora and this is what I learned.
  41. 04:05Two years ago I started and the bottleneck by then was code.
  42. 04:09So it kept moving and my job changed over the years but first there was bad code hallucination just stuff that didn't work.
  43. 04:17I added agents I added skills just reviewing it.
  44. 04:21So okay code got good.
  45. 04:24The plan was the bottleneck because I could do things but larger things.
  46. 04:30So whenever I have a good plan set out, it would do bigger things than just code changes.
  47. 04:38Okay, plans got good.
  48. 04:39Um the next bottleneck was deciding what to build.
  49. 04:44Talking with users, really understanding problems you're solving.
  50. 04:48This is why it's so good that you use your own product.
  51. 04:51You love what you're building for.
  52. 04:54And that got really good as well.
  53. 04:58The scope got bigger.
  54. 05:00AI could help writing uh plans.
  55. 05:03And I kept repeating myself and that was annoying.
  56. 05:06So I figured out there needs to be some kind of memory system.
  57. 05:10So every time um I repeat myself, I can say, "Hey, can you make sure to store this knowledge in some way?"
  58. 05:17I started with storing this in cloth MD, but at some point that became too large.
  59. 05:22Um, so I built a system that remembers and that's really where compound engineering came from and you see me go away from typing more towards judgment and taste and
  60. 05:36I think implementation is mostly solved even though you see many people that do orchestration dark factories who it kind of works which is cool but the thing that doesn't work is
  61. 05:49our judgment and our taste.
  62. 05:52And 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 it's where you add taste.
  63. 06:05So 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
  64. 06:24so 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.
  65. 06:38This is my loop.
  66. 06:39It's it there's more to it than this, but this is the overview.
  67. 06:44Brainstorming, planning, working, reviewing, polishing, compounding, and repeating.
  68. 06:51And the real trick here is on both ends.
  69. 06:53It's kind of the human AI sandwich where the human is the bread and the AI is the middle part.
  70. 07:00And the brain is on on the ends.
  71. 07:02So 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
  72. 07:14this 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
  73. 07:24like delight and throughout here especially in the brain on parts it's important to extract the learnings to compound.
  74. 07:34So that's basically the loop.
  75. 07:37You cannot run the middle if it's not set up correctly.
  76. 07:41And it's very important to be able to let go and let the machine rip overnight for many hours in parallel.
  77. 07:52And the only way to be able to do that is making sure you spend time on uh on that system.
  78. 07:58So my rules 50% should go into creating uh the feature just making sure like did it build the feature?
  79. 08:06Did it deliver the value you set out to do?
  80. 08:09But 50% of the time should go to um teaching the system for anything that it did wrong.
  81. 08:15Can we learn something?
  82. 08:16Can you teach the system something?
  83. 08:18And this is something that is kind of hard, but it's very important because it will make the next time better.
  84. 08:27One bonus is because of this extraction um 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
  85. 08:49you 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.
  86. 08:59Less research, finding things faster.
  87. 09:03The real reason why this works is my brain is fixed and AI isn't or less fixed.
  88. 09:11And my philosophy is keep extracting until the complete middle runs itself and is so freaking good that it will surprise you.
  89. 09:23Um let me show you how this works.
  90. 09:26Uh so I have a plugin called the compound engineering plugin that you can install in whatever tool you use codeexcloud code cursor plus 10 others and I just built this while building Kora shared it at some point and now
  91. 09:42hundreds of thousands of people use it daily.
  92. 09:44So thank you all for using it if you did.
  93. 09:46I'm honored.
  94. 09:47Um, I never decided this should be something like hype.
  95. 09:52It's just me using my plug-in shipping code.
  96. 09:55Uh, you can install it wherever.
  97. 09:57Uh, you can also create your own version of this, which could be just storing information in files.
  98. 10:03Uh, however you do it.
  99. 10:05But let me show you the plug-in.
  100. 10:06So, compound engineering became compound product as well.
  101. 10:12Uh I have a lovely uh co-contributor Trevan Chowo who has a very good product sense and product background.
  102. 10:20So 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 to use compound engineering.
  103. 10:32It's such a uh like universal uh concept of compounding knowledge.
  104. 10:37It doesn't have to be used for engineers but that's where it came from me.
  105. 10:41So the first demo is um it's it's here to activate your brain.
  106. 10:48So this is called CE ID8 and you can run it.
  107. 10:51And here I run it in it's maybe a little bit small but I say hey I have Kora version version one.
  108. 10:57I want to upgrade people to version two.
  109. 11:00Um come up with oh no actually this is look at all my open open tickets.
  110. 11:06Tell me what to do next.
  111. 11:07It's a great command.
  112. 11:08It will just go through all your issues and you can link linear open like open source issues on GitHub, Slack, intercom.
  113. 11:16What it will do is it will generate uh structure from all this mess and we'll make arguments about what is good to work on versus not good to work on.
  114. 11:27And 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.
  115. 11:36So this is generation of ids and the cool part is you can point it to your OKRs you can um get ideiation aligned to your strategy and that's kind of how it compounds.
  116. 11:48So 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 ids against this knowledge already which is really cool.
  117. 12:02And I've seen people dump this uh document inside cloth 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 low effort for you and very impressive to bring to your team.
  118. 12:23Uh next one is a very simple one.
  119. 12:26It's called C do review but is very useful.
  120. 12:29Um, if someone hands you a PRD or some kind of document, run dock review on it and it comes back with very sharp questions.
  121. 12:38I always like the questions.
  122. 12:39I'm like, "Oh, that's a good question.
  123. 12:41I did not think about it."
  124. 12:42So, either you relay this to your colleague or you ask them to answer.
  125. 12:48You can then compound that knowledge after answering with C compound so that the next time um 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.
  126. 13:02You can share this with people.
  127. 13:04You can say oh you can actually run this yourself as well.
  128. 13:07This runs anywhere.
  129. 13:09So you can do it in co-work as well.
  130. 13:10It doesn't need to be in cloth code.
  131. 13:12Um 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.
  132. 13:20This my most used one u it's when the ID is too big to describe.
  133. 13:25So this was the example of Kora version one to version two.
  134. 13:29I say c brainstorm.
  135. 13:31This is a brain on command.
  136. 13:33Uh I know I need to get into into the zone.
  137. 13:36I block off time.
  138. 13:38I'm not going to multitask or anything like that.
  139. 13:41Um, and I run this.
  140. 13:43So, it pulls in compound knowledge.
  141. 13:44It looks at the difference between Kora one and two and, uh, looks at the personas I've set up.
  142. 13:51So, it will see, hey, like certain people need certain things.
  143. 13:55And it will ask me questions.
  144. 13:57And it doesn't ask me a lot of questions.
  145. 14:00It's dialed in to ask you just the right amount of questions it needs to do the work.
  146. 14:06It's very easy to get 30 questions and feel, "Wow, I did so much."
  147. 14:10But in the end, the goal is not to answer questions.
  148. 14:13In the end, it's to get the absolute best work out of it.
  149. 14:17And I think other libraries might over question.
  150. 14:21H I think there's a balance uh to be found there.
  151. 14:24So out comes a plan, a brainstorm document stored and compounded.
  152. 14:29And then my favorite, which is SL LFG, which is basically the loop, the the automation loop.
  153. 14:37And if you like vibe coding/ LFG something is great as well.
  154. 14:42It will run for hours.
  155. 14:44It will do planning work review testing.
  156. 14:47Opens a PR.
  157. 14:48It will dog food.
  158. 14:48It will try fix fix things.
  159. 14:50It will then do a before and after video screenshot in the pull request.
  160. 14:55Makes it super easy for you to then see what happens last if it comes back.
  161. 15:03So this is overnight.
  162. 15:04You can do parallel.
  163. 15:05There's polish.
  164. 15:06This is the brain on again C polish.
  165. 15:09You give it the pull request and what it will do is it will show you.
  166. 15:12So 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.
  167. 15:24This is important.
  168. 15:25Sometimes 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.
  169. 15:37So sometimes I don't even know what it was solving for.
  170. 15:41So it's a good primer to know, okay, this is what we are here where we are.
  171. 15:45This is what it's solving.
  172. 15:46This is how I solved it.
  173. 15:47And you tell me what do you think?
  174. 15:50And this is not QA.
  175. 15:51This is raising the bar like it should work.
  176. 15:54If it doesn't work here, your LFG flow failed.
  177. 15:57Um, 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.
  178. 16:08So in this case I can say hey there are marks two marks here.
  179. 16:11Can we just make sure we only ever have one and run C compound.
  180. 16:16So it will extract that knowledge, make sure next time when I do design work, it's tagged correctly, it will find that file and uh know not to do that.
  181. 16:27So that's closing the loop.
  182. 16:29You merge it and you learn something.
  183. 16:34So why does compound engineering resonate with people?
  184. 16:38I think it's not a very new concept.
  185. 16:41It's just something how we do software engineering.
  186. 16:44is just now instead of working with teams we use with AI 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 latest models so
  187. 16:57uh if you want to do this yourself if you don't want to use my plug-in uh 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
  188. 17:11make sure that there is a middle that can run without you that does the planning, working, reviewing, and it should be boring.
  189. 17:16It should just work.
  190. 17:18Uh you should not be needed if you're still needed in the loop.
  191. 17:22Spend time on the middle.
  192. 17:23Do it manually.
  193. 17:25Feel where it's off and like iterate until you can actually let it go.
  194. 17:29And if if you are at a point where you just run something and runs for three hours and it's always good, you know you're there.
  195. 17:36[sighs]
  196. 17:37It's important to document the thinking, not the code.
  197. 17:39This is also very anti- um developery.
  198. 17:43It's like yeah but documentation shouldn't mean the code and like the code is the artifact itself but I am of the opinion to generalize you need reasoning behind why you did something
  199. 17:54and 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
  200. 18:14uh especially with postmortems and again every interaction spend 50% of your time to make it better the next time.
  201. 18:24So, make sure to build the system that will remember uh instead of was this good, make the system better and make the system know.
  202. 18:32And 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 h it's it works.
  203. 18:41It's great.
  204. 18:42Let's just move on.
  205. 18:43But it's very important and you can see the system really go if you do that a lot.
  206. 18:50So 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
  207. 19:05uh to have more leverage.
  208. 19:07So 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.
  209. 19:17Don't offload the thinking to the AI.
  210. 19:19Make sure you truly feel understand what you're doing, the problem.
  211. 19:23H let the AI go and at the end raise the bar.
  212. 19:27Make sure you don't fix things.
  213. 19:29It should be very good at the end, but make sure to raise the bar because we're not shipping shitty code.
  214. 19:36And your standard should be the next feature should be easier because you ship this one.
  215. 19:41If the next feature is harder because you added complexity, which is normally how engineering works, we're flipping that.
  216. 19:48The next feature should be easier to build because you ship this one.
  217. 19:53I'm Kiran.
  218. 19:54Uh, check out the plugin.
  219. 19:56It's open source.
  220. 19:57Please um, contribute.
  221. 20:00PR is welcome.
  222. 20:00I love PRs from everyone.
  223. 20:03Go build your orchestration system.
  224. 20:06Go build your personal uh, knowledge base that compounds.
  225. 20:10And thank you.
  226. 20:11I'll be hanging around if you have questions and enjoy the rest of your day.
  227. 20:16[applause]