Viva : 91 soumissions C notées au maximum sur 626 cachent un défaut que l'autograder n'a jamais testé
Une suite de tests qui passe prouve qu'un programme a fonctionné sur les entrées que l'enseignant a pris la peine de vérifier. Elle ne prouve pas que l'étudiant peut expliquer ce que le programme fait. Viva comble cet écart : GPT-5.6 lit l'énoncé et propose une entrée que la suite n'a jamais essayée, Viva exécute le programme de l'étudiant et le corrigé dessus, et ne pose une question à l'étudiant que si les deux ne s'accordent pas. Sur 626 vraies soumissions C notées au maximum, 91 (14,5 %) cachent un défaut que l'autograder n'a jamais testé, et 83 d'entre elles (13,3 %) échouent sur une entrée aussi simple que `5 5 3`. Pas une prédiction, un rejeu : chaque constat porte une commande rejouable.
Une suite de tests qui passe prouve qu'un programme a fonctionné sur les entrées que l'enseignant a pris la peine de vérifier. Elle ne prouve pas que l'étudiant comprend ce que le programme fait. Viva comble cet écart. GPT-5.6 lit l'énoncé et propose une entrée que la suite n'a jamais essayée, Viva exécute le programme de l'étudiant et le corrigé de l'enseignant dessus, et ne pose une question à l'étudiant que si les deux programmes ne s'accordent pas. L'enseignant reçoit une note de re-enseignement, jamais une accusation de tricherie.
L'exemple concret
L'énoncé demande d'imprimer le maximum de trois entiers. Les trois tests de l'enseignant sont `1 2 3`, `6 2 1`, `-1 3 1`. Aucun n'a d'égalité, donc rien n'attrape jamais l'égalité. On donne au programme de l'étudiant l'entrée `5 5 3` et il imprime `3` : les deux branches strictes `>` sont fausses quand a et b sont égaux, donc le else imprime la troisième valeur. L'étudiant a passé chaque test et obtenu la note maximale ; il n'a jamais appris que les égalités cassent le motif.
Pourquoi une session de chat ne peut pas faire ça
On colle le code dans un chatbot et il devinera si le code est faux, et hallucinera parfois un bug qui n'existe pas. Viva ne devine jamais. GPT-5.6 décide uniquement de ce qu'il faut tester ; l'exécution décide si cette soumission-là échoue. Un constat, ce sont deux programmes qui impriment des choses différentes sur la même entrée, avec les deux sorties affichées. Ce partage, c'est tout le design.
- GPT-5.6 (découverte, Responses API, effort élevé) : lit la spec de l'énoncé et le corrigé et propose des entrées de bord qu'un débutant se tromperait plausiblement (égalités, zéro, négatifs, éléments uniques, bornes). C'est la partie qui généralise à tout exercice et qu'un vérificateur codé en dur ne peut pas faire.
- Exécution (vérification) : compile le programme étudiant et le corrigé dans un runner C sur WSL, exécute les deux sur chaque entrée proposée, et ne garde que les divergences qui se reproduisent. Une différence cosmétique de format float (5.0 contre 5.000000) est détectée et exclue ; seules comptent les divergences qui changent la réponse.
- GPT-5.6 (défense, effort moyen) : note l'explication tapée de l'étudiant contre ce seul fait exécuté, et pousse si l'étudiant récite la sortie au lieu de tracer le code. Ne parle jamais de tricherie.
L'enseignant reçoit une note de re-enseignement, pas une accusation de tricherie
La vue enseignant organise les 91 constats par idée fausse : égalités, décalage aux bornes, traitement des négatifs, et quelques autres. Chaque idée fausse porte le nombre d'étudiants touchés et un probe canonique. C'est un signal de re-enseignement (la classe a systématiquement manqué le cas d'égalité), pas une accusation par étudiant.
Le flux de défense étudiant
L'étudiant reçoit une seule question sur son propre programme : sur le probe qui a montré la divergence, que fait le code et pourquoi imprime-t-il ça ? GPT-5.6 note la réponse contre ce seul fait exécuté, contraint à l'identifiant de preuve du probe. Si l'étudiant récite la sortie, le correcteur relance en lui demandant de tracer la branche qui s'est exécutée.
La réponse du correcteur est validée pour l'identifiant de preuve attendu avant d'atteindre l'interface. Si le modèle essaie de citer un probe qu'on ne lui a pas montré, ou invente une nouvelle entrée, la réponse est rejetée et régénérée. Il ne peut pas fabriquer un nouveau fait sur le code de l'étudiant, seulement raisonner sur le seul fait exécuté, donc la relance est toujours ancrée dans la même divergence que l'enseignant a vue.
Bâti dans Codex, de bout en bout
Viva a été bâti dans Codex avec GPT-5.6 (gpt-5.6-sol, gpt-5.6 en est un alias). GPT-5.6 est le moteur à deux endroits : l'étape de découverte (src/prober/generator.ts, Responses API, effort élevé) et le correcteur de défense (src/viva/grader.ts, effort moyen), qui est contraint au seul probe exécuté et validé pour l'identifiant de preuve attendu avant que sa réponse n'atteigne l'interface. Codex a accéléré le runner C WSL, le harnais d'exécution par lots, le schéma de preuve, le catégoriseur de divergences, le benchmark, et les flux enseignant et étudiant déployés.
Limites honnêtes
- Le benchmark hors ligne couvre trois exercices d'entiers où chaque entrée proposée est dans le domaine et chaque étiquette de concept est correcte. Ce n'est pas un taux de défauts pour tout le corpus. La découverte par GPT-5.6 étend la couverture aux exercices que le fallback curé saute délibérément (diviseur, moyenne, somme de chiffres, conversion de temps, chaînes).
- Le brief enseignant est une démo produit générée à partir de résultats de corpus publics et anonymisés. La production a besoin d'une intégration LMS, d'une revue d'accessibilité, du consentement, et d'une étude prospective avec des éducateurs et des étudiants.
- Viva rapporte une compréhension démontrée. Ce n'est pas un détecteur de tricherie et il ne fait jamais de revendication de paternité.
Viva: An Automated Oral Exam for Code. On 626 Full-Mark C Submissions, 91 (14.5%) Hid a Defect the Autograder Never Checked.
Voir le projet