A fábrica de software: do relatório de bug ao código em produção — Davis Palmie, 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: The Software Factory: From Bug Report to Production Code — Davis Palmie, Factory · Canal: AI Engineer · 18:09 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Governança e regulação de IA

Resumo

Davis Palmie apresenta a fábrica de software como um sistema de agents que transforma sinais de entrada, como bugs e feedback de usuários, em código de produção. Ele descreve como a função dos engenheiros muda da implementação manual para a supervisão, a definição de prioridades e a validação do trabalho dos agents. A palestra recomenda automatizar gradualmente etapas verificáveis, mantendo governança, segurança e supervisão humana. Para avaliar resultados, sugere medir impacto e eficiência — como tempo do sinal à produção e custo por PR — em vez de tokens ou linhas de código.

Pontos-chave

A evolução da engenharia de IA vai da conclusão automática de código à geração de arquivos e, depois, a agents capazes de reunir contexto, usar ferramentas e depurar resultados.
Uma fábrica de software conecta sinais como alertas e relatos de bugs a etapas de diagnóstico, planejamento, codificação, revisão, testes, implantação e monitoramento.
A adoção deve começar com tarefas estreitas e verificáveis, como triagem de incidentes, para que as equipes possam avaliar os resultados e desenvolver confiança.
Uma fábrica de software deve ser independente de modelo, compatível com diferentes modelos e custos, e oferecer opções de implantação adequadas às políticas de segurança da organização.
Contexto, documentação, testes e processos precisam estar integrados entre as equipes e ao longo do ciclo de desenvolvimento de software.
A preparação para agents inclui validação, sistemas de build, ciclos de feedback, documentação, ambientes reproduzíveis, modularidade, observabilidade e segurança.
Ações dos agents devem ser auditáveis e sujeitas a controles de acesso, privilégios mínimos e supervisão humana.
Engenheiros continuam essenciais para arquitetura, estratégia, priorização e validação; a execução precisa não garante que o projeto esteja bem concebido.
Métricas como tempo do sinal à produção, intervenções humanas, tempo médio de reparo, vida útil do código e custo por PR são mais úteis do que tokens ou linhas de código.

Capítulos

Início	Capítulo	Resumo
00:01	Da conclusão automática à fábrica de software	Davis Palmie apresenta sua trajetória e descreve a evolução da engenharia de IA até sistemas que organizam agents para produzir código.
03:18	Desafios de custo, modelos e organização	A palestra aborda custos, escolha de modelos, mudanças no papel dos engenheiros e a necessidade de compartilhar contexto entre equipes.
06:30	Automatizar gradualmente o ciclo de desenvolvimento	A fábrica de software assume tarefas desde a triagem e o planejamento até testes e monitoramento, começando por etapas estreitas e verificáveis.
10:22	Padrões de automação e escala nas empresas	Palmie apresenta usos comuns de agents e explica como padronizar governança e contexto pode reduzir a carga de coordenação entre equipes.
13:12	Preparação, governança e supervisão humana	A palestra detalha pilares de agent readiness e defende auditoria, implantação incremental e supervisão humana em decisões de arquitetura e estratégia.
15:58	Métricas de resultado para agents	O encerramento recomenda medir resultados concretos, como tempo do sinal à produção e custo por PR, em vez de tokens ou volume de código.

Citações

Cada avanço na escada de abstração tornou os engenheiros mais valiosos, não menos. — 01:37

Cada etapa da fábrica de software precisa de responsabilidade e monitoramento cuidadosos antes mesmo de pensar em deixar o pipeline operar em ciclo. — 07:40

Execução precisa não impede um projeto ruim. Nunca impediu. — 15:24

Você quer medir resultados, não tokens. — 16:30

Não os deixe soltos no seu código. E não maximize tokens. Meça o que realmente importa. — 17:35

Conceitos e entidades

