Vibe coding vs. engenharia agêntica

A L01 te mostrou que o Claude Code age: edita arquivo, roda comando, te entrega resultado. Esta lição é sobre a decisão que vem antes de cada pedido: quanto você vai conferir o que ele fez.

Os dois modos: dois jeitos de revisar o mesmo trabalho

Toda vez que você abre uma sessão e pede algo pro Claude, você está num de dois modos de trabalho. O que separa os dois é quanto você vai conferir o resultado. Vale igual pra quem está começando e pra quem programa há dez anos.

No , você descreve o que quer e aceita o que vem com revisão leve. Roda, olha se funciona, segue. O termo é do Andrej Karpathy, que ao cunhá-lo descreveu o estado de espírito assim (tradução livre do original em inglês): você se entrega às vibes, embarca no ritmo exponencial das ferramentas, e esquece que o código existe (Karpathy no X, 02/02/2025). É rápido e libertador pra protótipo descartável, pra exploração, pra "será que dá pra fazer isso?".

Na , você continua sendo o engenheiro. O agente faz mais (escreve mais código de uma vez, mexe em mais arquivos), mas você lê o diff, exige teste, e o mantém na coleira. Você continua responsável pelo que sai dali, do mesmo jeito que era antes de existir agente.

Karpathy: o piso e o teto

Karpathy separa as duas em duas alavancas. No original: "Vibe coding is about raising the floor for everyone in terms of what they can do in software" e "Agentic engineering is about extrapolating the ceiling." O vibe coding levanta o piso: quem nunca escreveu uma linha de Python consegue agora montar software. A engenharia agêntica estica o teto: o profissional preserva a barra de qualidade entregando muito mais rápido. Em ambos os casos, você continua responsável pelo resultado. Nas palavras dele: "You are not allowed to introduce vulnerabilities because of vibe coding. You are still responsible for your software, just as before." Ou seja, você não está autorizado a introduzir uma vulnerabilidade só porque estava vibe-codando; continua respondendo pelo software como antes.

E o que ele coloca como a linha que separa as duas: "You can outsource your thinking, but you can't outsource your understanding". Você pode terceirizar o pensamento, mas não o entendimento. O agente executa; entender o que foi construído continua sendo seu trabalho.

Fonte: writeup do próprio Andrej Karpathy sobre sua fala no Sequoia AI Ascent 2026.

A decisão que vem antes do prompt: declarar o modo

O erro comum é não escolher. Você começa "só testando" no modo vibe, o protótipo funciona, você gosta, e vai empilhando feature em cima sem nunca trocar de marcha. Aí aquilo virou o produto e ninguém revisou o caminho de pagamento.

Declarar o modo na largada resolve isso porque ele define a sua : o quão duro você confere o que o Claude produziu antes de aceitar. Modo vibe, régua baixa: roda e olha. Engenharia agêntica, régua alta: lê o diff linha por linha, pede o teste, confere a borda onde dado externo entra.

A régua não é arbitrária. Ela acompanha quão barato é, pra você, conferir o resultado. Karpathy coloca assim (tradução): o computador tradicional automatiza o que você consegue especificar em código; o LLM automatiza o que você consegue verificar (Karpathy, Sequoia Ascent 2026). Onde dá pra rodar e checar o resultado de graça (gerar código que tem teste, extrair estrutura de um texto), você pode dar autonomia alta. Onde a checagem é cara ou ambígua (decisão de produto, dinheiro, dado sensível), você puxa a autonomia pra baixo e revisa de perto.

Uma ressalva que vale pra quem trabalha com dados: "barato de conferir" pressupõe que você sabe conferir. Pedir pra transformar um CSV parece barato porque o código roda, mas se o Claude somar a rubrica errada ou inverter um filtro, o resultado vem plausível e errado, e você só pega se confere o número contra a fonte. Quando o output é um dado que outra pessoa vai ler como verdade, trate como régua alta mesmo que o código tenha rodado limpo: confira uma amostra contra o dado bruto.

