O novo INTENT.MD do Claude Code: o que é?

Autoria: Rob Shocks - Switch Dimension · 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: Claude Codes New INTENT.MD, What is It? · Canal: Rob Shocks - Switch Dimension · 15:58 · Assistir no YouTube

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

Resumo

O vídeo apresenta o playbook de SDLC nativo em IA da Anthropic e explica como agentes podem participar de todo o ciclo de desenvolvimento de software, não apenas da etapa de implementação. O processo começa com um arquivo intent.md, que registra a intenção de quem propõe uma funcionalidade ou relata um problema, e segue por especificação, planejamento, implementação, testes, deploy e manutenção. O apresentador destaca artefatos padronizados, agentes especializados, hooks, testes e evals, além de controles de governança e revisão humana. Ele ressalta que não existe um fluxo único adequado a todas as equipes.

Pontos-chave

Com agentes, a implementação deixa de ser o principal gargalo; o processo passa a ser o foco de otimização.
O arquivo intent.md registra, em formato legível por pessoas e acionável por máquinas, a intenção e o contexto de uma funcionalidade ou problema.
A cadeia de artefatos pode incluir intent.md, uma especificação e um plano, que devem ser revisados e padronizados pela equipe.
Agentes independentes podem assumir diferentes etapas, recebendo documentos para trabalhar sem depender do histórico de conversas de outro agente.
Hooks, permissões, linting e worktrees ajudam a automatizar tarefas e controlar o que os agentes podem fazer.
Na etapa de testes, agentes podem executar testes, verificar o projeto e, com ferramentas adequadas, testar a interface e registrar capturas ou gravações.
Evals podem ajudar a detectar regressões após mudanças em skills, modelos ou processos.
A revisão de pull requests e a manutenção também podem envolver agentes, com controles de segurança e aprovações humanas conforme o risco.
O fluxo deve ser adaptado à equipe e à criticidade das tarefas; o vídeo não recomenda substituir automaticamente processos existentes.

Capítulos

Início	Capítulo	Resumo
00:00	O SDLC nativo em IA e a mudança de gargalo	O vídeo introduz o ciclo de desenvolvimento de software e explica por que, com agentes, o processo inteiro passa a ser o foco.
01:02	Registrar a intenção em intent.md	O apresentador descreve entrevistas com agentes, a criação do intent.md e a organização das intenções em um backlog.
04:36	Da intenção à especificação e ao plano	A intenção aprovada dá origem a uma especificação e, depois, a um plano que deve ser claro o suficiente para orientar a implementação.
08:11	Implementação, governança e automação	O vídeo aborda permissões, worktrees, hooks, linting e subagents para acelerar e controlar a etapa de implementação.
10:46	Testes, evals e revisão de pull requests	Agentes podem executar testes e evals, enquanto revisões e controles de segurança ajudam a validar mudanças antes do deploy.
13:52	Manutenção e limites da automação	O apresentador propõe o uso de agentes para diagnosticar problemas de manutenção e conclui que cada equipe deve adaptar o fluxo ao seu contexto.

Citações

O código não é mais o gargalo; o processo é. — 00:30

O agente sintetiza os pontos de dor diretamente das fontes e os registra nesse arquivo intent.md, legível por pessoas e acionável por máquinas. — 01:32

Você quer chegar a um ponto em que, se entregasse esse arquivo plan.md a um engenheiro, ele pudesse implementar as mudanças sem consultar os documentos de intenção ou especificação. — 07:08

Realmente não existe uma solução única para todos. — 15:26

Conceitos e entidades

AI-native SDLC (conceito): Abordagem de ciclo de vida de desenvolvimento de software que incorpora agentes de IA às etapas de planejamento, implementação, testes, deploy e manutenção.
SDLC (conceito): Ciclo de vida de desenvolvimento de software, que no vídeo inclui planejamento, design, implementação, testes, deploy e manutenção.
intent.md (conceito): Arquivo que registra a intenção, as necessidades e o contexto de uma funcionalidade, problema ou melhoria.
artifact chain (conceito): Sequência de documentos produzidos ao longo do processo, como intent.md, especificação e plano.
Claude Code (ferramenta): Ferramenta mencionada como parte do fluxo de desenvolvimento assistido por agentes descrito no vídeo.
Anthropic (empresa): Empresa cujo playbook de SDLC nativo em IA é apresentado e discutido no vídeo.
Neon (empresa): Patrocinadora do vídeo, apresentada como uma plataforma de banco de dados com recursos voltados a workflows com agentes.
Cursor (ferramenta): Ferramenta citada como opção para planejar e desenvolver software com agentes.
Codex (ferramenta): Ferramenta mencionada como opção para trabalhar com agentes nas etapas do desenvolvimento.
Playwright (ferramenta): Ferramenta citada como opção para permitir que um agente teste software e registre evidências visuais.
Boris Cherny (pessoa): Criador do Claude Code, segundo a apresentação feita no início do vídeo.

