Meu sonho da dark factory de IA acabou (eis o que realmente funciona)

Autoria: Cole Medin · 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: My AI Dark Factory Dream Is Dead (Here’s What Actually Works) · Canal: Cole Medin · 19:07 · 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

Resumo

Cole Medin explica por que uma dark factory, que recebe uma descrição ampla e trabalha sem supervisão até entregar o software, não é confiável: modelos podem construir código, mas não conseguem inferir perfeitamente a intenção humana nem manter uma base de código como as pessoas. Como alternativa, ele apresenta uma software factory com supervisão humana, que recebe um escopo de trabalho delimitado, divide-o em tickets e processa cada um por meio de implementação, validação e revisão. O fluxo inclui cenários de teste ocultos, mapeamento de dependências, limites de tentativas e um agente gerente que monitora o andamento e alerta quando é necessária intervenção. Após a etapa automatizada, a equipe valida o lote de mudanças em staging, fornece feedback em novos tickets e só então leva o resultado à produção.

Pontos-chave

Uma descrição ampla não comunica toda a intenção humana; por isso, a dark factory pode tomar decisões de produto e implementação que não correspondem ao que as pessoas querem.
A software factory trabalha com releases delimitadas, em vez de tentar construir uma aplicação inteira a partir de uma instrução genérica.
O planejamento permanece nas mãos das pessoas; o documento da release é dividido em tickets, com dependências mapeadas para permitir execução na ordem certa ou em paralelo.
Cenários de teste ocultos ajudam a evitar que o agente adapte a implementação apenas para passar por testes conhecidos.
Implementação, validação do aplicativo e revisão do código são etapas distintas, com fluxos de trabalho ajustados à complexidade da tarefa.
Limites de tentativas e um agente gerente ajudam a evitar ciclos infinitos e a identificar tarefas travadas ou que precisam de intervenção.
As pessoas revisam o conjunto de funcionalidades em staging, registram problemas como novos issues e só promovem as mudanças à produção quando estiverem satisfeitas.
Modelos diferentes podem ser usados em etapas diferentes, reduzindo o consumo de tokens sem exigir o modelo mais capaz em todas as tarefas.

Capítulos

Início	Capítulo	Resumo
00:00	Por que a dark factory não funciona	Cole Medin apresenta a dark factory e explica por que a automação sem supervisão não consegue representar perfeitamente a intenção humana nem manter bem uma base de código.
05:11	A proposta da software factory	Ele diferencia a software factory da dark factory: o trabalho é dividido em releases delimitadas, com planejamento e decisões humanas sobre o escopo.
08:46	Planejamento, tickets e cenários de teste	A etapa de planejamento fica fora do fluxo automatizado, enquanto documentos da release são divididos em tickets com dependências e cenários de teste ocultos.
13:25	O ciclo de implementação e validação	Cada ticket passa por implementação, validação do aplicativo e revisão do código, com fluxos ajustados à complexidade e limites para novas tentativas.
15:31	Monitoramento, contexto e escolha de modelos	Um agente gerente monitora as execuções e pode alertar sobre problemas, enquanto regras protegidas e modelos variados ajudam a manter o processo confiável e eficiente.
17:33	Revisão em staging e entrega	A equipe testa as mudanças em staging, registra correções como novos issues e promove o resultado à produção quando ele corresponde à intenção.

Citações

Por mais poderosos que os LLMs fiquem, eles nunca vão conseguir simplesmente ler nossa mente. — 03:37

A issue é a entrada, e o pull request é a saída. — 06:42

O agente que implementa não sabe quais são os cenários de teste ocultos. — 10:50

A software factory, descobri, precisa dessa etapa de revisão humana. — 18:05

Conceitos e entidades

Dark Factory (conceito): Modelo de automação em que um agente recebe uma descrição ampla do produto e trabalha sem supervisão até concluir e entregar o software.
AI Software Factory (conceito): Fluxo de desenvolvimento que automatiza o trabalho em tickets delimitados, mantendo planejamento, revisão e validação humana.
human-in-the-loop (conceito): Abordagem que inclui pessoas em etapas importantes do fluxo para orientar o trabalho e verificar se o resultado corresponde à intenção.
Holdout scenarios (conceito): Cenários de teste mantidos ocultos do agente de implementação para reduzir a adaptação excessiva a testes conhecidos.
Jev (ferramenta): Ferramenta usada no fluxo para ajudar a decidir se um ticket exige um processo de implementação simples ou mais elaborado.
Port (empresa): Plataforma apresentada no vídeo para ajudar equipes a gerenciar uma software factory, com catálogo de contexto e servidor MCP.
Claude Code (ferramenta): Ferramenta de coding agent mencionada como agente principal e como exemplo de conexão com o MCP server da Port.
Opus 5.5 (modelo): Modelo citado como opção para tarefas de planejamento que exigem mais capacidade de raciocínio.
GPT-6 Astra (modelo): Modelo citado como opção para tarefas de planejamento na software factory.
Sonnet 5.5 (modelo): Modelo citado como opção para tarefas mais simples em etapas individuais do fluxo.

Tradução completa (pt-BR)

00:00 A fábrica sombria de IA é a forma mais autônoma de engenharia agêntica. Damos a ela algum tipo de documento de alto nível para um épico ou lançamento, e ela descobre como criar e validar tudo e lançar diretamente em produção. Se isso pudesse ser confiável, seria o sonho para criar qualquer software. Mas, para ser um pouco dramático, minhas esperanças e sonhos foram esmagados aqui. Enquanto experimentava construir minha própria fábrica sombria, cheguei à conclusão de que essa simplesmente não é a maneira de fazer as coisas. Mas o que realmente está funcionando para mim, no que transformei isso, não precisa ser tão diferente. Eu não estou, de fato,

