Nove meses viraram dois dias. Faltou na conta o custo de provar que está certo

Em 9 de outubro de 2026, a Cockroach Labs, empresa de bancos de dados, contou que um sistema de agentes de IA escreveu em menos de dois dias o suporte a um banco de dados que, da última vez, tinha exigido nove meses de equipe. Segundo a empresa, foi 164 vezes mais rápido e 38 vezes mais barato. No fim do mesmo texto, os mesmos autores dizem que ainda estão confirmando se esse código está correto, porque ninguém o revisou. ^{[1] afirmação da fonte original}

O caso é o suporte ao IBM Db2 na ferramenta MOLT, que a Cockroach usa para ajudar clientes a migrar dados de outros bancos para o dela. Segundo o relato, quando a empresa adicionou o Oracle à ferramenta, em 2024, o trabalho levou 9 meses e custou cerca de US$ 160 mil em horas de engenharia. O Db2, feito por agentes, levou menos de dois dias, e a conta de uso do modelo de IA foi de US$ 4.172. Uma pessoa descreveu o que queria num único pedido, e ninguém escreveu o código. ^{[1] afirmação da fonte original}

Por baixo, havia um sistema montado ao longo de meses. A equipe o desenhou como um hospital-escola: cada pedido de trabalho é um “paciente”, passa por um agente que investiga e faz um plano, outro agente, “diferente do que tratou o caso”, que só procura defeito, aprova ou rejeita o plano, só então outro escreve o código, e um último confere se a revisão aconteceu como mandam as regras antes de liberar. Os pedidos grandes são quebrados em pedaços de, no máximo, mil linhas. No caso do Db2, o pedido original virou 32 pedidos menores, gerou 27 alterações de código aceitas, e os agentes revisores devolveram trabalho 55 vezes. ^{[1] afirmação da fonte original}

Tempo

164×

Razão informada pela empresa entre o Oracle (2024, 9 meses, pessoas) e o Db2 (2026, menos de 2 dias, agentes). Quer dizer 164 vezes menos tempo, e não 164% mais rápido. É estimativa dos autores, não auditada, e as duas tarefas não são iguais: bancos de dados diferentes, anos diferentes.

Custo

38×

US$ 160 mil de horas de engenharia, estimadas, divididos pelos US$ 4.172 de uso de modelo de IA, medidos (conta nossa: 38,35). Não inclui o salário de quem montou o sistema nem o de quem revisou depois.

Quem leu o código

0 pessoas

Nas palavras dos autores, eles “não estavam revisando” o que o sistema escreveu nesse teste inicial. Agentes revisaram agentes. Depois da primeira semana, a empresa passou a exigir olhos humanos em toda alteração.

Um número de economia compara dois estados. O primeiro é o Oracle: feito por pessoas, revisado por pessoas, em produção, com o custo estimado em horas. O segundo é o Db2: feito por agentes, sem leitura humana naquele momento, com o custo medido em uso de modelo. Os autores são diretos sobre o segundo: estão “confirmando que o suporte ao Db2 está correto, já que não revisávamos o código que o hospital escreveu nesse teste inicial”. ^{[1] afirmação da fonte original}

Isso não quer dizer que o código do Db2 esteja errado. Ninguém sabe, e a empresa diz que está verificando. Quer dizer que o 38× não mostra o preço de um trabalho pronto. Mostra o preço de um trabalho escrito, com o controle de qualidade feito por outros agentes. A própria Cockroach conclui que isso não bastava: depois da primeira semana ligou o que chama de “modo de aprovação humana”, em que toda alteração passa por uma pessoa, e diz que só nesse modo podia ter certeza de que o código tinha qualidade para chegar ao cliente. ^{[1] afirmação da fonte original}

Há mais duas assimetrias na conta, e nenhuma é erro dos autores: são o que acontece quando se compara um custo medido com um estimado. O gasto dos agentes é medido ao centavo (cada etapa grava modelo, volume de texto processado, duração e custo), e o custo das pessoas é uma estimativa de horas. E os US$ 4.172 são o custo de uma tarefa dentro de um sistema que, no total, consumiu cerca de US$ 135 mil em cinco meses (conta nossa: a tarefa é 3,1% do total). Nenhum dos dois valores inclui o tempo dos dois engenheiros que construíram o sistema e das pessoas que passaram a aprovar o que ele produz. ^{[1] afirmação da fonte original}

