Ce que 1 500 heures de développement assisté par l'IA m'ont appris sur la différence entre le code qui s'exécute et le code qui appartient.*
TL;DR : ArchCodex empêche la dérive architecturale dans le code généré par l'IA en faisant apparaître les bonnes contraintes au bon moment. Les benchmarks ont montré : 36 % de risque de production en moins, 70 % de dérive en moins et l'Opus 4.5 a atteint zéro dérive sur des tâches vagues. Les modèles de haut niveau en ont besoin pour des raisons de cohérence. Les modèles de niveau inférieur en ont besoin pour produire du code fonctionnel (+55 pp).
GitHub - ArchCodexOrg/archcodex
Ceci est la première partie ; des plongées plus profondes à venir.
Pendant plus de 1 500 heures et environ 1 200 € de coûts API, j'ai construit NimoNova en tant que projet parallèle le soir et le week-end : un espace de travail de recherche de 2 300 fichiers avec des graphiques de connaissances automatiques, une extraction de faits et de chronologies, une analyse de documents et un RAG à plusieurs niveaux. Je l'ai construit presque entièrement avec des assistants de codage LLM.
Le code compilé. Les tests ont réussi. Les utilisateurs pourraient réellement l'utiliser.
Mais j'avais ce sentiment tenace : et si c'était plein d'erreurs que je ne pouvais pas voir ?
NimoNova : graphiques de connaissances extraits automatiquement des sources de recherche
Les LLM sont doués pour écrire du code qui semble fonctionner. Ils peuvent comprendre les API, suivre la syntaxe et implémenter correctement des algorithmes complexes.
Ce pour quoi ils sont terribles, c'est d'écrire du code qui leur appartient.
Ce n'est pas seulement mon expérience. Les chercheurs en sécurité ont identifié le même schéma :
"L'un des risques les plus difficiles à détecter est ce que l'on pourrait appeler la dérive architecturale : des modifications de conception subtiles générées par un modèle qui brisent les invariants de sécurité sans violer la syntaxe. Ces modifications échappent souvent aux outils d'analyse statique et aux réviseurs humains." — Laboratoires Endor, 2025
Chaque base de code a des modèles. Conventions. Une architecture implicite que les développeurs expérimentés apprennent en travaillant dessus, en construisant des modèles mentaux et grâce à des connaissances tribales. Lorsque vous demandez à un LLM d'ajouter une fonctionnalité, il ne sait pas que votre équipe utiliserequireProjectPermission()au lieu de contrôles manuels de propriété. Il ne sait pas que vous avez une convention de mutation par opération, ni que les exportations de barils se font en frères et sœurs.index.tsfichiers, ou que les enregistrements supprimés de manière logicielle doivent être filtrés par défaut (ou que la suppression logicielle est une chose).
Le LLM écrira quelque chose qui semble fonctionner. Mais il n’écrira pas quelque chose qui convienne.
Invites minutieuses, exécutions multiples, révisions manuelles. Tout a contribué à le contrer. Mais lorsque vous diffusez du code à grande échelle, les choses passent inaperçues. Une grosse application avec de nombreux modules et fonctionnalités dérivera. Cela se produit également dans les bases de code créées par l'homme. La différence est qu’avec les LLM, cela se produit plus rapidement et plus souvent.
Et voici ce qui a aggravé la situation : les composés dérivants. Lorsqu'il y a une incohérence dans votre base de code : plusieurs façons de faire la même chose, des utilitaires en double, des modèles concurrents, les LLM fonctionnent moins bien. Ils ne peuvent pas choisir la bonne approche lorsqu’il en existe plusieurs. Ils copient le mauvais modèle car il est apparu plus récemment dans son contexte. La dérive s'accélère.
Une fonction utilise le système d'autorisation centralisé ; un autre effectue une vérific...
[Courte citation de 8% de l'article original]