De Passageiro a Dono: o que o Vibe Coding está escondendo de você

Vibe coding é o padrão de trabalho onde a pessoa manda prompt vago, aceita o que a IA cospe, roda e reza para funcionar. Não há especificação, não há revisão, não há entendimento do que foi gerado — só sensação e esperança. Funciona para demo. Não funciona para produto.

O problema não é a IA. É o sistema em volta dela. Sem contexto estruturado, o mesmo modelo produz outputs radicalmente diferentes: o Claude Code com CLAUDE.md bem escrito e regras explícitas gera código previsível; o mesmo Claude Code com prompt genérico gera código que compila e quebra em produção. A diferença que o aluno vê ao vivo na aula é essa.

Vibe coding tem prazo de validade porque três coisas convergem simultaneamente: o custo de token está subindo, a complexidade dos produtos gerados cresce (e vira dívida técnica invisível) e o mercado passou a exigir builders que entendem o que estão construindo. Quem só vibecoda constrói demo bonita — e vê tudo desmoronar no primeiro bug real.

O modelo econômico das assinaturas flat (Claude Pro, GPT Plus, Cursor Pro) não é sustentável para uso pesado. As plataformas absorvem margens negativas nos usuários power como estratégia de aquisição — inevitavelmente vão ajustar. Felipe mostra o caso concreto na aula: US$ 200 em duas horas rodando Codex sem controle. O agente executou livre, sem limite, sem entendimento do que estava sendo gerado.

A tendência dos próximos dois anos é clara: pagar por token vai dominar. Quem não entende o custo por chamada, quando parar, o que está sendo gerado, paga a conta sem saber por quê. A moral do Felipe: "Sem entendimento do que roda, você paga pra IA fazer errado."

Estratégia defensiva: escolher modelo por tarefa (Opus para arquitetura, Sonnet para dia a dia, Haiku para mecânico, local quando fizer sentido); usar prompt caching agressivamente; configurar limites por sessão; ter métricas de custo por feature. Quem controla essas variáveis paga uma fração do que quem depende de subscription para tudo.

Lock-in acontece quando trocar de modelo ou de harness vira reescrita do sistema. Todo mundo elogia o Claude — até o dia em que o modelo muda de preço, muda de contrato de API, ou é banido de uma jurisdição. Felipe usa o caso real do Claude Fable 5, banido pelo governo Trump para uso fora dos EUA, como evidência: quem tinha produto rodando em cima só do Fable 5 precisou reescrever de emergência.

O problema também aparece em nível de harness. Framework proprietário, fluxo customizado, prompt que só funciona em um sistema específico — tudo isso é lock-in. Se o fornecedor muda de rumo, você fica órfão com uma pilha inteira de código que só rodava lá.

Antídoto: arquitetura harness-agnóstica. É o que Felipe demonstra na aula com o PD Framework rodando o mesmo sistema em Claude Code e em OpenCode — o framework não sabe quem executa. As três primitivas: Markdown como contexto, scripts Python no core, skills como diretório. Um contrato de runtime com 8 capacidades que qualquer harness precisa implementar. "Você não precisa de 3 frameworks diferentes. Precisa de 1 contrato que qualquer runtime implementa."

Como era antes: 80% do tempo codando, 20% planejando. O tempo de digitação forçava reflexão — você pensava enquanto escrevia. Como é agora: agentes rodam por horas gerando código que ninguém revisa. A codificação virou barata; o entendimento do que foi gerado virou caro.

A virada mental que Felipe defende: 80% especificação, 20% execução. O tempo que você economizou codando deve voltar para especificar. Escrever RFC, revisar arquitetura, definir critérios de aceitação, desenhar o contrato do agente — tudo isso antes de qualquer linha de código ser gerada.

Na prática, essa inversão exige um artefato novo — a RFC — que substitui a revisão linha a linha do código. Você revisa a especificação (menor, mais legível, com decisões explícitas) e não o output (grande, gerado, cheio de detalhes irrelevantes). O agente executa contra a especificação; o desvio fica evidente.

RFC (Request for Comments) é um documento Markdown escrito antes de codar. Origem no processo de padronização de protocolos de internet — você propõe algo, pede revisão, só depois executa. Aplicado a desenvolvimento com IA, a RFC vira o contrato explícito entre você e o agente.

Campos mínimos de uma RFC útil: contexto (por que essa feature existe), entradas e saídas (dados envolvidos), regras de negócio (o que precisa ser garantido), validações (o que não pode acontecer), critérios de aceitação (como saber que deu certo), integrações (o que essa feature toca).

RFC é agnóstica a linguagem — descreve DDD e padrões, não Python vs. TypeScript. A mesma RFC gera código em qualquer stack. É esse nível de abstração que faz a IA parar de improvisar: quando o agente lê e segue o RFC, a taxa de alucinação cai drasticamente porque não sobra margem para chutar. Felipe usa uma analogia memorável na aula: "PRD é a feijoada. RFC é como cozinhar o feijão."

