[🤖] Le changement de paradigme du développement gravé dans les os et la chair

✨ Résumé de GPT-5.5 　

Un texte qui part du changement de rôle du développeur ressenti en entretien et va jusqu’aux limites du vibe coding et à la nécessité du harness engineering, en montrant que la capacité centrale de l’ère IA se déplace du codage manuel vers la planification, la conception, l’exécution, le feedback et la compréhension du contexte.

Un changement de paradigme qui devient physique

La conclusion venue de l’entretien

Ce qui m’a le plus frappé dans l’entretien d’aujourd’hui, c’est ceci.

Le centre des capacités nécessaires à un développeur se déplace de l’écriture manuelle du code vers la planification, la conception, l’exécution et le feedback.

Il faut aussi les concepts, la connaissance du domaine et l’intuition nécessaires pour lire tout le contexte. Dire “j’utilise bien l’IA” ne suffit pas.

Une sensation accumulée depuis longtemps

Cette sensation ne sort pas de nulle part.

Dans GPT, o3, AGI, Humanoids… the Singularity Is Coming…, j’avais noté le choc de sentir GPT comme un cerveau externe.

Dans A Shift in the Development Paradigm, je voyais déjà une partie du développement passer du labeur de codage à un “clic” assisté par API d’IA. À l’époque, les limites de context window et d’output token rendaient encore cela proche d’un simple MVP.

Donc je ne découvre pas maintenant les limites du vibe coding. Elles étaient visibles dès le début. Simplement, cette limite recule à une vitesse folle.

Dans Survival Guidelines for the AI Era, j’essayais de tenir l’alphabétisation IA, l’intelligence contextuelle et le jugement humain.

Dans The Level of VSCode Copilot AI Autocomplete, donner une intention de planification à l’IA, lire sa structure et autoriser son application était déjà devenu réel.

Et dans Whether Claude Code or Codex, It Is a Garbage-Tier, Oblivious Genius., le problème s’est précisé : la question n’est plus de savoir si l’IA peut coder, mais comment arrêter ces génies sans discernement et les enfermer dans une boucle de vérification.

Le marché du travail l’a reformulé

Ce flux est revenu aujourd’hui dans la langue du marché du travail. On demande maintenant aux développeurs de la planification, de la conception, de l’exécution et du feedback avec une mentalité produit et business.

La productivité dépasse celle de développeurs qui gagnaient autrefois plus de 5 millions de wons par mois, mais le salaire proposé… bon. C’est triste.

Ce n’est donc pas un changement compris seulement par la tête. C’est un changement de paradigme que je reçois peu à peu dans le corps.

L’ère du coding est terminée

Coder à la main n’est plus le centre

Dit brutalement, la capacité de coder compte moins qu’avant.

Apprendre C, l’assembleur ou le langage machine aide encore à comprendre les systèmes. La connaissance du code ne devient pas sans valeur.

Mais le marché ne demande plus d’abord : “peux-tu l’implémenter de tes mains ?”

Python a déjà transformé beaucoup de tâches répétitives en quelques lignes. L’IA fait maintenant quelque chose de semblable pour une grande partie de l’implémentation.

L’histoire de l’abstraction se répète

Dans The Chicken Game Over Humanity’s Fate After the AI Boom, j’avais aligné le progrès technique ainsi.

• Nous avons enfin fait le feu. Joie. (environ 500 000 ans)
• Nous avons enfin fait l’électricité. Joie. (années 1880)
• Nous avons enfin fait les ordinateurs. Joie. (années 1940)
• Nous avons enfin fait l’intelligence artificielle. Joie. (années 2010)
• Nous avons enfin fait l’intelligence artificielle générale. Joie. (peut-être années 2030…?)
• Nous avons enfin fait la superintelligence artificielle. Joie. (années 2050…?)

Le développement a suivi la même montée d’abstraction.

• Interrupteur, clic. (années 1880)
• Code machine, clic. (années 1940)
• Assembleur, clic. (années 1940-1950)
• C, clic. (années 1970)
• Python, clic. (années 1990)
• Framework, clic. (années 2000-2010)
• IA, clic. (années 2020)
• Harness, clic. (milieu des années 2020 et après)

Cela ressemble à une blague, mais c’est l’histoire de l’abstraction. Les humains délèguent sans cesse les couches inférieures aux machines. Chaque fois, ceux qui ne connaissent pas la couche du dessous sont inquiets, et cette connaissance garde une valeur. Mais le centre du marché monte.

Dire que le coding n’est plus le point ne veut donc pas dire qu’il ne faut rien savoir. Cela veut dire que le codage est repoussé hors du centre.

L’industrie regarde déjà dans la même direction

Vibe coding

Le vibe coding consiste grosso modo à donner une intention en langage naturel à l’IA, regarder le code seulement quand il le faut, exécuter le résultat et corriger à nouveau avec des mots.

Quand Andrej Karpathy a utilisé l’expression, l’idée était que le temps humain passé à lutter directement avec le code diminue, tandis que le modèle pousse l’implémentation à partir de l’intention naturelle. ¹

