Esta semana descubrimos que usar un modelo más caro puede salir más barato, empezamos a evaluar nuestras skills y seguimos dándole vueltas a qué nos toca hacer a nosotros cuando los agentes hacen cada vez más.
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.