Table des matières
Confier 100% de son code à une IA, ça mène où ?
À lire l'article qui a inspiré cette note :
Un an de 100% généré - Le bilan
En résumé, ce que je retiens de cet article :
Conséquences d'un mandat 100% IA
- 100% IA ⇒ empilement de fonctionnalités, logiciel réécrit 100% par machine et qui n'est plus compréhensible ni par les humains ni même par les machines - Les développeurs les plus expérimentés partis, plus personne n'est capable de comprendre le code écrit - La dette technique empilée fait que le logiciel n'est plus maintenable
Dette cognitive et dégradation des compétences
- On craint la perte des compétences humaines, à force de tout confier à l'IA - Rien dans notre quotidien ne nous pousse plus à réfléchir de façon critique - Les compétences qu'on cesse d'exercer disparaîtront vite
Ce à quoi il faut faire attention
- Attention à garder la main, notamment sur l'architecture logicielle - Attention à comprendre ce qu'a fait l'IA au moins dans les grandes lignes, et en terme d'organisation du code. Rectifier pour savoir où est quoi et quoi fait quoi : un humain doit pouvoir faire le tri, l'IA aussi - Il ne faut pas accepter sans réserve tout ce que l'IA propose
Les conseils pour ne pas “perdre la main” : - formuler des idées avant de consulter l'IA - vérifier ce qui est généré, comprendre les décisions de l'IA, questionner l'IA sur ses choix, la rediriger si des choix nous semblent meilleurs
Mon retour / analyse
C'est quoi développer ?
C'est très intéressant et je suis d'accord : je continue de faire le parallèle entre agents IA et équipes de développement humain : tant qu'on reste sur de petits projets simples, ou tant qu'on découpe un gros projet complexe en pleins de petits modules simples, on peut confier le développement à une personne (réelle ou virtuelle), il arrivera toujours à s'en sortir, et un arrivant qui ne connaît rien (comme un agent IA à chaque reset de contexte) arrivera toujours à comprendre ce que ça fait. Si on laisse le dév empiler des milliers de fonctionnalités sans prendre garde à les cloisonner, sûr on va dans le mur. On avait déjà le problème avec des équipes réelles. Je soupçonne que ceux qui retournent en arrière ont eu la bonne idée de pas du tout faire attention à l'architecture logicielle, et que c'est aussi ça qui les perd.
Car la programmation c'est ça : découper de gros problèmes immensément complexes en pleins de petits problèmes simples. Si le découpage est lui-même un assemblage complexe, il faut le réduire à des découpages simples. En fin de compte en fini avec des petites chaînes simples de petites choses simples, et là on s'en sort toujours, car on va se concentrer sur uniquement des problèmes simples.
L'IA aujourd'hui n'intègre pas bien ces notions d'architecture logicielle, je trouve.
L'IA super-développeur
Je disais pas ça il y a 2-3 ans mais là depuis cet été je le dis : les agents actuels sont des excellents développements capables de résoudre des problèmes de ouf. Exemple : hier j'ai fait programmer un algo de préparation de vide grenier : disposition optimisée de tables de différentes dimensions pour coller aux métrés réservés par les exposants, sachant qu'ils peuvent réservés des mètres sans table pour mettre leurs propres portants… super casse-tête qui prend des jours de boulot chaque année aux organisateurs. Quand j'étais jeune, j'ai développé des algos similaires (plan de préparations de commandes de 50 à 100 palettes) et j'y arrivais (3 semaines de boulot quand même pour le cas le plus compliqué que j'ai croisé), mais là ya 2 ans pour mon vide grenier j'avais pas réussi. Je me fais vieux, pis bon je suis pas payé pour alors j'ai pas 3 semaines à y consacrer, la motivation n'est pas la même quand c'est pas la démonstration de ta compétence qui est en jeu. Bref, j'avais pas insisté. L'IA avait donné une réponse de débutant là dessus il y a 2 ans, en me sortant un algo simpliste que t'apprendrais en deuxième année de fac en bases de la programmation. Tant pis.
J'ai re-tenté hier, et incroyable : j'avais un système qui marchait, qui tenait la route, en même pas 1h. Je parle pas des impressions de plans, de listes d'exposants, de planches d'étiquettes, faites en 5 minutes en lui donnant juste les modèles de ce qu'on sort comme docs d'habitude…
Donc, bon : ok, l'IA est un super développeur.
Mais l'architecture logicielle dans tout ça ?
Par contre je le fais bosser régulièrement sur mon framework https://it.rocks, qui se veut d'une architecture ultra-découpée : la séparation des responsabilités, la limitation des dépendanes réciproques, découper un gros problème en pleins de petits les plus indépendants possibles les uns des autres… non, ça les agents, avec tout le talent de ceux qui leur ont apprès à faire des dév de ouf, ils ne savent pas encore bien le faire. Ok il imite l'architecture que j'avais déjà largement développé (et dont l'implémentation n'est pas encore bien complète, j'ai encore pas tout bien cloisonné comme je voudrais au final), mais souvent se glissent des choses qu'on ne veut pas voir, des bouts de code qui vont dans un module alors qu'ils en concernent un autre, des données trop compliquées pour passer d'un module à l'autre, car elles n'ont pas de sens pour quelqu'un qui voudrait utiliser ces modules poru d'autres usages, avec des interfaçages différents…
Limite toutefois : super développeur dans le sens d'être capable de faire des trucs super compliqués et qui marchent. Mais avec une limite : en programmant super compliqué. Pour moi un vrai super développeur est capable de faire des trucs super compliqués, qui marchent, et qui en plus sont super concis, clairs dans l'organisation du code, maintenables. Ça c'est un boulot de monstre que l'IA ne fait pas, elle fait comme la plupart des dévs : à partir du moment où ça marche, on envoie. D'ailleurs on fait facilement pareil quand on la fait bosser : ça marche ? Ben envoyons. J'avoue.
Donc : l'IA n'est pas un bon architecte logiciel. Pas encore.
Et demain ?
Si l'on considère qu'il existe une définition du “bon architecte logiciel”, car là aussi la profession se cherche : on est passés par le MVC/N-tiers en l'an 2000 à l'isolation du domaine métier en 2010, puis la hype des micro-services en 2015, au cloud serverless en 2016, on revient à l'événementiel en 2020, maintenant on va à fond sur l'architecture hexagonale, les monolithes modulaires… Du ping pong entre découpage et rassemblement, on n'a toujours pas trouvé la recette magique, globalement plus c'est gros plus ça se casse la gueulle, on sait difficilement faire autre chose, alors l'IA ayant appris à notre école, ne sait rien faire d'autre nont plus.
Pas encore ? Et bien si elle intègre et applique mieux les bon vieux principes fondamentaux de l'architecture logicielle qui eux n'ont pas bougé depuis les années 70-80, peut-être qu'elle deviendra un bon architecture, meilleur même que la plupart des architectes logiciels humains si elle arrive à maîtriser de façon cohérente une proposition d'architecture initiale.
Aujourd'hui, c'est à nous de la guider, pour cette partie là. Car si on la laisse faire n'importe quoi, ben ça sera comme laisser un très bon développeur empiler des dévs très compliqués jusqu'à ne plus être capable de rien maîtriser. Et nous ben on fait partie de l'état de l'art actuel, qui pour moi se cherche encore dans ce domaine : la recette magique pour les gros projets propres, qui l'applique vraiment ? De très gros projets s'en sortent, mais qui est capable de rentrer dans le noyau Linux et d'y comprendre quelque chose, à moins d'être une pointure… ou un agent IA ?
Ha non, le patron de Clever Cloud l'a dit : l'IA sait tout dév, sauf les OS où on sait pas bien pourquoi elle est pas bonne du tout (les OS de switch réseau, dans leur cas, autrement dit on est sur une niche. Elle est peut-être meilleure avec un OS opensource de multiples fois déclinés comme Linux).