TLDR : Je programme depuis 25 ans, et maintenant je vibe code des logiciels jetables par plaisir sur mon temps libre (et je ne regarde pas toujours le code).

Hey, ça faisait longtemps !

Hier, j’ai pensé qu’il était temps que j’écrive quelque chose sur mon blog, puis j’ai réfléchi à l’idée d’écrire une sorte d’essai sur ma vie de programmeur, car avec l’IA, car j’y ai pas mal réfléchi récemment.

Je programme depuis environ 25 ans maintenant, et professionnellement depuis à peu près 18 ans.

C’est étrange car dans ma tête, je suis encore cet ado qui a découvert qu’une calculatrice pouvait faire des choses bien plus intéressantes que de calculer le cosinus d’un angle, résoudre des équations ou tracer des fonctions à l’écran.

Bref, l’un de mes premiers langages de programmation a été le TI-Basic, sur une calculatrice Texas Instruments (je t’aimerai toujours, ma chère TI-89 <3).

  • Pendant mes études, j’ai appris les langages C, C++, C#, Java, Python, Awk, OCaml, Delphi, Maple, PHP, R, TeX, Bash, SQL.
  • Professionnellement, j’ai déjà été payé pour écrire en C, C++, Java, Kotlin, Python, Objective-C, Swift, JavaScript, Perl, SQL et Tcl.
  • Pour le plaisir et les projets personnels, il y a eu Clojure, OCaml, Java, Go, Ruby, Delphi, Elixir, PHP, TI-Basic et C/C++.
  • Les langages que j’ai préféré apprendre : Clojure et OCaml, sans aucun doute.

C’est une sacré liste écrite comme ça, ah et j’aime aussi beaucoup les éditeurs de texte, de Borland Turbo Pascal à DevC++, Visual C++, Borland Delphi, Macromedia Dreamweaver, Emacs avec le mode tuareg quand j’utilisais OCaml au quotidien (principalement à l’université et parce que j’adorais ça, en plus c’est français et mon prof était génial), à JEdit pour Java et PHP, TextMate, Eclipse, IntelliJ, XCode, Atom, VSCode, Vim, partout où je peux mettre Vim, j’utilise actuellement Zed sur mon Mac (avec les raccourcis Vim).

Anciens captures d'écran

À un moment donné, j’étais assez fan de Delphi et de C, et j’ai commencé à écrire mon propre shell, des commandes et un terminal nommé FTerm, pour apprendre davantage et en avoir un sur Windows.

Vous pouvez voir JEdit, Emacs, Quake3, RavenShield, FTerm, TeamSpeak, il y a même des icônes dont je ne me souviens plus de ce qu’elles étaient.

J’ai même commencé à écrire un IDE OCaml nommé KmlI, mais c’était une tâche trop grosse pour moi à l’époque et je ne l’ai jamais terminé.

En partie grâce à DHH et à ses anciennes démos de Ruby on Rails avec TextMate, j’ai fini par tomber dans une obsession inutile pour les éditeurs de texte. Quiconque a passé assez de temps à programmer sait que c’est une étape parfaitement normale de la maladie :). À un moment donné, on arrête de se demander comment écrire son application et on commence à se demander si le vrai problème dans sa vie est que son éditeur est trop lent pour charger des gros fichiers, ou n’a pas assez de raccourcis et de plugins.

J’ai toujours adoré coder, j’aime comprendre comment les choses fonctionnent, avoir un problème qui tourne en boucle dans mon cerveau pendant des heures et trouver la solution moi-même. J’aime prendre quelque chose qui fonctionne mal pour le faire fonctionner bien. J’aime prendre quelque chose de pas performant pour le rendre bien plus rapide. J’aime le code que quelqu’un d’autre peut comprendre six mois plus tard, des systèmes dont l’architecture a du sens et où l’on peut naviguer dans le code sans avoir l’impression que chaque fichier a été créé par une civilisation différente.

Et je déteste particulièrement les logiciels lents. Les ordinateurs sont tellement rapides, même si je sais que le temps de développement coûte plus cher que le temps CPU, je déteste attendre que le logiciel termine ce qu’il doit faire, et c’est très courant, beaucoup trop. Je trouve qu’il y a même quelque chose de super désagréable à cliquer sur un bouton et à regarder un spinner pendant trop longtemps (trop long dépend de vos goûts) pendant que la tâche attendue termine son travail.

Donc, la performance a toujours fait partie du plaisir pour moi. Pas une optimisation prématurée partout, mais au moins en prendre soin et savoir approximativement ce que la machine fait et ce qu’on lui demande.

J’ai adoré participer à des défis de programmation, comme Advent of Code, LeetCode, Code Jam. Je résolvais de petits problèmes inutiles simplement parce qu’ils étaient intéressants et/ou parce que je m’ennuyais, ou je voulais juste apprendre, ou je voulais juste voir où je me classais sur le leaderboard mondial.

