Quando os Testes de IA Passam e os Humanos Não: Três Falhas de Verificação, Um Padrão

Daniel sentou para testar um site de marketing que tinha tirado 100% nas verificações automatizadas de acessibilidade. Em dez minutos, o site falhou com ele de formas que nenhum scanner conseguiria enxergar.

O site foi construído com Lovable, uma ferramenta de IA que se vende como produtora de output acessível por padrão. Hampus Sethfors, da Axess Lab, rodou o Axe, o verificador automatizado padrão da indústria. O painel mostrou pontuação perfeita. Em seguida, entregou a página para Daniel, um usuário real de leitor de tela. Daniel tentou abrir o menu e ouviu o anúncio: “toggle menu”. Nada mais. Sem estado. Sem “expandido” ou “fechado”. Ele disse a Sethfors: “Ainda diz toggle menu, não sei se funciona porque não anuncia se eu expandi alguma coisa.”

Essa é a falha de verificação número um. Três falhas com nome e sobrenome aterrissaram na mesma semana, em três formatos diferentes, com a mesma causa raiz embaixo. Cada uma vale ser entendida por si só. O padrão que elas formam vale mais ainda.

Lovable: 100% de Pontuação, Múltiplas Falhas Críticas

O teste da Axess Lab, publicado em 13 de maio de 2026, é a demonstração mais clara de um problema que a indústria vem rodeando há dois anos. Ferramentas automatizadas de acessibilidade só conseguem testar o que conseguem parsear. Verificam marcação, contraste, ordem de foco, presença de ARIA. Não conseguem verificar se um usuário de leitor de tela realmente consegue concluir uma tarefa na página.

O site do Lovable passou em todas as checagens automatizadas. Daniel, usando a tecnologia assistiva que a pontuação deveria prever, encontrou múltiplos bloqueadores críticos nos primeiros dez minutos. O botão de menu não anunciava estado. Campos de formulário careciam do contexto necessário para serem preenchidos. O carrossel era inutilizável sem navegação visual.

O diagnóstico não é que a IA do Lovable é ruim em acessibilidade. O diagnóstico é que “100% acessível” nunca foi uma propriedade que a IA pudesse entregar. Era uma propriedade de um julgamento humano que alguém substituiu por uma métrica. A pontuação é o contrato que a equipe achou que estava assinando. A experiência do usuário é o contrato que ela realmente assinou.

Bun: 6.755 Commits, Zero Revisores Humanos

Seis dias. 6.755 commits. Zero revisores humanos.

Esse é o número que Jiacai Liu extraiu do log de commits do repositório do Bun entre 8 e 14 de maio de 2026, analisando o reescrita em Rust que o projeto está conduzindo em escala industrial. O código é escrito pelo Claude. As revisões são escritas pelo Claude. As decisões de merge são tomadas pelo Claude. Nenhum humano participa do loop em commit nenhum.

Liu, que não tem relação com o Bun e analisou os dados como observador externo, resumiu a preocupação em uma frase: “Código que você não entende não deveria rodar em produção.”

A equipe do Bun presumivelmente argumentaria que a suíte de testes é a verificadora, que as métricas vão capturar regressões, que a escala de geração justifica a ausência de revisão humana. Esse argumento tem a mesma forma da pontuação de acessibilidade do Lovable. Ambos delegam julgamento humano a um sinal automatizado. Ambos assumem que o sinal captura o que importa.

O caso Lovable demonstra como essa premissa pode quebrar. Daniel não conseguiu abrir o menu, e a pontuação dizia que o site era perfeito. Se um leitor de tela expõe uma categoria de falha que o Axe não detecta, qual categoria de falha uma suíte de testes deixa passar em 6.755 commits de código Rust novo?

Ainda não sabemos. Vamos saber daqui a seis meses, quando o modo de falha chegar em produção e alguém tiver que depurar um sistema que nenhum engenheiro vivo leu por completo.

Aviator: A Verificação Funciona, Quando Você Fez a Especificação

O terceiro caso complica a história de um jeito útil. Ankit Jain, da Aviator, publicou em 17 de maio de 2026 um experimento rodando revisão baseada em especificação sobre 6.000 linhas de código gerado. A equipe extraiu 65 critérios de aceitação checáveis da especificação. Um agente revisor validou os 65 em aproximadamente seis minutos. O resultado: 60 passaram, 4 falharam, 1 parcial.

Isso é verificação que escala. Seis minutos de revisão automatizada, ancorada na especificação, substituíram o que seriam horas de revisão humana de PR. As quatro falhas foram capturadas. A parcial foi sinalizada. O trabalho seguiu adiante com a confiança que a verificação entregou.

Mas Jain escreveu a frase que deveria estar na parede de todo líder de engenharia: “Você não consegue escrever testes contra requisitos que não soube articular.”

Verificação baseada em especificação funciona apenas se alguém fez o trabalho cognitivo de escrever a especificação. Esse trabalho não pode ser delegado ao mesmo modelo que vai gerar o código. É o julgamento humano que converte intenção em afirmações checáveis. É também o trabalho que a maioria das equipes pula, porque parece lento e a IA parece rápida.

