Personne ne sait encore comment construire avec l’IA
(worksonmymachine.substack.com)- À l’heure actuelle, aucune méthodologie de développement IA n’est encore établie, donc tout le monde est en phase d’expérimentation
- À l’ère de l’IA, la notion d’expert traditionnel perd son sens, et tout le monde est un débutant permanent
- Le processus réel de développement se fait par accumulation improvisée de documentation et essais-erreurs itératifs
- En collaborant avec l’IA, on peut produire des résultats énormes avec de courtes périodes de concentration et un minimum d’input
- Même son propre système documentaire est temporaire, et chacun poursuit une série d’expériences ponctuelles
The Great Experiment Nobody's Running the Same Way
- En développement IA, personne ne connaît la bonne méthode
- Comme dans la théorie des 10 000 heures de Malcolm Gladwell, l’expertise accumulée devient inopérante dans cet environnement
- Les outils IA évoluent trop vite pour qu’il soit facile d’y construire une vraie maîtrise
- Même en pair programming avec l’IA, l’expérience dépasse rarement deux ans : nous sommes tous en permanence débutants
Mon expérience actuelle (susceptible de changer)
- Avant de commencer, je m’appuie sur quatre documents principaux
pair_programming.mdproject_plan_{some extension}.mdtechnical_considerations.mdmcp-browser-architecture.md
- Ce système documentaire n’a pas été conçu dès le départ : c’est le résultat d’une accumulation improvisée
- Au départ, il n’y avait qu’un seul document d’architecture ; à force de problèmes récurrents et de difficultés à transmettre l’information, on est progressivement passé à quatre documents
- Ces quatre documents n’ont pas été définis comme un résultat optimal ; j’ai simplement eu le sentiment qu’il n’était plus nécessaire d’en ajouter
- Il m’arrive d’avoir l’impression de jouer un rôle avec moi-même en me disant : « ce document, c’est l’architecture », « ce processus, c’est l’officiel »
- Pourtant, le logiciel fonctionne, et c’est bien là l’essentiel : même ce type de système temporaire produit des résultats
- Le rôle de chaque document est le suivant
- Architecture Overview : part du README et consigne « ce que ce logiciel semble faire »
- Technical Considerations : documente les frustrations ou problèmes récurrents, avec ajout de détails à chaque fois que Claude se mélange
- Workflow Process : documente une procédure répétée ; en réalité, ce ne sont ni des règles officielles ni un document sacralisé, mais une collection de méthodes qui ont, par hasard, marché cette fois-ci
- Story Breakdown : des tâches découpées en blocs de 15 à 30 minutes. Cela sert à rafraîchir souvent le contexte de la conversation, car Claude oublie vite
Time Dilation in the Age of AI - La distorsion du temps à l’ère de l’IA
- En travaillant récemment sur le développement de Protocollie, collaborer avec l’IA a été une expérience qui bouleverse complètement notre perception du temps en développement logiciel
- Le projet avançait en demandant à Claude de travailler sur une fonctionnalité donnée, puis en profitant de sa vie personnelle entre-temps, avec des points de contrôle réguliers et de brefs retours
- Le temps réellement passé à « travailler » avec concentration était d’environ 90 minutes par jour, mais l’IA produisait entre-temps rapidement des milliers de lignes de code
- La quantité et la vitesse des résultats, par rapport à l’input, font s’effondrer les anciennes équations input-sortie, effort-résultat, temps-progrès
- Cette vitesse de développement peut parfois même susciter une forme de culpabilité ; elle cadre si mal avec le paradigme traditionnel qu’on peut avoir l’impression de tricher
La phase de « l’expérience spaghetti »
L’environnement actuel du développement avec l’IA est décrit comme une phase d’« expérience spaghetti »
- Autrement dit, le fait même de jeter des spaghettis contre le mur à titre expérimental a du sens ; savoir ce qui colle ou reste n’est pas l’essentiel. Le geste de lancer est en soi l’expérience
- Les tâtonnements, les échecs expérimentaux, les procédures qui ont fonctionné par hasard jouent le rôle de points de données dans une expérience collective
- Le système à quatre documents utilisé ici peut lui aussi perdre tout sens à tout moment, et l’essentiel est de conserver cet esprit d’expérimentation
Redéfinir ce qu’est un programme - What Even Is Programming Anymore?
En repensant à l’histoire du code, on prend conscience qu’avec les progrès de l’abstraction, nous sommes entrés dans une époque où « décrire ce que je veux » suffit pour que cela soit implémenté
- L’usage de l’IA devient plus qu’une nouvelle couche d’abstraction : il se transforme en quelque chose de radicalement différent
- Aujourd’hui, programmer demande moins la connaissance de la syntaxe, la compréhension des algorithmes ou la capacité de concevoir des systèmes, et davantage de nouvelles compétences comme une imagination concrète et l’expression précise de l’intention
- La capacité « à expliquer clairement et de manière cohérente ce que l’on veut » devient plus importante que tout
La signification philosophique du système à quatre documents - The Four-Document System as Accidental Philosophy
- Ce système à quatre documents est au fond une histoire de mémoire et d’oubli, un « enregistrement de ce qu’on ne veut pas revivre »
- Architecture Overview : « ce que j’aimerais savoir si j’étais amnésique »
- Technical Considerations : « les problèmes que je ne veux pas répéter »
- Workflow Process : « les schémas que je ne veux pas laisser m’échapper »
- Story Breakdown : « comment progresser dans une situation où l’on recommence à zéro à chaque fois »
- Tous ces documents jouent finalement le rôle de messages envoyés à mon moi futur
- En somme, ce sont des indications laissées à soi-même pour anticiper la perte d’information
Le plateau inconfortable et le débutant permanent - The Uncomfortable Plateau
Nous sommes désormais tous dans un état instable de débutant permanent, comme si tout le monde était redevenu junior developer
- Contrairement aux juniors traditionnels, la vitesse du changement technologique ne laisse même pas le temps de devenir expert
- Dans un monde où les « lois de la physique » changent sans cesse, l’adaptation et l’esprit d’expérimentation comptent plus qu’une compétence stable
- Cette incertitude est effrayante si l’on est attaché au contrôle, mais elle peut aussi être profondément libératrice si on l’accepte
Where This All Goes
Impossible de savoir ce que je construirai ensuite, quel processus j’utiliserai, ni même si je continuerai à utiliser ces quatre documents
- Tous les développeurs sont à la fois experts dans leur propre routine et débutants absolus face à de nouvelles situations
- Quand quatre jours de travail peuvent représenter plusieurs mois d’autrefois, la capacité à décrire ce que l’on veut devient la compétence décisive
- Mes quatre documents ne sont ni une recommandation ni un modèle, mais simplement une trace parmi d’autres de cette expérimentation collective
- Documentation, processus, méthodes : tout cela n’est que production temporaire, et la manière de faire des autres ne sera pas forcément votre réponse
Au fond, nous construisons tous des châteaux de sable (logiciels) à marée basse, en sachant que la vague du progrès viendra bientôt les effacer
Bientôt, quelqu’un essaiera sans doute un système à trois documents, à cinq documents, ou une approche totalement différente — et cela pourra fonctionner aussi
Conclusion
- Développer avec l’IA relève d’une expérimentation collective et d’une suite d’essais-erreurs créatifs
- Même le processus d’une semaine peut déjà devenir une relique du passé tant les choses évoluent vite
- Les traces laissées par d’autres peuvent aider, mais le plus important est que chacun forge sa propre voie
Pour finir, les quatre documents utilisés ici sont actuellement publiés sur GitHub
- Ce n’est ni une vérité absolue ni un modèle, mais le simple exemple d’une expérimentation à un moment donné
- Il est utile de s’inspirer des traces laissées par d’autres, sans avoir besoin de les suivre à la lettre
- Développer ses propres expériences et sa propre méthodologie constitue le nouvel écosystème du développement à l’ère de l’IA
4 commentaires
J’essayais de le traduire et de le poster ce week-end, mais GN+ m’a devancé 🥲
Le passage « le système documentaire n’a pas non plus été conçu dès le départ, c’est le résultat d’une accumulation improvisée » m’a vraiment parlé et m’a fait lâcher un petit rire. Haha
N’importe quoi, un type bizarre de secte qui se prend pour un maître vient poster des commentaires.
Commentaires Hacker News
Je me reconnais vraiment dans cet article. Je suis tombé par hasard sur la loi de Kidlin, c’est-à-dire l’idée que « si l’on peut décrire clairement un problème par écrit, alors il est déjà à moitié résolu ». C’est un principe extrêmement puissant à l’ère actuelle de l’IA. Maintenant que le langage naturel devient le principal moyen de communication avec la technologie, le simple fait de définir clairement un problème permet aussi de maximiser le potentiel de l’IA. L’approche du codage asynchrone est également vraiment intéressante. Personnellement, j’utilise très souvent Repl.it, et c’est un changement incroyable parce que cela me permet de me concentrer sur la résolution du problème. Quand j’utilise des outils de programmation, j’ai l’impression d’avoir ramassé une étoile ou un champignon dans Mario Kart. C’est extrêmement grisant, mais parfois l’IA part complètement dans une direction absurde, ce qui oblige à intervenir dans les décisions en temps réel. Il était déjà difficile de gérer une seule stack, et maintenant j’ai l’impression d’en affronter une infinité
Cela me rappelle souvent que, dans mon propre parcours pour devenir ingénieur logiciel, j’ai passé énormément de temps à apprendre le vocabulaire même du monde du logiciel afin de pouvoir expliquer ce que je voulais faire
Avec Repl.it, il y a des choses qui, quand tout se passe bien, se règlent en quelques minutes, mais qui peuvent aussi prendre tout un après-midi. Cela dit, il est parfois très frustrant d’essayer les suggestions sous la boîte de prompt et de voir que cela ne fonctionne pas correctement
En réalité, formuler clairement un problème a toujours été difficile, avant comme maintenant. C’est formidable d’avoir désormais des outils capables de transformer un langage naturel clair en code, mais même avec l’AGI, la nécessité de produire des spécifications claires ne disparaîtra pas. Ces outils réduiront sans doute le temps passé à se battre avec le code lui-même, mais au final, la partie la plus difficile restera l’écriture de spécifications vraiment précises
J’adore trop cette nouvelle façon de programmer. Je ne sais pas où elle va nous mener, mais pour l’instant j’en suis très satisfait. Même aujourd’hui, je produis du code à des moments où, normalement, je me reposerais, et cela ressemble presque à une forme de détente. C’est particulièrement bien pour les développeurs seniors qui ont beaucoup d’années de métier. De nos jours, le travail d’édition est surtout ennuyeux. Quand on repère un mauvais pattern dans le code, il faut souvent changer beaucoup de choses pour tester une nouvelle idée, alors qu’autrefois il fallait chercher sur Stack Overflow et se creuser la tête ; maintenant, un simple indice de Copilot, ou Claude, règle tout directement. Par exemple, j’ai créé une bourse fictive pour des échanges d’actions, et le branchement à une vraie place de marché était le genre de tâche que je repoussais souvent. Maintenant, Claude le fait pendant que je lis HN. Et si l’on ajoute l’implémentation de stratégies, même les tâches répétitives qui étaient en pratique juste ennuyeuses sont traitées immédiatement. Avant, on perdait du temps à cause des fautes de frappe, de l’ajout de dépendances, ce genre de choses, mais ce n’est plus nécessaire. On pourrait craindre que le code devienne un désastre, mais de mon côté, je dialogue toujours avec Claude tout en examinant les modifications avec un regard critique. L’expérience aide, bien sûr, et je repère assez vite quand l’IA part dans la mauvaise direction. J’ai donc rencontré ces outils au moment parfait de ma carrière. La question qui reste concerne les développeurs juniors. C’est comme grimper d’un coup au sommet d’une montagne dont l’escalier a disparu, et je me demande comment ils vont pouvoir progresser
Je partage cet avis sur les perspectives des développeurs juniors. J’approche des 50 ans, cela fait plus de 30 ans que je programme dans plusieurs domaines, et je sais m’appuyer sur mon expérience pour bien piloter des agents et construire une architecture solide. Si tout est préparé par l’IA sans cette expérience, je me demande vraiment comment les plus jeunes vont progresser. Seul le temps le dira
Moi aussi, j’utilise les grands modèles de langage avec plaisir, mais se contenter d’entrer des prompts en continu devient vite ennuyeux et même un peu anxiogène. J’ai l’impression de ne pas comprendre précisément comment le programme fonctionne. Fabriquer directement quelque chose soi-même est vraiment amusant, et je réserve les tâches répétitives déjà faites ou celles qui ne m’intéressent pas au LLM. J’ai même créé un jeu snake en terminal avec Claude, et c’était vraiment fascinant
Je me demande si vous avez réalisé vous-même qu’il n’est plus possible de revenir aux petites corvées d’autrefois. Depuis l’arrivée des LLM, j’ai beaucoup plus envie de sortir dehors pendant que je travaille. Je suis même jaloux des jeunes développeurs qui n’auront plus à vivre ces journées perdues à fixer un écran pendant 12 heures sans réussir à relier deux boîtes noires
Je me demande si, dans la pratique, vous traitez vraiment tout d’un bout à l’autre en une seule fois. De mon côté, j’implémente toujours de manière itérative et progressive, en écrivant puis en affinant. Si je devais comparer cela au dessin, je commence par une forme générale, puis j’ajoute progressivement les détails. À chaque étape, ce que je veux faire devient un peu plus clair, et c’est une manière d’obtenir le maximum d’effet avec un minimum d’effort. En code, mon style est centré sur le refactoring : je fais d’abord fonctionner le minimum, je laisse des commentaires TODO, puis j’améliore de façon itérative
Je trouve vraiment exaltant que ces outils prennent en charge des tâches ennuyeuses que j’ai déjà faites des milliers de fois auparavant
Pour moi, l’IA est le Google Search de nouvelle génération : un système qui permet de converser au-dessus de toutes les informations présentes sur Internet. De la même manière que la généralisation des moteurs de recherche a supprimé des emplois dans divers secteurs — journaux, annuaires, encyclopédies, agences de voyage, etc. — l’IA provoque aussi ce type de changement. Mais je ne pense pas que ce soit une crise existentielle aussi grave que certains l’imaginent. L’IA n’est qu’un outil. Des personnes intelligentes et créatives s’en serviront pour faire beaucoup de choses formidables. Au final, tout dépend de l’utilisateur. La recherche est devenue une conversation. Avant, on cherchait soi-même ; maintenant, on discute et l’IA cherche à notre place, voire fait davantage encore
Je ne suis pas certain que l’interface conversationnelle des LLM soit la forme optimale. Il me semble qu’il faudrait une approche plus intelligente
Contrairement à l’âge d’or de Google, on a maintenant davantage de bruit que de signal, et les sources des données deviennent floues
On a déjà l’impression que, dans les résultats Google, les déchets massivement produits par l’IA remontent avant les informations réellement utiles
Les moteurs de recherche récents donnent seulement la réponse, sans fournir le chemin qui y mène ; du coup, le rôle de ceux qui savent trouver correctement l’information et l’archiver est en train de disparaître. Si cette fonction disparaît, tout le monde finira par perdre le sens de l’orientation. Comme l’IA réutilise des informations existantes, il faut trouver un moyen de reverser de la valeur aux créateurs, en particulier aux journalistes qui font du bon travail. Sinon, il y a un vrai risque d’effondrement des bases d’une société démocratique. Le secteur de l’information est déjà en crise depuis des années, et cela s’est traduit par de la défiance, de la polarisation, de la désinformation et des manipulations extérieures. L’IA pourrait porter le coup fatal au secteur. Ce n’est pas seulement une question de remplacement d’emplois : la direction que nous prenons est très sombre
C’est clairement utile dans bien d’autres domaines que la recherche
J’aimerais faire tourner Claude Code depuis mon téléphone sur une VM cloud, pour continuer à travailler en donnant du feedback pendant une promenade ou une sortie à vélo
https://vibetunnel.sh
Le ratio entre entrée et sortie est intéressant. En général, on cherche à maximiser la quantité d’output, mais ici c’est presque l’inverse. Moi, plus que le volume maximal, je veux que le processus de travail soit découpé en étapes concrètes et vérifiables. Quand j’écris des exigences avec Cursor, cela se passe bien au début, mais il y a un problème : il génère parfois accidentellement de gros blocs de code qui s’écartent du plan. Il y a aussi de petits détails qu’il faut lui rappeler sans cesse, comme le fait d’ajouter une ligne vide après un titre Markdown. J’aimerais pouvoir contrôler davantage le processus itératif, la qualité et la cohérence. L’IA montre toute sa valeur quand on peut transformer un problème ouvert en problème fermé et testable. J’ai besoin d’un outil qui m’aide à convertir mes problèmes ouverts en problèmes fermés
À force de répéter l’expérience consistant à « entrer au bureau, tester ce que Claude a produit, puis si ça marche commit et push », j’ai l’impression qu’en tant que consultant en cybersécurité je vais pouvoir gagner énormément d’argent à l’avenir
Je ne pense pas que ce soit du vibe coding, c’est quelque chose de totalement nouveau. Moi, j’appelle ça du « flex coding ». En un après-midi, j’ai créé toute une app tout en étant un bon père. Je dis « maintenant, fais-moi l’UI de connexion au serveur », et Claude code pendant que je retourne à ma vie. Je prépare le petit-déjeuner, je joue avec mon fils, je regarde la télé, et pendant ce temps-là Claude continue de coder. Je passe juste de temps en temps, toutes les une ou deux heures, pour tester et donner du feedback
Sur le plan émotionnel, c’est extrêmement séduisant, et c’est sûrement un style de vie dont beaucoup rêvent, mais le code de Claude est-il vraiment assez fiable ? Peut-on l’utiliser pour facturer des clients ou pour un produit sur lequel on engage sa réputation ? Pour moi, la réponse est « non ». En l’utilisant moi-même, j’ai souvent vu des erreurs de référence, des copier-coller de types existants avec juste un nom changé, et des situations où il n’y avait tout simplement aucune erreur de type. Quand je lui ai demandé d’écrire des tests, il a parfois produit des tests bizarres qui, au lieu d’échouer quand ils devaient échouer, passaient simplement sa propre auto-validation. C’est très bien de passer un temps précieux avec sa famille, mais je ne recommanderais pas d’utiliser l’application que j’ai produite dans un contexte important
Cela amène aussi à se demander pourquoi payer un salaire à quelqu’un qui travaille ainsi, et pourquoi payer pour du logiciel alors que je pourrais le faire moi-même
Juste pour te prévenir : Claude risque bientôt de commencer à se plaindre que toi aussi, tu devrais faire un peu de travail
Je ressens des limites dans les outils logiciels construits autour des LLM. Il n’existe pas de moyen d’appliquer un unique system prompt global à toutes les apps fondées sur une clé OpenRouter, et il est difficile de transférer une conversation d’une application à une autre. Même fournir correctement à toutes les applications le même accès aux outils MCP n’est pas vraiment résolu. L’UX de Claude Code me semble actuellement la meilleure, mais je n’ai pas envie d’être enfermé dans l’abonnement Claude ; je veux me connecter au fournisseur de mon choix via ma propre clé
J’ai l’impression que cet article passe à côté d’éléments comme la sécurité, l’internationalisation, la localisation, l’accessibilité, l’utilisabilité, etc., qui devraient pourtant être correctement pris en compte dans les prompts. Le problème, c’est qu’il y a beaucoup trop d’amateurs qui se proclament « créateurs de logiciels » sans intégrer ces dimensions de qualité. Si elles manquent, il est impossible de réussir avec un logiciel commercial. Et si quelqu’un pense qu’il suffit de les résoudre facilement par prompt, c’est qu’il n’a pas d’expérience sérieuse dans ces domaines
Pour être honnête, même dans les logiciels commerciaux réels, il arrive souvent que ces points ne soient pas correctement pris en compte
Je reste moi aussi sceptique, mais parmi les quatre documents liés, il y a au moins ceux sur l’accessibilité et l’utilisabilité. Je ne vois pas l’internationalisation et la localisation, mais je ne pense pas que ce soit fondamentalement très différent. En revanche, la sécurité me paraît vraiment être un domaine à part
Je suis surpris qu’il y ait encore tant de gens qui croient qu’on peut faire évoluer le développement avec une logique du genre : « Mon système à quatre documents ? Au fond, ce n’est qu’un plat de spaghettis transformé en pattern, et demain tout pourrait s’effondrer. Il suffira de relancer des spaghettis contre le mur »
J’expérimente récemment le développement assisté par modèles, et je me reconnais profondément dans la partie de l’article qui demande : « Qu’est-ce que programmer ? » J’y mobilise à la fois mes 25 années d’expérience et toute ma formation en informatique, mais cela ne ressemble plus vraiment à la programmation traditionnelle consistant à écrire du code à la main. J’ai maintenant l’impression d’être moins un artisan qu’un pilote qui dirige des outils. À mon avis, les gens qui aiment le travail manuel ont de fortes chances de quitter le secteur dans les cinq prochaines années. Bien sûr, il restera encore des parties nécessitant du travail manuel, mais une nouvelle méthodologie est en train de s’ouvrir. Aujourd’hui, tout le monde ne la maîtrise pas encore, mais cela fera aussi partie de l’industrie