Et j’ai toujours eu des projets personnels.

Avant qu’on n’appelle ça des projets personnels

À l’époque, on faisait juste des trucs sur l’ordi, ce n’était pas du “indie hacking”, pas du “building in public” (je ne fais jamais ça de toute façon). On faisait des trucs parce qu’on le voulait, qu’on en avait besoin, nous ou nos amis, et parcequ’on voulait passer le temps en s’amusant.

Sur la TI-89, j’écrivais des choses pour moi-même et pour mes amis d’école. Par exemple un petit programme dont la sortie était exactement ce que notre professeur voulait lire, avec certaines variables remplacées par les bonnes réponses. Puis j’ai découvert un programme nommé Variatio ou peut-être c’est mon frère qui me l’a montré, ce programme faisait la même chose et encore plus.

Je ne savais même pas qu’il y avait une communauté sur le web partageant des logiciels complets, des jeux pour TI-89, c’était fou. J’étais juste un gamin avec une calculatrice ayant des capacités de programmation incroyables dont je n’avais aucune idée. Je savais déjà qu’il existait un langage de programmation nommé C, j’avais vu quelques exemples de code mais j’étais un total noob, j’ai loué un livre à la bibliothèque, j’ai commencé à l’apprendre, et j’ai découvert Ti-GCC, c’est là que j’ai commencé à approfondir. J’ai joué à des jeux comme TiCave et FallDown, j’ai passé des HEURES à y jouer, et c’est aussi là que j’ai découvert que je pouvais regarder le code source, notamment Othello 2 qui était super bien (je n’ai jamais gagné en mode difficile). Je m’écarte du sujet, mais tout ça pour expliquer comment j’ai découvert une sorte de logiciel open source, et que ces gens et ces logiciels étaient bien au-dessus de mes compétences, donc j’avais besoin de rattraper mon retard, c’était pas vraiment nécessaire, mais je le voulais.

Live FallDown logo

Tribute au jeu FallDown par je crois David Coz.

Plus tard, j’ai passé beaucoup de mon temps libre à jouer en ligne, surtout à Quake III Rocket Arena et Rainbow Six: Raven Shield. Nous avions des chans, TeamSpeak, des sites web de clans et des forums, même des serveurs dédiés, amenant tous sortes de petits problèmes qui nécessitaient des logiciels personnalisés !

Du coup naturellement, j’ai écrit des logiciels personnalisés. J’ai créé de petites utilitaires Delphi comme un sélecteur rapide de paramètres de jeu multi-utilisateurs pour Raven Shield (créant des fichiers .ini à la volée avant le lancement du jeu), des outils pour trouver des amis dans les salles de jeu afin de savoir où ils sont et les rejoindre en un click, afficher le statut de notre TeamSpeak en permanence sur notre site web (en PHP), une utilitaire Alt-Tab pour Quake III sur Windows. Diverses choses qui avaient du sens pour peut-être vingt personnes sur Terre, mais ces vingt personnes moi compris, nous les utilisions ces logiciels.

Photos de mes tout premiers projets

GC GUI: une interface graphique (GUI) pour Great Code par Christophe Beaudet

MPE: un éditeur d’images en Delphi

RvS KB: un éditeur de raccourcis clavier pour Raven Shield en Delphi (quand je ne jouais pas avec mon clan, j’étais nommé pr¡ñtƒ)

RvS LSS: une interface graphique pour les stats serveur en direct pour Raven Shield en Delphi

J’ai même créé quelque chose de proche d’un ClanBase (une plateforme de gaming compétitif) pour la communauté de gaming française sur Raven Shield. Avant que l’esport ne devienne des arènes, des sponsors, des entraîneurs professionnels et des adolescents gagnant plus que les architectes logiciels seniors, nous avions des guerres de clans organisées sur des sites web par des gens qui faisaient du PHP après l’école.

J’ai forké le système de templating de phpBB et construit mon propre système de tournois et de classement autour. Les clans pouvaient s’affronter, les résultats étaient enregistrés, les classements mis à jour, les tournois gérés. Je n’ai plus le code, mais je me souviens de fonctions de plus de 200 lignes de code, des if et else qu’on ne pouvait plus compter, le moment “wtf” où j’ai découvert l’opérateur $$ en PHP. L’architecture n’était pas parfaite, il y avait probablement des tonnes de failles de sécurité, mais ça marchait, j’étais heureux, les gens étaient heureux, et c’était suffisant pour moi.

Il y avait quelque chose de satisfaisant à voir des logiciels que j’avais créés être utilisés par une communauté dont je faisais partie. C’était évidemment non monétisé, je n’ai gagné rien d’autre que des merci d’amis sur le web.

La vitesse max de mon temps libre