Tradução completa (pt-BR)

00:00 Então, este é Boris Journey, o criador do nosso amigo Claude Code, e esse pessoal acabou de lançar seu playbook de SDLC nativo de IA. Se esse conceito é novo para você, SDLC é o ciclo de vida de desenvolvimento de software. Normalmente, em um fluxo de trabalho humano, ele é mais ou menos assim: você planeja, projeta, desenvolve, testa, faz o deploy e coloca em produção — dependendo do tipo de aplicativo — e depois cuida da manutenção. Então, volta ao início para a próxima funcionalidade, bug ou versão. Portanto, este novo documento da Anthropic trata de como

00:30 a equipe de lá, incluindo Boris, trabalha com seu novo ciclo de vida de desenvolvimento de software nativo de IA. Vamos fazer uma análise rápida. A grande ideia aqui é que o código não é mais o gargalo; o processo é. Antes da chegada dos agents, um SDLC era basicamente assim: tínhamos as etapas de planejamento, design, desenvolvimento, testes, deploy e manutenção. A etapa que levava mais tempo e normalmente era a mais cara era a de desenvolvimento. Mas isso mudou com os agents. Esta parte aqui foi reduzida a esta parte aqui. Olha quanto tempo nós

01:02 recuperamos. Então, basicamente, o que a Anthropic está dizendo é que fizemos um ótimo trabalho ao reduzir essa etapa — estamos duas vezes mais rápidos —, mas como podemos melhorar também todas as outras etapas com agents? Tradicionalmente, na etapa de planejamento, nos sentávamos, reuníamos requisitos, criávamos PRDs, fazíamos workshops, conversávamos com as partes interessadas e juntávamos tudo. Neste novo mundo, começamos fazendo os agents nos entrevistarem sobre a funcionalidade, o bug ou o produto que estamos desenvolvendo, para criar contexto. Eu uso minha própria skill de descoberta, chamada switch dimension discovery. Você poderia usar Realm me, de Matt Pocock, ou algo

01:32 como requirements discovery, do Cursor. O que você quer fazer é garantir que o agent faça perguntas repetidamente até ter um entendimento completo da funcionalidade que você está desenvolvendo ou do bug que está tentando resolver. Você despeja nessa conversa o máximo possível da sua experiência, do seu conhecimento do domínio e do contexto. Assim, o agent sintetiza os pontos problemáticos diretamente das fontes e depois os registra neste arquivo intent.md, que pode ser lido por humanos e executado por máquinas. A Anthropic está formalizando essa ideia em torno de um arquivo intent.md. Então, no

02:02 SDLC tradicional, a ideia passava por uma lista de pendências de entradas de usuários, histórias de usuário, pontos de história, transferências de responsabilidade e repasses. O que estamos discutindo no mundo nativo de IA é que quem origina a issue, a funcionalidade, o produto ou o que quer que seja, faz uma sessão de ideias com Claude e registra o resultado como intent.md. Para cada uma dessas etapas pelas quais vamos passar, desenvolveremos o que é chamado de cadeia de artefatos. Primeiro, começamos com um arquivo intent.md, depois teremos uma especificação e assim por diante, conforme avançamos pelas etapas. Isso é construir a cadeia de artefatos. Então, no seu

02:33 projeto, usando Cursor, Claude, Code, Codex ou o que você quiser, basta criar uma pasta chamada intent e salvar nela o arquivo intent.md. Então, nesta etapa de planejamento, posso conversar com meu agent sobre adicionar o modo escuro como funcionalidade, explicar o que quero e como quero que funcione, e depois criar um arquivo intent.md com base nisso. Em seguida, peço ao agent que salve o arquivo como intent.md na pasta intent, como a Anthropic propõe. E, claro, com qualquer um desses artefatos, sua equipe pode fazer o que quiser em termos de

03:04 workflow. Acho que o importante aqui é começar a padronizar e não mudar as coisas o tempo todo. Assim, a equipe, os agents e as skills trabalham todos no mesmo workflow, e vocês podem evoluir a partir daí. Quando esse arquivo intent.md é criado, o processo não acaba aí. A sugestão é que quem originou a intenção volte a revisar o que o agent escreveu para corrigir o que for necessário e garantir que ambos estejam satisfeitos. A pessoa que cria esse arquivo intent.md é chamada de originadora, e não precisa ser especialista da equipe. Pode ser qualquer pessoa que queira criar a intenção.

03:35 Pode ser um cliente que está enviando uma solicitação de correção de bug. Pode ser um gerente de produto com uma ideia para uma funcionalidade. Pode ser um desenvolvedor que quer registrar uma melhoria de processo. Então, talvez você tenha sua própria skill de registro de intenções, que produz algo parecido com isto. Com o tempo, ao coletar mais formas de intenção, você talvez queira colocar um prefixo com o nome da intenção antes do arquivo intent.md. É algo que venho fazendo e ensino no meu curso. Eu chamo isso de discovery, não de intent, mas, novamente, é a mesma ideia. Então, a intenção pode ser

