Raisonnement Externe : Utiliser des Agents de Codage avec un LLM

Un suivi de “Illusion Stochastique : Raisonnement LLM” explorant comment les structures externes peuvent augmenter les capacités des LLMs dans le développement logiciel

Introduction : Au-delà de l’Illusion Stochastique

Dans “Illusion Stochastique : Raisonnement LLM”, j’ai exploré comment les Grands Modèles de Langage créent une forme de raisonnement impressionnante mais finalement limitée. Les LLMs génèrent des séquences plausibles à travers une “construction stochastique à capacité limitée” plutôt qu’un véritable raisonnement causal, créant ce que j’appelle un “Flux de Conscience Agentique” qui semble comprendre mais opère fondamentalement par correspondance de motifs. Une correspondance de motifs très sophistiquée !

Cette limitation devient particulièrement problématique lorsque les développeurs déploient les LLMs comme agents de codage. Le développement logiciel nécessite une cohérence logique soutenue, des décisions architecturales complexes et une validation systématique—exactement le genre de raisonnement causal multi-étapes où les LLMs “abandonnent” typiquement ou produisent des résultats incohérents.

Mais que se passerait-il si les développeurs pouvaient augmenter les capacités des LLMs avec des structures de raisonnement externes ? Que se passerait-il si au lieu de demander au LLM de maintenir une logique complexe en interne, les développeurs fournissaient des frameworks externes qui guident, contraignent et valident sa sortie ?

Clairement, cela ajoute de la valeur. Claude Code et OpenHands avec Mistral montrent ce qui est possible. J’ai utilisé Claude Code sur un nouveau projet, l’appliquant à un domaine dans lequel je n’avais pas développé auparavant - à la fois le Langage (TypeScript) et l’Environnement (extension VS Code).

Ce post explore comment ajouter du contexte et des outils, effectivement du raisonnement externe, qui transforme les LLMs d’outils impressionnants mais peu fiables en partenaires de développement systématiques et fiables.

Le Défi : Illusion Stochastique dans le Code

Lorsque les LLMs agissent comme agents de codage, l’illusion stochastique se manifeste de manières prévisibles :

Dérive Architecturale

Les LLMs ont du mal à maintenir des décisions architecturales cohérentes à travers une grande base de code. Ils peuvent implémenter une fonctionnalité en utilisant un motif, puis passer à une approche complètement différente pour une fonctionnalité similaire, créant du code incohérent et non maintenable.

Dégradation des Exigences

À mesure que les conversations s’allongent, les LLMs perdent progressivement la trace des exigences originales. Ils peuvent implémenter une fonctionnalité qui fonctionne mais viole les contraintes antérieures, ou abandonner les cas limites qui ont été spécifiés tôt dans la conversation.

Lacunes de Couverture de Tests

Les LLMs sont notoirement pauvres en tests systématiques. Ils peuvent écrire des tests pour le chemin heureux mais manquer les conditions d’erreur, ou écrire des tests complets pour un module tout en ignorant complètement les autres.

Le Piège du “Assez Bon”

Peut-être le plus dangereusement, les LLMs tendent à produire du code qui fonctionne immédiatement mais échoue sous des conditions plus complexes. Ils optimisent pour le succès rapide plutôt que pour la maintenabilité à long terme.

Abandon de la Complexité

Face à une refactorisation complexe ou à des améliorations systématiques, les LLMs proposent souvent des raccourcis ou des solutions incomplètes plutôt que de travailler à travers la complexité complète.

Ces échecs ne sont pas aléatoires, ils suivent des limitations fondamentales de la génération stochastique. Le LLM peut maintenir une cohérence locale mais a du mal avec la cohérence globale, la validation systématique et le raisonnement logique soutenu.

Structures de Raisonnement Externe : La Solution

L’insight clé est que je n’ai pas besoin de résoudre le problème d’illusion stochastique, je dois travailler avec lui. Au lieu de demander aux LLMs de maintenir un raisonnement complexe en interne, je peux fournir des structures externes qui guident leur sortie vers des résultats systématiques et cohérents.

