Shopify acaba de lançar o melhor workflow de Claude Code de todos

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: Shopify Just Released The Greatest Claude Code Workflow Ever · Canal: AI LABS · 14:26 · Assistir no YouTube

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

Resumo

O vídeo apresenta o workflow de desenvolvimento com IA que Shopify criou para reconstruir seu aplicativo móvel, com 300 telas, usando agentes de IA. O processo divide cada funcionalidade em checkpoints e exige que cada etapa passe por gates de comportamento, interface, revisão adversarial do código e avaliação humana. Os apresentadores recriam o método em um projeto de demonstração, coordenado por uma skill chamada orchestrator e apoiado por subagents. A ideia central é permitir que o agente erre durante o trabalho, mas impedir que tarefas inacabadas avancem ou sejam entregues.

Pontos-chave

Shopify usou Helix para dividir o trabalho de reconstrução do aplicativo em checkpoints pequenos e ordenados por complexidade.
Uma pessoa revisa e aprova o plano de checkpoints antes de o agente começar a implementação.
Cada checkpoint só avança depois de passar pelos gates aplicáveis.
Subagents com context windows separados ajudam a evitar perda de informações em tarefas longas.
O gate de comportamento verifica funcionalidades com testes de código, sem depender do navegador.
O gate de interface compara o aplicativo com um protótipo, tanto visualmente quanto em comportamento.
Uma revisão adversarial procura problemas no código, e um agente separado corrige os problemas encontrados.
A revisão humana final verifica o recurso em uso e pode gerar novos checkpoints.
O orchestrator coordena o workflow e para para receber a aprovação humana em dois momentos: após o planejamento e ao final.

Capítulos

Início	Capítulo	Resumo
00:00	O workflow da Shopify e a recriação do método	O vídeo apresenta Helix, os checkpoints e os gates usados pela Shopify, além da recriação do workflow em um projeto de demonstração.
03:07	Planejamento e revisão dos checkpoints	O Checkpoint Planner divide funcionalidades em etapas crescentes, que uma pessoa revisa antes da implementação.
05:11	Gates e testes de comportamento	Um hook impede o avanço prematuro, enquanto testes de código verificam o comportamento de cada checkpoint.
09:16	Revisão da interface com protótipos	Protótipos permitem comparar a aparência e o comportamento do aplicativo com o resultado esperado.
11:53	Revisão adversarial e correções	Um agente procura problemas no código e outro os corrige até que a revisão adversarial aprove a etapa.
13:26	Revisão humana e encerramento do ciclo	A pessoa testa o recurso final, pode pedir mudanças que viram novos checkpoints e conclui o ciclo com o orchestrator.

Citações

Um gate é diferente porque, enquanto não for aprovado, não deixa o agente passar para a próxima tarefa. — 05:43

Uma tentativa pode estar errada. Ela não pode ser entregue até deixar de estar. — 06:13

O agente pode errar ao longo do caminho, mas os gates nunca deixam o trabalho inacabado passar. — 13:56

Conceitos e entidades

Shopify (empresa): Empresa que desenvolveu o workflow Helix para reconstruir seu aplicativo móvel com agentes de IA.
Helix (ferramenta): Ferramenta interna da Shopify que divide o trabalho em checkpoints e aplica gates de revisão.
Claude Code (ferramenta): Ferramenta mencionada no vídeo como ambiente em que o agente pode usar o servidor MCP da Hedra.
Gemini (modelo): Modelos usados pela Shopify como revisores de design, devido à capacidade de avaliar a posição e o tamanho de elementos na tela.
Hedra (empresa): Patrocinadora do vídeo, apresentada como serviço de geração de mídia acessível por um servidor MCP.
Ralph loop (conceito): Abordagem citada como inspiração para o hook que impede o agente de encerrar o trabalho antes de passar pelos gates.
orchestrator (ferramenta): Skill que coordena o planejamento, a implementação e as revisões do workflow.
Checkpoint Planner (ferramenta): Agente que transforma uma funcionalidade grande em checkpoints menores e os registra em um arquivo JSON.
TDD planner (ferramenta): Skill adaptada para planejar e escrever testes antes da implementação dos checkpoints.
AI Labs (empresa): Canal que apresenta uma recriação do workflow da Shopify em um projeto de demonstração.

Tradução completa (pt-BR)

