Minha configuração de autoaperfeiçoamento no Claude Code: fiz o Claude Code treinar a si mesmo!

Ver no idioma original →

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: My Self Training Claude Code Setup: I Made Claude Code TRAIN ITSELF! · Canal: AICodeKing · 14:59 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Claude Code, Engenharia de prompts e contexto

Resumo

O vídeo mostra como adaptar o padrão do AutoResearch para testar e aperfeiçoar as instruções de uma skill de correção de bugs no Claude Code, sem alterar o modelo subjacente. O apresentador propõe um experimento controlado, com tarefas de desenvolvimento, testes de avaliação fixos e tarefas separadas para medir se os resultados se generalizam. Ele explica como comparar versões das instruções, registrar tentativas e limitar custos, destacando que uma melhora nas tarefas de treino não prova, por si só, uma melhora geral. A recomendação é começar pequeno e adotar mudanças apenas quando elas também funcionarem em tarefas novas.

Pontos-chave

• O experimento altera as instruções e o workflow em torno do Claude, não o modelo subjacente.
• O AutoResearch fornece um ciclo de hipóteses, experimentos e avaliação, mas é preciso definir uma métrica clara.
• A avaliação deve usar tarefas e testes fixos que o otimizador não possa modificar.
• Cada tentativa deve começar em um projeto limpo e usar condições consistentes, incluindo modelo, ferramentas e limites.
• Tentativas com falhas comuns ou timeouts contam como não resolvidas; problemas de infraestrutura devem interromper a avaliação.
• Tarefas reservadas, não usadas durante a busca, ajudam a verificar se os ganhos se generalizam.
• O histórico deve incluir resultados de tentativas descartadas, além de métricas de sucesso, tempo e custo estimado.
• O custo total inclui as execuções de avaliação e o próprio trabalho do otimizador; por isso, é importante definir limites.
• Uma mudança de instruções só deve ser adotada após revisar o diff e confirmar o desempenho em tarefas novas.

Capítulos

Início	Capítulo	Resumo
00:01	A ideia de testar instruções automaticamente	O vídeo apresenta o AutoResearch e propõe aplicar seu ciclo de experimentação às instruções de uma skill de correção de bugs.
02:44	Configuração do experimento e do avaliador	O apresentador descreve a instalação do plugin, a criação da skill e a construção de tarefas e testes fixos para avaliar as correções.
05:27	Execuções controladas e métrica de sucesso	O vídeo explica como validar o avaliador, isolar as sessões e medir tentativas com limites consistentes de tempo e execução.
08:04	Busca por instruções melhores	O AutoResearch recebe um escopo, uma métrica e um comando de verificação, enquanto cada mudança é examinada e comparada com as anteriores.
10:44	Generalização, custos e adoção das mudanças	O apresentador recomenda testar as instruções em tarefas reservadas, calcular os custos e adotar mudanças somente após verificar ganhos em trabalho novo.

Citações

E se o Claude pudesse testar diferentes versões dessas instruções e descobrir quais realmente o ajudam a escrever código melhor? — 00:35

Uma instrução mais longa não significa automaticamente um agent de codificação mais inteligente. — 02:11

O worker pode alterar o projeto descartável. O otimizador pode alterar as instruções. As regras de avaliação permanecem fixas. — 04:23

Se o desempenho melhora no desenvolvimento, mas fica igual ou pior nas tarefas reservadas, não demonstramos uma melhora transferível. — 11:14

Comece pequeno, mantenha a métrica fixa e procure ganhos que persistam além dos exemplos usados na busca. — 14:28

Conceitos e entidades

• autoresearch (conceito): Padrão experimental em que um agent altera um sistema, executa avaliações e mantém ou descarta mudanças conforme os resultados.
• Claude Code (ferramenta): Ferramenta de codificação usada no vídeo para executar tarefas de correção de bugs seguindo instruções configuráveis.
• Uditcoen (pessoa): Nome associado na transcrição ao plugin comunitário de AutoResearch usado com Claude Code.
• Andrej Karpathy (pessoa): Criador do projeto original de AutoResearch citado como inspiração para o padrão experimental.
• bug fix (conceito): Skill proposta para orientar a compreensão do comportamento relatado, a correção focada e a verificação de bugs.
• Python (ferramenta): Linguagem usada nas pequenas tarefas de correção e no auxiliar de avaliação do experimento.
• Git (ferramenta): Sistema usado para registrar a versão inicial das instruções e inspecionar o histórico de alterações.
• Node.js (ferramenta): Tecnologia necessária, segundo o vídeo, para os hooks dos plugins.

Tradução completa (pt-BR)

