A segunda base de código que ninguém pediu, e que IA criou sem avisar

Skills não são apenas atalhos: são contratos implícitos entre humanos e modelos de IA. Cada uma codifica uma intenção, um contexto e uma versão específica de uma API, framework ou biblioteca. Quando o modelo muda, ou pior, quando o código-fonte que ele imita é atualizado, esse contrato se rompe em silêncio. Não há erro no console, só um comportamento lento, inconsistente ou inseguro que leva semanas para ser rastreado. É nesse vácuo que nasce a segunda base de código: não documentada, não testada, mas mantida por rotina, como um legado antigo que ninguém ousa tocar porque 'funciona'. O que torna isso crítico para startups é que, ao contrário de grandes empresas com equipes dedicadas de SRE e observabilidade, elas carregam essa dívida técnica sem perceber, até que o custo de manutenção exceda o orçamento de engenharia do trimestre.

O dado mais revelador não está nos benchmarks, mas na prática: 67% dos devs gastam *mais tempo depurando* desde que adotaram assistentes de IA. Isso não é falha de ferramenta, é sinal de que estamos tratando prompts como anotações e não como código fonte, e o preço disso é pago em velocidade de entrega, confiança do time e previsibilidade de roadmap. Startups que ignoram esse ciclo de vida estão construindo produtos com janelas de manutenção invisíveis, onde cada nova feature gerada por IA pode encurtar a vida útil do sistema inteiro.

A cobertura anterior já alertava sobre agent harnesses como dívida técnica oculta (2026-05-13) e sobre o débito técnico de agentes de IA (2026-06-03), mas a notícia atual traz a primeira evidência concreta de escala operacional: a 'segunda base de código' deixou de ser teórica e virou um problema de infraestrutura. Antes, discutíamos riscos; agora, temos métricas reais, 1,7x mais problemas em PRs com IA, 96% de desconfiança entre devs e o termo 'AI slop' entrando no léxico de engenharia. A evolução não está no conceito, mas na materialização: skills acumuladas viraram ativos técnicos com ciclo de vida próprio, exigindo pipelines de avaliação contínua, não só revisão pontual.

Para startups, essa segunda base de código é um acelerador de falhas silenciosas. Enquanto grandes empresas podem absorver o custo de manter habilidades obsoletas, uma startup com 5 engenheiros não tem margem para sustentar código que parece funcionar, mas quebrará assim que o próximo patch do React for lançado, ou quando o modelo da IA for atualizado com novo fine-tuning. O que importa não é evitar IA, mas incorporar disciplina: tratar prompts como código-fonte, documentar intenções com rigor (não só funcionalidades), e medir não só 'quantas skills foram criadas', mas 'quantas foram invalidadas no último mês'. É a diferença entre escalar com controle e escalar com sorte.