Verificação na Dark Factory: Quando nenhum humano lê o código

Uma Dark Factory (Nível 5) é um ambiente de desenvolvimento de software onde máquinas geram, verificam e implantam código — nenhum humano lê uma única linha. A camada de verificação que torna a dark factory viável exige avaliação no estilo holdout, Digital Twin Universes, revisão multi-agente e restrições de gosto codificadas. Sem essa camada, agentes manipulam testes e a qualidade desaparece.

A StrongDM lançou software sob duas regras: “O código não pode ser escrito por humanos” e “O código não pode ser revisado por humanos.”¹ Uma equipe de três pessoas (Justin McCarthy, Jay Taylor e Navan Chauhan) construiu e lançou o Attractor e o CXDB (16 mil linhas de Rust, 9,5 mil de Go, 6,7 mil de TypeScript) com um gasto mínimo de US$ 1.000 em tokens por engenheiro por dia.¹ A BCG Platinion, citando cobertura do Spotify e do TechCrunch, relata que os melhores desenvolvedores do Spotify não escreviam código desde dezembro de 2025, com a empresa mesclando centenas de pull requests gerados por IA mensalmente.²

Dan Shapiro chama o ponto final de Nível 5: a Dark Factory. Código gerado por máquinas, verificado por máquinas, implantado sem que um humano leia uma única linha.³ Os níveis anteriores acompanham a progressão que a maioria das equipes segue agora: codificação manual (Nível 0), delegação de tarefas (Nível 1), piloto automático na rodovia (Nível 2), Waymo com motorista de segurança (Nível 3) e robotáxi onde você escreve a especificação e sai por 12 horas (Nível 4).³

A pergunta que ninguém respondeu bem: como é a camada de verificação no Nível 5? A análise a seguir mapeia a infraestrutura necessária, partindo da infraestrutura de gosto que governa como avalio qualidade em todo o meu trabalho de engenharia.

O problema de verificação se acumula

Em todos os níveis abaixo do 5, um humano lê código em algum momento. No Nível 3, o humano gerencia a IA como um desenvolvedor sênior. No Nível 4, o humano verifica se os testes passaram após 12 horas.³ Esses níveis funcionam porque uma pessoa com conhecimento institucional consegue fazer correspondência de padrões com a intenção. A especificação dizia “retry com backoff exponencial” e o código faz retry linear; um desenvolvedor percebe isso num relance.

Remova o humano por completo e a verificação se torna um problema diferente. Não mais difícil em grau. Diferente em natureza. O verificador não pode depender de compreensão de leitura. O verificador precisa codificar o que “correto” significa em forma executável e então avaliar a saída contra essa codificação sem jamais inspecionar o artefato em si.

A armadilha central são agentes manipulando testes. A StrongDM descobriu que seus agentes escreviam return true para passar nas suítes de testes sem fazer nada útil.¹ Os testes estavam verdes. O pipeline de CI reportava sucesso. O código era inútil. Eran Kahana, de Stanford Law, estende a observação para um alerta estrutural: a questão mais ampla é a circularidade, onde a mesma classe de tecnologia avalia código que a mesma classe escreveu.⁴

A Lei de Goodhart opera aqui com força incomum. Gosto é um sistema técnico defende que a verificação automatizada precisa de uma camada de julgamento acima dela; sem avaliação no nível de gosto, testes se tornam alvos em vez de medidas. Quando agentes otimizam para passagem em testes, a passagem em testes deixa de medir corretude.⁴ Toda métrica que se torna o alvo deixa de ser uma boa métrica. A camada de verificação de uma dark factory precisa considerar essa dinâmica ou vai medir conformidade, não qualidade.

Como a StrongDM realmente resolve a verificação

A resposta da StrongDM é o que chamam de “Scenarios”: histórias de usuário de ponta a ponta armazenadas fora da base de código, funcionando como conjuntos holdout em machine learning.¹ A analogia é precisa: assim como praticantes de ML avaliam modelos contra dados nos quais nunca treinaram, agentes independentes avaliam o código gerado contra cenários que o agente de codificação não pode acessar durante a geração.

A métrica-chave é “Satisfaction”: a fração de trajetórias observadas que provavelmente satisfazem o usuário.¹ Não existe padrão da indústria para qual pontuação constitui satisfação suficiente. A StrongDM chegou ao seu próprio limiar empiricamente.

Para fazer testes baseados em cenários funcionarem em escala, a StrongDM construiu um Digital Twin Universe: clones comportamentais de Okta, Jira, Slack, Google Docs, Drive e Sheets.¹ Os gêmeos miram 100% de compatibilidade com API usando bibliotecas de referência SDK populares publicamente disponíveis.¹ Os agentes executam contra os gêmeos, não contra endpoints mockados. A fidelidade comportamental do gêmeo determina a confiabilidade do teste.