software factory (conceito): Sistema coordenado de agents que transforma sinais de entrada em código implantado e monitorado.
Agent readiness (conceito): Avaliação da preparação de ferramentas, processos, documentação e infraestrutura para que agents e engenheiros trabalhem com segurança.
Software Development Life Cycle (SDLC) (conceito): Ciclo de atividades de desenvolvimento de software, desde o planejamento e a implementação até testes e implantação.
DORA metrics (conceito): Métricas de desempenho de entrega de software, incluindo o tempo entre escrever código e colocá-lo em produção.
GPT-5.2 (modelo): Modelo citado como exemplo de desempenho em revisão de código comparável ao de modelos Opus mais recentes, a um custo menor.
Opus (modelo): Família de modelos mencionada na comparação de desempenho e custo para revisão de código.
Sentry (ferramenta): Ferramenta cujos alertas de incidentes são citados como possível sinal de entrada para um agent.
Slack (ferramenta): Plataforma mencionada como canal para agents compartilharem diagnósticos de incidentes.
Factory (empresa): Empresa em que Davis Palmie trabalha e cujas capacidades de fábrica de software são apresentadas na palestra.
Davis Palmie (pessoa): Membro da equipe técnica da Factory e palestrante sobre fábricas de software.

Tradução completa (pt-BR)

00:01 [música] Olá, pessoal. Sou Davis Palmie, membro da equipe técnica da Factory. Antes disso, cofundiei a Lummetric, uma plataforma de agents para equipes de investimento que passou pelo Y Combinator e foi adquirida pela Factory. Antes disso, fui líder de engenharia no laboratório de inovação da Slalom. Então, já vi implantações de IA

00:35 tanto em grandes empresas quanto em organizações mais nativas em IA. Com isso em mente, hoje vou falar sobre a fábrica de software e sobre como avançar em direção a um sistema autônomo que transforma sinais de entrada em código de produção. Primeiro, passamos por três eras distintas da engenharia de IA. No início, tínhamos o autocompletar de tabulação, a previsão do próximo token,

01:06 e o engenheiro ainda estava firmemente no comando. Depois, a IA passou a gerar arquivos inteiros, e o engenheiro de software se tornou um avaliador criterioso que copiava e colava. Mas ainda mantinha bastante controle sobre o resultado da IA. Em seguida, vieram os agents mais estreitamente integrados ao código. Eles conseguiam reunir o próprio contexto, chamar ferramentas e depurar os próprios resultados. O autocompletar costumava parecer mágico, mas agora, na melhor das hipóteses, é

01:37 uma curiosidade de que nos lembramos. Vale observar a velocidade com que a engenharia de IA está subindo a escada de abstração: dos tokens aos arquivos, depois ao contexto e, agora, a sistemas inteiros. Cada mudança representa um ajuste. Mas cada avanço na escada de abstração tornou os engenheiros mais valiosos, não menos. E agora estamos em um ponto de transformação. Os engenheiros estão deixando de digitar código para supervisionar agents e, por fim,

02:13 organizar esses agents em um sistema. Essa é a sua fábrica de software. Com isso, o papel do engenheiro passa a ser manter as barreiras de proteção bem definidas, detectar desvios no código e estabelecer as prioridades e a direção de alto nível. Enquanto isso, o sistema ingere sinais de entrada, como relatórios de bugs ou feedback dos usuários, e produz código de produção. Mas, se os sistemas de IA estiverem produzindo mais código do que os humanos, há

02:48 algumas grandes questões que todos estão, com razão, fazendo. Primeiro: como posso evitar estouros enormes de custos? Todos vimos as manchetes sobre o CTO do Uber gastar todo o orçamento anual de IA até abril, ou sobre a Microsoft revogar licenças do Claude Code para tentar reduzir os gastos. Na Factory, você não fica preso a um único provedor de modelos. Isso significa que você tem acesso a todo o espectro de custo

03:18 e desempenho dos LLMs. Você quer a máxima eficiência de custos e o nível mínimo de eficácia necessário para cada tarefa. Como nosso CEO gosta de dizer: se seu filho precisa de um professor particular de álgebra, com certeza dá para encontrar alguém mais barato que Albert Einstein. Segundo: como posso garantir o melhor acesso ao modelo que estiver no topo naquele momento? Bem, achamos que ter de apostar no cavalo certo é uma falsa escolha,

03:52 especialmente com a eficácia crescente dos modelos open source. Defendemos fortemente a possibilidade de escolher a ferramenta certa para o trabalho certo ou até mesmo encaminhar as tarefas dinamicamente. Terceiro: o que acontecerá com os engenheiros de software? Como será o futuro da engenharia de software? Bem, o papel está obviamente evoluindo, e a linha entre produto e engenharia está ficando menos nítida. Agora, os engenheiros vão criar e manter