Esse controle de "quanto de autonomia" é o que Karpathy chama de autonomy slider na fala Software Is Changing (Again) (Y Combinator, junho de 2025): o quanto você deixa o agente correr sozinho numa tarefa. No Claude Code esse controle aparece como modos de permissão que você troca durante a sessão com shift+tab. O atalho cicla por três: default (o normal, ele pede aprovação antes de editar ou rodar comando), acceptEdits (auto-aceitar edições: ele aplica as mudanças sem perguntar a cada uma) e plan mode (o Claude planeja e você aprova antes de ele tocar em qualquer arquivo). Menos autonomia: você aprova passo a passo. Mais autonomia: ele segue sozinho. Você não precisa decorar isso agora. Só saiba que o controle existe e que você vai usar esses modos de verdade mais pra frente (modos de permissão, docs do Claude Code).

Arraste o controle abaixo de "vibe" pra "agêntico" e veja cada parada mapear num controle concreto do Claude Code, e a régua de revisão subir junto. Repare que ela anda no sentido inverso: quanto mais autonomia você dá, mais barato o resultado precisa ser de conferir.

controle no Claude Codeplan mode (shift+tab)

régua de revisão

Régua máxima: você aprova o plano antes de qualquer arquivo mudar.

Regra: autonomia alta só onde o resultado é barato de verificar.

O mesmo pedido, dois modos

Pega uma tarefa real e veja o que o modo muda. O Claude pode escrever o mesmo código nos dois casos; o que muda é o quanto você confere antes de aceitar.

antes · text

MODO VIBE  (régua baixa)

- "faz aí e me mostra rodando"
- bato o olho: o número na tela
parece certo?
- aceito, sigo pra próxima coisa
- ok pra: protótipo na sua
máquina, pra você ver se a
ideia presta

depois · text

ENGENHARIA AGÊNTICA  (régua alta)

- "guarda o valor em centavos como
inteiro, nunca em float. mostra
o diff. escreve teste pro cálculo
do desconto, com arredondamento."
- leio o diff, rodo o teste
- confiro a borda: e se o
desconto vier negativo?
- obrigatório pra: qualquer
recibo que um cliente real vai
receber

O cálculo de centavos é o exemplo perfeito de por que a régua sobe. Float é como o computador guarda número com casa decimal, e ele faz isso de um jeito aproximado: por isso somar 0.1 + 0.2 não dá 0.3, dá 0.30000000000000004. Num recibo, essa sobra invisível vira centavo a mais ou a menos no valor que o cliente recebe. A saída é guardar dinheiro como número inteiro de centavos (R$ 19,90 vira 1990) e só dividir por 100 na hora de mostrar.

É o tipo de erro que o teste pega e a revisão de olho não. Régua alta aqui significa pedir, junto com o código, uma verificação que falha sozinha se a conta sair errada. Por exemplo:

// tudo em centavos como inteiro; desconto como percentual inteiro (10 = 10%)
function totalComDesconto(valorCentavos: number, descontoPct: number): number {
  // Math.round mantém o resultado inteiro — nada de centavo quebrado de float
  const desconto = Math.round((valorCentavos * descontoPct) / 100);
  const total = valorCentavos - desconto;
  // sanity check: o total tem que ser inteiro e não pode ficar negativo
  if (!Number.isInteger(total) || total < 0) {
    throw new Error(`total inválido: ${total} centavos`);
  }
  return total;
}

// trava o caso clássico de arredondamento
// 10% de R$19,90 = R$1,99 de desconto → R$17,91 = 1791 centavos
expect(totalComDesconto(1990, 10)).toBe(1791);

Esse par (o if que estoura se a conta sair de centavo inteiro ou negativa, e o expect que fixa o número esperado) é a régua virando código: se um dia o cálculo mudar e quebrar, ele acusa antes do cliente. É exatamente o que o modo vibe deixa passar e a engenharia agêntica trava.

O mapa pro mercado brasileiro

Pra escolher o modo, faça uma pergunta sobre a tarefa antes de pedir qualquer coisa: o que ela toca? A resposta já te entrega o modo.