04:05 registrada por qualquer pessoa. Pode ser um desenvolvedor ou um cliente enviando um bug. Basicamente, a pessoa só coloca suas ideias nesse arquivo intent.md. Mas é o responsável pelo produto que deve revisá-las na forma de um backlog. Elas podem ser simplesmente arquivos organizados em um arquivo Markdown. Todas essas ideias podem ser registradas no Notion ou no Linear e depois organizadas por um responsável pelo produto ou, em alguns casos, eu uso meus agents para fazer a triagem do backlog de issues. Dá para ver que eles podem atribuir tags como frontend, tarefas pequenas ou grandes, se é uma funcionalidade e até o nível de prioridade. Então,

04:36 passamos do artefato de intenção para o artefato de especificação. A Anthropic sugere que, assim que a intenção for registrada em um commit ou aprovada de alguma forma, você crie um hook ou processo para que a especificação seja gerada automaticamente. A Anthropic nos oferece um exemplo de prompt que poderíamos usar para transformar nossa intenção em uma especificação. Eles não estão fornecendo skills específicas para isso, mas certamente poderíamos criar uma skill. Basicamente: leia o arquivo intent.md anexado e produza uma especificação de requisitos e design. Use as skills disponíveis para planejar e

05:07 seguir as diretrizes da marca e, em seguida, documente a especificação por completo em spec.md. Dependendo do seu workflow e da sua organização, você pode simplesmente usar o modo de planejamento padrão do Cursor, Claude Code ou Codex, ou criar uma skill que produza especificações personalizadas, de acordo com a forma de trabalho da sua equipe. Não existe uma solução única para todos. Quando essa especificação for criada, pode ser apenas por meio de um agent padrão, ou vocês também podem ter um conjunto de diretrizes, políticas ou até skills para garantir que

05:38 os guias de estilo sejam aplicados e que a geração da especificação siga as melhores práticas da sua organização. Isso pode estar em um arquivo agents.md. Pode estar codificado em um conjunto de skills. É preciso garantir que essas skills e políticas sejam seguidas nas considerações de governança durante a geração da especificação. E isso se aplica a todos os artefatos desta cadeia. Uma breve pausa para falar do nosso patrocinador, Neon. Se você usa agents intensivamente no seu SDLC, recomendo muito que conheça a plataforma. Uso Neon há anos

06:08 para todas as minhas necessidades de banco de dados. Já falei bastante sobre como Neon é ideal para workflows com agents, graças ao excelente recurso de branching. O que adoro em Neon é que a plataforma é totalmente voltada para agents. Em todos os meus agents, por exemplo, no Cursor, tenho o MCP, a CLI e o conjunto de skills deles conectados. Assim, nem preciso tocar no dashboard. O agent sabe o que fazer com todos os serviços da plataforma. Se você não dá uma olhada em Neon há algum tempo, agora ela é uma plataforma completa. Inclui o Better Auth gerenciado, que se conecta ao seu banco de dados.

06:38 Você também tem funções de longa duração sem timeouts e armazenamento de objetos compatível com S3 para todos os arquivos dos seus projetos. Se você está desenvolvendo projetos e trabalhando com agents, recomendo muito Neon para facilitar sua vida. Os inscritos do canal podem conhecer a plataforma pelo link na descrição abaixo. Agora, vamos voltar ao SDLC. Em seguida, vamos entrar no modo de desenvolvimento. O processo começa basicamente com o engenheiro envolvido puxando a intenção e a especificação e inserindo-as no Claude Code ou no Cursor, no modo de planejamento, ou em algo do tipo.

07:08 Basicamente, alimentando-o com o intent e a spec. Então, o que obtemos é um arquivo plan.md. O que a Anthropic sugere é que você examine o plan perguntando que mudanças poderiam causar problemas. Em essência, você quer chegar a um ponto em que, se simplesmente entregasse esse arquivo plan.md a um engenheiro, ele pudesse implementar as mudanças sem consultar os documentos de intent ou spec. Isso é, na verdade, um ponto importante, porque não vamos ter um único agent executando todas essas etapas diferentes do ciclo de vida do desenvolvimento de software. Vamos ter uma context

07:40 window. Vamos ter um fio de conversas. Agents independentes, subagents, vão cuidar desse processo. Então, nesse cenário, aqui está um exemplo de um dos meus próprios workflows: você tem vários agents trabalhando no problema. Você quer entregar o planejamento e o intent na forma de documentos para cada um, para que possam começar do zero, sem conhecer a conversa anterior. Quando o engenheiro estiver satisfeito, ele prossegue com o plan. Você provavelmente já viu 50 maneiras de escrever um plan, mas, em essência, o que a Anthropic está dizendo é que você o divide nos

