Quando a IA Constrói na Velocidade do Pensamento, Quem Decide o Que Vai Para Produção?

Zach Wills, diretor sênior de engenharia na Luxury Presence, publicou um relato no início de fevereiro de 2026 que merece atenção não pelo entusiasmo — mas pelo que os números revelam quando lidos com cuidado.

Ele opera cerca de 60 agentes autônomos de IA. Esses agentes lidam com tudo, de correção de bugs a desenvolvimento de funcionalidades. Em uma noite, geraram 77 pull requests sem intervenção humana. O ritmo diário estabilizou entre 15 e 20 PRs.

É um número impressionante. Mas o número seguinte é mais importante: 33% de tudo que esses agentes produzem é rejeitado.

Um terço. Descartado. Não é nota de rodapé — é a história.

A Promessa Que Funciona (Até Certo Ponto)

O gap entre ideia e implementação colapsou. Isso é real. Wills descreve uma inversão econômica: a pergunta não é mais “vale a pena construir isso?” mas “vale a pena não construir?”

Quando execução custa quase nada, toda ideia se torna viável. E quando toda ideia é viável, o problema muda de natureza. Não é mais escassez de capacidade. É excesso de possibilidade.

A StrongDM — referenciada por Simon Willison em análise publicada na mesma semana — levou esse modelo ao extremo. Adotaram o que chamam de “Dark Factory”: código não deve ser escrito por humanos e não deve ser revisado por humanos. O custo: cerca de mil dólares por dia em tokens por engenheiro.

Willison, que é um defensor vocal dessas ferramentas, parou para observar o que esse número significa. Mil dólares diários não é custo de ferramenta — é custo de infraestrutura. É uma nova linha no orçamento que não existia seis meses atrás.

O Gargalo Que Ninguém Planejou

Wills identifica algo que poucos estão discutindo: a velocidade é recursiva. Execução mais rápida gera mais ideias. Mais ideias geram mais execução. O ciclo se retroalimenta — e os gargalos migram.

Primeiro, o gargalo era escrever código. Os agentes resolveram isso.

Depois, o gargalo virou orquestrar agentes. Ferramentas melhores resolvem isso parcialmente.

Agora, o gargalo é revisar e julgar o que foi produzido. E isso não é problema de ferramenta — é problema de pessoas e processos.

Nolan Lawson, engenheiro da Microsoft, publicou na mesma semana um ensaio que captura a natureza desse gargalo com uma metáfora desconfortável: programadores estão se tornando “agentes da TSA glorificados” — checando o output de uma máquina, repetidamente, sem contexto suficiente para entender o que realmente estão aprovando.

A metáfora incomoda porque é precisa. Quando um agente produz 20 PRs por dia e o engenheiro precisa revisar cada um, a qualidade da revisão cai. Fadiga cognitiva não é fraqueza — é consequência previsível de volume sem estrutura.

A Estrutura de Custos Oculta

Os mil dólares por dia da StrongDM parecem caros até você calcular o que substituem. Um engenheiro sênior no Vale do Silício custa bem mais que isso em salário, benefícios e overhead. A matemática aparente favorece os agentes.

Mas a conta real é diferente.

O custo visível — tokens, infraestrutura, ferramentas — é a parte menor. O custo invisível é o que acontece com o output. Quem revisa? Quem decide se aquele PR de madrugada resolve o problema certo do jeito certo? Quem mantém a coerência arquitetural quando 60 agentes trabalham em paralelo sem memória compartilhada do sistema?

Cada PR rejeitado não é apenas desperdício de tokens. É tempo de engenheiro gasto avaliando algo que não deveria ter sido gerado. A 33% de rejeição, um terço do esforço de revisão — que é agora o recurso mais escasso — é consumido para dizer “não”.

O Problema de Pessoas Vestindo Roupas de Tecnologia

Wills faz uma observação que, pela sua simplicidade, corre o risco de ser ignorada: isso é um problema de pessoas vestindo roupas de tecnologia.

A tentação é tratar a taxa de rejeição como um problema técnico. Modelos melhores, prompts mais precisos, contexto mais rico — e a rejeição cai. Talvez. Mas mesmo que caia pela metade, de 33% para 15%, o problema estrutural permanece: quem decide?

Stanford publicou na mesma semana um paper com um título que condensa a questão: “Built by Agents, Tested by Agents, Trusted by Whom?”

Construído por agentes. Testado por agentes. Em quem confiamos?

