Nota histórica: esta entrada se reconstruyó a partir del archivo conservado de Gemini. La secuencia verificada del 6 de junio abarca varias conversaciones conectadas y muestra el paso de la idea a la primera implementación.
La primera pregunta no fue sobre beneficios
Poco después de la 1:00, el proyecto se restauró en una conversación nueva mediante un prompt de continuidad creado la noche anterior. Casi de inmediato apareció una pregunta práctica: ¿cómo comprobar si el bot realmente analiza datos y aprende?
Era una pregunta importante porque entonces la palabra "aprender" se usaba de forma muy amplia. Un programa puede descargar precios, calcular indicadores y producir señales sin aprender en el sentido de machine learning. Todavía no existía una prueba rigurosa para separar ambas cosas.
Ya había código real que revisar
Unos minutos después se pegó para revisión un bot de trading temprano escrito en Python. Usaba la biblioteca ccxt para comunicarse con un exchange de criptomonedas. La conversación ya no trataba solo de lo que podría ser posible. El código tenía que ejecutarse, los datos tenían que llegar con el formato esperado y las bibliotecas tenían que funcionar juntas.
El cambio histórico está en el tipo de problema. El día anterior la pregunta era qué debía llegar a ser el bot. El 6 de junio empezó la pregunta de si la implementación hacía realmente lo que se suponía.
Más historia parecía la respuesta
Por la tarde, la atención pasó a los datos históricos del mercado. La idea inicial de aproximadamente un año de historia creció rápidamente hacia varios años.
Es un impulso comprensible. Si un bot debe conocer el mercado, más datos parecen automáticamente mejores. En la práctica también significan más trabajo: recopilar correctamente, alinear tiempos, detectar huecos y asegurarse de que el backtest no use entradas malas.
El paper trading pasó a ser una etapa concreta
A las 21:23 volvió el plan por etapas del día anterior con una pregunta práctica: ¿cuándo se puede empezar con paper trading?
La dirección seguía siendo la misma. Primero pruebas sin dinero real, después un posible paso live. Pero antes había que conseguir que los datos y el backtesting fueran suficientemente fiables para confiar incluso en una simulación.
Entonces el entorno se resistió
Desde aproximadamente las 21:38, el backtesting empezó a chocar con fallos del entorno y de dependencias. Es una de las partes menos espectaculares de construir software, y una de las más reales.
Una estrategia puede parecer sencilla en una conversación. Ejecutarla requiere un entorno Python funcional, paquetes compatibles, módulos correctos y acceso repetible a datos. Cuando una pieza falla, la idea no llega ni siquiera a la prueba.
Generar código fue rápido. Conseguir que todo el sistema funcionara de forma fiable ya era mucho más difícil.
Un primer choque útil con la realidad
El 6 de junio no demostró que el bot pudiera aprender ni ganar dinero. Mostró algo más básico: la distancia entre un plan generado con ayuda de IA y un sistema de trading operativo.
A partir de ese momento había que separar varias preguntas: ¿son correctos los datos?, ¿funciona el código?, ¿es válido el backtest?, ¿el bot se adapta o solo ejecuta reglas?, ¿se puede repetir el proceso mañana sin reconstruir el entorno?
Lo que vino después
El 7 de junio la ambición creció más rápido que la madurez técnica. Apareció la idea de construir el mejor trader del mundo, preguntas sobre cuándo el bot se convertiría en experto y si debía analizar acontecimientos mundiales porque afectan a las criptomonedas.
La distancia entre la ambición y la implementación iba a convertirse en una parte importante de la historia.
AUR sigue siendo un proyecto de investigación. Las entradas históricas documentan su desarrollo; no son asesoramiento de inversión ni una promesa de rentabilidad.