As ideias eram boas. A economia era ruim.

Software engineering está cheio de ideias que parecem obviamente corretas assim que você as lê.

Claro que contracts deveriam definir o que uma função pode aceitar e retornar. Claro que tests deveriam verificar properties em vez de alguns poucos exemplos escolhidos manualmente. Claro que equipes deveriam medir se os tests realmente detectam faults em vez de assumir que coverage basta. Claro que decisões de arquitetura deveriam permanecer sincronizadas com o código que governam.

Nada disso era controverso. O problema era econômico. Essas estratégias eram caras exatamente no recurso que a maioria dos times menos consegue multiplicar: atenção especializada.

Por anos, muitas estratégias fortes de engenharia seguiram o mesmo ciclo. Um time adotava uma delas. A qualidade melhorava. Depois vinha o custo de manutenção. Contracts entravam em drift. Property tests ficavam para trás quando o schema mudava. Surviving mutants se acumulavam sem triage. Documentos de arquitetura viravam ficção. A estratégia não fracassava porque estivesse errada. Fracassava porque exigia um nível de especialização contínua que a maioria dos times de produto não conseguia sustentar.

Esse é o contexto real do momento atual da AI. A mudança importante não é apenas que modelos escrevem código mais rápido. A mudança importante é que agora eles conseguem absorver boa parte do trabalho de specification e verification que antes tornava essas práticas caras demais.

O que realmente mantinha essas estratégias no nicho

Nunca foi só capacidade de computação. Computação barata existe há muito tempo.

Também nunca foi apenas problema de ferramentas. Boas ferramentas já existiam para muitas dessas ideias. Ainda assim, alguém precisava saber formular invariants, generators, contracts e boundary rules corretamente.

O verdadeiro gargalo era especialização difícil de paralelizar.

  • Design by contract exigia engineers capazes de escrever e manter preconditions, postconditions e invariants úteis ao longo de refactors.
  • Property-based testing exigia pessoas que pensassem em round trips, idempotência, comportamento de erro e properties algébricas em vez de apenas exemplos.
  • Mutation testing exigia triage de survivors para separar lacunas reais de equivalent mutants.
  • Type-level correctness exigia conforto com branded types, phantom types, typestates ou até ferramentas de verificação formal.
  • Living specifications exigiam traduzir decisões humanas continuamente em architecture rules executáveis.

Cada estratégia carregava seu próprio imposto de manutenção. Combinar várias era ainda mais caro porque também exigia uma camada de ligação entre elas.

Por isso tantas ideias “boas no papel” ficaram restritas ao setor aeroespacial, ao mercado financeiro, à pesquisa em métodos formais ou a times de infraestrutura incomumente disciplinados. Os métodos funcionavam. O modelo de alocação de pessoas não.

O que a AI muda

AI não remove julgamento de engenharia. Ela muda onde esse julgamento é gasto.

Antes, um engenheiro sênior precisava escrever quase todo o andaime manualmente. Agora o modelo pode rascunhar o primeiro contract, sugerir properties, montar o schema, propor uma architecture rule e até redigir um regression test inicial para um surviving mutant. O humano faz revisão de correção de domínio em vez de começar de uma página em branco.

Essa mudança importa muito mais do que parece.

O fluxo de trabalho antigo era centrado na autoria. O novo passa a ser centrado na revisão.

Isso significa:

  • contracts ficam mais baratos de introduzir
  • property-based testing se torna mais prático
  • mutation testing fica mais útil
  • architecture constraints ficam mais fáceis de impor

Esse é o verdadeiro desbloqueio econômico. Não se trata de substituir engineers por um modelo. Trata-se de tornar acessíveis estratégias que antes dependiam de autoria especializada.

A percepção importante: essas estratégias se reforçam

A melhor parte não está em uma técnica isolada.

O ponto interessante é que a AI torna o stack viável como sistema.

Um contract pode alimentar um property test. Um property test pode ser avaliado por mutation testing. Um schema pode definir a runtime boundary. Um ADR pode virar uma architecture rule. Um branded type pode estreitar a surface area antes mesmo de um check de runtime acontecer. O valor não está só nas partes. Está na camada de ligação entre elas.

Antes da AI, a maioria dos times mal conseguia justificar uma dessas estratégias. Depois da AI, fica realista combinar várias sem transformar o trabalho de confiabilidade em um programa de especialistas.

Isso não é mágica

Ainda existe um jeito errado de fazer.

Se você deixa a AI gerar código, contracts e tests sem deterministic enforcement, só cria uma pilha maior de texto plausível. O objetivo não é pedir para o modelo aprovar seu codebase. O objetivo é usar o modelo para produzir artefatos que possam ser verificados de forma barata e repetível.

Por isso o padrão vencedor continua sendo o padrão chato:

  • gerar com AI
  • validar com ferramentas determinísticas
  • revisar mudanças no nível da especificação
  • falhar rápido em CI quando uma regra é violada

AI é valiosa aqui porque fecha a lacuna de especialização, não porque deva ser o juiz final.

Por que isso importa agora

Os times já usam AI para comprimir tempo de implementação. O risco é a velocidade de entrega crescer mais rápido do que a profundidade de verificação.

Quando isso acontece, você não ganha uma organização de engenharia mais produtiva. Você ganha um caminho mais rápido para sistemas frágeis.

A oportunidade é usar os mesmos modelos que aceleram geração para ressuscitar práticas de reliability que historicamente eram caras demais. É assim que você impede velocidade de virar dívida operacional.

Os próximos anos vão premiar times que entendam essa diferença cedo. AI-assisted coding sozinho não é estratégia. AI-assisted verification and enforcement é.

E é por isso que tantas ideias antigas de engenharia voltam a importar: não porque ficaram subitamente mais corretas, mas porque finalmente ficaram economicamente práticas.