A demonstração sempre funciona

Toda demonstração de AI coding segue o mesmo arco. Alguém faz um prompt para um modelo. Um aplicativo funcional se materializa. A audiência fica impressionada.

E com razão. A velocidade é real. A capacidade é real. A primeira versão realmente vai ao ar mais rápido com AI no loop.

O problema é que a primeira versão nunca foi a parte difícil.

Onde o custo realmente está

O custo da engenharia de software não se concentra na criação inicial. Ele se concentra na quarta, quinta e sexta iteração:

  • O provedor de autenticação precisa mudar porque o preço mudou.
  • Analytics precisa mudar porque o fornecedor foi adquirido.
  • Uma funcionalidade precisa ser adicionada e tocar três telas que a geração original nunca antecipou.
  • Um sistema de estilos precisa ser substituído porque o designer mudou de direção.
  • Uma integração de pagamentos precisa ser trocada porque o produto se expandiu para um novo mercado.

Nada disso é falha da geração inicial. Tudo isso é desenvolvimento normal de produto. A pergunta é se a codebase torna essas mudanças baratas ou caras.

A codebase gerada por AI sob pressão de mudança

A maioria das codebases geradas por AI lida bem com a primeira mudança. A segunda já é desconfortável. Na quarta mudança, equipes começam a relatar os mesmos sintomas:

  • “Pedimos à AI para trocar o provedor de autenticação, mas ela mexeu em 14 arquivos.”
  • “O refactor quebrou testes em modules que deveriam ser não relacionados.”
  • “Não conseguimos dizer quais partes do sistema dependem do SDK de analytics.”
  • “Toda mudança exige reentender a codebase inteira.”

Esses sintomas não são falhas do modelo. São falhas de arquitetura. O modelo gerou um sistema sem fronteiras, e agora toda mudança tem um raio de impacto imprevisível.

Por que codebases de AI se degradam mais rápido

Codebases tradicionais também se degradam. Mas codebases geradas por AI se degradam mais rápido por razões específicas:

Sem modelo mental compartilhado. Uma equipe humana constrói intuição estrutural ao longo de meses. Uma AI gera código sem memória de por que decisões anteriores foram tomadas.

Otimização para o prompt imediato. Modelos resolvem a solicitação atual. Eles não otimizam para as próximas cinco. Cada geração toma decisões localmente corretas, mas globalmente incoerentes.

O volume amplifica o acoplamento. AI gera mais código, mais rápido. Mais código com fronteiras fracas significa mais acoplamento, mais rápido. A vantagem de velocidade vira o acelerador da degradação.

Refactor exige contexto global. Modelos têm dificuldade com refactors que atravessam a codebase inteira porque janelas de contexto são finitas e a intenção arquitetural é implícita.

O verdadeiro desafio de engenharia

O verdadeiro desafio de engenharia no desenvolvimento AI-native não é “Como gero código melhor?”

É “Como estruturo o sistema para que partes geradas por AI possam ser mudadas de forma independente?”

Isso significa:

  • Fronteiras que tornam o raio de impacto previsível.
  • Interfaces que desacoplam o que muda do que permanece.
  • Composition roots que tornam explícitos os grafos de dependência.
  • Contract tests que verificam integração sem exigir o sistema inteiro.
  • A capacidade de apagar e regenerar qualquer module sem falhas em cascata.

Manutenção no longo prazo é um problema estrutural

Nenhuma quantidade de prompting melhor corrige uma codebase em que todo module alcança o interior de todo outro module. Você não resolve acoplamento arquitetural só com prompting.

A manutenção de codebases de AI no longo prazo exige a mesma disciplina de sempre: fronteiras, contracts e isolamento. A diferença é que a velocidade da AI torna a ausência dessas disciplinas visível mais rápido. Uma equipe que levaria dois anos para criar um monólito impossível de manter agora consegue fazer isso em dois meses.

A velocidade é um presente e uma armadilha. Sem estrutura, ela só significa que você chega à crise de manutenção mais cedo.

A conexão com a arquitetura AI-native

Esse é o argumento central que fiz em Stanford CS146S está certo sobre AI coding. A disciplina que falta é arquitetura: fluência com ferramentas sem disciplina arquitetural produz codebases rápidas de criar e caras de manter.

O desenvolvedor de software moderno precisa dos dois lados. As ferramentas de AI para lançar rápido. A disciplina de arquitetura para continuar lançando rápido depois da primeira versão.

A primeira versão nunca foi o problema. O problema é saber se a quinta ainda é barata.

Perguntas frequentes

Por que codebases geradas por AI se tornam difíceis de manter?

Modelos de AI otimizam para o prompt imediato, não para mudanças futuras. Isso produz código que funciona, mas sem as fronteiras necessárias para modificação independente. Sem restrições arquiteturais explícitas, o acoplamento se acumula mais rápido do que em codebases escritas manualmente, porque AI gera mais código, mais rápido.

Como você evita a degradação de uma codebase de AI ao longo do tempo?

Três práticas estruturais: fazer enforcement de fronteiras de modules com interfaces controladas pela aplicação, centralizar a conexão das dependências em uma composition root e rodar contract tests que verifiquem pontos de integração de forma independente. Isso torna o custo de mudança previsível independentemente de como o código foi gerado.

O código gerado por AI é mais difícil de refactorar do que código escrito por humanos?

Não inerentemente. Mas código gerado por AI tem mais chance de não ter as fronteiras estruturais que tornam refactors seguros, porque modelos não otimizam espontaneamente para mudanças futuras. A correção é impor essas fronteiras antes da geração, não esperar que o modelo as produza sozinho.

Qual é o maior risco do AI coding em projetos de longo prazo?

O maior risco é a armadilha da velocidade: lançar tão rápido na fase inicial que a dívida arquitetural se acumula antes de o time perceber. Quando a manutenção fica cara, a codebase já está acoplada demais para ser corrigida incrementalmente.