"Le code est résolu" ? Le bug qui scintille dit non

"Le code est résolu" ? Le bug qui scintille dit non

Voici ce que personne qui pousse la ligne "le code est résolu" ne veut mettre à côté de son slide deck : l'outil de codage IA le plus discuté au monde a été livré avec un bug de scintillement d'écran, et il a fallu environ un an de correctifs, un rollback, et finalement un workaround-qui-est-toujours-derrière-un-feature-flag avant que quiconque puisse le considérer comme réglé.

Pas un problème matériel. Pas un problème d'infrastructure. Pas une obscure race condition de systèmes distribués nécessitant une équipe de recherche. Un bug de redessin de terminal. Le genre de truc qu'un ingénieur compétent règle en un après-midi — sauf que celui-ci a survécu à deux générations de modèle.

Je veux m'arrêter sur cet écart un instant, parce que c'est l'argument en entier.

L'histoire que j'entends sans cesse — sur X, dans les podcasts, dans ces threads essoufflés "l'ère de l'ingénieur logiciel touche à sa fin" — va comme ça : le prompting manuel est mort, coder est fondamentalement un problème résolu, et le mouvement intelligent maintenant est d'arrêter d'écrire du code et de commencer à écrire des boucles qui font tourner une IA à travers des cycles de prompts jusqu'à ce qu'une condition de victoire soit atteinte. Le difficile qui reste, dit l'histoire, c'est l'infrastructure, le feedback utilisateur et le matériel. Coder ? C'est la partie facile. C'est fait.

J'utilise des outils de codage IA chaque jour. Je ne suis pas là pour vous dire qu'ils ne marchent pas — ils marchent absolument, et je vous montrerai exactement où. Mais "le code est résolu" est le genre d'affirmation qui sonne intelligent dans une keynote et s'effondre dès que vous pointez les reçus. Et le reçu le plus net que j'ai est un bug si ennuyeux qu'il fait presque le point tout seul.

Allons-y.

Ce que "le code est résolu" affirme réellement (et qui le dit)

Avant de contester une position, je veux la formuler aussi fort que les personnes qui la tiennent le feraient. Steelmanning d'abord. C'est la seule façon honnête de faire ça.

La version la plus complète de l'argument vient de l'intérieur d'Anthropic même. Boris Cherny — le créateur de Claude Code — a dit dans des interviews mi-2026 que l'IA a pratiquement résolu le codage, et qu'il n'avait pas écrit une ligne de code à la main depuis huit mois (Fortune, juin 2026). Le cadrage qui s'est développé autour est encore plus tranchant : arrêtez de prompter Claude un message à la fois, dit l'argument — construisez des boucles. Construisez un harnais qui laisse le modèle observer, planifier, agir et réfléchir pendant des heures, parfois des jours, itérant contre des tests et des métriques d'acceptation jusqu'à ce qu'il converge vers un état d'approbation (l'analyse d'explainx.ai sur la thèse du harness engineering).

Dans cette vision du monde, le travail de l'humain change. Vous n'écrivez pas des fonctions. Vous écrivez la fonction de scoring — la condition de victoire — et la boucle avance vers elle. Choisir un meilleur modèle c'est optimiser la mauvaise variable ; construire une meilleure infrastructure de feedback est le vrai jeu. J'ai moi-même écrit sur la mécanique de cette approche dans ma propre analyse des harnais d'agents de longue durée, et je le dis franchement : comme technique, c'est réel et c'est puissant.

Puis il y a le chiffre que tout le monde cite. Anthropic a rapporté que les lignes de code mergées par contributeur actif ont atteint environ 8x la baseline pré-2025 d'ici Q2 2026 — cadré dans certains récits comme "deux ans de production de code, chaque trimestre, par personne" (OfficeChai). D'ici mai 2026, Claude aurait écrit plus de 80% du code de production mergé en interne (VentureBeat).

C'est un ensemble d'affirmations véritablement stupéfiant. Si je m'arrêtais ici, vous fermeriez l'onglet convaincu que coder était terminé.

Alors pourquoi ne suis-je pas convaincu ? À cause d'un détail enterré dans l'annonce même d'Anthropic — et à cause d'un bug. Prenons d'abord le détail.

La réserve qu'Anthropic a mise dans sa propre note de bas de page

