Como a equipe de IA da StrongDM cria software sério sem sequer olhar o código

Como a equipe de IA da StrongDM cria software sério sem sequer olhar o código

7 de fevereiro de 2026

Na semana passada, sugeri uma demonstração que vi de uma equipe implementando o que Dan Shapiro chamou de nível Dark Factory de adoção de IA, onde nenhum ser humano sequer olha para o código que os agentes de codificação estão produzindo. Essa equipe fazia parte do StrongDM e acaba de compartilhar a primeira descrição pública de como estão trabalhando nas Fábricas de Software e no Momento Agente:

Nós construímos um Fábrica de software: desenvolvimento não interativo onde especificações + cenários orientam agentes que escrevem código, executam chicotes e convergem sem revisão humana. (…)

Na forma kōan ou mantra:

• Por que estou fazendo isso? (implícito: o modelo deveria estar fazendo isso)

Na forma de regra:

• Código não deve ser escrito por humanos
• Código não deve ser revisado por humanos

Finalmente, de forma prática:

• Se você não gastou pelo menos US$ 1.000 em tokens hoje por engenheiro humano, sua fábrica de software tem espaço para melhorias

Acho que o mais interessante deles, sem dúvida, é “Código não deve ser revisado por humanos”. Como isso poderia possivelmente ser uma estratégia sensata quando todos sabemos o quão propensos os LLMs são a cometer erros desumanos?

Vi muitos desenvolvedores reconhecerem recentemente o ponto de inflexão de novembro de 2025, onde Claude Opus 4.5 e GPT 5.2 pareciam virar a esquina sobre a confiabilidade com que um agente de codificação poderia seguir instruções e assumir tarefas de codificação complexas. A equipe de IA da StrongDM foi fundada em julho de 2025 com base em um ponto de inflexão anterior relacionado ao Claude Sonnet 3.5:

O catalisador foi uma transição observada no final de 2024: com a segunda revisão do Claude 3.5 (outubro de 2024), os fluxos de trabalho de codificação agente de longo horizonte começaram a aumentar a correção em vez de erros.

Em dezembro de 2024, o desempenho de codificação de longo horizonte do modelo era inconfundível por meio do modo YOLO do Cursor.

A nova equipe começou com a regra “nenhum software codificado manualmente” – radical para julho de 2025, mas algo que vejo um número significativo de desenvolvedores experientes começar a adotar a partir de janeiro de 2026.

Eles rapidamente se depararam com o problema óbvio: se você não está escrevendo nada à mão, como garantir que o código realmente funcione? Fazer com que os agentes escrevam testes só ajuda se eles não trapacearem e assert true.

Esta parece ser a questão mais importante no desenvolvimento de software no momento: como você pode provar que o software que você está produzindo funciona se tanto a implementação quanto os testes estão sendo escritos para você por agentes de codificação?

A resposta do StrongDM foi inspirada nos testes de cenário (Cem Kaner, 2003). Como StrongDM descreve:

Nós reaproveitamos a palavra cenário para representar uma “história de usuário” de ponta a ponta, muitas vezes armazenada fora da base de código (semelhante a um “holdout” definido no treinamento de modelo), que pode ser compreendida intuitivamente e validada de forma flexível por um LLM.

Como grande parte do software que desenvolvemos tem um componente de agência, fizemos a transição de definições booleanas de sucesso (“o conjunto de testes é verde”) para uma definição probabilística e empírica. Usamos o termo satisfação para quantificar esta validação: de todas as trajetórias observadas em todos os cenários, que fração delas provavelmente satisfaz o usuário?

Essa ideia de tratar cenários como conjuntos de validação – usados ​​para avaliar o software, mas não armazenados onde os agentes de codificação possam vê-los – é fascinante. Ele imita testes agressivos realizados por uma equipe externa de controle de qualidade – uma forma cara, mas altamente eficaz de garantir a qualidade do software tradicional.

O que nos leva ao conceito da StrongDM de um Universo Gêmeo Digital– a parte da demonstração que vi que me causou a impressão mais forte.

O software que eles estavam construindo ajudava a gerenciar as permissões dos usuários em um conjunto de serviços conectados. Isso por si só já era notável: software de segurança é a última coisa que você esperaria que fosse criado usando código LLM não revisado!