08:11 arquivos que precisam ser alterados, na ordem do trabalho ou em algum tipo de lista de tarefas, em quaisquer riscos e restrições e, então, nas comprovações. Portanto, você precisa de algum tipo de critério de sucesso e de verificações para garantir que o trabalho foi feito corretamente. Isso pode ser feito de forma determinística, com linting e testes. Uma parte importante do processo em uma empresa é a governança. Então, o que a Anthropic sugere é que você salve versões do seu plan, do seu intent e do seu spec.md, além de registrar quem os altera e como eles evoluem. As empresas com que trabalhei acham essa parte particularmente difícil, mas

08:42 isso é muito importante se você quiser acompanhar os indicadores antecedentes e defasados dos seus projetos, comprovar de fato suas métricas DORA ou ver a eficácia que a IA está alcançando nos seus workflows. Para deixar o modo de build mais rápido, a Anthropic sugere usar o modo automático. Isso realmente depende da sua organização. Minha sugestão é que, quando você estiver trabalhando em um ambiente bloqueado, comece a trabalhar no repo com um conjunto de permissões bem ajustadas e vá exercitando-as à medida que avança. Depois de definir uma política sobre o que é uso permitido,

09:14 quais ferramentas os agents podem acessar, quais fontes da web podem consultar e quais pacotes podem baixar, e de restringir isso por meio das permissões do cursor ou da nuvem, seus agents poderão trabalhar muito mais rápido sem a sua participação. Há muitos aspectos envolvidos para garantir que o modo automático funcione sem problemas e que o raio de impacto do seu agent seja limitado. Não vou abordar isso neste vídeo, mas espero falar mais sobre o assunto em outra ocasião. A equipe também sugere worktrees, para que vários agents possam trabalhar em várias coisas ao mesmo tempo. Se isso está completamente além do que você conhece, tenho um vídeo completo no meu canal sobre Git e Git worktrees, caso você esteja apenas

09:45 se acostumando a eles ao trabalhar com agents. Então, uma parte importante para manter esse processo autônomo, manter as coisas atualizadas e manter tudo nos trilhos é o uso de hooks. Por exemplo, na fase de build, podemos atualizar o plan quando a implementação estiver concluída. Podemos impedir o agent de trabalhar em determinadas pastas ou de usar um pacote NPM que ainda não aprovamos. O linting existe há muito tempo. É basicamente uma maneira determinística, ou codificada, de percorrer nosso código ou nossos documentos e verificar se determinados critérios estão presentes

10:16 ou não, ou se estamos seguindo uma sintaxe específica. Ele vai percorrer os arquivos; os testes vão passar ou não. O resultado será binário: sim ou não. Algo que um bom agent harness oferece é a capacidade de executar subagents. Então, depois que o plan estiver pronto — isso já vem integrado ao Cursor, Cloud Code e Codex —, ele divide o plan em várias tarefas diferentes que podem ser feitas de forma independente. E, se algumas puderem ser executadas em paralelo, ele pode usar worktrees. Assim, acabamos com vários agents e subagents trabalhando na etapa de build. Depois que terminamos de construir, passamos para a fase de testes. No ciclo de vida do desenvolvimento de software tradicional,

10:46 essa pode ser uma etapa que realmente atrasa tudo. Posso ter terminado uma parte do trabalho, enviado para desenvolvimento e, então, precisar esperar alguns dias até que um testador ou alguém de QA apareça. Depois vêm algumas alterações, feedback e assim por diante. O ciclo todo leva bastante tempo. No ciclo de vida do desenvolvimento de software com IA, queremos que o agent faça o máximo possível de testes antes que um engenheiro ou alguém de QA chegue perto. Desculpem se este diagrama diverge um pouco do que a Anthropic está descrevendo, mas este é o workflow que venho ensinando no meu curso na Switch Dimension, e ele é muito parecido. Então, basicamente, depois de concluirmos aqui a etapa de build, passamos

11:17 para testes, linting e revisão de ponta a ponta. O agent escreve testes para garantir que nada quebre durante o desenvolvimento e para confirmar que eles passam. Ele vai executar o linting e fazer o build do projeto para garantir que não haja erros. E, se você já tiver experiência e estiver usando algo como Playwright, Test-Driven Development ou Cursor Browser, pode pedir ao agent para testar o software e tirar capturas de tela. Isso é algo que os agents da Cursor Cloud fazem muito bem. Eles iniciam um servidor, testam o software para você e fornecem uma gravação de tela. Então, em teoria, quando os testes estiverem concluídos e forem bastante rigorosos, isso

11:49 vai economizar muito tempo na etapa de revisão humana. A Anthropic também sugere aplicar evals a qualquer mudança em uma skill ou atualização de modelo. Isso é realmente uma forma de otimização, mas a ideia é ter avaliações contínuas na integração contínua. Basicamente, você pode reunir cerca de 20 issues ou problemas que talvez tenha resolvido na base de código. Você define um conjunto de resultados esperados para eles e, sempre que tiver um novo modelo, uma nova escala ou uma mudança fundamental na maneira como trabalha, pode executar essas avaliações para ver se o ciclo de vida do desenvolvimento de software

