O playbook SDLC nativo de IA, medido: tempos por etapa, imposto de gate, vereditos

Resumo

• Cada uma das seis etapas do playbook termina em um artefato commitado (intent.md, spec.md, plan.md, PR, registro de incidente). O post de lançamento e o curso de 14 aulas descrevem o formato, nenhum publica uma medição.
• Executada de ponta a ponta em um repo real de Express + Prisma, a cadeia completa corrigiu um bug em 11 min 31 s por $3.46, enquanto um prompt direto fez o mesmo em 2 min 13 s por $0.70: ×5.2 em tempo, ×4.9 em custo, ambos no verde.
• O imposto real é a leitura: 5,488 palavras de artefatos para um conserto de classe de uma linha, cerca de 27 min a 200 ppm. A cadeia converte tempo de escrita em tempo de leitura.
• Três das seis etapas compensaram neste contexto: Plan (intent.md), Build (plan mode + CLAUDE.md + TDD), Deploy (REVIEW.md + um hook). Design e as evals contínuas não compensaram para um dev solo; Maintain não foi executada.
• A etapa de spec sinalizou o próprio pré-requisito: não existiam skills de organização, então ela nunca foi checada contra políticas de marca, segurança ou UX. O playbook assume que esses skills já estão escritos.
• O gate determinístico funciona: um hook PreToolUse bloqueou um deploy em 14 s com exit 2. O modelo já tinha recusado uma vez por julgamento próprio antes de o hook disparar.

O que as medições dizem

O playbook enquadra a mudança como "o código não é mais o gargalo" e pede que cada etapa termine em um artefato commitado, de intent.md passando por spec.md e plan.md até a PR e o registro de incidente, com bandas de controle em Maintain s1. O curso traz os dados citáveis: 20 a 50 tarefas reais como suíte de evals, um teto de 5 nits no REVIEW.md, no máximo 2 a 3 sessões paralelas, e a regra de que um erro cometido duas vezes vai para o CLAUDE.md s2. A leitura neutra mais afiada tabula quem redige e quem aceita cada artefato e chama o documento de "vendor-claim throughout" com "no measurement anywhere" s4.

A tarefa de correção foi um bug real do upstream: um clone novo rodava npx nx test api e 1 suíte falhava de cara (auth.service.test.ts, "TypeError: Cannot read properties of undefined (reading 'prototype')"), 4 passavam, 14 testes no verde, 2.2 s. O caminho direto chegou a testes totalmente verdes em 2 min 13 s, $0.70, 40 turnos. O caminho com cadeia, intent depois spec depois plan depois build, também chegou ao verde em 11 min 31 s, $3.46, 169 turnos. Isso dá ×5.2 em tempo e ×4.9 em custo só do lado da máquina s2.

É no lado humano que a cadeia dói. Ela produziu 5,488 palavras de artefatos para ler (intent 558 + spec 2,167 + plan 2,763), cerca de 27 min a 200 ppm, para um conserto cuja carga de revisão direta é um diff pequeno s4. A tarefa de feature (silenciar autores) pela cadeia inteira levou 15 min 13 s, $4.11, 158 turnos e entregou um modelo Prisma Mute com migration, endpoints de mute e unmute, filtragem do feed, 1,422 inserções em 15 arquivos, 50 testes no verde com 3 arquivos de teste novos ou ampliados e um spec e2e. Seus artefatos pesaram 6,852 palavras (intent 450 + spec 2,337 + plan 4,065), cerca de 34 min de leitura s2.

A leitura cética da etapa Design se confirmou. A crítica do LinkedIn diz que o playbook esconde seus pré-requisitos: os skills de organização para marca, segurança e UX já precisam existir, e alguém precisa saber conduzir o brainstorm s7. O agente confirmou sem ser provocado. A preocupação C0 sinalizada no spec.md diz, literalmente: "No org skills available. … This spec has therefore not been checked against brand, security or UX policy." Uma spec de mais de 2,000 palavras que repete o código e não consegue checar política é a etapa a pular quando se trabalha sozinho s7.