04:22 o sistema responsável por criar seu código de produção e definir a direção de alto nível da fábrica de software. E, por fim, como isso vai mudar a organização? Bem, os limites entre as equipes também estão começando a ficar menos nítidos, e o contexto precisa fluir sem interrupções entre esses limites. As informações não podem ficar isoladas. Isso já era verdade para os humanos, mas é especialmente verdade para os agents de IA. Todos, em todas

04:53 as suas equipes, terão uma responsabilidade compartilhada pelos pilares da fábrica de software. A parte de codificar era a fácil. Na verdade, nunca foi o gargalo. Seu contexto está descrito em linguagem natural. Aposto que, se você analisar suas métricas reais de engenharia — qual é o tempo mediano para revisar um PR? Quanto tempo leva para reproduzir relatórios de bugs dos usuários ou analisar e depurar o código? Quem mantém sua documentação atualizada a cada

05:25 PR e quem a mantém atualizada a cada reunião de estratégia? Quem mantém seus conjuntos de testes? Muitas vezes, as equipes de teste, engenharia e produto estão cada uma em seu próprio continente. Se você consultar sua métrica DORA, o tempo entre escrever o código e colocá-lo em produção, aposto que ele é muito maior do que o tempo realmente gasto fazendo essas alterações de engenharia. A verdadeira necessidade hoje é haver coesão em todas essas frentes. Neste momento,

05:55 a documentação fica desatualizada, o código morto permanece e há muitas camadas de comunicação entre as diferentes equipes. Mais uma vez, isso é difícil para engenheiros humanos, mas fica ainda mais evidente no caso dos agents. Para construir sua fábrica, é essencial garantir que os agents consigam conectar todos esses serviços e entender as nuances da sua organização. Isso nos leva à fábrica de software, o sistema de agents

06:30 que vai conduzir você do sinal de entrada à implantação em produção. Seus agents não estão mais apenas codificando. Eles estão assumindo funções de suporte ao cliente, engenharia de produto, operações de implantação e muitas outras. Em todos esses pilares, seus agents devem classificar incidentes, elaborar planos, criar e atualizar documentação, executar o código, revisá-lo, testá-lo, implementá-lo e, depois, monitorar essa versão. Isso obviamente dá muito trabalho, e

07:07 você não vai querer começar fazendo tudo isso de uma vez. Primeiro, é uma iniciativa pesada demais. Segundo, suas equipes não terão tempo para desenvolver confiança nesse sistema. O ideal é começar por algo restrito e verificável, como a triagem de incidentes. Deixe seu agent ler um alerta do Sentry, buscar os rastros e outros dados de contexto e, em seguida, publicar no Slack. Mas mantenha o processo de modo que seus engenheiros possam revisar isso e decidir o que fazer. À medida que chegam cada vez mais diagnósticos corretos do

07:40 agent, sua equipe pode começar a desenvolver confiança e entendimento desse pilar. Portanto, cada etapa da fábrica de software precisa de responsáveis e monitoramento cuidadosos antes mesmo de você pensar em permitir que o pipeline entre em ciclo. Mas, quando conseguir relacionar o resultado desse sistema ao sinal de entrada, será possível promover o autoaperfeiçoamento organizacional. Acreditamos firmemente que sua fábrica de software deve seguir alguns princípios fundamentais.

08:13 Primeiro, ela deve ser independente de modelo. É claro que modelos diferentes se destacam em tarefas diferentes e têm eficiências de custo muito distintas. Descobrimos, por exemplo, que é possível obter o mesmo desempenho em revisão de código com GPT 5.2 e com os modelos Opus mais recentes, mas pela metade do preço. E, se você considerar as alternativas open source, pode reduzir os custos para algo entre 10 e 30 vezes menos.

08:44 Assim, na Factory, você tem acesso a todo o equilíbrio entre velocidade, eficácia na tarefa e custo. Não ficar preso a um único laboratório dá acesso a toda a fronteira de Pareto dos LLMs. Segundo: seu modelo de implantação deve ser soberano. Você não deveria ter de comprometer sua arquitetura de segurança ou suas políticas para fazer seu modelo de implantação de IA se encaixar. Na Factory, você pode escolher seu

09:15 workspace e seu modelo de implantação. Oferecemos desde uma solução totalmente gerenciada até a opção de trazer sua própria máquina, passando por ambientes completamente isolados de redes externas. Terceiro: sua fábrica de software precisa estar integrada em todo o SDLC. Essas preocupações já não podem ficar separadas e desconectadas. Mudanças na documentação devem orientar o código, e vice-versa. As metas de planejamento devem orientar o que você testa, independentemente de quantas camadas de comunicação existam entre estratégia, produto,

