Pare de começar pelo código: o novo primeiro passo da Anthropic

Autoria: Hyperautomation Labs · 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: Stop Starting With Code. Anthropic’s New First Step · Canal: Hyperautomation Labs · 13:00 · 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 curso AI Native SDLC Playbook, da Anthropic, propõe reorganizar o ciclo de desenvolvimento de software para um cenário em que a IA acelera a programação, mas planejamento, revisão e lançamento continuam sendo gargalos. O método divide o trabalho em seis etapas e conecta cada uma a um arquivo registrado no Git, criando um histórico de decisões e aprovações. Entre as práticas estão usar plan mode, manter o arquivo claude.md, criar skills e hooks, e dar ao Claude meios de verificar o próprio trabalho. Para começar, o vídeo recomenda adotar três práticas simples: documentar as orientações do projeto, exigir um comando de teste e criar um hook para bloquear ações indesejadas.

Pontos-chave

Quando a IA acelera a escrita de código, planejamento, revisão e lançamento podem se tornar os principais gargalos.
O curso organiza o desenvolvimento em seis etapas: planejar, projetar, construir, testar, lançar e manter.
Cada etapa termina com um arquivo registrado no Git, que serve de ponto de partida para a etapa seguinte e de trilha de auditoria.
No plan mode, Claude prepara um plano que precisa ser aprovado antes de poder editar arquivos.
O arquivo claude.md registra instruções do projeto; erros repetidos do Claude devem orientar sua atualização.
Skills oferecem instruções reutilizáveis, mas hooks podem impor bloqueios e aprovações de forma mais confiável.
Testes devem permitir que Claude verifique o próprio trabalho; em correções, o agente não deve enfraquecer o teste que falhou.
Evals podem ser executados regularmente e também após mudanças em claude.md, skills ou hooks.
A automação deve respeitar portões de aprovação: agentes podem preparar mudanças, mas não aprovar o próprio código nem contornar o processo de deploy.
Para começar, o vídeo sugere três ações: criar um claude.md curto, definir um comando de teste obrigatório e configurar um hook para bloquear uma ação proibida.

Capítulos

Início	Capítulo	Resumo
00:00	Por que o desenvolvimento precisa mudar	O vídeo apresenta o curso da Anthropic e explica como a aceleração da programação desloca os gargalos para as etapas ao redor do código.
02:01	Planejamento e design documentados	As duas primeiras etapas registram a intenção do trabalho em intent.md e a transformam em requisitos e design em spec.md.
03:34	Construção com plano, instruções e paralelismo	A etapa de construção combina plan mode, claude.md, skills e sessões paralelas para orientar o trabalho de Claude.
06:41	Testes, revisão e controles de lançamento	O vídeo aborda verificação do próprio trabalho, evals, revisão de código por humanos, hooks como portões de aprovação e automação de CI e deploy.
09:51	Manutenção, resultados e por onde começar	A manutenção fecha o ciclo ao transformar problemas observados em novas intenções; o vídeo apresenta números da Anthropic e recomenda práticas iniciais.

Citações

Quando programar deixa de ser o gargalo, o que muda? — 00:00

Se você guardar uma coisa de Claude Code, que seja este fluxo: explorar, planejar, programar e fazer commit. — 04:05

Sempre dê a Claude uma maneira de verificar o próprio trabalho. — 06:41

Se algo precisa acontecer sempre, sem falhas, não coloque em um prompt. Coloque em um hook. — 09:20

É tudo uma questão de confiança, mas com verificação. — 11:58

Conceitos e entidades

