A engenharia de software está se tornando engenharia de fábrica — Zach Lloyd, Warp

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: Software Engineering Is Becoming Factory Engineering — Zach Lloyd, Warp · Canal: AI Engineer · 20:13 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Engenharia de software com IA, Open source e ecossistemas de software

Resumo

Zach Lloyd argumenta que o desenvolvimento de software está migrando de agentes interativos para fábricas de software automatizadas, nas quais agentes conduzem etapas do ciclo de vida e humanos intervêm nos pontos certos. Ele descreve os componentes dessas fábricas: automações, contexto e skills, participação humana, monitoramento e mecanismos de autoaperfeiçoamento. Também explica como a automação ajudou a Warp a organizar seu projeto open source e recomenda que empresas construam vantagens além de um bom produto. Nesse cenário, engenheiros escreverão menos código, mas poderão entregar mais, enquanto julgamento humano e foco em produtos úteis continuarão essenciais.

Pontos-chave

• O desenvolvimento tende a avançar de agentes interativos para fábricas de software que automatizam etapas do ciclo de vida.
• Engenheiros poderão assumir o papel de projetar, operar e aperfeiçoar os sistemas que constroem produtos.
• Uma fábrica eficaz combina automações, contexto e skills, intervenções humanas nos momentos adequados e recursos de autoaperfeiçoamento.
• O fluxo pode incluir triagem, criação de especificações, implementação, revisão, verificação, entrega e monitoramento.
• O monitoramento deve alimentar novamente a fábrica, criando ciclos de melhoria contínua.
• Agentes podem ajudar tanto contribuidores quanto mantenedores em projetos open source.
• Como ficou mais barato criar e clonar software, empresas precisam de vantagens além do produto, como distribuição, ecossistema, marca ou dados.
• O trabalho dos engenheiros pode envolver menos escrita de código e mais entrega de produtos e aperfeiçoamento dos processos.
• Adaptabilidade, pensamento crítico, capacidade de aprender e compreensão de sistemas e arquitetura continuam importantes.
• Automação não substitui o julgamento humano sobre quais problemas resolver e o que será útil para as pessoas.

Capítulos

Início	Capítulo	Resumo
00:01	Da engenharia de software à engenharia de fábrica	Zach Lloyd apresenta sua trajetória e prevê que o desenvolvimento migrará de agentes interativos para processos automatizados.
03:13	O ciclo de uma fábrica de software	O palestrante descreve um fluxo que vai da triagem e das especificações à implementação, revisão, entrega e monitoramento.
04:19	Open source como fábrica pública	Lloyd explica por que a Warp tornou seu projeto open source e defende construir vantagens de negócio além de um bom produto.
08:02	Componentes e etapas da fábrica	A apresentação detalha automações, contexto, participação humana e o fluxo técnico de entradas, triagem, implementação e verificação.
12:13	Medição e ciclos de autoaperfeiçoamento	Lloyd aborda a infraestrutura da fábrica e mostra como medir resultados e usar agentes observadores para aprimorar skills.
14:51	O papel dos engenheiros e as perguntas da plateia	O palestrante discute a mudança no trabalho dos engenheiros, as habilidades valorizadas e a importância do julgamento humano.

Citações

A disciplina da engenharia de software vai se tornar algo mais parecido com engenharia de fábrica. — 01:37

Os engenheiros de software serão aqueles que vão construir e gerenciar essas fábricas. — 03:47

Todos vão programar menos, mas vão entregar mais. — 15:24

A única coisa que importa é: vocês estão construindo algo útil? — 19:12

Conceitos e entidades

• Zach Lloyd (pessoa): Fundador da Warp e ex-engenheiro principal do Google que apresenta sua visão sobre fábricas de software.
• Warp (empresa): Empresa que desenvolve um ambiente de desenvolvimento agentic, iniciado como terminal e posteriormente disponibilizado como open source.
• Google Docs (ferramenta): Suíte de produtos cuja engenharia Zach Lloyd liderou durante sua passagem pelo Google.
• build.warp.dev (ferramenta): Site que mostra issues em andamento no sistema da Warp e quais agentes ou contribuidores estão trabalhando nelas.
• software factory (conceito): Sistema de automações e intervenções humanas que conduz o trabalho de desenvolvimento desde a entrada de ideias até o monitoramento.
• Spec-driven development (conceito): Abordagem em que especificações de produto e técnicas orientam a implementação do software.
• product spec (conceito): Especificação que descreve os invariantes de produto que a implementação deve respeitar.
• tech spec (conceito): Especificação que descreve a arquitetura e a estrutura do código a ser construído.
• skill loop (conceito): Ciclo em que agentes observadores analisam a aplicação de skills e propõem melhorias para execuções futuras.
• factory agents (conceito): Agentes que executam tarefas de desenvolvimento dentro da fábrica de software.
• observer agents (conceito): Agentes que observam o desempenho de outros agentes e identificam oportunidades de melhoria.
• CI/CD (conceito): Práticas que Lloyd recomenda manter como parte do processo de verificação da fábrica.
• GitHub (ferramenta): Plataforma mencionada para o repositório open source apresentado como ponto de partida para criar agentes de fábrica.

