Un Repositorio Open-Source Convirtió a Claude Code en un Arquitecto de n8n — Y n8n Nunca Ha Sido Más Útil
El martes pasado a las 11 PM vi cómo Claude Code borró 140 variantes de producto de una tienda e-commerce en producción. No fue malicioso. Ni siquiera técnicamente incorrecto.
El flujo de trabajo que le pedí que arreglara estaba enviando una petición PUT a la API XML de PrestaShop con solo 4 campos. PrestaShop lo interpretó como "vacía todo lo demás". Referencias eliminadas. Códigos de barras perdidos. 140 combinaciones silenciosamente borradas mientras yo comparaba logs de ejecución en otra pestaña del terminal.
TL;DR: n8n no está muriendo. Lo que está muriendo es construir flujos de trabajo manualmente. Un repo open-source (czlonkowski/n8n-mcp) convirtió a Claude Code en un arquitecto de n8n. Lo he usado en un pipeline real de producción de 55 nodos, y por separado desactivé mi propio agente de IA porque quemaba tokens sin sentido. A continuación: qué funciona realmente, qué se rompe, y un framework para saber cuándo usar cada herramienta.
Quince minutos después, Claude Code también había diagnosticado la causa raíz, construido la solución (un patrón GET-antes-PUT a través de 4 nodos nuevos), desplegado los 12 cambios en una sola llamada atómica a la API, y verificado la reparación extrayendo el estado de la API de PrestaShop antes y después.
La misma investigación en la UI de n8n me habría tomado más de una hora. Lo sé porque lo he hecho antes, haciendo clic a través de 55 nodos, cambiando entre pestañas del navegador, exportando JSON manualmente, revisando datos de ejecución a ojo.
Dos semanas antes, había desactivado mi propio agente de IA. Le quité el enchufe a OpenClaw, el sistema multi-modelo que había estado construyendo y sobre el que había escrito durante meses. La relación entre tokens gastados y valor producido era negativa. El agente seguía gastando ciclos tratando de actualizarse a sí mismo en lugar de hacer trabajo real.
Así que ahora tenía una paradoja en mi terminal: un agente de IA que construí yo mismo que no podía justificar su propia factura de electricidad, y un sistema de flujos de trabajo asistido por IA que acababa de salvar una base de datos de producción en 15 minutos.
Esa paradoja es básicamente todo el debate sobre n8n ahora mismo.
El Repo Que Cambió la Descripción del Trabajo de n8n
Hace tres meses le pedí a Claude Code que me construyera un flujo de trabajo de n8n.
Inventó un nodo llamado scheduleTrigger. Ese nodo no existe. El real se llama schedule. Pasé 20 minutos depurando un error de importación en un archivo JSON que parecía perfectamente válido porque cada nombre de propiedad estaba casi correcto. Lo suficientemente cerca para importar, lo suficientemente mal para romperse. Claude estaba tan seguro además. Pura energía de alucinación. "Aquí tienes tu flujo de trabajo" y el JSON se ve hermoso hasta que te das cuenta de que la mitad de los tipos de nodos son fan fiction.
Dejé de pedirle a Claude Code que tocara n8n después de eso.
Entonces un desarrollador llamado czlonkowski publicó un servidor MCP open-source. Y la siguiente vez que le pedí a Claude Code que construyera un flujo de trabajo, conocía cada nombre de nodo, cada esquema de propiedades, cada sintaxis de conexión de ramas IF. Sin alucinaciones. Sin adivinanzas.
El debate online sobre lo que pasó después va así: Claude Code se está comiendo el almuerzo de n8n. Google Trends muestra que está superando a n8n en interés de búsqueda. Los creadores de YouTube que construyeron audiencias con tutoriales de n8n ven caer sus visualizaciones. Hilos de foros titulados "¿Está Muerto n8n?" aparecen cada dos semanas. El consenso siempre es la misma cosa tibia: "son herramientas complementarias para diferentes niveles de habilidad."
Ese consenso es preciso y completamente inútil.
El cambio real es más específico. El servidor n8n-mcp de czlonkowski (en GitHub) le da a Claude Code acceso estructurado a 1,084 nodos de n8n, más de 2,600 configuraciones del mundo real extraídas de plantillas, y reglas de validación que atrapan errores antes del despliegue. Un proyecto complementario añade 7 habilidades de Claude Code cubriendo sintaxis de expresiones, patrones de arquitectura y depuración.
n8n también lanzó su propio MCP oficial (Settings > Instance-level MCP), pero el suyo es deliberadamente más limitado: activar y consultar flujos de trabajo existentes, no construir nuevos. Decisión consciente de seguridad, no una debilidad.
Así que lo que pasó es que el constructor visual de n8n no murió. Cambió de trabajo. Solía ser la herramienta de construcción. Ahora es el panel de monitoreo. Claude Code construye, n8n ejecuta.
Pero construir flujos de trabajo más rápido es solo la mitad. Tengo 15 flujos de trabajo corriendo en mi instancia de n8n. El mes pasado abrí uno que no había tocado en 3 meses y no tenía idea de qué hacían los 20 nodos del medio. Una llamada MCP y Claude Code puso notas adhesivas en cada nodo explicando qué hace, qué espera, qué se rompe si lo cambias. Solo eso habría valido la pena la configuración. Pero entonces me di cuenta de que podía hacer esto después de cada modificación.
La cosa que edita el flujo de trabajo también documenta el cambio y lo commitea a git con un mensaje que realmente describe lo que pasó. A través de mis tres sesiones de depuración, eso significó 30 commits con capacidad completa de rollback, cero clics manuales de exportar/importar. Intenta hacer eso en la UI de n8n.
Advertencia justa: esta configuración significa que le estás entregando un token de API a una IA que obtiene acceso completo de lectura/escritura a tu instancia de n8n. Lo he hecho en staging y producción. No voy a pretender que eso esté libre de riesgos. En uno de mis flujos de trabajo, Claude Code podía ver la clave API de PrestaShop sentada en texto plano dentro de un nodo Parameters. Útil para verificación directa con curl. Terrible para higiene de credenciales. La gente de seguridad leyendo esto acaba de sentir una perturbación en la Fuerza. Lo siento. La capa MCP no tiene alcance de credenciales hoy.
Argumenté el mes pasado que los CLIs aún superan a MCP para la mayoría de herramientas de agentes de IA. Para agentes de propósito general, aún creo que eso es cierto. Pero para una plataforma específica y bien documentada como n8n? El enfoque MCP estructurado gana. czlonkowski lo demostró.
Tres Momentos de una Depuración Real de Producción
Ejecuto un pipeline de e-commerce para redactedshop.com, un sitio europeo de retail outdoor en PrestaShop 8.2.1. Un proveedor envía un catálogo CSV vía FTP. Un pipeline de n8n lee el CSV, lo parsea en Google Sheets (con detección de variantes asistida por IA vía Gemini), luego crea y actualiza ~265 productos en PrestaShop incluyendo precios, stocks, imágenes, categorías y traducciones en 3 idiomas. Dos flujos de trabajo principales, seis sub-flujos de trabajo, 55 nodos en total.
A través de tres sesiones de depuración en dos semanas, la combo de Claude Code + n8n-MCP manejó problemas que iban desde triviales hasta "¿cómo funcionó esto alguna vez?". Tres momentos destacaron porque cada uno prueba un punto diferente.
El Borrado Silencioso
El nodo update variants prix estaba enviando un PUT a /api/combinations/{id} con solo id, id_product, minimal_quantity, y price. La API de PrestaShop trata un PUT parcial como "reemplaza todo el recurso." Ugh. Cada campo que no envías se vacía. Esto había borrado silenciosamente códigos de referencia y códigos de barras EAN en 140 variantes de producto. Un segundo nodo tenía el mismo patrón Y estaba configurado a executeOnce: true, significando que solo el primer producto se actualizaba. El resto se saltaba completamente.
Claude Code extrajo los datos de ejecución vía MCP, extrajo un ID de combinación específico, hizo un GET en la API de PrestaShop para ver el daño, construyó 4 nodos Code nuevos implementando el patrón GET-antes-PUT, reconectó 4 conexiones en ramas IF, removió la bandera executeOnce, y desplegó los 12 cambios en una llamada n8n_update_partial_workflow. En la UI de n8n, esa secuencia significa: crear nodo, posicionarlo, llenar 6+ campos de configuración, arrastrar cables de conexión, repetir cuatro veces, luego verificar manualmente. Realísticamente 20 minutos de clics cuidadosos. Hecho en una llamada API, verificado en 3 minutos.
Ese fue el bug caro. El siguiente fue barato e irritante.
El Tipo Que No Existía
Google Sheets devuelve product_id: 32210 (un número) cuando una celda tiene contenido, pero product_id: "" (una cadena vacía) cuando no lo tiene. El operador exists del nodo IF de n8n pasa silenciosamente cadenas vacías porque una cadena vacía existe. Solo está vacía.
La coerción de tipos de JavaScript ataca de nuevo. El lenguaje donde [] == false pero [] ? true : false devuelve true. Google Sheets solo lo empeoró.
Tomó 4 commits a través de la sesión para converger en un filtro que funcionara: primero exists falló, luego isNotEmpty se atragantó con números, finalmente gt 0 con typeValidation: loose funcionó.
El inspector de ejecución MCP hizo esto diagnosticable. Mostró la estructura exacta de datos saliendo de cada nodo, lo que inmediatamente reveló el problema de tipos mixtos. Sin acceso programático a datos de ejecución, habría estado haciendo clic a través del inspector de ejecución de la UI de n8n nodo por nodo, entornando los ojos en paneles de salida JSON. Aún así, los primeros tres intentos de Claude Code en la configuración del nodo IF estaban mal. El comportamiento de tipos mixtos de Google Sheets no está documentado en ningún lado. Tuvo que ser descubierto empíricamente. Cuatro commits para arreglar un filtro. Ese es el ritmo real.
Ambos bugs tuvieron finales limpios. El tercero no.
La Prueba Que No Era
Después de arreglar la ruta de actualización de variantes, necesitaba validar la ruta de actualización de productos simples también. Problema: no existía ningún producto simple en el dataset actual de Google Sheet. La solución de Claude Code fue pragmática: ejecutar el JavaScript del nodo Code localmente vía node -e, luego hacer un PUT manual vía curl en un producto conocido para verificar que la transformación XML preservara todos los campos.
Esto valida la lógica regex y XML. NO valida las referencias de expresiones de n8n, el encadenamiento de nodos, o el comportamiento continueOnFail. La solución fue a producción parcialmente sin probar. Lo sé. Claude Code lo marcó. Una prueba completa end-to-end requeriría inyectar una fila de producto simple en Google Sheet, y no he hecho eso aún.
Te cuento esto porque todos los otros artículos sobre Claude Code + n8n te muestran el camino feliz. El camino real incluye una solución que fue en vivo sin una prueba de integración apropiada y un nodo Code que se crasheó en la primera ejecución porque Claude Code siguió su propia documentación de habilidades (que recomendaba retornos envueltos en array) mientras que el validador de runtime de n8n en modo runOnceForEachItem rechaza arrays.
La herramienta más inteligente del cuarto aún necesita una ejecución fallida para aprender las reglas del cuarto.
Por Qué Desactivé Mi Propio Agente de IA
Esa última sección podría sonar como si fuera negativo sobre la combo. No lo soy. Soy negativo sobre la versión donde cada demo termina en el camino feliz y nadie muestra el nodo Code que se crasheó en la primera ejecución. Esa brecha entre demo y producción, cuando la llevas más lejos, es exactamente lo que mató a mi agente.
Construí OpenClaw, un agente de IA multi-modelo corriendo en un VPS de $5. Kimi K2.5 como modelo primario, MiniMax M2.5 como respaldo. La versión original corría en el OAuth de Claude, que Anthropic mató y forzó a todos a claves API pagadas. Ahí fue cuando la economía cambió de "experimento barato" a "decisión presupuestaria real."
Peter Steinberger argumentó que deberías usar modelos frontier o nada. Probablemente tiene razón en el lado técnico, la mayoría de los problemas de OpenClaw venían de modelos que no eran lo suficientemente inteligentes para auto-actualizarse y auto-repararse confiablemente. Un modelo frontier probablemente resolvería eso. Pero Steinberger se unió a OpenAI poco después de decir esto, y los precios de API frontier para un agente no supervisado pueden llegar a $200/día. Para el resto de nosotros ejecutando cargas de trabajo reales en presupuestos reales, tener razón no lo hace asequible.
Desplegué OpenClaw por meses en los modelos más baratos. Luego lo apagué. Como desenchufar una Roomba que sigue chocando contra la misma pared pero con costos de API.
La relación era honesta y brutal: tokens gastados dividido por valor producido era negativo. El agente seguía consumiendo ciclos tratando de actualizarse, arreglar sus propias herramientas, reiniciar procesos fallidos. La solución existe, modelos más inteligentes. El precio no. Lo que el espacio realmente necesita es un sistema CRON inteligente y capacidades reales de auto-herramientas que funcionen sin quemar tokens de nivel frontier. Estoy considerando construir eso yo mismo. Pero ese es un artículo diferente.
Mientras tanto, mis flujos de trabajo de n8n han estado corriendo por meses. Los webhooks disparan. Los CRONs ejecutan. Los productos se actualizan. Los stocks se sincronizan. Las notificaciones se envían. Cero intervención. Cero costo de tokens más allá de la construcción inicial. Los logs de ejecución son auditables, el manejo de errores es determinístico, el hosting es estable.
El 80% de la automatización de negocios es aburrida y nadie en el campo de "los agentes de IA reemplazarán todo" quiere escuchar eso. Son trabajos CRON que disparan a las 6 AM, webhooks que atrapan eventos de Stripe, ramas IF/ELSE que enrutan datos al endpoint correcto. No necesitas un agente que "razone" sobre esto. Necesitas un pipeline que ejecute confiablemente y cueste nada ejecutar.
n8n hace eso.
Claude Code + MCP hace construirlo dramáticamente más rápido. De hecho, déjame poner un número en "dramáticamente": la depuración de PrestaShop que me habría costado una tarde se hizo en 15 minutos. Mi stack corre en una suscripción Claude Max y una instancia n8n auto-hospedada en un VPS de $5. No barato, pero comparado con costos de API frontier para un agente no supervisado corriendo 24/7, es un error de redondeo. Y esa combinación cubre el 90% de los casos de uso para los que la gente piensa que necesita agentes autónomos.
Los agentes no son inútiles. Solo son raros. Cuando genuinamente necesitas razonamiento dinámico que no puede reducirse a un árbol de decisión, ese es territorio de agentes. Todo lo demás es un flujo de trabajo con pasos extra y una factura más grande.
Construí el agente. Escribí los artículos. Le quité el enchufe.
El Framework: Cuándo Usar Qué
Después de ejecutar ambos en producción y matar uno de ellos, así es como decido.
n8n solo maneja más de lo que piensas. Procesos estables y repetitivos. Webhooks, CRONs programados, sincronización de datos entre dos APIs, pipelines de notificación. Cuando una persona no técnica necesita entender qué está corriendo. Cuando necesitas rastros de auditoría y logs de ejecución. Cuando el uptime importa más que la flexibilidad. Mis 5 productos SaaS corren en n8n solo para aproximadamente el 80% de su automatización.
Claude Code solo es la herramienta correcta cuando las cosas no se repiten. Script rápido para transformar un dataset. Prototipo que tirarás la próxima semana. Lógica personalizada tan específica que conectarla en n8n sería sobre-ingeniería. Modo exploración, no modo despliegue.
Ahora la parte interesante. Si estás a punto de pasar 45 minutos arrastrando nodos en la UI de n8n para un flujo de trabajo que ya tienes mapeado en tu cabeza, para. Ese es territorio de Claude Code + n8n vía MCP. Depurando pipelines complejos donde necesitas hacer referencias cruzadas de datos de ejecución con estado de API externa. Migrando o refactorizando flujos de trabajo existentes. Auto-documentando una docena de flujos de trabajo que no has tocado en meses. Y cada vez más, construyendo aplicaciones reales con n8n como backend en lugar de pegar con cinta adhesiva Airtable y Google Sheets en algo que pretende ser una interfaz. No he lanzado un front-end completo de esta manera aún, pero la arquitectura es obvia: Claude Code arma una UI real que habla con webhooks de n8n. App apropiada con un backend apropiado. Eso está siguiente en mi lista.
Y luego están los agentes autónomos de IA. La decisión correcta cuando la tarea requiere razonamiento que genuinamente no puede reducirse a IF/ELSE. Cuando la entrada es lo suficientemente impredecible que no puedes pre-mapear el árbol de decisión. Cuando el costo de tokens está justificado por el valor de la salida. En mi experiencia a través de 5 productos SaaS, esto cubre tal vez el 10% de las tareas de automatización. El otro 90% son flujos de trabajo usando disfraces de agentes 💀 Digo esto como alguien que vistió a su agente con el disfraz más elegante. Aún así no podía bailar.
La misma disciplina aplica aquí como en todas partes: define el contrato antes de dejar que la IA ejecute. Ya sea un contrato de prompt para Claude Code o una especificación de flujo de trabajo para n8n, el patrón es idéntico. Claridad por adelantado, ejecución después.
Última cosa. czlonkowski mantiene n8n-mcp contra cada nuevo release de n8n. Open-source, licencia MIT, sin paywall. Una persona construyó la cosa que hizo posible todo este artículo. Ve a darle estrella al repo. Eso es lo mínimo que le debemos.
El repo: https://github.com/czlonkowski/n8n-mcp
Si esto te salvó de reconstruir algo que ya funciona o de comprar un agente que no necesitas, escribo uno de estos por semana. Automatización de flujos de trabajo, Claude Code en producción, y las cosas que se rompen cuando los tutoriales terminan. Suscríbete si eso te es útil.
¿Esa imagen de portada? La hizo IA. Llegué a mi pico creativo con gradientes CSS en 2017 y mi carrera artística ha estado en declive gestionado desde entonces.
¿Cómo construir flujos de trabajo de n8n sin morir en el intento? Mi newsletter semanal comparte patrones reales de producción con IA, sin rodeos.