Kieran Klaassen and Trevin Chow break down Compound Engineering v3.20, which merges 120 PRs and adds new skills—including ce-pov, ce-explain, and ce-commit-push-pr—aimed at producing better quality results in a multi-model workflow. # Channel Presentation Observations ## Source Evidence - **Title:** *Compound Engineering Now Works Better in a Multi-Model World* - **Format:** Live stream / Q&A session with two hosts ("Kieran" and "Trevan"), including audience questions, screen shares, and a product release walkthrough. ## Intended Audience - **Advanced practitioners**, explicitly stated. When asked for an "explain like I'm 8" version: > "We will not do this. Sorry. This will be an advanced level. This will be for those who already really know what it is... a video for beginners will be released soon." - **AI-assisted software engineers** working with multiple model providers and tools (Claude Code, Codex, Cursor, Grok) — the demo content assumes familiarity with plugins, skills, PRs, and token costs. - **Team leads / agent fleet managers** — the "CE explain from last Thursday" skill is pitched as valuable "for those who work in teams, especially for leaders, team managers, or those who manage a fleet of agents." - Practitioners in **large companies and solo entrepreneurs** alike — hosts mention adoption "in Google, Amazon, and Meta," "governments," and solo builders. ## Claimed Scope - **"Compound Engineering"** is presented as both an open-source product/plugin ecosystem and a philosophy: accumulating knowledge in the repository, the "AI sandwich" (deep thinking at the start and rigorous review at the end). - Scope extends **beyond software engineering**: > "We really started as a software engineering project. Now it is used for intellectual work... from idea generation to product marketing. You can even do AI research... create educational videos." - **Multi-model, vendor-neutral positioning** is a core release theme: > "We are not tied to one model or one provider, which is one of the reasons for this release." - **Outcome-over-frugality philosophy:** "We are focused on the outcome... the ratio of tokens to value. We are trying to maximize value." - **Deliberate minimalism/reduction:** hosts emphasize deleting skills when providers absorb the functionality ("We try to delete even those skills that we had for a month"). ## Self-Description Evidence - Creators frame the project as **built for themselves first**: > "Cyrus and I build Compound Engineering, we use it every day. So in a lot of ways we're building this for ourselves, and it just so happens that there are a lot of people who want to use it too." - The channel carries a **"Compounding has its own opinion"** identity — opinionated tooling, not neutral: "you feel like Compounding has its own opinion, because it does. This is our opinion about things." - **Open source, community-driven** identity: audience is invited to file bugs, share success stories on Twitter, contribute skills, and check documentation in the repository. ## Observable Presentation Patterns - **Live, conversational format** with real-time Q&A, screen shares, and reference to audience members by name (Hugo, Dave, Kyle, Cole, Seth). - **Teaser of upcoming content:** beginner videos, an article on studying/learning, an article on the polishing stage, and "subscribe to stay up to date" — indicating an ongoing content series around the product. - Emphasis on **practical demonstration over promotion**: "don't promote tools, promote results." # Delivery Observation Report **Video:** *Compound Engineering Now Works Better in a Multi-Model World* **Speakers:** Two hosts (referred to in transcript as "Kieran/Cyrus" and "Trevan/Trevan"), live-stream format with Q&A > Note: the transcript appears to be machine-translated (via Russian), so exact wording of quotations may differ from the speakers' original English. Quotes below are verbatim from the supplied transcript. --- ## 1. Overall Tone - **Conversational and informal.** Opens with casual stream-checking chatter: *"Okay, we're on the air... Let's wait a few more minutes for people to connect."* - **Enthusiastic but hedged.** Repeated excitement markers alongside explicit uncertainty: - *"This is one of the things that really fascinates me."* - *"I think there will be mistakes and stuff, but here's what you can do."* - **Self-deprecating moments:** *"even I sometimes don't know everything we have because Trevan adds so many cool things."* - **Playful interjections:** *"Oh [ __ ], I'm done," "Boom. Now you can see it," "Steeply. Come on."* --- ## 2. Recurring Vocabulary & Phrases | Pattern | Evidence | |---|---| | **"Philosophy" as framing word** | *"it all comes down to philosophy"*, *"which was born out of a philosophy"*, *"Our philosophy is that the more tokens, the better."* | | **"Cool" as all-purpose positive** | *"I thought AI was pretty cool"*, *"a cool skill that Kieran has"*, *"they're really cool"*, *"which is quite funny... cool."* | | **Cost-per-outcome framing** | *"the cost of a single task matters"*, *"the ratio of tokens to value"*, *"is it worth paying $5 for this feature? And is it better if we spend $7?"* | | **Deletion/removal emphasis** | *"my goal is to always remove as much unnecessary stuff as possible"*, *"I would emphasize removal even more"*, *"we will simply remove this feature."* | | **Named dollar examples** | Consistently uses small concrete figures: *"$2,000 for a simple thing"*, *"$5... $7"*, *"hundreds of thousands of dollars a month."* | --- ## 3. Teaching Habits - **Concrete scenario openers.** Explanations almost always start from a user pain point: > *"You create your agent and it says, 'Hey, we could do this or that.' 'Which one do you want to choose?' You sit down often and maybe half the time you have the answer."* - **Imperative usage advice.** Frequent direct instructions to the audience: *"Be sure to check out the repository"*, *"Run it on a weekly schedule"*, *"give it a try."* - **Numbered/limited-option framing** to reduce overwhelm: > *"We don't want to exhaust ourselves with thirty questions. We need three questions that will really extract everything we need to know."* > *"you get up to three rounds of such an exchange. And, in my opinion, three rounds are quite enough."* - **Live demos interleaved with narration:** *"Let me share my screen... I typed `/cpovv oracle` and Claude used that skill."* Also self-corrections mid-demo: *"Oh, sorry, I'm not showing the screen. That's it."* - **Anticipating objections, then answering them.** A repeated rhetorical structure — pose the skeptic's question, validate it, answer it: > *"Why do you need more than one harness? Why can't we make everything simpler? Excellent question... There really is something there, I totally think it's a great question."* - **Explicit scope-setting with the audience:** declining an ELI8 request — *"We will not do this. Sorry. This will be an advanced level... A video for beginners will be released soon."* --- ## 4. Communication Patterns Between Speakers - **Handoff ritual.** One speaker explains, then explicitly invites the other: *"I'm curious, Trevan, what you think and if I missed something."* / *"Ahem. No, I think it's great. I would just add a few points."* - **Name-dropping colleagues and community members** as credibility anchors: *"my friend Paige Mann"*, *"My friend Matt, for example, only uses the CE plan"*, *"Kieran has a great approach to learning."* - **Complementary credit-giving:** each speaker repeatedly attributes ideas to the other (*"Triven called it an AI sandwich, which is quite funny"*, *"a cool skill that Kieran has called CE explains"*). --- ## 5. Recurring Persuasion / Framing Devices - **Anti-dogma positioning:** *"throw away the unnecessary terminology and dogma"*, *"The point is that we don't want to impose the idea that one model is the best."* - **"It just works" minimalism claims:** *"But if you don't call any of this, it somehow works and just finds things"*, *"It just works. It is simply executed."* - **Willingness-to-delete as trust signal:** *"If it turns out that no one is using it and we are not using it ourselves in a couple of months, we will simply remove this feature."* - **"Don't promote tools, promote results":** *"don't promote tools, promote results", and let the tools be a means to an end."* - **Personal-use framing:** *"Cyrus and I build Combat Engineering, we use it every day. So in a lot of ways we're building this for ourselves."* --- ## 6. Stable Patterns vs. Isolated Moments **Stable-looking (repeated across the session):** - Objection-then-answer structure (appears at least four times: harness question, token-frugality question, "why more than one model," adoption-in-companies question). - Concrete dollar-amount and numeric examples. - Handoffs with explicit invitations and credit attribution. - Demo → explanation → usage-recommendation arc for each skill. - Enthusiasm paired with hedging ("I think," "probably," "maybe"). **Isolated or thin evidence (uncertain as patterns):** - The humorous coined terms — *"AI sandwich"*, *"token rain"*, *"dark horse"*, *"self-training"* — each appear only once; whether they are recurring catchphrases cannot be confirmed from this single video. - The mock-annoyed banter (*"That person is just trolling"*, *"This person is definitely trolling"*) occurs only in the opening minutes; it may be a warm-up behavior rather than a consistent style. - Self-correction during screen sharing appears twice (*"Oh, sorry, I'm not showing the screen"*; *"Let me share and show you. Let's see. Where is it?"*) — suggestive but not conclusive of a consistent habit. --- ## 7. Uncertainty Notes - Speaker attribution in the transcript is inconsistent (names appear as "Kieran," "Cyrus," "Trevan/Trevana/Triven," likely translation artifacts), so per-speaker stylistic differences are **not** reliably separable here. - Because the transcript is apparently machine-translated, phrase-level stylistic markers (interjections like *"Steeply"*, *"Class."*) may be translation noise rather than authentic delivery habits. # Compound Engineering Now Works Better in a Multi-Model World — Observation Record ## Source and Attribution Notes - The video is a livestream/Q&A between two hosts. One host is identified in the transcript as **Trevan**; the other appears to be **Kieran** (the transcript variously renders names, and refers to "Cyrus and I" building "Combat/Composite Engineering" — likely transcription artifacts for "Kieran" and "Compound Engineering"). - The transcript is a rough (apparently machine-translated) rendering; tool names like "Kora/Core," "Fable," "Cloud Code," and "Codeex" are recorded as they appear and may correspond to Claude Code, Codex, etc. No correction is asserted here. - No other speakers are identified; audience questions are paraphrased by the hosts and not separately attributed. --- ## 1. Philosophy of Compound Engineering ### Claims (Kieran, opening) - Compound engineering "was born out of a philosophy" while he was building Kora/Core; AI seemed promising, he started building skills and tools, which grew into an ecosystem. - **Core philosophy:** generate solutions and files within the file system to **accumulate knowledge**, so the next pass through a process benefits from prior learning. - "We think at the beginning and at the end" — the **"AI sandwich"** (term attributed to Trevan): - *Front:* think hard about the problem, with AI asking a small number of high-value questions ("three questions that will really extract everything we need," not thirty). - *Middle:* the AI generates a large volume of tokens — "the more tokens, the better. We are not afraid of a large number of tokens." - *End:* strict evaluation of output; if something goes wrong, capture it so "the system can learn for the future." - **Cost position:** efficiency is measured as *cost per task / tokens per unit of outcome*, not raw token minimization. "It shouldn't cost us $2,000 for a simple thing," but paying more for better results is acceptable. - Optimization targets the **best models** while remaining functional on less capable ones. - Goal is to **remove unnecessary stuff** over time, "because the providers will do it for us." - Scope has expanded from software engineering to general intellectual work: idea generation, product marketing, AI research, educational videos. ### Claims (Trevan) - He emphasizes removal even more strongly: he deletes skills he built only a month earlier once providers ship equivalent features natively (e.g., a "cloud optimization" skill removed after a Claude update). - The **open-source, vendor-neutral** stance is deliberate: "Cyrus and I make no distinction as to what is valuable… we are not tied to one model or one provider." - Explicit qualification: they have "a very unique style of work" and shared views, which shape the plugin — the tool embodies their opinions rather than being neutral. ### Unresolved tension (preserved) - Kieran says "the more tokens, the better," then qualifies: total cost per task must stay reasonable; Trevan adds they are "efficient with tokens, but not frugal to the point of scarcity" and will "let the 'token rain' fall if we think it is best." Later, Trevan frames accumulated knowledge as actually *saving* tokens ("she will make decisions faster and more confidently"). These positions are complementary but stated at different levels (outcome-optimization vs. raw spend). --- ## 2. Skill: POV / Oracle (multi-model perspectives) **Speaker:** Trevan (demonstration). ### Problem as stated - Agents often ask questions the user can't answer; asking another model directly imports that model's bias as a starting anchor. Copy-pasting between Claude and Grok manually was tedious. ### Solution and evolution - First version: a "point of view" skill where the agent reviews the repository, does external research, and gives its view (inspired by his friend **Paige Mann**). - Expanded into the **"oracle"** concept: unbiased prompts go out to multiple models (Grok, Codex), and the main model **orchestrates** the responses. - Demo: `/cpovv oracle` in the Orca IDE produced answers where Codex cited Apple's naming guidelines — "it's not that they are better. The thing is, they are different." - Claimed frequency: "probably more than half the time" Claude says it "completely missed something" and changes its mind after seeing other models' input. - Process: if panel models agree, the position is strengthened; if they disagree, the orchestrator proposes its own view and challenges the panel — "up to three rounds," ending in agreement, deadlock, or rejection. - Trevan predicts this "will quickly become the most used" skill for many people (though later he hedges that PR supervision may be the most common). --- ## 3. Skill: CE Explain (learning and knowledge accumulation) **Speakers:** Trevan (demo), Kieran (rationale). ### Claims - **Trevan:** `CE explain` explains PRs and repository changes; "from last Thursday" produces a weekly report — merged PR counts, most important items, a chronological timeline with "three most important moments." Recommended for teams managing fleets of agents: run it on a weekly schedule, archive reports, share on Slack or with management. - **Kieran's rationale:** automation means *he learns less* — "the more I do everything automatically, the more I realize that I learn less." Explanation is "a way of accumulating knowledge… in our own brains." - Example: asking why SSE is less common than web sockets in Ruby on Rails surfaced a prior agent research decision already recorded in the repository, combined with external data. - PR-description integration: when "commit push PR" runs, a mini-explanation is embedded so reviewers (human and agent) learn new concepts introduced by the change — "agents read PRs too… it helps to leave little clues to build knowledge in the workflow." - A **learning mode** withholds direct answers and guides the user Socratically — for meeting prep or "if you're a real VI coder and you have no idea what you did there." - Kieran connects it to the advice "read the code": "You want to read code because you want to learn, and I think CE explain offers the same solution" — he says CE explain is better, a claim of preference, not settled fact. --- ## 4. Token-Efficiency Question (audience question, Trevan answering) - "Our goal is to be efficient with tokens, but not frugal to the point of scarcity… We are focused on the outcome… the ratio of tokens to value." - Kieran adds: the real question is "is it worth paying $5 for this feature? And is it better if we spend $7?" — pay $7 rather than do manual labor. - Qualification preserved: "Are we always right? No. But we are trying to do it." He also notes other plugins on "a different spectrum" with different priorities are "totally valid." --- ## 5. Multi-Model / Multi-Harness Support (the release's headline) **Speaker:** Trevan (main), with Kieran supplementing. ### Claims - Trevan's published article (that morning) describes his shift: "Eight weeks ago I was mostly working at Opus and Claude Code… 90% of my time." He now also uses Codeex, praising the OpenAI team. - "The key is not to use the tool for the tool's sake… many tools are used only because they provide access to a certain model." - Origin: the recurring request "how do we get Fable to do the planning?" without leaving Claude Code — leading to "a deterministic way to train a model to call the CLI and have reliable fallbacks in case of changes." - Usage patterns described: - `CE plan` orchestrated in Opus, with **Fable invoked only for high-reasoning steps** — saving cost. - `CE work` delegates implementation to Codeex from within Claude Code, using the existing plan. - `LFG` skill: e.g., "LFG, plan feature [name] with Fable, implement with Codeex" — brainstorm, Q&A, plan, then parallelized implementation, testing, PR creation and oversight. - `config.yaml` supports per-tool defaults ("When I'm in Claude, use Codeex for implementation"); many users prefer trigger words for control. - Kieran: "Why do we need more than one model? … It's like asking why you need more than one browser." They "don't want to impose the idea that one model is the best." - Trevan: subscription arbitrage is part of the appeal — "you can just use all the subscriptions." Also epistemic: "unless we try different models, we'll never know if it's better or not." - Removal commitment repeated: "If it turns out that no one is using it… we will simply remove this feature." - Trevan's prediction: most popular flow will be "multimodal models for analysis, planning with Fable, and implementing code through Codex," with Grok used by some percentage. - Qualification on harnesses: "harnesses do work well, but remember that every harness is different. Codeex usually works pretty well, clock coded is also not bad, but I've had mixed experiences with other bindings when automatically calling." - Note: they do **not** use hooks to intercept everything ("We don't do that. We only have descriptions") — distinguishing their approach from other unnamed libraries. --- ## 6. Brainstorm vs. Plan **Speaker:** Trevan (answering audience question), with Kieran adding. ### Claims - Planning pre-existed; brainstorming was the first skill Trevan added after joining. Originally two documents (PRD-like and implementation plan); merged into a single plan ~3–4 weeks ago because "it is easier for agents to update and adhere to." - Trevan: if there's no ambiguity, go straight to `CE plan` — "I think this happens less often than most people actually think. Many of your ideas are bad ideas." - Brainstorm "adaptively asks questions" — deliberately **open-ended first questions** rather than multiple choice ("What do you choose: one, two, or three? This is too limiting at the start"). - New capability: Brainstorm can generate a visual sketch / launch a web server to show an interface as a guide, "not for the final design." - Trevan dismisses dogma (including Rails-community "shaping" debates): "the point is to get a clear understanding of what you are building and who you are building it for." - Kieran: "I never launch a plan; I run CE LFG," which includes planning; or brainstorm. A ticket from a smart product manager is the case for plan-only. He frames it as "product versus development in the old sense." - Counterpoint preserved: his friend Matt only uses `CE plan` — Trevan concedes people do, but argues skipping brainstorm "can be quite limiting because you don't really go through the process of maybe proving to yourself that this is a really great idea." --- ## 7. Adoption in Teams and Large Companies **Speakers:** Trevan, Kieran. - Trevan: if a team resists docs/lessons-learned in the repo, "there's probably a bigger problem." Some gitignore the folders; he says artifacts aside, "no one knows exactly what skills you are using" — judge the output (documents, code), not the method. - "Don't promote tools, promote results." The best AI-coding teams treat mixed tooling as axiomatic ("plugins, bindings, models are mostly personal preferences"). - Kieran: adoption evidence offered — used at Google, Amazon, Meta (teams/individuals, "not all at once"), by governments, and solo entrepreneurs. These are his claims, not verified facts. - Common success story (Kieran): users never announce the tool; other people's agents find the accumulated documents, and colleagues ask how the documents were made. - Trevan: accumulated repository knowledge also *saves* tokens — the system "doesn't have to constantly search for information on the network." - `compound refresh` skill cleans up obsolete documents, updates links, merges documents; Trevan schedules it weekly in some repos. --- ## 8. PR Supervision Skill **Speaker:** Trevan. - "I spent an insane amount of time on this skill. I thought it would be very simple." - Claims it is "better… than all the others" (binding-agnostic competitors): after `commit push PR`, it responds to review comments, fixes CI errors, performs safe rebases, and writes "value-focused" PR descriptions (avoiding "stupid training data about bad PRs"), embedding a CE explain section. - Monitors the PR for up to ~8 hours automatically; can also be invoked separately by passing a PR link. - Some users add to `agents.md`: "When opening a PR, always use the CE commit push PR skill." - Trevan revises his earlier prediction here: "although I said POV is my most used skill, I think supervision is probably the most common, but not interactively. It just works." This self-contradiction is preserved as stated. --- ## 9. Miscellaneous / Closing - **Discovery problem acknowledged:** "even I sometimes don't know everything we have" (Kieran). Advice: browse skill documentation; skills include summaries of what/why/how. - **Configuration underused:** Kieran admits config is "something I should use more often"; supports default models and team workflow standardization. - Beginner content: a video for beginners is promised; in the meantime, users can point their agent at the repo's documentation folder, or use `CE explain` on it. - Closing requests: share success stories on Twitter, file bugs in the repo, DM Trevan or Kieran. Kieran mentions upcoming writing on "studying/learning" and on "the polishing stage." --- ## Contradictions and Qualifications Register | Item | Statement | Status | |---|---|---| | Most-used skill | POV "will quickly become the most used" vs. "supervision is probably the most common" | Trevan revised his own claim mid-video | | Token spend | "More tokens, the better" vs. "efficient… not frugal to the point of scarcity" vs. knowledge docs "save tokens" | Complementary but stated at different levels; not fully reconciled | | Omniscience | "Are we always right? No." | Explicit uncertainty on optimization approach | | Vendor neutrality vs. opinionated tool | "Not tied to one model or provider" vs. "Compounding has its own opinion… This is our opinion about things" | Both stated; tension acknowledged by speakers themselves | | Feature bloat concern | Many new skills released vs. "the main goal is to remove what we no longer need" | Removal examples given (deleted Claude-optimization skill) as mitigation | # Video Attribution & Provenance Record **Video:** *Compound Engineering Now Works Better in a Multi-Model World* **Format:** Live-stream discussion with audience Q&A (transcript indicates a "we're on the air" livestream, also mirrored on YouTube) --- ## Speaker Identification & Roles ### Kieran (referred to also as "Kira" / "Kieran") - **Role:** Creator / host. Co-builder of Compound Engineering, identified as the original builder ("I was building Kora and I thought AI was pretty cool"). - **Spoken portions:** Opening welcome, philosophy of Compound Engineering, the "AI sandwich" framing, answers on token efficiency, brainstorming/planning workflow, adoption in large teams, closing remarks. ### Trevan (also rendered "Triven" / "Trevon") - **Role:** Guest / co-creator. Introduced by the host: *"I'm here with Trevan."* Co-builder of Compound Engineering from a product perspective. - **Spoken portions:** Deletion philosophy, demo of the `/cpovv oracle` and "explain" skills, multi-model tooling (Fable planning, Codex implementation), PR oversight skill, brainstorming skill design. ### Audience members (identified by first name only in transcript) - **Role:** Q&A questioners (unverified identities). - **Named in transcript:** Hugo (beginner question), Seth (model choice), Dave (brainstorming/planning, documentation cleanup), Kyle (large-repository adoption), Cole (harness behavior). - ⚠️ These names appear only as spoken address; no further identity metadata is supplied. --- ## Third-Party Products, Models & People Referenced - **Models/tools:** Claude (Opus), Claude Code, Codex, OpenAI, Grok, Cursor, Microsoft Copilot, "clock coded" (Claude Code?), Orca IDE, Hermes. - **Repos/platforms:** GitHub, Slack, Twitter (as a channel for replies — *"I saw him on Twitter"*). - **Named third parties:** **Paige Mann** — credited by Trevan as inspiration for the POV/oracle skill (*"which I was inspired to do by my friend Paige Mann"*). A "Matt" cited as an example of a CE-plan-only user. "Seth's question," "Dave's question" as audience references. - **Companies/organizations (unverified claims by speakers):** Google, Amazon, Meta, and governments described as places where Compound Engineering is used. > ⚠️ **Unverified third-party claims:** usage at Google/Amazon/Meta/governments and performance comparisons ("better than all the others" regarding PR oversight) are speaker assertions only. --- ## Sources & Materials Referenced - **The Compound Engineering repository** (GitHub) — repeatedly directed to for skill documentation, config documentation, and beginner onboarding. - **Apple's naming guidelines** — cited by Codex within the demo output (as shown on screen, per transcript narration). - **An agent research document** on SSE vs. web sockets in the repository, referenced during the "explain" discussion. - **Trevan's article** published "this morning" (topic: multi-model work — title not given). - **Kieran's articles** — one on the "polishing stage" published; one on learning "already started" at time of recording. - **The "Trevan CE document"** — described as a good starter example for teams. --- ## Promotional Segments (Flagged) - **Product promotion (primary purpose of the stream):** The session is a release announcement and demo of the Compound Engineering plugin/skills, including explicit encouragement to adopt it. - **Call-to-action segments:** - *"Share your success stories on Twitter… open a bug in the repository."* - Encouragement to *"subscribe"* for upcoming articles and beginner materials. - **Self-comparative promotion:** Claims that PR oversight is *"better than all the others"* and that POV is the *"most used"* skill are promotional assertions by the creators about their own product, not independently sourced. --- ## Availability & Access Notes - **Comments/Q&A:** Live audience questions were taken during the stream; transcript includes several answered questions. - **Follow-up materials promised (not yet available at recording time):** - Beginner-level video (*"A video for beginners will be released soon"*). - Additional documentation. - Upcoming articles on learning and the polishing stage. - **Config documentation:** `config.yaml` support and per-tool defaults documented in the repository. - **Removal policy stated:** features unused by the creators may be deleted (*"we will simply remove this feature"*). --- ## Ambiguities & Cautions - Names are transliterated inconsistently in the transcript ("Trevan/Trevon/Triven," "Kieran/Kira," "Claude/Cloud/Class/Cyrus") — likely machine-transcription artifacts of an apparent non-English translation layer. Identity across variants is inferred from context, not confirmed by metadata. - No curated metadata (channel, date, URLs) was supplied; only title and transcript are available. - Skill names such as "CE explain," "commit push PR," "LFG," and "compound refresh" are quoted as spoken; exact CLI spellings are uncertain. Okay, we're on the air. Let 's see. Yes, we are on the air. Perfectly. Let's wait a few more minutes for people to connect. We're also on YouTube, I think. Greetings to everyone. I'm here with Trevan, and we're going to discuss some things, or not discuss but explain what we've been working on in recent weeks, on composite engineering. And we are here so that you can ask us questions, we can answer them, you can listen, and we can do something interesting together. So prepare your toughest questions, for example, to pester Trevana, such as: why do you need more than one harness? Why can't we make everything simpler? Excellent question. I saw him on Twitter. Someone asked this and Trevan replied as if it had touched me. This touched me. There really is something there, I totally think it's a great question. Because why complicate everything? Why do we add extra? I think the main theme is where we are now in composite engineering. Also, maybe a short introduction: what's new? What is our philosophy? Because it all comes down to philosophy. Why are we adding so many skills? Is this even good? Is my context getting corrupted? Aren't we doing too much of everything? Do I really need this? Do I really have to spend all my tokens on all this? Yes, thank you. Why do you need more than one strap? That person is just trolling. Well, because. Okay, I can put that on the screen. This person is definitely trolling. Why don't we start with you talking about the philosophy of composition and the "AI sandwich" and then we'll Yeah, let's go. Okay, I'll start, welcome everyone. We're talking about composite engineering , which was born out of a philosophy: I was building Kora and I thought AI was pretty cool. But he's wrong, and I started building some skills and tools, which turned into an entire ecosystem. At some point, Trevan was thinking about the same thing from a product perspective and thought, "This is cool, all this engineering, but we need to think." In fact, the problem is no longer even engineering, because AI is doing quite well with most tasks. So how do we really understand the problem we're solving, how do we communicate and capture that in files? The philosophy is that by generating these solutions or files within a system, like your file system, you can accumulate knowledge. So you can draw conclusions and make sure that the next time you go through this process, it will actually reveal them. And yes, that's really the philosophy: make sure you learn from what you do and capture your way of thinking in a system to move to the next level where you can think more deeply. And we think at the beginning and at the end. Triven called it an AI sandwich , which is quite funny. But basically, we think hard at the beginning about what problem we are solving and activate our brain with questions from the AI. Not too many, but just as many as needed. We do n't want to exhaust ourselves with thirty questions . We need three questions that will really extract everything we need to know. And we pass this on to AI. The AI will generate a bunch of tokens. Our philosophy is that the more tokens, the better. We are not afraid of a large number of tokens. But we want to be efficient. So the cost of a single task matters . It shouldn't cost us $2,000 for a simple thing. But if we can spend a little more money to get a better result, that's what we're aiming for. This is what we want. We also optimize engineering for the best models, while making sure everything works with less advanced models . But the main focus is on doing the best, truly pushing the boundaries of what is possible. When the model returns a result, it should be excellent. Ideally, it should be excellent. Everything works . Everything looks good. If for some reason something goes wrong, make sure you comment it out and run compound so the system can learn for the future. But the point of this stage is to evaluate your work even more strictly and make it even better. And this is our cycle. We invented the cycle before cycles became cycles or graphs. Now these are graphs. I think we have a count too. We have so many skills that you could make a pretty good graph out of them. But that's where it comes from, that's what we're trying to do. And my goal is to always remove as much unnecessary stuff as possible. It's funny that we have so many new releases, but I think the main goal is to remove what we no longer need, because the providers will do it for us. So, this is a pretty important point. But at the same time, we want to expand the scope of what we do and the range of problems we can solve. We really started as a software engineering project. Now it is used for intellectual work. This can be applied to almost everything from idea generation to product marketing . You can even do AI research or specific optimization tasks, create educational videos using component engineering, if that's what you want to do . So now we cover a lot . Well, a long introduction, but that's about where we are now. I'm curious, Trevan, what you think and if I missed something. Ahem. No, I think it's great. I would just add a few points, in particular, I would emphasize removal even more . We try to delete even those skills that we had for a month. I implemented the tool and then removed it a month later because I realized it wasn't needed at all ; for example, there was cloud optimization, then Claude released an update and I said: cool, we're just removing that skill. We delete it. And I think this is the advantage of the open source approach and not being tied to a single vendor. Cyrus and I make no distinction as to what is valuable. Of course, we have a very unique style of work, the way we like to work; we have the same views on almost everything you see in this plugin. But we are not tied to one model or one provider, which is one of the reasons for this release, which really embraces the new way of working that is needed now to achieve the best results. We can talk about this in more detail when we delve into the discussion of skills. Perfectly. One question before we start. I think it could be quite difficult. Is there a way to explain this as if I were 8 years old? We will not do this. Sorry. This will be an advanced level. This will be for those who already really know what it is . We will postpone this question for later. But there are many materials that explain it more clearly for beginners. We will also work on additional documentation. A video for beginners will be released soon , which we will also make. But for now, let's focus on those who are already knowledgeable on the topic. Be sure to check out the repository. There's also a lot of useful information there. Sorry, but we'll focus on the release. One piece of advice: Hugo, you asked, you can literally direct your agent to this repository. We have prepared a lot of documentation for each skill. Just ask your question. You can say, "Hi, I'm new to this repository." " Explain it to me as if I were eight years old ." Exploring this documentation folder is a great way to start, you can even ask him to create a video for you or something similar . Yes. By the way, a new skill has appeared that can be used for this. So, first of all, you need to understand what a plugin is. If you don't know, just read this—it can be installed anywhere. But now there is a skill called "teach" or " explain". Yes. Yes. C explain Here, in the skill documentation, you can see how it works. So for all skills you can say "see explain" and then point to this repository, for example, and I have an example, Kieran, a usage that I've been using a lot since you created this skill, I could show it. Class. Google, component development, GitHub—you'll get here or anywhere. Yes. Good. Let's start with one skill. Trevon, maybe we'll celebrate the release of the new version, then you'll show off this skill , and then we'll see. Sorry, did you mean a specific skill, or do you want me to choose one myself? No, you said you had an example to explain. Oh yes, I have an example. Even two examples, actually. So let me start with the problem. Good. I didn't expect this release to have this skill when I started thinking about this problem, but it quickly became my favorite. Although I think it will be overshadowed by other work, it will quickly become the most used for many people. So, here's the problem. You create your agent and it says, " Hey, we could do this or that." "Which one do you want to choose?" You sit down often and maybe half the time you have the answer. Otherwise, you have no idea what to do. You think, “ I don’t have enough information. I'm not sure which is better." So you can tell the agent, “I’m not sure. "Help me decide." Then he develops his own prejudices, etc. So I got tired of this constant hesitation and decided to change something. Actually, bring up the POV scale. We'll start with that one, and then I'll move on to the other one. I'm actually tired of copying, pasting, and trying to figure out different models. What I did was this: I told the agent: “ Hey, here’s a point of view from Claude, your Grock. What do you think about that? The problem is that I've already set up Grock to know what Claude is thinking. Depending on how the models work, they become biased and start to evaluate that as a starting point. So I started creating better, more unbiased prompts . Hey Claude, describe to me objectively what exactly we're trying to solve so I can pass it on to another agent. I copied it, switched between them, copied Grock's answer, gave it to Claude and said, "This is what Grock said." So, the first version of the skill we made was browsing your repository to answer questions. Sometimes we might ask, "Hey, should we choose a better option for the repository?" So your agent can actually review the repository, conduct external research, and express their point of view. But after releasing the first version, which I was inspired to do by my friend Paige Mann, who started discussing it with me, I realized that it coincided with my work. I quickly expanded on the idea by asking myself: why wouldn't the system be better at giving me a multi-model perspective? That's why I created the concept of an "oracle." In a quick way, you get informed and unbiased feedback from multiple models, and then the main model coordinates the responses. So let me show you, let me share my screen. Ahem. Okay, here's an example I started experimenting with. So this is...I use Orca IDE as my development environment. In this repository—it's literally a compound engineering repository—I came up with an idea: to give ideas labels, like in the real world, so that when a crazy idea comes along, you can pick an analogy that's easy to understand. And so I started talking to Claude. Earlier in the conversation, Claude said, “Yes, that’s a great idea” or “That’s a bad idea.” So what I just did: I typed \`/ cpovv oracle\` and Claude used that skill to create an unbiased query. He turned to Grok. He reached out to Codex and actually came back with an answer saying, "Here's the solution." And you can see here, he says, "Hey, the rationale," and explains why, explains what's going on here and what he thinks. And if you scroll down, he explains his proven facts. He cites references to them. Grok said this, or rather, Grok failed to execute the web part for some reason. But here Codex quoted Apple's naming guidelines and actually worked with them. And these are all things that Claude didn't do at first. So it's not that they are better. The thing is, they are different. And what's amazing is that I can't tell you how often—probably more than half the time—Claude says, " I completely missed something," fills in the blank, "another model pointed it out, and now I've changed my mind." So, this skill starts with an unbiased Oracle panel survey. He gets answers. He analyzes them and sees: first, if we all agree, then everything is fine, and he is actually saying, "This strengthens my position." Here is a recommendation. If they disagree, the orchestrator agent actually makes the decision and goes back to the panel saying, “ Hey, here’s what I think.” What do you think about this? So now the model, the agent, already has a certain point of view, and you are challenging it. This way, you get up to three rounds of such an exchange. And, in my opinion, three rounds are quite enough for such a discussion. And as a result, you get agreement, deadlock, or rejection when they say, “Hey, don’t do this” or “ You should agree and do this.” So this is a skill that I use very often. So now here's a great way to use the skill: the next time an agent asks you a question you're not sure about, call up Oracle and say, "Oracle, do this." Or you can even do things like ask Grok, get his opinion, get Grok's opinion in Cursor. There are many ways to use this. And also vice versa: you are in Codeex, you can ask to get a Fable answer from Claude. This is a pretty clever way to do it. This is one of the things that really fascinates me. Another skill I would say—we'll come back to this in the Q& A—is a cool skill that Kieran has called CE explains. That's where we started. This skill is interesting. Kieran has a great approach to learning: he strives to understand what is happening, even when he gives agents a lot of work to do. And that pushed me to actively use the tools he provided through the plugin. I often use this to understand what is going on. And the nice thing is that this is used to explain PR. Agents do a lot of work. This is a great help in staying on top of things. I often catch up on changes in the repositories. In some repositories where I work. One of the cool features is the CE explain from last Thursday. She comes in and explains to you exactly what happened. Now I'm going to share it right here. Let me share and show you. Let's see. Where is it? Here are the idea tags. Yes, I launched "from last Thursday" for compound engineering. She does a complete review of your week and tells you. It shows how many PRs were merged. Determines which ones are most important. Talks about the Oracle panel that I added to common engineering. It talks about project management skills, about how I manage time. And the last one is to improve the model of how cloud code works and how it improves. This is interesting for those who work in teams, especially for leaders, team managers, or those who manage a fleet of agents. It shows a timeline of what happened and highlights three most important moments . Here's when they happened, in chronological order on the timeline . So I find it an extremely impressive way to find out what's going on and keep up with things. And I think many will probably understand this, because with more agents comes more work and more branches of discussion. Many people feel overwhelmed by questions: how to monitor events without reading all the chat logs and checking everything manually? Therefore, the way to use this skill for teams with many agents is to run it cyclically. Run it on a weekly schedule. Run it from last Monday or any other date, get the report and just read it. You can also archive these reports, review them, share them on Slack with your team, or use them for presentations to management—a great way for those working in large companies. So, those are the two options I'm going to focus on, that's where I would probably start. Yes, these are great ideas. And it all came from the idea that accumulating knowledge is wonderful. But as you continue to accumulate data in your database or project , there is another aspect to learn and accumulate— your own knowledge. And the more I do everything automatically, the more I realize that I learn less. Yes, I release a finished product, do a lot of work, study agent engineering and all that, but I study less new technologies or concepts . And I hear this from other people who are more into agent engineering: explanation is a kind of way of accumulating knowledge, but already in our own brains, as a way of structuring what we think and a way of learning through change. You can do different things here, for example, it could be a concept. You might say, " Hey, I use a lot of web sockets in Kora, for example, but SSE is more commonly used for streaming in most places." So I ask: "Why is SSE less commonly used in Ruby on Rails, for example?" And explain this concept to me , and of course you can do it in a normal environment. But the most interesting thing is that it will be based on a repository. And in this case, he actually found a study done by an agent where he was investigating using SSE for streaming and decided not to do it due to the specifics of the server setup . I had no idea about it, I hadn't read it, but he took it out of context and backed it up with external data, which is really cool for development. So, it's mostly what you were saying, "Hey , what was released?" What has changed? Do I need to learn anything? I think it's interesting. And it will also do this: if you run a PR, or the command "commit push PR", it will do a kind of mini version of the explanation. So, in the description of your merge request (PR), if it introduces a big new concept, it will explain what it is and say, "Hey, you can learn more by running this command," and explain those things. So for larger features where you haven't reviewed all the details of the plan, this is great for making sure you catch larger changes and can integrate them for your team members or people working in the same repository. This explainer in the PR description is very helpful because often, when reading the PR, you don't quite realize that a new concept is being introduced : a term, a general idea, a data structure, or something important to the system. This is a great way to help the people who are reviewing your PR, but then again, agents read PRs too , so it helps to leave little clues to build knowledge in the workflow. Yes . So it's part of the workflow. There is one more point. There is also a learning mode. He can give examples, not giving a ready-made answer, but suggesting that you go through it yourself. It's very story-oriented. It's not about giving an answer. It's like, "Hey, this is how thinking works, what do you think about it?" So if you want to learn something, like prepare for a meeting, or if you have to talk about something and you're asked follow-up questions, or, uh, if you're a real VI coder and you have no idea what you did there but you still have to answer the question, then it's worth knowing exactly why you did it that way. This is exactly the tool that is worth running to get answers to all possible questions, I hope. Hmm, I think this is extremely interesting. I'm going to, I've actually already started writing an article about this. So I'll share the thoughts behind it . But I think it's really important, especially if you've been doing agent programming for a while, you realize, "Oh my god , I need to keep learning." Some say "read the code," and this is one version of such learning. I think C explain is better. But if you hear people advising you to read code, that's basically my variation on that theme. And the reason is not to read the code because you want to check if the AI ​​did something. You want to read code because you want to learn, and I think C explain offers the same solution. The question that someone asked—you want to highlight this issue regarding the effectiveness of tokens. We can talk about Oh, yeah. Good. Sorry. It was quick, I just said, "Hey, how does compounding work, C explain , load it up." And this is like a document that also comes out of that. So he creates cool explanations, by the way. Steeply. Come on, let's do a little bit, let's answer the questions. Uh, maybe, yes, that issue we talked about earlier, maybe even before you came. Our goal is to be efficient with tokens, but not frugal to the point of scarcity. We are not trying to save tokens. We are trying to use them in the best way possible, and we will let the “ token rain” fall if we think it is best. So we pay attention to how many tokens are spent, but we don't try to save them for the sake of saving. That's the best way to explain it. I think there are people who, you know, have other plugins and skills that are on a different spectrum and care about other things, and that's totally valid. They have a different focus. We're not that focused on that. We are focused on the outcome, and it is worth thinking about it as the number of tokens per unit of outcome or the ratio of tokens to value. We are trying to maximize value and are willing to spend as many tokens as possible to achieve it. Yes. Ahem. Yes, of course, if we can get more, but we understand that no one wants to pay hundreds of thousands of dollars a month for simple things. Ultimately, the main thing is not to look at the tokens, but to assess how much it costs to implement the solution. And I think that's what we're trying to optimize for: is it worth paying $5 for this feature ? And is it better if we spend $7? Then I think it's better to pay $7 instead of $5 than to still do a bunch of manual labor. The goal is to simply get the best possible result from the models. Um, and at some point everything starts going in circles and doesn't get any better. And this is our goal. Are we always right? No. But we are trying to do it. And each model is also different. So maybe this is the way to go for using multiple tools . Yes. Update, because this is an important point. Yes. Yes. So, a few tools. This is a bit related to Seth's question about choosing the right model for a specific task . I think it's not just a trend, like, I don't know, in my article that I published this morning. Eight weeks ago I was mostly working at Opus and Claude Code; these were my main working tools. I spent 90% of my time there. Gradually, I started using Codeex more. I think the OpenAI team is doing an incredible job, constantly adding new features, but the key is not to use the tool for the tool's sake. Tools are a matter of preference; people like them more. But, to be honest, I think many tools are used only because they provide access to a certain model. Of course, there are exceptions. There are some tools, like Cursor, that support multiple models. I know Microsoft Copilot supports multiple models. Um, but there are others where that's not the case. Claude Code—no, Codeex—no. I know there are various tricks, and people will start to argue, saying you can do this and that, but in general these tools don't support them. So the question is, the two most popular tools—Codeex and Cloud Code, you know, a lot of people use them. The idea was born from the question: “What if you want to go beyond the usual and get the job done?” The most common initial request was, "Hey, Trevan, how do we get Fable to do the planning?" The idea was, “Well, switch the model to Fable, do some planning and brainstorming, but don’t forget to switch it back to the other model before you start; otherwise you'll run everything on Fable or something like that and use up all the credits, or, when there was API billing, pay a bunch of money." So it all started with this idea, and then I started thinking: okay, wait a minute, what's next after Fable? What else can we do? And it became really interesting to build what started as something small and grew into something big: a deterministic way to train a model to call the CLI and have reliable fallbacks in case of changes. So I created a pretty good system that I'm quite happy with. I think there will be mistakes and stuff , but here's what you can do, and it's hard to explain briefly because the system is so large. But I'll give you a few examples: many people start C plan, submit an idea and want to plan with it, they don't brainstorm, they just plan. So you can use Fable at the end of this process. You can work in Opus with any level of reasoning; you can run a C plan, it will be orchestrated through Opus, but for specific steps that require high level reasoning, Fable will be used to get the benefits of Fable without spending it on the entire process. So, this is a way for us to somewhat manage tokens and things like that. Another option that many people talk about: I have unused subscriptions that I want to apply to implementations, and I like these models, but I want to stay in Cloud Code. Perfectly. CE work uses Codeex. So, if you are in Cloud Code, it will perform the implementation in Codeex, delegate the work there, and use the created plan. He will parallelize the processes as much as possible and figure everything out himself. You can even use Grok in CLI or Cursor, that will work too. There are many options here. And Kieran, for example, used the LFG skill , I added more options there. You can do things like "LFG, plan feature \[name\] with Fable, implement with Codeex." So you can be in Cloud Code and do it there. This is the LFG implementation table. The example he highlights here is a very common usage. I brainstorm the feature, go through interactive Q &A, review visual examples, and carefully work through requirements and scenarios. Then I say, "Great, that suits me." "LFG, implement using Codeex." He will start the execution of the plan. He will do everything in Cloud Code, and when it comes to implementation, he will use Codeex. It will parallelize tasks where possible, and LFG is great because it will continue testing, open a PR , oversee it, and prepare it for merge. Maybe I'm missing a lot , but if you go up a level, the "point of view" skill made it possible to use the knowledge and opinions of several models to form a conclusion. Other skills now have the ability to refer to other planning models and use other tools as needed. During planning and implementation, and again , if you don't want to do it, you don't have to. He wo n't do anything. But for those who want to do this all the time, there is a config.yaml file. YAML file, we support it. There are configuration changes in the documentation where you can set defaults and the skills will read them. The repository has a file describing the configuration parameters that can be defined for each tool, so you can say: "When I'm in Claude, use Codeex for implementation" and so on. But in general, many people use it with trigger words in the query because they want to have more, um, more control. So I'll stop there. I think this is where the huge potential lies, and I'm really interested to see how people will use it. I would guess that the most popular approach would be to use multimodal models for analysis, planning with Fable, and implementing code through Codex—this will probably be very common. Grok will probably also be used by at least a certain percentage of users. Yes. Perfectly. Plus, this already worked in Cursor, because Cursor is multi-agent, and it's great that it works everywhere now, because some people just prefer one model over another, and the question arises: why do we need more than one model? We need more than one model because people have their own preferences. It's like asking why you need more than one browser or why you need more than one option. Yes, that's right. Yes. The point is that we don't want to impose the idea that one model is the best, so you can only use it, because that's not the case. She is very good, like any other; This is exactly the one I would use . I also often use Cursor and Codex, but everyone chooses what is more convenient for them at a certain stage. And the coolest thing is that now you can share the results of your work much more easily. And you don't have to copy and paste all the time . It just gives more flexibility. I think giving people the opportunity to experiment with all of this will help us understand what works well and what doesn't. If it turns out that no one is using it and we are not using it ourselves in a couple of months , we will simply remove this feature. But I think this is the only way because we are not tied to anything. You could say, "Why do n't you just make it open source or something like that?" Then you can do everything. I think the choice of model is important, because they really work differently. Yes, they are becoming more and more similar to each other. But they are very different, especially for people with an engineering mindset who might prefer Codex , 5.6, or some other model. Maybe someone wants to plan or brainstorm; Maybe Claude is better suited to, for example, the Opus model, and it's great to have a choice. And I think probably the most important thing is that you just use, let's say, Fable, and you're like, "Oh \[ \_\_ \], I'm done," uh, let's use my OpenAI subscription or my Cursor subscription and. and you can just use all the subscriptions, uh, and the cool thing is, even if one is better than the other, unless we try different models, we'll never know if it's better or not, because I mean, how do you think about it, everyone, I mean, it's a little selfish if you look at it this way: Cyrus and I build Combat Engineering, we use it every day. So in a lot of ways we're building this for ourselves, and it just so happens that there are a lot of people who want to use it too. So we also switch between different environments . So this also happens. And so I think we've obviously considered broader needs and expanded the capabilities in ways that we probably wouldn't use, you know, but still I think it follows the main line of how we typically use things and what we recommend, so you feel like Compounding has its own opinion, because it does. This is our opinion about things. Uh, so yeah. Yes, that's a great question, Dave. So, uh, Kira, I can take it on if you want. Uh, brainstorming and planning. Okay, so the planning already existed, uh, was pre-existing. Uh, and I added brainstorming, that's probably the first skill I added, uh, when I joined, and it's been evolving. That's how, uh , evolution was, planning was at the beginning. There was an implementation plan, and I realized that, okay, we need more requirements. we need more brainstorming, like ideas, it's like regular product work. So I added brainstorming, and initially they wrote two different documents. One was traditional, like the PRD, and the other was an implementation plan. About a month ago, uh, or three weeks ago, I actually merged these documents. Now this is the only plan. From a logistical point of view, it is easier to manage. It is easier for agents to update and adhere to. But the way I do it—it's one of many ways to do it. So, here's what I'm going to suggest: if there's no ambiguity and you're just creating a technical implementation plan, you just go straight to the C plan. This is completely normal. I think this happens less often than most people actually think. Many of your ideas are bad ideas, and many of your ideas could be better if they were tweaked a little. Brainstorm is like having the smartest product specialist in the world working with you and asking tough questions like: Why are you doing this? For example: are you sure? But he doesn't just ask the standard "why are you doing this" questions every time. It adapts to your problem, and you can come up with either the craziest or the simplest idea. The magic is that it adaptively asks questions to help you refine your idea. It tries to ask in a way that is truly effective, without limiting you to a choice of several options. I made a very conscious decision at the very beginning: the first question is usually the one that needs to be answered in detail. Because instead of saying, "What do you choose: one, two, or three?" This is too limiting at the start, especially if the idea is quite ambitious. And then I added this: Often Brainstorm will force you to choose between options, like, "Hey, would you rather do this or that?" Now Brainstorm can offer a sketch, launch a web server, and show you a web interface—not for the final design, but as a guide. For example, imagine you're building a chat app and you want to display a notification icon or something similar. Of course, someone can explain it in words, but often the easiest way is to see it with your own eyes. So, Brainstorm is a great way to explore scenarios, requirements, and test ideas for robustness before moving on to the “Okay, agent, let’s figure out how to implement this” stage — that is, to plan the work, approach, and method of solving problems before development begins. So I think there are many ways to approach this—traditional PRDs, etc.—but my approach is to step back, to throw away the unnecessary terminology and dogma. Since I know there is a lot of talk in the Rails community about the “shaping” that Dave mentions, the point is to get a clear understanding of what you are building and who you are building it for. Are you ambitious enough, or perhaps too ambitious? And then improve everything based on that. This is exactly what these two skills are for. So, in general, I advise starting with CE brainstorming and then moving on to CE planning. Well, you know, I, I know a lot of people. My friend Matt, for example, only uses the CE plan, and people really do. But I think in many ways it can be quite limiting because you don't really go through the process of maybe proving to yourself that this is a really great idea. Yes. And the way I look at it, the skill of brainstorming also involves human participation. It's supposed to activate your brain and make you think. And the CE plan is simply when you give him one thing and he builds it, essentially it's part of the first step in LFG. So me, I never launch a plan; I run SL LFG. So it's either brainstorming or I run an LFG, which includes planning. And if you work in a team, you might get a ticket and the product manager has already thought of something; you just need to implement it. I, I don't know, maybe you can brainstorm again, and they probably missed something. But let's say you have a very smart product manager who has created something and is handing it over to you to implement. I think that's really the plan then. So it's also like product versus development in the old sense. Although we do it now, maybe it works that way too. The question is: "Hey, I love CE. I use it for my personal stuff. What are some tips for using it in larger projects, repositories, where CE is not yet used as a workflow?" I mean, this is actually a common question. Many, many people are successfully using this in large companies, and I think there are many ways to do it. There is no universal solution, but in general, I would give some advice, Kyle: if your team is not ready to have documentation and lessons learned added to the repository. I think there's probably a bigger problem, you know, but what could you do— some people add these folders to gitignore, and that's okay too, because they don't know. But I would say that apart from the artifacts that are added, no one knows exactly what skills you are using. So, I would say this: listen, you have to submit documents and explain to people that they shouldn't care about how you do your job. That is, if they believe that the document you submit or the code is of poor quality, then that's a different matter. This means that your skill, method, or tool is not producing the result the team expects. So I think if you present it that way, most people won't have to worry about it . But I know that in large companies and teams sometimes difficult moments arise, like: “Oh, we don’t use this plugin, we use this one .” And I think a lot of teams are coming to understand that plugins , bindings, models are mostly personal preferences, and there's a lot of mixing and matching going on now. So I think the best teams implementing AI programming right now are open to this fact, accepting it as an axiom, and figuring out how to set up the repository and what team processes and culture are needed to do that. So everyone— Kyle, for example—can use a component engineering solution, someone else— superpowers. Someone else might not use plugins or skills at all, but just do "bare" queries, I call it " self- training", and all of that should be possible. So, I think this is probably the best approach. If the question is how to popularize it? I would simply popularize this using my own example. Show through action. Just keep doing it, show results, and share success stories. People usually get used to tools that produce significant results. Yes. And some say that's great, but in a corporate environment it's hard to embrace it and promote it horizontally and vertically for context. I use this every year. Again, if you just start using it, this will be the best way. Just share how you apply this to your workflows and how it helps you work better. This could be explaining the code or creating a document that, for example, pulls out everything that was released in a week. These can be simple things to start with. One very good example is looking at the Trevan CE document, which is just wonderful. It's like a thorough interrogation of a document, asking difficult questions about it. This is also a good way to start. But I know it's used in Google, Amazon, and Meta. Not all at once, but there are teams or individuals who are promoting this in huge companies. I know it is used by governments. I know that many solo entrepreneurs use this. This is very useful in various situations. I don't think you have to implement it completely. You can simply apply this individually and inspire others. I think this is the best approach, because forcing engineers to say, "Okay, now you have to use this plugin" is quite difficult. But it's easy to show them how cool it is, how it all works, or how it's different from superpowers or other tools. One of the best and most common stories I hear from users of such engineering is that they never talk about it. The accumulated knowledge goes into a repository, and other people's agents find these documents. And then someone asks them, "How did you create this document? Where did it come from? This is very useful. How do I add documents like this?" So, this is another way to show everything in practice. Everything that Kieran said, and everything that I said before, I think is entirely appropriate here. Therefore, I believe that it is worth looking at this through the prism of "don't promote tools, promote results", and let the tools be a means to an end. Another thing to say is that it is more efficient with tokens. We need to get more data, do more assessments, but we've already done some of them . This showed that if you have this knowledge, everything will work more efficiently because the system doesn't have to constantly search for information on the network and check everything. So when these documents appear in your repository, she will make decisions faster and more confidently. So, it is actually more efficient in terms of tokens and provides higher quality in the long run. You can even present it as a way to save tokens. Yes. I think you can explain it this way: listen, all your agents are learning on the job. They stumble upon certain things. They get code reviewed, do something, and learn important lessons. Why are you making another agent learn this all over again when they are working on the same section of code? So the skills of accumulation create documents so that this knowledge can truly multiply. There's an instruction in my agents MD file , which is actually in the documentation, in our skill documents, that says something like this: "When you're learning, when you're faced with something, when you're solving something difficult, suggest running a difficult CE skill." Great, I often let sessions run, it just starts, and I have it set up to autostart when the need arises and it becomes part of the commit. Dave, you mentioned cleaning up the documentation; We have a compound refresh skill that essentially does this for complex engineering documents. So I have it scheduled to run weekly in some repositories, it cleans up, removes obsolete documents, updates links, and also merges documents when needed. Yes, this thing is great. Ahem. Yeah, there are lots and lots of skills, and even I sometimes don't know everything we have because Trevan adds so many cool things, and other people add things too . I would advise everyone to review the documentation on complex engineering skills, just scroll through here and click on what seems interesting. For example, if you don't know what it is, you say, "Oh, what is it?" And here is a good explanation with a brief summary at the beginning about what it can do, why and how. So be sure to check all of these out, because they're really cool . Configuration is something I should use more often. I know there's a lot more customization possible here. You can set, for example, default models . Now you can also say, " Hey, use these skills or these reviews ." This is required for customization for your team if you want to standardize workflows. Oh, sorry, I'm not showing the screen. That's it. Boom. Now you can see it. So, configuration... This is exactly what I was talking about, and you can see that all the skills here have pretty good documentation, so you can just read everything. Here, for example, is compound refresh: it says what to do with it, when to use it, what it does, and sometimes there are different modes, such as headless or interactive mode. This is for the conveyor that we have . So, yes, you should check them out yourself or have your agent do it, because you can learn a lot from them and discover things that you never even knew were there, and if there's anything missing, please add it. And there is one habit that we will probably soon get rid of. There is one skill that received an immediate update, and it's a mystery to me why we didn't do this sooner, is the "PR oversight" skill . Oh yes. I spent an insane amount of time on this skill. I thought it would be very simple. No problem. The time I spent getting this to work properly is simply amazing. So what she does, everyone does. You saw Claude, all the other bindings have it. This is better, I promise you, better than all the others. Uh, the best. She will oversee the PR after you open it, respond to and deal with any code review comments. It will fix CI errors. It will automatically and safely perform a rebase, figuring out if the master branch has changed and how to bring everything up to date. All those annoying things that are annoying when your agent opens a PR and you realize: oh, here are four comments, the main branch has been updated, how do I do a rebase now, and all that stuff. So when you use the commit push PR skill, it will open a PR with a great, value-focused description, done right, avoiding all the pitfalls that agents usually make because of stupid training data about bad PRs. It will include an explanation from C explain and then automatically monitor the PR for, say, 8 hours if you wish . And you often don't even have to do anything to enable this supervision. It will run automatically if you use the commit push PR skill. But if you don't want to use it, you can babysit PR separately by simply passing a link to the PR or something similar. Some people use this in their agents.md files. They add the instruction: "When opening a PR, always use the CE commit push PR skill" along with the oversight, and this ensures that your agents will follow the skill even if they try to do something different. So I think it's a " dark horse," even though I said POV is my most used skill. I think supervision is probably the most common, but not interactively. It just works. Yes, it just works. It is simply executed. Is this part of LFG? Uh, it will work as part of LFG, because it will be called via commit, push, or PR. Yes. Good. My favorite skill is LFG. If you don't know what that is, look it up. In general, you can simply say LFG brainstorm, LFG the brainstorm, or LFG with a plan. Now you can say Codeex with this model or whatever, but essentially it will do all of this. So if you're a beginner, give it a try and it will use everything that's "under the hood". Also, if you don't call any of this, it somehow works and just finds things from compound engineering, and I know there are other such unnamed libraries that implement hooks to intercept everything. We do n't do that. We only have descriptions. Yes. In my Hermes box, I only have competent engineering. Of course, Hermes has his skills, but this allows you to simply tell the oracle this. He will automatically use the POV skill, so yes, depending on the situation, Cole is right: harnesses do work well, but remember that every harness is different. So, Codeex usually works pretty well. Uh, clock coded is also not bad, but I've had mixed experiences with other bindings when automatically calling. Yes. Class. This is great. I think let's celebrate this release. I am very excited. Let's see what people will do with this. Please let us know if this works or not. Share your success stories on Twitter. Spread, reveal as much as you can. Even if it's something general, we'd like to hear about it. If it doesn't work, please open a bug in the repository. I'd love to know about it , or DM me or Kieran. We try to continue to make it great for everyone. Yes. Thank you very much. And we will have more materials for beginners. We hear you. Trevan and I are just really excited about everything new. But we're going to make it easy to get started. I'm going to write about studying. I just wrote about the polishing stage. If you haven't read where it comes from and how to use it, subscribe to stay up to date . And so, see you next time.