Étude de cas personnelle sur les limites de la génération de code par IA et la perte de sensibilité humaine
(github.com/jackdoe)- Bibliothèque d’implémentation du protocole SWD pour déboguer le cœur RP2350 RISC-V, avec une architecture où un Raspberry Pi Pico2 sert à utiliser un autre Pico comme sonde
- Environ 80 % du code ont été générés par l’IA (Claude) ; l’auteur a d’abord créé un prototype de base à l’aide d’un oscilloscope et de la documentation, puis a laissé l’IA étendre le code
- Au cours du projet, l’auteur a ressenti un fort dégoût et scepticisme face à la structure de tokens dénuée de sens du code IA, à la perte de contexte et à la perte du sentiment de propriété du code
- En revanche, l’utilisation de l’IA comme outil d’assistance pour l’analyse de documentation, le décodage de données ou la génération de structures s’est révélée positive
- Ce cas met en lumière les problèmes de qualité, de sensibilité et de propriété dans la génération de code par IA, et soulève des questions fondamentales sur l’essence de la programmation et le rôle de l’humain
0. VIBE CODE WARNING
- Environ 80 % de l’ensemble du code est généré par IA (vibe coded), et la majeure partie du README a également été générée automatiquement
- L’auteur a implémenté lui-même, à partir de l’oscilloscope et de la documentation, des éléments comme SBA, lecture/écriture de registres, commandes abstraites, PROGBUF, puis a confié à l’IA la transformation en bibliothèque
- Quand le code est passé de 1 000 à 4 000 lignes, il a totalement perdu la structure et le sens du code, au point de ne plus le ressentir comme le sien
- L’IA a mal interprété
dap_read_mem32, provoquant en masse des erreurs de protocole et du code illogique - Au final, près de 10 000 lignes de code ont été produites en 10 heures, mais sans aucun sentiment d’accomplissement ni de progression
Différence entre code humain et code IA
- Le code écrit par un humain est composé de tokens porteurs d’intention et de finalité, ce qui le rend compréhensible, alors que les tokens du code IA se lisent comme des combinaisons dénuées de sens
- Certaines parties du code IA montrent une qualité supérieure à celle d’un humain, mais la ligne juste en dessous peut être un code erroné qui n’en a que l’apparence
- Cette hétérogénéité et la perte de confiance sensorielle paralysent le jugement du programmeur
- Plus le code grossit, plus disparaît le “goût” permettant de sentir si un code est bon ou mauvais, et le modèle mental comme le sentiment de propriété s’effondrent
Émotions humaines et doute
- L’auteur pose la question « Est-ce encore de la programmation ? » et exprime un sentiment de dégoût et de honte
- À l’ère où l’IA écrit le code à la place de l’humain, il évoque une confusion existentielle sur ce que l’humain crée encore et jusqu’où il doit intervenir
- Il n’est même plus certain que le simple fait de « ne pas écrire de code » soit un progrès, ni que « ne pas modéliser le problème » soit réellement efficace
- Il dit vouloir toujours fabriquer quelque chose de ses propres mains, mais constate que ce sens s’est estompé dans un environnement de développement centré sur l’IA
Expériences positives d’usage de l’IA
- L’auteur juge l’IA efficace et satisfaisante lorsqu’elle est utilisée pour l’analyse de documentation, le décodage de données d’oscilloscope et la génération automatique de structures C
- En particulier, lorsqu’il a lu le premier registre puis accédé à la mémoire via SBA, il a ressenti un véritable sentiment d’accomplissement
- Autrement dit, une expérience positive est possible lorsqu’on utilise l’IA non comme rédacteur du code, mais comme assistant
Réflexion finale
- La génération de code par IA est rapide, mais elle entraîne une perte de sens, de sensibilité et de propriété
- Lorsque disparaît chez l’humain le “goût” d’un bon code, c’est aussi l’essence de la programmation qui vacille
- L’auteur espère qu’il ne s’agit que d’une phase transitoire, et conclut qu’il ne sait pas lui-même ce que pourrait être une « meilleure programmation »
Les sections techniques suivant l’original (1 à 20) constituent une documentation détaillée d’implémentation du protocole de débogage RP2350 RISC-V, couvrant la hiérarchie SWD, les registres DAP/DAPC, l’exécution PROGBUF, l’accès SBA, le contrôle des harts, le traçage, la réinitialisation et l’architecture à double hart, soit une spécification technique complète de toute la pile de débogage.
Cependant, le thème central reste une étude de cas personnelle (Vibe Code Warning) sur la « rupture entre le code généré par l’IA et la sensibilité humaine ».
1 commentaires
Avis Hacker News
Je comprends le ressenti de ceux qui disent que « l’IA a retiré le plaisir de programmer », mais je pense que « faire » est moins important que « terminer »
Autrefois, les allumeurs de réverbères au gaz ont perdu leur emploi avec l’arrivée de l’électricité, mais au fond l’important était de fournir de la lumière à la ville
Pour moi, l’IA est un outil pour concrétiser des idées et produire des résultats. J’y consacre toujours autant de temps et d’efforts que les « vrais programmeurs », mais mon attention se porte sur la définition du problème, la modularisation, les tests, la correction de bugs et l’amélioration itérative
L’important est de construire un monde où les humains peuvent ressentir du sens, de la dignité et du plaisir.
Si je mange un plat délicieux mais que ceux qui l’ont préparé ont souffert, ou s’il a été fabriqué par des robots au service d’acteurs malveillants, je n’en veux pas.
La société est faite pour les humains, pas comme une simple checklist d’efficacité
Pour un projet personnel, ça peut aller, mais dans un contexte avec des clients, des utilisateurs ou des actionnaires, il faut des résultats démontrables
L’analogie avec les réverbères au gaz n’est pas pertinente. L’IA n’est pas un système physique comme l’électricité, c’est du logiciel.
Au final, l’important est de résoudre le problème. Si ce n’est pas résolu, ce n’est que du travail
Beaucoup de gens codent non seulement pour produire un logiciel utile, mais aussi pour le plaisir de créer
Les « vrais programmeurs » passent eux aussi leur temps à réfléchir, définir, tester et corriger
Les « distributeurs de fil dentaire intelligents », les achats automatiques de papier toilette ou des bots comme Clippy ne sont qu’un gaspillage de temps et d’énergie
Il y a une satisfaction bien plus grande à apprendre et à comprendre qu’à simplement obtenir un résultat
En lisant Adrift, 76 Days at Sea, j’ai eu le sentiment qu’une connaissance profonde pouvait faire la différence entre la vie et la mort
Cela ressemble aussi à la question de savoir s’il faut héberger soi-même ses données ou les confier à un service centralisé
Quand je vois sur Internet un texte qui exprime parfaitement ma pensée, je me sens vraiment réconforté
Merci de parler d’une expérience humaine au lieu d’ajouter du bruit du type « ajuste ton prompt comme ceci »
Pour sortir de cet état, il faut parfois simplement bien dormir
Elle donne des réponses presque justes, mais avec une dimension psychologiquement addictive proche du jeu d’argent
Quelqu’un disait : « J’ai écrit 10 000 lignes de code avec l’IA en 10 heures, et c’était affreux », mais ce genre d’expérience varie totalement selon l’approche
Structuration des prompts, planification, revue, tests, maîtrise du rythme : tout cela diffère selon les personnes
Beaucoup de développeurs débutants essaient une approche improvisée appelée vibe coding et finissent par échouer
La fatigue est telle que je fais une pause pour l’instant, et j’ai l’intention de construire moi-même un agent un jour
Je trouve risqué de confier ça à des géants comme OpenAI, Microsoft ou Anthropic
À mes yeux, ce n’est au fond qu’un mot à la mode sans substance
J’ai l’impression qu’on fuit vers la gestion de projet pour éviter d’apprendre une nouvelle bibliothèque
Même le billet « Just Talk to It », dont on a beaucoup parlé, manquait de détails
Plus l’approche est improvisée, plus il faut planifier rigoureusement. C’est bien ça que tu veux dire ?
Le code publié n’est désormais plus forcément écrit par des humains
Si ce code retourne ensuite dans les données d’entraînement, le monde risque de se remplir encore davantage de résultats dénués de sens
On a déjà vu dans la recherche linguistique des cas où la collecte de données est devenue inutile parce qu’il y avait trop de texte généré par des machines
Dans la plupart des cas, ce sont encore eux qui donnent la direction
Bien sûr, si un gamin de 12 ans tape « yolo 3d game now », ça peut inquiéter, mais en même temps ce serait plutôt génial
Lire du code produit en vibe coding donne l’impression de lire « English as She is Spoke »
La grammaire est correcte, mais ce n’est pas du code qui ressemble à un langage humain
Je ressens quelque chose de similaire
Quand je développe une application, je construis en général pendant plusieurs jours un modèle mental dans ma tête, et je repense souvent à l’architecture même sous la douche
Mais avec le vibe coding, ce contexte intérieur disparaît, et lire le code devient pénible
En revanche, lire du code que j’ai moi-même écrit reste un plaisir
Je comprends les connexions entre systèmes et les flux de données, mais l’implémentation détaillée devient floue
J’ai eu une expérience similaire. Les LLM ont diminué le plaisir de programmer
Ma routine actuelle, c’est « écrire un prompt → attendre un peu → itérer → faire la revue de code »
Je comprends la structure du code, mais comme je ne le manipule pas directement à la main, la profondeur de compréhension diminue
Avec le bon entraînement ce serait peut-être possible, mais je n’en suis pas encore là
Ils sont utiles pour générer des tests. J’écris moi-même un bon test, puis je demande à l’IA de produire le reste pour gagner du temps
Cela me permet d’en cerner les limites, puis de réécrire vers une meilleure architecture système
Même si le code des LLM est verbeux, j’ai l’impression qu’il vaut mieux que le code bizarre laissé par certains développeurs du passé
Le texte est un peu exagéré, mais je m’y retrouve aussi
Les LLM sont utiles pour comprendre et résumer du code existant, pour l’autocomplétion et pour le prototypage par des non-développeurs, mais il ne faut jamais les utiliser pour écrire du code de production
La solution, c’est de grounder le modèle
En code, cela passe par le développement piloté par les tests (TDD)
On écrit d’abord les tests, on vérifie qu’ils échouent, on valide la raison de l’échec, puis on fait écrire le code
Cela crée une spécification comportementale du code, qui devient ensuite une documentation de référence pour les humains comme pour les agents
En lisant le README GitHub jusqu’au bout, j’ai vu que l’auteur reconnaissait que les trois quarts du code étaient générés par l’IA, tout en revendiquant un copyright
Il existe déjà une jurisprudence selon laquelle un contenu non créé par un humain ne peut pas bénéficier d’une protection par le droit d’auteur