Le prompting ne survit pas à une vraie base de code

Un agent de code n’échoue pas sur votre base de code parce que vous avez mal formulé la demande. Il échoue pour des raisons structurelles, et aucune formulation ne les atteindra.

C’est la prémisse de cette série, et il m’a fallu du temps pour l’accepter. Face à un agent qui déraillait, mon premier réflexe était toujours le même : réécrire le prompt. Ajouter une contrainte. Le dire plus fermement. Ça marche sur un dépôt jouet. Ça cesse de marcher dès que la base de code est assez grosse pour que l’agent ne puisse pas la garder en vue, assez vieille pour se contredire elle-même, et assez porteuse pour qu’une modification fausse et sûre d’elle coûte une journée.

TL;DR

• Le prompting est un acte ponctuel, requête par requête. Une vraie base de code impose des problèmes permanents : attention finie, règles périmées, mots du domaine ambigus, travail trop gros pour une seule étape. Rien de tout ça ne répond à une reformulation.
• Ce qui les corrige, c’est la machine autour du modèle : ce qu’il lit, ce qu’il a le droit de faire, ce qui est vérifié avant que sa sortie compte. Cette machine, c’est le harnais, et c’est elle l’unité d’ingénierie.
• Cette série prend un mécanisme par article. Un problème qu’il résout, une recette que vous pouvez exécuter. Pas de vibes.

L’échec est structurel

Regardez ce qui se passe vraiment mal et le motif apparaît vite. L’agent refait un travail qu’il a déjà fait. Il oublie une contrainte que vous avez posée quarante messages plus tôt. Il lit Member comme un mot anglais ordinaire au lieu de la chose précise qu’il désigne dans votre système. Il suit une règle écrite dans un fichier qui a cessé d’être vrai en mars.

Aucun de ces ratés n’est un raté de formulation. Ce sont des propriétés de la situation. La fenêtre de contexte est finie et le modèle la relit entièrement à chaque étape : une fenêtre plus pleine est donc une fenêtre moins bonne. Les règles que vous avez écrites se périment parce que rien ne les force à suivre le code. Votre vocabulaire métier est précis et non documenté, alors le modèle lui substitue le sens générique et poursuit avec une confiance totale.

Aucun prompt ne vous sortira de là. Vous ne pouvez que changer les conditions dans lesquelles le modèle travaille.

Le harnais est l’unité

Un menuisier qui doit refaire cent fois la même coupe ne s’entraîne pas à tenir la scie plus droit. Il fabrique un gabarit. Le gabarit n’est pas un bricolage pour compenser un manque de savoir-faire. C’est ce qui rend le savoir-faire répétable, et c’est une vraie pièce d’ingénierie à part entière.

Le harnais, c’est ce gabarit. C’est tout ce qui n’est pas le modèle : ce qui entre dans la fenêtre, ce que l’agent a le droit de toucher, ce qui s’exécute avant que son travail compte comme fait, ce qui se passe quand il se trompe. Le modèle est figé. La machine autour est entièrement la vôtre, et c’est elle qui fixe le plafond de ce que ce modèle peut faire pour vous de façon fiable.

C’est là que je me sépare de la plupart des écrits sur les agents. L’industrie vend de l’autonomie : donnez plus de liberté à l’agent et il en fera plus pour vous. Mon expérience va dans l’autre sens. La fiabilité vient d’une structure qu’un humain a conçue exprès. L’agent est un composant à l’intérieur, pas le pilote.

Commencez ici

Trois articles posent le vocabulaire sur lequel s’appuie le reste de la série. Ils sont courts et se lisent seuls.

• Ce qu’est vraiment une fenêtre de contexte (et ce qu’elle coûte) couvre le mécanisme qui se trouve sous tout le reste : pourquoi la fenêtre est finie, pourquoi une fenêtre plus longue coûte plus que proportionnellement, et pourquoi la capacité n’est pas la fiabilité.
• Context engineering : décider ce que le modèle voit est le versant contenu. Choisir quels tokens le modèle voit à chaque étape d’une tâche, ce qui est une discipline de jugement, pas une astuce de prompt.
• Harness engineering : la machine autour du modèle est le versant machine. La boucle, les outils, les garde-fous, les sous-agents, et pourquoi travailler cette machine bat mesurablement le fait de changer de modèle.

Puis le premier mécanisme : plus la fenêtre est grande, plus la pourriture est silencieuse. Pourquoi une fenêtre de contexte plus large a relevé le plafond de ce qu’un agent peut tenter sans jamais acheter la moindre immunité contre les tokens parasites, et les habitudes qui gardent un contexte de travail sobre, délibérément.

Où tout ça va

La série se déroule en trois arcs, chacun une forme de contrôle différente.

Le premier, c’est le contexte que vous écrivez : tout ce que vous décidez avant que l’agent tourne. Garder la fenêtre sobre, ancrer votre vocabulaire métier pour que le modèle cesse de deviner, garder honnêtes les règles permanentes à mesure que le code bouge, et encoder l’architecture comme quelque chose qu’on applique plutôt que quelque chose qu’on décrit.

Le deuxième, c’est le contexte que vous imposez : correction et sûreté pendant l’exécution. Transformer une demande floue en spécification typée que l’agent exécute, faire pousser des règles de lint maison qui durcissent avec le temps, tracer des frontières de permissions, isoler le travail pour que des agents parallèles ne se percutent pas, et déboguer par l’observation plutôt qu’à l’aveugle.

Le troisième, c’est la portabilité et le coût d’exploitation : mesurer ce que vous dépensez vraiment, router chaque tâche vers le modèle le moins cher capable de la faire, écrire une configuration qui n’est pas soudée à un fournisseur, et mettre un vrai chiffre sur l’énergie derrière tout ça.

Chaque article est étroit et opérable. Un mécanisme, le problème qu’il résout, et quelque chose que vous pouvez exécuter. Je publierai ce qui a cassé à côté de ce qui a marché, parce que c’est dans les échecs que vivent réellement les décisions de conception.