Josh Bleecher Snyder publie un article au titre explicite : « Claude n’est pas un compilateur ». L’argument est que Claude appartient à une catégorie différente, supérieure sous certains aspects. Un compilateur prend du code source et produit des binaires de façon déterministe : même entrée, même sortie. Un LLM prend une description en langage naturel et prend des décisions à chaque niveau de la stack, de la stratégie à l’implémentation. Le traiter comme un compilateur signifie s’attendre à une reproductibilité que la nature de l’outil ne garantit pas.

Pour ceux qui déploient des agents en production, le point est pratique. Si tu délègues à un agent une tâche complexe et t’attends à ce qu’il la refasse à l’identique la fois suivante, tu seras déçu. L’LLM prend des décisions sous-spécifiées, comme un architecte ou un PM, et la valeur réside dans le nombre et la qualité de ces décisions, non dans leur prévisibilité. Comme nous l’évoquions le 20 juillet quand trois papers convergeaient sur le même point, l’architecture avec laquelle tu circuites et vérifies un agent compte plus que la puissance du modèle.

Snyder l’illustre avec un cas réel : son équipe a construit un serveur DNS distribué en utilisant Claude pour la recherche, la conception et l’implémentation. Le modèle a fonctionné verticalement à travers la stack, quelque chose qu’un compilateur ne fait pas. Le prix est d’accepter que le même prompt produira toujours un résultat légèrement différent.

En détail

L’erreur catégorique.

Snyder avait déjà posé la question en 2025 : « Claude est-il un compilateur ? » Sa réponse à l’époque était « je ne sais pas ». Maintenant, il en est sûr : il appartient à une catégorie différente. Un compilateur opère à un seul niveau, celui de la traduction de source en binaire, et le fait avec précision déterministe. Les décisions qu’il prend (inline, allocation de registres, avertissements) sont internes à ce niveau et fiables par construction. L’ingénieur n’a pas besoin d’y penser.

Un LLM opère à tous les niveaux simultanément. Il peut parler de stratégie produit, d’architecture système, de détails d’implémentation, de code machine. C’est l’avantage : comme le rappelle Snyder en citant la construction de l’Empire State Building, les meilleurs projets sont ceux où les équipes travaillant à différents niveaux communiquent entre elles. L’LLM le fait tout seul, sans avoir besoin de programmer des réunions.

Le prix de la verticalité.

La verticalité coûte la reproductibilité. Un compilateur donne la même sortie pour la même entrée, toujours. Un LLM non, et jouer avec une température à zéro ou des seeds fixes ne change rien à la nature de quelque chose qui prend des décisions sous-spécifiées. Quand tu demandes « écris-moi un serveur DNS distribué », il y a mille décisions implicites que le modèle doit prendre, et il les prendra de façon légèrement différente à chaque fois.

Snyder l’illustre avec un cas réel. Son équipe (exe.dev) avait un problème de latence DNS : les serveurs démarraient si vite que la propagation DNS devenait le goulot d’étranglement. Ils ont écrit un serveur DNS personnalisé, puis ont ajouté des régions, et le DNS est redevenu le problème. La solution était un serveur DNS géographiquement distribué et cohérent. Au lieu de le construire manuellement niveau par niveau, ils ont utilisé Claude pour la recherche sur les designs distribués, les bizarreries du protocole DNS, les alternatives d’implémentation, jusqu’au code. Le modèle a travaillé à travers toute la stack en une seule session.

Ce que cela signifie pour ceux qui construisent.

Si tu mets des agents en production, l’implication est double. Première : arrête de t’attendre à ce que le même prompt produise la même sortie. C’est la nature de l’outil. Deuxième : conçois la vérification, non la reproductibilité. Comme trois papers convergents l’ont montré le 20 juillet, la qualité d’un système agentic dépend de comment tu circuits les contrôles, non de la prévisibilité du modèle.

Snyder ne présente pas un paper avec des données, mais une expérience. La limite est là : c’est quelqu’un qui raconte sa pratique, avec un échantillon de un. Le point conceptuel cependant est solide et converge avec ce que le domaine apprend sur ses propres erreurs : traiter les LLM comme des compilateurs mène à la frustration, les traiter comme des décideurs cross-layer mène à des résultats qu’un compilateur ne pourrait pas produire.