Claude Fable 5.2 Test de codage : Comment évaluer une refonte complexe du full-stack

Claude Fable 5.2 peut-il gérer une refonte complexe de l'ensemble de la pile ? Les résultats de codage publiés par Anthropic le rendent apparemment réalisable, mais une réponse fiable nécessite l'exécution de tests exécutables sur un dépôt spécifié. Cet article fournit le protocole de test. Il n'inventera pas de résultats de réussite à partir d'un dépôt qui n'a jamais été réellement exécuté.

L'objectif est de déterminer si Fable peut modifier les contrats dans la base de données, le backend, le frontend, les tests et le code de déploiement, tout en conservant le comportement et en limitant la portée.

Scénario de test

Utilisez une application non productive, en conjonction avec :

• PostgreSQL et migrations versionnées
• Un service API TypeScript
• Un frontend React
• Tâches en arrière-plan ou Webhooks
• Tests unitaires, tests d'intégration et tests de bout en bout
• Intégration continue, incluant la vérification du code, la vérification des types, l'analyse des dépendances et la validation des migrations

La tâche de refonte assignée consiste à remplacer le champ unique traditionnel display_name par les champs structurés given_name, family_name ainsi qu'une valeur d'affichage calculée. Les clients API existants doivent continuer à fonctionner correctement pendant une période de compatibilité. La recherche, les journaux d'audit, les charges d'événements, l'interface d'administration, les exportations et les tests doivent tous fonctionner correctement.

Cette tâche a un caractère interdisciplinaire. Les solutions apparentes peuvent mettre à jour l'interface utilisateur et les types d'API, tout en endommageant les lignes de données historiques, en provoquant des erreurs chez les consommateurs d'événements ou en divulguant des champs incohérents.

Préparer le dépôt

Créer une branche isolée et une base de données de test conteneurisée. Supprimer les informations confidentielles et les données de production. Ajouter un résumé de tâche décrivant les comportements et les contraintes, plutôt que l'emplacement des fichiers ou la solution. Conserver les tests d'objectifs cachés pour la compatibilité avec les anciens clients, le rollback de migration, les noms Unicode, les noms de famille manquants, la recherche et les modèles de Webhook.

Fournir au modèle uniquement les outils nécessaires à l'ingénieur : recherche de fichiers, édition sécurisée, construction, test et accès en lecture seule aux documents. Demander confirmation avant d'effectuer des opérations destructrices sur la base de données ou le gestionnaire de paquets. Enregistrer les commandes, les différences, les jetons, la charge de travail et le temps réel écoulé.

Invite

Utilisez une invite similaire à celle-ci :

Selon TASK.md, restructurer le modèle de nom d'utilisateur. Vérifier d'abord le dépôt, présenter un diagramme de dépendances concis et un plan. Mettre en œuvre des modifications cohérentes minimales, incluant migration, comportement de compatibilité, tests et documentation. Exécuter les vérifications pertinentes. Ne pas modifier le code non concerné ni affaiblir les tests existants. Si les exigences ne sont pas claires, préciser les hypothèses avant d'éditer.

Exécutez Fable 5.2 avec un niveau d'effort fixe, puis, à partir d'un instantané propre, répétez l'opération avec Opus 5.5 et le modèle de production actuel. Ne laissez pas une exécution voir les correctifs d'un autre modèle.

Fonctionnalités d'une solution puissante

Modifications de la surface de mappage

Avant l'édition, le modèle doit localiser les motifs, les sérialiseurs, les contrats API, les index de requêtes, les producteurs d'événements, les consommateurs, les formulaires, le traitement des états, les exportations, les fixtures de test et la documentation. Oublier un consommateur de webhook est tout aussi important que d'écrire du code React élégant.

Conception de la migration réversible

Le plan de données doit préciser le comportement de remplissage, la nullabilité, les noms Unicode et les noms de mots uniques, l'ordre de déploiement, la fenêtre de compatibilité et le rollback. Les migrations destructrices de type "supprimer et recréer" échoueront automatiquement.