00:01 [música] Oi, bem-vindos a mais um vídeo. Antes de começar, tenho publicado muitos tutoriais de projetos open source de que gosto também em vídeos exclusivos para membros. Estou publicando com mais regularidade. Então, se quiser apoiar o canal, clique no botão de participar. Os vídeos estão disponíveis em todos os níveis, a partir do bronze. Então, pode conferir. Agora, de volta ao vídeo. Passamos muito tempo dizendo ao Claude Code como trabalhar. Leia primeiro os arquivos relevantes. Reproduza o bug. Não reescreva metade do projeto. E, por favor, execute os testes antes de me dizer

00:35 que está tudo pronto. Mas e se Claude pudesse testar diferentes versões dessas instruções e descobrir quais realmente o ajudam a escrever código melhor? Essa é a ideia que vamos explorar hoje com auto research e Claude Code. Um ciclo automatizado de experimentos pode melhorar o workflow que Claude usa para resolver tarefas de programação? Vamos configurar um pequeno experimento de correção de bugs. Vamos dar a Claude um arquivo de instruções. Ele poderá aprimorá-lo e avaliar as mudanças em tarefas nas quais ainda não praticou. O modelo Claude subjacente permanece o mesmo. O que muda é o workflow que colocamos ao redor dele. E essa distinção importa, porque um arquivo de instruções mais longo

01:06 não significa automaticamente um agent de programação mais inteligente. Então, vamos direto ao assunto. Primeiro, o que é auto research? O projeto original de Andre Karpathy oferece a um agent de programação uma pequena configuração de treinamento de modelo. O agent altera o código de treinamento, executa um experimento, verifica uma métrica de avaliação fixa e mantém ou descarta a mudança com base no resultado. Depois, repete o processo. O histórico dos experimentos mostra quais ideias ajudaram e quais falharam. O repo original foi criado para treinar em uma GPU NVIDIA, com um limite de treinamento de 5 minutos para cada experimento. Isso não é uma promessa de que todo experimento termina em 5 minutos, porque

01:39 a inicialização e a avaliação também levam tempo. Neste vídeo, vamos aproveitar esse padrão experimental e aplicá-lo a um workflow de programação. Não precisamos executar a configuração original de treinamento do modelo nem comprar uma GPU para experimentar com as instruções de Claude. Vamos usar o plugin comunitário de auto research de Uditcoen para Claude Code. Ele nos dá um ciclo geral no qual especificamos um objetivo, um escopo editável, uma métrica e um comando que verifica o resultado. O plugin pode coordenar os experimentos, mas ainda precisamos definir o que significa um bom resultado. Essa provavelmente é a parte mais importante de toda esta configuração. Se eu disser: “Faça

02:11 Claude programar melhor”, não há uma linha de chegada clara. Se eu disser: “Resolva mais destas tarefas congeladas de correção de bugs, sob os mesmos limites”, aí temos algo que podemos verificar no experimento. Vamos criar uma skill chamada bug fix. As instruções iniciais são deliberadamente razoáveis: entenda o comportamento relatado, faça uma correção pontual, execute as verificações relevantes e resuma a mudança. Não vou dar instruções iniciais péssimas só para fazer a versão otimizada parecer boa. A questão interessante é se o ciclo consegue melhorar um workflow que realmente poderíamos usar. Agora vamos configurar

02:44 tudo. Você vai precisar de Claude Code, git, Python para o pequeno auxiliar de avaliação e Node.js para os hooks dos plugins. Comece em uma pasta de experimento separada, com um repo git limpo. Deixe de fora deste experimento seus aplicativos reais e qualquer trabalho não commitado. Abra o Claude Code e digite /plugin marketplace add, seguido do repo de auto research de Udit Guanka mostrado na tela. Em seguida, digite /plugin install, seguido de autoresearch at autoresearch. Inicie uma nova sessão do Claude depois da instalação para que o plugin e seus arquivos de referência sejam carregados corretamente. Você pode

03:16 usar /auto research: plan para seguir as etapas de configuração. Para nosso experimento em si, vamos fornecer explicitamente a métrica e o comando de verificação. Então, usamos o ciclo clássico de experimentos. Agora, crie a pasta da skill bugfix dentro de .claude e, dentro dessa pasta, a pasta skills. Crie skill.md com o nome, a descrição e as instruções iniciais das notas da gravação. Esse é o arquivo que o otimizador pode revisar. Mantenha fixa a identidade e a forma de invocação da skill. Estamos experimentando com as instruções dela. Também precisamos de uma cópia da versão inicial. Salve-a separadamente e registre o commit do git

