n8n vs Prefect: Asi un dia los workflows visuales dejan de escalar
Hace unos meses decidí automatizar algo que parecía sencillo: generar artículos para mi blog técnico a partir de material fuente. La idea era construir un pipeline que tomara contenido, lo procesara con varios LLMs, generara metadata, tradujera el resultado a español y finalmente lo publicara en Grav.
En teoría era una automatización clásica.
En la práctica terminó convirtiéndose en un pequeño sistema editorial.
Al principio probé hacerlo con n8n, porque para automatizaciones rápidas es una herramienta fantástica. Pero a medida que el flujo crecía, empecé a notar algo extraño: cada vez entendía menos mi propio pipeline.
El sistema funcionaba… pero ya no confiaba completamente en él.
Ese momento me llevó a replantear algo que rara vez se discute abiertamente:
No todos los workflows son automatización. Algunos terminan siendo software.
Y cuando eso ocurre, la herramienta que eliges importa mucho más de lo que parece.
Cuando la automatización deja de ser simple
Mi pipeline terminó teniendo algo así:
- selección de fuente según franja horaria
- generación editorial en varias etapas (outline → draft → review → edición final)
- generación paralela de metadata (slug, SEO, TLDR, tono, lectura estimada, etc.)
- enriquecimiento opcional con fuentes externas
- generación completa en inglés
- traducción automática al español
- búsqueda de artículos relacionados
- publicación en Grav
- deploy remoto opcional por SSH
- notificación a Slack
Nada particularmente revolucionario, pero suficiente para que el flujo tuviera 30 pasos y múltiples ramas.
Ese tipo de sistema tiene características que cambian la naturaleza del problema:
- decisiones condicionales
- paralelismo
- fallback logic
- manejo de estado intermedio
- múltiples artefactos de salida
- side effects controlados
En otras palabras: ya no era simplemente conectar servicios.
Era orquestar comportamiento.
El límite de los workflows visuales
Las herramientas visuales como n8n son excelentes cuando el flujo es algo como:
Webhook → Transform → API → NotificaciónPero cuando empiezas a tener:
- múltiples ramas
- merges complejos
- datos que evolucionan entre etapas
- lógica de fallback
- paralelismo real
el diagrama empieza a crecer como una planta sin podar.
El problema no es solo visual.
El problema es cognitivo.
En un pipeline grande empiezas a preguntarte cosas simples:
- ¿qué versión del draft llegó al final?
- ¿qué fallback se activó?
- ¿por qué faltan links externos en este artículo?
- ¿en qué nodo se generó realmente el slug?
Y responder esas preguntas en un canvas visual enorme empieza a ser sorprendentemente difícil.
En mi caso llegué a una sensación incómoda:
el sistema corría, pero ya no podía razonar fácilmente sobre él.
El mismo pipeline, pero como código
Decidí reconstruir el pipeline en Prefect, escribiendo cada etapa como una tarea explícita en Python.
Eso significaba más trabajo inicial, pero algo cambió inmediatamente.
El workflow dejó de ser un diagrama y volvió a ser software legible.
Las etapas se convirtieron en funciones claras:
load_source()generate_outline()draft_article()review_draft()generate_metadata_parallel()translate_to_spanish()resolve_related_articles()publish_to_grav()
Cada paso tenía:
- inputs definidos
- outputs claros
- logs útiles
- retries controlados
El pipeline seguía siendo complejo, pero ahora la complejidad era explícita y manejable.
No necesitaba navegar un grafo enorme para entender qué estaba pasando.
Solo tenía que leer código.
Automatización vs orquestación
Después de esta experiencia, empecé a ver estas herramientas de forma diferente.
n8n brilla cuando quieres conectar servicios rápidamente:
- webhooks
- integraciones SaaS
- automatización operativa
- procesos internos
Pero cuando el flujo empieza a tener:
- lógica compleja
- paralelismo
- estado intermedio importante
- decisiones dinámicas
- pipelines de IA
entonces deja de ser automatización.
Empieza a parecerse más a un sistema backend con orquestación.
Y ahí herramientas como Prefect, Airflow o Temporal se sienten mucho más naturales.
No porque sean más poderosas, sino porque permiten que el workflow siga siendo código.
La lección que me llevé
Las herramientas visuales optimizan la velocidad inicial.
Las herramientas programables optimizan la mantenibilidad.
Cuando el sistema es pequeño, la diferencia no importa. Cuando el sistema crece, importa muchísimo.
Hoy sigo usando n8n para integraciones rápidas. Pero para pipelines complejos —especialmente cuando involucran LLMs— prefiero que la lógica viva en código.
Porque cuando algo inevitablemente falla en producción, quiero poder responder una pregunta muy simple:
¿Dónde exactamente ocurrió el problema?
Y esa pregunta es mucho más fácil de contestar cuando el workflow es software, no un diagrama.
Si te interesan este tipo de experimentos con pipelines, IA y automatización, probablemente encuentres más historias técnicas en Deeditt, donde intento documentar no solo lo que funciona, sino también lo que me hizo replantear cómo construyo sistemas.
Happy coding.
--
Photo by SELİM ARDA ERYILMAZ on Unsplash
Written with StackEdit.
