Dívida cognitiva: quando ninguém entende o sistema que a IA escreveu

Nunca foi tão fácil tirar uma ideia do papel. Em um fim de semana, com uma IA e alguns prompts, dá para publicar um SaaS com login, pagamento e painel de controle. Funciona. Os primeiros clientes chegam.

Então o negócio faz o que todo negócio saudável faz: muda. Um cliente pede um plano diferente, a regra de cobrança precisa de uma exceção, uma lei nova altera o que pode ser guardado. E surge a pergunta que nenhum prompt respondeu: onde eu mexo sem quebrar o resto?

A distância entre essas duas coisas tem nome: dívida cognitiva.

A discussão está fazendo a pergunta errada

A conversa sobre IA no desenvolvimento costuma ficar presa entre dois extremos.

De um lado, a velocidade. Quantas funcionalidades saíram, quantas entregas por semana, quanto tempo foi economizado. A IA entrega, então o mercado mede o que ela entrega: quantidade.

Do outro lado, a desconfiança. "Precisa revisar cada linha que a IA escreveu." Parece prudente, mas anula o ganho e não escala. Ninguém vai ler com atenção dezenas de milhares de linhas geradas por mês.

Os dois lados olham para o código. E o código, sinceramente, deixou de ser o problema. Na maior parte do trabalho, quem vai escrever é a IA, e eu não acho isso ruim.

A pergunta que importa é outra: você tem como saber se o que foi feito está certo e como vai mudar isso amanhã?

Todo negócio saudável muda

Software não existe por si só. Ele existe para sustentar um negócio, e um negócio que não muda provavelmente parou de crescer. As regras mudam porque o mercado muda: concorrentes, clientes, leis, preços.

É por isso que existem arquitetura, padrões de projeto e desacoplamento. Não são enfeite nem burocracia de empresa grande. São formas de deixar a mudança mais barata.

Gregor Hohpe, em The Software Architect Elevator, compara boas decisões de arquitetura a opções financeiras: você paga um pouco antes para ter a liberdade de mudar depois, e essa liberdade vale mais justamente quando o futuro é incerto. Partes desacopladas podem ser trocadas sem derrubar o resto. Regras bem separadas podem mudar sem efeitos colaterais.

No fim, o objetivo é financeiro. A arquitetura decide se a próxima mudança custa uma tarde ou um mês.

O medo de mudar vem da falta de familiaridade

Hohpe também fala de algo que todo desenvolvedor já sentiu: o medo de mexer no código.

Ninguém tem medo de mudar o que entende. O medo aparece quando não se sabe o que depende daquele trecho, por que ele foi escrito daquele jeito e o que pode quebrar em outro lugar.

Antes da IA, essa falta de familiaridade vinha com o tempo: o sistema legado, a pessoa que saiu da empresa, o módulo em que "ninguém mexe". Agora ela pode existir desde o primeiro dia. É código que ninguém escreveu, ninguém leu com calma e ninguém precisou entender para colocar no ar.

Aquilo era falta de familiaridade acumulada ao longo de anos. Com IA, dá para acumular a mesma coisa em semanas.

A dívida técnica mora no código. A dívida cognitiva mora na cabeça das pessoas: é a distância entre o que o sistema faz e o que a equipe realmente entende dele.

O termo ganhou força em 2025, com um estudo do MIT Media Lab sobre pessoas escrevendo redações com ajuda do ChatGPT. Quem usou a IA mostrou menos engajamento cerebral e lembrava menos do próprio texto do que quem escreveu sem ajuda. O estudo é sobre redações, não sobre software, e ainda está em debate. Mas a ideia se aplica: o esforço que você deixa de fazer hoje vira entendimento que falta amanhã.

Contexto é o que torna a mudança possível

O problema não é a IA escrever o código. O problema é pedir uma solução mágica sem critérios, sem documentação e sem contexto, e depois esperar conseguir mudar o resultado.

Contexto, na prática, é:

• Regras de negócio escritas: num PRD (documento de requisitos do produto), com o problema que o sistema resolve, o que ele precisa garantir, as exceções e o vocabulário do negócio.
• Decisões registradas: as ADRs (registros de decisões de arquitetura), propostas por Michael Nygard em 2011, guardam o que foi decidido, por quê e quais alternativas foram descartadas.
• Regras da equipe: tecnologias usadas e evitadas, padrões, estrutura do projeto e o que a IA pode ou não fazer. São os guardrails.
• Critérios de validação: testes que expressam as regras de negócio e verificações automáticas que dizem se algo continua valendo.

Esse contexto serve para as pessoas e para a IA ao mesmo tempo. Com ele, a IA deixa de adivinhar: sabe as regras, as decisões e os limites. Sem ele, cada pedido começa do zero, e cada resposta pode contradizer a anterior.

Durante décadas, documentar foi a boa prática que perdia para o prazo. Escrever e manter documentação era caro, e ninguém tinha tempo. Hoje a IA escreve, atualiza e confere essa documentação com a gente.

Por isso a pergunta deveria mudar de "como entregar mais rápido" para "como entregar melhor". Velocidade e qualidade não são opostas, mas a prioridade precisa estar na qualidade. A velocidade vem de brinde quando cada mudança não é uma aposta.

Quando isso não vale

Nem tudo precisa desse rigor. Um protótipo feito em um fim de semana para testar uma ideia não precisa de ADRs nem de documentação de regras. Se a ideia não parar em pé, tudo vai para o lixo, e está tudo bem.

O risco é o protótipo virar o produto sem que ninguém perceba. No dia em que alguém paga pelo sistema, ele deixou de ser um experimento, e a dívida começa a contar.

Também vale deixar claro o que eu não estou defendendo: validar não é ler todo o código. Validar é ter meios de saber se o resultado respeita as regras. Isso passa por testes, critérios claros e revisão concentrada no que é crítico.

Na prática: 10%, 80%, 10%

Uma forma simples de pensar o trabalho com IA:

• 10% antes, humano: entender o negócio e escrever o contexto, ou seja, a regra, a restrição e a decisão. Se você não consegue escrever a regra, a IA também não vai acertá-la.
• 80% no meio, IA: a execução, dentro dos guardrails definidos.
• 10% depois, humano: validar contra os critérios definidos no início e atualizar a documentação com o que mudou.

Alguns começos possíveis:

1. Escreva um PRD com as regras de negócio do sistema, e faça a equipe e a IA lerem esse documento antes de qualquer mudança.
2. Registre como ADR toda decisão que um dia vai gerar a pergunta "por que foi feito assim?".
3. Transforme as regras de negócio mais importantes em testes.
4. Peça para a IA explicar o que fez e confronte a explicação com a documentação. Se não bater, algo está errado: no código ou no documento.

O que a IA não resolveu

A IA resolveu a parte de escrever. Ela não resolveu a parte de entender, e é entender que permite mudar.

Gerar código ficou barato. Mudar o que ninguém entende continua caro.