Le facteur limitant sur mes projets personnels a toujours été le temps (comme tout le monde, rien de nouveau). À un certain moment, quand j’ai eu assez de compétences, je pouvais construire presque tout ce que je voulais (sauf des jeux complets ou des choses très bas niveau comme des OS et des drivers, je n’ai jamais eu les compétences nécessaires), tant que j’avais assez de temps.

Un projet personnel avançait à la vitesse de mes soirs et week-ends. Quand j’étais jeune et que j’habitais chez ma mère, j’en avais beaucoup, et je m’en servais pour apprendre et apprendre, construire et construire, bidouiller et bidouiller, parfois très tard. Je me souviens avoir créé un petit Photoshop en Delphi à l’université (voir screenshot plus haut), j’ai passé toute la nuit sans dormir du tout, mais j’étais très fier d’avoir implémenté plusieurs types de flous (gaussien, radial, …).

Mais quand le travail quotidien devient sérieux, et qu’on a plus de responsabilités, une famille et des enfants, on a moins de ce temps, ce qui est absolument normal. Mon développement logiciel personnel se retrouvait alors compressé dans les petits bouts de temps restants, mais je n’ai jamais cessé d’avoir des idées, juste je ne pouvais pas les finir. J’ai probablement autour de 30 à 50 repository que j’ai commencés au fil du temps qui sont simplement morts. C’est là que l’IA a changé quelque chose de beaucoup plus important pour moi que l’autocomplétion, elle a changé comment je peux utiliser mon temps libre.

Quand la machine est devenue assez bonne

J’utilise des assistants de codage depuis je dirais 3 ans maintenant, au début ils étaient intéressants puis sont devenus utiles, même étonnamment utiles au final.

Il s’avère que vers la fin de 2024, ou peut-être pendant 2025 selon le type de travail, quelque chose a changé. Jusque-là, je me considérais toujours comme un meilleur programmeur que GPT. Bien sûr, il connaissait plus d’API que moi, ou une syntaxe que j’avais oubliée en changeant de langage. Il pouvait produire du boilerplate instantanément, mais quand les choses devenaient sérieuses, impliquant architecture, bugs subtils et problèmes de performance alors j’avais toujours l’avantage. C’était vrai à ce moment là, mais maintenant j’en suis beaucoup moins sûr.

Meilleur programmeur est une mesure presque sans signification de toute façon. Si vous me placez dans une base de code Java que je connais depuis dix ans, et que vous me donnez un bug de production impliquant de la concurrence, des exigences métier historiques et trois migrations précédentes que personne n’a documentées correctement, j’ai toujours d’énormes avantages parce que le contexte et l’expérience comptent. Mais donnez à un modèle récent un nouveau projet bien défini aujourd’hui et comparez ce qu’il peut produire en une heure avec ce que moi je peux produire en une heure, et il n’y a tout simplement pas de comparaison.

Il pense plus vite, tape plus vite, il connaît Go, Kotlin, Java, Swift, SQL, CSS, JavaScript et vingt librairies en même temps. Il peut écrire des tests, refactoriser, disséquer, faire des migrations, lire de la documentation comme moi mais 1000 fois plus vite, croiser les vérifications, passer du frontend au backend à la base de données sans les problèmes de changement de contexte que j’aurais. Aussi et surtout pour moi (et beaucoup de développeurs), il n’en a jamais marre. Moi, j’en ai marre, il y a des parties de la programmation que j’aime, et il y a aussi des parties que je n’aime pas du tout.

Comme par exemple mettre à jour le code inutile, écrire dix tests presque identiques, la glue, le mapping et les DTOs, ce sont des parties d’être un CRUD monkey. Les grosses migrations, comme passer un projet de Spring Boot 3.x à 4.x, c’est souvent l’enfer, on tombe dans toutes sortes de problèmes subtils qu’on n’a même pas envie de connaitre (problèmes Hibernate, mise à jour de Jackson, …).

L’IA n’a pas de concept de oh non, pas encore cet truc. (au moins jusqu’à présent), elle va juste le faire, et si elle se trompe parce que je ne suis pas le meilleur prompt engineer et que mes SKILLS.md ne sont pas à jour, je lui dirai pourquoi, et elle recommencera, encore et encore. Parfois, ça nécessite plusieurs itérations avant que je ne consière le code assez bon, et parfois je suis surpris de la façon dont elle a généré exactement ce que je voulais à partir de seulement 3 à 4 lignes de prompt en anglais pas parfait (je ne sais pas pourquoi je parle à l’IA en anglais 90% du temps alors qu’elle gère parfaitement le français, elle parle même mieux français que moi, lol).

Ça me laisse avec deux sentiments contradictoires, le premier est que je me sens incroyablement puissant, et deuxièmement je me sens aussi un peu diminué, peut-être légèrement dépossédé aussi. Parce que, dans le passé, quand je construisais quelque chose, je pouvais dire : J’ai fait ça. Non seulement j’avais l’idée, mais je connaissais chaque classe et chaque fonction, toutes les sales astuces et les contournements par ci et là, parce que mes propres petits doigts avaient écrit toutes ces lignes de code.

