Cómo guiamos las decisiones de diseño del agente en nuestra software factory, qué hacemos para que las PRs que sí leemos sean fáciles de revisar, qué plan tenemos para no quedarnos vendidos si Claude cae y cómo hemos llevado la idea de Jev a producto. ¿Y cómo estamos lidiando con la incertidumbre?
IA en 540
01. Nuestra software factory (IV): el diseño
Cuando delegas la implementación, el agente decide qué método nuevo hace falta, en qué clase va y si usa un if o mete un ternario. Nuestro trabajo es diseñar las reglas con las que toma esas decisiones y cómo nos aseguramos de que las cumpla.
Para eso tenemos guardarraíles de dos tipos:
Reglas que lee el agente (rules y skills), con las convenciones del equipo y el dominio. Decide él si las sigue.
Comprobaciones deterministas de toda la vida (tipos, linters, tests), que, a diferencia del agente, fallan siempre igual.
Si una regla importa y se puede comprobar con código, lo hacemos. Por ejemplo, a la regla de no escribir comentarios la acompaña un script que rechaza cualquier cambio que los tenga. La regla hace que el agente acierte a la primera, y la comprobación, que no se cuele nada.
Adelantamos cada comprobación todo lo que podemos, porque cuanto antes le llega el feedback al agente, más barato es corregirlo:
Cada vez que el agente escribe, formato y linters.
Al terminar de implementar, tipos, linters, arquitectura (las fronteras entre capas, sin ciclos) y tests.
Antes del commit, tipos y tests de lo que cambia.
Antes del push, todos los tests y la arquitectura.
En CI, cobertura, mutation testing, CRAP, duplicación y las métricas de calidad de todo el código (complejidad y acoplamiento), que no dejamos empeorar.
Las reglas salen de los acuerdos del equipo, que ponemos por escrito, de los comentarios de review que se repiten y de los fallos del agente. Además, podemos ser más estrictos: con la arquitectura hexagonal hacíamos excepciones pragmáticas, y ahora, con una comprobación detrás, seguirla al pie de la letra apenas cuesta. Cada regla inequívoca es una decisión que el agente ya no toma.
La semana que viene, la especificación, donde se hace el diseño concreto de cada tarea. Repasa las anteriores, si te las perdiste (I, II y III).
02. Las PRs que leas, que sean fáciles de revisar
La semana pasada contamos cómo mergear cada vez más PRs sin que nadie las mire. Esta, cómo hacemos que las demás sean más fáciles de revisar.
En AI Engineer Paris 2026, Matt Pocock propone que cada PR explique los cambios con diagramas, diga si es reversible y a qué afecta si falla. Usa de referencia /show-me, de HumanLayer, que resume los cambios en un pseudocódigo corto.
Nosotros estamos probando explain-pr, una skill con las ideas que más nos han encajado. Explica qué hace una PR sin bajar al código: diagramas de cómo funciona, efectos secundarios, si cumple lo pedido y si los tests lo prueban. Aquí un ejemplo.
03. Tenemos un problemilla y un posible problemón
Así arrancaba un mensaje en nuestro canal de IA en Slack:
Cada vez llegamos más al 100 % de cuota de Claude Code y toca pagar por uso.
Si nos pasa lo que a Felipe, nos quedamos vendidos.
El plan es pagar nosotros lo que exceda la suscripción y, en paralelo, dejar de depender de un solo proveedor. Queremos que nuestro orquestador pueda lanzar también Codex, y que nuestro workflow de implementación no dependa de Claude Code.
Hoy, si Claude cae, volvemos a la Edad Media porque el cambio no es rápido, y lo asumimos. Ninguna herramienta sustituye a otra tal cual, así que buscamos combinarlas. Cuando Claude caiga, avanzaremos más despacio o nos dedicaremos a lo que Codex hace igual o mejor.
04. El Jev de OpenAI, aplicado a producto
Hemos llevado a producto la idea de Jev, que ya probamos en nuestro flujo de desarrollo. Esta vez usamos la Decisions API de OpenAI, que también elige entre opciones cerradas en vez de generar texto.
En un proyecto, cada partida de un presupuesto se clasifica en un tipo de producto. Un buscador propone unos pocos candidatos y hasta ahora un agente con GPT-5.6 Luna elegía entre ellos. Lo hemos reemplazado por la Decisions API sobre GPT-6 Luna, que da a cada candidato su probabilidad, y nos quedamos con los más probables, normalmente uno o dos.
La mejora, medida sobre 4.918 partidas reales:
De 5,4 a 0,16 segundos por partida.
Del 16,9 % al 14,1 % de partidas mal clasificadas.
Enlaces de interés
Hasta 500 $ al mes en créditos de API en Claude
La suscripción empieza a incluir hasta 500 $ al mes de uso de la API en el plan Team, según las licencias. Es interesante para probar el Agent SDK o Managed Agents sin coste extra.
¿Por qué sigues usando pull requests? - Thorsten Ball
Si los modelos revisan mejor que tú, hay formas mejores de compartir conocimiento y el agente ya pasó los tests antes, la PR sobra y toca integrar directo.
10 thinkers in agentic coding - Ray Myers
Lista de personas a seguir si trabajas con agentes, entre ellas Lada Kesseler, Geoffrey Huntley, Birgitta Böckeler, Adam Tornhill y Dex Horthy. La nuestra reúne a las personas cuyo contenido más compartimos en 540.
Herramientas en el radar
cccc, mide la complejidad de cada función
Complejidad cognitiva y ciclomática por función en más de 20 lenguajes y falla si alguna pasa del umbral que fijes, con GitHub Action incluida. Mide las métricas de complejidad que comprobamos.
Una vuelta y media
Por Pablo Albizu
El año pasado, Gorka y yo volvimos a Pamplona de la TRG preocupados. Unos meses antes habíamos proclamado “la refundazione” de 540: teníamos que replantearnos cómo hacíamos las cosas y sacar partido a la IA. Pero por aquel entonces había más de intenciones que de realidad. La usábamos, podríamos decir, como acompañante: mismos procesos, mismas técnicas, pero aceleradas con IA.
En aquella edición, la IA apenas estuvo presente en la parrilla de ponentes, pero en los stands y en los pasillos era monotema. Una locura.
No fue hasta ir a este evento y ver el sentir general cuando vimos la urgencia de ponernos las pilas y hacer una apuesta total por la IA, de convertirla en una ventaja competitiva.
Volvimos entre acojonados y más motivados que nunca. Ahora sí que empezaba la refundación.
Desde entonces, la IA pasó a ser un tema central en nuestra estrategia, daba de lleno en nuestra línea de flotación. También nos comprometimos a contar públicamente todos nuestros aprendizajes. Una de las mejores decisiones que hemos tomado.
Un año después, volvíamos al mismo evento, también como patrocinadores. El objetivo: tener todas las conversaciones posibles en torno a la IA, a cualquier nivel, desde diseño y desarrollo hasta negocio y contrataciones. Y buscábamos algo también: bajar la conversación lo más posible al barro, no quedarnos en vaguedades y en “cómo mola la IA”, sino hablar de las cosas concretas que estamos haciendo.
Este año me volví con la sensación de que estamos bien. Muy avanzados en muchos de los aspectos de los que estuvimos hablando y, por las conversaciones que tuvimos, con un nivel de madurez que todavía no es lo habitual. Hubo personas que se acercaron a darnos las gracias por todo lo que estamos compartiendo y para las que estamos siendo referentes.
También me encontré mucho más miedo e incertidumbre en el sector de lo que me esperaba. Hay personas que han perdido su trabajo. De eso empezó hablando David Bonilla en la keynote, recuperando cortes de charlas suyas de hace años en las que ya hablaba de que la labor de un desarrollador no era picar código. Que eso era un medio, no el fin.
Nosotros seguimos teniendo dudas. Cómo afectará todo esto al modelo de negocio, qué tipos de cliente terminaremos teniendo, quién pagará los costes de la IA… Hemos avanzado muchísimo, pero seguimos sin saber cómo van a terminar encajando muchas cosas.
En eso estamos todos igual: nadie tiene certezas absolutas. Cada uno a su nivel y según sus circunstancias, todos tenemos incertidumbre.
Lo que sí ha cambiado este año es nuestra forma de lidiar con ella. ¿Qué nos ha ayudado?
Aceptar que estamos en una transición. Lo que hoy crees que va a ser de una forma, mañana es de otra. Hoy resuelves una cosa, mañana te sale un nuevo problema. Toca estar al loro, contrastar lo que vas aprendiendo y cambiar de opinión cuando haga falta. No vamos a tener certezas absolutas para movernos, así que no puedes quedarte esperando.
Pensar en largo plazo y valorar el riesgo de no prepararnos. La IA no es perfecta, pero ¿podemos permitirnos no estar preparados si lo cambia todo todavía más? Podemos dedicar tiempo a cosas que luego no lleguen a ninguna parte. Nos está pasando y nos seguirá pasando. La asimetría de Taleb: buscar apuestas en las que lo que puedes ganar sea mucho mayor que lo que puedes perder, asegurándote de que puedes asumir esa pérdida. Piensa en qué te cuesta empezar a probar en serio con la IA, qué puedes ganar y qué puedes estar perdiendo por no hacerlo.
Concentrarnos, probar y aprender. Somos muy fans de la opcionalidad, pero puedes tirarte días y semanas valorando cuáles son las mejores opciones a probar o cómo arrancar ciertas cosas. Ok, pero también hay que elegir algunas y ponerse. Parte de lo que necesitas saber solo lo vas a aprender haciéndolo.
Obligarnos a bajar el nivel de abstracción de las conversaciones sobre la IA. El gradiente de grises es enorme y, si solo hablamos de vaguedades y decimos «yo también hago todo con la IA», las interpretaciones son infinitas. Uno no termina de saber si su nivel de madurez es aceptable o no. Hay que hablar de las cosas concretas que estamos haciendo, de cómo las hacemos y de qué está pasando.
Exponernos públicamente más que nunca, con los riesgos que supone. Mostrar de verdad lo que hacemos nos ayuda a contrastar con otros cómo vamos. También nos obliga a ordenar lo que estamos aprendiendo y nos expone a que alguien nos diga que algo no tiene sentido. Todo eso viene bien.
Ir a más eventos y hablar con más gente externa que nunca. Salir es incómodo, pero las externalidades positivas a las que te expones son impagables. Salir, ir a fiestas, hablar con gente y abrir posibilidades de que pase algo bueno que no habías previsto. Otra vez Taleb. No puedes planificar qué conversación te va a cambiar la forma de ver algo, pero sí puedes exponerte a tenerla. La TRG del año pasado fue bastante más que eso.
No quererlo todo mañana y para todo el mundo. En las organizaciones hay distintas velocidades. Nosotros identificamos personas que tenían que tirar del carro de la IA, mientras procurábamos dar tranquilidad a quienes estaban sacando adelante el trabajo diario. No todo el mundo tiene que estar permanentemente excitado por probar y estar al día. Si siempre has sido de estar en el “edge”, seguramente te salga natural. Si nunca lo has sido, no tiene por qué ser diferente ahora. Eso sí, no lo pierdas de vista y sé exigente incorporando lo que otros van aprendiendo.
Venimos de años de tranquilidad en los que nos habíamos acomodado, y ahora toca cambiar. Y eso al principio cuesta: revisar lo que haces, aprender otras formas de trabajar y asumir que lo que te ha funcionado hasta ahora puede dejar de hacerlo.
A la vez, creo que estamos ante una oportunidad enorme para que este sector se haga mayor y se replantee cuánto de nuestra identidad profesional gira alrededor de las herramientas y cuánto de lo que conseguimos con ellas.
El miedo es comprensible, yo lo siento muchos días. Vivo con la ilusión de lo que estamos haciendo y la preocupación de no saber qué pasará el año que viene. Las dos cosas son compatibles. Pero tenemos que llevar la conversación más allá de «la IA nos va a quitar el trabajo», afrontar el cambio y ser más conscientes de qué va nuestro trabajo.
Habrá incomodidad y no todos lo viviremos igual. Aun así, soy optimista: tenemos una oportunidad para demostrar lo que podemos aportar y hacer cosas útiles que antes no estaban a nuestro alcance.
Vamos a aprovecharla.