12:20 regrediu ou não. Agora chegamos à etapa de deploy. Basicamente, fizemos nossa revisão humana. Vamos pedir ao agent que faça o merge ou crie um pull request para o repo principal com base nas alterações que fez. Em essência, temos um branch de desenvolvimento, um branch de produção e nosso agent, que fez algumas alterações no próprio branch ou em uma worktree. Então, ele criou algo chamado pull request, dizendo: “Ei, fiz algumas alterações. Quero que você dê uma olhada e, se estiver satisfeito, pode adicioná-las à base de código principal.” Como parte da integração contínua, a Anthropic sugere que, sempre que um pull request

12:50 for criado, você peça ao Claude para analisá-lo com base nas suas políticas e nos seus protocolos de segurança. Tudo isso é feito de forma assíncrona. O agent pode deixar comentários nesse PR dizendo que não o aceita ou que quer que algumas alterações sejam feitas e, no SDLC da Anthropic, há uma instância separada do Claude Code analisando esses comentários. E, claro, ela pode ter políticas diferentes com base no que está definido em agents.md e skills.md, nos hooks e no linting. Em termos de governança, você pode até ter um hook aqui que bloqueie

13:21 o deploy até que uma permissão específica seja concedida, uma pessoa específica aprove ou uma etapa de liberação seja cumprida. Aqui está um exemplo de um conjunto de permissões que poderia ser usado nessa etapa. Depois que o pull request estiver concluído, outro agent executa as verificações de segurança e a prévia da CI. Isso pode ser feito de forma determinística, com algum tipo de linting e verificação de condições, além de usar um agent como cursor, bug bot ou Claude security review para verificar se há erros. E isso finalmente nos leva à etapa de manutenção. Então, acho que é aqui que

13:52 o workflow fica bem mais ambicioso. Então, vamos analisar todo o nosso workflow aqui. Passamos por planejamento, design, construção, testes, deploy e agora chegamos à manutenção. Nesse ponto, ou nosso issue foi corrigido, ou nosso recurso foi desenvolvido e está no codebase. Em um ciclo tradicional de desenvolvimento de software, a manutenção pode ser uma fase reativa. Você saiu para almoçar, está de plantão, ou talvez sejam três da manhã e você receba um alerta avisando que seu servidor caiu. Há um ticket na fila de pendências que acaba completamente ignorado porque há coisa demais nessa fila. No AISDLC,

14:24 uma violação, um novo ticket, uma mensagem em um canal do Slack ou algum tipo de agendamento aciona o Claude sem que uma pessoa precise se envolver para realizar a manutenção. O Claude trabalha de forma assíncrona, diagnostica o problema e toma providências. E, nesse caso, ele gera o próprio arquivo intent.md com base nos logs que encontrou ou em qualquer ticket ou mensagem que tenha recebido. Na prática, isso funciona assim: você pode decidir que há certas métricas que quer manter. Então, talvez, durante os testes, uma página caia ou seu

14:54 limite de taxa da API aumente rapidamente. Isso pode acionar um agent para investigar e diagnosticar, criar um intent para diagnosticar um problema e oferecer um conjunto de sugestões, tudo antes mesmo de você chegar ao computador. Portanto, a premissa deste documento é que estamos deixando para trás a ideia de que os agents participam apenas da etapa de construção e passando a empregá-los em todo o ciclo de desenvolvimento de software. Como podemos começar a reduzir o tempo humano envolvido em cada uma dessas etapas, mas, principalmente, manter as pessoas no processo para as etapas importantes de revisão? Isso depende do seu workflow e da sua

15:26 necessidade e da sua equipe, mas você pode ter quantas pessoas quiser envolvidas em cada etapa, usar agents ou deixar que apenas os agents trabalhem sozinhos, se o nível de criticidade for baixo. Trabalhei em muitas empresas e com muitas empresas em seus ciclos de desenvolvimento de software com IA, e a questão é que realmente não existe uma solução que sirva para todos. Se você usa algo como superpowers ou B mad, ou desenvolveu sua própria versão disso, eu não jogaria tudo pela janela para adotar o que a Anthropic está fazendo aqui. Há muitas maneiras diferentes de abordar isso, desde loops até engenharia de grafos, loops totalmente automatizados, grandes sistemas orquestrados

15:58 até engenharia de civilização. Adoraria saber como você está conduzindo seu ciclo de desenvolvimento de software, mesmo que seja algo tão simples quanto o modo de planejamento ou vibe coding completo, no estilo YOLO. Se quiser aprender a tornar você mesmo ou sua equipe de desenvolvimento nativa em IA no que diz respeito ao ciclo de desenvolvimento de software, recomendo muito que confira a Switch Dimension. Você pode se inscrever na lista de espera para a próxima turma. Muito obrigado pelo seu tempo, pessoal. Até semana que vem.