03:51 antes de fazer qualquer melhoria. Caso contrário, não haverá uma base confiável para comparar com a versão final. Mas instalar o plugin não nos dá um benchmark universal de programação. Precisamos construir essa parte para o nosso experimento. Incluí um prompt de configuração que pede a Claude que crie um pequeno auxiliar de avaliação com casos de teste separados para cada tarefa, testes de classificação fixos e um registro de resultados. Esse auxiliar é código do nosso próprio experimento, não um recurso que vem incluído no auto research. Este é o trabalho básico que vamos pedir a ele. Comece cada tentativa com uma cópia limpa de um projeto com bugs. Inicie uma nova sessão de Claude com uma versão das instruções do

04:23 workflow. Deixe Claude tentar corrigir o problema e, depois, classifique os arquivos resultantes com testes controlados pelo avaliador. O worker pode alterar o projeto descartável. O otimizador pode alterar as instruções do workflow. As regras de classificação permanecem fixas. Essa separação é importante. Queremos descobrir instruções melhores para corrigir código. Se o ciclo puder reescrever o gabarito, uma pontuação maior nos diz muito pouco. Para o conjunto de desenvolvimento, use três pequenos bugs em Python cujo comportamento possamos descrever com precisão. Um pode envolver a remoção de duplicatas preservando a ordem. Outro pode envolver tratar zero incorretamente como um valor ausente. E outro pode envolver

04:55 alterar acidentalmente a lista de entrada de quem chamou a função. Essas tarefas são pequenas o suficiente para inspecionarmos na tela, mas ainda nos permitem testar se Claude considera comportamentos além do primeiro exemplo de caso ideal. Na tarefa de remoção de duplicatas, por exemplo, retornar um conjunto pode remover os valores repetidos, mas pode violar o tipo de saída ou a ordenação exigidos. Nossos testes devem verificar o contrato real, incluindo uma entrada vazia e valores repetidos em posições diferentes. Separe algumas tarefas diferentes para a avaliação final. Não inclua essas tarefas nem as respostas delas no feedback de desenvolvimento do otimizador. E, antes de pagarmos por um monte de execuções do Claude, teste o próprio avaliador.

05:27 Forneça a implementação sabidamente defeituosa e confirme que ela falha. Forneça um patch correto e revisado e confirme que ele passa. Depois, tente um patch que exclua um teste de classificação ou modifique um arquivo proibido e garanta que o avaliador o rejeite. Confira também o que acontece quando uma execução excede o tempo limite ou a autenticação falha. Uma tentativa incompleta não pode ser silenciosamente considerada aprovada. Essas verificações nos dizem se a ferramenta de medição funciona. Ainda não nos dizem se o workflow de Claude melhorou. Agora, vamos falar sobre como iniciamos as sessões de teste. Porque

05:58 há um detalhe aqui que, caso contrário, pode arruinar a comparação. Se cada execução herdar memórias, plugins ou uma conversa antiga diferentes, não estaremos mais comparando apenas os arquivos de instruções. Para a versão controlada deste experimento, o auxiliar usa o modo de impressão do Claude com a flag --bare. O modo bare ignora a descoberta automática habitual de skills, plugins, memória e arquivos CLAUDE.md. Depois, fornecemos explicitamente as instruções do workflow usando --append-system-prompt-file. O auxiliar extrai o corpo das instruções do arquivo da skill. Assim, as duas versões são inseridas da mesma maneira. Isso significa que este experimento

06:29 mede o conteúdo das instruções. Não mede se Claude escolhe automaticamente a skill certa em uma lista longa. Há também uma questão de cobrança. O modo bare não usa o login da sua assinatura normal do Claude. Você precisa de uma chave de API ou das credenciais apropriadas do provedor, e essas chamadas de teste são cobradas por essa via. Então, se quiser usar apenas sua assinatura, pode ensaiar o processo manualmente em sessões novas, invocando a mesma skill a cada vez. Apenas descreva isso como uma comparação menos controlada, em vez de apresentá-la como idêntica a esta configuração. O comando exato está nas notas. Fixamos o modelo e o nível de esforço, usamos as mesmas ferramentas, definimos os mesmos

07:02 limites de turnos e de tempo e salvamos os metadados da resposta junto com o código resultante. Agora, estamos prontos para verificar a configuração de base. Primeiro, execute um teste rápido sem pontuação, com as instruções originais, para conferir se um worker real é iniciado e se o patch dele é avaliado. A linha de base completa será a iteração zero do auto research, antes de ele alterar a skill. Isso evita pagar duas vezes pela mesma linha de base completa. Para as tentativas pontuadas, verifique se o código corrigido passa nos testes congelados, permanece dentro dos arquivos permitidos e termina dentro dos limites. Nossa pontuação principal é a porcentagem de todas as tentativas programadas