(O Digital Twin Universe é) clones comportamentais dos serviços de terceiros dos quais nosso software depende. Construímos gêmeos de Okta, Jira, Slack, Google Docs, Google Drive e Google Sheets, replicando suas APIs, casos extremos e comportamentos observáveis.

Com o DTU, podemos validar volumes e taxas que excedem em muito os limites de produção. Podemos testar modos de falha que seriam perigosos ou impossíveis em serviços ativos. Podemos executar milhares de cenários por hora sem atingir limites de taxa, acionar detecção de abuso ou acumular custos de API.

Como você clona as partes importantes do Okta, Jira, Slack e muito mais? Com agentes de codificação!

Pelo que entendi, o truque era efetivamente despejar toda a documentação pública da API de um desses serviços em seu agente e fazer com que ele construísse uma imitação dessa API, como um binário Go independente. Eles poderiam então fazer com que ele construísse uma interface de usuário simplificada para ajudar a completar a simulação.

Com seus próprios clones independentes desses serviços – livres de limites de taxa ou cotas de uso – seu exército de testadores simulados poderia ir embora. selvagem. Seus testes de cenário tornaram-se scripts para os agentes executarem constantemente nos novos sistemas à medida que eram construídos.

Esta captura de tela do gêmeo Slack também ajuda a ilustrar como funciona o processo de teste, mostrando um fluxo de usuários simulados do Okta que estão prestes a precisar de acesso a diferentes sistemas simulados.

Essa capacidade de criar rapidamente um clone útil de um subconjunto do Slack ajuda a demonstrar o quão perturbadora essa nova geração de ferramentas de agente de codificação pode ser:

Criar um clone de alta fidelidade de um aplicativo SaaS significativo sempre foi possível, mas nunca foi economicamente viável. Gerações de engenheiros podem ter desejado uma réplica completa na memória de seu CRM para testar, mas autocensurou a proposta de construí-lo.

A página de técnicas também vale a pena dar uma olhada. Além do Digital Twin Universe, eles introduzem termos como Transfusão de genes por fazer com que os agentes extraiam padrões de sistemas existentes e os reutilizem em outro lugar, Semportos para portar código diretamente de uma linguagem para outra e Resumos da Pirâmide por fornecer vários níveis de resumo, de modo que um agente possa enumerar os mais curtos rapidamente e ampliar informações mais detalhadas conforme necessário.

A StrongDM AI também lançou alguns softwares – de uma maneira apropriadamente não convencional.

github.com/strongdm/attractor é Atratoro agente de codificação não interativo no centro de sua fábrica de software. Exceto que o repositório em si não contém nenhum código – apenas três arquivos markdown que descrevem as especificações do software em detalhes meticulosos e uma nota no README de que você deve inserir essas especificações no agente de codificação de sua escolha!

github.com/strongdm/cxdb é uma versão mais tradicional, com 16.000 linhas de Rust, 9.500 de Go e 6.700 de TypeScript. Este é o seu “AI Context Store” – um sistema para armazenar históricos de conversas e resultados de ferramentas em um DAG imutável.

É semelhante ao mecanismo de registro SQLite da minha ferramenta LLM, mas muito mais sofisticado. Talvez eu tenha que fazer uma transfusão genética de algumas ideias desta!

Um vislumbre do futuro?

Visitei a equipe StrongDM AI em outubro como parte de um pequeno grupo de convidados.

A equipe de três pessoas composta por Justin McCarthy, Jay Taylor e Navan Chauhan foi formada apenas três meses antes e já tinha demonstrações funcionais de seu equipamento de agente de codificação, seus clones do Digital Twin Universe de meia dúzia de serviços e um enxame de agentes de teste simulados executando cenários. E isso foi antes dos lançamentos do Opus 4.5/GPT 5.2, que tornaram a codificação de agente significativamente mais confiável um mês após essas demonstrações.

Parecia um vislumbre de um futuro potencial do desenvolvimento de software, onde os engenheiros de software passam da construção do código para a construção e depois semimonitoram os sistemas que constroem o código. A Fábrica Negra.