Transcrição original

[00:00] So, this is Boris Journey, and he’s the creator of our friend Claude Code, and these guys have just released their AI native SDLC playbook. So, if this is a new concept to you, SDLC is the software development life cycle. Typically, in a human workflow, it looks something like this. You plan, you design, you build it, you test it, you deploy it, and put it into production, depending on what type of an app it is, and then you need to look at maintenance. And then you go right back to the start for the next feature, bug, or release. So, this new document from Anthropic is all about how

[00:30] the team there, including Boris, work in terms of their new AI native software development life cycle. So, let’s give it a rapid breakdown. So, the big idea here is code is no longer the bottleneck, it’s your process. So, before agents came along, this is pretty much how an SDLC looked. We had the planning stage, design, build, test, deploy, and maintain. The part that took the longest and was typically the most expensive was the build stage. But, that all changed with agents. This part here has been squashed down to this part here. Look at all this time here we’ve

[01:02] reclaimed. So, essentially, what Anthropic are saying we’ve done great to shrink this, we’re two times faster, but how do we improve all these other steps with agents as well? So, traditionally, in our planning stage, we would sit down, gather requirements, create PRDs, have workshops, talk to stakeholders, pulling it all together. In this new world, we start by getting the agents to interview us about the feature, the bug, or the product that we’re building in order to build up context. I use my own discovery skill called switch dimension discovery, you could use Realm me from Matt Pocock, or you could use something

[01:32] like requirements discovery from Cursor. So, what you want to do is make sure the agent asks you repeated questions until it has a complete understanding of the feature you’re building or the bug you’re trying to solve. You’re dumping as much of your experience, domain experience, and context into this conversation. So, the agent synthesizes pain points straight from the sources, and then captures them in this intent.md file, which is human-readable and machine-actionable. So, Anthropic is formalizing this idea around an intent.md file. So, in the

[02:02] traditional SDLC, the idea passed to a backlog of user entries, user stories, story points, ownership transfers, handoff. What we’re talking about in the AI-native world is the originator of the issue, the feature, the product, whatever, brainstorms with Claude and writes the result down as the intent.md. So, for each one of these steps as we move through, we’re going to be developing what’s called an artifact chain. First, we start with an intent.md file, then we’re going to have a spec, etc., as we go through the steps. That’s building the artifact chain. So, in your

[02:33] project using Cursor, Claude, Code, Codex, whatever you want, you’re just creating a folder called intent, and within that, that’s where you’re going to save your intent.md file. So, in my planning stage here, I might have a chat with my agent about adding dark mode as a feature, and I talk about what I want, how I want it to operate, and then we go and create an intent.md file from that. Then, I get the agent to save that as the intent.md file in the intent folder as proposed by Anthropic. And of course, with any of these artifacts, your team can do whatever they want in terms of a

[03:04] workflow. I think what’s important here is that you start to standardize it and not chop and change it too often. That way, the team, the agents, the skills, all work on the same workflow, and you can grow from there. Now, once that intent.md file is created, it doesn’t stop there. It’s It’s suggested that the originator of the intent goes back over what the agent has written to correct anything and make sure that both of them are happy. Now, the person that creates this intent.md file is called the originator, and that doesn’t have to be a specialist on the team. That can be anybody who wants to create the intent.

[03:35] It could be a customer who’s putting in a bug request. It could be a product manager who has an idea for a feature. It could be a developer who wants to capture a process improvement. So, you might have your own intent capture skill that produces something similar to this. What you might do over time as you’re collecting more forms of intent, you might prefix the name of the intent before your intent.md file. This is something I’ve been doing myself and teach on my course. I call it discovery, not intent, but again, it’s the same idea. So, the intent really can be

[04:05] captured by anyone. Could be a developer, uh a customer submitting a bug. They’re basically just dropping their thoughts into this intent.md file. But then it is the product owner that should review these in the form of a backlog. These could simply be ordered files in a markdown file. All these ideas could be captured in Notion or Linear and then organized by either a product owner or in some cases I’ll actually use my agents to triage the backlog of issues. You can see they can assign tags like front-end, smaller large tasks, whether it’s a feature, and even the priority level. So then we’re

[04:36] moving from the intent artifact to the spec artifact. Anthropic is suggesting that once the intent is committed or signed off in some way that you create a hook or a process that the spec is automatically generate. So, Anthropic gives us a sample prompt we might use to take our intent and turn it into a spec. They’re not giving us specific skills here, but we could certainly create a skill around this. So, essentially, read the attached intent.md and produce a requirements and design spec. Apply skills available to you to plan and

[05:07] conform to brand guidelines and then document the spec fully in spec.md. Depending on your workflow, your organization, you could just use the vanilla plan mode within Cursor or Claude Code or Codex or you could just go and create a skill that creates bespoke specs specific to how your team likes to work. There really isn’t a one-size-fits-all here. Now, when that spec is created, it could just be through a vanilla agent or you might also have a set of guidelines or policies or even skills that make sure

