Météo du jour - Déléguer son temps de pensée ?
Bonjour, c'est la météo du jour.
Caen: 🌧 +24°C Lille: ☀️ +29°C Marseille: ☀️ +31°C Paris: 🌩 +29°C Toulouse: ☁️ +28°C
En ce moment, il fait chaud mais moins que la semaine dernière. Et on n'est pas mal à Caen, avec cette bonne fraîcheur que la France nous envie.
----
Et ce matin en lisant un thread de collègues, j'ai pensé au point suivant : quand on utilise la gen AI pour écrire du code, ou pour comprendre du code, alors on délègue du “thinking time per line of code” à la machine, à une techno qui a un taux d’erreur non négligeable.
Ce qui m'a fait penser que : vérifier ce qu’a fait la machine devient d’autant plus important. Ici, des pratiques comme TDD ou des tests automatisés, des pratiques craft, enfin tout ce qui peut nous aider habituellement à vérifier que le code fonctionne comme attendu va rester très utile.
Cette notion de "tinking time per line of code" me rappelle aussi que, avant la gen AI je trouvais déjà que dans mes équipes, moi y compris, on avait un "thinking time per line of code" beaucoup trop bas et qu’on gagnerait à l’augmenter. Je ne sais pas évaluer l’influence de cette délégation supplémentaire sur ce point, elle dépend de la qualité du "thinking time per line of code" de la gen AI (qui bien sûr ne pense pas, mais qui délègue à son tour au thinking time qui a été dépensé pour créer ses données d’entraînement).
Bien sûr, si on délègue son temps de pensée sur l'écriture des lignes de code, ça nous libère du temps de pensée pour autre chose. On peut donc y trouver son compte. Le point qui m'intéresse ici est que ce temps de pensée qu'on a gagné pour écrire notre code nous obligera probablement à utiliser ensuite la gen AI pour lire notre code.
Alors : avec cette délégation on se crée une dépendance à l'outil gen AI. Outil dont je ne sais pas prédire si les montages financiers exotiques qui soutiennent sa croissance hors du commun sont pérennes, et dont je ne sais pas prédire l’évolution de la tarification. S’ajouter cette dépendance c’est faire un pari sur l’avenir ⇒ d’un point de vue stratégie d’entreprise ça me donnerait envie d’évaluer les risques d’un éclatement de bulle ou d’une augmentation forte du tarif. Ce que je ne sais pas faire. Si vous avez vu passer des évaluations de ce genre de risques ça m’intéresse.
Ensuite il y a les aspects environnementaux et sociaux qui me posent question, mais j’ai l’impression que c’est compliqué d’en parler car ce que je lis n’est pas optimiste et est clivant, et je n’ai pas l’énergie pour en discuter ici.
----
Bonus : je pense aussi à l'essai "Programming as Theory Building" :
Peter Naur’s classic 1985 essay “Programming as Theory Building” argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code.