07:33 que passem por todas as verificações exigidas. Falhas comuns e timeouts ainda contam como tentativas não resolvidas. Um problema de infraestrutura deve interromper a avaliação, em vez de reduzir silenciosamente o denominador. Um patch que corrige o exemplo relatado, mas quebra um comportamento existente, não conta como tarefa resolvida. Também estamos registrando o tempo decorrido e o custo estimado do modelo. Esses são números complementares úteis, mas uma resposta rápida e incorreta não supera uma resposta correta e mais lenta. Repita os testes, porque o mesmo modelo pode tomar decisões diferentes para a mesma tarefa. Para este pequeno experimento, usaremos três tentativas novas

08:04 por tarefa de desenvolvimento e manteremos essa quantidade igual para todos os candidatos. Não continue executando uma versão até ela ter sorte. Decida o número de tentativas antes de analisar os resultados. Depois que o teste de fumaça funcionar e o avaliador estiver congelado, podemos passar as instruções para a pesquisa automática. O objetivo é melhorar a taxa de sucesso na correção de bugs, respeitando os limites existentes. O escopo é apenas nosso arquivo de skill de correção de bugs. A métrica é a porcentagem de aprovação no desenvolvimento, em que um valor maior é melhor, e o comando de verificação executa nosso helper de avaliação nesse arquivo. Estou definindo três iterações para a

08:36 primeira busca real. Isso significa três revisões candidatas depois da linha de base, em vez de uma execução noturna sem limite. Também estou instruindo o agent a fazer uma mudança de instrução específica por candidato, preservar o nome da skill e descartar os candidatos que não melhorarem a pontuação. Qualquer problema com o avaliador deve interromper o experimento, em vez de provocar uma reformulação conveniente das regras de avaliação. O escopo do plug-in e as configurações de iteração são instruções para o agent. Não são um sandbox do sistema de arquivos nem um limite de gastos garantido. Portanto, o controlador da avaliação ainda precisa de suas próprias restrições e condições de parada.

09:08 Agora, vamos enviar isso e ver que hipótese ele propõe. Uma ideia possível é exigir uma reprodução concreta antes de editar. Outra é inspecionar as funções que chamam aquela função antes de alterar o valor retornado. Uma terceira possibilidade é verificar um caso de limite relacionado ao bug relatado antes de declarar a tarefa concluída. Esses são exemplos de candidatos, não resultados que estamos presumindo de antemão. A mudança real deve vir das falhas no desenvolvimento e ficar visível no diff das instruções. Esta é a parte que eu mostraria com atenção no vídeo. Abra as instruções antigas ao lado das candidatas e leia a mudança. Depois

09:39 mostre a transcrição de um teste em que essa instrução tenha a chance de afetar o comportamento do worker. Se o candidato disser para reproduzir o problema primeiro, procure a reprodução. Se disser para preservar a entrada, observe o patch no teste externo que verifica se houve mutação. Estamos relacionando uma mudança nas instruções a um comportamento observável, em vez de tratar um parágrafo de recomendações confiantes como uma melhoria por si só. Depois da verificação, o loop registra a pontuação e se o candidato foi mantido ou descartado. Se ele tiver um desempenho pior, o experimento deve voltar às instruções que eram as melhores até então, em vez de basear a próxima mudança em uma regressão. Mantenha as tentativas malsucedidas no

10:11 log. Elas são evidências úteis do que a busca tentou, e escondê-las faria o processo parecer mais confiável do que realmente é. Além disso, inspecione o histórico do git e os arquivos reais. Um resumo dizendo que houve melhora é útil, mas os resultados registrados dos testes precisam comprová-la. Agora, é fácil se enganar nesta etapa. A pontuação de desenvolvimento pode melhorar porque as instruções ficaram extremamente específicas para os três exemplos. Talvez mencionem o nome de uma função específica ou codifiquem discretamente a correção esperada. Isso poderia fazer a próxima execução parecer incrível, sem ajudar em nada com o problema de programação de amanhã.

10:44 Então, depois das três revisões candidatas, congele a melhor versão. Agora compare as instruções originais e as otimizadas nas tarefas que mantivemos fora da busca. Use cópias novas do projeto e sessões novas do Claude novamente. Execute cada versão três vezes por tarefa, com os mesmos limites, e alterne a ordem para que uma versão não seja sempre executada primeiro. Não deixe o otimizador ver uma falha nesse conjunto final. Revise as instruções dele e, então, chame a próxima tentativa de teste não visto. Quando você usa esse feedback para ajustar o workflow, essas tarefas passam a fazer parte do desenvolvimento. Na tela de resultados, mostre o desempenho tanto no desenvolvimento quanto no conjunto reservado. Inclua o número de

