Ele finalmente multiplicou por 10 o Claude Code com este método

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: He Finally 10x Claude Code With This Method · Canal: AI LABS · 12:21 · Assistir no YouTube

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

Resumo

O vídeo apresenta o Karpathy loop: um fluxo em que um agent executa tarefas repetidamente, verifica resultados com critérios fixos e mantém as mudanças que funcionam. Os apresentadores explicam como montar esse fluxo com skills, agents especializados, checks aprovados e instruções em program.md. Ao testá-lo em funcionalidades de aplicativos, identificam que o loop não aprende automaticamente com erros anteriores. Para resolver isso, criam o auto loop, que analisa os resultados e atualiza as instruções para orientar melhor as próximas funcionalidades.

Pontos-chave

O Karpathy loop permite que um agent teste mudanças em ciclos e mantenha as que melhoram o resultado.
Loops são mais úteis em tarefas recorrentes, com uso de tokens disponível, critérios de avaliação claros e possibilidade de executar o que foi construído.
A skill project context reúne informações atualizadas sobre o aplicativo, como páginas, convenções e restrições.
A skill build coordena o fluxo, enquanto write checks prepara verificações antes da implementação e um programa aprova e protege os checks.
O feature builder agent começa cada tarefa com um context window separado, e os resultados de cada rodada são registrados.
No teste do formulário de pedidos, os checks passaram, mas o loop também precisou criar o formulário e conectá-lo às regras.
O auto loop examina resultados anteriores e atualiza a seção de instruções de program.md, sem poder alterar os checks.
Os exemplos mostram hábitos incorporados às instruções, como conectar cada funcionalidade ao aplicativo e verificar locais antigos que possam conflitar com novas regras.

Capítulos

Início	Capítulo	Resumo
00:00	O método de Karpathy e os loops	O vídeo explica como o método usa experimentos repetidos e critérios de avaliação para melhorar resultados sem orientar cada etapa manualmente.
02:33	Quando vale a pena usar um loop	Os apresentadores descrevem quatro condições para justificar a configuração de um loop e explicam a estrutura de skills e agents do fluxo.
06:39	Teste do fluxo e limites do primeiro loop	O teste de pedidos para retirada mostra que os checks podem passar sem cobrir toda a funcionalidade e revela que o loop não aprende de uma execução para outra.
08:46	O auto loop atualiza as instruções	O auto loop analisa os resultados de cada rodada, identifica erros recorrentes e registra novos hábitos em program.md sem alterar os checks.
10:49	Novos hábitos e resultados nos testes	O fluxo incorpora aprendizados sobre integração e compatibilidade e usa novas rodadas de checks para detectar e corrigir problemas em funcionalidades colaborativas.
12:21	Encerramento	Os apresentadores encerram o vídeo e informam que as skills e outros recursos estão disponíveis na comunidade AI Labs Pro.

Citações

O agent executou 700 experimentos e encontrou 20 mudanças que fizeram o modelo treinar mais rápido. — 01:32

Loops usam muitos tokens, inclusive nas rodadas que falham. — 03:04

Todos os 11 checks passaram na primeira rodada, então o loop não precisou de outra. — 08:15

O auto loop verifica problemas que continuam aparecendo, como o mesmo erro ou a mesma lacuna em duas funcionalidades. — 09:18

Na terceira rodada, o builder corrigiu o problema e passou nos 10 checks. — 11:50

Conceitos e entidades

Karpathy loop (conceito): Fluxo iterativo inspirado no método de Andre Karpathy, no qual um agent testa mudanças e mantém as que melhoram o resultado.
Auto Researcher (repo): Projeto mencionado no vídeo em que um agent fazia experimentos repetidos para melhorar o treinamento de um modelo.
Andrej Karpathy (pessoa): Pessoa associada ao método de experimentação iterativa apresentado no vídeo.
Claude Code (ferramenta): Ferramenta cujas configurações são usadas no fluxo para impedir que o agent edite a pasta de checks aprovados.
project context (conceito): Skill que armazena o contexto específico do aplicativo para que o agent consulte informações relevantes quando necessário.
write checks (conceito): Skill que cria verificações antes da implementação de uma funcionalidade.
feature builder agent (conceito): Agent que implementa cada funcionalidade em uma execução com contexto separado.
auto loop (conceito): Skill que analisa os resultados de um loop e atualiza as instruções para melhorar execuções futuras.
program.md (repo): Arquivo de instruções que descreve como executar as rodadas do loop e como o agent deve trabalhar.
Upstash Box (ferramenta): Serviço apresentado no vídeo que fornece sandboxes na nuvem para agents trabalharem isoladamente.
Shopify (empresa): Empresa citada como exemplo de uso de um loop para executar experimentos em um modelo.
AI Labs (empresa): Canal que apresenta o método e os testes descritos no vídeo.