Anthropic (empresa): Empresa que publicou o curso AI Native SDLC Playbook apresentado no vídeo.
AI Native SDLC Playbook (conceito): Curso da Anthropic que apresenta práticas para adaptar o ciclo de desenvolvimento de software ao uso de IA.
Claude Code (ferramenta): Ferramenta de programação com IA abordada como parte do fluxo de desenvolvimento apresentado.
Fiona Fung (pessoa): Líder de engenharia e produto de Claude Code, citada na abertura do vídeo.
intent.md (conceito): Arquivo que registra o problema, o resultado esperado, as pessoas afetadas, os limites e as questões em aberto.
spec.md (conceito): Arquivo de requisitos e design elaborado a partir de uma intenção aceita.
plan.md (conceito): Arquivo que registra o plano de implementação antes de Claude começar a editar código.
CLAUDE.md (conceito): Arquivo na raiz do projeto com instruções, comandos e regras que Claude lê ao iniciar uma sessão.
hooks (conceito): Scripts que podem permitir, exigir aprovação ou bloquear uma ação antes de Claude executá-la.
evals (conceito): Conjunto de tarefas reais usado para avaliar o comportamento do agente, inclusive após mudanças nas instruções ou nos hooks.

Tradução completa (pt-BR)

00:00 A Anthropic acabou de lançar um curso gratuito sobre como o software é desenvolvido hoje — não a parte do código, mas tudo ao redor dela. E ele começa com uma pergunta da pessoa que lidera a engenharia do Claude Code. >> Quando programar deixa de ser o gargalo, o que muda? E, na equipe do Claude Code, programar já não é realmente a parte mais lenta. Por isso, sentimos que precisávamos mudar um pouco todos os processos anteriores e posteriores à programação.

00:30 >> Essa é Fiona Fung, que lidera a engenharia e o produto do Claude Code. Este curso é a resposta da Anthropic à pergunta dela. Ele se chama AI Native SDLC Playbook. São 14 aulas, com cerca de uma hora de duração, e eu li todas as páginas. Ao fim deste vídeo, você vai conhecer as seis etapas, o arquivo que cada etapa deixa para trás e o sexto ponto por onde você pode começar na segunda-feira, sem ter mais nada implementado. Aqui está o

01:00 problema com que o curso começa. Hoje, as equipes escrevem código com IA a uma velocidade que ninguém esperava há um ano, mas o processo ao redor do código não mudou. Os mesmos pontos de aprovação, as mesmas revisões, as mesmas transferências de trabalho. Veja este diagrama da primeira aula. Antes dos agents, a etapa de build era o bloco longo. Depois dos agents, ela encolhe até virar uma faixa estreita. Então, agora as partes lentas são tudo ao redor dela. Planejamento, revisão e lançamento ainda

01:30 acontecem em velocidade humana, porque programar já não é o gargalo e também estamos fazendo muito mais disso. Estes são alguns dos novos gargalos que estamos observando. No fim, somos sempre nós perguntando: este código está correto? Quem revisa este código? Então, o curso transforma a antiga linha reta em um ciclo, com Claude em cada etapa e pessoas acima dele, iniciando, orientando e aprovando o trabalho. E aqui está a ideia que mantém tudo isso unido. Cada etapa termina com um commit de um arquivo no Git, e a próxima

02:01 etapa começa lendo esse arquivo. Uma intenção aceita inicia o design. Uma especificação aprovada inicia o plano. Um pull request integrado inicia o pipeline. Assim, o histórico de commits se torna a trilha de auditoria. Quem pediu o quê? O que o agent construiu e quem aprovou? >> Um colega meu disse uma vez que o arquivo Markdown é a língua franca da IA no ciclo de vida do desenvolvimento de software. >> A primeira etapa é planejar, e o arquivo é intent.md.

02:32 Alguém tem uma ideia. Em vez de um ticket no backlog e três reuniões, a pessoa explica o problema ao Claude com as próprias palavras. Claude faz as perguntas que um analista faria: para quem é, o que está dentro do escopo e como é o sucesso. Então, ele escreve isto: o problema, o resultado, quem é afetado, os limites e as questões em aberto. A pessoa corrige o que Claude entendeu errado e faz o commit. O curso diz que isso deve passar de algumas