11:14 testes, aprovações completas, timeouts, custo estimado e o tempo gasto nas tentativas bem-sucedidas. Há alguns resultados possíveis, e a interpretação deve acompanhar o que realmente acontecer. Se o candidato melhorar no desenvolvimento e também resolver mais tarefas novas, isso é uma evidência de que essas instruções ajudaram esse modelo nesse conjunto específico de tarefas. É um resultado útil. Embora um punhado de tarefas pequenas ainda não estabeleça uma melhoria universal na programação. Se o desempenho no desenvolvimento melhorar, mas os resultados do conjunto reservado permanecerem iguais ou piorarem, não demonstramos uma melhoria transferível.

11:46 A busca pode ter se ajustado demais aos exemplos, ou o ganho aparente pode ter sido ruído. E, se as duas versões resolverem todas as tarefas, teremos atingido o limite deste pequeno benchmark. Nesse caso, podemos comparar o custo e o tempo de conclusão bem-sucedida ou criar uma avaliação futura mais difícil. Não devemos alegar uma melhoria de qualidade que o teste não conseguiu medir. É por isso que eu não prometeria que deixar isso rodando durante a noite produz automaticamente uma configuração melhor do Claude. Um loop pode explorar uma métrica ruim com o mesmo entusiasmo que uma boa. Agora, vamos falar do custo, porque três iterações parecem muito mais baratas

12:19 do que podem ser na prática. Com três tarefas de desenvolvimento e três tentativas por tarefa, uma avaliação contém nove testes com Claude. A linha de base mais três avaliações de candidatos nos dão 36 execuções de teste. Depois, comparar duas versões em duas tarefas do conjunto reservado, três vezes cada, acrescenta mais 12. Isso dá 48 testes de programação, sem contar o próprio raciocínio e a configuração do otimizador, nem ensaios. Portanto, o plug-in de pesquisa automática é open source, mas o experimento não é gratuito só porque o loop está escrito em uma skill. Comece com um teste de fumaça de uma tarefa para verificar o mecanismo. Quando funcionar, decida quanto vale para você fazer a comparação completa e

12:52 defina limites antes de executá-la. O modo print do Claude oferece suporte a um orçamento máximo em dólares e a um número máximo de turnos por execução. Use esses recursos junto com um timeout externo e um controlador que pare de iniciar mais testes quando o experimento como um todo atingir o limite. Trate os valores em dólares informados como estimativas e deixe uma margem no orçamento. Além disso, contabilize o otimizador separadamente. Limitar um worker de teste não limita todas as outras sessões do Claude. O valor depende da frequência com que você reutilizará o workflow. Pode fazer sentido gastar tempo e dinheiro melhorando um processo que você usa todos os dias. Fazer uma busca grande para economizar alguns segundos em uma tarefa pontual provavelmente não faz. E, depois do

13:26 experimento, não substitua imediatamente toda a sua configuração do Claude. Revise o diff das instruções vencedoras. Remova tudo que estiver relacionado às tarefas de prática. Depois, trate essa versão editada como uma nova candidata que precisa ser verificada. Até uma limpeza bem-intencionada altera o que você avaliou. Se as instruções ainda ajudarem em tarefas novas, adote-as para esse workflow específico e mantenha a versão original disponível. Deixe as skills não relacionadas e as preferências globais como estão. Você também pode aplicar a mesma ideia a outras tarefas repetitivas. Uma skill de escrita de testes poderia ser avaliada pela capacidade dos testes de detectar defeitos conhecidos. Um

13:58 workflow de migração poderia ser verificado em relação a requisitos de compatibilidade definidos. Uma skill de revisão de código poderia ser avaliada pelos defeitos reais encontrados e pelos falsos positivos introduzidos. A métrica deve refletir o resultado que você realmente quer. Mais testes, revisões mais longas ou menos chamadas de ferramentas não são automaticamente resultados melhores. Então, a pesquisa automática e o Claude Code podem melhorar o próprio workflow de programação do Claude? Eles podem criar um loop de feedback útil em torno das instruções que o Claude segue; para saber se uma revisão específica é melhor, é preciso consultar os resultados de tarefas novas, não a descrição que o otimizador faz do próprio

