Factory AI: precios, Droids y cuándo conviene usarlo

¿Qué es Factory AI?

Factory es una plataforma de desarrollo de software cuyos agentes, llamados Droids, pueden examinar un repositorio, proponer un plan, modificar archivos, ejecutar comprobaciones y preparar una pull request: el conjunto de cambios que se revisa antes de integrarlo en el código. Se utilizan desde una terminal, un entorno de desarrollo integrado (IDE) o las interfaces de escritorio y web de Factory. El «desarrollo centrado en agentes» consiste en encargar un resultado y revisar el trabajo entregado, en lugar de pedir cada modificación por separado. El producto es una capa que reúne modelos y herramientas de desarrollo; no es un nuevo lenguaje de programación ni un modelo que debas entrenar. La página de producto de Factory describe ese alcance.

Verificado el 21 de octubre de 2026, con los precios y la documentación vigentes de Factory. Este análisis se basa en documentación e incluye ejemplos desarrollados y cálculos de costos; no presenta pruebas comparativas de programación ni una evaluación de uso directo.

¿A quién le conviene Factory y quién debería seguir con su agente actual?

Factory encaja con responsables de ingeniería que quieren un proceso común para delegar tareas entre desarrolladores que usan distintos editores, o que desean cambiar de proveedor de modelos sin reconstruir cada flujo de trabajo. Resulta menos atractivo para quien ha fundado una empresa y ya tiene un agente que trabaja con el repositorio, las pruebas y el proceso de revisión con poca supervisión.

Las alternativas más directas son Claude Code, de Anthropic, su agente de desarrollo; Codex, de OpenAI, su agente de programación; y Cursor, un editor y una plataforma de agentes. La comparación útil es qué cambia cada compra en la forma de trabajar.

Estos son criterios de compra, no posiciones en una clasificación de rendimiento. Claude Code, Codex y Cursor ya van más allá de una ventana de chat o una terminal. Tener varias interfaces no basta para que Factory sea la mejor opción.

Factory AI frente a Claude Code

Vale la pena considerar Factory si quieres que los modelos Claude sean una opción dentro de un flujo de trabajo más amplio. Claude Code es la elección más sencilla cuando la organización ya cuenta con instrucciones, integraciones y prácticas de revisión que funcionan bien con él. Ejecutar un modelo Claude dentro de Droid no equivale a usar Claude Code: las herramientas que lo rodean, la selección de contexto y la forma de ejecutar las tareas dependen del producto que implementa el agente.

Por ejemplo, un responsable con desarrolladores de backend en JetBrains y de frontend en Cursor podría incorporar Factory para gestionar una cola común de tareas de mantenimiento. Es un motivo coherente para añadirlo. Pedir que todos cambien porque otro modelo produjo una demostración impresionante no lo es.

Deja Factory para más adelante si el principal problema son requisitos imprecisos, pruebas poco fiables o una cola de pull requests que nadie revisa. Esos problemas también limitan a Droids. Mantén Claude Code, Codex o Cursor mientras haces que el trabajo sea más fácil de verificar. La comparación entre Codex y Claude Code aborda esa decisión concreta; la selección de agentes de IA para programar cubre un abanico más amplio.

El análisis que sigue se apoya en cuatro criterios: calidad del contexto, control de la ejecución, continuidad entre interfaces y costo de lograr que un cambio sea aceptado.

Factory AI Droid: conserva tu editor y define bien el trabajo

Factory Droid puede funcionar dentro del editor que ya usas, lo que permite hacer una prueba piloto sin migrar de editor. En VS Code, Cursor y Windsurf, la integración aporta el archivo activo, el texto seleccionado, los archivos abiertos y los diagnósticos, es decir, los mensajes de error y advertencia del editor. También permite ver las diferencias de código de forma nativa. Ejecuta droid en la terminal integrada y luego usa /ide para comprobar la conexión. La documentación de Factory sobre IDE explica la configuración.

