Se a programação com IA está diminuindo a qualidade do seu código, você não está gerenciando a qualidade direito
A programação assistida por IA está dividindo engenheiros, que a veem ora como um poderoso ganho de produtividade, ora como um caminho rápido para “slop” difícil de manter que sobrecarrega os revisores. Muitos argumentam que a qualidade do código, no fim, depende do processo e do julgamento humanos — especificações rigorosas, testes, revisões e barreiras de proteção claras para agentes — enquanto outros respondem que, em equipes reais com gestão fraca, a IA apenas amplifica maus hábitos existentes e dívida técnica. Por trás do debate, há uma preocupação mais ampla de que as organizações estejam perseguindo velocidade e volume de código sem a cultura, os incentivos ou as salvaguardas necessários para manter os sistemas confiáveis ao longo do tempo.
Impacto na Qualidade do Código
- Há uma divisão clara: alguns dizem que a IA pode produzir código tão bom quanto ou melhor do que o deles; outros insistem que código gerado por IA é inerentemente mais descuidado ou difícil de manter.
- Críticos argumentam que muitos desenvolvedores não conseguem avaliar de forma confiável o que é um código “bom”, especialmente em arquitetura, e por isso superestimam a qualidade da IA.
- Defensores afirmam que modelos recentes, usados corretamente, produzem código de alta qualidade, especialmente para detalhes, refatorações e modernização de sistemas legados.
- Vários observam que a IA principalmente amplifica práticas existentes: bons engenheiros ficam um pouco melhores; os medianos produzem 10× mais código ruim.
Processo, Barreiras de Proteção e Testes
- Muitos comentários enfatizam que a qualidade vem de práticas clássicas: especificações claras, critérios de aceitação, revisão de código, linting, tipagem, verificações de complexidade e testes fortes.
- Instruções positivas e prescritivas (“sempre procure helpers antes de escrever um”) funcionam melhor do que regras do tipo “nunca faça X”.
- Passadas de “auditoria” pós-implementação por agentes para encontrar duplicatas, problemas de nomenclatura e violações de estilo são relatadas como eficazes.
- Forte ênfase em testes: unitários, baseados em propriedades/fuzzing, testes diferenciais, golden masters, cobertura. Alguns argumentam que a porcentagem de cobertura sozinha é um mau proxy de qualidade.
Produtividade vs. Carga de Revisão
- Os ganhos relatados vão de modestos a “10×” em trabalho solo em projetos novos; em contextos de equipe, aumentos de 50–100% são vistos como mais realistas.
- Outros dizem que a IA não economiza tanto tempo assim quando se inclui revisão séria e redesenho.
- A carga de revisão é um grande problema: a IA permite PRs enormes que humanos não conseguem compreender completamente, especialmente em grandes organizações e no open source.
Gestão, Incentivos e Responsabilidade
- Muitos argumentam que a IA não está “destruindo codebases” sozinha; são os humanos e os processos de gestão que decidem o que é aceito.
- Outros contra-argumentam que expectativas de velocidade irreais tornam a revisão cuidadosa impossível, forçando efetivamente o uso de IA de baixa qualidade.
- Há debate sobre se é justo culpar os usuários por “usar a ferramenta errado” em vez de exigir melhores padrões padrão e um comportamento mais seguro das ferramentas.
Uso Agentic e Recursivo
- Fluxos de trabalho recursivos e agentic (a IA modificando repetidamente sua própria saída) são vistos como particularmente arriscados, tendendo a um “random walk” de espaguete sem uma direção humana rígida.
- Alguns acham que as técnicas atuais de prompting e barreiras de proteção são insuficientes para permitir com segurança que agentes rodem sem supervisão em sistemas complexos e não-"boilerplate".
Atitudes e Ofício
- Um tema recorrente: cuidar do código como um ofício vs. ser “apenas um emprego”.
- Quem trata a IA como assistente e mantém padrões altos relata melhores resultados do que quem faz “vibe coding” e entrega o que quer que passe nos testes mínimos.