N'hésitez pas à me secouer si vous me trouvez à côté de la plaque.
Si on reprend le modèle de la Technology adoption life cycle, on est dans la phase du Chasm où la early majority demande des REX pour oser se lancer. Et cette majorité semble en avoir très envie / a un gros FOMO que provoque le marketing sous toutes formes.
Sauf qu'aujourd'hui, à part "100% de notre code est produit par de l'IA" on a pas des tonnes de REX qui parlent d'outcome tels que des gains à la fois en vitesse et en stabilité dans la durée (on a même des contre-exemples à la fois produit et technique avec le feature bloat et les bugs d'Anthropic par exemple). Et je pense qu'ils ne sont pas encore prêts d'en voir. Le mieux qu'on ait se fait dans des scopes avec peu d'enjeu, voiree d'ouverture pour critiquer, ou des scopes hyper spécialisés qui sont loin des préoccupations de la masse.
Avec de la chance, le temps que les gens comprennent ce vers quoi veut nous emmener Birgitta Böckeler avec son approche du Harness Engineering, et que les orgas mettent en place le nécessaire pour que ça marche, on en a probablement, au pif, encore pour 8-12 mois avant d'avoir de premiers REX d'entreprises sur des scopes réduits qui ressemblent à peu près à celles qui en demandent :
J'entends ça de plus en plus. Et grossièrement ma réponse (forme adaptée selon le public) :
Ce n'est pas tant que les ops sont en retard que les influenceurs devs ont pu donner l'illusion de grandes avancées, sans preuve de maintenabilité à long terme (quoiqu'on a maintenant un certain nombre de REX de gueule de bois maintenant).
Le volume de produits dédiés aux opseries est arrivé avant le volume de REX, et les quelques REXs que je vois apparaissent depuis la fin / début d'année sur des éléments assez spécifiques et peu ouverts / accessibles pour être mis à l'épreuve du public.
CLAUDE.md + living docRéflexe du moment sur mes mini-projets : mon CLAUDE.md est généré par des scripts. Il y a au moins une section Instructions (sourcé d'un md dédié), une section commandes (sourcé d'un make help, ./gradlew tasks ou dans le genre), une section Structure (sourcé d'un parcours du dossier avec une fonction d'ignore). Le top du fichier indique que c'est généré par un script dont je donne le chemin, et qui articule les scripts dédiés à chaque section. Le fichier est régénéré automatiquement par un Stop hook.
J'ai une suite d'actions que je répète désormais invariablement quand je reprends un existant (jusqu'ici assez modeste) pour le rendre utilisable avec la GenAI : le CLAUDE.md du dessus, un répertoire tooling, un répertoire devcontainer avec firewall généré par un script et qui me permet de charger des skills/mcp de mon home pour être dispos dans le conteneur, puis immédiatement derrière, je mets en place des tests unitaires en faisant boucler le modèle sur une haute target de couverture et mutation testing (le but étant d'ajouter de la friction et du feedback à tout changement de comportement). Selon le type de projet, je m'embarque aussi parfois à avoir une couverture spécifique en tests end-to-end, surtout si je sais que la refonte architecturale sera lourde. À partir de là, je suis plus serein pour lancer un agent dans la masse et faire des choses, et quand je vois un comportement qui fait dévier le code, son archi, etc, je place des instructions et met en place un outil de vérification auto.
En gros, j'ai plus de sécurité à garantir que le comportement bouge pour les bonnes raisons même s'il est incorrect, que de lancer des améliorations sans savoir quel comportement voulu ou non disparaitrait sans que je le sache.
