Dex Horthy nos contó por qué él apuesta por revisar todo el código más deprisa, mientras nosotros intentamos leer cada vez menos y solo donde haga falta. Os contamos cómo de maduros están nuestros controles deterministas para poder dejar de leerlo, qué métricas ponemos en un panel para saber dónde mirar y, al final, nos preguntamos por el precio de todo esto: ¿qué riesgo asumimos por acelerar y cuál por no acelerar lo suficiente?
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.