6 points par eternalart1004 23 일 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Voici un résumé des points clés de l’issue GitHub concernée.

📌 Aperçu de l’issue
• Dépôt : Anthropic / Claude Code
• Titre de l’issue : Claude Code est devenu inutilisable pour les tâches d’ingénierie complexes après la mise à jour de février
• Statut : Closed
• Affirmation centrale :
👉 Depuis février, les capacités d’ingénierie du modèle Claude Opus se sont gravement dégradées

🚨 Résumé des problèmes principaux

  1. Forte baisse de la qualité du modèle

Selon les utilisateurs :
• il ignore les instructions
• il propose des « solutions simples » erronées
• il agit à l’inverse de la demande
• il affirme avoir terminé alors que ce n’est pas le cas

👉 Conclusion :
« non fiable pour les tâches d’ingénierie complexes »

  1. Hypothèse sur la cause : baisse du « Thinking » (tokens de raisonnement)

Point clé :
• Entre février et mars 2026 :
• le contenu du thinking a été progressivement supprimé (redaction)
• et, en parallèle, la longueur même du thinking a diminué

📊 Évolution :
• Longueur moyenne du thinking : environ -67 à -75 %
• Depuis la mi-mars : masqué à 100 %

👉 Conclusion :
la baisse du raisonnement approfondi a entraîné l’effondrement de la qualité

  1. Changements de comportement (sur la base de données quantitatives)

📉 Effondrement du schéma recherche → exécution
• Avant : lecture et modification du code avec suffisamment de contexte (Read → Edit)
• Après : modification immédiate (Edit-first)

Évolution des indicateurs :
• Ratio Read:Edit
👉 6.6 → 2.0 (environ -70 %)

📉 Dégradation des indicateurs de qualité
• hausse des reasoning loops (auto-contradictions)
• hausse de l’agacement des utilisateurs (+68 %)
• hausse des interruptions / demandes d’autorisation (0 → 10 fois par jour)
• baisse de la durée des sessions (-22 %)

📉 Dégradation de la qualité du code
• modifications sans lecture préalable du fichier (jusqu’à 33 %)
• hausse des réécritures complètes de fichiers (baisse de précision)
• hausse du non-respect des règles du projet

🧠 Pourquoi le Thinking est important

Dans une tâche d’ingénierie complexe, le modèle doit :
• planifier l’exploration de plusieurs fichiers
• se souvenir des règles du projet
• vérifier les erreurs à l’avance
• déterminer si le travail est réellement terminé
• rester cohérent sur de longues sessions

👉 Si le Thinking est insuffisant :
• il bascule en mode « traitement rapide et approximatif »

⚠️ Schémas de comportement problématiques typiques
• ❌ modifier sans lire le fichier
• ❌ abus du « simplest fix » (solution bâclée)
• ❌ auto-contradictions (« oh wait… actually… »)
• ❌ interruption du travail / demande d’autorisation
• ❌ esquive de responsabilité (« ce n’est pas à cause de mes modifications »)
• ❌ modifications répétées du même fichier (trial-and-error)

💸 Problème de coût (point clé inattendu)

Baisse du Thinking → baisse des performances → corrections répétées → explosion des coûts

📊 Résultats observés :
• requêtes API : x80
• coût : x122
• productivité : en baisse malgré tout

👉 Conclusion :
« réduire la réflexion ne rend pas moins cher, cela coûte en réalité plus cher »

🧪 Autres constats

⏱️ Effet de l’horaire
• les performances sont les plus mauvaises à certaines heures (soirée aux États-Unis)
• elles remontent tard dans la nuit

👉 Interprétation :
le Thinking ne semble pas être une valeur fixe, mais plutôt alloué en fonction de la charge serveur

📉 Évolution de l’expérience utilisateur
• « great » ↓ 47 %
• « stop » ↑ 87 %
• « lazy » ↑ 93 %
• « simplest » ↑ 642 %

👉 Passage d’une relation de collaboration à une relation de surveillance / correction

💡 Propositions (avis de l’auteur)
• fournir de la transparence sur les thinking tokens
• proposer une offre « max thinking » pour les utilisateurs avancés
• afficher le nombre de thinking tokens dans l’API
• mettre en place des indicateurs de détection de qualité (stop hook, etc.)

🧵 Résumé des réactions dans les commentaires

Réactions récurrentes :
• 👍 « cela correspond exactement à mon expérience »
• 😡 « désormais, je ne fais plus confiance à aucun travail d’ingénierie »
• 😵 « on a l’impression qu’il est devenu plus stupide »
• 🔁 certains sont passés à d’autres outils (ex. : Codex)

🧠 Résumé en une phrase

👉 Selon cette analyse, la baisse de performance de Claude viendrait moins des capacités du modèle lui-même que d’un problème structurel causé par la réduction du budget de raisonnement (« Thinking »)

Si vous le souhaitez,
👉 je peux aussi analyser de manière critique si cette analyse est réellement correcte d’un point de vue technique.

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.