00:30 perdendo tanta autonomia assim. E é isso que quero abordar com vocês agora. E preciso dizer: foi uma jornada fascinante chegar aonde estou agora. Há tantas lições que quero compartilhar neste vídeo sobre por que a fábrica sombria não funciona e por que o que estou construindo agora funciona. E, no caso da fábrica sombria, mesmo que tivéssemos AGI e os melhores LLMs do mundo, isso ainda não funcionaria. Precisamos de um sistema que se pareça mais com isto. E sim, eu sei, parece complicado, mas vou explicar tudo de um jeito bem simples agora. E é importante

01:00 entender esse tipo de workflow porque, vamos encarar, a maneira como trabalhamos com agentes de programação não vai ser a mesma nem daqui a seis meses. À medida que os harnesses e os LLMs melhoram cada vez mais, precisamos dar a eles mais autonomia se quisermos lançar mais rápido. Por isso, acredito de verdade que, nos próximos dois anos, todas as pessoas e empresas vão avançar em direção a um sistema como este. E mesmo que você não queira construir agora uma fábrica completa de software com IA — que, sim, é diferente de uma fábrica sombria —, ainda assim é bom ver como é o processo completo. Há muitas lições que incluí aqui e que você pode até

01:32 incorporar aos seus workflows atuais de programação agêntica. Mas, de modo geral, é assim que vejo o setor convergindo. Enquanto trabalho com empresas e construo esse tipo de coisa, e converso com pessoas que estão criando as próprias soluções, vejo todos construindo sistemas que ficam cada vez mais parecidos com o tempo. Então, este realmente é o futuro. Este é o próximo passo da engenharia agêntica. Certo, antes de entrar em qualquer outra coisa, preciso explicar por que a fábrica sombria não funciona tanto quanto eu gostaria. E o objetivo número um aqui é simples e direto. Só queremos tornar nossos agentes de programação o mais autônomos possível. Agora,

02:03 isso não é vibe coding, porque estamos investindo muito esforço de engenharia no nosso harness desde o início. Então, sim, confiamos no agent em tempo de execução, quando ele está construindo o software, mas só porque investimos muito do nosso esforço de engenharia para prepará-lo para ter sucesso. Assim, definimos o processo exato pelo qual ele passa enquanto constrói tudo. Quanto à minha própria fábrica sombria, comecei como um experimento público mais para o começo do ano. Assistir à fábrica funcionando é muito entediante, porque ficamos apenas esperando os agents avançarem pelo trabalho. Mas, como eu disse, investimos muito desse esforço de engenharia

02:34 no harness desde o início. Foi isso que mostrei nos vídeos do YouTube e nas transmissões ao vivo que fiz. Foi muito divertido, e construí uma fábrica sombria bastante bem-sucedida. Falei bastante sobre isso na época, mas minha principal inspiração para construir a fábrica sombria foi a publicação no blog de Dan Shapiro. Ele aborda aqui os cinco níveis diferentes de autonomia na programação com IA. A maioria de nós vive o dia a dia no nível três, talvez no nível quatro, mas o nível cinco, com a fábrica sombria de software, é a forma máxima de autonomia. Ele usa a analogia de dirigir um veículo: na fábrica sombria, não há nem volante. Você informa o

03:05 destino final, ou o que quer construir, mas não dá nenhuma orientação sobre como chegar lá. E isso parece um sonho. Ei, Claude, ei, Codex, aqui está um aplicativo enorme que quero construir. Vá em frente e crie. Não pare até terminar. Não cometa erros. Quer dizer, é mais ou menos isso que parece. E, em teoria, parece que eventualmente seria viável, porque, à medida que os LLMs melhoram cada vez mais, alcançaríamos esse nível de autonomia. Isso se tornaria realmente viável. Mas há um grande problema nisso. E esse grande problema tem a ver exatamente com o que abordei no meu último vídeo. À medida que os LLMs melhoram cada vez mais, eles ficam

03:37 melhores em construir software, mas não ficam muito melhores em nos entender e entender nossas intenções. O gargalo passa a ser conseguir o que você realmente quer, porque nós, humanos, nunca vamos conseguir comunicar perfeitamente os recursos que queremos construir, como queremos manter nossa base de código e coisas desse tipo. Então, sei que parece meio cafona, mas a fábrica sombria é fundamentalmente falha porque, por mais poderosos que os LLMs se tornem, eles nunca vão conseguir simplesmente ler nossa mente. Também já ouvi o argumento — e acho isso fascinante — de que os LLMs vão ficar tão bons que suas ideias e intenções vão se tornar

04:08 melhores que as nossas e, por isso, vamos entregar completamente a eles o desenvolvimento de software. Mas não acredito nisso. Acho que sempre precisaremos estar no banco do motorista porque, por melhores que sejam os LLMs, nós sempre vamos entender o que as outras pessoas querem. Vamos sempre conhecer melhor os problemas que estamos resolvendo e nossos clientes. E, para realmente continuarmos no banco do motorista, também precisamos garantir que participemos da manutenção da base de código. Não podemos nos excluir completamente do código, porque os agentes de programação também têm um jeito estranho de manter uma base de código. Eles espalham código por todo lado, e esse é, na verdade, o principal argumento de Dex

04:39 Horthy. Há alguns meses, ele fez uma palestra muito popular sobre por que as fábricas de software fracassam, e o principal argumento dele é a facilidade de manutenção da base de código. Os agents simplesmente não conseguem mantê-la como os humanos, então ainda precisamos fazer parte desse processo. Na verdade, Dex fez o mesmo que eu: começou com a fábrica sombria e precisou recuar um pouco, acrescentando mais participação humana no processo para torná-la realmente viável. Quando ele diz que as fábricas de software fracassam, acho que isso está mais de acordo com a minha definição de fábrica sombria, certo? Tipo, este é o sistema que não funciona. E então, reuni todas as lições que expliquei aqui. Isso é um precursor importante e leva ao

