Développement piloté par PRD : comment j'utilise plus de 30 PRD pour livrer avec des agents IA

Le workflow RalphBlaster de SaasMaker génère une pull request complète à partir d’un ticket d’une ligne en moins de 45 minutes, sans que le développeur ne touche une seule ligne de code pendant l’implémentation.¹

J’ai essayé ce modèle. Il fonctionne. Il échoue aussi de manières que les vidéos de démonstration ne montrent pas.

TL;DR

J’ai rédigé plus de 30 PRD pour des tâches d’agents IA au cours des six derniers mois. Le modèle fonctionne bien pour des tâches bien définies avec des critères d’acceptation clairs : endpoints CRUD, ajouts de tests, composants d’interface suivant des modèles établis. Il échoue face aux exigences ambiguës, aux décisions d’architecture inédites et à tout ce qui nécessite un jugement humain itératif. Mon modèle de PRD a évolué d’un simple format de user story vers un document structuré contenant les emplacements de fichiers, les attentes de tests, les contraintes et des listes explicites de « ne pas toucher ». Cette évolution s’est produite parce que les agents interprétaient les PRD vagues de manière surprenante.

Le workflow que j’utilise réellement

Étape 1 : créer un ticket

Je définis ce qui doit se passer en langage naturel. La précision compte bien plus que je ne le pensais initialement :

Vague (produit des résultats imprévisibles) :

Add user preference saving to the settings page.

Précis (produit des résultats prévisibles) :

Add dark mode toggle to /settings. Persist to user_preferences
table (column: dark_mode, type: boolean, default: false).
Use existing SettingsForm component. Add toggle below the
notification section. No new dependencies.

La seconde version contraint suffisamment l’agent pour que le résultat corresponde aux attentes. La première version m’a donné une page de paramètres avec un nouveau composant React, trois nouveaux paquets npm et une implémentation localStorage au lieu de la persistance en base de données que je voulais.

Étape 2 : générer ou rédiger le PRD

Mon skill /prd convertit un ticket en un PRD structuré avec des user stories, des critères d’acceptation, des emplacements de fichiers et des attentes de tests.² Un PRD typique ressemble à :

## Story: Add dark mode toggle
**As a** user
**I want to** toggle dark mode from settings
**So that** I can read comfortably in low light

### Acceptance Criteria
- [ ] Toggle appears in SettingsForm below notifications
- [ ] Persists to user_preferences.dark_mode (boolean)
- [ ] Default: false (light mode)
- [ ] Toggle state reflects current DB value on page load

### Files to Modify
- app/routes/settings.py (add dark_mode to form handler)
- app/templates/settings.html (add toggle component)
- app/models/user.py (add dark_mode column if missing)

### Files NOT to Modify
- app/static/css/styles.css (dark mode CSS already exists)
- app/templates/base.html (already reads dark_mode class)

### Test Expectations
- Test toggle persists to database
- Test default value on new user
- Test toggle reflects current state on reload

La section « Files NOT to Modify » a été la plus grande évolution du modèle. Sans elle, les agents « amélioraient » utilement des fichiers connexes, introduisant des changements que je n’avais pas demandés et que je ne voulais pas.

Étape 3 : implémentation par l’agent

L’agent travaille dans un worktree git isolé, évitant toute interférence avec ma branche courante :³

# Create isolated worktree for agent task
git worktree add ../worktrees/dark-mode -b feature/dark-mode

# Agent works in ../worktrees/dark-mode/
# I continue working in main workspace

# Review and cleanup after merge
git worktree remove ../worktrees/dark-mode

Mon garde-fou de récursion surveille le comportement de spawn de l’agent. Mon gardien de sécurité git empêche l’agent de faire un force-push ou de commiter des identifiants. Ces hooks s’exécutent automatiquement. Je ne supervise pas l’agent pendant l’implémentation.

Étape 4 : revue

Une notification arrive lorsque l’agent termine. Je passe en revue le diff par rapport aux critères d’acceptation du PRD. Si tous les critères sont remplis, je fusionne. Sinon, je corrige manuellement ou je relance l’agent avec un contexte mis à jour.⁴

Où le développement piloté par PRD fonctionne

Endpoints CRUD avec des modèles de données clairs. Le PRD spécifie le modèle, les routes et le format de réponse. L’agent génère du code standard qui correspond aux modèles existants.