03:03 semanas para algumas horas. A segunda etapa é o design. Depois que a intenção é aceita, Claude a transforma em uma especificação de requisitos e design, spec.md. Este é o prompt usado no curso. E a última linha é a parte inteligente. Descreva claramente quaisquer pontos de preocupação, especialmente aqueles em que você não consegue atender a políticas conflitantes. As regras da empresa para marca, segurança e design são carregadas como skills. Assim,

03:34 os conflitos aparecem enquanto a especificação está sendo escrita, e não em uma revisão semanas depois. O responsável pelo produto revisa a especificação, mas não a escreve. E uma pessoa sempre decide se ela segue para a etapa de build. Uma coisa rápida: se isso for útil, inscreva-se no canal. É grátis. E, para apoiar o trabalho, clique em Participar ou no botão de apoiador no Facebook. Agora, a terceira etapa. A terceira etapa é build e tem quatro práticas. A primeira é o modo de planejamento. O engenheiro inicia o Claude Code no modo de planejamento, entrega a especificação

04:05 e pede um plano. Quais arquivos serão alterados, em que ordem, e quais testes comprovam que funciona? >> Se você guardar uma só coisa sobre o Claude Code, que seja este workflow: explorar, planejar, programar e fazer commit. >> Depois, questione o plano. O que isso poderia quebrar? Qual etapa é a mais arriscada? O que você decidiu não fazer? Continue até que um engenheiro que nunca viu a conversa consiga implementar tudo apenas com base no plano. O modo de planejamento impõe isso

04:37 por conta própria, porque Claude não pode editar nenhum arquivo até você aceitar o plano. Você faz o commit como plan.md e, mais tarde, a revisão de código compara a alteração final com ele. A segunda prática é o arquivo CLAUDE.md. Pense nele como aquilo de que uma pessoa recém-contratada precisa no primeiro dia. Os comandos de build e de teste, as regras da equipe e uma seção que este exemplo chama de coisas que Claude erra. Execute /init. Reduza o arquivo para menos de uma página e faça o commit.

05:07 Depois, siga uma regra do curso. Quando Claude comete o mesmo erro duas vezes, a correção vai para o CLAUDE.md. É um arquivo Markdown que você adiciona à raiz do projeto, e o Claude Code o lê automaticamente sempre que você inicia uma sessão. É como um roteiro de integração para a sua base de código. A terceira prática são as skills. Uma skill é uma pasta pequena que diz ao Claude quando usá-la e exatamente o que fazer. Por exemplo, o padrão de segurança de API desta empresa. A pessoa responsável pela política aprova, e todos recebem a nova

05:39 versão na sessão seguinte. Mas aqui está o ponto que a maioria das pessoas não percebe. Uma skill é apenas uma orientação. Claude geralmente vai segui-la, mas nada o obriga a isso. Nas palavras do curso, a skill torna as violações raras, e um hook as torna quase impossíveis. >> Se você perceber que está explicando a mesma coisa ao Claude repetidamente, bem, isso é uma skill esperando para ser escrita. >> A quarta prática são sessões paralelas. Um engenheiro executa duas ou três sessões do Claude ao mesmo tempo, cada uma na própria árvore de trabalho,

06:10 para que nunca mexam nos mesmos arquivos. Tarefas que você repete se tornam subagents, como este verificador, que executa o aplicativo e informa o que observa, mas não tem permissão para corrigir nada. E o limite não é o seu laptop. É quantas sequências de trabalho uma pessoa consegue revisar direito. >> Vai ser muito tentador usar várias instâncias do Claude ao mesmo tempo. Sei que há pessoas na Anthropic e alguns clientes que usam quatro instâncias do Claude simultaneamente. A quarta etapa é testar, e nela está a regra mais

06:41 útil de todo o curso. Sempre dê ao Claude uma maneira de verificar o próprio trabalho. Um comando para os testes, um para o build e uma captura de tela para qualquer coisa que apareça na tela. Para corrigir um bug, Claude escreve primeiro o teste que falha. Você confirma que ele falha e faz o commit. Só então pede a correção. E esta linha vai direto para o seu CLAUDE.md: se um teste falhar, corrija o código, não o teste. O curso até sugere um hook