05:11 sistema que tenho agora, que está funcionando muito bem para mim. E então, pensando em como manter a participação humana no processo sem deixar de tornar o processo o mais autônomo possível. Como fazer com que continuemos ajudando a manter a base de código? Como manter os agents no rumo enquanto eles passam por todos esses tickets? Tudo isso já está incorporado. Então, há uma grande diferença entre a fábrica de software e a fábrica sombria, e não quero me prender demais a definições em geral, mas acho que há uma distinção realmente importante aqui. Vou explicar isso com uma versão mais simplificada

05:41 da minha fábrica de software; depois, vou detalhar melhor como cada etapa funciona para que você veja de verdade como a confiabilidade e a participação humana no processo estão incorporadas. A grande diferença entre a fábrica de software com IA e a fábrica sombria, além da óbvia participação humana no processo, sobre a qual falaremos no final, é o escopo do trabalho que você incorpora ao sistema e o quanto planeja isso com o agent. Na fábrica sombria, ficamos o mais distantes possível do processo. Criamos apenas algum tipo de documento de alto nível para o aplicativo enorme que queremos criar e esperamos que a fábrica divida isso em issues e

06:11 lidar com todos eles um de cada vez ou com alguns em paralelo. A questão é que tudo acontece sem intervenção assim que damos essa descrição mais ampla do que queremos criar. E ainda estamos deixando o agent preencher algumas lacunas da nossa intenção, certo? Esse é o grande problema de que eu estava falando: não queremos que o agent presuma qual é a nossa intenção, mesmo que seja um modelo muito capaz. Então, o que fazemos com a fábrica de software é fornecer releases individuais ao sistema. Ainda fazemos com que ele percorra sozinho uma tonelada de issues, mas, em vez de simplesmente dizer: “Construa tudo, pode começar”,

06:42 a ideia é realmente descobrir: “Qual é o próximo escopo de trabalho?”. Vamos definir os tickets e como queremos dividir o trabalho. Depois, deixamos a fábrica cuidar disso de forma autônoma. Então, o ciclo principal da fábrica continua o mesmo: como lido com cada issue individual do GitHub, ticket do Jira ou qualquer outra coisa. Tenho uma maneira muito parecida de construir e validar, e a issue sempre será a entrada, e o pull request, a saída. Isso continua igual. O que torna a fábrica muito mais confiável e mantém o humano no loop é, na verdade, boa parte do que faço antes e depois. Então, com isso, deixa eu

07:13 passar pelas três partes principais da fábrica. Vou manter a explicação em um nível bem geral, porque passei centenas de horas construindo e testando esse sistema. Obviamente, poderia entrar em muitos detalhes, mas quero apenas dar uma ideia geral do processo, falar sobre o que realmente está funcionando no setor como um todo e, depois, me contem nos comentários se quiserem que eu aborde algo específico em um vídeo dedicado. Agradeço muito à Port por patrocinar o vídeo de hoje. É a plataforma que ajuda equipes a operar sua própria fábrica de software com IA. Porque o seguinte: tudo o que estou mostrando no vídeo de hoje funciona para

07:44 equipes de engenharia reais. Eu mesmo construí isso. Mas, quando você começa a implementar fábricas em organizações com centenas de serviços, várias equipes e todas essas pessoas e agents abrindo pull requests, precisa de algo para ajudar a gerenciar tudo isso. Essencialmente, uma fábrica de software gerenciada. Seus agents precisam saber quem é responsável por cada coisa e quais padrões se aplicam. E você precisa conseguir ver o que seus agents estão entregando à medida que fazem isso. É aí que entra a Port. Ela mapeia todo o seu ambiente no que chama de lago de contexto. Ali, seus serviços, responsáveis, documentos e padrões

08:15 ficam todos reunidos em um catálogo. Você também pode conectar seus agents ao servidor MCP da Port. Como aqui, no Cloud Code, fiz isso com um único comando. Agora, meu agent pode consultar todas as minhas fábricas, obter informações como quem é responsável por cada coisa e acessar outros dados contextuais sobre a fábrica, como seu nível de prontidão e quais verificações estão falhando. Porque sempre teremos um padrão para testar nossas fábricas. E, como cada pull request entra no catálogo da Port, posso perguntar ao meu agent sobre vários aspectos das minhas fábricas, como quantos pull requests cada uma está integrando por mês e quanto tempo meus ciclos estão levando, em média.

08:46 Essas informações são muito valiosas se você quiser melhorar suas fábricas ao longo do tempo. E, claro, posso definir permissões para meu agent; este aqui, por exemplo, tem apenas acesso de leitura. A Port é gratuita para até 15 usuários, não exige cartão de crédito e você pode experimentar sem pagar nos seus próprios repos. Vou deixar um link para ela na descrição. Antes de entrarmos no ciclo principal da fábrica, há duas etapas. Precisamos planejar o conjunto maior de trabalho que queremos realizar no próximo release e, depois, dividi-lo em tickets, para termos partes menores que possam passar, cada uma, pelo ciclo completo que vou explicar daqui a pouco. Agora,

09:18 a primeira etapa, o planejamento, deixei intencionalmente fora da fábrica. Nada no harness vai orientar você nesse processo, porque parto do princípio de que você já tem sua própria maneira de planejar com seu agent. Eu tenho a minha, você provavelmente tem a sua, e todas as empresas com que trabalho também têm. Não quero impor isso à fábrica. E quero participar plenamente do planejamento. Então, você cria seu PRD, seu documento de arquitetura ou o que costuma fazer normalmente, e isso passa a ser a entrada da fábrica. Assim, planejamos nosso próximo release. O que diferencia a fábrica de software da fábrica obscura