DRY (Don't Repeat Yourself) do Programador Pragmático não é sobre copy-paste de código. É sobre conhecimento: toda regra de negócio, decisão, estrutura tem uma representação única e autoritativa no sistema. Duplicar é criar dois pontos que vão divergir — é questão de quando, não de se.

A IA viola DRY por padrão porque otimiza para o problema imediato. Pediu função de validação de CPF? A IA escreve. Pediu de novo em outro contexto? Escreve de novo — possivelmente diferente. Agora você tem duas fontes da verdade para o mesmo conhecimento; quando a regra muda, você atualiza uma e esquece a outra.

Antídoto na aula: identificar a fonte única para cada tipo de conhecimento (validação, formatação, cálculo, regra), gerar ou linkar a partir dela — nunca copiar à mão. Configurar quality gate que detecta duplicação (jscpd, análise estática) e bloqueia merge quando aparece. Assim a fonte única deixa de ser convenção humana e vira restrição do sistema.

ETC (Easier To Change) é o segundo princípio: toda decisão de design se julga por "isso vai facilitar ou dificultar mudar depois?". Não é sobre extensibilidade especulativa (YAGNI). É sobre não amarrar o sistema desnecessariamente ao presente.

A IA viola ETC por padrão porque otimiza pro problema imediato e não pensa em mudanças futuras. Exemplos concretos: paths hardcoded no meio do código, IDs de serviço como constante, valores mágicos, decisões de negócio que vazaram pra 10 lugares diferentes. Quando você precisa mudar, precisa caçar tudo — e alguma sempre escapa.

Antídoto: camada de abstração entre a decisão e quem a usa. Env var em vez de constante hardcoded. Config file em vez de valor inline. Interface em vez de dependência direta. Não é design pattern por si só — é a pergunta: se essa decisão mudar amanhã, quantos lugares eu preciso tocar? Se a resposta for mais que um, tem violação de ETC.

Ortogonalidade é o terceiro princípio: componentes que não se afetam. Mudar um não quebra o outro. Se você toca no módulo A e precisa também mexer no B por causa de acoplamento invisível, isso é violação de ortogonalidade — o "se eu mexer aqui, tenho que ir lá também" é o sinal canônico.

A IA viola ortogonalidade por padrão porque gerar um bloco único é mais fácil que gerar componentes independentes que conversam via interface. O resultado: sistemas onde tudo depende de tudo, refatoração vira reescrita, testes ficam impossíveis.

Antídoto que Felipe defende na aula: você não pede pra IA escrever código componentizado — a IA não vai fazer sozinha. Você configura o quality gate que impede o contrário. Linter que limita linhas por função, linhas por arquivo, complexidade ciclomática. Regra do Felipe: "Você não pede pra IA escrever código limpo. Você configura o gate que impede o contrário."

Quality gate é o mecanismo automatizado que valida código antes do merge. Ao contrário do code review humano (que cansa, esquece, aprova por educação), o gate roda sempre, com os mesmos critérios, sem viés. Se o código gerado ultrapassa o limite (linhas por função, duplicação, complexidade), o gate bloqueia — a IA precisa refatorar.

Ferramentas úteis: ruff para Python (lint + estilo), radon para complexidade, jscpd para duplicação, eslint para JavaScript/TypeScript, mypy para tipos, bandit para segurança. Cada uma vira um portão que só abre se o critério passar. Configurados no CI, viram parte do fluxo — nenhum merge acontece sem passar por eles.

O princípio se estende para o próprio harness. Skills atômicas com limite de 70-80 linhas, um agente por skill, um squad por área. Mesmo raciocínio: não pede pra IA se autolimitar; o gate impede o contrário. O resultado é sistema que escala em complexidade sem virar bagunça.

Piso mínimo não é saber escrever Python do zero, não é entender algoritmos, não é ter formação em Ciência da Computação. É saber ler código o suficiente para entender se a IA fez o que você pediu; escrever RFC para especificar antes de executar; reconhecer as violações de DRY, ETC e Ortogonalidade como checklist de revisão; configurar um gate básico que bloqueia os piores casos.

Ordem de estudo sugerida por Felipe na aula: (1) lógica de programação básica — variável, condição, loop, função, import. (2) como ler e entender código — abrir script real e identificar o que cada linha faz. (3) system design introdutório — como as peças conversam. (4) DRY, ETC, Ortogonalidade na prática — do livro O Programador Pragmático.

A frase que fecha a aula: "No-code foi a porta de entrada. O que vai determinar quem continua no mercado daqui a 2 anos não é saber mais ferramentas — é entender o que as ferramentas estão fazendo."