Le bonheur est dans le prompt (non)

Le travail du dev se résume-t-il à interroger un programme comme ChatGPT, Perplexity ou LeChat, puis à copier-coller la réponse dans son éditeur ? Si on écoute la petite musique actuelle de l'innovation numérique, c'est le futur radieux qui se dessine pour l'ensemble des développeurs.

Utiliser un langage de programmation reste un moyen sûr de créer un programme et d'obtenir le comportement souhaité. La génération de code est séduisante mais ne me convainc pas.

La promptomanie, ou la manie de prompter excessivement

La tech chante la gloire éternelle des agents intelligents construits sur les grands modèles de langage (LLM). Une foule de gens, souvent ignorants, nous explique à longueur de tribunes que des professions pourraient bientôt se réduire à l'enchainement de quelques prompts bien sentis : création d'image, rédaction et maintenant programmation informatique. C'est fatiguant. La semaine dernière, dans le New York Times, un papier faisait récemment l'éloge de cette transformation et du vibecoding.

Le vibecoding est un terme popularisé par le chercheur en IA Andrej Karpathy. Cette technique désigne la manière dont les outils d'IA permettent aujourd'hui même à des amateurs, qui ne savent pas coder, de créer des applications et des sites web entièrement fonctionnels, à l'aide de prompts. Il n'est pas nécessaire de savoir coder pour faire du vibecoding - il suffit généralement d'avoir une idée et un peu de patience. Kevin Roose, Not a Coder? With AI, Just Having an Idea Can Be Enough.

Et de continuer :

Ces outils ne changent pas le monde en soi. Ce qui est nouveau et remarquable, c'est qu'em quelques touches, les amateurs peuvent désormais construire des produits qui auraient auparavant nécessité des équipes d'ingénieurs. [...] Je crains que l'ingénierie logicielle ne soit que la première profession dite cols blancs à subir les effets de remplacement de la main-d'œuvre par les outils d'intelligence artificielle. Mais pour l'instant, créer des applications pour automatiser les tâches ennuyeuses ou chronophages de ma vie me semble être une aussi bonne utilisation de l'IA que n'importe quelle autre. Je vais donc continuer à faire du vibecoding. Kevin Roose, see above

Gary Marcus, sorte d'alter-ego américain, l'a promptement remis à sa place dans un court debunking. Je garde cette saillie :

Il va sans dire que l'art du code consiste généralement à construire quelque chose de nouveau. Ici, Roose a commis le péché capital de ne s'intéresser qu'à la régurgitation plutôt qu'à la généralisation. Gary Marcus

La fin du code, vraiment ?

Le travail de développement informatique peut-il se réduire à l'interrogation d'un agent conversationnel ? La programmation est-elle soluble dans la GenAI ? Allons-nous faire IA-remplacer ?

... en passant, juste une précision : la génération de contenu (texte, image) ne relève désormais plus de l'IA, puisque cette technologie fonctionne ...

99.99% du code est déjà écrit par des programmes

Les programmes ne sont plus écrits dans un langage exécutable nativement par un processeur. À moins d'être particulièrement masochiste ou extrêmement compétent, les développeurs écrivent leur code dans un langage de haut niveau (ex: C, Java, Python, etc) et le compilent en un code machine comprend le processeur. Ils utilisent un ... programme, appelé compilateur. Nos programmes sont donc déjà écrits par des programmes.

Le processus est en réalité plus compliqué : la compilation peut se faire en plusieurs étapes avec des langages intermédiaires, certains langages sont interprétés, et autres finasseries techniquement passionnantes et extrêmement complexes, mais ce n'est pas le sujet.

Faut-il encore apprendre à programmer ?

Doit-on encore écrire des programmes, ou peut-on faire écrire ces programmes directement par d'autres programmes ?

Prompter, c'est écrire un texte où on décrit ce que le programme doit faire, sans écrire directement ce programme. On formule ce qu'on souhaite générer, en s'exprimant dans un langage naturel (ex: anglais, français). Il faut être très spécifique pour contrôler au mieux la génération - ou très chanceux.