09:47 engenharia e suas equipes de teste. Cada um desses pilares sustenta a fábrica de software. Uma fragilidade em qualquer um deles significa uma fragilidade no sistema inteiro. Então, na prática, em uma organização nativa em IA, como isso se parece? Bem, normalmente vemos a fusão e a automação incremental de várias subequipes sob o guarda-chuva de uma única fábrica de software. Alguns padrões bem comuns que observamos são

10:22 fazer a triagem de sinais recebidos, como alertas do Sentry, e fazer com que o agent elabore um diagnóstico antes mesmo de um humano conseguir responder ao alerta. Testar a segurança proativamente, procurando segredos ou vulnerabilidades. Criar e manter seus testes, monitorando aqueles que estão se tornando frágeis ou desnecessários. Mais uma vez, manter a documentação sincronizada com o código, manter a documentação sincronizada com os diferentes canais de reunião e, depois, as tarefas clássicas: revisar código, comentar em PRs,

10:56 acompanhar implantações, monitorar versões. Com o agent fazendo tudo isso, o papel do engenheiro humano passa a ser responder, exercer discernimento e corrigir a IA de modo que ela possa aprender com esses erros. Agora, tudo é interdependente entre as subequipes. Uma melhoria em um grupo significa uma melhoria no sistema inteiro. Então, por que sua empresa deveria se importar

11:26 uma fábrica de software? Bem, quanto maior e mais fragmentada for a organização, mais você sente o peso linear de gerenciar equipes. Em termos técnicos, sua fábrica de software deve reduzir esse peso de O de N para O de um, de forma conservadora. Você pode definir suas barreiras de proteção, seus agents, sua documentação, suas políticas de teste e, de fato, sua governança uma única vez e depois padronizá-las em toda a organização. E esse padrão deve garantir que

12:02 todos sejam elevados ao nível mais alto, e não ao mínimo denominador comum. Além disso, se os agents puderem atuar em todas essas superfícies, poderão manter esse padrão de qualidade entre as equipes sem que você precise aumentar linearmente o tempo dedicado a gerenciar cada uma. E, se os agents estiverem atuando em todos esses serviços, haverá um único lugar onde o contexto poderá ser unificado e onde você terá visibilidade executiva sobre o desempenho de todo o SDLC. Agora, assim como o agnosticismo em relação a modelos elimina

12:39 a dependência de um único fornecedor, seus agents também devem ser agnósticos em relação às superfícies. Eles precisam estar altamente disponíveis para suas equipes. Independentemente das ferramentas que usem, suas equipes não deveriam ter que abrir mão de seus processos ou ferramentas para tentar se adaptar ao seu provedor de IA. Na Factory, temos agents disponíveis em todos os lugares, de máquinas remotas à CLI e ao Slack, em qualquer ferramenta que suas equipes usem. E, embora humanos e agents possam usar serviços diferentes,

13:12 tudo deve compartilhar o mesmo harness e contexto subjacentes. Portanto, o trabalho de construir a fábrica vai revelar conhecimento tribal, processos manuais e informações desatualizadas. Desbloquear isso não vai ajudar apenas seus agents, mas também suas equipes de engenharia. Na Factory, temos o conceito de prontidão para agents, que avaliamos com base em oito pilares. O primeiro é validação. Vocês têm

13:45 barreiras de proteção, como linters e formatters, em vigor? Depois, o sistema de build. Os comandos de build e o CI estão bem documentados? Ciclos de feedback. Vocês têm testes unitários e de integração rigorosos e documentação, como arquivos README e agents.mmd? Seus ambientes de desenvolvimento podem ser reproduzidos de forma confiável, para que um agent possa usá-los? Seu código é modular, com limites claros e regras contra a expansão descontrolada? Vocês têm observabilidade? Quanto tempo leva

14:20 para descobrir por que algo deu errado? E vocês fazem varreduras de segurança proativas para não precisarem se preocupar com secrets expostos ou vulnerabilidades? Basicamente, a principal conclusão aqui é que, se seus agents e seus engenheiros humanos vão percorrer os mesmos caminhos, pavimentá-los bem é duplamente útil. Agora, não é possível governar aquilo que não se consegue enxergar. E isso vale para agents e engenheiros humanos. Você pode começar com esta

