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.⁠

IA en 540

01. Hablamos con Dex Horthy

Os contábamos que Uncle Bob apenas mira el código de sus agentes y que Dex Horthy apostaba a que rectificaría. Teníamos que hablar con él por si algo se nos escapaba: ¿desconfía de que haya señales fiables o cree que, sin leer cada diff, se pierde el contexto para plantear bien el siguiente cambio?

Nos contó que cada vez más gente con experiencia admite que los modelos se complican solos, Anthropic incluida. Y nos dio su tesis: ir lo más rápido posible minimizando el dolor futuro (expected pain) y siendo responsables del resultado, que para él pasa por revisar el código.

Duda de que hoy haya señales fiables para no leer el código (más en la próxima edición). Coincidimos en que la complejidad crece sola y en definir mejor, pero él tira por revisarlo todo más deprisa y nosotros por leer cada vez menos, solo donde unos controles deterministas o un panel de métricas nos digan que hace falta.

02. Escala de Uncle Bob: suspendemos casi todos

Lo prometido es deuda: pasamos por nuestros proyectos la skill que mide, siguiendo la idea de Uncle Bob, cuánto le falta a un repositorio para dejar de leer el código de los agentes.

El mejor saca 22 sobre 36 puntos y la mediana se queda en 13. Sin sorpresas: web delante, móvil detrás, y al final los proyectos donde menos autonomía tenemos o en los que aún estamos poniendo los mimbres.

Donde mejor estamos es en arquitectura y tests: linters que impiden mezclar capas o crear ciclos de dependencias, y tests con reglas de estilo. Si algo falla, rompe la build.

Flojeamos en especificación, cobertura y mutación. Los criterios de aceptación van en la tarea y los verifica el agente, así que no hay especificación ejecutable que mutar. Los tests de aceptación no bloquean nada, la cobertura casi nunca rompe la build y el mutation testing falta en la mayoría.

Más que la nota, nos quedamos con lo que señala el análisis: que todo eso rompa la build y meter, donde falten, cobertura, mutación y linters de arquitectura y duplicación. Hay partes del análisis que nos han chirriado, lo vemos en la próxima edición.

03. Si no leemos el código, ¿qué miramos?

En uno de los proyectos hemos montado un panel con estas métricas para ver el estado del código sin leerlo:

• Complejidad: cuánta acumula la clase y cuántos caminos tiene un método (WMC y CC).

• Acoplamiento: cuántas dependencias tiene una clase con otras (CBO).

• Cohesión: si una clase hace una cosa o son varias en una (LCOM).

• Índice de mantenibilidad de 0 a 100 que combina complejidad y tamaño en una nota.

Nos hemos puesto de objetivo 80 de mantenibilidad (estamos en 75). La tabla de peores candidatos nos dice qué ficheros tocar primero.

Esto nos recuerda a lo que ya hacíamos con los tableros de “preocupaciones” que aprendimos de Xavi Gost: al resolver tareas apuntábamos los problemas generales que veíamos y en una reunión semanal decidíamos qué atacar. La métrica ha ocupado el sitio del tablero, que al no leer el código ya no llenamos. Sigue decidiendo el equipo. Toca ver si estas métricas predicen la mantenibilidad a largo plazo.

Enlaces de interés

Claude Code añade soporte para AGENTS.md

Por fin, si una carpeta no tiene CLAUDE․md, Claude Code lee y usa AGENTS․md, y se puede activar o desactivar en /config. Ya no hacen falta los apaños que teníamos por compatibilidad en proyectos donde no todos usan Claude Code. A ver si lo siguiente es todo lo que cae en .claude/.

Por qué los líderes de la IA están pidiendo frenar - MultiVersial

Carlos Molina defiende que OpenAI, Anthropic o xAI piden frenar porque no pueden seguir la carrera a este ritmo: cada entrenamiento cuesta más de lo que ingresan y una salida a bolsa lo dejaría a la vista. Es una explicación bastante coherente de la narrativa del miedo. Y su lectura: la burbuja no ha pinchado, pero esta puede ser la primera señal.

Uncle Bob publica su visor UML para supervisar agentes

Si la revisión humana es el cuello de botella y los harnesses deterministas son demasiado restrictivos, Uncle Bob propone interrogar el sistema en vez de leerlo: un diagrama tipo UML coloreado con métricas CRAP y mutation score, navegable hasta el código, desde el que pides al agente refactors o cambios de arquitectura. Hemos montado un timeline para seguir cómo ha evolucionado su postura.

Herramientas en el radar

Claude plugin eval

Claude Code estrena evals para plugins y skills: defines casos de prueba, ejecutas tu skill contra ellos, puntúas las ejecuciones y las repites sin la skill para ver la diferencia. Cubre parte de lo que buscábamos con Promptfoo y viene integrado. Lo tenemos que probar.

Eventos en el radar

Kernel Panic! #01 - 6 de octubre, Madrid

Primera conferencia abierta de IA de Helmcode, con Hugging Face, InditexTech y Cloudflare. 200 personas, una sala y cuatro charlas de 45 minutos sobre modelos abiertos e inferencia en producción. Nos hemos apuntado varios de 540.

Una vuelta y media

Por Pablo Albizu

Los grandes capos de la IA discuten sobre sus riesgos y sobre si hay que frenar o no. No voy a opinar sobre ello, tranquilos, pero sí me gustaría llevarlo a la trinchera.

Nuestra apuesta desde hace un tiempo: adaptar nuestra forma de construir software a la nueva era de la IA. Nuestra estrella del Norte: ser capaces de no leer el código que generamos y dormir tranquilos por la noche. No porque el código dé igual, sino porque queremos construir sistemas lo suficientemente confiables, sostenibles y seguros como para no necesitar revisarlo para saber que lo que hemos construido está bien.

¿Estamos ahí? No. Pero esta semana un equipo me contaba que en sus últimos desarrollos calculaban que no habían leído el 90% del código.

¿Y vamos a frenar? Pues tampoco.

Aquí me acordaba de una idea sobre la que Taleb insiste bastante: el “Risk of Ruin”. Hay determinados riesgos de los que tienes que protegerte porque, aunque sean poco probables, si ocurren te dejan fuera de la partida.

¿Y si nuestro Risk of Ruin es precisamente no acelerar lo suficiente?

No queremos descubrir demasiado tarde que otros son mucho más rápidos y que nuestros clientes esperan otra cosa.

Así que seguimos acelerando:

• Un grupo de personas (IA-edge) que reflexiona, investiga, prueba cosas y las lleva al límite. Otro grupo (IA-leads) que hace permear lo que vale a la realidad y que devuelve aprendizajes.

• Aprovechamos “la barra libre del token” para poder usar los modelos más punteros y aprender al máximo.

• Seguimos evolucionando nuestra “máquina” en la que delegamos tareas cada vez más complejas y que es capaz de ejecutar de manera autónoma

• En los clientes donde prima el time to market y apuestan claramente por la IA, más radicales que nunca, asumimos los riesgos.

• En proyectos con un horizonte temporal corto, antes muchas buenas prácticas costaba más amortizarlas (costaba más la salsa que los caracoles). Pagar deuda técnica es cada vez más barato. Podemos comprar mucha más velocidad asumiendo deuda conscientemente.

• Juniors que aprenden a desarrollar software delegando en IA desde el día uno, sin haber conocido otra forma de hacerlo.

Pero después de dos años acelerando, ¿qué estamos empezando a ver?

Esto ya no es jugar con Claude. Estamos empezando a industrializar esta forma de desarrollar software. Está en clientes reales, en producción y en sitios donde equivocarte a veces cuesta poco y otras veces cuesta muchísimo.

