Qualidade de software na era em que a IA escreve o código

A inteligência artificial já faz parte do dia a dia de times de engenharia. Ela acelera onboarding, apoia revisões, sugere soluções para problemas recorrentes e reduz o tempo gasto em tarefas repetitivas. 

Times que adotaram ferramentas de geração de código relatam aumentos de até 30% no volume de pull requests. 

A Stripe, por exemplo, já tem mais de 1.300 PRs por semana gerados sem uma linha de código humano, revisados por pessoas, mas produzidos por IA. 

O problema é que velocidade sem controle cria risco. A mesma IA que entrega mais código também pode entregar mais erro. 

Este artigo discute como manter qualidade de software quando a IA faz parte do processo de desenvolvimento e por que isso exige mais engenharia, não menos.

O aumento de produtividade com IA é fato, mas ele também aumenta o risco

A IA já está gerando ganhos concretos de produtividade em times de tecnologia e transformando profundamente a forma como software é concebido, desenvolvido, testado e mantido. 

Ela acelera o onboarding, apoia desenvolvedores em tarefas do dia a dia, ajuda na revisão e compreensão de código, sugere soluções para problemas recorrentes e reduz o tempo gasto em atividades repetitivas. 

Mais do que uma ferramenta de apoio, a IA começa a redefinir o papel da engenharia de software, deslocando parte do esforço operacional para que os times possam dedicar mais energia a decisões de arquitetura, qualidade, produto e impacto no negócio. 

Mas os dados ainda são mistos. Laura Tacho, ex-CTO da DX, empresa americana focada em developer experience, observa que alguns times reportam mais incidentes após a adoção de IA, enquanto outros reportam menos. 

O ponto central é que ninguém está imune a incidentes relacionados a código gerado com apoio de IA. Depois de alguns casos severos, a Amazon passou a exigir que todo código gerado por IA seja revisado por um engenheiro sênior.

Sem os controles adequados, a adoção de IA pode aumentar a taxa de falhas, introduzir vulnerabilidades e reduzir a visibilidade sobre a qualidade do que está sendo entregue. Por isso, a discussão sobre qualidade de software se torna ainda mais importante no mundo da IA.

Para líderes de tecnologia, a pergunta relevante não é apenas “onde estamos hoje?”, mas “onde queremos estar à medida que escalamos o uso de IA?”.

Se até organizações com engenharia madura precisam recalibrar seus controles, nenhum time deveria expandir o uso de IA sem guardrails claros. A produtividade importa, mas ela precisa caminhar junto com revisão, segurança, qualidade e responsabilidade técnica.

Guardrails de qualidade de software

Adotar IA sem definir guardrails é como aumentar a velocidade de uma linha de produção sem revisar o controle de qualidade. 

O volume cresce, os erros também. As seções a seguir detalham os pontos de atenção mais críticos, de revisão de código a segurança, e o que times maduros estão fazendo para manter qualidade sem abrir mão da velocidade.

Qualidade de código continua sendo problema de engenharia

Uma provocação comum, em especial logo quando os primeiros agentes de código surgiram com modelos ainda longe de ter a qualidade do Opus e do GPT 5.4, era dizer que a inteligência artificial escreve “código feio” e por isso não podíamos confiar no código que ela escrevia. 

Em 2026, com os modelos e harness atuais, a resposta pra isso é inequívoca: não, IA não escreve código pior por natureza. Ou, no mínimo, não pior do que o código que humanos sempre escreveram. 

Quando a IA produz código feio, isso está geralmente mais associado a falta de contexto do que ao modelo em si. Sem saber quais são as melhores práticas, decisões de design e de organização de código que o time segue, ela pode eventualmente tomar decisões que parecem sub-ótimas. Com a informação correta, ela raramente erra. 

De maneira geral, os dois principais problemas do ponto de vista de qualidade de código que vejo ela cometer com alguma frequência é a duplicação de código. 

É difícil para a IA ter todo o contexto do seu código, particularmente em grandes bases de código e saber que tem código que poderia ser reutilizado na tarefa atual. 

Aqui a solução é ajudar ela apontando para métodos e classes que ela pode reutilizar na tarefa. Dar instruções explícitas para ela dentro do seu arquivo de agentes ou skills é também muito eficaz quando você tem conjuntos de classes que são reutilizadas com frequência.

A IA também pode tender a escrever métodos mais longos do que gostaríamos. Métodos longos nem sempre são um problema, mas se você tem restrições mais rígidas em relação a isso, deixe isso bem claro na sua instrução. 

Em compensação, muitas vezes conhece melhor os frameworks e evita algumas gambiarras justamente por conhecer funcionalidades que você ou o seu time talvez não use com frequência. 

Eu perdi as contas de quantas vezes fui surpreendido positivamente com alguma solução muito mais esperta do que eu tinha em mente.

No fim, a responsabilidade sobre a qualidade do código continua sendo humana. É o time que precisa garantir a qualidade de código gerado, não o agente. 

