O que é preciso para construir uma fábrica de software — Tereza Tížková, Factory

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: What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory · Canal: AI Engineer · 22:24 · Assistir no YouTube

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

Resumo

Tereza Tížková define uma fábrica de software como um ciclo autônomo que abrange todo o desenvolvimento: da coleta de sinais e priorização à execução, validação e melhoria contínua. Ela explica por que a geração de código é apenas uma parte do desafio e destaca a importância de trabalhar com diferentes modelos, conceder autonomia com governança e criar loops verificáveis. A palestra apresenta missões com agentes trabalhadores e validadores, além de estratégias para gerenciar contexto e preparar bases de código para o uso de IA. Por fim, defende que as fábricas de software podem liberar as pessoas de tarefas repetitivas para que decidam o que construir.

Pontos-chave

Uma fábrica de software cobre o ciclo completo de desenvolvimento, não apenas a escrita de código.
A organização deve se preparar para esse modelo; não basta inserir uma ferramenta ou contratar uma consultoria.
A abordagem deve ser agnóstica a modelos e ambientes, autônoma com permissões e governança adequadas, e capaz de aprender continuamente.
O roteamento entre modelos pode equilibrar custo, velocidade e confiabilidade, escolhendo um modelo adequado à dificuldade da tarefa.
Loops longos precisam de critérios verificáveis para determinar se a tarefa foi concluída de verdade, não apenas se passou nos testes.
As missões da Factory combinam um agente orquestrador, agentes trabalhadores em sequência e validadores que revisam o resultado.
Validadores podem inspecionar o código e também testar a aplicação em um ambiente virtual, interagindo com ela.
A divulgação progressiva de ferramentas e informações pode evitar o excesso de contexto e reduzir o uso de tokens.
Bases de código organizadas, documentadas, testadas e reproduzíveis favorecem a adoção produtiva de IA.
A palestrante prevê que as pessoas passarão a supervisionar agentes e decidir o que construir, em vez de se concentrar em como construir.

Capítulos

Início	Capítulo	Resumo
00:01	O que é uma fábrica de software	A palestrante define o modelo como um ciclo autônomo de desenvolvimento e explica por que avanços recentes tornaram sua aplicação mais viável.
03:26	Princípios: flexibilidade, autonomia e melhoria contínua	A Factory defende uma abordagem agnóstica, com permissões e governança apropriadas e mecanismos para aprender continuamente.
05:04	Roteamento entre modelos	A palestra descreve como classificar tarefas e escolher modelos para equilibrar custo, velocidade e confiabilidade.
09:47	Loops, missões e validação	A palestrante apresenta missões com agentes orquestradores, trabalhadores e validadores, enfatizando critérios verificáveis e testes de uso.
15:44	Contexto e preparação da base de código	A fala aborda a divulgação progressiva de ferramentas, a redução do excesso de contexto e a importância de preparar e documentar o código.
20:08	O papel das pessoas nas fábricas de software	A palestrante imagina pessoas supervisionando agentes e escolhendo o que construir, enquanto a automação assume tarefas mais repetitivas.
21:52	Encerramento	A palestra termina com a ideia de delegar tarefas tediosas aos agentes e reservar às pessoas o trabalho mais interessante.

Citações

Gerar código e escrever código é a parte fácil, em comparação com todo o resto. — 02:51

O desafio é verificar se o loop terminou e se a tarefa foi realmente concluída. — 10:52

Os validadores avaliam código que não escreveram. — 13:38

Nós, humanos, devemos decidir o que construir no software, não como construir. — 21:18

Acredito que a IA vai tirar de nós as tarefas irritantes. — 21:52

Conceitos e entidades

software factory (conceito): Modelo que automatiza o ciclo completo de desenvolvimento de software, incluindo priorização, execução, validação e melhoria contínua.
automatic model routing (ferramenta): Recurso da Factory que seleciona e pode alternar entre modelos conforme a tarefa e o desempenho.
factory missions (conceito): Sessões longas em que agentes trabalham em tarefas por meio de ciclos de execução e validação.
deferred context engine (ferramenta): Mecanismo que revela ferramentas e suas descrições gradualmente, conforme se tornam necessárias.
Agent readiness (conceito): Verificação da preparação de uma base de código e de seu ambiente para a adoção de agentes.
Factory (empresa): Empresa apresentada por Tereza Tížková como criadora de produtos e recursos para fábricas de software.
Tereza Tížková (pessoa): Palestrante que apresenta a visão da Factory sobre a construção de fábricas de software.
EY (empresa): Uma das empresas citadas como exemplo de organização para a qual é possível construir uma fábrica de software.
Adobe (empresa): Uma das empresas citadas como exemplo de organização para a qual é possível construir uma fábrica de software.

Tradução completa (pt-BR)

00:01 [música]

