Contexto técnico
Me encantan estas historias no por lo anecdótico, sino por la conclusión de ingeniería tan sincera. Le pides a un modelo que haga un eval «invulnerable» y, en vez de solo variar la semilla en el código, ya está trayendo la red principal de Bitcoin como fuente de aleatoriedad «verdaderamente impredecible». Ahí se ve cómo la implementación de IA puede desviarse del sentido común hacia el culto a la rigurosidad absoluta.
Dejando las bromas, la lógica técnica existe. El hash de un futuro bloque de Bitcoin realmente no se puede predecir con normalidad, y como fuente de entropía externa funciona. Pero yo ahí pararía de inmediato: para evaluar un modelo normalmente necesito reproducibilidad, una semilla controlada y estadísticas claras, no diez minutos de espera por un bloque y una dependencia extra de una red ajena.
Aquí lo que me llama la atención no es Bitcoin, sino la trayectoria de pensamiento del modelo. Le dieron el objetivo de «no confiar en el azar local» y diligentemente se fue a buscar una fuente de aleatoriedad más «pura». No la más óptima, ni barata, ni rápida. Simplemente la más protegida contra un defecto imaginario.
Y esto es muy indicativo de los sistemas agentivos modernos. Si en el prompt o la especificación dejas un vacío tipo «hazlo lo más fiable posible», el modelo empezará a construir una arquitectura de IA para el peor caso, no para la tarea real. Luego la gente se sorprende de que un simple eval requiera de repente acceso a red, APIs externas y medio día para ejecutarse.
Impacto en el negocio y la automatización
La conclusión para los negocios es sencilla: no solo los requisitos débiles son peligrosos, sino también los excesivamente heroicos. Cuando diseño automatización con IA, siempre separo «suficientemente bueno en términos estadísticos» de «criptográficamente impecable». Estos dos modos cuestan sumas de dinero completamente diferentes.
Solo ganan aquí los escenarios raros donde se necesita una fuente externa de entropía públicamente verificable. Pierden casi todos los pipelines aplicados: eval, pruebas A/B, tests internos de agentes, evaluación de calidad por lotes. Ahí obtienes retrasos, complejidad de integración y fragilidad en vez de beneficios.
Lo veo constantemente en los clientes: el problema no es el modelo, sino la formulación de los requisitos. En Nahornyi AI Lab precisamente aterrizamos estas cosas para que la automatización con IA no se convierta en una fantasía de ingeniería costosa. Si su sistema ya empieza a «pensar de manera demasiado fundamental» donde solo se necesita un resultado que funcione, revisemos la arquitectura y construyamos soluciones de IA para empresas sin el culto a la perfección.