Quelles architectures de code conviennent le mieux aux agents AI

Les agents d'IA écrivent maintenant du code, mais ils ont des limitations : la mémoire et la fenêtre de contexte sont beaucoup plus petites que celles d'un humain. Cela remet en question les approches architecturales traditionnelles du code — des approches développées par des humains pour des humains.

Pourquoi l'Architecture

Est Soudainement Devenue Plus Importante

Quand un agent écrit du code, il ne voit pas l'ensemble du système. Il doit comprendre la tâche, trouver les fichiers pertinents, comprendre comment ils sont connectés, apporter des modifications — tout cela dans une fenêtre de contexte limitée. Différentes architectures aident (ou entravent) ce processus différemment. Certaines approches contiennent les informations sous forme comprimée, structurée. D'autres sont dispersées dans le système, obligeant l'agent à voir un énorme morceau de code et à se souvenir de comment tout est connecté.

Quelles Architectures Fonctionnent Avec les Agents

Les plus utiles pour les agents d'IA :

• TDD (développement piloté par les tests) — les tests sont une spécification écrite en code. Un agent peut rapidement comprendre ce qu'une fonction fait en regardant les tests.
• Programmation fonctionnelle — les fonctions sont isolées les unes des autres, ne nécessitent pas une compréhension approfondie de l'état du système.
• DDD (conception orientée par le domaine) — sépare explicitement les domaines, chaque domaine est presque indépendant.
• Architecture hexagonale — des limites claires entre les couches, les adaptateurs décrivent explicitement l'interaction.
• CQRS (séparation des responsabilités entre commande et requête) — les commandes et les requêtes sont explicitement séparées, la logique est claire.

Moins utiles ou nécessitant de la prudence :

• POO avec héritage — l'encapsulation est bonne, mais les hiérarchies profondes de classes nécessitent de voir l'ensemble du graphe d'héritage.
• MVC/MVVM — structuré, mais les contrôleurs contiennent souvent une logique qui ne se trouve pas à la surface.
• Microservices — bons pour la séparation des responsabilités, mais l'agent doit se souvenir de comment ils interagissent.
• Architecture orientée événements — nécessite de suivre l'état global et les événements dispersés dans le système.

Pourquoi le Contexte Décide de Tout

Un humain peut garder à l'esprit l'architecture d'un système entier. Un agent ne peut pas. Pour un agent, seul ce qui se trouve dans sa fenêtre de contexte en ce moment compte. Les architectures comme TDD ou DDD fonctionnent parce qu'elles mettent l'information à une place évidente. Un test dit à l'agent ce qu'une fonction fait. Une limite de domaine dit où une zone de responsabilité se termine et une autre commence. Les fonctions qui ne dépendent pas de l'état global sont plus faciles à comprendre sans contexte. Les interfaces qui décrivent explicitement comment les composants interagissent économisent la fenêtre de contexte.

"À l'ère des agents, l'architecture n'est pas une question de beauté

du code, mais de compressibilité de l'information dans la fenêtre de contexte".

En Pratique

Les projets qui utilisent déjà TDD ou DDD obtiennent un avantage dès maintenant. Leur code est plus facile pour les agents. Les projets aux limites floues et à l'état implicite nécessitent plus d'efforts et d'erreurs de la part de l'agent. Cela ne signifie pas que vous devez réécrire tout le code. Cela signifie que lorsque vous choisissez entre plusieurs façons de résoudre un problème, vous devez choisir l'option architecturalement propre — car elle fonctionnera avec les agents de manière plus efficace.

Ce Que Cela Signifie

Les développeurs et les architectes peuvent commencer à choisir des approches non seulement parce qu'elles sont théoriquement correctes, mais parce qu'elles fonctionnent avec les limites de l'IA. TDD et DDD ne sont pas seulement de bonnes pratiques — elles deviennent un avantage compétitif dans le monde de la programmation avec l'IA.