Tradução completa (pt-BR)

00:01 [música] >> Certo. Olá a todos. Estou animado por estar aqui. Meu nome é Zach Lloyd. Hoje vou falar sobre fábricas de software que se aprimoram, o novo modelo open source e, basicamente, o que acho que está acontecendo com o desenvolvimento. Para começar, um pouco sobre mim. Sou ex-engenheiro principal do Google. Eu liderava a engenharia da suíte Google Docs.

00:35 Tenho trabalhado como engenheiro há mais de 20 anos, bastante tempo. Ainda faço entregas com frequência, mas não escrevi uma linha de código nos últimos 6 meses. Sou fundador de uma empresa chamada Warp. Se você não conhece, Warp é um ambiente de desenvolvimento open source baseado em agents. Talvez nos conheça como um terminal. Foi assim que a empresa começou. Somos basicamente um terminal com agents integrados. Abrimos o código há alguns meses, e vou falar um pouco sobre

01:07 essa experiência e a motivação por trás dela. É um projeto open source popular, com mais de 60.000 estrelas no GitHub. Tivemos algumas centenas de pessoas contribuindo. Mais de 800.000 desenvolvedores ativos usam o Warp. E, cada vez mais, nosso foco não está apenas no aspecto de terminal e no aspecto interativo do desenvolvimento, mas também em como automatizar o desenvolvimento. Vou falar principalmente sobre isso. Então, minha tese é que a

01:37 disciplina da engenharia de software vai se tornar algo mais parecido com a engenharia de fábricas. Vou explicar o que quero dizer daqui a pouco, mas guardem isso em mente. É isso que acho que vai acontecer. Se olharmos para o desenvolvimento nos últimos dois anos, quero dizer, é impressionante como mudou. Saímos de um mundo de chat e autocompletar com IA para cursor co-pilot e chegamos à fase em que estamos agora, que considero ser, em grande parte,

02:08 agents interativos. Então, você fica sentado diante do computador e pede ao Claude Code para fazer algo, pede ao Warp para fazer algo. E acredito que, nos próximos 6 meses ou um ano — é difícil prever o ritmo —, vamos avançar muito mais para um mundo de automação. Mas, antes de entrar nisso, só quero fazer uma rápida pergunta para ver quem levanta a mão: quantas pessoas aqui estão desenvolvendo com agents? Todo mundo? Faz sentido. Quantas pessoas costumam desenvolver com vários agents ao mesmo tempo?

02:40 Mais uma vez, quase todo mundo. Quantas pessoas estão executando um agent agora? Não vou ficar ofendido. Eu também estaria fazendo isso. Tudo bem. Por curiosidade, quantas pessoas estão executando agents na nuvem? Parece que são menos da metade, mas ainda é um número significativo. E quantas pessoas configuraram internamente um sistema para automatizar todo o ciclo de vida do desenvolvimento de software? Tudo, desde triagem, especificação, implementação até revisão. Estou vendo

03:13 algumas mãos. Então, algumas pessoas estão fazendo isso. É isso que vai acontecer. Acredito que todo projeto de tamanho significativo vai ter algo assim. E vai se parecer com esse grande ciclo. Todo mundo está falando de ciclos. Não há nada de complicado nos ciclos. Este ciclo diz “fábrica de software na nuvem”. Poderia literalmente dizer “ciclo de vida do desenvolvimento de software”. É a mesma coisa. Mas, para percorrer esse ciclo: as ideias vão entrar por cima. Os agents vão fazer a triagem. Se algo for complicado, eles vão escrever uma especificação.

03:47 Essas caixinhas azuis são onde os humanos entram. Os humanos vão revisar a especificação. Os agents vão fazer a implementação. Um humano e um agent vão revisar o código. Os agents vão verificar. Um humano vai revisar o produto. Você faz o deploy, monitora e o ciclo recomeça. E, para o bem ou para o mal, acho que é assim que o desenvolvimento de software vai acabar se parecendo. Então, repito a tese: se é assim que a engenharia de software vai ser, os engenheiros de software serão aqueles que vão construir e gerenciar essas fábricas. >> [fungada]

04:19 >> No começo, prometi — e coloquei no título da palestra — que falaria sobre open source, então quero fazer isso por alguns minutos. Vou fazer um breve desvio. Trago o tema do open source porque um dos principais motivos para a Warp ter adotado o open source foi construir uma fábrica pública. Esta é uma imagem do site que criamos, chamado build.warp.dev, que mostra todos os issues que estão passando pelo nosso sistema, em que estado estão, quais agents estão trabalhando neles

