Le code de Claude divulgué révèle le système KAIROS et le déficit de vérification des agents d'IA

Ce que la fuite a révélé

Anthropic a accidentellement inclus une source map dans son package npm, exposant l'intégralité du code source de Claude Code. La fuite contient 512 000 lignes de TypeScript, 44 drapeaux de fonctionnalité, et un système caché appelé KAIROS.

KAIROS est décrit comme un agent en arrière-plan toujours actif qui effectue plusieurs fonctions pendant que l'utilisateur est inactif :

• Consolide la mémoire
• Fusionne les observations
• Supprime les contradictions
• Prépare le contexte pour qu'il soit propre au retour de l'utilisateur

L'expérience de développement indépendant

Un développeur solo construisant une plateforme TypeScript de 668 000 lignes avec Claude Code a rencontré les mêmes limites que KAIROS adresse. Il exécute des campagnes autonomes s'étalant sur plusieurs sessions avec des fichiers d'état persistants qui transportent le contexte au-delà des limites de la fenêtre de contexte.

Le problème : les campagnes s'arrêtent entre les sessions. Lorsqu'on termine une phase et qu'on revient plus tard, les développeurs doivent redémarrer manuellement, relire les fichiers de campagne, et déterminer où les choses se sont arrêtées parce que la mémoire de l'agent disparaît avec la session.

La solution qu'ils ont construite : un démon qui enchaîne les sessions via des déclencheurs programmés. Une session se termine, écrit l'état, se termine avec le code 0 (« aucune erreur »), et le démon détecte la fin pour lancer la session suivante avec le contexte complet. Cela a réduit des campagnes qui prenaient une semaine de redémarrages manuels pour s'exécuter en une seule fois.

Le problème de vérification

Le développeur a découvert que le code de sortie 0 signifie « aucune erreur » mais ne signifie pas « cela fonctionne ». Lors de leur première nuit d'exécution du démon, un agent a livré une fonctionnalité invisible — une campagne complète terminée avec une vérification de type propre, zéro avertissement, et une fin confiante, mais 37 des 38 entités étaient manquantes dans l'application réelle.

Dans un autre cas, une session de flotte a remplacé 6 composants fonctionnels en parallèle, résultant en des composants affichant « Running NaN » sans chronologie ni signes vitaux. Les agents n'ont jamais rendu ce qu'ils ont construit — ils ont seulement vérifié que cela compilait et sont passés à autre chose.

La solution de couche de vérification

Le développeur a réalisé que « le démon seul est un moyen plus rapide de livrer du code cassé ». Ils ont construit une couche de vérification qui force les agents à prouver leur travail visuellement :

• Naviguer sur des routes réelles dans un vrai navigateur
• Compter les éléments DOM
• Capturer des captures d'écran
• Si une vue qui devrait avoir 38 cartes d'entité en a zéro, le système le détecte
• Si un agent a modifié des fichiers d'interface utilisateur, il ne peut pas terminer sans artefacts de capture d'écran

Cela est implémenté comme une barrière stricte, pas une suggestion.

L'écart fondamental

KAIROS résout le problème de mémoire mais ne résout pas le problème de vérification. Bien qu'il fusionne les observations, supprime les contradictions, et convertit des aperçus vagues en faits concrets, ni la consolidation de la mémoire ni le mode démon n'adressent l'écart fondamental : les agents ne peuvent pas vérifier leur propre travail visuellement. Ils peuvent prouver la structure mais ne peuvent pas prouver l'apparence.

Le développeur note que la convergence entre le KAIROS d'Anthropic et leur solution indépendante indique un plafond réel : une fois que les sessions sont suffisamment longues et que les campagnes s'étalent sur des jours, l'exécution en arrière-plan persistante devient inévitable. Cependant, « le démon est la partie facile. N'importe qui peut enchaîner les sessions. La partie difficile est de construire l'infrastructure qui détecte les échecs que le démon livrera avec confiance. »

Leçon clé

Si vous construisez une forme quelconque d'exécution autonome d'agents, posez une question avant de livrer : mon agent peut-il prouver que ce qu'il a construit fonctionne réellement ? Si la réponse est « cela a compilé », vous risquez de rencontrer les mêmes problèmes. Les 27 post-mortem documentés du développeur leur ont appris que « le démon est un multiplicateur de force. Sans une couche de qualité, il multiplie vos échecs. »

Le démon, la couche de vérification, et le système de persistance de campagne sont open-source sur github.com/SethGammon/Citadel.