Y hay cosas con las que probablemente tengamos que ser más estrictos que nunca:

• Lo de siempre, las buenas prácticas. Si queremos generar más código y leer menos, necesitamos mejores tests, feedback, diseño y garantías. Preparando nuestra formación sobre desarrollo de software con IA nos hemos dado cuenta de que tenemos que rescatar el de “buenas prácticas para poder desarrollar software” y añadirle el “con IA”.

• La IA no es el fin, sigue siendo el medio. Podemos invertir una barbaridad en mejorar el sistema, pero seguimos estando aquí para construir productos que mueven la aguja.

• Cuidado con los economics, a más delegación, más coste (lo hablamos en la newsletter anterior).

• El contexto importa. No podemos acelerar igual en un cliente donde equivocarse es barato que en un sistema muy complejo y donde equivocarse es muy caro (banca, por ejemplo).

• Dependencias. Hemos apostado por Claude porque nos permite profundizar, pero mañana pueden cambiar los precios, los modelos o todo el panorama. Tenemos que estar preparados para el cambio.

• Los equipos. No pretendamos de repente que todo el mundo tenga la capacidad de construir los sistemas que generan software con IA: habrá gente que los construya y gente que los opere.

Curioso, no podemos permitirnos no acelerar, pero cuanto más aceleramos más cosas encontramos en las que tenemos que ser estrictos.

Y ahora lleva todo esto al plano personal, ¿es para ti un Risk of Ruin no actualizarte a esta nueva forma de desarrollar software? ¿Qué pasa si dentro de unos años otros han aprendido a delegar gran parte de la ejecución y tú sigues trabajando como antes?

Pero si estás a tope con la IA, ¿te estás pasando de frenada y estás delegando cosas que no deberías?

Paradójicamente, cuanto menos código queremos leer, más estamos viendo que necesitamos preocuparnos por todo lo que nos permite confiar en ese código.

Más rápidos que nunca y a la vez más estrictos que nunca.

Enlaces de interés

Avoiding Risk of Ruin

Una explicación ligera del concepto de Risk of Ruin y de por qué evitar quedarte fuera de la partida cambia cómo deberías pensar sobre determinados riesgos.

La IA ha llegado al mundo real - Better Business, Better World

Una reflexión interesante sobre el paso de jugar y experimentar con IA a meterla en el mundo real, donde empiezan a importar los costes, las restricciones y las consecuencias.

IA en 540

01. La Maquineta se hace mayor

Con La Maquineta sacamos más trabajo sin estar pendientes del flujo: ataca la épica con sus tareas y cuando necesita algo, te busca. Por eso la hemos extendido a todo el equipo del proyecto. El mensaje ha sido “usadla por defecto y reportad lo que no funcione”.

Eso ha acelerado su evolución. Su repositorio ha recibido entre 30 y 40 PRs en una semana y ahora se le pueden asignar tareas sueltas, corre en Linux, soporta stacks de PRs y se ve mejor qué está haciendo.

Extenderla ha forzado a que el proceso de definición sea el mismo para todos. Con cuatro personas cada una podía preparar la épica a su manera. Con todo el equipo delegando en ella, no.

Para eso estamos montando versiones propias de tres skills de Matt Pocock (grill-me, to-spec y to-tickets) que trabajan la definición y la convierten en tareas comprobables. Lo contaremos cuando esté cerrado.

02. La CI, ahora duele

El gasto en CI se nos está disparando en algunos proyectos. Vamos más rápido, abrimos muchas más PRs que antes (hasta 50 en un día) y los minutos de GitHub Actions incluidos se agotan en los primeros diez días del mes. Hay dos opciones: asumirlo o revisar qué tiene sentido seguir haciendo en la CI.

Antes metíamos de todo en la CI porque no dolía. Ahora toca decidir qué se lanza en cada fase (local, draft PR, PR, tras merge, manual), si todo o solo una parte, y cuántas veces: si algo rompe dos de cada mil ejecuciones, no merece correr en cada PR.

Esto es lo que estamos probando:

• Subimos las PRs en draft con jobs distintos dentro y fuera del draft.

• Cuando una PR se actualiza, cancelamos la ejecución en curso.

• Lo que ya se comprobó en local no se repite en la PR. Se comprueba tras el merge, por si la integración rompe algo.

• Autorrebaseamos antes de mergear para proteger main, y cada rebase relanza la CI entera. Quizá pueda esperar al merge.

• Optimizamos build, tests y linting, porque cada minuto se multiplica por el número de ejecuciones.

03. XP ya lo dijo: el feedback, constante y temprano

Cuanto antes sabes que algo va mal, más barato es corregirlo. Extreme Programming lo llamó feedback rápido y con la IA aplica más que nunca: si delegas una tarea larga y solo miras el resultado, te ha costado tiempo, tokens y retrabajo.

Estamos adelantando el feedback en varios puntos:

• Al definir la tarea, un subagente refuta los criterios de aceptación buscando contradicciones y criterios no comprobables.

• Mientras el agente trabaja, otro vigila cómo razona y le da feedback (el patrón Hawk Agent). Claude Code está experimentando algo similar con los observer agents.

• También probamos el advisor de Claude Code: el agente para y consulta a un modelo igual o más capaz. Sonnet trabajando y Opus aconsejando.

• Adelantamos a local lo que corría en la CI. Rachel Laycock lo defiende en el blog de Martin Fowler: con la IA multiplicando el código, revisar en la PR no escala. Si el feedback vale, acércalo al momento de decidir.

Enlaces de interés

Uncle Bob duda de su propio harness

Uncle Bob lleva meses defendiendo un harness de herramientas deterministas para agentes (Gherkin, tests, métrica CRAP, mutation testing) y, viendo cuánto han mejorado los modelos, empieza a pensar que quizá los está sobrerrestringiendo, y mucho.

Runway presenta Solaris

Runway, empresa de IA generativa de vídeo e imagen conocida por sus modelos GenAI, presenta el primero de su familia Interface World Models: genera la interfaz de una app o web en tiempo real mientras el usuario interactúa, un fotograma por cada clic o arrastre, sin código intermedio.

¿Y si a las empresas de IA les interesa parecer peligrosas? - MultiVersial

Tras una semana de dimisiones y mensajes apocalípticos sobre frenar la IA, Carlos Molina plantea que a OpenAI y Anthropic les conviene amplificar el peligro: el riesgo justifica regulación con barreras de entrada y financiación estatal como cuestión de seguridad nacional.

Knowledge Compressor - GitHub Next

Compresión de documentación técnica guiada por agentes: saca preguntas sobre el original, comprime y comprueba que siguen respondiéndose. Deja los tokens a la mitad sin apenas perder respuestas. Cuando la documentación que damos a los agentes crezca y se reutilice, el recorte ahorra en cada sesión.

Una vuelta y media

Por Pablo Albizu

Unas cervezas, una barbacoa de empresa y un buen melón: ¿y si las horas extras ahora pueden hacerlas los agentes?

2025, un equipo enfocado en el desarrollo de una nueva versión de una aplicación móvil para llegar a Black Friday. Pico de trabajo, tocaba apretar y meter horas extra.

2026, mismo equipo, mismas fechas, reto parecido: rediseñar por completo la app. Solo cambiaba una cosa: ahora tenían La Maquineta, una máquina capaz de delegar la ejecución de tareas en la IA.

Ahora, pueden dejar a la IA trabajando unas horas el fin de semana sin aumentar en la misma proporción las horas metidas por el equipo. Lo hicieron, pero una persona agotó la capacidad contratada. Gasto extra ese fin de semana: 100€. Lo pagamos y punto, pero ¿y si hubiesen sido 5.000€?