14:53 avaliação de prontidão para agents, mas, independentemente disso, seus engenheiros precisam monitorar o desempenho dos agents e controlar seu comportamento. Na Factory, cada ação pode ser auditada. Ela opera de acordo com seus padrões, com controle de acesso baseado em função e privilégio mínimo. Por exemplo, as equipes que estão construindo essa fábrica de software precisam primeiro desenvolver confiança e compreensão. É por isso que você deve implementá-la gradualmente.

15:24 Você deve automatizar primeiro cada um dos pilares, antes de transformar esse sistema em um ciclo. E, mais uma vez, uma execução precisa não impede um projeto ruim. Nunca impediu. Você ainda precisa muito de humanos no ciclo para a arquitetura, a estratégia e a definição de rumo. Os engenheiros não serão substituídos, mas agora o julgamento e a priorização valem mais do que a habilidade de implementação mecânica.

15:58 Os agents não conseguirão lidar com tudo. Haverá barreiras de proteção que precisarão ser reforçadas e código que se desviará do padrão. Os humanos precisam atuar como etapas de validação nessa fábrica. Mas, assim como não precisamos mais alimentar a máquina com cartões perfurados, o código não precisa ser escrito à mão. Sua equipe deve poder definir a estratégia e os parâmetros de risco e, então, deixar os agents executarem. E saber se seus agents estão executando bem depende de medir as

16:30 coisas certas. Basicamente, você quer medir resultados, não tokens. Linhas de código e tokens gerados são métricas que podem ser manipuladas. Na verdade, elas não estão associadas a resultados. Rankings de tokens em grandes empresas só incentivam gastos pródigos. É a lei de Goodhart em tempo real. Se você decidir medir o uso de tokens, os engenheiros vão otimizar o uso de tokens, e essa métrica deixará de ser boa. A questão não é quem gasta mais com

17:05 tokens. A questão é quem consegue obter os resultados de maior impacto com esse gasto. Algumas métricas de que gostamos na Factory são o tempo do sinal à produção, a quantidade de intervenções humanas, o tempo mediano para reparo, a vida útil do código e o custo por PR. Esses são resultados concretos e tangíveis. Portanto, a prontidão para agents é realmente um precursor da

17:35 engenharia eficaz. Seja um agent ou um humano quem acaba atuando nesse sistema, seus agents precisam estar sujeitos à mesma governança cuidadosa que seus engenheiros: ferramentas, níveis de acesso e sistemas de revisão. Não os deixe à solta no seu codebase. E não maximize o uso de tokens. Meça o que realmente importa. Seus usuários finais não se importam com quanto você está gastando com IA. Eles se importam em sentir as melhorias drásticas que

18:09 virão da sua fábrica de software. Obrigado. >> [música]

Transcrição original

[00:01] [music] Hey folks, I’m Davis Palmy, a member of technical staff here at factory. Uh before this I co-founded Lummetric which was an agent platform for investment teams that we took through Y Combinator and was acquired by factory and prior to that I was a engineering lead for Slalom’s innovation lab. So I’ve seen AI

[00:35] deployments both across large enterprises and more AI native orgs. With that in mind, today I’m going to be talking to you about the software factory and how you can move towards an autonomous system that translates input signals into production code. So, first we’ve moved through three distinct eras of AI engineering. First, we had tab autocomplete, next token

[01:06] prediction, and the engineer was still firmly in the driver’s seat. Then AI could generate entire files and the software engineer became a bit of a discerning copy pastaster. Um, but they still heavily had control over the output of the AI. And then you had agents that were more tightly coupled with the code. They could gather their own context, call tools, and debug their own output. Now, autocomplete used to feel magical, and now at best it’s it’s

[01:37] a quaint thing we remember. You want to look at the speed at which AI engineering is climbing the abstraction ladder from tokens to files to context now to entire systems. Every shift you have here is an adjustment. But each move up the abstraction ladder has made engineers more valuable, not less. And so now we’re at a transformational point. Engineers are going from typing code to governing agents and eventually

[02:13] you’ll organize those agents into a system. That’s your software factory. So with this the engineer’s role shifts to keeping guard rails tight, catching code drift and setting the highle priorities and direction. But meanwhile, the system is ingesting input signals like bug reports or user feedback and outputting production code. So if you have AI systems that are producing more code than humans, there

