L'autre jour, en parcourant mes flux de veille technique, je suis tombé sur une énième publication sensationnaliste affirmant qu'une IA venait de « réécrire son propre code en toute autonomie » pour devenir infiniment plus intelligente. Dans l'écosystème du développement logiciel, ce mythe de l'auto-amélioration perpétuelle suscite autant d'enthousiasme que d'inquiétudes infondées.
En tant que développeur indépendant et fondateur d'Agile Up, j'ai choisi d'aborder cette problématique sous l'angle de l'ingénierie rigoureuse lors de la conception de Code Buddy. Plutôt que de fantasmer sur une autonomie débridée, nous devons nous poser une question concrète : comment permettre à un agent de perfectionner ses méthodes sans introduire de régressions critiques ni déstabiliser la base de code ?
L'inspiration formelle : les machines de Darwin-Gödel
Pour concevoir le sous-système d'auto-amélioration de Code Buddy (src/agent/self-improvement/), je me suis appuyé sur les principes théoriques de la machine de Gödel formalisée par Jürgen Schmidhuber et sur les algorithmes évolutionnaires darwiniens.
La règle d'or d'une telle architecture réside dans un cloisonnement strict : il faut distinguer la couche d'apprentissage réversible et contextuelle de l'évolution structurelle du code source lui-même. Chaque couche nécessite des garanties de sécurité et des métriques d'évaluation adaptées.
1. La couche d'apprentissage réversible et ses portes de contrôle
La première forme d'adaptation concerne les outils dont l'agent se dote pour accomplir ses tâches. Lorsqu'un développeur exécute buddy improve tools, l'agent peut proposer de nouveaux outils spécialisés, identifiés par le préfixe authored__*. Par défaut le mode est propose-only : rien n'est persisté. Il faut --apply (ou CODEBUDDY_SELF_IMPROVE=true) pour conserver un outil validé dans .codebuddy/self-improvement/authored-tools.json.
Il est hors de question d'intégrer aveuglément un outil généré par un modèle de langage. Pour être validé, le candidat doit franchir successivement les portes de tool-gate.ts :
- Porte G1 (Sécurité statique) : un scan sans exécution (motifs dangereux, secrets, placeholders d'omission, écriture disque, réseau). Ce n'est pas une analyse AST complète.
- Porte G3 (Cas comportementaux visibles) : l'outil doit réussir les cas de tests fonctionnels déclarés, dans un bac à sable qui ne l'enregistre pas.
- Porte G4 (Cas secrets / « held-out tests ») : pour contrer le reward hacking — coder en dur les sorties des tests visibles —, l'outil est confronté à des entrées que le proposeur n'a jamais vues. Un scénario sans cas secrets est refusé. Si G4 échoue, la proposition est rejetée sans altérer l'environnement.
2. L'évolution du moteur applicatif sous isolation stricte
La modification du code source de l'agent lui-même (src/) relève d'un niveau d'exigence encore plus élevé. Lorsque buddy evolve run --goal "…" est déclenché, le système explore des variantes :
- Isolation en git worktree : aucune modification n'est opérée directement sur votre espace de travail. Chaque candidat est compilé et scoré dans un arbre Git jetable.
- Score de fitness empirique : un agrégat pondéré dans
[0,1]— typiquementtsc --noEmit, une cible de tests unitaires (pas la suite complète à ~27 000 tests) et, en option, des évals LLM. Une régression par rapport à la ligne de base fait échouer le candidat. - Diversité par MAP-Elites : l'archive conserve le meilleur candidat par niche de comportement, avec la généalogie (parent, génération, plan).
- Validation humaine obligatoire : rien n'est fusionné silencieusement.
buddy evolve keep <id> --confirmn'agit que sur la branche courante, jamais surmain/master— l'invariant est dans le code (assertMergeTargetAllowed).
Cette fonctionnalité est désactivée par défaut et exige CODEBUDDY_EVOLVE=true.
Limites honnêtes
Il est capital de démystifier le comportement des modèles de langage dans ces architectures. Un LLM ne possède pas de conscience de la cohérence globale d'un projet ; il optimise localement ce qu'on lui demande de maximiser. Sans surveillance, il peut générer des outils inutilement redondants ou sur-optimiser un test unitaire au détriment de la lisibilité.
L'auto-amélioration logicielle n'a de valeur pratique que si l'arbitre reste inflexible : un banc de test déterministe, reproductible, et un développeur humain qui conserve la responsabilité de la livraison finale.
EXCERPT: Un agent qui écrit ses propres outils et fait évoluer son code : ce que Code Buddy fait vraiment, les portes empiriques qui l'encadrent, et pourquoi un humain garde le dernier mot.
CATEGORY: IA