09:49 é que não vamos simplesmente tentar construir o aplicativo inteiro. Para projetos greenfield, a fábrica deve construir apenas uma prova de conceito para o primeiro release. Já para projetos brownfield — porque sim, a fábrica também funciona muito bem sobre bases de código existentes —, basta definir um epic pequeno. Sei que “pequeno” é algo bastante subjetivo quando se trata de um epic. Cada organização define o escopo do trabalho de um epic ou release de um jeito diferente. Depende mesmo de você. Minha regra geral é que quero

10:19 criar um documento de epic que será dividido em algo entre 10 e 20 tickets. Sei que é uma faixa ampla. Cada ticket terá um tamanho bem diferente, mas essa é a melhor estimativa que posso dar. Se você construir sua fábrica e usar esse sistema, com o tempo vai desenvolver essa intuição sobre o tamanho de epic que funciona bem para você. Mas o importante no epic é descrever tanto o que estamos construindo quanto o que, especificamente, não estamos construindo. Definir o que está fora do escopo também é muito útil para continuar orientando a fábrica enquanto ela processa os diferentes

10:50 tickets. E a outra coisa que definimos de antemão, mais específica da fábrica, mas também muito útil para qualquer workflow de programação com agents, são os cenários de teste reservados. Basicamente, um cenário de teste reservado é um teste que vamos executar ao final da implementação. Mas o agent responsável pela implementação, o construtor, não sabe quais são esses cenários, certo? Estamos ocultando essa informação. Assim, evitamos qualquer viés. O agent não pode ajustar demais a implementação para fazer nossos cenários de teste passarem. Isso foi algo que

11:21 aumentou a confiabilidade da minha fábrica de software, porque agents são bajuladores. Se souberem quais cenários de teste você vai usar, tentarão projetar a implementação apenas para fazê-los passar. Muitas vezes, o software não é realmente bem construído; ele é apenas bem construído para aqueles testes. Por isso, não queremos que o construtor saiba quais são eles. Então, definimos tudo isso em um documento. Você cria seu PRD, documento de arquitetura ou o que costuma usar, e a fábrica vai usá-lo para ajudar a dividir o trabalho em tickets. Como parte desse processo, ela também vai ajudar a mapear as dependências. Assim,

11:52 vamos descobrir o que pode ser concluído em paralelo e quais dependências existem, para podermos definir uma ordem específica para os ciclos que vamos executar. O importante é que a fábrica vai aplicar labels do GitHub para configurar todas essas dependências e preparar o ciclo principal para dar certo, fazendo as coisas e testando-as na ordem correta. Não precisamos necessariamente manter um humano no loop aqui. Boa parte do que estou incorporando à minha fábrica de software são opções para manter o humano no loop. Por exemplo, podemos decidir se revisamos os PRs antes de integrá-los à staging ou não, e se revisamos a divisão do trabalho antes de

12:24 começar a construir ou não. E, então, cada organização, cada pessoa tem necessidades diferentes, certo? E isso também depende da complexidade do que estamos construindo nesta versão específica. Então, pode haver versões em que estamos lidando com conformidade e regulamentação e realmente precisamos garantir que tudo esteja sólido. Nesse caso, queremos revisar a divisão, queremos revisar os PRs no final, mas ainda queremos que o sistema processe as issues assim que as criarmos. E há outras versões em que talvez estejamos apenas lidando com um grande backlog de bugs. Nesse caso, talvez queiramos simplesmente confiar totalmente nele para dividir o trabalho em tickets e mesclar as coisas direto no nosso

12:54 ambiente de homologação, certo? Tipo, há uma necessidade dinâmica que temos: nem sempre a intervenção humana precisa acontecer neste ponto ou naquele ponto. Por isso, criei a fábrica para ser bastante adaptável. Acredite, eu gostaria muito de poder mostrar em detalhes como essa fábrica funciona, incluindo as execuções, os planos, as divisões e como ficam as listas de issues, mas tentei gravar uma versão deste vídeo mostrando tudo isso e ela ficou longa demais. Então, por enquanto, preciso manter a explicação em alto nível, mas com certeza vou falar mais sobre isso em vídeos futuros. O ponto é que, depois do planejamento e da divisão, temos uma lista de

13:25 issues do GitHub e vamos passar por elas rapidamente com o loop principal da fábrica, que faz todo o planejamento e a validação. Aproximando, começamos com a issue do GitHub. Podemos executar muitos desses ciclos em paralelo porque fizemos o mapeamento das dependências e sabemos quais tarefas podemos concluir ao mesmo tempo. Então, a cada ciclo, o sistema escolhe uma única issue do GitHub para trabalhar. Ele aplica um rótulo de atribuição para que outros ciclos paralelos não a selecionem e, em seguida, tomamos uma decisão logo no início, porque notei algo com a primeira versão até mesmo da minha fábrica escura: quando eu usava o workflow mais

13:56 abrangente para lidar com cada implementação, havia tickets básicos que levavam uns 30 ou 20 minutos para implementar e não precisavam daquele processo. Então, tomo a decisão logo no início usando o Jev: é algo simples, para o qual basta usar um workflow de build mais rápido, ou é mais complexo e queremos incluir etapas de iteração e coisas assim? O sistema toma essa decisão, mas, de qualquer forma, quando termina de construir, passa pela validação e pela revisão de código, que também levam em conta, com base na complexidade da implementação, quanto tempo precisamos dedicar a isso. E

14:26 há revisão e validação porque são coisas diferentes. Validação significa que, como parte do harness, forneço as ferramentas para que o sistema teste a aplicação como um usuário faria. Isso substitui boa parte dos meus testes manuais, porque queremos que o sistema seja mais autônomo. Esse é o objetivo de uma fábrica de software. Então, ele clica em botões, digita texto no campo de chat ou faz o que for necessário na aplicação. Depois, fazemos a revisão de código, que consiste mais em analisar o seguinte: como sabemos que o aplicativo está funcionando, agora vamos garantir que o código seja simples e fácil de manter e que a implementação esteja correta, certo? Esse tipo de decisão mais ligada à engenharia de software, a revisão de código mais tradicional.

