Le code est une responsabilité (pas un actif). Les dirigeants technologiques ne comprennent pas cela. Ils pensent que l'IA est géniale parce qu'elle produit 10 000 fois plus de code qu'un programmeur, mais cela signifie simplement qu'elle produit 10 000 fois plus de responsabilités. 1/

Si vous souhaitez une version au format essai de ce fil de discussion à lire ou à partager, voici un lien vers celui-ci sur mon blog, sans surveillance, sans publicité et sans traqueur : 2/

L'IA est l'amiante que nous enfouissons dans les murs de notre société high-tech : Le code est une responsabilité. Les *capabilités* du code sont des atouts. 3/

L'objectif d'un atelier technologique est d'avoir un code dont les capacités génèrent plus de revenus que les coûts associés à son fonctionnement. 4/

Pendant longtemps, les entreprises ont entretenu une fausse croyance selon laquelle le coût d'exécution du code diminue avec le temps : après une période de rodage initiale durant laquelle les bugs du code sont identifiés et corrigés, le code ne nécessite plus de maintenance significative. 5/

Après tout, le code est une machine sans pièces mobiles - il ne s'use pas ; il ne s'épuise même pas. C'est la thèse du livre de Paul Mason de 2015 *Postcapitalisme*, un livre qui a remarquablement mal vieilli (bien que, peut-être, pas aussi mal que la crédibilité politique de Mason lui-même). 6/

Le code n'est pas une machine infiniment reproductible qui ne nécessite aucun travail. Au contraire, c'est une machine fragile qui nécessite des mesures de plus en plus héroïques pour la maintenir en bon état de fonctionnement, et qui finit par "s'user" (dans le sens d'avoir besoin d'une refonte complète). 7/

Pour comprendre pourquoi le code est une responsabilité, vous devez comprendre la différence entre "écrire du code" et "l'ingénierie logicielle." "Écrire du code" est un passe-temps incroyablement utile, amusant et captivant. 8/

Cela implique de décomposer des tâches complexes en étapes discrètes, si précisément décrites qu'un ordinateur peut les exécuter de manière fiable, optimisant les performances en trouvant des moyens astucieux de minimiser les exigences que le code impose aux ressources de l'ordinateur, telles que la RAM et les cycles du processeur. 9/

En attendant, "l'ingénierie logicielle" est une discipline qui englobe "l'écriture de code", mais avec un accent sur les opérations à long terme du *système* dont le code fait partie. 10/

L'ingénierie logicielle concerne les processus en amont qui génèrent les données que le système reçoit. Elle concerne les processus en aval auxquels le système émet des informations traitées. 11/

Il concerne les systèmes adjacents qui reçoivent des données des mêmes processus en amont et/ou émettent des données vers les mêmes processus en aval auxquels le système émet.

"Écrire du code" consiste à créer un code qui *fonctionne bien*. "Ingénierie logicielle" consiste à créer un code qui *échoue bien*. Il s'agit de créer un code qui est lisible - dont les fonctions peuvent être comprises par des tiers qui pourraient être amenés à le maintenir. 13/

Ces tiers pourraient être invités à adapter les processus en aval, en amont ou adjacents au système pour éviter que le système ne se casse. 14/

C'est ça le problème : tout code non trivial doit interagir avec le monde extérieur, et le monde extérieur n'est pas statique, il est *dynamique*. Le monde extérieur brise les hypothèses faites par les auteurs de logiciels *tout le temps* et chaque fois qu'il le fait, le logiciel doit être corrigé. 16/

Vous vous souvenez de Y2K ? C'était un jour où un code parfaitement fonctionnel, tournant sur un matériel parfaitement fonctionnel, cessait de fonctionner - non pas parce que le code avait changé, mais parce que *le temps avançait*. 17/

Nous sommes à 12 ans du problème Y2038, lorsque les versions 32 bits d'Unix cesseront toutes de fonctionner, car elles auront également épuisé les secondes calculables. 18/

L'existence de "le monde" est un facteur inéluctable qui use le logiciel et nécessite qu'il soit reconstruit, souvent à un coût énorme. Plus le code est en opération longtemps, plus il est probable qu'il rencontre "le monde." 20/

Prenez le code que les appareils utilisent pour signaler leur position physique. À l'origine, cela était utilisé pour des choses comme la facturation - déterminer quel réseau de transporteur ou de fournisseur vous utilisiez et si vous étiez en itinérance. 21/

Ensuite, nos appareils mobiles utilisaient ce code pour aider à déterminer votre position afin de vous donner des directions étape par étape dans les applications de navigation. Ensuite, ce code a été réutilisé pour nous aider à retrouver nos appareils perdus. 22/

