Cómo verificamos el código de nuestra software factory, cómo crece el orquestador al llegar a más equipos, qué queremos probar en el IA Hack Day y cómo la IA cambia la elección del stack. ¿Y si mejorar cómo una empresa desarrolla software empieza a parecerse a un proceso de industrialización?
IA en 540
01. Nuestra software factory (III): la verificación
Con la implementación desatendida generamos código más rápido de lo que podemos revisarlo, y ese es el nuevo cuello de botella. Para resolverlo, buscamos que las PRs sean más fáciles de revisar y que cada vez se mergeen más sin que nadie las mire. En ningún caso el número de incidentes puede subir.
Por eso, cada PR pasa por varias capas de revisión. Ninguna lo para todo, pero lo que se le escapa a una lo caza otra (modelo del queso suizo). La persona interviene solo cuando hace falta y el resto se delega:
Comprobaciones deterministas que bloquean, las del CI de siempre: tipos, linters, arquitectura, tests, duplicación, cobertura, CRAP y mutation testing.
La skill /review-pr (la misma del workflow de implementación), con dos agentes:
Uno pone una nota de 0 a 10 según cinco aspectos: corrección, arquitectura, dominio, tests y UI y estilos.
Otro valora el riesgo: si toca una zona delicada (como los pagos), si la persona responsable del cambio conoce poco esa zona o si el cambio es muy grande.
Pruebas de la funcionalidad, al implementar cada tarea y otra vez cuando está toda terminada.
Si falla alguna comprobación o la nota no llega al mínimo, la PR se queda con los comentarios. Si hay riesgo, se marca para revisión. Si todo está bien, queda lista para mergear. Los comentarios los arregla el workflow de implementación, en otra vuelta.
A la persona le queda mirar las PRs marcadas, decidir hasta dónde profundizar y mergear. Al equipo, decidir cómo se calcula la nota y cuál es la mínima, y qué cuenta como zona delicada o como cambio muy grande. Y cada fallo que se nos escapa nos sirve para que el sistema lo cace la próxima vez.
La semana que viene, el diseño: de dónde salen las reglas y las comprobaciones en las que se apoya todo esto. Repasa las anteriores, si te las perdiste (I, II).
02. Nuestro orquestador sigue creciendo
El orquestador al que delegamos épicas enteras lo hemos llevado a tres equipos más. Cada uno le ha añadido lo que necesitaba:
GitHub Projects además de Jira.
Hacer configurable lo que estaba fijo.
Soporte para proyectos con varios repositorios.
Varios orquestadores en la misma máquina, uno por proyecto.
03. Lanzamos nuestro IA Hack Day
El viernes 13 de noviembre nos juntaremos para sacar adelante varias iniciativas que en el día a día cuesta atacar y que creemos que nos pueden llevar a otro nivel. Os comparto algunas de las que hemos pensado:
Dejar de depender de los dynamic workflows de Claude Code y montar el flujo determinista con LangGraph o en TypeScript.
Llevar el orquestador a la nube y que el ordenador de cada uno pase a ser un nodo de ejecución.
Portar nuestro flujo delegado a agentes de código y modelos abiertos servidos por Helmcode, para ver si es una alternativa real a Claude.
Dejar la CI en lo mínimo y firmar en local que los checks pasan.
Tener evals de workflows y skills para saber si siguen funcionando igual de bien al cambiar de proveedor o de modelo.
04. ¿La IA cambia cómo decidimos el stack?
La IA ha hecho que escribir código cueste muy poco, incluso en un lenguaje que no dominas, y eso puede estar cambiando cómo elegimos la tecnología.
En móvil optamos por React Native para no hacer la app dos veces, como muchos otros. Ahora Shopify y Coinbase vuelven a nativo, porque el agente se encarga de la segunda plataforma. Eso sí, la IA también acelera en React Native, y puedes usarla para aplicar sus últimas mejoras de rendimiento.
DHH se puso a reimplementar y optimizar Campfire en Elixir, Go y Rust. Rust gana de largo, Ruby queda el último, y se pregunta qué sentido tiene elegir un lenguaje por lo legible que es si ya no lees el código. Ahora bien, si el rendimiento es tu problema, quizá baste con llevar a Rust la parte crítica.
Enlaces de interés
Cómo hace code review el equipo de Claude Code
Varios agentes revisan cada PR y la aprobación humana depende del riesgo, muy en la línea de nuestra verificación. Las PRs con comentarios de revisión sustantivos pasaron del 16 % al 54 %.
El cuello de botella ya es verificar - Addy Osmani
Defiende que los agentes funcionan mejor cuando pueden comprobar su propio trabajo y repasa qué tests les ayudan a hacerlo.
Herramientas en el radar
Lightpanda 1.0, un navegador para agentes
Un navegador escrito desde cero, más ligero que un Chrome headless, que agent-browser ya puede usar como motor. Como Simfleet, permite que varios agentes prueben a la vez sin dejar el ordenador frito.
Una vuelta y media
Por Pablo Albizu
¿Por qué antes odiaba el término “software factory” y estamos dando la matraca con una en 540?
Hace años ya discutíamos sobre si estábamos convirtiendo nuestros equipos en factorías porque habíamos “industrializado” el flujo de desarrollo de software: teníamos un proceso bien marcado, PRs, revisiones de código, tests, despliegues automatizados…
Alguna vez nos llamaron “los reyes de la ortodoxia”. Incluso nos acusaron de que “les comíamos la cabeza a los desarrolladores” para implantarles esa forma ordenada de hacer las cosas. Creíamos que cuanto más sistematizado estuviese el proceso, más seguro y sostenible sería el código que generábamos. Y de paso, más tiempo teníamos para centrarnos donde más teníamos que pensar.
El código lo seguían escribiendo las personas. Con su conocimiento, su criterio y también cierto arte para resolver los problemas. Por eso, el término factory no me gustaba: parecía que las convertía en máquinas.
Por eso sí que creo que ahora tiene sentido que hablemos de software factory porque efectivamente estamos construyendo una máquina que automatiza parte del SDLC.
Durante estos años, algunos clientes nos llamaban para que les ayudásemos a desarrollar producto, querían sacarlo antes, sabiendo que lo íbamos a hacer bien. Otros, para mejorar cómo desarrollaban software.
En estos últimos casos, rara vez entrábamos solo para mejorar el proceso. Necesitábamos algo que construir juntos: un producto nuevo, una evolución, un problema sobre el que trabajar. Ahí introducíamos prácticas, desarrollábamos habilidades y cambiábamos la forma de hacer las cosas con ellos. La implantación se hacía en la cabeza de los desarrolladores.
Ahora podemos incorporar parte de esas prácticas a un sistema que las ejecuta.
Hablo con empresas que quieren ese sistema, esa máquina que construya software de manera casi autónoma. Aquí aparece la conversación que más estoy teniendo estos días: este trabajo empieza a parecerse mucho a implantar maquinaria en una fábrica.
Vas, entiendes cómo trabajan, qué quieren producir y dónde están los problemas. Te replanteas el proceso con ellos: qué puede ejecutar la máquina, qué decisiones siguen tomando las personas y cómo se comprueba el resultado. Y construyes el sistema para trabajar así.
Francesc Pla lo cuenta en A Motor Per Machine: electrificar las fábricas exigió reorganizarlas para aprovechar la nueva tecnología. Con la IA nos toca hacernos esa misma pregunta antes de construir e implantar la máquina.
Hasta ahora nos costaba imaginar una intervención así en desarrollo de software. Podíamos dejar mejores prácticas, personas más preparadas, automatizaciones y herramientas. Ahora empiezo a ver la posibilidad de dejar un sistema que ejecute una parte mucho mayor del proceso.
Tanto me está recordando a una implantación industrial que me estoy planteando hablar con empresas de ingeniería tradicional para aprender cómo lo hacen ellas. Cómo ponen una máquina en marcha, cómo comprueban que funciona, cómo preparan a quienes van a operarla y cómo la mantienen y evolucionan.
Antes me molestaba hablar de factorías porque parecía que queríamos convertir a las personas en máquinas. Ahora puedo empezar a imaginar que podemos montar una máquina que automatiza la construcción de software.
Ya no me molesta tanto el nombre.