Anthropic : Thariq Shihipar dévoile des astuces pour optimiser Fable 5

Anthropic : Thariq Shihipar dévoile des astuces pour optimiser Fable 5

Selon le développeur d'Anthropic, Thariq Shihipar, la qualité des résultats du nouveau modèle Fable 5 de Claude dépend de la capacité des utilisateurs à reconnaître leurs propres lacunes et angles morts avant d'écrire des prompts.

Shihipar propose plusieurs techniques pour découvrir ces "inconnues", notamment :

• brainstorming ciblé
• entretiens structurés avec l'IA
• prise de notes détaillées lors des sessions de codage

Un défi central dans la formulation des prompts, note Shihipar, est de trouver le bon niveau de spécificité : des instructions trop détaillées peuvent enfermer l'IA dans des approches erronées, tandis que des prompts trop vagues ont tendance à produire des réponses génériques et peu utiles.

Quiconque code avec des agents IA connaît le problème. Le prompt est défini, le plan semble clair, mais le résultat n'est pas tout à fait correct. Selon Shihipar, avec le dernier modèle de Claude, Fable 5, cela devient de moins en moins un problème lié au modèle lui-même et davantage le résultat des angles morts de l'utilisateur.

Shihipar affirme que Fable 5 est le premier modèle où la qualité de sortie est limitée par la capacité de l'utilisateur à clarifier ses "inconnues". Les "Known Knowns" sont ce qui est déjà dans le prompt. Les "Known Unknowns" sont des questions que vous savez ne pas avoir encore résolues. Les "Unknown Knowns" décrivent des connaissances si évidentes que vous ne les écririez jamais, mais que vous reconnaîtriez si vous les voyiez. La catégorie critique, selon Shihipar, est celle des "Unknown Unknowns", c'est-à-dire des choses que vous n'avez pas du tout considérées.

Être trop spécifique est tout aussi problématique que d'être trop vague.

Planifier à l'avance ne suffit pas, dit Shihipar. Les inconnues peuvent surgir profondément dans l'implémentation ou indiquer que le problème devrait être résolu d'une manière complètement différente. Les meilleurs codeurs agissants ont relativement peu d'inconnues, mais s'attendent toujours à en rencontrer, soutient-il.

Une trop grande spécificité risque de faire suivre à Fable 5 des instructions de manière rigide, même lorsqu'un changement de cap serait plus judicieux. À l'inverse, une trop grande vagueur conduit à des décisions basées sur des normes industrielles qui ne correspondent pas à la tâche spécifique.

"Lorsque vous ne tenez pas compte de vos inconnues, vous échouez des deux côtés", écrit Shihipar. Mais Claude peut vous aider à découvrir vos propres inconnues plus rapidement, ajoute-t-il. Il explore les bases de code et Internet à grande vitesse et connaît plus de sujets que l'utilisateur moyen. La clé, selon Shihipar, est de donner à Claude un contexte sur votre point de départ, c'est-à-dire où vous en êtes dans votre réflexion et quelle expérience vous avez avec le problème.

Avant de construire, découvrez systématiquement vos angles morts

Shihipar décrit plusieurs techniques pour la phase précédant l'implémentation réelle. Dans ce qu'il appelle un "blindspot pass", vous demandez à Claude d'identifier vos inconnues inconnues. Cela fonctionne particulièrement bien lorsque vous travaillez dans une partie inconnue de la base de code, dit-il.

Un exemple de prompt qu'il suggère : "Je travaille sur l'ajout d'un nouveau fournisseur d'authentification, mais je ne sais rien des modules d'authentification dans cette base de code. Peux-tu faire un blindspot pass pour m'aider à identifier mes inconnues inconnues pertinentes et m'aider à mieux te prompt."

Pour les domaines avec de nombreux "unknown knowns", comme le design visuel, Shihipar recommande le brainstorming et le prototypage. Au lieu de se lancer directement dans l'implémentation, il demande à Claude de générer plusieurs directions de design radicalement différentes sous forme d'artefacts HTML afin qu'il puisse y réagir. Il commence presque chaque session de codage par une phase d'exploration ou de brainstorming pour définir consciemment le périmètre du projet.