00:00 A Shopify acabou de reconstruir seu principal app para dispositivos móveis e, nesse processo, lançou um fluxo de trabalho incrível de programação com IA. Para entender por que isso é tão importante, você precisa entender que essa é uma tarefa enorme. Eles reconstruíram um app gigantesco, com 300 telas, e fizeram tudo usando agents de programação com IA. Mas não simplesmente entregaram todo o trabalho a um agent de uma só vez. Usaram um fluxo de trabalho estruturado até o fim. Assim, o app manteve o padrão deles, mas eles só falaram sobre o método e nunca nos mostraram como ele foi executado. Então, refizemos o percurso e reconstruímos o mesmo fluxo de trabalho para

00:30 nós mesmos. As etapas do fluxo de trabalho da Shopify dão ao seu agent um processo do qual ele não consegue se esquivar. Mas, mesmo com o fluxo de trabalho implementado, o agent ainda tentou fazer besteira. E uma mudança que fizemos resolve esse problema por completo. Se você chegou agora, seja bem-vindo. Somos uma empresa de software, e este é o nosso canal, AI Labs. Neste vídeo, vamos mostrar o fluxo de trabalho da Shopify e como o configuramos para que você também possa executar o mesmo ciclo de programação com IA no seu próprio app. A Shopify chama a ferramenta por trás desse ciclo de Helix. Eles a criaram porque estavam reescrevendo o app de um jeito diferente daquele em que ele foi

01:01 criado originalmente. Resumindo o que fizeram, pegaram uma tela do app antigo e pediram ao agent que a convertesse para a nova versão. Em seguida, o Helix leu essa tela e dividiu o trabalho em tarefas menores, chamadas de checkpoints. Uma pessoa da equipe deles revisou esses checkpoints primeiro. Depois que foram aprovados, cada checkpoint teve que passar por quatro verificações rigorosas antes que o Helix começasse a trabalhar no próximo. Essas verificações garantiam que o app atendesse aos padrões deles. O Helix usa subagents para realizar a maior parte do trabalho. O principal motivo para usarem subagents em tudo é ter uma context window nova. Se um agent está

01:33 trabalhando em uma tarefa muito longa e mantém tudo na mesma context window, isso causa problemas. Quando tudo fica reunido na mesma context window, o volume de informações se torna grande demais para o agent, e ele começa a esquecer as coisas importantes no meio do caminho. Assim, a qualidade do trabalho começa a cair. Os subagents evitam isso mantendo uma context window separada para cada tarefa. Todo o ciclo também é construído em torno de duas coisas. A primeira são os checkpoints, que são as pequenas partes do trabalho de que falamos. A segunda são as quatro verificações, que a Shopify chama de gates. Um gate é uma verificação pela qual o trabalho precisa passar. E qualquer

02:05 trabalho que não passar na verificação não pode avançar para a próxima tarefa até que o gate seja aprovado. Embora usem esse fluxo de trabalho para transformar um app de uma forma em outra, ele pode ser usado para muito mais do que isso. Esse processo permite criar funcionalidades enormes, garantindo que o que você desenvolve atenda aos padrões do seu app e também tenha uma boa aparência. O Helix ainda é interno, e não temos acesso a ele, mas eles divulgaram toda a configuração. Então, criamos nosso próprio fluxo de trabalho e o testamos em um projeto demonstrativo de sistema de RH. Já tínhamos o app inteiro construído e estávamos apenas adicionando funcionalidades. Vamos explicar em detalhes o que cada etapa faz, para que

02:37 você possa reproduzir o mesmo fluxo de trabalho enquanto trabalha no seu app. Como executar todas as etapas desse ciclo por conta própria exigiria muita participação nossa, criamos uma skill chamada orchestrator. O orchestrator é a única skill que você precisa acionar com um prompt, e ele cuida de todas as outras partes sozinho. Você só precisa intervir duas vezes; no restante do tempo, o orchestrator cuida de tudo por conta própria. Mas, antes de construirmos algo com ele, vamos passar pelas partes principais do ciclo. Começando pelos checkpoints. Como mencionamos antes, os checkpoints são, na verdade, pequenas partes de uma funcionalidade grande. A Shopify trabalhou

03:07 dessa forma: até que um checkpoint seja concluído corretamente, o próximo não pode começar. Eles dividiram o trabalho em checkpoints em ordem crescente de complexidade. Isso significa que as tarefas menores devem ser construídas primeiro, depois a próxima tarefa mais complexa e assim por diante. Isso porque cada checkpoint é construído sobre o anterior. Portanto, se uma decisão inicial estiver errada, você percebe enquanto ainda é algo pequeno e barato de corrigir. Para dividir nossa funcionalidade em partes menores, criamos um agent chamado Checkpoint Planner. O Checkpoint Planner recebe a funcionalidade grande que fornecemos ao orchestrator e

