Cómo ahora, en nuestra software factory, la entrega la lleva un agente e iteramos sobre lo desplegado, cómo verificamos las PRs con IA cuando al cliente le cuesta delegar en ella, por qué la IA está acercando la verificación formal al código del día a día y por qué decidimos parar para el IA Hack Day del viernes 13. ¿Y de verdad importa cómo llamemos a la software factory, o qué implica construirla y qué podemos conseguir con ella?
IA en 540
01. Nuestra software factory (VI): la entrega
Trabajamos con tareas pequeñas que se integran cada poco en la rama principal (trunk-based development), y el despliegue está automatizado en la CI. Cada merge llega a un entorno de pruebas, y a producción sube una versión cuando creamos su tag de release, numerado con versionado semántico. Lo que aún no queremos lanzar va oculto tras un feature flag y producto lo activa cuando toca.
Con la implementación desatendida generamos código mucho más rápido, y eso ha cambiado cómo trabajamos: construir una idea y probarla lleva tan poco que preferimos iterar sobre lo desplegado antes que sobre prototipos o diagramas. Para hacerlo, dependemos mucho más de los feature flags. Activamos cada cambio primero para el equipo, después para algunas personas y luego para un porcentaje de usuarios cada vez mayor, así que vemos el impacto y los bugs antes de que lleguen a todos. La contrapartida es que los flags se acumulan, y cada uno tiene su coste de mantenimiento.
El otro cambio es que ya no tenemos que estar tan encima de cada despliegue. Lo teníamos muy automatizado, pero alguien tenía que lanzar la build, los tests y la subida a producción, vigilar que cada uno terminara bien y arreglar lo que fallaba. Ahora lo hace un agente: lanza los pasos y, si algo falla, analiza el error y reintenta. Donde más se nota es en las apps, que tienen más pasos (las release notes, una build por plataforma), y el agente deja la versión lista para publicar.
La semana que viene, la operación, lo que pasa después de desplegar. Repasa las anteriores, si te las perdiste (I, II, III, IV, V).
02. Verificar las PRs cuando cuesta delegar en la IA
En nuestra software factory, un agente puntúa cada PR y, en función de esa nota, la aprueba o la deja pendiente de una persona. Un equipo de 540 busca lo mismo en un cliente de banca, más reticente a que la IA decida qué se mergea. Ahí hemos ajustado la estrategia:
La IA detecta. Identifica el tipo de PR (hay 12) y las reglas que rompe (hay 57), con la evidencia.
Un script determinista puntúa. Parte de 100 y resta lo que pesa cada regla rota.
Cada regla tiene su peso. Depende del tipo de PR: un nombre poco claro pesa más en un refactor que en una nueva funcionalidad. El equipo ajusta los pesos cada viernes con una skill que analiza las respuestas a los comentarios de la IA.
La persona decide si se mergea. En la PR quedan un resumen con la nota, los comentarios y una etiqueta (aprobada, con sugerencias o rechazada), con un aviso de que salen de un proceso agéntico.
03. El auge de la verificación formal
Cada vez vemos más casos en los que se demuestra matemáticamente que el código cumple su especificación y que no queda ningún camino sin cubrir. La IA ya escribe las demostraciones y, de regalo, destapa bugs que los tests no habían cazado.
Boris Cherny, creador de Claude Code, verifica con Lean el Claude Agent SDK, y de un par de prompts sacó 16 PRs con correcciones.
Lauren (poteto), del equipo de Grok, ha añadido a su stack (pstack) la forma de crear una skill de verificación formal para tu código.
GitHub Next y Microsoft Research presentan PDD Kit (solo para Rust), que pasa el plan a una especificación formal y demuestra que el código la cumple.
Anthropic, con Theorem, ha convertido en demostraciones los tests de 123 librerías open source, y ha encontrado cientos de bugs.
Nosotros estamos probando Predictable Code en nuestra software factory, ahora que tenemos acceso al CLI y las skills de su beta privada.
04. IA Hack Day: ya está aquí
Este viernes 13 de noviembre hemos decidido parar todo el equipo y juntarnos para sacar adelante 10 iniciativas que nos hacen avanzar con la IA. Van desde rehacer de cero nuestro orquestador de tareas y agentes para llevarlo a la nube hasta montar una skill que cree cualquier recurso visual de 540 con nuestro sistema de diseño, incluso desde el móvil.
Al más puro estilo hackatón: tokens, pizzas, mucha pasión y hasta que el cuerpo (y la cabeza) aguanten. Algunos alargarán todo el fin de semana y participarán en el NASA Space Apps Challenge.
Te dejo el planteamiento completo.
Enlaces de interés
Ahora Claude responde antes
Más allá de mejorar el modelo, Anthropic también acelera Claude Code y la API para que Claude dé respuestas más rápidas. Ahora Claude Code comprime lo que envía en cada turno y la API guarda la conversación en el servidor, así que solo viajan los mensajes nuevos.
El momento de los agentes personales
Cada vez se oye más hablar de agentes que te llevan el día a día. Instinct crece por WhatsApp, en abierto están Hermes y OpenClaw, OpenAI tiene dots y xAI, Grok Bot. Ahora Anthropic presenta Claude Duet.
HumanLayer libera su core - Dex Horthy
Uno de los proyectos que más hemos seguido publica con licencia Apache 2.0 la app de escritorio, el daemon que ejecuta sesiones de Claude Code y Codex y las skills de RPI. Días después anuncia que se une a Factory.
Herramientas en el radar
Simlock, un móvil para cada agente - Callstack
Como Simfleet, coordina simuladores, emuladores y móviles físicos entre agentes que prueban a la vez: cada uno tiene el suyo hasta que lo libera. Nosotros seguimos con Simfleet para poder lanzar varias pruebas a la vez. La coordinación ya la resuelve nuestra factoría, así que de momento no nos hace falta.
Una vuelta y media
Por Pablo Albizu
Ha sido la discusión estrella en X este fin de semana: ¿es apropiado utilizar el nombre “software factory”?
Tenemos una gran capacidad para acabar discutiendo de lo que no importa. Ya perdimos mucho tiempo discutiendo sobre si “craftsmanship” era la mejor metáfora y ahora estamos repitiendo la historia con “factory”.
Antes odiaba hablar de factorías de software porque parecía que queríamos convertir a las personas en máquinas. Ahora hay máquinas escribiendo el código por nosotros, así que tampoco me parece una locura. La industria ha elegido “software factory” para decir “automatizar e ingenierizar el SDLC con IA”. Pues ya está. Siguiente.
Me interesa bastante más qué implica construir una y qué podemos conseguir con ella.
Qué implica. La factory es el resultado de un proceso de ingeniería: diseñar cómo trabaja, qué contexto tiene, cómo valida lo que produce y cómo aseguramos que el resultado resuelve lo que tiene que resolver. Y hacerte responsable de lo que pones en producción. Se apoya más que nunca en buenas prácticas, algunas replanteadas ahora con la IA.
Para poder automatizar el ciclo de vida del desarrollo de software tenemos que hacer explícito mucho de lo que antes resolvíamos sobre la marcha: qué necesita una tarea para empezar, qué reglas debe respetar, cómo verificamos el resultado y cuándo debe intervenir una persona. Y una vez explícito, lo podemos cuestionar y mejorar.
Eso cambia dónde ponemos la atención. Vamos saliendo del bucle de la implementación para centrarnos en entender qué queremos resolver, definir bien lo que entra y verificar que lo que sale funciona, genera valor y es mantenible.
Y esto no va de fabricar coches iguales. Cada incremento funcional se define a medida y hay que aprender de lo que ocurre al utilizarlo.
Qué podemos conseguir. Más capacidad de ejecución. Más capacidad para convertir decisiones en software funcionando más rápido y de forma constante. Puedes probar, iterar y aprender más veces. Pero multiplicar el output no garantiza más outcome: los resultados mejoran solo si aprovechas ese aprendizaje para decidir mejor. Habrá organizaciones que usen esa capacidad para hacer mucho más y otras que prefieran liberar tiempo para otras cosas.
Eso sí, “la potencia sin control no sirve de nada”. Nosotros avanzamos hacia nuestra north star: no necesitar leer el código. Esto nos obliga a poner el foco en el sistema, en construir las garantías que nos permitan confiar en el resultado. Un sistema que no genere mierda a paladas imposible de mantener en el medio y largo plazo.
Y aquí mi vuelta y media: construir tu software factory es una decisión estratégica, supeditada al fin que persigas. En 540 estamos invirtiendo en la nuestra y ayudamos a nuestros clientes a construir la suya. Y como con cualquier técnica, metodología o herramienta que hemos incorporado, tiene que haber una intención detrás. Nos puede gustar mucho jugar con tecnología, pero esto tiene que servir para algo.
No deja de ser una inversión: construir y mantener esa capacidad cuesta tiempo y dinero. Cuánto merece la pena ingenierizar y automatizar dependerá de tu contexto y de lo que quieras conseguir. Decidir eso sigue siendo lo complicado.
El fin sigue siendo el de siempre: aportar valor con tecnología. La factory es un medio más para conseguirlo. Y cuanto más rápido produce, más nos toca preguntarnos si lo que le pedimos merece la pena construirlo. Esa responsabilidad no se delega.
Llámala como quieras.
El punto 02 es oro: que la IA señale, que un script ponga la nota y que una persona apriete el botón. Si dejas puntuar al modelo, la misma PR te la aprueba un día y te la suspende al siguiente ;) Y recalibrar los pesos cada viernes con una skill me encanta: es la retro de toda la vida, pero con el agente sentado a la mesa.