Orquestras, não fábricas: como trabalham os construtores mais rápidos — Charlie Holtz, maestro

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Orchestras, Not Factories: How the Fastest Builders Work — Charlie Holtz, Conductor · Canal: AI Engineer · 17:06 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA

Resumo

Charlie Holtz, cofundador da Conductor, apresenta princípios que observou entre construtores de software de alto desempenho. Ele recomenda acompanhar de perto as novidades sem gastar tempo demais otimizando workflows que ainda não se tornaram padrão, além de definir áreas do código que exigem revisão humana rigorosa. Também defende alimentar agentes com contexto organizacional e permitir que trabalhem em sandboxes na nuvem, com colaboração em tempo real. Por fim, propõe pensar no desenvolvimento como uma orquestra de pessoas e agentes, não como uma fábrica automatizada.

Pontos-chave

• Acompanhe as novidades e experimente ferramentas recentes, mas evite passar mais tempo ajustando o workflow do que realizando trabalho.
• Invista em otimizações específicas quando tiver informações sobre seus usuários ou sua base de código que os modelos não conhecem.
• Defina áreas do código que exigem revisão humana rigorosa, como arquivos de migração, e cuide da qualidade das instruções e skills usadas pelos agentes.
• Centralize informações da organização para que os agentes tenham contexto sobre como a equipe trabalha.
• Permita que agentes executem tarefas em sandboxes na nuvem, continuem trabalhando quando o computador estiver fechado e possam colaborar com pessoas e outros agentes.
• Use APIs para iniciar o trabalho dos agentes de diferentes lugares, inclusive por meio de mensagens.
• Projete ferramentas que mantenham as pessoas no centro do trabalho criativo, em vez de tratá-las como gerentes de uma linha de produção.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação e princípios para construir com agentes	Charlie Holtz apresenta a Conductor e explica que reuniu princípios observados nos workflows de construtores experientes.
02:11	Acompanhar a fronteira sem tentar superar o mercado	Holtz recomenda experimentar novidades, mas evitar otimizar workflows emergentes sem uma vantagem específica sobre o que os modelos já sabem.
05:24	Criar zonas livres de slop	O palestrante defende revisão humana rigorosa em partes sensíveis do código e atenção especial às instruções e skills dos agentes.
07:34	Alimentar os agentes com contexto	A Conductor centraliza mensagens, solicitações e reuniões para dar aos agentes mais informações sobre o funcionamento da organização.
08:40	Agentes livres e colaboração na nuvem	Holtz demonstra sandboxes na nuvem, workspaces compartilhados em tempo real e agentes que podem ser iniciados por meio de uma API.
14:29	Orquestras, não fábricas	O encerramento defende ferramentas que apoiem a colaboração entre pessoas e agentes e mantenham o trabalho humano e criativo no centro.

Citações

Pergunte a si mesmo: por que esse workflow ainda não é o padrão? — 03:50

Coloque tudo em um banco de dados, dê ao seu agente uma ferramenta SQL e deixe que ele cuide do resto. — 08:09

Orquestras, não fábricas. — 14:29

Temos a responsabilidade de tornar essas ferramentas ótimas para as pessoas. — 16:03

Conceitos e entidades

• Charlie Holtz (pessoa): Cofundador da Conductor e palestrante que apresenta princípios para construir software com agentes.
• Conductor (ferramenta): Aplicativo de desktop apresentado como uma interface para gerenciar equipes de agentes de programação.
• slop-free zone (conceito): Área de uma base de código ou aplicativo que requer revisão humana especialmente rigorosa.
• Conductor Internal Agent (ferramenta): Agente interno da Conductor que centraliza informações da organização, como mensagens, solicitações de bugs e reuniões.
• PostgreSQL (ferramenta): Banco de dados usado no exemplo para armazenar informações coletadas pelo agente interno.
• Ralph loop (conceito): Workflow mencionado como exemplo de uma tendência que pode não valer o esforço de otimização antes de se tornar padrão.
• sandbox (conceito): Ambiente isolado no qual agentes podem explorar uma base de código e executar tarefas sem depender do computador do usuário.
• Lord Crandon (agent): Agente pessoal demonstrado pelo palestrante, com acesso à API da Conductor para iniciar novos workspaces.