Tradução completa (pt-BR)

00:00 As pessoas vêm usando ciclos para fazer agentes de IA construírem muitas coisas por conta própria. E o motivo de isso funcionar é o workflow estruturado por trás de cada ciclo. É por isso que as pessoas deixam seus agentes trabalharem em tarefas grandes por horas seguidas e estão obtendo bons resultados. Há muitas maneiras de configurar um desses workflows, e uma delas é o ciclo de Karpathy. Então, configuramos o ciclo de Karpathy em nossos próprios apps para ver como ele se sairia na prática. Ele se saiu bem, mas encontramos um problema que o ciclo não consegue detectar sozinho. Para resolver esse problema, fizemos uma alteração no ciclo. Se esta é a sua primeira vez, somos uma

00:30 empresa de software, e este é o nosso canal AI Labs. Neste vídeo, vamos mostrar o que é o ciclo de Karpathy, como configurá-lo nos seus próprios apps e qual alteração resolve esse problema. Mas, antes de [fungada] entrarmos no workflow, vamos falar sobre o método do próprio Karpathy, porque este ciclo foi criado com base nele. Se você não conhece ciclos, já temos um vídeo completo sobre eles no nosso canal. Você pode assistir para entender melhor os ciclos. Há algum tempo, Andre Karpathy criou um projeto chamado Auto Researcher, no qual um agente de IA continuava trabalhando no treinamento de um modelo e executava o código repetidamente até que o modelo realmente melhorasse. O

01:00 agente fazia isso em um ciclo, então não havia necessidade de orientar cada uma de suas etapas. No Auto Researcher, o agente só tinha permissão para alterar um arquivo, o arquivo que treinava o modelo. Cada rodada era um experimento em que o agente fazia uma alteração nesse arquivo de treinamento e, em seguida, treinava o modelo por alguns minutos. Depois disso, um segundo arquivo atribuía uma pontuação ao modelo. Se a pontuação melhorasse, o agente mantinha a alteração. Mas, se a pontuação continuasse igual ou piorasse, o agente desfazia a alteração. O agente não tinha permissão para mexer no arquivo de pontuação. Isso porque, se pudesse alterá-lo, bastaria facilitar a obtenção de uma pontuação melhor, em vez de

01:32 melhorar o modelo. E um terceiro arquivo, chamado program.md, dizia ao agente como executar cada rodada. O program.md era basicamente um arquivo de instruções que Karpathy escreveu em inglês simples. Karpathy escreveu esse arquivo de instruções e deixou o ciclo rodar por 2 dias. Nesse período, o agente executou 700 experimentos e encontrou 20 alterações que fizeram o modelo treinar mais rápido. Esse experimento mostrou que os agentes podem continuar trabalhando e verificar todas as possibilidades, algo que não seria possível se você controlasse cada etapa por conta própria. Isso porque controlar

02:02 700 experimentos por conta própria leva muito tempo, mas o agente os executou sozinho e encontrou diferentes métodos que funcionaram. O CEO da Shopify também executou o mesmo tipo de ciclo e obteve bons resultados. Ele o executou em um dos próprios modelos enquanto dormia, e o agente realizou 37 experimentos. Pela manhã, o desempenho do modelo estava 19% melhor. Assim, o método de Karpathy mostrou que, quando recebe apenas um objetivo, um agente pode continuar tentando coisas e melhorar por conta própria, sem que você oriente cada etapa. Foi aí que muita gente começou a se interessar por engenharia de ciclos. Agora, antes de [fungada] configurar um ciclo,

