Hace unas semanas terminé mi tercera maratón, la segunda en Madrid, y la terminé en 3:25. Para mí, mejorar mi marca en maratón no era tan importante como terminarla sin lesionarme (en la anterior terminé con una sobrecarga muscular), y lograr superar ese “muro de la maratón” al que me había enfrentado en las anteriores ocasiones.
En este post me gustaría contaros cómo, usando la IA, logré cumplir ese objetivo.
Por qué un agente y no un chat
En anteriores ocasiones había usado la IA como creo que lo usan muchas personas que comienzan a hacer uso de ella para el deporte. Quiero hacer X marca en 10k/media maratón/maratón, y le pido a ChatGPT/Claude que me escriba un plan de N semanas. Quizás le doy algo de contexto sobre el tiempo que tengo para entrenar, mis ritmos, y mis mejores marcas. Y te lo da. Pero pasan las semanas, y crees que no se ajusta bien a tu ritmo de vida, o tiene demasiada carga para tu nivel de forma actual, o algún otro problema que hace que te entren las dudas. Y el gran problema es que, si abres una conversación nueva, la IA que generó ese plan no sabe quién eres, ni lo que has estado entrenando la semana pasada, ni el contexto que le diste en la preparación del plan. No sabe nada de ti. ¿Te imaginas que tu entrenador personal fuera como el protagonista de la película Memento?. Suena ridículo, pero así era como usaba la IA antes, y era frustrante a la par de inútil.
Un entrenador humano hace muchas más cosas que un chat de IA, por defecto, no hace. Te conoce: sabe tu edad, tus marcas, tus lesiones, qué zapatillas usas, a qué hora entrenas. Mira tus datos, te pregunta, revisa tus actividades de la semana, lee los splits, compara con la semana anterior, valora tu contexto y situación actual, mental y física. Y decide la semana siguiente en función de la anterior: la planificación del miércoles depende de cómo te vio el lunes.
Un chat suelto falla en todo eso. Empieza de cero cada vez. No accede a tus datos a menos que se los pegues. No recuerda lo que se dijo en la conversación previa porque, para él, no hubo conversación previa. La solución que planeé para atacar este problema fue tratar de resolver esas pérdidas de contexto, y dejar de usar la IA como la había estado usando hasta entonces.
La arquitectura
Imagina dos personas trabajando para ti, conectadas por una nota semanal. La primera mira lo que has hecho durante la semana y prepara un informe con métricas, splits y observaciones. La segunda toma ese informe y planifica la siguiente semana. Cada una tiene su trabajo, sus herramientas, su contexto. La nota intermedia es lo único que las une.
Mi sistema funciona así. Dos proyectos independientes: Uno en Claude Desktop como proyecto, llamado “Entrenador Personal”, y otro en el que uso Claude Code llamado “Generador de informes”. Ambos se comunican a través de un archivo markdown que genero cada lunes con el generador de informes y que comparto con el entrenador personal.
Hay dos razones por las que separé el sistema en dos proyectos en lugar de meterlo todo en uno. La primera es técnica: Claude Code permite definir Skills, archivos que orquestan un trabajo con un formato y una ventana de tiempo configurables. Eso encajaba bien con la pieza de extracción del informe. La segunda es pragmática: ya tenía MCPs configurados en Code y configurar el de Strava ahí me llevó unos minutos.
El generador de informes corre en Claude Code, dentro del editor o linea de comandos. Está conectado a un MCP público de Strava (Doy detalles más adelante), un servicio que expone mis actividades como herramientas que Claude puede consultar directamente. Una skill que escribí, informe-semanal, orquesta el trabajo: determina la semana en curso, pide la lista de actividades, recupera detalles y vueltas por cada una, me pregunta por las sensaciones si las he omitido en Strava, aplica una plantilla y guarda un markdown en disco con nombre YYYY-MM-DD_YYYY-MM-DD_semana.md. El output es un informe con kilómetros, splits, distribución por zonas de frecuencia cardíaca, evolución de carga de las últimas cinco semanas y observaciones para el entrenador. Podeis encontrar la skill completa aquí.
El entrenador personal se ejecuta en Claude Desktop, en un proyecto dedicado. Sus instrucciones permanentes incluyen mi perfil completo, mis principios de entrenamiento codificados como reglas, y un plan inicial de 12 semanas para Madrid como archivo del proyecto que sirve como guía al entrenador. Cada lunes le subo el informe que generó el primero, añado dos o tres frases con cómo me siento físicamente, y le pido la planificación de la semana siguiente.
Las tres palancas
Tres elementos hacen que esto funcione, y cada uno resuelve una de las pérdidas de contexto del apartado anterior.
1. Contexto permanente
Las instrucciones del proyecto son lo primero que Claude lee al empezar cualquier conversación. No es algo que se le pega en el primer mensaje y se olvida en el segundo. Se configura en el proyecto, vive ahí, es persistente, y no desaparece entre sesiones.
En el proyecto “Entrenador personal” tengo cargadas unas instrucciones. Un extracto de cómo están organizadas:
PERFIL
Edad: <>. Peso: <> kg. FCmáx: <>. FC reposo: <>.
VO₂máx estimado: <>. Años corriendo: <>. Km totales: <>.
Marcas: 5K <>, 10K <>, HM <>, M <>.
ZONAS FC (Karvonen, no Garmin por defecto)
Z1: < <> Z2: <>-<> Z3: <>-<>
Z4: <>-<> Z5: > <>
PRINCIPIOS NO NEGOCIABLES
- Salud > progresión > rendimiento, en este orden.
- 80/20: 80% del volumen semanal en Z1-Z2.
- Crecimiento máximo de volumen: 10-15% por semana.
- Honestidad sobre objetivos irrealistas. Si discrepas, discrepa.
...
Para escribir esas instrucciones también me apoyé en la IA. Las redacté dando como contexto todo lo que no había salido bien en mis preparaciones anteriores. Por ejemplo, un aspecto clave fue la sobrecarga muscular que tuve en la anterior maratón. Eso hizo que especificara en las instrucciones que debía incluir al menos un día de fuerza por semana, y si era posible, dos. También tuvo en cuenta que la estrategia de ritmo que seguí en la anterior maratón no había sido acertada, y me recomendó seguir una basada en pulso.
El otro efecto del contexto permanente es menos obvio. El modelo discrepa conmigo cuando toca. En numerosas ocasiones he tratado de meter más intensidad de la que tocaba en los días de calidad. Esto ya me había traído problemas en el pasado en forma de sobrecargas y molestias. Lo configuré para que fuera honesto y discrepara siempre que lo veía necesario, explicando siempre el porqué de sus decisiones. Eso hizo que a lo largo de la preparación no tuviera ningún tipo de sobrecarga, y fuera asimilando el volumen de manera correcta, sin sobreentrenar.
2. Datos sin copy-paste
MCP son las siglas de Model Context Protocol. Es un estándar abierto, diseñado por Anthropic a finales de 2024, que define cómo un modelo accede a herramientas externas: APIs, bases de datos, servicios. Una vez configurado, el modelo “ve” esos servicios como funciones que puede llamar. Hay MCPs casi para cualquier plataforma: Garmin, Google Calendar, Notion y casi cualquier servicio con API.
Sin MCP, el flujo es: yo voy a Strava, hago un pantallazo o copio los datos, pego en el chat, y explico qué información le estoy dando (Por ejemplo, si son las actividades de esta semana). Con MCP, le digo “haz el informe de esta semana” y Claude consulta Strava por su cuenta. Esto facilita mucho la extracción de información y hace que esa provisión de contexto a la IA sea mucho más sencilla y completa.
Usé el MCP de Strava porque es la aplicación que más uso. El MCP de Strava que uso es público, y se instala en un par de minutos. A día de hoy, no hay un conector para Strava o Garmin que permita usarlo desde Claude Desktop, aunque no creo que tarde mucho en llegar.
Este es un ejemplo de como usé el skill /informe-semanal para generar el informe de una semana que compartí con el entrenador:
/informe-semanal esta semana. La tirada larga del martes se me hizo pesada. Hice 23km respecto a los 26 planeados por que sopló bastante el viento. Creo que noté también algo la fatiga de los 94km de la semana pasada. Este fin de semana ha sido cansado también. Estuve de viaje, y el domingo no hice el entrenamiento planeado. Creo que esta semana necesito recuperarme de la semana anterior.
3. Bucle iterativo
El plan inicial de 12 semanas es un guardarraíl, y no está escrito en piedra. Se lo dije al proyecto explícitamente al generarlo: este plan es una referencia, cada semana tienes que ajustarlo a lo que cuente el informe y a cómo llegue yo.
El bucle se repite cada semana con cuatro entradas cada lunes: los informes de las semanas anteriores, las sensaciones que añado yo, la semana correspondiente del plan original (que obtiene del documento cargado en el proyecto), y todo lo almacenado en la memoria durante el proceso. La salida es la planificación de la semana siguiente, justificada paso a paso. Si propone reducir volumen tras una semana floja, dice por qué. Si propone subir, también.
No siempre acierta a la primera. A veces pecaba de conservador, priorizando que no me lesionara cuando mis sensaciones eran buenas, y yo le matizaba que estaba para más. Otras veces el plan que proponía no encajaba con un viaje de fin de semana, y le pedía adelantar carga a principio de semana. La gran diferencia con un chat suelto es que aquí la segunda iteración llega con todo el contexto cargado.
Para entrenadores
Mi caso quizás no es el caso típico de persona que está empezando a fijar sus primeras metas. Llevo ya más de cinco años corriendo de manera habitual, dos maratones previas y, por mi perfil técnico, sé qué es un MCP y cómo se configura un proyecto de Claude. Para alguien que empieza, un entrenador humano sigue dando cosas que un sistema como este no puede dar: la mirada que ve la lesión antes de que llegue, el freno cuando uno se cree más fuerte de lo que es, la rendición de cuentas de tener que hablar con otra persona el lunes.
Para mí no es ahorro de tiempo. Producir el informe me lleva cinco minutos, y cerrar el plan con Claude otros diez. Probablemente tardaría un tiempo similar si lo hiciera yo mismo. Lo que tengo es un segundo criterio cada lunes: la diferencia entre planificar yo solo, valorándome a mí mismo, y planificar con alguien que conoce mis lecciones documentadas y discute conmigo cuando hace falta.
Para un entrenador profesional, el cuello de botella no es el conocimiento, es el tiempo. Procesar los datos de quince corredores, cruzarlos con su historia, redactar las observaciones de la semana: esa parte se la come bien un agente. La parte difícil, decidir, hablar con el corredor, leer entre las métricas lo que no aparece en las métricas, se queda donde tiene que quedarse.
Creo que este sistema no automatiza el entrenamiento, y que hay una oportunidad enorme para entrenadores personales que quieren dar un servicio más personalizado a más clientes. Para corredores amateurs como yo, creo que ayuda a tener un entrenamiento algo mas personalizado, y programar cada entrenamiento de acuerdo a un contexto mas amplio, y no sobre lo que tocaba en un calendario impreso hace tres meses o descargado de internet.