Factory Automations: Cómo automatizar tareas de código

Factory anunció el 30 de septiembre de 2026 que sus Automations llegan a disponibilidad general, y la propuesta es tan directa como suena: describir con palabras un trabajo repetitivo de desarrollo y dejar que un agente lo haga cada vez que se cumpla una condición. Si eres de los que cada mañana repite el mismo ritual de revisar pull requests o clasificar errores, esto está pensado exactamente para ti. Aquí te explicamos qué es Factory Automations y en qué se diferencia de un simple script programado.

Qué es Factory Automations en palabras claras

Factory Automations es una función que convierte al agente de código de Factory, llamado Droid, en un compañero de trabajo que se ocupa de las tareas que vuelven una y otra vez. En lugar de lanzar el agente a mano cada vez, defines una automatización y esta arranca una sesión de Droid sola cuando su disparador se activa.

Esa palabra, disparador, es la clave de todo. Puede ser un horario, un mensaje que llega a un canal de Slack, un evento de GitHub o una llamada webhook que envía otro servicio. Eliges cuándo debe empezar el trabajo, escribes las instrucciones que el agente debe seguir, y a partir de ahí se ejecuta sin que tengas que estar delante.

La diferencia con un cron job de toda la vida está en el motor. Un script clásico ejecuta comandos fijos. Droid es un agente de código que razona sobre lo que encuentra: si un pull request cambia una función, el agente entiende el cambio, lo revisa y comenta lo que ve. No es un bot de reglas, es un agente que trabaja sobre el contexto.

Cómo funciona una automatización de Droid

Cada automatización de Factory se arma con los mismos cinco ingredientes, y vale la pena conocerlos porque son los que determinan qué hace y cómo se comporta.

• Disparador. Qué enciende la ejecución: un horario, un mensaje de Slack, un evento de GitHub o un webhook.
• Instrucciones. El texto que Droid sigue en cada ejecución, con un modelo y un nivel de razonamiento opcionales.
• Identidad de ejecución. Quién actúa en cada ejecución: tú, o una cuenta de servicio que comparte el equipo.
• Destino. Dónde trabaja Droid: una máquina de Droid en la nube, tu propia máquina a través de la app de escritorio, o GitHub Actions.
• Visibilidad. Si la automatización es privada o se comparte con la organización, y quién puede abrir las sesiones que genera.

Con esos cinco elementos ya puedes montar casi cualquier cosa. Y hay un detalle que importa si trabajas en una empresa con infraestructura propia: Factory permite conectar máquinas de la propia red mediante Bring Your Own Machine. Se conectan de forma saliente al backend de Factory y no necesitan configurar nada más. Eso lo hace viable en entornos privados, y varias empresas del Fortune 500 ya lo usan en producción.

Ejemplos prácticos de Factory Automations

La mejor forma de entender esta herramienta es ver qué automatizaciones vienen ya hechas. Factory incluye plantillas que solo hay que apuntar a tus repositorios y canales.

Las más útiles para empezar son estas:

• Ticket a PR. Cada 15 minutos, coge un ticket listo de Linear o Jira y lo lleva hasta un pull request abierto.
• Revisor de PR. De lunes a viernes, entre las 9:00 y las 17:00, revisa pull requests nuevos y deja un comentario por commit.
• Resumen diario de estado. A las 9:00 de lunes a viernes, envía un resumen de tus PRs y tickets: qué te necesita, qué espera a otros y qué ha cambiado desde ayer.
• Salud del código. Cada mañana, rota entre auditorías de dependencias, código muerto, huecos de cobertura y documentación desactualizada, dejando un pequeño PR de mantenimiento por ejecución.
• Clasificación de errores. Cada hora, revisa Sentry o Datadog, investiga los errores que importan y abre un PR de arreglo si es seguro.
• Arreglador de bugs desde Slack. Un mensaje en Slack se convierte en ticket, con hipótesis de causa en el hilo y PR de arreglo para cambios pequeños.

Fíjate en el patrón. Casi todas las plantillas hacen dos cosas: recogen información de una herramienta y devuelven un resultado en otra. Ahí está el valor real: el agente une sistemas que normalmente no se hablan entre ellos.

Para quién tiene sentido usar Factory Automations

No es una herramienta para cualquiera, y conviene ser honesto con eso. Está pensada para equipos de desarrollo que ya usan Git, tienen sus tickets en un sistema como Linear o Jira y manejan pull requests a diario. Es, en esencia, automatización desarrollo de software aplicada a las partes que más se repiten. Si ese es tu caso, las automatizaciones quitan de encima parte del trabajo que nadie disfruta: la revisión rutinaria, el resumen de estado, la limpieza de dependencias.

El desarrollador que ya usa los agentes de código de Factory a mano es el candidato natural. Si lanzas al agente cada vez que tienes una tarea, automatizar los casos repetidos es el siguiente paso lógico. El salto está en dejar de pedir y empezar a configurar una vez para que se haga solo.

Para un equipo pequeño, la ventaja está en el tiempo que recupera la persona que antes hacía esas tareas a mano. Para uno grande, en la consistencia: la automatización se comporta igual todos los días, con la misma revisión y el mismo nivel de detalle.

Limitaciones que debes conocer

Como cualquier herramienta de agentes, tiene sus bordes, y es mejor saberlos antes de montar nada.

Factory usa un modelo de autonomía por niveles. Por defecto, el agente empieza en modo de solo lectura y necesita permisos explícitos para modificar archivos, instalar dependencias o tocar sistemas externos. Eso es una protección, pero también significa que una automatización mal configurada puede quedarse corta y no hacer lo que esperabas.

El coste también hay que mirarlo. Las automatizaciones que corren todos los días gastan cómputo, y un flujo que se dispara cada 15 minutos suma muchas ejecuciones al mes. Antes de dejar veinte automatizaciones activas, conviene revisar cuáles aportan de verdad.

Y está el tema de la confianza. Un agente que abre pull requests en tus repositorios necesita que alguien revise lo que hace, sobre todo en las primeras semanas. La automatización no sustituye la revisión humana: la concentra en los cambios que de verdad la necesitan.

Sobre privacidad, si trabajas en un entorno con datos sensibles, la opción de conectar tus propias máquinas es la pieza que hace viable usar esto sin sacar el código fuera de tu red. Merece la pena revisar bien esa configuración antes de activar nada.

Conclusión: automatizar lo que ya sabes hacer

Factory Automations no promete magia: promete quitar de en medio el trabajo repetitivo que ya está resuelto y solo necesita que alguien lo ejecute. Tú describes la tarea una vez, eliges el disparador y el agente la repite cuando toca. Para revisiones rutinarias, resúmenes y clasificación de errores, es una de esas funciones que, una vez montadas, cuesta entender cómo se vivía sin ellas.

Si te interesa probar la idea, lo natural es empezar por una sola automatización. Elige la tarea más pesada de tu semana, móntala, y mira cómo se comporta durante unos días. Cuando veas que funciona, ya tendrás criterio para decidir qué más merece la pena delegar y qué prefieres seguir haciendo tú.