04:51 e quais colaboradores estão trabalhando neles. É como uma fábrica em estágio inicial, operando em escala. Não está funcionando perfeitamente, mas está funcionando. E um dos motivos para adotarmos o open source foi tentar construir isso. De modo geral, acho interessante falar sobre open source na era do desenvolvimento com agents. Este gráfico é muito tosco, mas dá para entender? Está ficando muito mais barato criar software. Um corolário disso é que

05:23 está ficando trivial clonar software. Então, se você trabalha no ramo de software — não sei quantas pessoas nesta sala trabalham especificamente nesse ramo —, é muito difícil construir um negócio de software se é de graça criar software. É difícil capturar o valor, especialmente se um concorrente pode clonar o produto. E minha grande conclusão, ou grande dica para todo mundo aqui, é que a primeira coisa a fazer é patentear seu código. Estou brincando. Não façam isso. É uma piada completa. >> [risos] >> Não façam isso.

05:54 Minha primeira dica é, obviamente, que você precisa ter um ótimo produto. Isso sempre foi verdade, mas eu diria que provavelmente um ótimo produto nunca foi suficiente. E, agora, mais do que nunca, se você acha que vai construir um ótimo negócio de software apenas criando e lançando um ótimo produto, provavelmente não vai ter sucesso. Você precisa de vantagens além do produto. Essas vantagens podem ser distribuição, ecossistema, uma ótima marca ou um fosso de dados.

06:26 Você pode ter capital, mas, se é uma startup — falo aqui a partir da minha experiência no mundo das startups —, simplesmente não tem essas vantagens. E, ainda assim, você quer se destacar. Uma das maneiras que sugiro para conseguir isso é construir de forma aberta. Para deixar claro, a Warp passou 5 anos desenvolvendo de forma fechada antes de dar o salto para construir de forma aberta, e vou explicar o motivo. Mas construir de forma aberta ajuda a desenvolver seu ecossistema. Pode fazer com que você passe de ser odiado

06:57 no Hacker News a ser tolerado. Pode fortalecer sua marca, criar uma comunidade, e há todas essas vantagens. E algumas coisas que tradicionalmente eram um problema agora podem ser gerenciadas. Por exemplo, os problemas tradicionais do open source podem incluir muitos issues ruidosos. PRs malfeitos. Você pode acabar num inferno de revisão de código. Pode acabar tendo que gastar muito tempo verificando mudanças. E a solução — então, para chegar a isso de um jeito um pouco prolixo —

07:31 no caso do open source, ou pelo menos da Warp, o que finalmente nos fez decidir fazer isso foi termos criado um conjunto completo de automações — na verdade, uma fábrica de software — para gerenciar o projeto open source. Como eu disse, acho que é assim que o futuro vai se parecer. Vou entrar um pouco mais em detalhes técnicos para quem quiser tentar construir algo assim para os próprios projetos. Então, quais são os componentes de uma fábrica de software eficaz? Não é

08:02 assim tão complicado começar, pelo menos em alto nível. Você precisa de um conjunto de automações. Precisa de uma maneira de fornecer contexto e skills, e de uma maneira de trazer humanos para o processo na hora certa. É como quando as coisas ficam emperradas na fábrica. E uma coisa muito importante é que você precisa de algum conjunto de recursos de autoaperfeiçoamento. Pense nisso como ciclos. E, se fizer isso direito no mundo do open source, você pode chegar a um mundo em que os agents ajudam os colaboradores a contribuir. Eles ajudam

08:34 os mantenedores mantêm. E quero enfatizar que não há nada de especial em open source aqui. Acho que todo projeto de porte considerável pode se beneficiar dessa abordagem, e prevejo que toda empresa, todo projeto open source terá no seu núcleo uma espécie de fábrica de software, mais ou menos como aconteceu com CI/CD, que virou algo do tipo: “Ah, claro que você tem isso”. Talvez, não sei, isso tenha acontecido há 10 anos. Vamos dar uma olhada no chão de fábrica por um instante. Então, vocês não vão conseguir ler isto. Isto

09:05 é coisa demais. O objetivo deste slide não é fazer vocês lerem o workflow. É mostrar que o chão de fábrica é basicamente um grafo de etapas em que você define, tipo: “Certo, como o software é construído para o meu produto?”. E isso é bem parecido para todos os produtos. As coisas entram e passam pelo fluxo. Elas ficam paradas em certos pontos. E, de modo geral, voltando um pouco: há as entradas. As entradas são, na verdade, ideias.

09:36 As entradas podem vir da sua equipe, podem vir dos seus usuários. As próprias entradas tendem a chegar por certos canais, que você deve considerar, por exemplo, como o seu rastreador de tarefas, que é uma opção óbvia, ou o Slack ou o Teams, como seus canais de comunicação. Elas podem vir diretamente do seu terminal ou IDE. Podem vir dos seus sistemas de monitoramento, mas há um conjunto de entradas que traz o trabalho para a fábrica. Há a triagem. Esta é uma etapa muito importante. Então,