De momento, tenemos bastante claro que las licencias de IA son herramientas de trabajo y su coste va dentro de nuestras tarifas. Pero si mañana puedo gastar 5.000€ más y conseguir que un equipo tenga bastante más capacidad durante unas semanas, ya no tengo tan claro que estemos hablando de lo mismo.

De hecho, puede ser el propio cliente el que diga: “estas dos semanas meted mucha más caña con los agentes y si hay que gastar 10.000€ más, gastadlos”.

Y esto no va solo de consultoría. Una empresa de producto puede hacer exactamente lo mismo con sus propios equipos.

Hasta ahora teníamos claro que si metías IA dentro de una funcionalidad aparecía un coste variable: cuanto más la usaban tus clientes, más tokens gastabas. Puede pasar lo mismo cuando construyes la propia funcionalidad.

Antes, para sacar más trabajo, necesitabas más personas o más horas. Ahora tienes otra palanca. Podemos añadir a la habitual jornada laboral horas de trabajo que hacen los agentes. Las personas siguen teniendo que dirigir, revisar y validar ese trabajo, y en un pico como este seguramente también toque meter alguna hora más, pero el rendimiento de esas horas es mucho mayor. La relación directa entre horas y output (output, no valor) se ha roto.

Eso sí, para poder decir “gastemos 10.000€ más” primero tienes que haber construido una máquina capaz de convertir ese dinero en trabajo útil. No basta con comprar más tokens y esperar que salga más software.

Nosotros llevamos tiempo trabajando precisamente en construir esa máquina y nos hemos encontrado con una consecuencia que afecta directamente a nuestros economics.

¿Empezaremos a estimar el trabajo no solo en horas, sino también en tokens? ¿Tendremos un apetito en tiempo y en gasto de IA?

¿Tendrán los equipos un presupuesto para agentes que puedan abrir o cerrar dependiendo de cuánto quieran acelerar?

¿Hasta qué punto podremos convertir más gasto en IA en más capacidad del equipo?

Como diría mi padre: con dineros, caramelos. Habrá que ver cuántos.

Enlaces de interés

Uber gasta 36.000$ al año en IA por ingeniero - Estrategia de Producto

Simón pone números al gasto de Uber en herramientas de IA. 36.000$ por ingeniero y año. Lo de los 100€ igual dura poco.

¿La IA en desarrollo va a ser pay-to-win? - Gorka Moreno

Gorka tira del mismo hilo, pero en dirección contraria: gastar más no significa producir proporcionalmente más. Rendimientos decrecientes, nuestros números en 540 y cuánto estamos pagando realmente por los tokens que consumimos.

IA en 540

01. Cuando lo caro sale barato

Quien haya trabajado con Sentry sabe el horror que es revisarlo cada mañana: ruido, errores repetidos y fallos esporádicos que se ignoran porque resolverlos no compensa. Uno de nuestros equipos quiso automatizar el triaje con IA para dejar preparada cada tarea con la causa y la posible solución.

Para contener el coste, montaron un proceso multiagente sobre Opus. Uno recogía los errores, otro buscaba la causa raíz y un tercero discutía el análisis. Aun así, casi nunca encontraban la causa raíz y acababan proponiendo parches para los síntomas. El proceso era costoso y complejo, así que lo pausaron.

Cuando alguien del equipo tuvo que hacer el triaje, decidió hacerlo directamente con Fable y consiguió un resultado mejor con un proceso más simple y barato.

Aprendimos que, en trabajos de causa raíz, abaratar el modelo puede encarecer todo el proceso. La próxima vez comprobaremos primero si un modelo más capaz resuelve la tarea de forma más efectiva y eficiente.

02. La pieza que nos faltaba para evaluar skills

Hasta ahora, para probar nuestras skills solo teníamos Skill Creator, el plugin oficial de Anthropic, y se quedaba corto. Ayuda a crearlas y añade evals básicos de activación y regresión. Pero cada sesión hay que lanzarla y revisarla a mano. No puedes dejarla automatizada.

Igual que el código, una skill necesita tests que comprueben si sus instrucciones siguen haciendo lo que esperamos. Los llamamos evals.

Promptfoo cubre ese hueco de forma bastante completa. Comprueba la activación de la skill, su comportamiento y el resultado. Usa reglas deterministas para lo que se puede comprobar sin ambigüedad y deja el juez LLM para lo demás. Todo se define en un fichero de configuración.

Estamos viendo cómo integrarla en el flujo. Hoy validamos las skills por sensaciones, pero para evolucionarlas sin romperlas necesitaremos evals igual que necesitamos tests para el software.

03. Agentes: tornados tácticos en potencia

Seguimos dándole vueltas a una pregunta: cuando los agentes escriben buena parte del código, ¿dónde aportamos más valor los desarrolladores? Boris Cherny, creador y responsable de Claude Code, y Matt Pocock, referente en desarrollo con IA, han cruzado en X dos ideas que separan cosas que solemos meter en el mismo saco: escribir código y construir software.

Boris distingue tres niveles: codificar, resolver el trabajo adyacente (depuración, rendimiento y diseño de sistemas) y hacer cualquier trabajo con un ordenador. Su tesis es que Claude ya ha superado el primero, participa en el segundo y empieza a asomarse al tercero.

Matt pone el contrapunto con una idea de John Ousterhout en A Philosophy of Software Design. Ousterhout distingue entre una programación táctica, que saca adelante la siguiente tarea, y otra estratégica, que cuida la salud del código. Llama «tornados tácticos» a quienes producen muchísimo y dejan tras de sí un sistema cada vez más difícil de cambiar.

Así, los agentes son tornados tácticos con esteroides. Producen código a toda velocidad. A nosotros nos toca aportar la estrategia y la mantenibilidad: decidir la arquitectura y poner controles para que el código no se degrade.

Enlaces de interés

El punto ciego de grill-me

En 540 usamos mucho grill-me y lo recomendamos porque ayuda a cerrar las decisiones antes de implementar. Ujue Agudo señala su punto ciego: cada pregunta llega con una respuesta recomendada que puede anclar nuestro razonamiento. Su propuesta: responder primero y dejar que la IA contraste después.

Uncle Bob y los fundamentos del software en la era de los agentes

Matt Pocock conversa con Uncle Bob sobre qué cambia cuando dejamos de escribir cada línea de código, dónde siguen haciendo falta controles y qué prácticas de la programación tradicional tiene sentido trasladar a los agentes.

Una vuelta y media

Por Pablo Albizu

Mi tío es cazador y, por lo que he entendido después de unas cuantas conversaciones con él, cazar perdices debe de ser algo parecido a jugar la Champions de la caza.

Cuando habla de ello nunca le escucho hablar demasiado de escopetas. Me habla de conocer el terreno, de saber dónde colocarse, de los perros y de saber leerlos, de caminar mucho y de desarrollar algo que desde fuera seguramente llamaríamos instinto.

Al final, matar una perdiz es difícil, pero lo realmente difícil es ponértela a tiro.

Me gusta porque habla de todo lo que ocurre antes del disparo. Y últimamente pienso que a nosotros nos falta un poco de respeto precisamente por eso.

La IA escribe código y los desarrolladores van a desaparecer. Como un desarrollador experimentado produce mucho más, ya no hacen falta equipos. Managers, tampoco. Alguien construye una aplicación haciendo vibe coding y desarrollar productos tecnológicos se ha vuelto trivial. Las consultoras también van a desaparecer, cobrar por horas ha muerto y ahora todos vamos a cobrar por impacto.