A StrongDM observou um padrão que eu também vi: “com a segunda revisão do Claude 3.5 (outubro de 2024), fluxos de trabalho agênticos de longo horizonte começaram a acumular corretude em vez de erro.”¹ Abaixo de um limiar de capacidade, execuções mais longas de agentes produzem mais erros. Acima dele, execuções mais longas produzem código melhor. O padrão da dark factory só se tornou viável depois que os modelos cruzaram esse limiar.

Cinco camadas de governança

O framework de transformação de cinco pilares da BCG Platinion inclui uma camada de governança com múltiplas etapas de verificação antes que o código chegue à produção.² Os pilares: um sistema operacional orientado por intenção, infraestrutura de conhecimento codificado, capacitação da força de trabalho, uma camada de governança com agentes de verificação independentes e arquitetura de fábrica para orquestração.² O pilar de governança inclui testes baseados em cenários executados por agentes independentes, análise estática, verificação de conformidade arquitetural, testes de regressão comportamental e agentes red-team que ativamente tentam quebrar a saída.²

A independência importa. Quando o mesmo agente escreve e testa seu próprio código, o problema de circularidade de Kahana se aplica.⁴ Quando um agente separado (com system prompts diferentes, contexto diferente, incentivos diferentes) avalia o trabalho, os modos de falha se descorrelacionam. Não eliminam. Descorrelacionam. Dois agentes ainda podem compartilhar vieses sistemáticos herdados dos dados de treinamento. Porém, a probabilidade de pontos cegos idênticos diminui quando o agente avaliador opera a partir de um referencial diferente.

A BCG Platinion identifica “pensamento de intenção” como uma competência crítica para equipes de dark factory: traduzir necessidades de negócio em descrições precisas e testáveis dos resultados desejados.² O papel humano muda de escrever código para escrever especificações contra as quais agentes podem executar. Especificações ruins produzem testes que passam em comportamento errado, a mesma dinâmica de return true que a StrongDM encontrou.¹

A BCG Platinion também identifica uma restrição que já experimentei diretamente: “Agentes de IA são tão eficazes quanto o conhecimento codificado que podem acessar.”² Um agente operando sem contexto de projeto gera código plausível que viola convenções locais, ignora decisões arquiteturais e redescobre problemas que a equipe já resolveu. Conhecimento codificado (decisões de design, contratos API, guias de estilo, históricos de falha) é infraestrutura, não documentação.

O que eu já executo no Nível 4

Meu loop de execução noturna, a arquitetura do agente Ralph, opera no Nível 4 de Shapiro. Eu escrevo especificações, lanço agentes, durmo e reviso os resultados pela manhã. Os agentes executam contra mais de 95 hooks que interceptam cada chamada de ferramenta (escritas de arquivo, comandos git, execução de shell) antes e depois da execução. Os hooks impõem restrições com as quais o agente não pode negociar ou contornar.

Os hooks abordam o problema de manipulação de Kahana no nível de ferramenta. Um post separado documenta a arquitetura completa de hooks, mas a propriedade relevante aqui é a interceptação: hooks disparam antes da execução da ferramenta, não depois. Um agente que tenta fazer force-push para a main é bloqueado antes do comando executar. Um agente que tenta commitar arquivos correspondendo a padrões .env é interceptado. Um agente que reporta “todos os testes passaram” sem executar pytest é sinalizado pelo evidence gate, que exige saída de teste colada mostrando zero falhas, não uma afirmação de que os testes passariam.

O evidence gate impõe seis critérios em toda mudança não trivial: segue padrões da base de código (nomeie o padrão e o arquivo), solução mais simples funcional (apresente alternativas rejeitadas), casos extremos tratados (liste cada um), testes passam (cole a saída), sem regressões (nomeie os arquivos verificados) e resolve o problema real (declare a necessidade do usuário e como a mudança a endereça). “Eu acredito” e “deveria” não são evidência. O gate rejeita linguagem evasiva e exige artefatos.

O quality loop (implementar, revisar, avaliar, refinar, ampliar a visão, repetir, reportar) executa como uma restrição comportamental codificada no system prompt do agente via CLAUDE.md. O loop não garante que o agente siga cada etapa. Os hooks verificam que seguiu.

Os cinco pilares da BCG Platinion mapeiam para infraestrutura que eu já mantenho:

• SO orientado por intenção: Arquivos CLAUDE.md e especificações de desenvolvimento orientadas por PRD codificam a intenção do projeto como contexto executável.
• Conhecimento codificado: Mais de 139 skills, organizadas como capacidades reutilizáveis, dão aos agentes acesso a convenções do projeto, decisões arquiteturais e conhecimento de domínio.
• Governança: Hooks implementam a camada de interceptação. O evidence gate implementa a camada de auditoria. O quality loop implementa a camada de restrição comportamental.

Não construí dois pilares: capacitação da força de trabalho (irrelevante para um praticante solo) e arquitetura de fábrica como plataforma de orquestração dedicada (meu setup atual usa o spawning nativo de agentes do Claude Code, não uma fábrica construída para esse fim). O sistema de contexto composto descreve como essas camadas de infraestrutura se acumulam em um ativo de capital, tornando cada sessão subsequente mais capaz.

A lacuna entre o Nível 4 e o Nível 5

Passar do Nível 4 para o Nível 5 significa eliminar a revisão matinal. Agora, eu acordo e leio o que os agentes produziram durante a noite. Verifico diffs do git. Executo a aplicação. Confirmo que a saída corresponde à minha intenção. Essa revisão leva de 30 minutos a uma hora e captura problemas que os hooks não pegam.

Os problemas que os hooks não pegam são os interessantes. Eles se dividem em categorias que a automação atual lida mal:

Desvio de intenção. O agente completou a especificação fielmente, mas a especificação era ambígua, e o agente escolheu a interpretação errada. Nenhum teste captura uma interpretação incorreta que produz comportamento válido. A abordagem de cenários da StrongDM enfrenta isso codificando histórias de usuário como a especificação, não requisitos técnicos.¹ Os cenários descrevem o que um usuário experimenta, não o que o código faz.

Erosão arquitetural. O agente adicionou um recurso que funciona isoladamente, mas degrada a coerência estrutural do sistema. Uma nova consulta ao banco de dados que contorna o padrão de repositório existente. Um novo endpoint que duplica lógica de outro módulo. Análise estática captura alguns desses casos. Verificação de conformidade arquitetural (a camada de governança da BCG Platinion) captura mais.² Nenhuma das duas captura os casos sutis em que o novo código é tecnicamente consistente com os padrões, mas introduz uma divisão conceitual que se acumula ao longo de mudanças futuras.

Perda de conhecimento institucional. Kahana levanta um risco subestimado: quando ninguém lê o código, ninguém constrói intuição sobre o sistema.⁴ Como Kahana alerta, “Ninguém vai saber por quê. Ninguém vai saber como consertar.”⁴ Hoje, minha revisão matinal constrói essa intuição incrementalmente. No Nível 5, o sistema se torna opaco para seu operador. Todo sistema complexo eventualmente precisa de intervenção que a automação não consegue lidar: um incidente de segurança, uma mudança de lógica de negócio que viola premissas embutidas na suíte de testes, uma integração com um sistema externo que se comporta diferente do que sua documentação afirma. O operador que nunca leu o código não consegue intervir efetivamente.

O que a camada de verificação realmente precisa

Sintetizando a prática da StrongDM, o framework de governança da BCG Platinion, a análise de falhas de Kahana e minha própria infraestrutura, a camada de verificação para uma dark factory requer no mínimo:

Avaliação no estilo holdout. Testes que o agente gerador não pode acessar durante a produção de código. Os cenários da StrongDM. Especificações comportamentais armazenadas separadamente da base de código, avaliadas por agentes independentes. Sem avaliação holdout, a Lei de Goodhart transforma toda suíte de testes em um alvo.

Gêmeos digitais para testes de integração. Agentes não podem testar contra sistemas de produção. Mocks são rasos demais; verificam contratos API, não comportamento. Gêmeos que replicam a superfície comportamental de dependências externas permitem execução de cenários de ponta a ponta sem risco de produção.

Verificação multi-agente com modos de falha descorrelacionados. O agente escritor e o agente avaliador devem operar a partir de contextos diferentes. Agentes red-team que ativamente sondam por manipulação, atalhos e verificação fantasma fornecem uma camada que testes passivos não conseguem.

Interceptação no nível de ferramenta. Hooks que bloqueiam operações nocivas antes da execução, não testes que detectam danos depois. A camada de hooks fica abaixo da tomada de decisão do agente e resiste a contorno por prompting inteligente ou atalhos de return true.

Especificações de intenção executáveis. Especificações precisas o suficiente para que a ambiguidade seja detectável. A competência de “pensamento de intenção” da BCG Platinion.² A especificação de Nível 4 de Shapiro que você escreve antes de sair por 12 horas.³ A especificação é o produto. O código é um efeito colateral.