00:36 Oi, pessoal. E aí, tudo bem? Sou Teresa. Hoje vou falar sobre software factory. Todo mundo está falando sobre software factory, mas poucas pessoas estão realmente construindo uma, e menos ainda sabem o que é preciso para construir uma e como defini-la. Então, vou falar sobre o que é uma software factory, se você deve construir a sua ou terceirizar, o que já funciona em produção, quais são os principais desafios e quanto tudo isso vai custar. Meu nome é Theresa. Trabalho em uma

01:10 empresa chamada factory.com, e há bastante tempo estamos desenvolvendo esse conceito de software factory, mas, finalmente, a tecnologia está avançando e já é possível construir isso em produção para empresas como EY ou Adobe. Eu definiria a software factory como o ciclo completo, todo o ciclo de vida do desenvolvimento de software com autonomia — o que não significa apenas programar e gerar código. Com isso, quero dizer coletar todos os sinais, reagir ao feedback dos usuários e aos logs, priorizar o que é importante e, então, orquestrar tudo

01:45 isso, executar, validar, fazer testes realmente bons em produção e, depois, iterar sobre tudo isso, ao mesmo tempo que se aprimora continuamente o processo e se adquirem novos conhecimentos e novas habilidades. Este é apenas o nosso dashboard, mostrando como é a nossa software factory. Se você olhar, ele abrange todo o ciclo. Isto é só um pouco de história — e, quando digo história, quero dizer 2023 na área de IA. A software factory não era realmente possível antes, embora nós

02:16 sempre tivéssemos essa ideia desde o começo do CH GPT lounge e de outros. Tínhamos essa ideia de um ciclo contínuo; já existiam o autog baby agi, com os conceitos de iterar no software, mas isso não funcionava antes porque os LLMs alucinavam, havia problemas com o tamanho do contexto, com a qualidade do raciocínio e outros problemas desse tipo, ou não tínhamos bons ambientes nos quais os agents pudessem realmente trabalhar de forma isolada. Tudo isso acabou levando a que a software factory seja o paradigma que está começando

02:51 a se popularizar agora e a ser realmente útil. Gosto de definir as coisas pelo que elas não são. Então, quero dizer que software factory não é apenas um coding agent, nem mesmo um enxame de coding agents — nem milhares de agents —, porque gerar código, escrever código, é a parte fácil em comparação com todo o resto. Os engenheiros nem sequer passam a maior parte do tempo apenas escrevendo código. Os desafios estão no restante. É isso que quero aprimorar. E não é apenas algum tipo de consultoria ou uma estratégia abstrata que alguém vai tentar vender

03:26 a você e à sua organização. Acho que as abordagens são, claro, diferentes, mas acreditamos que você realmente deve reconstruir sua organização desde o início para prepará-la para se tornar uma software factory. Não dá para contratar uma consultoria e simplesmente colocar alguma coisa no meio da sua organização. Você precisa agir com cuidado e reconstruí-la do zero. Essa é a abordagem que gosto de mostrar para construir a software factory, e acho que é parecida com construir uma

03:58 equipe humana de verdade, porque há muitos agents, como eu disse: eles vão testar, validar e iterar, e tudo isso pode acabar virando um grande caos. Então, é preciso agir com cuidado, e eu diria que os três pontos importantes são: ser agnóstico na software factory, ou seja, ser independente das escolhas de LLM e da forma como a organização já trabalha; depois, é preciso ter autonomia. Então, você precisa dar aos agents os níveis de confiança adequados e todas essas permissões e regras de governança, e confiar neles para que funcionem por muito tempo, porque as previsões são

04:30 que os agents vão funcionar por até um ano ou mais sem intervenção humana. Claro que isso parece ambicioso, mas, por exemplo, nossas missões — nossas sessões de longa duração — já estão construindo coisas e funcionando por semanas. Então, não é tão absurdo. E o terceiro ponto é estar sempre melhorando. Assim como numa organização humana, você precisa integrar cada pessoa nova da equipe, dando a ela um bom entendimento da base de código, uma boa estrutura e documentação, e também permitindo que ela melhore durante o processo, adquira novos conhecimentos e os compartilhe com a equipe. Compartilhe-os.

05:04 Esses são os três pontos. Agora, vamos falar sobre ser agnóstico. Acho que é importante destacar que, se você está construindo diferentes componentes da software factory, precisa estar preparado para a forma como cada um já trabalha. Você precisa funcionar em diferentes ambientes, como Slack e GitHub, e se conectar a tudo. Também precisa permitir que as pessoas usem as assinaturas que já têm, porque, a cada vez que surge uma nova tecnologia, novos modelos de ponta ou novos benchmarks, é muito

05:36 difícil acompanhar, mas também prever o que vai sair na frente. Então, o melhor é ser agnóstico para todo mundo. Depois, há o tema de ser agnóstico em relação aos modelos. Esse tem sido bastante discutido recentemente, e este gráfico é do CEO da Coinbase, que publicou um tuíte sobre como começaram a economizar dinheiro com IA na organização sem reduzir o gasto com tokens. A linha preta mostra quanto gastaram com