02:33 você precisa saber quando deveria usar um, antes de mais nada. Se usar ciclos para o tipo errado de tarefa, desperdiçará tokens e talvez nem consiga o que quer. Os ciclos são muito úteis quando usados nas situações certas, mas a situação adequada depende do que você está tentando realizar com a tarefa. Para valer a pena configurar um ciclo, a tarefa precisa atender a quatro requisitos. O primeiro é que você repita a tarefa com frequência. Leva tempo para criar um ciclo, e você só recupera esse tempo quando repete a tarefa. Então, para um trabalho que você faz uma única vez, um bom prompt é suficiente. Se configurar um ciclo para esse tipo de trabalho,

03:04 você passará mais tempo configurando-o do que realizando a tarefa em si. O segundo requisito é o seu limite de uso, porque os ciclos consomem muitos tokens. Em um ciclo, o agente lê o projeto novamente e tenta uma nova solução a cada rodada. Isso consome tokens até mesmo nas rodadas que falham. Por isso, um ciclo longo em um plano de US$ 20 atinge o limite de uso antes mesmo de o trabalho terminar. O terceiro requisito é que o trabalho possa ser verificado por algo que forneça uma pontuação clara. Em um app, isso é feito com pequenos trechos de código que testam um recurso e confirmam se ele funciona. O último requisito é que o agente consiga executar o que construiu e ver o que

03:35 dá errado, para saber o que corrigir na rodada seguinte. Usamos diferentes tipos de ciclos nos nossos workflows, mas apenas em tarefas com uma pontuação clara que possamos medir, e nunca deixamos um ciclo construir um app inteiro e damos o trabalho por concluído. Usamos ciclos apenas para construir um recurso de cada vez ou uma versão simples do app que as verificações do ciclo possam validar. Mas, antes de configurarmos tudo, seria ótimo se você se inscrevesse no canal e apertasse o botão de hype. Esse pequeno gesto de apoio significa muito para nós. Karpathy [fungada] compartilhou muitas informações sobre como trabalha com agentes de IA. Então, pegamos o que ele

04:06 compartilhou e transformamos em uma configuração que pudéssemos usar no nosso próprio workflow. Para fazer o ciclo dele funcionar no nosso app, configuramos algumas skills e agents para automatizar esse trabalho. Vamos explicar em detalhes o que cada parte faz para que você também possa pedir ao Claude que crie cada uma delas. A primeira coisa que criamos foi uma skill muito importante, chamada contexto do projeto. Essa skill é específica para aquilo que você está construindo e contém tudo o que é preciso saber sobre isso. Ela funciona como um banco de memória sobre o que o app faz, quais páginas tem, quais convenções segue e o que deve evitar. Assim, quando o

04:36 modelo está trabalhando, ele pode buscar contexto ali. A skill de contexto do projeto cresce conforme o app cresce. Assim, está sempre atualizada com a versão mais recente. Usamos uma skill em vez de arquivos onde essas informações normalmente ficariam porque só a descrição curta da skill permanece na context window o tempo todo. Isso significa que o agent sempre sabe que ela está disponível, mas só carrega os detalhes completos quando necessário, em vez de levar tudo para cada tarefa. Então, seja lá o que você estiver construindo, pode pedir ao agent com quem está trabalhando que configure uma skill para armazenar todo esse contexto para você.

05:06 Depois disso, há uma skill principal que conduz todo o processo para que o ciclo possa rodar sem que você fique acompanhando. É a skill de construção, que contém todas as instruções para executar o ciclo em cada recurso. A primeira tarefa da skill de construção é escrever as verificações, e ela não faz isso sozinha. Ela usa outra skill chamada escrever verificações. Escrever verificações é semelhante ao agent autor de testes que usamos em vídeos anteriores, mas é adaptada a este projeto e workflow. Isso garante que as verificações sejam escritas antes de qualquer recurso ser construído, para que o agent tenha algo com que comparar, em vez de avaliar o próprio código. Depois que as verificações são escritas,