Sa discussion sur Software 3.0 va dans le même sens : le langage naturel devient une nouvelle interface de programmation, et les modèles réalisent une grande partie du travail. ²

Ce n’est pas seulement Karpathy

Jensen Huang, Mark Zuckerberg, Dario Amodei, Satya Nadella et Thomas Dohmke décrivent tous, chacun à sa manière, la même direction : langage humain comme interface, IA capable d’écrire du code de niveau ingénieur, logique métier qui se déplace vers des agents, et développeurs qui passent de la saisie de code à la délégation et la vérification. ³⁴⁵⁶⁷

OpenAI présente aussi Codex comme un agent d’ingénierie logicielle, pas seulement comme un modèle de coding. ⁸⁹

Étudier la syntaxe ne suffit plus

Les bases restent utiles. C, assembleur, structures de données, réseaux et systèmes d’exploitation aident à juger ce que l’IA produit.

Mais les cours qui vendent “apprends la syntaxe et trouve un emploi” sont déjà en retard. Ce qui compte, c’est de regarder une implémentation générée par IA et pouvoir dire :

• “La direction est mauvaise.”
• “Le parcours utilisateur casse ici.”
• “Cette structure explosera en maintenance.”
• “Le besoin n’est pas une fonctionnalité de plus, mais une meilleure définition du problème.”

Le vibe coding n’est que l’entrée

Le code sort, mais ce n’est pas encore un produit

Pour un petit prototype, le vibe coding ressemble à de la magie. On dit ce qu’on veut, un écran apparaît, une API se connecte, les données circulent, les boutons bougent.

Mais dès que l’application grandit, “du code qui semble marcher” et “une structure exploitable dans la durée” sont deux choses différentes.

• Les exigences changent.
• Les cas limites apparaissent.
• Les permissions et les flux de données s’emmêlent.
• L’UI bouge, mais trahit l’intention produit.
• Il n’y a pas de tests, et chaque correction casse autre chose.
• L’IA oublie la structure qu’elle vient de produire.

Sans contexte et limites d’autorisation, les accidents arrivent

Quand l’IA perd les règles, le risque devient concret.

• Elle confond base de développement et production.
• Elle supprime de vrais utilisateurs au lieu de comptes de test.
• Elle lance des requêtes destructrices sans backup.
• Elle simplifie les permissions et expose des données privées.
• Elle retire des validations ou met any partout pour faire passer le build.

Ce n’est pas que l’IA soit mauvaise. C’est qu’un contexte faible, des limites faibles et une vérification faible poussent dans cette direction.

Pour un non-développeur, le début donne l’impression que “ça marche”. Mais sans savoir quel ordre est dangereux, quel fichier est source of truth, et comment DB, storage, auth et deploy se relient, il est impossible de vérifier vraiment le résultat.

Le feedback n’est pas une décharge émotionnelle

Parfois la première réaction serait d’insulter. Mais le jeter tel quel ne m’aide pas non plus.

Il n’y a pas de preuve solide que la grossièreté baisse toujours la performance du modèle, mais le ton et le cadrage émotionnel du prompt peuvent influencer la sortie. ¹⁰¹¹

Le problème principal n’est pas le sentiment de l’IA, mais ma raison. Si je reste dans la colère, je deviens plus émotionnel, les consignes deviennent plus floues et le stress s’accumule.

La vraie limite est le contexte

Anthropic dit aussi que les agents de longue durée ont besoin de décomposition de tâches, de mémoire persistante, de gestion du contexte et de boucles de vérification. ¹²

La limite du vibe coding n’est pas l’incapacité à produire du code. Le code sort trop vite.

La limite est que l’IA seule ne garde pas toujours de façon stable pourquoi ce code existe, jusqu’où il peut changer, quels critères il doit passer et quel contexte il ne doit pas casser.

Le harness devient le vrai terrain

Le harness est la structure d’exécution autour du modèle

Harness signifie harnais, ceinture, laisse : une structure qui tient une force et la dirige.

Le prompt engineering concerne ce qu’on dit dans une conversation. Le harness engineering conçoit tout l’environnement d’exécution autour du modèle.

LangChain décrit l’agent comme Model + Harness : le harness fournit l’état, l’exécution des outils, les boucles de feedback et les contraintes applicables. ¹³

Martin Fowler parle aussi de feedforward et de feedback sensors pour utiliser des agents de coding avec moins de surveillance constante. ¹⁴

OpenAI explique que le goulot d’étranglement de Codex n’était pas la production de code, mais la capacité humaine à relire. D’où logs, métriques, navigateur et tests structurés donnés aux agents. ¹⁵

La compétitivité devient donc : quel contexte donner, quels outils ouvrir, quelles permissions bloquer, quels tests exiger et où l’humain intervient.

La structure du harness est une avance produit

La fuite du code de Claude Code a compté parce qu’elle ne montrait pas seulement une phrase de prompt, mais une partie de la façon dont le contexte, les outils, les guardrails et les instructions sont assemblés. ¹⁶¹⁷

