Claude Is Not a Compiler

Début 2025, j'ai écrit « Is Claude a Compiler? ». À l'époque, ma réponse était : je ne sais pas.

Je suis désormais assez sûr que la réponse est « non, c'est une erreur de catégorie, c'est mieux qu'un compilateur. » Mais cela demande un peu de déballage.

Les programmes informatiques sont notoirement complexes et capricieux. Un programme opère à un niveau de précision extrême. Il n'existe pas d'instruction CPU « à la louche ». Les objectifs de haut niveau, eux, sont profondément sous-spécifiés.

Dans une vision très stylisée du monde, le logiciel se construit en couches, chacune ajoutant de la spécification et masquant du détail « inutile ». La vision devient stratégie, les plans produit deviennent plans de code, le code devient binaires. Chaque étape est prise en charge par un rôle différent : dirigeant, VP, PM, architecte, ingénieur, compilateur.

Point crucial : chaque étape implique de prendre beaucoup de décisions. C'est ce que signifie augmenter le niveau de spécification. (C'est pourquoi l'une de mes deux métriques clés pour recruter des ingénieurs est le jugement. L'autre est la comity — la capacité à bien travailler ensemble.)

La couche du bas, du code source au binaire, c'est ce que fait un compilateur. Les compilateurs prennent beaucoup de décisions ! Inlining, allocation de registres, choix d'émettre un warning ou de rejeter carrément un programme. Et ces décisions comptent : elles pilotent la performance, la stabilité du système, la prévisibilité et les modes de défaillance. Le travail d'un ingénieur compilateur consiste à faire en sorte que le compilateur prenne des décisions constamment bonnes.

Un bon compilateur, digne de confiance, libère un ingénieur logiciel d'avoir à prendre ces décisions. La plupart des ingénieurs n'ont guère idée du fonctionnement d'un compilateur ; ils n'en ont pas besoin pour être efficaces.

En 2025, on opérait dans un monde où l'on utilisait les LLM pour générer de petits morceaux de code. Dans ce modèle mental, un agent de code pouvait s'insérer comme une nouvelle couche entre l'ingénieur et le compilateur traditionnel. Il « compile » du langage naturel en code, prenant des décisions pour que l'ingénieur n'ait pas à les prendre. Sa valeur est proportionnelle à sa fiabilité et à l'ampleur des décisions qu'il peut prendre.

Le problème, c'est que cette vision très stylisée du monde est fausse. Les abstractions fuient et les couches se frottent. Et même si ce n'était pas le cas, on y percerait des trous de toute façon.

Travailler à travers les couches a énormément de valeur ; la mécanique de sympathie compte.

Une partie de la manière dont l'Empire State Building a été construit en moins d'un an et sous budget (!!) tient à ce travail systématique à travers les couches. Par exemple, pour décider du bardage extérieur en acier chrome-nickel :

Ni les architectes, ni les constructeurs, ni les sous-traitants ne se sentaient compétents pour traiter ce problème technique complexe de construction sans consultation complète. En conséquence, après discussion préliminaire approfondie, une réunion réunissant tout le monde fut convoquée, à laquelle assistèrent des représentants du maître d'ouvrage [...].