Verificação Nunca Foi o Gargalo. Compreensão É, e Dá para Construir para Isso.

TV
Thiago Victorino
7 min de leitura
Verificação Nunca Foi o Gargalo. Compreensão É, e Dá para Construir para Isso.

Por dois anos a premissa de trabalho na engenharia assistida por IA foi que verificação é o imposto que se paga pela velocidade. Nós mesmos defendemos isso em A Dívida de Verificação: 96% dos desenvolvedores não confiam no output da IA, apenas 48% verificam, e a distância entre esses dois números se acumula todos os dias. Geoffrey Litt, escrevendo em julho de 2026, avança o quadro um passo. Conforme os agentes ficam melhores em checar o próprio trabalho, a restrição que de fato limita passa a ser a compreensão. Um humano ainda entende o sistema bem o suficiente para conduzi-lo?

Essa pergunta soa mais branda que um scan de segurança. Ela é a mais difícil. Verificação é cada vez mais algo que uma máquina faz sobre o próprio output: roda os testes, gera as property checks, critica o diff, produz uma obrigação de prova e a cumpre. Cada uma dessas é uma tarefa delimitada, com um passa ou falha. Compreensão não tem passa ou falha, e nenhum agente a faz por você. Ela mora na cabeça de uma pessoa, e se deteriora.

A Dívida Que Aparece no Terceiro Loop

A observação de Litt vai além de dizer que compreensão é um bônus desejável. Compreensão é o recurso que você gasta sem perceber. Você aceita o primeiro módulo construído pelo agente porque funciona e os testes estão verdes. Aceita o segundo porque o primeiro deu certo. No terceiro ou quarto loop você está aprovando mudanças em um sistema que já não segura mais na cabeça. O output continua correto. Sua capacidade de definir a direção dele acabou.

Esse é o mecanismo por trás do que chamamos de dívida cognitiva. Os primeiros loops parecem rápidos porque o agente absorve o trabalho. O custo é adiado e invisível: cada diff não lido move mais um pedaço do sistema para um território que só o agente visitou. Quando chega um requisito genuinamente novo, do tipo que exige um humano para inventar uma direção em vez de aprovar uma, o modelo mental necessário para isso já se erodiu em silêncio. Você ainda consegue verificar. Você já não consegue imaginar.

Correto porém incompreensível é um modo de falha pior que errado e óbvio, pela mesma razão que código “quase certo” é pior que código que não compila. Nada dispara um alerta. O painel de velocidade permanece verde enquanto a capacidade da equipe de definir trajetória escoa por ele.

Quatro Artefatos Que Você Pode Construir Neste Trimestre

A parte útil do texto de Litt é que ele trata compreensão como algo que se constrói em vez de uma virtude a ser pregada. Ele esboça quatro artefatos concretos, e nenhum deles exige nova capacidade de modelo. Exigem decidir que entender faz parte da definição de pronto.

Uma skill /explain-diff. Aponte para uma mudança e ela produz uma explicação ordenada para o aprendizado, não para a cronologia. O git mostra o que aconteceu em ordem de commit. Uma explicação pedagógica começa pelo conceito que o leitor precisa primeiro, depois a mudança que depende dele, depois o caso de borda que só faz sentido quando os dois anteriores já estão no lugar. O agente que escreveu o código está bem posicionado para ensiná-lo, porque retém a intenção completa que o próprio diff descarta.

Um quiz de cinco perguntas que regula a circulação. Antes de uma mudança poder ir para o merge ou para produção, o sistema gera cinco perguntas a partir dela, e um humano precisa respondê-las. O sistema faz perguntas de verdade sobre o que o código faz e por quê, e um carimbo no PR não responde a elas. O objetivo é tornar visível a perda de compreensão no momento em que ela ocorre, enquanto o contexto ainda é recuperável, em vez de no terceiro loop, quando já se foi. Pegar quem cola é secundário.

