Dívida de Controle: quando o vibe coding começa a cobrar juros

Você já aceitou um refactor gigante sugerido pela IA, deu aquele scroll rápido, pensou "parece ok" e mandou um git commit? Provavelmente você acabou de fazer mais um parcelamento na sua Dívida de Controle.

Fala-se muito de dívida técnica. Mas com Cursor, Windsurf e Claude Code, tem uma categoria específica ganhando força: a dívida que não está só no código em si, mas na nossa capacidade de entender e governar o sistema.

É a hora em que o código continua "rodando", mas você já não consegue explicar com segurança por que ele funciona. Quando isso acontece, você não é mais o arquiteto. É só o síndico assinando papel sem ler.

O que é Dívida de Controle, na prática

Dívida de Controle é o passivo que você acumula toda vez que:

• aceita uma sugestão de IA que não conseguiria reimplementar sem ela;
• deixa entrar um refactor de impacto não mapeado;
• passa a depender do histórico da ferramenta para lembrar o que mudou;
• perde a visão de fluxo de quem chama quem ou que dado atravessa qual fronteira.

O código funciona hoje, mas você perdeu alavancas. Você não sabe onde tocar para mudar um comportamento, onde colocar um guardrail contra bugs, nem como argumentar sobre riscos arquiteturais com o time.

É igual aceitar um laudo técnico baseado em uma IA que você não consegue auditar. O STJ acabou de rejeitar um relatório produzido por generativa porque ela "alucinou" um termo que a perícia oficial não encontrou. A corte não consegue traçar o raciocínio da máquina. Logo, não confia nela para decisões sérias.

No mundo dev, usar IA como engine de refatoração sem contrapeso é abrir mão da auditabilidade em troca de velocidade imediata.

Vibe coding promete fluxo, mas esconde custo

"Vibe coding" é sedutor porque conversa com o nosso lado criativo. Você descreve o que quer em linguagem natural, a ferramenta preenche com blocos de código e você faz um vibe check superficial. Não gritou erro, segue o jogo.

Quando isso vira rotina, o fluxo muda. Gastamos menos tempo escrevendo do zero e mais tempo lendo diffs gigantes tentando achar erros. Nossas decisões ficam diluídas em chats e prompts.

O problema é que leitura passiva não equivale a controle ativo. Subestimamos o quanto o cérebro "carrega" de um código escaneado visualmente. Você absorve o suficiente para não travar, mas não o suficiente para segurar o sistema no colo quando algo quebrar.

A falsa sensação de senioridade

Há um efeito colateral curioso: o júnior com uma boa IA entrega tanta coisa que parece sênior. Só que grande parte dessa entrega vem sem entendimento de trade-offs, sem visão de longo prazo de arquitetura e sem critério para rejeitar uma sugestão da ferramenta.

Isso escancara o "seniority gap". Não falta código, falta controle. Sênior hoje não é quem digita mais rápido. É quem consegue manter o mapa mental atualizado enquanto a máquina puxa o volante.

A IA não tira rigor. Ela exige mais

Existe uma leitura ingênua da IA de código de que agora podemos relaxar. É o oposto.

Quanto mais você delega, mais precisa de contratos claros entre módulos, testes que enquadram a IA e limites explícitos de onde a ferramenta pode atuar sozinha.

Pense de novo no STJ. O problema não é "usar IA", é usá-la sem trilha de verificação. No código é a mesma coisa. Você quer a IA produzindo alternativas exploratórias, não ditando a arquitetura principal.

A disciplina de testes é a única coisa entre você e um sistema impenetrável.

O novo papel do sênior: menos escritor, mais avaliador

Num fluxo com IA forte no loop, o papel do sênior se aproxima de um curador de decisões, um arquiteto de fluxo e um guardião de contexto.

Isso muda a prática diária: você escreve menos código bruto e mais testes e asserts que definem limites. O sênior que resiste a essa mudança e tenta competir com a IA em volume de linha escrita joga o jogo errado. O importante agora é prever o que vai quebrar se a IA fizer um refactor agressivo.

Como reduzir Dívida de Controle sem abrir mão da IA

Dá para usar IA pesado e manter o volante, mas exige processo intencional.

1. Refactor com propósito explícito

Cada refactor assistido deve responder a uma pergunta. Estamos reduzindo complexidade? Criando uma fronteira melhor? Isolando dependências? Se a resposta é "só achei legal", você emitiu mais uma parcela de dívida.

2. Pedir explicação à própria IA

Antes de aceitar o diff, peça um resumo arquiteto-friendly: o que mudou nas invariantes, funções afetadas e fluxos descontinuados. Esse mapa mantém a visão de conjunto.

3. Escrever testes como contrato

Dê à IA um cercadinho claro. Use testes para congelar comportamento. Se o diff quebrou um contrato, não importa a beleza da sintaxe, está reprovado.

4. Não delegar arquitetura

"Projeta a arquitetura ideal" faz a IA brincar de CTO em um contexto cego. O melhor é você propor um esqueleto e pedir à máquina para estressar gargalos e acoplamento. A IA vira crítico, não autor principal.

5. Documentar decisões

A IA gera volume, e sem registros, o sistema vira caixa-preta. Um simples DECISIONS.md ou anotações por pasta criam a trilha necessária para auditoria futura.

Sinais de que a Dívida de Controle já chegou

• PRs que ninguém revisa por terem "muito código gerado".
• Bugs que levam horas para reprodução porque não se conhece o fluxo.
• Features intocáveis feitas na pressa com assistente.
• Novos devs dependentes 100% da IA para navegação.

O dashboard de produtividade não mostra o humor do time nem o medo de mexer no repositório.

IA como aliada: desde que você continue dirigindo

Essas ferramentas vieram para ficar. Elas exploram opções em segundos e automatizam tarefas ingratas. Elas só se tornam perigosas quando achamos que a responsabilidade é delegável.

O tribunal consulta um laudo, mas o juiz assina a sentença. A ferramenta escreve o código, mas quem faz o deploy continua sendo você.

A Dívida de Controle nasce de usar a IA sem assumir seu papel de avaliador. Trate a máquina como consultora e não arquiteta-chefe, e o vibe coding não resultará num monolito irreconhecível amanhã.