Há ainda uma terceira diferença: os dois números não caíram juntos. O tempo caiu 164 vezes e o custo, 38 (conta nossa: 164 ÷ 38 ≈ 4,3). O tempo encolheu cerca de quatro vezes mais do que o custo, ou seja, o que mudou foi também o ritmo do gasto: pouco tempo, muito consumo por hora. É o que se espera de um sistema que troca pessoas por tempo de processamento, e vale ter na cabeça antes de multiplicar a economia por mil tarefas.

Em 1956, Armand Feigenbaum publicou na Harvard Business Review o artigo “Total Quality Control”, em que organiza o que uma fábrica gasta com qualidade em quatro blocos. ^{[3] afirmação da fonte original} Antes, a percepção corrente era que mais qualidade exige mais custo, comprando material melhor ou contratando mais gente. Feigenbaum mostrou que o custo da qualidade tem uma parte que se paga para evitar o defeito e outra que se paga porque ele aconteceu. ^{[3] afirmação da fonte original}

1. 1

   Prevenção: evitar que o defeito nasça

   Planejamento, treinamento, regras escritas. Na Cockroach: nenhum código antes de um plano revisado, pedidos quebrados em pedaços de até mil linhas, 25 arquivos de instruções com mais de 100 mil palavras e um registro de decisões da chefia que os agentes consultam antes de escalar.

2. 2

   Avaliação: procurar o defeito antes de sair

   Inspeção e conferência. Na Cockroach: o agente revisor, que lê o plano e o código para achar falha, o agente final que confere se a revisão foi feita, e, depois da primeira semana, a aprovação por uma pessoa em tudo. Os pedidos ficam de um a dois dias no sistema, e a espera, segundo os autores, é dominada pelo tempo até o revisor humano olhar.

3. 3

   Falha interna: o defeito achado antes de chegar ao cliente

   Retrabalho e desperdício. No Db2, 55 devoluções para 27 alterações aceitas (conta nossa: duas devoluções por alteração). Um pedido de uma linha, urgente, ficou 11 rodadas de revisão em dois dias. Em uma janela de revisão, três pedidos complexos (9, 9 e 7 rodadas) consumiram cerca de US$ 631 dos US$ 1.046 gastos, 60% do total.

4. 4

   Falha externa: o defeito que chega ao cliente

   Garantia, correção em campo, reputação. É a única parcela que o relato não mede e a mais cara na indústria. O que há de visível: 7 reversões em mais de um milhão de linhas (o relato não diz se alguma chegou ao cliente) e o Db2, cuja correção os autores dizem estar sendo confirmada.

O que vale em primeiros princípios é perguntar o que acontece com cada bloco quando o custo de escrever cai quase a zero. A prevenção não cai, porque escrever o plano, as regras e os papéis dos agentes é trabalho de pessoas, e a Cockroach levou cinco meses ajustando isso. A avaliação sobe, porque há muito mais para revisar por hora, e a revisão final é de gente: a equipe conta que um dia inteiro de reuniões ainda rende dez alterações aprovadas. A falha interna também sobe, porque o sistema erra rápido e em volume, e ainda inventa trabalho: quase metade dos pedidos do repositório foi aberta pelo próprio sistema. ^{[1] afirmação da fonte original}

O verbete descreve um padrão que a Cockroach reencontrou a seu modo: diante de defeitos em alta, as organizações tendem a colocar mais gente na inspeção, e como a inspeção nunca é totalmente eficaz, o custo de avaliar fica alto enquanto o de falha continuar alto. A saída que o conceito indica é investir na dose certa de prevenção. ^{[3] afirmação da fonte original} Na Cockroach, o dado que mais se parece com isso é o do plano: os planos que passam por revisão são rejeitados em menos de 10% das vezes, mas, quando são, é a revisão de maior valor do sistema, porque joga o retrabalho para o ponto mais cedo possível. Um dos exemplos é um defeito que deixaria o nome de máquina e do banco de dados de um cliente nos registros e que, segundo os autores, dificilmente seria achado na revisão do código. ^{[1] afirmação da fonte original}

A conclusão fácil é “a IA derrubou o custo de produzir”, e ela é verdadeira. As decisões que importam estão nos efeitos de segunda e de terceira ordem, os que aparecem quando as pessoas reagem ao número. Cada efeito abaixo parte de um fato do relato; o que vai além do fato é hipótese da Invisible Work e está dito assim.

