A live Q&A in which Kieran Klaassen answers audience questions about Compound Engineering, a plug-in that changes how developers build and use AI to code, following an Every-hosted camp. Questions he couldn't answer during the camp are addressed here. # Channel Identity Observations: Q&A Livestream on Compound Engineering ## 1. Explicit Self-Description Evidence ### Organizational Affiliation - The host identifies the channel's parent organization directly: > "I am Austin. I drive growth at Every." > "Every is the only subscription you need to stay up to date on AI. Just go to every.to and check out the latest ideas, apps, and training that we've got for you." - The channel is presented as a distribution arm of **Every**: > "we'll put this video up on our YouTube and X so anyone who missed it can watch it." ### Claimed Content Scope - The closing CTA claims coverage of **AI ideas, apps, and training**: > "the latest ideas, apps, and training that we've got for you" - Reference to a preceding live event demonstrates a **bootcamp/training format**: > "On Friday we had a great bootcamp with Compound engineering, where Kieran showed everyone how the plugin he created works." ### Featured People and Products - **Kieran (Kiran)**: "the General Manager of Kora at Every and the creator of the Compound Engineering plugin." - **Kora**: described as "an AI assistant for email" with an "iOS version coming soon." - The video functions partly as a **product/creator showcase** for Kieran and his ecosystem ("follow Kieran on X. He's posting more content on Every"). ## 2. Intended Audience (Observed) - **Practitioners of AI-assisted coding**, spanning beginners to professionals: > "This is a good guide, whether you are a beginner or an experienced engineer." - **Community members who attended or missed the bootcamp** — the video is explicitly a follow-up artifact: > "We received a bunch of questions that we didn't have time to answer during the camp, so we've collected them here." - **Non-technical knowledge workers**: Austin repeatedly frames his own perspective as "a technical novice" and "someone with a non-technical background," and discusses adapting workflows "for intellectual work." - **Engineers using Claude Code / Codex** specifically — questions revolve around these tools, token plans ("if you have a $20 plan... if you're a professional, you have a $200 plan"), and GitHub workflows. ## 3. Claimed vs. Demonstrated Scope ### Claimed - Channel covers AI broadly ("ideas, apps, and training") — a broad editorial scope. ### Demonstrated - This video demonstrates: **deep-dive Q&A on one specific tool** (the Compound Engineering plugin), including live screen shares of GitHub repos, plugin setup commands (`/setup`, `/LFG`), and workflow walkthroughs. - The format demonstrated is a **two-host conversational Q&A with audience-submitted questions**: > "I'll put them to Kiran live. I'll ask follow-up questions." - Audience questions are cited by name ("Someone named Noah asked...", "There's one question from Swissy"), showing an **interactive community** (Discord mentioned: "I released it to our Discord"). ## 4. Observable Presentation Patterns - **Educational, product-adjacent tone**: step-by-step guidance ("there are three levels of planning... you choose the level of implementation detail") mixed with product promotion. - **Community-driven content pipeline**: bootcamp → unanswered questions → this video, indicating an events-plus-followup content strategy. - **Tactical, practitioner-level depth**: discussion of specific commands, PRs ("There is an open pull request... number 885"), pricing tiers, and tool integrations (Linear, Cursor, GitLab, Vercel Agent Browser CLI). - **Cross-promotion habit**: pushes every.to, X follows, and internal products (Kora, Proof, Spiral) within the content itself. ## 5. Notes on Distinguishing Claims from Demonstration - No explicit channel-wide mission statement beyond the closing Every CTA; scope evidence is largely **inferred from demonstrated format** (one tool deep-dive) plus the **explicit** closing self-description. - Creator motivations are not asserted beyond stated intent ("we've collected them here... so anyone who missed it can watch it"). # Delivery Observation: *Compound Engineering: Your Questions Answered Live* ## Format & Structure - **Two-speaker Q&A format**: Austin hosts and relays audience questions; Kieran (Kiran) answers at length. - > "We received a bunch of questions that we didn't have time to answer during the camp, so we've collected them here. I'll put them to Kiran live. I'll ask follow-up questions..." - **Live product walkthroughs**: Kieran repeatedly shifts from talk to screen share mid-answer. - > "Let me show you how it looks for Kora... So, open GitHub. Code." - > "We are here in Corora. Let's move on here." / "I'll show you my screen." ## Tone & Register - **Conversational, unpolished, enthusiastic**: frequent fillers ("uh," "um," "yeah," "yes"), false starts, and self-corrections, especially during demos. - > "uh, I'm looking for, uh, for, uh, for agent search, and I also have, uh, metadata..." - **Casual, humorous framing** of advanced automation: the recurring "/LFG" command discussed as a "fun" shortcut. - > "It will write the code for you and give you the result. So it's just a fun way to say, 'Hey, if you have tokens left for the day and have some interesting idea—just try it.'" ## Vocabulary & Recurring Phrases - **Repeated core terminology**: "brainstorm(ing)," "planning," "review," "accumulation," "context," "agents," "skills," "knowledge base," "session." - **Habitual first-person origin narrative**: Kieran frames features as personal discoveries. - > "I just found ways to use AI that worked better for me..." - > "So I had an idea: why not put it in files, because files are great for storing information." - **Direct-speech reenactment**: both speakers habitually act out dialogues with the AI using quotes. - > "You say, 'Hey, can you use a different style, I like it better.'" - > "Tell her what I say all the time. 'Treat me like I'm stupid.'" - **"Hey" as a default opener** when mimicking prompts to the AI (appears dozens of times: "Hey, can you...", "Hey, this is..."). ## Teaching Habits - **Advice delivered as progressive onboarding**: repeated step-by-step "start small" guidance. - > "Just try using it. See how it works." - > "Start with a project that you're not afraid to 'screw up' at all, and then go for it." - **Reassurance against rigidity**: a recurring message that the system is customizable, not fixed. - > "There is no one way to use it, and I think that is a strength." - **Personal anecdotes as teaching tools**: the musician/VST plugins story and the 3D printing example. - > "For example, I'm a musician, and I thought: why not create a bunch of weird VST reverb plugins..." - **Explicit hedging / epistemic honesty**: Kieran flags the limits of his knowledge. - > "I don't have real answers to all these questions... We're still thinking, 'Is this the best way to do it?' Maybe not. Maybe so. I don't know." ## Interaction Patterns - **Mutual validation loop**: frequent short affirmations ("Yes," "Exactly," "Yes, I agree 100%," "That's right"). - **Host adds complementary perspective**: Austin regularly bridges engineering to non-technical/knowledge work. - > "I think from a technical novice's perspective, I find it extremely helpful to just trust the plugin and then watch what happens as a way of learning." - **Reverse questioning**: near the end, roles flip—Austin shares his own plugin-building workflow and Kieran responds ("You know, I do the same thing"). ## Notable One-Offs (Uncertain as Patterns) - The interruption about **quantum mechanics** ("Someone asked if quantum mechanics is also part of complex engineering. Yes, it is.") appears once; unclear whether deadpan humor or transcription noise. - The **Discord bot failure story** (Austin) is a single extended anecdote; its self-deprecating style ("I was a little cocky") may reflect his general manner but has insufficient repetition to confirm. ## Uncertainty Notes - Transcript appears to be an auto-translation (e.g., "cloth MD" for "Claude.md," "Kiran/Kieran" inconsistency, "Corora"); some delivery nuance (filler frequency, exact phrasing) may be artifacts rather than observable speech. - Attribution of some mid-transcript lines is ambiguous where speaker turns aren't clearly marked. # Position Record: Compound Engineering Q&A Live ## Speakers - **Kieran (Kiran)** — General Manager of Kora at Every; creator of the Compound Engineering plugin. - **Austin** — drives growth at Every; host/asker of audience questions. ## Context Follow-up Q&A after a Friday bootcamp on the Compound Engineering plugin. Questions were collected from bootcamp attendees (e.g., Noah, Swissy). --- ## Kieran's Positions ### On the plugin's origin and nature - Compound Engineering emerged from building **Kora** (an AI email assistant); it was a personal productivity approach turned into a systematic plugin. - Core cycle: **planning → doing work → reviewing**, with "Compound flow" capturing and codifying learnings at any point. - Claims it is **more than a plugin** — "a new way of working," possibly "the future of how we work." - Used by "tens of thousands of people." ### On common mistakes users make - People assume his setup is **the only way** to use it, or that it can't be customized ("Yeah, but it's not mine" regarding the verification agent). - It is customizable: `/setup`, custom knowledge base, skills, coding standards. - Token cost caveat: on a **$20 plan** it may not be the best plugin (token-heavy); on a **$200 professional plan** he sees no reason not to use it, even for small tasks. - Value claim: even small tasks pay dividends via accumulated learning and resurfaced old-code knowledge. ### On accumulation of knowledge (his central method) - **Knowledge accumulation is the hardest part** for everyone — not just his view. - Previously stored everything in a long **Claude.md**, which became unmanageable and polluted context. - Solution: document everything in **Markdown files in the repository**, searched by agents (Best Practices Explorer subagent) so it isn't loaded into prompts — saving context. - Qualifications he preserved: "we're still thinking, is this the best way to do it? Maybe not. Maybe so. I don't know." - Broader framing: analogous to OpenAI's "harness engineering" and contextual engineering. ### On planning depth and finality - **No fixed rule** — depends on the project and whether it's professional or for fun. - For entertainment projects, he sometimes doesn't read plans at all; for professional work he **always reviews** plans (saves time, enables learning). - Warns Claude "has a tendency to overdo it" (e.g., unnecessary backward compatibility, risk mitigation) — advises telling it to slow down. - For big tasks: **brainstorm first** (added by Trevan), then plan; several medium plans beat one giant plan, though he wants to "push the boundaries." ### On customization - `/setup` creates a `compound engineering local MD` file for custom agents/skills (review and work stages); without it, defaults are used. - Supports non-engineering uses: he uses it for writing; agents can be domain-agnostic (marketing, etc.). - Mentioned open PR **#885** (basic skill component) and upcoming harness-engineering-inspired features; also building an iOS app for Kora needing Swift-specific setup. - Austin's plugin work prompted Kieran's remark: he is "a little jealous" Austin can start from scratch. ### On learning fundamentals vs. learning while building - "It's always good to understand what you're doing, but it's not always fun." - Recommends the **brainstorming team** (more interactive), reading plans carefully, and "interviewing" the model — asking it to work step by step and explain why. - Advises explaining *why* ("do this because XYZ") to communicate at a higher level. - In professional settings, you should know when to intervene and ideally why things exist. - Not always using full flows: on entertainment projects he skips them to "feel the model" and check which plugin steps (e.g., simplification checker) may become unnecessary as models improve. ### On non-engineering uses - Music: brainstormed "weird VST reverb plugins." - 3D printing: Claude is "very good at creating STL files" for household objects. - Structured flow is slower but more thorough and higher quality. ### On team collaboration (answering Swissy's question) - Current weakness: committing to source code doesn't work for team feedback loops. - Working on **Proof** (by Dan) — Google Docs for AI/human co-writing — to be integrated for shareable plans with agent-visible comments. - Claims Amazon and Google teams use it, though he qualifies: his team is two people; large-team experience is **not his personal experience**. ### On incremental building and trust - Agrees with Austin: build/use one feature at a time, end to end, before adding more. - Frequent small releases are better — "basic principles of software development." - Notes it's easier to skip detail when you already know what quality work looks like. ### Favorite features - **Test browser**: end-to-end browser-based testing in QA-engineer style; uses Vercel Agent Browser CLI; possible because of Opus 4.6 ("wasn't possible before 4.5"). - **Video viewer**: records a video of changes attached to merge requests — useful for external repos. --- ## Austin's Positions ### On onboarding advice for beginners - Let the plugin "take control" first, follow it exactly, then gradually take more authority, in **low-risk projects** without hard deadlines. - Eventually clone the repository or build your own inspired version. - Recommends being "a lot more open to mistakes" and starting with a project you're not afraid to screw up. ### On learning style - "It's very difficult to say that this is the right way to learn for everyone. Everyone learns differently." - His method: learn while doing, choose an inspiring outcome, ask the model to slow down ("Treat me like I'm stupid", "Don't move on to the next step until I understand it"). - Tip: hand a guide/article to the agent and say "let's talk this through together," then implement in the same terminal. - Qualification: he didn't enjoy book-learning; acknowledges it differs per person. ### His own "Compound Knowledge" plugin - Built by asking Claude Code to copy Kieran's plugin structure adapted to intellectual work — reviewers focused on **strategic relevance** and **data accuracy**. - Took "maybe an hour or two"; uses it daily. - Presents it as an example of how others can build their own, not as a general recommendation. - Admits he used his brain "not as much as I expected" — the agent proposed task types and tools; he reviewed, removed, and added. ### On trust and incrementalism - Builds one function at a time and tests each end to end — "the only way I've found that really works for me" (non-technical background). - Cautionary example: a **Discord bot** for stream automation broke when released all at once ("I was a little cocky"); would have been better as a scheduling bot first, then copywriter. - Small victories beat big disappointments. ### Team knowledge sharing - Every uses a Notion "repository" with tagged insights (people knowledge, questions, company observations); agents read it at start of day. Qualification: "the system is not yet fully set up to automatically pull this data." ### Favorite feature - The **review agents** (both Kieran's engineering reviewers and his custom intellectual-work reviewers) — "a game-changer I couldn't have imagined a year or two ago"; standard chat models review based only on base-model behavior, while these have opinion, taste, and clear guidelines; can review four work tabs in parallel. --- ## Shared / Intersecting Positions - Both agree the plugin is **customizable by design** and that partial adoption (just planning, just reviews) is legitimate. - Both emphasize **learning by doing** and openness to mistakes, with explicit acknowledgment that learning styles differ. - Both observe that accumulation/knowledge sharing across sessions and teams remains **unresolved and experimental**. ## Preserved Tensions & Unresolved Points - Kieran explicitly uncertain whether file-based accumulation is the best approach long-term. - Large-team usage claimed as real (Amazon, Google) but outside Kieran's direct experience. - Token cost makes the plugin questionable on cheaper plans — a qualification he stated directly. - Austin vs. Kieran differ in building style: Austin incremental one-feature-at-a-time; Kieran acknowledges agent-built components he doesn't fully read, while agreeing with Austin's caution. # Speaker Attribution Record ## Video - **Title:** Compound Engineering: Your Questions Answered Live - **Format:** Live two-person Q&A session, follow-up to a Friday bootcamp; intended for publication on YouTube and X. ## Identified Speakers | Speaker | Role | Evidence | |---|---|---| | **Austin** | **Co-host / interviewer**; drives growth at Every; asks audience questions and follow-ups | "I am Austin. I drive growth at Every." | | **Kieran** (also rendered "Kiran" once in transcript) | **Guest / featured expert**; General Manager of Kora at Every; **creator of the Compound Engineering plugin** | "I'm here with Kiran, the General Manager of Kora at Every and the creator of the Compound Engineering plugin." | No other speakers appear; no narrator or third voice is present. ## Referenced Third Parties / Audience Contributors - **Noah** — audience member who asked about common mistakes when using Compound Engineering. - **Swissy** — audience member with questions on team workflows and favorite plugin features. - **Trevan** — credited by Kieran as having added the brainstorming team. - **Dan** — referenced as building "Proof" (Google Docs–like tool for AI/human attribution); not a speaker. - **DHH, Cron** — mentioned as removable default skills/agents within the plugin. - Companies mentioned as users of the plugin: **Amazon**, **Google** (per Kieran; he notes this is not his personal experience with large teams). ## Referenced Products, Tools, and Sources - **Compound Engineering plugin** (created by Kieran) — central topic. - **Kora** — AI email assistant at Every; Kieran's GM responsibility; iOS version stated as "coming soon." - **Claude / Claude Code**, **Codex**, **Cursor**, **Linear**, **GitLab**, **GitHub Issues** — tools and workflow integrations discussed. - **OpenAI "harness engineering"** — cited by Kieran as a related approach; future plugin features "inspired" by it. - **Vercel Agent Browser CLI** — used by the test-browser feature. - **Proof** — upcoming sharing tool by Dan; planned integration with the plugin. - **Austin's "Compound Knowledge" plugin** — Austin's own derivative plugin for intellectual work, built using Kieran's plugin as a guide. - **Pull request #885** — open PR for a basic skill component; feedback requested. - Pricing references: **$20 and $200 plans** for Claude. - Model versions mentioned: **Claude 4.5 / Opus 4.6** (per transcript). ## Promotional Segments (Flagged) - **Closing promotion:** Austin promotes Every subscription — "Every is the only subscription you need to stay up to date on AI. Just go to every.to..." and encourages following Kieran on X and highlights Kora. - **Indirect promotion** throughout: discussion of the plugin's availability, its "tens of thousands of users," and the /setup command functions partly as product guidance, though framed as Q&A. ## Provenance & Availability Notes - **Comment availability:** Not stated in transcript or metadata; unknown. - **Claims about third parties** (Amazon, Google usage) are **second-hand per Kieran's own admission** ("not my personal experience"). - Transcript shows likely transcription artifacts: inconsistent spelling (**Kiran/Kieran**, "Claude/Cloth/Cloud Code," "cloth MD / Claude.md"); no timestamps available. - Curated metadata was not supplied; all facts above derive from the transcript alone. OK. Hello everyone. I'm here with Kiran, the General Manager of Kora at Every and the creator of the Compound Engineering plugin. I am Austin. I drive growth at Every. On Friday we had a great bootcamp with Compound engineering, where Kieran showed everyone how the plugin he created works , why he developed it, what the philosophy behind it is, and also provided step-by-step instructions on how to use it yourself. We received a bunch of questions that we didn't have time to answer during the camp, so we've collected them here. I'll put them to Kiran live. I'll ask follow-up questions, and then we'll put this video up on our YouTube and X so anyone who missed it can watch it. Welcome, Kiran. Thank you for doing this. Yes, cool. Yes, thank you all. There were so many good questions, they just flew by, and there was already so much information, so we thought it would be worth sorting them out here, going into a little more detail. So yes, thank you. So, why don't you start? Just in case anyone is still new to this, if they haven't been to a camp or have n't used Compound Engineering yet, give me a minute or two answer on what the plugin is, and I'll drop it in the chat while you're at it . Yes, of course. So, Compound engineering is a way of building software that emerged during the development of Kora, a product I'm working on, which is an AI assistant for email. I just found ways to use AI that worked better for me, that made it easier to release better features, that ensured that the AI ​​wouldn't make as many mistakes, and that it wouldn't repeat the same mistakes. I started creating all these pieces, agents and teams, and at some point I thought, "Okay, let me just make this into a plugin," and I did , calling it Compound engineering. Because there's this cycle of planning, doing work, and then reviewing, and at any point, if you want to capture something, want to codify it in the system, you can call the Compound flow, and it learns from what you do. So, we actually developed a kind of productivity hack, turned it into a systematic approach, and now we're sharing it with this plugin. This is my plugin, but tens of thousands of people use it, which is really cool, and many are inspired by it. So yeah , that's kind of its origin, but it's also the way the work is done. We discovered this too. Austin uses this in intellectual work. It's simply an approach that works very well with AI because we have feedback loops that we can use to self-improve. So yeah, that's kind of an introduction to it. Steeply. Yes, I think it's useful, especially for those new to using cloud code for both intellectual and engineering work. This is a good guide, whether you are a beginner or an experienced engineer. I've noticed that it helps not to get hung up on your own ideas or your own discursive task. In fact, beyond all the value it provides, it's just a great default organizer if you've never worked in this field before . Um, the first question I would like you to consider, and which I think is a good fit after the camp is over, is when you see other people using composite engineering . Someone named Noah asked if there are any common mistakes that you notice, or do you see people using it in a way that may not be a mistake, but they miss out on the huge value that it provides. That's a good question. So I, I see that people , yeah, I think the main thing is that people assume that the way I set up the plugin and the way I use it is the only way to use it. They just assume that this is a fixed system, that this is the only way it works, and they say, "I don't want this, this, and this," or " I don't need this, this, and this." Or they think that, for example, the verification agent that I added is my own verification agent - they say, "Yeah, but it's not mine." And that's why I can't use this plugin. That's what I often hear. And people also think that it can't be customized. This plugin is really a system that, first of all , shows how I do it. So you can get inspired. Feel free to create your own version. I think this is very interesting. Just try using it. See how it works. But, secondly, you can customize it. You can just, uh, run the /setup command , it will help you set everything up, and you can add your own, uh, knowledge base. You can add your own skills. You can add your own coding standards. So, I think from that perspective, I see people thinking they can't use it because it's not tailored for them. On the other hand , I see people asking, "Yes, but for a regular simple function, is it worth using it?". People think they can't use it because it's too bulky. And maybe if you have a $20 plan, this is not the best plugin as it will consume more tokens. But if you're a professional, you have a $200 plan because there's no reason not to have one. And I believe that using this tool, even for small tasks, will pay dividends: you will either learn something new that will multiply over time, or you will remember something from old code that you completely forgot about, but it surfaced during your research. And even though it does the job very simply, I feel calm and confident using it because I know it does everything carefully. The worst thing about AI for me is when you do something and think, "Ah, that's easy." You just start, you do it, and at the end you say, “Oh no, I forgot something, I missed something, I broke something, or there was an incident I didn’t think about,” and that happens all too often if you don’t go through the whole process to the end. So, the point is, and touching on this, I think, start trusting the process; it should be a reflection of how you work, how you act—it should be automatic. It shouldn't feel like a burden or something you have to force yourself to do. Ideally, it's just part of your workflow. It's how you think. It's how you work. It's like, well , it's a plugin, but the way you work with it is also a new method of working. So I'm sure you've felt a little bit of that in the way you use it. It's just a new way of learning to work, and I think that's also something that people misunderstand . They think it's just a tool, but it's actually more than a plugin. It's like, "Hey, this is probably the future of how we work," and it's a little confusing . That's right. I think from a technical novice's perspective, I find it extremely helpful to just trust the plugin and then watch what happens as a way of learning. Especially when you get to the planning and review stage, you see the plan and think, " This probably looks good." I'm just guessing what it means, but let me see what happens if I do it. And then you get to the review stage for the first time, and you have these three built-in technical review agents. And it forces you to learn and work in new ways because you think, "Oh , apply these changes, but don't apply these." And I find it helpful to just accept the fact that you're making a lot of assumptions and that you'll have to see what comes out of it. And then you need to train yourself. And also, I thought when you said that you also need to train the agent himself or the LLM a little on how to work with him. Because I see in questions and feedback that people stop because : "It seems like the agent, or the model, or Claude, if you're using Claude Code, is telling me to do these actions, like fix all P0s or move on to the next step." And I think it takes enough trying to figure out when to say, "Yeah, keep going," or "No, I'm actually going to change something else." And that's something you just have to teach yourself. But, uh, yeah, I notice when I get questions like that, I usually respond with, "Just be a lot more open to mistakes, okay?" Start with a project that you're not afraid to "screw up" at all, and then go for it. Don't do this. Yes. Yes. before testing it on something important. Undoubtedly. Yes. And also, you know, it's important to understand that yes, this is a framework, but it was built over, I don't know, two and a half years or so , and these are all small moving elements that are gradually starting to form a complete system. And these are still small systems, and it's important that they are composite, because that means you can only use part of the system, for example, just the planning mode at first. Because people ask, "Oh, can I use this in my XYZ workflow?" For example, I write plan files in markdown, and people say, "Yeah, but I use Linear, how does that work?" Well, you can just change the prompt or tell it, “Hey, instead of plotting in markdown, can we use Linear? »—and maybe add Linear skills, or adapt it somehow. You can use it in your own way and start, for example, with just reviews if you want to take the first small step. Or, if you're more comfortable with iterative work where you want to see all the changes, then of course don't use the work command, but just put the plan it came up with and that you've checked into the Cursor— if that's your choice—and go step by step, saying, "Hey, can you explain everything step by step?" There is no one way to use it , and I think that is a strength. It's also difficult because people suddenly ask, "Oh, how do I use this?" I reply, "Well, whatever." And this is its advantage. We have these steps, and there's even an LFG command, which essentially just contains the ID for the pull request. So, there are all these different things you can do. You should try it out on some hacker project or something random, just to see how it works for you, what you like and what you don't, and so on. Yes. Because it has its own specifics. Yes. And it is very easy to assemble. Yes. Another question that I don't know the answer to, but I'm really curious about: someone asked how you use this to build a working relationship with Claude Code throughout sessions and even between different projects? So, each session improves Claude's understanding of how you like to work. Um, this is related to the step of accumulating knowledge. And I think it would be great if you could explain how this step works, because we didn't really go into it when we discussed the project level. But there were many questions about how the accumulation of knowledge that you use at the project level begins to apply to all your work, as a whole. Yes, um, yes. So, someone also asked, " What is prompt engineering? What does it mean? Hello. We're talking about my approach to engineering. And the question was also, what is " knowledge accumulation"? I think the hardest part of all this is still the accumulation itself. And it's not just my opinion as a plugin author; everyone thinks so. It's the hardest part for everyone, and everyone has their own perspective on it. You have, for example, OpenAI with their "harness engineering," which is a variation of that. Um, like contextual engineering, which is basically similar because you're managing the context, and the accumulation part is interesting because you're using an agent to pull information at certain points and then codify it in some file. That's how I do it. So that next time it doesn't make the same mistake, and you can say, "Oh yeah, this is Claude.md and memory," and it's actually a similar thing. Imagine you're reviewing a pull request and there's a syntax or style you don't like, and you say, "Hey, can you use a different style, I like it better." Before, you would say, " Hey, can you add this to Claude.md?" Because I don't want to keep repeating this." Just make sure next time that the context I'm building it in always uses this style. I used to do that, and it resulted in a very long Claude.md file that became difficult to manage because sometimes the information that's there is n't always up to date. For example, with the style , yes, of course, it's always applicable to everything you do. But if, for example, you have a feature like a special library for a narrow task, you don't want that information to clutter your context or need to be managed. You kind of forget that it exists . Yeah, it's kind of polluting your context. So I had an idea: why not put it in files, because files are great for storing information, and the agent is good at searching files with agent search. I came up with a system: instead of storing it in the cloud, I'll document everything in files, like in Markdown format. Let me show you how it looks for Kora. I think this is a good example. So, open GitHub. Code. Someone asked if quantum mechanics is also part of complex engineering. Yes, it is. But we filter them out if you... that's a bit different. That's it. So I like to keep things in my repository because agents can search for information. You can see, this is Kora. This is a product that I'm building. It's an AI assistant for email. I've always been a big fan of GitHub Issues. I still use them. As you can see , they're there, but they're more for active work, for focus. And here I document how I work and what I'm building, and hopefully as the models improve, that information will become even more valuable. So that's the idea. You can see the " brainstorms" section—I've just started doing them, but here's all my work. I have a feature where... you use the " brainstorms" section of the plugin, and all these ideas are stored somewhere inside Kora. Yeah. So if you run the slashworkflows brainstorm command from the plugin, at the end an artifact is created that is captured in the source code. But as you can see, there is also a section called "research" . For example, if something goes wrong. I started doing this recently. It's kind of like bug-solving with analyzing what went wrong. And the " solution" is where all the complexity goes. Here are the best practices. As you can see, I recently got it organized. Sometimes I just clean it up and start over. Developer experience, integration issues. I categorize them to make it easier to navigate. uh, I'm looking for, uh, for, uh, for agent search, and I also have, uh, metadata, so I can search for things, and you see, it just says, "Hey, we need account features in LM tools." Uh, so it's like saying, "Hey, we need, uh, prefix, we need account scope, " and that's how we do it, and it's, uh, its own kind of how it's documented, and you see, it's quite a long time. If you were to add all of that information to cloth MD, it would just get incredibly big , and that's just when I'm using LM tools in CI and feature flex. Uh, so there's the account scope for those places, and the beauty of it is that this document is never there or never, ever inserted into the prompt. And you see how we then get that inserted, like, how do we find out about it? So, I think it's the " Best Practices Explorer," I need to mention, so there's an agent that I use within the planning team and the work team, it's the " Best Practices Explorer," and you can find it here. Uh, it's going to discover things. See where it is? Online research results. Uh, yeah. Oh , yeah. Here. So, yeah. So, he, he, he does a bunch of things, but also looks at, uh, the folder of collected discoveries, and then finds it. So it's a subagent that brings this in as research and essentially says, "Hey, uh, this is something we've had before." This is something we've already, uh, discovered, and we should stick to it. And the beauty is that it's a subagent, so it doesn't, uh, waste context. He just finds the document, shares what he learned, and says, "Hey, we've done this before." I think you should want this, and if you want to learn more, go to this document to go into detail, and. I think it works really well, uh , because the problem with things like that is they can get stale, and if you have a lot of stuff that you're always loading, it just clutters up the context. Uh, files like Cloth Code are really good at managing files and, uh, just finding the right context, so that's great, also with a 1 million token window, uh, right now. This is madness. You can do much more. Uh, and we're still thinking, "Is this the best way to do it?" Maybe not. Maybe so. I don't know. But now I do it this way, and it suits me, and it's a way, for example, if I get annoyed or something like "I don't want to do this again" happens, I can save it somewhere . And I also hope that in the future the models will get better, and maybe we'll be able to say, " Hey, I have all these advanced methods and discoveries." Can we somehow combine them, rewrite them, or simplify access to them so that everything works even better? Yes. So yes, I have the same experience as you, I use it the most when I'm irritated. I feel like I did this a week ago. Yes. Well, at least now that I practice session stacking, I don't feel like there's something in my system that just works, is automated, constantly learning and getting smarter while staying organized. It seems to me that this is a kind of impossible dream. We're not quite there yet. It would be great if we were already there. But the part with the accumulation is good because I am working on the same project or another one that is stored locally. I can say, for example— I think you always talk to Claude too—"I think you found out about this a few days ago." Can you just find it? And even just having it is incredibly helpful, even if I still make the same mistakes. Yes. And I also want to say that accumulation is a philosophy, and it is also in this, well, in the plugin. And I would say that the version in the plugin is not the full version, because the way I use the plugin is also... I am its creator. So I'm just modifying the plugin to make it better, which in itself is also a build, but it's not as obvious to people who just think, "Oh, it's a plugin , this is how it works." I add new agents or add things to skills, and sometimes I have skills that I transfer to the plugin. And this is your question: " How do you manage this locally in a project versus using it across multiple projects?" Well , for me it's a plugin, because it all started with Kora. Kora was local, and I thought, “Oh, I want the same workflow in other places.” So, I created a plugin. So, I, I see it a little bit like you we get a few questions about, um, how to get started with these things too. And my advice, if you're a beginner, is I see these steps as, let's say, letting him take control. Just let him, well, follow him exactly. Let him guide you through this process. see what happens. Start trying to control it yourself more, like take more authority over how the plugin works at each step, or as you say, sometimes use just the validation phase, sometimes use just the planning phase, like, after you see everything it can do, probably in low- risk projects where there's no, you know, where there's no hard deadlines or need to release the product to the world right away. um, do it there. And then , when you feel like you've mastered it, and it makes sense to you, and it helps you, I totally agree that then, for example, either cloning the repository and creating your own, or using it as inspiration to create your own—that's really the best way to get the most out of it. Um, and then you can always refer to yours. This is the path I took, and it was helpful. Um, there are a few questions in the chat that I think I'd like to hear your answer to, and that we also got during the bootcamp, which is: I think a lot of people start their journey with code or codex with this plugin, or it's something they start adding because they've heard about it. And we have two questions: How much, um, basic knowledge, fundamental knowledge do you think a person should have before they start creating something with these tools, engineering or just using cloud code, or do you think it's better to learn as you create? Um, so here's the thing , I I think, I think it's always good to understand what you're doing, but it's not always fun, and sometimes it's just too complicated, and then you don't do it. So, there is this question. For example, um, I...I think one thing that's really fun to use is the brainstorming team, actually, because it's more interactive, which means you have a better understanding of what it's doing. For example, you ...you will better understand , step by step, what he is doing, and perhaps you will feel why he is doing it. That's why I think brainstorming is a great option. hmm, and planning is created more to simply get a result at the output. So I would advise reading the plan very carefully and perhaps asking why it did certain things the way it did . Why did he choose one path or another ? And also know that you can " interview" the model: she can do tasks in one go in teams, but you can say, "Hey, can you do this step by step instead?" Because I want to understand why you do certain things, and that's the best way to learn; This happens right in the session because the model has context. She knows the prompts. So it can literally tell you, "Oh, because of this line in this prompt, I'm doing it like this ...". And I usually also explain why —I don't just say " do this," I say " do this because XYZ," because then you're communicating at a higher level and hopefully opening up the possibilities for newer models or "deeper thinkers" because they might go in directions that I did n't even know about. So " interview", experiment, dig into the details, ask Claude, CodeEx or whatever tool you use why they do certain things. I think that's good. You don't need to understand everything. Uh, but I think if you're using this in a professional environment, you should understand, at least, when it's appropriate to intervene and when not to intervene, and ideally, understand why certain things are there at all. Do I always use prompt engineering flows? For Claude—yes, always. And for entertainment projects on the site, not really. Because I want to feel the model; For example, when we check models " by touch", I run them through prompt engineering, but this also normalizes the results in a way. I also want to see how good it is without anything, i.e. can I remove certain steps? For example, the simplification checker is there because Claude really wants to publish a bunch of things , but maybe someday they'll fix it and we won't need the simplification checker anymore—we'll just remove it. So it's also useful to understand what a model version is and what a plugin is. So I would say that both are important . If you're into "vibe coding" and just want to see how crazy it can be, uh, /LFG—I moved it somewhere, but it's the same command. Yes. So, SL LFG—it's just whatever you want to do, and it's going to take a bunch of tokens. It will write the code for you and give you the result. So it's just a fun way to say, "Hey, if you have tokens left for the day and have some interesting idea— just try it," sometimes it takes 30 minutes if the project is larger. I would say it's interesting because it's just checking the other side. It's like, "Hey, how far can you go without doing anything?" because it also takes a lot of energy if you have to learn and do it all yourself. So I would try both approaches. I would do both . I'm just really curious. I also want to know how everything works. But this is not necessary. If it helps you—of course, use it. I feel the same way. I think it's very difficult to say that this is the right way to learn for everyone. Everyone learns differently. What works for me and what I would really recommend is in line with a lot of what you said, which is that you learn the most if you have fun and are passionate about it. And I believe the best way to achieve this is to choose an outcome that inspires you. Whether it's "I want to release my first app" or "I want to automate some of my work ." It could be something simple like email or calendar automation. Try to start with something achievable. And don't overexert yourself when trying to study. I really enjoy learning in the process. I think what you mentioned—that the model can go all the way and create a version for you—is true. Maybe she'll be able to do it on the first try. The result will probably be a little imperfect, but I found a very good way to teach: ask her to slow down, she will listen to you. Tell her what I say all the time. "Treat me like I'm stupid." And also: " I really want to go through this step by step." "Don't move on to the next step until I understand it." And it's kind of an "on the fly" method for acquiring fundamental knowledge, where you learn on the job, not like me—I, for example, did n't really enjoy studying at school, sitting and reading a book about how to do something, I'm not interested at all. I'm interested in taking it and doing it myself, but this is what works for me, although for someone else I think it might be different. Um, that's why we have these guides where you can just sit down and read the instructions . Another tip I would give that I think is incredibly helpful for those who want to get a knowledge base before starting work: take a guide or article, no matter where it comes from, give it to your agent and say, “ Let’s talk this through together.” Um, and then you can immediately implement it in the same terminal; it's also incredibly useful. Yes. Another interesting thing: I like to try using this for things that are not related to engineering. For example, I'm a musician , and I thought: why not create a bunch of weird VST reverb plugins, these are the kind of plugins that create a spatial effect, like you're in a church or something like that. So I just asked, "Hey, can I do some really weird effects that don't exist yet?" And he came up with some really interesting ideas, so I said, "Oh, okay," and we went through the brainstorming phase, and I decided, "Okay, let's do it." And, um, I guess I just created the interface that I wanted to see in all of this , but the algorithms and everything else didn't really bother me. I thought, "This is just so I can make music, have fun, and see how far I can go." And first I had an interface, I said, " Okay, this is an interface, and this is what I wanted to do from a musical perspective," and it's cool, it doesn't matter if it's bad or good, the main thing is that it's interesting. Another example is 3D printing. If you have a 3D printer, Cloth is very good at creating STL files. So for any household chores you need to do at home. Maybe you can write code "on vibe" or something, and going through the compound engineering flow—it's actually a very structured approach; it has a good structure that ensures everything is correct and follows best practices, which is actually beneficial for everything. So, you can start applying this to other things. It's certainly not as fast as "hey, do this for me" , but it's more thorough and you get higher quality. So just experiment as well, because I think play is very important to get going. Agree. Um, okay, there are a number of questions that go deeper into the different phases of compound engineering, and it would be great if you could answer them. One concerns the planning mode. First: How do you decide when you 're using it that you're confident the plan is final and you're ready to move on? Yes, this...let's also open the plan. We are here in Corora. Let's move on here. Besides, I don't have real answers to all these questions, because I understand everything too . I think it's just good. Yes, it's good to hear your opinion, and I can Yes. Yes. Workflow team . But I would say that for me, as long as you're discovering it, it's pretty volatile, right? Like, when I'm really playing and I don't care, I'm like I sometimes don't even read the plan and I'm like, let's just see what happens. Sometimes someone asked, when do you deepen the plan? I only deepen the plan when I'm making progress on something in the background. Yes. But I'm in meetings one after another and I don't want to do it right now, and I'm like, go ahead and do it, or like, " deepen the plan," continue the research for me while I'm gone, because I don't want to do it for you. So I think it depends quite a bit on the project, but yes, what do you want? Yes. Yes. I think it's this prompt. I think it really depends on a lot of things, and I think you've already touched on a few. It depends on whether it's your job or if it's entertainment. I think if it's entertainment, I usually don't read the plans because I think it's okay if it's not very good. The risk is that if the plan isn't what you want and you follow it, you'll have to go back and make the plan again. This is where the risk really lies. But with things that are for fun, I'll probably delete it anyway. So it's like I'm not stuck at all. I have no goal to complete it. So if there is no goal to complete, I like to use LFG, which does everything. He creates a plan, then builds, checks, creates a merge request, and I see if I like it and can, well, do some personal stuff, not for open source. I also create plans, but I don't check them because I think: if it turns out badly, the next version will be better. My approach is this: it's mine, so it doesn't matter if there are mistakes or if the architecture is easily repairable—I prefer to move forward rather than constantly go back. So I don't read plans at times like these, and there are different levels of planning. So, there are three levels of planning. Let's see where they are. Ahem. Level of detail. Yes. So, okay. Here. Yes. We choose the level of implementation detail. He will come up with a minimal structure, something small. I think for a minimum level you can review, but everything is pretty clear. There are even more that contain more information, such as multiple files. It could be the result of brainstorming, for example, or there's a big option, uh. This is a great option, I think, yes, very comprehensive. I think if you chose " a lot", you should reconsider, because he can do too much - for example, Claude has a tendency to overdo it sometimes. So you can limit the volume. You might say, “That’s cool , but you’re being too diligent—you’ve done a whole set of tests and backward compatibility for the new feature.” We don't need backward compatibility in such cases. Sometimes it suggests risk mitigation strategies— this is important for certain things, but if you're testing it for yourself, it might not be necessary. So you can say, "Hey, slow down a little," and I think checking is helpful. Ahem. So, I would say that in a professional environment, I always review the plan because it saves time and also allows you to learn. For example, if something goes wrong, you say, "Hey, can you not add risk mitigation strategies? I don't need that in this application," you can run the compiled flow, and then next time it won't do that when planning, so you can start compiling in that phase. Yes, I agree. This is one of the best ways to learn, especially if you are just starting out. Yes. I read almost every plan, at least cursorily, unless I'm busy or in a meeting, I just want to see where it's going to go, to find errors. Um, I also see we've gotten questions about using this plugin and vibe coding for large, ambitious projects, like a big brainstorm, a plan summary, an in-depth analysis. Is this done all at once, or are there ways to slow down the process. Another thing I particularly like about this approach is the ability to brainstorm and plan a multi-step roadmap. So it could be an eight-step roadmap, and you can see where you start and where you're going. You can give him notes, and then he breaks it down into parts, like, "Okay, let's release phase zero," or you can say release phases zero through two, and then we'll check and see how it goes. And I like this approach. Yes, definitely. And something else. Yes, and if the tasks are really big, I recently started brainstorming because Trevan, who added the brainstorming team, did a really good job. We do this before the planning phase, because if you don't know exactly what you 're solving and what problem you're facing, it's hard to even make a plan. And that's usually the problem: you don't fully understand what exactly needs to be done. So I think it's great, and what I like about brainstorming is that it's about generating ideas and exploring. It's like scaling up where you try to cover as much as possible , and then planning helps narrow it down, make it specific, and turn it into steps. Um, so I think planning and brainstorming together is very powerful, and if the task is really big, I would definitely brainstorm. You may even need multiple plans for different stages. After all, you can break down this big plan, because a comprehensive plan is still the most difficult to implement. The middle option is ideal. If you have several medium plans, it will work better than one giant one, although the models are getting better. So we want to push the boundaries of what is possible. So I'm not saying you shouldn't do it. Ahem. One thing I like...I haven't released it yet, but what I'm doing: Dan is creating Proof , which is essentially Google Docs built for AI so you can share things with people and see what's written by AI and what's written by humans. And I'm going to implement this into the Compound Engineering workflow, where at the end of a storm or a plan, you can say "create a shareable link" and share it with the team. Because we're talking about how you review this, but Swissy also had a question: "Hey, how's your team working on this?" "Because if you commit it to source code and push it to Git, it doesn't work in teamwork." Not everyone has access to GitHub or the desire to use it. Um, how do I get feedback? How to see what people said? Well, things like that . So, that's a question that we're trying to answer ourselves, and our solution right now is Proof, where you can see, uh, yeah, and it's going to be built into the Compact Engineering plugin. So you can see, "Hey, this was written by an AI," and maybe I have a plan , I send it to Austin, he says, "Hey, this is cool, but let's rewrite it to something else here," or "Hey, how about this?" "And the agent can then see those comments, work on them again, uh, and I think the collaborative aspect is important." We're going to experiment a little bit, because I'm obviously working mostly on Kora by myself, but we're trying to figure out how everything can work together. So we'll talk more about how to use this in large teams . But I know people at Amazon use it; Google uses it too . So, big companies use this in teams, it's quite real. Uh, I just don't have 50 people on my team . There are two of us, me and another colleague, so this is not my personal experience, but it is definitely possible. I will share one more point: I agree that the sharing of experiences within the team, and especially between agents, seems experimental, and we are trying to find a solution that can be simply passed on to others. But one thing that really helped us is that our Notion workspace has a “ repository” where we can transfer the accumulated knowledge after the session is over. Regardless of your agent, you can share insights sorted by categories: people knowledge, questions, observations about the company. They are tagged, but the system is not yet fully configured to automatically pull this data with each new session. Yes, exactly. It's not the smartest system yet , but it centralizes knowledge and gives you a place to find things. All the agents I use in my work are set to read this at the start of the day to consider changes to how they work. And I think this is the start of something useful. Yes, definitely. We don't know exactly how this will develop, but we know that shared knowledge is necessary. Everyone agrees with this, and it can't be in real time because it's too slow. You need to record your findings somewhere, and having the right context is the best moment to commit, because you have a fresh window of context from which you can extract everything you need. Modern models learn very well from their own experiences, and that's really cool. Yes. Yes. We have a few questions about how difficult or easy it is to modify the plugin for your own needs. To configure or change it. You've already touched on this, but I can show you my workflow on how to achieve this. Um, I wonder what your advice would be for people who are thinking about this when they get to this stage—it's very helpful. Someone asked about simpler agents for viewing or using for intelligent work. As you would advise, because you are setting this up yourself, since you are creating a plugin. If someone wanted to customize this for their own work, where would you recommend starting? Yes, there is such a way. Yes, there is a command called setup, you can call it via /setup. It creates a file called compound engineering local MD, and you can configure which agents you want to run during the review and work stages. For now, these are the two points where you might want to add your own customizations, as it's quite specific. If you don't have this file , it will just use mine. It will simply use the default settings. Um, but you can do it. It will determine what system you have, for example, it will say "hey , Rails" and use my Python, and there is also general Python, TypeScript, and you can quite create your own, which are not even related to engineering, just saying that this is not an engineering matter, but, for example, marketing. So I actually use compound engineering for writing as well. It's a little strange, because if you were planning a work, you would probably call it a draft or something, but that's probably all the differences. So you can set this up if you're using Linear, or if you want to use GitLab, or whatever else people use, and you just want to remove DHH or Cron— just don't add them and use your own skills. If you have skills, whether in global or local settings, you can say, "Hey, these are the agents or skills I want to use," and it will just do it . So there is nothing rigidly fixed in the teams themselves anymore . So, it will automatically detect if that file exists and download all your information at the right time, or just use the default settings. This is the best way. The SL setup command from the compound engineering plugin is the best way to go, it's interactive, you can talk to it , and it will guide you through everything . More features inspired by harness engineering from OpenAI will be added soon, but it's not out yet. But I'll focus on the settings because I'm currently building an iOS app for Kora. So I'm like: hey, I need Swift and a little different setup. Er , so I understand these difficulties. This if works, but it would work better if I had more customization options, and I will share that in more detail. There is an open pull request if you want to take a look, it's number 885. This is a basic skill component , read it and tell me what you think. We would be happy to hear your feedback, if anyone has any suggestions. It's a little more complicated, but if anyone is interested, take a look. Yes, I, uh, I'll show you my screen. Ahem. This setup command is simply incredible. I had no idea it existed. Eh, glad I know now. Never shared this . No, since Friday. For most of these things, I found the answer: just ask Cloud Code to do it for you, and it works really well. So I use the Compound Engineering plugin and the process itself, especially the brainstorming phase , to create this Compound Knowledge plugin, which is focused on me, but also the thought came up: what if we made a version not for engineering, but for intellectual work itself? And I said, " Show me how we can do this. I've never built plugins before. Use Kieran's Compound Engineering plugin as a guide on how to do this. Um, and let's just figure this out together." And I said, " Again, take me step by step on how we can implement this." And that's how I came up with this, which copies almost all the settings you have for Compound Engineering, but adapts them for real intellectual work . For example, the reviewers here are not the same as those for engineering, they focus on strategic relevance and data accuracy. Two things that I think are quite comprehensive if you're doing any kind of task execution in the intellectual labor field, and I think it's quite useful. I use it; It is useful for me. But I think more than anything, instead of saying, “Oh, just use this plugin for your intellectual work,” this is a good example of how you can just open Cloud Code, give it the Compound Engineering plugin—I would recommend trying it out a few times first—and then say, “Okay , make me my own, which I’ll modify, and explain how it works .” I spent maybe an hour or two on it, and now I use it every day. Yes, that's right. And the coolest thing is that it removes everything from my plugin that you don't really need. So he is economical. I'm even a little jealous that you can start from scratch . Yes. Because I also think that I should probably start from scratch, and I'm trying to update it, but I have all these people using it. But it's great to understand, and if you have a moment where something doesn't work or you missed something, you say, " Hey, can you look at the Compound Engineering plugin, how they did it, or something?" And because it's based on that or has such a close match, it can just learn things from there, which is very convenient. Yes. Yes. Besides, it was funny. I feel like I actually used my brain just as much as I should have, but not as much as I expected, creating this thing, because I knew what intellectual work I was doing, but what even counts as intellectual work? Let's say we were trying to create a general- purpose plugin for this kind of job. So what? I just said to Cloud Code, "Look at what I'm doing, and then do your research and figure it out for yourself." He suggested the types of tasks that should be supported and then built tools into the plugin to make them easy to perform. And I thought: that's pretty good, right? I didn't sit down and come up with any of these things that he set up to work. I reviewed it, removed some things, and added my own when he had everything ready. But, um, sending this out to review my own work for new ideas and then exploring how it could be applied to more people was great. You , you're alluding to this when you talk about 3D printing, right? So, like, yes, ideas become really good, especially if you direct them in a certain way, according to your taste. Yes. I have a question for you, because sometimes I feel like: hey, if I implement a new process or do something new, when do I start using it in real work? We are experimenting, but when do we start using this in everyday life or in our real work, in real cases? Um, how do you know it's good, or how do you start to trust it? Because, apparently, artificial intelligence is very good at creating a lot of complex processes, agents, and things like that, but does it really help? Does this solve any problem? How, how do you keep your sanity? In order not to get too carried away by the fact that , say, "hooray, I created a plugin, it does a lot of things and "communicates", but in reality it is not very effective or useful" - how, how do you do it? So I took the same approach to this as I did when setting up my Open Claw, which was to do it for something I actually want to use, not just to play around with to see how far I could go. I'm going to build this one function at a time and make sure the function itself works before adding anything else. This will be much slower than what you are able to create now. It also seems like a less intellectual approach than the one I would have to work with when I see how you or Dan work. I see other people working and I think, “Oh, this looks like real basic level, but this is how I can actually use it, right? So with that Compound Knowledge plugin that I was showing, all I really wanted was to have some kind of framework that would organize me without giving me too much direction about where to go. I really just want to move from brainstorming to planning, reviewing , working, and delivering, and to have a little bit of guidance, like, for example, he suggested four or five agents to review, and I thought, let's just make these two agents really high-quality -- a strategy agent and a data analysis agent . Um, and then I tested it out, and it actually worked really well, in the sense that I think it helped me get organized first. Um, and I did the same thing with my Openclaw. I thought, "Okay, let me make sure this thing can read my emails properly, that it's connected to my email and working." And then: "Okay, now let's connect it to the calendar, and then to my database." And, especially as someone with a non-technical background, taking each step, especially if I'm building something, implementing each feature one at a time and testing each one from start to finish, is the only way I've found that really works for me so that I can use it every day. Yes, you can do that because you actually know what quality work looks like. And I know, I understand the whole system, right? Someone else built it. The agent did it. And if the agent creates eight components and I only use three, and there are five components that I don't understand...It really makes it difficult to continue working on that foundation. Um, and I don't think I need to...I don't read everything he creates. I don't read all the explanatory files. But I really think that using each part from start to finish before moving on was very helpful for me . And I... when I don't do that, when I think, "It looks good, let's move on, " and then something breaks, it's bound to come out sideways. Yes. This is because I didn't really use or understand everything from start to finish before moving on. Yes, I agree 100%. Yes. And it's easier if you're already good at what you do or know what you need to do. You just don't go into the details that much. Yes. Yes. I tried to set up a Discord bot for us last Friday that would automate the entire process of our broadcast: scheduling in the calendar, finding a time to stream, writing all the texts. And I was a little cocky, thinking, "We'll definitely do it in one go." I could just tell Cloud Code to do it and it would figure it out. And then I released it to our Discord, and people are like, "Oh, I want to be able to request previews." "And then it all broke because I didn't do it, and I would have been much more useful if I had let it be just a post scheduling bot at first , and then it became a copywriter. Um, and maybe there are people who are so good at prompting or design that they can do all of that at once, but I think that's my level, and that's okay. I can do it. I can do it step by step right now. You know, I do the same thing. I think it also helps you feel better because you have small victories instead of big disappointments when nothing works. I think that's good too. And it's not just you, it's the whole company. If you suddenly release something that can do everything, people have a hard time even understanding what it is. So if you release something small that people can understand—that's better. So more frequent releases are probably better. I think that's just the basic principles of software development. Yeah. That's crazy, because what I was just saying is that a lot people who are using it now, including me , have no experience, and it's like, oh, I'll do something. It works for me. I think it's really good. Now I want my team to use it. And you see someone doing something that you thought they would never use it for, and it breaks, which is very familiar to anyone who's been building products for years. But the knowledge workers who are trying to do it now are like, what the hell are you talking about? Why would I use this? And it's funny how much you have to learn that side of things now if you want to build these kinds of tools for knowledge work. Yeah. Cool. Yeah. There's one question from Swissy. I think it's cool. What's your favorite part of the plugin? Do you have a favorite part? Is it the testing? Because I thought the testing phase, both at the beginning of using it and now, would be like: This thing looks weird. Can you just test it? Whether I use it or not your reviewers for something engineering-related, or reviewers that I've created for some intellectual work. For me, it's a game-changer that I couldn't have imagined a year or two ago. Because I do a lot of writing and editing, you know? The way that the standard Claude or ChatGPT chat can let you down is if you ask it to review something. It just reviews it based on what the basic model is. And we see how good reviewers can be when they have their own opinion, taste, and clear guidelines . It can happen in the background, like I'm working on something, and I open four different work tabs and I say, can you review all four things at once? Um, that's my favorite feature. I think it's really cool, and it's probably the thing that changes my day-to-day work the most. Yeah, my favorite is the test browser. It's not actually built into the review step, but it might be worth doing. So the test browser essentially offers end-to-end browser-based testing in the style of a QA engineer. It opens up a browser and does everything on its own. I just think that's my least favorite part. I don't like writing system tests because they're slow, they're brittle, etc., but you want to test what you're building. So I really like that. And it also finds things that don't work. And if you run it in "headed" mode, well, this is it. You can run it in front-end mode. So you can see what it's doing and give feedback right away. You say, "Hey, you missed something on this page , blah blah blah." And you can start iterating. You can also say, "Hey, this page looks really bad. Use the design iteration agent to make it better with these guidelines." I think that's one of my favorite parts of the plugin. It's using the Vercel Agent Browser CLI to iterate on the real thing. product. I think this is my favorite part right now, because it wasn't possible with anything before 4.5, and now with Opus 4.6 it works really well. I think this is a training that we might want to do at some point: how to teach your agents to use the browser, because even I feel like I'm a little behind on that. Yeah. And that's really the missing piece to getting things done from start to finish. I think when we launched this, I was like, "Okay, now this is going to work." And another thing that I'm doing—I have another one. I think it's a video viewer. Viewer. Video, video feature. That's it. That's another one. which will click the app, create a video, upload it, and attach it to the merge request. I, I didn't even know this was here. which is really handy, because if you're if you're pushing requests to other people's repositories, like we do, for example, I have access to spiral and others, and sometimes I get something It's annoying, and I'm like, "Oh, let's just fix this," and I run this command, and it creates a video of everything I've done. So it's really easy for a developer to see exactly what's changed, what it looks like, what it does, and it's just one click away. So yeah. That's great. Okay. So, Kieran, thanks for coming. Thanks for watching. Every is the only subscription you need to stay up to date on AI. Just go to every.to and check out the latest ideas, apps, and training that we've got for you. And follow Kieran on X. He's posting more content on Every, which is really cool. You can see not only compound engineering, but all the other cool things that he's exploring in this area, and Kora, the AI ​​email assistant that he's continuing to improve. iOS version coming soon. iOS version coming soon. Really cool. Can't wait. Cool, man. Okay. Thank you for doing this. Thank you all for Thank you. See you all.