Ce n’est pas seulement théorique, voici un exemple concret : le développement d’une extension VS Code pour l’intégration micro.blog, construite en utilisant des LLMs mais guidée par des structures de raisonnement externes, basées sur les meilleures pratiques de développement.

Conception Pilotée par le Domaine (Domain-Driven Design) comme Logique Externe

La Conception Pilotée par le Domaine (Domain-Driven Design - DDD) fournit un framework de raisonnement externe crucial. Au lieu de laisser le LLM prendre des décisions architecturales ad hoc, j’ai établi des frontières de domaine claires :

src/
├── domain/                   # Logique métier pure (pas de dépendances)
│   ├── Blog.ts              # Entité Blog avec validation de domaine
│   ├── Post.ts              # Entité Post avec analyse de contenu
│   ├── LocalPost.ts         # Entité post local avec frontmatter
│   └── Credentials.ts       # Objet valeur d'authentification
├── services/                # Services d'application
│   ├── MicroblogService.ts  # Orchestration principale
│   ├── ApiClient.ts         # Client HTTP
│   └── PublishingService.ts # Workflow de publication
└── providers/               # Intégration VS Code
    ├── TreeProvider.ts      # Vue arbre de contenu
    └── ContentProvider.ts   # Visualiseur de contenu en lecture seule

Cette structure agit comme un raisonnement externe qui prévient la dérive architecturale. Voilà—plus de code spaghetti ! Lorsque le LLM a besoin d’ajouter de nouvelles fonctionnalités, les frontières DDD le forcent à considérer :

  • Est-ce de la logique de domaine ou de la logique d’application ?
  • Cela devrait-il être une nouvelle entité ou étendre une existante ?
  • Quelles sont les dépendances et comment s’écoulent-elles ?

La structure externe fournit le framework logique que le LLM suit, compensant pour son incapacité à maintenir la cohérence architecturale en interne.

Développement Piloté par les Tests (Test-Driven Development) comme Validation Externe

Le Développement Piloté par les Tests d’Acceptation (Acceptance Test-Driven Development - ATDD) fournit une validation externe du raisonnement LLM. Au lieu de faire confiance au LLM pour écrire du code correct, j’ai établi un workflow de test systématique :

// Validation externe : tests écrits avant l'implémentation
suite('Phase de Création de Contenu', () => {
  test('utilisateur peut créer un nouveau post local', async () => {
    const title = 'Mon Post de Test';
    await executeCommand('microblog.newPost', title);
    
    // Validation externe : vérifier le workflow complet
    const localDrafts = await getTreeViewItems('📝 Brouillons Locaux');
    assert.ok(localDrafts.includes(title));
    
    const filePath = path.join(workspacePath, 'content', `${title.toLowerCase().replace(/\s+/g, '-')}.md`);
    assert.ok(await fileExists(filePath));
  });
});

Cette validation externe capture les échecs de raisonnement LLM qui passeraient autrement inaperçus :

  • Le LLM a-t-il implémenté le workflow complet ?
  • La fonctionnalité fonctionne-t-elle dans des conditions limites ?
  • Tous les points d’intégration sont-ils correctement connectés ? (Croyez-moi, les bugs d’intégration sont où les bonnes intentions vont mourir).

Cette approche de validation systématique fait écho au concept de TDD comme fonction de récompense, où les métriques externes guident les décisions de développement et fournissent un retour quantifiable sur la qualité du code au-delà du simple passage de tests.

Documentation comme Mémoire Externe

Les LLMs n’ont pas de mémoire persistante à travers les conversations. Pour compenser, j’utilise CLAUDE.md comme mémoire externe qui préserve les décisions architecturales, les protocoles de développement et les leçons apprises :

## Architecture (DDD dans la Structure VS Code)
- Les entités de domaine n'ont pas de dépendances externes
- Les services orchestrent entre le domaine et l'infrastructure
- Les providers gèrent seulement l'intégration VS Code

## Commandes de Développement
- `npm run compile` - Construire TypeScript
- `npm test` - Lancer tous les tests (114 passent)
- `npm run lint` - Validation ESLint