A pergunta não é retórica. É operacional. Se o agente escreveu o código, outro agente testou, e a revisão humana é superficial porque o volume é alto demais — onde está o ponto de responsabilidade? Quando o sistema falha em produção, quem assina embaixo?

Nas organizações que acompanho, essa pergunta raramente tem resposta clara. E a ausência de resposta não é neutra. É risco acumulado.

A Economia do Julgamento

Wills articula uma inversão que tem implicações profundas para como organizamos equipes de engenharia: julgamento sobre execução se torna a habilidade primária.

Historicamente, valorizamos engenheiros pela capacidade de executar — escrever código limpo, rápido, funcional. Quando execução é delegada a agentes, o diferencial migra para a capacidade de avaliar, decidir e direcionar.

Isso tem consequências concretas:

Para contratação: A entrevista técnica tradicional — “resolva esse problema no quadro branco em 45 minutos” — avalia a habilidade errada. A pergunta deveria ser: “aqui está o código que um agente gerou para resolver este problema. O que está errado? O que está faltando? O que você faria diferente?”

Para desenvolvimento de equipe: Engenheiros juniores precisam de exposição a arquitetura e design de sistemas, não apenas a sintaxe. A competência de revisar exige repertório — e repertório se constrói com experiência em construir, não apenas em ler.

Para estrutura organizacional: O papel de “tech lead” ou “arquiteto” ganha relevância que vinha perdendo na era dos squads ágeis. Alguém precisa manter a visão sistêmica quando 60 agentes constroem em paralelo.

O Gap Que Importa

A questão real não é “podemos construir mais rápido?”. Claramente, podemos. Wills provou. A StrongDM provou. Dezenas de equipes estão provando diariamente.

A questão é: podemos governar o que é construído?

Governança aqui não é burocracia. Não é comitê de aprovação nem processo de 47 etapas. É resposta clara para três perguntas:

Quem decide o que merece ser construído? — Quando execução é quase gratuita, o filtro de priorização se torna mais importante, não menos.
Quem avalia se o que foi construído resolve o problema certo? — Testes automatizados verificam se o código funciona. Não verificam se resolve o problema correto.
Quem responde quando o sistema falha? — Responsabilidade difusa é responsabilidade inexistente. Se “o agente fez”, quem corrige?

Essas são perguntas organizacionais, não tecnológicas. E a maioria das empresas que adotam agentes de IA para desenvolvimento não tem resposta para nenhuma delas.

O Que Isso Significa Para Sua Organização

Se você lidera tecnologia em uma empresa brasileira — ou em qualquer empresa que está adotando agentes autônomos — três realidades:

Primeira: velocidade sem governança é apenas caos caro. Os dados de Wills são claros: produzir mais rápido sem capacidade de avaliar mais rápido cria acúmulo de output não verificado. É dívida técnica gerada na velocidade da IA.

Segunda: o gargalo é humano, e vai piorar. À medida que agentes ficam mais capazes, o volume de output cresce. Mas a capacidade humana de revisar não escala no mesmo ritmo. Você precisa de processos que filtrem antes de chegar ao revisor — critérios claros, gates automatizados, padrões de aceitação definidos.

Terceira: julgamento é a nova habilidade crítica. Não “prompting” — isso é tático. Julgamento: a capacidade de olhar para um resultado e determinar se resolve o problema certo, da maneira certa, com os trade-offs aceitáveis. Isso exige senioridade, contexto de negócio e visão sistêmica.

A velocidade do pensamento é real. Os 60 agentes de Wills, os 77 PRs noturnos, a Dark Factory da StrongDM — tudo isso funciona. A pergunta que cada líder precisa responder não é se vai adotar essa capacidade, mas se tem a estrutura organizacional para governá-la.

Sem essa estrutura, você não tem velocidade. Tem uma fábrica de problemas que funciona 24 horas por dia.

Fontes

Zach Wills. “Building at the Speed of Thought.” Fevereiro 2026.
Simon Willison. Análise sobre StrongDM e “Dark Factory”. simonwillison.net, fevereiro 2026.
Nolan Lawson. “We Mourn Our Craft.” Fevereiro 2026.
Stanford Law School. “Built by Agents, Tested by Agents, Trusted by Whom?” Fevereiro 2026.

O Grupo Victorino ajuda organizações a construir a camada de governança que transforma velocidade autônoma de IA em resultados de negócio confiáveis. Se sua equipe está escalando agentes de IA e precisa da infraestrutura de revisão para fazer isso funcionar, entre em contato: contato@victorino.com.br ou visite www.victorino.com.br.