05:37 a skill de construção lista, em palavras simples, o que cada verificação testa. É aqui que você precisa conversar com o agent para garantir que as verificações cubram todos os problemas que costumam surgir durante o trabalho. Quando você dá o sinal verde, um pequeno programa chamado aprovar verificações as bloqueia. O programa de verificações aprovadas move as verificações para uma pasta bloqueada, e uma regra nas configurações do Claude Code impede que o agent edite essa pasta. Assim, o ciclo não pode facilitar as próprias verificações. Depois que você aprova as verificações, a skill de construção faz commit delas. Isso adiciona mais uma camada de proteção para o caso de o agent tentar

06:08 mude-as. Então, ele executa o loop, mas a skill de build não constrói as funcionalidades no próprio context window. Para manter o contexto de cada funcionalidade separado, ela entrega cada uma delas ao agent construtor de funcionalidades. O agent construtor de funcionalidades começa do zero a cada vez e constrói a funcionalidade conforme as instruções. O resultado de cada rodada é armazenado em um arquivo para que possamos usá-lo mais tarde. Quando todas as funcionalidades estiverem prontas, a skill de build gera um relatório, e todas as instruções do loop, como as regras fixas e o modo de trabalhar, são escritas em program.md. Isso também segue o mesmo formato usado por Karpathy. Assim, nossa configuração fica completa

06:39 para executar o loop dessa maneira. Mas, antes de executarmos essa configuração, vamos ouvir nosso patrocinador, Upstash Box. Agora, os agents conseguem criar e corrigir software de verdade, mas seu laptop só consegue executar um de cada vez. Isso porque executar mais de um significa que eles podem entrar em conflito, deixar tudo mais lento ou, pior ainda, ler ou alterar arquivos da sua máquina sem que você perceba. É por isso que você precisa de um sandbox, e é exatamente esse problema que Upstash Box resolve, dando a cada agent seu próprio sandbox. Cada um é um computador de verdade na nuvem, com seu próprio shell e sistema de arquivos. Assim, um agent pode trabalhar no seu repo sem jamais tocar na sua

07:11 máquina. Colocamos 10 deles para funcionar, cada um com sua própria tarefa. Um criou uma nova funcionalidade, outro investigou um bug, e nada disso tocou no nosso laptop. Como cada sandbox do Upstash salva seu próprio estado, eles continuaram trabalhando por horas, até durante a noite. É uma fábrica de software inteira, e nada disso fica na sua máquina. Há um plano gratuito, você só paga pelo que usa, e o serviço reduz a zero quando nada está em execução. Use vários agents para impulsionar seu workflow em upstash.com; os links estão na descrição. Agora, como estávamos trabalhando em um projeto que já estava pela metade, pedimos ao Claude que usasse a skill de build e criasse uma

07:43 funcionalidade que permite aos clientes fazer pedidos de comida para retirada no site do restaurante. Mas essa funcionalidade ainda não estava na nossa lista de funcionalidades. Então, Claude a adicionou e escreveu as regras para pedidos online em features.md. Esse era o arquivo que estávamos usando para acompanhar as funcionalidades. Com as regras registradas, Claude nos mostrou todas as verificações que faria. A primeira lista tinha 10 verificações. Também queríamos o e-mail do cliente. Então pedimos a Claude que o adicionasse. Isso totalizou 11 verificações, e a nova verificação garantia que o e-mail fosse um endereço válido. Quando aprovamos as verificações, Claude fez o commit delas. Então, o agent construtor de funcionalidades

08:15 construiu a funcionalidade, e isso levou cerca de 6 minutos. No final, o relatório mostrou que as 11 verificações foram aprovadas na primeira rodada, então o loop não precisou de outra rodada. Mas o loop também detectou algo que a pontuação não mostrava. As verificações testavam apenas as regras de pedidos. Portanto, o loop tinha escrito essas regras, mas não o formulário de pedido que os clientes usam no site. Então, o loop criou o formulário de pedido e o conectou às regras antes de marcar a funcionalidade como concluída. Mas esse tipo de loop tem um problema: o agent cria hábitos. Em um loop, se ele perceber que uma determinada abordagem não está funcionando, vai melhorá-la