14:28 trabalho. Pessoalmente, acho que vale a pena explorar isso para um workflow específico que você repete com frequência e consegue avaliar de forma confiável. Comece pequeno, mantenha o avaliador fixo e procure ganhos que se mantenham além dos exemplos usados durante a busca. Isso dá uma resposta muito mais útil do que simplesmente pedir ao Claude para reescrever suas instruções e torcer para que a nova versão seja melhor. No geral, é bem legal. Enfim, me contem o que acham nos comentários. Se gostaram deste vídeo, [música] considerem fazer uma doação pela opção Super Thanks ou se tornar membros clicando no botão Join. Além disso, deixem um gostei neste [música] vídeo e se inscrevam no meu canal. Vejo vocês

14:59 no próximo. [música] Até lá, tchau. Calor. Calor. >> [música]

Transcrição original

[00:01] [music] Hi, welcome to another video. Before starting the video, I have been posting many tutorials of open-source projects that I like in membersonly videos as well. I am posting more regularly. So, if you want to support the channel, please hit the join button and the videos are available on all tiers from bronze and up. So, please go ahead and check them out. Now, back to the video. So, we spend a lot of time telling Claude code how to work. Read the relevant files first. Reproduce the bug. Don’t rewrite half the project. And please run the tests before telling me

[00:35] everything is done. But what if Claude could test different versions of those instructions and figure out which ones actually help it write better code? That’s the idea we’re exploring today with auto research and Claude code. Can an automated experiment loop improve the workflow that Claude uses to solve coding tasks? We’re going to set up a small bug fixing experiment. Give Claude one instruction file. It can improve and evaluate the changes on tasks it hasn’t practiced on. The underlying Claude model stays the same. What changes is the workflow we put around it. And that distinction matters because a longer

[01:06] instruction file doesn’t automatically mean a smarter coding agent. So let’s get right into it. First, what is auto research? Andre Karpathy’s original project gives a coding agent a small model training setup. The agent changes the training code, runs an experiment, checks a fixed evaluation metric, and keeps or discards the change based on the result. Then it repeats that process. The experiment history tells it which ideas helped and which ones failed. The original repository is built around training on an NVIDIA GPU with a 5minute training budget for each experiment. That isn’t a promise that every experiment finishes in 5 minutes because

[01:39] startup and evaluation add time as well. For this video, we’re borrowing that experimental pattern and applying it to a coding workflow. We don’t need to run the original model training setup or buy a GPU to experiment with Claude’s instructions. We’ll use Uditcoen’s community auto research plugin for Claude code. It gives us a general loop where we specify a goal, an editable scope, a metric, and a command that verifies the result. The plugin can coordinate the experiments, but we still have to define what a good result means. That is probably the most important part of this entire setup. If I say make

[02:11] Claude better at coding, there is no clear finish line. If I say solve more of these frozen bug fixing tasks under the same limits, now we have something we can check for the experiment. We’ll create a skill called bug fix. The starting instructions are deliberately reasonable. Understand the reported behavior, make a focused correction, run the relevant checks, and summarize the change. I’m not going to give the baseline terrible instructions just to make the optimized version look good. The interesting question is whether the loop can improve a workflow we might actually use. Now let’s set everything

[02:44] up. You’ll need claude code, git, python for the small evaluation helper and node.js for the plugins hooks. Start in a separate experiment folder with a clean git repository. Keep your real applications uncommitted work out of this experiment. Open clawed code, then type /plugin marketplace ad followed by Udit Guanka’s autoresearch repository shown on screen. Next, type /plugin install followed by autoresarch at autoresarch. Start a new claude session after installation so the plugin and its reference files load properly. You can

[03:16] use /auto research colon plan to work through the setup. For our actual experiment, we’re going to provide the metric and verification command explicitly. So, we use the classic experiment loop. Now, create the bugfix skill folder inside.claude then skills inside that folder. Create skill.md with the name, description, and the starting instructions from the recording notes. That is the file the optimizer can revise. Keep the skills identity and invocation fixed. We’re experimenting with its instructions. We also need a copy of the starting version. Save that separately and record its git commit

[03:51] before making any improvements. Otherwise, there’s nothing reliable to compare the final version against. But installing the plugin doesn’t give us a universal coding benchmark. We need to build that part for our experiment. I’ve included a setup prompt that asks Claude to create a small evaluation helper with separate task fixtures, fixed grading tests, and a results log. This helper is our own experiment code rather than a feature that comes bundled with auto research. Here’s the basic job we’re giving it. Start every trial with a clean copy of a broken project. Launch a fresh Claude session with one version of

[04:23] the workflow instructions. Let Claude attempt the repair, then grade the resulting files with tests controlled by the evaluator. The worker can change the disposable project. The optimizer can change the workflow instructions. The grading rules stay fixed. That separation is important. We want to discover better instructions for repairing code. If the loop can rewrite the answer key, a higher score tells us very little. For the development set, use three small Python bugs with behavior we can describe precisely. One can involve removing duplicates while preserving order. Another can involve incorrectly treating zero as a missing value. And another can involve