Cela est devenu un moyen de localiser des appareils *volés*, un cas d'utilisation qui diverge fortement de la recherche d'appareils perdus. Lors de la localisation d'un appareil perdu, vous n'avez pas à faire face à la possibilité qu'un acteur malveillant ait désactivé la fonction "trouver mon appareil perdu". 23/

Ces cas d'utilisation supplémentaires - en amont, en aval et adjacents - ont révélé des bogues dans le code original qui n'avaient jamais émergé dans les applications précédentes. 24/

Par exemple, tous les services de localisation doivent avoir un certain type de comportement par défaut dans le cas (très courant) où ils ne sont pas vraiment sûrs de leur position. 25/

Peut-être qu'ils ont une solution générale - par exemple, ils savent à quelle antenne cellulaire ils sont connectés, ou ils savent où ils étaient la *dernière* fois qu'ils ont obtenu une localisation précise - ou peut-être qu'ils sont complètement perdus. 26/

Il s'avère que dans de nombreux cas, les applications de localisation traçaient un cercle autour de tous les endroits où elles *pouvaient* être, puis définissaient leur position au milieu de ce cercle. 27/

C'est bien si le cercle n'a que quelques pieds de diamètre, ou si l'application remplace rapidement cette approximation par un emplacement plus précis. Mais que se passe-t-il si l'emplacement s'étend sur des kilomètres et des kilomètres, et que la localisation *ne* s'améliore *jamais* ? 28/

Que se passerait-il si l'emplacement de n'importe quelle adresse IP sans emplacement défini était donné comme *le centre des États-Unis continentaux* et que toute application qui ne sait pas où elle se trouve rapporte qu'elle est dans une maison au Kansas ? 29/

Et dans ma ville de Burbank, où le service de partage de localisation de Google nous a un jour dit que notre fille de 11 ans (dont nous ne pouvions pas atteindre le téléphone) était à 12 miles, sur une rampe d'autoroute dans une zone non incorporée du comté de LA. 32/