Aujourd’hui je peux toujours dire que j’ai fait l’application, mais ça n’a plus le même sens, j’ai décrit l’application que je voulais dans un AGENTS.md (ou de faire écrire par Claude/Codex sur la base d’un prompt vague), de corriger certaines décisions. Je n’ai pas vraiment écrit le code. C’est peut-être l’équivalent du développement logiciel d’être un menuisier qui a passé sa vie à fabriquer des meubles à la main et qui reçoit une machine du futur où il peut décrire une chaise et la regarder en fabriquer une.

Le menuisier peut faire vingt fois plus de chaises et c’est très utile, mais j’imagine qu’après un moment, il commence à se demander quelle partie de la chaise lui appartient toujours.

Vibe coding avec 25 ans d’XP

J’ai cherché sur internet qui était le premier à sortir l’expression vibe coding. Apparemment, c’est Andrej Karpathy, et plus tard décrit comme Software 3.0, où le langage naturel lui même devient une interface de programmation.

Je suppose que ce que je fais maintenant avec mes projets personnels relève donc du vibe coding. Au début, c’était du vibe coding avec 25 ans d’expérience en revue de code full, où je relisais tout ce que l’IA générait, chaque fichier et chaque fonction, chaque test. Maintenant, j’ai arrêté de tout lire, j’ai actuellement des logiciels Go vibe codés pour lesquels je n’ai même pas regardé une seule ligne. Je lis toujours assez de code parce que je suis intéressé, mais c’est un plaisir guidé par mon objectif d’apprendre, ce n’est pas nécessaire du tout pour ce genre de projets.

Je ne parle pas de vibe coding pour de la prod à mon travail (pour l’instant) où il y a des conséquences potentielles, des collègues et des clients. Je parle de projets personnels, pour ceux-là je regarde surtout l’architecture, je demande comment le projet est structuré, j’inspecte les morceaux importants et je regarde le modèle de données. Je challenge les choix et je demande pourquoi il a sélectionné une approche plutôt qu’une autre (s’il ne me le dit pas tout de suite, ce qui arrive parfois). Je me soucie des interfaces, qu’elles soient facilement extensibles dès le début, puis une fois construit, je lance et je teste les comportements, je lui demande d’écrire des benchmarks pour être sûr que ça correspond à mon gout de la perf, et c’est tout.

Je n’ai pas le même niveau de compétence dans chaque langage. Je suis extrêmement à l’aise avec Java et Kotlin, par exemple. Je connais très bien Go, sa philosophie, je peux lire et écrire, mais je ne suis pas du tout le programmeur Go équivalent de mon niveau en Java ou Kotlin, donc je ne peux pas rivaliser avec la machine dans tous ces domaines en même temps.

Je fais simplement confiance à ce que l’IA fait, ce n’est pas une confiance aveugle, plutôt une confiance éclairée. J’en sais assez pour comprendre la solution et j’en sais assez pour poser les bonnes questions. Mais c’est pourquoi et afin de maintenir une confiance éclairée je demande pour le moment uniquement à l’IA de générer du code dans des langages que je connais et comprends.

Je n’ai aucune compétence en Rust, aucune compétence en Assembleur ni en Haskell, donc je ne créerai aucun projet personnel utilisant l’IA avec ces langages. Même si je ne lis pas toujours le code généré, je le peux encore si nécessaire. Une exception étant le CSS, je suis absolument nul en CSS, je n’aime pas ça et j’ai pas envie d’en lire même une ligne, je veux juste que le site ait l’air OK !

Je n’ai jamais produit autant de logiciels personnels

C’est amusant qu’après des années où j’avais de moins en moins de temps dispo pour le dev personnel, je suis soudainement plus prolifique que jamais. Si j’ai besoin de quelque chose, je regarde sur github, et si ça n’existe pas (assez rare) ou que ce n’est pas excactement comme je l’imaginais, alors je le fais moi même.

Certains programmes peuvent être un projet d’un après-midi, voire d’un week-end à deux semaines. Quand je suis super pris par une nouvelle idée, j’alterne entre Claude et Codex, ils bossent bien ensemble. C’est marrant d’ailleurs quand je demande à GPT combien de temps ça prendra et qu’il me dit 2 à 3 mois, je me dit allez tu rêves et on le fait en 2 jours.

