Estudo em sombra com IA: treine o diagnóstico que o código gerado não faz por você

Quando alguém propõe comparar o próprio diagnóstico com o de uma inteligência artificial, a reação mais comum é: se a IA gera código mais rápido do que eu, treinar assim é perda de tempo. A objeção está certa sobre uma parte e errada sobre outra. Para produzir código, a IA é mais rápida, e ninguém precisa treinar para digitar mais depressa do que ela. Só que produzir código não é o gargalo de um teste instável. O gargalo é o diagnóstico: dada uma falha intermitente, qual é a causa? Essa pergunta exige olhar log, tempo, estado e ordem de execução, e gerar um cy.wait(2000) é barato justamente porque ele não responde a ela.

Gerar é barato e verificar é caro. Quanto mais código a IA produz, mais decisões de revisão caem no seu colo, e a habilidade que não some é julgar se uma correção ataca a causa ou apenas esconde o sintoma. É esse julgamento que o estudo em sombra treina, e o caso mais claro para enxergar isso é o teste instável, o chamado flaky test.

Um teste instável é um problema de confiança antes de ser um problema técnico. Quando o time aprende que o vermelho às vezes mente, passa a ignorar o vermelho, e uma falha real passa despercebida. Em automação de interface a queixa é comum: manter os testes costuma custar mais do que escrevê-los, e esperas mal colocadas e seletores frágeis aparecem em toda conversa sobre o assunto. Não cito percentuais porque não quero repetir número que não verifiquei; descrevo o padrão que quem trabalha com automação reconhece.

O falso verde

O risco concreto é o falso verde. Uma correção errada, mas plausível, é pior do que uma falha, porque a falha avisa e a correção errada deixa o teste passando sem ter consertado nada. Veja um teste em Cypress que abre uma lista carregada por uma requisição e clica no primeiro item:

it("abre o primeiro artigo", () => {
  cy.visit("/blog");
  cy.get("[data-cy=post-item]").first().click();
  cy.url().should("include", "/blog/");
});

Ele depende de a API responder antes do clique. A sugestão mais comum, de humano ou de IA, é colocar uma espera fixa:

cy.visit("/blog");
cy.wait(2000); // tempo fixo: esconde o sintoma
cy.get("[data-cy=post-item]").first().click();

Isso passa na sua máquina e falha no CI, com mais carga, porque o tempo fixo não tem relação com o evento que o teste realmente aguarda. A causa raiz é que o teste espera um intervalo de relógio e não uma condição. A correção que ataca a causa sincroniza no evento:

it("abre o primeiro artigo", () => {
  cy.intercept("GET", "/api/posts*").as("posts");
  cy.visit("/blog");
  cy.wait("@posts"); // espera o evento real
  cy.get("[data-cy=post-item]").should("have.length.greaterThan", 0);
  cy.get("[data-cy=post-item]").first().click();
  cy.url().should("include", "/blog/");
});

Repare no que o diagnóstico exigiu: saber que o Cypress repete asserções até passarem, que um cy.wait de tempo não é asserção e que a fonte do atraso era a rede. Um modelo pode acertar isso ou propor a primeira versão, que tem aparência de correta, e quem não treinou o diagnóstico não consegue distinguir as duas.

Para chegar a esse diagnóstico com rapidez, ajuda classificar a falha antes de agir. Quatro famílias cobrem a maior parte das instabilidades em testes de interface:

• Sincronização: elemento não encontrado ou não clicável, e o teste passa ao repetir. A pergunta é em que evento ele deveria esperar.
• Dados e ordem: o teste passa isolado e falha na suíte inteira. A pergunta é se ele depende do estado deixado por outro teste.
• Ambiente: passa local e falha no CI. A pergunta é o que difere, como CPU, relógio, rede, fuso ou dados.
• Seletor: quebra depois de uma mudança de tela que não mudou o comportamento. A pergunta é se o seletor descreve intenção ou estrutura.

Classificar a falha numa dessas famílias reduz o espaço de busca e dá nome ao erro, e nomear o erro é o que permite medir a evolução, que é onde o método entra.

Como funciona o estudo em sombra