03:38 a divide em checkpoints. Ele grava esses checkpoints em um arquivo JSON. Isso porque a estrutura é fácil de entender para o agent, e ele consegue encontrar facilmente o que precisa no arquivo. Mas há uma coisa que você precisa fazer: revisar esses checkpoints. Embora o JSON seja estruturado, é difícil para você, como pessoa, ler o arquivo e entendê-lo diretamente. Isso porque o arquivo vira um enorme bloco de texto estruturado, difícil demais para uma pessoa acompanhar. Por isso, também criamos um visualizador simples em uma página da web, onde podemos ver facilmente o que o

04:08 agent planejou. O que acontece é que contamos ao orchestrator qual funcionalidade queremos adicionar ao app. Então, o orchestrator inicia dois subagents. Um subagent verifica o estado atual do app e garante que ele esteja funcionando. O outro é o agent Checkpoint Planner que criamos. Se o Checkpoint Planner tiver alguma pergunta, ele fará essas perguntas a você. Depois, ele registra todos os checkpoints, e o orchestrator abre o visualizador para que você possa revisá-los. O visualizador mostra cada etapa em ordem, quais estão em andamento e o que cada tarefa precisa cumprir para ser considerada concluída. Também instruímos o Checkpoint Planner a manter a

04:40 linguagem simples para que você entenda facilmente o texto. Nesse momento, o orchestrator também dá a outro subagent a tarefa de planejar os testes. Esse subagent registra em detalhes como cada checkpoint será testado, para que tudo fique documentado desde o início. Essa revisão é uma das etapas que você precisa fazer com cuidado, para ter certeza de que o plano não deixou nenhuma funcionalidade de fora e de que o tempo gasto pelos agents na implementação não será desperdiçado. Depois de revisar o plano, você pede alterações ou o aprova. Quando você aprova o plano, o orchestrator começa a trabalhar no checkpoint um. Mas, antes de vermos como

05:11 o checkpoint um é construído, você precisa entender o que um checkpoint tem que cumprir para ser considerado concluído. E, antes de falarmos disso, seria ótimo se você se inscrevesse no canal e apertasse o botão de hype. Esse pequeno gesto de apoio ajuda muito a gente. O que permite que um checkpoint seja aprovado é, na verdade, um ponto de revisão. A Shopify chama esses pontos de revisão de gates. Geralmente, você define essas revisões na forma de prompts. Mas um gate é diferente de uma regra nas instruções que você fornece nos prompts ou arquivos, porque uma regra é apenas uma recomendação. O agent esquece a regra enquanto está trabalhando, e você precisa

05:43 lembrá-lo de novo. Um gate é diferente porque, enquanto não for aprovado, ele não deixa o agent avançar para a próxima tarefa. Para garantir que nossa configuração não deixasse o agent trabalhar na próxima tarefa antes da aprovação de um gate, criamos um hook. O hook que criamos é executado toda vez que o agent tenta parar. Quando ele tenta parar, o hook também gera o código de saída 2. Esse código de saída 2 não serve para indicar que ocorreu um erro durante o trabalho; ele serve apenas para instruir o agent a fazer o que precisa, para que possa continuar trabalhando. Nosso hook diz ao agent que o trabalho não está concluído, então

06:13 ele precisa continuar até que os gates sejam aprovados. Esse é o mesmo conceito que pegamos emprestado do ciclo Ralph. Há quatro gates que a Shopify usou no fluxo de trabalho. O primeiro é o gate de comportamento, que verifica se a funcionalidade funciona ou não. Depois, o gate de interface verifica se a tela se parece com o design que queríamos. Em seguida, o gate de revisão de código verifica se o código por trás da funcionalidade está bom. E o último gate é a sua revisão final. Então, vamos começar configurando o gate de comportamento. Mas, antes de configurá-lo, vamos ouvir algumas palavras do nosso patrocinador, Hedra. Seu agent já trabalha bem ao seu lado no editor, mas, no momento em que seu build

