Il est remarquable de constater comment les non-développeurs ont récemment été en mesure de créer leurs propres applications, générant même des revenus. Nous avons récemment observé des avancées significatives dans le domaine du développement par l'IA, avec des succès allant du « greenfield code » (applications construites de zéro) au « brownfield code » (applications existantes à grande échelle). Les modèles les plus récents sont devenus bien plus performants dans l'utilisation d'outils et ont rencontré un succès considérable dans l'implémentation de fonctionnalités au sein d'applications plus vastes, à tel point que les développeurs s'arrêtent à peine pour réviser le code. Ils consacrent davantage leur temps à la définition des exigences (prompting) et aux tests fonctionnels, ce qui leur permet de livrer plus de fonctionnalités.
En même temps, développer de nouvelles fonctionnalités aussi rapidement risque d'augmenter la dette technique au point où il devient pratiquement impossible de progresser. Sans supervision, les équipes peuvent se retrouver avec des montagnes de code spaghetti, il est donc essentiel de garder à l'esprit les standards de qualité du code avant que le problème ne devienne incontrôlable.
Maintenir des standards élevés de qualité du code est plus facile à dire qu'à faire. La revue humaine ne peut pas suivre le rythme, et demander à Claude ou Cursor de réviser votre code revient à demander à quelqu'un de réviser une thèse sans aucun contexte de la discipline ou des standards à respecter.
Que font les équipes lorsque le code IA s'accumule ?
Le coût de l'omission des revues, en particulier pour les modifications architecturales, se manifeste plus tard, généralement après quelques mois. Les modifications générées par l'IA s'empilent les unes sur les autres, et chaque couche suppose que celle qui la précède est solide. Lorsque ce n'est pas le cas, le modèle dispose d'une base fragile pour se construire, tout comme les développeurs qui l'interrogent. Les bugs apparaissent dans des endroits inattendus et même de petites modifications commencent à produire des effets secondaires qui prennent du temps à déboguer.
À un certain point, la vélocité élevée du premier mois commence à s'inverser. L'équipe déploie plus lentement car chaque PR ressent désormais le poids de tout ce qui l'a précédé.
Ensuite, lorsque les équipes tentent de faire du nettoyage, c'est une tâche considérable. Les organisations essaient même de résoudre le problème avec des spécialistes du "vibe coding cleanup". Vous pouvez trouver des personnes occupant ce rôle sur LinkedIn dès maintenant.
Il semble contradictoire de bénéficier de l'IA mais de devoir ensuite mobiliser plus de personnes pour résoudre les problèmes qu'elle a engendrés. Les équipes devraient donc prendre des mesures pour examiner le code de manière précoce et efficace.
Comment maintenir une dette technique faible
Les meilleures options trouvées jusqu'à présent pour réduire la dette technique se répartissent généralement en deux catégories :
- Un outil pour vérifier la qualité du code sur les pull requests afin de détecter la dette technique précocement
- Un outil pour vérifier la qualité du code sur les dépôts
Les équipes les utilisent pour :
- D'un point de vue managérial, vérifier quelles équipes pourraient bénéficier de plus de développeurs seniors, ou pour voir quelles équipes doivent relever leur barre de qualité de code.
- Suivre les constatations individuelles. Par exemple, même si vous avez un dépôt legacy que vous ne touchez pas parce qu'il "fonctionne tout simplement", parcourir les résultats des bugs de logique reste intéressant, pour comprendre s'il pourrait y avoir des effets secondaires inattendus avec un impact caché.
Ces deux cas d'usage ne fonctionnent que si les vérifications sous-jacentes sont précises, et la précision dépend de la rigueur avec laquelle chaque vérification est délimitée. Demander à un LLM d'examiner un dépôt entier en une seule passe rencontre les mêmes difficultés qu'un prompt trop vague à Cursor, avec trop d'informations à traiter pour se concentrer sur quelque chose de spécifique.
C'est pourquoi la fonctionnalité Code Quality d'Aikido lance des appels LLM règle par règle. Cela aide grandement le LLM à se concentrer sur une question spécifique à la fois. De plus, il est possible d'affiner ces règles avec un contexte supplémentaire pour s'assurer que les résultats correspondent au style de code. S'il n'existe pas de règle ciblant une exigence spécifique, des règles personnalisées peuvent également être ajoutées. Cette couche de contrôle contribue à rationaliser l'ensemble du processus au sein de l'équipe.
De plus, cette couche de contrôle s'applique simultanément aux vérifications de PR et à l'analyse des dépôts, afin de garantir que les données statistiques de l'analyse des dépôts s'alignent sur les retours des pull requests.
Prompts benchmarkés pour la qualité du code
Un deuxième avantage de l'utilisation d'un système dédié à la qualité du code est que les LLM reçoivent des prompts affinés et benchmarkés (ce que nous faisons également avec AutoTriage). Le processus est simple. Nous collectons des échantillons de code pour une règle donnée et les étiquetons manuellement, en indiquant s'ils doivent être signalés ou non, avec un score de confiance.
Certaines règles de qualité de code se situent dans une zone grise, rendant incertaine la décision de les signaler ou non. Par exemple, nous avons constaté de grandes différences dans la rigueur avec laquelle les équipes traitaient la règle "pas de duplication évidente". Le style de code d'Aikido lui-même est de ne pas appliquer cette règle très strictement. La lisibilité est souvent préférée à l'avantage de maintenabilité de la déduplication. Les nouvelles recrues voudraient parfois qu'il soit plus 'DRY' et feraient de grands efforts pour ajouter des abstractions afin d'y parvenir. Il n'y a pas de bien ou de mal ici, c'est juste une nuance de gris différente. Dans de tels cas, une étiquette de confiance définit le nombre de personnes que nous nous attendons à voir signaler quelque chose ou non.
Cependant, nous devons prendre une décision binaire (oui/non) lorsque nous signalons quelque chose sur une PR. Alors, comment naviguer dans la zone grise lors de l'application des étiquettes de confiance ? Premièrement, nous visons simplement à ne pas signaler les échantillons de la zone grise – nous sommes plus susceptibles de frustrer les développeurs avec trop de résultats que de les impressionner avec des résultats parfaitement pertinents. Nous l'intégrons également dans notre système d'ingénierie des prompts. Après avoir étiqueté les échantillons, nous ajustons les prompts de manière à maximiser la satisfaction client.
Malheureusement, les LLM ne sont pas parfaits et des erreurs continuent de se produire, nous devons donc choisir nos batailles. Disposer d'échantillons de zone grise nous aide à choisir les bonnes batailles. Lorsque nous prenons la mauvaise décision sur un échantillon de zone grise, elle est moins pénalisée que sur un échantillon évident. Le résultat est que les constatations sont très proches de la vérité, significativement plus proches que ce que l'on obtient avec un prompting "vanilla".
Privilégier la qualité du code à la détection de bugs
Une source intéressante de confusion entre un système de qualité de code et d'autres systèmes de revue de PR est que la plupart des systèmes ont tendance à se concentrer sur la détection de bugs. C'est bien sûr un aspect important, mais il sert un objectif différent. La manière la plus pratique de progresser est d'itérer rapidement sur le style de code, et ces systèmes doivent être rapides. Le système de qualité de code d'Aikido se termine généralement en moins d'une minute après le push du commit, ce qui maintient la boucle de feedback courte. Cela inclut à la fois la qualité du code et les vérifications de sécurité.
Dans un avenir proche, il sera également possible de demander une vérification rigoureuse sur un commit. Cette vérification traquerait alors les bugs de logique et les problèmes d'autorisation de manière plus approfondie. Elle se comporte de manière agentique et est donc plus lente et plus coûteuse, mais constitue une vérification finale idéale sur une PR avant le déploiement.
Conclusion
Un prompt générique à Claude ou Cursor vérifie le code en fonction de ce que le modèle priorise ce jour-là, et non de la culture de codage spécifique d'une codebase. Un système dédié à la qualité du code corrige cela car il exécute les mêmes règles ajustées sur les pull requests et les dépôts complets, ainsi une équipe obtient une réponse cohérente au lieu de deux différentes selon l'endroit où la vérification est exécutée. L'étape suivante approfondit cette réponse : une vérification agentique conçue pour tracer les bugs de logique et les problèmes d'autorisation, suffisamment stable et sûre pour être exécutée juste avant le déploiement au lieu de sur chaque commit.
