Qualidade do código gerado por LLM: estudo prático em 12 projetos

A maior parte do debate sobre o código gerado por IA gira em torno de saber se funciona. É a pergunta errada. A pergunta relevante para sistemas em produção é se funciona de forma fiável, se pode ser mantido por engenheiros que não o escreveram e se introduz defeitos a um ritmo compatível com a entrega contínua.

Decidimos responder com dados, não com opiniões.

Metodologia

Analisámos 12 projetos em produção, entregues entre junho de 2025 e janeiro de 2026, com a metodologia de desenvolvimento orquestrado por IA da NOSOTA. Cada projeto foi construído por um a três engenheiros seniores no papel de orquestradores, com agentes de IA a gerar a maior parte do código de produção a partir de briefings estruturados e de revisão humana.

Os projetos abrangem back-ends empresariais, aplicações móveis multiplataforma, portais web e sistemas com integração de ML. No total, somam mais de 200 000 linhas de código, mais de 1 400 testes automatizados e mais de 350 endpoints de API REST. Cada métrica é rastreável através do histórico do Git, dos registos de execução de CI/CD e dos sistemas de gestão de pedidos.

Medimos três dimensões: cobertura de testes (cobertura de linhas e de ramos reportada pelo CI), densidade de defeitos (defeitos por mil linhas de código nos primeiros 90 dias após a colocação em produção) e manutenibilidade (tempo necessário para um engenheiro que não conhece o código implementar uma alteração não trivial).

Conclusão 1: a cobertura de testes supera as referências do setor

Nos 12 projetos, a mediana da cobertura de linhas foi de 78 %, com três projetos acima dos 85 %. A cobertura de ramos — uma métrica mais exigente — situou-se, em média, nos 64 %. Para comparação, os inquéritos ao setor situam de forma consistente a cobertura média de linhas entre 40 % e 60 % nas bases de código empresariais.

A explicação é estrutural, não heroica. Os agentes de IA geram testes como parte da sua saída habitual quando recebem um briefing com âmbito bem definido. O custo de escrever um teste cai a pique quando o agente o produz juntamente com a implementação. O que é caro nos fluxos de trabalho tradicionais — conjuntos de testes abrangentes — passa a ser o resultado natural do desenvolvimento orquestrado por IA.

O fator decisivo é a qualidade do briefing. Os projetos em que o orquestrador especificou critérios de aceitação explícitos em cada briefing atingiram uma cobertura 15 a 20 pontos percentuais superior à daqueles em que os requisitos de testes ficaram implícitos.

Conclusão 2: a densidade de defeitos é menor, mas a causa é a disciplina de revisão

A mediana da densidade de defeitos nos 12 projetos foi de 0,8 defeitos por mil linhas de código nos primeiros 90 dias. A referência do setor para equipas maduras situa-se tipicamente entre 1 e 5 defeitos por KLOC. Dois projetos registaram zero defeitos em produção durante o período de medição.

O resultado não se deve ao facto de a IA gerar código perfeito — não gera. Nos nossos dados, cerca de 12 % do código gerado por IA precisou de ser alterado durante a revisão humana antes da integração. A baixa taxa de defeitos resulta do processo de revisão: cada linha produzida pela IA passa pela avaliação de um engenheiro sénior antes de entrar na base de código. A combinação da velocidade de geração da IA com o rigor da revisão humana produz código que se escreve depressa e se verifica com cuidado.

Os projetos em que o orquestrador saltou ou apressou a revisão — identificáveis por tempos de revisão mais curtos nos metadados do Git — apresentaram taxas de defeitos 3 a 4 vezes superiores. A metodologia funciona quando o ser humano no circuito leva a sério a sua responsabilidade de revisão.

Conclusão 3: a documentação permite que outros mantenham o código

A manutenibilidade é a dimensão sobre a qual os clientes menos perguntam e aquela que pagam durante mais tempo. Um sistema é fácil de manter quando um engenheiro que não o construiu consegue compreendê-lo depressa e alterá-lo com segurança.

No desenvolvimento orquestrado por IA, a documentação não é algo que se acrescenta no fim, mas um subproduto do próprio método. Todos os projetos da amostra foram entregues com as especificações que orientaram os agentes de IA, registos de decisões de arquitetura, documentação de API e código comentado para explicar a intenção, e não a sintaxe. A mesma revisão que procura defeitos no resultado da IA verifica também se o código se explica por si.

Isto tem duas consequências práticas. Em primeiro lugar, o cliente não fica dependente de um fornecedor: o conhecimento do sistema está no repositório, e não na cabeça de quem o construiu. Em segundo lugar, o desenvolvimento pode passar de uma equipa para outra — engenheiros internos, outro prestador de serviços ou novos colaboradores — com uma curva de aprendizagem mínima, porque a nova equipa parte das mesmas especificações e decisões que a original.