## Portes de Qualité (Non-Négociables)
1. Lancer `npm run compile` - s'assurer que TypeScript compile proprement
2. Lancer `npm test` - s'assurer que tous les tests passent
3. Lancer `npm run lint` - s'assurer de la conformité du style de code

Cette mémoire externe empêche le LLM de prendre des décisions qui contredisent les choix architecturaux antérieurs ou d’oublier les pratiques de développement établies. Cette approche documentation-first s’appuie sur les principes du développement basé sur l’intention, où une documentation claire et des processus systématiques guident le développement assisté par l’IA vers des résultats plus fiables.

Développement Incrémental comme Contrôle Externe

Le développement logiciel complexe nécessite de décomposer de gros problèmes en pièces gérables. L’outil TodoWrite de Claude Code fournit une gestion de tâches externe qui empêche le LLM de tenter de tout résoudre à la fois :

// Gestion de tâches externe empêche l'abandon de complexité
[
  {"content": "Créer l'entité domaine LocalPost", "status": "completed"},
  {"content": "Implémenter les opérations de fichier dans FileManager", "status": "in_progress"},
  {"content": "Ajouter le workflow de publication", "status": "pending"},
  {"content": "Intégrer avec la vue arbre VS Code", "status": "pending"}
]

L’outil TodoWrite de Claude Code agit comme une structure de contrôle externe qui force le LLM à :

  • Travailler systématiquement à travers des problèmes complexes
  • Compléter chaque étape avant de passer à la suivante
  • Maintenir la visibilité du progrès
  • Prévenir le comportement “d’abandon de complexité” sur les tâches complexes

L’outil est spécifiquement conçu pour adresser la tendance du LLM à abandonner les implémentations complexes. En externalisant la gestion de tâches, Claude Code transforme le processus de génération stochastique en un workflow systématique où chaque étape doit être complétée avant de procéder à la suivante.

Protection de Tests de Régression comme Validation Externe

Peut-être le plus important, j’ai implémenté une protection de tests de régression qui empêche le LLM de briser accidentellement la fonctionnalité existante :

## PROTECTION DE TESTS DE RÉGRESSION (CRITIQUE)
La suite de tests de régression est PROTÉGÉE et ne devrait JAMAIS être modifiée pendant le développement de fonctionnalités.
- LECTURE SEULE pendant le développement de fonctionnalités
- Modifier seulement quand explicitement demandé
- Valide la fonctionnalité complétée

Ce système de validation externe s’assure que lorsque le LLM ajoute de nouvelles fonctionnalités, il ne brise pas par inadvertance la fonctionnalité existante—un mode d’échec commun quand la génération stochastique perd la trace des contraintes globales.

Implémentation du Monde Réel : Les Résultats

L’approche de raisonnement externe a produit des résultats mesurables dans le projet d’extension VS Code :

Succès Quantitatif

  • 114 tests passants avec une couverture complète
  • Architecture propre maintenue à travers 3 phases de développement
  • Zéro échec de régression pendant le développement de fonctionnalités
  • Livraison de fonctionnalités réussie de toutes les fonctionnalités planifiées

Améliorations Qualitatives

  • Motifs de code cohérents à travers toute la base de code
  • Séparation appropriée des préoccupations entre domaine, services et providers
  • Gestion d’erreurs systématique à travers tous les modules
  • Documentation complète maintenue tout au long du développement

Changements de Comportement LLM

Le plus important, les structures de raisonnement externe ont changé comment le LLM se comportait :

  • Approche systématique plutôt qu’ad hoc de développement
  • Décisions architecturales cohérentes à travers les fonctionnalités
  • Implémentation complète de fonctionnalités plutôt que des solutions partielles
  • Validation de qualité proactive plutôt que correction de bugs réactive

C’est comme la différence entre avoir un bon éditeur et réviser frénétiquement à 2h du matin. (Devinez lequel je préfère ?)

Directives pour la Conception de Raisonnement Externe

Basé sur cette expérience, voici les principes pour concevoir des structures de raisonnement externe efficaces :

