Cuándo tu workflow de n8n ya pide a gritos pasar a código

Construyo bastante en n8n y se gana su lugar. Arrastras tres nodos y ya tienes un webhook que publica en Slack, enriquece una fila en Supabase y manda un correo, todo antes del almuerzo. Pero casi todo workflow útil llega a un punto en el que deja de rendir lo que cuesta: el lienzo que te hacía rápido empieza a frenarte. Esto es un marco de decisión para reconocer ese momento sin engañarte: tres preguntas de diagnóstico que respondes en dos minutos, más el patrón híbrido que uso casi siempre, para que muevas a código los workflows correctos y dejes en paz a los demás.

Quiero que te quedes con un sesgo deliberadamente conservador. Reescribir una automatización que funciona es de las cosas más caras que puedes hacer, y "se ve improvisado" no es una razón. Por eso el marco está pensado para mantener los workflows en n8n salvo que crucen una vara real.

01 · La prueba del vistazo

La primera pregunta es la más barata. Abre el workflow. ¿Entiendes lo que hace en menos de un minuto con solo mirarlo?

Un flujo lineal, disparador, transforma, escribe, notifica, pasa esa prueba siempre. Se lee igual con diez nodos que con tres. Déjalo en n8n. Llevarlo a código no te daría más que archivos extra que mantener y un deploy que vigilar.

El problema empieza con la ramificación. Cada nodo IF y Switch duplica los caminos que el lector tiene que tener en mente a la vez. Dos ramas, bien. Cuatro ramas anidadas con un merge al final son un diagrama que vuelves a dibujar mentalmente cada vez que lo depuras, y el diseño visual, que se suponía que era la documentación, se vuelve justo lo que tienes que descifrar.

Mi umbral aproximado

Más de tres puntos de decisión, o cualquier rama con un bucle que lleva lógica condicional dentro, y el lienzo ya está escondiendo complejidad en vez de mostrarla. Esa es la primera señal real. La pista más clara es cuando te sorprendes abriendo un nodo, leyendo su expresión, cerrándolo, abriendo el siguiente y rearmando mentalmente la forma de los datos nodo por nodo, porque el lienzo ya no te dice qué fluye hacia dónde.

02 · La pregunta de los tests

Esta es la señal que zanja casi cualquier discusión. Pregúntate cómo escribirías un test para el workflow: no darle a ejecutar y revisar el resultado a ojo, sino un test repetible de verdad, que reviente sin disimulo cuando alguien rompa la lógica.

En n8n la respuesta sincera casi siempre es que no puedes, no de verdad. Puedes fijar datos de ejemplo y volver a correrlo a mano. Puedes armar un segundo workflow que llame al primero y revise el resultado. Las dos cosas son parches con cinta adhesiva. Ninguna te da lo que mantiene sano el código durante años: una suite que corres antes de cada cambio y que en segundos te avisa si rompiste algo.

Así que la regla va sobre qué tipo de lógica contiene el workflow:

1. Lógica de negocio que importa: precios, elegibilidad, scoring, cualquier cosa donde una respuesta equivocada cuesta dinero o confianza. Si no puedes escribir un test que falle para eso, con eso basta para justificar la reescritura. Prefiero ochenta líneas de TypeScript con una docena de tests unitarios que un lienzo precioso al que tengo que encomendarme en cada deploy.
2. Código de pegamento: mueve este archivo para allá, avisa a tal canal, copia una fila. No hay nada relevante que verificar. Un test solo confirmaría que n8n sigue hablando con Slack, y eso es trabajo de n8n, no tuyo.

No escribas código por el gusto de poder probar la fontanería. El punto de la pregunta es separar las dos cosas, y la respuesta suele saltar a la vista en cuanto intentas siquiera nombrar qué comprobaría ese test.

03 · La pregunta de las 3 de la mañana

La tercera señal es operativa. Cuando esto se rompa a las 3 de la mañana, ¿puedes responder rápido dos preguntas: qué cambió y cómo lo revierto?

n8n ya tiene historial de versiones y se agradece. Pero no es git. No hay un diff de verdad que leas en un pull request, ni blame sobre una sola expresión, ni manera de abrir una rama para un cambio riesgoso, validarlo en revisión e integrarlo limpio. Y las credenciales y la lógica viven en el mismo lugar, lo que vuelve el workflow más difícil de compartir y de auditar. Como alguien que viene del mundo de la seguridad, esa última parte me incomoda más que el resto: los secretos y la lógica no deberían ir acoplados en el mismo export.

Si un workflow cambia cada semana, si lo toca más de una persona o si una caída sale realmente cara, lo quieres bajo la misma disciplina de revisión y rollback que el resto de tu sistema. Eso significa código en un repositorio. No porque el código sea moralmente superior, sino porque git es el seguro más barato que vas a contratar en tu vida. Un revert limpio y un diff legible a las 3 de la mañana valen más que toda la pulcritud del lienzo junta.

