#3: Uncle Bob y un Mercedes del 90
El autor de Clean Code ya no lee código. Nosotros seguimos probando cómo trabajar mejor con agentes: adiós JetBrains, más contexto de dominio y mejores especificaciones. Y, entre tanto cambio, pensamos en qué merece la pena construir para que dure.
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.