06:44 precisa de mídia real, ele trava e você precisa sair para usar uma ferramenta separada. Hedra elimina essa lacuna. Adicionamos o servidor MCP da Hedra ao Claude Code em cerca de um minuto e, de repente, o agent podia criar a própria mídia sem sair da sessão. Por baixo, são os mesmos modelos da Hedra, só que acessados de dentro do nosso agent. Então pedimos o que a implementação precisava: um clipe curto para a página inicial. Em vez de um indicador de carregamento silencioso, Hedra transmitiu o progresso real enquanto passava da geração à finalização, para podermos assistir ao clipe sendo renderizado de verdade em tempo real, em vez de apenas receber um arquivo. Um momento depois, o vídeo finalizado

07:15 apareceu ali mesmo na nossa sessão. É mais uma coisa que seu agent pode fazer de repente sem abrir outra aba. Se seus agents já travaram por precisarem de mídia real, Hedra elimina essa lacuna. Experimente gratuitamente em hedra.com e use nosso código para ter 50% de desconto no primeiro mês. O link e o código estão na descrição. Agora, a etapa de verificação do comportamento envolve todos os testes que podem ser feitos sem usar o navegador nem o agent. Em vez de verificar o app clicando nele, o agent escreve pequenas verificações em forma de código, que usam o recurso da mesma maneira que uma pessoa usaria. Essas pequenas

07:45 verificações são chamadas de testes, e já vimos eles serem planejados anteriormente no visualizador. O motivo pelo qual planejamos os testes primeiro, como sempre mencionamos em nossos vídeos anteriores, é que queremos que o agent tenha um padrão claro para usar na verificação do próprio trabalho, para que possa confirmar se o recurso está funcionando como deveria. Esses testes cobrem o maior número possível de casos para que possamos verificar se o workflow por trás do app está funcionando corretamente com diferentes entradas. Para facilitar isso, modificamos nossa skill de planejamento de TDD anterior para que se encaixe nesse workflow. Essa skill basicamente

08:15 planeja e escreve os testes para o recurso que recebe. Essa skill garante que, nessa etapa, tudo o que pode ser verificado sem um navegador seja testado. Isso porque muitas coisas não precisam de um navegador para serem verificadas, como saber se um gerente tem permissão para aprovar a licença de alguém. Para isso, o agent pode usar um trecho de código para verificar essa parte diretamente, sem precisar clicar em botões para ver se a licença foi aprovada ou não. O subagent que planejou os testes anteriormente estava seguindo essa skill. Essa etapa vem depois da nossa última etapa, na qual criamos os pontos de verificação usando o agent. Depois que você aprova os pontos de verificação que foram mostrados

08:46 a você, o orquestrador começa a trabalhar no primeiro ponto de verificação. Primeiro, o orquestrador inicia alguns subagents para escrever os testes necessários para a primeira etapa. No começo, todos vão falhar, porque o recurso para o qual os testes foram escritos ainda não foi implementado. Quando os testes estiverem prontos, o orquestrador inicia outro subagent, que realmente escreve o código para esse ponto de verificação. Depois, o orquestrador usa mais um subagent para executar os testes e garantir que todos passem. Quando todos os testes passam, a primeira etapa é marcada como aprovada para o primeiro ponto de verificação. Então, o orquestrador passa para a

09:16 próxima rodada de revisão, que é a etapa de verificação da interface. Essa etapa é uma das mais importantes, porque afeta diretamente a experiência do usuário. Como a Shopify estava convertendo um app em outra forma, manter o design exatamente igual se tornou muito importante. Para essa etapa, a Shopify usou modelos Gemini como revisores de design perfeccionistas. Isso porque, durante os testes, eles descobriram que esses modelos têm uma percepção espacial muito boa, ou seja, conseguem identificar onde as coisas estão na tela e qual é o tamanho delas. Assim, Gemini consegue detectar pequenas diferenças de espaçamento

09:48 e tamanho entre duas telas. Mas, quando você trabalha nos próprios projetos ou desenvolve para clientes, normalmente não tem nada com que comparar. Então, nesses casos, primeiro criamos protótipos em HTML. Criar protótipos nos permite demonstrar rapidamente os aspectos visuais dos produtos e experimentar diferentes direções sem nos preocuparmos em afetar o projeto principal. O protótipo também é o que mostramos aos clientes para obter a aprovação deles. Para criar esses protótipos, usamos outra skill chamada prototype. A skill prototype cria o protótipo inteiro em um único arquivo que podemos abrir e percorrer clicando, para

10:19 ver se o que queremos está realmente sendo criado. Essa skill segue as orientações do próprio projeto, como o arquivo de design. Esse é um arquivo estruturado que lista todos os detalhes de design necessários para criar o design. Já tínhamos criado um para nosso app usando a skill de planejamento design.md, que disponibilizamos no sistema de design do AI labs na comunidade. Com esse arquivo pronto, os protótipos são criados antes da interface. Para comparar o protótipo com o app que criamos, usamos uma skill separada. Essa skill garante que os aspectos visuais correspondam e também garante

