Carnet de notes

Catégorie : IA

  • Un petit programme par l’IA

    J’avance sur mes outils de sauve­garde mais aussi sur mes explo­ra­tions IA.

    J’ai eu besoin d’un second programme qui va lire tous les emails d’une boite au format mail­dir, regar­der l’an­née du mail, et le dépla­cer dans une boite mail­dir spéci­fique à cette année là.

    J’au­rais pu le faire en Javas­cript ou en Ruby mais vu ce que m’a fait l’IA en quelques minutes précé­dem­ment, je me suis dit que j’al­lais conti­nuer et refaire un script Go (je n’ai jamais codé une seule ligne de Go).

    Voici le résul­tat : github.com/edas/split-mail­dir-by-year.

    Les 300 lignes de Go ont analysé l’in­té­gra­lité de mon archive Gmail (537 000 emails quand même).

    • Je ne crois pas avoir touché le code source à la main
    • Le code a toujours compilé du premier coup
    • Le code a toujours fait ce que je souhai­tais, sans erreur

    Le code est correc­te­ment struc­turé, des fonc­tions ont été créées au fur et à mesure des besoins quand le code a évolué. Quand une fonc­tion est un peu longue, il sépare en blocs et ajoute une ligne de commen­taire pour dire ce que fait le bloc, ce qui me permet de ne pas avoir à déco­der un code dans un langage que je ne connais pas.

    10 demandes courtes pour avoir le programme et le faire évoluer vers mes besoins, ques­tions de relec­ture incluses. 17 ajouts par la suite pour trai­ter des cas spéci­fiques rencon­trés.

    Je n’au­rais pas fait plus vite moi-même, ni en Go ni dans un langage que je connais très bien. Peut-être que ça aurait été un peu plus diffi­cile pour un non-déve­lop­peur, mais je vois mal ce que j’au­rais eu à y gagner à le coder à la main.

    À chaque modi­fi­ca­tion j’ai le diff à vali­der mais aussi une bonne expli­ca­tion de l’IA sur ce qui a été modi­fié, comment et pourquoi. Ma relec­ture s’est souvent faite en diago­nale sur la base des commen­taires de code. L’IA a su répondre à mes ques­tions quand j’ai rencon­tré des éléments moins évide

    Plutôt que lister les étapes, je copie direc­te­ment mes prompts.

    I have hundreds thousands of files in the "maildir/new" directory. Each file contains a raw email with headers.

    I want a program which reads all emails one by one, look for the "Date" header, return an error in the header doesn't exists or is unreadable, and otherwise move the email file in the directory "by-year/{year}/new" where {year} is the year in the Date header.

    Je relis parce que ça va toucher des données réelles et que j’ai la flemme de faire des données de tests.

    Je vois qu’il retourne toujours une date même quand il y a une erreur. Inha­bi­tué de Go, j’ai peur de certaines erreurs de débu­tants en PHP ou en JS, où on utilise une date du jour plutôt que gérer l’er­reur. Je pose ma ques­tion et je suis rassuré par sa réponse (que je trouve logique après coup vu le fonc­tion­ne­ment des erreurs en Go)

    can the parseEmailDate return nil when it doesn't find a Date header ?

    Je vois aussi un mkdir sans test d’exis­tence préa­lable. Dans d’autres langages ça jette une erreur si le réper­toire existe. Je pose la ques­tion et là aussi je suis rassuré par sa réponse.

    what if the directory already exists line 63 ?

    Je demande une adap­ta­tion, non stric­te­ment néces­saire, pour que chaque réper­toire soit bien une boite mail­dir avec les 3 réper­toires obli­ga­toires. Ce n’est pas néces­saire à ma sauve­garde mais je préfère, au cas où ça m’évite des erreurs un jour.

    Oui, j’ai parfois basculé en français. Je ne sais ni pourquoi j’ai du français ici, ni pourquoi j’ai mis de l’an­glais avant. L’IA est confi­gu­rée pour toujours me répondre en français. Le code est toujours commenté en anglais. Je pense que propres entrées dépendent ce sur quoi mon atten­tion était à ce moment là (code, page web, etc.)

    Si le répertoire "by-year/{year}" n'existe pas, il faut aussi créer "by-year/{year}/cur" et "by-year/{year}/tmp", même si nous ne nous en servons pas

    Seconde adap­ta­tion : L’IA m’a dit plus haut qu’elle avait un code de gestion de conflit. Je vois le commen­taire dans le code qui dit qu’en cas de conflit le code ajoute un suffixe avec le times­tamp du moment pour éviter d’écra­ser un fichier exis­tant. Norma­le­ment ça ne devrait jamais arri­ver mais un suffixe risque­rait de casser le format de nommage des fichiers mail­dir donc je préfère qu’on s’ar­rête avec une erreur et que j’avise.

    if there is a conflict, to not append a timestamp to make it unique. Return an error.

    Troi­sième adap­ta­tion. Je traite un demi-million de fichiers. Je préfère que ça traite les fichiers au fil de l’eau plutôt qu’a­voir la liste d’un demi-million de fichiers en mémoire.

    Au départ c’est d’abord une ques­tion. Je ne sais pas si Go retourne un tableau ou un itéra­teur (oui, j’ai été flem­mard jusqu’à ne même pas faire atten­tion au typage). Je m’at­ten­dais à deman­der la correc­tion dans le premier cas. Au final il modi­fie de lui-même le code à partir de la seconde ques­tion pour faire des itéra­tions par lots 100 fichiers, sans que je ne le demande expli­ci­te­ment.

    En réalité c’est du script maison, qui sera lancé juste une poignée de fois. L’op­ti­mi­sa­tion est tota­le­ment inutile mais je n’ai pas encore appris à tota­le­ment lâcher prise vis-a-vis de ce que j’au­rais codé moi-même.

    What does return ReadDir in line 88 ?
    Si le répertoire contient des millions de fichiers, est-ce que la variable files ligne 88 va tout avoir en mémoire ?

    Je vais jouer avec de vraies données. Je veux voir les erreurs et m’ar­rê­ter pour corri­ger, pas que ça conti­nue et que j’ai à remon­ter voir s’il y a eu des erreurs.

    The programm should stop at the first error, not continue with the next file

    Et, parce que je n’y avais pas pensé avant : 

    Le programme doit aussi prendre un chemin en argument. C'est là que se trouveront les différents répertoires prévus.

    La première phase est faite. Je passe au test en condi­tions réelles, sur le demi-million d’email de mon archive. Chaque fois que j’ai une erreur, je lui indique et j’avance.

    C’est là que je vois que chaque client email fait bien ce qu’il veut avec les entêtes. J’ai croisé un nombre inat­tendu de formats diffé­rents et d’er­reurs dans les entêtes. Chaque fois le programme m’af­fiche l’er­reur, je copie-colle la date problé­ma­tique, l’IA corrige, et je relance jusqu’à l’er­reur suivante.

    We should also parse the format for "Mon, 21 Aug 2006 16:47:08 +0200 (CEST)"
    We should also parse the date "Mon, 1 Dec 2008 10:57:10 UT"

    Sur une erreur étrange, j’ouvre l’email et je me rends compte qu’il prend en compte la conti­nua­tion d’une entête Recei­ved comme si c’était une date, parce qu’il ne prend pas en compte les espaces avant le mot clé Date.

    TrimSpave at line 30 should only trim right space, not left space

    Parti­cu­la­rité Gmail, quand il récu­père un email d’une boite tierce (via POP3 ou IMAP), il crée des entêtes à lui, saute une ligne et après pose le vrai email. Rétros­pec­ti­ve­ment je pense que j’au­rais dû reti­rer la section ajou­tée par Gmail pour retrou­ver un email normal. Je le ferais peut-être plus tard. Là je me suis contenté de lui faire contour­ner le problème.

    When we find the header "X-Gmail-fetch-Info", we should ignore the blank line following if it exists

    Encore des ques­tions de dates…

    We should be able to parse the Date "Tuesday 29 May 2007, 16:03"
    We should also parse "Wed, 03 Mar 2010 22:36:13 +0100 CET"
    We should also parse "Thu, 22 Jul 2010 23:02:50"
    We should also parse "Mon, 30 Mar 2009 20:11:22 +0100"

    Ce coup-ci ça ne corrige pas mon problème. Rétros­pec­ti­ve­ment j’au­rais pu le comprendre parce que le message d’er­reur n’était pas exac­te­ment le même, mais je le laisse trou­ver seul. Le mot clé DATE était en majus­cules, c’était la première fois.

    pourtant le script fait une erreur sur la ligne "DATE: Mon, 30 Mar 2009 20:11:22 +0100". Pourquoi ?

    Le code qu’il me génère imbrique quatre fonc­tions de mani­pu­la­tion de texte sur une seule ligne. Je ne trouve pas ça lisible. Je pose la ques­tion.

    que fait la ligne 49 ?

    Ça semble redon­dant avec la ligne suivante, pré-exis­tante. Effec­ti­ve­ment, quand je pose la ques­tion il iden­ti­fie le doublon et le supprime.

    Il faut penser à relire (même si l’er­reur aurait juste était du code inutile). Cursor me fait vali­der chaque chan­ge­ment sous forme de diff donc c’est assez rapide et facile à faire.

    que fait la ligne 50 ?

    Encore des formats de date…

    Encore un format : "mon, 10 jul 2006 01:02:08 gmt"
    encore un : "wed, 23 jun 2004 01:19:32 cest"
    encore un "mon, 22 mar 2010 14:20:15 +0100 +0100". C'est probablement une erreur d'écriture mais il faut la prendre en compte
    "wen, 16 jul 2008 22:09:05 +0200"

    Les deux derniers cas sont forcé­ment des erreurs de la part de clients emails. Pour la première erreur il choi­sit d’igno­rer toutes les répé­ti­tions du déca­lage horaire.

    La seconde erreur est inté­res­sante parce que « wen » est proba­ble­ment là pour « wed » (wednes­day). Il iden­ti­fie l’er­reur et ajoute un code qui remplace toute une liste d’er­reurs de frappes habi­tuelles pour les code courts de jour de la semaine. Parfait.

    "wed, 19 apr 2006 12:15 -0800"

    J’ai mon premier cas d’email sans entête « Date ». Je ne sais pas si c’est auto­risé ou non mais peu importe. Je lui dis de fouiller les entêtes « Recei­ved » à la place. Je sais que ces entêtes peuvent être sur plusieurs lignes.

    L’IA va plus loin que moi, sait que la date est en seconde posi­tion dans ces entêtes, et regarde unique­ment après le premier point virgule. Elle sais aussi comment s’ap­pellent ses entêtes sur plusieurs lignes (lignes de conti­nua­tion). Mieux que ce que j’au­rais fait.

    Je note que je tape vite, avec des erreurs de frappe, un guille­met en trop, etc. Peu importe, c’est destiné à l’IA. Me relire est super­flu : je peux reve­nir en arrière si c’est mal compris.

    If you don't find any Date header, try again to look if you can find a date somewhere in a "Received" header (theere may be multiple "Received" headers") or in the lines begining with a space and following a "Received" header

  • Fin ou trans­for­ma­tion d’un métier

    BD tirée de CommitStrip. Première case: le chef/commercial parle avec l'ingénieur informaticien. Case 1 : le commercial vient voir l'informaticien, un mug à la main. L'informaticien est sur son PC, un mug à côté aussi. Commercial : un jour on n'aura plus besoin de codeur. On aura juste à définir des spécifications et ça générera automatiquement une application. Case 2 : le commercial est en train de boire dans son mug. Infoteux, devant son PC et un mug de café : T'as raison, il suffira simplement d'écrire des spécifications complètes et précises et pouf, plus besoin de codeur ! Commercial, l'air satisfait : c'est ça ! Case 3. Infoteux : Et tu sais comment on appelle des spécifications suffisamment complètes et précises pour qu'un programme puisse générer une application ? Commercial, dubitatif : Euh... Non ? Case 4. Informaticien, l'air blasé, pointant son clavier : Du code. On appelle ça du code. Le commercial est tellement surpris qu'il penche son mug par inadvertance et renverse un peu le breuvage sacré. (le alt n'est pas de moi et à été honteusement repompé)
    « Il suffira d’écrire des spéci­fi­ca­tions complètes et précises »

    Je revois cette planche de BD dans une conver­sa­tion et je trouve qu’elle passe à côté d’un élément fonda­men­tal : On ne trans­met pas juste­ment pas de spéci­fi­ca­tions complètes et précises au déve­lop­peur.

    Complé­ter, préci­ser

    Une grosse partie du boulot de déve­lop­peur c’est complé­ter et préci­ser ces spéci­fi­ca­tions incom­plètes et impré­cises.

    Complé­ter, préci­ser, le tout à partir du contexte projet, des habi­tudes et de l’im­pli­cite courant… C’est le cas d’usage exact des LLM.

    On essaie de leur faire faire « de l’IA » mais ces outils sont en premier lieu de formi­dables outils de complé­tion à partir d’un contexte et de l’im­pli­cite habi­tuel pour un type de tâche donnés. Bref, le travail d’un déve­lop­peur.

    Refor­mu­ler dans un langage plus formel

    Que fait le déve­lop­peur d’autre ? Il traduit ça dans un langage formel (le code).

    Refor­mu­la­tion, ça aussi c’est le cas d’usage parfait pour les LLM.

    La dernière tâche du déve­lop­peur est très tech­nique. C’est de l’in­gé­nie­rie logi­cielle, réus­sir à tout agen­cer pour que ce soit faci­le­ment testable, main­te­nable, évolu­tif, etc.

    Une grosse part de cette dernière tâche est basée sur l’ap­pren­tis­sage et la repro­duc­tion de motifs ou de pratiques. Le LLM est aussi parfait pour ça.

    Il reste aussi qu’il s’agit de rendre les choses testables, main­te­nables et évolu­ti­ves… par des humains. Peut être qu’une partie de ce besoin va dispa­raître ou du moins évoluer le jour où le code sera plus mani­pulé par des LLM que par des humains. Leurs besoins, faci­li­tés et diffi­cul­tés sont forcé­ment diffé­rents des nôtres.

    Appren­tis­sage

    Oui il faudra faire des aller-retours avec l’ou­til pour complé­ter ou corri­ger sa complé­tion. Il en va de même du déve­lop­peur, surtout lors de sa première arri­vée dans une équipe ou dans un projet.

    Oui un LLM fera des erreurs d’in­ter­pré­ta­tion. Un déve­lop­peur aussi.

    Est-ce que les allers-retours et erreurs seront plus impor­tants que ceux avec un déve­lop­peur ? Aujourd’­hui proba­ble­ment, demain je n’en sais rien, peut-être.

    Est-ce que ces allers-retours et correc­tions seront plus coûteux qu’un déve­lop­peur ? Alors là je n’en sais rien, mais je ne parie­rai pas dessus.

    Besoin d’ex­per­tise

    Est-ce qu’on aura toujours besoin d’un déve­lop­peur et d’ex­per­tise pour accom­pa­gner l’ou­til auto­ma­tique ? Très proba­ble­ment sur une partie, oui, mais proba­ble­ment moins en propor­tion qu’on n’en a besoin aujourd’­hui.

    Très certai­ne­ment aussi que le travail sera diffé­rent de celui d’aujourd’­hui, et que savoir inter­agir avec les outils auto­ma­tiques sera essen­tiel dans les compé­tences requises. C’est déjà partiel­le­ment le cas aujourd’­hui. On ne code pas comme au temps des cartes perfo­rées. C’est juste que les outils vont chan­ger et vont très proba­ble­ment prendre une plus grande place.

    Certi­tudes

    Je ne donne que mes certi­tudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le senti­ment, sans aucune tech­no­béa­ti­tude, qu’il est en train d’ar­ri­ver.

    On fait faire, dire ou espé­rer plein de choses quand on parle d’IA. Il ne s’agit pas de voiture volantes et autres IA sentientes ici.

    Ici je parle LLM, complé­tion et refor­mu­la­tion de textes. Je peux me trom­per et je ne mets ma main au feu à propos de rien, mais je me base sur des capa­ci­tés qui sont déjà là aujourd’­hui.

    Juger le futur

    Est-ce souhai­table socia­le­ment ? Est-ce soute­nable pour la planète ? Comment va-t-on gérer la tran­si­tion au niveau de la société ?

    Ce sont honnê­te­ment d’ex­cel­lentes ques­tions dont j’ai­me­rais avoir les réponses.

    Le fond n’est pas si je souhaite ou pas ce futur, c’est que je constate qu’il est en train d’ar­ri­ver, et que je veux pas faire semblant de l’igno­rer.

    Pour les futurs déve­lop­peurs

    Je crains une vraie crise dans le métier dans quelques années. Certains, beau­coup, vont rester sur le carreau.

    Je ne sais pas si j’en­cou­rage les plus jeunes à se lancer dans le déve­lop­pe­ment infor­ma­tique. Si vous le faites, je vous encou­rage à à la fois deve­nir très vite expert (parce que j’ima­gine qu’on aura besoin des experts pour complé­ter les LLM), et apprendre à coder via les LLM (pas juste « avec ») même si ce n’est pas rentable aujourd’­hui.

    Je suis conscient de la contra­dic­tion à deman­der aux juniors de deve­nir immé­dia­te­ment expert.

    Je ne suis pas certain qu’il y ait un avenir pour les déve­lop­peurs moyens, ou pour les junior. Leur valeur ajou­tée sera faible et il y aura dans un premier temps suffi­sam­ment de déve­lop­peurs formés pour jouer les experts sans devoir inves­tir des années dans des compé­tences inter­mé­diaires qui pour­raient deve­nir experts un jour.

    Pour choi­sir son futur

    Si vous êtes très tech, faites des maths, de la mani­pu­la­tion de données, des statis­tiques, et globa­le­ment de l’IA. Les places seront peut être chères et deman­de­ront des compé­tences plus avan­cées que pour être déve­lop­peur, mais il y aura du travail.

    Si vous avez envie de créer, pour moi l’ave­nir est plus dans les métiers du produit, des product mana­ger avec une colo­ra­tion et un inté­rêt tech­nique. Ça veut dire savoir parler busi­ness, marché, client, etc.

    Pour les déve­lop­peurs actuels

    Pour ceux qui sont encore majo­ri­tai­re­ment les mains dans le code, je vous conseille de passer au plus tôt dans le déve­lop­pe­ment via les LLM.

    Je sais que vous n’en ressen­tez pas le besoin, que ces outils font des erreurs que vous ne faites pas, que ça ne vous accé­lère pas aujourd’­hui.

    Le fond c’est que les plus jeunes ça les accé­lère, que demain ils auront déve­loppé leur exper­tise mais sauront aussi utili­ser ces outils, et qu’ils en compren­dront assez les limites et les défauts pour être l’ex­pert dont le métier aura besoin.

    Il y aura encore long­temps de la place pour des vieux experts du code pour la main­te­nance et pour les gros groupes qui ont plusieurs géné­ra­tions de retard. Il y a aujourd’­hui toujours besoin de déve­lop­peurs et Cobol. La vraie ques­tion : Est-ce le posi­tion­ne­ment auquel vous aspi­rez ?

    Et moi, direc­teur tech­nique ?

    Honnê­te­ment je ne sais pas. Je ne sais pas bien quel sera mon avenir.

    Le mana­ge­ment de grandes équipes de déve­lop­pe­ment risque d’être aussi has been demain que les vieux DSI dépas­sés d’aujourd’­hui. Est-ce que je veux être de ceux là ? Je ne sais pas.

    J’ado­re­rais prendre la tête d’équipes de data science, mais j’ima­gine qu’il y a une batte­rie de docteurs sur les rangs, avec une exper­tise qui me ferait défaut.

    Entre temps je vais proba­ble­ment au moins essayer d’in­té­grer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.

  • [Lecture] Custo­mers don’t care about your AI feature

    Rather than enhan­cing percep­tions, the term “gene­ra­tive AI” signi­fi­cantly lowe­red expec­ta­tions of a product’s poten­tial impact

    grow­thun­hin­ged.com

    Peu surpre­nant mais c’est bien d’avoir un peu de chiffres.

    Tout le monde se met à vouloir injec­ter de l’IA par prin­cipe et s’en vanter, y compris là où ça induit plutôt une perte de valeur pour l’uti­li­sa­teur (typique­ment pour de l’in­te­rac­tion avec les équipes support).

    Si je suis étonné, c’est plutôt que l’ef­fet ne soit pas beau­coup plus néga­tif.

  • IA : L’élé­phant dans le couloir

    Je me vois mal commen­cer à plon­ger dans l’IA1 en igno­rant toute la ques­tion éner­gé­tique. Je commence ce billet pour essayer d’y voir clair.

    C’est un brouillon partagé où je vais poser des notes au fur et à mesure des lectures, pas une conclu­sion.

    On a tous nos biais, moi aussi. Quelques posi­tions de départ :

    1. J’ai un gros biais néga­tif à la base. J’ai vu passer les délires de la réalité virtuelle, des seconds mondes, du web3 et autres crypto-actifs. Je m’en suis tenu aussi éloi­gné que possible, j’en suis bien heureux et je ne souhaite vrai­ment pas entrer dans un gros hype alors que j’ai réussi à éviter les précé­dents. Le fait qu’une partie des suppor­ters de l’IA étaient suppor­ter du web3 n’est pas trop en faveur des ques­tions d’IA.
    2. Le second gros biais néga­tif vient de mes commu­nau­tés et lectures. Je navigue dans des sphères très concer­nées par les enjeux clima­tiques, qui font les efforts asso­ciées, et qui sont dans l’en­semble extrê­me­ment critiques vis-a-vis de l’IA, pour ne pas dire en total rejet. Ça ne me lie pas, mais c’est une posi­tion de départ et il est toujours diffi­cile de sortir tota­le­ment de ses préju­gés. Ici ça me sera d’au­tant plus diffi­cile que ça voudra dire tenir une posi­tion oppo­sée aux personnes qui m’en­tourent.
    3. À l’op­posé, je vois les trans­for­ma­tions à venir dans mon métier et cette fois-ci, j’y crois. J’ai à la fois envie d’être dans le train, et peur pour mon avenir si je décide de ne pas monter pour des raisons morales. Ça joue, et il va falloir que je fasse atten­tion à ce que ça ne me fasse pas cher­cher des prétextes ou des excuses.
    4. Enfin, j’ai aussi vécu les propos inco­hé­rents sur les enjeux clima­tiques, avec la chasse aux emails à effa­cer ou des préco­ni­sa­tions qui oublient tota­le­ment les ordres de gran­deurs. Parfois on désigne l’en­nemi à abattre et quand les chiffres ne tiennent pas on fini par « tout compte », ce qui est à la fois vrai et à la fois parfois juste un prétexte pour justi­fier une mauvaise posi­tion.

    Pour expli­ci­ter le dernier point, je me refuse à juste regar­der la consom­ma­tion éner­gé­tique en absolu. Il faut tout réduire mais pas tout suppri­mer. L’enjeu c’est de savoir où et comment couper.

    illustration d'un graphique en deux axes, sobriété énergétique et utilité. L'intérieur est coloré du vert (sobre et utile) marqué "à garder" jusqu'au rouge (pas sobre, pas utile) marqué "à jeter"

    Pour l’ins­tant je vais déjà collec­ter les liens qu’on me fait suivre (en vrac dans un premier temps) :

    1. C’est amusant, je vois que j’uti­lise IA quand je donne un ton posi­tif et LLM quand je donne un ton néga­tif, quand bien même dans ces contextes je parle fina­le­ment de la même chose. Je vais garder IA ici mais c’est un sujet de réflexion. ↩︎

  • Partage d’Elea­nor Morton « Lite­rally every company now »

  • Lecture de Steve Yegge : « The Death of the Stub­born Deve­lo­per »

    De  « The Death of the Stub­born Deve­lo­per »

    Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level inter­ior tasks, even on large soft­ware projects. Which is great. But what’s left over for humans is prima­rily the more diffi­cult plan­ning and coor­di­na­tion nodes. Which are not the kind of task that you typi­cally give junior deve­lo­pers.

    C’est peut être là que je diverge. C’est vrai pour les déve­lop­peurs « code », un peu moins pour les déve­lop­peurs « produit ».

    Howe­ver, some junior engi­neers pick this new stuff up and fly with it, basi­cally uple­ve­ling them­selves. And many senior engi­neers seem to be heading towards being left behind. So what is it, then?

    (…)

    Chat-Orien­ted Program­ming, CHOP for short (or just chop). Chop isn’t just the future, it’s the present. And if you’re not using it, you’re star­ting to fall behind the ones who are.

    Ne croyez pas qu’on a à faire à encore un rêveur qui imagine un futur avec des voitures volantes. On parle du présent.

    They believe these gene­ric auto­no­mous soft­ware agents will solve the problem of chop being too diffi­cult and toil­some. In fact some people claim that agents can take over the task graph enti­rely, perhaps at least for small busi­nesses, allo­wing non-tech­ni­cal CEOs to launch apps them­selves without having to hire any pesky deve­lo­pers.

    I think those people are smoking some serious crack.

  • Lecture de Steve Yegge :  « The Death of the Junior Deve­lo­per »

    De  « The Death of the Junior Deve­lo­per »

    Gene, as an accom­pli­shed and senior author, is deligh­ted with his produc­ti­vity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just fini­shed, in which he had spent easily 45+ minutes craf­ting the prompt, refi­ning it until he had a 7500-word narra­tive that could serve as a star­ting point for rewri­ting, editing, and adjust­ment. (In compa­ri­son, this blog post is about half that size.) And that draft was fantas­tic. I’ve read it and it’s glorious.

    On a good day, Gene can write 1,000 words per day. His esti­mate is that Claude did for him in 90 minutes what would normally have taken him ten days. It solves the « blank-page problem » and gets him to the 20-yard line, where the fun begins.

    Il y a d’autres histoires. Je note un motif que ceux qui répondent « qualité » ne semblent pas voir.

    L’IA est un outil. On ne lui demande pas force­ment de savoir tout faire, ni même de le faire bien. On lui demande de savoir faire assez pour amener le donneur d’ordre plus loin, ou plus vite, et majo­ri­tai­re­ment de lui permettre de se concen­trer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écri­ture.

    My senior colleagues have recently recoun­ted simi­lar chat scena­rios in which a more junior dev would have been comple­tely taken in, poten­tially losing days to weeks of work going the wrong direc­tion.

    Or worse.

    Chat, it seems, is safer for senior program­mers than it is for junior ones. And a lot of compa­nies are going to inter­pret « safer » to mean « better. »

    (…)

    Brie­fly, what do I mean by « senior » here? Really just two things:

    –  You know what you want before the AI writes it. You already have a vision for how you would write this by hand, or have it narro­wed to a few reaso­nable options.
    –    You can detect when it is giving you bad guidance.

    J’ajou­te­rais : savoir utili­ser l’ou­til. Ça reste un outil. Comprendre ses limites, sa zone d’ef­fi­ca­cité et comment en obte­nir le meilleur peut faire la diffé­rence.

    Rien que : aujourd’­hui les tâches répé­ti­tives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répé­ti­tive (comme un déve­lop­peur en fait).

  • Lecture d’Anne Vella : « Dear Soft­ware Engi­neer: It’s Time to Reclaim Your Role »

    Cita­tions d’Anne Vella :

    I totally agree that soft­ware engi­nee­ring should be a lot more than just writing code. When I studied compu­ter science at univer­sity, they taught us how to elicit requi­re­ments, write user stories, design user inter­faces and apply UX prin­ciples, archi­tect complex systems, create test plans, execute test cases and so much more. The whole shebang.

    De mon temps on appe­lait ça de façon mépri­sante les pisseurs de code. Et pour­tant, à cause de la spécia­li­sa­tion, je vois énor­mé­ment d’in­gé­nieurs tomber dans cette caté­go­rie de « déve­lop­peur expert ».

    J’en ai même vu s’in­di­gner qu’on arbitre trop souvent en faveur du produit et des utili­sa­teurs plutôt qu’en faveur d’une qualité de code interne.

    Rien qu’à dire ça je sais que je vais avoir quelques réac­tions assez fortes.

    Personne n’a raison mais ça devient des métiers diffé­rents.

    Steve Yegge recently wrote a follow-up to his contro­ver­sial article The Death of the Junior Deve­lo­per, refra­ming his posi­tion as The Death of the Stub­born Deve­lo­per. He talks about how if you’re not adop­ting Chat-Orien­ted Program­ming, or CHOP, you’re getting left behind

    Je ne joue­rai pas à qui va devoir chan­ger.

    Je suis convaincu que les déve­lop­peurs « produit » vont devoir chan­ger de façon de travailler. Pour autant, le besoin ne va pas dispa­raître, loin de là. Les juniors vont vite avoir des super-pouvoirs. Les seniors qui se reposent un peu trop sur leur savoir acquis, sur la complexité du code set sur le besoin de renou­vel­le­ment perma­nent de techno vont eux avoir du soucis à se faire parce que leur valeur ajou­tée va deve­nir faible.

    On ne rempla­cera pas les déve­lop­peurs « code » experts. L’IA tant vantée n’est quand même qu’un outil statis­tique et je ne la vois pas de si tôt créer du code profond tel qu’on peut en trou­ver dans les biblio­thèques de code qui forment les briques de base. On aura besoin de personnes qui comprennent le fonc­tion­ne­ment de tout ça pour savoir quoi faire (éven­tuel­le­ment assis­tés par de l’ia s’ils le veulent). Là ce sont les juniors qui vont avoir du mal à trou­ver une place.

    Pour être franc je ne sais pas si tout ça est vrai­ment neuf. L’IA va juste démul­ti­plier un effet déjà exis­tant, mais peut être au point de rendre certains posi­tion­ne­ments très diffi­ciles à tenir.

    So dear soft­ware engi­neer, please take heed. If you’re not a “product engi­neer” and have specia­li­sed in writing code, AI may indeed take your job. But this isn’t just a warning – it’s an oppor­tu­nity. It’s time to reclaim your role and return to what soft­ware engi­nee­ring was always meant to be: a craft that combines tech­ni­cal exper­tise with problem-solving, user empa­thy, and busi­ness acumen. The future belongs to those with curio­sity who can see beyond the code.

    Mes propos semblent peut être trop alar­mistes, ou trop futu­ristes. J’ai l’im­pres­sion qu’on passe des paliers très vite.

    Je ne saurais trop conseiller aux déve­lop­peurs qui veulent prévoir leur avenir de sauter sans filet et de passer au CHOP et BATON décrits dans le billet cité.

    Si ça n’ac­cé­lè­rera pas grand chose aujourd’­hui, savoir comment utili­ser ses outils correc­te­ment demande un chan­ge­ment de para­digme et donnera plusieurs longueurs d’avance d’ici quelques années au plus.

    Si vous avez vu le sex appeal des déve­lop­peurs « no code » (non, il n’y a pas contra­dic­tion), ça va vite de démul­ti­plier.

    C’est une croyance de ma part mais elle est très forte.

    Oui, je sais. Il y a aussi à côté d’énormes enjeux éner­gé­tiques. J’ai­me­rais bien qu’on puisse les igno­rer mais je ne le crois pas. Je ne les mets pas de côté.

    Main­te­nant consi­dé­rant le coût des ingé­nieurs, celui de l’usage de ces outils, la valeur qu’on en tire, le futur sera quand même celui là. On peut refu­ser mais il faudra au mieux se prépa­rer à oublier les périodes fastes du point de vue emploi et salaire, pour ceux qui trou­ve­ront un emploi.

    Je n’ai pas la solu­tion à tout ça. Je me contente d’ob­ser­ver.

  • Prude IA

    Le contrôle des réseaux et de l’in­for­ma­tique par les États-Unis me saute à la figure de plus en plus souvent.

    Il y a peu, je lis que les États-Unis inter­disent TikTok si l’ac­ti­vité n’est pas reven­due à un tiers. L’enjeu c’est est celui de la sécu­rité natio­nale avec le fait que c’est une base chinoise et pas une base améri­caine. En même temps il y a une pres­sion qui commence à se consti­tuer de la part des États-Unis pour que l’Eu­rope ne bride pas les services améri­cains, voire qu’ils consi­dèrent les amendes de régu­la­tion de X ou de Meta comme du protec­tion­nisme au titre des règles de libre échange. Si l’im­pé­ria­lisme numé­rique se faisait par influence, main­te­nant on est dans le rapport de force clair et net.

    Ce n’est pas qu’une ques­tion écono­mique. Les liber­tés et inter­dits font partie de ce qui nous est imposé. C’est vrai autant pour le légal que pour le légal. Il est inté­res­sant de voir que les IA n’ont pas de filtre avan­cée pour gérer la vie privée mais qu’elles sont inca­pables de parler de corps fémi­nin ou de sexe. On importe à la fois leur free speech et leurs tabous.

    Où est-ce que ça nous mène ? Je ne sais pas, mais voyant quelle place est amenée à prendre l’IA, le fait qu’elle se fixe sur des règles du jeu d’un seul pays me met quelque part très mal à l’aise.

  • Outil ou collègue

    Mon conseil pour les rares qui me suivent encore et que j’ai pu moti­ver à deve­nir deve­lop­peur: fuyez! Redui­sez vos dettes. Votre train de vie. […] inves­tis­sez tout et prepa­rez vous pour l’hi­ver.

    Je vous garan­tie que avant la fin de votre carrière (voir de la décen­nie) il faudra se recon­ver­tir. Préfé­ra­ble­ment dans un truc manuel.

    On lit toujours plein de choses alar­mistes sur le futur. Tout avance très vite mais les métiers dispa­raissent rare­ment en moins d’une géné­ra­tion. Jusqu’à présent.

    Et pour­tant, vu d’où je l’ai lu, ça m’a fait cogi­ter.

    J’ai repris un peu mes tâches pénibles habi­tuelles via Cursor. Rien de neuf. Je le fais régu­liè­re­ment. Si je trouve la complé­tion auto­ma­tique magique, pour moi c’est un outil en plus, pas de quoi éteindre le métier.

    Là j’ai suivi les traces de Simon Willi­son. J’ai utilisé l’agent et lui ai tout dicté, refu­sant de toucher à un quel­conque fichier direc­te­ment, de résoudre un quel­conque problème tech­nique moi-même.

    J’ai plein de posi­tif et plein de néga­tif mais… mon dieu je ne conseille­rai pas à mon fils de faire du déve­lop­pe­ment. C’est foutu pour lui. Je ne sais pas s’il aurait pu tout réali­ser sans rien savoir, mais ça n’en était pas loin. Dans 2 ans, 10 ans… oui la moitié des tâches de déve­lop­pe­ment au moins se passe­ront proba­ble­ment d’ex­perts tech.

    Ok, c’est de la boule de cris­tal. Je peux me trom­per. Je me suis déjà trompé par le passé. Oui ça ne remplace pas tout mais on a passé un sacré cap. Il me reste 20 ans au moins, la révo­lu­tion se fera pendant ma vie profes­sion­nelle, et elle sera lour­de­ment impac­tée.