Imagina que una responsable de backend va a cambiar cómo valida una aplicación los permisos de las cuentas. El encargo útil no es «refactoriza la autorización», sino identificar todos los puntos de llamada, conservar el comportamiento para los usuarios actuales, proponer la secuencia de migración e indicar qué pruebas detectarían un cambio accidental de privilegios.

Esa descripción delimita el trabajo del agente y ofrece a quien revisa criterios para rechazarlo. Un conjunto amplio de cambios no demuestra por sí solo que la migración sea correcta.

¿Cómo trabaja Factory AI a partir de una especificación?

El Spec Mode de Factory separa la investigación y la planificación de la implementación. Lee el contexto pertinente y propone un plan antes de pedir aprobación; en la CLI, Shift+Tab alterna entre los modos Normal y Spec. El nivel de autonomía es un ajuste independiente que determina qué acciones pueden ejecutarse sin otra confirmación. La documentación sobre los modos deja clara esta diferencia.

Para la migración de permisos, empieza en Spec Mode y exige que el plan identifique los archivos afectados, los supuestos de compatibilidad y los pasos de verificación. Rechaza cualquier plan que proponga cambiar las reglas de acceso sin explicar cómo conservará el comportamiento actual. Aprueba la implementación cuando esas decisiones estén claras.

Una secuencia práctica sería:

1. Pide a Droid que localice los puntos de entrada de la autorización y las pruebas pertinentes.
2. Solicita un plan que conserve el comportamiento actual e identifique los requisitos que aún no estén claros.
3. Revisa el plan y elige un nivel de autonomía adecuado para el trabajo permitido.
4. Examina las diferencias de código y los resultados de las pruebas antes de abrir o aceptar la pull request.

La ventaja es contar con un punto de revisión antes de que el agente genere mucho código. La limitación es que un plan convincente también puede estar equivocado. Los criterios de aceptación deben cubrir el comportamiento, no solo la existencia de pruebas.

Hay además una salvedad según el editor: Factory documenta que su integración con JetBrains no comparte automáticamente archivos abiertos, selecciones, diagnósticos ni diferencias de código nativas de Droid. Al desplegarlo en un equipo con varios editores, hay que contemplar esa diferencia en vez de asumir que la experiencia de VS Code se repite en todos.

Cambia de modelo sin reconstruir el flujo de trabajo

Factory permite elegir entre distintas familias de modelos manteniendo la interfaz de Droid y la estructura de las tareas. Esto resulta útil para equipos que buscan una forma común de delegar trabajo sin vincular todos sus procesos a un único proveedor de modelos.

El catálogo vigente de modelos de Factory incluye, entre otros:

• Claude Opus 5.5 y Claude Sonnet 5.5, de Anthropic.
• GPT-6.1 Sol y GPT-6 Astra, de OpenAI.
• Gemini 3.1 Pro, de Google, y Grok 4.7, de xAI.
• Modelos abiertos como Mistral Large 4, Kimi K3 y DeepSeek V4.1 Flash.

Es una muestra de los modelos compatibles, no una clasificación por calidad ni una garantía de que las políticas de todas las cuentas permitan usarlos todos.

Piensa en una cola de actualizaciones de dependencias. Asigna a cada modelo candidato el mismo cambio, las mismas instrucciones de prueba y la misma definición de tarea completada. Registra si termina la actualización, si supera las comprobaciones y cuánta intervención necesita de quien revisa. Un modelo que exige menos supervisión puede justificar un consumo mayor; uno más barato que deja pruebas fallidas una y otra vez quizá no.

La comparación debe mantener constantes la tarea y el entorno. Si cambias a la vez el modelo, las instrucciones del repositorio y el nivel de autonomía, el resultado será imposible de interpretar. El catálogo de Factory incluye distintos multiplicadores de uso y ajustes de razonamiento, de modo que «el mismo número de prompts» no permite comparar el consumo de forma fiable.

