Un programador de tareas no es un editor autónomo
“Trae el Markdown original, corrígelo y publícalo.”
Suena fácil.
Hasta que intentas automatizarlo.
Hay que leer el Markdown, decidir si está listo, comprobar 12 idiomas, quitar encabezados extraños, revisar enlaces, publicar, mirar la página real, volver si algo falla, encontrar la causa, corregirla, ejecutar otra vez y comprobar que el arreglo no rompió otra cosa.
De pronto, la cinta transportadora también tiene el cargo de jefe de edición.
El problema no es que Cloudflare Workers, las tareas programadas o GitHub Actions sean malos.
Están hechos para otro tipo de trabajo.
Los sistemas de automatización son excelentes repitiendo procesos conocidos. Una fábrica de contenido, en cambio, recibe textos diferentes y errores diferentes. A veces hay que leer, interpretar, corregir y verificar.
Eso se parece más a un agente que a un cron.
1. La misma tubería no significa el mismo trabajo
Una fábrica de artículos parece producción en masa.
Entrada: Markdown. Salida: artículo publicado.
Parece lógico ejecutar el mismo proceso cien veces.
Pero un texto no es una pieza idéntica de fábrica.
El artículo A tiene un título raro. El B perdió uno de los 12 idiomas. El C está traducido, pero usa palabras que nadie buscaría en ese país. El D publicó por accidente una nota interna de SEO. El E tiene un enlace de afiliación válido, pero colocado en un sitio absurdo. El F se publicó bien, pero el sistema sigue marcándolo como “en ejecución”.
Todo ocurrió dentro del mismo proceso.
Pero cada fallo necesita una solución distinta.
Si la entrada cambia, también cambia la forma del error.
2. Los programadores son muy buenos ejecutando trabajo conocido
GitHub Actions ejecuta flujos definidos de antemano cuando ocurre un evento, cuando se lanza manualmente o según un horario.[1]
ChatGPT Scheduled Tasks también ejecuta tareas en horarios elegidos o ante eventos compatibles.[2]
Cloudflare Workers es una plataforma muy potente para manejar solicitudes, trabajos periódicos y conexiones entre servicios.
Estos sistemas responden muy bien a preguntas como:
“¿Cuándo se ejecuta?” “¿Qué script toca?” “¿Terminó correctamente?” “¿Qué hacemos si esta condición es verdadera?”
Otra cosa es preguntar:
“¿Este título suena demasiado traducido?” “¿Esta sección es correcta pero inútil para el lector?” “¿El enlace funciona pero está mal colocado?” “¿El error de hoy es realmente el mismo de ayer?”
Un programador tiene reloj.
No viene con intuición editorial.
3. Lo difícil es cerrar todo el ciclo de mejora
No basta con cambiar una cosa.
Hay que:
detectar el fallo, diagnosticar la causa, corregir, volver a ejecutar, comprobar el resultado real, buscar efectos secundarios, y probar otra hipótesis si la primera era incorrecta.
Una persona hace esto casi sin pensarlo.
En automatización, cada transición debe diseñarse.
Los casos más molestos son los éxitos parciales.
La página se publicó, pero el estado no cambió.
La traducción terminó, pero un idioma quedó vacío.
El repositorio cambió, pero el despliegue real falló.
Si simplemente repites todo, puedes duplicar trabajo o publicar dos veces.
Por eso una automatización robusta no solo busca “no fallar”.
Busca:
que repetir la operación sea seguro.
Cloudflare Workflows está diseñado con pasos duraderos, resultados persistidos y reintentos, y su documentación insiste en que las operaciones repetidas deben ser seguras.[3][4]
4. Cloudflare puede recuperar procesos, pero no sustituye el criterio editorial
Cloudflare Workflows puede conservar el estado de tareas de varios pasos, reintentar partes fallidas y continuar desde pasos ya completados.[3]
Cloudflare Queues puede reintentar mensajes y enviar los que fallan repetidamente a una Dead Letter Queue.[5]
Eso sirve muy bien para:
errores temporales de red, fallos de API, tiempos de espera, mensajes que no se procesan, trabajos que deben continuar más tarde.
Pero hay otros problemas:
“El español se entiende, pero nadie buscaría así.”
“El contenido es correcto, pero este subtítulo empeora el artículo.”
Subir los reintentos de tres a diez no crea criterio editorial.
Solo puede repetir el mismo fallo diez veces con una disciplina admirable.
Reintentar no es pensar.
5. GitHub Actions es un excelente banco de trabajo, no un editor autónomo
GitHub Actions es fantástico para tareas deterministas.
Ejecutar pruebas. Validar archivos. Construir. Desplegar con reglas claras. Lanzar scripts periódicos.
Ese es su terreno.[1]
Pero Actions no lee un texto y concluye:
“El problema no está en el título, sino en la introducción.”
Puedes llamar a una IA desde el flujo, sí.
Pero entonces el problema importante pasa a ser otro:
qué contexto ve la IA, qué puede modificar, cómo verifica el resultado, y cómo continúa después de un fallo.
Culpar a GitHub Actions por no ser editor es como pedirle a un taladro eléctrico que dirija la reunión de redacción.
6. Mejor dos caminos que una obsesión por el 100% automático
Una fábrica práctica necesita dos rutas.
Ruta normal: automatizar lo comprobable
La máquina puede revisar:
- archivos obligatorios
- 12 idiomas presentes
- campos no vacíos
- formato de URL
- identificadores únicos
- comando de publicación correcto
- página final accesible
Workers, scripts y Actions son buenos para eso.
Ruta de excepciones: aislar y seguir
Un artículo defectuoso no debería detener todo el lote.
Registra el motivo. Aparta el artículo. Continúa con el siguiente.
Por ejemplo:
- idioma ausente
- estructura incorrecta
- enlace roto
- error de publicación
- revisión semántica necesaria
- causa desconocida
Si 90 de 100 pasan automáticamente, publica los 90.
No hace falta castigar a 90 artículos sanos porque diez necesitan una conversación seria.
Salta la excepción y sigue.
7. Las excepciones son trabajo para un agente que pueda leer el repositorio
La ruta de excepciones suele requerir lectura, razonamiento, edición y verificación.
Ahí encaja un agente de programación.
La documentación de Codex Cloud describe tareas en un entorno preparado donde el agente puede investigar errores, cambiar código, ejecutar pruebas y continuar el trabajo desde dispositivos compatibles.[6]
En una fábrica de contenido, ese agente puede ser la mesa de reparación:
tomar el artículo fallido, leer el Markdown original, examinar la salida, leer el registro del error, revisar código si hace falta, corregir, ejecutar comprobaciones, volver a publicar, y verificar la página real.
No hace falta gastar razonamiento avanzado en cada artículo normal.
La máquina procesa lo rutinario.
El agente se queda con lo extraño.
8. Cuando una excepción se repite, conviértela en regla
La cola de excepciones tampoco debe convertirse en un vertedero permanente.
Si el mismo fallo aparece muchas veces, ya no es una excepción. Es un patrón.
Si siempre falta un idioma, añade una comprobación automática.
Si aparece el mismo encabezado no deseado, crea una validación que lo bloquee.
Si la publicación funciona pero falla el registro de estado, verifica primero la página real y repara el estado después.
La secuencia sana es:
poner la fábrica en marcha, recoger fallos reales, usar agentes para casos raros, detectar patrones, automatizar solo los patrones frecuentes.
Intentar predecir todos los fallos posibles antes de publicar nada es una forma excelente de construir una fábrica eternamente y no fabricar jamás.
Conclusión: el programador es la cinta; el agente es el taller de reparación
Cloudflare, las tareas programadas y GitHub Actions decepcionan si esperas que se comporten como editores autónomos.
Pero esa no es su función.
El sistema programado debe:
arrancar, hacer comprobaciones deterministas, mover los casos correctos, aislar los fallos, y mantener la línea en marcha.
El agente debe responder:
“¿Por qué este artículo es raro?” “¿Qué hay que cambiar?” “¿La corrección funcionó de verdad?”
La arquitectura útil es sencilla:
Automatiza la ruta fácil. No dejes que una excepción bloquee el lote. Manda las excepciones al agente. Convierte las excepciones repetidas en reglas automáticas.
La fábrica no necesitaba una cinta transportadora capaz de pensar en todo.
Necesitaba una cinta que no se detuviera y un buen taller para las cajas que se salieran de la línea.
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