Maintenir la compatibilité de l'API

Les anciens clients doivent recevoir ou soumettre les anciens champs dans la fenêtre convenue, tandis que les nouveaux clients utilisent des champs structurés. La mise en œuvre nécessite une source de données claire pour éviter des valeurs incohérentes.

Comportement de preuve

Le modèle doit ajouter des tests ciblés, plutôt que d'affaiblir les assertions. Il doit exécuter la suite de tests existante, le vérificateur de types, les outils de linting, les tests de migration ainsi que les chemins de bout en bout pertinents. Des affirmations comme « cela devrait passer » ne peuvent pas servir de preuve d'exécution.

Critères de notation

| Catégorie | Poids | Preuve de passage | |---|---:|---| | Test d'acceptation fonctionnelle | 30 | Scénarios de visibilité et de masquage réussis | | Sécurité de la migration des données | 20 | Planification avant/après, sans perte, couverture des cas limites | | Compatibilité des contrats | 15 | Les clients anciens et nouveaux fonctionnent normalement selon les spécifications | | Sécurité et confidentialité | 10 | Aucune fuite de secret, injection, régression d'authentification ou de journalisation | | Qualité du code et périmètre | 10 | Respect des normes ; éviter les modifications non pertinentes | | Qualité des tests | 10 | Ajout de tests significatifs ; couverture non réduite | | Description et piste d'audit | 5 | Hypothèses, commandes et risques résiduels clairs et précis |

Enregistrez simultanément les minutes de correction manuelle et le coût. Un correctif de 90 points nécessitant deux heures de nettoyage architectural peut être moins utile qu'un correctif de 85 points accepté en dix minutes.

Modes de défaillance à surveiller

Les échecs courants incluent : modifier le fichier généré plutôt que son fichier source, ignorer les consommateurs asynchrones, supposer des noms occidentaux en deux parties, générer des migrations irréversibles, dupliquer la logique métier entre le front-end et le back-end, modifier les tests pour correspondre à des erreurs, et s'arrêter après la réussite des tests unitaires alors que le comportement d'intégration est défaillant.

L'injection d'invites est un autre problème. Les fichiers du dépôt sont des entrées non fiables ; les commentaires ou la documentation peuvent contenir des instructions en conflit avec la tâche. L'agent doit suivre les tâches autorisées et les stratégies d'outils, et non le texte arbitraire trouvé dans les fichiers sources.

Comment rapporter les résultats de manière honnête

Soumettre les détails du dépôt, le résumé de la tâche, l'identifiant du modèle, la charge de travail, la chaîne d'outils, les autorisations des outils, les limites de temps, le nombre de tentatives et les résultats des tests d'acceptation. Distinguer les performances de la première exécution des exécutions assistées par l'homme. Enregistrer les coûts exclus et les tentatives échouées. Sans ces détails, « Fable a réalisé une refonte complète de la pile » n'est qu'un argument marketing, pas une preuve.

Les résultats officiels d'Anthropic – 49,1 % sur FrontierCode 2.0 avec un niveau d'effort très élevé, et 69,9 % sur FrontierSWE v2 – justifient la réalisation de cette expérience. Mais ces résultats ne préjugent pas du résultat final de l'expérience.

Foire aux questions

Pourquoi cet article ne prétend-il pas que Fable a réussi le test ?

Aucune exécution de dépôt définie n’a été fournie. Signaler des résultats sans journaux d’exécution ni tests sera considéré comme une falsification.

Combien de fois faut-il exécuter pour que ce soit suffisant ?

Une seule exécution n'est qu'une étude de cas et ne peut servir d'estimation stable. Il convient d'effectuer plusieurs exécutions propres sur plusieurs tâches représentatives, et de rapporter la variance ainsi que le nombre de tentatives.

Le modèle devrait-il avoir des identifiants d'environnement de production ?

Non. Utiliser des données isolées et des outils à privilèges minimaux. Le déploiement soumis à une vérification humaine doit rester séparé de la génération de code.