Tradução completa (pt-BR)

00:01 [música] >> Olá. Estive em um casamento neste fim de semana, em Nova York, e havia várias pessoas descoladas lá

00:33 e eu contei — estava conversando com alguém que nunca tinha conhecido antes — que estava me preparando para esta apresentação. E a pessoa disse: “Ah, que legal. Sobre o que é a conferência?” Eu disse que era sobre engenharia de IA. E pude ver os olhos dela ficarem vidrados, e ela começou a olhar por trás de mim, procurando a próxima pessoa com quem conversar. E eu pensei: é tão legal estar de verdade em uma sala cheia de pessoas que querem mesmo ouvir sobre essas coisas. Então, estou muito animado por estar aqui. Sou cofundador da Conductor. Alguém aqui já usou a Conductor? Legal. Muito bem. Certo, legal. Então,

01:09 para quem não conhece, a Conductor é um app para desktop para gerenciar uma equipe de agentes de programação ao mesmo tempo. Então, em vez de ter várias janelas de terminal para Claude Code, Codex ou qualquer outro agente de programação, você tem uma interface para gerenciar todos eles. E uma das coisas muito legais de construir a Conductor foi poder observar de perto muitos dos melhores construtores. Acompanhei o workflow deles, vi como trabalham, vi as coisas que fazem e as coisas que evitam fazer. Então, achei que reuniria alguns dos princípios

01:40 que vi os melhores engenheiros usarem e os apresentaria a vocês. Então, é assim que a Conductor se parece. Vocês conseguem ver? Legal. Certo. Então, é assim que a Conductor se parece. E estes são meus princípios para ser o construtor mais rápido da sua organização. Vamos começar pelo número um: mantenha-se perto da fronteira. Manter-se perto da fronteira significa estar sempre experimentando as novidades, basicamente no dia em que são lançadas. Isso

02:11 significa que, quando o Ultra Code é lançado, você experimenta. Significa que, quando o /go é lançado, você testa. É muito importante se manter perto da fronteira por alguns motivos. Se você está criando sua própria startup, manter-se perto da fronteira significa que terá muitas ideias novas sobre o que deveria construir. E isso aconteceu literalmente conosco. Estávamos construindo um app totalmente diferente chamado Chorus. Mas começamos a usar — éramos usuários avançados do Claude Code em fevereiro do ano passado — e começamos a construir

02:45 todo o nosso workflow em torno do Claude Code. Começamos a clonar nosso repo cinco vezes, depois descobrimos as worktrees e, aos poucos, acabamos construindo a Conductor como uma ferramenta interna. Não teríamos percebido isso se não estivéssemos perto da fronteira. E, se você não está criando uma startup, deveria ser a pessoa na sua empresa que sempre sabe quais são os workflows mais recentes. Antes, você podia simplesmente usar sua rede de contatos, e as informações importantes sobre os melhores workflows acabavam chegando até você. Mas agora as coisas se movem rápido demais

03:16 para isso. Você sempre vai ficar de três a seis meses atrás se fizer assim. Então, é muito importante se manter perto da fronteira. E há uma palavra importante aqui: perto. Há um perigo em estar na fronteira: você pode fazer o que chamo de imitar alguém no meio do movimento, passando todo o seu tempo trabalhando no seu workflow em vez de fazer o trabalho de verdade. Por isso, internamente, criamos uma heurística para isso. Chamamos de “não tente superar o mercado”. Não tente superar o mercado. A ideia aqui, a heurística que você deve usar quando estiver

03:50 decidindo se está perto da fronteira ou na fronteira, fundo demais nas últimas tendências, é perguntar a si mesmo: por que este workflow não é o padrão? Por exemplo, quando os loops de Ralph estavam virando uma tendência, você deveria se perguntar: devo passar um tempão otimizando meu workflow para funcionar com loops de Ralph? Porque, se os loops de Ralph funcionam para todo mundo, se são o padrão, então provavelmente

