A Fábrica de Software Mais Governada que Você Nunca Ouviu Falar

Em julho de 2025, Justin McCarthy — CTO do StrongDM, empresa conhecida por sua plataforma de controle de acesso a infraestrutura — reuniu dois engenheiros e anunciou duas regras para um novo projeto interno. Regra um: nenhum humano escreve código. Regra dois: nenhum humano revisa código.

Sete meses depois, o resultado está publicado em factory.strongdm.ai. Não é um artigo acadêmico. É um manifesto operacional, com técnicas documentadas, produtos open-source e métricas de custo. Uma equipe de três pessoas operando uma fábrica de software onde agentes de IA fazem tudo — da implementação à validação.

A reação natural é chamar isso de irresponsável. Afinal, código sem revisão humana soa como o oposto de governança. Mas quando você examina o que o StrongDM Factory realmente construiu, o que aparece é justamente o contrário: cada técnica descrita é um mecanismo de governança disfarçado de prática de engenharia.

O Manifesto Que Parece Insano (Mas Não É)

O contexto brasileiro é útil aqui. Empresas brasileiras adotam IA com velocidade impressionante — mas formalizam governança depois, quando já existem dezenas de agentes operando em produção sem supervisão clara. O resultado é previsível: shadow AI, dados sensíveis em fluxos não mapeados, e uma camada de risco que cresce silenciosamente.

O StrongDM Factory inverte essa sequência. A tese é direta: se a governança está profundamente codificada na infraestrutura, humanos não são mais o mecanismo de enforcement. Humanos definem as regras. A infraestrutura as impõe.

Isso não significa ausência de controle. Significa que o controle não depende de alguém “dar uma olhada” no código às 17h de sexta-feira. O controle é mecânico, contínuo e auditável.

A provocação das duas regras — nenhum humano escreve, nenhum humano revisa — é intencional. Força a pergunta: se você tirar o humano do loop de execução, o que sobra? A resposta do StrongDM: sobra a infraestrutura de validação. E se essa infraestrutura for rigorosa o suficiente, o resultado é mais governado, não menos.

Cenários em Vez de Revisão

O coração técnico do Factory é o modelo de cenários. O ciclo é simples: Seed, Validation Harness, Feedback Loop.

O “Seed” é o ponto de entrada — pode ser um PRD, uma captura de tela, um trecho de código existente. O “Validation Harness” é o que importa: cenários end-to-end que descrevem o comportamento esperado do software, armazenados fora do código. O “Feedback Loop” é o mecanismo de autocorreção — resultados alimentam as entradas até que os cenários holdout passem consistentemente.

Dois detalhes merecem atenção.

Primeiro, os cenários não são testes unitários. São especificações comportamentais completas — histórias de usuário executáveis que descrevem trajetos inteiros pelo sistema. A métrica de sucesso não é binária (passou/falhou), mas probabilística. O Factory usa o termo “satisfação”: qual fração das trajetórias observadas provavelmente satisfaz os requisitos? Isso reconhece que software produzido por modelos de linguagem tem uma natureza estatística, não determinística.

Segundo, o código é tratado como artefato opaco. A analogia usada pelo Factory é precisa: código gerado por agentes é como pesos de um modelo de ML — validado pelo comportamento que produz, não pela sua estrutura interna. Ninguém lê os pesos de uma rede neural para verificar se ela funciona. Você roda os testes.

Para quem trabalha com LGPD ou compliance no Brasil, essa separação entre quem processa e quem audita soa familiar. É o mesmo princípio: o mecanismo de validação é independente do mecanismo de produção. Os cenários são a auditoria. O código é o processamento. Misturar os dois é o erro clássico.

Nicholas Carlini, pesquisador da Anthropic, demonstrou algo semelhante no início de fevereiro ao coordenar 16 instâncias do Claude para construir um compilador C. O padrão é o mesmo: testes como especificação, ambiente como controle, humano como arquiteto do sistema — não como executor.

Digital Twin — Testando Sem Risco Real