10:07 mais uma vez, reduzo isso a algo muito simples, mas você quer um agent que analise as issues conforme chegam e simplesmente diga: “Sabe, se isto for fácil e não houver ambiguidade, é só implementar”. E é assim que você pode realmente começar a operar uma fábrica. Se uma issue for difícil, recomendo ter um agent que produza especificações. Quem aqui usa desenvolvimento orientado por especificações? Levantem a mão. As pessoas seguem essa abordagem? Certo. Dá para fazer isso de muitas maneiras diferentes, mas acho muito eficaz. A maneira que fazemos na Warp e que recomendo é ter um agent que escreva o que

10:41 chamamos de especificação de produto e especificação técnica. A especificação de produto descreve as invariantes do produto que você está desenvolvendo. A especificação técnica descreve a arquitetura e a estrutura do código. Depois, você tem um agent de implementação. Basicamente, é um agent de programação que roda em algum lugar na nuvem. Ele cria um diff. Dá para usar vários tipos de agents de programação para isso. Depois vem a revisão. Em muitos sentidos, esta é a parte mais dolorosa. Acho que as pessoas já estão um pouco cansadas de revisar

11:12 porcaria idêntica. Eu faria um agent revisar o código primeiro. E, com o tempo, isso se torna um exercício de gestão de riscos: quando envolver pessoas na revisão do código? Mas você quer ter uma etapa aqui em que as pessoas possam fazer isso. Para certos tipos de aplicativos, a etapa de verificação é muito importante. Isso incluiria coisas como uso do computador. Se você estiver criando uma interface de usuário, faça o computador realmente usar o código produzido pelo agent para gerar vídeos e capturas de tela.

11:43 CI/CD, continuem usando, obviamente. E depois, monitoramento. Então, nossos agents não param na fábrica quando o código é entregue. Eles devem observar o que foi entregue. Está falhando? Está sendo usado? E o ciclo continua, porque você pega o resultado desta etapa de monitoramento e o devolve ao início da fábrica. Agora, você poderia tentar construir isso. Mais cedo, fui a uma palestra do meu amigo Adam, na qual ele falou que a Uber criou uma versão interna disso. E é

12:13 bem legal. Eu diria que, para a maioria das organizações — depende mesmo de onde você está —, será fácil construir uma versão simples disso. Mas, para construir algo que realmente escale, provavelmente você deveria se concentrar no seu próprio produto, não em construir essa infraestrutura, porque há muitas coisas que você acaba querendo. Mais uma vez, não é para vocês lerem isto. É só um monte de coisas. Se você construir isso ou comprar, vai acabar com algo mais ou menos assim, que é

12:45 um conjunto de maneiras de levar trabalho para a sua fábrica. É o que está no topo aqui. Você terá uma espécie de plano de controle para descobrir como o trabalho é distribuído pelo chão de fábrica. Terá o lugar onde o trabalho realmente acontece, que serão sandboxes na nuvem. Vai decidir qual agent executar. Então, qual é o harness? Qual é o modelo? E, por fim, acho que isto é muito importante: você vai querer configurar algum tipo de plano de dados que fique abaixo da sua fábrica. É algo que permite aos agents

13:17 se lembrarem do que fizeram, aprenderem e melhorarem com o tempo. A fábrica não é apenas um produto. É também uma mentalidade, e isso me traz de volta à tese que apresentei no começo. É preciso medir e melhorar. Então, fábrica… aqui é onde, não sei, você pode estender essa metáfora o quanto quiser, mas deveria estar pensando em eficiência. Isso significa coisas como: quanto software você entregou? Quanto isso custou em tempo humano e tempo de token? E você vai querer medir isso e tentar melhorar com o tempo.

13:50 Uma parte essencial disso é criar ciclos. Os ciclos, de novo, parecem complicados, mas não são tão complicados. Basicamente, são maneiras de fazer os agents melhorarem, observando o que estão fazendo e onde estão falhando. Um tipo comum de ciclo que você vai querer incluir na sua fábrica é um ciclo de skill. Isso significa que você terá seus

14:20 agents da fábrica executando skills e, depois, terá agents observadores que veem como essas skills estão sendo aplicadas, procuram problemas e tentam aprimorá-las. Por exemplo, se você tivesse um agent de revisão de código que deixasse comentários e uma equipe de engenharia com engenheiros seniores fosse corrigindo esses comentários, você iria querer um agent observador que analisasse isso e, basicamente, aprimorasse o agent de revisão de código para a próxima execução. Quero deixar uma ideia para vocês: o que isso… Onde isso

14:51 deixa os engenheiros? Acho que vocês vão ter de adotar essa mentalidade. Estou me esforçando bastante para levar a nossa equipe a adotá-la. Nem sempre é fácil. A ideia é que você não está apenas construindo o produto, mas também aquilo que constrói o produto. E isso é simplesmente diferente. É mais parecido com engenharia de processos, manufatura ou algo assim. E você pode pensar: “Certo, talvez isso seja uma pena. Será que é uma pena?”. Bem, isso depende. Depende de que

