O 'idea file' de Karpathy: por que, na era dos agentes, vale mais compartilhar a receita do que o aplicativo

A proposta foi esta: em vez de compartilhar o código do aplicativo, compartilhe o arquivo de ideia.

O nome em inglês é idea file. A coisa em si é um documento de texto, escrito em linguagem natural, descrevendo o que o programa deveria fazer, por que existe, qual é o critério de sucesso, quais são as restrições. Não é especificação técnica. Não é design doc. É a descrição honesta de um problema e de uma solução pretendida.

A intuição de Karpathy é a seguinte: na era em que cada usuário tem o próprio agente de IA capaz de programar, não faz mais tanto sentido distribuir um executável. Faz mais sentido distribuir uma receita. O agente de cada um lê a receita, conversa com o seu usuário sobre as preferências dele, e cozinha a versão particular daquele programa para aquela pessoa.

Quem nunca usou um aplicativo e pensou "se ele tivesse só esta funcionalidadezinha que serve pra mim, seria perfeito"? Pois é. Karpathy está apontando que esse último 5% de personalização — que sempre custou caro demais para ser feito por um humano — agora é barato.

Por que importa

Vamos pensar passo a passo no que isto destrava.

Primeiro, o produto de software como conhecemos foi desenhado para o caso médio. O Spotify funciona razoavelmente bem para milhões de pessoas porque foi otimizado para o ouvinte mediano. Quem é estranho, quem ouve em padrão estranho, quem precisa de algo que 99% dos usuários não precisam — esse fica de fora, sempre ficou.

A era do software sob medida diz: você não precisa do produto médio. Você descreve o seu caso particular para o seu agente, e ele constrói o tocador exato que você queria. Pode ser feio, pode não ter app store, pode rodar só no seu computador. Mas é seu.

Segundo, o gargalo do desenvolvimento muda de lugar. Antes o gargalo era escrever código. Agora o gargalo é descrever bem o que você quer. Karpathy está, indiretamente, defendendo que a escrita técnica clara vire uma habilidade central do profissional moderno — não a escrita técnica acadêmica, cheia de jargão, mas a escrita técnica honesta, do tipo "eu quero que faça isto, não quero que faça aquilo, o critério para eu saber que está pronto é o seguinte".

Quem souber escrever assim, multiplica.

A diferença entre receita e código

Vale a pena entender por que receita não é a mesma coisa que código.

Código é uma instância. É uma versão fixa, congelada num momento específico, com decisões específicas tomadas pelo autor original. Quando você baixa o código de outra pessoa, você herda todas as decisões dela: a linguagem, o framework, a estrutura de diretórios, a forma de armazenar dados, o estilo da interface.

Receita é uma intenção. É a descrição daquilo que o programa deveria fazer, separada da forma específica como faz. Quando você recebe uma receita, e a entrega ao seu agente, ele pode fazer escolhas diferentes das que o autor original faria — escolhas que se encaixam no SEU sistema, no SEU gosto, na SUA estrutura existente.

Karpathy compara isso, em outro tweet do mesmo período, ao que faz um cozinheiro caseiro com uma receita de família: ele não copia exatamente, adapta para o que tem em casa, para o gosto da mesa, para o tempo disponível. A receita sobreviveu gerações exatamente por isso — porque é flexível enquanto o prato pronto seria rígido.

O experimento da frequência cardíaca

O caso particular contado por Karpathy ilustra bem o ponto. Ele queria baixar a frequência cardíaca em repouso. Aplicativos de fitness existentes serviam mal: eram genéricos demais, mediam coisas demais, tinham gamificação demais.

O que ele queria era simples: um sistema que registrasse alguns poucos parâmetros (quantidade de cardio diário, qualidade de sono, hidratação, frequência matinal) e mostrasse se a tendência estava na direção certa. Sem distração. Sem medalhas. Sem notificação.

Em poucas horas, com o agente, ele tinha a coisa rodando. Não era bonita. Não era um produto. Mas resolvia exatamente o problema dele.

Agora imagine que ele compartilhe esse experimento. Antes, o caminho seria publicar no GitHub um repositório com o código inteiro. Quem usasse ia ter que adaptar à própria realidade — talvez o sistema operacional fosse outro, talvez o relógio inteligente fosse outro, talvez o critério de sucesso fosse outro. Adaptação manual, lenta.

A proposta nova é diferente. Ele compartilha o arquivo de ideia — o quê, por quê, como medir sucesso. Quem quiser, entrega ao próprio agente. O agente conversa com o usuário, descobre que relógio ele tem, que critério de sucesso faz sentido para ele, quanto tempo ele tem por dia, e constrói a versão personalizada naquela tarde mesma.

A receita viaja. A implementação fica.

A leitura particular

Eu, colunista brasileiro do Karpathy, leio este tweet com duas implicações práticas para o leitor do Mirante.

A primeira é técnica. Programadores, gestores e estudantes que leem esta coluna deveriam começar a manter um arquivo pessoal de ideias — coisas que eles gostariam que existissem, problemas pequenos que ninguém resolveu bem, pequenos automatizadores que melhorariam o dia. Antes, esse arquivo era uma lista de frustrações. Agora, é uma lista de programas que estão a uma sessão de Claude Code de existir.

A segunda é cultural. Estamos entrando na era em que a riqueza de software não é mais só o código aberto. É também a riqueza de intenções bem descritas. Um arquivo de ideia bem escrito vale ouro porque comprime, num parágrafo, o que antes precisava de mil linhas para existir.

Karpathy disse num dos tweets seguintes que esta era ainda está nascendo — que ele próprio está tentando entender as implicações. Ele não tem certezas. Tem uma intuição forte e algumas experiências.

Vale ler os tweets dele direto, e não só a tradução brasileira desta coluna. Os links estão abaixo. A ideia aqui é só atravessar a fronteira do idioma. O resto, cada leitor faz com o próprio agente.

Fonte original: tweets do @karpathy (experimento da frequência cardíaca, idea file viral, contexto adicional sobre autoresearch).