04:22 você deveria simplesmente esperar a Anthropic, a OpenAI ou quem quer que seja incorporar esse workflow ao harness padrão. Dá para pensar nisso como uma espécie de hipótese dos mercados eficientes: a menos que você tenha uma vantagem real, não deveria otimizar demais seu workflow. E o que quero dizer com vantagem real é algum tipo de informação sobre seus usuários ou sua base de código que os modelos talvez não conheçam. Um exemplo nosso: somos um app de chat. Precisamos renderizar chats muito longos com muita rapidez

04:54 e o desempenho é importante para nós. Por isso, precisamos passar bastante tempo otimizando nossas consultas do React para renderizar os chats rapidamente, e estamos dispostos a fazer sacrifícios em outras partes da nossa base de código para conseguir isso. Então, se você tem algum tipo de vantagem, alguma informação sobre o app que está construindo que os modelos talvez não conheçam, deve dedicar tempo ao workflow. Caso contrário, não imite alguém no meio do movimento. Não seja a pessoa com uma configuração incrível do Emacs que não consegue, de fato, concluir o trabalho.

05:24 Certo, número três: crie zonas sem código ruim. Na Conductor, usamos o termo “zona sem código ruim”. Uma zona sem código ruim é uma parte da base de código ou do app que exige uma revisão humana muito rigorosa. E acho que somos um pouco incomuns nesse aspecto. Acho que muita gente presume que somos maximizadores de tokens puros, que estamos produzindo PRs de 30 mil linhas a toda velocidade, mas não é bem assim. Na verdade, temos bastante cuidado com certas partes da nossa base de código e somos bem mais flexíveis com outras.

05:58 Isso é importante porque, se você não tomar cuidado com suas zonas sem código ruim, sua base de código pode acabar numa situação bem complicada. E isso aconteceu conosco. Tivemos que reescrever o app inteiro algumas vezes porque não tivemos cuidado com essas zonas. Em particular, temos um arquivo de migrações. No nosso CI, qualquer alteração no arquivo de migrações exige revisão de uma pessoa. Também presumimos que tudo o que é escrito

06:28 no Slack está livre de código ruim. Não é escrito pela IA, é escrito por uma pessoa. Dedicamos bastante tempo a toda a nossa documentação, a todos os nossos arquivos CLAUDE.md e a todas as nossas skills para deixá-los bons. Também observei isso nos melhores construtores que acompanhei de perto. Eles dedicam uma quantidade incomum de tempo ao CLAUDE.md ou aos arquivos de skills. Outra forma como penso nisso é: se um novo estagiário estivesse entrando na sua empresa e você pudesse sussurrar algo no ouvido dele

07:00 toda vez que começasse a trabalhar — todos os dias, sempre que se sentasse, você pudesse sussurrar algo no ouvido dele —, provavelmente pensaria bastante no que dizer. É isso que o CLAUDE.md ou o AGENTS.md representa: informações que são carregadas no contexto do agent sempre que ele começa a trabalhar. Então, provavelmente vale a pena pensar bastante nisso. Certo, número quatro: alimente a máquina. Na Conductor, temos uma ferramenta interna que chamamos de Conductor Internal Agent.

07:34 Ela também é conhecida como CIA. A CIA é basicamente o banco de dados centralizado de tudo o que acontece na organização. Então, sempre que uma nova mensagem é enviada no Slack, a CIA a coleta. O agent da CIA vê que uma nova mensagem foi enviada no Slack, coleta a mensagem e a salva em uma tabela do Postgres. Sempre que alguém relata um bug no Discord, acontece a mesma coisa. Sempre que temos uma reunião, nós a gravamos, e ela vai para a CIA. Chamamos isso de alimentar a máquina porque você quer, se a sua

08:09 Para que os agents sejam eficazes na sua empresa, você quer que eles tenham o máximo possível de informações e contexto sobre a maneira específica como vocês trabalham. E a melhor forma de fazer isso é ter um lugar centralizado para reunir todas as informações. Acho que este tweet resume isso muito bem. É muito eficaz simplesmente colocar tudo em um banco de dados, dar ao seu agent uma ferramenta de SQL e deixar que ele cuide do resto.