15:24 alegria você tira da engenharia de software. Se a sua alegria está em escrever código, acho que todos aqui que são engenheiros de software vão escrever menos código. Mas, se a sua alegria está em entregar produto, nunca houve um momento melhor, e é aí que eu encontro a minha alegria. Gosto de construir e entregar a coisa. Então, todos aqui vão programar menos, mas vão entregar mais, e isso vai ser uma troca. Mas, se você abordar isso como um engenheiro de fábrica, acho que vai perceber que ainda há

15:55 um conjunto muito interessante de desafios de engenharia. Dá até para pensar nisso como metaengenharia. Como projetar o seu sistema de agents para que a engenharia seja a melhor possível? Mas acho que é um conjunto de desafios muito atraente e interessante para resolver. Então, é isso. Para quem tiver interesse: seguindo o link deste QR code, deixei no GitHub um repo open source para qualquer pessoa que queira tentar criar seus próprios agents de fábrica

16:27 dá para fazer isso. Isso usa a plataforma de agents da Warp como parte do processo, mas, sinceramente, você não precisa usá-la. Não estou tentando empurrar nosso produto, mas isso deve dar uma boa ideia de como, por exemplo: se você quiser configurar um agent para fazer triagem ou um agent para redigir especificações, como faz isso na prática? Como você sai da teoria de trabalhar com uma fábrica e começa a colocá-la em prática? Não sei se temos como fazer perguntas aqui. Reservei alguns

16:57 minutos para perguntas. Se alguém tiver alguma, senão vou encerrar. Sim. >> Sim, tenho uma pergunta. Há uma certa tensão no que você disse: você não quer construir isso porque dá muito trabalho. >> Sim. >> Mas você também constrói fábricas. Qual é a sua posição? >> Ótima pergunta. Eu disse algo que é quase contraditório. Acho que você deveria… A maneira de pensar nisso é que todo mundo vai implementar algum tipo de fábrica, mas depois vem o ajuste fino da fábrica: essas são as skills certas para o meu domínio? Esta fábrica está

17:27 construindo meu produto da maneira certa? Ainda acho que há vários desafios de engenharia interessantes. Em alguns lugares, você pode construir isso, mas, de novo, acho que, em geral, você provavelmente deveria se concentrar em construir o produto principal da sua empresa. Ainda assim, há vários ajustes e questões sobre como fazer a fábrica funcionar para o seu produto que são importantes. Ótima pergunta. Sim. >> Oi, Tom, muito obrigado. Eu tinha uma pergunta. Se você fosse universitário agora… >> Sim. >> …se formando e entrando no mercado de trabalho, onde você investiria seu tempo?

18:00 >> É… A pergunta, caso as pessoas não tenham conseguido ouvir, foi: se eu fosse universitário, me formando e entrando no mercado de trabalho agora. Acho que as habilidades mais importantes neste novo mundo são a capacidade de adaptação. Acho que também é o pensamento crítico. É a velocidade com que você consegue aprender. Não sei se você estuda ciência da computação, mas ainda acho que há muito valor em entender os sistemas e a arquitetura subjacentes, e em ser capaz de raciocinar e entender o código, entender as especificações que os agents escrevem — desculpe, que eu escrevo. Então,

18:34 eu me concentraria nessas habilidades. E, não sei, estamos contratando mais pessoas do que nunca. Há muita informação enganosa sobre pessoas não serem contratadas por causa da IA, mas essa não tem sido nossa experiência até agora. O que procuro são pessoas realmente adaptáveis, com foco em produto, que sejam excelentes em resolver problemas, mesmo com as mudanças na tecnologia subjacente. Sim, acho que dá tempo para mais uma pergunta. Sim.

19:12 E quanto ao… A pergunta era sobre o senso de produto: como você realmente constrói algo útil? Acho que talvez a questão certa seja como formular isso e de onde vêm as ideias. Acho que o problema da metáfora da fábrica, embora eu esteja apostando nela porque acho que há algo de válido aí, é que ela pode soar como mecanização ou desumanização. Ainda acho que, no fundo, a única coisa que importa é: você está construindo algo útil? E

19:42 se você tem uma fábrica que produz algo com que ninguém se importa, qual é o sentido? Acho que o gosto humano, a contribuição humana, o senso de produto humano e a orientação de pessoas nesses pontos de contato em que não dá para automatizar as coisas são absolutamente essenciais. É nisso que eu trabalho o tempo todo: tento descobrir o que os clientes querem, o que as pessoas querem e o que será valioso para elas. Então, acho que esse é um ponto absolutamente fundamental. Acho que meu tempo acabou. Então, preciso

20:13 ir. Espero que todos tenham gostado desta conversa. Sou muito grato pelo convite para falar. Muito obrigado a todos. >> [música] >> Oi.

Transcrição original

[00:01] [music] >> Okay. Hello everyone. I’m excited to be here. My name is Zach Lloyd. Today I’m going to be talking about self-improving software factories, the new open-source model, and basically what I think is happening to development. A little bit about me just to begin. So, I am a former principal engineer from Google. I used to lead engineering on