Voici quelque chose que les fils de hype n'incluent presque jamais, et c'est la phrase la plus honnête de toute la conversation.

Quand Anthropic a publié le chiffre de 8x, le propre billet de blog de l'entreprise a mis en garde que le nombre était "presque certainement une surestimation", parce que compter les lignes de code récompense le volume, pas la qualité — et les comptages de lignes par PR ont dû être plafonnés au 99e percentile juste pour filtrer les commits aberrants (comme rapporté dans la couverture de productivité).

Relisez ça. L'organisation qui fait l'argument le plus fort de "le code est résolu" a attaché un avertissement à sa propre métrique titre. Les lignes de code sont un proxy notoirement cassé — tout ingénieur qui est dans le métier depuis assez longtemps sait que plus de code est souvent pire, pas mieux. Un outil qui vous laisse générer huit fois le diff n'est pas évidemment un outil qui a résolu le codage. C'est peut-être simplement un outil qui a résolu la frappe.

Et c'est la couture que je veux tirer. Parce qu'il y a une différence entre trois affirmations qui se mélangent quand les gens disent "le code est résolu" :

1. L'IA accélère la production de code. Vrai. Évidemment, mesurément vrai.
2. L'IA améliore la qualité du code quand elle est bien utilisée. Souvent vrai, avec de vraies réserves.
3. Coder, comme problème humain difficile, est terminé. C'est le saut. Et il ne survit pas au contact avec les preuves.

Les deux premiers sont de vraies avancées. Je me battrais avec quiconque dirait à un dev junior d'ignorer ces outils. Mais la troisième affirmation — celle du terminé — c'est là que le marketing dépasse la machine. Et la preuve n'est pas une objection philosophique sur la créativité ou l'artisanat. C'est beaucoup plus embarrassant que ça. C'est un scintillement.

Le bug de scintillement que personne n'a pu corriger discrètement

Si coder était résolu — si vous pouviez simplement pointer une boucle sur un problème et la laisser avancer vers une condition de victoire — alors l'équipe de codage IA la mieux équipée de la planète, faisant du dogfooding de son propre outil, écrivant 80% de son code avec le modèle même en question, devrait pouvoir écraser un bug de rendu de terminal sans broncher.

Ce n'est pas ce qui s'est passé.

Claude Code est une application terminal — du codage IA agentique qui vit dans votre ligne de commande, sorti en février 2025. Depuis le début, il avait un problème notoire de scintillement d'écran. Le contenu du terminal défilait rapidement, tremblait et flashait du texte d'avant dans la session — causé par le renderer qui redessinait tout le buffer du terminal à chaque mise à jour de streaming au lieu de faire des mises à jour incrémentales par ligne. Vous pouvez suivre la trace vous-même à travers un cimetière d'issues GitHub : #769, et une longue traîne de suivis comme #16939, #18084, et #18827, couvrant Windows Terminal, VS Code, Cursor, et les terminaux intégrés d'Android Studio.

Maintenant observez la chronologie, parce que la chronologie est l'argument :

• Début 2025 et au-delà : Scintillement signalé à répétition. Particulièrement brutal dans les terminaux basés sur xterm.js (VS Code, Cursor), où le redessin complet du buffer 2–3 fois par seconde faisait stroboscoper l'écran.
• Vers décembre 2025 : Anthropic l'adresse publiquement, prétendant selon les rapports une grande réduction du scintillement avec un renderer différentiel réécrit — environ un tiers des sessions voyait encore au moins un scintillement, selon les rapports de la communauté du déploiement.
• Peu après : Instabilité. Un changement de rendu sans scintillement a été déployé, et une régression a suivi — issue #41965 documente comment le rendu "sans scintillement" en écran alternatif de v2.1.89 détruisait le scrollback du terminal par défaut. Le correctif a créé un nouveau problème. Les choses ont été annulées. Fin 2025 : toujours pas résolu proprement.
• Vers le 1er avril 2026 : Un "no flicker mode" arrive — CLAUDE_CODE_NO_FLICKER=1 — utilisant une approche de buffer d'écran alternatif, le même truc que Vim utilise quand il prend le contrôle de votre terminal et le rend intact quand vous quittez (piunikaweb). Ça marche. Mais c'est un contournement, pas un correctif de cause racine : ça évite le problème de redessin en rendant ailleurs entièrement. Et ça a été livré comme un research preview, derrière un feature flag, avec un flag compagnon pour désactiver la capture de souris parce que ça introduisait sa propre friction.
• Fin mai 2026 : Une interface terminal plus récente affichait encore des messages d'erreur peu informatifs, "mystérieux" — la gestion des erreurs elle-même pas polie.

