Os contamos cómo estamos construyendo nuestra software factory, por qué lo que frenaba a un equipo sin IA le sigue frenando con ella y cómo usamos Jev para poner nota a una code review de forma automática. Y además, ¿y si la delegar la ejecución está haciendo mucho más visibles las diferencias entre desarrolladores?
IA en 540
01. Nuestra software factory (I)
Cada vez se habla más de software factories, sistemas de desarrollo de software con IA. Llevamos tiempo construyéndolas en nuestros clientes.
Para nosotros, una software factory cubre todo el ciclo de desarrollo de software (SDLC), del descubrimiento a la operación. Cada etapa tiene un objetivo, una forma de hacerse y sus controles.
Hoy, en el descubrimiento y la especificación el agente pregunta y escribe, y la persona decide. En el diseño aplicamos la ingeniería que siempre nos ha acompañado, y unas métricas deterministas controlan la complejidad y el orden de la arquitectura del código. La implementación va desatendida de ticket a PR, y la persona mergea. Es posible porque cada regla del equipo tiene un check que la hace cumplir, y un agente revisa cada cambio antes del merge.
No creemos en una software factory única. Cada una depende de los procesos, las prácticas, la base de código y el contexto del cliente.
Semana a semana os iremos contando la nuestra, pieza a pieza. Lo natural sería empezar por el principio, por el descubrimiento, pero arrancamos por la implementación, la parte que más cambia en este nuevo paradigma.
02. Lo que te frenaba sin IA te sigue frenando con ella
Un equipo nuestro integrado en un cliente hizo una retro con una pregunta: ¿por qué les cuesta delegar más en la IA?
Sus errores cuestan dinero, porque trabajan en el camino crítico del negocio.
Tocan muchos backends y frontends de otros equipos, no pensados para que ellos metan mano, y se adaptan a la forma de trabajar de cada uno. Cuando han querido correr, se han dejado cosas.
Gran parte del trabajo es refinar y adaptar lo que ya existe, más que crear algo nuevo o hacerlo evolucionar.
El diseño llega muy poco cerrado y se itera en pleno desarrollo.
Con tanta complejidad repartida, la IA tiene los mismos frenos que tenían ellos antes: todo hay que mirarlo dos veces, un cambio correcto pide entender a fondo sistemas ajenos, hay que preguntar a otros equipos y alguien nuevo tarda meses en ser productivo.
03. Probamos Jev
La semana pasada contábamos el lanzamiento de Jev, un modelo que elige entre opciones cerradas y te dice cuánto confía en su elección. Lo hemos probado en un caso concreto, poner nota a una code review automática a partir de los problemas que detecta (los findings).
Hasta ahora un LLM evaluaba cada finding y, para sacar una nota sobre 10, restaba según el tipo (2 puntos por testing, 1 por alineamiento y 0,5 por naming, por poner números). Ahora hemos puesto a Jev a clasificar esos findings, y aquí tenéis el ejemplo completo.
En una sola llamada responde cinco preguntas sobre cada finding (¿se hizo a propósito?, ¿arreglarlo mejora el código?, ¿se arregla o se descarta?, ¿cómo de grave es?, ¿de qué tipo es?), cada una con su probabilidad. Con esas respuestas sale la nota.
En las pocas reviews que hemos lanzado va rápido, sale barato y la nota coincide con nuestro criterio.
Enlaces de interés
OpenAI presenta Decisions API
Es la misma idea que Jev, y tiene pinta de que saldrán más modelos de este tipo. OpenAI ya tiene su propia implementación sobre GPT-6 Luna, de momento en preview limitada.
Por qué a Martin Fowler no le gustan los LLMs
No le gusta cómo hablan ni que se inventen cosas con el mismo aplomo con el que aciertan, pero los sigue usando. Le preocupa que la IA tome el control de infraestructuras o diseñe armas biológicas, justo lo que pone en duda Uncle Bob, porque no ve cómo podría hacerlo sin depender de nosotros.
Software factories
Lecturas sobre cómo otros montan su software factory.
La software factory de OpenAI - Gergely Orosz
Una persona define el objetivo, Codex implementa y otros agentes lo revisan en paralelo, cada uno centrado en un área como seguridad o infraestructura. Los cambios de más riesgo pueden pasar por un ingeniero, y el despliegue lo aprueba una persona. Después, más agentes vigilan latencia e incidentes, y lo que pasa en producción es contexto del siguiente cambio.
Warp define su software factory como código - Ben Holmes
Un agente central reparte cada tarea entre agentes de triage, implementación, revisión y diseño, y otros puntúan las conversaciones y proponen por PR mejoras en las skills. Todo vive en un factory․yaml versionado, y tienen varias factories, una por área de producto. Su CEO, Zach Lloyd, separa construir el producto de construir la factory que lo produce, una división que ya planteamos.
La software factory Holodeck - Ben Dechrai
Los proyectos se construyen dentro de la factory. Un orquestador reparte el trabajo entre agentes distintos, con modelos distintos, para escribir tests, implementar y revisar. Cada agente trabaja en su worktree y en un contenedor desechable, y los tests y hooks corren fuera de su bucle como filtro de calidad.
Why Software Factories Fail - Dex Horthy
Los modelos se entrenan premiando que pasen los tests, sin castigar un diseño que complica mantener el código, y por eso lo degradan con el tiempo. Propone buscar dónde aporta más una persona: alinear producto, arquitectura y diseño del programa antes de escribir código, y revisar la implementación.
Herramientas en el radar
Open Code Review - Alibaba
CLI open source de revisión de código que combina reglas deterministas con agentes. Hace lo mismo que otros servicios de revisión de PR con IA como Greptile, pero corre en local, sobre tus cambios y con el modelo que elijas.
ARTEMIS - Google
Framework para automatizar Android en dispositivos reales a partir de lenguaje natural, a 3-5 segundos por paso. Se integra con Claude Code como herramienta (vía MCP) y reporta más del 99% de éxito en el benchmark AndroidWorld.
Una vuelta y media
Por Pablo Albizu
Me reúno con uno de nuestros clientes para ver cómo está funcionando nuestra gente y me enseña un ranking de PRs mergeadas. Pum.
De primeras, me entra un sudor frío, otra vez a vueltas con una “vanity metric” para medir el rendimiento de las personas. Siempre he considerado que contar PRs, commits o líneas de código dice bastante poco sobre la productividad y choca de frente con mi creencia de que la unidad mínima para medir la productividad siempre ha sido el equipo.
Pero al ver el ranking hay algo que me llama mucho la atención. Mirando los últimos 30 días, una persona lleva más de 60 PRs mergeadas y otra no llega a 20. Una diferencia suficientemente grande como para querer entender qué está pasando.
En este equipo no hay product managers y los desarrolladores están muy cerca de los stakeholders. Además, hemos madurado una software factory que cubre todo el ciclo desde que aparece una necesidad hasta que terminamos construyéndola. Dentro de ella, la implementación y gran parte de la verificación están delegadas en IA.
El 0% del código lo escriben humanos y aproximadamente el 80-90% ni siquiera se lee.
Hay personas box-to-box capaces de gestionar y desarrollar producto de principio a fin y de mantener la software factory. Otras más enfocadas en operar el sistema y sacar producto. Y otras generan menos output directo porque dedican más tiempo a mantener y mejorar la factory.
Para hacernos una idea de cuánto ha cambiado la capacidad de producción, en dos momentos pico similares pasamos de 187 PRs mergeadas en agosto de 2025 a 513 bastante más grandes en agosto de 2026.
Volvemos al ranking.
Me siento con la persona de 540 responsable del equipo y empezamos a mirar por qué en 30 días hay un x3 de diferencia.
Una de las personas que está arriba estaba trabajando en un rediseño grande pero perfectamente aterrizado y acotado. Tenía muchísimo trabajo preparado y, mientras siguiese teniéndolo, podía mantener continuamente en marcha la parte de la software factory que delega la implementación y gran parte de la verificación en IA.
Otra persona que esperábamos encontrar bastante más arriba estaba trabajando en una iniciativa con poco backlog preparado y en la que necesitaba hablar continuamente con unos y con otros, coordinar, conseguir respuestas y desbloquear decisiones para saber qué hacer después. Y resulta que ese tipo de trabajo es precisamente una de las cosas en la que tiene menos experiencia.
Así que una diferencia de más de 60 frente a menos de 20 PRs no significa que una persona sea tres veces más productiva que otra. El contexto sigue importando muchísimo.
Pero miramos también dos personas que están trabajando en un contexto parecido y vemos una diferencia similar. Ahí empieza a ser bastante más difícil explicar la diferencia por el trabajo que les ha tocado.
Y puede que estemos viendo una diferencia real de rendimiento que antes era mucho más difícil detectar porque antes, aunque dos personas partiesen de situaciones parecidas, entre ellas y el resultado seguía estando su capacidad para implementar. Una podía tardar más porque conocía peor esa parte del código, porque técnicamente el cambio se le atragantaba o simplemente porque programaba más despacio. Era muy difícil separar cuánto de la diferencia venía de la persona y cuánto de la propia ejecución.
Ahora hemos quitado buena parte de la implementación humana de esa ecuación.
Si dos personas parten de condiciones parecidas y utilizan el mismo mecanismo de ejecución, la capacidad que tienen disponible para convertir trabajo preparado en software también se parece muchísimo más. Tenemos menos ruido para entender de dónde viene la diferencia..
No quiero decir con esto que el número de PRs se haya convertido mágicamente en una métrica de productividad. La métrica no te da la respuesta, pero ahora puede darte una señal bastante más clara de dónde merece la pena investigar.
Empezamos a intuir otra diferencia que antes apenas existía: cuánto eres capaz de delegar de verdad en la IA.
Dos personas pueden tener acceso exactamente a las mismas herramientas y utilizarlas de maneras muy diferentes. Una puede confiar en las garantías que hemos construido alrededor del proceso, delegar agresivamente y apenas entrar en el código. Otra puede seguir queriendo hacerle cierto micromanagement a la IA.
Y creo que aquí está la vuelta y media de ese ranking.
Delegar la ejecución del software en IA está haciendo más visibles las diferencias entre ellos.
Seguimos jugando con contextos distintos y las PRs siguen sin ser una métrica de productividad. Pero cuando quitas buena parte de la implementación humana de la ecuación y las diferencias siguen ahí, son mucho más llamativas.
La métrica no te da la respuesta, pero puede decirte dónde merece la pena hacer la pregunta.
Y quizá eso sea lo que ha cambiado: antes muchas diferencias quedaban escondidas detrás de la propia ejecución. Ahora empiezan a quedar a la vista.