[02:48] are some big questions that everyone is rightly asking. First, how can I prevent massive cost overruns? We’ve all seen the headlines about Uber’s CTO blowing through the years, AI budget by April, or Microsoft clawing back clawed code licenses to try and cut down on spend. At Factory, you’re not locked into a single model provider. And this means you unlock the entire spectrum of cost

[03:18] performance with LLMs. You want the maximum uh cost efficiency and the minimum effectiveness necessary for each task. As our CEO likes to say, uh if your kid needs a algebra tutor, you can definitely find someone cheaper than Albert Einstein. Second point, how can I ensure the best access to whatever model is top right now? Well, we think that having to back the right horse is a false choice. Um,

[03:52] especially with the increasing effectiveness of open source models. We’re strong proponents of being able to choose the right tool for the right job or even now have it dynamically routed. Number three, what happens to software engineers? What does the future of software engineering look like? Well, the role is obviously evolving and the line between product and engineering is blurring. Engineers will now build and maintain

[04:22] the system that’s responsible for building your production code and they’ll set the highle direction for the software factory. And lastly, how is this going to change the organization? Well, team boundaries are also starting to blur and context needs to flow seamlessly across these boundaries. Information can’t be siloed. That was true for humans, but it’s especially true for AI agents. Everyone across all

[04:53] your teams will have a shared responsibility for the pillars of the software factory. Now, coding was the easy part. This actually was never the bottleneck. Your context is laid out in natural language. I bet if you look at your real engineering metrics, what’s the median time to review a PR? How long does it take you to reproduce user bug reports or go through and debug code? Who keeps your docs current with every

[05:25] PR and who keeps it current with every strategy meeting? Who maintains your test suites? oftentimes the testing teams and the engineering teams and the product teams are each on their own continent. If you pull your dora metric, the time from code written to time in production, I would bet dwarfs the time actually making those engineering changes. The real need you have today is cohesion across all of these surfaces. Right now,

[05:55] docs will go stale, dead code lingers, and there are so many layers of communications between your different teams. Again, this is hard for human engineers, but it is especially more pronounced for agents. The necessary undertaking to build your factory is to make sure the agents can bridge all of these services and understand the nuance within your organization. So this brings us to the software factory which is the system of agents

[06:30] that will take you from input signal to production deployment. Your agent’s not just coding anymore. It’s taking on customer support, product engineering, deployment ops, and many other roles. Across these pillars, your agent should be triaging incidents, making plans, creating and updating docs, actually executing the code, reviewing it, testing it, rolling it out, and then monitoring that release. Now, that’s obviously a ton of work, and

[07:07] you don’t want to jump into that all at once. For one, it’s too heavy of an undertaking, but for two, your teams will not have time to build trust in this system. You want to start with something narrow and verifiable like incident triage. Let your agent read a sentry alert, pull the traces in other context, and then post in Slack. But keep it so your engineers can review this and decide what to do. And as more correct diagnoses roll in and in from

[07:40] the agent, your team can start to build trust and an understanding of this pillar. So each step in the software factory needs careful ownership and monitoring before you even think about letting the the pipeline loop. But once you can tie the output of this system back to the input signal, that’s when you unlock organizational self-improvement. Now we feel pretty strongly that your software factory should have a few key

[08:13] principles. First, it should be model agnostic. Obviously, different models excel at different tasks and with very different cost efficiencies. We found, for instance, that you can achieve the same performance on code review with GPT 5.2 as with the latest Opus models, but at half the price. And now if you look at the open- source alternatives that can slash your cost down to 10 to 30x cheaper.

[08:44] So at factory again you have the entire interplay of speed to task efficacy to cost. Not being locked into a single lab means you unlock the entire PTO frontier of LLMs. Now number two your deployment model should be sovereign. You shouldn’t have to compromise on your security architecture or your policies to try and fit your AI deployment model in. Now at factory you can choose your

[09:15] workspace and your deployment model. We support everything from fully managed to bring your own machine to entirely airgapped. And number three, your software factory needs to be integrated across the SDLC. These are no longer separate uncoupled concerns. Docs changing should inform your code and vice versa. Planning goals should inform what you test for, not however many communication layers there are between strategy, product,

[09:47] engineering, and your testing teams. Each one of these pillars supports the software factory. And weakness in one means a weakness in the entire system. So tactically in an AI native or what does this look like? Well, we typically see it as the fusion and the incremental automation of many sub teams under the umbrella of one software factory. Some really common patterns we see are