Ces derniers temps j’ai donc écrit des outils dont j’avais besoin.

  • reliure, écrit en Go, qui se connecte à ma Kindle, transfère des EPUBs et gère des statistiques de lecture.
  • pomtool, aussi en Go, un analyseur/linter rapide pour les fichiers pom.xml.
  • Bonum, une application de suivi des finances personnelles écrite en Kotlin et Postgres. Celle-ci est intéressante car c’est celle que j’ai commencée avant d’utiliser des LLMs et GPT and co m’ont aidé à repérer des problèmes avec mes schémas de données, à écrire du code SQL bien meilleur et plus performant et à ajouter de nouvelles fonctionnalités rapidement.
  • facteur, un outil en ligne de commande Go destiné à remplacer Postman dans ma façon de bosser.
  • Une application web pour pratiquer l’anglais que j’ai faite pour ma fille, utilisant Go et HTMX. Elle a des flash card, des cours complets, des exercices et une légère gamification (avec de petits tigres mignons en svg entièrement générés par Opus).
  • Divers scripts Python pour obtenir mes données de Withings et les afficher comme je le souhaite ou même analyser des trucs d’opendata.

Et j’ai déjà d’autres idées, pas besoin d’en faire tout un plat, je partage sur Github si quelqu’un les trouve utiles, et si 3 personnes les utilisent, c’est super, mais si tout le monde s’en fiche, c’est pas grave car ça me sert à moi.

Le coût de fabrication du logiciel est devenu assez faible, donc la question est-ce que des gens l’utiliseront ? n’est plus quelque chose que je me demande avant de commencer. Je peux créer des logiciels extrêmement spécifiques, un logiciel pour un seul problème ou pour 4 personnes, pour ma famille. Un logiciel pour moi.

Je trouve que c’est très similaire au web du début, où les gens faisaient de petits sites web parce qu’ils le pouvaient, et désormais un peu tout le monde peut créer de petites applications super rapidement parce que c’est devenu beaucoup plus simple. J’ai évidemment créé beaucoup de petits sites web sur différents sujets dans le passé.

Je vibe code en Go depuis que j’ai arrêté de l’écrire

Une autre chose marrante, j’ai commencé à utiliser Go pour presque tous mes projets secondaires (j’aime bien Go de toute façon).

C’est rapide, le compilateur est très rapide, le tooling est excellent, le déploiement est top car ennuyeux, on obtient un seul binaire et voilà. La bibliothèque standard est bonne, ce qui est cool parce que l’IA n’a pas toujours besoin de tonnes de dépendances, l’écosystème est mature, la concurrence est bonne, et c’est possible d’optimiser un max si nécessaire.

De plus les modèles sont très compétents avec Go (je trouve spécialement GPT 5.5+). Si je devais écrire tout le code moi-même, j’aurais peut-être choisi un autre langage, car Go n’est pas le langage dans lequel je trouve personnellement que taper du code est le plus … agréable.

Il y a des langages que je trouve plus expressifs, j’adore Clojure, OCaml est top, Kotlin est expressif, Ruby aussi. Mais si je ne suis plus le gars qui écrit le code, ce n’est plus la même histoire. Je n’ai pas besoin de me demander dans quelle syntaxe j’aime le plus écrire ?, je peux juste prendre un langage qui optimise les propriétés que je veux dans le logiciel final, à savoir : compilation rapide, déploiement très simple, très bonne performance. Et Go réunit tout cela.

Les langages de programmation sont des interfaces entre l’esprit humain et les machines, mais si une partie significative du code est produite par une autre machine alors le langage idéal n’est pas forcément celui que les humains auraient conçu pour eux-mêmes en priorité. Peut-être que les langages ennuyeux gagnent la course, ceux avec d’excellents compilateurs, de bonnes garanties statiques et un tooling simple, et deviennent super attrayants parce que les agents peuvent générer les parties verbeuses sans se plaindre.

Si ça se trouve dans le futur, nous n’aurons même plus de code à relire même si nous voulons, j’ai lu certaines interviews d’Elon disant :

« Le code lui-même disparaîtra au profit de la simple création du binaire directement. L’étape suivante sera la génération directe et en temps réel de pixels par le réseau neuronal. »

« Le code source est sur le point de devenir comme l’assembleur. L’étape suivante est de se débarrasser complètement du “code source” et de simplement créer un binaire efficace directement avec l’IA. »

Ce serait marrant qu’après des années où nous avons construit des langages plus expressifs pour que les humains en tapent moins, et bien maintenant c’est la machine qui tappe tout de toute façon.

Logiciels jetables

Tout cela m’amène à une expression à laquelle je reviens souvent : disposable software (logiciels jetables).

On entre dans une ère où on créé des logiciels, on les utilise pendant un certain temps et on les jete. Mais je ne suis pas convaincu que ce soit une si mauvaise chose, les devs ont tendance à s’attacher émotionnellement aux logiciels qu’ils produisent, surtout au début de leur carrière, en tout cas c’était mon cas.