14:58 E, para qualquer coisa que o sistema considere incorreta em uma dessas etapas, ele a envia de volta ao workflow de implementação para corrigir, certo? Então, mesmo no caso de uma implementação complexa, ele simplesmente passa pelo workflow simples para resolver qualquer feedback. E, claro, há um número máximo de tentativas, para não ficarmos presos em um loop infinito com a fábrica. Então, quando terminamos a revisão e as possíveis iterações, permitimos que o pull request seja mesclado na branch que segue para o nosso ambiente de homologação, mas somente se o CI estiver verde e o código revisado estiver bom.

15:31 E, para todo esse processo, tenho um agent gerente que é executado periodicamente, a cada duas ou três horas, e monitora o sucesso de todos os ciclos em conjunto. Na verdade, essa é a coisa mais recente que acrescentei à fábrica. Antes disso, esses agents não se comunicavam de verdade, certo? Cada ciclo individual não entendia se as dependências estavam mudando ou se algum pull request estava emperrado. Se chegarmos ao número máximo de tentativas e um agent realmente ficar preso em um problema, precisamos de algo que acompanhe o

16:01 processo inteiro e consiga reorganizar as issues ou, de certa forma, assumir um workflow e concluí-lo, se necessário. Isso também aumentou bastante a confiabilidade, porque configurei o sistema para me alertar quando realmente precisar que eu intervenha. Por mais que queiramos que tudo seja autônomo, já não é uma fábrica escura. Não nos importamos de ter que entrar no sistema de vez em quando para revisar a divisão ou, sabe, resgatar um workflow. Isso acontece de vez em quando. Então, geralmente, peço ajuda ao meu agent principal do Claude Code, como se fosse meu segundo cérebro,

16:32 quando o gerente me alerta sobre esses problemas. E, claro, também entram em cena os cenários de controle, porque os usamos para validar o aplicativo. Como parte da fábrica, tenho meu contexto central. Chamo esses arquivos de mission.md ou engineering.md. Eles definem o que está fora do escopo e que nunca quero construir, além de dar orientações gerais sobre como quero que o agent trabalhe no meu codebase. Isso, junto com as regras globais. E garanto que esses arquivos nunca sejam editados. Isso faz parte da minha revisão: garantir que nunca os alteremos, porque não quero que a fábrica possa mudar as próprias permissões e o próprio comportamento. E o

17:03 último ponto é que, em cada um desses nós, uso modelos e até provedores diferentes, porque deixei essa fábrica muito eficiente no uso de tokens. Nem sempre precisamos do máximo de raciocínio possível. Então, em boa parte do planejamento que faço, como aqui, uso Opus 5.5 ou GPT-6 Astra. Mas, em muitos desses nós individuais, uso o Jev para escolher a tarefa e, para as tarefas simples, talvez use apenas Sonnet 5.5. Quer dizer, até para executar esses diferentes nós, não preciso usar o melhor modelo. E fiz muitas

17:33 dessas experimentações para otimizar o uso de tokens. Executo centenas e centenas de ciclos toda semana sem atingir meus limites de uso. Certo, e agora a última parte do processo: é aqui que voltamos para revisar as coisas. Então, reunimos todas as issues do épico no nosso loop principal. Mesclamos as mudanças no ambiente de homologação. É aqui que podemos validar as coisas por conta própria, porque precisamos dessa etapa para verificar se o resultado corresponde à nossa intenção. Então, testamos tudo nós mesmos e, se algo estiver fora do esperado — por exemplo, se algo não tiver sido construído como queríamos —, basta criar uma nova issue no repositório, e a fábrica

18:05 vai identificá-la automaticamente, assim como fez com a divisão inicial do nosso documento do épico. Então, é muito fácil testar o conjunto de funcionalidades do épico e dar feedback sobre elas de uma só vez. Podemos criar quatro ou cinco issues, por exemplo, e o sistema vai processar todas rapidamente; depois, podemos testar o ambiente de homologação de novo. Quando tudo estiver certo, seguimos para produção. Então, a fábrica escura basicamente vai direto para produção, mas descobri que isso é muito importante na fábrica de software. Assim, temos uma verdadeira intervenção humana no processo, mas, ao mesmo tempo, podemos revisar muitas coisas de uma só vez. E assim resolvemos esse gargalo, pelo menos

18:36 em parte para a revisão humana no final. E então, quando estivermos satisfeitos com o que está em produção, podemos simplesmente seguir para a próxima versão e repetir esse processo, passando pelo planejamento, pelo loop principal e pelos ambientes de staging e produção. E é isso. Essa é a fábrica de software com IA em alto nível. E, claro, como já disse, me avisem se quiserem que eu aborde qualquer parte disso com mais detalhes, mas espero que tenham achado estas ideias inspiradoras para seus próprios fluxos de trabalho de programação com IA ou, se quiserem construir uma fábrica de software por conta própria, isso realmente é o futuro da engenharia agêntica. E, se vocês gostaram deste vídeo e estão esperando mais conteúdo sobre uma fábrica de software com IA e programação com IA em geral, eu realmente agradeceria se deixassem um like e se inscrevessem. E, com isso, vejo vocês no próximo vídeo. E, se vocês gostaram deste vídeo e estão esperando mais conteúdo sobre IA

19:07 em geral, eu realmente agradeceria se deixassem um like e se inscrevessem. E, com isso, vejo vocês no próximo vídeo.

Transcrição original