A crítica sobre infraestrutura também se confirmou. O argumento é que, quando os testes batem em fakes obsoletos, "the agent sees the tests pass and reports the work finished", porque a cadeia de artefatos registra o que foi decidido, não o que realmente roda s8. Na execução, o loop só verificou testes unitários e o build; a própria revisão listou nx e2e como "Not run: needs a running server and a seeded DB" e prisma migrate status como "Not run: needs a DB". O loop verde nunca tocou um sistema vivo s8.

A etapa Deploy foi o ganho barato. O REVIEW.md rodou em 117 s por $0.80: nx test (5/5 suítes, 50 passaram), nx build (ok), um delta de lint contra a base do plano (34 vs 33, o +1 permitido explicitamente pelo item A3 do plano) e uma checagem do prettier (9 arquivos falhando, registrado como nit N1). Veredito: 0 Important, 6 nits, 5 listados e 1 resumido porque o teto se aplicou. A revisão se recusou a aprovar o próprio trabalho com "this agent does not approve", a separação de funções como o curso a escreve s2. O gate por hook se comportou como os docs descrevem: pedido para fazer deploy antes do merge, o agente recusou por julgamento próprio sem rodar o script, então o hook nunca disparou. Depois do merge, a tentativa de deploy foi bloqueada pelo hook PreToolUse (exit 2) em 14 s com a mensagem do gate s19.

As evals foram baratas de escrever e fáceis de errar. Cinco casos saíram do histórico do git em 283 s por $1.44. As duas execuções rodaram contra a base errada, porque o runner criou a branch depois do merge do conserto, e os dois agentes perceberam ("the bug was already fixed here") em vez de fingir um passe. Uma execução de eval custa cerca de 60 a 70 s, então o dimensionamento do próprio playbook, de 20 a 50 casos, equivale a mais ou menos 20 a 55 min de tempo de agente por execução de CI s2. A configuração do CLAUDE.md levou 63 s e $0.44 por uma página commitada, a jogada mais barata de todas; uma triagem de log de CI somente leitura apontou a causa correta em 11 s por $0.13 s2.

A thread da comunidade traz telemetria mais ampla: em 10,000 desenvolvedores, times com muito uso de IA mergeiam 98% mais PRs enquanto o tempo de revisão sobe 91% e o tamanho das PRs 154% s6.

Medições

Protocolo: a cadeia rodou em headless (claude -p, modelo claude-opus-5-5, permissões restritas a acceptEdits mais uma allowlist, --setting-sources project,local) em um clone descartável de gothinkster/node-express-realworld-example-app (Express + TypeScript + Prisma + Postgres 16 em Docker, workspace Nx). Cada etapa foi cronometrada e registrada em exp/metrics.jsonl (17 linhas). Total: $11.90 + $0.14 por uma repetição do hook, 539 + 3 turnos, cerca de 41 min de tempo de agente.

Ressalvas: um repo, um desenvolvedor, um dia. As jogadas em escala de time não foram executadas, o modo headless comprime as etapas de entrevista em prompts únicos, e as execuções de evals contam só o custo por execução.

Faça isto na segunda

• Escreva uma página de CLAUDE.md para o seu repo principal: comandos de build, teste e lint, e os dois erros que o agente cometeu semana passada. Commite. Reserve 63 s de tempo de agente.
• Antes da sua próxima tarefa não trivial, peça primeiro um intent.md: objetivo, não objetivos, decisões abertas. Responda as perguntas abertas e só então deixe o agente planejar. Pule o spec.md a menos que você tenha skills de política de organização para checá-lo.
• Rode a etapa de build em plan mode com um loop TDD e exija que o plano registre os desvios (D1, D2, ...) para que a revisão tenha em que se apoiar.
• Adicione uma passada de REVIEW.md rodada por uma sessão nova, com teto de nits e uma linha explícita "this agent does not approve". Faça-a rodar testes, build, um delta de lint e uma checagem do formatador.
• Coloque um gate determinístico no lugar: um hook PreToolUse que sai com exit 2 em deploy quando a branch não é main.
• Antes de confiar em um loop verde, liste no fim da revisão o que ele não rodou (e2e, migrations, qualquer coisa que precise de um banco vivo).
• Meça o seu próprio imposto de gate: cronometre o caminho direto e o caminho com cadeia no mesmo bug pequeno e conte as palavras que você teve que ler.