On passe des mois à créer quelque chose, on prends des décisions architecturales, corrige des bugs, on se bats pour ça en réunion, on écrit du code joli et maintenable, et donc ça devient notre application, comme un bébé numérique. Puis une réorganisation se produit, une autre branche de l’entreprise achète un produit qui couvre 70% de ce que l’application fait, deux départements fusionnent, un programme stratégique apparaît avec un PowerPoint contenant plusieurs flèches et le mot synergie. On retourne à son bueau et hop l’application est morte.

Quand j’étais junior ça me dérangeait beaucoup, tout ce travail et ce code, toutes mes belles abstractions, hop à la poubelle. Mais au final ça ne signifie pas que le travail a été gaspillé, le logiciel avait une valeur tant qu’il était utile et j’ai appris plein de choses dans le processus.

Un pont n’est pas considéré comme un échec parce qu’il est remplacé après 100 ans, un repas de restaurant n’est pas un échec parce que le restaurateur ne le garde pas pour toujours à la carte, dans le monde du logiciel on a développé une espèce de mythologie où le fait qu’un logiciel dur prouve sa valeur. Winamp était génial, ce n’est pas parce que quelqu’un utilise Spotify que Winamp n’était pas un logiciel utile qui a marqué l’histoire, même si je préférais foobar2000 à Winamp, c’est la même chose, Winamp a toujours été génial et utile.

Au travail je fais donc toujours de mon mieux pour créer du logiciel maintenable, je me soucie toujours de la qualité, de la performance et du prochain développeur qui travaillera dessus. Mais je ne suis plus émotionnellement perturbé par la possibilité qu’un jour on me dise : On n’a plus besoin de ça.. Pas grave, il y a plein d’autres choses à écrire, je ne suis pas mon code, j’écris simplement du code … et maintenant je demande même à une machine d’écrire du code pour moi.

Petit open source

Une énorme quantité des logiciels que j’ai utilisé au fil des années existe juste parce que quelqu’un d’autre avait le même petit problème à réglet que moi, mais avant moi. On cherche sur GitHub, trouve un repo avec 600 étoiles qui fait 80% de ce dont on a besoin, on ouvre une issue ou peut-être qu’on crée même une PR. Maintenant, supposons que j’ai besoin d’un petit utilitaire CLI aujourd’hui, soit je peux passer trente minutes à chercher sur GitHub et à comparer différents projets, qu’ils sont maintenus, ou bien je peux décrire exactement ce que je veux à un agent et avoir une première version 15 minutes plus tard.

Je l’ai déjà fait plusieurs fois, parce que c’est pratique, mais cela crée un problème intéressant. Si tout le monde commence à générer sa propre petite version de tout, nous contribuons moins aux outils partagés. Au lieu d’une seule bonne bibliothèque utilisée par 50 000 développeurs, on peut se retrouver avec 50 000 implémentations générées légèrement différentes dans des dépôts privés.

Même en considérant les avantages d’avoir des implémentations partagées concernant les corrections de bugs, les problèmes de sécurité, etc. Un outil personnel généré ne reçoit aucun de ces avantages, et je m’en fiche que mon utilitaire de transfert EPUB survive pendant vingt ans car s’il casse après une mise à jour Kindle je peux demander à un agent de le corriger. Mais ça ne s’applique pas à tout, nous n’avons pas besoin et ne voulons pas 1 000 implémentations concurrentes de TLS ou crypto.

Sans oublier les mainteneurs qui croulent sous les PR générées de personnes qui n’ont pas lu le code et ne peuvent pas expliquer ce que leur correctif fait. Je n’y ai jamais été confronté car je n’ai jamais eu à maintenir un projet très utilisé de toute façon. Mais il y a quelques mois, j’ai écrit un très petit plugin Obsidian qui faisait quelque chose dont j’avais vraiment besoin pour mon second brain, et j’ai pensé que ce serait super rapide de l’avoir approuvé par les mainteneurs, il s’est avéré que ça a pris plusieurs semaines, presque 3 mois en fait, parce que les mainteneurs avaient des milliers de PR à gérer, c’est un travail gigantesque pour eux et probablement que la plupart n’est pas encore uniquement du code généré par l’IA.

J’espère que l’open source restera important, j’ai BEAUCOUP appris en lisant du code écrit par des gens bien meilleurs que moi, si le futur des développeurs devient uniquement génère ça pour moi, nous perdrons quelque chose, lire du bon code apprend le bon goût. Mais peut-être que ce dont nous avons plutôt besoin sera le goût pour ce à quoi ressemble un bon logiciel (architectural, comportemental, perf).

La littératie logiciel comptera encore plus

Le savoir est précieux, il est important de connaître toutes les bases, mais je pense qu’une autre forme de littératie deviendra plus importante si le logiciel généré par l’IA devient la norme, nous pouvons l’appeler littératie logiciel.

C’est le fait savoir ce que le logiciel peut raisonnablement faire, quand quelque chose semble simple mais cache des choses difficiles, comprendre que les données doivent vivre quelque part, que l’authentification et l’autorisation sont des choses différentes, ce qu’est approximativement une API, que si une application doit se synchroniser entre plusieurs appareils, vous devez gérer l’état et les conflits quelque part.

