Travailler avec Claude Fable 5 ne cesse de me rappeler une vieille leçon : la carte n'est pas le territoire.
La carte, une représentation du travail à accomplir, ce sont mes prompts, mes compétences et mon contexte, c'est ce que je donne à Claude. Le territoire, c'est là où le travail doit se faire, la base de code, le monde réel, ses contraintes réelles.
La différence entre la carte et le territoire, c'est ce que j'appelle les inconnues. Lorsque Claude rencontre une inconnue, il doit prendre une décision basée sur sa meilleure estimation de ce que je veux. Plus le travail est important, plus Claude risque de rencontrer d'inconnues.
Fable est le premier modèle où je constate que la qualité du travail est limitée par ma capacité à clarifier ses inconnues.
Il est important de noter que le simple fait de planifier à l'avance ne suffit pas toujours. Vous pouvez découvrir des inconnues au cœur de l'implémentation, ou vos inconnues peuvent vous indiquer que vous devriez en fait résoudre le problème d'une manière complètement différente.
J'ai découvert que travailler avec Fable est un processus itératif de découverte de mes inconnues avant, pendant et après l'implémentation.
J'ai créé quelques exemples d'artefacts pour trouver les inconnues ici, mais assurez-vous de revenir pour développer l'intuition nécessaire pour savoir quand les utiliser.
Connaître ses inconnues
Quelles sont vos inconnues ? Lorsque je présente un problème à Claude, j'ai tendance à le décomposer de 4 manières :
- Connues connues : C'est essentiellement ce qui se trouve dans mon prompt. Qu'est-ce que je dis à l'agent que je veux ?
- Inconnues connues : Qu'est-ce que je n'ai pas encore compris, mais dont je suis conscient de ne pas avoir compris ?
- Connues inconnues : Qu'est-ce qui est si évident que je ne l'écrirais jamais, mais que je reconnaîtrais si je le voyais ?
- Inconnues inconnues : À quoi n'ai-je pas du tout pensé ? De quelle connaissance ne suis-je pas conscient ? Est-ce que je sais à quel point quelque chose peut être bon ?
Les meilleurs codeurs agentiques ont relativement peu d'inconnues. Regarder quelqu'un comme Boris ou Jarred faire un prompt, il m'est évident qu'ils savent exactement ce qu'ils veulent en détail. Ils sont profondément en phase avec la base de code et les comportements du modèle.
Mais ils supposent aussi des inconnues. À bien des égards, réduire et planifier vos inconnues est la compétence clé du codage agentique. Mais heureusement, c'est une compétence que vous pouvez améliorer en travaillant avec Claude.
Aider Claude à vous aider
Donner des instructions à Claude est un équilibre délicat. Si vous êtes trop précis, Claude suivra vos instructions même lorsqu'un changement de cap serait plus approprié. Si vous êtes trop vague, Claude fera souvent des choix et des hypothèses basés sur les meilleures pratiques du secteur qui pourraient ne pas convenir à votre tâche.
Lorsque vous ne tenez pas compte de vos inconnues, vous échouez des deux côtés. Vous ne savez pas quand le chemin sera semé d'embûches et vous ne savez pas quand le chemin sera dégagé, mais vous voulez quand même que Claude change de direction.
Claude peut vous aider à découvrir vos inconnues plus rapidement. Il peut parcourir votre base de code et Internet extrêmement rapidement et en sait beaucoup plus que vous sur le sujet moyen. Il peut aussi itérer plus rapidement après un échec.
La partie la plus importante de ce processus est de donner à Claude un contexte sur votre point de départ. Par exemple, dites-lui où vous en êtes dans votre processus de réflexion ; divulguez votre expérience avec le problème et la base de code ; et laissez-le travailler avec vous comme un partenaire de réflexion.
J'ai déjà écrit sur l'utilisation de HTML avec Claude, et dans presque tous ces cas, un artefact HTML est la meilleure façon de visualiser et de représenter cela.
Dans cet article, je détaille certains des modèles que j'utilise pour découvrir ces inconnues. Je n'utilise pas chaque technique à chaque fois, mais c'est une collection de techniques utiles à avoir.
Avant l'implémentation
Passage en revue des angles morts
Au début d'un travail, l'une des choses les plus utiles que vous puissiez faire est de comprendre vos angles morts. Par exemple, si vous écrivez une fonctionnalité dans une nouvelle partie de la base de code ou si vous utilisez Claude pour vous aider avec un travail inconnu comme itérer sur un design, vous aurez probablement beaucoup d'inconnues inconnues.
Vous ne savez peut-être pas quelles questions poser, à quoi ressemble un bon résultat, quel travail historique a été fait ou quels pièges éviter.
Pour ce faire, vous pouvez demander à Claude de vous aider à trouver vos inconnues inconnues et de vous les expliquer. J'aime utiliser les mots littéraux « passage en revue des angles morts » et « inconnues inconnues ». Lui donner un contexte sur qui vous êtes et ce que vous savez est généralement important.
Exemples de prompts :
- « Je travaille sur l'ajout d'un nouveau fournisseur d'authentification mais je ne connais rien aux modules d'authentification dans cette base de code. Peux-tu faire un passage en revue des angles morts pour m'aider à identifier mes inconnues inconnues pertinentes et à mieux te guider ? »
- « Je ne sais pas ce qu'est l'étalonnage des couleurs mais j'ai besoin d'étalonner cette vidéo. Peux-tu m'apprendre à comprendre mes inconnues inconnues sur l'étalonnage des couleurs, afin que je puisse mieux te guider ? »
Brainstormings et prototypes
Lorsque je travaille dans un domaine avec beaucoup de connues inconnues, impliquant des critères que je ne peux définir qu'en les voyant, j'aime demander à Claude de faire un brainstorming et un prototype avec moi.
Il est extrêmement précieux d'identifier et de verbaliser les connues inconnues tôt lors du prototypage, car les découvrir pendant l'implémentation peut être (relativement) coûteux. De petits changements dans une fonctionnalité ou un cahier des charges peuvent entraîner des implémentations radicalement différentes dans le code, et il peut être plus difficile pour votre agent d'annuler les modifications précédentes.
Par exemple, vous voudrez peut-être simplement voir à quoi ressemble un bouton ajouté à un cadre sans avoir à configurer une route backend ou à maintenir un état supplémentaire dans le frontend.
Le design visuel est quelque chose qui, pour moi, est difficile à exprimer, mais je sais ce que je veux quand je le vois. Dans ces cas-là, je demande plusieurs approches de conception pour un artefact.
Je commence également presque chaque session de codage par une phase d'exploration ou de brainstorming. Cela m'aide à commencer avec l'intention de définir la portée du projet. Claude trouve souvent des approches à haute valeur ajoutée que j'aurais manquées et parfois, il ne voit pas la forêt à cause des arbres. Le brainstorming m'empêche de fixer un cadre trop étroit ou trop large.
Exemples de prompts :
- « Je veux un tableau de bord pour ces données mais je n'ai aucun goût visuel et je ne sais pas ce qui est possible. Fais-moi une page HTML avec 4 directions de design radicalement différentes pour que je puisse réagir. »
- « Avant de tout connecter, crée un seul fichier HTML simulant la nouvelle barre d'outils de l'éditeur avec de fausses données. Je veux réagir à la disposition avant que tu ne touches à la vraie application. »
- « Voici mon problème général : les utilisateurs se désabonnent après l'intégration. Parcours la base de code et fais un brainstorming de 10 endroits où nous pourrions intervenir, du moins cher au plus ambitieux. Je te dirai lesquels résonnent. »
Entretiens
Une fois que j'ai suffisamment brainstormé, j'ai probablement encore des inconnues.
Dans ce cas, je demande à Claude de m'interviewer sur les inconnues ou les ambiguïtés. Lorsque vous demandez à Claude de vous interviewer, essayez de lui donner un contexte sur votre problème pour guider ses questions. Voici quelques exemples.
Exemples de prompts :
- « Interviewe-moi une question à la fois sur tout ce qui est ambigu, donne la priorité aux questions où ma réponse changerait l'architecture. »
Références
Parfois, vous ne pouvez pas décrire ce que vous voulez en détail. Par exemple, vous n'avez peut-être pas le vocabulaire ou c'est tellement compliqué que cela vous prendrait beaucoup de temps.
Dans ce cas, la meilleure réponse est une référence. Bien que vous puissiez inclure des diagrammes, de la documentation ou des images, la meilleure référence absolue est le code source.
Si vous avez une bibliothèque qui implémente quelque chose d'une certaine manière ou un composant de design que vous aimez vraiment, pointez simplement Fable vers le dossier et dites-lui quoi chercher, même si c'est dans un langage différent.
C'est aussi ainsi que fonctionne Claude Design. Vous n'êtes pas obligé de lui fournir un fichier (bien que vous puissiez le faire aussi). Vous pouvez le pointer vers un module sur un site Web que vous aimez, et il lit le code sous-jacent, pas seulement la capture d'écran. Cela fournit des détails beaucoup plus riches sur le balisage, la structure et la façon dont le composant est réellement construit.
Exemples de prompts :
- « Cette crate Rust dans vendor/rate-limiter implémente exactement le comportement de backoff que je veux. Lis-la et réimplémente la même sémantique dans notre client API TypeScript. »
Plans d'implémentation
Quand je pense être prêt à implémenter, j'ai tendance à demander à Claude de préparer un plan d'implémentation à réviser, en se concentrant sur les parties les plus susceptibles de changer, par exemple pour réviser les modèles de données, les interfaces de type ou les flux UX. Cela permet à Claude de faire remonter des choses que je pourrais avoir besoin de modifier.
Exemples de prompts :
- « Rédige un plan d'implémentation en HTML, mais commence par les décisions que je suis le plus susceptible de modifier : les changements de modèle de données, les nouvelles interfaces de type et tout ce qui est orienté utilisateur. Enterre le refactoring mécanique à la fin, je te fais confiance pour cette partie. »
Pendant l'implémentation
Notes d'implémentation
Une fois que je suis satisfait de mon plan, j'ouvre une nouvelle session et je transmets les artefacts dans le prompt. Par exemple, je peux passer un fichier de spécifications et un prototype et demander à un agent de l'implémenter.
Mais la vérité est que, peu importe la quantité de planification, il y a toujours des inconnues inconnues qui se cachent. L'agent peut découvrir pendant son travail qu'il doit emprunter une voie différente en raison d'un cas limite trouvé dans le code.
Je demande à Claude Code de conserver un fichier temporaire 'implementation-notes.md' (ou .html) où il garde une trace des décisions prises afin que nous puissions apprendre de notre prochaine tentative.
Exemples de prompts :
- « Garde un fichier implementation-notes.md. Si tu rencontres un cas limite qui t'oblige à t'écarter du plan, choisis l'option conservative, enregistre-la sous 'Déviations', et continue. »
Après l'implémentation
Pitchs et explications
L'une des parties les plus importantes de la livraison d'un produit est d'obtenir l'adhésion et les approbations. Construire des artefacts de pitch et d'explication dans le document final aide à :
- Accélérer la compréhension lorsque les réviseurs commencent avec les mêmes inconnues que vous
- Accélérer les approbations lorsque les experts veulent voir que vous avez tenu compte des inconnues et des points de défaillance courants qu'ils auraient anticipés
Exemples de prompts :
- « Regroupe le prototype, le cahier des charges et les notes d'implémentation dans un seul document que je peux déposer dans Slack pour obtenir l'adhésion. Commence par le GIF de démonstration. »
Quiz
Après une longue session de travail, Claude a peut-être accompli beaucoup plus que ce que j'avais réalisé. Lire les diffs de code ne peut me donner qu'une compréhension légère de ce qui s'est passé, car une grande partie du comportement dépendra des chemins de code existants.
Demander à Claude de me faire passer un quiz sur le changement après m'avoir donné beaucoup de contexte m'aide à comprendre ce qui s'est passé. Je ne fusionne qu'après avoir réussi le quiz parfaitement.
Exemples de prompts :
- « Je veux m'assurer de comprendre tout ce qui s'est passé dans ce changement. Fais-moi un rapport HTML sur les changements pour que je puisse lire et comprendre avec le contexte, l'intuition, ce qui a été fait, etc., et un quiz à la fin sur les changements que je dois réussir. »
Comment cela se concrétise : le lancement de Fable
La vidéo de lancement de Fable a été entièrement montée par Claude Code. C'était un nouveau domaine pour moi et je suis loin d'être un expert.
J'ai donc commencé par ce que je savais. Je savais que Claude pouvait utiliser du code pour éditer des vidéos et les transcrire, mais je n'étais pas sûr que ce soit assez précis. J'ai ensuite demandé à Claude de m'expliquer comment fonctionnait la transcription comme Whisper, et si je pourrais découper avec précision des choses comme les « euh » ou les longues pauses en utilisant ffmpeg.
Je voulais que Claude crée une interface utilisateur synchronisée avec les mots que je disais, mais je n'étais pas sûr que ce soit possible, alors j'ai demandé à Claude de créer une vidéo prototype en utilisant Remotion et une transcription pour voir si cela fonctionnerait.
Enfin, la vidéo elle-même semblait un peu terne, ce que je savais être le résultat de l'étalonnage des couleurs, mais je ne savais pas vraiment ce qu'était l'étalonnage des couleurs. Ma première tentative a été d'essayer de faire faire quelques variations à Claude pour choisir, mais j'ai réalisé que je ne savais pas à quoi ressemblait un « bon » étalonnage des couleurs. J'ai donc plutôt demandé à Claude de m'enseigner l'étalonnage des couleurs pour découvrir mes inconnues.
Vous pouvez regarder une explication plus approfondie à ce sujet ici.
Faire correspondre la carte et le territoire
Plus les modèles deviennent performants, plus vous pouvez accomplir avec la bonne approche. Lorsqu'une tâche à long terme revient erronée, il est probable que vous deviez passer plus de temps à définir vos inconnues ou à créer un plan d'implémentation qui permette à 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 que cela ne devienne coûteux à corriger.
Alors, commencez votre prochain projet en demandant à Claude de vous aider à trouver vos inconnues.