06:07 tokens. O gasto continua crescendo, e eles continuam maximizando o uso de tokens, mas pararam de gastar tanto dinheiro. Como fizeram isso? Com diferentes truques, como definir modelos padrão diferentes para as pessoas. Então, parar de incentivar as pessoas a usarem apenas os modelos de ponta como padrão. Depois, usar cache, é claro, para não repetir as mesmas coisas toda vez. E não impor limites de gastos, mas exigir que as pessoas vejam os resultados quando gastarem muito. E a última coisa, que é um tema realmente importante, é o roteamento inteligente

06:37 entre LLMs, otimizando o uso de tokens entre eles, em vez de simplesmente gastar tantos tokens. Criamos algo na Factory chamado roteamento automático de modelos, e recebemos muitas perguntas sobre isso. O que ele faz é encaminhar automaticamente as tarefas entre diferentes modelos durante o processo. O importante é que primeiro decide qual modelo é o mais adequado e, depois, pode mudar para outro modelo se não estiver conseguindo concluir a tarefa ou

07:09 se houver algum problema, mas isso normalmente não acontece. O importante é que não ajuda apenas a economizar dinheiro. Também ajuda com a confiabilidade e a velocidade, porque os modelos open source costumam ser mais rápidos. E, se um provedor de LLM falhar, você pode simplesmente mudar para outro automaticamente. Então, ele faz muito mais do que apenas economizar dinheiro. Este é o nosso benchmark, que é bem conservador. Prefiro benchmarks conservadores, mas acho que a tendência é

07:40 clara. Por exemplo, você pode economizar 25%, e provavelmente até mais. Como funciona o roteamento? Há quatro partes. Primeiro, você simplesmente atribui a tarefa e não precisa fazer mais nada, mas, como organização, pode, por exemplo, dar permissões diferentes e definir modelos padrão diferentes para pessoas diferentes, o que é muito útil: marketing, vendas e engenharia podem ter modelos padrão diferentes. Depois, vem a classificação, que é a parte importante. Essa é a mágica do roteamento. É preciso realmente

08:12 analisar a estrutura do prompt, da base de código, o grau de dificuldade da tarefa, quais ferramentas estão sendo usadas e todos esses fatores, e classificar o nível de dificuldade da tarefa. Depois disso, você basicamente define um limite mínimo para o que é suficiente para concluir a tarefa e escolhe o modelo mais barato acima desse limite. Ou seja, o modelo mais barato que, segundo a previsão, consegue concluir sua tarefa. E então você prossegue. Certo. Quando lançamos isso, recebemos

08:42 muitas perguntas, como: isso realmente funciona? E se o modelo for encaminhado incorretamente? É mais lento? Na verdade, é mais caro? E se o modelo não conseguir concluir a tarefa ou precisar mudar para um modelo melhor? E como vocês lidam com o cache? Acho que todas essas são perguntas válidas, e é por isso que é tão difícil construir um bom roteador: você precisa classificar muito bem e o desafio é não precisar trocar com muita frequência, mas, mesmo que você troque no meio da tarefa, passar de uma tarefa difícil para uma mais difícil

09:14 modelo, no geral, você ainda é mais rápido, provavelmente porque ainda vale a pena. Isto é só uma visão geral do cacheamento. Recebemos muitas perguntas sobre isso: como lidamos com o cacheamento? Damos descontos aos usuários? Porque os laboratórios de LLM, claro, economizam muito dinheiro usando cache e pulando o pré-preenchimento do contexto o tempo todo. Modelos open também podem fazer isso. Acho que às vezes as pessoas se esquecem disso, e você também pode hospedar modelos open em computação dedicada.

09:47 E aproveitar o mesmo cacheamento. Então, aumentar o preço final para os usuários é apenas uma decisão de precificação. Não é um desafio técnico, porque qualquer um pode usar cacheamento. A questão é que preço você repassa aos usuários e que acordos faz com os provedores de API. Então, isso é ser agnóstico. E agora, a autonomia, que é o núcleo da fábrica de software. Todo mundo está falando de ciclos. Acho que os ciclos já existem há bastante tempo, em diferentes contextos. Eles estão apenas avançando e passando para o contexto dos agents.

10:20 Provavelmente você já ouviu falar do ciclo Ralph, de especificar as tarefas e dividi-las em subtarefas para os agents. É um conceito conhecido, e a questão não é o ciclo em si, mas como definir o que significa concluir o ciclo. Este é um exemplo de um colega meu: ele criou um ciclo de agents para fazer uma impressão 3D do nosso logo.

10:52 Acho que aqui dá para ver qual é o desafio dos ciclos: antes, na programação, havia critérios claros para determinar o que significava concluí-los. Agora, os critérios se tornam abertos, porque muitas tarefas são bastante não determinísticas. É basicamente um mundo aberto: dá até para fazer coisas no mundo real, como imprimir algo. E é muito difícil definir como verificar se o ciclo terminou, se a tarefa foi concluída. Essa é a parte difícil. Eles só precisam ser verificáveis. A isto eu chamo de gráfico assustador. Ele basicamente mostra que as tarefas e o tempo que elas são executadas de forma autônoma com agents vêm aumentando. Mas ainda não são tão confiáveis.