Ce genre de connaissances est moins porté sur la syntaxe et plus sur les modèles mentaux, les gens qui comprennent le logiciel peuvent donner de meilleures instructions à l’IA parce qu’ils savent quelles questions sont importantes et ils peuvent aussi vite savoir quand le résultat est suspect.

Imaginez deux personnes qui demandent à l’IA de construire une application de finances personnelles. L’une dit, Fais-moi une app pour suivre mon argent, l’autre dit Je veux un stockage local-first, des imports depuis CSV, un historique de transactions immuable, des catégories qui peuvent être renommées sans modifier les imports bruts passés, pas d’arithmétique en virgule flottante pour l’argent, et j’ai besoin de pouvoir exporter tout dans un format documenté.

La deuxième personne n’a pas écrit une ligne de code, mais elle comprend le logiciel, et aujourd’hui cette différence produit des résultats très différents. Je pense que mon expérience me donne cet avantage parce que j’ai passé 25 ans à accumuler ces informations, et quand un agent propose quelque chose, j’ai déjà un modèle dans ma tête de là où ça peut mal tourner.

Combien de tout ça restera nécessaire quand que les modèles deviendront meilleurs pour poser les questions eux-mêmes ? Un agent futur pourrait répondre à fais-moi une app pour suivre mon argent en interviewant l’utilisateur pendant vingt minutes avant de générer quoi que ce soit. Poser les questions qui comptent sur les devises multiples, les transactions modifiables, la réconciliation, ce qui se passe quand un import est effectué plusieurs fois, la confidentialité.

Le système compensera alors le manque de littératie logiciel de l’utilisateur, mais même là je pense que comprendre le logiciel restera utile de la même manière que comprendre la finance est utile même si vous avez un comptable. La délégation fonctionne mieux quand on peut comprendre les conséquences des décisions prises pour vous, et quand quelque chose ne va pas, quelqu’un doit savoir ce que faux signifie (et je veux que cette personne soit moi).

Qu’est-ce qu’un développeur alors ?

Je ne sais pas comment répondre à que fera un développeur logiciel dans cinq ou dix ans ? On entends depuis plusieurs années : L’IA ne remplacera pas les développeurs. Les développeurs utilisant l’IA remplaceront les développeurs qui ne l’utilisent pas.

Peut-être que c’est vrai, mais comme expliqué plus tôt, mon expérience me donne encore un avantage aujourd’hui lorsque j’utilise des agents de codage, savoir quand diviser un projet, les abstractions inutiles, et tout ça, mais je ne vois aucune raison d’imaginer cet avantage comme permanent. Le modèle d’aujourd’hui a besoin que je dise, Non, ne structure pas le projet comme ça parce que ça deviendra problématique quand on ajoutera X, celui dans trois ans le saura déjà et mieux que moi. Il aura été entraîné sur 10 millions de projets similaires, peut-être qu’il simulera plusieurs architectures à la fois, générera les prototypes et pourra les benchmarker pendant que j’essaie encore d’expliquer mon prompt et mon raisonnement.

Chaque fois qu’une autre couche peut être automatisée le rôle humain restant se déplace un peu, peut-être que cela continuera pendant longtemps et que les humains restront toujours au sommet, mais peut-être pas. Le CEO d’Anthropic a dit que dans 3 à 6 mois (donc très bientôt, maintenant) l’IA écrira 90% du code que les développeurs logiciels étaient chargés de, et ensuite il a précisé que écrire 90% des lignes est très différent de supprimer 90% des ingénieurs logiciels, ce qui est une distinction importante c’est vrai.

J’imagine plusieurs futurs pour les développeurs logiciels, et ce qui rend tout cela compliqué, c’est que certains scénarios complètement opposés sont aussi plausibles.

Le scénario optimiste est que nous créons juste beaucoup plus de logiciels.

C’est exactement ce qui m’est arrivé personnellement. L’IA ne m’a pas fait passer un dixième du temps à programmer puis à utiliser tout le temps restant à regarder Netflix, j’utilise toujours la même quantité de temps libre que je peux raisonnablement consacrer à des projets personnels (encore plus, en fait), mais dans ce même laps de temps, je peux produire beaucoup plus de choses. Au lieu d’un projet progressant lentement pendant six mois, je peux avoir plusieurs choses fonctionnelles après quelques week-ends.

Il n’y a aucune raison pour que les entreprises ne se comportent pas de même. Imaginez une entreprise a 100 développeurs et que l’IA rend chaque développeur cinq fois plus productif, nous pourrions évidemment dire que l’entreprise n’a maintenant besoin que de 20 développeurs, et je suis sûr que certaines entreprises feront ça.