Un ingénieur indépendant a titré son analyse "Le correctif qui a mis un an à arriver." Quelqu'un d'autre a sorti un patch tiers appelé Claude Chill juste pour gérer le scintillement, et il a atteint la page d'accueil de Hacker News. Quand les utilisateurs construisent des outils externes pour corriger votre rendu, le rendu n'est pas résolu.

Voici pourquoi ce seul bug porte autant de poids : il n'y a pas d'excuse matérielle. Pas d'excuse d'infrastructure. Pas d'échappatoire "la vraie partie difficile est ailleurs". Le scintillement d'écran dans un terminal est un problème logiciel pur et autonome — exactement la catégorie dont le récit "le code est résolu" dit qu'elle est la partie facile, la partie terminée. Et il a fallu un an, un rollback, et un workaround contrôlé par flag à l'entreprise la mieux positionnée sur Terre pour le corriger.

Si coder était résolu, ce bug serait mort en un week-end. Ce ne fut pas le cas. Ce n'est pas un gotcha. Ce sont des données.

"Écrivez juste des boucles" fonctionne — jusqu'à rencontrer le bug sans glamour

Je veux être juste avec la thèse de la boucle, parce que je l'aime sincèrement. Je fais tourner de l'automatisation basée sur des boucles dans mon propre travail — j'ai écrit sur planifier Claude Code dans des cron loops et sur le changement plus large d'un SDLC manuel vers un cycle de vie de développement agentique. Quand le problème a une condition de victoire claire et vérifiable par machine — les tests passent, les types vérifient, le benchmark passe au vert — une boucle bien construite est quelque chose de magnifique à regarder. Elle converge. C'est ce qui se rapproche le plus de "définissez la fonction de scoring et partez" que j'ai expérimenté en quinze ans d'écriture de logiciel.

Mais notez la forme des problèmes où les boucles brillent : ils ont tous une condition de victoire claire.

Un terminal scintillant n'en a pas. Quel est le test qui passe au vert ? "Ça a l'air moins saccadé pour un œil humain à travers quarante émulateurs de terminal différents, chacun avec son propre renderer, sur trois systèmes d'exploitation, à des taux de rafraîchissement variables" ? Il n'y a pas d'assertion pour ça. Pas de expect(screen).not.toFlicker(). La condition de victoire est floue, dépendante de l'environnement et partiellement subjective — ce qui est précisément pourquoi un an de boucles n'a pas pu en venir à bout. La boucle est seulement aussi intelligente que la fonction de scoring que vous pouvez écrire, et certains des problèmes logiciels les plus importants sont exactement ceux que vous ne pouvez pas scorer proprement.

C'est la partie que le cadrage "le code est résolu" saute. Il suppose silencieusement que chaque problème restant ressemble à un test unitaire. La plupart des difficiles non. Ils ressemblent à du scintillement. Ils ressemblent à "le message d'erreur est techniquement correct mais ne dit rien à l'utilisateur." Ils ressemblent à la vulnérabilité de chargement de projet que les chercheurs ont trouvée dans la fuite de code source, où des requêtes API se déclenchaient avant que l'invite de confiance n'apparaisse — un oubli de conception qu'aucun test n'a attrapé parce que personne n'a pensé à scorer pour ça.

Si vous préférez que quelqu'un construise et maintienne ces boucles agentiques correctement — avec les garde-fous et la gestion d'erreurs ennuyeuse-mais-critique que les démos sautent — c'est une bonne partie de ce que je prends en charge. Vous pouvez voir ce que j'ai livré sur fiverr.com/s/EgxYmWD.

Donc la boucle n'a pas tort. Elle est étroite. C'est un outil fantastique pour le milieu bien spécifié de l'espace du problème et inutile aux bords flous — et les bords flous sont là où le logiciel casse vraiment en production. Appeler ça "résolu" c'est prendre la partie qu'on peut mesurer pour tout le travail.