Bring your own key (BYOK) significa configurar tus propias credenciales del proveedor de modelos o un endpoint compatible. Factory admite modelos personalizados de uso personal, incluidas configuraciones locales, pero su documentación sobre BYOK establece una limitación importante de portabilidad: esos modelos personales están disponibles en la CLI y la aplicación de escritorio, pero no en las interfaces web o móvil alojadas por Factory.

La consecuencia para la compra es concreta. Factory puede reducir el esfuerzo necesario para cambiar de modelo dentro de un flujo de trabajo, pero hay que comprobar que el modelo deseado esté disponible en la interfaz donde se ejecutará la tarea. Un piloto con un modelo local no valida automáticamente la delegación desde la web.

Revisa el trabajo delegado desde el escritorio y la web

La aplicación de escritorio de Factory resulta útil cuando necesitas inspeccionar visualmente el resultado junto a la conversación. Su página de producto enumera vistas previas de diferencias de código, documentos, presentaciones, hojas de cálculo, PDF y sitios web en funcionamiento, además de comentarios vinculados a líneas de código o elementos seleccionados. Está disponible para macOS y Windows. Factory Desktop también describe la continuidad de las sesiones entre escritorio, web, móvil y CLI.

Para un fundador con perfil técnico que modifica una página de configuración de cuentas, el proceso es sencillo: describir el comportamiento, inspeccionar el resultado renderizado, añadir comentarios al elemento correspondiente y revisar los cambios de código antes de publicarlos. Los comentarios visuales ayudan a ubicar una petición como «este error debe aparecer junto al campo de correo electrónico». No demuestran que el servidor rechace una actualización inválida ni que la configuración de otro usuario siga siendo inaccesible.

Esta diferencia importa al delegar. Quien aprueba la interfaz y quien comprueba el comportamiento de la aplicación pueden ser personas distintas. Pide tanto el cambio visible como las pruebas de que el funcionamiento subyacente es correcto. Una vista previa convincente no debería ser el único criterio para dar el trabajo por terminado.

Factory también ofrece conectores para herramientas como GitHub, Linear, Slack y Sentry. Pueden aportar contexto autorizado, pero conectar un gestor de tareas no convierte un ticket ambiguo en uno preciso. La tarea sigue necesitando un responsable, un alcance y un resultado claro.

La ejecución remota introduce otra distinción: la interfaz donde revisas el trabajo no es la computadora que lo ejecuta. Los Droid Computers gestionados por Factory son entornos persistentes que conservan archivos, paquetes instalados, servicios y configuración entre sesiones. Factory documenta por separado una opción de Remote Control para una máquina que ya administras. La documentación de Droid Computers describe ambas opciones.

La persistencia ayuda cuando preparar el entorno requiere mucho esfuerzo. También implica que alguien debe hacerse cargo de su estado. Factory indica expresamente que reconstruir un Environment no actualiza un Droid Computer creado antes a partir de una instantánea de ese entorno. Por tanto, un responsable de plataforma debería verificar el estado de la máquina antes de asumir que una ejecución correcta puede reproducirse en otro lugar.

Una fábrica de software con IA empieza por una tarea repetible

Factory gana interés cuando Droid se ocupa de una cola de trabajo definida sin que un desarrollador tenga que iniciar manualmente cada conversación. Droid Exec es su modo sin interfaz interactiva: un comando no interactivo que ejecuta una tarea y devuelve resultados para un script o un sistema de integración continua (CI). Por defecto funciona en modo de solo lectura; las modificaciones y los comandos de mayor alcance requieren ajustes explícitos de autonomía. La documentación de Exec explica los formatos de salida, los directorios de trabajo y los worktrees aislados de Git.

Un buen primer flujo de trabajo es analizar un repositorio y obtener evidencias que la persona responsable de mantenerlo pueda comprobar. Tras instalar Droid y autenticarte, ejecuta lo siguiente desde un repositorio:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

