n8n para lo fácil, código para lo que no puede fallar

El espejismo de "si funciona en el lienzo, funciona en producción"

Llevo tiempo viendo el mismo error: alguien monta cuatro nodos en n8n, conecta un webhook con un CRM, ve que el flujo verde se ejecuta sin fallar y se cree que acaba de hacer ingeniería de software. No la ha hecho. Ha automatizado una tarea. Son cosas distintas y la diferencia se paga cara justo cuando menos te lo esperas.

No es que n8n sea una mierda. Es que confundir "esto funciona en la demo" con "esto aguanta en producción" es la forma más rápida de que un domingo a las tres de la mañana te llame alguien preguntando por qué se han duplicado 400 pedidos.

Dónde n8n gana sin discusión posible

Para lo lineal, n8n es la herramienta correcta y no hay debate. Conectar dos SaaS con un solo nodo, activar un trigger cuando llega un webhook, mover un dato de un sistema A a un sistema B: eso son minutos de trabajo en vez de días escribiendo un cliente HTTP, gestionando autenticación y montando un servidor que escuche peticiones.

Si tu caso de uso es "cuando entre un lead en Typeform, mándalo a Notion y avisa por Slack", escribir código para eso es perder el tiempo. Ahí el low-code cumple su promesa: menos fricción, menos superficie de mantenimiento, y cualquiera del equipo puede tocarlo sin saber programar.

El problema no es la herramienta. El problema es cuándo dejas de usarla para lo que sirve y empiezas a estirarla hasta que se rompe.

El momento exacto en que el lienzo se rompe

La lógica lineal ("si pasa X, haz Y") no tiene fricción en un editor visual. La lógica con estado sí. Y aquí es donde la mayoría de gente que monta workflows en n8n no tiene ni idea de en qué charco se está metiendo.

Piensa en una máquina de estado real: un pedido que pasa de "creado" a "pagado" a "en preparación" a "enviado", con transiciones que pueden fallar en cualquier punto y que necesitan volver atrás sin corromper el resto del proceso. O en reintentos con backoff exponencial: si una API externa falla, no quieres reintentarlo cada segundo hasta tumbarla; quieres esperar 1s, luego 2s, luego 4s, luego 8s, con un límite de intentos y una alarma si se agota.

Añade validación de payloads que llegan rotos (porque en el mundo real los JSON llegan con campos que faltan, tipos que no cuadran o codificaciones raras), el "parking" de esos mensajes fallidos para poder reprocesarlos más tarde sin perderlos, y observabilidad de verdad: logs estructurados, trazas, métricas que te digan en qué nodo exacto reventó el proceso y con qué dato.

Nada de eso es imposible en n8n. Pero cada pieza que añades al lienzo para simular ese comportamiento es una capa extra de nodos, condicionales anidados y variables globales que nadie del equipo, ni siquiera quien lo montó hace tres meses, va a poder depurar de un vistazo. Python, con su de librerías para colas, reintentos, testing y logging, te da control real sobre cada una de esas piezas. No es que sea "mejor" en abstracto: es que resuelve problemas que el lienzo visual no está diseñado para resolver.

Y aquí conviene ser justo con n8n: no es que esté cerrado a código. Tiene nodos de Function y Code donde puedes meter JavaScript o Python a pelo, y puede llamar a servicios externos con la lógica que haga falta. La dicotomía "n8n o código" es en parte falsa: en la práctica, muchos equipos que hacen esto bien no eligen uno u otro, montan un híbrido. n8n se queda como capa de orquestación de alto nivel (el mapa de qué pasa después de qué) y la parte con estado, los reintentos, la validación fina, se saca a un microservicio en Python al que n8n solo llama. El lienzo no desaparece, se queda con el trabajo para el que sirve; lo que cambia es que dejas de pedirle que haga de motor de estados él solo.

Un caso con números reales, no una opinión

No hay estudios que comparen n8n contra código puro para lógica compleja, ni cifras sobre coste de mantenimiento a largo plazo de uno contra otro. Quien te diga que tiene ese dato, miente. Pero sí hay un caso que enseña lo que pasa cuando la disciplina de ingeniería se toma en serio, sea cual sea la herramienta.

