FLIN a été construit en 301 sessions. L'audit a couvert le code de 93 de ces sessions en un seul passage analytique. Pas 93 sessions d'audit -- 93 sessions de développement, revues en un effort concentré. La distinction compte. Construire une fonctionnalité dans une session prend des heures d'exploration, d'expérimentation, de débogage et d'affinage. Auditer le résultat de cette session prend des minutes, parce qu'on ne construit pas -- on vérifie. La friction créative a disparu. Ce qui reste est une lecture systématique.
Mais la lecture systématique de code écrit au fil de 93 sessions, par un CTO IA dont le contexte se réinitialise entre les conversations, présente ses propres défis. Chaque session avait ses propres objectifs, ses propres contraintes et sa propre compréhension du codebase. Les changements faits à la Session 200 pourraient contredire les hypothèses de la Session 50. Une fonction ajoutée à la Session 130 pourrait être supplantée par une approche différente à la Session 180 mais jamais supprimée. L'audit n'était pas juste une revue de code -- c'était une expédition archéologique à travers 42 jours de construction incrémentale.
La piste des sessions
Chaque session a laissé des traces dans le code. Les annotations de commentaires indiquaient quelle session avait introduit quelle fonctionnalité. L'audit a utilisé ces annotations pour reconstruire la chronologie du développement et vérifier que les sessions ultérieures ne cassaient pas les invariants antérieurs.
rust// Traces from FLIN's session history, found during the audit:
// Session 103: Modules (Import, From, As, Export)
// token.rs lines 325-334
Import, From, As, Export,
// Session 112: String interpolation
// scanner.rs lines 1038-1119
// Session 115: Switch, Watch, Context, Impl
// token.rs lines 157-159, 299-301, 315-316
// Session 118: Lazy, Hash, Fragment <>
// token.rs lines 305-306, 828-830
// Session 119: DocComment token
// token.rs lines 924-925, scanner.rs lines 676-706
// Session 133: Trait keyword
// token.rs lines 317-318
// Session 147: Static, Generic type handling
// token.rs lines 319-320, scanner.rs lines 576-582
// Session 150: Pipeline operator |>
// token.rs lines 807-808, scanner.rs lines 632-634
// Session 155: Loop labels
// token.rs lines 909-911, scanner.rs lines 656-658
// Session 195: WebSocket keywords
// token.rs lines 173-184, 386-390, 517-522
// Session 240: About keyword for RAG
// token.rs lines 201-202
// Session 252: URL pass-through (HTML compliance)
// scanner.rs lines 4056-4246Le modèle de couverture de l'audit
Le modèle de couverture avait trois niveaux :
Tier 1: Line-by-line reading (5 files, 66,889 lines)
vm/vm.rs 27,257 lines -- Every line, every opcode
parser/parser.rs 16,544 lines -- Every parse function
database/zerocore.rs 15,098 lines -- Every database operation
codegen/emitter.rs 8,837 lines -- Every emit function
vm/renderer.rs 7,540 lines -- Every render path
Tier 2: Function-level review (8 files, 49,563 lines)
parser/ast.rs 5,162 lines -- Type definitions
typechecker/checker.rs 7,715 lines -- Type checking logic
server/http.rs 3,870 lines -- HTTP routing
server/websocket.rs 3,200 lines -- WebSocket handling
lexer/scanner.rs 4,248 lines -- Token scanning
lexer/token.rs 1,606 lines -- Token definitions
database/storage.rs 5,800 lines -- Storage backends
vm/builtins/* 15,967 lines -- Built-in functions
Tier 3: Spot checking (92 files, 69,800 lines)
Remaining modules, tests, configurationLes fichiers du niveau 1 étaient lus ligne par ligne car ils avaient la plus haute densité de défauts et le plus fort impact. Les fichiers du niveau 2 étaient revus au niveau des fonctions. Les fichiers du niveau 3 étaient vérifiés ponctuellement pour les patterns courants : commentaires TODO, appels panic, code mort et anti-patterns de sécurité.
Ce que l'archéologie des sessions a révélé
Les découvertes d'audit les plus intéressantes n'étaient pas des bugs -- c'étaient des patterns dans la façon dont le codebase a évolué au fil des sessions.
Accrétion de fonctionnalités. Le vocabulaire de tokens est passé d'environ 30 tokens dans les premières sessions à 80+ à la Session 252. Chaque session qui ajoutait une fonctionnalité du langage ajoutait aussi des tokens, des mots-clés et des nœuds AST.
Couches défensives. Les sessions tardives avaient tendance à ajouter des vérifications défensives autour du code des sessions antérieures plutôt que de le refactoriser. C'est naturel -- réécrire le code d'une session précédente risque de casser les fonctionnalités qui dépendent de son comportement actuel. Mais cela produit un codebase avec des couches de validation redondantes.
Dérive de spécification. Certaines fonctionnalités ont évolué loin de leur spécification originale au fur et à mesure que la réalité de l'implémentation s'imposait. L'audit a trouvé plusieurs cas où le comportement du code différait de la description d'intention des journaux de session.
La valeur de l'exhaustivité
Lire chaque ligne d'un codebase de 186 252 lignes est un investissement. Mais le retour sur cet investissement était disproportionné par rapport à l'effort.
Avant l'audit, nous savions que FLIN fonctionnait pour les cas que nous avions testés. Après l'audit, nous connaissions chaque cas où il ne fonctionnait pas. Avant l'audit, les bugs étaient découverts par des rapports d'utilisateurs et des sessions de débogage -- réactifs, coûteux, imprévisibles. Après l'audit, chaque défaut connu était catalogué avec son emplacement exact et une correction proposée -- proactif, systématique, planifiable.
Les 93 sessions auditées en un seul passage représentaient le travail accumulé de 42 jours. L'audit a distillé ce travail en une image unique et cohérente : ce que FLIN est, où il est fort, où il est faible, et exactement ce qui doit se passer pour le rendre prêt pour le monde.
Ceci est la partie 155 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [154] Appels panic en production : suivi et élimination - [155] 93 sessions auditées en un seul passage (vous êtes ici) - Arc suivant : le chemin de FLIN vers la bêta