(Elle était dans un parc à proximité, mais hors de portée, et l'application a estimé sa position comme le centre de la région où elle avait été localisée pour la dernière fois.) (Ce fut quelques heures difficiles.) 33/

Le code sous-jacent - le code qui utilise un certain défaut autrefois inoffensif pour falsifier des emplacements inconnus - doit être mis à jour *constamment*, car les processus en amont, en aval et adjacents qui y sont connectés changent *constamment*. 34/

Plus le code reste là, plus ses comportements originaux deviennent obsolètes, et plus les correctifs superposés deviennent baroques, encombrés et obscurcis. 35/

Le code n'est pas un actif - c'est un passif. Plus un système informatique fonctionne longtemps, plus il représente de la dette technique. Plus le système est important, plus il est difficile de l'arrêter et de le refaire complètement. 36/

Au lieu de cela, de nouvelles couches de code sont superposées, et là où les couches de code se rencontrent, il y a des fissures dans lesquelles ces systèmes se comportent d'une manière qui ne correspond pas exactement. 37/

Pire encore : lorsque deux entreprises sont fusionnées, leurs systèmes informatiques fissurés et défectueux sont amalgamés, de sorte qu'il existe désormais des sources *adjacentes* de dette technique, ainsi que des fissures en amont et en aval : 38/

C'est pourquoi les grandes entreprises sont si vulnérables aux attaques par ransomware - elles sont remplies de systèmes incompatibles qui ont été amenés à une imitation de compatibilité avec diverses formes de pâte à modeler numérique, de ficelle et de fil de fer. 39/

Ils ne sont pas étanches et ne peuvent pas être rendus étanches. Même s'ils ne sont pas abattus par des hackers, ils tombent parfois simplement et ne peuvent pas être remis debout. 40/

Vous vous souvenez quand les ordinateurs de Southwest Airlines ont planté pendant toute la semaine de Noël 2022, laissant des millions de voyageurs bloqués ? 41/

Les compagnies aériennes sont particulièrement mauvaises, car elles ont informatisé tôt et ne peuvent jamais éteindre les anciens ordinateurs pour les remplacer par de nouveaux. C'est pourquoi leurs applications sont si nulles. 42/

C'est pourquoi il est si terrible que les compagnies aériennes aient licencié leur personnel de service client et exigent que les passagers utilisent les applications pour *tout*, même si les applications ne fonctionnent pas. Ces applications ne fonctionneront jamais. 43/

La raison pour laquelle l'application de British Airways affiche "Une erreur inconnue s'est produite" 40 à 80 % du temps n'est pas (juste) qu'ils ont licencié tout leur personnel informatique et externalisé à des soumissionnaires à bas prix à l'étranger. 44/

C'est vrai, mais aussi que les premiers ordinateurs de BA fonctionnaient avec des vannes électromécaniques, et tout depuis doit être rétrocompatible avec un système qu'un des protégés d'Alan Turing a grignoté à partir d'une bûche entière avec ses propres dents. 45/

Le code est une responsabilité, pas un atout (la nouvelle application de BA a des années de retard). Le code est une responsabilité. Les serveurs des terminaux Bloomberg qui ont fait de Michael Bloomberg un milliardaire fonctionnent sur des puces RISC. 46/

Cela signifie qu'il est contraint d'utiliser un nombre décroissant de fournisseurs de matériel spécialisé et de centres de données, de payer des programmeurs spécialisés et de construire des chaînes de code fragiles pour connecter ces systèmes RISC à leurs équivalents moins exotiques dans le monde. Le code n'est pas un actif. 47/

L'IA peut écrire du code, mais l'IA ne peut pas faire d'ingénierie logicielle. L'ingénierie logicielle consiste à réfléchir au *contexte* - que viendra-t-il avant ce système ? Que viendra-t-il après ? Qu'est-ce qui sera à ses côtés ? Comment le monde va-t-il changer ? 48/

L'ingénierie logicielle nécessite une "fenêtre de contexte" très large, ce que l'IA n'a pas et ne peut pas avoir. La fenêtre de contexte de l'IA est étroite et superficielle. Les augmentations linéaires de la fenêtre de contexte de l'IA nécessitent des *expansions* géométriques des demandes computationnelles : 49/

Écrire du code qui fonctionne, sans tenir compte de la manière dont il échouera, est une recette pour la catastrophe. C'est une façon de créer une dette technique à grande échelle. C'est comme si on mettait de l'amiante dans les murs de notre société technologique. 50/

Les patrons *ne savent pas* que le code est un passif, pas un actif. C'est pourquoi ils ne cessent de parler des chatbots qui produisent 10 000 fois plus de code que n'importe quel programmeur humain. 51/

Ils pensent avoir trouvé une machine qui produit des *actifs* à 10 000 fois le rythme d'un programmeur humain. Ils ne l'ont pas fait. Ils ont trouvé une machine qui produit des *passifs* à 10 000 fois le rythme de n'importe quel programmeur humain. 52/

La maintenabilité n'est pas seulement une question d'expérience acquise vous enseignant où se trouvent les pièges. 53/

Cela nécessite également le développement du "Fingerspitzengefühl" - le "sentiment au bout des doigts" qui vous permet de faire des suppositions raisonnables sur les pièges qui pourraient émerger là où vous ne les avez jamais vus auparavant. 54/

C'est une forme de connaissance procédurale. C'est inéluctable. Ce n'est pas latent même dans le plus grand corpus de code que vous pourriez utiliser comme données d'entraînement : *Mon garçon*, les patrons de la tech ne comprennent vraiment pas cela. 55/

Prenons Microsoft. Leur gros pari en ce moment est sur "l'IA agentique." Ils veulent installer un logiciel espion sur votre ordinateur qui capture chaque frappe, chaque communication, chaque écran que vous voyez et l'envoie au cloud de Microsoft, tout en donnant accès à une ménagerie de chatbots.

Ils prétendent que vous pourrez dire à votre ordinateur : "Réserve-moi un train pour Cardiff et trouve cet hôtel que Cory a mentionné l'année dernière et réserve-moi une chambre là-bas" et il le fera. C'est une idée incroyablement irréalisable. 57/

Aucun chatbot n'est capable de faire toutes ces choses, ce que Microsoft stipule librement. Plutôt que de faire cela avec un seul chatbot, Microsoft propose de le décomposer entre des dizaines de chatbots, chacun desquels Microsoft espère atteindre une fiabilité de 95%. 58/

C'est une norme de chatbot totalement implausible en soi, mais considérez ceci : les probabilités sont *multiplicatives*. Un système contenant deux processus qui fonctionnent avec une fiabilité de 95 % a une fiabilité nette de 90,25 % (0,95 * 0,95). 59/

Divisez une tâche entre une couple de douzaines de bots à 95 % de précision et la chance que cette tâche soit accomplie correctement se rapproche de *zéro*. 60/

Pendant ce temps, un cadre de Microsoft a eu des problèmes en décembre dernier lorsqu'il a publié sur Linkedin annonçant son intention de faire réécrire *tout* le code de Microsoft par l'IA. 63/

Refactoriser la base de code de Microsoft a beaucoup de sens. Microsoft - comme British Airways et d'autres entreprises anciennes - a beaucoup de code très ancien qui représente une dette technique insoutenable. 64/

Certains d'entre vous *sont* des ingénieurs logiciels qui ont trouvé les chatbots incroyablement utiles pour écrire du code pour vous. C'est un paradoxe courant de l'IA : pourquoi certaines personnes qui utilisent l'IA la trouvent-elles vraiment utile, tandis que d'autres la détestent ? 66/

Est-ce que les personnes qui n'aiment pas l'IA sont "mauvaises en IA" ? Est-ce que les fans de l'IA sont paresseux et ne se soucient pas de la qualité de leur travail ? 67/

Il y a sans aucun doute un peu des deux en jeu, mais même si vous enseignez à tout le monde à devenir un expert en IA, et que vous excluez tous ceux qui ne sont pas fiers de leur travail de l'échantillon, le paradoxe restera toujours. 68/

La véritable solution au paradoxe de l'IA réside dans la théorie de l'automatisation, et le concept de "centaures" et "centaures inversés" : 69/

Dans la théorie de l'automatisation, un "centaure" est une personne assistée par une machine. Un "centaure inversé" est quelqu'un qui a été conscrit pour *assister une machine*. 70/

Dites que vous êtes un ingénieur logiciel qui utilise l'IA pour écrire du code de routine que vous avez le temps et l'expérience de valider, déployant votre Fingerspitzengefühl et vos connaissances des processus pour garantir qu'il est adapté à son objectif. 71/

Il est facile de voir pourquoi vous pourriez trouver l'utilisation de l'IA (quand vous choisissez de le faire, de la manière que vous choisissez, à un rythme que vous choisissez) utile. Mais disons que vous êtes un ingénieur logiciel qui a reçu l'ordre de produire du code à 10x, 100x ou 10 000x votre taux précédent. 72/

Dites que la seule façon de le faire est via l'IA, et qu'il n'y a aucun moyen humain de pouvoir examiner ce code et de s'assurer qu'il ne se brisera pas au premier contact avec le monde, vous allez le détester : 73/

(Vous le détesterez encore plus si vous avez été transformé en le bouc émissaire de l'IA, personnellement responsable des erreurs de l'IA.) Il existe une autre manière dont les ingénieurs logiciels trouvent le code généré par l'IA incroyablement utile : lorsque ce code est *isolé*. 74/

Si vous réalisez un projet unique - disons, convertir un lot de fichiers dans un autre format, juste une fois - vous n'avez pas à vous soucier des processus en aval, en amont ou adjacents. Il n'y en a pas. 75/

Vous écrivez du code pour faire quelque chose une fois, sans interagir avec d'autres systèmes. Une *grande* partie du codage est ce type de projet utilitaire. C'est fastidieux, ingrat et propice à l'automatisation. 76/

Beaucoup de projets personnels entrent dans cette catégorie, et bien sûr, par définition, un projet personnel est un projet centaure. Personne ne vous oblige à utiliser l'IA dans un projet personnel - c'est toujours votre choix comment et quand vous faites un usage personnel de n'importe quel outil. 77/

Mais le fait que les ingénieurs logiciels puissent parfois améliorer leur travail avec l'IA n'invalide pas le fait que le code est un passif, pas un actif, et que le code IA représente une production de passifs à grande échelle. 78/

Dans l'histoire du chômage technologique, il y a l'idée que la nouvelle technologie crée de nouveaux emplois même si elle rend les anciens obsolètes : pour chaque forgeron mis au chômage par l'automobile, il y a un emploi qui attend en tant que mécanicien. 79/

Depuis le début de l'inflation de la bulle de l'IA, nous avons entendu de nombreuses versions de cela : l'IA créerait des emplois pour des "ingénieurs de prompt" - ou même créerait des emplois que nous ne pouvons pas imaginer, car ils n'existeront pas tant que l'IA n'aura pas changé le monde au-delà de toute reconnaissance. 80/

Je ne miserais pas sur le fait d'obtenir un emploi dans un métier fantaisiste qui ne peut littéralement pas être imaginé parce que nos consciences n'ont pas encore été modifiées par l'IA au point d'acquérir la capacité de conceptualiser ces nouveaux modes de travail. 81/

Mais si vous *cherchez* un emploi que l'IA va définitivement créer, par millions, j'ai une suggestion : le retrait d'amiante numérique. 82/

Le code AI - écrit à 10 000 fois la vitesse de n'importe quel codeur humain, conçu pour bien fonctionner, mais pas pour échouer gracieusement - est l'amiante numérique que nous remplissons dans nos murs. Nos descendants passeront des générations à déterrer cet amiante des murs. 83/

Il y aura beaucoup de travail pour réparer les choses que nous avons cassées grâce à la psychose AI la plus dangereuse de toutes - la croyance hallucinatoire que "écrire du code" est la même chose que "l'ingénierie logicielle." 84/

À ce rythme, nous aurons un plein emploi pour des générations de désamianteurs. 85/