Génération de code déterministe vs probabiliste : pourquoi la conversion en Rust de Bun via Vibe-Coding soulève des drapeaux rouges

Noah Hall, écrivant pour The Tech Enabler, trace une ligne claire entre la génération de code déterministe et probabiliste. Il utilise la récente conversion vibe-codée d'un million de lignes de code de Zig vers Rust par Bun comme exemple édifiant. Son argument central : les systèmes déterministes produisent des résultats cohérents et vérifiables ; les LLM introduisent une incertitude qui rend la relecture de code impossible à grande échelle.

Génération de code déterministe

Hall cite des outils déterministes établis : le 2to3 de Python pour la migration Python 2→3, et les transpileurs pour des langages comme Elm, PureScript et TypeScript qui produisent toujours le même JavaScript. Son propre langage Derw peut produire du JavaScript, TypeScript ou anglais ; Tegan produit du JavaScript ou Go ; Mojie cible JavaScript, Python ou anglais. Tous reposent sur une transformation AST vers AST — avec la même entrée, on obtient toujours la même sortie. La cohérence compte : « Si un bug est cohérent, on peut le corriger. S'il est incohérent, le corriger devient exponentiellement plus difficile. »

Génération de code probabiliste

Les LLM varient leur sortie à chaque exécution — parfois A, parfois B. Hall a créé neuro-lingo il y a trois ans comme parodie : les humains écrivent uniquement les signatures de fonction et les commentaires, et les LLM génèrent l'implémentation à neuf à chaque compilation. Exemple :

function add(a: number, b: number): number {
  // Additionne deux nombres
}
function main() {
  // Affiche "Hello World" dans la console
  // Affiche le résultat de add(2, 3)
}

« À chaque compilation de neuro-lingo, le code est généré à neuf par les LLM. Il est légèrement différent à chaque fois. Parfois il introduit des bugs. Parfois il est propre et simple. Parfois chaotique. » Hall soutient que les flux de code entièrement pilotés par l'IA font exactement cela, mais livrent en production avec une responsabilité humaine.

Le sophisme « il y a des tests »

Les tests seuls ne peuvent garantir la qualité. Hall cite SQLite comme la base de code la plus testée : 155,8 KSLOC de code C contre 92 053,1 KSLOC de code de test (590× plus). Malgré une couverture de branche à 100 %, des millions de cas de test et des harnais complets, SQLite repose toujours sur une relecture humaine. « Il est impossible pour un humain de relire 1 million de lignes de modifications en 9 jours. Bun n'a pas relu le code qu'ils ont fusionné dans la branche principale. »

Hall conclut que la génération de code déterministe a toujours besoin de validation, et que la génération probabiliste crée un risque qui croît avec le nombre de lignes. L'article source approfondit chaque exemple.