Radar Tech: cognitive debt — por que o código gerado por IA precisa continuar sendo entendido por gente
O tópico mais comentado das últimas 24h não é um framework novo: é como adotar código gerado por IA sem entregar o entendimento do sistema a uma máquina. Entenda o debate e a resposta de arquitetura (ADR + fitness functions).
O debate mais quente das últimas 24h no Hacker News não foi sobre um novo framework ou mais uma CVE — foi sobre uma dor silenciosa que afeta qualquer equipe que usa copiloto de código. Um ensaio com 460+ votos e centenas de comentários defendeu uma ideia quase herética em 2026: para quem quer dominar de verdade a própria base de código, vale retipar manualmente o código gerado por IA (veja "Prevent cognitive debt by manually retyping LLM-generated code", de Ankur Sethi).
O problema não é a IA, é a autoria
Quando um LLM gera um trecho e o engenheiro cola sem ler a fundo, o código entra na base sem que ninguém carregue o "mental model" — a representação interna de onde cada coisa mora e por que existe. Isso é cognitive debt, a dívida do entendimento que é diferente (e mais traiçoeira) da dívida técnica dos code smells.
- Código tecnicamente sujo ainda é entendível e refatorável.
- Código que ninguém entende não é nem "refatorável" — é uma caixa-preta que roda.
- Com o tempo, o onboarding desacelera, mudanças viram garimpo e aparece aquele bug que "ninguém sabe por que quebrou".
Dois caminhos, duas escolhas
A discussão no HN expôs dois polos:
- Copy-paste cego: ganho máximo de velocidade a curto prazo, dívida cognitiva acumulando em cada merge sem revisão a sério.
- Autoria humana governada: a IA propõe, o engenheiro edita/retipa e constrói o mental model; um pouco mais lento, mas a base continua evoluível e o time sênior de verdade.
A maioria dos comentários convergiu para um consenso maduro: não é sobre "IA sim ou não", é sobre como integrar — e isso é, por definição, uma decisão de arquitetura.
A resposta de arquitetura: documente a decisão
É exatamente para isso que existem os Architecture Decision Records (ADRs). Em vez de uma política informal em um chat de equipe, a decisão de como adotar código de IA merece o mesmo tratamento de qualquer decisão arquitetural importante:
- Contexto e drivers — por que adotar e o que pesa contra.
- Decisão imperativa — escopo permitido, critério de aceite de PR e caminho de reversão.
- Fitness functions — métricas observáveis por CI que avisam quando a decisão está sendo violada (ex.: % de linhas de IA alteradas depois do merge).
- Checklist por PR — regra booleana que prova que quem subiu a mudança a entende.
O que está em jogo não é excluir IA do fluxo — é nunca mais aceitar código que ninguém consegue explicar. Velocidade sem entendimento vira passivo amortizado que cobra juros nos piores momentos, como o onboarding de um júnior justamente quando o sprint aperta.
Resumo do dia para o seu time
- Trate a adoção de IA como decisão de arquitetura com ADR, não como preferência individual.
- Exija autoria: quem sobe a mudança precisa conseguir explicar, em uma frase, o que ela faz e por quê.
- Meça com fitness functions e reavalie por reversibilidade — se a decisão não tem como voltar atrás, é uma aposta, não uma decisão.
Para quem quiser um ponto de partida concreto, o marketplace da ArchPrompts traz um pacote multi-arquivo que transforma o contexto da sua equipe em um ADR de governança de IA completo — com regras anti-alucinação, exemplos para casos de borda (inclusive dev solo em ambiente regulado) e critérios objetivos de aceite. A pergunta do dia não é se você vai usar IA no código; é se você vai continuar entendendo ele. Faça a segunda parte valer por escrito.