11:26 Mesmo que você consiga executá-las por muito tempo, isso não significa que serão confiáveis em produção, e provavelmente ainda vai precisar iterar e dar feedback. Então, isso ainda não foi resolvido, e há problemas como trapaça. Por exemplo, se você escrever de forma errada o que significa concluir uma tarefa, o agent pode tentar passar nos seus testes, mas sem realmente verificar o que precisa fazer e concluir; em vez disso, pode simplesmente tentar passar no seu teste.

11:59 Para trapacear dessa forma, temos algo chamado missões da Factory. São sessões longas, muito longas, dos agents. Chamamos de missões porque enviamos o agent para uma missão. As missões funcionam em um ciclo, iterando na tarefa até que ela seja concluída, e podem durar até semanas. O agent principal é o orquestrador, que atribui trabalho aos agents trabalhadores e, depois, aos validadores, que revisam a tarefa. Este é um exemplo de uma missão real de um dos nossos clientes, que durou 16 horas. E isso só

12:35 para mostrar como a validação também é importante: ela pode levar até 40% do processo inteiro. Para resumir, o orquestrador decide e escreve as condições do que precisa ser feito. Depois, passa isso aos agents chamados trabalhadores. Os agents trabalham na tarefa. E o que é interessante, ou vale notar, é que eles trabalham em sequência. Não trabalham em enxame nem em paralelo. Os agents trabalham em sequência, cada um realiza algo e passa para o próximo. Na verdade, descobrimos que, se fizer isso,

13:06 você acaba com um contexto mais novo e uma espécie de mente mais fresca. É parecido com quando outros colegas verificam o código de uma pessoa. Então, fazemos algo semelhante: deixamos os agents passarem o trabalho para o próximo. Mas cada trabalhador da sequência ainda pode ter subagents trabalhando em paralelo em tarefas menores. Por exemplo, pesquisar na web ou criar arquivos nesse meio-tempo. Então, eles trabalham em sequência, e cada um também tem subagents. Os validadores revisam o resultado, dão feedback e o enviam de volta ao início.

13:38 O importante é que os validadores avaliam código que não escreveram. Há algo do agent orquestrador chamado contrato de validação, que é escrito antes de qualquer código ser feito. O primeiro tipo é o validador de análise rigorosa. O segundo é o validador de testes com usuários. O de análise rigorosa é quem realmente verifica como está a base de código: os linters, os tipos, os testes. É uma verificação muito rigorosa do código. Mas o segundo, acho, é realmente interessante: o validador de testes com usuários.

14:08 E esse é quem realmente entra em campo e testa as coisas. Não se importa com como foram feitas: simplesmente vai até lá, funciona no computador virtual e clica nas coisas, verificando de verdade se tudo funciona. Vi um engenheiro migrando bases de código com o Droid, usando nosso agent, e no fim ele realmente precisou que o agent clicasse nas coisas porque, com outros produtos, ele simplesmente criava o produto, mas ele não funcionava e não era interativo.

14:39 Era só um resultado falso. Então, nosso agent, que realmente clicava nas coisas, permitia verificar se estava funcionando de fato, e não apenas se o código parecia bom. Acho que essa é uma coisa muito legal, que também foi possível graças ao progresso no uso do computador e aos ambientes persistentes — máquinas virtuais para agents —, que antes não existiam ou não eram tão bons. Agora são realmente ótimos, permitindo que o agent entre em campo. Este é apenas um exemplo de uma missão real dos nossos usuários. Gosto de entender o que os usuários estão criando e

15:13 receber feedback. E é assim que isso pode aparecer no seu painel. É assim que visualizo as missões. O interessante é que é apenas um ciclo com ciclos menores, porque cada um dos agents também funciona em ciclos, mas, no geral, é um ciclo grande. Certo, talvez isso seja um pouco estranho, mas gosto que sejam todos ciclos com ciclos menores. Certo. E a terceira parte: melhorar sempre, aprender sempre.

15:44 Há esse elefante na sala: o contexto com agents. Muitas perguntas válidas são do tipo: como lidar com a inflação de contexto, já que você trabalha nessas missões longas na fábrica de software, e como manter o contexto limpo? Essa preocupação é muito válida, porque empresas, especialmente, usam centenas de ferramentas: Figma, notion, Gmail, drive, slack, em média. Todas elas têm especificações no código, esquemas, parâmetros e descrições de registros. Então, isso pode fazer o agent ficar realmente sobrecarregado e escolher as ferramentas erradas se houver duas ferramentas com nomes parecidos, ou fazer com que perca o contexto porque elas preenchem a context window e é preciso compactá-la.

16:18 Então, isso é realmente perigoso. Para lidar com isso, temos algo na fábrica de software chamado mecanismo de contexto adiado, que desenvolvemos para revelar progressivamente o que está no contexto e quais ferramentas usar. Basicamente, temos ferramentas surpresa que só ajudam mais tarde, se forem realmente necessárias. Então, no início, ele tem apenas uma lista curta das ferramentas e

