Me pasó con Pulse, un gestor de tareas que uso yo y construí para mí. Esta es la historia de lo que rompí por confiar de más en el LLM, y cómo lo arreglé.

Por qué construí Pulse

Probé Motion, Sunsama, Reclaim, Akiflow, ClickUp. Todas asignan trabajo por horas disponibles: bloqueas 90 minutos, te meten una tarea de 90 minutos. Ninguna entiende que una hora a las 9 vale más que dos a las 16.

Quería un sistema que cruzara tres cosas para decidir qué tarea encaja en cada hueco: el tipo de trabajo (creativo, ejecutivo, comunicación), las horas libres del día, y mi energía en ese momento según mi patrón habitual.

Empecé a construir Pulse hace unos meses. La v1.1 lleva una semana en producción.

El primer scheduler era 100% Claude

El planteamiento parecía elegante. Cada noche, Claude leía todas mis tareas pendientes y devolvía el orden del día siguiente con qué tarea iba a qué hora.

Sonaba bien. Claude Code me llevó ahí en pocas iteraciones: yo le iba describiendo la lógica de priorización en lenguaje natural y él la traducía a código. A las 48 horas tenía algo que funcionaba en ejemplos.

Hasta que lo dejé corriendo en automático un par de semanas.

Dos problemas que solo aparecen en producción

Primero, lentitud. Cada vez que reordenaba mis tareas, Claude tardaba entre 8 y 15 segundos en responder. En un proceso automático nocturno se aguanta. Pero cualquier cambio durante el día (mover una tarea, añadir una nueva) disparaba la repriorización y el sistema se sentía pesado.

Segundo, inestabilidad. Cambiar una palabra del prompt cambiaba el orden entero. La tarea X aparecía arriba un día y abajo al siguiente sin que yo hubiera tocado su contenido. Y lo peor: no podía debugear por qué. Claude era una caja negra que me daba respuestas distintas en distintos momentos.

Esto es algo que Claude Code no te avisa cuando construyes. Te empuja a soluciones que parecen elegantes ("un LLM puede hacer todo") y prototipan rápido. Pero para un sistema que tiene que correr 365 días sin sorpresas, son veneno.

El rediseño

Acabé separando el scheduler en dos partes.

Una base de prioridad calculada con código clásico. Cada tarea recibe una puntuación según la importancia de su carpeta, la urgencia, y la fecha límite. Es estable y predecible: si la tarea X tenía 78 puntos ayer, sigue teniendo 78 hoy a menos que yo la haya editado.

Encima de esa base, Claude ajusta. Le doy la lista con puntuaciones y le permito mover cada una un máximo de 15 puntos arriba o abajo, justificando cada cambio. Si la tarea X sube de 78 a 91 porque Claude decidió que era más urgente, yo veo el razonamiento y puedo desactivar el ajuste si no estoy de acuerdo.

Y la colocación en el día (qué tarea va en qué hueco) ya no la decide Claude. La hace código clásico: respeta mis horarios de trabajo, encaja tareas back-to-back, y prioriza los huecos que coinciden con mi mapa de energía.

Resultado: unas 400 líneas más de código clásico. Más trabajo. Pero el sistema ahora es estable, debugeable, y la latencia bajó por debajo de los 2 segundos.

Lo que aprendí del stack por el camino

Algunas decisiones que solo vi cuando me topé con ellas.

Uso Claude a través de la línea de comandos (claude -p), no a través de su API oficial. La API se paga por uso; la línea de comandos usa mi suscripción Max plana. Para un proceso automático diario, la diferencia es 0€ vs 30-50€ al mes.

Para los datos uso Supabase, que es una base de datos Postgres con extras integrados. Aunque Pulse solo lo uso yo, me da algo útil: cuando muevo una tarea en el móvil, el desktop la ve actualizarse en tiempo real sin tener que recargar.

Y monté un servidor aparte para exponer Pulse a la aplicación de Claude. Eso me permite añadir tareas desde una conversación con Claude sin abrir Pulse. El servidor está en Hostinger porque Vercel (donde vive el resto de la app) no permite procesos que se queden corriendo.

El patrón que aprendí

Si estás construyendo algo con Claude Code y todavía no lo has dejado correr en producción real (un cron, usuarios, uptime), este es el patrón que recomiendo:

"Cualquier decisión que tenga que ser estable a 12 meses, sácala del LLM y métela en código clásico. Deja al LLM el rol de ajustar, no el de juez."

Es menos sexy. Es más código. Pero es la diferencia entre algo que se mantiene y algo que tienes que reescribir cada vez que cambia el modelo o el prompt.

¿Has construido tus propias herramientas con Claude? Si es así, cuéntame qué.