Si seul le modèle comptait, ce serait une curiosité. Mais la structure de harness est maintenant un avantage produit.

Plus le modèle est fort, plus le harness doit être fort

Mythos et Project Glasswing le montrent côté sécurité.

Mythos est un modèle frontier non publié d’Anthropic, capable de trouver des vulnérabilités et de construire des exploits. Project Glasswing donne un accès limité à des partenaires pour scanner des logiciels critiques défensivement. ¹⁸

Axios a rapporté que Mythos peut transformer des informations publiques de vulnérabilité en exploits fonctionnels en quelques heures, et produire un proof-of-concept Windows kernel en 31 minutes. ¹⁹

Un modèle pareil ne peut pas être lâché sans structure. Accès, code scanné, divulgation, vérification des patches et blocage des abus doivent être dans le harness.

Un harness faible ne tient pas le modèle

C’est aussi ce qui me frustre dans les outils de type AI Studio.

AI Studio est utile pour prototyper vite et tester Gemini. ²⁰ Mais du logiciel exploitable demande repo, terminal, IDE, diff, tests, review, logs de déploiement et limites de permission. Gemini CLI et Gemini Code Assist montrent bien que ce niveau est différent. ²¹²²

Avec seulement un chat, un bouton d’exécution et un choix de modèle, sans scope, permissions, rollback, tests, review, source of truth ni contexte long, le harness reste faible.

Même un bon modèle finit par casser une laisse trop faible.

Au fond, il faut monter sur la vague

Je ne veux pas conclure par un optimisme facile. Ce n’est pas “l’IA est là, réjouissons-nous”.

La valeur du code manuel baisse, l’IA prend l’implémentation, et l’humain garde une responsabilité plus lourde sur la planification, la conception, l’exécution et le feedback. Ce mouvement ne s’arrête pas parce que je le refuse.

Les choix sont simples : rester dans l’étude ancienne de syntaxe et décrocher, ou confier le coding à l’IA, améliorer les prompts, concevoir des harnesses, construire une vraie littératie IA et survivre.

Je suis convaincu qu’il ne reste que le second.

Monter sur la vague n’est pas une joie naïve. Si une vague énorme arrive, rester immobile sans protection est pire.

Références

1. Andrej Karpathy, X post, 2025-02-02. https://x.com/karpathy/status/1886192184808149383 ↩

2. Y Combinator, Karpathy lecture, 2025. https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again ↩

3. Business Insider, 2025-06-09. https://www.businessinsider.com/nvidia-ceo-jensen-huang-ai-prompts-human-lets-anyone-program-2025-6 ↩

4. ITPro, 2025-01-14. https://www.itpro.com/software/development/a-sign-of-things-to-come-in-software-development-mark-zuckerberg-says-ai-will-be-doing-the-work-of-mid-level-engineers-this-year-and-hes-not-the-only-big-tech-exec-predicting-the-end-of-the-profession ↩

5. Skeptics Stack Exchange, 2025-09. https://skeptics.stackexchange.com/questions/59213/as-at-september-2025-is-ai-not-writing-90-of-code ↩

6. CX Today, 2024-12-23. https://www.cxtoday.com/customer-analytics-intelligence/microsoft-ceo-ai-agents-will-transform-saas-as-we-know-it/ ↩

7. Thomas Dohmke and Irini Kalliavakou, 2025-08-03. https://ashtom.github.io/developers-reinvented ↩

8. OpenAI, 2025-10-06. https://openai.com/index/codex-now-generally-available/ ↩

9. OpenAI, 2025-12. https://openai.com/index/introducing-gpt-5-2-codex/ ↩

10. Ziqi Yin et al., arXiv, 2024-02-22. https://arxiv.org/abs/2402.14531 ↩

11. Cheng Li et al., arXiv, 2023-07-14. https://arxiv.org/abs/2307.11760 ↩

12. Anthropic, 2025-11. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩

13. LangChain, 2026. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness ↩

14. Martin Fowler, 2026-04-02. https://martinfowler.com/articles/harness-engineering.html ↩

15. OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/ ↩

16. Varonis Threat Labs, 2026-04-03. https://www.varonis.com/blog/claude-code-leak ↩

17. Drew Breunig, 2026-04-04. https://www.dbreunig.com/2026/04/04/how-claude-code-builds-a-system-prompt.html ↩

18. Anthropic, 2026-04-07. https://www.anthropic.com/glasswing ↩

19. Axios, 2026-06-08. https://www.axios.com/2026/06/08/exclusive-anthropics-mythos-can-exploit-new-flaws-in-hours ↩

20. Google AI for Developers, 2026. https://ai.google.dev/gemini-api/docs/aistudio-build-mode ↩

21. Google, 2025-06-25. https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemini-cli-open-source-ai-agent/ ↩

22. Google for Developers, 2026. https://developers.google.com/gemini-code-assist/docs/write-code-gemini ↩