Ce que le modèle sait · Craftomancer

Vérifier à chaque appel, soit. Reste à savoir sur quoi la vérification porte : il y a des demandes où l’agent est increvable, et d’autres où il invente avec exactement le même aplomb.

Bonne nouvelle : la frontière existe, elle est prévisible, et elle ne passe pas du tout là où l’intuition la place. Tout se déduit d’un seul fait — ce que le modèle sait, il l’a appris une fois, ailleurs, et il ne l’apprendra plus.

Le modèle apprend-il de vos sessions ?

Non. Jamais. Et c’est la première chose que j’ai dû accepter, parce qu’elle condamne un réflexe très naturel : celui de « lui expliquer » pour de bon.

Il y a deux moments, et ils ne communiquent pas. L’entraînement, c’est le moment où les poids sont ajustés sur des téraoctets de texte et de code : il a eu lieu une fois, chez le fournisseur du modèle, et il est terminé. L’inférence, c’est ce qui se passe quand vous utilisez le modèle : les poids sont figés, rien n’est appris, rien n’est retenu.

Trois conséquences en sortent, et elles se prennent toutes en session.

Le modèle a une date de coupure. Il ne connaît ni la dernière version de votre framework, ni la bibliothèque sortie le mois dernier. Tout ce qui est plus récent doit lui être fourni.
Le modèle n’apprend pas de vos sessions. Corriger trois fois la même erreur ne l’éduque pas : à la session suivante, tout recommence à zéro. La seule mémoire qui existe est celle que votre outillage reconstruit dans le contexte — fichier d’instructions, historique, mémoire applicative.
Le modèle ne sait rien de votre projet. Il n’a jamais vu votre dépôt, vos conventions, votre dette. Tout ce qu’il en sait au moment de répondre tient dans la fenêtre de contexte.

LE CRAFTOMANCER

« Le modèle connaît ce framework » est toujours une approximation. Il en a vu des milliers d’exemples à des versions mélangées, et rien dans les poids ne les date. Le code qu’il produit est un amalgame statistique de ces versions : c’est de là que viennent les appels qui ressemblent à deux versions à la fois. Fournissez la version et la documentation pertinente au lieu de présumer.

Que veut dire « savoir » pour un modèle ?

Pas ce que vous croyez. Un LLM ne stocke pas des faits dans une base qu’il consulterait : ses poids compressent des régularités statistiques extraites du corpus.

L’image qui m’a le plus aidé, c’est celle du JPEG très compressé. Là où l’image d’origine était uniforme et répétitive, la restitution est impeccable. Là où elle était riche en détails uniques, ça bave — et ça bave avec le même piqué apparent que le reste.

C’est exactement ça. Quand la régularité est massive et cohérente — la syntaxe d’un langage, les idiomes d’une bibliothèque standard — la compression est si fiable qu’on ne la distingue pas d’un savoir exact. Quand elle est rare, contradictoire ou récente, le modèle interpole : il produit ce qui ressemblerait à la bonne réponse.

Les deux traces de l’Étape précédente sont les deux régimes, côte à côte. fibonacci est massivement représenté, la continuation probable est la bonne, vingt-six tokens de suite. Sur le prompt qui dit explicitement Pydantic v2, le candidat de tête est .dict — l’API v1, supprimée. La distribution ne dit pas ce qui est correct en v2 : elle dit ce qui suit le plus souvent dans le code public que le modèle a vu. Votre demande pèse dans cette distribution, elle ne la remplace pas.

D’où le déplacement de question, et si vous ne retenez qu’un geste de cette Étape, prenez celui-là. Non pas « est-ce que ça a l’air juste ? » — la fluidité est constante, elle ne trie rien — mais « est-ce le genre de chose qu’un corpus public a pu voir massivement ? ».

Un pattern CRUD, oui. Le nom exact d’une option de CLI sortie il y a six mois, non. Votre schéma de base de données, jamais.

Une question se pose ici, et cette Étape n’y répond pas : si ce ne sont pas des faits rangés quelque part, à quoi ressemblent-ils dans les poids ? « D’où viennent ces poids » déroule la compression et ce qui la produit.

Pourquoi ça marche si bien sur du code ?

Pour deux raisons, et la seconde décide de toute votre façon de travailler. Une machine à continuer du texte, sur le papier, ça devrait être médiocre en programmation. C’est l’inverse.

Le code est un langage formel et massivement redondant. Les mêmes motifs — CRUD, parsing, tests, plomberie HTTP — apparaissent des millions de fois dans le corpus. La continuation probable est très souvent la bonne : c’est le régime de la trace A, étendu à la plus grande partie du travail ordinaire.

Le code est vérifiable mécaniquement : il compile, il se type, il se teste. C’est l’asymétrie qui rend le développement assisté viable, et elle mérite d’être énoncée jusqu’au bout : la sortie du modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être réfutable à bas coût.

Ce qui donne une règle que je trouve libératrice : ce n’est pas la qualité du modèle qui décide de ce que vous pouvez déléguer, c’est la vitesse à laquelle votre outillage dit non. Là où un test tourne en trois secondes, vous pouvez laisser un agent se tromper dix fois. Là où la vérification demande une relecture humaine attentive — une migration de données, un choix d’architecture, un texte destiné à un client — la même machine devient beaucoup plus chère qu’un gain.

Le périmètre de la délégation, c’est le périmètre de votre vérification.

Et ce qui manque ?

Ça se fournit. C’est la règle unique où les deux moitiés se rejoignent : ce qui est massivement représenté, le modèle le produit sans que vous ayez à y penser ; tout le reste — le récent, le privé, le spécifique — n’existe pour lui que si vous le mettez dans le contexte.

Il n’y a pas de troisième voie. Ni mémoire, ni apprentissage, ni bonne volonté.

Fournir a un prix et une place. Ce que ça coûte se compte en tokens, et l’Étape suivante apprend à l’estimer ; où ça se loge, et pourquoi la place occupée n’est pas neutre, c’est le contexte.

En pratique

Remplacez « il sait / il ne sait pas » par « c’est massivement représenté dans un corpus public / ça ne l’est pas ». Votre intuition des erreurs s’améliore immédiatement.
Tout ce qui est postérieur à la date de coupure ou propre à votre projet doit être fourni. Sinon, ça n’existe pas.
Nommez la version et joignez la documentation quand elle est récente. Une bibliothèque qui a changé d’API est le cas où le corpus travaille contre vous.
Ne « rééduquez » pas le modèle dans le fil : capitalisez la correction dans votre fichier d’instructions, la seule mémoire qui persiste.
Avant de déléguer une tâche, demandez-vous comment vous saurez qu’elle est ratée, et en combien de temps. Pas de réponse rapide, pas de délégation.

Vérifiez votre modèle

Quatre questions pour voir si le modèle mental tient. Cliquez une réponse : le verdict s’affiche.

RUN · II 0 / 4

jack in — choisissez votre réponse

Vous avez corrigé trois fois la même erreur de l’agent cette semaine. À la prochaine session, il…

La meilleure question pour prédire le risque d’erreur, c’est…

L’agent produit un appel qui mélange deux versions d’une même bibliothèque. La cause la plus probable…

Ce qui rend la délégation de code viable, c’est…