¿Agente de IA o n8n? Mi regla simple para elegir
Mike Codeur
Claude Code mató al no-code. Los agentes de IA mataron a la automatización clásica. Lo repetimos desde hace meses y, en general, es cierto.
Construyo mis SaaS con Claude Code. Ejecuto OpenClaw y Hermes en tareas que cableaba en Make hace dos años. El movimiento de fondo es real: los expertos en no-code vuelven al código, y los flujos visuales están siendo reemplazados por lenguaje natural.
Salvo que conservé n8n. Y no por nostalgia.
Por qué ganaron el no-code y la automatización
Antes de la IA, el desarrollo era el cuello de botella. Lento y caro. Un MVP costaba decenas de miles de euros y tardaba meses.
Dos familias de herramientas explotaron al mismo tiempo para sortear ese problema:
- No-code de producto: Bubble, Webflow, Airtable, Glide. Construye tu aplicación sin escribir código.
- Automatización: Zapier, Make, n8n, Pipedream. Conecta tus herramientas sin escribir scripts.
No ganaron porque fueran técnicamente mejores. Ganaron porque el desarrollo era demasiado lento.
Esto importa, porque si desaparece la razón de su victoria, su ventaja desaparece con ella.
Lo que cambió del lado del producto
Claude Code no es un autocompletado. Es un agente que trabaja dentro de tu repositorio: lee el proyecto, modifica archivos, ejecuta comandos, lee los errores y se corrige.
En la práctica, el desarrollador recupera lo único que el no-code tenía realmente a su favor: la velocidad. Una landing con formulario de captura son noventa segundos de prompt en lugar de treinta minutos de arrastrar y soltar.
Salvo que al final tienes lo que Bubble nunca te dio:
- un repositorio Git real, con historial
- pruebas
- una arquitectura que eliges tú
- alojamiento libre
- la posibilidad de irte sin reescribirlo todo
Antes el no-code decía «voy más rápido que tú». Hoy el desarrollador responde «yo también, y al final tengo un producto de verdad».
Lo que cambió del lado de la automatización
Make y Zapier se basan en el mismo principio: cableas tu flujo nodo por nodo, a mano. Doce nodos para una lógica que habrías descrito en una frase.
Con un agente, escribes justamente esa frase. «Ordena mi correo: archiva el spam, responde a los mensajes de bienvenida, asigna las solicitudes de colaboración.» El agente hace el enrutamiento, la decisión, la acción y la iteración por su cuenta.
La diferencia de fondo no es la sintaxis, es la comprensión. Un escenario de Make aplica patrones que cableaste de antemano. Un agente entiende el contexto, incluidos los casos que no habías previsto.
Para todo lo que es personalizado y algo inteligente, el agente gana. Con claridad.
La trampa del precio cuando funciona
Casi todas estas herramientas comparten algo: la facturación por uso. Por operación en Make, por unidad de carga en Bubble, por registro multiplicado por asiento en Airtable.
Empiezas con unos pocos euros al mes. Luego tu producto funciona, el volumen sube y la factura sigue la misma curva. Puedes acabar pagando cientos de euros mensuales por una lógica que habrías alojado tú mismo por una fracción.
Un proyecto en código propio sobre Vercel y Supabase se mantiene bastante plano cuando el volumen crece. La curva no se dispara.
El no-code te castiga justo en el momento en que tu producto empieza a funcionar. Es exactamente lo contrario de lo que quieres.
Dónde está la verdadera línea
El debate ya no es no-code contra código. Está en otro lugar:
estocástico contra determinista
Un modelo de lenguaje es estocástico. Mismo prompt, mismo contexto, el resultado puede variar de una ejecución a otra. Puedes acotarlo con reglas y ejemplos: reduces la varianza, no la eliminas.
Para la gran mayoría de lo que le pido a un agente, esa varianza es una fortaleza. Es justo lo que compro: la capacidad de gestionar un caso particular que no había anticipado.
Para el resto, es un riesgo que no asumo.
Lo que nunca delego a un agente
Hay flujos donde un resultado distinto no es una adaptación inteligente, es un incidente:
| Flujo | Por qué no un agente |
|---|---|
| Webhooks de Stripe, cobros | Un pago mal procesado es un incidente contable, no una variación |
| Sincronización de CRM | Un dato de cliente duplicado o perdido contamina toda la cadena comercial |
| Registros de cumplimiento y RGPD | Debes poder probar que el tratamiento fue idéntico cada vez |
| Cualquier proceso crítico recurrente | Si el resultado cambia, ya no puedes depurar |
Estos flujos necesitan tres cosas que un agente no garantiza: un resultado reproducible, una ejecución observable y reintentos previsibles.
Esa es la definición de un motor de workflow. n8n, pero también Temporal o Airflow según la escala.
Ahí se entiende por qué n8n sobrevive donde Make y Zapier retroceden: n8n nunca fue no-code para no desarrolladores. Es un motor de workflow para desarrolladores, autoalojable, versionable, con registros aprovechables. No es la misma categoría de producto.
Mi stack en 2026
Ya no elijo entre ambos. Los apilo.
Capa de inteligencia, estocástica. Claude Code, Cursor, los agentes OpenClaw y Hermes. Para todo lo que exige entender el contexto y decidir.
Capa de producto. Next.js, Supabase, Stripe, Vercel. El repositorio propio, el que escala sin que la factura se dispare.
Capa de flujos críticos, determinista. n8n autoalojado. Para todo lo que debe producir exactamente lo mismo en cada ejecución.
Airtable, Notion y Make siguen siendo herramientas de apoyo. Útiles puntualmente, nunca una base.
La regla
Si solo retienes una cosa:
- ¿El flujo debe producir un resultado idéntico en cada ejecución? Motor de workflow, es decir n8n.
- ¿El flujo debe entender el contexto y decidir? Agente de IA.
- ¿Es el producto en sí? Código, escrito con Claude Code.
El error en 2026 no es elegir n8n en lugar de un agente. Es creer que hay que elegir.
Desarrollo cada punto con demostraciones en pantalla en el vídeo: Agente IA o n8n, mi regla simple