Esta semana va de ir más rápido. De agentes capaces de hacer viables trabajos que antes no compensaban, de procesos que quizá deberíamos dejar de hacer como siempre y de preparar nuestros sistemas para trabajar mejor con IA. Y también de una pregunta que cada vez nos parece más importante: ¿estamos aprendiendo a ir más rápido o simplemente a producir más deprisa?
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.