Primeira ordem: a que aparece na reunião

Produzir ficou muito mais barato e muito mais rápido, e todo mundo vai querer essa economia. Projetos de software, de relatórios, de análises e de documentos passam a ser orçados pelo custo de produzir, que é a parte que o número mostra. É a leitura que cabe numa apresentação de uma página, e é verdadeira até onde vai.

Segunda ordem: o que os gestores fazem em reação ao número

1. 01

   A tentação de cortar a revisão para colher a economia.

   A economia aparece no custo de escrever, e o orçamento costuma cortar onde a revisão mora: engenheiros seniores, qualidade, jurídico, conformidade. A Cockroach fez o contrário: ligou a aprovação humana em tudo, e o que limita a velocidade passou a ser a agenda de quem aprova (um dia de reuniões rende dez aprovações, e os pedidos ficam de um a dois dias no sistema, em boa parte à espera de um revisor humano). ^{[1] afirmação da fonte original} Hipótese nossa: a capacidade de revisão passa a ser a capacidade da empresa, e deve ser planejada como se planeja a capacidade de uma fábrica, não tratada como sobra de agenda.

2. 02

   O fornecedor mais barato entrega sem mostrar quem conferiu.

   Se um fornecedor usa agentes e cobra por entrega, o custo de provar que a entrega está certa ou aparece como retrabalho do lado de quem comprou ou fica na conta de quem comprou sem perceber. É a falha externa, trocada de dono. Hipótese nossa, com um fato por trás: a própria Cockroach, que tem o sistema mais bem descrito que vimos, ainda confirmava a correção do que entregou sem revisão. Um comprador que aceita “38 vezes mais barato” sem perguntar quem conferiu paga a diferença quando o erro chegar.

3. 03

   O caso de negócio nasce inflado e o projeto parece fracassar.

   Um retorno calculado sobre o custo de escrever fecha rápido no papel. Quando a revisão, o retrabalho e a espera aparecem na conta real, o retorno encolhe e o projeto “decepciona”, quando o que falhou foi o cálculo inicial. O efeito seguinte é de credibilidade: quem patrocinou perde crédito, e o orçamento de IA sofre corte no trimestre em que o sistema estaria amadurecendo. Hipótese nossa.

4. 04

   A escassez troca de lugar: de produzir para escolher.

   O sistema da Cockroach cria o próprio trabalho: quase metade dos pedidos foi aberta por ele. O departamento de pesquisa dos agentes, que propunha novas tarefas a cada três horas, gerou tanto que a equipe não dava conta de avaliar: a frequência passou a diária e as propostas à espera de aprovação foram limitadas a dez. Os autores dizem que achar as “pepitas de ouro no rio” continua sendo a parte difícil. ^{[1] afirmação da fonte original} Hipótese nossa: quando produzir custa pouco, o recurso escasso é a decisão sobre o que admitir, e a empresa sem alguém dono dessa decisão se enche de trabalho que é bom o bastante e não é prioridade.

Terceira ordem: o que se forma, ou se perde, nos próximos anos

1. 01

   Falta quem saiba revisar, e o revisor sênior fica mais caro.

   O sistema foi construído por dois engenheiros seniores, que somam mais de 40 anos de experiência. Os autores admitem que fizeram um hospital-escola que, na prática, não ensina: o modelo rende muito a quem tem a agenda cheia e o julgamento de décadas, e, dizem, não atende bem quem está começando. ^{[1] afirmação da fonte original} Hipótese nossa: se agentes escrevem e o júnior deixa de praticar, a procura por quem sabe revisar sobe enquanto a oferta de quem aprendeu a revisar cai. Em alguns anos, a empresa compra revisão no mercado pelo preço que o mercado pedir, ou paga explicitamente para formar quem antes aprendia junto com o volume.

2. 02

   O rastro de cada etapa vira ativo, e a prova vira o que se compra.

   Cada pedido da Cockroach guarda o plano, o teste que falhou antes do conserto, cada revisão com o motivo e o custo de cada etapa. Cinco meses depois, a equipe consegue reconstruir por que qualquer das 1.238 alterações foi aceita. ^{[1] afirmação da fonte original} Hipótese nossa: quando todo fornecedor usa IA, “usa IA” deixa de diferenciar, e o que passa a valer em concorrências em que o erro custa caro (dados de clientes, saúde, finanças, setor público) é mostrar como o trabalho foi verificado. Auditores, seguradoras e clientes regulados tendem a pedir esse rastro. Quem não o tem fica de fora do contrato.

