Le playbook SDLC natif IA, mesuré : durées par étape, taxe de garde-fou, verdicts

En bref

• Les six étapes du playbook finissent chacune par un artefact committé (intent.md, spec.md, plan.md, PR, fiche d'incident). Le post de lancement et le cours en 14 leçons décrivent la forme, aucun ne publie de mesure.
• Exécutée de bout en bout sur un vrai repo Express + Prisma, la chaîne complète a corrigé un bug en 11 min 31 s pour $3.46, là où un prompt direct l'a fait en 2 min 13 s pour $0.70 : ×5.2 en temps, ×4.9 en coût, les deux au vert.
• La vraie taxe, c'est la lecture : 5,488 mots d'artefacts pour un correctif de classe d'une ligne, environ 27 min à 200 mots/min. La chaîne transforme du temps d'écriture en temps de lecture.
• Trois étapes sur six ont rapporté dans ce contexte : Plan (intent.md), Build (plan mode + CLAUDE.md + TDD), Deploy (REVIEW.md + un hook). Design et evals continues non pour un dev solo ; Maintain n'a pas été exécutée.
• L'étape spec a signalé elle-même son prérequis : aucun skill d'organisation n'existait, donc elle n'a jamais été vérifiée contre une politique de marque, de sécurité ou d'UX. Le playbook suppose ces skills déjà écrits.
• Le garde-fou déterministe fonctionne : un hook PreToolUse a bloqué un déploiement en 14 s avec exit 2. Le modèle avait déjà refusé une première fois de son propre chef avant que le hook ne se déclenche.

Ce que disent les mesures

Le playbook présente le virage comme « le code n'est plus le goulot d'étranglement » et demande que chaque étape se termine par un artefact committé, de intent.md à spec.md puis plan.md, jusqu'à la PR et la fiche d'incident, avec des bandes de contrôle en Maintain s1. Le cours apporte les chiffres citables : 20 à 50 tâches réelles comme suite d'evals, un plafond de 5 nits dans REVIEW.md, 2 à 3 sessions parallèles au maximum, et la règle qu'une erreur commise deux fois va dans CLAUDE.md s2. La lecture neutre la plus incisive tabule qui rédige et qui accepte chaque artefact, et qualifie le document de « vendor-claim throughout » avec « no measurement anywhere » s4.

La tâche de correction était un vrai bug amont : sur un clone neuf, npx nx test api échouait sur 1 suite dès la sortie de boîte (auth.service.test.ts, « TypeError: Cannot read properties of undefined (reading 'prototype') »), 4 passaient, 14 tests verts, 2.2 s. Le chemin direct a atteint des tests entièrement verts en 2 min 13 s, $0.70, 40 tours. Le chemin chaîne, intent puis spec puis plan puis build, a lui aussi atteint le vert en 11 min 31 s, $3.46, 169 tours. Cela fait ×5.2 en temps et ×4.9 en coût côté machine seulement s2.

C'est côté humain que la chaîne fait mal. Elle a produit 5,488 mots d'artefacts à lire (intent 558 + spec 2,167 + plan 2,763), environ 27 min à 200 mots/min, pour un correctif dont la charge de revue directe est un petit diff s4. La tâche de fonctionnalité (muter des auteurs) à travers toute la chaîne a pris 15 min 13 s, $4.11, 158 tours, et a livré un modèle Prisma Mute avec migration, endpoints mute et unmute, filtrage du feed, 1,422 insertions sur 15 fichiers, 50 tests verts avec 3 fichiers de test nouveaux ou étendus et un spec e2e. Ses artefacts pesaient 6,852 mots (intent 450 + spec 2,337 + plan 4,065), soit environ 34 min de lecture s2.

La lecture sceptique de l'étape Design s'est confirmée. La critique LinkedIn dit que le playbook cache ses prérequis : les skills d'organisation pour la marque, la sécurité et l'UX doivent déjà exister, et quelqu'un doit savoir mener le brainstorm s7. L'agent l'a confirmé sans qu'on le lui demande. La réserve C0 de spec.md dit, mot pour mot : « No org skills available. … This spec has therefore not been checked against brand, security or UX policy. » Une spec de plus de 2,000 mots qui reformule le code existant et ne peut pas vérifier la politique est l'étape à sauter quand on travaille seul s7.

La critique sur l'infrastructure tient aussi. L'argument : quand les tests tapent sur des fakes périmés, « the agent sees the tests pass and reports the work finished », parce que la chaîne d'artefacts enregistre ce qui a été décidé, pas ce qui tourne réellement s8. Dans l'essai, la boucle n'a vérifié que les tests unitaires et le build ; la revue elle-même listait nx e2e comme « Not run: needs a running server and a seeded DB » et prisma migrate status comme « Not run: needs a DB ». La boucle verte n'a jamais touché un système vivant s8.

L'étape Deploy a été la victoire bon marché. REVIEW.md a tourné en 117 s pour $0.80 : nx test (5/5 suites, 50 passés), nx build (ok), un delta de lint contre la base du plan (34 contre 33, le +1 explicitement autorisé par l'item A3 du plan) et un contrôle prettier (9 fichiers en échec, consigné comme nit N1). Verdict : 0 Important, 6 nits, 5 listés et 1 résumé parce que le plafond s'appliquait. La revue a refusé d'approuver son propre travail avec « this agent does not approve », la séparation des tâches telle que l'écrit le cours s2. Le garde-fou par hook s'est comporté comme le décrivent les docs : invité à déployer avant le merge, l'agent a refusé de son propre jugement sans lancer le script, donc le hook ne s'est jamais déclenché. Après le merge, la tentative de déploiement a été bloquée par le hook PreToolUse (exit 2) en 14 s avec le message du garde-fou s19.

