Código gerado por LLM em produção: o que revelam os dados de 12 projetos

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

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

Metodologia

Analisamos 12 projetos em produção entregues entre junho de 2025 e janeiro de 2026 utilizando a metodologia de desenvolvimento orquestrado por IA da NOSOTA. Cada projeto foi construído por um a três engenheiros sêniores no papel de orquestradores, com agentes de IA gerando a maior parte do código produtivo sob briefs estruturados e revisão humana.

Os projetos abrangem backends corporativos, aplicativos 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 REST API. Cada métrica é rastreável pelo histórico do Git, logs de CI/CD e rastreadores de issues.

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

Achado 1: A cobertura de testes supera as referências do setor

Nos 12 projetos, a mediana de cobertura de linhas foi de 78%, com três projetos acima de 85%. A cobertura de branches — uma métrica mais rigorosa — ficou em média em 64%. Para comparação, pesquisas setoriais situam consistentemente a cobertura média de linhas entre 40% e 60% em bases de código corporativas.

A explicação é estrutural, não heroica. Agentes de IA geram testes como parte de sua saída padrão quando recebem um brief com escopo bem definido. O custo de escrever um teste despenca quando o agente o produz junto com a implementação. O que é caro em fluxos de trabalho tradicionais — suítes de testes abrangentes — passa a ser o resultado natural do desenvolvimento orquestrado por IA.

O fator decisivo é a qualidade do brief. Projetos em que o orquestrador especificou critérios de aceitação explícitos em cada brief atingiram de 15 a 20 pontos percentuais a mais de cobertura do que aqueles em que os requisitos de testes ficaram implícitos.

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

A mediana de densidade de defeitos nos 12 projetos foi de 0,8 bugs por mil linhas de código nos primeiros 90 dias. A referência do setor para times maduros fica tipicamente entre 1 e 5 bugs por KLOC. Dois projetos atingiram zero defeitos em produção durante o período de medição.

O resultado não se deve à IA gerar código perfeito — não gera. Em nossos dados, cerca de 12% do código gerado por IA precisou de modificação durante a revisão humana antes do merge. A baixa taxa de defeitos vem do processo de revisão: cada linha de saída da IA passa pela avaliação de um engenheiro sênior antes de entrar no codebase. A combinação de velocidade de geração da IA e rigor da revisão humana produz código que se escreve rápido e se verifica com cuidado.

Projetos em que o orquestrador pulou ou apressou a revisão — identificáveis por tempos de revisão mais curtos nos metadados do Git — apresentaram taxas de defeitos de 3 a 4 vezes maiores. A metodologia funciona quando o humano no loop leva a sério o mandato de revisão.