04 · El híbrido es la respuesta de verdad

Esto es lo que hago la mayoría de las veces, y no es ni n8n puro ni una reescritura completa. Deja a n8n como el orquestador y mueve la lógica difícil a un único endpoint de código que él se encarga de llamar.

n8n sigue haciendo lo que sabe hacer: el disparador, los reintentos, la programación, el reparto hacia tres servicios, la aprobación con una persona en el medio. El núcleo complicado, lleno de ramas y testeable, vive en un solo endpoint HTTP, una ruta de Next.js o un servicio pequeño, que tienes como código, con tests, en git.

Un ejemplo real

Tenemos un workflow que procesa las transcripciones de negociación que entran a Proyección, nuestra herramienta para practicar negociación. La orquestación queda muy bien en n8n: un webhook recibe la transcripción, reintenta contra un upstream inestable, ramifica según el tipo de archivo y publica el resultado de vuelta. Pero el scoring, la parte que lee la transcripción y decide qué hizo bien la persona, es lógica de verdad, con casos límite. Eso no tiene cabida en un nodo Set lleno de expresiones.

Así que el workflow hace una sola llamada:

// app/api/score-negotiation/route.ts
import { NextRequest, NextResponse } from 'next/server'
import { scoreTranscript } from '@/lib/negotiation/score'

export async function POST(req: NextRequest) {
  const { transcript, rubric } = await req.json()

  // Toda la lógica ramificada y testeable vive aquí — no en un lienzo.
  const result = scoreTranscript(transcript, rubric)

  return NextResponse.json(result)
}

Y la lógica que invoca es código plano y bien probado:

// lib/negotiation/score.test.ts
import { scoreTranscript } from './score'

test('marca un ancla que nunca fue contrarrestada', () => {
  const out = scoreTranscript(fixtureAnchorIgnored, defaultRubric)
  expect(out.flags).toContain('uncountered-anchor')
})

Ese reparto es justo el punto. n8n es dueño de la forma del proceso: qué pasa, en qué orden, con qué reintentos. El código es dueño de las decisiones: la parte donde equivocarse sale caro. Cada herramienta hace aquello en lo que de verdad es buena, y la unión entre ambas es una aburrida llamada HTTP que puedes leer en un pull request.

Cómo asegurar ese punto de unión

Esa unión es también el nuevo punto de falla, así que pide algo de disciplina:

• Dale al endpoint un nodo HTTP con timeout y un par de reintentos con backoff. La red da hipos; que los absorba el orquestador, no tú.
• Pon un secreto compartido en la llamada (un token en el header que n8n envía y la ruta verifica) para que el endpoint no sea una puerta abierta. Léelo de una variable de entorno; nunca lo dejes fijo en el código.
• Decide el fallback de forma explícita. Si el scoring está caído, ¿la transcripción se encola y reintenta más tarde, o falla a la vista en un canal? Cualquiera de las dos sirve; dejarla caer en silencio, no.

05 · Concesiones honestas y cuándo ni te molestes

El híbrido no sale gratis. Ahora tienes dos sistemas y un salto de red entre ellos. Tienes que manejar que el endpoint se caiga, lo que implica que n8n necesite un reintento y un fallback razonable. Tienes un deploy pequeño que cuidar para la mitad de código. Para un workflow que corre dos veces al día, ese costo no compensa: déjalo todo en el lienzo.

Y no reescribas por gusto. "n8n se ve improvisado" no es una razón. Si el workflow es estable, casi no lo tocas y se lee fácil, lo más caro que puedes hacer es moverlo por comodidad estética. La meta es una automatización que funciona y en la que nadie tiene que pensar, no la arquitectura limpia como fin en sí mismo.

Una forma rápida de no engañarte:

• Reescribe (híbrido): dos o más "no" a las tres preguntas, sobre todo una decisión no testeable que cuesta dinero cuando se equivoca.
• Parte, no reescribas: el único problema es un lienzo que creció de más; divídelo primero en workflows más pequeños.
• Déjalo en paz: pegamento lineal, casi nunca se edita, un solo dueño, barato si falla. La herramienta visual también se ganó su lugar.

La trampa que más veo es el instinto de todo o nada: o todo se queda en el lienzo o todo se vuelve un servicio. El híbrido existe precisamente para que nunca tengas que apostar así. Mueve las decisiones, conserva la orquestación y deja que la aburrida llamada HTTP sea lo único entre ambas.

Corre las tres preguntas la próxima vez que un workflow te saque de quicio. Si cruza la vara, ve por el híbrido antes que por la reescritura completa: conservas la velocidad de n8n donde se la gana y pones tus tests donde está el dinero. Y si no la cruza, la jugada más senior es cerrar la pestaña y dejar en paz lo que funciona.