08:40 Certo. O próximo princípio são os agents em liberdade. Dê bastante espaço para seus agents brincarem. Dê a eles uma sandbox onde não sejam encerrados, onde possam explorar sua base de código, trabalhar em tarefas realmente difíceis e saber que não serão desligados quando você fechar a tampa do laptop. Dê a eles oportunidades de criar mais agents como eles. Dê a eles maneiras de colaborar com outros agents e com outras pessoas.

09:12 Acho que o que é realmente interessante nessa ideia de agents em liberdade, e por que isso é importante, é que os modelos estão melhorando e conseguem funcionar por muito mais tempo, e haverá muito mais deles. Então, se ficarem confinados ao seu laptop, não serão nem de longe tão eficazes quanto seriam se pudessem circular livremente. Outra coisa importante aqui é que, quando você lhes dá uma sandbox para brincar que não fica confinada ao seu laptop, há um monte de coisas muito legais

09:42 que você pode criar por cima. Nós incorporamos algumas dessas coisas ao Conductor, e vou dar uma olhada rápida em algumas delas. Então, este é o Conductor. Vou aumentá-lo um pouco. Esta é, na verdade, uma nova versão do Conductor, que será lançada esta semana e é centrada na colaboração na nuvem. Então, eu disse que é preciso uma sandbox para os agents brincarem. É preciso um agent livre. E, por isso, você vai

10:16 notar que cada espaço de trabalho tem um pequeno ícone de nuvem no topo. Posso clicar nele e obter informações sobre a sandbox em que o agent está funcionando. E o que é incrível nisso é que posso fechar meu laptop e os agents vão continuar funcionando. Até basicamente esta semana, cada tarefa no Conductor era criada em uma árvore de trabalho do Git, mas agora elas ficam em uma sandbox na nuvem. São agents em liberdade. Mas outra coisa muito legal que podemos criar por cima da nuvem é a colaboração. Então, como você pode ver aqui, vou aumentar ainda mais

10:48 a imagem. Este sou eu. E aqui está uma lista das coisas em que estou trabalhando. Dá para ver que estou na organização do Conductor. Mas, se eu rolar para baixo, consigo ver no que Cadence está trabalhando. Consigo ver no que Lewis está trabalhando. Consigo ver no que Tywan está trabalhando e consigo ver o rosto de Jackson aparecer ali. Posso clicar e ver em tempo real no que ele está trabalhando. E acho que a colaboração é um dos conceitos novos mais importantes

11:18 nessas ferramentas, mas ninguém está realmente falando sobre isso agora. A colaboração é importante porque não é só verdade que todas as grandes coisas são criadas por equipes de pessoas — elas não são criadas por indivíduos, são criadas por equipes. Mas, à medida que os modelos melhoram, como vimos nos dois dias de Fable, você pode assumir projetos muito mais ambiciosos. E, se seus projetos forem mais ambiciosos, vai precisar de mais pessoas e mais agents trabalhando neles. Então, vou entrar em um

11:48 espaço de trabalho em que Caden está trabalhando. Este aqui. E vou dizer… Posso revisar as alterações que ele fez. Vou diminuir um pouco, e isso parece bom, mas vou perguntar: podemos usar tabulações, em vez de espaços? Caden deve conseguir ver essa mensagem em tempo real e também pode conversar no espaço de trabalho. Então, nós

12:19 podemos ver aqui que ele está digitando. Estou vendo que Caden está digitando. Vamos ver o que ele diz. Parece que está digitando bastante. Certo, talvez tenha parado. Vou dar um segundo para ele dar uma olhada. Mas o ponto é que agora podemos ter espaços de trabalho colaborativos, compartilhados em tempo real com as pessoas

12:52 da nossa equipe. Certo, ele está digitando de novo. Certo, voltou. Os agents escaparam. Tudo bem. Estou muito animado com isso, e vamos disponibilizar a novidade para todos os usuários do Conductor esta semana. Acho que a colaboração vai ser uma das mudanças mais importantes na interface este ano. Outra coisa muito legal da nuvem é que, ao dar aos