Hexploits montó la plataforma de orquestación multiagente de swarmd.ai en seis meses: un 75% por debajo de presupuesto y un 75% por delante del plazo. No fue magia ni un framework milagroso.

Usaron policy-as-code evaluado por un motor de políticas con versiones inmutables, de forma que cada auditoría se puede reproducir contra las reglas exactas que estaban activas en ese momento exacto, no contra la versión actual de las reglas. Eventos con hash encadenado y entrega transaccional, para que una escritura de negocio y su registro de auditoría vivan o mueran juntos (si uno falla, el otro no queda huérfano contando una historia distinta). Y seguridad en cada capa: mTLS entre servicios, tokens con alcance limitado en vez de credenciales todopoderosas, cifrado aplicación y aislamiento por fila entre clientes, para que un backup robado no le sirva a nadie de nada.

Un detalle importante: ese caso no metía modelos de IA generando nada dentro del pipeline. Era enforcement determinista de reglas, código que hace exactamente lo que dice que hace, siempre. Cuando entra un modelo generativo en la ecuación, la cosa se complica de otra manera.

Cuando el que decide no es código, sino un modelo

Pearl Enterprise evaluó a GPT-5.5 para tareas de negocio y encontró un 72,7% de alineación general con expertos humanos. La media suena aceptable hasta que la desglosas: 80,9% en negocio, 68,8% en salud y solo 62,1% en mascotas. La media esconde exactamente dónde el modelo se cae, y esa es la trampa de fijarte solo en el número redondo de arriba.

El CEO de Pearl lo resumió mejor de lo que yo podría: un estudiante de aprobado raspado que sabe que va justito se maneja bien, porque pide ayuda cuando duda. El que va justito y está convencido de que es un sobresaliente, y responde con total confianza a todo lo que le preguntan, es el que mete a la empresa en un lío. Ese es el problema real de meter un LLM en un flujo de decisión: no falla siempre, falla con la misma seguridad con la que acierta, y tú no sabes distinguir un caso del otro sin revisión humana.

Aquí conecta con algo que ya hemos desmontado antes: el problema de fondo no es que el modelo "razone mal", es que el prompt no controla lo que hace el agente en producción (lo que controla el comportamiento real es la estructura que rodea al modelo, las validaciones, los límites y quién revisa el resultado antes de que impacte en algo real).

El código generado por IA no es gratis tampoco

Y ojo, porque esto no es "n8n mal, código con IA bien". Si sustituyes el lienzo visual por un asistente de IA que te escribe el código de la lógica compleja, el riesgo no desaparece, cambia de forma.

Un informe de CodeRabbit de diciembre de 2025 encontró que el código generado por IA tenía un 70% más de errores que el escrito por humanos, y que esos errores eran más graves. Es un dato de hace meses en un campo que cambia rápido, así que tómalo como fotografía de un momento concreto, no como verdad eterna. Pero el patrón de fondo que describe David Loker, de CodeRabbit, sigue siendo relevante: los sistemas de codificación con IA duplican funcionalidad porque no reconocen que una función ya existe, y eso genera lógica de negocio inconsistente repartida en varios sitios a la vez. Es deuda técnica que se acumula sin que nadie la vea venir.

Jack Cable, CEO de Corridor, lo pone en términos de superficie de ataque: aunque la IA escriba mejor código línea a línea, el volumen que produce (hasta 20 veces más) exige mucha más revisión, y más complejidad significa más vulnerabilidades. No es determinista: no significa que todo código generado por IA termine en un agujero de seguridad. Significa que el riesgo sube y que revisar menos porque "la IA ya lo hizo bien" es la forma más tonta de perder ese margen.

Los investigadores de Georgia Tech lo están midiendo con el Vibe Security Radar: más de 70 vulnerabilidades críticas de software probablemente originadas por código escrito con IA desde agosto de 2025, con un salto notable en los últimos dos meses, a fecha de abril de 2026. Si quieres ver cómo se traduce esto en negocio real, ya lo contamos con detalle al hablar de las apps montadas en tres horas con IA que luego revientan en producción: la velocidad de escritura no es el problema, la falta de revisión sí.