[04:55] accidentally changing the caller’s input list. These are small enough to inspect on screen, but they still let us test whether Claude considers behavior beyond the first happy path example. For the duplicate removal task, for example, returning a set might remove repeated values, but it could violate the required output type or ordering. Our tests should check the actual contract, including an empty input and repeated values in different positions. Keep a couple of different tasks for the final evaluation. Don’t include those tasks or their answers in the optimizer’s development feedback. And before we pay for a pile of clawed runs, test the evaluator itself.

[05:27] Give it the known broken implementation and confirm that it fails. Give it a reviewed correct patch and confirm that it passes. Then try a patch that deletes a grading test or modifies a forbidden file and make sure the evaluator rejects it. Also check what happens when a run times out or authentication fails. An incomplete trial cannot quietly become a passing result. Those checks tell us whether the measuring tool works. They don’t tell us that Claude’s workflow has improved yet. Now, let’s talk about how we launch the trial sessions. Because

[05:58] there’s a detail here that can otherwise ruin the comparison. If every run inherits different memories, plugins, or an old conversation, we aren’t only comparing the instruction files anymore. For the controlled version of this experiment, the helper uses Claude’s print mode with the-bear flag. Bear mode skips the usual automatic discovery of skills, plugins, memory, and claude.md files. Then, we explicitly supply the workflow instructions using-append system prompt file. The helper extracts the instruction body from our skill file. So both versions are injected in the same way. That means this experiment

[06:29] measures the instruction content. It doesn’t measure whether Claude automatically chooses the right skill from a long list. There’s also a pricing catch. Bear mode doesn’t use your normal Claude subscription login. You need an API key or the appropriate provider credentials and those trial calls use that billing path. So if you only want to use your subscription, you can rehearse the process manually in fresh sessions with the same skill invoked each time. Just describe that as a less controlled comparison. Rather than presenting it as identical to this setup, the exact command is in the notes. We fix the model and effort level, use the same tools, set the same

[07:02] turn and time limits, and save the response metadata along with the resulting code. Now, we’re ready to check the baseline setup. First, run one unscored smoke trial with the original instructions to check that a real worker launches and its patch gets graded. The full baseline will be auto researches iteration zero before it changes the skill. that avoids paying for the same full baseline twice. For the scored trials, check whether the repaired code passes the frozen tests, stays within the allowed files, and finishes within the limits. Our main score is the percentage of all scheduled attempts

[07:33] that pass every required check. Ordinary failures and timeouts still count as unsolved attempts. An infrastructure problem should halt the evaluation rather than quietly shrink the denominator. A patch that fixes the reported example but breaks an existing behavior doesn’t count as a solved task. We’re also recording elapse time and estimated model cost. Those are useful supporting numbers, but a fast incorrect answer doesn’t beat a slower correct one. Repeat the trials because the same model can make different decisions on the same task. For this small experiment, we’ll use three fresh

[08:04] attempts per development task and keep that count unchanged for every candidate. Don’t keep rerunning one version until it gets lucky. Decide the number of attempts before looking at the results. Once the smoke test works and the evaluator is frozen, we can give auto research its instructions. The goal is to improve bug fixing success under the existing limits. The scope is only our bug fix skill file. The metric is the development pass percentage with higher being better and the verify command runs our evaluation helper against that file. I’m setting iterations to three for the

[08:36] first real search. That means three candidate revisions after the baseline rather than an unlimited overnight run. I’m also telling it to make one focused instruction change per candidate, preserve the skills name, and discard candidates that don’t improve the score. Any problem with the evaluator should stop the experiment rather than trigger a convenient rewrite of the grading rules. The plug-in scope and iteration settings are instructions to the agent. They aren’t a file system sandbox or a guaranteed spending limit. So, the evaluation controller still needs its own restrictions and stopping

[09:08] conditions. Now, let’s send it and see what hypothesis it proposes. One possible idea is to require a concrete reproduction before editing. Another is to inspect the functions callers before changing its return value. A third might be to check one boundary case related to the reported bug before declaring the task complete. Those are examples of candidates, not results were assuming in advance. The actual change should come from the development failures and be visible in the instruction diff. This is the part I would show closely in the video. Open the old instructions next to the candidate and read the change. Then