08:46 naquele loop, mas não vai se lembrar disso na próxima vez que executar o loop. Nosso loop tem o mesmo problema, porque cada funcionalidade começa com um agent construtor de funcionalidades novo e os mesmos arquivos de instruções. Portanto, um erro cometido por um modelo em uma rodada vai se repetir na próxima. A solução é um segundo loop que analisa como o primeiro loop foi executado e muda o modo como ele funciona. Criamos nossa própria versão desse segundo loop como uma skill chamada auto loop. No método de Karpathy, uma pessoa escreve program.md, mas, na nossa configuração, a auto loop reescreve para nós a parte de program.md que explica como trabalhar. Para isso, a auto

09:18 loop lê o arquivo de resultados, que armazena cada rodada executada pelo loop. Para cada rodada, o arquivo de resultados também mostra se ela foi mantida ou desfeita, o que o agent tentou e quais verificações ainda falharam. Basicamente, a auto loop procura problemas recorrentes, como o mesmo erro cometido pelo agent ou a mesma lacuna aparecendo em duas funcionalidades. Então, ela registra cada hábito junto das rodadas que o evidenciam. Depois, a auto loop reescreve a parte de program.md que explica como trabalhar, para que as próximas funcionalidades sejam construídas com as novas instruções. Mas a auto loop não pode editar as verificações. Se a

09:48 auto loop pudesse editar as verificações, poderia torná-las mais fáceis de passar. Assim, as rodadas deixariam de falhar sem que os hábitos fossem corrigidos. Agora, para testar o loop dentro do loop, executamos um em outro projeto. Era um app de gerenciamento de projetos que não tinha como as pessoas combinarem e compartilharem seus workflows. Para executá-lo, pedimos a Claude que criasse outra skill chamada auto loop. A skill auto loop basicamente executa o mesmo loop, com o mesmo agent construtor de funcionalidades e a skill de escrever verificações usados na configuração anterior, mas executa esse loop dentro de outro loop. Isso é diferente da skill de build que

10:19 usamos antes, porque a skill de build executa apenas uma passagem. Cada funcionalidade recebe as mesmas instruções e os agents a constroem, mas nada do que o loop aprende é levado para a próxima funcionalidade. A skill auto loop também executa o loop uma funcionalidade por vez, mas, depois de cada funcionalidade, analisa e atualiza as instruções, para que a próxima comece com o método que realmente funcionou. Isso ajuda a melhorar muito seu loop. O objetivo dessa skill é, na verdade, melhorar o próprio loop e alterar as instruções. Assim, sempre que o loop for executado novamente, ele

10:49 funciona melhor do que na execução anterior. Então, para adicionar funcionalidades ao nosso app, executamos a skill auto loop e dissemos o que queríamos. Pedimos uma maneira de várias pessoas trabalharem juntas, para que pudessem compartilhar sessões de foco e executar projetos em conjunto. A skill auto loop começou adicionando essas funcionalidades ao arquivo de acompanhamento. Como antes, a skill auto loop primeiro lista as verificações. Você pode alterá-las, se necessário, ou pedir ao seu agent que comece a construir diretamente. A primeira funcionalidade era um banco de dados compartilhado, para que o trabalho de todos ficasse em um só lugar. O banco de dados passou em todas as 10

11:19 verificações, mas o app nunca salvou nada nele. Então, a auto loop adicionou um hábito às instruções: conectar cada funcionalidade ao app na mesma rodada em que suas verificações são aprovadas. Depois, a auto loop detectou um segundo problema com as menções, que permitiam atribuir uma tarefa digitando o nome de alguém depois do símbolo arroba. As menções passaram nas verificações, mas uma parte mais antiga do app ainda interpretava o símbolo arroba à moda antiga. Por isso, a auto loop adicionou um segundo hábito: encontrar todos os lugares em que o app já realiza uma tarefa e fazer com que cada um siga as novas regras. Os dois hábitos funcionaram

