- A equipe de IA da StrongDM defende o conceito de Software Factory, que cria software de alta qualidade sem sequer olhar o código
- Com base em especificações/cenários, os agentes escrevem o código, executam o harness de testes e convergem sem revisão humana em um modo de desenvolvimento não conversacional
- O código não deve ser escrito nem revisado por humanos, e é preciso gastar pelo menos US$ 1.000 por dia em tokens por engenheiro para que a software factory funcione de verdade
- Desde a segunda revisão do Claude 3.5 (outubro de 2024), os fluxos de trabalho longos de codificação por agentes passaram a acumular correção de forma composta, em vez de acumular erros, confirmando a viabilidade do desenvolvimento não conversacional
- Expandindo o conceito tradicional de testes, o time introduz cenário (scenario) e satisfação (satisfaction) para construir um sistema em que o LLM avalia probabilisticamente a satisfação do usuário
- Por meio do Digital Twin Universe (DTU), eles clonam os principais SaaS como Okta, Jira e Slack para realizar validação em larga escala, permitindo validar cenários com volume e velocidade acima dos limites de produção
- A era dos agentes muda fundamentalmente a economia do software, tornando a construção de réplicas SaaS de alta fidelidade, antes economicamente inviável, uma tarefa rotineira
Conceito de Software Factory
- Especificações (specs) e cenários (scenarios) impulsionam os agentes em um sistema de desenvolvimento não conversacional que escreve e valida código
- É proibido que humanos escrevam ou revisem código, e os agentes executam todo o processo de desenvolvimento
- A eficiência é medida com base em mais de US$ 1.000 por dia em uso de tokens por engenheiro
- Essa abordagem tem como objetivo construir um ambiente autônomo de produção de software em que o código é gerado, validado e converge automaticamente sem intervenção humana
Formação da equipe de IA da StrongDM
- Em 14 de julho de 2025, a equipe de IA da StrongDM foi formada e iniciou experimentos de desenvolvimento não conversacional
- Participantes: Jay Taylor, Navan Chauhan, Justin McCarthy (cofundador e CTO)
- No fim de 2024, após o Claude 3.5 (revisão de outubro), a precisão da escrita de código de longo prazo melhorou, tornando possível o acúmulo composto de correção (compounding correctness) em vez do acúmulo repetitivo de erros
- O modo YOLO do Cursor mostrou com clareza a capacidade do modelo para escrita de código de longo prazo
- Em modelos anteriores, ao aplicar repetidamente LLMs a tarefas de codificação, acumulavam-se todos os tipos de erros — mal-entendidos, alucinações, erros de sintaxe, violações de DRY entre versões, incompatibilidades de biblioteca — e o app “desmoronava”
- A combinação entre o modelo atualizado da Anthropic e o modo YOLO confirmou a primeira possibilidade de desenvolvimento não conversacional ou de software cultivado
Princípio central: tirar as mãos
- Na primeira hora do primeiro dia da equipe de IA, foi estabelecida uma carta de princípios, e o mais importante era: “humanos não devem escrever código diretamente”
- No início, era uma simples intuição e um experimento: até onde se consegue ir sem escrever absolutamente nenhum código à mão?
- No começo, surgiram limitações; o progresso começou depois da adição de testes
- Os agentes ficam obcecados com a tarefa imediata e escolhem atalhos: testes escritos de forma estreita podem passar com return true, mas isso não se generaliza para o software realmente desejado
- Testes simples não bastam; é preciso expandir para testes de integração, regressão, ponta a ponta e de comportamento
De testes para cenários e satisfação
- Um tema recorrente na era dos agentes: é preciso uma nova linguagem; a palavra “teste” é insuficiente e ambígua
- Testes armazenados no codebase podem ser reescritos de forma preguiçosa para se ajustar ao código, ou o código pode ser reescrito para passar nos testes de forma trivial
- O termo cenário é redefinido para representar uma história de usuário ponta a ponta, armazenada fora do codebase (semelhante a um conjunto de “holdout” no treinamento de modelos), que o LLM consegue entender intuitivamente e validar com flexibilidade
- Como o próprio software cultivado inclui componentes agentes, o critério de sucesso deixa de ser um simples valor booleano e passa para uma satisfação probabilística e empírica (satisfaction)
- Satisfação: quantifica a proporção de trajetórias observadas que passaram por todos os cenários e provavelmente satisfariam o usuário
Validação de cenários com o Digital Twin Universe
- No regime anterior, usavam-se testes de integração, regressão e automação de UI para decidir “funciona?”
- Foram descobertos dois limites das técnicas antes consideradas confiáveis:
- Os testes são rígidos demais: como o código é escrito por agentes e os loops entre LLM e agente são usados como primitiva de design, avaliar sucesso muitas vezes exige um LLM-as-judge
- Os testes são vulneráveis a reward hacking: é preciso uma validação menos suscetível a trapaças por parte do modelo
- O Digital Twin Universe (DTU) é a resposta: clones comportamentais dos serviços de terceiros dos quais o software depende
- Construção de gêmeos de Okta, Jira, Slack, Google Docs, Google Drive e Google Sheets, replicando APIs, casos de borda e comportamento observável
- Com o DTU, é possível validar com volume e velocidade muito acima dos limites de produção
- Também é possível testar modos de falha que seriam perigosos ou impossíveis em serviços ao vivo
- Dá para executar milhares de cenários por hora sem atingir rate limits, disparar detecção de abuso ou acumular custos de API
Economia não tradicional
- O sucesso com o DTU mostra uma das várias formas pelas quais o momento agentic muda fundamentalmente a economia do software
- Sempre foi possível criar clones de alta fidelidade dos principais aplicativos SaaS, mas isso era economicamente inviável
- Várias gerações de engenheiros queriam uma réplica completa em memória de um CRM para testes, mas nem chegavam a propor isso à gerência (prevendo a recusa)
- Quem constrói software factories precisa praticar uma ingenuidade deliberada (deliberate naivete): identificar e remover hábitos, convenções e restrições do Software 1.0
- Com o DTU, aquilo que era inimaginável seis meses atrás agora virou rotina
Leituras seguintes
- Principles : nossas crenças sobre desenvolvimento de software com agentes
- O software é cultivado por meio da estrutura seed → validation harness → feedback loop, e tokens funcionam como combustível
- Todo software precisa de uma seed inicial: antes podia ser um PRD ou uma especificação; hoje, algumas frases, screenshots ou um codebase existente também servem
- O validation harness deve ser ponta a ponta e o mais próximo possível do ambiente real (clientes, integrações, economia)
- Fazer feedback da amostra de saída para a entrada em um loop fechado permite autocorreção do sistema e acúmulo composto de correção
- A teoria de validação e feedback é fácil de entender, mas a prática exige engenharia criativa e de ponta: buscar formas de converter todos os obstáculos em representações que o modelo consiga entender
- Techniques : padrões recorrentes para aplicar esses princípios
- Digital Twin Universe (DTU)
- Replica o comportamento externamente observável de dependências críticas de terceiros
- Valida com volume e velocidade muito acima dos limites de produção
- Fornece condições de teste determinísticas e reproduzíveis
- Gene Transfusion
- Atribui exemplos concretos aos agentes para transferir padrões operacionais entre codebases
- Soluções acompanhadas de boas referências podem ser reproduzidas em novos contextos
- Filesystem
- Permite que o modelo navegue rapidamente pelo repositório e ajuste seu próprio contexto com leitura/escrita de arquivos
- Diretórios, índices e estado on-disk funcionam como uma base prática de memória
- Shift Work
- Separa o trabalho conversacional do trabalho totalmente especificado
- Quando a intenção está completa (especificação, testes, app existente), o agente pode executar ponta a ponta sem idas e vindas
- Semport
- Portabilidade automatizada com consciência semântica, executada uma vez ou continuamente
- Move código entre linguagens ou frameworks preservando a intenção
- Pyramid Summaries
- Resumos reversíveis em vários níveis de zoom
- Comprime contexto sem perder a capacidade de expandir novamente para todos os detalhes
- Products : ferramentas que usamos todos os dias e que acreditamos que também serão úteis para outras pessoas
- CXDB é um repositório de contexto self-hosted para agentes de IA, com Turn DAG, deduplicação de blobs, tipos dinâmicos e depuração visual
- StrongDM ID é um sistema de identidade para humanos, workloads e agentes de IA, com suporte a autenticação federada e compartilhamento com escopo por caminho
- Attractor é um agente de codificação não conversacional estruturado como grafo de fases, para execução ponta a ponta quando a tarefa está completamente especificada
3 comentários
Experimentei desenvolvimento orientado por especificações usando múltiplos agentes no desenvolvimento. É verdade que isso reduz bastante o trabalho, mas, por causa das limitações de desempenho dos LLMs, não dá para criar um produto que satisfaça o cliente. A substituição 100% é impossível, e certo nível de trabalho humano ainda é necessário.
É um texto até provocativo demais, mas dá para entender até certo ponto... é o tipo de texto que deixa a gente meio estranho.
Lendo este texto e depois o texto abaixo, dá para se identificar ainda mais.
Lamentamos o nosso espírito artesão
Comentários do Hacker News
Eu me identifico com o conceito de Digital Twin Universe
Minha base de código também tem muitas integrações com serviços externos, então, se eu bloqueasse as chamadas externas nos testes, quase não daria para validar nada
Por isso, eu criava implementações falsas de cada API, como Okta, Jira, Slack e Google Docs, para testar
Só que eu não replicava a UI, apenas imitava o comportamento da API
A frase “se você não está gastando US$ 1.000 por dia em tokens por engenheiro, ainda há espaço para melhorar” soa irrealista demais
Fico em dúvida se isso é mesmo uma afirmação séria
Fazendo as contas, isso dá cerca de US$ 250 mil por ano
Se a IA realmente entregasse essa produtividade, talvez fosse razoável
Na prática, parece mais algo no nível de dois engenheiros juniores
No fim, os humanos provavelmente ficariam no papel de liderança, cuidando só de planejamento e validação
É um otimismo exagerado, mas não chega a ser completamente absurdo
Eu só uso as assinaturas de US$ 20 por mês do Claude e da OpenAI
Quando os tokens acabam, vou caminhar ou ler um livro
Não sou aceleracionista, mas ainda assim trabalho o suficiente
Eu sou uma das pessoas do time da StrongDM
O ponto principal é que gastar US$ 1.000 por dia em tokens é fácil, mas usar isso de forma produtiva é difícil
Isso parece simples ostentação
Como se estivessem sinalizando: “estamos muito mais avançados em IA do que vocês”
Senti um certo constrangimento ao ler o texto
Deu a impressão de que estavam embalando mocks e testes de simulação já conhecidos como se fossem uma “inovação”
Ainda assim, reconheço que eles foram honestos ao expor a estrutura de custos
Eu estava procurando código ou produto de verdade no site deles
A única coisa que encontrei foi strongdm/attractor
“namorada canadense que codifica” agora virou modelo de negócio
Além disso, achei strongdm/cxdb, mas o histórico de commits parecia ter sido limpo
Há código real no repositório cxdb
Não sei se isso é loucura ou um vislumbre do futuro
Na página Products também há um banco de dados e um sistema de identidade
Para vários agentes colaborarem, contexto compartilhado e um sistema de permissões são indispensáveis
Assisti a um webinar sobre o BAML da BoundaryML
Spec-driven development é uma abordagem para criar fluxos de trabalho estruturados com humanos dentro do loop
Ela define claramente o loop
/research → /plan → /implemente faz passar por validação humana em cada etapaÉ a filosofia oposta à afirmação da StrongDM de que “humanos não escrevem nem leem código”
Isso parece mais um post vazio de blog
Não há resultado concreto, e essa conversa de US$ 1.000 por dia em tokens parece voltada a impressionar investidores
Se não resolverem o problema da validação, tudo isso não passa de pose
Mesmo com revisão automática e guardrails, no fim das contas quem vai confirmar a correspondência entre especificação e resultado é um humano
Nós, na Speedscale, estamos automatizando validação com captura e reprodução de tráfego
Na verdade, desenvolvimento humano também não é perfeito
Já existem vários procedimentos sistemáticos de validação, como code review, testes e QA
O importante não é se a IA é perfeita, mas sim se a qualidade do sistema como um todo converge
Pela minha experiência, no Opus 4.5 há um pequeno efeito líquido positivo
Eu praticamente concordo
O ponto central é validação, não geração
Estou criando uma estrutura em que vários agentes independentes expõem divergências e chegam a consenso
Em termos simples, isso equivale a empurrar a validação e os testes de segurança para o usuário final
Precisamos usar mais linguagens baseadas em especificação e verificação formal
No fim, programação será redefinida como “o ato de concretizar uma especificação”
Com US$ 1.000 por dia em tokens, você acaba gastando mais com IA do que com humanos
Isso parece um ponto de colapso da visão de IA
Disseram que Simon Willison atualizou o texto
US$ 240 mil por ano é nível de engenheiro iniciante em FANG
Sinceramente, há muito júnior pior que o Claude
No fim, isso deve se reorganizar numa estrutura em pirâmide com poucos humanos no topo
Se der para terminar o mesmo trabalho em 5 dias, então o custo em relação à velocidade pode ser razoável
Se a produção crescer proporcionalmente, a eficiência custo-benefício pode até fazer sentido
Além disso, o preço dos tokens pode cair
O setor jurídico e o de seguros devem ser os que mais sofrerão com essa mudança
Erros humanos são modeláveis, mas erros em cascata de loops autônomos são um problema completamente diferente
No fim, as decisões da IA vão recair sob responsabilidade humana
Isso provavelmente será o freio de toda a mudança agentic
US$ 1.000 por dia em tokens é uma métrica absurda
Se a qualidade do código for ruim, o consumo de tokens explode
No fim, é a base de código desorganizada que aumenta os custos
Se um time está queimando mil dólares por dia, provavelmente a eficiência é quase nula
(Referência: este meme)
É uma questão de otimização de curto vs. longo prazo
A escolha é entre aumentar a eficiência agora ou melhorar o sistema como um todo
Talvez só agora a diretoria perceba a importância do refactoring
O time do padrão Dark Factory que mencionei antes era justamente este
Escrevi um texto relacionado e esse time é o grupo de experimentadores mais ambicioso
Mas, na prática, quase não há resultados
Se você desse US$ 10 mil para alguns universitários, provavelmente fariam algo melhor
US$ 1.000 por dia em tokens é algo que o orçamento do meu time nem sonha em permitir
Pessoalmente, também é impossível por causa do custo de vida
No fim, dá a sensação de “se fizer, dá ruim; se não fizer, também dá ruim”
Sem resultados verificáveis, é só discurso
E agora até discurso ficou muito mais barato graças aos LLMs
É preciso haver divulgação ética
A terminologia do site só repagina conceitos já existentes
“Digital Twin Universe” são mocks, “Gene Transfusion” é ler código de referência, e “Semport” é transpiling
Não existe dado nem benchmark de verdade
É um caso de marketing de IA embalado como insight de engenharia
Na verdade, a maior parte do código central já está no GitHub
O verdadeiro diferencial está no desenho dos mecanismos e nos valores
O futuro vai caminhar para a combinação de métodos formais com IA
O método de “testar cenários mantendo um holdout set” é interessante
É uma forma de imitar os testes agressivos da equipe de QA
É marcante separar o time de build do time de detecção de bugs e criar uma estrutura de competição mútua
Mas US$ 1.000 por dia em tokens é desanimador para desenvolvedores open source
Dá para reduzir custos usando modelos locais
Como nesta thread, automação de agentes locais também é perfeitamente viável
Talvez um dia os agentes comecem até a subornar uns aos outros
Eu ainda prefiro um modelo com humanos dentro do loop
Sair queimando tokens sem critério é desperdício
No texto “LLMs aren’t tools”, explorei o framework mental para usar LLMs
A “fábrica de software” é o ponto final atual, mas a próxima etapa é ver o LLM como uma aplicação
Ou seja, não só automatizar workflows, mas criar um harness personalizado