Expliquer ce qu'on veut faire faire à un programme, c'est programmer. Il faut s'exprimer de manière très précise. En informatique, les doubles sens sont des blasphèmes, les flous sont interdits, les non-dits sont bannis. Le langage naturel n'est donc pas adapté, car il est trop souple, trop imprécis, trop ambigü. Inversement, on ne pense pas le Bateau Ivre en Lisp ou en ALGOL.

Les langages de programmation sont utilisés pour faire exécuter des tâches à un ordinateur, dans l'ordre souhaité. Le lecteur dubitatif ira explorer 70 ans d'histoire de la programmation informatique, dans une de ces références.

Penser qu'on triomphera en enchaînant des prompts est une ineptie

Pourquoi perdre son temps à générer un programme alors qu'on peut simplement l'écrire ?

Un programme, c'est d'abord un code source. Un code source, c'est comme une maison : sans structure saine, sans fondation, ça s'écroule. On ne peut rien construire sur du sable. C'est trivial ? C'est surtout crucial, pour douze mille raisons différentes.

Je vais donner trois raisons principales.

Pour écrire un programme :
1. formuler un problème ;
2. comprendre ce problème ;
3. résoudre ce problème.

Jusqu'à preuve du contraire, remplir ces trois conditions nécessite un cerveau et des milliers d'heures de pratique. Comprendre ce qu'on fait est généralement une bonne stratégie.

Il se trouve que les systèmes de génération actuels, s'ils sont impressionnants, montrent une limite dure : ‪malgré les discours technophiles et optimistes, ces programmes ne comprennent rien. Ce n'est pas leur fonction. Ils sont aujourd'hui entrainés à répéter et assembler des trucs de manière complexe. Ils ne sont pas entraînés à comprendre. Or, c'est un pré-requis pour concevoir un programme : il faut comprendre ce qu'on veut faire.

Accumuler du contexte ne fait pas tout

Oui mais plus tard on aura un contexte énorme, avec des millions de token, on pourra faire trop de trucs.

Les systèmes génératifs actuels ne peuvent pas tout absorber. Ils ont un contexte limité. C'est une limite technique. Ce contexte est fourni lors du prompt, ou des prompts successifs. En Février 2025, ce contexte est limité à une centaine de milliers de token (~mots). D'ici quelques années, le contexte sera probablement suffisant pour fournir un ensemble de spécifications à un LLM et lui demander de générer un programme entier. Peut-être.

Tu peux générér ce que tu veux, lapin, si tu ne comprends pas ce que tu génères, tu finiras dans le ravin.

Oui mais on pourra donner tout le code à une IA pour regénérer une structure saine.

Restructurer, simplifier, améliorer ? Peut-être. Qui veut tenter l'aventure ? Qui maintiendra le code ? Qui corrigera les bugs ?

Et pourtant, les programmes de demain seront générés !

Un programme conséquent ne devrait pas être écrit par un système qui colle, assemble, bluffe. Un programme conséquent ne devrait pas être généré à partir de notre langage flou et ambigü d'humains souples et ambigüs.

C'est pourtant ce qu'il va se passer. Parce que les gens qui allouent les budgets n'ont aucune putain d'expérience en conception ou en implémentation de programmes (prove me wrong). La réduction des coûts à court terme sera le grand moteur de ce bazar, comme d'hab'. Tant pis pour les juniors.

Le marché a besoin de se manger une claque

Elle sera forte.
Et qui devra reprendre la conception de ces programmes générés ? Mmmh ?

Préparez les budgets.
Corriger les bugs et inepties d'un programme généré par un agent dit intelligent, ça se paiera au prix fort.
J'annonce des dettes techniques extraordinaires.

Créer un programme non trivial requiert (encore) la présence d'un cerveau

Il n'y a, à nos yeux, aucune raison de faire suffisamment confiance aux outils de génération pour leur confier des tâches qui, habituellement, requièrent la présence d'un cerveau fonctionnel.

Les ordinateurs sont de bons serviteurs, très efficaces, mais je n'ai aucune envie de les servir. Capitaine Spock, USS Enterprise

Un autre billet sur le même thème, avec un angle un peu différent : The Death of the Junior Developer et la suite The Revenge of the Junior Developper.

Thomas

Nous ne sommes toujours pas des machines. Nos textes sont pensés et écrits par des humains. Aucun texte n’est généré. Tout soutien sera le bienvenu.