Idée principale

Une spécification complète est une fiction : même bien écrite, elle laisse des zones muettes — cas limites, messages d'erreur, comportements implicites, règles de sécurité, temps d'expiration, micro-interactions, décisions de repli. Ces zones ont toujours été comblées par le développeur au moment de coder, sans que personne n'appelle cela une décision produit.

Confier une partie du code à un agent supprime ce comblement silencieux. Il faut dire le comportement attendu, trancher les cas limites, écrire les critères d'acceptation et vérifier la sortie, parce que la machine ne partage ni l'habitude de l'équipe ni la mémoire des arbitrages passés. Ce qui était absorbé dans l'implémentation remonte à la surface et devient un objet à cadrer.

Le changement n'est donc pas que ces décisions apparaissent : elles existaient déjà. C'est qu'elles cessent d'être invisibles, et qu'il devient impossible de prétendre qu'elles relèvent de la seule exécution.

Pourquoi c'est important

Cela transforme une charge d'écriture apparemment supplémentaire en révélation utile : le temps passé à expliciter un comportement pour un agent est du temps passé sur un arbitrage qui se prenait sans trace.

Et cela déplace le débat sur la responsabilité produit des développeurs : ils ne commencent pas à décider, ils décidaient déjà — la délégation à une machine rend seulement la chose visible et discutable.

Nuances et limites

L'explicitation a un coût, et il n'est pas toujours rentable : sur un comportement trivial, écrire ce qu'un développeur aurait tranché en trois secondes consomme plus qu'il ne rapporte.

Et l'agent comble aussi les silences, à sa manière : sans consigne, il produit une décision par défaut qui a toutes les apparences d'un choix. Le risque se déplace alors du non-dit vers le non-relu.

Questions ouvertes

• Quelles zones muettes méritent d'être écrites une fois pour toutes comme règles d'équipe, plutôt que tranchées à chaque fonctionnalité ?