Vibe coding é furada (mas IA é seu melhor pair programming)
Vibe coding é você gerar código num prompt gigante, colar tudo, e esperar que funcione. Você não entende o que saiu. Não sabe por que funciona. Só espera que funcione e segue.
Passei por isso. Vi clientes passarem por isso. Vi devs iniciantes fazendo isso. É um caminho pra desastre.
Mas AI como pair programming é outra coisa completamente diferente. Aí sim, é produtivo.
O problema com vibe coding
Vibe coding é quando você:
- Descreve uma funcionalidade genérica (“faça um dashboard”)
- Claude ou GPT gera 500 linhas de React
- Você copia tudo pra seu projeto
- Apertou run e “funcionou”
- Você não mexe mais nisso
Três meses depois, precisa adicionar uma feature. Você abre o código e pensa: “Que porra é isso?”. Você não escreveu. Não sabe como funciona. Pode quebrar tudo tentando mudar.
Vi um cliente virar pra mim com um app que vinha sendo feito assim. Dashboard com 2mil linhas de código gerado. Ninguém lembrava como aquela parte de estado funcionava. Ninguém entendia por que aquele useEffect rodava em cada render. Refatorar foi pesadelo.
O custo real do vibe coding não é no dia um. É três meses depois quando você precisa dar manutenção e não sabe onde começa e termina a lógica.
Onde vibe coding bate você especificamente
Arquitetura se torna acidental
Você não projeta a arquitetura. Ela simplesmente emerge do que Claude gera. Se você pediu um component de tabela, ele pode vir com Redux integrado porque o modelo treinou em exemplos com Redux. Você não escolheu Redux. Só aconteceu.
Isso se multiplica. Um component aqui, outro ali. Tudo gerado. No fim, sua arquitetura é um frankenstein de decisões que ninguém tomou.
Segurança cai pro segundo plano
Claude não sabe do contexto real do seu app. Gerou um formulário? Pode estar sem CSRF protection. Gerou uma query? Pode estar sem prepared statements.
Vi um dev junior pegar código de autenticação gerado, colar direto em produção. Ninguém validava token. Ninguém checava permissions no backend. Funcionou até o dia que alguém descobriu que qualquer usuário podia acessar qualquer conta.
Debugging vira brincar no escuro
Quando você não entende o código, debugging vira adivinhar. Você coloca console.log em todo lugar. Testa inputs aleatórios. Espera que algo acenda uma luz.
Um projeto que acompanhei tinha um bug numa animação. O dev que pegou o componente gerado gastou 6 horas tentando entender por que requestAnimationFrame rodava errado. O código tinha um if que ninguém percebia que era a causa. Ninguém leu aquelas 80 linhas de CSS-in-JS.
Testes são deixados de lado
Se você usou vibe coding pra gerar o código, você não vai entender bem o suficiente pra escrever testes bons. Testes genéricos que passam? Sim. Testes que cobrem casos de edge? Não.
Aí entra AI como pair programmer
Pair programming com IA é diferente. Você está no controle. IA é seu copiloto, não quem faz as decisões.
Como funciona:
- Você projeta a arquitetura. IA não faz isso pra você.
- Você escreve um componente. IA completa ou refatora.
- Você pede ajuda com uma função complexa. IA escreve. Você entende, modifica, testa.
- Você escreve testes. IA sugere edge cases.
- Você sabe todo o código. IA só acelerou.
A diferença que muda tudo: você está fazendo o trabalho de entender.
Onde IA é ouro como pair
Boilerplate
Não há razão em digitar mais Redux boilerplate. IA escreve. Você entende porque leu. Economia: 20-30 minutos por slice.
Num projeto que fiz com Zustand, precisei de 4 stores. Sem IA, 2 horas digitando. Com IA como pair, 15 minutos: eu descrevia o store, IA gerava, eu verificava e pronto.
Testes
Escrever testes é tedioso. IA gera fixtures, mocks, casos de teste. Você verifica se cobrem o que importa.
Peguei uma função de validação com 15 casos de edge. Escrever todos os testes na mão demoraria 90 minutos. Passei pra Claude, em 30 segundos tinha 80% dos testes. Gastei 20 minutos ajustando os 20% que estavam errados.
Resultado: todos os casos cobertos, tempo total: 50 minutos versus 90. E aprendia o que eu não tinha pensado.
Refactoring e code cleanup
Um projeto herdado tinha código que passava por 5 devs diferentes. Ninguém entende por que aquele if estava lá. Certo dia, era hora de limpar.
Passei trechos de código pra Claude pedindo para refatorar. Ele sugeria extrair uma função, remover condições redundantes, simplificar nomes. Eu lia, concordava ou discordava. Isso levou horas, mas era horas de entendimento.
Vibe coding: eu pedia “refatore isso” e colava tudo de novo sem saber o que mudou.
Pair programming com IA: eu entendia cada mudança.
Trocas de tecnologia
Começou um projeto em uma tech, precisou mudar pra outra. Em vez de reescrever tudo manualmente, peguei componentes, passei pra Claude pedindo para converter de Vue pra React. Ele convertia. Eu testava. Uma hora de trabalho que seria meio dia manual.
Mas o importante: eu testava cada component. Não era vibe coding.
Casos reais que vi acontecer
O caso do banco integrado com IA ruim
Um dev era muito preguiçoso. Queria um sistema de banco integrado. Passou um prompt gigante pra GPT pedindo “construa um banco”. Recebeu um projeto inteiro com 3mil linhas.
Seis meses depois, precisava adicionar um tipo de transação novo. O código estava tão desorganizado que ninguém mexia. Demoraria refatorar do zero.
Resultado: 30 horas de trabalho que poderia ter sido 8 horas se tivesse sido feito com IA como pair.
O caso da clínica com IA boa
Uma clínica odontológica que eu trabalho agora tem um app de agendamento. Vez que precisam de ajustes, eu:
- Entendo o contexto (por que essa mudança?)
- Abro o código
- Passo trechos pro Claude
- Claude sugere mudanças
- Eu entendo, testo, faço merge
A app funciona. Tem testes. É manutenível. Porque não foi feita por vibe coding. Foi feita com IA como pair desde o início.
Como você distingue na prática
Se você está fazendo vibe coding, suas respostas são assim:
- “Como funciona? Não faço ideia, só colei”
- “Onde está a lógica de X? Boa pergunta”
- “Você consegue mudar Y sem quebrar Z? Talvez, deixa eu testar”
Se você está usando IA como pair:
- “Como funciona? Eu e o Claude projetamos assim: (explicação clara)”
- “Onde está a lógica? Nessa função, olha aqui”
- “Você consegue mudar Y? Sim, vai afetar Z, aqui está o plano”
Por que IA é melhor como pair que como autor
IA não sabe do seu contexto. Não sabe das trocas que você fez antes. Não sabe das limitações do seu projeto. Sabe linguagens. Sabe padrões.
Você sabe tudo aquilo acima. Você é o architect. IA é o desenvolvedor experiente que você consultou pra acelerar.
Melhor forma de usar IA em 2026: você pensa, IA acelera.
Pior forma: IA pensa, você coloca em produção.
Mudança que fiz no meu workflow
Comecei a impor uma regra pra mim mesmo:
- Entendo o código antes de fazer commit
- Se não entendo, eu reescrevo ou peço pro Claude explicar
- Sempre escrevo testes mesmo que IA tenha gerado o código
- Sempre reviso a arquitetura antes de gerar
Tempo extra? Sim, uns 15%. Mas reduz bug em produção em 70%. Manutenção fica mais rápida.
Checklist: usando IA sem cair em vibe coding
- Você entende a arquitetura geral do projeto (não IA)?
- Você escreve ou revisa 80%+ do código crítico (não gerado)?
- Testes são escritos por você, mesmo se IA sugeriu casos?
- Você consegue explicar por que aquela função existe do jeito que é?
- Código gerado foi testado antes de ir pra produção?
- Você poderia manter esse código em 6 meses se IA não existisse?
- A arquitetura foi decida por você, não emergiu do que IA gerou?
- Segurança foi pensada, não deixada ao acaso?
- Performance foi considerada, não assumida que é “boa o bastante”?
- Você consegue onboarding de um dev novo nesse código em menos de uma hora?
Quando IA pair programming falha
Pair programming com IA (vibe coding) � incr�vel 80% do tempo. Aqui est�o 3 cen�rios onde falha:
Falha 1: Quando o problema � amb�guo
Voc� escreve: “cria um componente de bot�o”. IA gera um bot�o. Mas voc� queria um bot�o com loading state, disabledstate, variants. IA precisava de mais contexto.
Resultado: 3 itera��es pra chegar no que voc� queria.
Solu��o: especifique antes de pedir. “Componente de bot�o com estados: default, loading, disabled, error. Tamanhos: sm, md, lg”.
Falha 2: Quando IA “acha que sabe” mas t� errado
Voc� pede uma integra��o com uma API obscura. IA gera c�digo. Parece bom. Voc� implementa. N�o funciona porque IA alucinrou um endpoint.
Resultado: 2 horas perdidas.
Solu��o: leia a documenta��o junto. Mande a doc da API junto no chat, IA usa aquilo como fonte verdadeira.
Falha 3: Quando refatorar quebra contexto
Voc� t� construindo um feature step-by-step. Primeiro passo, tudo bem. Segundo passo, voc� quer refatorar o primeiro passo. IA esquece do segundo passo e volta ao primeiro.
Resultado: c�digo fica inconsistente.
Solu��o: n�o refatore at� terminar. Termine a feature, depois refatore tudo junto.
Padr�o: quando NOT usar IA pair programming
- Problemas amb�guo (especifique primeiro)
- APIs undocumented (traga documenta��o)
- Refatora��es no meio (refatore ao final)
- Code review de terceiros (revise voc� mesmo)
Nesses casos, melhor usar IA como “pesquisador” que como “co-programmer”.
Leia também: Os 5 prompts que economizam minha semana | MCP server caseiro pro Claude | Entregar projetos rápido com IA