No me sorprende que nos preguntemos cómo va a cambiar nuestro trabajo. Sería bastante hipócrita criticarlo justo debajo de una sección llamada “IA en 540”. Lo que me cabrea es lo poco que parecemos respetar la profundidad de lo que hacemos.

No imagino a un médico cuestionando su profesión porque una tecnología detecte un cáncer mejor que él, ni a un arquitecto porque aparezca una nueva forma de construir edificios. Cambiará lo que hacen y cómo lo hacen, pero parecen tener claro que su trabajo es bastante más profundo que la herramienta que utilizan.

Hace poco visitamos una empresa grande, con décadas de historia y que cotiza en bolsa. Llegas allí, ves sus sistemas y procesos y enseguida piensas todo lo que harías diferente. Tú con tu Claude Code, claro.

Hasta que empiezas a rascar.

Las decisiones tienen historia. Los sistemas dependen de otros sistemas. Hay personas, clientes, presupuestos, relaciones, intereses y riesgos que desde fuera no ves. Entender todo eso antes de decidir qué hay que construir también es nuestro trabajo.

Quizá parte del problema venga de lejos. Durante años hicimos una virtud de no parecernos a una profesión seria. Mientras otros llevaban traje, nosotros camiseta y pantalón corto. Zuckerberg dirigía una de las empresas más importantes del mundo en sudadera y aquello nos parecía la demostración de que muchas de las convenciones anteriores eran una gilipollez.

Y seguramente muchas lo eran. El problema es que nos creímos tan importantes por dominar la tecnología que acabamos pensando que todo lo demás era secundario.

Ahora llega la IA y resulta que hacemos justo lo contrario: como una máquina empieza a dominar nuestra parte, parece que los secundarios somos nosotros.

Pero las organizaciones, las personas, las relaciones, los incentivos, la historia y, sobre todo, los problemas que hay que resolver siguen ahí.

Tenemos una oportunidad increíble para cambiar cómo trabajamos, pero también para madurar un poco como sector. Porque esto puede poner muchas cosas patas arriba.

Madurar no consiste en negarlo. Consiste en afrontar el cambio sin asumir que todo lo que sabíamos hacer hasta ayer era una gilipollez.

Mi tío lleva muchos años caminando detrás de perdices. Supongo que por eso tiene claro que disparar es solo una parte.

Lo difícil es ponértela a tiro.

Enlaces de interés

La tecnología suele ser el legacy fácil

Javier G. Recuenco explica por qué en las grandes organizaciones los incentivos, la cultura y la estructura pueden ser problemas mucho más difíciles de mover que la propia tecnología. Una buena cura para llegar desde fuera pensando que sabes todo lo que habría que cambiar.

Por qué es tan difícil definir los equipos

John Cutler explica por qué entender cómo funciona realmente una organización es bastante más difícil que dibujar un organigrama. Incentivos, poder, presupuestos y carreras profesionales hacen que muchas veces describir la realidad tenga un coste político.

IA en 540

01. Ahora cualquiera puede atacar tu web

El incidente entre OpenAI y Hugging Face demostró que los agentes ya pueden encontrar y encadenar ataques contra sistemas. Nos hizo pensar en cómo usar esa misma capacidad para descubrir vulnerabilidades antes de que alguien las explote.

Lo probamos con un WordPress de pruebas que replica una configuración real. Necesitábamos un modelo que aceptara tareas ofensivas dentro de un entorno controlado. Fable 5 limitaba estas peticiones, así que usamos GLM-5.2, un modelo abierto comparable a Opus 4.6 en tareas de seguridad, a través de OpenRouter y una versión de OpenCode preparada para pentesting.

Hemos recogido la prueba completa en este informe. El agente identificó 38 posibles vías de ataque y aprovechó un fallo en un plugin de calendario sin actualizar. Desde ahí encadenó 34 peticiones para recuperar la contraseña del administrador y entrar con esa cuenta, sin que tuviéramos que guiar cada paso.

Si nosotros hemos llegado hasta aquí, alguien que se dedique a atacar podría llegar mucho más lejos. Ahora que la IA permite aprovechar cualquier descuido con mucha más rapidez, vemos imprescindible incorporar revisiones de seguridad y mantener al día las versiones y los parches.

02. ¿Cuánto te falta para dejar de revisar cada línea?

Hace poco contamos que Uncle Bob ya no revisa el código que escriben sus agentes porque cada cambio supera una serie de comprobaciones deterministas. Para saber qué nos falta, hemos convertido su marco en una skill.

La skill comprueba si un repositorio puede verificar cambios sin depender de que una persona lea cada diff. Para ello mide nueve controles sobre especificación, tests y calidad del código. Puntúa cada uno de 0 a 4, señala el fichero y la línea que lo justifican y propone entre tres y cinco mejoras priorizadas por confianza y esfuerzo.

Hemos compartido la skill para que audites tu proyecto. La vamos a aplicar en los nuestros y compartiremos los resultados.

03. Que Claude Code no llene tu código de comentarios

Seguimos tratando de domar a Opus 5. Por mucho que las reglas le indiquen que no escriba comentarios, los añade y consigue justificarlos todos.

Siempre hemos preferido que el código se explique solo y sea la única fuente de verdad. Si un bloque necesita un comentario, solemos verlo como un fallo de expresión: antes mejoramos el nombre o extraemos un método. Los comentarios pueden quedarse desactualizados y acabar mintiendo.

Hemos convertido la regla en un hook de Claude Code. Se lanza antes de escribir y rechaza cualquier comentario nuevo, respeta los existentes y exige aprobación para las excepciones. Cuando una regla se puede comprobar, dejamos de pedírsela al agente y la convertimos en un control determinista.

Enlaces de interés

AirLLM: modelos enormes con poca VRAM

AirLLM carga el modelo por capas para reducir mucho la memoria necesaria durante la inferencia. Esto permite ejecutar modelos muy grandes en una sola GPU con poca VRAM, como Llama 3.1 405B en 8 GB.

Asientos Premium para ChatGPT Business

ChatGPT Business añade asientos Premium con cinco veces más uso, sin el límite de cinco horas. La suscripción para equipos se equipara así a las opciones que ya ofrece Claude Code y elimina uno de los principales inconvenientes de nuestra prueba de Codex: ser bastante más caro al tener que pasar enseguida a pago por uso.

OpenAI amplía Daybreak

Más organizaciones podrán acceder a los modelos avanzados de ciberseguridad de OpenAI a través de socios aprobados: Blue cubre flujos defensivos y Red trabajos más sensibles. Como vimos al probar GLM-5.2, la idea es poner esa capacidad de ataque en manos de los defensores para que encuentren y corrijan vulnerabilidades antes de que alguien las explote.

Una vuelta y media

Por Pablo Albizu

Hace unos meses vivimos un experimento en uno de nuestros clientes: quitar a los Product Managers de un equipo y acercar directamente a los desarrolladores a los stakeholders.

Unos meses después, el experimento ha funcionado pero no igual para todos.

Hay personas que se han adaptado perfectamente al nuevo rol de “product builders”. Hace tiempo se pasaron el “juego tecnológico” y lo que les motiva de verdad es el impacto en el negocio. Hablan con stakeholders, entienden hacia dónde van, gestionan prioridades, aterrizan el producto, levantan la mano si la cosa se tuerce y además lo ejecutan con IA.

El hombre orquesta. El mirlo blanco. Los Pogacar del ciclismo.