D'autres techniques qu'il décrit incluent des entretiens structurés, où Claude pose à l'utilisateur des questions sur les ambiguïtés, en priorisant celles dont les réponses changeraient l'architecture. Les références sont également importantes, dit Shihipar. Le code source est la meilleure référence, même s'il est écrit dans un langage de programmation différent. Par exemple, Claude Design lit le code sous-jacent d'un site web, pas seulement la capture d'écran.

Avant que le travail réel ne commence, Shihipar demande à Claude de créer un plan d'implémentation qui se concentre sur les parties les plus susceptibles de changer, telles que les modèles de données, les interfaces de type et tout ce qui concerne l'utilisateur. Le refactoring mécanique vient en dernier.

Pendant et après l'implémentation, documentez et comprenez

Les inconnues rôdent également pendant l'implémentation, prévient Shihipar. Il demande à Claude Code de garder un fichier temporaire "implementation-notes.md" où il suit les décisions qu'il prend afin d'apprendre de la prochaine tentative. Lorsque des cas limites inattendus se présentent, Claude doit choisir l'option conservatrice, enregistrer la déviation et continuer à travailler.

• Ce qui est énoncé dans le prompt : c'est-à-dire, la connaissance explicitement déclarée par l'utilisateur.
• Questions que vous savez ne pas avoir encore répondues.
• Connaissances si évidentes que vous ne les écririez jamais, mais que vous les reconnaîtriez immédiatement si vous les voyiez.
• Unknown Unknowns : des choses que vous n'avez pas du tout considérées.

Après l'implémentation, Shihipar recommande deux techniques. D'abord, les "pitches et explainers", qui sont des documents de synthèse pour les parties prenantes regroupant le prototype, les spécifications et les notes d'implémentation. Ensuite, les "quizzes", où Claude génère un rapport HTML détaillant les changements effectués, avec contexte et insights, suivi d'un quiz. Shihipar affirme qu'il ne fusionne pas tant qu'il n'a pas réussi le quiz sans erreurs.

Une vidéo de lancement entièrement montée avec Claude Code

Shihipar montre comment ces techniques fonctionnent ensemble en utilisant l'exemple de la vidéo de lancement de Fable, qu'il a entièrement montée avec Claude Code. Le montage vidéo était un territoire nouveau pour lui, dit-il.

Il a commencé par ce qu'il savait. Claude peut monter et transcrire des vidéos à l'aide de code. Il n'était pas clair si la précision serait suffisante, alors il a demandé à quelqu'un d'expliquer comment fonctionne la transcription avec Whisper et si les mots de remplissage et les pauses pouvaient être coupés avec précision à l'aide de ffmpeg. Pour le fondu contrôlé dans le temps des éléments de l'interface utilisateur, il a construit un prototype avec Remotion.

Lorsque le résultat semblait plat en termes de couleur, il a d'abord essayé de demander à Claude de générer diverses variations de correction des couleurs. Mais il a réalisé qu'il ne savait pas à quoi ressemblait un "bon" étalonnage des couleurs. Au lieu d'évaluer aveuglément les variations, il a demandé à Claude de lui enseigner le sujet pour découvrir ses inconnues.

Plus les modèles deviennent puissants, plus vous pouvez réaliser de choses avec la bonne approche, dit Shihipar. Si une tâche de longue durée déraille, vous devez probablement investir plus de temps à définir vos propres inconnues ou créer un plan d'implémentation qui permet à Claude d'improviser à travers elles.

"Chaque explication, brainstorming, entretien, prototype et référence est un moyen peu coûteux de découvrir ce que vous ne saviez pas avant qu'il ne devienne coûteux de le corriger", écrit-il. Shihipar a également mis en place une version visuelle de ses conseils sur un site web.