Karpathy: o Vibe Coding Virou Engenharia
Andrej Karpathy voltou ao palco da Sequoia Capital para dar nome a uma transição que muita gente já sente no dia a dia, mas ainda não conseguiu organizar em linguagem: o momento em que programar com IA deixa de ser apenas uma brincadeira produtiva e passa a exigir disciplina operacional.
O vídeo, publicado pela Sequoia Capital, parte de uma confissão curiosa. Karpathy, um dos nomes mais importantes da IA moderna, diz que nunca se sentiu tão atrasado como programador. Não por falta de capacidade técnica, mas porque a própria definição de programar está mudando rápido demais.
A era do software com IA não elimina a engenharia. Ela apenas transfere a parte difícil para especificação, verificação e julgamento.
O ponto de virada do vibe coding
Karpathy descreve dezembro como um ponto de inflexão. Até então, agentes de código eram úteis, mas ainda exigiam correções constantes. A experiência era familiar: pedir um trecho, revisar, ajustar, pedir de novo, corrigir a direção.
Em algum momento, essa dinâmica mudou. Os blocos de código começaram a sair bons o suficiente para que ele pedisse mais. E mais. E mais. A confiança no sistema aumentou até que a prática virou aquilo que ele havia popularizado como vibe coding: construir software por intenção, iteração e sensação de direção, sem controlar cada detalhe manualmente.
O ponto importante é que Karpathy não trata isso como uma curiosidade de produtividade. Para ele, o vibe coding elevou o piso. Mais pessoas agora conseguem criar software. Protótipos, automações, apps internos e experimentos saem do papel com muito menos atrito.
Mas elevar o piso não é o mesmo que preservar o teto.
A diferença entre brincar com agentes e fazer engenharia
A distinção mais importante do vídeo aparece quando Karpathy separa vibe coding de agentic engineering.
Vibe coding é liberdade. É a sensação de que qualquer pessoa pode transformar uma ideia em software funcional. Agentic engineering é outra coisa: é coordenar agentes poderosos sem abandonar a barra de qualidade que software profissional exige.
Essa diferença parece pequena, mas muda tudo.
Um agente pode escrever código rápido. Isso não significa que ele entende o modelo de negócio, a ameaça de segurança, o fluxo de pagamento, a fronteira entre usuários ou a consequência de escolher o identificador errado para associar créditos a uma conta. Karpathy cita um exemplo prático: um agente tentou reconciliar dados de Stripe e Google usando e-mail como elo entre contas. Funcionava no caso feliz. Era uma péssima decisão de produto e segurança.
Esse é o novo trabalho do engenheiro: não lembrar se a API usa dim, axis, reshape ou transpose, mas saber o que precisa ser verdadeiro para o sistema fazer sentido.
Software 3.0 não é só código mais rápido
Karpathy também retoma sua tese de Software 3.0. Software 1.0 era código escrito explicitamente. Software 2.0 era programação por dados e pesos aprendidos. Software 3.0 é a programação por contexto: prompts, documentos, imagens, instruções e estado operacional viram a interface com um novo tipo de computador.
Essa leitura é mais radical do que parece.
Se o LLM é um computador, então a pergunta muda. Não é apenas “como escrevo o mesmo sistema mais rápido?”. A pergunta passa a ser: “que sistemas agora não precisam existir do jeito antigo?”.
O exemplo do menu é didático. Karpathy criou um app que recebia foto de cardápio, fazia OCR, identificava pratos, chamava um gerador de imagem e remontava uma interface com fotos. Depois percebeu que a versão Software 3.0 era simplesmente entregar a imagem a um modelo multimodal e pedir que ele produzisse o resultado final sobre o próprio cardápio.
O app intermediário, nesse caso, era resíduo do paradigma anterior.
Essa é uma das leituras mais úteis para produto: muita coisa que hoje parece startup pode ser apenas uma ponte temporária até o modelo absorver a tarefa inteira.
A vantagem está onde existe verificação
Outro eixo forte da conversa é a verificabilidade. Karpathy argumenta que os modelos avançam primeiro onde o resultado pode ser verificado com clareza. Código, matemática, testes automatizados, xadrez, ambientes de reinforcement learning: todos esses domínios oferecem feedback objetivo.
É por isso que agentes parecem tão fortes em programação e tão estranhos em perguntas simples de senso comum. O mesmo sistema pode refatorar um codebase enorme e tropeçar em uma decisão banal fora dos circuitos mais treinados.
Essa irregularidade é o que ele chama, em outras palavras, de inteligência recortada. O modelo não é uniformemente inteligente. Ele tem picos impressionantes em áreas valorizadas pelos laboratórios e buracos em regiões menos treinadas, menos verificáveis ou menos presentes na distribuição.
Para quem constrói produto com IA, isso é um mapa estratégico.
Não basta perguntar se uma tarefa “parece automatizável”. A pergunta melhor é: existe uma forma confiável de verificar se a saída está certa? Se existe, dá para criar loops, avaliações, dados sintéticos, fine-tuning e ambientes de melhoria. Se não existe, o humano continua muito mais no centro.
O novo gargalo humano é entendimento
A frase mais importante do vídeo talvez não seja técnica. Karpathy menciona uma ideia que ficou na cabeça dele: você pode terceirizar o pensamento, mas não pode terceirizar o entendimento.
Essa frase organiza a ansiedade atual melhor do que quase qualquer gráfico de produtividade.
Agentes podem escrever funções, resumir documentos, gerar telas, buscar bugs e operar ferramentas. Mas alguém ainda precisa entender o que vale construir, por que aquilo importa, quais restrições não podem ser violadas e onde a solução está apenas parecendo correta.
Esse ponto conversa diretamente com a ideia de LLM Wiki, que o próprio Karpathy defende. Uma wiki mantida por LLM não serve só para armazenar informação. Ela serve para reprojetar informação em formatos que aumentam entendimento humano. O objetivo não é retirar o humano do loop. É melhorar a qualidade do humano que dirige o loop.
Infraestrutura precisa nascer agent-native
Há também uma crítica prática à infraestrutura atual. Karpathy observa que quase tudo ainda é escrito para humanos: documentação, dashboards, menus, telas de configuração, fluxos de deploy, DNS, permissões.
Mas um mundo de agentes operando com contexto local e permissões reais exige outra superfície. Em vez de documentação que diz “clique aqui”, a pergunta passa a ser: qual é o bloco de instruções que meu agente consegue executar com segurança?
Isso aponta para uma mudança relevante em SaaS, DevOps e plataformas de desenvolvimento. A próxima infraestrutura vencedora talvez não seja apenas mais bonita para humanos. Ela será mais legível para agentes.
APIs, MCPs, logs, permissões, ambientes reproduzíveis, comandos idempotentes e documentação copiável deixam de ser detalhes técnicos. Viram produto.
A minha leitura
O vídeo de Karpathy é importante porque tira o debate de IA para programação da camada do entusiasmo. Sim, o vibe coding é real. Sim, mais gente vai construir software. Sim, a velocidade aumentou.
Mas o recado central é menos confortável: quanto mais fácil fica produzir código, mais caro fica não saber o que se está fazendo.
A vantagem deixa de estar em decorar sintaxe. Ela passa para a capacidade de especificar bem, verificar bem, decompor problemas, entender trade-offs e perceber quando o agente entregou algo que apenas parece correto.
No fim, agentic engineering não é o fim da engenharia. É a volta da engenharia por outro caminho.
O programador que só escrevia código perde parte do território. O engenheiro que entende sistemas, produto, segurança, dados e operação ganha um campo muito maior para atuar.