Trilha de auditoria sem lacuna de responsabilidade. Kahana cita os AI Life Cycle Core Principles exigindo que a saída seja “rastreável até uma parte responsável apropriada.”⁴ Ainda não existe metodologia padrão de auditoria para software construído por agentes.⁴ A camada de verificação precisa produzir artefatos que um humano (ou regulador, ou respondente de incidentes) consiga rastrear desde o comportamento implantado até a especificação que o gerou.

A avaliação honesta

Eu executo o Nível 4 com alta confiança. Meus agentes noturnos produzem trabalho que passa na revisão matinal na maioria das vezes. Os hooks capturam as falhas mecânicas. O evidence gate captura as falhas epistêmicas. O quality loop reduz as falhas comportamentais.

O Nível 5 requer resolver problemas que não resolvi. Detecção de desvio de intenção sem correspondência de padrões humana. Conformidade arquitetural que captura erosão conceitual, não apenas violações estruturais. Conhecimento institucional que se acumula no sistema em vez de na cabeça do operador.

A BCG Platinion reporta ganhos de produtividade de 3 a 5x em equipes que adotam padrões de dark factory.² A StrongDM lançou software construído por agentes com três engenheiros e um orçamento de tokens.¹ O caso de produtividade é claro. O caso de verificação, não.

As equipes que estão tendo sucesso no Nível 5 compartilham um traço comum: investiram mais em infraestrutura de verificação do que em geração de código. A StrongDM construiu um Digital Twin Universe inteiro antes de confiar nos agentes para entregar código.¹ O framework da BCG Platinion tem cinco pilares de transformação incluindo uma camada de governança com múltiplas etapas de verificação antes que o código chegue à produção.² A dark factory não é uma fábrica que funciona no escuro. É uma fábrica onde as luzes são a camada de verificação, e todo o resto (incluindo o código) é commodity.

Já escrevi anteriormente sobre o que quebra quando agentes rodam sem supervisão e sobre o evidence gate como defesa contra verificação fantasma. Esses textos descrevem a infraestrutura para o Nível 4. A dark factory exige essa mesma infraestrutura, estendida para operar sem o humano que atualmente lê o diff matinal. Os hooks, os evidence gates, os quality loops: todos necessários no Nível 5, mas não suficientes. A peça que falta é verificação que escala com a mesma autonomia que a geração.

Construir essa peça é o trabalho que vem pela frente. O hub de engenharia de IA reúne o arco completo dessa investigação, desde o design de hooks individuais passando por contexto composto até a fronteira da dark factory.

FAQ

O que é uma Dark Factory no desenvolvimento de software?

Uma Dark Factory (Nível 5 de Dan Shapiro) é um ambiente de desenvolvimento de software onde máquinas geram código, verificam código e implantam código sem que um humano leia uma única linha. Os níveis anteriores progridem da codificação manual (Nível 0) através de automação crescente, sendo o Nível 4 o modo “robotáxi” onde um humano escreve a especificação, sai por 12 horas e revisa os resultados. A dark factory elimina até mesmo essa revisão final.

Qual é o maior desafio de verificação no Nível 5?

A armadilha central são agentes manipulando testes. A StrongDM descobriu agentes escrevendo return true para passar nas suítes de testes sem fazer nada útil. A Lei de Goodhart opera com força incomum: quando agentes otimizam para passagem em testes, a passagem em testes deixa de medir corretude. A camada de verificação precisa considerar isso usando avaliação no estilo holdout (testes que o agente gerador não pode acessar durante a produção de código), verificação multi-agente com modos de falha descorrelacionados e interceptação no nível de ferramenta que bloqueia operações nocivas antes da execução.

Qual é a lacuna entre o Nível 4 e o Nível 5?

Três problemas que a automação atual lida mal: desvio de intenção (o agente completou a especificação fielmente, mas escolheu a interpretação errada de um requisito ambíguo), erosão arquitetural (novos recursos que funcionam isoladamente, mas degradam a coerência estrutural) e perda de conhecimento institucional (quando ninguém lê o código, ninguém constrói intuição sobre o sistema necessária para intervenção durante incidentes ou mudanças de lógica de negócio).

Como a StrongDM resolve o problema de verificação?

A StrongDM usa “Scenarios”, histórias de usuário de ponta a ponta armazenadas fora da base de código que funcionam como conjuntos holdout em machine learning. Agentes independentes avaliam o código contra cenários que o agente de codificação não pode acessar durante a geração. Eles construíram um Digital Twin Universe (clones comportamentais de Okta, Jira, Slack, Google Docs) mirando 100% de compatibilidade com API, para que agentes testem contra superfícies comportamentais realistas em vez de mocks rasos.