16:54 apenas descrições curtas. Quando uma ferramenta é realmente necessária no código, eles podem chamá-la e carregá-la por completo. O importante é que nada é realmente removido: apenas fica oculto e inacessível até ser necessário. Fica reservado para depois. E o importante é que isso economiza muitos tokens em escala, quando você usa cada vez mais ferramentas. Quanto mais ferramentas você usa, mais tokens economiza; isso realmente escala, e você pode economizar 50% dos tokens ou mais. Certo. Outra coisa complicada

17:24 e que me surpreendeu da primeira vez é que, ao adotar IA, você pode ter um grande sucesso ou um grande fracasso. É um pouco como uma lei de potência. Então, se sua base de código não estiver pronta, se não for estruturada e não tiver todas as coisas importantes, adotar IA ou se transformar em uma fábrica de software pode acabar piorando as coisas e degradando seu código. E há uma grande e crescente diferença de produtividade entre quem simplesmente adotou IA e quem realmente refletiu um pouco mais sobre isso.

17:58 Há outros dados de Stanford sobre isso: sem uma base de código estruturada, pronta para o uso de IA e bem documentada, a IA pode piorar seu código. E acho que, se vocês são engenheiros, provavelmente concordam que às vezes a IA realmente faz uma bagunça, e isso pode se acumular cada vez mais, ficando difícil voltar atrás. Como parte da software factory, temos algo chamado prontidão para agents. É uma estrutura — não gosto da palavra “estrutura” —, mas encarem como uma verificação de higiene da base de código.

18:30 E há uma correlação bem interessante entre o estado da sua base de código e todos os detalhes dela e o quanto você vai conseguir adotar bem a IA e se tornar produtivo, em vez de ficar com uma base de código bagunçada. Há fatores como: quão reproduzível é o ambiente de desenvolvimento? Você escreveu bons testes? Está tudo bem documentado? Qual é o estilo do seu código? E quanto aos testes e linters? Tudo o que você também faria para manter a base de código limpa. Então, esses fatores

19:02 se mostram muito úteis. Nossos clientes maiores passam por essa estrutura de prontidão para agents e fazem todas as verificações. Depois, podem dar continuidade com as ações recomendadas para corrigir os problemas. Acho que mais uma coisa sobre o contexto e o aprendizado contínuo na software factory é que, na maior parte do tempo, ao trabalhar com IA — ou, pelo menos, pela minha experiência —, você fica repetindo para os agents como quer que as coisas sejam feitas e sente que o agent não entende você de verdade. E acho que

19:36 isso é mais uma boa analogia com organizações e equipes humanas, porque, quando você entra em uma empresa nova, há muitas regras que não estão realmente codificadas em lugar nenhum. Você simplesmente aprende e observa como as coisas são feitas, e há muitas coisas implícitas que não dá para aprender em nenhum outro lugar além de observando. Acho que isso também é um grande desafio para os agents. Uma coisa que lançamos para lidar com isso são plugins, que são skills reutilizáveis e empacotadas, além do contexto e das coisas que acontecem nos bastidores, que você realmente pode codificar ou

20:08 automatizar, atualizando automaticamente nossa documentação e revisando e documentando o que você tem. Então, a pergunta é: o que vai acontecer conosco, humanos, se construirmos uma software factory assim? Os humanos simplesmente vão perder seus empregos e acabar em uma subclasse permanente? Acho que não. E quero ser otimista. Então, penso nessa analogia de os humanos simplesmente subirem de nível, passando para tarefas mais legais do que antes. Acho que, na verdade, já tivemos

20:45 essa mesma experiência de nós, humanos, subirmos alguns níveis de abstração. Na verdade, começamos como computadores humanos. Éramos nós que fazíamos todo o trabalho mais detalhado no começo. Depois vieram as linguagens de programação, que codificaram parte desse trabalho e elevaram o nível de abstração; depois, os coding agents, que passaram a assumir parte dele, mas ainda com a gente muito envolvida e monitorando tudo de perto. E agora estamos avançando, de certa forma, para as software factories, onde gerenciamos esses agents — como eu disse, agents orquestradores,

21:18 workers e validadores, todas essas equipes estruturadas de agents que trabalham continuamente, em um ciclo, enquanto nós apenas monitoramos e decidimos o que construir. Então, quero mesmo terminar com uma mensagem positiva. Nós, humanos, devemos decidir o que construir no software, não como construí-lo, porque isso cabe aos agents. Com esse ciclo contínuo de software autônomo, acho que podemos realmente chegar lá. Este é um gráfico de alerta, ou algo assim, para quem

21:52 acha que a IA vai tirar de nós as coisas legais. Na verdade, acredito que ela vai tirar as coisas irritantes. Em empresas e organizações, vocês já gastam muito tempo com alinhamentos e reuniões, como mencionei: basicamente, com aquilo que fica implícito, mas que você realmente precisa fazer — obter contexto de todos, compartilhar seu status e sincronizar as coisas em reuniões. Tudo isso poderia ser transferido para a sua software factory, e vocês poderiam simplesmente conversar sobre as coisas legais. Certo, é isso. Muito obrigada. Vão tocar um pouco de grama