1. Compenser les Limitations Spécifiques des LLMs

  • Mémoire : Fournir une documentation persistante et du contexte
  • Cohérence : Établir des frontières architecturales claires
  • Validation : Implémenter des workflows de test systématiques
  • Complexité : Décomposer les gros problèmes en pièces gérables

2. Rendre les Contraintes Explicites

  • Portes de qualité qui doivent être passées avant de procéder
  • Frontières architecturales qui ne peuvent pas être violées
  • Exigences de test qui doivent être satisfaites
  • Protocoles de développement qui doivent être suivis

3. Fournir un Retour Systématique

  • Tests automatisés qui capturent les échecs de raisonnement
  • Suivi de progrès qui prévient l’abandon
  • Métriques de qualité qui mesurent le succès systématique
  • Documentation qui préserve les leçons apprises

4. Équilibrer Créativité avec Structure

  • Frontières de domaine qui permettent la créativité dans les contraintes
  • Développement piloté par les tests qui valide les solutions créatives
  • Développement incrémental qui permet l’exploration dans les limites
  • Portes de qualité qui assurent la validation systématique

5. Rendre le Raisonnement Externe Visible

  • Listes de tâches qui montrent le progrès systématique
  • Résultats de tests qui démontrent la validation
  • Documentation qui explique les décisions architecturales
  • Métriques de qualité qui mesurent le succès systématique

Conclusion : Intelligence Hybride

L’avenir du développement assisté par l’IA ne concerne pas la construction de meilleurs LLMs—il concerne la construction de meilleurs systèmes de raisonnement externe qui augmentent les capacités des LLMs.

Les LLMs excellent en reconnaissance de motifs, génération de code et résolution créative de problèmes. Ils ont du mal avec le raisonnement logique soutenu, la validation systématique et la cohérence architecturale. En fournissant des structures externes qui gèrent ces aspects systématiques, nous pouvons créer des systèmes d’intelligence hybride qui combinent le meilleur des deux approches.

Ce n’est pas différent des humains, bon définitivement moi, les projets sont complexes, nous bénéficions tous de ce genre de structures externes.

Des outils comme Claude Code et OpenHands démontrent déjà cette approche hybride en pratique, montrant comment les structures de raisonnement externe peuvent transformer les LLMs en partenaires de développement fiables.

L’Approche Hybride

  • Les LLMs fournissent créativité, reconnaissance de motifs et implémentation rapide
  • Le raisonnement externe fournit cohérence, validation et contrôle systématique

Cette approche hybride s’intègre naturellement avec d’autres pratiques de développement systématiques—TDD comme fonction de récompense fournit le framework de validation quantitative, tandis que le développement basé sur l’intention offre le workflow structuré qui rend le raisonnement externe pratique dans les scénarios de développement du monde réel.

Prochaines Étapes Pratiques

  1. Identifier les modes d’échec des LLMs dans votre processus de développement
  2. Concevoir des structures externes qui compensent ces limitations
  3. Implémenter une validation systématique qui capture les échecs de raisonnement
  4. Créer des boucles de retour qui améliorent le raisonnement externe au fil du temps
  5. Documenter l’approche pour qu’elle puisse être raffinée et partagée

Le problème d’illusion stochastique ne va pas disparaître—mais il n’a pas à limiter ce que les développeurs peuvent accomplir avec les LLMs. En concevant des structures de raisonnement externe réfléchies, les développeurs peuvent transformer des assistants de codage peu fiables en partenaires de développement systématiques et fiables.

La clé est de reconnaître que le problème n’est pas le raisonnement du LLM—c’est notre attente que le LLM devrait gérer tout le raisonnement en interne. Lorsque les développeurs fournissent des structures externes qui guident, contraignent et valident la sortie des LLMs, ils créent quelque chose de plus puissant que l’un ou l’autre pourrait accomplir seul : une véritable intelligence hybride.

Lectures Connexes

Ce post fait partie d’une série explorant les pratiques de développement assisté par l’IA :

Ce post est basé sur une expérience réelle de développement d’une extension VS Code en utilisant des LLMs guidés par des structures de raisonnement externe. Le projet complet, incluant tous les outils de raisonnement externe et la documentation, est disponible comme étude de cas en développement systématique assisté par l’IA.