[05:38] that style guides are applied and however the spec is generated is based on the best practices of your organization. This might be in an agents.md file. It could be encoded into a set of skills. You want to make sure that those skills and policies are adhered to in your governance considerations for when the spec is being generated. And that applies to all of the artifacts in this chain. A quick diversion to talk about our sponsor, Neon. If you’re using agents heavily in your SDLC, I highly recommend you check them out. I’ve been using Neon for years

[06:08] for all my database needs. I’ve talked loads about how Neon is ideal for agent workflows with their awesome branching feature. What I love about Neon is they’re totally agent first. So, in all my agents, here’s an example of Cursor. I’ve got their MCP and the CLI and their set of skills plugged in. So, I never even have to touch the dashboard. The agent knows what to do with all their services. If you haven’t checked in on Neon lately, it’s now a full-fledged platform. It has managed better auth included, which links to your database.

[06:38] You’ve also got long-running functions with no timeouts, S3 compatible object storage for all your files in your projects. If you’re building projects and working with agents, I highly recommend Neon for an easy life. Channel subscribers can check them out via the link in the description down below. So, let’s get back to the SDLC. So, next up, we’re moving into build mode. So, it starts essentially by the engineer involved in the process pulling in the intent and the spec and feeding it into Cloud Code either in or in Cursor in plan mode or something like that.

[07:08] Basically, feeding the intent and the spec. So, what we get then is a plan.md file. So, what Anthropic are suggesting is you interrogate the plan by asking what changes could break. Essentially, you want to get to a point where if you were just to hand over this plan.md file to an engineer, they could go and implement the changes without reference to the intent or spec documents. Now, that’s actually an important point because we’re not going to have one agent carry out all of these different stages in the software development life cycle. We’re going to have a context

[07:40] window. We’re going to have a thread of conversations. Independent agents, sub-agents are going to handle this process. So, in that world, and here’s just an example from one of my own workflows, you’ve got multiple different agents working on the problem. You want to hand off your planning, your intent as documents to each one, so it can start from scratch without an understanding of the previous conversation that happened. So, when the engineer is happy, they go and proceed with the plan. You’ve probably seen 50 ways to write a plan, but essentially what Anthropic are saying is you break it down into the

[08:11] files that need to be changed, the order of work or type of to-do list, any kind of risks, constraints, and then proof. So, you want some kind of success criteria and checks inevitably to make sure that the work was done correctly. This could come in a deterministic form of linting and tests. A big part of the process in an enterprise company is going to be governance. So, what Anthropic suggests is that you’re saving versions of your plan, your intent, your spec.md, who touches them, and how they are evolved. Companies I’ve worked with find this part particularly hard, but

[08:42] it’s But, it’s really important if you want to track the leading and lag indicators for your projects and really prove out your Dora metrics or see how effective AI actually is becoming in your workflows. So, in terms of making your build mode fast, Anthropic suggests you use auto mode. It really does depend though on your own organization. What I suggest is that when you’ve got a locked-down environment that you’re working in, that you actually start to work in the repository with a set of dialed-in permissions, and that you’re ex- secting them as you go. Once you’ve built up a policy of what’s fair use,

[09:14] what tools the agents can access, what web sources, what packages they’re pulling, and you lock that down in terms of cursor or cloud permissions, you’re going to be able to have your agents move a lot faster without you involved. There are a lot of elements in making sure auto mode runs smoothly and you’ve got a tight blast radius for your agent. Not for the context of this video, but hopefully I’ll cover more on that again. The team also suggests work trees, so you can have multiple agents work on multiple things at the same time. If that’s completely over your head, I’ve got a full video on my channel covering Git and Git worktrees if you’re just

[09:45] getting used to them when it comes to working with agents. So, a big part of keeping this process autonomous, keeping things updated, and keeping things on rail are the usage of hooks. So, as an example, in the build phase, we might update the plan once the implementation is complete. We might block the agent from working on certain folders or prevent it from operating an NPM package that we haven’t signed off on yet. Linting has been around for a long time. It’s essentially a deterministic or a coded way of running through our code or our documents and checking that certain criteria are there

[10:16] or not there. Or that we’re matching a particular syntax. It’s going to run through the files, the tests will pass or not. It’s going to be a binary yes or no. Something you’ll get in a good agent harness is the ability to run subagents. So, once the plan is in place, this is actually baked into Cursor Cloud Code Codex. It divides the plan into various different tasks that can be done independently. And if some are in parallel, it can use worktrees. So, we end up having multiple agents and subagents working on the build step. So, after we’re finished building, we move into the test phase. In the traditional

