#2: Opus 5, donde entra la persona en el ciclo delegado y la opcionalidad
Esta es la newsletter de 540, una publicación sobre nuestra visión del mundo de la tecnología, los negocios... y la vida.
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
Más sobre “Real Options”
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.