[00:00] The AI dark factory is the most autonomous form of agentic engineering. We give it some kind of higher-level document for an epic or release, and it figures out how to build and validate everything and ship it straight to production. If this could be reliable, it would be the dream for building any software. But, to be a bit dramatic for effect, my hopes and dreams have been crushed here. As I’ve been experimenting building my own dark factory, I’ve come to the conclusion this is just simply not the way to do things. But, what is actually working for me, what I’ve

[00:30] turned this into, doesn’t have to be that much different. I’m not actually losing that much autonomy. And so, that’s what I want to cover with you right now. And let me tell you, it has been a fascinating journey to get to where I am now. There’s so many lessons I want to share with you in this video for why the dark factory doesn’t work and why what I’m building now actually does. And so, for the dark factory, even if we had AGI and the best LLMs in the world, this still wouldn’t work. We need a system that looks more like this. And yeah, I know, it looks complicated, but I’ll break it down nice and simple for you right now. And it’s important to

[01:00] understand this kind of workflow because, let’s face it, the way we work with coding agents, even in the next 6 months, isn’t going to look the same. Because as harnesses and LLMs get better and better, we need to give them more autonomy if we want to ship faster. And so, I truly believe in the next couple of years every person and company is going to be moving towards a system that looks like this. And even if you don’t want to go and build a full AI software factory right now, which yes, that is different than a dark factory, it’s still good to see what the full process looks like. There’s a lot of lessons I have built in here that you can even

[01:32] just incorporate for your current agentic coding workflows. But overall, this is how I’m seeing the industry converge. As I work with companies and build this sort of thing, talk to people that are creating their own, everyone is building a system that is becoming more and more similar over time. So, this really is the future. This is the next step for agentic engineering. Okay, so before I get into anything else, I need to cover why the dark factory doesn’t work as much as I wish it did. And so, the number one goal here is plain and simple. We just want to make our coding agents as autonomous as possible. Now,

[02:03] it’s not vibe coding because we’re putting a lot of effort up front engineering our harness. And so, yeah, we’re trusting the agent at runtime when it’s building the software, but it’s only because we put a lot of our engineering effort into setting it up for success. And so, we define the exact process it goes through as it builds everything. Now, for my own dark factory, I started it as a public experiment more towards the start of the year. Now, watching the factory itself run is very boring cuz we’re just waiting for agents to churn through work. But like I said, we’re putting a lot of that engineering effort

[02:34] into the harness up front. So, that is what I showed with YouTube videos and live streams that I did. It was a blast and I built a pretty successful dark factory. I covered this a lot back then, but my main inspiration for building the dark factory was Dan Shapiro’s blog post. He’s covering the five different levels of autonomy for AI coding here. Most of us, we live our day-to-day like level three, maybe level four, but level five with the dark software factory is the ultimate form of autonomy. And so, he uses the analogy of driving a vehicle where with the dark factory, there’s not even a steering wheel. You supply the

[03:05] final destination or like what you want to build, but nothing with the directions for how to actually get there. And that sounds like the dream. Hey Claude, hey Codex, here’s a massive app I want to build. Go and create it. Don’t stop until you’re done. Make no mistakes. I mean, that’s kind of what it sounds like. And in theory, it seems like it would be practical eventually because as LLMs get better and better and better, we would reach this level of autonomy. Like it would actually become practical. But there’s a big problem with this. And this big problem relates to exactly what I was covering in my last video. As LLMs get better and better, they become

[03:37] better at building software, but not that much better at understanding us and our intent. The bottleneck becomes getting what you actually want because as humans, we’re never going to perfectly communicate the features we want to build, how we want to maintain our codebase, those kinds of things. And so, I know it sounds kind of cheesy, but the dark factory is fundamentally flawed because as powerful as LLMs get, they’re never going to be able to just read our minds. Now, I’ve also heard the argument, and I do find this fascinating. People say that LLMs are going to get so good that their ideas and their intent is going to become

[04:08] better than our own, and so we will fully hand over the development of software. But, I just don’t buy into that. I think we will always need to be in the driver’s seat because no matter how good LLMs are, we’re always going to understand what other people want. The problems we’re solving for, our customers, we’re always going to know best. And to truly keep us in the driver’s seat, we also need to make sure that we’re a part of maintaining the code base. We can’t take ourselves out of the code entirely because also coding agents have a weird way of maintaining a code base. They sprawl a lot, and this is actually the main argument of Dex

[04:39] Horthy. He gave a really popular talk why software factories fail a couple of months ago, and his main argument is code base maintainability. Agents just aren’t able to keep it up in the way that humans do, so we have to be a part of that process still. In fact, Dex also did the same thing as me where he started with the dark factory and had to dial it back a bit, adding more human in the loop to make it actually realistic. Now, when he says software factories fail, I think that’s more in line with my definition of a dark factory, right? Like this is the system that doesn’t work. And so, I’ve taken all the lessons here that I’ve explained. It’s an important precursor, and that leads into

[05:11] the system I have now that is genuinely working extremely well for me. And so, thinking about, you know, how can we maintain human in the loop while still keeping the process as autonomous as possible. How do we make it so we continue to help maintain the code base? How do we keep the agents on track as they’re ripping through all these different tickets? All of this is built in. So, there’s one big difference here between the software factory and the dark factory, and I don’t want to get super caught up on definitions in general, but I think there is a really important distinction here. So, I’ll cover that with a more simplified view

[05:41] of my software factory, then I’ll get more into how each step works so you can really see how reliability and human in the loop is built in. So, the big difference between the AI software factory and Dark Factory, besides the obvious human-in-the-loop that we’ll talk about at the end, is the scope of work that you build into the system and how much you plan that with the agent. So, with the Dark Factory, we are as hands-off as we possibly can be. We create just some kind of high-level document for this massive application we want to create, and we expect the factory to split that into issues and