3. 03

   O 38× vira meta, e a forma mais barata de bater a meta é desligar o controle.

   Um número de economia que circula em conferências e conselhos vira régua para comparar equipes e fornecedores. O caminho mais curto para igualá-lo é fazer como o teste do Db2: rodar sem revisão humana. Hipótese nossa, sustentada por um fato: o 38× da Cockroach vem de um teste em que a revisão humana não existia. Tende a ocorrer um incidente (dados corrompidos de um cliente, um erro que vai a produção) antes de o mercado aprender que o número sem a prova não vale. É a mesma dinâmica de qualquer meta que pode ser jogada, que já tratamos em outro Insight.

O método abaixo serve para qualquer número de economia que chegue à sua mesa, de uma equipe interna ou de um fornecedor. Ele não exige entender de código: exige perguntar o que está dentro da conta. Antes das cinco decisões, há um teste de uma frase: pergunte “o que foi desligado para chegar a esse número?”. No caso da Cockroach, a resposta, dita pelos próprios autores, foi a leitura humana, e a decisão sensata foi religá-la.

1. 01

   Finanças: peça o caso de negócio em quatro linhas.

   Prevenção, avaliação, falha interna e falha externa, com o custo das pessoas que revisam. Aprove o investimento sobre o trabalho pronto e aprovado, em produção, e não sobre a primeira versão. Compare o antes e o depois na mesma régua: medido com medido, revisado com revisado.

2. 02

   Operação e tecnologia: dimensione a fila de quem confere antes da de quem produz.

   Quantas pessoas aprovam, quantas horas por semana têm livres e quantas entregas a IA gera nesse período? Defina também o limite de tentativas antes de uma pessoa assumir. Sem esse número escrito, um trabalho que não converge gasta sem fim: na Cockroach, três pedidos consumiram 60% do gasto de uma janela, e a correção foi um disjuntor (depois de quatro rodadas seguidas em que cada uma achou um novo problema, ou de seis rodadas de qualquer tipo, passa a uma pessoa).

3. 03

   Compras e jurídico: ponha a prova no contrato.

   Quem confere, com que evidência (um registro do que foi verificado), em quanto tempo corrige e quem responde pelo erro que chegar ao cliente. Se a resposta é “o cliente descobre”, o custo da qualidade não está na proposta e está sendo pago por quem recebe.

4. 04

   Pessoas: crie a trilha de quem aprende a revisar.

   Se a IA escreve, onde o profissional jovem pratica o julgamento que o sênior tem? Defina que parte das revisões ele faz, defendendo a decisão, e como isso entra na avaliação. A Cockroach, que percebeu o problema, está construindo o caminho em que a pessoa faz o plano e o sistema a questiona.

5. 05

   Conselho e diretoria: exija o rastro, não só o número.

   Peça que a apresentação de resultados traga como o trabalho foi verificado e onde está o registro. Um número de economia sem o rastro de quem conferiu é uma promessa, e promessa não entra em auditoria.

O relato é de uma empresa sobre o próprio sistema, em um projeto de software de banco de dados, e não passou por auditoria externa. Os 164× e 38× são os números dela, entre duas tarefas diferentes, e o custo de pessoas do Oracle é uma estimativa. O texto não afirma que o código do Db2 esteja errado: afirma que os autores dizem estar confirmando se está correto. Os US$ 135 mil, as 7 reversões e as demais contagens são autodeclarados. O relato não mede falha externa, e o que dizemos sobre ela é hipótese. A divisão em quatro blocos de custo é de Feigenbaum para fábricas, lida por verbete de enciclopédia, e a aplicação a agentes de IA é nossa. Os efeitos de segunda e de terceira ordem da Parte 4 são previsões da Invisible Work a partir de fatos do relato, nenhuma observada em empresa. Um leitor da discussão no Hacker News comentou que o relato quase não trata da qualidade e da manutenção do código no longo prazo, o que é coerente com o que o texto da Cockroach não mede. ^{[2] afirmação da fonte original} Não há dado brasileiro neste texto.

Seis perguntas para quem aprova orçamento de IA, patrocina um projeto ou presta contas por ele.