Les evals ont été peu coûteuses à écrire et faciles à rater. Cinq cas sont sortis de l'historique git en 283 s pour $1.44. Les deux exécutions ont tourné sur la mauvaise base, parce que le runner a créé sa branche après le merge du correctif, et les deux agents l'ont détecté (« the bug was already fixed here ») au lieu de simuler un succès. Une exécution d'eval coûte environ 60 à 70 s, donc le dimensionnement du playbook lui-même, 20 à 50 cas, représente à peu près 20 à 55 min de temps d'agent par run de CI s2. La mise en place de CLAUDE.md a pris 63 s et $0.44 pour une page committée, le coup le moins cher de tous ; un tri de log CI en lecture seule a nommé la bonne cause en 11 s pour $0.13 s2.

Le fil communautaire importe la télémétrie plus large : sur 10,000 développeurs, les équipes très IA mergent 98% de PR en plus, tandis que le temps de revue augmente de 91% et la taille des PR de 154% s6.

Mesures

Protocole : la chaîne a tourné en headless (claude -p, modèle claude-opus-5-5, permissions limitées à acceptEdits plus une allowlist, --setting-sources project,local) sur un clone jetable de gothinkster/node-express-realworld-example-app (Express + TypeScript + Prisma + Postgres 16 dans Docker, workspace Nx). Chaque étape a été chronométrée et consignée dans exp/metrics.jsonl (17 lignes). Total : $11.90 + $0.14 pour un rejeu du hook, 539 + 3 tours, environ 41 min de temps d'agent.

Limites : un repo, un développeur, une journée. Les plays à l'échelle d'une équipe n'ont pas été exécutés, le mode headless compresse les étapes d'interview en prompts uniques, et les runs d'evals ne comptent que le coût par run.

À faire lundi

• Écris une page de CLAUDE.md pour ton repo principal : commandes de build, de test et de lint, les deux erreurs que l'agent a faites la semaine dernière. Committe-la. Prévois 63 s de temps d'agent.
• Avant ta prochaine tâche non triviale, demande d'abord un intent.md : objectif, non-objectifs, décisions ouvertes. Réponds aux questions ouvertes, puis laisse l'agent planifier. Saute spec.md sauf si tu as des skills de politique d'organisation pour la vérifier.
• Lance l'étape build en plan mode avec une boucle TDD et exige que le plan consigne les écarts (D1, D2, ...) pour que la revue ait de quoi s'appuyer.
• Ajoute une passe REVIEW.md lancée par une session neuve, avec un plafond de nits et une ligne explicite « this agent does not approve ». Fais-lui lancer les tests, le build, un delta de lint et un contrôle du formateur.
• Mets en place un garde-fou déterministe : un hook PreToolUse qui sort en exit 2 sur deploy quand la branche n'est pas main.
• Avant de faire confiance à une boucle verte, liste en bas de la revue ce qu'elle n'a pas exécuté (e2e, migrations, tout ce qui demande une base vivante).
• Mesure ta propre taxe de garde-fou : chronomètre le chemin direct et le chemin chaîne sur le même petit bug, puis compte les mots que tu as dû lire.

