Checklist de dependencia de agentes de código: el salto de $5.000 millones de Factory

Estás decidiendo si un solo agente de código con IA puede estar en cada ruta de compilación. Factory recaudó $200 millones en una ronda anunciada el 15 de septiembre de 2026, elevando su valoración a $5.000 millones. Eso siguió a una recaudación de $150 millones en abril de 2026 con una valoración de $1.500 millones. El salto convierte una elección de herramienta en una elección de proveedor.

Un salto en la valoración es una señal de dependencia

Cuando el precio de un proveedor clave sube, se reevalúa la relación. Los agentes de código empresarial están entrando en la misma categoría. Factory construye una plataforma empresarial donde agentes de IA crean, prueban y mantienen software, compitiendo con Cognition y Cursor, ambas plataformas de código con IA. Para el 16 de septiembre de 2026, los compradores empresariales ya estaban sopesando Factory, Cognition, Cursor y Poolside como opciones separadas. El mercado está tratando la categoría como infraestructura, por lo que la decisión de dependencia es ahora una decisión de negocio.

Blackstone, Khosla Ventures, Sequoia Capital, Insight Partners, Evantic Capital y Sound Ventures participaron en la financiación. Ese tipo de respaldo no garantiza la calidad del producto, pero sí eleva las apuestas. Si el proveedor es una dependencia clave, su balance forma parte de tu modelo de riesgo.

A fecha del 15 de septiembre de 2026, cientos de miles de desarrolladores usan la plataforma de Factory, incluyendo personas empleadas por Nvidia, Adobe y Palo Alto Networks. En enero de 2026, los modelos de lenguaje de gran escala fueron descritos como mejorando automáticamente a los agentes de Factory a partir de señales anónimas de miles de sesiones diarias. Esa combinación plantea la pregunta operativa: ¿cuánto de tu ruta de compilación depende de la herramienta?

Aplica la prueba de dependencia antes de estandarizar

Una dependencia es una herramienta en la que confías cuando el negocio está bajo presión. La prueba es si puedes modelar el costo de esa dependencia antes de que se vuelva real. Empieza por la unidad de valor. ¿El agente se cobra por asiento, por repositorio, por cómputo o por resultado? Una unidad de precio que no coincide con la forma en que tu equipo consume la herramienta se desviará.

Luego, mapea la ruta de datos. Cuando el agente mejora a partir del uso, necesitas saber qué aprende, qué retiene y qué puedes revocar. Por último, ensaya la salida. Un proveedor que no puede describir una ruta de migración te está pidiendo que aceptes un compromiso abierto.

El poder de fijación de precios y la retroalimentación de datos deciden si la herramienta se acumula a tu favor o en tu contra. La viabilidad del proveedor, el bloqueo por integración y la ruta de salida deciden si puedes irte. Cada punto siguiente debe ser respondible en una reunión, no en un proyecto de debida diligencia.

• Poder de fijación de precios. ¿Puedes predecir el costo de renovación por ingeniero, por repositorio o por ejecución del agente? Pide el precio unitario, el medidor de uso y el supuesto de renovación. Respuestas poco claras convierten al proveedor en una apuesta.
• Retroalimentación de datos. ¿Qué señales de uso salen de tu entorno y qué mejoran? Cuando el modelo del proveedor mejora a partir de tus sesiones anónimas, necesitas los límites. Obtén qué se retiene, qué se agrega y qué puedes desactivar.
• Viabilidad del proveedor. ¿Puede el proveedor sobrevivir a una guerra de precios, un cambio de proveedor de modelos o un hueco de financiación? Revisa la estructura accionarial, la base de clientes y la hoja de ruta del producto. Un balance sólido ayuda, pero deja riesgo operativo.
• Bloqueo por integración. ¿Cuánto de tu ruta de compilación, pruebas y liberación depende de una sola interfaz? Mapea los puntos de contacto: pipeline de compilación, revisión de código, despliegue y respuesta a incidentes. Eliminarlo no debería significar reescribir ninguno de esos.
• Ruta de salida. ¿Qué puedes exportar y cuánto tarda la migración? Solicita una exportación de muestra, una estimación de migración y un compromiso de soporte. Una promesa sin fecha no es un plan.

Haz que el checklist produzca resultados

No estandarices un agente de código hasta que el checklist produzca resultados. Un modelo de costos, un límite de datos y un plan de migración son el mínimo. Un proveedor que no puede responder por escrito ya ha respondido. Las respuestas vagas deben incorporarse al costo de la decisión. Las respuestas ausentes deben tratarse como un costo mayor que la cotización escrita del proveedor.