Para ir além

• A variante de dois gates: um gate de revisão adversarial (sdlc-gate) e só dois pontos de decisão humana em vez de um por etapa, o formato pragmático para um time pequeno s12.
• A cadeia completa instalável: templates de intent, spec, plan e REVIEW, um validador de gates, um runner de evals e detecção de bandas de controle, se você prefere não montar o andaime à mão s5.
• Planejamento com entrevista primeiro: uma pergunta por vez vence o lote, e "AI agents don't ask clarifying questions. They assume." Um relato de configuração sem tempos medidos s11.
• Por que um pipeline fixo único acaba sendo contornado: "a docs fix and a payments migration shouldn't travel the same path", e o processo real fica invisível. Agrupa o playbook com Kiro e GitHub Spec Kit s9.
• As lacunas que um fornecedor de plataforma vai te vender: entrada de sinal para intent, roteamento por raio de impacto, um painel de métricas. s13.
• Uma consultoria que aplicou o mesmo formato (CRAFT) em times de clientes desde janeiro e admite "we don't yet have a formal answer for what a control band looks like" s10.
• Um exemplo trabalhado de intent.md (uma caixa Select All) que mostra a função do arquivo: trazer à tona decisões abertas em vez de deixar o agente escolher em silêncio s14.

Fontes

• The AI-Native SDLC Playbook (launch post), claude.com. Por que ler: o formato de seis etapas e a regra do artefato commitado em cinco minutos.
• The AI-native SDLC playbook (course, 14 lessons), Claude Academy. Por que ler: o único lugar onde os números vivem (20 a 50 tarefas de eval, teto de 5 nits, 2 a 3 sessões), grátis e sem login.
• The Committed-Artifact Chain, howardism.dev. Por que ler: quem redige e quem aceita cada artefato, e a constatação direta de que nada no playbook é medido.
• bashebr/ai-native-sdlc, GitHub. Por que ler: templates, validador de gates e runner de evals que você pode instalar em vez de escrever.
• Anthropic published an AI-native SDLC playbook, r/ClaudeAI. Por que ler: a thread que traz a telemetria da Faros (98% mais PRs, +91% de tempo de revisão) para o debate.
• The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. Por que ler: o argumento dos pré-requisitos ocultos que a etapa de spec confirmou por conta própria.
• The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. Por que ler: o problema dos fakes obsoletos, com voz de fornecedor, mas o argumento se sustenta sozinho.
• The AI-native SDLC won't be one process, worldprogramming.org. Por que ler: o argumento da cerimônia contra um único caminho para toda mudança.
• Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. Por que ler: um time independente convergindo para o mesmo formato e admitindo o buraco em Maintain.
• AI-Native SDLC: First Try, kyle.pericak.com. Por que ler: a única primeira execução prática com entrevista primeiro, escrita antes de o playbook existir.
• TsCarpe/claude-sdlc-skills, GitHub. Por que ler: a variante de dois gates com uma etapa de revisão adversarial.
• Implementing the Anthropic AI-Native SDLC Playbook, Port blog. Por que ler: a lista do que o playbook deixa de fora, para ler como um mapa de lacunas.
• What Is intent.md in Claude Code?, dev.to. Por que ler: um intent.md concreto cuja estrutura você pode copiar.
• Hooks guide, Claude Code docs. Por que ler: como um hook PreToolUse com exit 2 vira o gate determinístico em que o playbook se apoia.

FAQ

A cadeia completa chega a valer a pena para um conserto de uma linha?

Não nesta execução: ×5.2 em tempo e ×4.9 em custo pelo mesmo resultado verde, mais 5,488 palavras para ler. Use só o intent.md para tarefas pequenas.

Por que pular o spec.md ao trabalhar sozinho?

A spec se sinalizou sozinha: sem skills de organização para marca, segurança ou UX ela não conseguiu checar política, e gastou mais de 2,000 palavras repetindo o código.

O hook substitui o julgamento do modelo?

Não, ele o reforça. O agente recusou por conta própria o deploy antes do merge; o hook bloqueou a tentativa pós-merge em 14 s com exit 2.