Frederick Vanbrabant modelou esse trade-off em um Gantt hipotético publicado em 15 de maio de 2026. Um projeto tradicional poderia parecer 70 dias de desenvolvimento mais 10 dias de escopo. Com IA, a fase de desenvolvimento desaba para cerca de 3 dias. O projeto total não encolhe, porque a fase de escopo e documentação expande para cerca de 40 dias. O gargalo se moveu. Não desapareceu.

O Padrão Por Trás

Três casos. Três formatos diferentes de verificação. Uma causa raiz.

O Lovable substituiu o usuário de leitor de tela pelo Axe. O Bun substituiu o revisor humano pelo Claude. A organização hipotética de Vanbrabant tentou substituir o escritor de especificação por quem quer que estivesse segurando o prompt no momento. Em todos os casos, uma categoria de julgamento humano foi delegada a um sistema que não conseguia sustentar essa responsabilidade.

A tese da dívida de verificação (coberta antes em A Dívida de Verificação e em O Imposto de Verificação da IA) tratava o problema como falha de medição: desenvolvedores não confiam no output da IA e não verificam sistematicamente, então código não revisado se acumula. Esses três casos estendem o diagnóstico. O problema não é só que a verificação é pulada. O problema é que a verificação está sendo feita contra um proxy que a equipe confundiu com a coisa real.

Uma pontuação de 100% em acessibilidade é proxy para “usuários cegos conseguem usar este site”. Uma suíte de testes passando é proxy para “o código novo faz o que o código antigo fazia”. A taxa de aprovação de um agente revisor é proxy para “este código corresponde ao que realmente quisemos construir”. Cada proxy tem um domínio de validade. Nenhum captura a propriedade completa que a equipe precisa.

O experimento da Aviator é instrutivo justamente porque revela o limite. Os 60 critérios aprovados não significam que o código está correto. Significam que o código satisfaz as 65 coisas que a equipe soube perguntar. O que a equipe não articulou, a verificação não captura. O agente revisor é honesto sobre seu escopo. O trabalho de especificação da equipe é o substrato que dá sentido à pontuação.

Para Onde o Trabalho Real Se Moveu

Se você aceita o modelo de Vanbrabant (o tempo de desenvolvimento colapsa, o tempo de escopo expande), as implicações para liderança de engenharia são diretas.

O gargalo do desenvolvimento assistido por IA não é mais velocidade de digitação. É velocidade de articulação. Quão rápido sua equipe traduz “precisamos de um fluxo de checkout que funcione para usuários de leitor de tela” em uma lista de critérios de aceitação checáveis que um agente revisor consiga validar? Quão rápido você converte “a nova porta em Rust deve preservar o comportamento da implementação atual em JavaScript” em uma suíte de testes baseada em propriedades que capture os casos que seu modelo gerador não vai capturar sozinho?

Esse trabalho é humano. Não é opcional. É a superfície que determina se a verificação que você delega à IA está de fato verificando o que importa ou apenas gerando painéis verdes.

O caso Lovable nomeia o modo de falha na sua forma mais nítida. Um usuário real, com uma tecnologia assistiva real, encontrou falhas reais, em tempo real, que nenhuma checagem automatizada jamais traria à superfície. O site tinha 100% de pontuação. Daniel não conseguiu usá-lo.

Se sua superfície de verificação se parece mais com a pontuação do Axe do que com dez minutos com o Daniel, você está acumulando o tipo de dívida que chega como um ticket de suporte, uma ação judicial de acessibilidade, ou uma falha em produção que ninguém na equipe atual consegue depurar.

Faça Isto Agora

Audite os últimos 30 dias do seu output assistido por IA contra uma pergunta: para cada portão de verificação que aprovou o envio, qual era a propriedade subjacente que aquele portão representava, e quão confiante você está de que o proxy captura essa propriedade?

Se seu código gerado por IA passa numa suíte de testes, nomeie três modos de falha que a suíte não cobre. Se sua UI construída por IA passa num scanner de acessibilidade, leve-a para um usuário real de leitor de tela ainda neste mês. Se seus commits gerados por IA fazem merge automático, escreva qual classe de regressão você está disposto a colocar em produção sem revisão humana, e qual classe não está, e torne essa linha explícita na automação de merge.

Três casos numa semana não é coincidência. É a indústria aprendendo, em público, que a superfície de verificação herdada da era pré-IA foi construída para uma taxa de geração de código que não se aplica mais. A nova taxa exige uma nova superfície. As equipes construindo essa superfície agora vão capitalizar a vantagem. As equipes confiando nos painéis verdes vão capitalizar a dívida.

Fontes

Axess Lab. “Lovable’s AI Built a 100% Accessible Site, Or Did It?.” Maio de 2026.
Jiacai Liu. “My Thoughts on Bun’s Rust Rewrite.” Maio de 2026.
Engineering Leadership Newsletter. “How to Avoid AI Code Slop.” Maio de 2026.
Frederick Vanbrabant. “I Don’t Think AI Will Make Your Processes Go Faster.” Maio de 2026.

A Victorino ajuda empresas a desenhar portões de verificação que protegem usuários reais, não dashboards verdes: contato@victorino.com.br | www.victorino.com.br