22:24 e deixem seus agents construírem por vocês. Obrigada. [aplausos] [música] >> [música]

Transcrição original

[00:01] [music]

[00:36] Uh hi everyone. Hey what’s up? I’m Teresa. Uh and today I will be talking about software factory. uh everyone is talking about software factory but only few people are actually building one and even fewer people know what it actually takes to build one and how to define it. So I will be talking about what is a software factory, should I build your own or outsource it, what works in production already, what are the main challenges and how much is this all going to cost? Uh my name is Theresa. I work at a

[01:10] company called factory.com and we’ve been building uh this concept of the software factory for quite a long time but finally uh the technology is catching up and it’s possible to build this in production for enterprises like EY or Adobe uh I would define the software factory as the whole loop the whole life cycle of developing software with autonomy which doesn’t mean just coding and generating code by that I mean collecting all the signals reacting to user feedback to logs, prioritizing what’s important, then orchestrating it

[01:45] all, executing, validating, doing really good uh testing in production and then iterating on all this uh while also continuously improving in the process and gaining new knowledge and new skills. So this is just our dashboard how our software factory looks if you if you look at it and it’s catching the whole cycle there. uh this is just some history and by history I mean 2023 in AI. So the software factory wasn’t really possible before even though we

[02:16] always had this idea from the beginning of uh CH GPT lounge and others we had this idea of the continuous loop there was autog baby agi already with the concepts of iterating on the software but it didn’t work before because the LMS were hallucinating there was problem with context length uh problem with the reasoning quality uh different problems like this or we were missing good environments where the agents can actually work in the isolation. So all this kind of led to why the software factory is the paradigm that’s starting

[02:51] to be popular now and actually useful. I like to define things by what they are not. So I want to say software factory is not just coding agent and it’s not even a swarm of coding agents even thousands of agents because generating code writing code that’s the easy part compared to all the others. uh engineers don’t even spend most of the time uh just writing code. The challenges are the rest of it. Uh so this is what I want to enhance and it’s also not just some consultancy or just some abstract strategy that someone will try to sell

[03:26] you and to your organization. Uh I think the approaches are of course different but we believe you should really rebuild your organization from ground up to be ready to become a software factory like you can’t invite a consultancy and just throw something in the middle of your organization. You should really be mindful and rebuild it from scratch. uh this is the approach I like uh showing to building the software factory and I think it’s similar to building the

[03:58] real team of humans because there is a lot of agents as I said they will be testing validating iterating and it all can end up as a big chaos uh so you need to be mindful and I would say the three important things is being agnostic in the software factory so being independent of LLM choices uh of how you already work as the organization then you need to be autonomous. So you need to give the agents the right trusts and all this permissions and governance and you need to trust it to run really for a long time because the predictions are

[04:30] that agents will run even a year or more years without the human in the loop. Of course that sounds ambitious but for example our missions already our long runninging sessions already build uh things and run for weeks. So it’s not that crazy. And third thing always improving. So same as human organization you need to onboard any new people in your team by giving them good uh code base understanding good structure documentation and also let them improve in the process and gain new knowledge and share it share it within the team.

[05:04] So these are the three points and now let’s talk about the agnostic one. Uh I think the important thing to point out if you are a builder and building different primitives of the software factory you need to be ready for how everyone is already working you need to work across environments like Slack, GitHub and connected to everything and you need to also allow people to already bring subscriptions they are using because there is every every time there is like new technology, new frontier models, uh new benchmarks and it’s so

[05:36] difficult to catch up but also to predict what we’ll be winning. So it’s best to be agnostic for everyone. Uh then there’s the topic of being agnostic to models. Uh this is a topic of a lot of discussions recently and this chart is from this chart is from CEO of Coinbase uh who tweeted about how they started uh started saving money in their organ or organization on AI but without reducing the token spend. So the black line is how much they spent on

[06:07] tokens. They continue growing and token maxing but they stopped spending so much money. Uh how they did it uh different tricks like different default default models for people. So stop pushing people to use only the frontier as a default. Then caching of course uh to stop preferring the stuff every time. And then no limits on spending but just needing to see the results if you spend a lot. And the last thing that’s really important topic is routing. So smart

[06:37] routing between LLMs and just a token optimizing between uh the LMS instead of just spending so much tokens. Uh we built uh a thing in factory called uh automatic model routing and there’s been a lot of questions around it but what it does is it automatically routes between different models in your process. The important thing is it decides first what model is most optimal and then uh it can switch to different model if it’s failing the task or in

[07:09] case of any troubles but it usually doesn’t happen and important thing is it doesn’t just help uh spend money. It also helps with reliability or with speed because open source models are often faster and uh if one LM provider fails you can just switch to another one automatically. So it really does more things than just saving the money. This uh is our benchmark which is very conservative. I prefer conservative benchmarks but I think the direction is

