IA e qualidade

IA em código: o que sabemos sobre bugs e carga de controle de qualidade

A adoção da IA para programação está avançando, mas os números de mais bugs provêm principalmente de percepções e não demonstram causalidade. O que as pesquisas realmente mostram e como medir isso em equipe.

4 de novembro de 2026 9 min de leitura

A adoção é alta, mas as métricas são importantes

A pesquisa Stack Overflow de 2025 descobriu que 84% dos entrevistados usaram ou planejaram usar ferramentas de IA em seu processo de desenvolvimento; Entre os desenvolvedores profissionais, 51% relataram usá-los diariamente. A questão abrange ferramentas de IA em geral: não prova que essa percentagem gera código, nem descreve especificamente as equipas de QA.

Para olhar para o outro lado do fluxo, a DeviQA publicou sua própria pesquisa em julho de 2026 com 300 profissionais de controle de qualidade, SDET e líderes de testes. 52% disseram que perceberam um aumento nos bugs desde que o desenvolvimento começou usando IA e 58% perceberam mais carga de testes. É um sinal relevante a investigar, não uma estimativa representativa do sector: é uma amostra interna de fornecedores, baseada em respostas e experiências auto-relatadas.

A pesquisa da DeviQA pergunta sobre as mudanças que os participantes associam temporariamente à adoção da IA; não compara repositórios equivalentes com e sem IA, nem controla o tamanho das alterações, a experiência, a velocidade de entrega ou a política de revisão. Também pode influenciar que mais defeitos sejam agora detectados ou relatados. Portanto, não é apropriado concluir que a IA, por si só, causa um aumento geral de bugs.

DORA 2025 propõe ler a IA como um amplificador do sistema de trabalho existente: feedback rápido, plataformas internas e prioridades claras ajudam; Processos fracos e mudanças difíceis de revisar também são amplificados. A pesquisa relata associações, não uma regra causal universal. A mensagem prática é medir todo o fluxo e não atribuir variação a uma única ferramenta.

O que medir antes de mudar o processo

Registre, ao longo de várias iterações, quantas alterações foram feitas e qual o tamanho; quantos defeitos aparecem antes e depois da publicação; sua gravidade; quantas vezes um caso é reaberto; quanto tempo leva para o controle de qualidade receber e responder; e quanto trabalho é repetido. Separe as alterações feitas com a ajuda da IA somente se a equipe puder identificá-las de forma consistente e sem monitorar cada pessoa.

Compare os períodos com cuidado: use as mesmas definições, observe as alterações nos produtos ou equipamentos e analise o que os testes detectam e quais alertas se revelam falsos. Se mais alterações forem lançadas, o número total de defeitos poderá aumentar mesmo que cada alteração tenha menos. Comparar os defeitos com o número e o tamanho das alterações ajuda a entender o que aconteceu.

Imagine que antes a equipe lançava dez alterações por semana e encontrava quatro defeitos; Depois de adicionar um assistente, ele publica vinte alterações e encontra seis. O total subiu, mas o índice passou de 0,4 para 0,3 defeitos por troca. Sem o denominador, a manchete “tem mais bugs” mistura volume de entrega com qualidade por unidade. A detecção também pode aumentar porque foram adicionados testes, registros melhores ou uma revisão mais intensa. Nesse caso, observar mais falhas pode revelar que o desempenho do sistema está melhor, e não que o produto piorou.

É conveniente separar quatro medidas: defeitos encontrados antes da publicação; defeitos que atingiram a produção; gravidade e impacto; e custo de investigá-los e corrigi-los. Encontrar mais problemas menores durante os testes não significa ter mais incidentes de usuário. Por outro lado, uma taxa estável pode esconder um risco maior se o número de alterações aumentar ou se as falhas se concentrarem em pagamentos, permissões ou dados. Decida o que você vai contar antes de comparar.

O que acrescenta a revisão do código gerado, além da execução de testes

Só porque todos os testes foram aprovados não prova, por si só, que uma mudança seja fácil de manter, respeite as regras do projeto ou tenha testes suficientes. Numa investigação de 2026, o METR pediu a quatro mantenedores de três projetos que revisassem 296 alterações preparadas por agentes e aprovadas por uma avaliação automatizada. Em média, os responsáveis aceitaram menos alterações que o avaliador: a diferença foi de 24 pontos percentuais. A amostra foi limitada e os agentes não conseguiram corrigir suas propostas após receberem comentários; O resultado deixa clara uma distinção: “os testes passaram” e “a equipe está disposta a integrar a mudança” não significam a mesma coisa.

Portanto, além de verificar se a função faz o que é esperado, verifique se a mudança afeta outras funções, como ela trata os erros, se respeita a segurança e se os novos testes realmente detectam o problema. Um teste gerado pode repetir o mesmo erro do código. Ele pede que cada teste esteja relacionado a um requisito e verifica se ele falha quando a função que deveria proteger é removida.

Durante quatro a seis semanas, registe uma linha de base com definições estáveis e selecione alterações comparáveis por tamanho, risco e componente. Se a equipe usar IA, rotule a mudança voluntariamente e no nível do trabalho, não no nível pessoal. Compare grupos ou períodos quando possível, observe mudanças simultâneas – nova cobertura, refatoração, rotatividade de equipe – e normalize por mudanças, linhas modificadas ou exposição. Não use uma única porcentagem como meta: isso pode incentivar a ocultação de defeitos ou a redução da cobertura.

