A adoção de IA generativa no desenvolvimento de software trouxe uma promessa poderosa: escrever código mais rápido, reduzir esforço operacional e acelerar entregas.

Em parte, essa promessa está se cumprindo.

Mas um estudo recente da Harness, o The State of Engineering Excellence Report 2026, traz um alerta importante para líderes de tecnologia, engenharia, produto e qualidade:

A IA pode estar aumentando o volume de código gerado, mas também está criando uma “nova camada” de trabalho invisível para os times de desenvolvimento.

E esse trabalho nem sempre aparece nos dashboards tradicionais de produtividade.

O novo trabalho invisível criado pela IA

Segundo o relatório da Harness, 31% do dia de um desenvolvedor já pode estar sendo consumido por atividades relacionadas à IA, como revisar código gerado por ferramentas, corrigir bugs sutis, alternar contexto entre ferramentas e validar se o resultado realmente atende ao que o negócio precisa.

Esse é um ponto essencial.

Quando falamos de IA no desenvolvimento, muita gente olha apenas para a velocidade de geração do código. Mas gerar código não é o mesmo que entregar software funcionando, seguro, sustentável e aderente à regra de negócio.

O desenvolvedor deixa de ser apenas autor do código e passa a atuar cada vez mais como:

• • revisor de código gerado por máquina;
  • validador de lógica e regra de negócio;
  • responsável por explicar decisões que nem sempre foram escritas manualmente por ele;
  • guardião da qualidade, segurança e manutenção futura daquela implementação.

Ou seja, parte do esforço saiu da digitação do código e foi transferida para a validação.

Mais código não significa, necessariamente, mais produtividade…

Um dos dados mais relevantes do estudo é que 81% dos líderes de engenharia afirmam que o tempo de code review aumentou após a adoção de ferramentas de IA.

Isso mostra uma contradição importante.

A IA pode acelerar a criação inicial, mas também pode aumentar o esforço posterior de revisão, debug e correção. Se a empresa mede apenas volume de código, quantidade de pull requests, commits ou velocidade aparente do ciclo, ela pode estar olhando só para a produtividade bruta.

Mas o que realmente importa é a produtividade líquida.

A pergunta não deveria ser apenas:

“Estamos gerando mais código?”

A pergunta deveria ser:

“Estamos entregando mais valor com menos retrabalho, menos risco e mais qualidade?”

Essa diferença muda completamente a conversa.

Quando o estudo mediu junto aos líderes de engenharia qual era o maior desafio na criação de uma experiência positiva para desenvolvedores com ferramentas de IA, as principais respostas foram problemas de visibilidade:

• • Medir o impacto real na produtividade (26%)
  • Manter a qualidade do código com IA (24%)
  • Comprovar o ROI para a liderança (18%)

O risco das métricas tradicionais

Frameworks como DORA, cycle time, lead time e métricas de fluxo continuam importantes. Eles ajudam a entender velocidade, frequência de entrega, estabilidade e eficiência do processo.

Mas o estudo da Harness aponta que essas métricas, sozinhas, podem não capturar bem a realidade dos fluxos com IA.

Principalmente quando deixam de fora fatores como:

• • tempo gasto validando código gerado por IA;
  • retrabalho após sugestões incorretas da IA;
  • bugs sutis introduzidos por automação;
  • dívida técnica criada por soluções aparentemente prontas;
  • dificuldade de explicar código gerado (principalmente durante alinhamentos e refinamentos);
  • impacto na carga cognitiva dos profissionais;
  • riscos de segurança e compliance;
  • burnout e sobrecarga mental.

O relatório também indica que 94% dos entrevistados concordam que dívida técnica, tempo de validação e burnout ficam fora das métricas atuais.

Esse dado é extremamente relevante porque revela um ponto sensível: muitas empresas estão tentando medir produtividade com IA usando modelos que foram criados antes dessa nova dinâmica de trabalho.

O perigo de medir a coisa errada

Existe um risco real de algumas organizações caírem em uma armadilha: medir produtividade por volume.

Volume de código. Volume de commits. Volume de PRs. Volume de sugestões aceitas. Volume de tokens consumidos.

Mas volume não é valor.

Um time pode gerar mais código e, ao mesmo tempo, aumentar a dívida técnica. Pode fechar mais tarefas e, ao mesmo tempo, criar mais bugs. Pode parecer mais rápido e, ao mesmo tempo, transferir esforço para QA, sustentação, segurança ou produção.

Quando a métrica incentiva apenas velocidade e volume, o comportamento do time tende a se adaptar a isso.

E aí o ganho da IA pode virar uma ilusão operacional.

O papel da qualidade, do negócio e do produto nesse novo cenário

Esse debate reforça algo que profissionais de qualidade, engenharia e produto já conhecem bem:

Não existe produtividade sustentável sem qualidade.

Com IA, isso fica ainda mais crítico.

Se a especificação for ruim, a IA pode gerar código errado com muita velocidade. Se os critérios de aceite forem vagos, a IA pode implementar algo tecnicamente funcional, mas desalinhado com o negócio. Se não houver revisão adequada, bugs sutis podem passar despercebidos. Se não houver governança, o time pode ganhar velocidade hoje e criar complexidade para amanhã.

Mas existe um ponto adicional importante: a IA também já está sendo usada para criar histórias de usuário, critérios de aceite, cenários de teste, regras de negócio, documentação funcional e até sugestões de DoR e DoD.

E isso é extremamente útil, mas…

Aqui aparece o mesmo alerta do estudo da Harness aplicado ao desenvolvimento: o trabalho não desaparece, ele muda de lugar.

No caso de negócio, produto e qualidade, esse custo invisível pode aparecer na revisão da especificação gerada, na validação da regra de negócio, na identificação de ambiguidades, na correção de critérios mal formulados, na priorização de riscos e na confirmação de que o que foi escrito pela IA realmente representa a intenção do produto.