[07:40] clear. You can save for example 25% but even more probably. Uh how the routing works uh there are four parts. First you just assign the task and you don’t really need to do anything but as an organization you can for example give different permissions and different default models to different people which is very useful like marketing or sales or engineers can both uh have different default models and then you have the classification which is the important part. This is the magic of the routing. You need to really

[08:12] uh look at the structure of the prompt of the uh code base of how difficult the task is, what tools are being used, all these factors and make a classification of difficulty of the task. Uh after that you basically do a threshold of what is enough to accomplish the task and you choose the cheapest model above the threshold. So cheapest model that is predicted to accomplish your task and then you go. Okay. So when we launched this we got a

[08:42] lot of questions like does it actually work? What if uh the model mis routes? Uh is it slower? Is it more expensive actually? What if the model can’t accomplish the task or what if it needs to upgrade? And how do you handle caching? So I think these are all valid questions and that’s why it’s so difficult to build a good router like you need to basically classify it very well and the challenge is to not not to need to switch too often but even if you’re switching in the middle of the task to difficult to more difficult

[09:14] model you still overall are faster probably because it’s still worth uh this is just some overview of caching uh lot of questions we got on this was also So how do we handle caching? Do we do discounts for users? Uh because LLM LLM labs of course save a lot of money by caching and skipping all the context prefill all the time. Uh open models can do this as well. I think people sometimes forget this and you can just host open models as well uh on dedicated

[09:47] compute and you can take the same advantage of the caching. Uh so I want to enhance uh the final price for users. is just a pricing decision. It’s not a technical challenge because everyone can do caching. It’s just what price you pass on the users and what deals you make with the API providers. So this is uh being agnostic and now the autonomy which is the core of the software factory. Uh everyone is talking about loops. Uh loops I think have been

[10:20] here the whole time already in different context. They are just now leveling up and moving to the context of agents. You probably heard about the Ralph loop and specifying the tasks and splitting to subtasks for agents. Uh this is a known concept and uh the question is not the loop itself but the question is how how you define what it means to be done in the loop. This is one example from my colleague uh he he made a loop uh of agents building 3D printing of our logo.

[10:52] uh I think here you can see what is the challenge of the loops because uh before in programming loops had clear criteria of what it means to be done while now the criteria become open-ended because a lot of the tasks are very nondeterministic it’s basically open world you can do even real stuff like printing something and it’s really difficult to define how do you verify that the loop was done that the task was accomplished so that’s the difficult part uh yeah they just need to be verifiable This I call the scary chart. It basically shows that the tasks and how

[11:26] long they run autonomously with agents have been increasing. But still it’s not that reliable. Even if you can run for a very long time, it doesn’t mean that it will be reliable in production and you still probably need to need to iterate on it and uh provide feedback. So it’s still not solved and there are problems like cheating. For example, if you write the what it means to be done in the wrong way, the agent can try to pass your tests but not really like not really verify what you need to do and accomplish but instead try to solve just

[11:59] passing your test. So cheating by that uh we have something called factory missions and this is like long longunning sessions of the agents. We just call it missions because we send the agent to the mission and uh the missions work in the loop and iterating on task until it’s done and they can do it even for weeks and uh the main agent is orchestrator and then it’s uh assigns work to workers agents and then validators who review the task. So this is one example uh real mission from our customers that run 16 hours and just

[12:35] just to see how important is the validation as well. it takes even 40% of the whole process. Uh to summarize, the orchestrator just decides and writes the conditions what it needs to be done. Then it gives it to the agents called workers. The agents work on it. And what is interesting or worth noting is that they work in a sequence. So they don’t work in a swarm or parallel. The agents work in sequence and everyone accomplishes something and passes it to the next one. uh we actually found that if you do this

[13:06] you end up with more fresh context and kind of fresh head. Same with when with humans have like other colleagues verifying their code. So similar thing we just let the agents pass to the next one. But still every worker of the sequence can have parallel agents doing smaller tasks. So I don’t know researching on the web or building files during that. So they are in sequence and everyone has sub agents as well. and validators they review the output and provide feedback and send it back to the beginning.

[13:38] Uh important thing is uh the validators judge code that they didn’t write. Uh there’s something from the orchestrator agent called validation contract uh that’s written before any code is done. And first type is scrutiny validator. Second is user testing validator. The scrutiny is the one who really verifies how the codebase looks. the liners types tests it’s really rigorous check of the code but the second I think is really interesting is user testing validator

[14:08] and that’s the one who is really in the arena trying the things so it doesn’t care how it was made it just goes it works in its virtual computer and it clicks on the stuff and really checks if everything works I’ve seen one engineer migrating uh code bases with droid with our agent and uh it really needed the agent in the end to click through the stuff because with other products it just created created the product but it didn’t work and was wasn’t interactive.

[14:39] It was just a dummy result. So our agent that really clicked on the stuff uh allowed to check that it’s actually working and not just looking good in the code. I think this is one cool thing that was also allowed by the progress in computer use and the persistent environments virtual machines for agents which also wasn’t here before or wasn’t that great but now it’s really great so it’s allowing to go in the arena as an agent. Uh this is just one example of real mission from our users. I I like to just learn what users are building and