11:50 porque as funcionalidades seguintes já vieram com suas telas conectadas. Para ver as verificações em ação, o builder errou duas rodadas de projetos compartilhados. Na primeira rodada, ele quebrou as menções, então elas falharam e a rodada foi desfeita. Na segunda rodada, ele calculou a parte de cada pessoa da maneira mais simples: três pessoas receberam 33 cada, o que soma apenas 99. Essa verificação falhou e, na terceira rodada, o builder corrigiu o problema e passou em todas as 10 verificações. Quando termina, ele gera um relatório que informa onde o agent errou e como corrigiu o erro, além de mostrar como ficou o workflow. Assim, sempre que

12:21 você trabalhar na próxima funcionalidade, não vai precisar enfrentar o mesmo problema de novo. Agora, todas as skills que criamos neste vídeo, junto com outros recursos, estão disponíveis na nossa comunidade, AI Labs Pro. Então, se você achou nosso trabalho útil e quer apoiar o canal, essa é a melhor maneira de fazer isso. O link está na descrição. Isso nos leva ao fim deste vídeo. Se quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, você pode usar o botão Super Thanks abaixo. Como sempre, obrigado por assistir, e até o próximo vídeo.

Transcrição original

[00:00] People have been using loops to get AI agents to build a lot of things on their own. And the reason that works is the structured workflow behind each loop. That’s why people let their agents work on big tasks for hours at a time, and they’re getting good results. There are a lot of ways to set one of these workflows up, and one of them is Karpathy loop. So, we set up the Karpathy loop on our own apps to see how well it actually holds up. It held up well, but we found one issue that the loop can’t see on its own. To fix that issue, we made one change to the loop. If this is your first time, we’re

[00:30] software company, and this is our channel AI Labs. And in this video, we’re going to show you what the Karpathy loop is, how to set it up on your own apps, and the change that fixes that issue. But before [snorts] we go into the workflow, let’s go over Karpathy’s method itself, because this loop is built on it. If you don’t know loops, we already have a full video on them on our channel. You can watch it so that you understand loops better. Now, Andre Karpathy made a project called Auto Researcher a while back, where an AI agent kept working on training a model and ran the code again and again until the model actually improved. The

[01:00] agent did this in a loop, so there was no need to direct its steps. Now, in Auto Researcher, the agent was only allowed to change one file, and that was the file that trained the model. Every round was one experiment where the agent made one change to that training file, and then trained the model for a few minutes. After that, a second file gave the model a score. If the score got better, the agent kept the change. But if the score stayed the same or got worse, the agent undid the change. The agent wasn’t allowed to touch the scoring file. This was because if the agent could change the scoring file, it could have just made the score easier to

[01:32] beat instead of making the model better. And a third file called program.md told the agent how to run each round. And program.md was basically an instructions file that Karpathy wrote in plain English. Karpathy wrote that instructions file and let the loop run for 2 days. In that time, the agent ran 700 experiments and found 20 changes that made the model train faster. Now, this was an experiment that showed how agents can keep going and check every single possibility, which wouldn’t be possible if you controlled every step yourself. This is because controlling

[02:02] 700 experiments yourself takes a long time, but the agent ran them on its own and found different methods that worked. The CEO of Shopify also ran the same kind of loop and got good results. He ran it on one of his own models while he slept, and the agent ran 37 experiments. In the morning, his model was performing 19% better. So, Karpathy’s method showed that when an agent is just given a goal, it can keep trying things and get better on its own without you directing every step. This is when a lot of people started getting into loop engineering. Now, before [snorts] you set up a loop,

[02:33] you need to know when you should even use one in the first place. If you use loops for the wrong kind of task, you waste tokens and might not even get what you want. Loops are really helpful when they’re placed in the right scenarios, but the right scenario depends on what you’re actually trying to get done with the task. For a loop to be worth setting up, the task needs four things. The first is that you repeat the task often. A loop takes time to build, and you only get that time back when you keep repeating the task. So, for a job you do once, one good prompt is enough. If you set up a loop for that kind of job,

[03:04] you’ll spend more time on the setup than on the task itself. The second is your usage limit, because loops use a lot of tokens. In a loop, the agent reads your project again and tries a new fix on every round. That uses tokens even on the rounds that fail. So, a long loop on a $20 plan hits the usage limit before the work is even done. The third is that the work can be checked without by something that gives a clear score. In an app, that’s done by small pieces of code that try a feature and confirm it works. The last is that the agent can actually run what it built and see what

