Tres de cada diez proyectos de automatización que auditamos están fallando o funcionan muy por debajo de su potencial. No fallan por bugs de código ni por herramientas malas. Fallan por decisiones de diseño que sonaban razonables al principio y que pagan intereses durante meses hasta que alguien decide apagarlos. Este post junta los tres patrones que vemos con más frecuencia, por qué suceden, cómo detectarlos, y qué hacer si ya estás adentro.
No son los únicos anti-patterns posibles, pero son los que explican la mayoría de los casos perdidos.
Anti-pattern 1: Automatizar un proceso roto
El anti-pattern más común y el más destructivo. El equipo tiene un proceso que "funciona mal pero funciona", lo odian todos, y viene alguien y propone automatizarlo. Suena a solución: si el proceso es tedioso, que lo haga la máquina. Si la gente se equivoca, que la máquina no se equivoque.
El problema es que los procesos "funcionan mal pero funcionan" porque humanos son infinitamente adaptativos. Ven una excepción, la manejan con criterio, avisan a alguien, hacen un workaround. La máquina no puede hacer nada de eso. Si automatizás un proceso caótico, lo único que lográs es convertir el caos humano (lento pero reparable) en caos automatizado (rápido y que genera 500 registros inconsistentes antes de que te enteres).
Señales de que estás por caer en este pattern:
El proceso tiene muchas "excepciones". Si el dueño del proceso usa la palabra "excepción" más de dos veces en la conversación inicial, desconfiá. Cada excepción es una decisión humana que tu automatización va a tener que tomar de alguna manera, y casi nunca se pueden enumerar todas al principio.
Nadie puede explicar el proceso sin frases tipo "y después depende". Un proceso que depende del criterio del humano que lo ejecuta no está listo para automatizarse. Primero hay que hacerlo reglamentable; después se automatiza.
Diferentes personas lo hacen distinto. Si tres personas del mismo equipo describen el mismo proceso con pasos distintos, el proceso no existe como tal; existen tres versiones ad hoc. Automatizar requiere primero elegir una versión canónica, y eso es un trabajo organizacional, no técnico.
Los errores del proceso actual no tienen consecuencia. Si cuando algo sale mal "alguien lo arregla después", es porque el proceso tiene humanos actuando como red de seguridad. Cuando automatizás, esa red desaparece y los errores empiezan a propagarse.
Cómo evitarlo: antes de automatizar, mapeá el proceso con rigor. Si encontrás zonas grises, resolvelas primero organizacionalmente. Documentá reglas explícitas. Hacé un "dry run" donde alguien sigue las reglas documentadas sin juicio propio durante una semana. Si sobrevive, el proceso está listo para automatizar. Si no sobrevive, ningún sistema lo va a hacer funcionar.
Cómo salir si ya estás adentro: suspendé el workflow problemático hasta resolver las reglas. Volver atrás al proceso manual temporalmente es mucho más barato que seguir automatizando caos. Trabajá las reglas con el equipo que lo ejecutaba antes. Cuando tengas una versión canónica escrita, volvé a activar la automatización.
Anti-pattern 2: El workflow-monstruo
Un único workflow que hace todo. Arranca con una lectura de Sheets, pasa a una llamada a OpenAI, cruza datos, hace tres if's anidados, llama a una API, actualiza Postgres, manda un email, escribe un log, y opcionalmente escala a Slack. Doscientos nodos en una sola cadena. En n8n se ve como un plato de espaguetis que ocupa tres pantallas.
Los workflow-monstruo nacen naturales. El primer día tu workflow hacía una cosa. Después te pidieron agregar una verificación. Después una notificación. Después un caso especial para clientes premium. Después un reporte. Cada adición fue pequeña y razonable. A los seis meses tenés un monstruo que nadie entiende y que nadie quiere tocar por miedo a romper algo.
Los costos del monstruo:
Imposible de debuggear. Cuando algo falla, no es obvio cuál nodo lo causó. El error aparece en el paso 87 pero la causa real está en el paso 12. Diagnosticar un incidente toma horas cuando debería tomar minutos.
Imposible de testear. No podés testear una parte sin correr todo. Los cambios producen miedo. Los cambios con miedo producen parches defensivos que agravan la complejidad. Círculo cerrado.
Imposible de reutilizar. Una parte del monstruo hace algo útil que otro workflow también necesitaría. Pero está enredada con las otras 199 cosas. Terminás copiando la lógica en otro lado y ahora tenés dos versiones que divergen.
Un cambio en cualquier paso rompe todo. Una API upstream cambia su contrato, actualizás el nodo correspondiente, y sin querer rompés un nodo lejano porque pasaba un dato que ahora llega distinto. La fragilidad crece cuadráticamente con los pasos.
Señales de que estás viviendo este pattern:
- El workflow no cabe en una sola pantalla.
- Para entender un workflow nuevo que llega, necesitás más de 20 minutos.
- Nadie quiere modificarlo excepto la persona que lo creó originalmente.
- Los commits recientes son puro parches defensivos ("catch este caso", "skip si el campo X está vacío").
- Nadie puede explicar qué hace el workflow en tres oraciones.
Cómo evitarlo: diseñá con subworkflows desde el principio. Cada subworkflow debería hacer una cosa identificable y ser entendible en un minuto. El workflow principal solo los orquesta. La regla nuestra: si un workflow no cabe en una sola pantalla a zoom normal, es señal de que hay subworkflows esperando ser extraídos.
Cómo salir si ya estás adentro: refactorizar un monstruo es doloroso pero la estrategia que funciona es "extraer por partes". Identificá bloques que hacen una cosa coherente (ej. "todo lo que interactúa con la API de Stripe"). Extraelos a un subworkflow. El workflow principal llama al subworkflow con parámetros definidos. Repetí hasta que el principal quede solo como orquestador. No intentes refactorizar todo de una; dividí en 3-5 extracciones y testeá cada una.
Anti-pattern 3: Dependencia sin fallback
Tu workflow depende de una API externa. Por ejemplo, OpenAI. Durante meses funciona impecable. Un día, OpenAI tiene una degradación de servicio (pasa cada tanto, es normal, tienen incidentes como cualquier cloud). Tu workflow empieza a fallar. Tus usuarios internos notan que "el sistema anda raro". Vos te enterás cuando alguien se queja.
El problema acá no es que OpenAI haya fallado. Es que diseñaste como si nunca pudiera fallar. Toda dependencia externa tiene que estar en tu mapa de riesgos con un plan concreto.
Las tres categorías de dependencia vulnerable:
APIs externas con disponibilidad variable. OpenAI, Claude, las APIs de Google, Stripe, cualquier SaaS. No son infalibles. Tienen incidentes, mantenimientos programados, cambios de contrato. Si tu workflow no puede tolerar un down de 30 minutos, es frágil.
Credenciales que expiran. OAuth tokens, API keys con rotación, certificados SSL. Si alguien configuró un token hace 18 meses y nadie anotó cuándo vence, está por romperse.
Formatos de datos upstream que cambian. Un proveedor cambia su CSV export: agrega una columna, renombra otra, cambia el formato de fecha. Tu parser rompe silenciosamente o genera datos corruptos.
Señales de que tu workflow tiene este pattern:
- No hay un log central de qué dependencias externas usa y qué pasa si cada una falla.
- La última vez que se verificó la validez de las credenciales fue "hace tiempo".
- El workflow no tiene timeout explícito en las llamadas a APIs; asume que siempre responden.
- No hay alerta configurada para "la API upstream tiró 500 más de N veces en la última hora".
- No existe un plan para "si esta dependencia está caída, qué hacemos mientras tanto".
Cómo evitarlo: hacé un mapa de dependencias al momento de diseñar. Por cada dependencia, documentá: qué hace si está caída (falla hard, retry, fallback, modo degradado), cómo te enterás (alerta automática), y qué intervención manual requiere. Configurá retries con backoff y circuit breakers donde aplique. Cuando sea posible, diseñá caminos de fallback: si OpenAI está caído, ¿podemos derivar a Claude temporalmente? Si el API principal está caído, ¿podemos encolar los items y procesarlos cuando vuelva?
Cómo salir si ya estás adentro: auditá los workflows activos e identificá las dependencias externas de cada uno. Para las más críticas, agregá en este orden: (1) alertas si la dependencia falla, (2) retries con backoff, (3) plan manual documentado para cuando sí cae, (4) si es posible, modo degradado automático. No necesariamente tenés que resolver todo al mismo tiempo, pero sabiendo qué está expuesto podés priorizar.
Por qué estos tres son tan comunes
No son errores de gente inexperta. Los tres pasan en proyectos de todos los niveles porque las causas son estructurales:
Automatizar un proceso roto sucede porque el pedido inicial del cliente suele ser "automatizá esto" y no "ayudame a resolver si esto es automatizable". El implementador técnico responde al pedido literal, no al pedido correcto.
El workflow-monstruo sucede porque los pedidos de cambio siempre son chicos. Nadie pide "refactor completo"; piden "agregá este caso". Sin disciplina proactiva, la complejidad crece sin freno.
Dependencia sin fallback sucede porque al inicio las dependencias funcionaban y no hubo ningún incidente. La tranquilidad del "no pasó nada" se confunde con diseño robusto. Cuando ocurre el primer incidente es tarde.
Detectarlos tempranos requiere intencionalidad. No es algo que emerja naturalmente del trabajo; hay que buscarlo activamente.
La señal general: "si duele cambiarlo, está mal diseñado"
Un resumen útil que usamos internamente: cualquier workflow en el que "cambiar algo da miedo" está sufriendo uno de estos tres anti-patterns o una combinación. El miedo al cambio es el síntoma. La causa es siempre estructural.
Un workflow bien diseñado se cambia con confianza. Un subworkflow se reemplaza sin tocar el resto. Una dependencia se sustituye por otra sin reescribir todo. Si tu primera reacción al pedido "cambiá este workflow" es "uy, eso va a ser complicado", estás frente a deuda técnica que probablemente caiga en alguno de estos tres patrones.
Cómo los prevenimos nosotros
En nuestros proyectos, tres prácticas concretas que atacan estos anti-patterns:
Revisión del proceso antes del diseño. Nunca arrancamos a armar workflows sin mapear primero el proceso y detectar si está listo para automatización. A veces la primera semana del proyecto es 100% organizacional, sin escribir una línea técnica.
Subworkflows desde el día 1. Cada dominio del sistema (extracción, validación, notificación, persistencia) vive en su subworkflow con contrato claro. El workflow orquestador es corto por diseño.
Mapa de dependencias explícito. Documento corto por proyecto que lista cada API, cada credencial, cada formato de datos externo, y el plan si cada uno falla. Se actualiza cada vez que agregamos una dependencia nueva.
Ninguna de estas prácticas es opcional. Los proyectos que las saltean al principio las tienen que agregar después cuando ya hay deuda acumulada, y el costo es mucho más alto.
El punto
Los proyectos de automatización que fracasan rara vez lo hacen por decisiones técnicas pobres. Fracasan por decisiones de diseño tomadas sin fricción, bajo presión, o con la intención correcta pero sin proceso. Estos tres anti-patterns son los más comunes y los más identificables. Conocerlos no garantiza evitarlos, pero da lenguaje para detectarlos tempranos. Y cuando aparecen, intervenir pronto es órdenes de magnitud más barato que vivir con ellos.