Karpathy deixou um agente otimizando seu LLM por 2 dias — encontrou 20 melhorias que transferiram para modelos maiores

Imaginem a cena. Andrej Karpathy, 39 anos, ex-diretor de IA da Tesla e cofundador da OpenAI, sentado no escritório de casa em Palo Alto numa terça-feira de março de 2026. Cheiro de café preto frio na caneca, monitor de 49 polegadas brilhando com gráficos de loss, ar-condicionado zumbindo no canto. Ele digita um arquivo prompt.md de quarenta linhas. Aperta enter. Levanta da cadeira. Vai dormir. Sai pra correr. Vive a vida.

Quarenta e oito horas depois, ele volta. Observe o que estava na tela: vinte propostas de melhoria. Vinte. Encontradas por um agente de IA que trabalhou sozinho — sem supervisão, sem pausa, sem café — sobre o código de treinamento do nanochat enquanto Karpathy fazia outra coisa. Todas as vinte reduziam a perda de validação. E quando ele aplicou todas juntas num modelo do dobro do tamanho, no dia seguinte, vinte de vinte funcionaram. Aditivas. Transferíveis. Sem cancelamento mútuo.

Vamos por partes, porque o tweet é denso e a implicação é ainda mais.

Primeiro o objeto. Karpathy tem um projeto chamado nanochat — um repositório no GitHub que implementa, em poucos arquivos legíveis, todo o pipeline de treinamento e inferência de um clone mínimo de ChatGPT. É projeto irmão do nanoGPT, o repositório pedagógico que ele lançou anos atrás para ensinar como treinar um GPT-2 em casa — o mesmo Karpathy que, mais recentemente, decretou o fim do 'vibe coding' e propôs a engenharia agêntica como novo paradigma para quem desenvolve com inteligência artificial.

A diferença é que o nanochat vai do tokenizador até a interface web final, num só lugar. Quem quiser, sobe uma máquina com 8 GPUs H100, roda um script único, e em quatro horas está conversando com o próprio LLM treinado do zero — exatamente o tipo de avanço prático que Andrej Karpathy situa no horizonte da década, não do trimestre. Custo aproximado: cem dólares.

Esse é o brinquedo. O experimento é outro.

O que é o autoresearch

Karpathy montou, em paralelo, um sistema chamado autoresearch. Ele descreveu o sistema como "uma receita, não um produto": um jeito estruturado de deixar um agente de IA — desses que rodam sobre Claude, GPT ou similar — iterar de forma autônoma sobre o código de treinamento do nanochat.

A ideia é simples e quase provocadora. O humano define o objetivo num arquivo de texto (prompt.md). O agente lê esse objetivo, propõe alterações no arquivo de treinamento (train.py), roda o treinamento, mede o resultado, compara com a baseline, decide se mantém ou descarta a mudança, e segue tentando. Considerem a divisão de trabalho: o humano escreve o critério de sucesso. A máquina executa a busca.

Em outras palavras: o agente faz, sozinho, aquilo que um pesquisador júnior faria sentado na frente do computador por uma noite inteira. Mexe num hiperparâmetro. Roda. Olha o resultado. Mexe noutro. Roda de novo. Anota o que melhorou.

Não é mágica. É exatamente o trabalho mais tedioso da pesquisa em machine learning, automatizado com paciência infinita.

O que aconteceu nos dois dias

Karpathy deixou rodando. Saiu do laboratório. Foi viver a vida.

Quando voltou, o agente havia testado dezenas de variações no modelo pequeno — uma rede neural com 12 camadas de profundidade. E havia encontrado 20 mudanças que reduziam a perda de validação. Perda de validação, para quem precisa do termo explicado, é a métrica que mede o quão bem o modelo prevê os próximos tokens em textos que ele nunca viu durante o treinamento. Quanto menor, melhor o modelo está aprendendo o idioma — e não apenas decorando o que viu.

Vinte melhorias num modelo é muito. Não é uma melhoria revolucionária — Karpathy não usaria essa palavra, e a coluna respeita o desprezo dele por superlativos —, mas é o tipo de coisa que, somada, faz diferença prática. A medida que voce processa o número, voce percebe o regime novo: aquilo que custaria a um pesquisador humano duas semanas de trabalho repetitivo, custou a um agente dois dias de execução silenciosa.

O ponto interessante, e foi este o ponto que ele ressaltou no tweet seguinte, vem agora.

A transferência para o modelo maior

No dia seguinte, Karpathy pegou as 20 mudanças encontradas pelo agente no modelo de 12 camadas e aplicou todas elas, juntas, num modelo de 24 camadas — o dobro do tamanho.

E todas funcionaram.

Todas, ele escreveu, eram aditivas (cada uma contribuía sem cancelar as outras) e transferíveis (o que melhorou no pequeno melhorou no grande).

Para entender por que isso é grande, é preciso lembrar de uma verdade incômoda do campo: descobertas em modelos pequenos quase nunca transferem direito para modelos maiores. Você passa três meses afinando uma técnica num modelo de brinquedo, escala para o de produção, e descobre que a melhoria desaparece. Acontece toda semana.