[09:39] show a trial transcript where that instruction has a chance to affect the worker’s behavior. If the candidate says reproduce the issue first, look for the reproduction. If it says preserve the input, look at the patch in the external test that checks for mutation. We’re connecting an instruction change to observable behavior rather than treating a paragraph of confident advice as an improvement by itself. After verification, the loop records the score and whether the candidate was kept or discarded. If it performs worse, the experiment should return to the previous best instructions instead of building the next change on top of a regression. Keep the unsuccessful attempts in the

[10:11] log. They’re useful evidence of what the search tried, and hiding them would make the process look more reliable than it is. Also, inspect the git history and the actual files. A summary saying improved is helpful, but the recorded trial results need to support it. Now, there’s an easy way to get fooled at this point. The development score can improve because the instructions have become extremely specific to the three examples. Maybe they mention a particular function name or quietly encode the expected fix. That could make the next run look amazing while doing nothing useful for tomorrow’s coding

[10:44] problem. So after the three candidate revisions, freeze the best version. Now compare the original and optimized instructions on the tasks we kept out of the search. Use fresh project copies and fresh clawed sessions again. Run each version three times per task with the same limits and alternate the order so one version doesn’t always get the first run. Don’t let the optimizer see a failure on this final set. Revise its instructions and then call the next attempt an unseen test. Once you use that feedback to tune the workflow, those tasks have become part of development. For the results screen, show both development and held out performance. Include the number of

[11:14] trials, complete passes, timeouts, estimated cost, and the time spent on successful attempts. There are a few possible outcomes, and the interpretation should follow what actually happens. If the candidate improves on development and also solves more fresh tasks, that’s evidence that these instructions helped this model on this particular task set. It’s a useful result. Although a handful of small tasks still doesn’t establish a universal coding upgrade. If development improves, but the heldout results stay flat or get worse, we haven’t demonstrated a transferable improvement.

[11:46] The search may have fitted the examples too closely, or the apparent gain may have been noise. And if both versions solve every task, we’ve hit the ceiling of this little benchmark. Then we can compare cost and successful completion time or design a harder future evaluation. We shouldn’t claim a quality improvement that the test couldn’t measure. That is why I wouldn’t promise that leaving this running overnight automatically produces a better clawed setup. A loop can explore a bad metric just as enthusiastically as a good one. Now, let’s come to the cost because three iterations sounds much cheaper

[12:19] than it can actually be. With three development tasks and three attempts each, one evaluation contains nine clawed trials. The baseline plus three candidate evaluations gives us 36 trial runs. Then comparing two versions on two held out tasks three times each adds another 12. That’s 48 coding trials before counting the optimizer’s own thinking setup or any rehearsals. So the auto research plugin is open source, but the experiment isn’t free just because the loop is written in a skill. Start with a one task smoke test to check the machinery. Once it works, decide what the full comparison is worth to you and

[12:52] set limits before running it. Claude’s print mode supports a maximum dollar budget and a maximum number of turns per run. Use those alongside an external timeout and a controller that stops launching more trials when the overall experiment reaches its limit. Treat the reported dollar amounts as estimates and leave room around the budget. Also, account for the optimizer separately. Limiting a trial worker doesn’t limit every other clawed session. The value depends on how often you’ll reuse the workflow. Spending time and money improving a process you use every day can make sense. Running a large search to shave a few seconds off a one-off task probably doesn’t. And after the

[13:26] experiment, don’t immediately replace your entire clawed configuration. Review the winning instruction diff. Remove anything tied to the practice tasks. Then treat that edited version as a new candidate that needs checking. Even a well-intended cleanup changes what you’ve evaluated. If the instructions still help on fresh work, adopt them for that specific workflow and keep the original version available. Leave unrelated skills and global preferences alone. You can apply the same idea to other repeated tasks as well. A test writing skill could be evaluated by whether its tests catch known defects. A

[13:58] migration workflow could be checked against fixed compatibility requirements. A code review skill could be measured on real defects found and false positives introduced. The metric should reflect the outcome you actually want. More tests, longer reviews, or fewer tool calls aren’t automatically better outcomes. So, can auto research and Claude code improve Claude’s own coding workflow? They can set up a useful feedback loop around the instructions Claude follows, whether a particular revision is better has to come from the fresh task results rather than the optimizer’s description of its

[14:28] own work. Personally, I think this is worth exploring for a narrow workflow you repeat often and can evaluate reliably. Start small, keep the greater fixed, and look for gains that survive beyond the examples used during the search. That gives you a much more useful answer than simply asking Claude to rewrite your instructions and hoping the new version is better. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, [music] consider donating through the super thanks option or becoming a member by clicking the join button. Also, give this [music] video a thumbs up and subscribe to my channel. I’ll see

[14:59] you in the next one. [music] Until then, bye. Heat. Heat. >> [music]