L’IA écrit-elle du bon code?

Question

VX-N · Accepted Answer

Oui — remarquablement bon, sur les chemins bien balisés qui forment la majeure partie des logiciels d’affaires. Le risque n’est pas la syntaxe; l’IA écrit rarement du code qui ne s’exécute pas. Le risque, c’est l’architecture sans supervision : du code qui fonctionne pendant la démo et qui s’effondre face aux vrais droits d’accès, aux vrais volumes de données et à la vraie charge. Que le code écrit par l’IA tienne ou pourrisse dépend de la discipline de révision et des tests qui l’entourent, pas du modèle. Pour la majorité routinière des logiciels d’affaires (formulaires, tableaux, API, rapports, liens entre systèmes), le code écrit par l’IA n’est pas seulement acceptable, il est souvent plus propre que la version humaine moyenne, parce que l’IA a vu le modèle dix mille fois et ne s’ennuie pas au neuvième écran. Quiconque vous dit que le code de l’IA est forcément bâclé décrit 2023, ou protège un modèle de facturation. Le problème de la syntaxe est réglé. C’est justement pour ça que le vrai problème s’est déplacé vers un endroit moins visible. Le vrai problème, c’est que l’IA optimise pour la question qu’on lui pose, et une démo pose des questions faciles. Le code généré va volontiers récupérer toutes les fiches et les filtrer dans le navigateur — correct avec 200 lignes, mort avec 200 000. Il va vérifier les droits d’accès dans l’interface, mais pas dans la couche de données, ce qui veut dire que les règles tiennent jusqu’à ce que quelqu’un appelle l’API directement. Il va stocker la même information à trois endroits parce que chaque session a réglé son propre problème local, et les trois copies divergent discrètement un mois plus tard. Rien de tout ça n’apparaît quand le développeur — humain ou IA — clique sur le scénario où tout va bien. Tout ça apparaît quand arrivent de vrais utilisateurs, de vraies données et quelqu’un d’un peu malveillant. Le code était bon; l’architecture n’était pas supervisée. La différence entre du code d’IA qui tient des années et du code d’IA qui pourrit en quelques mois est ennuyeuse, et c’est la même discipline qui a toujours distingué les logiciels sérieux des démos : quelqu’un de responsable lit le code, le modèle de données est conçu avant que la génération commence plutôt qu’accumulé au fil des sessions, les droits d’accès sont appliqués là où vivent les données, et il existe des tests qui attraperaient les défaillances ci-dessus avant qu’un client le fasse. L’IA rend cette discipline moins coûteuse à appliquer, pas facultative — les tests eux-mêmes sont maintenant en grande partie écrits par l’IA. Ce qui ne peut pas être généré, c’est la décision de les exiger. Voilà ce que veut dire travailler avec l’IA de façon professionnelle, par opposition à accepter tout ce qu’elle produit : le modèle écrit la majeure partie du code, et un humain assume les conséquences — le modèle de données, la conception des droits d’accès, les contrats d’intégration, la révision. C’est ainsi que VX-N bâtit tout, et c’est pourquoi la vitesse est réelle sans l’effondrement sous la charge. Si vous avez une base de code générée et que vous ne savez pas trop de quel type elle est, c’est un premier appel tout indiqué; un premier examen et un plan en 24 heures ne vous coûtent rien.