El problema es que no todo el mundo tiene la misma experiencia ni las mismas habilidades innatas. Una cosa es tener product mindset y otra es pedirles que gestionen: coordinar dependencias, comprometer fechas, perseguir temas, comunicar avances, detectar que algo se está torciendo antes de que sea demasiado tarde y responsabilizarse de que todo llegue a buen puerto.

Hay personas muy buenas técnicamente, y con muchísimo product mindset, que están sufriendo con el cambio. No porque no entiendan el negocio, sino porque de repente les estamos pidiendo habilidades de gestión, comunicación, coordinación y liderazgo que antes no eran una parte tan importante de su trabajo.

Así que, ante este panorama, tenemos dos alternativas.

La primera es diseñar nuestros equipos pensando que todos sus miembros deben ser ingenieros excepcionales capaces de moverse desde una conversación de negocio hasta la implementación. Equipos pequeños y muy productivos.

Luego llegará Paco con las rebajas: tendremos que pagar lo que cuestan esas personas, competir por ellas y aceptar que hemos reducido muchísimo el conjunto de gente que puede trabajar con nosotros.

Y, muy importante, comprobar que tenemos suficientes problemas a la altura de su ambición. Un equipo lleno de mirlos blancos también necesita trabajo para mirlos blancos. Pogacar quiere correr el Tour de Francia, no el Gran Premio Miguel Induráin de mi pueblo, Estella.

La segunda, aceptar equipos más heterogéneos y construir un nuevo proceso incluyendo la IA alrededor para que personas con capacidades distintas puedan funcionar bien juntas. Ni tan corto ni tan calvo.

Aquí aparece una posibilidad, podemos acabar teniendo ingenieros capaces de entender un problema, diseñar el producto y construir los sistemas de agentes que producen el software.

Y otros cuyo trabajo se parezca más a controlar y mejorar la cadena de producción: comprobar que el sistema funciona, asegurar la calidad del resultado y modificar el propio proceso cuando algo falla. Jamon Holmgren lo explica aquí perfectamente.

No son dos niveles del mismo trabajo, sino dos trabajos diferentes.

Y si realmente terminan siendo trabajos distintos, también tendrán distinto valor en el mercado: salarios, oportunidades, capacidad de negociación y carreras profesionales diferentes.

Quizá estemos viendo cómo una profesión empieza a dividirse en dos.

Enlaces de interés

In five years, everyone will be a product manager - Gojko Adzic

Equipos más pequeños, más autonomía y responsabilidades de producto cada vez más repartidas. La trampa: asumir el trabajo de un PM no significa saber hacerlo.

De desarrollador a Product Engineer

Una escalera de 12 pasos para pasar de ejecutar tickets a entender el negocio, hablar con usuarios, liderar discovery y responsabilizarse del producto.

5 comportamientos que definen a un Product Engineer - Javier Escribano

Cuando los desarrolladores dejan de ser los que construyen - Gorka Moreno

Si la IA permite que producto y negocio construyan directamente, quizá el trabajo del desarrollador pase a ser crear las herramientas y garantías para que puedan hacerlo.

No todos vamos a convertirnos en “builders” — Lee Robinson

IA en 540

01. Decide cómo te habla Claude Code

Opus 5 se enrolla, mezcla niveles de detalle y cuesta seguirle. Detectamos el problema hace dos semanas y la misma queja se ha repetido bastante.

Pedirle que aclare la respuesta funciona, pero tienes que hacerlo cada vez. Nos ha funcionado mejor configurar un output style propio, para indicarle cómo queremos que nos hable durante la conversación.

Claude Code acaba de añadir Concise, que va directo al resultado y da respuestas cortas. Sigue teniendo sentido crear uno a medida, si además quieres personalizar la estructura y añadir reglas concretas.

02. Migrar código que antes no compensaba

Anthropic migró Bun de Zig a Rust: más de un millón de líneas en 11 días.

Ahora han explicado el método, usado ya en diez proyectos. Primero preparan y validan los tests para comprobar que la nueva versión hace lo mismo que la anterior. Después afinan las reglas de migración con una muestra y finalmente lanzan agentes a migrar y revisar todo el código hasta que la nueva versión compila, arranca y supera los tests.

Lo interesante es cómo cambia el proceso: si un fallo se repite, no arreglan el código generado. Corrigen las reglas y regeneran. Los humanos dejan de hacer la migración para centrarse en mejorar el sistema que la hace. Así vuelven viables migraciones que antes eran demasiado costosas.

Anthropic ha publicado el kit para ponerlo en práctica. Nos interesa probarlo para modernizar sistemas de diseño limitados por librerías de componentes generalistas y sacar lógica de negocio de procedimientos almacenados.

03. La IA se queda corta si repites lo de siempre

En dos casos distintos, la IA aceleró el trabajo sin transformar el proceso.

Agustín Cuenca, con 30 años montando empresas de software, explicó que su equipo preparó una propuesta diez veces más rápido, pero con el mismo formato, flujo de revisión y proceso comercial.

A raíz de nuestra decisión de subir las PRs en draft, Francesc Pla, CTO de SeQura, propuso dejar de simular el flujo para humanos: una persona fija el plan antes de empezar y los agentes trabajan en local hasta dejar la PR lista para mergear.

Dos ejemplos en los que hemos cambiado el proceso: sustituir los PowerPoints de las propuestas comerciales por prototipos navegables y convertir una aplicación para generar formularios desde Excel en varias skills.

04. Evita que la IA se invente tu diseño

En uno de nuestros proyectos, cuando el agente no encontraba un componente adecuado en el sistema de diseño, elegía otro o inventaba uno que encajase. Tenía acceso al código, pero eso no era suficiente para saber qué componente usar ni cómo combinarlo.

Para evitarlo, construimos un MCP con el que puede consultar el sistema. Todo se genera desde el código y la documentación existentes, así no mantenemos una fuente de verdad nueva.

Para añadir un modal, encuentra el componente, consulta sus propiedades, revisa el orden de los botones y recupera una story con el patrón de código.

Storybook muestra el sistema a las personas y el MCP permite que los agentes también lo consulten.

Enlaces de interés

Tus sesiones de Claude Code pueden hablar entre ellas

Ahora, dos sesiones independientes pueden pasarse hallazgos, decisiones o avisos mientras trabajan en paralelo. Solo intercambian el mensaje que preparan, sin compartir el historial de la conversación ni los ficheros.

Explican el incidente entre OpenAI y Hugging Face

Dos miembros de OpenAI que trabajan en alineamiento, seguridad e infraestructura reconstruyen cómo varios agentes de una evaluación interna compartieron hallazgos, escaparon de su entorno y acabaron comprometiendo infraestructura de OpenAI y Hugging Face.

«Con IA ya no leo código»

Javi Santana defiende que decidir qué código necesita revisión, comprensión o ajustes siempre ha sido parte del trabajo de ingeniería. La IA permite centrar el esfuerzo en lo que importa.

Herramientas en el radar

Argent

Herramienta para que los agentes controlen, depuren y analicen desde la terminal aplicaciones para iOS y Android, además de aplicaciones Electron o Chromium. Promete mejoras sobre agent-device, que es lo que nosotros usamos.

Una vuelta y media

Por Pablo Albizu

Esta semana he leído Speed Above All Else, un artículo que parte de una idea con la que estoy de acuerdo: velocidad y rigor no son incompatibles.

Me ha hecho gracia porque hace unos años en 540 hicimos pegatinas con una frase que parece decir lo contrario: “Vísteme despacio, que tengo prisa”.

Durante años he visto en desarrollo de software justificar casi cualquier cosa porque “hay que ir rápido”. No hacemos tests porque hay que ir rápido. No pensamos demasiado el diseño porque hay que ir rápido. Es un MVP, ya lo haremos bien más adelante.