10:50 que os dois se comportem da mesma maneira quando alguém interage com eles. Antes de comparar qualquer coisa, a skill também verifica se o protótipo e o app estão no mesmo estado. Por exemplo, um botão que ainda não foi enviado e outro que já foi enviado estão em estados diferentes. Então, a skill garante que o protótipo e o app mostrem o formulário no mesmo estado. Mas não usamos Gemini para isso. Em vez disso, a skill delega a comparação ao Claude em uma nova sessão, iniciando-o a partir da própria sessão. Nem todo ponto de verificação precisa dessa etapa, porque a primeira já testa a maioria das coisas sem um navegador.

11:21 É por isso que apenas alguns dos pontos de verificação mostrados anteriormente no visualizador não tinham essa etapa. Então, quando o orquestrador chega a um ponto de verificação que precisa dela, inicia dois subagents Claude separados, lado a lado. Um analisa a aparência da tela e o outro analisa o comportamento dela. Nenhum dos dois vê as instruções do projeto. Assim, eles avaliam o app apenas em relação ao protótipo e ao arquivo de design. Cada um apresenta uma análise das diferenças, e o orquestrador combina as duas. Essa análise combinada decide então se a etapa é aprovada ou reprovada. Agora o recurso funciona e se parece com o

11:53 protótipo, mas o código por baixo ainda pode estar uma bagunça. É aí que entra a próxima etapa. A terceira etapa é a revisão adversarial. A revisão adversarial é configurada para contestar o código. A Shopify tem processos de revisão rigorosos porque precisa garantir que aquilo que publica esteja de acordo com seus padrões. O método dela usa dois agents adversariais que verificam o código segundo um padrão documentado pela Shopify. Todo problema encontrado precisa ser corrigido, e essa etapa só é aprovada quando os dois agents dão sua aprovação. Então, também fizemos isso com dois agents, mas, em vez de ambos criticarem o código, optamos por um ciclo adversarial em que um agent critica e o outro corrige.

12:24 O primeiro agent é o agent adversarial, que basicamente parte do princípio de que o código está errado e tenta encontrar problemas nele. O segundo é o agent corretor, que corrige os problemas encontrados pelo agent adversarial. Para coordenar o workflow, temos uma skill chamada adversarial loop, que gerencia a comunicação entre os dois agents. Quando as etapas de verificação do comportamento e da interface são aprovadas, o orquestrador inicia o agent adversarial e aguarda a análise dele. Se o agent adversarial

12:55 não encontrar nenhum problema, o orquestrador simplesmente marca a etapa como concluída. Caso contrário, o orquestrador inicia o agent corretor para fazer as correções e, em seguida, o agent adversarial verifica o código novamente. Os dois agents alternam entre essas tarefas, e a etapa só é concluída quando o agent adversarial aprova o código. A última etapa é a participação humana no processo, e ela é realmente importante porque, mesmo que os agents tenham padrões e critérios para orientar a revisão, eles não conseguem revisar a partir da perspectiva de uma pessoa. Você precisa garantir que o recurso funcione corretamente quando alguém realmente o usar. Então, quando

13:26 todos os pontos de verificação estiverem concluídos, você precisa testar o recurso para garantir que ele funcione da maneira desejada. Você também verifica se algo poderia funcionar melhor ou ter uma aparência melhor, para poder solicitar pequenas alterações no recurso. Quando você solicita alterações, o orquestrador as transforma em novos pontos de verificação, que passam por todas as mesmas etapas, e registra seu feedback em um arquivo de aprendizados que todos os agents leem antes de começar a trabalhar. Agora, todo o workflow que acabamos de percorrer é executado por uma única skill chamada orchestrator, que mencionamos anteriormente. Quando você simplesmente dá um prompt para essa skill, ela executa o processo

13:56 todo o workflow, desde os pontos de verificação até entregar a funcionalidade final para você revisar. O orquestrador só vai parar para você duas vezes. Ele para uma vez depois de planejar os pontos de verificação, para que você possa aprová-los, e outra quando termina, para que você possa conferir o app e completar o ciclo. Então, o agent pode errar ao longo do caminho, mas as etapas de aprovação nunca deixam o trabalho inacabado passar. A Shopify coloca dessa forma: uma tentativa pode estar errada. O que não pode é ser lançada até estar certa. Então, você pode criar todo esse workflow por conta própria, dando um prompt ao Claude e informando a tarefa que quer que essa skill execute. Mas, se você