E essa garantia continua contextual: alguns sistemas e alguns trechos de código exigem muito mais cuidado do que outros. 

O dia em que o dev não precisará ler mais código e a máquina conseguirá escrever código fácil de ser mantido por conta própria chegará. Mas esse dia ainda não é hoje. Legibilidade, modularidade e reuso continuam essenciais para lidar com incidentes, segurança e evolução do sistema.

Revisão de código precisa mudar de forma, mas não desaparecer

Revisão de código sempre funcionou como guardrail manual para encontrar erros na funcionalidade implementada, melhorar testes, e compartilhar conhecimento. 

Esse papel ainda não desapareceu por completo, mas o gargalo fica muito mais evidente com a IA. Quando a produção de diffs aumenta, revisar tudo da mesma forma deixa de ser viável. É simplesmente muito código pra revisar.

Por isso, faz sentido tratar revisão de código de maneira mais priorizada. A pergunta deixa de ser "todo diff precisa do mesmo tipo de review?" e passa a ser "quando revisão humana é realmente necessária?". 

Em mudanças de baixo risco, talvez só a revisão feita pela própria IA seja suficiente. Em mudanças de risco maior, você provavelmente ainda quer combinar não só a revisão de uma AI mas também a de um humano.

Outro ponto importante é deixar bem claro que a garantia da qualidade da mudança é 100% do autor e não do revisor. 

É frustrante revisar um PR feito por AI e encontrar muitos erros. Como revisor, isso significa exigir provas de que o código foi realmente testado antes de ir pra revisão. 

Por fim, a IA ainda não escreve código perfeito o tempo todo, mas ela aprende muito rápido. Seu trabalho é também garantir que toda má decisão de código que a IA tomou vire informação para que ela não erre novamente.

Testes automatizados ficam mais baratos, mas não ficam automaticamente melhores

Se antes já quase não havia desculpas para não escrever testes automatizados, agora com IA, não existe desculpa alguma. A IA reduz bastante o custo de se escrever testes. 

Mas só baixar o custo não resolve o principal problema: IA é muito boa em escrever testes que passam sem realmente testar algo importante.

Alguns problemas recorrentes que aparecem com frequência em testes: excesso de mocks, testes que verificam implementação em vez de comportamento, e testes repetidos. 

Você deve deixar bem claro para a IA quais são os critérios de um bom teste. Muitas vezes eu até digo pra ela quais casos de teste testar, para garantir que ela sabe o que está fazendo. Também é importante deixar bem claro para ela quais testes o agente deve rodar antes de dar uma funcionalidade como finalizada.

Ter testes de diferentes níveis é também essencial. Só teste de unidade não vai ser suficiente. Precisamos de sinais mais fortes de que a mudança realmente funciona.

Análise estática entrando de vez no loop do agente

Outra consequência prática da adoção de IA é o reposicionamento da análise estática. Aqui entram ferramentas como linters, type checkers, e null checkers. Dev nenhum gosta de corrigir erro de análise estática que quebrou o seu build. 

Mas elas são baratas e rodam local e de alto retorno. Você deve colocar essas ferramentas dentro do loop do agente: a ferramenta roda, a IA corrige, e o ciclo só termina quando não houver mais erro. 

Isso transforma análise estática em um mecanismo de contenção automática de problemas mais mecânicos, e uma maneira determinística de garantir que a IA produz código que atende aos seus critérios de qualidade. 

Um ponto de atenção é o mesmo que já conhecemos do uso de análise estática: regras em excesso podem gerar ruído e atrapalhar mais do que ajudar. Por isso, o ajuste fino precisa ser cuidadoso, equilibrando cobertura, relevância e impacto no fluxo de trabalho.

O arquiteto de software continua existindo

A chegada da IA não elimina o trabalho de engenharia de software. Desenhar sistemas de maneira com que eles escalem e sejam robustas ainda é tarefa do humano. 

Afinal, a IA ainda não tem acesso a todo um conjunto de informações que arquitetos usam para tomar decisões, por exemplo, frequência de acesso ao cache, padrões de acesso aos seus micro-serviços, e até acordos comerciais com provedores de cloud e terceiros.

Apesar da IA ainda não decidir de maneira autônoma qual a melhor arquitetura para o seu sistema, ela é ótima para discutir padrões arquiteturais, listar prós e contras, explicitar trade-offs e sugerir caminhos de implementação. Isso é muito útil.

A IA vai chegar lá. Precisamos começar a documentar melhor a arquitetura para que a IA consiga começar a entendê-la melhor. Quanto mais informação disponível para ela, melhor.

Observabilidade, rollout parcial e rollback são prioridade

Se vamos colocar mais mudança em produção, precisamos detectar mais rápido quando algo quebrar. Observabilidade deixa de ser detalhe de maturidade e passa a ser prioridade máxima. Isso inclui alertas bem calibrados e sinais confiáveis sobre o estado real da aplicação.

