Charlie Holtz, co-founder and CEO of Conductor (a desktop app for running many coding agents at once), shares principles common to the most effective AI-assisted builders: staying near the frontier without trying to beat the market, creating 'slop-free zones' that always receive careful human review (migrations, docs, skill files), feeding agents a unified database of Slack messages, bug reports, and meeting notes, and giving agents free range via cloud sandboxes that keep running after you disconnect. He demos a new Conductor version with real-time collaboration, cloud-based agents, and starting agents from your phone, and argues for an 'orchestra' model — humans conducting teams of people and agents — over a 'software factory' mindset. # Channel Presentation Observations — "Orchestras, Not Factories" (Charlie Holtz, Conductor) ## Intended Audience - **AI engineering conference attendees and practitioners.** The speaker explicitly contrasts outsiders with this audience: > "I said it was about AI engineering. And I could just see his eyes glaze over... it's so cool to actually be in a room full of people who actually want to hear about this stuff." - **Professional software builders using or evaluating coding agents.** He assumes familiarity with tools like "Cloud Codes" (Claude Code), "Code Accesses" (Codex), work trees, CI, migrations files, and `claude.md` files: > "instead of having a bunch of terminal windows for your Cloud Codes, your Code Accesses... you have one interface to manage them all." - **Builders inside companies or startups**, addressed directly with role-based framing: > "if you are doing your own startup... and if you're not doing a startup, you should be the person at your company who always knows what the latest workflows are." ## Claimed Scope - The talk claims to distill **principles for being "the fastest builder in your organization,"** compiled from firsthand observation: > "I've seen a lot of the best builders up close... I thought I would compile a bunch of the principles um that I've seen the best engineers use." - The claimed scope is a **six-principle framework** (frontier adoption, "don't beat the market," slop-free zones, "feed the beast," free-range agents, "orchestras not factories"), packaged with a mnemonic: > "Came up with this handy acronym for for remembering it. Stickfo." ## Self-Description Evidence - **Product identity:** "I am the co-founder of Conductor... Conductor is a desktop app for managing a team of coding agents all at the same time." - **Origin story tied to frontier tool adoption:** "We were such power users of cloud code back in February of last year... bit by bit we had built conductor as an internal tool." - **Positioning against an industry term:** "The whole like talk track today is about software factories. And I honestly kind of hate the term." - **Values claim about tooling:** "because we're all building these tools we actually have a responsibility to make the tools great for humans." - **Product announcement embedded in the talk:** a new cloud-collaboration version of Conductor — "we're rolling this out to all conductor users this week." ## Demonstrated Presentation Patterns (observable, not claimed) - **Personal anecdote as a hook** (the wedding story) to establish shared identity with the audience. - **Live product demo integrated into principles** — cloud sandboxes, real-time collaborative workspaces, and a Telegram-controlled agent ("Lord Crandon") shown in operation. - **Insider vocabulary as community signaling:** "slop free zones," "token maxers," "midwit miming," "Ralph loops," "the CIA" (Conductor Internal Agent). - **Reference to external cultural artifacts** (a tweet about agents + SQL, a Steve Jobs analogy) to anchor arguments. - **Humor and unscripted moments** left in the presentation (waiting for a teammate to type, "The agents have escaped"). ## Distinguishing Claims vs. Demonstration - The **claim** that these principles come from observing "the best builders" is a creator statement, not independently verifiable from the transcript. - What the material **demonstrates** is Conductor's workflow-centric design (cloud sandboxes, shared workspaces, API-driven agent spawning) consistent with the stated principles of "free-range agents" and collaboration. # Delivery Observation: Charlie Holtz — "Orchestras, Not Factories" ## Overall Communication Style The delivery is **conversational and narrative-driven**, built as a list of numbered principles punctuated by personal anecdotes, product demos, and humor. Holtz consistently frames abstract advice through **concrete, specific examples** ("we started cloning our repo five times, and then we discovered work trees"). --- ## Recurring Phrases & Vocabulary - **"Stay near the frontier"** — repeated as the core principle, then deliberately dissected: *"And there's an important word here, near."* - **Frontier vs. at the frontier** — a distinction he explicitly draws: *"you're to decide if you're near the frontier or at the frontier."* - **"Feed the beast"**, **"free-range agents"**, **"slop free zones"** — memorable, metaphor-heavy coined terms naming each principle. - **"Real alpha"** — borrowed finance vocabulary: *"unless you have like real alpha you shouldn't be optimizing your workflow too much."* - **"I want to feel like..."** — anaphora in the closing section: *"I want to feel like a human. I want to like be in the flow. I want to be like in front of an orchestra."* Also *"I want my software to feel human and crafted."* - Note: he audibly says **"mid-whip miming"** and **"slot free zones"** in places — likely transcription artifacts of "midwit meming" and "slop free zones," but as delivered they appear in the transcript verbatim. --- ## Teaching Habits - **Numbered principle scaffolding**: *"let's start with number one, stay near the frontier"* through *"four. Feed the beast"* and *"The final principle."* The talk ends with an explicit recap and a mnemonic: *"Came up with this handy acronym for for remembering it. Stickfo."* - **Rhetorical question heuristic**: he teaches via a question to ask oneself — *"you should ask yourself why isn't this workflow the default?"* - **Analogy as teaching device**: - Intern whisper analogy: *"if you had a new intern that was joining your company, and you had the opportunity to like whisper something in their ear every time they started working."* - Efficient market hypothesis analogy for workflow optimization. - Conductor-as-orchestra metaphor as the thesis. - **Live demo with audience narration**: *"That's me. And here are a list of the things that I am working on."* He narrates waiting in real time: *"Seems like he's typing a lot. Okay, maybe he stopped typing. I'll give him a second."* - **Humor to recover from demo friction**: *"Okay, come back. The agents have escaped. All right."* --- ## Communication Patterns - **Self-deprecating or situational cold open**: starts with a wedding anecdote about an eyes-glazing listener, contrasting it with the room: *"it's like so cool to actually be in a room full of people who actually want to hear about this stuff."* - **Frequent audience check-ins**: *"has anyone here used Conductor?"* / *"can you can you guys see this?"* - **Named-coined-concept habit**: nearly every idea gets a label (Conductor Internal Agent → *"also known as the CIA"*, "don't beat the market", "midwit meming"). - **"Like" and "uh" fillers throughout**, plus repeated doubled words ("I I", "you you", "the the"), indicating an unscripted, spoken-flow delivery. - **Values-forward close**: pivots from tactics to worldview — *"we actually have a responsibility to make the tools great for humans"* — before returning to the principle recap. --- ## Stable Patterns vs. Isolated Moments **Stable (repeated across the talk):** - Coined metaphorical labels for each concept. - Teaching via analogies and self-question heuristics. - Supporting claims with first-person Conductor anecdotes ("this literally happened to us", "this actually happened to us"). - "I want to..." anaphora in the final section. **Isolated (thin evidence, one occurrence each):** - The "Stickfo" acronym joke — only stated once, without elaboration. - The live-demo recovery humor ("the agents have escaped") — a single moment, though demo narration itself is sustained. - The Steve Jobs reference: *"I want to feel like I'm Steve Jobs designing the Mac"* — one-off aspirational framing; no broader pattern of name-dropping. # Observation Record: "Orchestras, Not Factories" — Charlie Holtz, Conductor ## Speaker & Context - **Speaker:** Charlie Holtz, identified in the transcript as **co-founder of Conductor**, a desktop app for managing multiple coding agents in one interface. - The talk distills principles Holtz says he learned by observing "the best builders up close" through running Conductor. - Positions below are drawn exclusively from the transcript; no private beliefs are inferred. ## Six Stated Principles for Being "the Fastest Builder" ### 1. Stay near the frontier - **Claim:** Builders should try the latest tools "basically the day they come out." - **Reasoning:** Social-graph-driven information flow is too slow now — "You're always going to be three to six months behind if you do that." - **Supporting anecdote:** Conductor emerged as an internal tool while Holtz's team were power users of Claude Code, cloning repos five times before discovering worktrees. ### 2. Don't try to beat the market - **Claim:** There's a danger of being *at* (not near) the frontier — what Holtz calls **"midwit miming"**: "spending all of your time working on your workflow and not doing actual work." - **Heuristic:** Ask **"why isn't this workflow the default?"** If a practice (his example: Ralph loops) works for everyone, wait for Anthropic or OpenAI to build it into the default harness. - **Framework:** Likened to the efficient market hypothesis — only invest in workflow optimization if you have **"real alpha"** (information about your users or codebase the models don't know). His example: Conductor's need to render long chats quickly justifies workflow investment. ### 3. Create slop-free zones - **Claim:** Conductor is "unusual" — people assume they're "pure token maxers" shipping 30,000-line PRs, but they apply strict human review to sensitive areas. - **Qualification / admission:** "We've had to rewrite our whole app like a couple of times because we weren't careful about slop free zones." - **Practices cited:** - Migrations files require human review in CI. - Slack content is assumed human-written ("slop free"). - Heavy investment in docs, CLAUDE.md files, and skills. - **Analogy:** The CLAUDE.md is like whispered guidance to a new intern every time they start working — so it deserves that level of care. He notes the best builders put "an unusual amount of time" into these files. ### 4. Feed the beast - **Claim:** Agents are only effective with maximum organizational context, centralized in one place. - **Practice:** Conductor's internal tool, the **"Conductor Internal Agent" (CIA)**, ingests Slack messages, Discord bug reports, and recorded meetings into a Postgres database. - **Endorsement:** "It's really effective to just put everything in a database and then give your agent a SQL tool and let it handle the rest." ### 5. Free-range agents - **Claim:** Agents should run in sandboxes unconstrained by the builder's laptop — able to explore, work on hard tasks, spawn more agents, and collaborate. - **Reasoning:** Models are improving, running longer, and multiplying in number; confining them to a laptop limits their effectiveness. - **Product demonstration offered as evidence:** - New Conductor version (announced as rolling out "this week") moves tasks from git worktrees to **cloud sandboxes** that persist after the laptop closes. - **Real-time collaborative workspaces** — Holtz demoed reviewing and messaging a colleague (Caden) inside a shared workspace, calling collaboration "one of the most important new concepts... that no one is really talking about right now." - **Agent self-spawning via API** — demoed texting his "OpenClaw" agent ("Lord Crandon") via phone/Telegram to create a workspace and kick off work remotely. - **A conceded caveat:** "All great things are built with teams of people... they're not built by individuals," and ambition requires more people and agents. - **Contrast:** Rising ambition (he references "the two days of Fable") means teams need more collaborative tooling. ### 6. Orchestras, not factories (title principle) - **Claim:** Holtz "honestly kind of hates" the term "software factories" and considers it the wrong mental model. - **Reasoning:** - Factories connote automation and "factory line managers pushing buttons" to pump out features. - He invokes the earlier failure of the "feature factories" concept: "we tried this like 10 years ago... and it just doesn't work." - **Preferred vision:** Feeling "like a human at the center of it all" — "waving my baton" in front of an orchestra of humans and agents, zooming out most of the time and zooming in when desired. He likens it to "Steve Jobs designing the Mac with a team of amazing humans and AI agents." - **Normative claim for builders:** "Because we're all building these tools we actually have a responsibility to make the tools great for humans," including using language that makes people feel "excited," "capable," and "in the flow." ## Summary Framing Offered by Speaker - Holtz packages the six principles into the acronym **"Stickfo"** (Stay near the frontier, Try/beat market caveat, Create slop-free zones, Feed the beast, Free-range agents, Orchestras not factories). - Closing: an open invitation for questions and to connect online. ## Unresolved Tensions & Qualifications Preserved - **Tension between principles 1 and 2:** Holtz simultaneously urges daily experimentation with new tools and warns against workflow over-optimization; the "near the frontier" vs. "at the frontier" distinction and the "real alpha" test are his stated resolution, not a settled rule. - **Contradiction with audience expectations:** He explicitly rejects the assumption that Conductor users maximize output, while also advocating agentic scale ("give them opportunities to create more of themselves"). - **Live-demo friction:** The collaboration demo showed delays ("Seems like he's typing a lot... Okay, maybe he stopped typing") and Holtz joked "the agents have escaped" — presented as-is, not smoothed into a flawless product claim. # Speaker & Provenance Record ## Video Identification - **Title:** *Orchestras, Not Factories: How the Fastest Builders Work — Charlie Holtz, Conductor* - **ID:** `01a15ca7-2740-7a11-9fbf-8079dcc8d1bf` ## Speaker Roles | Speaker | Role | Basis in Transcript | |---|---|---| | **Charlie Holtz** | Presenter; **co-founder of Conductor** | Opens with "Hello... I am the co-founder of Conductor"; conference presentation at an AI engineering conference | ### Additional Named Individuals (mentioned, not speakers) - **Caden (spelled "Cadence"/"Caden" and "Kaden" at various points)** — colleague shown working in a shared Conductor workspace - **Lewis, Tywan, Jackson** — teammates visible in the collaboration demo - **Steve Jobs** — invoked rhetorically ("designing the Mac") - **Lord Crandon** — the presenter's personal "open claw" (OpenClaw) agent, used in a Telegram demo - **"CIA" (Conductor Internal Agent)** — Conductor's internal tooling, a system not a person > No guest, narrator, or third-party speaker segments appear; the entire transcript is the single presenter's conference talk. ## Referenced Sources & Third-Party Claims - **A tweet** summarizing the "feed the beast" idea: *"It's really effective to just put everything in a database and then give your agent a SQL tool and let it handle the rest."* — tweet author not identified in the transcript. - **Tools/products referenced:** Conductor (presenter's own product), Chorus (a prior app the team built), Claude Code / "Cloud Code" (as spoken), Codex ("Code Access"), worktrees, Slack, Discord, Postgres, Telegram, OpenClaw, Anthropic, OpenAI. - **Internal company facts cited as evidence:** - Chorus was the original product; Conductor emerged as an internal tool around February of the prior year. - Migrations files in CI require **human review** ("slop free zones"); the app was rewritten "a couple of times" due to insufficient review discipline. - Conductor is described as a chat app where React query performance is prioritized. - A new cloud-sandbox/collaboration version of Conductor was "coming out this week." ## Promotional Segments ⚠️ - **Product promotion:** The talk is delivered by a company co-founder and features extended **live demos of Conductor** (cloud workspaces, real-time collaboration, agent-spawning API), with an explicit rollout announcement: > "we're rolling this out to all conductor users this week." - This constitutes a **promotional context** for Conductor; claims about the product's capabilities originate from its vendor. ## Comment Availability - **Not stated.** The transcript contains no information about whether comments are enabled, so comment availability is **unavailable/unrecorded**. ## Uncertainty Flags - Speaker identity ("Charlie Holtz") derives from the title metadata; the transcript itself does not state the speaker's name. - "Ralph loops," "mid-wit miming," "ultra code," and "/go" appear as spoken/heavily transcribed terms; exact spellings of product names may be transcription artifacts. - Colleague's name is inconsistently rendered (Cadence/Caden/Kaden) in the transcript. \>\> Hello. I was at a wedding this weekend and it was in New York and there were a bunch of trendy people there and uh I I told I was talking to someone who I'd never met before and uh I told him I was prepping for this presentation and he was like, "Oh, that's cool. Like, what what's the conference about?" And I said it was about AI engineering. And I could just see his eyes glaze over and he started like looking behind me to find the next person to talk to. And I'm it's like so cool to actually be in a room full of people who actually want to hear about this stuff. So, I I I I'm very excited to be here. Um I am the co-founder of Conductor. Um has anyone here used Conductor? Okay, nice. Nice. Okay, cool. So, uh uh for those who don't know, uh Conductor is a desktop app for managing a team of coding agents all at the same time. So, instead of having a bunch of terminal windows for your Cloud Codes, your Code Accesses, or your uh whatever uh coding agent, you have one interface to manage them all. And one of the really cool things about building Conductor has been that I've seen a lot of the best builders up close. I've like watched their workflow, I've seen how they work, I've seen the things they do do and the things that they avoid doing. And so, I thought I would compile a bunch of the principles um that I've seen the best engineers use um and give them to you all. Um so, here's what Conductor looks like. Uh can you can you guys see this? Okay, nice. Okay. So, here's what Conductor looks like. Um and here are my principles for being the fastest builder in your organization. So, let's start with number one, stay near the frontier. Staying near the frontier means you are always trying the latest things, basically the day they come out. Uh it means that when uh uh ultra code comes out, you're trying it. It means that when uh uh slash go comes out, you're giving it a go. Um it's really important to stay near the frontier um for a few reasons. Um if you are doing your own startup, then staying near the frontier means that you will um come up with lots of new ideas for what you should actually be building. Um and this literally happened to us. We were building a totally different app called Chorus. Um but we started using We were such power users of cloud code back in February of last year that we uh started building our whole workflow around cloud code, and we started cloning our repo five times, and then we discovered work trees, and then bit by bit we had built conductor as an internal tool. And we couldn't have figured that out if we uh weren't staying near the frontier. And if you're not doing a startup, you should be the person at your company who always knows what the latest uh the latest workflows are. Um it used to be that you could just kind of like use your social graph and the information that was important about the best workflows to use would trickle down to you. But things just like move way too fast now. You're You're always going to be three to six months behind if you do that. Um so, it's a very important to stay near the frontier. And there's an important word here, near. Um there is a danger if you are at the frontier, um you can you can do what uh I call mid-whip miming, where you're spending all of your time working on your workflow and not doing actual work. And so, internally we've come up uh with a heuristic for this. Um we call it don't beat the market. Don't try and beat the market. Um uh the concept here, like the heuristic you should use when you're you're to decide if you're near the frontier or at the frontier and uh too deep in into the latest trends is you should ask yourself why isn't this workflow the default? So for example when Ralph loops were becoming a big thing you should ask yourself like should I spend a ton of time optimizing my workflow to work with Ralph loops because if Ralph loops work for everyone like if they are the default then you probably should just wait for Anthropic or Open AI or ever to build the workflow into the into the default harness. You can think of this is sort of like an efficient market hypothesis where unless you have like real alpha you shouldn't be optimizing your workflow too much. And what I mean by real alpha is like some kind of information about either your users or your code base that the models might not know about. So an example for us is we it's we're we're a chat app. We have to render really long chats really quickly and performance is is important to us and so we need to spend a lot of time optimizing our react queries to render the chats quickly and we're willing to make sacrifices in other parts of our code base to make that happen. Um So if you have some kind of alpha like some kind of information about the app you're building that the models might not know about then you should put time into the workflow. Otherwise don't don't midwit meme. Don't don't be the person who has an amazing Emacs setup but like doesn't actually get stuff done. Okay three. Create slop free zones. So at Conductor we have this term we call a slop free zone. And a slop free zone is a part of the code base or a part of the app that requires really strict human review. And we're actually I think a little bit unusual in this way. I think a lot of people assume that we are uh pure token maxers and we are like ripping through like 30,000 line PRs, but we're actually not. Um we're actually quite careful with certain parts of our codebase, and then very loose with other parts of our codebase. Um the reason this is important is because if you are not careful about your slot free zones, your your code your codebase can get in a really tricky spot. Um and this actually happened to us. We have We've had to rewrite our whole app like a couple of times because we weren't careful about slot free zones. Um specifically, we have a uh migrations file. And uh in our CI uh any change to migrations file requires the AI uh a human to review it. Um we also assume that anything written in Slack is slot free. It's It's not written by the AI. It's written by a human. All of our docs, um all our cloud MDs, like all our skills, we put a ton of time into making them good. Um and this is also something I've seen with all the the the best builders up close. Like they put an unusual amount of time into the cloud MD or their skill files. Um and I I think like another way that I've thought about this is like if you had a new intern that was joining your company, and you had the opportunity to like whisper something in their ear every time they started working. Like every day, anytime they sat down, you could like whisper something in their ear. You would probably put a lot of thought into like what it is that you're whispering in their ear. And this is what the cloud MD or agent's MD is. It's like information that gets loaded into the agent's context every time they start working. Um and so you probably want to put a lot of thought into into those. Um okay, four. Feed the beast. Uh at Conductor, we have a uh internal tool we call the Conductor Internal Agent. Um and it is uh we also also known as the CIA. And the CIA is basically like the the uh centralized database of everything that's happening in the organization. So, anytime a new Slack message gets sent, the CIA picks it up. The CIA agent will see that a new message sent Slack, it will pick it up, and it will save it to a Postgres uh uh table. Anytime a user has a bug request in Discord, the same thing happens. Anytime we have a meeting, we are recording it, uh and it goes into the CIA. Um we call this feed the beast because you you want to for if your agents to be effective uh in your company, you want them to have as much information and as much context as they can have about the way you guys specifically work. And the best way to do that is by having a centralized place for all of the information to go. Uh I think this this tweet sums it up pretty well. Uh uh It's really effective to just put everything in a database and then give your agent a SQL tool and let it handle uh uh handle the rest. Okay. Next is free-range agents. Give your agents a lot of space to play. Give them Give them a sandbox where they that won't get killed, where they can explore your code base, where they can work on really hard tasks, where they can they know that they're not going to get shut down when you close your laptop lid. Uh Give them Give them opportunities to create more of themselves. Um Give them ways uh to collaborate with other agents and other humans. Um I think what's really in- interesting about free-range agents and like this this concept and why this is important is the models are getting better, and they are able to run for much longer, and there're going to be many more of them. And so, if they are confined to your laptop, then the they're not going to be nearly as effective as uh as if they are free roaming. Um The other thing that's important here is that once you give them a a sandbox to play in that isn't confined to your laptop, there's a bunch of really cool stuff that you can build on top. Um and we have built some of those things into Conductor and I I'll give you a quick glimpse into into some of those cool things. So, this is Conductor. I'm going to make it a bit bigger. Um and this is actually a new version of Conductor that is uh coming out this week and it is centered around collaboration in the cloud. And so, the the the thing I said was you need a a sandbox for agents to play. You need a free-range agent. And so, you'll notice that each workspace has a little cloud icon at the top and I can click it and get information about the sandbox that the agent is running in. Um and what's what's awesome about this is I can close my laptop and the agents are going to keep running. Up up until basically this week, every uh every task in Conductor was built on a get work tree, but now they're in a cloud sandbox. They are free-range agents. But what's also really cool um that you can that we can build on top of uh cloud is collaboration. So, you'll see here, I'll make this even bigger. That's me. And here are a list of the things that I am working on. And you can see that I am in the Conductor org. But if I scroll down, I can see what Cadence is working on. I can see what Lewis is working on. I can see what Tywan is working on and I can I can I can see that I can see Jackson's face pop up there. I can click in and see what he's working on in real time. Um and I think collaboration is the the one one of the most important new concepts uh in these tools that no one is really talking about right now. Um collaboration is important because uh not only as not only it is it true that all great things are built with teams of people. Like they're not built by individuals. They're they're built by teams. Um but also as the models get better, um as we've seen this with the two days of Fable, you can get a lot more ambitious with the kinds of things you're building. And if you're getting more ambitious, you're going to need more people and more agents to work on those things. So, I'm going to go into an uh a workspace that Caden is working on. Uh this one, and I'm going to say um I can review the changes that he's made. Um I'll make this a little smaller, and this looks fine, but I'm just going to say uh can we actually use tabs, not spaces? And Caden should be able to see that message happen in real time, and he can actually chat in the workspace as well. So, we can see here that he's typing. So, I see Caden is typing. Let's see what he says. Seems like he's typing a lot. Okay, maybe he stopped typing. I'll give him a second to take a look at it. But, the point is we can now have collaborative workspaces that are shared in real time with people on our team. Um Okay, he's typing again. Okay, come back. The agents have escaped. All right. So, I'm really excited about this, and we're rolling this out to all conductor users this week. Um I think I think collaboration is going to be one of the most important one of the most important new interface changes this year. Um the other really cool thing about cloud is that um and giving it the agents the free-range sandbox is that we can give the agents APIs to spawn themselves. So, I have here a uh I'll bring up my open claw. Uh this is my open claw called Lord Crandon. And you can see that it has I don't know how how well you can see this text, but it has access to a conductor API. And so, from my phone or from my Telegram or from really or from Slack or wherever I am, I can say, "Hi, can you create a new workspace for me that makes Yeah, makes all the buttons blue." And so, I'll I'll text that to Lord Crandon, and Lord Crandon has access to the conductor API and so can kick off work itself. Um So, let's see what it does here. Okay, so just created the workspace. The agent is on it. And then I can go into my conductor while I'm out and about, but it's still setting up the workspace, and it will do work for me while I am gone. So, I'm pretty excited about all the all the cool things you can build on top of of free range agents. Okay. The final principle that I want to talk about today and the title of this talk is orchestras, not factories. The whole like talk track today is about software factories. And I honestly kind of hate the term. I think it's the wrong way of thinking about these new tools that are emerging. I think like when I think of a factory, I think of automation. And I think of like there's a lot of amazing things about automation and like it makes our lives more efficient, and we can like create more of everything. But I don't want the future to be built around factories. I want the future to I want to feel like a human. I want to like be in the flow. I want to be like in front of an orchestra like waving my baton and we're and like I wave it this way and this this team of agents starts working and then this intermingling of humans and agents starts working as I go here. And I can when I want to I can zoom in on the details, but most of the time I can zoom out. And I don't think the future should be we are like managing swarms of agents and we are like factory line managers like pushing buttons getting the agents to like pump out the next feature. Like we can we can we tried this like 10 years ago with the term feature feature factories and it just doesn't work. Like I want my software to feel human and crafted. I want to feel like a human at the center of it all. And I think because we're all building these tools we actually have a responsibility to make the tools great for humans. I think it's really important to like use the words that make us feel excited and like feel feel capable and feel like we're in the flow and having fun. And so I don't think the future is is is something like this. I don't want to be I don't want to be in in my dark factory. I don't want to be a line manager. I want to feel like this. I want to be in the flow. I want to be having fun. I want to be crafting things. I want to feel like I'm Steve Jobs designing the Mac with a team of amazing humans and AI agents all in the same place. Like I want to feel like I'm in an orchestra. So here are my principles for for being the best builder in your organization. Stay near the frontier. Don't try and beat the market. Create slop free zones. Feed the beast. Free range agents and think about orchestras not factories. Came up with this handy acronym for for remembering it. Stickfo. All right. So thanks thanks a ton for for having me. I'll be around. Feel free to ask questions and I'll see you on the internet.