FLIN fue construido en 301 sesiones. La auditoría cubrió el código de 93 de esas sesiones en un solo pase analítico. No 93 sesiones de auditoría -- 93 sesiones de desarrollo, revisadas en un esfuerzo concentrado. La distinción importa. Construir una característica en una sesión toma horas de exploración, experimentación, depuración y refinamiento. Auditar el resultado de esa sesión toma minutos, porque no estás construyendo -- estás verificando. La fricción creativa desaparece. Lo que queda es lectura sistemática.
Pero la lectura sistemática de código que fue escrito a lo largo de 93 sesiones, por un CTO de IA cuyo contexto se reinicia entre conversaciones, presenta sus propios desafíos. Cada sesión tenía sus propios objetivos, sus propias restricciones, y su propia comprensión del código base. Los cambios hechos en la Sesión 200 podrían contradecir suposiciones de la Sesión 50. Una función agregada en la Sesión 130 podría ser reemplazada por un enfoque diferente en la Sesión 180 pero nunca eliminada. La auditoría no fue solo una revisión de código -- fue una expedición arqueológica a través de 42 días de construcción incremental.
El modelo de cobertura de la auditoría
La cobertura tenía tres niveles:
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)
Tier 3: Spot checking (92 files, 69,800 lines)Los archivos del Nivel 1 se leyeron línea por línea porque tenían la mayor densidad de defectos y el mayor impacto. Los archivos del Nivel 2 se revisaron a nivel de función. Los archivos del Nivel 3 se verificaron por muestreo en busca de patrones comunes: comentarios TODO, llamadas panic, código muerto y anti-patrones de seguridad.
Lo que reveló la arqueología de sesiones
Los hallazgos más interesantes de la auditoría no fueron errores -- fueron patrones en cómo el código base evolucionó a lo largo de las sesiones.
Acreción de características. El vocabulario de tokens creció de aproximadamente 30 tokens en las primeras sesiones a más de 80 en la Sesión 252.
Capas defensivas. Las sesiones posteriores tendían a agregar verificaciones defensivas alrededor del código de sesiones anteriores en lugar de refactorizarlo.
Deriva de especificaciones. Algunas características evolucionaron alejándose de su especificación original a medida que la realidad de implementación se imponía.
El valor de la completitud
Leer cada línea de un código base de 186.252 líneas es una inversión. Pero el retorno de esa inversión fue desproporcionado al esfuerzo.
Antes de la auditoría, sabíamos que FLIN funcionaba para los casos que habíamos probado. Después de la auditoría, sabíamos cada caso donde no funcionaba. Antes de la auditoría, los errores se descubrían a través de reportes de usuarios y sesiones de depuración -- reactivo, costoso, impredecible. Después de la auditoría, cada defecto conocido estaba catalogado con su ubicación exacta y una corrección propuesta -- proactivo, sistemático, programable.
Las 93 sesiones auditadas en un pase representaban el trabajo acumulado de 42 días. La auditoría destiló ese trabajo en una imagen única y coherente: lo que es FLIN, dónde es fuerte, dónde es débil, y exactamente qué necesita suceder para que esté listo para el mundo.
Esta es la Parte 155 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [154] Llamadas panic en producción: rastreo y eliminación - [155] 93 sesiones auditadas en un solo pase (estás aquí) - Siguiente arco: el camino de FLIN hacia Beta