14:26 quiser as skills que criamos neste workflow, pode encontrá-las no AIABS Pro, que é a nossa comunidade. Então, se você encontrou valor no que fazemos e quer apoiar o canal, essa é a melhor forma de fazer isso. Os links estão na descrição. Isso nos leva ao fim deste vídeo. Se você quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, pode fazer isso usando o botão Super Thanks abaixo. Como sempre, obrigado por assistir, e até o próximo vídeo.

Transcrição original

[00:00] Shopify just rebuilt their main mobile app and in the process released an amazing AI coding workflow. To make you understand why this is a big deal, you need to understand that this is a huge task. They rebuilt a huge app with 300 screens and they did it all using AI coding agents. But they didn’t just give the whole job to an agent in one go. They used a structured workflow all the way to the end. So the app stayed up to their standard, but they just talked about the method and they never showed us how it was done. So, we retraced it and rebuilt the same workflow for

[00:30] ourselves. The steps in Shopify’s workflow give your agent a process it can’t talk its way out of. But even with their workflow in place, the agent still tried to mess up. And a change that we made fixes that problem entirely. If you’re new here, welcome. We’re a software company and this is our channel, AI Labs. And in this video, we’re going to show you Shopify’s workflow and how we set it up so that you can run the same AI coding loop on your own app as well. Now, Shopify calls the tool behind their loop Helix. They built it because they were rewriting their app in a different way than it was

[01:01] built originally. To summarize what they did, they took one screen from the old app and asked the agent to convert it to the new version. Helix then read that screen and split the work into smaller tasks called checkpoints. A person on their team then reviewed these checkpoints first. Then, after they were approved, each checkpoint had to pass four strict checks before Helix started working on the next one. These checks made sure that the app was up to their standards. Helix uses sub aents to carry out most of the work. The main reason they used sub aents for everything is the fresh context window. If an agent is

[01:33] working on a very long task and keeps everything in the same context window, this leads to problems. When everything is collected in the same context window, all of that becomes too much for the agent and it starts forgetting the important things in between. So the quality of its work starts to go down. Sub agents prevent that by keeping a separate context window for each task. The whole loop is also built around two things. The first is the checkpoints which are the small pieces of work we talked about. The second is the four checks which Shopify calls gates. A gate is a check the work has to pass. And any

[02:05] work that fails the check is stopped from going to the next task until that gate is cleared. Now even though they use this workflow for changing an app from one form to another, it can be used way beyond that. This process lets you build huge features by making sure that what you build is up to your app’s standards and also looks good. Now, Helix is actually still internal and we don’t have access to it, but they released their whole setup. So, we created our own workflow and tested it on a demo HR system project. We had the whole app built and we were just adding features to it. We are going to tell you what each step does in detail so that

[02:37] you can replicate the same workflow when you are working on your app. Since running every step of this loop ourselves would need a lot of our input, we created a skill and called it the orchestrator. The orchestrator is the only skill you need to prompt and it handles all the other parts itself. Your input is just needed twice and the rest of the time the orchestrator handles everything on its own. But before we build with it, we’re going to go to the core parts of the loop. Starting with checkpoints. Just like how we mentioned before, checkpoints are actually small parts of a big feature. Shopify worked

[03:07] this way that until one checkpoint is completed properly, the next checkpoint cannot start. They divided their work in checkpoints in order of increasing complexity. What this means is that the smallest tasks should be the ones built first and then the next more complex task and so on. That’s because each checkpoint is built on top of the one before it. So if an early decision is wrong, you catch it while it’s still small and cheap to fix. So to split our feature into smaller parts, we created an agent called Checkpoint Planner. The checkpoint planner takes the large feature we give to the orchestrator and

[03:38] splits it into checkpoints. It writes these checkpoints into a JSON file format. This is because its structure is easy for the agent to understand and it can easily find what it needs in the file. But there’s one thing you need to do and that’s review these checkpoints. Even though JSON is structured, it’s actually hard for you as a human to read that file and understand it directly. That’s because the file becomes a huge block of structured text that is too much for a person to follow. So for that reason we also built a simple webpage viewer where we can easily see what the