[06:11] handle them all one at a time or some in parallel. The point is it is entirely lights out once we give that more broad-level description of what we want to create. And we’re even letting the agent fill in the gap for some of our intent, right? And that’s the big problem I was talking about where we don’t want the agent to assume our intent, even if it is a very capable model. And so, what we’re doing with the software factory is we are giving individual releases into the system. So, we’re still having it rip through a ton of issues all by itself, but instead of it just being like, “Build the entire

[06:42] thing, go.” it’s let’s actually figure out like, “What’s the next scope of work?” Let’s figure out the tickets and how we want to split up the work. Then we let the factory handle it autonomously. So, the core loop of the factory is still the same. How I handle each individual GitHub issue, Jira ticket, whatever that might be. I have a very similar way of building and validating, and it’s always going to be the issue is the input, the pull request is the output. That remains the same. It’s really a lot of what I do beforehand and after the fact that makes the factory a lot more human-in-the-loop and reliable. And so, with that, let me

[07:13] go through the three core parts of the factory here. Now, I’m going to stay pretty high-level cuz I’ve spent hundreds of hours building this system and testing it. Obviously, I could get really in the weeds, but I just want to generally give you inspiration for the process, talk about what’s really working in the industry as a whole, and then let me know in the comments if you want me to cover anything specific here in a dedicated video. Big thanks to Port for backing today’s video. They’re the platform that helps teams run their own AI software factory. Cuz here’s the thing, everything I’m showing you in today’s video works for

[07:44] real engineering teams. I’ve built it myself. But when you start to roll factories out to organizations where you have hundreds of services, a bunch of teams, all these people and agents opening up pull requests, you need something to help you manage all of it. Essentially, a managed software factory. Your agents need to know who owns what and what standards apply. And you need to actually be able to see what your agents are shipping as they do so. And that is where Port comes in. They map your entire environment into what they call the context lake. Here your services, owners, docs, and standards

[08:15] all live in one catalog. You can also connect your agents with Port’s MCP server. Like right here in Cloud Code, I did so with a single command. And so now my agent can query all my factories, get information like who owns what, and get other context around the factory like its readiness and which checks are failing. Cuz we’re always going to have a standard to test against for our factories. And because every pull request goes in Port’s catalog, I can ask my agent about a lot of context around my factories, like how many pull requests each one is merging per month, things like how long my laps are taking

[08:46] on average. These insights are very valuable if you want to make improvements to your factories over time. And of course, I can set permissions for my agent like this one here is just read-only. Port is free for up to 15 seats, no credit card required, and it’s free to try on your own repos. I’ll have a link to them in the description. So before we get into the core loop of the factory, there’s two steps. We need to plan the larger body of work we want to accomplish in the next release, and then split it into tickets so we have bite-size pieces of work that can each go through the full loop that I’ll cover in a second. Now,

[09:18] the first step here, the planning, I have intentionally left out of the factory. Nothing in the harness is going to walk you through this because I’m assuming you already have your own way of planning with your agent. I have that myself, you probably do, every company I work with. I don’t really want to force that into the factory. And I want to be fully in the loop with the planning. And so, you create your PRD, your architecture document, whatever you usually do in your normal way, and then that becomes input to the factory. So, we’re planning our next release. Now, the point of the software factory that makes it very different than the dark

[09:49] factory is we’re not going to try and just build the entire application. And so, for greenfield, it’s just simply a proof of concept. You want the factory to build for that first release. And then for brownfield, because yes, the factory works great if you apply it on top of existing codebases as well, it is simply a small epic that you’re going to define. Now, I know that small is very much left up to interpretation for an epic. Every organization has a different way that they scope work for an epic or release. It’s really up to you. My general rule of thumb is I want to

[10:19] create an epic document that’s going to get split into anywhere between 10 and 20 tickets. I know that’s a large range. Every ticket is going to be a very different size, but that’s just the best estimate I can give you. And so, if you build out your factory, you use this system, you’ll start to just build that muscle over time for, you know, that size of epic that works well for you. But the point in the epic is you want to describe both what we are building here and what specifically we are not building. So, having things that are out of scope is also very helpful for the factory just to continue to steer it as it’s churning through the different

[10:50] tickets. And then the other thing that we define up front that is more unique to the factory, but is also just really helpful for any agentic coding workflows, is defining the holdout scenarios. And so, essentially what a holdout scenario is is it is a test that we’re going to run at the end of the implementation. But the implementer agent, the builder, doesn’t actually know what the holdout scenarios are, right? We’re withholding that information. So, that way there’s no bias there. The agent can’t overfit the implementation to make our testing scenarios pass. This is a big thing that

[11:21] has boosted reliability in my software factory because agents are sycophantic. If they know the test scenarios you’re going to be working with, they’re going to try to engineer the implementation just to get those to pass. And so, a lot of times the software isn’t really built well, it’s just built well for those tests. And so we don’t want the builder to know what they are. So we define all of that in a document. You create your usual PRD architecture doc, whatever, and then the factory will take that and help you split it into tickets. And as a part of this process, it’s also going to help you do your dependency mapping. So

[11:52] figuring out things that can be knocked out in parallel, dependencies that we have, so we have to, you know, have a specific order for the laps that we accomplish. The point is the factory is going to be applying GitHub labels to set up all these dependencies to really set the core loop up for success, so it’s doing things and testing things in the right order. Now, we don’t have to have human in the loop here. A lot of what I’m building into my software factory is sort of like toggles that we have for human in the loop, so maybe we don’t review PRs before we merge into staging or we do, or we do review the split before we

[12:24] start building or we don’t. And so every organization, every person has different needs, right? And it also depends on the complexity of what we’re building in this specific release. So there might be some releases where we’re dealing with compliance and regulation, we really have to make sure things are solid. So we want to review the split, we want to review the PRs at the end, but we still want the system to just churn through the issues once we do create them. And then there are other releases where we’re maybe just handling a big backlog of bugs. And in that case, maybe we just want to entirely trust it to split into tickets and merge things right into our