A técnica mais ambiciosa do Factory é o Digital Twin Universe (DTU). A ideia: construir clones comportamentais de serviços externos — Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets — que replicam APIs, edge cases e comportamentos observáveis.

O objetivo é compatibilidade total com as bibliotecas SDK públicas de cada serviço. Se o cliente SDK do Jira funciona contra o clone, o clone é fiel o suficiente.

Para empresas brasileiras de SaaS que integram dezenas de ferramentas no dia a dia, o valor é imediato. Testar integrações em produção é caro, lento e arriscado. Testar contra mocks simplificados é rápido mas falho — mocks não capturam os edge cases que quebram em produção. O DTU ocupa o espaço intermediário: fidelidade comportamental sem dados reais de clientes, sem rate limits, sem custos de API.

O conceito não é novo. Ambientes de staging existem há décadas. O que é sem precedentes é a ambição: replicar o comportamento externo de seis plataformas complexas com fidelidade suficiente para que testes automatizados validem software inteiro contra esses clones. E depois rodar esses testes em volumes que excedem o que a produção real jamais veria.

Há uma implicação regulatória que merece menção. A LGPD exige que dados pessoais sejam processados com base legal e finalidade específica. Testes de integração que usam dados reais de clientes — prática ainda comum em muitas empresas brasileiras — criam exposição desnecessária. O DTU elimina esse vetor de risco por design: os agentes testam contra dados sintéticos em ambientes comportamentalmente fiéis, mas completamente isolados de informações reais.

Na prática, DTU é um sandbox de governança. Permite que agentes operem com autonomia total em um ambiente onde erros não têm consequências reais — mas onde os cenários de validação são rigorosos o suficiente para que o comportamento validado se transfira para produção.

Weather Report — O Catálogo de Serviços da IA

O Weather Report é talvez o componente mais subestimado do Factory. É um relatório publicado abertamente e atualizado regularmente que documenta quais modelos de IA são usados para quais tarefas, e como estão performando.

O roteamento de modelos segue a lógica de especialização. O Factory usa Claude Opus 4.6 para tarefas de frontend, DevOps e QA. Usa GPT-5.3 Codex para segurança, ciência da computação e matemática. Para planejamento, usa consenso entre múltiplos modelos.

Isso não é uma curiosidade técnica. É o equivalente em IA de um catálogo de serviços de SRE — o documento que define qual ferramenta é usada para qual propósito, com qual nível de serviço esperado.

Para o mercado brasileiro, onde sensibilidade a custos é uma realidade constante, o Weather Report endereça uma dor real. Usar o modelo mais caro para toda tarefa é desperdício. Usar o mais barato para tudo é imprudência. Roteamento inteligente de modelos é, no fundo, uma decisão de custo consciente — a versão IA de right-sizing em cloud.

Mas o Weather Report resolve um segundo problema, talvez mais urgente: shadow AI. O Gartner estima que 40% das empresas enfrentarão incidentes de segurança com shadow AI em 2026. Shadow AI acontece quando equipes usam modelos não autorizados, em fluxos não mapeados, sem supervisão. O Weather Report é o antídoto: ao publicar abertamente quais modelos são usados e para quê, o Factory torna a infraestrutura de IA legível. Não há modelo escondido. Não há fluxo não documentado.

Transparência operacional, nesse caso, é governança. E o formato aberto — qualquer pessoa pode consultar o Weather Report — cria accountability externa. Se o Factory diz que usa Opus 4.6 para QA e depois muda silenciosamente, alguém vai notar. O registro público é, em si, um mecanismo de controle.

R$ 5.000 por Dia por Engenheiro

Justin McCarthy oferece uma métrica provocativa: se você não está gastando pelo menos US$ 1.000 por dia em tokens por engenheiro humano, sua fábrica de software tem espaço para melhorar.

Convertendo para a realidade brasileira: aproximadamente R$ 5.000 por dia. R$ 100.000 por mês por engenheiro apenas em consumo de IA.