[10:22] triaging incoming signals like sentry alerts, having the agent make diagnosis before the human can even answer the page. Proactively testing security, scanning for secrets or vulnerabilities. Creating, maintaining your tests, monitoring the ones that are becoming brittle or unneeded. Again, keeping docs in sync with code. keeping docs in sync with your different meeting channels and then the classic reviewing code, commenting on PRs,

[10:56] rollouts, monitoring releases and with the agent doing all of this, the human engineer’s role shifts to responding to exercising judgment and correcting the AI in such a way that it can learn from these mistakes. Now everything is transitive across sub teams. An improvement to one group means an improvement to the entire system. So why should your enterprise care about

[11:26] a software factory? Well, the larger and the more fragmented you are, the more you feel the linear pain of managing teams. In tech terms, your software factory should take this pain from O of N to O of one conservatively. You can define your guardrails, your agents, your docs, testing policies, really governance just one time and then standardize it across the organization. And this standard should make sure that

[12:02] everyone is pulled to the highest bar, not the lowest common denominator. Now also if agents can move across these surfaces then they can hold that quality bar across teams without you having to linearly scale your time to manage each one. And if agents are moving across all these services then you have one place where context can be unified and you can have executive visibility into how the entire SDLC is performing. Now, just like model agnosticism removes

[12:39] lock in, your agents should also be surface agnostic. They need to be highly available to your teams. Regardless of what tools they use, your teams should not have to compromise on their processes or their tooling to try and fit your AI provider in. At Factory, we have agents available everywhere from remote machines to the CLI to Slack, any tool your teams use. And even though humans and agents may use different services,

[13:12] everything should share the same underlying harness and context. So the undertaking of building the factory will expose tribal knowledge, manual processes, and outdated info. Unblocking these is not only going to help your agents, but it’s also going to help your engineering teams. At factory, we have the concept of agent readiness and we evaluate this based on eight pillars. The first is validation. Do you have

[13:45] guard rails like llinters and formatterers in place? Then your build system. Are your build commands and CI well documented? Feedback loops. You have unit and integration tests tight and you have docs like readmes, agents.mmd files. Are your dev environments cleanly reproducible such that an agent can use them? Is your code modular with clear boundaries and rules against sprawl? Do you have observability? How long does

[14:20] it take you to find out why something went wrong? and are you proactively security scanning so that you don’t have to worry about leaked secrets or vulnerabilities. Basically, the key takeaway here is that if your agents and your human engineers are going to walk the same roads, paving them well is doubly useful. Now, you can’t govern what you can’t see. And that’s true for agents and human engineers. You can start with this

[14:53] agent readiness assessment, but no matter what, your engineers must monitor agent performance and control behavior. At factory, every action is auditable. It operates under your standards with role-based access control and least privilege. For example, your teams that are building this software factory need to first build trust and understanding. That’s why you should roll this out incrementally.

[15:24] You want to automate the individual pillars first before you turn this system into a loop. And again, precise execution does not prevent poor design. It never has. You still heavily need humans in the loop for architecture, for strategy, and for setting direction. Engineers will not be replaced, but judgment and prioritization now beat mechanical implementation skill.

[15:58] Agents won’t be able to handle everything. There will be guardrails to tighten, code that drifts. Humans need to stand as validation gates in this factory. But just like we don’t have to feed punch cards into the machine anymore, code does not have to be written by hand. Your team should be able to set the strategy and their risk parameters and then let agents execute. And knowing if your agents are executing well comes down to measuring the right

[16:30] things. Basically, you want to measure outcomes, not tokens. Lines of code and tokens generated are gameable metrics. These are not actually associated with outcomes. Token leaderboards at big companies just encourage proflegate spending. It’s goodart’s law in real time. If you decide to measure token usage, engineers are going to optimize for token usage and then it’s no longer a good metric. It’s not about who spends the most on

[17:05] tokens. It’s about who can get the highest leverage outcomes from that spend. Some metrics that we like at Factory are signal to production time, human intervention count, median time to repair, shelf life of code, and cost per PR. These are real tangible outcomes. So agent readiness is really a precursor to

[17:35] effective engineering. Whether it’s an agent or a human that ends up in that system, your agents need the exact same careful governance as your engineers, tooling, access levels, systems for review. Don’t just turn them loose in your codebase. And don’t token max. Measure what actually matters. Your end users don’t care about how much you’re spending on AI. They care about feeling the dramatic improvements that

[18:09] will come from your software factory. Thank you. >> [music]