[03:35] breaks, so it knows what to fix in the next round. We use different types of loops in our workflows, but only for tasks that have a clear score we can measure, and we never let a full app get built in one loop and call it done. We only use loops to build one feature at a time or a simple version of the app that the loops checks can verify. But before we set things up, it would be great if you subscribe to the channel and hit the hype button. This small gesture of support goes a long way for us. Karpathy [snorts] has shared a lot about how he works with AI agents. So we took what he

[04:06] shared and turned it into a setup we could use in our own workflow. In order to make his loop work for our own app, we set up a few skills and agents so that we could automate this job. We’ll explain what each part does in depth so that you can ask Claude to build each one for you as well. The first thing we built was a skill that’s really important called project context. This skill is specific to whatever you’re building and contains everything there is to know about it. It acts as a memory bank for what the app does, which pages it has, the conventions it follows, and the things it should avoid. So when the

[04:36] model is working, it can pull context from there. The project context skill grows as the app grows. So it’s always up to date with the latest version. We use a skill instead of a files where this information would normally live because only the skills short description stays in window all the time. That means the agent always knows it’s available, but only loads the full details when needed instead of carrying all of them into every task. So whatever you’re building, you can ask the agent you’re working with to set up a skill that stores all of this context for you.

[05:06] After that, there’s a main skill that drives the whole thing so that the loop can run without you watching it. It’s the build skill and it has all the instructions for running the loop on each feature. The first job of the build skill is to write the checks and it doesn’t do that on its own. It uses another skill called write checks. Write checks is similar to the test author agent we used in our previous videos, but it’s tailored to this project and workflow. This makes sure that the checks are written before any feature is built so that the agent has something to verify against instead of judging its own code. Once the checks are written,

[05:37] the build skill lists what every check tests in simple words. This is where you need to go back and forth with your agent so that you can make sure the checks cover all the problems that commonly happen during the work. Once you give it a go-ahead, a small program called approve checks locks them in. The approved checks program moves the checks into a locked folder, and a rule in Claude code settings blocks the agent from editing that folder. So, the loop can’t make its own checks easier. Once you approve the checks, the build skill commits them. This adds another layer of protection in case the agent tries to

[06:08] change them. Then, it runs the loop, but the build skill doesn’t build the features in its own context window. To keep each feature’s context separate, it gives every feature to the feature builder agent. The feature builder agent starts fresh each time and builds the feature as instructed. The result of every round is stored in a file so that we can use it later on. When every feature is done, the build skill gives out a report, and all the loop’s instructions like the fixed rules and how to work are written in program.md. This follows the same format Karpathy used, too. That makes our setup complete

[06:39] for running the loop this way. But, before we run this setup, let’s have a word by our sponsor, Upstash Box. Agents can build and fix real software now, but your laptop can only run one at a time. Because running more than one means they’ll either collide with each other, slow everything down, or worse, they’ll quietly read or change files on your machine. That’s why you’d want a sandbox, and it’s exactly the problem Upstash Box fixes by giving each agent its own sandbox. Each one is a real computer in the cloud with its own shell and file system. So, an agent can work on your repo without ever touching your

[07:11] machine. We spun up 10 of them, each with its own job. One built a new feature, another chased down a bug, and none of it touched our laptop. Because each Upstash sandbox saves its own state, they kept working for hours, even overnight. It’s a whole software factory, and none of it lives on your machine. There’s a free tier, you only pay for what you use, and it scales to zero when nothing’s running. Have multiple agents powering your workflow at upstash.com, links in the description. Now, since we were working on a project that was already half-built, we prompted Claude to use the build skill and asked it to build a

[07:43] feature that lets guests order food for pick up from the restaurant’s website. But that feature wasn’t in our feature list yet. So Claude added it and wrote the rules for online ordering into features.md. This was the file that we were using for feature tracking. With the rules written down, Claude gave us all the checks it was going to make. The first list had 10 checks. We wanted the guest’s email as well. So we asked Claude to add it. That made 11 checks and the new check made sure the email was a real address. When we approved the checks, Claude committed them. Then the feature builder agent