[00:35] the Google Docs suite. I’ve been an engineer now for over 20 years, a long time. I am still shipping frequently, but I haven’t written a line of code in the last 6 months. And I’m the founder of a company called Warp. Warp, if you’re not familiar, is a open-source agentic development environment. You may know us as a terminal. That is how the company started. We’re basically a terminal that has agents built in. We open-sourced it a couple months ago, and I’m going to talk a little bit about

[01:07] that experience and the motivation for it. It’s a popular open-source project, over 60,000 GitHub stars. We’ve had a couple hundred people contributing. We have over 800,000 active developers who are using Warp. And increasingly, we are focused not just on the terminal aspect and the interactive aspect of development, but more so on how do you automate development? I’m going to talk mostly about that. So, the thesis that I have is that the

[01:37] discipline of software engineering is going to become something more like factory engineering. And I’ll explain what I mean by this in a minute, but just keep that in mind. That’s That’s what I think is going to happen. If you look at development over the past couple years, it’s I mean, it’s crazy how it’s changed. We’ve gone from a world of chat and AI auto complete to cursor co-pilot to the phase that we’re in now, which I consider to be mostly

[02:08] interactive agents. So, you’re sort of sitting at your computer and you are telling Claude code to do something, you’re telling Warp to do something. And I believe what’s going to happen over the next 6 months, a year, hard to predict the pace, is that we’re going to move much more towards a world of automation. But, before I get into that, just quick show of hands, how many folks in here are building with agents? Ever Ever 100% makes sense. Uh how many How many folks are building typically with multiple agents at one time?

[02:40] So, again, almost everyone. How many people are running an agent right now? I’m not offended. I would Okay, that’s totally cool. I would be doing it, too. Uh how many folks are running agents in the cloud out of curiosity? So, that looks like less than half, but still significant. Uh and how many folks have have set up a system internally to automate the whole software development life cycle. So, everything from like triage, specking, implementing, reviewing. So, I see

[03:13] some hands. So, some people are doing this. So, this is what’s going to happen. Uh every project of significant size, I believe, is going to have something like this. Um and it’s going to look kind of like this big loop. And everyone is talking about loops. There’s nothing that complicated about loops. This loop says a cloud software factory. This loop could literally just say like the software development life cycle. It’s the same thing. Um but just to go through this loop, it’s like ideas are going to come in at the top. Agents are going to do triage. If something is complicated, they will write a spec.

[03:47] Uh these little blue boxes are where humans step in. Humans will review the spec. Uh agents will do the implementation. A human and agent will review the code. Agents will verify. Human will review the product. You ship, and then you monitor, and round and round you go. Uh and this is what software development for better or worse I think is going to end up looking like. So, I repeat the thesis which is that if this is what software engineering is going to look like um software engineers are going to be the ones who end up building and managing these factories. >> [snorts]

[04:19] >> Now, I promised at the beginning and I put in the title of the talk that I was going to talk about open source and so I want to do that for a few minutes. I’m going to take a quick digression. Um I bring up open source because one of the main reasons that Warp open source was to build uh build a public factory. Um and so this is a picture of this website we’ve built called build.warp.dev which shows all of the issues that are flowing through our system and what state they’re in, what agents are working on

[04:51] them, what contributors are working on them. And it’s kind of like a proto-factory done at scale. It’s not working perfectly, but it is working. And one of the reasons we open source was to try to build this. Um just in general, I think it’s interesting to talk about open source in the time of agentic development. This is a really stupid graph, but it’s like it’s just it it you get it? It’s like it’s becoming much cheaper to build software. Um a corollary of that is that

[05:23] it’s becoming trivial to clone software. And so if you are in the software business, I don’t know how many folks in this room are in the software business per se, but it’s very hard to build a software business if it’s free to build software. It’s hard to capture the value, especially if a competitor can clone. And so my big takeaway or big tip for everyone in here is that the first thing you should do is patent your code. I’m kidding. Don’t just It’s a complete joke. >> [laughter] >> Don’t don’t do this.

[05:54] Uh my my first tip is obviously you need to have a great product. Uh this has always been the case um but I would say a great product probably was never enough, but even now more than ever, if you think that you’re going to build a great software business just by building and shipping a great product, you’re probably not going to succeed. Uh, you need advantages beyond the product. And so those advantages could look like distribution, ecosystem, it could be that you have a great brand or a data mode.

[06:26] You might have capital, um, but if you’re a startup, again, I’m coming from the startup world here, you just don’t have these advantages. And so you you still want to break through. Uh, and one of the ways that I suggest doing this is by building in the open. And so to be clear, it took Warp 5 years of building closed to sort of make the leap into building in the open, and I’ll explain why. But if you build in the open, um, it helps build your ecosystem. It it can take you from being like hated

