Desenvolvemos 10 vezes mais rápido. Estamos também acelerando os erros?

Nos últimos meses consolidou-se uma linha de pensamento em torno do desenvolvimento de software assistido por IA, e ela aponta na direção certa. O termo Loop Engineering surgiu da prática (Boris Cherny, criador do Claude Code, e Peter Steinberger o colocaram no mapa, e Andrew Ng depois o sistematizou em seus três loops para construir produtos de 0 a 1) e substitui o paradigma inicial do surgimento da GenAI, o de "um prompt, uma resposta", por ciclos em que o agente planeja, implementa, testa, avalia e tenta de novo. Liu Shangqi, da Thoughtworks, articulou o Spec-Driven Development: a qualidade do software já não depende apenas do código, mas da qualidade das especificações que o agente recebe. E Sunit Parekh, também da Thoughtworks, propôs os cinco blocos da engenharia AI-native (Agent, Model, Methodology, Spec e Context): a ideia de que improvisar prompts já não basta; é preciso orquestrar todo o ambiente em que o agente trabalha.

Tudo isso aponta na direção certa. Mas para mim ainda falta algo, e vale a pena olhar mais de perto esses cinco blocos, porque na minha humilde opinião são o mapa mais completo que existe hoje: Agent é quem executa, Model é com que capacidade se desenvolve, Methodology é sob qual processo, Spec é o que se pede ao agente, e Context é com que conhecimento prévio posso criar mais rápido o novo conhecimento, aplicação, modelo ou o que quer que eu esteja construindo. Os cinco governam os inputs e a execução. Nenhum governa o output como conhecimento: nenhum pergunta se o que o agente produziu está correto em termos do domínio de conhecimento em que se está desenvolvendo, ou dos subdomínios que esse desenvolvimento envolve.

Depois de vários meses desenvolvendo modelos híbridos de machine learning, IA e software guiados ou acelerados por agentes para diferentes setores (saúde, engenharia, mineração) com agentes como Claude Code e Codex, entre outros, junto com a colaboração dos seus ambientes tradicionais, e levando em conta que cada um tem seu campo em que é melhor que os outros, estou convencido de que há peças do quebra-cabeça nesta nova forma de criar conhecimento e valor que estão nos escapando e que nem todos estão vendo.

Quase toda a conversa está orientada a acelerar a geração de software, ou mesmo de conhecimento. Mas muito pouco a validar o conhecimento que os agentes produzem, a validade do seu raciocínio, o julgamento que assume os critérios éticos e científicos.

Os erros caros são cada vez menos de programação

Na minha experiência, os erros que mais custam já não são bugs. São mais sutis, e portanto mais perigosos, porque dependem de conhecimento real e profundo; nos últimos meses vi que, usando Spec-Driven Development, aparecem problemas sutis e difíceis de enxergar:

Interpretações incorretas do objetivo do problema, ou uma compreensão equivocada do problema.
Aplicação de métodos matemáticos ou estatísticos inadequados ou errados.
Premissas implícitas que nunca foram solicitadas.
Compreensão parcial do contexto do domínio.
Soluções tecnicamente impecáveis… para um problema diferente do que queríamos resolver.
Afirmações persistentes às quais os modelos se agarram até que se prove o contrário.

Em machine learning e IA isso acontece com uma frequência surpreendente, e com uma sutileza que só se distingue quando se aprendeu a partir da base matemática dos problemas, ou porque o conhecimento especializado sugere que algo está errado.

Um agente pode implementar corretamente um algoritmo e, ao mesmo tempo, otimizar a métrica errada, introduzir data leakage, interpretar mal uma análise de feature importance, propor um esquema de validação metodologicamente incorreto ou assumir uma restrição que nunca existiu. O código compila, os testes passam, e no entanto a conclusão (científica, clínica, de negócio) pode estar errada. E quem a revisa? Quem a audita?

Nenhuma suíte de testes captura isso. Os testes verificam que o código faz o que diz que faz. Não verificam que o que ele diz que faz é a coisa certa.

Os agentes não fazem o que você pede, com uma frequência que costuma passar despercebida

Há um fenômeno que observo repetidamente, e que está na raiz de quase todos esses erros.

Os agentes não fazem o que você pediu. Fazem o que entenderam que você pediu.

A diferença parece sutil, mas em projetos complexos pode mudar o resultado por completo. O código pode ser impecável e ainda assim responder a outra interpretação da intenção original. E como o artefato que você recebe (o código, o gráfico, o número) parece pronto, a lacuna entre o que foi pedido e o que foi entendido fica oculta até que alguém com conhecimento do domínio a detecte. Às vezes muito depois.

Esse é exatamente o ponto cego que os cinco blocos anteciparam. Spec melhora a qualidade do que entra. Context melhora a qualidade do conhecimento prévio. Methodology e Loop Engineering melhoram a qualidade do processo. Todos trabalham sobre os inputs e a execução. Nenhum valida o output como conhecimento: se o raciocínio está correto, se o método é o adequado, se as premissas são admissíveis, se o problema resolvido é o problema real.

O próximo passo: um Expert Validation Loop

