Cuando la idea del bot de trading autodidacta se volvió concreta

La idea pasó del código al trading

La conversación empezó preguntando cómo se llama a un especialista en operaciones LONG y SHORT con criptomonedas. Un minuto después se añadió un especialista en IT y programación al equipo imaginario de IA.

Ese cambio importa. El problema ya no era solo escribir Python. El proyecto empezaba a combinar conocimiento del mercado con desarrollo de software y a pensar en la IA como un grupo de ayudantes especializados, no como un único asistente genérico.

El primer plan explícito

A las 21:41 la idea central quedó clara. Construir una máquina o programa que observara el mercado de criptomonedas, analizara lo que ocurría y pasara un periodo aprendiendo antes de poder operar.

El plan inicial imaginaba alrededor de un mes de observación e incluía posiciones LONG y SHORT. La ambición ya era mayor que una simple señal de compra o venta en una hoja de cálculo. El software debía observar, aprender y, con el tiempo, tomar decisiones.

En ese momento, sin embargo, la palabra "aprender" seguía siendo imprecisa. No había una definición madura del modelo, un protocolo de entrenamiento ni un estándar de evidencia. Era una aspiración, no un sistema de aprendizaje demostrado.

No empezar con dinero real

Pocos minutos después, el plan ganó una capa de seguridad útil. Primero aprendizaje. Después demo o paper trading. El dinero real solo debía aparecer si la fase simulada parecía rentable y, aun así, la cantidad sería muy pequeña.

Ese orden no resolvía los problemas científicos de la investigación de trading. Un paper trading rentable no demuestra que una estrategia vaya a sobrevivir en mercados reales. Pero históricamente muestra que el proyecto no pretendía entregar capital importante a un bot inacabado desde el primer día.

Observar primero. Probar sin dinero. Considerar un paso real muy pequeño solo si la etapa anterior parece convincente.

Una señal temprana de otro problema: la continuidad

Más tarde esa misma noche se pidió un prompt de recuperación por si la conversación se perdía. Parece un detalle pequeño, pero se convertiría en un problema recurrente del proyecto.

Si una IA ayuda a construir un sistema grande durante muchas sesiones, perder el contexto puede ser casi tan dañino como perder código. Mucho antes de que AUR tuviera archivos de estado, handoffs y bloqueos de investigación formales, ya existía la necesidad de conservar suficiente contexto para continuar el trabajo.

Todavía era una versión ingenua de la idea

El plan del 5 de junio escondía una suposición fuerte: dejar que el bot observara el mercado durante un tiempo y aprendería lo suficiente para operar. Las semanas siguientes mostrarían cuánto faltaba en esa frase.

Había que recopilar datos correctamente. Los backtests tenían que ser fiables. Las librerías debían funcionar. Las API de los exchanges tenían que comportarse como se esperaba. También hacía falta una forma de distinguir aprendizaje real de un código que simplemente calculaba indicadores y generaba decisiones.

Lo que vino después

El 6 de junio el proyecto pasó a la implementación. Aparecieron código temprano en Python y conexiones con exchanges, datos históricos, preguntas sobre si el bot estaba aprendiendo de verdad y los primeros problemas dolorosos de backtesting, entorno y dependencias.

El cambio del 5 de junio fue más simple: por primera vez había un destino concreto. Construir un bot cripto que observara primero, probara antes de arriesgar dinero y terminara tomando decisiones LONG y SHORT. Todo lo que siguió fue un intento de averiguar si esa idea podía sobrevivir al contacto con la realidad.