Bend 2 impose une preuve de 442 lignes pour un jeu simple

Présentation de Bend 2

Bend 2 se positionne comme un langage destiné à l’ère du codage assisté par IA : les développeurs rédigent des lois, l’IA génère l’implémentation et le compilateur vérifie la validité des preuves. Le démonstrateur officiel comporte 58 lignes de LAWS.bend qui décrivent l’interdiction de toucher le drapeau, puis 442 lignes de PROOF.bend qui attestent ces propriétés. Le projet est hébergé sur GitHub et se veut un exemple de collaboration humain‑IA pour la vérification formelle.

Analyse du piège du vibe‑coding

Le terme "vibe‑coding" désigne la tendance à développer une solution complète avant d’identifier les travaux existants dans le domaine concerné. Dans le cas de Bend 2, aucune référence à la vérification formelle n’apparaît sur le site ou dans le code, alors que le problème traité relève précisément de ce champ. Le développeur a ainsi créé un langage et un compilateur sans exploiter les outils déjà disponibles, ce qui a conduit à une surcharge de spécifications et de preuves.

Comparaison avec SPARK et la vérification formelle standard

En reproduisant le même scénario dans le langage SPARK, qui intègre nativement la vérification, le même jeu est décrit avec moins de 200 lignes de code et aucune preuve séparée. Le fragment suivant illustre la définition du type d’état et l’invariant de sécurité :

type State is record
   X    : Column;
   Y    : Row;
   Won  : Boolean;
end record;

function Safe (G : State) return Boolean is
   ((G.X > 2 or G.Y > 2) and not Wall(G.X, G.Y) and not G.Won)
   with Ghost;

Après compilation avec gnatprove, le rapport indique « Success: all checks proved » pour les 12 vérifications générées, sans qu’il soit nécessaire d’écrire un fichier de preuve de plusieurs centaines de lignes. Cette différence montre que l’approche SPARK élimine plus de 99 % du travail de preuve requis par Bend 2.

Implications pour la conception de nouveaux langages

Le cas Bend 2 souligne le risque de concevoir des systèmes qui reproduisent des fonctions déjà couvertes par des cadres établis. L’absence de recherche préalable a conduit à une solution qui consomme davantage de ressources de calcul et de tokens LLM. Pour les concepteurs, la leçon est de cartographier les domaines connexes – ici la vérification formelle – avant d’investir dans une architecture propriétaire. Une intégration directe d’outils comme SPARK ou Coq aurait permis de réduire le volume de code, d’améliorer la robustesse des garanties et de limiter la dette technique.