[08:15] built the feature and it took about 6 minutes. At the end, the report showed that all 11 checks passed in the first round, so the loop didn’t need another round. But the loop also caught something the score didn’t show. The checks only tested the ordering rules. So the loop had written those rules, but not the order form that guests use on the website. So the loop built the order form and connected it to those rules before it marked the feature as done. But this kind of loop has one problem, which is that the agent has habits. In a loop, if it sees that a particular way wasn’t working, it’s going to improve it

[08:46] in that loop, but it won’t remember that for the next time it runs that loop. Our loop has the same problem because every feature starts with a fresh feature builder agent and the same files for instructions. So a mistake that a model made in one round is going to carry over to the next. The fix for that is a second loop that reads how the first loop ran and changes how the first loop works. We built our own version of that second loop as a skill called auto loop. In Carpen these method, a person writes program.md, but in our setup, the auto loop rewrites the how to work part of program.md for us. To do that, the auto

[09:18] loop reads results file, which stores every round the loop ran. For every round, results file also shows whether the round was kept or undone, what the agent tried, and which checks still failed. The auto loop basically checks for problems that keep coming back like the same mistake agent was making or the same gap showing up in two features. Then it writes down each habit with the rounds that show it. Then the auto loop rewrites how to work part in the program.md, so the next features are built with the new instructions. But the auto loop can’t edit the checks. If the

[09:48] auto loop could edit the checks, it could make them easier to pass. Then the rounds would stop failing without the habits ever getting fixed. Now, to test the loop within the loop, we ran one on another project. It was a project management app that didn’t have any way of people combining and sharing their workflows. To run it, we asked Claude to create another skill called auto loop. The auto loop skill basically runs the same loop with the same feature builder agent and write check skill that the previous setup was using, but it runs that loop inside another loop. This is different from the build skill that we

[10:19] used previously because the build skill only runs one pass. Every feature gets the same instructions and the agents build it, but nothing the loop learns carries over to the next feature. The auto loop skill also runs the loop one feature at a time, but after each feature, it reviews and updates the instructions, so the next feature starts from the method that actually worked. This helps make your loop much better. The whole purpose of this skill is actually to improve the loop itself and make changes in the instructions. So, whenever the loop runs the next time, it

[10:49] works better than the previous run. So, to add features to our app, we ran the auto loop skill and told it what we wanted. We asked for a way for many people to work together, so they could share focus sessions and run projects together. The auto loop skill then started by adding those features to the tracking file. Just like before, the auto loop skill first lists the checks. You can change them if needed or ask your agent to start building directly. The first feature was a shared database, so everyone’s work could live in one place. The database passed all 10 of its

[11:19] checks, but the app never saved anything to it. So, the auto loop added a habit to the instructions, which was to connect each feature to the app in the same round that makes its checks pass. Then the auto loop spotted a second problem with mentions, which let you assign a task by typing someone’s name after an at sign. Mentions passed its checks, but an older part of the app still read the at sign the old way. That’s why the auto loop added a second habit, which was to find every place the app already does a job and make each one follow the new rules. Both habits worked

[11:50] because the next features came with their screens already connected. To see the checks in action, the builder got two rounds of shared projects wrong. In the first round, it broke mentions, so the mentions failed and the round was undone. In the second round, it estimated each person’s share the simple way, so three people got 33 each, which only adds up to 99. That check failed, and in the third round, the builder fixed it and passed all 10 checks. When it is done, it gives a report telling you where the agent went wrong and how it fixed that, along with what the workflow looked like. So, whenever

[12:21] you’re working on the next feature, you don’t have to face the same issue again. Now, all the skills that we created in this video, along with other resources, are all available in our community, AI Labs Pro. So, if you found value in what we do and want to support the channel, this is the best way to do it. The link’s in the description. That brings us to the end of this video. If you’d like to support the channel and help us keep making videos like this, you can do so by using the Super Thanks button below. As always, thank you for watching and I’ll see you in the next one.