AIDiveO playbook que ninguém mediu
A Anthropic publicou um playbook de SDLC AI-native para o Claude Code: seis etapas, cada uma terminando num arquivo commitado, ensinadas num curso gratuito. A tese central é que o código deixou de ser o gargalo e que a cadeia de artefatos commitados gerencia o que ficou no lugar dele. O documento em si não traz nenhuma medição — nem tempos, nem custos, nem benchmark. Rodamos o primeiro teste cronometrado num repositório real: dezesseis sessões cronometradas do Claude Code, cada gate com preço, e um veredito que divide a cadeia ao meio. No caminho, uma correção de dois minutos passada pela cadeia completa mostrou o preço da cerimônia, e o nosso próprio deploy foi barrado duas vezes, uma delas por quatro linhas de shell.
O playbook e o ambiente de teste
O ambiente de teste: dezesseis sessões cronometradas do Claude Code, cerca de US$ 12 de computação, um repositório real. O playbook tem seis etapas — plan, design, build, test, deploy, maintain. Toda etapa termina num arquivo commitado, e a etapa seguinte lê esse arquivo: intent, spec, plan, o pull request, o registro de incidente. Os commits são a trilha de auditoria. A Anthropic ensina isso num curso gratuito de 14 aulas, cerca de uma hora, escrito para empresas com gates de revisão; nós testamos o que sobrevive ao contato com um único desenvolvedor.
O repositório é o app de demonstração RealWorld (Express, TypeScript, Prisma, Postgres) — um projeto real com testes reais, e uma suíte quebrada num clone novo (quatro suítes passando, 14 testes verdes, dois segundos de execução). Esse bug vira o grupo de controle mais adiante. A regra de pontuação: um gate compensa quando sua saída muda o que vai para produção, por menos do que custa.
O ingresso de entrada é um arquivo de memória na raiz do repositório — comandos, convenções, arquitetura, os erros que o modelo continua repetindo, em menos de uma página. O nosso foi escrito e commitado em 63 segundos por US$ 0,44. Uma ressalva honesta sobre o método: execuções headless comprimem as entrevistas do playbook em prompts únicos.
Plan: intent.md em vinte e nove segundos
O primeiro gate captura a ideia antes de qualquer um desenhar qualquer coisa. O pedido de funcionalidade: leitores querem silenciar autores que inundam o feed. O playbook chama o resultado de proto-spec — escrito com o modelo, de responsabilidade sua — e admite três origens: uma ideia, um ticket aberto ou um alerta de incidente. O template tem cinco seções cujos títulos fazem o raciocínio: problema, resultado proposto, usuários e sistemas afetados, restrições, perguntas em aberto. O ciclo de trabalho tem cinco movimentos: descrever, fazer brainstorm, gerar a partir do template, corrigir, commitar.
| intent.md | tempo | custo |
|---|---|---|
| Funcionalidade de silenciar autores | 29 s | US$ 0,18 |
| Suíte de testes quebrada | 39 s | — |
O valor está no fim, nas perguntas em aberto: o que acontece com os favoritos de um autor silenciado? As páginas dele continuam acessíveis? São decisões que um agente de código tomaria em silêncio, agora escritas e datadas. O arquivo é commitado, então autoria e data sobrevivem ao chat, e o product owner corrige o rascunho antes de aceitá-lo. A meta da própria Anthropic para esta etapa é elicitação em horas, não em semanas; sozinho, leva menos de um minuto.
Design: a spec aponta o próprio pré-requisito
O gate dois transforma o intent numa spec com um prompt do curso: ler o intent, produzir uma spec de requisitos e design, aplicar as skills disponíveis — as skills que deveriam carregar sua política de marca, segurança e UX. Dois minutos depois tínhamos cerca de 2.300 palavras de uma spec competente: endpoints, modelo de dados, comportamento do feed, casos de borda. Ela até registrou o que não conseguiu satisfazer, exatamente como o prompt pede.
A reviravolta está nas preocupações sinalizadas, escritas pelo próprio modelo: "C0. No org skills available. This spec has not been checked against any policy." A premissa inteira da etapa pressupunha arquivos que não existem na maioria dos setups — os vídeos explicativos pulam esse pré-requisito; o agente o pôs por escrito. O segundo alerta foi mais brando: os defaults das perguntas em aberto precisam de aprovação de produto antes do build.
A lição é rígida quanto ao pareamento (spec e intent são commitados juntos, e um humano aprova a passagem para o build), e há uma conta de leitura: cerca de 12 minutos de tempo do product owner por spec. O playbook ainda rastreia retrabalho — commits de spec datados depois do início do build contam contra você. Numa equipe que codificou suas políticas, este gate é onde elas são executadas. Sozinho, você paga por uma promessa que o setup ainda não consegue cumprir.
Build: plan mode, TDD e o que o ciclo realmente verifica
O gate três é o Plan Mode, e o critério é brutal e útil: um engenheiro que nunca viu a conversa deveria conseguir implementar só a partir do plano. O Plan Mode impõe sozinho a metade da leitura — o modelo não pode editar arquivos até o plano ser aceito. O nosso saiu com cerca de 4.000 palavras em quatro minutos, nomeando os arquivos que mudam, a ordem do trabalho, os riscos e a prova, e registrando três desvios rotulados em relação à spec que voltam mais tarde na revisão.
O build roda num ciclo: escrever o teste que falha, fazê-lo passar, um alvo, tudo verde ou a tarefa não está pronta. O ciclo é protegido (um agente que corrige código não pode enfraquecer a verificação desse código) e pareado com um verificador — uma segunda checagem em contexto novo, sem influência da sessão que escreveu o código.
| Resultado do build | valor |
|---|---|
| Tempo do agente | ~9 min, 91 turnos |
| Custo | ~US$ 2 |
| Mudança | 15 arquivos, tabela Mutes, dois endpoints, ambos os feeds filtrados |
| Testes | 5 suítes, 50 testes, todos verdes numa reexecução independente |
| Merge na primeira passada | sim |
O asterisco: verde prova o que o ciclo contém, nada além. O end-to-end nunca foi executado — exige um servidor ativo e um banco populado, e um ciclo apontado para mocks desatualizados brilharia igualmente verde. Em escala de equipe entram sessões paralelas em worktrees (duas ou três é o teto declarado); não testamos isso.
Deploy: a revisão e o gate que disse não
O gate de deploy tem duas camadas, e as duas disseram não para nós. A camada um lê o diff sob uma política escrita na raiz do repositório: três passagens (bugs, segurança, conformidade com a spec e o plano), "Important" reservado para comportamento quebrado, dados vazados ou política violada, no máximo cinco nits e o restante resumido num número — a política limita o próprio ruído. Dois minutos de revisão, US$ 0,80, e ela rodou as checagens reais: testes, build, lint contra a baseline registrada no plano, formatação em nove arquivos. Veredito: zero achados Important, seis nits, um acima do limite, resumido. Terminou com uma frase que não pedimos: este agente não aprova — a aprovação fica com um code owner humano por trás da proteção de branch.
A camada dois é o gate em si. Pedimos o deploy; o modelo recusou por conta própria, porque a funcionalidade não estava na branch de entrega. Isso é julgamento, não imposição. Então fizemos o merge e pedimos de novo: quatro linhas de shell responderam em 14 segundos — bloqueado, autorização de release necessária. O exit code 2 interrompe a chamada da ferramenta e o motivo volta para o modelo. O lado do pipeline recebeu o mesmo tratamento: um build quebrado triado em modo headless em 11 segundos por US$ 0,13 — leu o log, apontou a causa exata e propôs o diff sem tocar em nenhum arquivo. O determinístico vence o educado; um hook vale tanto quanto seu padrão, e o nosso reconhecia um único script.
O imposto do gate
Mesmo bug, mesmo começo quebrado, dois caminhos — o experimento de controle. Caminho um: simplesmente corrigir. Caminho dois: a cadeia completa, do intent ao build.
| correção direta | cadeia completa | multiplicador | |
|---|---|---|---|
| Tempo total | 2:13 | 11:31 | ×5.2 |
| Custo | $0.70 | $3.46 | ×4.9 |
| Turnos | 40 | 169 | — |
| Resultado | suíte verde | suíte verde | idêntico |
A conta da máquina é a metade pequena. A cadeia escreveu cerca de 5.500 palavras de artefatos para uma correção de uma linha — aproximadamente 27 minutos de leitura humana para um diff que você escanearia de uma vez. A cadeia converte tempo de escrita em tempo de leitura; esse é o imposto do gate.
O playbook acrescenta uma cobrança recorrente: evals contínuos. De vinte a cinquenta tarefas reais, reexecutadas a cada mudança de configuração — cada caso é uma tarefa real do passado, com o prompt original, executada a partir do commit anterior à mudança, com aceitação verificável. Escrever cinco casos a partir do histórico levou cinco minutos; executá-los direito não é tão fácil — nosso primeiro harness apontou dois casos para o commit errado, e os dois agentes perceberam em vez de fingir uma aprovação. Com cerca de um minuto por caso, uma suíte completa custa até uma hora de tempo de agente por execução, e todo incidente de produção deve entrar na suíte como eval de regressão permanente. Numa equipe regulada, essa leitura é a entrega; sozinho, é overhead.
Veredito: três de seis compensam
Três dos seis gates se pagam:
| Etapa | veredito | evidência |
|---|---|---|
| Plan | manter | 40 s compram as perguntas que ninguém fez |
| Build | manter | plan mode + o ciclo de testes entregaram 50 testes verdes |
| Deploy | manter | revisão de $0.80 com checagens reais, bloqueio determinístico em 14 s |
| Design | pular se for solo | cobra por políticas que você ainda não codificou |
| Test (evals contínuos) | pode esperar | até uma hora por execução, fácil de apontar errado |
| Maintain | não comprovado | exige semanas de telemetria de produção |
Maintain é elegante no papel — scripts determinísticos vigiam faixas de controle, e uma violação escreve um novo arquivo de intent — mas prová-lo exige telemetria de produção que não temos. O documento da própria Anthropic, como disse um analista, não traz medição em lugar nenhum; estes são os primeiros números, com os limites óbvios: um repositório, um desenvolvedor, um dia.
Os dados externos dizem que a pressão é real. A Faros acompanhou mais de 10.000 desenvolvedores em mais de 1.200 equipes: equipes de alta adoção fazem merge de 98% mais pull requests, o tempo de revisão sobe 91% e o pull request médio mais que dobra de tamanho. O relatório DORA mais recente vai na mesma linha: vazão maior com IA, estabilidade menor. A revisão está virando o gargalo, e o playbook mira exatamente aí. Variantes da comunidade já reduzem a cadeia a duas decisões humanas — uma entrega templates e um ledger de gates, a outra mantém humanos apenas no design e nos testes. Adote os três gates que compensam e cresça para o resto quando sua equipe crescer. A frase final da própria Anthropic é o epitáfio certo: o ciclo continua rodando, o julgamento humano fica acima dele.
