Quería que una IA publicara por mí cada mañana (Parte 1/2)
Acabé peleándome con un error de los años 90.
Llevo semanas con una tesis en la cabeza… El problema ya no es construir, es que alguien lo vea. Construir se ha vuelto barato y rápido; la distribución, en cambio, sigue siendo dura y manual. Así que me propuse un experimento: montar un agente que se ocupara de la parte aburrida (publicar, medir y aprender) mientras yo me dedicaba a otra cosa.
Hola, soy Pol Marzà, AI Product Builder y cada semana escribo una nueva edición de Con Criterio, la newsletter sobre construir productos digitales con IA, con planificación, método y sin atajos. Si te han reenviado este email, puedes suscribirte aquí:
El plan era sencillo. Cada mañana, el agente escribiría tres versiones de un post (tres ángulos distintos), las publicaría en Bluesky a través de Buffer, recogería las métricas del día anterior y ajustaría el contenido del siguiente. Y lo más bonito: el contenido iría sobre cómo se estaba construyendo el propio agente. El medio como mensaje.
Para el disparo diario tiré de lo que tenía más a mano: /loop, el comando de Claude Code que repite una tarea cada cierto tiempo. “Que se lance solo a las ocho”, pensé. Dejaba el Mac en reposo por la noche y, en teoría, a la mañana siguiente el agente habría publicado.
Spoiler: no funcionó 🥲
El muro
Lo primero que descubrí es que /loop no estaba pensado para esto.
/loop vive dentro de una sesión abierta y necesita el ordenador despierto: cuando el Mac entra en reposo, macOS suspende los procesos y el temporizador, sencillamente, no dispara.
Pero el problema de verdad llegó cuando intenté forzarlo.
Para que el agente publicara sin pedirme permiso cada mañana, edité a mano la configuración de permisos. Y ahí Claude Code empezó a bloquearse: cada vez que enviaba un mensaje, ocurría esto: process exited with code 1 — an internal error occurred (EPERM). Treinta minutos sin poder trabajar, desinstalando y reinstalando para recuperar el control.
EPERM significa “operation not permitted”. Es un error del sistema de archivos, no de la configuración de Claude. ¿La causa de fondo? Tenía todo (el proyecto y la carpeta de configuración de Claude) en un disco externo. Las escrituras y los bloqueos que Claude hace constantemente empezaron a chocar con los permisos del volumen externo.
La lección que me llevé
Pasé un buen rato culpando a mi configuración. Estaba equivocado: un EPERM casi nunca es culpa de tu config, sino del sistema de archivos que tienes debajo. Pero la lección más útil no fue esa, fue otra:
Había confundido dos cosas que parecen iguales y no lo son: lo atendido y lo desatendido.
/loop es una herramienta atendida: brilla cuando estás delante, con la máquina despierta y la sesión viva. Para vigilar un deploy mientras trabajas, para iterar sobre una tarea hasta terminarla, es perfecta. Lo que yo necesitaba era lo contrario: algo desatendido, que corriera cada mañana durante semanas, con el Mac apagado y sin nadie delante. Dos mundos distintos.
Y ahí estaba el verdadero problema de diseño: no era de permisos, era de arquitectura. Mi automatización dependía de mi portátil, y un portátil se duerme, se apaga y vive en un disco que se queja. Si quería que aquello corriera de verdad solo, tenía que sacarlo de mi máquina.
En la segunda parte cuento cómo lo hice: moverlo todo a la nube, qué decisiones tomé con criterio por el camino (incluida una que me hizo pasar de “gratis” a pagar unos céntimos al mes, a propósito), y cómo quedó un sistema que, literalmente, se cuenta a sí mismo.