Le coût humain de prétendre que la partie difficile est finie

Maintenant je veux parler de la partie qui me dérange vraiment, parce que le bug n'est que la preuve — voici les enjeux.

Le récit "le code est résolu, déployez en prod, écrivez la boucle, atteignez la condition de victoire" n'atterrit pas dans le vide. Il atterrit sur des développeurs qui, en ce moment même, sont plus épuisés et plus anxieux pour leurs emplois que je ne les ai vus depuis longtemps. Et le message empire les deux.

Voici le mécanisme cruel, et il est bien documenté. Quand les organisations décident que l'IA a rendu le codage trivial, elles ne mettent pas le temps gagné en réserve — elles traitent chaque minute économisée comme une minute due en retour comme plus de production. Le volume de PR bondit de 40–60%, et le goulot d'étranglement se déplace simplement en aval vers la revue. Maintenant les mêmes humains se noient dans du code qu'ils n'ont pas écrit, en qui ils ne peuvent pas entièrement avoir confiance, et sous pression pour approuver vite. Ce n'est pas moins de burnout. C'est un nouveau type de burnout, pire, et il frappe les personnes qui ont le plus embrassé l'IA. Il y a même tout un genre de post-mortems "l'IA était censée résoudre le burnout des développeurs" maintenant, ce qui vous dit comment l'expérience se déroule.

Mettez les deux moitiés ensemble et la malhonnêteté s'aiguise. Le management entend "le code est résolu" et fixe des attentes comme si c'était vrai. Les développeurs vivent dans l'écart entre cette affirmation et la réalité scintillante, crachant des erreurs, occasionnellement cassée — et sont blâmés pour l'écart. On vous dit que la partie difficile est finie pendant que vous passez votre mardi à débuguer pourquoi la boucle a déployé avec confiance quelque chose de subtilement faux, avec un message d'erreur qui n'expliquait rien.

Il circule une métaphore directe pour ce genre de message — que quelqu'un fait quelque chose à votre jambe et insiste que c'est la météo. Je resterai de bon goût, mais le sentiment est juste. Dire à des ingénieurs épuisés que leur travail dur, réel, toujours nécessaire est "la partie facile" — alors qu'ils nettoient derrière les mêmes outils qu'on appelle une solution — ce n'est pas de l'optimisme. C'est du gaslighting déguisé en statistique de productivité.

Et je dis ça en tant que quelqu'un qui est ouvertement, presque honteusement accro à Claude Code. Je ne suis pas la résistance. Je suis un utilisateur intensif qui vous dit que le marketing signe des chèques que l'outillage ne peut pas encore encaisser.

Ce qui est vraiment résolu, ce qui ne l'est vraiment pas

Laissez-moi être spécifique, parce que le pessimisme vague est aussi inutile que le hype vague. Voici mon bilan honnête après une utilisation quotidienne de ces outils en 2025 et en 2026.

Vraiment accéléré par l'IA aujourd'hui :

• Boilerplate, scaffolding, code de liaison, configuration — quasi instantané, quasi parfait.
• Refactors bien spécifiés avec une couverture de tests solide — les boucles les écrasent.
• Traduire une intention en premier jet — ce qui prenait 45 minutes prend 6.
• Explorer une codebase ou API inconnue — plus rapide que la documentation.

Vraiment amélioré, avec des réserves :

