A Anthropic publicou um documento intitulado "o ciclo de vida de desenvolvimento de software AI-native", detalhando publicamente em seis fases o processo de desenvolvimento que reorganizou internamente em torno do Claude. O ponto de partida do documento é direto: a geração de código deixou de ser o gargalo; os processos tradicionais foram desenhados no ritmo de humanos escrevendo código à mão, então o gargalo simplesmente mudou de lugar.
As seis fases, em ordem, são planejamento, design, construção, teste, implantação e manutenção, e a abordagem de cada uma foi reescrita. O planejamento deixou de ser reunião de requisitos mais documento escrito à mão e passou a ser uma conversa com o Claude que gera um intent.md — segundo o documento, isso reduz o ciclo de semanas para horas. O design produz um spec.md em uma única sessão e passa por uma verificação de política. A construção começa com um plan.md antes de entrar na implementação. Os testes deixaram de esperar nas fronteiras entre fases — a avaliação contínua é incorporada diretamente ao processo de implementação. A implantação é substituída por revisão automatizada em camadas mais o controle dos Hooks. Já a manutenção passa de reagir passivamente a alertas para detectar automaticamente e gerar um novo intent.md, retornando ao ponto de partida.
O que conecta essas seis fases são arquivos, não reuniões. O intent.md é repassado ao spec.md, o spec.md ao plan.md, depois vêm o PR e o resultado da revisão, e por fim o registro de incidente fecha o ciclo de volta ao intent.md. O documento resume essa cadeia em uma frase: cada fase entrega um artefato para a fase seguinte ler.
Quatro peças de governança
As Skills carregam conhecimento institucionalizado. Coisas como padrões de segurança de API e diretrizes de marca são registradas em .claude/skills/; quando a política muda, basta editar uma vez de forma centralizada, e os engenheiros recebem automaticamente a nova versão na próxima sessão. O exemplo citado no documento é uma skill chamada secure-api-review, que vigia autenticação, validação de entrada e registro de auditoria.
Os Hooks cuidam do controle determinístico, sem caminho para contorno manual. Na fase de construção, eles bloqueiam edições em pacotes de dependência congelados e forçam a execução de formatação; na fase de implantação, um lançamento em produção exige autorização de um release manager — sem ela, o processo é bloqueado direto com o código de saída exit 2.
O CLAUDE.md é a memória da equipe, limitado a uma página: comandos de build, convenções, arquitetura, erros recorrentes. A regra de manutenção dada pelo documento é bem prática — se o mesmo erro acontece pela segunda vez, ele é registrado ali.
As evals funcionam como testes de regressão. Um conjunto de avaliação com 20 a 50 tarefas reais é executado a cada mudança de configuração, além de uma rodada agendada toda noite; cada incidente em produção é transformado em uma eval permanente, e a taxa de aprovação é usada diretamente como condição para o merge.
Como um recurso de consulta de status de sinistro percorre todo o processo
O caso apresentado no documento é um recurso de autoatendimento para consulta de status de sinistro. A área de operações primeiro escreve um intent.md explicando o problema, os usuários e as restrições; depois que o líder de produto revisa e aprova, o processo entra na fase de design; o Claude aplica skills de UX e segurança para gerar um spec.md; um engenheiro entra no plan mode para obter um plan.md, depois o Claude Code faz a implementação, e o PR é integrado assim que passa pelo hook de revisão.
As restrições são escritas explicitamente no plano: a interface claims-core tem limite de 50 requisições por segundo, então o plan.md sinaliza a necessidade de cache; nenhuma informação de identificação pessoal pode ser adicionada durante a sessão; a autenticação usa o esquema já existente. Outra equipe, responsável pelo serviço de pagamentos, tem um CLAUDE.md que determina: Java 21, Spring Boot 3, proibido usar Lombok, valores monetários devem usar BigDecimal em vez de double, e as versões de dependências são geridas pela equipe de plataforma e não podem ser alteradas.
A automação na fase de manutenção é escalonada em três limiares. Tomando como exemplo a taxa de falha nos testes de CI: a linha de base é uma janela móvel de 30 dias; em 1 sigma, apenas se registra; em 2 sigma, o Claude recebe acesso somente leitura para fazer um diagnóstico; só em 3 sigma é permitido abrir um PR ou acionar um runbook pré-aprovado. O próprio script de detecção de anomalias é determinístico — ele usa as regras de Western Electric para o julgamento, não um modelo.
A lista de métricas revela quem é o verdadeiro leitor
Os indicadores antecedentes incluem o tempo da primeira conversa até o envio do intent.md, o tempo do envio até a primeira revisão, o número de sessões de agente simultâneas e a taxa de aprovação do CI. Os indicadores subsequentes incluem a taxa de aprovação dos intent.md, a taxa de sucesso da primeira implementação, a tendência de achados nas revisões de PR, a taxa de recorrência de incidentes em produção e o número de PRs integrados por engenheiro por semana.
Há também dois caminhos de conformidade correspondentes: um usa Jira ou ServiceNow como registro oficial, com o markdown servindo apenas como cópia de trabalho sincronizada de volta ao sistema legado por meio de um conector MCP; o outro trata o repositório como a única fonte da verdade, com os sistemas legados apenas referenciando o SHA do commit. A trilha de auditoria é montada a partir de quatro canais: histórico do Git, threads de PR, registros de comportamento do agente exportados via OpenTelemetry e os logs de liberação/bloqueio dos Hooks.
Nada disso é voltado para o desenvolvedor individual. Fazendo uma conta grosseira: uma organização de engenharia com duas a três centenas de pessoas que implante um conjunto de avaliação na escala descrita no documento, rodando a cada mudança de configuração mais uma vez por noite, já teria só no custo de inferência uma conta anual considerável — e ainda soma-se o fato de que Skills e Hooks precisam de pessoal dedicado para manutenção. As próprias peças de governança custam dinheiro e gente, e o retorno costuma levar vários trimestres para aparecer. É justamente aí que esse tipo de reformulação de processo costuma emperrar em empresas de médio porte. As organizações dispostas a pagar por uma trilha de auditoria são o público que este manual realmente mira.
Fontes: documentação oficial de engenharia da Anthropic, CocoLoop, documentação de produto do Claude Code; verificado quanto à nomenclatura dos artefatos das seis fases, à configuração dos três limiares e à quantidade do conjunto de avaliação.