[15:13] get feedback and this is just uh how it can look in your dashboard. And this is how I visualize the missions. What is interesting is that it’s just a loop with smaller loops because every of the agents are running in loops as well, but overall it’s like one big loop. Okay, maybe this is a bit weird, but I just like that it’s all loops with smaller loops. Uh, okay. And the third part, always improving, always learning.

[15:44] Uh there is this elephant in the room context with agents. A lot of questions which are valid are like how do you navigate the context blo because you work on these long missions in the software factory and how do you actually keep the context clean and that’s very valid because enterprises especially they use hundreds tools they use Figma, notion, Gmail, drive, slack like hundreds tools on average. So all these have specification in the code. all these have schema and parameters and log descriptions. So, uh it can cause agent

[16:18] to really bloat with that and pick wrong tools if there are two tools that sound similar or to actually lose context because they fill up the the context window and need to compress. So, this is really dangerous. Uh for this we have something within the software factory called uh deferred context engine and we build it such that we just progressively disclose what’s in the context and what tools to use. So we basically have a surprise tools uh that help later only if they are actually needed. So it first just has short list of the tools and uh

[16:54] only a short descriptions and when it’s needed actually in the code uh they can call the tool and fully load it. So important thing is nothing is actually removed it’s just hidden and not reachable until needed. So it’s just for later and important thing is it actually saves a lot of tokens uh at scale once you use more and more tools. uh the more actually you save it really scales and you can save 50% of tokens or more. Okay. Uh another thing which is tricky

[17:24] and was surprising for me for the first time is that when adopting AI you either succeed big or you can fail big the same way it’s a bit of power law. So if your codebase is not ready, if you don’t have structured codebase and all important things, then adopting or turning into software factory can actually make you end up worse and make your code degrading. And uh there is a big and growing gap in productivity between those who just adopted AI versus those who actually thought about it a bit more.

[17:58] Uh there is another data from Stanford about yeah without structured uh code base and being ready and documenting well the AI can make your code worse and I think if you are engineers you probably can agree that sometimes AI really makes a mess and this can really compound more and more and it’s difficult to go back. uh we have something as a part of the software factory uh we have something called agent readiness and it’s a framework I don’t like the word framework but uh take it as a hygiene

[18:30] check of your codebase and things you should do because there is actually nice correlation between how your codebase is looking and all the details there and how good you’re going to adopt the AI and end up productive instead of uh with a messy code base. So there are things like how how reproducible is your developer environment or if you have written good tests if you have all things well documented what’s the style of your code all the tests and llinters uh everything that you would do also to keep codebased screen. So these factors

[19:02] actually show to be very useful and we have our bigger customers actually go through this agent readiness framework and do all checks and then they can follow up with recommended actions uh how to fix that. Uh I think one more thing about the context and the continuous learning in the software factory is the most of the time when working with AI or at least from my experience is that you keep repeating to agents how how do you want the things done and you feel like the agent doesn’t really get you and I think

[19:36] this is again nice parallel with human organizations and teams because when you join a new company there are a lot of rules that are not really codified anywhere like you just learn and observe how things are done and there are a lot of things between the lines that you can’t really learn anywhere else than just observing. I think this is big challenge for agents as well and one thing we launched for that is plugins which are like packaged reusable skills and context and the things behind the scenes that you can really codify or

[20:08] auto which is automatically updating our documentations and uh yeah and um reviewing and documenting what you have. So the question is what will happen to us humans if we build software factory like this? Uh will humans just lose jobs and go to permanent underclass? I think they will not. And uh I want to be positive. So I’m thinking of this parallel of humans just moving up uh levels up to the uh to the cooler tasks than before. I think we actually had

[20:45] before the same same experience of us as humans abstracting some levels up and we actually started ourselves as human computers. We actually were the computers doing all the most detailed stuff at the beginning. Then we had programming languages codifying some of it, abstracting and then coding agents. So outsourcing some of it but uh still being in the loop very closely uh and very monitoring everything. And now we are moving kind of up to software factories where we manage these agents as I said orchestrator agents and

[21:18] workers and validators and all these teams structured teams of agents that work really continuously in the loop and we just monitor and decide what to build. Uh so I want to really end this positively. We should be as humans deciding what to build in the software not how to build it. uh because that’s up for the agents and by this uh continuous cycle of autonomous software I think we can actually achieve that. Uh this is one warning chart or if someone

[21:52] thinks AI will take the cool cool stuff from us. I believe actually it will take the annoying stuff and in enterprises and organizations you already spend a lot on alignments on the meetings as I mentioned basically the thing behind between the lines that you really need you need to get context from everyone share your status sync on the things on meetings so all these things could be actually outsourced to your software factory and you could be just talking about the cool stuff okay so this is it thank you so much go touch some grass

[22:24] and let your agents uh built for you. Thank you. [applause] [music] >> [music]