Por isso a comunidade desenvolveu um princípio prático: para saber se uma técnica é boa de verdade, você tem que testá-la em escala. E isso é caro. Custa GPU. Custa tempo. Custa energia.

O que Karpathy mostrou, ao deixar o agente rodando 48 horas no modelo pequeno, é que existe um corredor estreito mas real onde o teste barato no modelo pequeno PREVÊ o resultado no grande. Não para qualquer mudança. Mas para mudanças do tipo que o agente foi instruído a buscar — refinamentos de hiperparâmetro, ajustes de arquitetura, mudanças no schedule de treinamento.

Vinte de vinte transferiram. Vinte. De vinte.

Reparem na frase repetida: ela não é exibicionismo retórico. É a forma como o próprio Karpathy a registrou no tweet, e é a forma como pesquisadores de máquina dizem "isso aqui não foi sorte".

Por que isso importa para quem não treina LLM

Você pode estar lendo esta coluna e pensando: muito bonito, mas eu não treino modelos de linguagem em casa. O que isto tem a ver com a minha vida de programador, de gestor, de estudante?

A resposta tem três camadas.

A primeira camada é técnica. Se o experimento de Karpathy escala — e ele já está conversando publicamente com colaboradores sobre rodar o autoresearch em paralelo, em vários agentes ao mesmo tempo, para acelerar o ciclo —, então boa parte do trabalho diário de um pesquisador em machine learning passa a ser feita por agentes. Não substituídos, mas multiplicados. O pesquisador humano vira o que Karpathy chama, em outros tweets, de "human in the loop": quem define o objetivo, quem revisa o que o agente descobriu, quem decide o que vai para produção.

A segunda camada é metodológica. Pesquisa científica, em qualquer domínio que admita iteração rápida sobre uma métrica clara, está ganhando uma ferramenta nova. Não estamos falando ainda de descoberta de teoremas. Estamos falando de busca exaustiva inteligente sobre um espaço de hipóteses bem definido. Essa é uma fração enorme do trabalho científico aplicado, e essa fração está sendo automatizada de modo prático, agora, com ferramentas que qualquer um com algumas centenas de dólares por mês pode rodar.

A terceira camada é cultural. Karpathy fez questão de publicar o autoresearch como uma "receita" pública — não como produto fechado, não como API paga, não como serviço SaaS. É um arquivo markdown e um conjunto de padrões. Qualquer um que tenha um agente próprio pode aplicar a ideia ao próprio domínio.

Esta é a chave por trás de outro tweet recente dele, sobre o que ele chamou de "idea file": no novo regime, faz menos sentido compartilhar código rodando, e mais sentido compartilhar receitas que cada agente vai instanciar para o caso particular do seu usuário. Naturalmente, quem pensa em produto vai estranhar. Quem pensa em conhecimento vai aplaudir.

A leitura particular desta coluna

Imaginem outro personagem. Mateus Quiroga, 27 anos, engenheiro de ML iniciante numa fintech de São Paulo, terça-feira à noite, escritório vazio, ar-condicionado zumbindo, a quarta xícara de café já fria. Ele está rodando à mão, há três meses, exatamente o tipo de varredura de hiperparâmetros que o agente do Karpathy fez em dois dias. Cada experimento dele leva quatro horas. Cada gráfico ele plota na mão. Cada decisão ele anota num caderno físico, porque o gestor exige rastreabilidade.

No dia em que Mateus ler o tweet do Karpathy, ele vai sentir duas coisas ao mesmo tempo. A primeira é alívio — porque alguém finalmente disse o que ele já desconfiava: este trabalho podia estar sendo feito por máquina. A segunda é medo — porque, se o trabalho podia estar sendo feito por máquina, o que sobra para ele? A resposta, e é a leitura particular desta coluna, é: sobra a parte difícil. Sobra escrever a receita. Sobra revisar a curadoria. Sobra dizer não para o agente quando ele propõe algo bonito mas errado.

Está nascendo, neste experimento, uma figura nova: o pesquisador-supervisor. Alguém que não digita as iterações, mas que escreve com clareza o objetivo, define o critério de sucesso, revisa as descobertas, e descarta o que não faz sentido.

Karpathy é, hoje, esse profissional. Ele largou um agente trabalhando, foi dormir, e voltou para revisar 20 propostas e testar a transferência. O trabalho dele virou curadoria informada. O trabalho do agente virou execução paciente.

Quem programa em 2026 e ainda não experimentou esse padrão — escrever uma receita clara, deixar um agente iterar, voltar para auditar — está vivendo numa versão antiga do ofício. Considerem a hipótese mais incômoda: talvez o valor de um engenheiro, daqui pra frente, não venha mais do código que ele escreve, mas do prompt que ele escreve para outra coisa escrever o código. É uma migração de músculo. E migrações de músculo doem.

E, como Karpathy mesmo disse num outro tweet recente: nunca se sentiu tão atrasado como programador. Se ele se sente, vale a pena que nós também sintamos. Quando o pioneiro confessa que perdeu o passo, é porque a estrada virou outra coisa — e quem ainda não percebeu vai chegar atrasado num lugar que já mudou de nome.

Fonte original: tweets do @karpathy de 7 e 9 de março de 2026 (primeiro, segundo) e o repositório nanochat no GitHub.