La mayoría de las herramientas de feedback te permiten «configurar reglas»: rellenas condiciones, eliges acciones, haces clic en guardar. Funciona, pero tiene un techo: las reglas son estáticas, el negocio no deja de cambiar y un proceso que configuraste pronto se queda atrás. Uno de los giros diferenciadores de Loopback es elevar la «configuración» a «evolución»: ese es el Coding Loop (también llamado Modo Builder).

De «configurar reglas» a «describir un objetivo»

Cuando creas un flujo de trabajo, no tienes que ir haciendo clic en un montón de menús desplegables de condiciones. Describes el objetivo en lenguaje llano —por ejemplo, «negativo relacionado con reembolsos → asignar al equipo de pagos y redactar una disculpa»— y haces clic en «Generar borrador»; el borrador aparece en el chat de IA de la derecha. A partir de ahí lo refinas en la conversación:

  • Haz clic en «Editar» para cambiarlo en lenguaje natural, por ejemplo «cuenta también las valoraciones de menos de 3 estrellas».
  • Haz clic en «Siguiente» para pasar a la revisión previa a la publicación.
  • Una vez que la supera, haz clic en «Publicar» para activarlo.

Junto con la IA, estás escribiendo una pieza de lógica de gestión, no rellenando un formulario. De ahí viene el nombre «Coding Loop»: iterar sobre un proceso como iterarías sobre código, solo que en lenguaje natural.

Dos controles antes de publicar

Un proceso ejecuta acciones automáticamente, por lo que hay una revisión antes de que entre en producción:

  1. Comprobación de dependencias: ¿un canal que el proceso necesita notificar (Feishu, por ejemplo) aún no está conectado? Te sugiere conectarlo primero, eliminar ese paso o cambiar a un canal ya conectado.
  2. Reproducción de impacto: las acciones que se ejecutarán automáticamente (asignar / escalar / cerrar / cambiar prioridad) requieren tu autorización explícita, y obtienes una reproducción sobre los últimos 30 días de historial: si este proceso ya hubiera existido, con cuántos elementos habría coincidido y cuántas acciones habría activado. Así puedes juzgar si el alcance es razonable antes de la publicación.

Límites de seguridad infranqueables

«Evolucionar» no significa «automatización sin control». El sistema tiene algunas restricciones que nunca pueden cruzarse:

  • Nada de respuestas salientes totalmente automáticas: un borrador de respuesta debe ser confirmado por una persona antes de enviarse.
  • Nada de cerrar automáticamente una P0.
  • Mantén cada proceso en 1–4 reglas acotadas; no se recomienda meter toda tu lógica en un solo proceso.

Un proceso activo puede pausarse / reanudarse en cualquier momento; seguir editándolo crea una nueva versión, la versión anterior se archiva automáticamente y solo una versión de un proceso dado está activa a la vez.

Por qué las arquitecturas tradicionales no pueden llenar este vacío

Antes de que existieran los agentes de código, hacer que un proceso iterara sobre sí mismo significaba o bien un equipo de ingeniería escribiendo scripts (no reutilizables, y hay que asignar personal para ello) o bien que sencillamente no se podía hacer. El SaaS de tickets tradicional está diseñado en torno a «personas que configuran reglas» y no puede añadir la capa en la que «la IA lo escribe por ti y sigue aprendiendo». El Coding Loop convierte en producto «la flexibilidad de construir tus propios scripts»: flexible, pero sin tener que mantener a un equipo de ingeniería para su mantenimiento.

Los planes difieren en la concurrencia del bucle de Builder (Pro permite 1 ejecución concurrente, Max es ilimitado). La forma más rápida de experimentarlo es iniciar una prueba gratuita para una prueba de Max de 7 días: la prueba te da el bucle de Builder completo. También puedes empezar leyendo Plantillas de flujos de trabajo para aprender el camino a partir de una plantilla.