E acredite, mesmo testando as várias ferramentas de mercado que se propõe a isto, observamos este aumento de carga cognitiva na prática.

Ou seja, a IA pode gerar uma história bem escrita do ponto de vista textual, mas isso não significa que ela esteja correta do ponto de vista de negócio, ou que não precise simplesmente de diversos ajustes.

Ela pode sugerir critérios de aceite bem estruturados, mas isso não garante que todos os cenários críticos foram considerados.

Ela pode gerar cenários de teste em Gherkin, mas isso não significa que cobriu os riscos mais importantes da jornada.

Ela pode produzir documentação aparentemente completa, mas ainda assim deixar lacunas, assumir regras inexistentes ou simplificar decisões que dependem de contexto humano.

Esse é o ponto central: artefato bonito não é sinônimo de entendimento correto do valor e risco.

Quando usamos IA para apoiar etapas de negócio e qualidade, o trabalho humano passa a ser menos sobre “começar do zero” e mais sobre revisar, validar, questionar, complementar e tomar decisões.

Isso também gera carga cognitiva.

O profissional precisa avaliar se a IA entendeu corretamente o problema, se não inventou regras, se não omitiu exceções importantes, se não tratou como simples algo que é crítico, se não criou critérios genéricos demais e se os cenários realmente representam o comportamento esperado do sistema.

Portanto, assim como acontece com o código, também precisamos medir e governar o uso da IA nas etapas anteriores do ciclo de desenvolvimento.

Não basta perguntar:

“A IA gerou a história mais rápido?”

A pergunta deveria ser:

“A história gerada pela IA reduziu ambiguidade, melhorou o entendimento, diminuiu retrabalho e ajudou o time a entregar mais valor com menos risco?”

Por isso, IA no desenvolvimento precisa vir acompanhada de práticas que envolvam engenharia, qualidade, produto e negócio, como:

• • histórias bem estruturadas, mesmo que apoiadas por IA;
  • critérios de aceite gerados com IA, mas validados por pessoas que entendem o produto;
  • cenários de teste sugeridos por IA, mas revisados com base em risco, criticidade e jornada do usuário;
  • revisão humana qualificada sobre regras de negócio e exceções;
  • automação de testes conectada aos fluxos mais relevantes;
  • validações de segurança, compliance e impacto operacional;
  • rastreabilidade entre requisito, código, teste e evidência;
  • definição clara de DoR e DoD;
  • governança sobre o uso de IA na criação de artefatos;
  • métricas que olhem para valor entregue, clareza, retrabalho evitado e risco reduzido, não apenas para velocidade de geração.

A IA pode ser uma grande aliada na qualidade.

Mas ela ainda não substitui totalmente o entendimento do negócio, a análise crítica, a priorização baseada em risco e a responsabilidade sobre o produto final.

Na prática, o desafio não é apenas usar IA para escrever mais rápido.

É usar IA para pensar melhor, decidir melhor e entregar melhor.

O que deveríamos começar a medir?

Se a IA muda a forma como o software é produzido, também precisamos evoluir a forma como medimos produtividade.

Atualmente ao realizarmos um Assessment em grandes empresas de software do mercado, podemos perceber principalmente o seguinte como necessidade:

Algumas métricas antes ignoradas passam a ser cada vez mais importantes:

• • tempo gasto revisando código gerado por IA;
  • percentual de sugestões aceitas sem alteração;
  • percentual de código gerado que precisou de retrabalho;
  • bugs encontrados em código assistido por IA vs desenvolvimento humano;
  • defeitos escapados para produção;
  • tempo de explicação e entendimento do código (comuns na fase de refinamento técnico);
  • aumento ou redução do tempo de code review;
  • impacto na cobertura de testes;
  • impacto na dívida técnica;
  • incidentes relacionados a mudanças geradas com apoio de IA;
  • Precisão dos Agentes ou das ferramentas;
  • percepção de carga cognitiva do time.

Essas métricas ajudam a sair da visão simplista de produtividade e aproximam a análise da realidade.

IA não elimina responsabilidade. Ela muda onde a responsabilidade aparece.

A grande reflexão é esta:

A IA pode escrever parte ou todo o código, mas a responsabilidade pela entrega, riscos assumidos e garantia de valor continua sendo humana e organizacional.

• • Alguém precisa garantir que aquilo atende à regra de negócio.
  • Alguém precisa validar segurança.
  • Alguém precisa avaliar impacto em produção.
  • Alguém precisa entender o que foi feito e explicar para os demais.
  • Alguém precisa sustentar aquela solução depois de implementada (além dos impactos causados).

Por isso, a conversa sobre IA em engenharia de software não pode ficar restrita à pergunta “quanto tempo economizamos escrevendo código?”.

A conversa precisa evoluir para:

“Como garantimos que a IA está aumentando a entrega de valor sem aumentar risco, retrabalho e sobrecarga invisível?”

Conclusão

Este artigo ficou um pouco extenso, mas o que o estudo da Harness nos traz, não é um argumento contra o uso de IA no desenvolvimento de software.

Pelo contrário.

Ele mostra que a IA veio para ficar e já está transformando profundamente a rotina dos times de engenharia.

Mas também deixa claro que precisamos amadurecer a forma como medimos, governamos e integramos essas ferramentas ao ciclo de desenvolvimento.

Wellington Charles Sota

Especialista em Qualidade de Software | QA Architect | QA Lead |Processos de Qualidade |IA aplicada ao SDLC | COE de Qualidade na Keeggo

Fonte principal: Harness — The State of Engineering Excellence Report 2026.

Link para o relatório: https://www.harness.io/state-of-engineering-excellence