Descartável → vibe coding. Protótipo que roda só na sua máquina, script que você joga fora depois, "será que dá pra raspar essa página". Ninguém de fora vê, nada quebra se estiver errado. Régua baixa: rode, olhe, siga. É aqui que o vibe coding ganha: você explora rápido sem pagar pedágio de revisão.

Toca um usuário real → engenharia agêntica. Qualquer coisa que uma pessoa de fora vai ver ou usar: uma tela, um formulário, um endpoint público. Vale mesmo quando seu produto não cobra nada: numa ferramenta de transparência que mostra gasto público, publicar o número errado sobre uma pessoa custa tão caro quanto um bug de pagamento. Erro aqui é visível e custa confiança. Régua alta: leia o diff, teste o caminho feliz e a borda, e confira o dado exibido contra a fonte antes de a página ir pro ar.

Mexe em dinheiro / centavos → engenharia agêntica, régua no talo. Cálculo de valor, cobrança, desconto, imposto. Conferir depois que o dinheiro errado saiu é caro. Régua máxima: assertion no cálculo, teste com arredondamento, diff lido com atenção. É onde o próprio Karpathy escorregou no MenuGen, no quadro logo abaixo.

Toca dado sensível / LGPD → engenharia agêntica. CPF, e-mail, qualquer dado pessoal. Vazamento não tem /clear. Régua alta na prática: confira onde o dado entra (de qual campo, de qual upload), como ele é guardado (em texto puro ou com acesso restrito) e quem consegue ler depois. E não exponha dado pessoal numa tela ou log público sem necessidade.

Karpathy vibe-codou um app e travou na parte de virar produto

O próprio Karpathy fez esse caminho com o MenuGen (você fotografa um cardápio, o app gera imagem de cada prato). O protótipo local saiu rápido e foi divertido, vibe coding puro; ele conta que se sentia "80% done" quando na real estava "closer to 20%". O custo veio depois, ao virar app de verdade no ar: ele descreveu essa etapa como "a bit of a painful slog as a deployed, real app", algo como "uma arrastada dolorosa", com a parte chata sendo deploy na Vercel, variáveis de ambiente, autenticação (Clerk), DNS e pagamento (Stripe).

O bug de pagamento mostra por que dinheiro pede régua alta. Nas palavras dele, o Claude "tried to match up the email addresses, but the email the user might give in the Stripe checkout may not be the email of the Google account they signed up with". Ou seja, tentou casar o pagamento ao usuário pelo e-mail, mas o e-mail do checkout do Stripe nem sempre é o mesmo da conta de login, então o pagamento podia ficar pendurado na pessoa errada. Karpathy apontou o erro e o Claude corrigiu passando o ID único do usuário nos metadados da requisição ("passing around unique user ids in the request metadata"). Quem lê o diff pega esse tipo de erro de integração; quem aceita de leve, recebe a denúncia do cliente que pagou e não viu o produto.

Fonte: Vibe coding MenuGen, Andrej Karpathy.

Lab: escreva seu mapa antes de precisar dele

Leva uns 5 minutos e te deixa com um critério pronto pra usar, em vez de decidir no calor da hora.

Liste 5 tarefas do produto que você está construindo. Coisas concretas que você vai pedir pro Claude nas próximas semanas. Ex: "tela de criar recibo", "script que importa o CSV do banco uma vez", "cálculo do valor com imposto", "página pública de listagem".

Marque cada uma com o que ela toca. Use as quatro perguntas: é descartável? toca usuário real? mexe em dinheiro? toca dado sensível? A primeira que der "sim" já decide o modo: qualquer "sim" em usuário, dinheiro ou dado puxa pra engenharia agêntica.

Escreva a régua de cada uma em uma linha. Para as de régua alta, seja específico no que você vai exigir: "leio o diff", "peço teste do arredondamento", "confiro onde o CPF é guardado". Esse é o seu mapa modo → régua de revisão. Guarde onde você for achar de novo: ele vira input dos prompts que você escreve.

Você terminou quando

Você consegue, diante de uma tarefa nova, dizer em voz alta qual modo ela pede e por quê, apontando o que ela toca (descartável, usuário, dinheiro, dado), e descrever a régua de revisão que vem junto, sem precisar pensar muito.