Y siempre me ha parecido una falsa dicotomía.

Para ir rápido no tienes que dejar de hacer las cosas bien. Otra cosa es ser pragmático. Hay momentos en los que toca tomar atajos, asumir deuda o hacer una solución mucho más sencilla. Pero tienes que saber qué estás haciendo, por qué y en qué contexto.

Para mí, ahí está gran parte del oficio. El que tiene conocimiento y criterio no activa un modo ”rápido” en el que de repente se le olvida todo lo que sabe. Simplemente sabe dónde puede correr y dónde no.

Hace un par de años di una charla sobre calidad de software y hablaba de la Design Stamina Hypothesis. La idea es sencilla: puedes ir muy rápido al principio si no te preocupas demasiado por cómo estás construyendo, pero esa ventaja desaparece cuando cada nuevo cambio empieza a costar más que el anterior.

No sabemos exactamente cuándo ocurre. Pero todos los que hemos trabajado en una base de código poco cuidada sabemos lo rápido que puede pasar.

Por eso cada vez me gusta más pensar que la capacidad de ir rápido se construye.

Los tests, una arquitectura razonable, la automatización o tener el conocimiento importante fuera de la cabeza de cuatro personas no son cosas que hacemos porque nos guste hacer software bonito. Son, entre otras cosas, lo que nos permite cambiarlo rápido mañana.

Y justo hace unas semanas leí otro artículo de Jason Fried que añade un matiz que me gusta. Dice que desarrollar más rápido, hacer más commits, trabajar más horas o poner más personas o agentes a trabajar no hace que el producto sea mejor.

Lo compara con un restaurante: sería como valorar la comida por el número de cocineros que había en la cocina, las horas que trabajaron o la cantidad de pedidos que sacaron. Al cliente todo eso le da igual. Lo que le importa es el plato.

Pero creo que podemos darle una vuelta más.

Al cliente le da igual cómo tengas la cocina, pero el estado de tu cocina determina tu capacidad para sacar el siguiente plato.

Puedes no limpiar nada para sacar el plato de ahora un poco antes. Y seguramente a veces sea exactamente lo que tengas que hacer. Pero prueba a hacerlo durante cien platos seguidos.

Con la IA podemos producir mucho más software, abrir más PRs y poner más agentes a trabajar. Pero eso no significa necesariamente que estemos aportando valor antes.

Hace poco escribía precisamente sobre empresas que quieren “meter IA para ir más rápido” cuando no tienen tests, procesos claros, una arquitectura mínimamente cuidada o el conocimiento necesario por escrito.

No necesitan producir más rápido. Necesitan construir la capacidad de ir rápido.

Aunque para conseguirlo, a veces, tengan que ir un poco más despacio.

El vísteme despacio, que tengo prisa...

Enlaces de interés

Lean Software Development: Construyendo con calidad - Eduardo Ferro

Una reflexión sobre cómo construir calidad dentro del proceso en lugar de tratarla como algo que añadimos después.

Por qué hay que apretar - Javi Santana

No siempre corres para producir más. A veces corres porque no tienes ni idea de si estás haciendo lo correcto y necesitas descubrirlo cuanto antes.

IA en 540

01. Entorno de desarrollo: adiós a JetBrains

En octubre cancelaremos las 20 licencias de JetBrains. Con lo fans que hemos sido siempre.

Están saliendo herramientas más pensadas para trabajar con agentes que para editar código, los ADE (Agent Development Environments). Hasta Spotify ha sacado el suyo.

El IDE de HumanLayer no nos sirve: impone un flujo que ya tenemos resuelto y cuesta 100 $ al mes por persona.

Hemos probado t3.codes. Tiene cosas buenas a nivel de gestión de sesiones, pero su capa para conversar con el agente pierde contra el CLI nativo de Claude Code.

Queremos probar Herdr. Mientras tanto, seguimos con Orca, lo mejor hasta la fecha.

02. Contexto de dominio: mantenerlo es clave

Casi todos usamos grill-me, la skill de Matt Pocock que interroga antes de empezar para acotar la tarea y el diseño de la solución.

Un equipo usa además grill-with-docs que mantiene un glosario de dominio en CONTEXT.md y registra en docs/adr/ decisiones difíciles de revertir, sorprendentes y con una contrapartida real. Así, el contexto se acumula entre tareas para no repetir dudas y crear un lenguaje ubicuo.

Lo difícil es mantenerlo al día. La skill no evita que CONTEXT.md se desactualice y los ADRs no registran bien cuándo una decisión invalida otra. En un proyecto nuevo salieron 13 en una semana y varios quedaron obsoletos.

Vamos a darles una vuelta y media a nuestras skills, fijándonos en cómo usa Matt ese contexto al implementar.

03. Qué es realmente SDD

Vemos confusión sobre Spec-Driven Development (SDD), un término poco definido para enfoques donde una especificación guía la implementación con IA.

Matt Pocock no considera sus skills spec-driven. En su flujo, la especificación es un detalle desechable, mientras que CONTEXT.md y los ADRs documentan lo que el código no puede describir.

Birgitta Böckeler propone tres niveles en el blog de Martin Fowler:

• Spec-first: guía la implementación y puede borrarse.

• Spec-anchored: se conserva para la evolución y el mantenimiento.

• Spec-as-source: es la fuente principal y la persona no toca el código.

Nuestro enfoque encaja en spec-first: aclaramos qué construir y por qué antes de delegar. Después la especificación sobra.

04. Uncle Bob no lee el código

Uncle Bob tiene 73 años, escribió Clean Code y lleva décadas defendiendo la disciplina en el desarrollo de software. Ahora ha provocado revuelo al contar que ya no lee el código de sus agentes. No porque haya dejado de importarle la calidad. Al contrario: en vez de revisar cada diff, hace iterar a los agentes hasta superar una batería de comprobaciones deterministas.

Entre ellas están la métrica CRAP (cruza complejidad y cobertura de tests), la detección de duplicados, las reglas de arquitectura y el mutation testing, que mete fallos a propósito en el código para comprobar si los tests los cazan.

Ya hacemos buena parte de esto, pero usaremos su lista como marco para detectar qué falta en cada proyecto y fijar validaciones deterministas que nos permitan dejar de estar encima de cada diff.

Enlaces de interés

Long ramble sessions with LLMs

Para Andrej Karpathy, a veces funciona mejor hablarle al modelo durante diez minutos y volcarle todo lo que tienes en la cabeza, aunque salga desordenado, que buscar el prompt perfecto.

AI Skills for Real Engineers

Matt Pocock ha convertido su proceso de ingeniería con agentes en skills pequeñas, enfocadas y complementarias. Nos convence mucho este enfoque, que permite incorporar solo lo que necesitas.

Where We Actually Are

Francesc Pla sostiene que implementar se ha abaratado mientras las empresas gastan presupuestos enormes sin resultados medibles. Ahora lo difícil es decidir qué construir y ver si funciona.

Diseño y desarrollo, desde el principio · 540

Olaia cuenta cómo estamos cerrando la brecha entre diseño y desarrollo: Storybook y el código como fuente de verdad, Figma para bocetar y documentación que los agentes pueden consultar.

Herramientas en el radar

Directorio de Agent Development Environments · 540

La lista curada de ADEs que tenemos en el radar para gestionar varios agentes de código desde un mismo entorno.

Una vuelta y media

Construir para durar

Esta semana contaba en LinkedIn que estoy caliente con comprarme un Mercedes SL R129 de 1990.