Por isso acredito que o próximo avanço não consiste apenas em melhorar os agentes. Consiste em incorporar um Expert Validation Loop: um ciclo explícito em que especialistas do domínio (cientistas, engenheiros, médicos, estatísticos, arquitetos ou especialistas de negócio) revisam não apenas o código, mas o raciocínio, as premissas, as decisões metodológicas e a compreensão do contexto, antes de aprovar um resultado. Em termos simples, o conhecimento formal aprendido nas universidades, aquele que constrói pensamento crítico, raciocínio abstrato e intuição, começa a importar mais do que antes. Porque o conhecimento mais geral já está ao alcance de quase todos, mas o outro não.

Não é um code review com outro nome. É uma camada diferente, com perguntas diferentes:

O objetivo que o agente otimizou é o objetivo real, ou um próximo que se parece com ele?
O método estatístico é adequado à estrutura destes dados, ou apenas a dados bem comportados?
Quais premissas foram introduzidas sem serem pedidas, e continuam válidas?
A conclusão resiste ao julgamento de alguém que conhece o domínio, ou apenas ao critério de que "o código roda"?

O especialista não substitui o agente. Ele fecha o loop que o agente não consegue fechar sozinho, porque um modelo não sabe o que não sabe sobre o domínio. Na prática, o Expert Validation Loop transforma o especialista de "revisor final ocasional" em parte estrutural do ciclo de desenvolvimento, tão estrutural quanto os testes, e pelas mesmas razões: porque o que não se valida explicitamente, se assume.

E no entanto: software melhor não é mais valor

Aqui vale a pena subir um nível. Toda a conversa (Spec-Driven Development, Context Engineering, Loop Engineering, até este Expert Validation Loop) se concentra em produzir inteligência de maior qualidade por meio de agentes, e a uma velocidade várias vezes maior do que a que nos acostumamos nos últimos anos. Mas produzir software melhor, ou mais rápido, não garante por si só produzir mais valor para uma organização.

Da perspectiva que venho desenvolvendo na AI Value Realization Theory (AVRT), a IA não cria valor diretamente: gera potencial de inteligência. O valor aparece apenas quando essa inteligência é convertida em decisões melhores, essas decisões em ações melhores e essas ações em resultados mensuráveis. É precisamente nessa conversão que muitas iniciativas de IA têm sucesso técnico e fracassam na criação de valor, e, além disso, poderiam produzir problemas que até agora a maturidade do desenvolvimento tecnológico já havia superado.

E aqui as duas ideias se encontram. Se o valor nasce de converter inteligência em decisões, então converter inteligência incorreta mais rápido não é progresso: é risco acelerado. Um pipeline que gera modelos dez vezes mais rápido, sem uma camada que valide que esses modelos respondem à pergunta certa, não acelera a criação de valor: acelera a propagação de conclusões erradas para decisões reais. O Expert Validation Loop é, na linguagem do AVRT, o portão que garante que a inteligência que entra na cadeia de conversão está correta antes de se tornar ação.

As peças se encaixam assim:

Spec-Driven Development (Liu Shangqi) melhora a qualidade das especificações.
Context Engineering melhora a qualidade do contexto.
Loop Engineering (Ng, sobre Cherny e Steinberger) melhora a qualidade da iteração.
Os cinco blocos AI-native (Sunit Parekh) orquestram o ambiente de execução.
Expert Validation Loop melhora a qualidade do conhecimento gerado.
AI Value Realization Theory (AVRT) explica como toda essa inteligência se converte, ou não, em decisões, ações e valor.

A hipótese

A IA reduziu drasticamente o custo de construir. O que antes levava semanas ou meses agora leva horas. Quando construir deixa de ser o gargalo, o gargalo passa a ser outra coisa: a velocidade com que uma organização consegue validar o que construiu e aprender com isso. Isso reorganiza muito do que tomávamos como certo, dos ciclos Agile à cadência dos OKRs, e é um tema que merece sua própria discussão. Porque agora desenvolver em Agile, ou trabalhar com OKRs, em assuntos que exigem desenvolvimento de software já não é mais caro; fechar em ciclos curtos se torna cada vez mais real, mas exige um duplo clique.

Talvez o maior impacto da IA não seja escrever software mais rápido. Talvez seja acelerar a capacidade de uma organização de aprender, decidir melhor e converter esse aprendizado em valor, e isso exige, antes da velocidade, uma forma explícita de validar que o que foi aprendido é verdadeiro.

Essa, pelo menos, é uma hipótese que acredito valer a pena explorar.

Referências

Liu, Shangqi (2025). Spec-driven development. Thoughtworks, 10 de dezembro de 2025.
Parekh, Sunit (2026). Beyond vibe coding: The five building blocks of AI-native engineering. Thoughtworks Insights, 18 de março de 2026.
Ng, Andrew (2026). Loop Engineering — three loops for building 0-to-1 products. LinkedIn. Ng atribui a origem do termo a Boris Cherny (criador do Claude Code) e Peter Steinberger.
Barrientos, Claudio (2026). AI Value Realization Theory (AVRT). Série no LinkedIn.