Aller au contenu

LLM : code plausible != code correct — reimplementation SQLite 20000x plus lente

Resume

L'article demontre que les LLM generent du code plausible (syntaxiquement correct, structures reconnaissables) mais pas necessairement correct (semantiquement juste). Cas d'etude : une reimplementation de SQLite en Rust generee par IA produit des requetes 20 000x plus lentes que l'original. Le planificateur de requetes ne reconnait pas les colonnes INTEGER PRIMARY KEY et force des full scans au lieu de recherches binaires. Le LLM a produit un planificateur qui "ressemble" a un planificateur mais qui ne fonctionne pas.

Analyse critique

Ce qui est juste :

L'exemple est devastateur. Un facteur 20 000x n'est pas une degradation marginale — c'est un changement de classe de complexite (O(n) vs O(log n) sur chaque requete). Le LLM a genere du code qui compile, qui passe les tests de structure, mais qui manque une optimisation fondamentale du domaine.

C'est le meme mecanisme que le papier Apple GSM-Symbolic (fiche du jour) : le LLM optimise la vraisemblance syntaxique (le code "ressemble" a du bon code) plutot que la justesse semantique (le code "fait" la bonne chose). Pattern matching sur la forme, pas comprehension du fond.

La conclusion de l'auteur est operationnelle : definir des criteres d'acceptation mesurables AVANT la generation, pas apres. C'est exactement le workflow ProbatioVault : specs + tests (steps 1-2) avant implementation (step 6).

Ce qui manque :

L'article ne mentionne pas quels LLM ont ete utilises ni les prompts. La reproductibilite est faible. Sur des taches plus petites (un module, pas un SGBD complet), les LLM performent mieux. Le cas SQLite est un worst case volontaire.

Pertinence ProbatioVault

Impact modere — renforce nos choix existants :

  1. Specs avant code : notre workflow impose spec + tests + plan AVANT implementation. L'article confirme que c'est indispensable — sans criteres d'acceptation pre-definis, le code LLM "a l'air correct" mais ne l'est pas.

  2. Verification TypeScript incrementale (procedure step 6b) : apres chaque agent, npx tsc --noEmit detecte les erreurs de type mais pas les erreurs de logique. Ce cas montre qu'il faut aussi des tests fonctionnels a chaque agent — renforce le TODO #12 (TDD + archi hexagonale).

  3. Gates PMO : les gates verifient la conformite aux specs, pas la performance. Un code 20 000x plus lent passerait nos gates actuelles si les specs ne mentionnent pas de contraintes de performance. A ajouter dans les criteres d'acceptation : seuils de performance pour les modules critiques (crypto, recherche, archivage).

  4. Complement Apple GSM-Symbolic : meme mecanisme (pattern matching vs raisonnement), domaine different (code vs maths). Ensemble, ces deux papiers forment un argument solide contre la confiance aveugle dans les outputs LLM.