Mesurer le laisser-aller du code : métriques de verbosité et d'érosion

Les LLM sont devenus très performants pour générer du code qui passe les tests. Mais un code correct peut quand même être bâclé : plein de lignes dupliquées, d'abstractions inutiles et de mauvais choix de conception. Comme le note l'auteur, « le fait qu'un code soit formellement correct ne signifie pas qu'il n'introduit pas d'abstractions inutiles, qu'il ne crée pas de doublons ou qu'il ne prend pas de mauvaises décisions dans l'ensemble ». Le résultat est une explosion du nombre de lignes de code (LOC) difficile à suivre pour les humains, et – contrairement à certaines affirmations – les agents ne peuvent pas non plus gérer ce laisser-aller.

Pourquoi le LLM-juge ne fonctionne pas

L'article rejette l'approche courante dans l'industrie consistant à utiliser l'IA pour juger la qualité du code. Demander à un modèle de noter le code de 1 à 10 équivaut « pratiquement à un générateur de nombres aléatoires ». Les comparaisons par paires (A vs B) sont instables : il suffit de renommer les solutions pour inverser la préférence du modèle. Les grilles d'évaluation et les tests écrits par LLM aident, mais « sont encore loin d'éliminer réellement le laisser-aller ».

La métrique la plus simple : la variation du nombre de lignes de code

Étonnamment efficace : il suffit de suivre la variation du nombre de lignes de code. L'auteur note l'ironie : « si nous commencions à optimiser pour cela, cela cesserait d'être une mesure pertinente ».

VerbosIté

Mesure les lignes dupliquées et inutilement verbeuses. C'est la fraction de lignes signalées par AST-Grep ou marquées comme clones, divisée par le nombre total de lignes de code :

VerbosIté = |lignes signalées par AST-Grep ∪ lignes clonées| / LOC

Érosion

Mesure dans quelle mesure la masse d'une base de code est concentrée dans quelques grandes fonctions complexes. Définissons d'abord la masse d'une fonction :

masse(f) = CC(f) * sqrt(SLOC(f))

Où CC(f) est la complexité cyclomatique et SLOC(f) le nombre de lignes de code source. L'érosion est alors la fraction de la masse totale détenue par les fonctions dont la complexité cyclomatique est supérieure à 10 :

Érosion = ∑_{f: CC(f) > 10} masse(f) / ∑_f masse(f)

Ces deux mesures – introduites par l'article SlopCodeBench – ont plutôt bien séparé les bases de code héritées du laisser-aller généré par les LLM dans les tests de l'auteur.

À retenir

• Les juges LLM ne sont pas fiables pour la qualité du code ; la préférence s'inverse lors du renommage.
• La variation du nombre de lignes de code est un signal de laisser-aller étonnamment fort, mais s'effondre si on l'optimise directement.
• La verbosité combine les signalements AST-Grep et la détection de clones sur le nombre de lignes de code.
• L'érosion capture la masse de complexité dans les fonctions avec CC > 10.

Pour les équipes qui livrent du code généré par LLM à grande échelle, ces métriques offrent une alternative quantitative à l'évaluation au feeling.