Ce que l’IA change, et ce qu’elle ne change pas, en ingénierie logicielle

Travailler avec des assistants IA sur de vraies fonctionnalités et du vrai code legacy m’a laissé une courte liste de ce qui a changé, et une plus courte encore de ce qui n’a pas changé.

Ce qui a changé. Écrire du code n’est plus l’activité rare. Un assistant produit une implémentation plausible plus vite que je ne peux la lire, dans n’importe quel langage, avec des tests si on les demande. Le coût d’essayer une approche s’est effondré: explorer trois conceptions avant d’en choisir une est devenu abordable. Et la spécification s’est déplacée au centre: ce que j’écris avant le code est désormais ce qui est réellement construit, ligne pour ligne, alors il vaut mieux qu’elle soit juste.

Ce qui n’a pas changé. Quelqu’un doit toujours décider ce que le logiciel doit faire, ce qu’il ne doit jamais faire, et quand il est assez bon pour partir.

L’assistant implémentera très bien une mauvaise idée

La vérification reste la partie coûteuse, et elle l’est devenue davantage, pas moins: il y a plus de code à vérifier et il arrive plus vite. Et la responsabilité n’a pas bougé: quand du code généré tombe en production, personne ne demande des comptes au modèle.

La conséquence pour le métier n’est pas que les ingénieurs disparaissent. C’est que le centre de gravité passe de la production du code à sa validation: écrire des spécifications assez précises pour être exécutées, relire les conceptions de façon contradictoire, garder les invariants explicites, et refuser de fusionner ce qui ne peut pas être vérifié. C’étaient déjà les compétences seniors. L’IA en a fait tout le métier.

Ce qui m’inquiète n’est pas la technologie. Ce sont les organisations qui mesurent le gain en lignes produites et jamais en lignes vérifiées, et qui laissent partir une masse de code généré parce qu’il ne coûtait rien à produire.

Ne rien coûter à produire n’a jamais voulu dire ne rien coûter à posséder