07:13 que bloqueia edições nos arquivos de teste durante uma correção. Assim, o agent não consegue enfraquecer a própria verificação. >> A verificação é muito importante porque, para a nossa equipe em particular, prestamos muita atenção à verificação. E aí, >> quando Claude cria um PR para mim no Claude Code, sim, >> ele testa e me envia capturas de tela de como vai ficar. E então você ganha confiança. >> A segunda prática são os evals. Reúna de 20 a 50 tarefas reais de trabalhos recentes, cada uma com o resultado que você aceitaria. Execute-as no CI todas as noites e sempre que alguém alterar o CLAUDE.md, uma skill ou um hook. Essa configuração orienta o agent, que é testado como código, e cada incidente em produção se torna um novo eval. Assim, o mesmo erro não pode voltar silenciosamente. Então, quando pensamos em mudar os prompts, como fazemos para saber se melhoramos as coisas, se elas continuam iguais ou se estragamos completamente o Claude Code? >> A quinta etapa é o deploy, e a primeira prática é usar IA na revisão de código. O líder técnico

07:45 escreve um arquivo de revisão com três etapas: bugs, segurança e se a alteração corresponde à especificação e ao plano. O arquivo também limita a cinco as observações sobre detalhes menores por revisão. E aqui está o ponto de governança: o agent que escreveu o código não tem como aprová-lo. As descobertas ajudam uma pessoa, e um responsável pelo código ainda aprova o merge. >> Claude realmente ajuda os revisores humanos a escolher onde concentrar o tempo e a

08:17 energia. Você pode deixar Claude identificar essas pequenas coisas e resolvê-las de forma autônoma. Então, essa já não é realmente a parte importante da revisão de código humana. >> É. Em seguida, hooks como etapas de aprovação. Um hook é um script pequeno que é executado antes de Claude agir e pode permitir a ação, pedir a aprovação de alguém ou bloqueá-la. Neste exemplo, qualquer deploy em produção sem uma aprovação de lançamento identificada pelo nome é bloqueado, e o motivo é enviado diretamente de volta ao Claude. Os hooks que uma equipe nunca deve

08:48 energia. Você pode deixar o Claude descobrir essas coisinhas e resolvê-las de forma autônoma. Então, não é bem essa a parte importante da revisão humana de código hoje em dia. >> É. Em seguida, ganchos como barreiras de aprovação. Um gancho é um pequeno script que é executado antes de o Claude agir e pode permitir a ação, pedir a confirmação de uma pessoa ou bloqueá-la. Neste caso, qualquer deploy de produção sem uma aprovação de release com um responsável identificado é bloqueado, e o motivo é enviado diretamente de volta ao Claude. Os ganchos que uma equipe nunca deve

09:20 desative, acesse as configurações de gerenciamento, que a equipe da plataforma controla e que os engenheiros não podem sobrescrever. Se algo precisa acontecer sempre, sem falhar, não coloque isso em um prompt. Coloque em um hook. >> Depois, CI e deploy. Comece com tarefas somente de leitura, como Claude lendo um build com falha e escrevendo um resumo de três linhas no pull request. Depois, adicione tarefas que escrevam por trás dos controles que você já tem. Tudo o que o agent escrever chega como um

09:51 pull request, sem possibilidade de enviar diretamente para main. O curso resume isso em uma frase. O agent pode agir até o controle de produção, mas não pode ultrapassá-lo. >> E então, automação headless. Acho que essa é a coisa que mais nos empolga, mas também ainda estamos tentando entender internamente: como podemos usar Claude de forma programática? Já fazemos isso no GitHub Actions. Queremos descobrir outros lugares criativos onde podemos começar a usá-lo. >> A etapa seis é manutenção. E é aqui que

