Je ne suis pas un ingénieur logiciel
(huronbikes.mataroa.blog)- Le rejet de l’identité d’ingénieur logiciel a commencé il y a 23 ans avec une remarque disant : « bon hacker, mais pas ingénieur »
- Le paradigme des agents donne l’impression de fabriquer des programmes qui devraient être déterministes à l’aide de programmes non déterministes
- La confiance dans le code repose sur la lisibilité, la compréhensibilité, l’efficacité, la possibilité de raisonner dessus et la reproductibilité qui donne la même sortie pour la même entrée
- Les agentic user flows au travail et les KPI d’usage de l’IA sont perçus comme une manière de privilégier les métriques et les entrées en langage naturel plutôt qu’un bon code
- La vision de l’avenir portée par l’industrie de l’IA semble aller au-delà du remplacement du développement logiciel pour tenter de bâtir un fossé défensif autour de la pensée elle-même
Ingénierie logicielle et paradigme des agents
- Le fait de s’exclure soi-même de l’identité d’ingénieur logiciel vient d’une expérience, il y a 23 ans, où un collègue a dit de l’auteur qu’il était un « bon hacker », mais pas un ingénieur
- Le récent « nouveau paradigme des agents » ressemble à une façon de demander à une machine comme Waylon Smithers de ne pas se tromper, puis d’habiller le résultat en ingénierie logicielle experte
- Une manière d’écrire, avec des programmes à sortie non déterministe, des programmes qui devraient être déterministes est présentée comme l’avenir de l’ingénierie logicielle
- Les convictions de base sur le code restent la lisibilité, la compréhensibilité, l’efficacité, une capacité de raisonnement suffisante et la reproductibilité consistant à produire la même sortie pour la même entrée
- Comme la reproductibilité est déjà difficile dans les systèmes réels, l’écriture du code elle-même ne devrait pas être bâtie sur des « sables mouvants »
- Des détails comme l’impact sur les performances des requêtes d’une vue composée de sous-requêtes corrélées et d’expressions d’agrégation, l’inversion de contrôle (Inversion of Control), ou une conception qui sépare les fonctionnalités des méthodes afin de les rendre testables indépendamment, restent importants
Méfiance envers les flux de développement centrés sur l’IA
- Les agentic user flows exigés au travail n’ont pas de sens clairement défini, et il est difficile de comprendre en quoi une zone de saisie en langage naturel serait meilleure qu’un choix parmi un petit ensemble d’options
- Il existe un mouvement visant à utiliser des agents à toutes les étapes du cycle de vie du développement logiciel, et certains disent qu’écrire du code à la main sera traité comme le fait d’utiliser COBOL
- Les agents ressemblent à des wrappers de prompts LLM qui évaluent des sorties selon le contexte, et les résultats concrets paraissent souvent insuffisants
- L’usage de l’IA est suivi comme KPI, mais pendant les 23 dernières années, écrire du bon code a toujours été plus important que les KPI
- Un ancien code de l’auteur a déjà été décrit comme « écrit par quelqu’un qui a fait des maths », et cela a été reçu comme un grand compliment
- L’implémentation d’un staff software engineer dans la même entreprise n’avait pas d’interface explicite, exposait un conteneur DI comme membre public static, et utilisait une configuration CSV non pas parce qu’elle convenait à des données tabulaires, mais parce qu’elle était « plus facile à utiliser pour les utilisateurs métier »
- Dire que cette implémentation était très mauvaise a causé des problèmes, et cet épisode a mené à la conclusion ironique que l’auteur n’était pas un ingénieur logiciel
- À deux reprises, des personnes jugées intelligentes ont conseillé d’accepter l’IA comme futur de l’écriture logicielle et du secteur, mais cette attitude semble imprudente
- Les logiciels d’IA essayés ont donné l’impression non pas d’aider le processus de pensée, mais de l’entraver ou de se l’approprier activement, et cette récupération inquiète
- Des dirigeants de grandes entreprises de l’IA parlent avec enthousiasme de l’avenir du secteur du développement logiciel, annoncent que leurs produits auront des devastating effects sur l’emploi, et utilisent l’expression « intelligence too cheap to meter »
- Si cet avenir est terrifiant, ce n’est pas parce que les machines transformeront tout le monde en trombones, mais parce qu’ils imaginent bâtir un fossé défensif autour de la pensée elle-même
1 commentaires
Avis sur Lobste.rs
Dans un livre de Mary Walton sur W. Edwards Deming, il y a cette anecdote : un ouvrier d’usine s’est retrouvé avec une machine en panne qui ne produisait plus que des pièces défectueuses ; il l’a signalé, mais comme la maintenance tardait, il a essayé de la réparer lui-même, jusqu’à ce qu’un superviseur arrive et lui dise de simplement la laisser tourner
Au final, on lui donnait donc l’ordre de « fabriquer des pièces défectueuses », et il a dit : « Où est ma fierté d’ouvrier là-dedans ? Ce serait mieux si le superviseur me respectait au moins autant que la machine. » Ce qu’il ne voulait pas, c’était fabriquer des pièces défectueuses et être payé pour ça
Ça vaut le coup de le lire ?
J’ai bien moins d’expérience que l’auteur, mais au début de ma carrière, j’ai essayé de faire sortir une partie des workflows de CSV à cause de ses nombreux problèmes, et on m’a répondu à l’époque que « pour les workflows métier, CSV est plus simple »
Sur le moment, comme l’auteur, j’ai trouvé cette réponse vraiment mauvaise, mais avec le temps j’en suis venu à penser qu’elle était plutôt juste
Si le fait qu’on ait dit il y a 23 ans que quelqu’un n’était pas un ingénieur logiciel te travaille encore, je pense que la solution est simplement de moins te soucier de l’opinion des autres
Si les politiques stupides de ton employeur ou le manque de sérieux de tes collègues te frustrent, tu peux aller chercher une autre entreprise. Il y a 8 milliards de personnes dans le monde, beaucoup veulent qu’un ordinateur fasse quelque chose pour elles, et parmi elles beaucoup paient pour de la programmation
Ça sonne comme : « Quand j’ai commencé à travailler dans une boulangerie, un collègue m’a dit que les croissants étaient un complot de Big Dairy pour vendre plus de beurre, alors j’en ai fait la base de ma vision du monde et j’en ai conclu que je ne pourrais plus jamais travailler dans une boulangerie. » Si l’auteur n’avait pas donné son âge, j’aurais cru lire un lycéen, mais s’il parle d’un événement d’il y a 23 ans, il a largement dépassé cet âge
L’idée du billet n’est pas que son auteur ne soit réellement pas ingénieur logiciel ; il a probablement travaillé longtemps sous ce titre. L’idée est plutôt que cette prise de distance vis-à-vis de ce titre est une réaction à l’évolution du secteur
C’est une façon de dire : « Ce n’est pas de l’ingénierie, c’est n’importe quoi. Si c’est ça, être ingénieur logiciel, alors je ne le suis pas. »
Personnellement, je comprends ce sentiment. Il m’est souvent arrivé de trouver que qualifier d’« ingénierie » ce que nous faisons en tant que développeurs logiciel relevait presque de l’insulte envers les autres disciplines d’ingénierie. Surtout parce qu’en l’appelant ainsi, nous ne semblons pas tant nous soucier que ça de ce que nous construisons réellement
Les ingénieurs civils prennent vraiment très au sérieux l’effondrement d’un pont, et quand une catastrophe majeure se produit, tout le secteur réagit, en tire des leçons et essaie d’éviter que cela se reproduise. À l’inverse, les soi-disant « ingénieurs » logiciel peuvent provoquer encore et encore des pannes en production pour des raisons entièrement évitables, puis le raconter sur leur CV comme si c’était une réussite
Vous pouvez probablement deviner ce que je pense de l’orientation actuelle du software engineering, à savoir la tendance à ne pas se soucier du code effectivement déployé et à en déléguer l’écriture à une autre « intelligence »
Je ne prétends pas comprendre parfaitement pourquoi cela arrive, ni avoir toutes les réponses sur ce qu’il faudrait faire. Mais il ne faut pas faire semblant que c’est un travail sérieux, c’est-à-dire de l’« ingénierie ».