Aller plus loin

• La variante à deux garde-fous : un garde-fou de revue adversariale (sdlc-gate) et seulement deux points de décision humaine au lieu d'un par étape, la forme pragmatique pour une petite équipe s12.
• La chaîne complète installable : templates intent, spec, plan et REVIEW, un validateur de garde-fou, un runner d'evals et la détection de bandes de contrôle, si tu préfères ne pas monter l'échafaudage à la main s5.
• Planification en interview d'abord : une question à la fois bat le lot, et « AI agents don't ask clarifying questions. They assume. » Un compte rendu de mise en place sans chronométrage s11.
• Pourquoi un pipeline fixe unique se fait contourner : « a docs fix and a payments migration shouldn't travel the same path », et le vrai processus devient invisible. Range le playbook avec Kiro et GitHub Spec Kit s9.
• Les manques qu'un éditeur de plateforme va te vendre : de l'intake signal vers intent, du routage par rayon d'impact, un tableau de bord de métriques. s13.
• Un cabinet de conseil qui applique la même forme (CRAFT) chez ses clients depuis janvier et admet « we don't yet have a formal answer for what a control band looks like » s10.
• Un exemple d'intent.md travaillé (une case Select All) qui montre le rôle du fichier : faire remonter les décisions ouvertes au lieu de laisser l'agent choisir en silence s14.

Sources

• The AI-Native SDLC Playbook (launch post), claude.com. Pourquoi le lire : la forme en six étapes et la règle de l'artefact committé en cinq minutes.
• The AI-native SDLC playbook (course, 14 lessons), Claude Academy. Pourquoi le lire : le seul endroit où vivent les chiffres (20 à 50 tâches d'eval, plafond de 5 nits, 2 à 3 sessions), gratuit et sans login.
• The Committed-Artifact Chain, howardism.dev. Pourquoi le lire : qui rédige et qui accepte chaque artefact, et le constat sans détour que rien dans le playbook n'est mesuré.
• bashebr/ai-native-sdlc, GitHub. Pourquoi le lire : templates, validateur de garde-fou et runner d'evals à installer plutôt qu'à écrire.
• Anthropic published an AI-native SDLC playbook, r/ClaudeAI. Pourquoi le lire : le fil qui amène la télémétrie Faros (98% de PR en plus, +91% de temps de revue) dans le débat.
• The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. Pourquoi le lire : l'argument des prérequis cachés que l'étape spec a confirmé d'elle-même.
• The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. Pourquoi le lire : le problème des fakes périmés, porté par un éditeur mais l'argument tient seul.
• The AI-native SDLC won't be one process, worldprogramming.org. Pourquoi le lire : l'argument de la cérémonie contre un chemin unique pour chaque changement.
• Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. Pourquoi le lire : une équipe indépendante qui converge vers la même forme et admet le trou de Maintain.
• AI-Native SDLC: First Try, kyle.pericak.com. Pourquoi le lire : le seul premier essai pratique en interview d'abord, écrit avant l'existence du playbook.
• TsCarpe/claude-sdlc-skills, GitHub. Pourquoi le lire : la variante à deux garde-fous avec une étape de revue adversariale.
• Implementing the Anthropic AI-Native SDLC Playbook, Port blog. Pourquoi le lire : la liste de ce que le playbook laisse de côté, à lire comme une carte des manques.
• What Is intent.md in Claude Code?, dev.to. Pourquoi le lire : un intent.md concret dont tu peux copier la structure.
• Hooks guide, Claude Code docs. Pourquoi le lire : comment un hook PreToolUse avec exit 2 devient le garde-fou déterministe sur lequel s'appuie le playbook.

FAQ

La chaîne complète vaut-elle jamais le coup pour un correctif d'une ligne ?

Pas dans cet essai : ×5.2 en temps et ×4.9 en coût pour le même résultat vert, plus 5,488 mots à lire. Utilise intent.md seul pour les petites tâches.

Pourquoi sauter spec.md quand on travaille seul ?

La spec s'est signalée elle-même : sans skills d'organisation pour la marque, la sécurité ou l'UX, elle ne pouvait pas vérifier la politique, et elle a dépensé plus de 2,000 mots à reformuler le code existant.

Le hook remplace-t-il le jugement du modèle ?

Non, il le double. L'agent a refusé le déploiement avant merge de lui-même ; le hook a bloqué la tentative après merge en 14 s avec exit 2.