[06:57] on Hacker News to like tolerated. Uh, it can burnish your brand, it creates community, and so there’s all these advantages to it. Uh, and some of the things that I think have traditionally been a pain, um, can now be managed. And so like the traditional, you know, pain of open source might be something like you get a lot of noisy issues. You get sloppy PR’s. You can end up in code review hell. You can end up having to spend a lot of time verifying changes. And so the solution, so kind of a long-winded

[07:31] way of getting to this, for open source, or at least for Warp in the case of open source, the thing that made us finally decide to do this was that we built a whole set of automations, really a software factory, around managing the open source project. And so, like I said, this is what I think the future is going to look like. I’m going to drill into it a bit just to get a little bit more technical for folks who want to try to build something like this for their own projects. So what are the components of an effective software factory? Uh, it’s

[08:02] really not that complicated to start or at a high level. You need a set of automations. you need a way of providing context and skills, you need a way of bringing humans in at the correct time. It’s sort of like when things get stuck on the factory. And then a really important thing is you need some set of self-improvement capabilities. So think of this as loops. And if you do this right in the open source world, you can get a you know, world where agents are helping contributors contribute. They’re helping

[08:34] maintainers maintain. And I want to emphasize there’s nothing special about open source here. I think every sizable project can benefit from this approach and I I predict that every every company every open source project will have at its core a software factory kind of like the way that CI/CD became just like oh of course you have that. Uh maybe I don’t know when that happened 10 years ago. Let’s tour the tech the factory floor for a second here. So you’re not going to look at this. This

[09:05] is too much. Uh the the point of this slide is not to have you read the workflow. It’s that the factory floor is basically a graph um of steps where you are defining like okay, how does software get built for my product? And it looks pretty similar for every product. Things come in, they flow through. Um they get stuck at certain points. Um and you know, broadly speaking just to back out a second. So there’s the inputs. The inputs are really ideas.

[09:36] Um the inputs could be coming from your team, they could be coming from your users. Um the inputs themselves tend to come in through certain channels that you should think about as like your task tracker is an obvious one or Slack or Teams like your communication channels. They could come directly from like your terminal or IDE. They could come from your monitoring systems, but there’s some set of inputs that bring work into the factory. There’s triage. This is a really important step. So

[10:07] again, I boil it down to something very simple, but like you want an agent that is looking at issues as they come in and just saying, you know, if this is easy and this is unambiguous, just implement it. And this is how you can actually get going with a factory. If an issue is hard, uh I recommend having uh an agent that produces specs. Folks in here using spec-driven development, show hands. People follow this? Okay. You can do this many different ways, but I think it’s very effective. The way that uh we do it at Warp that I recommend is having an agent write what

[10:41] we call a product spec and a tech spec. Product spec describes the product invariants that you’re building towards. Tech spec describes the architecture and the shape of the code. Then you have an implementation agent. This is basically a coding agent that runs somewhere in the cloud. It makes a diff. You can use all sorts of coding agents for this. You have review. This is in many ways the most painful part. Like I expect that people are a little bit tired of reviewing identical

[11:12] slop. Uh I would have an agent do code review first. And then it becomes over time like a risk management exercise of like when do you bring in humans to do code review, but you want to have a step in here where humans can do it. This is a very important step uh for certain types of apps, the verification step. So, this would be things like computer use. Uh if you’re building a a sort of UI, having the computer actually use the code that the agent produced in producing videos and screenshots.

[11:43] CI/CD, still use it, obviously. Uh and then monitoring. So, our agents don’t stop in your factory when code is shipped. They should observe what’s been shipped. Is it crashing? Is it being used? And round and round you go cuz you take the output of this monitoring step and you feed it back into the top of the factory. Now, you could try and build this and um I went to a talk earlier that my friend Adam gave where Uber has built an internal version of this. Um and it’s

[12:13] pretty cool. I would say for most you know, most organizations, it really depends where you are, you’ll be able to build a simple version of this easily, but to build a thing that actually scales is probably like you should probably focusing on your own product not building this infrastructure because there’s a lot of stuff that you end up wanting. You’re not again not supposed to read this. It’s just a lot of stuff. If you do build it or if you buy it, you’ll end up with something that looks kind of like this which is um

[12:45] you’re going to have a bunch of ways of getting work into your factory. That’s what’s in the top here. You’re going to have a sort of control plane for figuring out how work gets distributed across your factory floor. You’re going to have the actual place where the work happens and so that’s going to be cloud sandboxes. It’s going to be figuring out what agent to run. So what’s the harness? What’s the model? And then finally, I think this is a really important thing. You’re going to want to set up some kind of data plane that sits below your factory. And so that’s something that lets agents

[13:17] remember what they’ve done, learn um improve over time. The factory is not just like a product. It’s also a mindset and this brings me back to the thesis I had at the beginning. You need to measure and improve. So factory this is where the I don’t know, you can stretch this metaphor as far as you want, but like you should be thinking of efficiency and so that means like how much software did you ship? How much did it cost in terms of