Pensando en por qué me atrae tanto un coche de hace más de treinta años, en un momento en el que todo a mi alrededor parece cambiar cada vez más rápido, acabé llegando a una idea: me gustan las cosas que duran.

Después de publicar aquello leí Nunca posees un Casio, de Joan Tubau. El artículo cuenta la historia de Patek Philippe y de cómo dejó de vender precisión, materiales o maquinaria para vender otra cosa: la idea de que un reloj podía sobrevivir a su propietario.

No compras algo para consumirlo. Lo custodias hasta que llegue el siguiente.

Esa palabra, custodiar, me hizo darle otra vuelta al Mercedes. Si sabes que algo va a ser sustituido dentro de poco, optimizas para hoy. Si aspiras a que siga ahí dentro de diez, veinte o cincuenta años, empiezas a tomar decisiones diferentes.

Y no vale solo para los objetos. En 540 llevamos doce años diciendo que queremos construir una empresa en la que podamos jubilarnos. Quizá eso significa que tampoco somos del todo sus propietarios, sino sus custodios. Nos toca hacerla avanzar, transformarla cuando haga falta y procurar dejarla mejor preparada para los que vengan después.

Pensándolo ahora, esta obsesión por la durabilidad también ha estado siempre en nuestra manera de construir software. Hace años dábamos una charla que titulábamos “Desarrollo de aplicaciones antifrágiles”, robándole el término a nuestro amado Taleb, sobre cómo construir aplicaciones mantenibles.

Hablábamos de arquitecturas limpias, de aislarnos de frameworks y APIs, de testing, de gestión de errores… En el fondo, muchas de aquellas decisiones perseguían lo mismo: protegernos de aquello que sabíamos que iba a cambiar y poder seguir cambiando el software sin romper por el camino lo que ya funcionaba.

Construir software que dure nunca ha significado construir software que no cambie.

Y ahora la IA ha reducido radicalmente el coste de producirlo. Podemos escribir más código, probar más ideas y construir más cosas que nunca. Pero que podamos construir muchísimo más no significa necesariamente que debamos hacerlo.

Si estamos construyendo muchísimo más software gracias a la IA, ¿cuánto de todo lo que estamos produciendo hoy seguirá mereciendo existir dentro de diez años?

Quizá una de las habilidades importantes de los próximos años no sea solo aprender a construir más rápido, sino aprender qué merece la pena construir. Y, cuando lo encontremos, construirlo bien.

Por eso siempre hemos apostado por el largo plazo: ser muy rápidos con las cosas que pueden cambiar y muy pacientes con las que importan de verdad.

Los modelos, las herramientas y nuestra manera de desarrollar software cambiarán. Pero la confianza, las relaciones, el oficio, el trabajo bien hecho y la intención con la que construimos deberían moverse a otra velocidad.

No sé si acabaré comprándome el Mercedes. Pero empiezo a pensar que lo que me atrae de él no es que tenga más de treinta años, sino que alguien lo construyó sin saber quién estaría conduciéndolo treinta años después.

Y todavía está aquí.

Enlaces de interés

The Magic Behind Bezos and Buffett: Things That Don’t Change · Farnam Street

Es más útil pensar en lo que no va a cambiar que intentar predecir lo que sí.

El efecto Lindy - Nassim Nicholas Taleb

Para determinadas cosas, haber sobrevivido mucho tiempo es precisamente una señal de que pueden seguir haciéndolo. En un mundo obsesionado con lo nuevo, el tiempo también es evidencia.

En esta edición:

• Qué conclusiones sacamos tras dos semanas con Opus 5, dónde sigue haciendo falta una persona cuando automatizas el ciclo entero y cómo delegamos la épica entera. Nos fijamos en los modelos guardianes e indagamos en cómo funciona un modelo por dentro.

• Nuestra amada opcionalidad.

  ---

IA en 540

01. Opus 5

Dos semanas con Opus 5 y no nos convence: va más lento, habla más, se le entiende peor y gasta más tokens.

Jarred Sumner, creador de Bun, recomienda ajustar el esfuerzo de razonamiento a medium, porque el high itera de más y hace más de lo que le has pedido.

Anthropic ha quitado el 80% del system prompt de Claude Code, y nos cuadra: donde más reglas le hemos puesto, peor va.

Para cuando no le entiendes, Matt Pocock ha publicado la skill wait-what, que le hace reformular en lenguaje llano y con el vocabulario del proyecto.

Veníamos de cambios menores que no se notaban tanto, y aquí hemos aprendido que un cambio de versión mayor no es directo.

02. Por qué fallan las factorías de software

Comentamos la tercera charla de la serie, en la que Dex Horthy (HumanLayer) cuenta cómo evoluciona el desarrollo en una factoría de software hasta que ya nadie lee el código.

Cuando automatizas el ciclo entero aparecen atascos nuevos, y él señala dos puntos donde más vale que siga habiendo alguien: la definición y el diseño técnico, y la revisión del código.

Y reivindica los diagramas y la arquitectura, porque la factoría falla cuando ya nadie controla lo que ha construido.

03. La Maquineta

En la reunión del grupo de ai-leads vimos funcionando La Maquineta. Le delegas una épica entera y ella la implementa, la revisa y la corrige tarea a tarea. Tú te quedas para mergear y para validar que la épica hace lo que tenía que hacer.

Cuando necesita algo te lo pide como un compañero más en la tarea de Jira o en la PR de GitHub.

Todo depende de definir bien la épica y sus tareas, y ahí es donde toca poner el foco y el criterio, porque lo demás se automatiza.

04. Modelos que vigilan al modelo

Mistral AI ha publicado Shieldstral, un modelo guardián que filtra preguntas y respuestas. Lo aceptable depende del contexto, y lo válido en ciberseguridad puede ser dañino en salud mental.

La novedad es que lleva las reglas en el system prompt en lugar de en el entrenamiento. Y solo pesa 3B, con pesos abiertos.

Merece la pena seguirle la pista a esta familia de modelos pequeños y especializados para vigilar al grande.

05. Entender los modelos

Karlos G. Liberal, siempre intentando ir un pasito por delante, vino a nuestra jam-ai en La Nave para arrojar luz sobre el artículo de Anthropic A global workspace in language models, y lo hizo con una charla interactiva muy clarificadora.

Si te interesa cómo funciona un modelo por dentro, capa a capa, pídesela.

Enlaces de interés

Cursor Router

Otro modelo especializado, en este caso dirigido a enrutar cada petición automáticamente al modelo más capaz para esa tarea y mandar lo simple a modelos más baratos. Promete ahorros de hasta el 60% en el gasto de tokens.

Claude Security

Plugin en beta para Claude Code que analiza el código en busca de vulnerabilidades desde la terminal, ya sea sobre los cambios que tienes pendientes antes de commitear o sobre el repositorio entero.

Herramientas en el radar

ECC

Plugin de Claude Code que añade al agente todo un sistema de ingeniería alrededor del código. En nuestro caso no vimos nada nuevo, pero puede ser útil como punto de partida si no tienes nada montado.

No todo es IA en 540

La opcionalidad

En nuestra forma de entender la tecnología siempre ha habido una fuerte mirada económica: tenemos que proteger la inversión que hace un negocio en tecnología para conseguir sus objetivos sin perder por el camino nuestra esencia.

Por eso, algunos conceptos que inicialmente conocimos para tomar mejores decisiones de negocio han acabado formando parte también de nuestra manera de entender el software.

Uno de los más importantes es la opcionalidad: tomar decisiones que mantengan abiertas el mayor número posible de buenas opciones futuras.