A reação instintiva é engasgar. Mas a métrica não é uma recomendação de gasto — é um indicador de maturidade. Funciona como métricas de eficiência de cloud spend: se você gasta pouco em computação por engenheiro, não é porque sua equipe é eficiente. É porque sua equipe está fazendo manualmente o que poderia ser automatizado.

O argumento implícito é que, em uma fábrica de software operada por agentes, o custo primário não é salário humano. É consumo de tokens. E se o retorno por token é positivo — ou seja, se os agentes produzem software validado que teria custado mais para produzir manualmente — então o gasto é investimento, não despesa.

O contraste com os dados da Kiteworks é instrutivo. Em 2026, 63% das organizações não conseguem impor limites de propósito da IA — não sabem o que seus agentes estão fazendo, nem quanto estão gastando. O Factory, ao publicar custos e roteamento abertamente, demonstra que controle de custos e autonomia de agentes não são antagônicos. São complementares, desde que a infraestrutura de observabilidade exista.

O Padrão Que Emerge

Olhe o Factory como um todo e um padrão se torna visível. Cada componente que parece ser uma técnica de engenharia é, na verdade, um mecanismo de governança:

Cenários são enforcement de políticas. Definem o que o software deve fazer, independente de como é implementado.
DTU são testes controlados. Permitem validação rigorosa sem exposição a dados ou sistemas reais.
Weather Report é supervisão operacional. Torna legível quem faz o quê, com qual ferramenta, a qual custo.
CXDB é contexto auditável. Um banco de dados de contexto para agentes que registra o que cada agente sabia no momento de cada decisão — usando uma arquitetura DAG imutável que garante rastreabilidade.
StrongDM ID é identidade de agentes. Federação de autenticação para humanos, workloads e agentes de IA, com compartilhamento baseado em escopo — porque agentes que operam sem identidade são agentes que operam sem responsabilidade.

O Attractor, o agente de codificação não interativo do Factory, executa trabalho end-to-end quando as especificações estão completas. Mas ele opera dentro de todas essas camadas. Não é um agente solto. É um agente governado.

A lição central é uma que muitas organizações ainda resistem em aceitar: governança que depende de atenção humana no ponto de execução falha na velocidade dos agentes. Quando agentes produzem código em horas, revisão humana sequencial se torna o gargalo — não apenas de velocidade, mas de governança. Porque o revisor cansado na sexta-feira à noite é o elo mais fraco da cadeia de controle.

A solução não é mais revisores. É codificar a revisão na infraestrutura.

Você não precisa ir tão longe quanto “nenhum humano escreve código” para adotar esses padrões. Cenários como especificação, ambientes de teste isolados, catálogos de modelos publicados, contexto auditável, identidade de agentes — cada um desses componentes pode ser adotado incrementalmente, dentro da realidade da sua organização.

O que não pode é ser ignorado. Porque a alternativa — IA operando sem governança codificada — é exatamente o que produz os incidentes de shadow AI que o Gartner projeta, as violações de propósito que a Kiteworks documenta, e os riscos operacionais que mantêm CTOs acordados de madrugada.

A empresa mais radical em IA construiu o framework de governança mais disciplinado. Isso não é coincidência. É causa e consequência.

Fontes

StrongDM Factory. “Principles,” “Techniques,” “Products” e “Weather Report.” factory.strongdm.ai, 2025-2026.
Nicholas Carlini. “Building a C compiler with Claude.” Blog de Pesquisa da Anthropic, fevereiro de 2026.
Gartner. “Predicts 2026: 40% das empresas enfrentarão incidentes de segurança com shadow AI.” 2025.
Kiteworks. “Previsão 2026: 63% das organizações não conseguem impor limitações de propósito da IA.” 2026.

O Grupo Victorino ajuda organizações a construir a camada de governança operacional que torna a IA autônoma sustentável. Se você está projetando operações de IA ou precisa de ajuda para implementar mecanismos de supervisão que funcionam na velocidade das máquinas, entre em contato.