[13:50] human time and token time and you’re going to want to measure this and try to improve it over time. A key part of this is creating loops. So uh loops are again, they they sound complicated, they’re not that complicated. Loops are basically ways of uh having agents improve um by like observing what they’re doing, where they’re failing. Um and so a common kind of loop that you’re going to want to put in your factory is like a skill loop. That means you’re going to have your

[14:20] factory agents that are running skills, and then you’ll have observer agents that are seeing how those skills are being applied, looking for issues, and trying to improve the skills. So, for instance, if you had a code review agent, and it was leaving comments, and a senior engineer engineering team is going and correcting those comments, you’d want an observer agent that would look at that and basically improve the code review agent for the next run. This is one thought just to leave folks with, like, what is Where does this

[14:51] leave engineers? Um I think you’re going to have to get into this mindset. And I’m trying very hard to get our team into this mindset. It’s not always easy. That you’re not just building the product, but you’re building the thing that builds the product. And that’s like it’s just different. It’s more like process engineering or manufacturing or something like that. Um and you could think like, okay, maybe that’s a bummer. Like, is that a bummer? Or is that uh you know, and it depends. Like, it depends what

[15:24] joy you get out of software engineering. If your joy is in writing the code, I think you’re everyone in in here who is a software engineer is going to be writing less code. But if your joy is in shipping product, like, it’s never been a better time, and this is actually where I find my joy. It’s like I like building and shipping the thing. So, everyone in here is going to code less, but they’re going to ship more, and that’s going to be a trade-off. But if you approach it like you’re a a factory engineer, I think you can see like that there’s

[15:55] still a really cool set of engineering challenges. Um you can almost think of it as like meta engineering. Like, how do you engineer your system of agents to be the best possible engineering? But I think it’s a very compelling and interesting set of challenges to solve. So, that’s it. Um uh for folks who were interested, uh this If you follow the link on this QR code, I’ve set up um a open source GitHub repo where anyone who wants to try building their own factory agents

[16:27] can do it. This uses Warps agent platform as part of it, but you honestly you don’t have to use it. I’m not trying to like push into our product, but this should give you a good sense of like, okay, if you want to set up an agent that does triage or an agent that does spec writing, how do you actually do that? How do you get from like the theory of working with a factory to actually putting it into practice? I don’t know if we have the capability to do questions in here. I saved a few

[16:57] minutes for questions if anyone has questions, otherwise I will I will wrap up. Yes. >> Yeah, I have a question. So, there’s a bit of a tension in what you said where it’s like, you don’t want to build this cuz this is a lot of work. >> Yes. >> But you are also a factory builder. Like, where do you stand >> It’s a great question. So, I said something that’s almost contradictory. I think you should The way you should think of it is like, everyone’s going to deploy some sort of factory, but then the tuning of the factory, the like, are these the right skills for my domain? Is this factory

[17:27] building my product in the right way? I still think there’s a bunch of interesting engineering challenges. And for some places you can build this, but again, I think I think that the you should probably be focusing on building the core product for your company for the most part, but there’s a bunch of like tuning and like figuring out how to make the factory work for your product that matters. It’s a great question. Yes. >> Hey Tom, thank you so much. Um, I had a question. So, if you were a college student right now >> Yes. >> graduating and entering the workforce, where would you be spending your time?

[18:00] >> Yeah, it’s So, the the question in case people couldn’t hear was like, if I was a college student graduating and entering the workforce right now. So, I think that the most important skills in this new world are adaptability. I think that that’s critical thinking. It’s like the the speed at which you can learn. I do think, I don’t know if you’re a computer science student, but I still think there’s a ton of value in understanding like the underlying systems and architecture and being able to reason and understand the code, understand the specs that agents are written sorry I writing. So,

[18:34] I would focus on on those skills and like I don’t know we’re hiring more people than we’ve ever hired. There’s a lot of kind of like misdirection around like you know, people not being hired because of AI that’s not the experience we’ve had so far and what I’m looking for are like really adaptable product focused thinkers who can like basically be great problem solving problem solvers even as the underlying technology changes. Yeah, I think I’ve time for one more question. Yes.

[19:12] What about the like so the question was what about the the product taste in like the how do you actually build something useful? I think it’s probably the right like maybe the framing and like uh where do the ideas come from? And so I think that um the problem with the factory metaphor even though I’m like leaning into it because I think that’s like there’s something to it is that it can kind of sound like uh mechanizing or dehumanizing um and I still think underlying all of this the only thing that matters is like are you building something useful? And

[19:42] if you have like a a factory that is like turning out that no one cares about it’s like what’s the point? And I think that human taste, human input, human product sense, um humans like guiding at those touch points where you can’t automate stuff is absolutely like essential and like that’s like what I do all like I’m trying to figure out what do what do customers want? What do people want? What’s going to be valuable to them? So, I think that’s an absolutely key point to it. I think I’m at time. So, I have

[20:13] to go. I hope folks enjoyed this chat. I’m really grateful for being invited to speak. So, thank you all very much. >> [music] >> Hey.