10:21 a linha se transforma em um loop. Um script simples, sem IA, monitora um número, como a frequência com que seus testes falham. As regras ficam em um pequeno arquivo chamado bands.yml. Se estiver um pouco fora do normal, ele apenas registra isso. Se estiver mais fora do normal, Claude investiga em modo somente leitura. Se estiver muito fora do normal, Claude pode agir, mas apenas abrindo um pull request ou executando uma reversão aprovada previamente. E tudo o que encontrar, ele

10:52 registra em um arquivo intent.md totalmente novo. Essa é a etapa um. Mais uma vez, o loop se alimenta sozinho. >> Agents proativos superam agents reativos. Queremos que Claude passe de uma ferramenta a um colega de equipe. Você pode passar de um agent que espera você pressionar Enter e criar um PR para um agent que reage a problemas e abre um PR por conta própria. >> Então, isso funciona em escala? A equipe de segurança da Anthropic publicou seus próprios números. Agora, Claude escreve cerca de 80% do

11:24 código integrado na Anthropic. Seus engenheiros entregam oito vezes mais código por trimestre do que entregavam de 2021 a 2025. E a proporção de pull requests que recebem comentários de revisão de verdade cresceu de 16% para 54%. Então, por onde começar? O curso organiza as 12 práticas de acordo com aquilo de que elas dependem. E a fileira de cima não depende de nada. Capturar a intenção, CLAUDE.md, skills, o loop de feedback, hooks e modo de planejamento. Se você trabalha sozinho, escolha

11:58 três para esta semana. Um CLAUDE.md com menos de uma página. Um comando de teste que Claude precisa executar antes de dizer que terminou. E um hook que bloqueie aquilo que você nunca gostaria que um agent fizesse. >> Mas, onde definitivamente ainda quero uma pessoa é na questão da expertise. Tudo se resume a confiar, mas verificar. >> Falando sério, 90% de vocês que estão assistindo ainda não se inscreveram. No Facebook, inscrever-se é o botão de apoiador. É isso que mantém as luzes acesas por aqui. No YouTube, é

12:28 de graça e avisa o algoritmo para mostrar mais conteúdo para você. Inscreva-se para nos apoiar. Coloquei todos os arquivos deste vídeo em um PDF gratuito chamado “Os seis arquivos preenchidos a partir de uma execução real”: intent, spec, plan, CLAUDE.md com os hooks, o arquivo de evals e revisão, e bands.yml, além da ordem para adotá-los. Comente “intent” e meu bot enviará o PDF para você. É novo no Claude Code? Meus guias para iniciantes estão

13:00 nos links abaixo. Para apoiar diretamente este canal, clique em “Participar” abaixo deste vídeo ou no botão de apoiador no Facebook, e acompanhe no Instagram as dicas rápidas. Seis etapas, seis arquivos, um loop. E as pessoas ainda tomam todas as decisões importantes. Até a próxima.

Transcrição original

[00:00] Antropic just released a free course on how software gets built now, not the code part, everything around it. And it starts with a question from the person who runs engineering on cloud code. >> When coding is no longer the bottleneck, what changes? And so on the cloud code team, coding is really the slow part anymore. And so like that’s why all the upstream and all the downstream kind of like processes we felt like we’ve have to change a little bit.

[00:30] >> That’s Fiona Fung who leads engineering and product for claude code. This course is anthropic answer to her question. It’s called the AI native SDLC playbook. 14 lessons about an hour and I went through every page. By the end of this video you’ll know all six stages. the one file each stage leaves behind and the sixth place you can start on Monday with nothing else in place. Here’s the

[01:00] problem the course opens with. Teams now write code with AI at a speed nobody expected a year ago, but the process around the code hasn’t changed. Same approval gates, same reviews, same handoffs. Look at this diagram from the first lesson. Before agents, build was the long block. After agents, build shrinks to a sliver. So now the slow parts are everything around it. Planning, review, and release still

