Le intent.md, qui lance le processus de développement logiciel, peut entrer par différentes voies. Une personne a une idée, un ticket est déposé, ou un incident est révélé via une alerte (voir Étape 6 : Maintenir).
Lorsqu'une personne a une idée, elle fait un brainstorming avec Claude et produit une proto-spécification en Markdown. Dans le SDLC traditionnel, cette même personne doit ensuite convaincre un membre de l'équipe produit de rédiger l'idée avec elle ou en son nom.
La proto-spécification générée par Claude est lisible par un humain, versionnée, et immédiatement consommable par l'étape suivante. La proto-spécification est enregistrée sous forme d'intent.md.
Que l'intention provienne d'un déclencheur d'événement ou d'une personne, les mêmes étapes s'appliquent : le propriétaire du produit relit et corrige l'intent.md rédigé par l'agent avant qu'il ne soit validé (commit).
Ce qui change
| Traditionnel | Natif IA |
|---|---|
| Une idée passe par des entrées de backlog, des user stories, des points d'histoire et des réunions de raffinement avant que quiconque puisse agir dessus. La propriété est transférée à chaque transmission, de sorte que ce qui parvient à l'ingénierie est éloigné de plusieurs étapes de ce que l'initiateur voulait dire. | L'initiateur fait un brainstorming avec Claude et consigne le résultat sous forme d'intent.md, une proto-spécification dans les propres termes de l'initiateur. L'artefact contient ce qui est souhaité, pourquoi, et sous quelles contraintes. Les processus répétitifs sont encodés via des Compétences. |
Pour commencer
- Prérequis : Aucun.
- Infrastructure : Accès à Claude pour les personnes qui ne sont pas ingénieures (claude.ai ou Cowork) ; un modèle d'
intent.mdconvenu ; un emplacement partagé et versionné pour l'intention que le propriétaire du produit surveille. Pour un seul produit, l'emplacement le plus simple est un dossierintent/dans le dépôt du produit. Cette configuration maintient la chaîne d'artefacts à proximité du code qui en est dérivé. Un dépôt d'intention dédié ne vaut la surcharge que lorsque l'intention s'étend sur de nombreux dépôts, et dans un monorepo, il s'agit d'un répertoire. La section Systèmes hérités de l'Étape 3 : Construire explique comment cet emplacement se rapporte à un outil Jira ou de gestion des exigences qui détient déjà l'enregistrement.
La mise en place de cela est une tâche ponctuelle pour l'équipe plateforme ou ingénierie. Un membre technique de l'équipe doit mettre en place l'emplacement de l'intention et décider qui peut y écrire, car de nombreux contributeurs viendront de toute l'organisation.
Une fois le dépôt créé, les contributeurs sans expérience de Git n'ont pas besoin d'utiliser Git directement. À la place, un connecteur vers le système de contrôle de version (par exemple, GitHub) permet à Claude de valider (commit) des fichiers Markdown en leur nom depuis claude.ai ou Cowork.
Comment l'exécuter
- L'initiateur décrit le problème à Claude avec ses propres mots. L'initiateur peut décrire ce qu'il ne peut pas faire aujourd'hui, qui est affecté par l'idée, à quoi ressemble une amélioration, ou ce qui est hors périmètre. Aucun langage formel n'est requis.
- Faites un brainstorming jusqu'à ce que l'idée soit concrète. Claude pose les questions qu'un analyste poserait : périmètre, utilisateurs, contraintes, et à quoi ressemble le succès.
- Demandez à Claude de rédiger le résultat sous forme d'
intent.mden utilisant le modèle de l'organisation, qui peut être encodé comme un ensemble de Compétences mis en place par un membre technique de l'équipe et validé par un responsable. Cela peut couvrir le problème, le résultat proposé, les utilisateurs et systèmes affectés, les contraintes, et les questions ouvertes. - L'initiateur corrige tout ce que Claude a mal compris.
- Validez (commit) l'
intent.mddans l'emplacement partagé. L'auteur et l'horodatage rejoignent l'enregistrement, et le propriétaire du produit reprend l'idée à partir de là.
À quoi cela ressemble
intent.md :
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
## Affected users and systems
Claims handlers, portal team, claims-core API.
## Constraints
No new PII in the portal session. Existing authentication only.
## Open questions
Do third-party loss adjusters need access too?Considérations de gouvernance
La preuve est l'intent.md validé (commit), qui répertorie l'auteur, l'horodatage, et l'historique complet des révisions. Cela est consigné dans l'historique Git de l'emplacement de l'intention. Le propriétaire du produit approuve, et la décision d'accepter ou de rejeter qui envoie l'intention vers l'Étape 2 : Concevoir est enregistrée comme la fusion (merge) ou la revue de clôture.
Comment le mesurer
- Indicateur avancé : Temps entre la première conversation et un
intent.mdvalidé (commit), lu à partir de l'historique Git de l'emplacement de l'intention, qui enregistre l'auteur et l'horodatage. L'attente est que cela passe d'un cycle d'élicitation et de raffinement de plusieurs semaines à quelques heures. - Indicateur retardé : Le taux de survie, ou la part des fichiers
intent.mdque le propriétaire du produit accepte dans l'Étape 2 : Concevoir plutôt que de clôturer. La décision d'accepter ou de rejeter est enregistrée comme la fusion de l'artefact ou la revue clôturée. De plus, comptez les modifications apportées à l'intent.mdaprès le premier commit despec.mdpour le même changement.