Limites em bases grandes e legadas
Onde a assistência de IA perde eficácia em sistemas antigos e extensos, e como compensar isso.
Os três módulos anteriores assumiram, na maior parte dos exemplos, um projeto de tamanho gerenciável. Este último módulo trata do caso onde a maioria dos times realmente trabalha: bases de código grandes, com anos de histórico, decisões antigas nem sempre documentadas e convenções que mudaram ao longo do tempo. É aí que a assistência de IA perde eficácia — e onde vale saber compensar isso deliberadamente.
Por que bases grandes e legadas são mais difíceis
O módulo 1 já estabeleceu o problema central: o assistente só sabe o que está no contexto fornecido. Em uma base grande, isso significa que a fração do sistema visível a qualquer pedido é pequena — e em uma base legada, essa fração pequena pode conter convenções de épocas diferentes, competindo entre si, sem indicação clara de qual é a atual.
O resultado mais comum não é um erro óbvio — é um código que funciona, mas segue um padrão que o time já abandonou há anos, porque foi o padrão mais representado no trecho de contexto que o assistente recebeu.
Três compensações práticas
1. Trate a seleção de contexto como parte do trabalho, não um detalhe. Em uma base grande, vale mais tempo decidindo quais dois ou três arquivos são realmente relevantes do que em um projeto pequeno, onde quase tudo cabe. Priorize os arquivos modificados mais recentemente sobre os mais antigos, quando ambos parecerem relevantes — código recente tende a refletir a convenção atual com mais fidelidade.
2. Documente convenções explicitamente, em vez de esperar que o assistente as infira. Um arquivo curto listando as decisões atuais do projeto — o padrão de nomenclatura vigente, a abordagem de tratamento de erro preferida, o que está sendo descontinuado — economiza mais tempo do que parece, porque elimina a ambiguidade que faz o assistente escolher entre convenções concorrentes.
3. Prefira mudanças pequenas e isoladas a mudanças amplas. Numa base legada, uma mudança que toca muitos arquivos de uma vez tem mais chance de esbarrar em uma parte do sistema com contexto próprio, não documentado, que uma mudança pequena e isolada não alcançaria. Isso é o mesmo princípio de quebrar tarefas longas do curso de Fundamentos de IA, aplicado à escala de um sistema inteiro.
Um sinal de alerta específico: confiança alta em área desconhecida
O padrão de "excesso de confiança em domínio estreito", do curso de Fundamentos de IA, aparece com força em bases legadas: uma parte antiga do sistema, com lógica específica de negócio que só faz sentido para quem conhece o histórico, pode receber uma resposta do assistente com a mesma fluência de qualquer outra parte — mesmo que o assistente não tenha como conhecer o motivo histórico por trás daquela lógica específica.
Nessas áreas, o nível de revisão certo (do módulo 3) sobe, não porque o assistente piorou, mas porque o custo de um erro nessas áreas costuma ser maior e mais difícil de perceber.
Quando vale a pena voltar para o método manual
Em alguns casos, a base é grande e antiga o suficiente para que montar o contexto certo consuma mais tempo do que faria a diferença de usar IA. Reconhecer esse limite é parte da maturidade de uso, não uma admissão de que a IA "não serve": o mesmo raciocínio do módulo sobre onde a IA ajuda, em Fundamentos de IA — verificabilidade baixa (não dá para checar rápido se o contexto estava completo) some com tolerância a variação baixa (código legado crítico raramente tolera erro) para formar exatamente o quadrante onde IA ajuda menos.
Fechando o curso
Este curso partiu do princípio de que a maioria das respostas ruins de um assistente de código vem de contexto insuficiente (módulo 1), aplicou isso aos usos de melhor retorno — refatoração e testes (módulo 2) —, definiu a revisão certa para o que é gerado (módulo 3) e termina reconhecendo onde o próprio método atinge seu limite. Usar bem um assistente de código não é sobre confiar mais ou menos nele em geral — é sobre saber, tarefa por tarefa, o que ele precisa para acertar e quando isso deixa de valer a pena montar.
Exercício
Identifique uma área do seu projeto que você considera "legada" ou pouco documentada. Escreva, em poucas frases, as convenções e decisões que um novo integrante do time (ou um assistente de IA) precisaria saber para trabalhar bem ali — o rascunho desse documento já é o primeiro passo da compensação sugerida neste módulo.
O que fica
- Bases grandes e legadas reduzem a fração do sistema visível a qualquer pedido, e podem misturar convenções de épocas diferentes sem indicação de qual é a atual.
- Três compensações: tratar a seleção de contexto como parte do trabalho, documentar convenções explicitamente, preferir mudanças pequenas e isoladas.
- Excesso de confiança em domínio estreito aparece com força em código legado — o nível de revisão deveria subir ali, não por o assistente ter piorado.
- Reconhecer quando montar o contexto certo custa mais do que vale a pena é maturidade de uso, não fracasso do método.