Es un ejemplo de invocación, no una ejecución realizada para este análisis. Por sí solo no demuestra la cobertura: las llamadas dinámicas, las pruebas de integración y el código generado pueden invalidar una conclusión simplista. El resultado es una lista de posibles tareas para quien mantiene el proyecto.

El siguiente paso es permitir que Droid implemente un cambio de pruebas aprobado y delimitado en una rama o un worktree independiente, y luego ejecute las comprobaciones del repositorio. La validación para aceptar el trabajo debe quedar fuera de la explicación del propio agente. El resultado de CI y la decisión de quien revisa deben determinar si la tarea está completa.

Hay un obstáculo de automatización fácil de pasar por alto: una decisión efectiva de política de comandos ask sigue exigiendo aprobación con autonomía High, y un trabajo de una sola ejecución no puede solicitar una aprobación interactiva. Aumentar la autonomía, por tanto, no garantiza que una automatización bloqueada pueda continuar. Factory documenta droid rules check para anticipar las decisiones de las políticas antes de ejecutar. Es un problema de configuración que debe resolverse de forma deliberada, no un motivo para desactivar todas las comprobaciones de permisos.

Para trabajos de mayor alcance, Mission Mode coordina agentes de trabajo y validación. Requiere autonomía High o la anulación de seguridad documentada, y las Missions de planes individuales pueden pausarse al alcanzar los límites de uso. Empieza con tareas habituales de alcance acotado antes de prometer que una migración grande se completará sin supervisión.

La ventaja es la repetibilidad: el mismo proceso de entrada, los mismos límites de permisos y el mismo conjunto de evidencias en cada ejecución. La dificultad es hacerse cargo de la operación. Alguien debe mantener las dependencias, las credenciales, el alcance de las tareas y la gestión de fallos. La comparación de plataformas de fábricas de software es el siguiente paso si esa capa operativa importa más que la sesión individual de programación.

Precios de Factory AI: elige según tu forma de trabajar

Factory Teams es la opción directa para un equipo pequeño que necesita facturación centralizada. Business es el plan que conviene consultar cuando hacen falta uso compartido sujeto a contrato, gestión de identidades o políticas de administración. Pasar de un plan individual a Teams no implica obtener esos controles.

Estas son las condiciones mensuales de la página de precios vigente de Factory, verificadas el 21 de octubre de 2026:

La página de precios no publica cuotas de tokens. El uso solo se expresa como múltiplos de Pro. Esos múltiplos no garantizan un número de tareas, y no existe una conversión fiable a pull requests aceptadas. La documentación de planes para organizaciones aclara que cada usuario de Teams tiene los límites de uso de Pro; Business y Enterprise utilizan uso compartido sujeto a las condiciones del contrato.

Cinco usuarios de Teams cuestan $260 al mes: $60 + 5 × $40. Diez cuestan $460. Si un equipo de cinco usuarios aceptara, hipotéticamente, 20 pull requests de Droid en un mes, la parte correspondiente a la suscripción sería de $13 por pull request aceptada. Es un cálculo, no una previsión de capacidad; antes de comparar el costo total hay que sumar el uso adicional, los recursos de cómputo y el tiempo de revisión.

A menudo, el problema es que el plan no cubre lo que exige el flujo de trabajo. Pro no ofrece los controles empresariales enumerados en Business. Teams no se anuncia con el uso de Plus para cada usuario. Además, la documentación de planes individuales incluye Droid Computers gestionados en Pro, mientras que la página comercial de precios los añade en Plus. Para presupuestar, toma como referencia la página de precios y confirma qué incluye realmente el plan antes de depender de esos recursos gestionados.

Limitaciones que pueden frenar la adopción

Las limitaciones más importantes de Factory tienen que ver con la consistencia entre interfaces y planes. Pueden frenar su adopción aunque una sesión individual de programación dé buenos resultados.

La compatibilidad con un editor no garantiza las mismas funciones. JetBrains no comparte automáticamente archivos, selecciones y diagnósticos como los editores de la familia de VS Code. El Agent Panel de Zed no restaura sesiones anteriores de Factory Droid. Un equipo que adopte Droids como herramienta común seguirá necesitando una puesta en marcha específica para cada editor y un plan para recuperar el contexto. Factory documenta estas diferencias.

El BYOK personal no se traslada a la web o al móvil alojados por Factory. Un modelo configurado localmente puede ser decisivo por sus costos o por el tratamiento de los datos. Esa configuración no está disponible en todas las interfaces de Factory. Valida el flujo remoto que pretendes utilizar antes de comprar basándote en una demostración local. La restricción es explícita.

Los múltiplos de uso no garantizan una capacidad predecible. La documentación de planes individuales describe ventanas móviles independientes de 5 horas, 7 días y 30 días. Una suscripción superior no convierte esas ventanas en una cuota publicada de tokens ni en una garantía de finalización. Si un plazo de entrega a un cliente depende de la ejecución sin supervisión, consulta la capacidad contractual en lugar de extrapolar los resultados de un piloto breve. Las reglas de uso individual de Factory también indican que las Missions se pausan cuando se alcanza un límite de uso.

Hay que confirmar si el plan incluye recursos de cómputo gestionados. La discrepancia entre Pro y Plus es relevante para un fundador que espera que el trabajo se ejecute fuera de su portátil. La tabla de planes de este análisis se basa en la página de precios vigente; la documentación contradictoria no demuestra que se incluya una mejora gratuita. Revisa también las condiciones de cómputo por separado de las de uso de modelos, en vez de interpretar «agentes en la nube» como una asignación completa de infraestructura.

Las reglas de permisos no equivalen a aislamiento del sistema operativo. La propia documentación de autonomía de Factory lo señala. Que un comando esté permitido no demuestra que sea inocuo, y una instrucción en lenguaje natural de evitar producción no constituye una barrera de red. Para un piloto, utiliza el acceso y el entorno adecuados para la tarea; para imponer controles en toda la organización, evalúa los que ofrecen los planes bajo cotización.

Estas limitaciones aconsejan una adopción acotada. Introduce Factory en un flujo donde estén definidos el entorno, el modelo, los permisos y la persona responsable de la revisión. Extenderlo a todos los repositorios antes de resolver esas decisiones añade un trabajo de coordinación que puede anular el beneficio de delegar.

Opinión sobre Factory AI: cómo decidir si vale la pena

Factory se gana su lugar cuando reduce el trabajo humano necesario para convertir una tarea definida en un cambio aceptado. La elección de modelos, las distintas interfaces y la ejecución remota solo son útiles si mejoran ese resultado.

Añádelo junto al agente actual cuando una cola común de mantenimiento, un flujo entre distintos editores o una comparación deliberada de modelos no tenga hoy una solución satisfactoria. Sustituye al agente actual para ese tipo de tareas solo cuando trabajos comparables demuestren menos esfuerzo de revisión o un costo total menor sin debilitar las comprobaciones de aceptación. Prescinde de él cuando duplique un flujo que Claude Code, Codex o Cursor ya resuelven bien.

Para empezar la semana, organiza una evaluación pequeña con una persona responsable del resultado:

Factory es un candidato sólido para esta evaluación. Su documentación respalda un sistema de agentes amplio y configurable. No demuestra que los ingenieros vayan a entregar mejor trabajo por el simple hecho de sustituir el agente que ya conocen por Droid.

Preguntas frecuentes

Consigue la Lista de verificación para auditar flujos de trabajo empresariales con IA a través del boletín para definir la tarea, los permisos, quién se encarga de revisar y el costo operativo antes de ampliar la adopción de agentes.