Il est étonnant de constater à quel point les non-développeurs ont récemment acquis les moyens de créer leurs propres applications, capables même de générer des revenus. Nous avons récemment assisté à des progrès dans le domaine du développement de l’IA, celle-ci passant avec succès du « code greenfield » (applications construites à partir de zéro) au « code brownfield » (applications existantes à plus grande échelle). Les modèles les plus récents maîtrisent désormais bien mieux l’utilisation des outils et ont connu un succès retentissant dans la mise en œuvre de fonctionnalités au sein d’applications plus complexes, au point que les développeurs n’ont pratiquement plus besoin de vérifier le code. Ils consacrent davantage leur temps à définir les exigences et à effectuer des tests fonctionnels, ce qui leur permet d’accélérer le rythme des livraisons.
Dans le même temps, développer de nouvelles fonctionnalités à un rythme aussi soutenu risque d'alourdir la dette technique au point qu'il devienne pratiquement impossible de continuer à avancer. Sans supervision, les équipes peuvent se retrouver avec des montagnes de « code spaghetti » ; il convient donc de privilégier les normes de qualité du code avant que le problème ne devienne incontrôlable.
Maintenir des normes élevées en matière de qualité du code est plus facile à dire qu’à faire. La relecture humaine ne suffit pas, et demander à Claude ou à Cursor de relire votre code revient à demander à quelqu’un de relire une thèse sans connaître le contexte de la discipline ni les normes à respecter.
Que font les équipes lorsque le code d'IA s'accumule ?
Le coût lié au fait de ne pas effectuer de révisions, en particulier sur les modifications architecturales, se fait sentir plus tard, généralement au bout de quelques mois. Les modifications générées par l’IA s’ajoutent les unes aux autres, et chaque couche part du principe que celle qui la précède est correcte. Or, lorsque ce n’est pas le cas, le modèle repose sur des bases fragiles, tout comme les développeurs qui lui fournissent des instructions. Des bugs apparaissent dans des endroits inattendus et même les plus petites modifications commencent à produire des effets secondaires qui prennent du temps à corriger.
À un moment donné, le rythme soutenu du premier mois commence à s'inverser. L'équipe avance plus lentement, car chaque PR subit PR le poids de tout ce qui l'a précédée.
Du coup, lorsque les équipes tentent de procéder à un nettoyage, cela représente une tâche colossale. Certaines entreprises vont même jusqu’à faire appel à des spécialistes du nettoyage de code « vibe » pour résoudre ce problème. Vous pouvez d’ores et déjà trouver des personnes occupant ce poste sur LinkedIn.
Il semble contradictoire de tirer parti de l'IA tout en ayant ensuite besoin de davantage de personnes pour résoudre les problèmes que cette même IA a rendus possibles. Les équipes devraient donc prendre des mesures pour vérifier le code dès le début et de manière efficace.
Comment limiter la dette technique
Les meilleures solutions trouvées à ce jour pour réduire la dette technique relèvent généralement de l'une des deux catégories suivantes :
- Un outil permettant de vérifier la qualité du code dans les demandes de fusion afin de détecter rapidement la dette technique
- Un outil permettant de vérifier la qualité du code dans les dépôts
Les équipes les utilisent pour :
- D'un point de vue managérial, il convient de déterminer quelles équipes auraient besoin de développeurs plus expérimentés, ou de voir quelles équipes doivent relever le niveau de qualité de leur code.
- Suivez les résultats au cas par cas. Par exemple, même si vous disposez d’un dépôt hérité que vous ne modifiez pas parce qu’il « fonctionne tout simplement », il reste intéressant de parcourir les résultats relatifs aux bogues logiques afin de déterminer s’il pourrait y avoir des effets secondaires inattendus ayant des répercussions cachées.
Ces deux cas d'utilisation ne fonctionnent que si les vérifications sous-jacentes sont précises, et cette précision dépend du degré de précision avec lequel chaque vérification est définie. Demander à un LLM d'analyser l'intégralité d'un dépôt en une seule fois pose le même problème qu'une instruction trop vague donnée à Cursor : il y a trop d'informations à traiter pour qu'il puisse se concentrer sur un élément spécifique.
C’est pourquoi la fonctionnalité « Quality Code »Aikido lance des requêtes LLM règle par règle. Cela aide considérablement le LLM à se concentrer sur une question spécifique à la fois. De plus, il est possible d’affiner ces règles en y ajoutant du contexte afin de 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 permet de rationaliser l’ensemble du processus au sein de l’équipe.
De plus, cette couche de contrôle s'applique à la fois PR et à l'analyse des dépôts, afin de garantir que les chiffres statistiques relatifs à l'analyse des dépôts correspondent aux retours sur les pull requests.
Critères de référence pour la qualité du code
Un deuxième avantage lié à l'utilisation d'un système dédié à la qualité du code réside dans le fait que les modèles de langage de grande envergure (LLM) reçoivent des invites optimisées qui ont fait l'objet de tests comparatifs (ce que nous faisons également avec AutoTriage). Le processus est simple : nous collectons des échantillons de code correspondant à une règle donnée, puis nous indiquons manuellement s'ils doivent être signalés ou non, en leur attribuant un score de confiance.
Certaines règles de qualité du code se situent dans une zone grise, ce qui rend difficile de déterminer s’il faut ou non les signaler. Par exemple, nous avons constaté de grandes différences dans la manière dont les équipes appliquaient la règle « pas de duplication évidente ». Le style de code propre Aikidoconsiste à ne pas appliquer cette règle de manière très stricte. La lisibilité est souvent privilégiée par rapport à l’avantage en termes de maintenabilité qu’apporte la déduplication. Les nouvelles recrues souhaitent parfois respecter davantagele principe « DRY »et n’hésitent pas à aller très loin pour ajouter des abstractions afin d’y parvenir. Il n’y a pas de bonne ou de mauvaise réponse ici, il s’agit simplement d’une nuance de gris différente. Dans de tels cas, un indicateur de confiance permet de définir le nombre de personnes dont nous nous attendons à ce qu’elles signalent ou non un élément.
Cependant, nous devons prendre une décision tranchée lorsque nous signalons quelque chose dans une PR. Comment alors gérer la zone grise lors de l’attribution des étiquettes de confiance ? Tout d’abord, nous cherchons simplement à ne pas signaler les échantillons situés dans cette zone grise : nous risquons davantage de frustrer les développeurs avec un trop grand nombre de résultats qu’avec des résultats parfaitement ciblés. Nous intégrons également cette approche 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 bien choisir nos priorités. Disposer d’exemples relevant de la « zone grise » nous aide à faire ce choix. Lorsque nous prenons une mauvaise décision concernant un exemple de la « zone grise », la pénalité est moins importante que si nous prenions une mauvaise décision sur un exemple évident. Il en résulte des conclusions assez proches de la vérité, nettement plus proches que celles obtenues avec des prompts classiques.
Privilégier la qualité du code plutôt que la recherche de bogues
Une source de confusion intéressante entre un système de qualité du code et d’autres systèmes PR réside dans le fait que la plupart des systèmes ont tendance à se concentrer sur la recherche de bogues. C’est bien sûr un aspect important, mais il répond à un objectif différent. Le moyen le plus efficace de progresser consiste à itérer rapidement sur le style du code, et ces systèmes doivent donc fonctionner rapidement. Le système de qualité du code Aikidos’exécute généralement en moins d’une minute après la publication du commit, ce qui permet de maintenir une boucle de rétroaction courte. Cela inclut à la fois les contrôles de qualité du code et les contrôles de sécurité.
Dans un avenir proche, il sera également possible de demander une vérification approfondie d’un commit. Cette vérification permettrait alors de détecter de manière plus approfondie les bogues logiques et les problèmes d’autorisation. Elle fonctionne de manière autonome et est donc plus lente et plus coûteuse, mais constitue une vérification finale idéale d’une PR son déploiement.
Conclusion
Une requête générique adressée à Claude ou à Cursor vérifie le code par rapport à ce que le modèle décide de privilégier ce jour-là, et non par rapport à la culture de codage spécifique d’une base de code. Un système dédié à la qualité du code résout ce problème, car il applique les mêmes règles optimisées aux pull requests et aux dépôts complets ; ainsi, une équipe obtient une réponse cohérente au lieu de deux réponses différentes selon l’endroit où la vérification est effectuée. L’étape suivante permet d’approfondir cette réponse : une vérification « agentique » conçue pour détecter les bogues logiques et les problèmes d’autorisation, suffisamment stable et sûre pour être exécutée juste avant le déploiement plutôt qu’à chaque commit.