[12:54] staging environment, right? Like there’s there’s a sort of dynamic need that we have where it’s not always human in the loop needs to be this place, this place, and so I’ve created the factory to be very adaptable. Now, trust me, I wish I could really get into what this factory looks like in action, showing the runs, showing my plans, the splits, and what the issue lists look like, but I did try recording a version of this video where I showed all that, and it got way too long. So I have to stay high-level for now, but definitely I will be getting more into this in future videos. The point is here that after the planning and the splitting, we have a list of

[13:25] GitHub issues, and we’re just going to rip through them with the core loop of the factory doing all the planning and validation. So, zooming in here, we start with the GitHub issue. We can run many of these labs in parallel because we did the dependency mapping, we know things that we can knock out at the same time. So, each time we run a lap, it is going to choose a single GitHub issue to work on. It’ll apply a sort of claim label, so other parallel labs don’t pick it up, and then we make a decision up front because something that I noticed with the first version of even my dark factory is when I did the more

[13:56] comprehensive workflow to handle every single implementation, there was these basic tickets that would take like 30 minutes or 20 minutes to implement where they really didn’t need that. And so, I make the decision up front actually using Jev, is this a simple thing where I just have a faster build workflow, or is it more complex where we do want to have the stages for iteration and things like that. And so, it makes the decision, but either way, once it’s done building, it’s going to go through the validation and code review that also understands, you know, based on the complexity of the implementation, how much time do we have to spend here. And

[14:26] so, there’s both review and validation cuz they are different things. Validation means as a part of the harness, I give it the tooling to actually test the application as a user would. So, it replaces a lot of my manual testing because we do want it to be more autonomous. That’s the whole point of the software factory. And so, clicking buttons, entering text in the chat input, whatever it is for the application. And then after we do the code review, and this is more analyzing like since we know that the app is working, now let’s make sure that it’s simple, the code is maintainable, it was implemented correctly, right? Like those kinds of more software engineering

[14:58] decisions, the the more classic code review. And then for anything that it deems incorrect in either one of these stages, it sends back to the implementation workflow to fix, right? So, even for a complex implementation, it’s just going to go through the simple workflow to address any feedback. And of course, there are max retries, so we don’t get stuck in an infinite loop with the factory. And so, then once we are done with our reviewing and potential iterating, then we allow to merge the pull request into whatever branch goes into our staging environment only if CI is green and the reviewed code is good.

[15:31] And then for this entire process here, I have a manager agent that runs on a periodic basis like every two or three hours and it’s kind of surveying the success of all the laps together because this is actually the most recent thing I’ve added into the factory. Before I had this, these agents are never really communicating, right? Like each individual lap isn’t really understanding if dependencies are changing or if one pull request is getting really stuck. Like if we hit the max retries and an agent really is getting stuck on a problem, we need something that kind of peers over the

[16:01] entire process and can realign issues or kind of like hijack a workflow and finish it if needed. And this has also really increased the reliability because also I’ve set it up where it will actually alert me if I really do need to come into the system. Because as much as we want this to be autonomous, it’s not a dark factory anymore. We are okay with once in a while us having to come in and review the split or, you know, sort of rescue a workflow. It happens once in a while. So usually I’ll just have my main Claude code agent like my second brain

[16:32] help me when the manager is alerting me of these issues. And then of course the holdout scenarios come in because we’re running those for the app validation. And as a part of the factory, I have my core context. I call it my mission.md or engineering.md. It’s the things that are out of scope that I never want to build and just higher level direction for how I want the agent to operate in my code base. So kind of that plus the global rules together. And I’m making sure that I never edit these files. That’s a part of my review making sure that we never touch those because I don’t want the factory to be able to change its own permissions and behavior. And then the

[17:03] last thing right here is for every single one of these nodes, I’m using different models and even different providers because this factory I’ve made it very token efficient. We don’t always need the most reasoning possible. So definitely for a lot of the planning that I’m doing like right here, I am using you know Opus 5.5 or GPT-6 Astra. But for a lot of these individual nodes, like using Jev to pick the task and then for simple maybe just using Sonnet 5.5. I mean even for shipping these different nodes in here, I don’t have to use the best model. And so I’ve done a lot of

[17:33] that experimentation optimizing for the sake of tokens. I’m running hundreds and hundreds of laps every single week not hitting my rate limits. All right, and then the last part of the process here, this is where we come back in to review things. And so we build up all the issues for the epic within our core loop. We merge things into the staging environment. This is where we get to validate things ourselves cuz we need the step to verify our intent. And so we test things ourselves and then anything that’s off like if something wasn’t built how we actually wanted it to be, all we have to do is simply create a new issue in the repository and the factory

[18:05] will pick that up automatically just like it did with the initial split from our epic document. And so it’s very easy for us to sort of test the batch of features in the epic and then give batch feedback. We we could you know create four or five issues, whatever, and then it’ll just rip through all of these and then we can test staging again. And then we go to the production once it’s right. And so the dark factory pretty much goes straight to production, but the software factory, I found this to be very important. So we have true human in the loop, but at the same time we get to review a lot at once. And so we are solving that bottleneck at least

[18:36] partially for the human review at the end. And then once we’re happy with what’s in production, we can simply just go on to the next release and repeat this process going through the planning, core loop, and the staging and production. And that’s it. That is the AI software factory at a high level. And so of course, like I already said, let me know if you want me to cover any part of this in more detail, but hopefully you found this inspirational just take aways for your own AI coding workflows or if you want to build a software factory yourself, it really is the future of agentic engineering. And so if you appreciate this video, you’re looking forward to more things on an AI

[19:07] software factory and AI coding in general, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.