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

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.

En esta edición:

• Por qué casi nadie usa el modelo barato y qué hacemos ahora que Fable se paga por uso, qué conclusiones sacamos tras una semana con Codex y por qué las PRs se suben en draft.

• La falsa dicotomía: hacer cosas con propósito vs hacer cosas que generan dinero.

  ---

IA en 540

01. Solo usamos el último modelo

En ai-edge comentamos una sospecha que las métricas de uso de Claude Code confirman: de unas 30 personas, solo 8 usan de verdad modelos más baratos (Sonnet).

Concluimos que ante la duda tiramos del mejor, porque no hay forma fácil de saber si el barato es suficiente.

La lentitud de Opus no importa, lanzas varios a la vez y siguen solos mientras haces otra cosa. El problema es el coste, y ya rozamos los límites.

Así que toca mirar cómo lo hacen los que sí usan modelos baratos, y optimizar qué modelo usamos en cada paso que delegamos.

02. Para qué usar Fable

Anthropic ha sacado Fable, su modelo más capaz, de las suscripciones de equipo más baratas (Team Standard): ahora se paga por uso.

Antes de mandar al equipo el “usadlo con cuidado”, hemos escrito esta lista de cómo usarlo con criterio.

Sirve para:

• Profundizar en el código que ya existe: dependencias, vulnerabilidades, un bug que no encuentras, un problema de rendimiento.

• Investigar y planificar lo que aún no está escrito: arquitectura, planteamientos, valorar diferentes enfoques.

• Desatascar lo que no sacas con Opus por más que insistas.

• Orquestar, lanzando subagentes en modelos más baratos.

Para implementar no, ahí Opus aporta lo mismo y cuesta menos.

03. La prueba de Codex

Hemos estado una semana probando Codex en el día a día, para resolver las preguntas de la semana pasada.

En coste, el más por menos en nuestro caso no se da. La única cuenta que hay para equipos es la de 20 €, se gastó enseguida y el resto fue a coste extra.

En acoplamiento, migrar la configuración de Claude (skills, hooks, agentes) es fácil, Codex lo hace directamente al arrancar. Pero lo que está pensado para la forma de funcionar de Claude Code hay que readaptarlo. Y como no hay nada parecido a los workflows, lo que teníamos programado hay que volver a dictárselo al agente.

Codex va bien, pero no nos sale más barato ni hace nada que no tengamos ya. Readaptarse no costaría mucho, aunque no cambias la herramienta de todo un equipo sin estar muy convencido.

04. PRs en draft

En la última ai-leads salió que varios equipos han acabado haciendo lo mismo, cada uno por su lado: las PRs se suben en draft.

Antes lo revisabas tú y luego hacías el push. Ahora el flujo llega solo hasta la PR, así que la primera revisión la hacen la CI y la review de la IA, y lo que saquen ellas, o quien entre a revisarla, te vuelve como corrección que lo dispara todo otra vez.

En draft solo corren linters, tests unitarios y de integración. Los checks pesados y la review de la IA esperan a que la marques lista para revisar, y eso lo haces tú tras mirarla.

Alargamos el ciclo de feedback sin darnos cuenta, y el draft lo acorta otra vez.

Enlaces de interés

A global workspace in language models

Anthropic identifica en Claude un “J-space”: unas pocas docenas de conceptos activos que funcionan como el espacio de trabajo global de las teorías de la consciencia, y que el modelo puede reportar y modular. Si le quitan ese espacio, Claude sigue hablando con fluidez pero deja de poder razonar paso a paso.

Anthropic

ReactBench

ReactBench: benchmark que mide agentes de IA en tareas realistas de desarrollo con React, evaluando además rendimiento, accesibilidad y calidad del código, no solo si funciona.

React Bench

Herramientas en el radar

Graphify

Graphify convierte repos completos en grafos de conocimiento consultables desde Claude Code, Cursor o Gemini CLI. El parseo de código es local con tree-sitter, sin llamadas a API.

GitHub · Graphify Labs

No todo es IA en 540

01. La falsa dicotomía: propósito vs dinero

Algunas de las mejores decisiones de negocio que hemos tomado en 540 parecían irracionales cuando las tomamos. No optimizaban el corto plazo, no encajaban en un Excel y parecían directamente ineficientes.

La falsa dicotomía es pensar que tienes que elegir entre hacer dinero o hacer las cosas con propósito.

Hace poco recopilamos algunas de esas decisiones en este post y en este otro, explicando cómo acabaron convirtiéndose en una ventaja competitiva.

Enlaces de interés

Dos capítulos de uno de nuestros podcasts de referencia, Kapital, con dos personas muy unidas al mundo tecnológico que hablan sobre decisiones de negocio y de vida, irracionalidad y largo plazo.

Javier G. Recuenco · El pingüino nihilista

Kapital · Spotify

Miguel Carranza · El sueño americano

Kapital · Spotify