[10:46] software development life cycle, this can be a step that really holds things up. I might have finished a piece of work, pushed it into development, and then I have to wait a couple of days for a tester to come along or a QA. Then there’s some changes, feedback, etc. The whole cycle takes quite a lot of time. In the AI software development life cycle, we want the agent to do as much testing as possible before a human engineer or QA gets near it. Now, sorry if this diagram diverges a little bit from Anthropic we’re talking about, but this is the workflow I’ve been teaching on my course at Switch Dimension, which is really similar. So, essentially, once we finish the build step here, we move

[11:17] into testing, linting, end-to-end review. The agent write tests to make sure nothing is breaking when developed and make sure those tests pass. It’s going to lint and build the project to make sure there’s no errors. And if you’re advanced enough and you’re using something like Playwright, Test-Driven Development, Cursor Browser, you can actually get the agent to test the software and take screenshots. This is actually something that Cursor Cloud agents do really well. They’ll actually spin up a server and test the software for you and give you a screen recording. So, theoretically, once the testing is complete and it’s fairly rigorous, it’s

[11:49] going to save you a whole lot of time when it comes to the human review stage. Anthropic also suggests that you apply evals to any skill change or any model upgrade. Now, this really is optimizing, but the idea is that you have continuous evaluations in your continuous integration. So, basically, you might collect collect 20 or so issues or things that you might have solved in the code base. You have a set of expected outcomes for those, and whenever you have a new model, a new scale, or a new fundamental change to how you do your work, you can run this to see if your software development life cycle

[12:20] regresses or not. So, now we’re getting to the deploy stage. Essentially, we’ve done our human review. We’re going to get the agent to merge or we’re going to get it to create a pull request to the main repository based on whatever changes it made. So, essentially, we have a development branch, we have a production branch, and our agent is after making some changes on its own branch or in a work tree. So, it’s made something called a pull request where it’s saying, “Hey, I made some changes. I want you to take a look at them, and if you’re happy, you can go and add them into the main code base.” So, Anthropic is suggesting as part of your continuous integration or whenever a pull request

[12:50] is made that you get Claude to jump in and review it against your policies and your security protocols. And all this is done asynchronously. Now, the agent might have its own comments on this PR saying it doesn’t accept it or it wants some changes made in and and in Anthropic’s SDLC, you’ve got a separate instance of Claude code reviewing those comments. And of course, it might have different policies based on what agents.md, what skills.md, what hooks, what linting it has in place. In terms of governance, you might even have a hook in place here that would block

[13:21] deployment unless a specific permission has been granted, unless a specific person approves, or a release gate is met. Here’s an example of a set of permissions that might be used as part of that stage. So, once the pull request is complete, you have another agent that runs the security, the CI preview. This could be deterministic with some form of linting and gate checking, as well as just having an agent like cursor, bug bot, or Claude security review come in and check for any errors. And that finally brings us to the maintenance step. So, I think this is where the

[13:52] workflow gets really aspirational. So, we look at our whole workflow here. We’ve moved to planning, design, building, testing, deploying, and now we’ve reached maintenance. So, at this point, either our issue is fixed or our feature is built and it’s sitting within the codebase. So, in a traditional software development life cycle, maintenance can be a reactive phase. You’re out for lunch, you’re on call, or maybe it’s 3:00 a.m. in the morning and you get an alert to say that your server has fallen over. A ticket is sitting in a backlog and it gets completely ignored because there’s just too much in the backlog. In the AISDLC,

[14:24] a breach, a new ticket, a channel message in Slack, or some kind of a schedule invokes Claude without any kind of a person involved to perform maintenance. Claude asynchronously goes ahead and diagnoses and acts on that in And in this case, it’s generating its own intent.md file based on the logs that it’s discovered or whatever ticket or message it’s been sent. Now, how this works in practicality is you might decide that you have certain metrics that you want to uphold to. So, maybe in your testing, a page falls over or your

[14:54] API rate limit rapidly increases. That might trigger an agent to go and diagnose, create an intent, to diagnose a problem, and offer a set of suggestions, but all before you’ve even got to your computer. So, the whole premise of this document is we’re moving past agents just being involved in the build step to being employed in the whole software development life cycle. How can we start to reduce the amount of human time involved in each one of these steps, but importantly keeping humans in the loop for the important review steps. It depends on your workflow and your

[15:26] need and your team, but you can have as many humans involved in each step or agents or purely just agents on their own if there’s low criticality. I’ve worked in a lot of companies and I’ve worked with a lot of companies with their AI SDLC and the thing is there really is no one size fits all. If you’re using something like superpowers or B mad or you’ve developed your own version of this, I wouldn’t throw it completely out the window to adopt what Anthropic is doing here. There are so many different ways to approach this from loops to graph engineering, fully automated loops, large orchestrated

[15:58] systems all the way to civilization engineering. I’d love to hear how you’re working your software development life cycle even if it’s a simple as plan mode or complete vibe code yolo. If you want to learn how to make yourself or your development team AI native in terms of software development life cycle, highly recommend you check out switch dimension. You can sign up the waitlist there for the next cohort. Thanks so much for your time guys. I’ll see you next week.