Tem uma confusão que anda circulando por aí e que me incomoda como desenvoledor: tratar “vibe code” e “AI pair programming” como se fossem sinônimos. Não são. As duas coisas usam o mesmo motor — um agente de IA gerando código — mas param em lugares completamente diferentes, e essa diferença é justamente onde mora o risco.
Vou separar bem as duas, porque a distinção não é frescura acadêmica. Ela define quem é o dono do código no fim do dia.
Vibe code: confiança cega
Vibe code é você pedir, o agente entregar, e você aceitar. Ponto. Você não lê o diff com atenção, não questiona a abordagem, não sabe direito por que aquela query foi montada daquele jeito ou por que o agente decidiu criar mais três classes. Se rodou e o teste passou (quando existe teste), tá aprovado.
O nome é honesto: você está codando “no vibe”. Confiando 100% no que a máquina cuspiu, sem entender o que está sendo gerado.
E olha, funciona. Funciona assustadoramente bem pra protótipo, pra script descartável, pra aquele projeto de fim de semana que ninguém vai manter. O problema é quando isso vira o modo padrão de trabalho num sistema que vai pra produção e que outra pessoa (ou você daqui a seis meses) vai precisar manter.
O que o vibe code esconde:
- Dívida técnica que você nem sabe que contraiu. O agente pode ter resolvido o problema de um jeito que funciona hoje e vira um pesadelo de acoplamento amanhã. Você não vai perceber, porque você não leu.
- Decisões de arquitetura tomadas por quem não conhece o seu domínio. O agente não sabe que aquele fluxo tem uma regra de compliance por trás. Ele otimiza pro que parece certo, não pro que é certo no seu contexto.
- Zero capacidade de debugar. No dia que quebrar — e vai quebrar — você vai estar de frente com um código que nunca foi seu. Boa sorte.
Vibe code transfere a autoria pro agente e mantém a responsabilidade com você. Esse é o desequilíbrio que ninguém comenta.
AI pair programming: a IA escreve, você continua sendo o engenheiro
Pair programming clássico é aquilo de dois devs, um teclado. Um dirige, o outro revisa em tempo real, questiona, aponta o caso de borda que o primeiro não viu. A dupla produz um código melhor do que qualquer um dos dois sozinho.
AI pair programming é a mesma dinâmica, só que o “driver” é a IA e o “navigator” é você. O agente escreve — rápido, incansável, cobrindo boilerplate que você odeia digitar — mas cada linha passa pelo seu crivo. Você lê o diff. Você entende a abordagem. Você discorda quando faz sentido discordar e manda refazer. Você é quem carrega o modelo mental do sistema na cabeça.
A diferença prática não está na quantidade de código que a IA gera — nos dois casos ela gera muito. A diferença está em quem entende o código no final. No pair programming, quem entende é você. No vibe code, ninguém.
Na prática, o AI pair programming se parece com isto:
- O agente propõe, você avalia o trade-off. “Deu certo” não basta; a pergunta é “é a melhor forma dado o resto do sistema?”.
- Você segura a rédea da arquitetura. As decisões estruturais continuam sendo suas — o agente executa dentro dos limites que você define.
- Você mantém a habilidade de ler, revisar e debugar o próprio projeto, porque nunca deixou de estar por dentro dele.
O ganho de produtividade é real e é enorme. Mas ele vem de acelerar o desenvolvedor, não de substituí-lo.
Onde isso importa
A tentação de deslizar do pair programming pro vibe code é grande, e ela cresce junto com a confiança na ferramenta. Quanto melhor o agente fica, mais fácil é parar de ler o diff. É aí que o desenvolvedor experiente se separa do resto: não é sobre desconfiar da IA, é sobre nunca abrir mão de entender o próprio sistema.
Minha régua é simples. Se eu não consigo explicar por que aquele código está do jeito que está, eu não deveria ter feito merge. Não importa se foi eu, um colega ou um agente que escreveu.
A IA mudou quem digita. Ela não mudou quem é responsável.