Bitácora

En un roguelike personal decidí no escribir sus ~100 pisos a mano. Un servicio de dominio los genera desde una seed determinista: ensambla piezas de datos y la dificultad sube por curvas en JSON, no por código. El guiño es técnico — una seed reproduce la corrida exacta, la misma reproducibilidad que uso para volver a montar un incidente en producción o hacer replay de una transacción.

El aprendizaje: el rigor que hace predecible una plataforma crítica —determinismo, comportamiento dirigido por datos y decisiones registradas como ADR— no cambia con el dominio. Aplicado a un juego hobby es el mismo que evita sorpresas a las 3 de la madrugada en banca. La disciplina viaja; el dominio es anécdota.

El análisis de comida por foto en TrainO se volvió casi 2x más lento sin que hubiéramos hecho ningún deploy. No cambió el código. Cambió el comportamiento del proveedor del modelo: empezó a devolver el JSON pretty-printed. En platos con varios ítems, la respuesta empezó a chocar contra el límite de 1024 tokens de salida, y cada respuesta truncada activaba un retry con el modelo más caro. Resultado: las escalaciones pasaron de 0% a 29% en pocos días.

El aprendizaje fue simple: un límite de tokens de salida no es necesariamente un mecanismo de ahorro. Si lo aprietas demasiado, no reduces costo: solo conviertes una respuesta incompleta en un segundo intento completo, más lento y más caro.

El fix fue menos glamoroso, pero más correcto: subimos el cap de salida, forzamos JSON minificado (entre 30% y 50% menos tokens de salida) y dejamos de descartar respuestas truncadas — ahora rescatamos los ítems completos antes de decidir si hace falta escalar. También agregamos trazabilidad por registro: timings, outcome, modelo usado, fallback aplicado y causa de truncación. La próxima vez, el diagnóstico no será intuición. Será un query SQL.

Dos tests de regresión fallaban de forma intermitente. La lectura fácil era flakiness aleatorio, pero aislados fallaban igual todo el día: no eran aleatorios, eran deterministas por fecha. El generador siembra su PRNG diario con la fecha local, y el test creía fijarla con un mock de formatDateLocal apuntado al módulo equivocado — el código la importa de un módulo hermano, así que el mock era un no-op silencioso y el test quedaba a merced del reloj real (verde solo algunos días).

La moraleja doble: un mock en la ruta de import equivocada no te avisa, simplemente no se aplica; y «flaky» casi nunca es aleatorio, es determinista respecto a algo — acá, el día. El fix fue anclar el reloj con fake timers; el bug de fondo era confiar en un pin que nunca existió.

En VaultOS, la barra de comandos usa un modelo local de 3B para frases como «dame el primer password que guardé» o «la contraseña más débil» — y devolvía siempre el mismo elemento. La causa: el modelo no tiene reloj ni sabe medir fuerza de contraseñas, y ante datos que no existen un LLM no dice «no sé»: adivina.

El fix no fue prompt engineering, fue determinismo: detecto la intención con reglas, ordeno los candidatos para que el ítem 1 sea la respuesta correcta por construcción, y las frases de calidad se resuelven contra la auditoría de seguridad — con un null honesto si no hay nada. El modelo solo elige de una lista que ya no le deja equivocarse.

Entreno desde siempre. Hasta que una hernia discal me frenó y me dijeron que no volvería a entrenar. No lo acepté como veredicto: lo tomé como un problema que había que diagnosticar. Estudié y desglosé carga, recuperación y progresión hasta entenderlo —y volví. TrainO nació de ahí.

Por eso TrainO no reparte plantillas: razona. Calcula un readiness score cada día —sueño, fatiga acumulada, estado del sistema nervioso— y ajusta volumen y descansos. Cada sesión respeta tu recuperación real, no un calendario fijo. Es el sistema que yo hubiera necesitado.

Y no es una feature: es un sistema completo —entrenamiento, híbrido, cardio con GPS, un motor de nutrición con base científica (seis reglas que citan estudios reales, detección de adaptación metabólica), Apple Watch autónomo, modo coach y portal de nutricionista—. El reto fue mantener todo eso coherente: un sistema, no una suma de features.

VaultOS llegó a MVP funcional en Mac: una bóveda local-first donde la base de datos entera se cifra con AES-256-GCM, la clave se deriva con Argon2id y el desbloqueo puede ir por Touch ID.

Lo que más me gusta: corre IA local on-device, sin que un solo byte salga de la máquina. Sin nube, sin telemetría. 172 tests cubren el núcleo de cripto y datos. Privacidad por arquitectura, no por promesa.