[04:08] agent planned. Now what happens is that we tell the orchestrator about the feature we want to add to the app. The orchestrator then starts two sub aents. One sub agent checks the current state of the app and make sure it’s running. The other is the checkpoint planner agent that we created. If the checkpoint planner has any questions, it will ask them from you. Then it writes down all checkpoints and the orchestrator opens the viewer for you so that you can review them. The viewer shows you each step in order, which steps are in progress, and what each task would need to be called done. We also instructed the checkpoint planner to keep the

[04:40] language simple so that you can understand the wording easily. At this point, the orchestrator also gives another sub aent the job of planning the tests. That sub agent writes down in detail how each checkpoint will be tested so that everything is documented from the get-go. This review is one of the steps you need to do thoroughly so that you know the plan isn’t missing any features and all the time agents spent implementing isn’t going to be wasted. Once you’ve reviewed the plan, you either ask for changes or approve it. Once you approve the plan, the orchestrator starts building with checkpoint one. But before we see how

[05:11] checkpoint one gets built, you need to understand what a checkpoint has to pass before it counts as done. And before we discuss those, 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. Now, the thing that lets a checkpoint pass is actually a review point. And Shopify calls these review points gates. You usually give these review in forms of prompts. But a gate is different from a rule in your instructions that you give in your prompts or files because a rule is only advice. The agent forgets the rule when it’s working and you have to

[05:43] remind it again. A gate is different because unless a gate is passed, it won’t let the agent move to the next task. To make sure that our setup didn’t let the agent work on the next task until a gate is passed, we created a hook. The hook we created runs every time the agent tries to stop. When it does try to stop, the hook throws an exit code too. This exit code two is not used to show an error has occurred during work, but it is just used to prompt the agent to do the thing so that it can continue working. Our hook tells the agent that the work isn’t done, so

[06:13] it has to keep going until the gates are passed. This is the same concept we borrowed from the Ralph loop. There are four gates that Shopify used in their workflow. The first is the behavior gate which checks whether the feature works or not. Then the UI gate checks if the screen looks like the design we wanted. After that, the code review gate checks that the code underneath is good. And the last gate is your final review. So we’ll start by setting up the behavior gate. But before we set it up, let’s have a word by our sponsor, Hedra. Your agent already works right beside you in the editor, but the moment your build

[06:44] needs real media, it stalls and you have to leave for a separate tool. Hedra closes that gap. We added the Hedra MCP server to Claude code in about a minute and suddenly the agent could make the media itself without leaving the session. It’s the same Hedra models underneath just reached from inside our agent. So we asked for what the build needed a short clip for the landing page and instead of a silent spinner, Hedra streamed its real progress as it moved from generating to finalizing so we could watch it genuinely render the clip in real time, not just hand over a file. A moment later, the finished video

[07:15] landed right there in our session. It’s one more thing your agent can suddenly do without opening another tab. If your agents ever stalled out needing real media, Hedra closes that gap. Try it for free at hedra.com and use our code for 50% off your first month. The link and code are in the description. Now, the behavior gate involves all the testing that can be done without using the browser and agent at all. Instead of checking the app by clicking through it, the agent writes small checks in the form of code that use the feature the same way a person would. These small

[07:45] checks are called tests, and we already saw them planned in the viewer earlier. The reason we plan the tests first, just like we’ve always mentioned in our previous videos, is that we want the agent to have a clear standard to check its work against so it can verify that the feature is working as intended. These tests make sure to cover as many cases as possible so that we can verify the workflow underneath the app is working right with different inputs. For making that easier, we modified our previous TDD planner skill so that it fits this workflow. This skill basically

[08:15] plans and writes the tests for the feature that is given to it. This skill makes sure that everything that can be verified without a browser gets tested at this point. That’s because a lot of things don’t need a browser to be checked, such as whether a manager is allowed to approve someone’s leave. For that, the agent can use a piece of code to verify that part directly, and it doesn’t need to press buttons to see if it’s approved or not. The sub agent that planned the tests earlier was following this skill. This step comes after our last step where we created the checkpoints using the agent. Once you approve the checkpoints that were showed

[08:46] to you, the orchestrator starts working on the checkpoint one. What the orchestrator does first is start a few sub agents to write the tests which are needed for the first gate. They will all be failing at first because the feature that the tests are written for isn’t written yet. Once the tests are done, the orchestrator starts another sub agent that actually writes the code for this checkpoint. Then the orchestrator uses one more sub aent to run the tests and make sure every one of them passes. And once every test passes, gate one is marked as passed for checkpoint one. Then the orchestrator moves on to the