Ni siquiera el low-code está libre de líos de seguridad

Y no, tampoco es que n8n sea intrínsecamente inseguro. Desde octubre de 2025, Cisco Talos ha documentado campañas de phishing que abusan de webhooks de n8n bajo subdominios *.app.n8n.cloud para colar malware o hacer fingerprinting de dispositivos. En marzo de 2026 los correos con URLs de webhook de n8n se dispararon un 686% respecto a enero de 2025, según los mismos datos de Talos.

Una campaña concreta usaba enlaces de webhook de n8n en correos de "documento compartido" falsos: al hacer clic, la víctima llegaba a un CAPTCHA, y al resolverlo se descargaba un ejecutable o instalador MSI que desplegaba versiones modificadas de herramientas RMM legítimas (Datto, ITarian) para mantener acceso persistente. Otra técnica, más silenciosa, mete píxeles de rastreo invisibles: al abrir el correo se dispara una petición HTTP GET al webhook con parámetros como el email de la víctima, y así el atacante confirma quién abrió el mensaje.

La cuestión aquí no es que la plataforma tenga un fallo de diseño. Es phishing e ingeniería social combinados con la confianza que la gente deposita en un dominio que parece legítimo. Pero el aviso vale para cualquier herramienta de automatización, incluida la tuya: si tus webhooks son públicos y no validas de dónde vienen las peticiones, alguien va a intentar usarlos en tu contra tarde o temprano.

¿Y las rutinas de Claude, entonces?

Anthropic metió otra pieza en el tablero el 14 de abril de 2026 con Claude Code routines: un servicio en la nube para automatizaciones programadas o disparadas por eventos, que corre en infraestructura de Anthropic, soporta conectores y está disponible en los planes Pro, Max, Team y Enterprise con límites diarios de ejecuciones (5, 15 y 25 según el plan).

No son cron jobs de toda la vida ni agentes autónomos con memoria persistente: son algo intermedio. Lanzan un prompt a un modelo con un horario o un disparador, pueden tomar acciones dinámicas según el contexto, pero son de vida corta y sin estado propio entre ejecuciones. Son útiles para cosas como verificar un deployment o triar alertas, no para sustituir ni a n8n ni a código propio: resuelven un problema distinto, el de tener un modelo haciendo comprobaciones puntuales sin montar infraestructura propia para ello.

No hay datos públicos sobre lo fiable que es esa infraestructura en el día a día, así que tampoco vale venderlo como la solución definitiva. Es una opción más en el mapa, con sus límites de ejecuciones diarias bien marcados, no un salvavidas universal.

El criterio que de verdad importa

Si tuviera que resumir la línea divisoria en una frase sería esta: usa n8n cuando el fallo cuesta un reintento manual, y escribe código cuando el fallo cuesta dinero, datos o confianza que no se recupera con un clic. La automatización rápida y barata está bien para lo reversible; para lo que no lo es, hace falta control real.

Y hay una tercera pata que ni el low-code ni el código puro resuelven solos: cuando el que decide es un modelo de IA, no una regla determinista, hace falta un humano en medio. Varun Badhwar, de Endor Labs, lo deja claro: todo lo que toque dinero, seguridad o decisiones difíciles de revertir necesita ese humano en la cadena, por muy seguro que parezca el modelo sobre su propia respuesta.

Nadie te va a dar una tabla mágica con porcentajes que digan "a partir de aquí, código; antes de aquí, n8n". No existe ese dato y quien te la venda te está vendiendo humo, como cuando alguien promete que puedes automatizar tu empresa entera en 24 horas. Lo que sí existe es la pregunta que te tienes que hacer antes de montar el flujo: si esto falla a las tres de la mañana, ¿alguien se entera a tiempo y sabe exactamente qué pasó? Si la respuesta es "ni idea", ya sabes qué herramienta no es.