Depuis une semaine, je médite sur les générateurs de code style RAD. Le genre déterministe à l’ancienne.
Les systèmes classiques avaient un problème fondamental : ils rendaient le code facile à générer et difficile à maintenir. Il fallait presque toujours éditer le rendu, ce qui rendait la régénération fragile.
Certains problèmes semblent solubles aujourd’hui, notamment la préservation des personnalisations via des mécanismes d’extension officiels.
Les systèmes RAD avaient raison sur un point important : traiter un modèle comme source de vérité.
Beaucoup étaient antérieurs à SOAP et REST, donc leurs modèles étaient principalement des schémas de base de données. Aujourd’hui, on peut représenter l’intention d’une application de façon plus riche, incluant les contrats, les permissions, les workflows, les intégrations et le comportement de l’UI.
Le défi, c’est de garder les applications maintenables pendant qu’elles évoluent.
La sécurité, la régénération, l’extensibilité et la rigidité architecturale étaient des faiblesses majeures. Le low-code a survécu, mais la promesse de générer du code d’application maintenable ne s’est jamais vraiment concrétisée.
Ma théorie, c’est qu’un générateur propre et flexible, exposé via MCP, pourrait réduire la consommation de tokens d’un agent d’un ordre de grandeur. En supposant que le workflow coûte moins cher que d’écrire le code directement. Reste à voir.
J’appréciais la prévisibilité des systèmes RAD. Quoi que vous bâtissiez, vous saviez à quoi vous attendre. La qualité du code était peut-être nulle, mais elle était nulle de façon constante.
L’entropie architecturale
Les agents de codage modernes ont presque le problème inverse.
Ils peuvent produire un code excellent, mais pas nécessairement la même architecture deux fois. Cette flexibilité introduit une entropie architecturale.
Il y a là une division du travail utile.
Laissons les générateurs déterministes gérer l’implémentation répétitive, les conventions et les résultats prévisibles. Laissons les agents gérer l’interprétation, la spécification et les exceptions.
Mettez l’intelligence dans l’outil qui pilote le générateur, plutôt que dans le générateur lui-même.
Je soupçonne que beaucoup de limitations reflétaient la technologie, les budgets et les pratiques de l’époque plutôt que la génération déterministe en soi.
La productivité des développeurs a radicalement changé depuis. Les agents de codage rendent aussi la création et la maintenance des générateurs moins coûteuses.
Si on pouvait passer de trois heures à dix minutes pour générer une application d’entreprise complexe, l’impact pourrait être substantiel.
La vingtième modification
Mais le temps de génération initial est peut-être la mauvaise métrique.
Le test le plus révélateur, c’est la vingtième modification.
C’est là que les systèmes RAD classiques s’effondraient. Chaque personnalisation augmentait la distance entre l’application et son modèle sous-jacent.
Un système qui reste facile à modifier parce que son modèle continue de représenter l’intention de l’application serait fondamentalement différent.
Peut-être que l’opportunité n’est pas de générer plus de code, ni même de le générer plus vite... mais plutôt de réduire la complexité que le développeur doit gérer personnellement.
Je suis curieuse de voir à quel point l’espace des possibles a changé.
Codex vient de livrer un premier jet.
Jetez un œil à cette magnifique abomination de prototype.
Je vais cogiter là-dessus encore un peu.