Duas capacidades operacionais ficam ainda mais relevantes: rollout parcial e rollback automatizado. Feature flags e deploy granular ajudam a reduzir o impacto de código quebrado. Rollback automatizado reduz o tempo de reação quando alertas disparam. 

Quanto mais conseguirmos dar acesso a nossa stack de observabilidade para a IA, mais chegamos perto do momento onde a IA também vai nos ajudar com monitoração e resolução de incidentes.

Segurança fica mais difícil porque a superfície de ataque aumenta

Quanto mais código, mais problema de segurança. Sempre foi assim. E não é raro ver IA sugerindo práticas inseguras, como SQL injection, cross-site scripting, credenciais hard-coded, dependências alucinadas e valores padrões inseguros. 

Esse risco aumenta ainda mais quando o código foi produzido por alguém sem bagagem técnica suficiente para identificar esses problemas. 

Por isso, o uso de ferramentas de segurança, SAST, DAST, pentests e outras, dentro e fora da sua integração contínua, é mais importante do que nunca.

UX e UI ganham peso

Se escrever código fica mais fácil, o diferencial deixa de estar apenas na capacidade de produzir implementação. UX (user experience) ou a qualidade da experiência que um produto oferece para quem o usa passa a fazer ainda mais diferença. 

O difícil já não é escrever a função, é ter bom gosto para construir algo que as pessoas queiram usar.

Times que querem escalar com qualidade precisam formar desenvolvedores com mais repertório de UX e UI, além de criar práticas claras sobre como especialistas de UX e devs trabalham juntos. A IA tende a aumentar o valor de quem sabe o que construir, não só de quem sabe construir.

O futuro da engenharia de software agêntica

Tenho certeza de que a maioria das limitações que eu mencionei neste artigo desaparecerão por completo ou mudarão de forma. Mas já conseguimos prever algumas coisas:

• O primeiro é o agente, que hoje está basicamente no repositório local de código para buscar informações, indo para o ambiente de produção para capturar sinais e eventualmente ajudar na resolução de incidentes. 
• O segundo é que agentes de código vão começar a escrever código sem mesmo que você peça. Eles vão observar sinais do seu sistema, por exemplo, uma exceção aparecendo no seu sistema de monitoramento, e vão automaticamente abrir um PR para corrigi-lo.
• O terceiro é o surgimento de agentes e skills cada vez mais complexos e sistemáticos, capazes de resolver problemas que sempre foram difíceis e manuais. Tarefas que sempre demandaram tempo e energia, como debugar testes flaky, serão totalmente feitas por agentes.

Ainda assim, mesmo assim, o futuro da engenharia de software não tende à eliminação por completo. Pelo contrário, esse futuro exigirá mais método, mais contexto, mais política e mais clareza sobre os limites aceitáveis de automação.

Conclusão

Grady Booch, famoso engenheiro de software e criador da UML, falou recentemente sobre velocidade e qualidade no mundo da AI: 

“[...] estou consternado com o foco na velocidade. Se você está correndo a toda velocidade, no estilo Thelma e Louise, rumo a um IPO, então certamente a velocidade será um fator crítico. Mas para a maior parte do domínio da computação, para sistemas que sejam significativos e duradouros, outros fatores são muito mais importantes: correção, repetibilidade, segurança, manutenibilidade, esses são os que predominam e, como tal, não se deixe distrair pelo ruído, fumaça, calor e luz de um estilo "IA em primeiro lugar" que pode te fazer sair da linha de partida rapidamente, mas que te deixará na mão na ultramaratona da maioria dos desenvolvimentos.”

Sem dúvida, ir rápido é importante; mas não podemos abrir mão da qualidade.

Referências

• Stripe. "Over 1,300 Stripe pull requests merged each week…" post no X
• Laura Tacho, The Pragmatic Summit. "Data vs Hype: How Orgs Actually Win with AI."
• John P. Mello Jr. "Open-Source Vulnerabilities Double as AI Coding Grows."
• Brian Scanlan. Thread no X sobre plugins internos no Claude Code na Intercom.

FAQ | Perguntas frequentes sobre qualidade de software

1. A IA substitui o engenheiro de software? 

Não, pelo menos não no horizonte previsível. A IA executa bem tarefas bem definidas, mas decisões de arquitetura, segurança, qualidade e produto ainda dependem de julgamento humano. O que muda é onde o esforço humano é mais necessário.

2. Como garantir qualidade em código gerado por IA? 

Com os mesmos mecanismos de sempre, agora reorganizados: revisão humana priorizada por risco, testes com critérios explícitos, análise estática no loop do agente e observabilidade robusta em produção. A diferença é que esses controles precisam escalar junto com o volume de código.

3. Vale a pena adotar IA no desenvolvimento mesmo com os riscos? 

Os dados apontam que sim, desde que os guardrails estejam em vigor. Times sem controles claros tendem a acumular dívida técnica e incidentes. Times com processos bem definidos conseguem combinar velocidade e qualidade.