- O problema de simplesmente perguntar à IA 🤔
- Primeiro vem o garimpo 📚
- A saída é construir uma espécie de Wikipédia da pessoa 🔎
- A parte realmente interessante: transformar evidências em regras 🧠
- E se a IA estiver inventando a persona? 🚨
- A persona vira um agente de verdade 🤖
- O “run gate” é talvez a melhor ideia do projeto ⚙️
- Então isso é melhor do que simplesmente usar Claude? 💻
- Isso poderia funcionar com qualquer especialista?
- A ideia vai além de criar “clones” de especialistas
Principais destaques
- Conhecimento vira sistema: o método transforma textos, vídeos, códigos e posts públicos de um especialista em uma memória estruturada e rastreável.
- Regras, não imitação: o agente tenta reproduzir padrões de raciocínio, sempre vinculando cada regra a fontes e citações verificáveis.
- A IA precisa provar que fez: um mecanismo de verificação impede o agente de afirmar que um código funciona sem antes executá-lo e testá-lo.
A ideia parece simples, mas muda bastante a forma de construir agentes de IA.
Em vez de pedir ao Claude para “pensar como” uma determinada pessoa, o método tenta compilar o trabalho público desse especialista em um sistema operacional de raciocínio.
O experimento usou Andrej Karpathy como referência. O material inclui textos, palestras, repositórios de código e publicações em redes sociais.
O objetivo não é criar um chatbot que responda como Karpathy.
É fazer algo mais ambicioso: construir um agente que tenha acesso às regras que parecem orientar a maneira como ele resolve problemas.
O problema de simplesmente perguntar à IA 🤔
Modelos de linguagem são excelentes em produzir respostas convincentes. Isso não significa que sejam igualmente bons em explicar por que chegaram àquela resposta.
Esse detalhe fica especialmente importante quando o objetivo é aprender ou desenvolver software.
Segundo o texto, Karpathy já observou esse comportamento ao tentar usar Claude Code como uma espécie de professor enquanto programava. O modelo tende a privilegiar a produção do código em vez de explicar detalhadamente as decisões tomadas durante o processo.
O efeito colateral: você pode receber uma solução aparentemente boa sem necessariamente entender como ela foi construída.
Para quem está aprendendo, isso prejudica a compreensão.
Para quem está entregando software a um cliente, pode ser ainda pior. Quando alguma coisa quebra, fica mais difícil descobrir por que a solução funcionava ou onde estava a suposição errada.
A proposta do agente de persona é justamente transformar boas práticas de raciocínio em regras explícitas que o modelo precisa seguir.
💡 A diferença fundamental é sair de “o que esse especialista disse” para “quais regras parecem orientar a maneira como ele resolve problemas”.
Primeiro vem o garimpo 📚
O processo começa reunindo o máximo possível de material público relevante.
No experimento, isso inclui:
• vídeos e palestras;
• artigos e textos de blog;
• repositórios no GitHub;
• publicações no X;
• outros materiais públicos que revelem como o especialista pensa e trabalha.
Para vídeos do YouTube, o processo pode usar ferramentas como YouTube Transcript API e yt-dlp. Para o histórico do X, o projeto citado utiliza uma API paga.
A estratégia também é importante: em vez de mandar um único agente percorrer tudo sequencialmente, o trabalho pode ser dividido entre agentes responsáveis por diferentes fontes.
O resultado pode chegar a centenas de milhares de palavras.
Só que existe um problema.
Ter 700 mil palavras armazenadas não significa ter 700 mil palavras úteis para um agente.
É o equivalente digital de jogar centenas de livros em uma sala e dizer: “agora encontre a informação certa”.
A saída é construir uma espécie de Wikipédia da pessoa 🔎
O projeto transforma o material bruto em uma wiki baseada em arquivos Markdown interligados.
É aí que entra o Obsidian.
Mas há uma distinção importante: o Obsidian não é obrigatório. Ele funciona principalmente como uma interface visual para enxergar as conexões.
A estrutura pode existir simplesmente como arquivos organizados que o Claude Code consegue consultar.
Uma ideia apresentada em uma palestra pode, por exemplo, ser relacionada a:
- uma determinada técnica;
- um princípio de engenharia;
- outros textos que defendem a mesma abordagem;
- exemplos de aplicação;
- uma regra extraída pelo sistema.
Isso transforma documentos isolados em uma rede de conhecimento.
E essa rede é importante porque permite comparar evidências.
Uma ideia encontrada em uma única publicação casual tem um peso diferente de um princípio que aparece em entrevistas, palestras e códigos ao longo de vários anos.
A parte realmente interessante: transformar evidências em regras 🧠
É aqui que o projeto deixa de ser apenas um sistema de recuperação de informações.
Cada regra precisa estar associada a uma citação exata e a uma fonte rastreável.
Se não houver uma fonte clara, o agente precisa dizer que está fazendo uma inferência.
Essa exigência funciona como uma espécie de freio contra a invenção de personalidade.
No caso de Karpathy, o processo identificou sete regras principais:
1️⃣ Construa você mesmo: fazer algo é parte essencial de realmente compreendê-lo.
2️⃣ Ataque o primeiro termo: procure primeiro o fator fundamental do problema.
3️⃣ Faça uma previsão: diga o que espera que aconteça antes de executar o código e depois compare previsão e resultado.
4️⃣ Mostre o erro: apresentar a versão quebrada ajuda a explicar por que a correção funciona.
5️⃣ Demonstre: afirmações importantes devem ser comprovadas, não apenas declaradas.
6️⃣ Explicite premissas: não esconda pressupostos dentro da solução.
7️⃣ Prefira o simples: soluções mais simples devem ser priorizadas quando resolvem o problema.
O detalhe decisivo é que essas regras não deveriam existir simplesmente porque “a IA acha que Karpathy faria isso”.
Cada uma precisa apontar para evidências.
E se a IA estiver inventando a persona? 🚨
Esse é provavelmente um dos pontos mais importantes do método.
Imagine alimentar um modelo com milhares de posts de uma pessoa e pedir:
“Agora pense como ela.”
O modelo inevitavelmente preencherá lacunas.
Pode atribuir à pessoa opiniões que nunca foram expressas. Pode transformar uma observação isolada em princípio geral. Pode ainda misturar conhecimentos próprios com aquilo que realmente foi dito pelo especialista.
O sistema descrito tenta reduzir esse problema obrigando o agente a diferenciar:
evidência → regra → aplicação
Isso também torna possível clicar na regra e chegar à fonte original.
Em outras palavras, a persona deixa de ser uma espécie de “prompt mágico” e passa a funcionar como um sistema de conhecimento auditável.
A persona vira um agente de verdade 🤖
Depois de extraídas, as regras são transformadas em dois componentes.
Um deles é um subagente do Claude, com instruções e contexto próprios.
O outro é uma skill personalizada, que pode ser chamada diretamente para submeter uma tarefa ao conjunto de regras.
O agente também pode avaliar a própria resposta com base em uma checklist.
Isso cria uma diferença importante em relação a um prompt tradicional.
Um prompt diz ao modelo o que fazer.
Uma skill pode estabelecer um procedimento recorrente.
E um sistema com memória estruturada, regras rastreáveis e mecanismos de verificação começa a parecer mais com uma ferramenta especializada.
O “run gate” é talvez a melhor ideia do projeto ⚙️
Existe ainda uma camada particularmente interessante para programação.
O agente não pode simplesmente escrever:
“O código funciona.”
Ele precisa executar o código.
O mecanismo chamado de run gate verifica se isso aconteceu antes de permitir que o agente encerre sua tarefa.
Se o modelo produziu código mas não o executou, o mecanismo bloqueia a conclusão e manda o agente voltar ao trabalho.
Isso cria um ciclo:
prever → implementar → executar → comparar → corrigir → responder
Em vez de:
implementar → afirmar que funciona → torcer para estar certo
A diferença parece pequena no papel. Na prática, é enorme.
Especialmente porque agentes de programação têm justamente a tendência de produzir respostas convincentes antes de verificar todas as suas premissas.
Então isso é melhor do que simplesmente usar Claude? 💻
Nem sempre.
O próprio texto reconhece que construir o sistema dá trabalho. A coleta inicial pode levar quase uma hora, e ainda existe toda a etapa de organização, extração das regras e configuração do agente.
Para uma pergunta simples, é exagero.
Para trabalhos recorrentes, aprendizado técnico ou revisão de código antes de entregar algo a um cliente, a equação começa a mudar.
| Abordagem | Vantagem | Limitação |
|---|---|---|
| Prompt comum | Rápido e simples | Regras podem se perder entre conversas |
| RAG tradicional | Recupera informações relevantes | Não necessariamente captura como o especialista raciocina |
| Persona estruturada | Reproduz princípios e métodos | Exige preparação e manutenção |
| Persona + verificação | Une conhecimento, regras e testes | É mais complexo de construir |
🔄 E existe outra vantagem: o sistema não precisa ficar congelado.
Um novo vídeo, artigo, entrevista ou até uma gravação de voz transcrita pode entrar posteriormente no acervo.
A wiki pode ser atualizada, novas regras podem ser adicionadas e regras existentes podem ganhar novas evidências.
A persona passa, portanto, a funcionar como um sistema que aprende com o próprio arquivo de fontes.
Isso poderia funcionar com qualquer especialista?
Em princípio, sim.
O método não depende especificamente de Karpathy.
Um professor, pesquisador, programador, escritor ou especialista com produção pública suficiente poderia servir como fonte.
Mas há uma condição importante: volume não basta.
Diversidade e consistência são fundamentais.
Se existem apenas três posts de uma pessoa sobre determinado assunto, seria arriscado transformar aquilo em uma regra geral de pensamento.
Quanto mais fontes independentes apontarem para o mesmo comportamento, maior a confiança de que existe realmente um padrão.
A ideia vai além de criar “clones” de especialistas
O ponto mais interessante talvez não seja construir uma IA que imite Karpathy.
É construir uma metodologia para transformar conhecimento tácito em procedimentos explícitos.
Isso pode ser extremamente útil dentro de empresas.
Imagine, por exemplo, uma organização que possui um especialista com 20 anos de experiência.
Normalmente, parte desse conhecimento fica presa na cabeça dessa pessoa, em documentos antigos, apresentações, e-mails, códigos e decisões tomadas ao longo dos anos.
Um sistema desse tipo poderia tentar transformar esse acervo em:
fontes → conceitos → princípios → regras → agente → verificação
A grande promessa não seria criar uma cópia digital do especialista.
Seria tornar o conhecimento dele consultável, rastreável e reutilizável.
E existe uma ironia interessante nisso tudo: o objetivo de “pensar como um especialista” acaba exigindo algo bastante diferente de simplesmente pedir para uma IA imitar alguém.
É preciso primeiro descobrir como aquela pessoa realmente pensa, separar padrões de opiniões isoladas, provar as regras com evidências e depois criar mecanismos que obriguem o agente a segui-las.
No fim, a inteligência artificial continua sendo a ferramenta. O que muda é a qualidade do método usado para ensiná-la a trabalhar.
E talvez essa seja a parte mais importante: você pode terceirizar parte do acesso ao conhecimento de um especialista, mas ainda não terceirizou a compreensão.
