Qué hacemos ahora que parte del equipo agota la ventana semanal de Claude Code y por qué Opus 5.5 igual es la solución. Qué le vamos a cambiar a nuestra skill de la escala de Uncle Bob ahora que probamos la verificación formal como alternativa a los tests de aceptación. Y nos preguntamos qué queda del Software Craftsmanship.
IA en 540
01. ¡Ay, que nos quedamos sin tokens!
Parte del equipo con licencia premium ha agotado la ventana semanal de Claude Code. Y el uso no para de crecer: de 16 licencias premium en junio a 22 en septiembre.
Encima, ha terminado el aumento temporal del 50 % y el límite queda en un +25 % permanente, un 17 % menos que en agosto. ¿Qué hacemos?
Pago por uso: por ahora sí. Son unos 25 € por 2 h de desarrollo. Compensa si son pocas personas y falta poco para renovar la ventana.
Codex integrado en el flujo: solo si va a más. Como sustituto nos obliga a migrar los workflows de Claude. Nos convence más darle procesos (reviews cruzadas, definición, investigación), y de paso ver en qué gana a Claude.
Más suscripciones: no lo vemos. Una extra por persona o una compartida rozan lo que permiten los términos.
Otros agentes: no. Tenemos que probarlos más. Al nivel de Claude Code solo vemos a Codex.
Frenar el uso: no. Ya lo dijimos. Como mucho, lo optimizamos.
02. Opus 5.5: ahora sí
Justo ahora sale Opus 5.5, que es más barato, gasta menos tokens y nos parece menos verboso y más claro, todo lo que echábamos en falta en Opus 5. Ya es nuestro modelo por defecto.
Y encima va más rápido: en nuestro flujo de implementación, con la misma tarea y cambiando solo el modelo del agente que implementa, pasamos de 27 a 12 minutos hasta la PR y de 10M a 8M tokens.
Igual no hace falta pagar más, de momento.
03. Escala de Uncle Bob: lo que le vamos a cambiar
Queremos que la skill profundice más y que sus propuestas sean accionables y alcanzables (nuestro mejor proyecto saca 22 sobre 36).
Que no se conforme con la primera evidencia. Hoy le basta un linter contra ciclos de dependencias para aprobar la arquitectura, aunque nada controle las capas. En aceptación, le vale que haya tests y no mira qué cubren.
Que distinga dónde corre la comprobación. Solo puntúa lo que bloquea en CI o en un hook de git, no el feedback temprano que recibe el agente mientras trabaja. Y que los puntúe por separado: el agente comprueba su cambio y CI, el proyecto entero.
El sobresaliente exige la especificación como código. Requiere tests de aceptación que se escriben antes que el código y que se mutan para ver si están completos. No lo tenemos así, a posta, y ahora contamos por qué.
Cuando la actualicemos, os avisamos.
04. ¿Hemos encontrado la pieza que faltaba?
Cubrir toda la especificación con tests de aceptación invierte la pirámide de tests y acaba en suites lentas y frágiles.
Participamos en la beta privada de Predictable Code, la herramienta de verificación formal de la que os hablamos en mayo. Con ella, la especificación se deriva de tu código y, si cambias un requisito, se marca el código que ya no lo cumple.
Dex Horthy desconfía de que hoy haya señales fiables para dejar de leer el código. La verificación formal puede ser una: demuestra que los invariantes (condiciones que deben ser ciertas siempre) se cumplen y avisa al momento si alguno se rompe. Sobre un proyecto nuestro cazó suscripciones que nunca se liberaban y podían acabar con la memoria.
Vamos a probarlo, a ver si cambiamos comprobaciones que hoy hacen agentes por verificaciones deterministas.
Enlaces de interés
Shopify deja React Native y vuelve a nativo
Antes React Native ganaba por escribir una vez para iOS y Android. Hoy Shopify implementa en una plataforma y los agentes construyen el equivalente en la otra, alineado con specs y tests, y así reconstruyó la app Shop en nativo en 12 semanas. Con su tamaño se lo puede permitir. En otros contextos no está tan claro, sobre todo cuando la IA acelera igual en React Native. Lo que sí cambia es el trade-off que dábamos por hecho.
TypeSafe lanza Jev, un modelo que devuelve decisiones
Por si alguien se ha perdido el lanzamiento (difícil, a estas alturas). Jev no genera texto. Le das el contexto, le planteas una pregunta con opciones cerradas y te contesta cuál elige y con qué grado de confianza. Puede servir para clasificar, enrutar o tomar decisiones dentro de un flujo, y para eso sale mucho más rápido y barato que un modelo de texto. Compartiremos usos reales que hemos probado y otros que nos han llamado la atención.
Herramientas en el radar
/retro, la skill que revisa tus sesiones
Matt Pocock publica /retro, una skill más de su repositorio del que ya hemos compartido varias. Lee los logs de una sesión y propone mejoras al entorno del agente: punteros a ficheros que le costó encontrar, comprobaciones automáticas que habrían cazado el fallo, instrucciones de CLAUDE․md que no cambian nada. Nos encaja que, cuando el fallo es mecánico, proponga un check determinista antes que otra línea en el CLAUDE․md. La vamos a probar.
Una vuelta y media
Por Pablo Albizu
Este fin de semana David Heinemeier Hansson (DHH), se subió al escenario de la Rails World 2026 y “se jubiló como programador profesional” ya que escribir código a mano ya no es una actividad económica rentable.
Bravo, DHH, alguien al admiro engullido por su propio personaje.
A partir de esto, ríos de tinta sobre la enésima muerte de la profesión, de los programadores, de los “artesanos del software”, etc.
Y todo esto conectó en por qué durante los últimos años nos ha dado repelús cada vez que alguien nos presentaba como “los artesanos de software”. No siempre fue así.
Cuando empezábamos en esto conocimos el movimiento “Software Craftsmanship” y lo abrazamos ya que encontramos en el una forma de entender el desarrollo de software que encajaba con cómo queríamos trabajar.
No bastaba con que las cosas funcionasen.
Había que hacer las cosas con intención, con criterio, hacerte responsable de lo que entregabas. Preocuparte por la calidad, construir software que sirviese para algo y que pudieses seguir cambiando mañana.
Muchas de esas ideas acabaron formando parte de los cimientos de 540 y hasta nos liamos la manta a la cabeza organizando una conferencia llamada “Pamplona Software Crafters”.
Pero con los años empezó a pasarnos algo raro.
Seguíamos creyendo en lo mismo, pero cada vez nos daba más repelús decirlo. Un escalofrío recorría mi cuerpo cuando alguien nos presentaba como “los artesanos del software”. Duro. Muy duro.
El problema era la metáfora.
Lo del artesano se había ido retorciendo hasta construir una imagen con la que cada vez nos identificábamos menos.
El desarrollador como artesano. El código como obra. El orgullo por hacer las cosas con tus propias manos. El programador encerrado en su cubículo perfeccionando su pieza.
Dejamos de tener ganas de identificarnos con ello, hasta pensamos en cambiar el nombre de la conferencia.
Y llegó la IA.
Si había algo capaz de terminar de enterrar la metáfora del artesano era esto. Nosotros mismos diciendo que nuestra visión es llegar a no leer código. Muy loco.
El funeral perfecto del Software Craftsmanship salvo por una cosa, cuanto más delegamos, más nos preocupamos por muchas de las cosas que hicieron que abrazásemos aquel movimiento.
Si queremos dejar de leer código, necesitamos más garantías para confiar en lo que se genera.
Y necesitamos hacernos responsables de lo que ponemos en producción, porque “lo ha hecho la IA” no parece una gran explicación cuando algo se va a la mierda.
El error estaba antes, nuestra profesión nunca fue escribir líneas de código a mano. Era un medio.
El fin fue resolver problemas y generar oportunidades reales utilizando software solo que durante años tuvimos que escribir código para construir software y acabamos confundiendo el medio con el fin.
Todas las prácticas y técnicas que utilizábamos eran medios, algunas cambiarán, otras desaparecerán y aparecerán otras nuevas.
Pero hacerse responsable de lo que construyes sigue muy vigente.
Así que me ha pasado con el Software Craftsmanship como cuando llevas años criticando algo que quieres por todos sus defectos y, de repente, viene alguien de fuera a criticarlo sin criterio.
Te entran unas ganas de defenderlo de la hostia.
Enlaces de interés
Rails World 2026 Opening Keynote - DHH
El discurso que ha provocado buena parte de esta newsletter.
El 11S para los artesanos del software
Otra lectura sobre qué significa la IA para el Software Craftsmanship.