Um painel útil mostra quantos defeitos aparecem, qual a sua gravidade e em que fase são detectados; quantos chegam à produção ou reabrem; quanto tempo leva para a equipe receber uma resposta; e quantos alertas automatizados uma pessoa confirma. Guarde exemplos para entender de onde vêm os problemas. Se a equipe trabalha mais rápido, mas chegam defeitos mais graves na produção ou aumenta o retrabalho, o processo não melhorou. Se você capturar mais antes de publicar e menos chegar à produção, poderá encontrar melhores problemas agora.

Uma pesquisa recente aponta aumento na carga de trabalho de QA

Uma pesquisa separada da DeviQA, publicada em setembro de 2026 e respondida por 4.000 profissionais de controle de qualidade, ajuda a descrever a outra extremidade do fluxo. 65% disseram que as funções chegam aos testes mais cedo; 64% indicaram que chegam mais funções ao mesmo tempo; 55% observaram uma cauda de QA mais longa; e 52% relataram mais ciclos de teste-correto-reteste. Estes números não devem ser confundidos com o inquérito anterior a 300 pessoas: são instrumentos, amostras e perguntas diferentes. Eles também não medem os defeitos por alteração nem provam que a IA é a causa. Eles mostram uma tensão concreta que uma equipe pode verificar: a implantação mais rápida não elimina a revisão, a regressão ou a coordenação e pode concentrar o trabalho que o controle de qualidade recebe.

A consequência prática é não atribuir mais testes cegos. Vale perguntar onde se forma a fila: espera de ambiente, requisitos incompletos, revisão tardia, dados difíceis de preparar, falhas intermitentes ou muitos alertas não reconhecidos. Cada causa requer uma resposta diferente. Se a equipe não sabe quando uma entrega chegará ou o que mudou, uma segunda ferramenta de IA pode adicionar ruído; Se você conhece a diferença, o risco e o resultado esperado, poderá priorizar melhor. Ele mede o tempo de espera separado do tempo efetivo de teste: é assim que você distingue um problema de capacidade de um problema de fluxo.

Uma contagem absoluta responde quantos defeitos foram encontrados; não indica por si só se cada mudança é pior. Suponha que uma equipe revisou dez alterações e encontrou quatro defeitos, e depois revisou vinte e encontrou seis. O total cresceu, mas a taxa de câmbio caiu. Mesmo essa taxa pode ser enganosa se as novas alterações forem maiores, afetarem componentes diferentes ou receberem mais cobertura. Use vários denominadores dependendo da decisão: alterações revisadas para carga de triagem, tamanho e risco para comparar a exposição, execuções para estabilidade e usuários ou transações para estimar o impacto. Não transforme as linhas de código em uma medida universal de qualidade: elas servem como contexto, não como um substituto para o risco funcional.

Também separa gravidade, tempo de detecção e custo. Um defeito de bloqueio detectado antes da liberação pode ser um sinal de que os testes estão funcionando; uma falha menor em produção pode ser menos séria do que uma falha de permissão, embora ambas sejam consideradas “um bug”. Registre se o problema estava nos requisitos, implementação, integração, dados ou ambiente. Esta classificação serve para corrigir o processo e não culpar o autor ou a ferramenta. Mantenha exemplos representativos e revise o que mudou entre os períodos; uma métrica sem explicação do caso pode levar a equipe a otimizar o número errado.

Como avaliar uma ferramenta com critérios para descartá-la

Antes de adicionar IA ao ciclo, defina uma pergunta que permita uma resposta negativa: por exemplo, “Os testes baseados em histórias reduzem as omissões sem aumentar o tempo de revisão?” Escolha um fluxo limitado, defina uma linha de base e defina o que conta como salto, duplicação, alerta válido e retrabalho. Compare várias iterações e alterações de risco semelhante. Se possível, alterne tarefas ou equipes; Caso contrário, observe as mudanças na cobertura, pessoal, liberação e ferramentas que poderiam explicar a diferença. Não atribua causalidade a uma comparação antes/depois se houver outras mudanças ao mesmo tempo.

Os testes controlados também precisam de uma regra de interrupção. Se a ferramenta não tiver contexto suficiente, utilizar dados reais sem autorização, modificar um ambiente não isolado ou produzir resultados que ninguém possa reproduzir, ela deverá ser interrompida e aguardar execução. A revisão humana foca nos riscos relevantes, não aceitando tudo o que o modelo gera. No fechamento, apresenta resultados juntamente com limites de amostra, falsos positivos, defeitos escapados e custo de tempo de revisão. Se os dados não apoiarem uma conclusão, esta é uma conclusão válida: o próximo passo é melhorar a medição e não declarar o sucesso.

Um alerta automático é uma observação que ainda não foi classificada. Pode apontar para um novo defeito, uma regressão conhecida, uma diferença visual não impactante, um problema ambiental ou um teste que não representa mais o comportamento esperado. Se o painel adicionar tudo como “bugs”, a ferramenta parecerá encontrar mais problemas, mesmo que a maioria deles sejam duplicatas ou ruídos. Mantém status distintos para encontrar recebido, revisado, reproduzível, confirmado, duplicado e descartado; Também registra o motivo do descarte. Dessa forma, a equipe pode medir a precisão e o custo da triagem sem ocultar um sinal válido abaixo da média.

A análise também deve olhar para o tempo. Uma falha detectada em minutos não tem o mesmo custo que um relatório que aparece no final de uma suíte noturna; Um alerta correto que ninguém vê até depois da liberação também não melhora a prevenção. Observe quanto tempo levou para o sistema reportar, quando alguém o revisou e quando foi fechado. Se o número bruto de alertas aumentar, mas a porcentagem confirmada cair e o tempo de revisão aumentar, o próximo experimento deverá melhorar a seleção e o contexto, e não gerar ainda mais casos. Se a detecção precoce de defeitos relevantes aumentar e o retrabalho subsequente diminuir, há um sinal mais forte de utilidade.