Taleb, en Antifrágil:

Las opciones, cualquier opción, te darán más upside que downside, son vectores de antifragilidad. Si tienes opcionalidad, no necesitas inteligencia, conocimiento, visión o habilidades. Porque ya no tienes que acertar tan a menudo. Basta con no cometer errores que te perjudiquen (actos de omisión) y reconocer resultados favorables cuando ocurran. La clave es que la evaluación no es necesaria de antemano, solo después del evento.

Es una idea clave cuando trabajas en entornos de incertidumbre. Y tanto los negocios como la tecnología tienen bastante de eso.

Hablamos de ello hace unas pocas semanas a raíz de un artículo muy interesante de Kent Beck.

¿Cómo intentamos tener opcionalidad nosotros?

• Contratando personas que sobre todo, aprenden y se adaptan rápido a la incertidumbre, porque creemos que, en vez de volverte loco tratando de diseñar una estrategia perfecta, la estrategia en sí son las personas. Este artículo de Xavier Marcet nos marcó en su día.

• “Fuck you money”. Ahorro, buena caja y buenas tarifas. El dinero no solo compra cosas: compra opciones futuras. Te permite decir que no, esperar, invertir cuando aparece una oportunidad o equivocarte sin que el error sea irreversible. En este tema, Joan Tubau es nuestra referencia.

• Holguras. No intentar ocupar siempre el 100% de nuestra capacidad. Lo que en un Excel puede parecer ineficiencia es también capacidad disponible para reaccionar, aprender o aprovechar algo inesperado. Lo contamos aquí hace ya un tiempo.

Y esta misma lógica tiene una traducción especialmente interesante al software: Real Options.

La idea viene de las opciones financieras: cuando existe incertidumbre, tener el derecho, pero no la obligación, de hacer algo en el futuro tiene valor. Aplicado al desarrollo de software, significa reconocer que cada decisión que posponemos sin un coste excesivo conserva información y posibilidades, mientras que cada decisión irreversible que tomamos demasiado pronto elimina opciones.

No significa retrasar decisiones por sistema. Significa distinguir entre las decisiones que necesitamos tomar ahora y aquellas que será mejor tomar cuando sepamos más.

De ahí otra idea que nos ha influido mucho: posponer las decisiones hasta el último momento responsable.

Porque decidir pronto puede transmitir sensación de control. Pero, en contextos de incertidumbre, muchas veces la mejor decisión que puedes tomar hoy es no cerrar todavía una puerta que mañana podrías querer atravesar.

Enlaces de interés

Commitment

Un libro que nos recomendó nuestro amigo Vicenç Garcia sobre cómo gestionar proyectos y tomar decisiones utilizando Real Options.

El arte de postponer decisiones

Imperdible esta serie de artículos de otro de nuestros referentes, Edu Ferro.

En esta edición:

• Por qué casi nadie usa el modelo barato y qué hacemos ahora que Fable se paga por uso, qué conclusiones sacamos tras una semana con Codex y por qué las PRs se suben en draft.

• La falsa dicotomía: hacer cosas con propósito vs hacer cosas que generan dinero.

  ---

IA en 540

01. Solo usamos el último modelo

En ai-edge comentamos una sospecha que las métricas de uso de Claude Code confirman: de unas 30 personas, solo 8 usan de verdad modelos más baratos (Sonnet).

Concluimos que ante la duda tiramos del mejor, porque no hay forma fácil de saber si el barato es suficiente.

La lentitud de Opus no importa, lanzas varios a la vez y siguen solos mientras haces otra cosa. El problema es el coste, y ya rozamos los límites.

Así que toca mirar cómo lo hacen los que sí usan modelos baratos, y optimizar qué modelo usamos en cada paso que delegamos.

02. Para qué usar Fable

Anthropic ha sacado Fable, su modelo más capaz, de las suscripciones de equipo más baratas (Team Standard): ahora se paga por uso.

Antes de mandar al equipo el “usadlo con cuidado”, hemos escrito esta lista de cómo usarlo con criterio.

Sirve para:

• Profundizar en el código que ya existe: dependencias, vulnerabilidades, un bug que no encuentras, un problema de rendimiento.

• Investigar y planificar lo que aún no está escrito: arquitectura, planteamientos, valorar diferentes enfoques.

• Desatascar lo que no sacas con Opus por más que insistas.

• Orquestar, lanzando subagentes en modelos más baratos.

Para implementar no, ahí Opus aporta lo mismo y cuesta menos.

03. La prueba de Codex

Hemos estado una semana probando Codex en el día a día, para resolver las preguntas de la semana pasada.

En coste, el más por menos en nuestro caso no se da. La única cuenta que hay para equipos es la de 20 €, se gastó enseguida y el resto fue a coste extra.

En acoplamiento, migrar la configuración de Claude (skills, hooks, agentes) es fácil, Codex lo hace directamente al arrancar. Pero lo que está pensado para la forma de funcionar de Claude Code hay que readaptarlo. Y como no hay nada parecido a los workflows, lo que teníamos programado hay que volver a dictárselo al agente.

Codex va bien, pero no nos sale más barato ni hace nada que no tengamos ya. Readaptarse no costaría mucho, aunque no cambias la herramienta de todo un equipo sin estar muy convencido.

04. PRs en draft

En la última ai-leads salió que varios equipos han acabado haciendo lo mismo, cada uno por su lado: las PRs se suben en draft.

Antes lo revisabas tú y luego hacías el push. Ahora el flujo llega solo hasta la PR, así que la primera revisión la hacen la CI y la review de la IA, y lo que saquen ellas, o quien entre a revisarla, te vuelve como corrección que lo dispara todo otra vez.

En draft solo corren linters, tests unitarios y de integración. Los checks pesados y la review de la IA esperan a que la marques lista para revisar, y eso lo haces tú tras mirarla.

Alargamos el ciclo de feedback sin darnos cuenta, y el draft lo acorta otra vez.

Enlaces de interés

A global workspace in language models

Anthropic identifica en Claude un “J-space”: unas pocas docenas de conceptos activos que funcionan como el espacio de trabajo global de las teorías de la consciencia, y que el modelo puede reportar y modular. Si le quitan ese espacio, Claude sigue hablando con fluidez pero deja de poder razonar paso a paso.

Anthropic

ReactBench

ReactBench: benchmark que mide agentes de IA en tareas realistas de desarrollo con React, evaluando además rendimiento, accesibilidad y calidad del código, no solo si funciona.

React Bench

Herramientas en el radar

Graphify

Graphify convierte repos completos en grafos de conocimiento consultables desde Claude Code, Cursor o Gemini CLI. El parseo de código es local con tree-sitter, sin llamadas a API.

GitHub · Graphify Labs

No todo es IA en 540

01. La falsa dicotomía: propósito vs dinero

Algunas de las mejores decisiones de negocio que hemos tomado en 540 parecían irracionales cuando las tomamos. No optimizaban el corto plazo, no encajaban en un Excel y parecían directamente ineficientes.

La falsa dicotomía es pensar que tienes que elegir entre hacer dinero o hacer las cosas con propósito.

Hace poco recopilamos algunas de esas decisiones en este post y en este otro, explicando cómo acabaron convirtiéndose en una ventaja competitiva.

Enlaces de interés

Dos capítulos de uno de nuestros podcasts de referencia, Kapital, con dos personas muy unidas al mundo tecnológico que hablan sobre decisiones de negocio y de vida, irracionalidad y largo plazo.

Javier G. Recuenco · El pingüino nihilista

Kapital · Spotify

Miguel Carranza · El sueño americano

Kapital · Spotify