A ideia é um experimento controlado de uma pessoa só, com a IA como comparação cega: você diagnostica primeiro, ela diagnostica em paralelo sem ver a sua conclusão, e depois os dois resultados são confrontados. O começo do passo a passo é este:

1. Escolha um teste realmente instável, com o log da falha e o que mudou entre uma execução verde e uma vermelha.
2. Escreva a sua hipótese antes de qualquer ajuda, em quatro campos: família, causa provável, evidência e correção proposta. Se você não consegue escrever a evidência, o que tem é palpite.
3. Dê à IA o mesmo material, sem a sua hipótese, e peça o diagnóstico no mesmo formato.

Para o terceiro passo, um prompt simples basta:

Segue o log de uma falha intermitente, o código do teste e o diff entre a execução verde e a vermelha.
Responda em quatro campos:
1. Família (sincronização, dados e ordem, ambiente ou seletor)
2. Causa provável
3. Evidência, no material enviado, que sustenta a causa
4. Correção proposta e por que ela ataca a causa

Com os dois diagnósticos em mãos, o restante do processo é este:

4. Compare campo a campo e anote onde houve concordância e divergência. A divergência é o ponto de aprendizado.
5. Peça à IA que critique a sua hipótese (que evidência você ignorou, que alternativa não descartou) e depois faça o inverso com a hipótese dela.
6. Verifique na execução: aplique a correção e rode o teste dezenas de vezes, não uma.
7. Registre o resultado no placar.

O sexto passo é o que impede o método de virar debate de opiniões e evita aceitar uma explicação só porque está bem escrita. Em Cypress, uma forma direta de repetir o teste é gerar várias cópias dele, de preferência em um ambiente sob carga, como o CI, que aumenta a chance de expor a condição de corrida:

Cypress._.times(30, (i) => {
  it(`abre o primeiro artigo (${i + 1})`, () => {
    cy.intercept("GET", "/api/posts*").as("posts");
    cy.visit("/blog");
    cy.wait("@posts");
    cy.get("[data-cy=post-item]").first().click();
    cy.url().should("include", "/blog/");
  });
});

O placar transforma acertos e erros em dado. Uma tabela simples basta, com as colunas caso, família que você apontou, família que a IA apontou, família real, quem acertou a causa e se a correção se manteve estável depois das execuções. Depois de algumas semanas, leia por coluna: a sua taxa de acerto da família mostra se o condicionamento funciona, a família em que você mais erra mostra o que estudar, e os erros da IA mostram em que tipo de falha desconfiar mais dela. Esses números são seus, de um conjunto pequeno de casos, e não uma estatística de mercado.

Sobra responder à objeção do começo com algo além de opinião. O custo é pequeno e limitado, porque cada caso cabe em poucos minutos de escrita mais a conversa com a IA. O retorno se acumula, já que você trabalha com a IA todos os dias e cada diagnóstico bem feito melhora a forma como descreve o problema a ela e como revisa a saída dela. E o método protege contra o falso verde, cujo custo (um teste que mente, uma falha real mascarada) supera o tempo gasto no treino. Ele não substitui a IA: você continua usando para gerar, e o treino calibra o juízo que decide o que fazer com o que ela gerou.

Esse princípio tem um paralelo no software embarcado em aeronaves. A norma DO-178C, reconhecida por autoridades como FAA, EASA e Transport Canada, trata a verificação como atividade própria, com revisão de requisitos e casos de teste, rastreabilidade entre requisito, teste e resultado e cobertura estrutural até MC/DC nos níveis mais críticos, e um de seus pilares é a independência: quem verifica não é quem produziu, para não herdar o mesmo ponto cego. O estudo em sombra empresta essa ideia em escala pessoal, com a IA como segunda leitura independente e a execução repetida como evidência objetiva. É um paralelo de princípio: não estou dizendo que equipes de aviação usam este método com este nome.

Vale declarar os limites. O método é uma proposta, sem estudo controlado que comprove ganho, e o seu único validador é o seu placar. A IA pode errar com confiança, por isso a verificação por execução é obrigatória. E logs podem conter dados sensíveis, tokens ou informações de cliente, que não devem ir para o modelo. Para começar esta semana, pegue os três testes mais instáveis do seu projeto, escreva a hipótese de cada um antes de abrir qualquer ferramenta e só então compare.