Como usar IA em novos projetos sem transformar seu código em um Frankenstein · faconi

Pessoal, não sei se esse é o canal correto, mas gostaria muito que vocês assinassem minha newsletter — estou postando toda segunda-feira, de forma recorrente, com coisas práticas de engenharia/arquitetura.

Nos últimos meses ficou normal pedir pra IA criar endpoint, use case, query, fluxo… Só que tem um risco silencioso que eu vejo pouca gente tratando com seriedade:

o problema não é a IA errar — é ela acertar cada vez de um jeito diferente.
Compila, passa, “funciona”… mas o padrão vai sumindo.

Quando você pede “cria um endpoint”, a IA escolhe um caminho com base num caldeirão de repositórios públicos. Resultado: cada entrega pode vir com uma arquitetura diferente (service aqui, controller inchada ali, CQRS do nada, camada inventada…). Em pouco tempo, o sistema vira um Frankenstein arquitetural — e ninguém mais sabe qual é o “jeito certo”.

Na postagem eu trago um caminho bem pragmático pra evitar isso, com exemplos do que tem funcionado na prática:

definir a coluna dorsal do sistema (estilo + camadas + regras do que não usar)
documentar isso dentro do repositório (pra pessoas e pra IA)
usar ADRs e registros de decisão como memória do porquê das escolhas
criar rituais leves (tech talks + gravação/transcrição) pra transformar conhecimento tácito em base consultável

Se você já teve sensação de “IA ajudou, mas bagunçou o padrão”, acho que vai curtir:
https://luisfaconi.substack.com/p/como-usar-ia-em-novos-projetos-sem

Queria ouvir também: o que mais “quebra consistência” no teu time quando IA entra no fluxo? Prompt? Falta de docs? Pressa? Onboarding?