[01:30] running at human speed because coding is no longer the bottleneck and also we’re doing so much more of it. These are some of the new bottlenecks that we’re seeing. So it’s really always us asking is this code correct? Who reviews this code? So the course turns the old straight line into a loop with Claude at every stage and people above it, starting it, steering it, and approving it. And here’s the idea that holds the whole thing together. Every stage ends by committing one file to Git, and the next

[02:01] stage starts by reading that file. An accepted intent starts the design. An approved spec starts the plan. A merged pull request starts the pipeline. So your history of commits becomes the audit trail. Who asked for what? What the agent built and who approved it. >> Colleague of mine once said the markdown file is the lingua frana of the AI in nature of software development life cycle. >> Stage one is plan and the file is intent.md.

[02:32] Someone has an idea. Instead of a backlog ticket and three meetings, they explain the problem to Claude in their own words. Claude asks what an analyst would ask, who it’s for, what’s in scope, and what success looks like. Then it writes this, the problem, the outcome, who’s affected, the limits, and the open questions. The person fixes anything Claude got wrong and commits it. The course says this should go from a few

[03:03] weeks to a few hours. Stage two is design. Once the intent is accepted, Claude turns it into a requirements and design spec spec.md. This is the actual prompt from the course. And the last line is the clever part. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies. The company’s rules for brand security and design are loaded as skills. So

[03:34] conflicts show up while the spec is being written, not in a review weeks later. The product owner reviews the spec, but doesn’t write it. And a human always decides if it goes to build. Quick one. If this is useful, hit subscribe. It’s free. And to back the work, hit join or the supporter button on Facebook. Now, stage three. Stage three is build and it has four plays. The first is plan mode. The engineer starts clawed code in plan mode, hands

[04:05] it the spec and asks for a plan. Which files change in what order and which tests prove it works? >> If you take one thing away from cloud code, let it be this workflow. Explore, plan, code, and commit. >> Then you question the plan. What could this break? Which step is riskiest? What did you decide not to do? Keep going until an engineer who never saw the conversation could build it from the plan alone. Plan mode enforces this on

[04:37] its own because Claude can’t edit a single file until you accept the plan. You commit it as plan MD and later the code review checks the final change against it. Play two is the claude.md file. Think of it as what a new hire needs on day one. The build and test commands the team’s rules and a section this example calls things Claude gets wrong. Run /init. Cut it to under a page and commit

[05:07] it. Then follow one rule from the course. When Claude makes the same mistake twice, the fix goes into claude.md. It’s a markdown file that you add to the root of your project and Cloud Code reads it automatically every time you start a session. It’s like an onboarding script for your codebase. Play three is skills. A skill is a small folder that tells Claude when to use it and exactly what to do. Like this company’s API security standard. The policy owner signs off and everyone gets the new

[05:39] version in their next session. But here’s the line most people miss. A skill is advisory. Claude will usually follow it, but nothing forces it to. In the course’s words, the skill makes violations rare, and a hook makes them close to impossible. >> If you find yourself explaining the [music] same thing to Claude repeatedly, well, that’s a skill waiting to be written. >> Play four is parallel sessions. One engineer runs two or three Claude sessions at once, each in its own work

[06:10] tree, so they never touch the same files. jobs you repeat become sub agents, like this verifier, which runs the app and reports what it sees, but isn’t allowed to fix anything. And the limit isn’t your laptop. It’s how many streams one person can properly review. >> It’s going to be very tempting to use multiple clouds at once. And so I know people at Anthropic and a few customers that run four clouds at the same time. Stage four is test and it holds the most

[06:41] useful rule in the whole course. Always give Claude a way to check its own work. One command for the tests, one for the build and a screenshot for anything on screen. For a bug fix, Claude writes the failing test first. You confirm it fails and you commit it. Only then do you ask for the fix. And this line goes straight into your claude.md. If a test fails, fix the code, not the test. The course even suggests a hook

