Il y a ce problème fascinant qu’on rencontre quand on essaie de bâtir une IA de génération de code à haute vélocité. Ça tourne autour des métriques de complexité, mais c’est hors du champ du suivi de complexité que j’ai conçu jusqu’ici. Voyez-vous, alors que je tiens compte de la complexité des modules et des fichiers d’une app pendant que l’IA l’implémente... je ne tenais pas compte du score cognitif global de l’app, alors que j’ai les chiffres. Et c’est là que ça devient intéressant.
Quand la complexité liquéfie la continuité
Trop de complexité non contrôlée dans l’app elle-même finit par griller le cerveau, même quand on est rigoureux, qu’on utilise l’injection de dépendances et qu’on bâtit ses modules proprement.
Mais attendez, il y a un autre problème dans ce sac de nœuds. Le seuil de score de complexité menant à la fonte cognitive — celle qui provoque des refactorisations hallucinées — n’est pas particulièrement élevé. Ça arrive dans des apps que des humains considéreraient comme des bases de code relativement petites, avec une douzaine de fichiers d’application assez complexes.
À première vue, on pourrait croire que c’est un point de blocage total.
On pousse trop loin en maintenant la continuité sur trop de sessions, et on flingue son app parce qu’on est limité par les limites de la technologie LLM actuelle, pas vrai ?
Faux !
Les tests de flux comme ancres architecturales
Ma solution est une nouvelle approche des tests de flux. Le test de flux est un type de test unitaire pour les tests d’intégration qui se concentre sur le flux de données à travers des systèmes complexes. Il s’agit de cartographier les chemins de l’entrée à la sortie de toute l’app, et de déterminer ce qu’il faut pour aller du point A au point B en termes de fonctionnalités de base.
Les tests unitaires classiques ne suivent que l’entrée et la sortie de fonctions, modules et classes spécifiques. Écrivez un mauvais test, vous aurez de mauvais résultats. Mais cette méthode renforce le design de toute votre app, de bout en bout, dès la conception. Ça vous verrouille sur de bons principes de design et sur un processus transparent et cognitivement simple.
Cartographier le flux, puis l’imposer
Voilà ma méthode : tout au début et à chaque jalon de fonctionnalité, je maquette tout le flux de données de l’application. Je trace les parties clés de l’API centrale et je cartographie comment les données passent d’un côté à l’autre de l’arbre de décision.
Avec les tests de flux, on peut tester l’app entière, vérifier comment les données circulent dans tout le système, peu importe sa complexité. Ils vous montrent ce qui marche et ce qui est pété. Ici, la couverture partielle n’existe pas : une couverture partielle signifie que l’app est cassée.
Je traite ces tests de flux comme des vérités immuables qui ne peuvent pas être modifiées pendant un cycle de codage. Et en les liant à des hooks de pré-commit Git, on ne peut tout simplement pas commit si un test de flux échoue.
Je trouve ça élégant.
Le NLP, c’est quand même passionnant, non ?