13:23 agents uma sandbox em liberdade, podemos dar a eles APIs para criarem instâncias de si mesmos. Então, tenho aqui um… Vou abrir meu OpenClaw. Este é meu OpenClaw, chamado Lord Crandon. Dá para ver que ele tem… Não sei se dá para ler bem este texto, mas ele tem acesso a uma API do Conductor. Então, pelo meu telefone, pelo Telegram, pelo Slack ou por onde quer que eu esteja, posso dizer: “Oi, você pode criar um novo espaço de trabalho para mim que deixe

13:56 É, deixe todos os botões azuis.” Então vou mandar uma mensagem para Lord Crandon, e Lord Crandon tem acesso à API do Conductor, então pode iniciar o trabalho por conta própria. Vamos ver o que ele faz. Certo, acabou de criar o espaço de trabalho. O agent já está trabalhando nisso. E então posso acessar meu Conductor enquanto estou por aí; ele ainda está configurando o espaço de trabalho, e vai trabalhar para mim enquanto eu estiver fora.

14:29 Estou bem animado com todas as coisas legais que dá para criar com agents em liberdade. Certo. O último princípio sobre o qual quero falar hoje — e que também dá título a esta palestra — é: orquestras, não fábricas. Toda a conversa de hoje gira em torno de fábricas de software. E, sinceramente, eu meio que detesto esse termo. Acho que é a maneira errada de pensar nessas novas ferramentas que estão surgindo. Quando penso em uma fábrica,

15:03 penso em automação. E há muitas coisas incríveis na automação: ela torna nossas vidas mais eficientes e podemos criar mais de tudo. Mas não quero que o futuro seja construído em torno de fábricas. Quero que o futuro… Quero me sentir humano. Quero estar no fluxo. Quero estar diante de uma orquestra, regendo com minha batuta. E, quando eu a mover para um lado, esta equipe de agents começa a trabalhar, e então essa interação entre pessoas e agents começa a acontecer enquanto eu vou

15:33 até aqui. E, quando quiser, posso aproximar a imagem para ver os detalhes, mas, na maior parte do tempo, posso afastá-la. Não acho que o futuro deva ser nós gerenciando enxames de agents, como gerentes de linha de fábrica apertando botões para fazer os agents produzirem o próximo recurso. Já tentamos isso há uns 10 anos com o termo “fábricas de recursos”, e simplesmente não funciona. Quero que meu software pareça humano e feito com cuidado. Quero sentir que há uma pessoa no centro de tudo. E acho que, como todos nós estamos

16:03 criando essas ferramentas, temos a responsabilidade de torná-las ótimas para as pessoas. Acho muito importante usar palavras que nos deixem animados, que nos façam sentir capazes, no fluxo e nos divertindo. Então, não acho que o futuro seja algo assim. Não quero ficar na minha fábrica escura. Não quero ser gerente de linha. Quero me sentir assim. Quero estar no fluxo. Quero me divertir. Quero criar coisas com cuidado. Quero sentir que sou Steve

16:36 Jobs projetando o Mac com uma equipe de pessoas incríveis e agents de IA, todos no mesmo lugar. Quero sentir que estou em uma orquestra. Então, aqui estão meus princípios para ser o melhor construtor da sua organização. Fique perto da fronteira. Não tente superar o mercado. Crie zonas livres de conteúdo de baixa qualidade. Alimente a fera. Deixe os agents livres e pense em orquestras, não em fábricas. Criei este acrônimo prático para lembrar disso: Stickfo. Para

17:06 certo. Muito obrigado por me receberem. Vou ficar por aqui. Fiquem à vontade para fazer perguntas e nos vemos na internet.

Transcrição original

[00:01] [music] >> Hello. I was at a wedding this weekend and it was in New York and there were a bunch of trendy people there

[00:33] 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

[01:09] 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

[01:40] 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

[02:11] 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

[02:45] 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

[03:16] 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

[03:50] 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

[04:22] 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

[04:54] 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.

[05:24] 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

[05:58] 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

[06:28] 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

[07:00] 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

[07:34] 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

[08:09] 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.

[08:40] 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

[09:12] 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

[09:42] 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

[10:16] 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

[10:48] 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

[11:18] 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

[11:48] 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

[12:19] 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

[12:52] 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

[13:23] 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

[13:56] 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.

[14:29] 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,

[15:03] 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

[15:33] 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

[16:03] 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

[16:36] 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

[17:06] 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.