• Qualité du code, quand vous avez construit le harnais (tests, lint, types, métriques d'acceptation) contre lequel la boucle peut scorer. Pas de harnais, pas de gain de qualité — juste du désordre plus rapide.

Vraiment PAS résolu :

• Problèmes flous, non scorables — rendu à travers des environnements hétérogènes, polissage UX, "c'est techniquement correct mais ça semble faux."
• Gestion des erreurs et conception des modes de défaillance — les 80% sans glamour que les démos ne montrent jamais, et où Claude Code lui-même trébuche encore.
• Savoir quoi construire, et si ça devrait exister du tout.
• Le jugement pour outrepasser la boucle quand sa condition de victoire est subtilement la mauvaise cible.

Notez que la colonne "pas résolu" est exactement là où le bug de scintillement vit. Ce n'est pas une coïncidence. Le bug n'est pas un cas aberrant — c'est un échantillon représentatif du travail que le hype a déclaré terminé.

Alors le codage est-il résolu ? Non — et la réponse honnête est plus utile que le hype. Le codage est accéléré, parfois dramatiquement. Les parties bien spécifiées sont de plus en plus automatisables par des boucles. Mais le noyau dur, flou, lourd de jugement — la partie qui fait de l'ingénierie logicielle une profession et non une compétition de vitesse de frappe — est exactement aussi non résolu qu'avant, et les propres bug trackers des outils le prouvent.

Questions fréquemment posées

Le codage est-il vraiment résolu par l'IA en 2026 ?

Non — le codage est dramatiquement accéléré, pas résolu. Les outils d'IA excellent dans les tâches bien spécifiées et vérifiables par machine (boilerplate, refactors, tests qui passent) mais peinent encore avec les problèmes flous et non scorables comme le rendu cross-environnement, le polissage UX et la conception de modes de défaillance. La preuve est que même les outils de codage IA sont livrés avec des bugs persistants que leurs propres boucles ne peuvent pas corriger.

Que signifie "écrivez juste des boucles" dans le codage IA ?

"Écrivez juste des boucles" fait référence au harness engineering — au lieu de prompter une IA un message à la fois, vous construisez un système qui fait tourner le modèle à travers des cycles répétés d'observer-planifier-agir-réfléchir jusqu'à atteindre une condition de victoire définie comme des tests qui passent. C'est une technique sincèrement puissante, mais elle ne fonctionne que là où vous pouvez écrire une fonction de scoring claire, ce qui exclut de nombreux problèmes du monde réel.

Pourquoi le bug de scintillement de Claude Code est-il significatif ?

Le bug de scintillement est un problème logiciel pur sans excuse matérielle ou d'infrastructure, pourtant il a fallu environ un an, un rollback, et un workaround contrôlé par flag pour l'adresser — à l'entreprise la mieux positionnée pour le corriger. Cela en fait le contre-exemple le plus net à l'affirmation que "coder est la partie facile" du logiciel moderne. Pour la chronologie complète, voir la section ci-dessus.

Le codage IA cause-t-il du burnout chez les développeurs ?

Les rapports et post-mortems de 2026 suggèrent que oui — pas parce que l'IA fait moins de travail, mais parce que les organisations convertissent le temps économisé en plus de production, faisant bondir le volume de PR de 40–60% et déplaçant la charge vers la revue de code débordée. Le récit "le code est résolu" aggrave cela en fixant des attentes qui ne correspondent pas à la réalité plus chaotique à laquelle les développeurs font réellement face.

Le reçu auquel je reviens sans cesse

J'ai ouvert avec un terminal scintillant, alors laissez-moi fermer là-dessus.

Quand quelqu'un vous dit que le codage est résolu, posez une question : si c'est vrai, pourquoi les gens qui le disent le plus fort ont passé un an à corriger un écran qui n'arrêtait pas de trembler — et ont ensuite livré le correctif derrière un feature flag ? Il n'y a pas de matériel à blâmer. Pas d'infrastructure derrière laquelle se cacher. Juste un problème logiciel difficile et sans glamour faisant ce que les problèmes logiciels difficiles ont toujours fait : résister aux gens qui l'ont sous-estimé.

Utilisez les outils. Construisez les boucles. Livrez plus vite — je le fais, chaque jour, et j'en suis meilleur. Mais tenez la ligne sur la vérité : le codage n'est pas résolu, il est amplifié. La partie difficile n'a pas disparu. Elle s'est déplacée là où les boucles ne peuvent pas atteindre, et elle est toujours vôtre.

Et honnêtement ? C'est une bonne nouvelle. Parce que ça signifie que le jugement que vous avez passé des années à construire est la partie qui n'a pas été automatisée — c'est la partie qui est devenue plus précieuse. Ne laissez pas un slide de productivité vous convaincre du contraire.

Ce soir, voici la seule chose qui vaut la peine : la prochaine fois que vous rencontrez un bug que votre IA a échoué avec confiance à corriger, ne vous sentez pas en retard. Faites une capture d'écran. Ce bug est la partie du travail qui est toujours vôtre — et c'est la partie qui paie.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des flux de travail ou faire évoluer votre infrastructure tech ? J'adorerais aider.

• Fiverr (builds sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io