A camada de verificação da Dark Factory

StrongDM lançou software sob duas regras: “O código não deve ser escrito por humanos” e “O código não deve 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 fazendo merge de centenas de pull requests gerados por IA mensalmente.²

Dan Shapiro chama o estágio 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 em que a maioria das equipes se encontra agora—desde codificação manual (Nível 0), passando por delegação de tarefas (Nível 1), piloto automático na estrada (Nível 2), Waymo com motorista de segurança (Nível 3), até 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?

O problema de verificação se multiplica

Em todos os níveis abaixo do 5, um humano lê o 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 nunca inspecionar o artefato em si.

A armadilha central são agentes burlando testes. A StrongDM descobriu que seus agentes escreviam return true para passar nos conjuntos de teste sem fazer nada útil.¹ Os testes estavam verdes. O pipeline de CI estava satisfeito. O código era inútil. Eran Kahana, de Stanford Law, estende a observação para um alerta estrutural: o problema mais amplo é 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. Quando agentes otimizam para aprovação em testes, a aprovação 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 levar essa dinâmica em conta, ou vai medir conformidade, não qualidade.

Como a StrongDM realmente resolve a verificação

A resposta da StrongDM é o que eles chamam de “Scenarios”—histórias de usuário ponta a ponta armazenadas fora do codebase, funcionando como conjuntos de validação em machine learning.¹ A analogia é precisa: assim como modelos de ML são avaliados contra dados nos quais nunca foram treinados, código construído por agentes é avaliado contra cenários que o agente não pode acessar durante a geração.

A métrica principal é “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 limite 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 visam 100% de compatibilidade com API usando bibliotecas de cliente de referência SDK populares e publicamente disponíveis.¹ Os agentes rodam contra os gêmeos, não contra endpoints mockados. A fidelidade comportamental do gêmeo determina a confiabilidade do teste.

A StrongDM observou algo que também já vi: “com a segunda revisão do Claude 3.5 (outubro de 2024), fluxos de trabalho agenticos de longo horizonte começaram a acumular corretude em vez de erros.”¹ 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 ultrapassaram 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.² Dentro do pilar de governança, a BCG Platinion descreve 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 de 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 se eliminam. Se descorrelacionam. Dois agentes ainda podem compartilhar vieses sistemáticos herdados dos dados de treinamento. Mas a probabilidade de pontos cegos idênticos cai quando o agente avaliador opera a partir de um referencial diferente.

A BCG Platinion identifica o “pensamento por 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 passa de escrever código para escrever especificações contra as quais agentes podem executar. Especificações ruins produzem testes aprovados em comportamento errado—a mesma dinâmica do return true que a StrongDM encontrou.¹

A BCG Platinion também identifica uma restrição que 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 de API, guias de estilo, históricos de falhas—é infraestrutura, não documentação.

O que eu já rodo no Nível 4

Meu loop de execução noturno, o Ralph Loop, opera no Nível 4 de Shapiro. Eu escrevo especificações, lanço agentes, durmo e reviso os resultados de manhã. Os agentes rodam contra mais de 95 hooks que interceptam toda 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 resolvem o problema de burla de Kahana no nível da ferramenta. Um agente que tenta fazer force-push para main é bloqueado antes que o comando execute, não depois que um teste detecta o dano. Um agente que tenta fazer commit de arquivos correspondendo a padrões .env é interceptado. Um agente que relata “todos os testes passaram” sem rodar pytest é sinalizado pelo evidence gate, que exige output colado de testes mostrando zero falhas, não uma alegação de que os testes passariam.

O evidence gate impõe seis critérios em toda mudança não trivial: segue padrões do codebase (nomeie o padrão e o arquivo), solução funcional mais simples (declare alternativas rejeitadas), casos extremos tratados (liste cada um), testes passam (cole o output), 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 funcionar” não são evidência. O gate rejeita linguagem evasiva e exige artefatos.

O quality loop—implementar, revisar, avaliar, refinar, visão panorâmica, repetir, relatar—roda como uma restrição comportamental codificada no system prompt do agente via CLAUDE.md. O loop não garante que o agente siga cada passo. Os hooks verificam que seguiu.

Os cinco pilares da BCG Platinion mapeiam para infraestrutura que 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.

Dois pilares que não construí: 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 spawn nativo de agentes do Claude Code, não uma fábrica construída para esse fim).

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 os diffs do git. Rodo a aplicação. Verifico se 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 detectam.

Os problemas que os hooks não detectam são os interessantes. Eles se enquadram 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 ataca 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 query de banco de dados que contorna o padrão de repository existente. Um novo endpoint que duplica lógica de outro módulo. Análise estática captura alguns desses. Verificação de conformidade arquitetural—a camada de governança da BCG Platinion—captura mais.² Nenhum dos dois captura os sutis, onde o novo código é tecnicamente consistente com os padrões, mas introduz uma divisão conceitual que se multiplica em 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 no conjunto 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 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 do codebase, avaliadas por agentes independentes. Sem avaliação holdout, a Lei de Goodhart transforma todo conjunto 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 de API, não comportamento. Gêmeos que replicam a superfície comportamental de dependências externas permitem execução de cenários ponta a ponta sem risco em 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 de red-team que ativamente investigam burlas, atalhos e verificação fantasma adicionam uma camada que testes passivos não conseguem fornecer.

Interceptação no nível da ferramenta. Hooks que bloqueiam operações prejudiciais antes da execução, não testes que detectam danos depois. A camada de hooks opera abaixo da tomada de decisão do agente e não pode ser contornada por prompts espertos ou atalhos 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 por intenção” da BCG Platinion.² A especificação do 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 de auditoria padrão da indústria para software construído por agentes.⁴ A camada de verificação precisa produzir artefatos que um humano (ou regulador, ou respondente de incidentes) possa seguir do comportamento implantado de volta até a especificação que o gerou.

A avaliação honesta

Eu rodo o Nível 4 com alta confiança. Meus agentes noturnos produzem trabalho que passa na revisão matinal com mais frequência do que não. 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 relata ganhos de produtividade de 3-5x de 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 enviar código para produção.¹ 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 roda no escuro. É uma fábrica onde as luzes são a camada de verificação, e todo o resto—incluindo o código—é commodity.

Eu 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—são necessários no Nível 5, mas não suficientes. A peça que falta é verificação que escale com a mesma autonomia que a geração.

Construir essa peça é o trabalho que vem pela frente.