Micromundos interativos. Um ambiente pequeno e executável onde a pessoa percorre o novo comportamento com entradas reais e vê o estado mudar. Ler um diff é passivo. Operar um sistema é ativo, e engajamento ativo é como a compreensão de fato se forma. Um micromundo transforma um muro de texto em algo que dá para cutucar.

Espaços de planejamento compartilhados entre humano e agente. Compreensão construída durante a construção é mais barata que compreensão reconstruída depois. Se o plano é coautorado, um documento que humano e agente leem e escrevem antes de existir código, o humano chega à revisão já segurando a intenção. A alternativa é forense: fazer engenharia reversa de um processo de decisão a partir de um artefato que nunca o registrou, que é exatamente o problema de debugging que descrevemos para código de IA não verificado.

O Quiz É um Regulador de Velocidade, Não uma Trava

O instinto ao ler “quiz que bloqueia o merge” é ouvir um checkpoint burocrático. Essa leitura ignora o design. Uma trava cega para tudo a um custo fixo. Um quiz de compreensão não custa nada quando o humano já entende a mudança, e custa tempo real apenas quando ele não entende. É um governador num motor, aplicando resistência na proporção do quanto o humano ficou para trás do agente.

Essa propriedade importa porque faz o controle se autodimensionar. Numa mudança bem compreendida e de baixo risco, o humano responde cinco perguntas em um minuto e o loop roda a toda velocidade. Numa mudança que silenciosamente derivou para além do modelo mental de qualquer um, o quiz fica difícil, o humano desacelera, e desacelerar é exatamente a resposta correta. O sistema regula o próprio ritmo contra a única variável que os painéis nunca capturam: se uma pessoa ainda sabe o que está sendo entregue.

Compreensão É um Controle de Governança

A linhagem intelectual aqui é mais antiga que os agentes. Seymour Papert argumentou que as pessoas constroem entendimento construindo coisas, não sendo mostradas a resultados prontos. Andy Matuschak passou anos demonstrando que a leitura produz a ilusão de entendimento enquanto a evocação ativa produz o entendimento real, que é justamente o que o quiz operacionaliza. Alan Kay projetou sistemas nos quais se podia enxergar por dentro, na premissa de que uma ferramenta que você não consegue inspecionar é uma ferramenta que pensa por você em vez de pensar com você. O fio condutor é a participação. Você entende um sistema habitando-o, não supervisionando o output dele de fora.

Isso reposiciona compreensão de um hábito pessoal para um controle organizacional, que é o mesmo movimento que fizemos com verificação. Verificação virou infraestrutura quando as equipes pararam de torcer para que os indivíduos revisassem com cuidado e começaram a orçar a revisão no pipeline. Compreensão segue o mesmo caminho. Ela pode ser instrumentada: uma explicação gerada em cada diff, um quiz regulando a circulação, um espaço de planejamento que existe antes do código. Cada um é um ponto onde o sistema confere que um humano ainda está no loop como pensador em vez de apenas como aprovador.

Este é o próximo movimento depois da dívida de verificação, e ele inverte a prioridade. Uma vez que os agentes conseguem verificar a própria correção, o recurso escasso deixa de ser a confiança de que o código funciona. Passa a ser a capacidade humana de ainda mudar para onde o código vai. Uma governança que só mede correção vai reportar tudo verde enquanto essa capacidade desaparece.

Faça Isto Agora

Escolha o seu repositório de maior velocidade, aquele onde os agentes mais entregam e os humanos menos leem. Adicione um artefato: o quiz de cinco perguntas no merge. Ainda não bloqueie nada. Apenas gere as perguntas e registre se os humanos daquele repositório conseguem respondê-las. Em duas semanas você terá algo que nenhuma métrica de velocidade dá, uma leitura direta de quanto do seu próprio sistema a sua equipe ainda entende. Se as respostas estão piorando, você achou a dívida antes que ela achasse você. Depois construa a skill /explain-diff, porque a forma mais rápida de passar no quiz é ter sido bem ensinado sobre a mudança desde o início.


Fontes

A Victorino ajuda organizações de engenharia a transformar compreensão em um controle de governança, instrumentado no pipeline em vez de deixado à disciplina individual: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa