Fábrica de software con agentes: SuperPlane 1.0

Una fábrica de software con agentes, para todo el equipo

El 27 de octubre SuperPlane lanzó su versión 1.0 y la presenta como una fábrica de software con agentes: una capa open source y agnóstica de modelo que rodea a tus agentes de código y lleva el trabajo del ticket a un pull request verificado. Me ha llamado la atención porque pone nombre a algo que se ve mucho en los equipos que adoptan agentes: cada persona trabaja con los suyos a su manera y nadie tiene una vista común de lo que está pasando.

Ojo con lo que leo aquí: casi todo viene de su propio anuncio. No lo he probado, así que cuento lo que dicen ellos y marco aparte lo que es opinión mía.

El problema que plantean

Su punto de partida es sencillo. Según ellos, todo el mundo tiene ya un agente de código, pero no pasa nada hasta que alguien abre una sesión, y la configuración de cada uno es distinta. Lo resumen con una imagen que me ha gustado: hemos convertido a los mejores ingenieros en “aguadores” de sus agentes, porque alguien tiene que decidir si una tarea está lista, comprobar el resultado, perseguir la CI y contestar los comentarios de la revisión.

Eso conecta con lo que contaba en Vibe coding vs SDD: generar código rápido no basta si nadie define qué es estar bien hecho.

Qué hace, según SuperPlane

Describen cinco ideas:

• Puntúa los tickets antes de lanzar nada. Lee el backlog y puntúa cada tarea por claridad, complejidad y verificabilidad, para que arregles los puntos flojos antes de que el agente empiece. Según ellos, la mayoría de los tickets no están listos para un agente.
• Exige pruebas de que está hecho. Cada cambio vuelve con evidencias: checks que pasan, capturas de la interfaz real, grabaciones y una nota sobre lo que no ha podido verificar. Revisan esas pruebas personas o agentes.
• Hace volver al agente. Cuando falla la CI o llegan comentarios de revisión, reenvía al agente con esa evidencia hasta que el PR esté listo para que lo mire una persona.
• Comparte estándares. Las habilidades, la preparación del entorno, los chequeos de que una tarea está lista y las reglas de verificación son del equipo, y hay un tablero que muestra qué corre, qué falla, cuánto cuesta y dónde hace falta una persona.
• Lo decide una persona. Qué construir, qué compromisos aceptar y cuánto riesgo asumir lo deciden las personas; el resto es trabajo de la fábrica.

Cada tarea se ejecuta en su propio entorno de desarrollo en la nube, en paralelo. Es open source con licencia Apache 2.0 según su propio anuncio, y dicen que funciona con modelos de OpenAI, Anthropic, Google, xAI, DeepSeek, Qwen y Kimi. Aun así, es un producto comercial: según su anuncio, hay un plan por uso, Starter a 20 $ por organización al mes y Team a 50 $ por usuario al mes, más el uso de sandbox y tokens.

La cifra del 52 %

Cuentan que, durante el último mes, el 52 % de los pull requests que fusionó su propio equipo salieron de SuperPlane. Es un dato de ellos, sobre su propio equipo y sin que yo haya podido contrastarlo. Lo que sí me parece honesto es cómo lo interpretan: dicen que no han delegado la mitad de su trabajo, sino que han hecho trabajo extra que nunca habrían abordado. Esa distinción es importante para cualquier equipo que se esté planteando algo parecido.

Por dónde empezarían ellos

Recomiendan empezar pequeño: arreglos de bugs bien definidos, actualizaciones de dependencias y de seguridad, y pequeñas mejoras que nadie encuentra tiempo de hacer. Me parece buen consejo, y el criterio de empezar por lo verificable encaja con lo que escribí en agentes que prueban lo que programan: un agente solo puede entregarte algo fiable si hay una forma clara de comprobarlo.

Lo que yo me preguntaría antes de adoptarlo

Esto es opinión mía, no de ellos:

• ¿Quién escribe el criterio de “listo”? Puntuar la claridad de un ticket ayuda, pero la especificación sigue teniendo que existir. Para mí es el sitio natural de Spec-Driven Development: cuanto mejor está la spec, más tareas pasan el filtro.
• ¿Qué permisos tiene el agente dentro de la fábrica? Un sistema que lanza agentes solo ante un ticket o una alerta de seguridad es cómodo, pero también ejecuta cosas sin que nadie abra la sesión. Los mismos temas de permisos, sandboxes y secretos valen aquí.
• ¿Las pruebas son de verdad pruebas? Una captura o una grabación es útil, pero alguien tiene que mirarla. Que la nota diga qué no pudo verificar es lo más valioso del enfoque, siempre que se lea.
• ¿Es tu problema ahora? Si tu equipo aún no tiene tickets bien escritos ni una CI en la que confiar, una fábrica no lo arregla.

Es un 1.0 recién salido, no lo he probado, y yo lo trataría como una idea para estudiar más que como algo para meter en producción sin probarlo antes.

Qué me llevo

La parte que me quedo es el cambio de foco: el problema ya no es el primer commit del agente, sino darle al equipo un camino compartido y verificable para que los agentes trabajen sin depender de que alguien abra una sesión. Eso se puede empezar a construir hoy con tu propia CI y tus propias specs, sin esperar a ninguna herramienta.

En onext ayudamos a equipos a adoptar agentes de IA con Spec-Driven Development y con verificación desde el principio. Si quieres pensar cómo organizar los agentes de tu equipo, escríbenos y lo hablamos.