Ajouts de tests pour du code existant. « Écrire des tests pour app/content.py couvrant load_post_by_slug avec un slug valide, un slug invalide et un fichier manquant » produit des tests utiles parce que la fonction existe déjà et que les critères d’acceptation sont objectifs.

Composants d’interface suivant des modèles établis. « Ajouter un filtre par catégorie à la page de listing du blog en utilisant le même modèle d’onglets que la page de guide » fonctionne parce que l’agent peut référencer le modèle existant.

Migrations de base de données avec des schémas définis. Le PRD spécifie les colonnes, les types, les valeurs par défaut et les contraintes. L’agent génère la migration et met à jour le modèle.

Où le développement piloté par PRD échoue

Exigences ambiguës. « Améliorer le blog » n’est pas un PRD. L’agent effectuera des changements, mais ils ne correspondront pas à votre intention parce que votre intention n’a pas été spécifiée.

Décisions d’architecture inédites. Quand j’ai eu besoin de concevoir le modèle de consensus du système de délibération, aucun PRD ne pouvait capturer cette décision. J’avais besoin d’explorer des options, d’évaluer des compromis et d’itérer sur la conception. Cela nécessitait mon skill de délibération, pas un PRD.

Optimisation des performances. « Accélérer le chargement de la page » nécessite du profilage, des mesures et une investigation itérative. L’agent ne peut pas profiler les modèles de trafic de votre production à partir d’un PRD.

Code critique pour la sécurité. Les PRD pour les systèmes d’authentification produisent du code qui gère le cas nominal. Les cas limites en authentification (attaques par timing, fixation de session, CSRF dans des flux non standard) nécessitent une expertise humaine que les PRD ne peuvent pas encoder.

Comment mon modèle de PRD a évolué

Version 1 (mois 1) : user stories simples

As a user, I want to save preferences so I can customize my experience.

Problème : trop vague. L’agent faisait des hypothèses raisonnables mais erronées sur le mécanisme de stockage, le placement dans l’interface et la portée.

Version 2 (mois 2) : ajout des emplacements de fichiers

## Story: Save preferences
### Files to Modify
- app/routes/settings.py
- app/templates/settings.html

Problème : mieux, mais les agents « amélioraient » encore des fichiers adjacents sans permission.

Version 3 (mois 4) : ajout des contraintes

## Story: Save preferences
### Files to Modify (only these)
- app/routes/settings.py
- app/templates/settings.html
### Constraints
- No new dependencies
- Use existing database models
- Do not modify CSS

Problème : les agents ignoraient parfois les contraintes lorsqu’elles entraient en conflit avec les « bonnes pratiques » issues de leurs données d’entraînement.

Version 4 (actuelle) : exclusions explicites + attentes de tests

Le modèle actuel ajoute « Files NOT to Modify », des attentes de tests explicites et des cases à cocher pour les critères d’acceptation. Cette version produit des résultats prévisibles environ 85 % du temps. Les 15 % restants nécessitent une seconde passe avec des instructions clarifiées.⁵

La bibliothèque de 30 PRD

Après plus de 30 PRD, des tendances ont émergé :

Le taux de réussite pour les fonctionnalités inédites (50 %) explique pourquoi le développement piloté par PRD complète mon workflow plutôt que de le remplacer. La moitié du temps, le travail inédit nécessite une itération que les PRD ne peuvent pas capturer à l’avance.

Points clés à retenir

Pour les développeurs solo : - Commencez par un type de PRD bien défini (CRUD, tests) et validez le workflow avant de passer à des tâches plus complexes - Ajoutez « Files NOT to Modify » à chaque PRD ; les agents « amélioreront » utilement du code que vous ne leur avez pas demandé de toucher - Utilisez les git worktrees pour isoler le travail de l’agent ; le coût de nettoyage d’une exécution d’agent échouée devrait être une seule commande, pas une séance d’archéologie git

Pour les responsables d’ingénierie : - La qualité du PRD détermine la qualité du résultat de l’agent ; investissez dans les modèles de PRD et les processus de revue avant de mettre à l’échelle l’utilisation autonome des agents - Suivez le ratio de fusion sans modifications pour mesurer la maturité du workflow ; ce ratio devrait s’améliorer à mesure que les modèles de PRD évoluent - Le travail d’architecture inédit et le code critique pour la sécurité ne devraient pas être délégués via PRD ; réservez la délégation aux agents pour les tâches bien définies et reproductibles

Références