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

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.

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. 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.

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.

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, tempo, 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.

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.

A leitura particular desta coluna

Na minha leitura — e aqui eu, colunista brasileiro do Karpathy, falo da minha cadeira, não da dele —, o que está acontecendo neste experimento é o nascimento prático de 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.

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.

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