Mais l’autre possibilité est qu’ils se rendent compte qu’ils ont assez de travail pour les 100 développeurs dans tous les cas.

Dans chaque entreprise pour laquelle j’ai travaillé, il y avait toujours beaucoup plus de logiciels que les gens voulaient que de développeurs disponibles pour les écrire. Il y a des fonctionnalités qui traînent dans les backlogs pendant des années, de petites applications internes que personne n’a le temps de créer, des processus manuels que tout le monde sait qu’ils ne sont pas optimaux mais qui sont toujours là, des feuilles de calcul partout. Il doit y avoir des millions de ces petits problèmes à l’intérieur des entreprises, tout le shadow IT classique.

Le développement logiciel a toujours été assez cher pour que beaucoup de problèmes ne valent tout simplement pas la peine d’être résolus, mais pas avec l’IA. Donc, peut-être que nous ne finirons pas avec moins de développement logiciel du tout, mais avec avec une quantité gigantesque de logiciels, y compris beaucoup de choses qui aujourd’hui ne justifieraient jamais un développement.

Et cela correspond à l’idée de logiciel jetable, car chacune de ces applications n’a pas besoin de devenir un produit maintenu pendant vingt ans. Un département peut créer quelque chose pour un processus qui existe pendant 18 mois, l’utiliser, puis le processus change et l’application disparaît, ce qui est acceptable si son écriture a pris une journée ou une semaine.

Est-ce qu’un futur comme ça convient aux développeurs ?

Je m’amuse un max

Je m’amuse plus à dev mes logiciel personnels que jamais depuis des années.

Mon principal problème depuis peut-être dix ans n’était jamais un manque d’idées, c’est que je n’avais tout simplement pas assez de temps pour transformer la plupart de ces idées en concret. L’IA a changé ça.

L’application d’apprentissage d’anglais que j’ai fait pour ma fille est un bon exemple. Avant j’aurais pu construire l’application moi-même, il n’y a rien de techniquement extraordinaire, mais entre le backend, le frontend, la DB, les exercices, les utilisateurs, une petite gamification, l’UI, le déploiement et tous les petits détails qui apparaissent une fois qu’on commence, ça aurait facilement pu devenir un des repository sur lequel je travaille pendant deux mois avant d’abandonner lentement.

Et si ma fille l’utilise pendant une année scolaire ou deux puis ne l’ouvre plus jamais, c’est pas grave.

Je veux toujours programmer et travailler pour moi-même, par exemple, si je fais l ‘Advent of Code, demander à Claude la solution n’aurait évidemment aucun sens parce que l’objectif n’est pas d’obtenir le résultat, l’objectif est de résoudre le problème moi-même et d’apprendre.

Quand je travaille sur un petit algorithme parce que je trouve le problème intéressant, je veux programmer. Quand j’ai besoin d’un outil parce que quelque chose m’ennuie et que je veux que l’outil existe ce soir, je veux du logiciel.

L’IA peut-elle nous transformer en entrepreneurs ?

Avec un tel coût si faible pour tester des idées, je commence à réfléchir un peu plus au fait que certaines de ces idées pourraient devenir de vrais produits.

Je ne me suis jamais considéré comme un entrepreneur, j’aime la technologie, la programmation, créer des choses et résoudre des problèmes techniques, mais je n’ai jamais eu ce réflexe que certaines personnes ont, où chaque petite idée devient immédiatement comment puis-je transformer ça en 10k MRR ?. Je ne suis pas super excité par le marketing, les funnels, le SEO, l’acquisition de clients et tout ce qui vient après la partie technique.

Il y avait aussi une raison pratique simple pour laquelle je ne l’ai pas vraiment essayé, créer un produit sérieux seul est une énorme quantité de travail. Même quand l’idée est super simple, il faut quand même toutes le fonctionnalités de base autour, auth, emails, paiements, monitoring, backups, panneau d’admin.

Peut-être qu’il y a beaucoup de gens comme moi, pas des entrepreneurs dans l’âme parce que le coût de l’expérimentation était tout simplement trop élevé, mais qui connaissent extrêmement bien un problème de niche et qui peuvent maintenant construire une solution plus rapidement. J’ai plein d’idées.

Par contre j’ai aucune idée de à quoi ressemblera mon travail dans 5 ou 10 ans, peut-être que je passerai encore la plupart de mon temps à écrire du Java avec un assistant encore meilleur, peut-être que je ne superviserai que plusieurs agents et écrirai à peine du code moi-même, développeur logiciel deviendra un terme tellement large qu’il ne décrira plus grand-chose.

Ou peut-être que toute la bulle de l’IA explosera d’une manière ou d’une autre et qu’on fera à nouveau les choses à l’ancienne ou avec des modèles locaux. Ou alors je trouve une super idée, l’exécute avec mes amis IA en un mois et deviens super riche. Qui sait.

À la prochaine !