Un développeur a créé un outil d'entraînement à la lecture de code — et s'est heurté au non-déterminisme du LLM

Un développeur de Habr a lancé un projet inhabituel : un entraîneur où vous ne codez pas, mais lisez un fragment de code fonctionnel et l'expliquez avec vos propres mots — et un modèle de langage évalue la qualité de votre explication. L'idée est simple, mais l'implémentation s'est avérée être étonnamment complexe.

D'où vient l'idée

Deux frustrations se sont accumulées progressivement. La première était mon propre code d'il y a deux mois : en principe, tout est clair, mais il faut plus de temps que souhaité pour le relire. La deuxième était mes tentatives d'expliquer l'architecture du projet à des amis : tu sais tout parfaitement, mais tu parles par fragments, tu hésites sur les mots, tu ne peux pas connecter tes pensées en un tout cohérent. L'entraîneur est né de ces deux problèmes.

La mécanique est simple : on vous montre un vrai fragment de code fonctionnel, vous l'expliquez avec vos propres mots — oralement ou par écrit — et vous recevez une évaluation d'un LLM. Aucune écriture de code, juste de la lecture et de l'explication. Quelque chose entre une revue de code et une conversation avec un mentor.

L'idée en elle-même n'est pas nouvelle — expliquer le code à haute voix est utilisé dans la programmation en paire et aux entretiens techniques. Mais une version automatisée, toujours disponible, est déjà intéressante.

Où ça s'est cassé : non-déterminisme du LLM

Écrire l'entraîneur lui-même s'est avéré être simple. Les difficultés ont commencé lors de la configuration de l'évaluation. La tâche semble triviale : donner au modèle deux textes — le code et l'explication de l'utilisateur — et lui demander d'évaluer à quel point l'un décrit bien l'autre. En pratique, le modèle s'est comporté de manière imprévisible :

• Pour la même explication, il donnait des scores différents lors de requêtes répétées
• Il valorisait injustement certains aspects du code, en ignorait d'autres sans raison
• La « rigueur » de l'évaluateur changeait d'une requête à l'autre sans motifs visibles
• C'était impossible à dire ce qui compte comme une bonne explication — exhaustive ou concise ?

C'est le non-déterminisme classique du LLM — une propriété que tout le monde connaît théoriquement, mais que vous ressentez vivement précisément quand vous avez besoin d'une fonction d'évaluation reproductible du modèle, et non de la génération de texte.

Qu'évaluer exactement

Le développeur a découvert que le problème principal n'est pas technique, mais conceptuel : qu'est-ce qui compte comme une bonne explication de code ? Doit-elle être exhaustive — couvrir toutes les branches, les cas limites, les effets secondaires ? Ou suffit-il de transmettre avec précision l'idée principale de l'algorithme ? Faut-il mentionner les bugs potentiels ? La terminologie est-elle importante ? La personne qui explique doit-elle démontrer qu'elle comprend pourquoi ce code a été écrit, pas seulement ce qu'il fait ?

Sans réponses claires, n'importe quel critère d'évaluation pour un LLM devient vague — et le modèle remplit l'incertitude arbitrairement. C'est précisément pourquoi l'ingénierie des prompts pour les tâches d'évaluation est significativement plus complexe que pour les tâches génératives.

Approches techniques possibles : prompts stricts avec des rubriques spécifiques, vote sur plusieurs requêtes indépendantes au modèle, explications de référence comme point de repère. Mais d'abord, vous devez déterminer exactement ce que vous mesurez.

"La partie la plus difficile s'est avérée être non pas d'écrire

l'entraîneur, mais de faire évaluer le réseau de neurones honnêtement et de manière cohérente — et de comprendre exactement ce qui doit être évalué"

Ce que cela signifie

L'histoire illustre un piège typique des projets LLM : la partie qui semble la plus simple — « le modèle va évaluer » — requiert en réalité bien plus d'effort d'ingénierie que tout le reste du produit. La tâche de former la compétence de lire et d'expliquer du code est un besoin réel, en particulier dans les équipes ayant beaucoup de code hérité. Mais construire un évaluateur automatisé fiable pour de telles compétences pratiques reste un défi d'ingénierie ouvert.