Karpathy Aposentou o Vibe Coding. O Substituto É Gestão de Produto.

Andrej Karpathy cunhou “vibe coding” no início de 2025. Em maio de 2026, segundo o relato de Jeff Gothelf, declarou o termo obsoleto e o substituiu por uma lista de atividades que qualquer líder de produto honesto reconhece de imediato.

Esse reconhecimento é a história.

A Lista Que Karpathy Usou Para Aposentar o Próprio Termo

Como Gothelf reconstrói a lista, Karpathy descreve o que a engenharia agêntica realmente exige: escrever specs de design, supervisionar planos, inspecionar diffs, escrever testes, construir loops de avaliação, gerenciar permissões, preservar qualidade.

Leia a lista duas vezes. Note o que não está nela. Digitar código. Decorar sintaxe. Escolher framework. Configurar build tool. As atividades que definiam “desenvolvedor” em 2015 estão ausentes. As atividades que definiam “gerente de produto” estão todas presentes.

Gothelf traça o paralelo de forma direta. Cada item da lista de Karpathy mapeia para uma atividade clássica de PM: definição de problema, priorização, validação de outcome, métricas de sucesso, alinhamento de escopo, julgamento de qualidade. O vocabulário mudou. O trabalho, não.

Por Que Essa É a Admissão Que Importa

Por dois anos, a conversa sobre desenvolvimento com IA foi uma conversa de engenharia. Quantas licenças de Cursor. Qual modelo. Qual agent loop. Qual IDE. A suposição implícita: isso é um problema de ferramentas, resolvido por compras e treinamento de engenharia.

A aposentadoria que Karpathy fez do próprio termo fura essa suposição. O trabalho de julgamento nunca foi o gargalo de engenharia. Era o gargalo de PM disfarçado de engenharia.

Quando um desenvolvedor aceita uma sugestão ruim da IA e dá deploy, a falha não foi o modelo alucinar. A falha foi ninguém ter escrito uma spec afiada o suficiente para tornar a alucinação óbvia. Quando um agente executa um comando perigoso, a falha não foi o agente. Foi a fronteira de permissão ausente. Quando um loop de avaliação não produz nada útil, a falha não foi o loop. Foi a ausência de uma métrica de sucesso com a qual alguém tenha concordado.

Cada uma delas é uma atividade de PM. Nenhuma é curada com mais licenças de Claude.

A Frase Que Deveria Estar na Parede de Todo CTO

A frase mais afiada de Gothelf cai aqui. “A versão administrativa de cada uma dessas atividades é automatizável agora, e será automatizada. A versão de julgamento é o trabalho.”

A versão administrativa de escrever uma spec é preencher um template. A versão de julgamento é saber o que o cliente ainda não consegue articular. A versão administrativa de inspecionar um diff é ler o arquivo. A versão de julgamento é saber quais 200 linhas de refactor são liquidamente positivas e quais são uma regressão vestida de código limpo. A versão administrativa de um loop de avaliação é instrumentá-lo. A versão de julgamento é escolher a métrica certa a medir.

A primeira coluna está sendo devorada por agentes em ciclos trimestrais. A segunda coluna é o que sobra. Karpathy, na prática, está dizendo a líderes de engenharia que vêm fazendo staffing da primeira coluna e ignorando a segunda.

O Que as Organizações Estão Fazendo de Errado Agora

Três padrões que vemos repetidamente em 2026:

Times de engenharia adicionando capacidade de IA sem capacidade de PM. Uma engenharia de 40 pessoas instala o Claude Code, vê um lift de 25% na primeira medição de throughput e decide que o gargalo agora é “mais tooling de IA”. Seis meses depois, o lift achatou. A investigação revela que o que falta não é mais tooling. É que os mesmos cinco gerentes de produto agora limitam o dobro do output de engenharia, e as specs que escrevem não se adaptaram a um mundo em que o executor lê literalmente.

PMs tratados como redatores de ticket, não como autores de spec. Na maioria das empresas, o papel de PM degradou na última década para gestão de stakeholders, triagem de tickets e teatro de roadmap. O pensamento de produto de verdade, o julgamento do cliente, a articulação de trade-offs, foi sendo espremido. Agentes de IA expõem isso na hora. Um agente alimentado com um ticket do tipo “melhorar o fluxo de onboarding” vai produzir alguma coisa. Se essa coisa está certa exige o trabalho de julgamento que PMs vêm sendo cada vez mais dispensados de fazer.

“Desenvolvedor assistido por IA” como título de cargo, sem equivalente em produto. Os anúncios de vaga em maio de 2026 estão cheios de “engenheiro aumentado por IA” e “engenheiro agêntico”. O cargo correspondente em produto não existe com a mesma nitidez. O mercado segue recrutando executores para um ambiente em que execução é cada vez mais automatizada, e subfinanciando os papéis de julgamento para um ambiente em que julgamento é a restrição que aperta.

O Que Fazer Segunda-Feira

Audite a qualidade das specs antes de auditar a escolha do modelo. Puxe as últimas dez specs que sua equipe entregou a agentes de IA. Pergunte: um júnior inteligente mas literal, sem contexto do seu produto, construiria a coisa certa a partir disso? Se a resposta for não, o gargalo está a montante do modelo. Nenhuma mudança de tooling vai resolver.

Empurre o trabalho de julgamento para o início do ciclo. Se o PM só entra na fase de teste de aceite, você já pagou pela iteração de engenharia. Com agentes produzindo código em minutos, esse custo de iteração caminha para zero, o que significa que o custo de julgamento domina. PMs precisam estar na sala quando a spec está sendo escrita, não quando o PR está em revisão.

Reframe desenvolvimento com IA como questão de staffing de produto. Pare de perguntar “temos engenheiros suficientemente fluentes em IA?” Comece a perguntar “temos pessoas suficientes que conseguem articular o problema certo de forma clara o bastante para um agente resolver?” São perguntas diferentes, com respostas diferentes, e a segunda é a que determina o resultado.

Pare de contratar PMs que não conseguem ler um diff. A versão de julgamento de “inspecionar diffs” exige letramento técnico. Um PM que nunca leu código não consegue avaliar se o refactor do agente está certo, só se a demo parece certa. Num mundo em que a demo sempre parece certa, isso não basta mais.

Construa o loop de avaliação como artefato de produto, não de engenharia. Critérios de avaliação para saída de IA são decisões de produto. O que conta como “bom”, quais thresholds de aceite valem, o que é regressão, não são perguntas técnicas. São perguntas de produto vestidas de técnica. Trate como tal.

O reframe que Karpathy está forçando é desconfortável para organizações que passaram dois anos se convencendo de que a virada de IA era um problema de compra e treinamento em engenharia. Não era. Sempre foi um problema de disciplina de produto. As ferramentas só tornaram impossível seguir ignorando.

As empresas que fizerem staffing para essa realidade agora vão compor ganhos. As que seguem contratando mais executores para um ambiente em que execução é grátis vão passar 2027 se perguntando por que o investimento em IA não trouxe os retornos que o deck prometia.

---

Fontes

• Jeff Gothelf. “Karpathy Said Vibe Coding Is Obsolete. What He Described Instead Is Product Management.” Maio de 2026.

A Victorino ajuda times de liderança a reposicionar desenvolvimento assistido por IA como problema de staffing de produto, construindo a disciplina de spec, validação de outcome e julgamento que determina se o stack agêntico de fato gera valor: contato@victorino.com.br | www.victorino.com.br