Cómo detallamos la especificación en nuestra software factory para que el agente implemente del tirón, el salto adelantado a Codex para no quedarnos sin cuota, por qué replanteamos el Hack Day para rehacer el orquestador desde cero, y la disputa por el entorno de trabajo entre el chat y la terminal. Y una vuelta y media a los tres trabajos distintos que seguimos llamando desarrollo de software.
01. Nuestra software factory (V): la especificación
Con la implementación delegada, definir bien lo que entra importa tanto como validar lo que sale. La especificación tiene que llegar completa, porque al implementar el agente no se para a preguntar.
Seguimos estos pasos, con skills adaptadas de Matt Pocock:
Aclarar. El agente te interroga para no dar nada por supuesto, y solo te pregunta lo que no está del todo cerrado o lo que no puede resolver buscando en el código (/grill-me).
Especificar. Lo decidido se convierte en una especificación: el problema, las decisiones de implementación y de testing, y lo que queda fuera de alcance (/to-spec).
Trocear. La especificación se parte en tareas pequeñas que se pueden entregar por separado, con sus dependencias y sus criterios de aceptación como tabla de casos (specification by example). Esos criterios marcan cuándo ha terminado el agente y qué se comprueba al verificar (/to-tickets).
En nuestro enfoque la especificación guía la implementación y después sobra, lo que Birgitta Böckeler llama spec-first dentro del Spec-Driven Development (SDD).
No nos convence la propuesta de ciertos frameworks (OpenSpec, Spec Kit) de mantener la especificación junto al código (spec-anchored). Te obliga a sincronizar dos cosas a mano. En cambio, estamos explorando Predictable Code, que deriva la especificación del código y marca lo que deja de cumplirla.
Y spec-as-source, que regenera el código desde la especificación en cualquier momento, hoy no lo vemos viable.
La semana que viene, la entrega, lo que pasa desde el merge hasta que el cambio llega a producción. Repasa las anteriores, si te las perdiste (I, II, III, IV).
02. No dejes para el Hack Day lo que necesites hacer hoy
Parte de lo que teníamos reservado para el día 13 lo hemos tenido que atacar ya. Algunos del equipo iban a quedarse sin cuota a poco más de mitad de semana, y pagar el exceso no era asumible.
Por un lado, hemos empezado a definir la especificación con Codex. Es un trabajo mano a mano con el agente, apoyado en skills, así que el cambio ha sido directo.
Por otro, ya hemos hecho que en nuestro orquestador se pueda configurar cada paso para lanzar Codex. Además, hemos creado un ejecutor de workflows que lanza con Codex los dynamic workflows de Claude Code.
Y eso ha hecho tambalear el planteamiento del IA Hack Day.
03. Nuestro Hack Day, patas arriba
Llevar el orquestador a la nube, con nodos locales, cambia la arquitectura más de lo que esperábamos. Eso nos ha hecho replantear el Hack Day: vamos a dedicarlo a rehacer el orquestador desde cero, en TypeScript, observable de serie y desacoplado. Tendrá cuatro módulos:
Core decide qué lanzar y dónde.
Worker ejecuta la orden con el agente local.
Ejecutor de workflows, ampliado para lanzar scripts sin pasar por un agente y elegir el modelo en cada paso.
UI muestra y configura lo que hace el core.
El objetivo: una versión mínima con las piezas conectadas.
El nuevo reto: preparar bien el contrato entre las piezas, para que cada equipo avance por su lado y luego encajen.
Mantenemos la prueba de nuestro flujo con agentes de código y modelos abiertos, para ver si son una alternativa real a Claude y Codex. No queremos retrasarla más.
04. Hacia el chat o de vuelta a la terminal
Nuestro rol evoluciona, y las herramientas también, así que seguimos explorando entornos de desarrollo para trabajar con agentes (ADE).
La mayoría sigue con Orca, pero le estamos dando otra oportunidad a T3 Code. Ahora que el trabajo es más conversar y editar markdown, y alternamos entre Codex y Claude Code, su interfaz unificada nos aporta más que el CLI hecho a medida.
Herdr va en la dirección contraria: divide la terminal en paneles, uno por agente, como tmux. Es ligero, todo va con atajos de teclado y te basta con SSH para manejar los agentes desde otra máquina, incluso desde el móvil. Lo malo es que es café para muy cafeteros. Quien lo probó a fondo empezó escéptico y ahora le gusta mucho. Le seguimos la pista.
Enlaces de interés
La suscripción de Claude ya sirve en harnesses de terceros - Dan McAteer
Sin pagar aparte, desde el Agent SDK, claude -p, la API o Managed Agents. OpenCode también vuelve a poder usarse con ella.
Qué modelo abierto usar en lugar de Claude - Helmcode
Propone elegir por tipo de trabajo y medir el coste por tarea completada, porque abierto no siempre es más barato. Nos ha parecido una comparativa muy interesante, sobre todo ahora que queremos probar nuestro flujo con modelos abiertos.
Herramientas en el radar
OpenCode lanza la versión 2.0
El agente pasa a ser un servicio en segundo plano al que se conectan la terminal, la web, el escritorio y tus propios scripts. Va muy en la línea de lo que queremos hacer con nuestro orquestador: un core desacoplado y la UI aparte.
Una vuelta y media
Por Pablo Albizu
Volviendo al origen de los tiempos, la misión de un desarrollador de software siempre ha sido resolver problemas de negocio a través de la tecnología. La tecnología, el código, era un medio para un fin.
El crecimiento de la industria y la ejecución como cuello de botella favorecieron una taylorización del desarrollo: frontend, backend, frontend del frontend, bla, bla, bla. Nos especializamos cada vez más y, en muchos casos, acabamos confundiendo el medio con el fin.
Nos llenábamos la boca hablando de product mindset, pero a mí dame un frontend que haga 8 horas al día componentes de React y dime tonto.
Llega la IA y la implementación y gran parte de la verificación pueden ser delegadas. El código ya no lo escribimos nosotros. La implementación pierde peso como cuello de botella y más foco se pone en producto.
Podemos tener una capacidad de producción enorme y tenerla esperando porque no hemos conseguido preparar el trabajo. Ya hablé de que lo importante no es solo dispararle a la perdiz, es ponerla a tiro.
Y conviene también diferenciar product mindset de gestión de producto. Una cosa es guiar tus decisiones por lo mejor para el negocio y otra ser capaz de definir producto, gestionar prioridades, coordinar dependencias y responsabilizarte de que todo llegue a buen puerto.
Y en esta transición nos hallamos, con las software factories automatizando cada vez más partes del ciclo de vida del desarrollo. Empezamos a vislumbrar que lo que antes se llamaba de una forma ahora tiene formas distintas.
Product builders. Personas box-to-box capaces de gestionar y desarrollar producto de principio a fin. Hablan con stakeholders, entienden el problema, hacen discovery, gestionan prioridades, aterrizan el producto y lo desarrollan utilizando la factory. Pueden también crearla y mantenerla, pero su foco está en mejorar el producto. Los Fede Valverde o Steven Gerrard, Pogačar o LeBron. Preparan la jugada y la rematan.
Factory runners. Personas enfocadas en operar el sistema y sacar producto. Parten de un problema suficientemente aterrizado, lo concretan técnicamente, aseguran que el plan técnico tiene sentido, delegan la implementación y verifican el resultado. Cuestionan decisiones, comprueban que las evidencias son suficientes para dar el trabajo por bueno e investigan cuando algo falla. Su responsabilidad es sacar adelante ese trabajo con garantías.
Factory builders. Personas cuyo foco está en mejorar la factory, en mejorar los agentes que mejoran el producto. Trabajan sobre el contexto, las herramientas, las evaluaciones y las garantías que permiten delegar. Generan menos output directo de producto porque dedican más tiempo a mantener y mejorar el sistema que utilizan los demás. Similar a una parte del trabajo de un staff engineer: habilitar que otros tengan el entorno y las herramientas necesarias para hacer su trabajo.
Una persona puede combinar los tres focos. El factory runner puede evolucionar hacia product builder, pero también profundizar en la construcción de la factory, en la fiabilidad del resultado o en problemas técnicos concretos que requieren profundidad. Ser autónomo de principio a fin no significa que tenga sentido hacerlo todo solo.
Nos falta la pata del mercado.
A igualdad de capacidad para sacar adelante el trabajo, ser capaz también de prepararlo aporta una autonomía que el mercado puede valorar especialmente. Quien mejora la factory puede multiplicar la capacidad de todo el equipo. Podrán crearse diferencias salariales, de oportunidades y de capacidad de negociación.
Y quien se centre en operarla tendrá que observar cuánto de su aportación va absorbiendo la propia factory. No todos tienen que convertirse en product builders, pero quien se limite a intervenciones que el sistema vaya absorbiendo tendrá que ampliar su aportación.
Estamos viviendo una transición. No tenemos respuestas definitivas, pero sí podemos ir orientando nuestros procesos de selección y la configuración de nuestros equipos en base a lo que estamos viendo.
Si nuestra unidad de medir la productividad sigue siendo el equipo, tendremos que ver cómo lo configuramos según el contexto de cada organización. Algunas apostarán por equipos pequeños de product builders. Otras, por personas con capacidades distintas y por construir procesos y simbiosis que les permitan funcionar bien juntas.
Alguien muy builder puede centrarse más en preparar trabajo si tiene al lado a alguien que le cubre bien la espalda con los planes técnicos y la verificación de los resultados.
En las compañías más tecnológicas, es razonable pensar que algunas intentarán reducir equipos con la idea de que con menos gente más “builder” tendrán la misma capacidad. Habrá que ver qué ganan, qué pierden, cuánto cuesta y cómo escala eso.
Mientras tanto, seguimos llamando desarrolladores a personas que hacen trabajos cada vez más distintos.
Y si cambia lo que necesitamos de ellas, tendremos que cambiar también qué buscamos al contratar, cómo valoramos su aportación y qué caminos les ofrecemos para crecer.
Enlaces de interés
El nacimiento del Software Verification Engineer - Leonid Bugaev
Si los agentes escriben el código y los tests, alguien tiene que construir las reglas, los entornos y las evidencias que permitan confiar en el resultado. Una mirada al trabajo de ingeniería que hay detrás de delegar con garantías.
Mejorar el producto o mejorar la factory - Ben Holmes
Ben distingue entre mejorar el producto y mejorar los agentes que lo construyen. Un ejemplo concreto: puntuar las conversaciones de los agentes por eficiencia y calidad del código, y utilizar otro agente para proponer mejoras en las skills a partir de las peor puntuadas.