[09:16] next round of review, which is the UI gate. The UI review gate is one of the most important gates because it directly affects the user experience. Since Shopify was converting one app into another form, keeping the design exact same became really important. For this gate, Shopify used Gemini models as a perfectionist design reviewer. That’s because when they were testing, they found that these models have very good spatial awareness, which means the models can tell where things are on a screen and how big they are. So, Gemini can catch small differences in spacing

[09:48] and size between two screens. But when you’re working on your own projects or when you’re building for clients, you normally don’t have anything to review against. So in those cases, we create HTML prototypes first. Creating prototypes lets us quickly demo the products visuals and experiment with directions without worrying about affecting the main project. The prototype is also what we show our clients to get their approval. To create these prototypes, we use another skill called prototype. The prototype skill builds the whole prototype as one file that we can open and click through so we

[10:19] can see if what we want is actually being created. This skill follows the project’s own guidance like the design file. It is a structured file listing all the design details for building the design. We had already created one for our app by using the design.md planner skill that we’ve provided in our AI labs design system in the community. With that file in place, the prototypes get created before UI gets built. To compare the prototype with the app we built, we use a separate skill. This skill makes sure the visuals match and it also makes

[10:50] sure both of them behave the same way when you interact with them. Before comparing anything, the skill also checks that the prototype and the app are in the same state. For example, a button that’s not been submitted and has been submitted are in two different states. So, the skill makes sure the prototype and the app are both showing the form in the same state. But we didn’t use Gemini for this. Instead, the skill hands the comparison to Claude in a new session by launching it from the session itself. Not every checkpoint needs this gate because gate one already tests most things without a browser.

[11:21] That’s why only some of our checkpoints that were shown on the viewer earlier were missing this gate. So, when the orchestrator gets to a checkpoint that needs this gate, it starts two separate clawed sub aents side by side. One reviews how the screen looks and the other reviews how it behaves. Neither of them sees the project’s instructions. So they judge the app only against the prototype and the design file. Each one returns a review of the differences and the orchestrator combines the two. That combined review then decides whether this gate passes or fails. Now the feature works and it looks like the

[11:53] prototype, but the code underneath can still be a mess. So that’s where the next gate comes in. The third gate is actually the adversarial review gate. The adversarial review means it’s set up to argue against the code. Shopify has heavy review processes because they need to make sure what they ship is up to their standards. Their method uses two adversarial agents that check the code against a standard Shopify wrote down. Every problem they find has to be fixed and only when both of the agents approve is this gate passed. So we also did this with two agents but rather than having

[12:24] both of the agents criticize the code, we went with an adversarial loop where one agent is criticizing and the other is fixing. The first agent is the adversarial agent which basically assumes that the code is wrong and tries to find issues with it. The second one is the fixer agent which actually fixes the issues the adversarial agent finds. To coordinate the workflow, we have a skill called adversarial loop that manages the communication between the two agents. When the behavior gate and the UI gate are passed, the orchestrator starts the adversarial agent and waits for its review. If the adversarial agent

[12:55] reports back with no issues, the orchestrator just marks the gate as done. Otherwise, the orchestrator starts the fixer agent to make the fixes and then the adversarial agent checks the code again. The two agents go back and forth like this and the gate is only done once the adversarial agent approves the code. The last step is the human in the loop and it’s a really important step because even if agents have standards and things to review against, they won’t be able to review from the perspective of a human. You need to make sure that the feature works properly when a person actually uses it. So when

[13:26] all of the checkpoints are done, you need to test the feature to make sure it works the way you wanted. You also check whether anything in it would work or look better so that you can ask for small changes to the feature. When you ask for changes, the orchestrator turns them into new checkpoints that go through all the same gates and it writes your feedback down in a learnings file that every agent reads before it starts work. Now the whole workflow that we just went through is run by a single skill called the orchestrator that we talked about earlier. When you just prompt this skill, it runs it through

[13:56] the whole workflow from checkpoints to giving you the end feature to review. The orchestrator will only stop for you twice. It stops once after it plans the checkpoints so you can approve them and again when it’s done so that you can check the app and complete the cycle. So the agent can get things wrong along the way, but the gates never let unfinished work through. Shopify puts it this way that an attempt is allowed to be wrong. It is not allowed to ship until it isn’t. So the whole workflow is something you can create on your own by prompting Claude telling the task you want this skill to perform. But if you

[14:26] want the skills that we have created in this workflow, you can get them in AIABS Pro which is our community. So if you found value in what we do and want to support the channel, this is the best way to do it. The links 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.