[07:13] that blocks edits to test files during a fix. So the agent can’t weaken its own check. >> Verification is so important because like I think we for our team especially, we have, you know, really paid a lot of attention to verification. And so >> when Claude creates a PR for me for cloud code, yes. >> Uh it tests it, it sends me screenshots for what it will look like. uh and then you kind of get confidence. concern. >> Play two is eval. Collect 20 to 50 real tasks from recent work, each with the

[07:45] result you’d accept. Run them in CI every night and every time someone changes claude.md a skill or a hook. That setup steers the agent so it gets tested like code and every production incident becomes a new evil. So the same mistake can’t quietly come back. So when we think about changing the prompts, how do we make how do we know we made things better or the same and we didn’t totally ruin cloud code? >> Stage five is deploy and the first play is AI in code review. The tech lead

[08:17] writes a review file with three passes bugs, security, and whether the change matches the spec and the plan. It also caps nitpicks at five per review. And here’s the governance point. The agent that wrote the code has no way to approve it. The findings inform a human and a code owner still approves the merge. >> Claude really helps human reviewers uh choose where to focus their time and

[08:48] energy. You can have Claude figure out those little things and address them autonomously. So it’s like that’s not really the important part of human code review anymore. >> Yeah. Next, hooks as approval gates. A hook is a small script that runs before Claude acts and it can allow the action, ask a person or block it. In this one, any production deploy without a named release approval gets blocked and the reason goes straight back to claude. The hooks a team must never

[09:20] switch off go into manage settings which the platform team controls and engineers can’t override. If something needs to happen every time without fail, don’t put it in a prompt. Put it in a hook. >> Then CI and deployment. Start with read only jobs like Claude reading a failed build and writing a threeline summary on the pull request. Then add jobs that write behind the gates you already have. Anything the agent writes arrives as a

[09:51] pull request with no way to push straight to main. The course sums it up in one sentence. The agent may act up to the production gate and cannot pass it. >> And then headless automation. I think this is the thing we’re most excited about, but also we are still trying to wrap our heads around internally, which is how can we use Claude programmatically. We have that in GitHub actions. We want to figure out other creative places we can start using it. >> Stage six is maintain. And this is where

[10:21] the line becomes a loop. A plain script with no AI in it watches one number like how often your tests fail. The rules live in a small file called bands.yuml. A little offn normal and it just logs it. Further off and claude investigates read only way off and claude may act but only by opening a pull request or running a roll back that was approved in advance. and whatever it finds, it

[10:52] writes up as a brand new intent MD. That’s stage one. Again, the loop feeds itself. >> Proactive agents uh beat reactive agents. We want Claude to go from a tool to a teammate. Um you can move from an agent that is waiting for you to actually press enter and create a PR to an agent that reacts to problems um and opens a PR itself. >> So, does this work at scale? Anthropic’s security team team published their own numbers. Claude now writes about 80% of

[11:24] the code merged at Anthropic. Their engineers ship eight times as much code per quarter as they did from 2021 to 2025. And the share of pull requests that get real review comments grew from 16% to 54. So where do you start? The course maps all 12 plays by what they depend on. And the top row needs nothing at all. Capture intent, claude.m MD, skills, the feedback loop, hooks, and plan mode. If you are one person, pick

[11:58] three for this week. A claude MD under a page. One test command Claude has to run before it says done. And one hook that blocks the thing you’d never want an agent to do. >> But where I still definitely want a human is that expertise. It’s all about trust but verify. >> Real talk, 90% of you watching haven’t subscribed. On Facebook, subscribe is the supporter button. That is what keeps the lights on here. On YouTube, it’s

[12:28] free and it tells the algorithm to send you more. Subscribe to support us. I put every file from this video into one free PDF called the six files filled in from a real run. intent, spec plan, claude.m MD with the hooks, the evals and review file and bands.yml plus the order to adopt them. Comment intent and my bot sends it to you. New to claude code? My beginner guides are

[13:00] linked below. To support this channel directly, hit join under this video or the supporter button on Facebook and follow along on Instagram for the quick wins. Six stages, six files, one loop. And people still make every call that matters. See you in the next one.