Coder avec un agent tient de la magie pendant une semaine environ. Vous décrivez une fonctionnalité, il écrit le code, et vous avancez plus vite que jamais. Puis vous lui demandez de modifier quelque chose, et il réécrit avec assurance la mauvaise moitié, parce qu'il n'a jamais vraiment compris à quoi servait la fonctionnalité. Il n'a compris que votre dernière phrase.

Le problème ne vient pas du modèle. Il vient du fait qu'un prompt est un mauvais endroit où conserver l'intention. Les prompts sont éphémères. La compréhension s'évapore dès que la conversation se termine. Ce qui survit, c'est le code, et le code vous dit ce qui a été construit, jamais pourquoi.

Un prompt est une requête, une spec est un contrat

Quand vous construisez une fonctionnalité à coups de prompts, chaque message est une négociation repartie de zéro. L'agent devine les parties que vous avez laissées de côté, et ses suppositions dérivent. Au dixième message, vous ne construisez plus, vous corrigez.

Une spec change la nature du travail. Avant tout code, nous écrivons ce que nous construisons et pourquoi. Le problème que cela résout, les entrées et les sorties, les cas limites, ce à quoi ressemble le "terminé". Cela n'a pas besoin d'être long. Cela doit être clair. L'agent met alors en œuvre un contrat au lieu de deviner un souhait.

Un agent peut construire la fonctionnalité à la perfection sans avoir la moindre idée de la raison de son existence. La spec, c'est là que vit le pourquoi.

La spec sert aussi aux humains

Le plus pratique, c'est que le document qui rend un agent fiable est le même que celui qui aligne une équipe. La spec, c'est là que les désaccords remontent à la surface avant de devenir du code. C'est là que le responsable produit et l'ingénieur découvrent qu'ils s'imaginaient deux choses différentes, à un moment où la modifier ne coûte encore rien.

Nous avons détecté plus de bugs dans une spec d'une page que dans des heures de relecture, car l'endroit le moins coûteux pour corriger un malentendu, c'est avant qu'il n'ait été construit deux fois. La spec transforme une vague impression en quelque chose que l'on peut pointer du doigt et contester.

Comment nous travaillons en pratique

Nous gardons des specs courtes et proches du code. Pour une fonctionnalité, cela peut tenir en quelques paragraphes : l'objectif, les données, les règles, les cas qui doivent fonctionner et les cas qui doivent échouer. L'agent la lit, l'implémente en s'y référant, et nous relisons le résultat à l'aune du même document. Quand la fonctionnalité change, c'est la spec qui change d'abord, et le code en découle.

Cela règle aussi ce qui rend le code assisté par IA effrayant à grande échelle. Quand l'intention vit dans une spec, un nouvel ingénieur ou une nouvelle session d'agent peut reprendre le travail sans que le contexte soit perdu. La compréhension est écrite noir sur blanc, elle n'est pas prisonnière de l'historique de discussion d'une seule personne.

La vitesse sans l'amnésie

La promesse du développement assisté par IA, c'est la vitesse. Le coût caché, c'est l'amnésie. Avancez assez vite à coups de prompts seuls et vous vous retrouvez avec une base de code que personne, humain ou modèle, ne sait expliquer. La spec est le remède. C'est une petite dose d'écriture en amont qui vous achète un système dont l'intention reste lisible des mois plus tard.

Écrivez la spec d'abord. Laissez l'agent construire en s'y référant. Relisez en vous y référant. Vous avancerez tout aussi vite, et vous comprendrez encore ce que vous avez construit le jour où cela comptera.