Lo interesante no ha salido de ninguna documentación oficial, sino de mirar los logs de cada una de las trazas.

El descubrimiento en los logs

• La expectativa: Esperaba encontrar un System Prompt perfectamente estructurado, gigantesco e inmutable, con todas las reglas sagradas del agente en el rol de sistema, tal y como dictan los manuales de prompt engineering.

• La realidad: El rol de sistema en Claude Code estaba prácticamente vacío.

• El truco: Las instrucciones clave e indicaciones de contexto se inyectan dinámicamente como system reminders en los mensajes del propio usuario a lo largo de la conversación.

Por qué la teoría falla y gana el pragmatismo

A primera vista parece una chapuza o un “truco sucio”, pero responde a dos restricciones de producción muy concretas:

1. Prefix Caching (Latencia y Costes): Si cambias el System Prompt en cada interacción para meterle contexto variable, rompes el caché de prefijo de la API. Mantener el mensaje de sistema estático o mínimo permite congelar ese prefijo, bajando la latencia y la factura de tokens drásticamente.

2. Combate al Recency Bias: Los modelos tienden a olvidar las instrucciones del principio a medida que la ventana de contexto crece. Repetir recordatorios en el flujo del usuario mantiene al agente enfocado sin reescribir la base del sistema.

El impacto en cómo construyo ahora

Ver cómo los propios ingenieros de Anthropic o los creadores de otros harnesses rompen las “buenas prácticas” para priorizar el rendimiento te cambia el chip.

• Menos arquitectura limpia, más observabilidad: Sin un gateway para medir latencia, caché y tráfico real, estás programando a ciegas.

• Ajuste en mis propios agentes: He empezado a reestructurar las llamadas de mis herramientas para maximizar el prefix cache e inyectar contexto en los turnos de usuario en lugar de inflar el System Prompt.

Compartir The Learning Curve

Muchísimas gracias a los mecenas que apoyáis Cuaderno de Bitácora y hacéis posible este diario de a bordo semana a semana. Si quieres recibir estos análisis en tu correo o participar en la comunidad, puedes suscribirte en The Learning Curve.

Suscríbete ahora

En esta hora y media de video nos dedicamos a añadir una seguridad básica en nuestra API y a hacerla disponible desde la nube para poder acceder desde cualquier parte.

abrimos la documentación de fastapi y seguimos las instrucciones para integrar una gestión de usuarios. Finalmente nos quedamos con una gestión de token tradicional.

Al final del video conectamos Langsmith para controlar las latencias y los costes del procesamiento de cada documento.

También te cuento una forma sencilla de reducir los costes a la hora de procesar documentos.

Te dejo por aquí el episodio anterior por si no lo habías visto!

Como comento en el directo, a partir de aquí hay mil cosas que se podrían hacer y estoy abierto a profundizar en esas que os resulten más interesantes a vosotr@s.

Deja un comentario

Una de las cosas que haremos en los siguientes directos será configurar modelos Open Source. Si no sabes como hacerlo, te dejo aquí un video que explico como

y, por último, te dejo por aquí algunos enlaces de interés:

• Repositorio

• Utiliza Novita.AI para ejecutar modelos Open Source

• Utiliza DigitalOcean para desplegar proyectos con un solo click

Muchas gracias a los que estuvísteis en la sesión en directo.

Hasta la semana que viene!

Suscríbete ahora

y que encima es algo con lo que llevo pegándome unas semanas en el trabajo

Lo descubrí leyendo un artículo de Google sobre cómo diseñar agentes capaces de mantener conversaciones muy largas, los llamados long horizon agents

El concepto es sencillo

Pero tiene una consecuencia bastante importante

Empecemos por el prompt cache

Cuando hacemos una llamada a un LLM, el modelo tiene que procesar el contexto antes de empezar a generar una respuesta

Esta fase se conoce como prefill

ya te lo expliqué en este video

Si nuestra conversación tiene 50.000 tokens de contexto y solo hemos añadido una pregunta nueva, sería bastante absurdo tener que procesar esos 50.000 tokens desde cero en cada turno

Por eso existen los prompt caches

Si una parte del prompt es exactamente igual que en la llamada anterior, el proveedor puede reutilizar ese procesamiento

Menos trabajo

Menor latencia

Menor coste

Hasta aquí, todo perfecto

El problema aparece cuando empezamos a construir agentes de verdad

El problema del system prompt dinámico

Imagina que tienes un agente que conoce al usuario

En cada turno le puedes pasar cosas como:

• Su perfil

• Un resumen de la conversación

• Información recuperada mediante RAG

• El estado actual de una tarea

• Las acciones que ha realizado

• Información sobre herramientas disponibles

Todo esto suele acabar dentro del system prompt

ERROR

Si modificamos el system prompt en cada turno, el prefijo deja de ser idéntico

Por tanto, la caché no puede reutilizarlo

Puedes tener un system prompt de 50.000 tokens y estar procesándolo prácticamente desde cero una y otra vez

La caché está activada

Pero en la práctica no te está sirviendo de nada

Es parecido a un Docker build

Esta analogía me parece especialmente útil

Imagina que tienes un Dockerfile con muchas capas:

FROM python
COPY requirements.txt .
RUN pip install ...
COPY app .

Si cambias una capa de las primeras, Docker tiene que reconstruir todo lo que viene después

Con el prompt ocurre algo parecido

Si modificas una pequeña parte al principio del contexto, puedes invalidar todo lo que viene después

Por eso no solo importa qué información introduces en el contexto

También importa dónde la introduces

La solución: ordenar el contexto por estabilidad

La propuesta de Google es separar la información del agente en diferentes niveles dependiendo de cuánto cambia

1. Información congelada

Al principio del prompt

• System instructions

• Persona

• Definiciones de herramientas

• Reglas del agente

Todo aquello que debería ser idéntico durante toda la sesión

Esta parte queremos que sea extremadamente estable

2. Información relativamente estable

Después podemos colocar información relacionada con el usuario

• Preferencias

• Configuración

• Perfil

Contexto que cambia entre sesiones, pero no en cada turno

La idea es cargarla al comenzar la sesión y no modificarla continuamente.

3. Información volátil

Y al final dejamos todo aquello que cambia constantemente.

• Estado de la ejecución

• Contadores

• Warnings

• Memorias recuperadas

• Información temporal

• Resumen de la conversación

Aquí sí esperamos cambios.

La clave está en que los cambios ocurran lo más tarde posible dentro del contexto.

Pero podemos ir un paso más allá

Hay información dinámica que ni siquiera necesita formar parte del system prompt

Por ejemplo:

Usuario → Agente
"Busca vuelos a Roma"

Agente → Tool
search_flights("Madrid", "Rome")

Tool → Agente
"Encontrados 12 vuelos..."

Esa información ya está entrando en el contexto como parte de la conversación

No necesitas reconstruir todo el system prompt para añadirla

Y esto nos permite mantener una propiedad muy interesante:

todo lo que ocurrió hasta el turno anterior puede seguir siendo cacheable.

El resultado es que, después de calentar la caché, una gran parte del contexto puede reutilizarse en cada nueva llamada.

En el ejemplo que muestra Google, el cambio de arquitectura hace que aproximadamente el 95% del prompt pueda servirse desde caché.

Y ahí es donde empieza a aparecer una diferencia enorme en agentes con sesiones largas.

El detalle importante: medirlo

Hay otra lección que me parece incluso más importante

No asumas que tu prompt está siendo cacheado. Mídelo

Si el proveedor te devuelve métricas sobre tokens cacheados, míralas.

Porque puedes tener:

Prompt cache: ON

y al mismo tiempo:

Cached tokens: 0

Y eso significa que, técnicamente, tienes caching.

Pero arquitectónicamente has diseñado tu agente para que nunca pueda aprovecharlo.

Esto cambia cómo diseñamos agentes

Cuando empezamos a construir agentes, solemos pensar mucho en:

• Qué modelo utilizar

• Qué herramientas darle

• Qué memoria necesita

• Qué prompt escribir

Pero hay otra capa que empieza a ser igual de importante:

cómo diseñamos el contexto.

• Dónde ponemos cada pieza de información

• Qué cambia

• Cuándo cambia

• Qué puede permanecer estable

Y qué información puede llegar mediante herramientas o mensajes en lugar de modificar continuamente las instrucciones del sistema

En agentes de pocas interacciones quizá esto no importe demasiado

Pero cuando hablamos de agentes que trabajan durante minutos, horas o incluso días, con contextos enormes y cientos de llamadas al modelo, puede convertirse en una diferencia enorme de coste, latencia y escalabilidad

Y esto es solo una pequeña parte del harness que necesitas para construir agentes realmente eficientes

En los próximos artículos podemos entrar en más patrones de diseño para construir agentes que no solo funcionen, sino que sean rápidos, baratos y capaces de escalar

Deja un comentario

Hoy hablo sobre una consecuencia directa del capítulo anterior: cómo la velocidad a la que construimos con IA ha destruido el filtro de enfriamiento que tenían las ideas antes de convertirse en código.

De qué va el episodio:

• El caos de la app de notas: La experiencia de volver con el móvil a reventar de arquitecturas, ideas de producto y soluciones pensadas en crudo.

• La trampa de la fricción cero: Antes, el esfuerzo o la lentitud de picar código servían como un control de calidad natural. Hoy, tardas dos horas en levantar un prototipo completo de algo que en realidad no necesitabas.

• El filtro que nos saltamos: Por qué releer esas notas unos días después me reveló que la mitad eran decisiones ridículamente complejas, y cómo el simple paso del tiempo limpia más código inútil que cualquier refactorización.

• La regla de las 48 horas: La decisión de usar la app de notas como un congelador antes de meterle un prompt a ChatGPT o abrir el editor.

Si alguna vez has sentido la tentación de convertir en software cualquier pensamiento aleatorio a las diez de la noche solo porque ahora la IA te lo permite en minutos, este episodio es para ti.

El audio ya está disponible en el feed del podcast.

Muchísimas gracias a todos los mecenas que apoyáis Cuaderno de Bitácora y hacéis posible este diario de a bordo semana a semana. Si quieres leer las reflexiones que acompañan a cada entrega o unirte a la comunidad, recuerden que podéis suscribiros en la newsletter de Substack en The Learning Curve.

Escucha el capítulo anterior aquí

Hasta hace no mucho, la respuesta era bastante incómoda.

Tenías que descargar los pesos, encontrar una GPU con suficiente VRAM, configurar CUDA, levantar un servidor de inference y encargarte de que todo funcionase.

Hoy puedes hacer algo mucho más sencillo:

elegir un modelo y llamarlo mediante una API.

En este artículo vamos a utilizar Kimi K3 como ejemplo y veremos cómo podemos utilizarlo mediante Serverless Inference con Novita.

El problema de ejecutar un modelo open source

Cuando hablamos de modelos open source, solemos pensar en todo lo que hay que montar alrededor del modelo: GPU, memoria, entorno de ejecución, servidor de inference, API y escalado.

Todo esto tiene sentido si quieres operar el modelo tú mismo.

Pero muchas veces nuestro objetivo es bastante más sencillo:

Quiero utilizar el modelo dentro de mi aplicación.

No necesito necesariamente saber qué GPU lo está ejecutando, cómo está configurado el servidor o cómo se distribuye el modelo.

Aquí es donde aparece Serverless Inference.

¿Qué significa Serverless Inference?

Serverless no significa que no existan servidores.

Significa que tú no tienes que gestionarlos.

El proveedor se encarga de la infraestructura necesaria para ejecutar el modelo y tú consumes esa capacidad mediante una API.

En el caso de Novita, puedes acceder a modelos mediante una API Serverless sin tener que desplegar tú mismo la infraestructura de inference. Kimi K3 en Novita

Y esto cambia bastante la barrera de entrada para experimentar con modelos grandes.

Vamos a probar Kimi K3

Para verlo en la práctica vamos a utilizar Kimi K3.

Kimi K3 es un modelo MoE con 2,8 billones de parámetros totales y 104.000 millones de parámetros activos, además de una ventana de contexto de hasta 1 millón de tokens.

Es un modelo orientado especialmente a tareas de razonamiento, programación y agentes.

Lo interesante para nosotros es que podemos acceder a él mediante la API Serverless de Novita.

No necesitamos ejecutar nosotros mismos toda esa infraestructura.

Paso 1: crear una API key

Entramos en Novita y creamos una API key.

Una vez tenemos nuestra clave, podemos utilizar el modelo desde código.

Y aquí hay algo especialmente interesante:

la API es compatible con OpenAI.

Por tanto, si ya has utilizado el SDK de OpenAI, la integración resulta muy sencilla.

Paso 2: instalar el SDK

En Python:

pip install openai

Después creamos nuestro cliente:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.novita.ai/openai"
)

Paso 3: llamar a Kimi K3

Ahora simplemente hacemos una petición:

response = client.chat.completions.create(
    model="moonshotai/kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Explain speculative decoding in simple terms"
        }
    ],
    max_tokens=1000
)

print(response.choices[0].message.content)

Y ya está.

No hemos descargado Kimi K3.

No hemos configurado CUDA.

No hemos seleccionado una GPU.

No hemos instalado un inference server.

No hemos desplegado un contenedor.

Hemos hecho una petición y hemos recibido una respuesta.

Ese es precisamente el valor de esta abstracción.

¿Cuánto cuesta?

Kimi K3 se ofrece actualmente en Novita con pricing basado en tokens.

El precio que muestra actualmente Novita es de $3 por millón de tokens de entrada, $0,30 por millón de tokens leídos desde caché y $15 por millón de tokens de salida. Pricing de Kimi K3 en Novita

Esto significa que no necesitas mantener una GPU dedicada funcionando mientras no estás utilizando el modelo.

Pagas por el uso de inference.

¿Y si quiero utilizar otro modelo?

Aquí está la parte que me parece más interesante.

La idea no es realmente Kimi K3.

Kimi K3 es simplemente nuestro ejemplo.

La idea es poder elegir un modelo open source y consumirlo mediante una API sin preocuparnos inicialmente por la infraestructura que hay detrás.

Novita ofrece un catálogo amplio de modelos y diferentes modalidades de inference.

Esto cambia la pregunta que nos hacemos como desarrolladores.

En lugar de empezar pensando:

¿Qué GPU necesito para ejecutar este modelo?

Podemos empezar pensando:

¿Qué modelo quiero utilizar?

Y después decidir cómo queremos consumirlo.

¿Serverless significa que siempre es la mejor opción?

No.

Y esta distinción es importante.

Hay una diferencia entre utilizar un modelo y operar un modelo.

Si quiero consumir un modelo rápidamente y abstraer la infraestructura, una plataforma como Novita tiene mucho sentido.

Si quiero controlar directamente la GPU, el container, el runtime o el deployment del modelo, probablemente quiera una solución como RunPod.

No se trata de que una opción sea mejor que la otra.

Se trata de elegir el nivel de control que necesitas.

La idea importante

Creo que esta es una de las abstracciones más interesantes que estamos viendo en infraestructura de IA:

usar un modelo y operar un modelo son problemas diferentes.

Durante mucho tiempo, para utilizar un modelo open source teníamos que ocuparnos también de ejecutarlo.

Ahora podemos separar ambas cosas.

La infraestructura sigue existiendo.

Simplemente deja de ser nuestro problema.

Y eso permite que un developer pueda experimentar con modelos que, de otra forma, serían bastante difíciles de ejecutar localmente.

Prueba Kimi K3

Si quieres probar Kimi K3 sin montar tu propia infraestructura de inference, puedes hacerlo directamente desde Novita.

Probar Kimi K3 con Novita

Y si quieres verlo paso a paso, en el vídeo de esta semana lo hago desde cero:

Cómo usar un modelo de 2,8T de parámetros sin tener una GPU.

La idea que quiero que te lleves es sencilla:

Cuando quieras probar un modelo open source, quizá la primera pregunta ya no sea “¿qué GPU necesito?”, sino “¿dónde puedo consumirlo?”

Y esa diferencia está cambiando la forma en la que construimos con IA.

Probar Kimi K3

Estoy totalmente a favor de usarla para ganar tiempo.

El problema no es la herramienta. El problema es esta fiebre por metérsela a absolutamente todo y, sobre todo, la tentación de delegarle la única parte de nuestro trabajo que de verdad nos pertenece: el pensamiento crítico.

La frontera entre ejecución y criterio

El error en el que estamos cayendo es confundir dos conceptos que deberían estar completamente separados:

• Delegar la ejecución: Es pedirle a un modelo que te escriba una función auxiliar, te dé la sintaxis exacta de un comando que no recuerdas o te convierta un formato de datos a otro. Tú sabes exactamente qué quieres hacer y por qué lo necesitas. La IA solo te ahorra el tecleo mecánico. Ganaste tiempo y tu criterio sigue intacto.

• Delegar el criterio: Es abrir la terminal, tirarle a Claude Code un problema que ni te has parado a entender, ejecutar a ciegas lo que te chuta y, cuando salta un error, copiar la traza sin leerla para decirle “no funciona, arréglalo”.

Cuando delegas el criterio, estás apagando el motor.

El efecto GPS

Nos está pasando lo mismo que cuando empezamos a meter la dirección en la aplicación del móvil para ir a sitios por los que habíamos pasado cien veces. Al principio era una ayuda para evitar un atasco puntual. Con el tiempo, dejamos de mirar las calles, dejamos de memorizar puntos de referencia y entregamos la navegación.

El resultado es que hoy hay gente incapaz de orientarse en su propio barrio si la pantalla del móvil no le dice dónde girar.

Con la tecnología y el desarrollo nos está ocurriendo lo mismo a velocidad multiplicada. Si cada vez que nos topamos con un problema acudimos al chat antes de haber dedicado tres minutos a masticar la solución por nuestra cuenta, la capacidad de razonar se atrofia. Pensar cuesta energía, y el cerebro siempre va a buscar la ruta de menor resistencia si se lo permitimos.

Dos formas de estar frente a la pantalla

Cada vez se nota más la brecha entre dos formas de trabajar:

1. El perfil sparring: Utiliza la IA para rebotar ideas, cuestiona sus respuestas, revisa la arquitectura y entiende cada línea que entra en su proyecto. Mantiene el control y usa la herramienta para acelerar.

2. El perfil cable: Se limita a hacer de puente entre la ventana del chat y el repositorio. No razona sobre las decisiones técnicas ni sobre las implicaciones del código. Simplemente pasa datos de un lado a otro.

Conclusión

Usar la IA para ahorrar tiempo en lo mecánico es ser eficiente. Usarla para evitar el esfuerzo de pensar nos regala una falsa sensación de velocidad a costa de perder la capacidad de resolver problemas cuando la herramienta falla o el escenario se complica.

La herramienta tiene que ir siempre por detrás de la lógica humana, nunca por delante. En el momento en que la máquina decide el porqué y nosotros solo nos dedicamos a pulsar botones, dejamos de construir.

En esta sesión definimos diferentes métodos de validación para asegurarnos de que nunca se añada nada no deseado en nuestra base de datos.

Y esta vez no estamos hablando de un modelo gigantesco que necesita un cluster de GPUs para funcionar.

Se llama Muse Glimmer.

Es un modelo de aproximadamente 30.000 millones de parámetros, con capacidades multimodales, razonamiento, uso de herramientas y tareas agenticas, pero diseñado específicamente para poder ejecutarse en hardware de consumo. (Hugging Face)

Y lo más interesante es que puedes probarlo ahora mismo sin tener una GPU de 24 GB o 32 GB.

Vamos a verlo.

¿Qué es Muse Glimmer?

Muse Glimmer es un modelo de lenguaje desarrollado por Meta Superintelligence Labs y publicado bajo licencia Apache 2.0. (Hugging Face)

Pero llamarlo simplemente “un LLM de 30B” se queda bastante corto.

Meta lo ha diseñado pensando especialmente en agentes de IA.

Eso significa que el modelo no está pensado únicamente para responder preguntas.

Está entrenado para trabajar en tareas de varios pasos, utilizar herramientas, escribir y depurar código, recuperarse de errores y mantener planes durante workflows relativamente largos. (Hugging Face)

Además, es multimodal.

Puede recibir texto e imágenes, por lo que puede trabajar con capturas de pantalla, documentos, gráficos o interfaces visuales además de texto. (Hugging Face)

Y aquí viene una de las partes más interesantes.

30B no significa necesariamente que necesites 30B de VRAM

Muse Glimmer ha sido optimizado específicamente para inferencia local.

Meta proporciona versiones cuantizadas de aproximadamente 4 bits que reducen el tamaño del modelo a menos de 20 GB.

Según Meta, una de las versiones está pensada para GPUs de 24 GB y otra para GPUs de 32 GB. (Hugging Face)

Esto hace posible ejecutar un modelo de esta categoría en hardware que hasta hace poco habría parecido insuficiente.

Y todavía hay otra optimización interesante.

Speculative decoding

Muse Glimmer viene acompañado de un pequeño modelo denominado DFlash.

En lugar de generar los tokens estrictamente uno a uno, DFlash propone bloques de tokens y el modelo principal los verifica en paralelo.

Si las predicciones son correctas, se pueden aceptar varios tokens de una vez.

Esto es lo que conocemos como speculative decoding.

Según las mediciones publicadas por Meta, esta técnica puede aumentar considerablemente la velocidad de generación. En una RTX 5090, por ejemplo, Meta reporta pasar de 74,9 tokens por segundo sin especulación a 233,4 tokens por segundo utilizando DFlash. (Hugging Face)

Es decir, no solo han intentado hacer que el modelo quepa en una GPU de consumo.

También han trabajado en que sea suficientemente rápido para utilizarlo en aplicaciones interactivas y agentes.

¿Y cómo puedo probarlo?

Aquí tenemos dos opciones.

La primera es ejecutarlo localmente.

La segunda, y la que vamos a utilizar en este tutorial, es probarlo mediante una API.

¿Por qué?

Porque para probar el modelo no necesitamos descargar 20 GB de pesos ni tener una GPU compatible.

Hugging Face permite utilizar modelos mediante Inference Providers, que actúan como una capa común para acceder a diferentes proveedores de inferencia. Además, puedes cambiar de proveedor sin modificar prácticamente tu integración. (Hugging Face)

En el caso de Muse Glimmer, actualmente podemos utilizar Together AI como proveedor.

Muse Glimmer 30B en Hugging Face

Paso 1. Crear una cuenta en Hugging Face

Lo primero es crear una cuenta en Hugging Face si todavía no tienes una.

Después necesitaremos un token de acceso.

Puedes encontrar la configuración de tokens dentro de tu cuenta de Hugging Face.

La ventaja de utilizar Hugging Face Inference Providers es que podemos utilizar un único token de Hugging Face para acceder a diferentes proveedores compatibles. (Hugging Face)

Crear una cuenta en Hugging Face

Paso 2. Instalar el cliente de OpenAI

Vamos a utilizar el SDK de OpenAI porque Together AI proporciona una API compatible con este formato.

Instalamos el cliente:

pip install openai

Y configuramos nuestro token de Hugging Face:

export HF_TOKEN="tu_token_de_huggingface"

Paso 3. Hacer nuestra primera llamada

Ahora podemos utilizar el modelo directamente desde Python.

from openai import OpenAI

client = OpenAI(
    base_url="https://router.huggingface.co/v1",
    api_key=os.environ["HF_TOKEN"],
)

response = client.chat.completions.create(
    model="meta-models/Muse-Glimmer-30B",
    messages=[
        {
            "role": "user",
            "content": "Explícame qué es speculative decoding."
        }
    ],
    provider="together",
)

print(response.choices[0].message.content)

La idea es muy sencilla.

Nuestro código habla con Hugging Face.

Hugging Face enruta la petición hacia Together AI.

Together AI ejecuta Muse Glimmer.

Y nosotros recibimos la respuesta.

Todo esto sin descargar el modelo.

Paso 4. Probar el razonamiento

Muse Glimmer está especialmente orientado hacia tareas de razonamiento y agentes.

Por eso merece la pena probar algo un poco más complejo que un simple “¿qué es Python?”.

Por ejemplo:

response = client.chat.completions.create(
    model="meta-models/Muse-Glimmer-30B",
    messages=[
        {
            "role": "system",
            "content": "Reasoning strength: high"
        },
        {
            "role": "user",
            "content": """
            Tengo una aplicación Python que procesa imágenes
            en tiempo real y empieza a quedarse sin memoria
            después de varias horas.

            Propón un proceso sistemático para encontrar
            el origen del problema y explica qué métricas
            monitorizarías.
            """
        }
    ],
    provider="together",
)

print(response.choices[0].message.content)

Una de las cosas interesantes de Glimmer es precisamente que permite controlar la intensidad del razonamiento mediante el parámetro Reasoning strength, con niveles low, medium, high y xhigh.

Meta recomienda high o xhigh para problemas complejos, programación y tareas agenticas. (Hugging Face)

Paso 5. Probar sus capacidades multimodales

Y aquí es donde empieza a ponerse interesante.

Muse Glimmer no trabaja únicamente con texto.

Su arquitectura incorpora un encoder de percepción específico de aproximadamente 1.800 millones de parámetros que permite introducir imágenes junto con el texto. (Hugging Face)

Por ejemplo, podemos enviarle una captura de pantalla y preguntarle qué está ocurriendo.

response = client.chat.completions.create(
    model="meta-models/Muse-Glimmer-30B",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Analiza esta captura de pantalla y dime qué problema ves."
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": "https://example.com/screenshot.png"
                    }
                }
            ]
        }
    ],
    provider="together",
)

print(response.choices[0].message.content)

Esto abre la puerta a casos de uso mucho más interesantes.

Un agente que entiende una interfaz.

Un agente que analiza documentos.

Un agente que interpreta gráficos.

O incluso un agente capaz de observar el estado de una aplicación y decidir qué hacer a continuación.

¿Y si quiero ejecutarlo localmente?

Aquí está probablemente la parte más interesante de Muse Glimmer.

No necesitas obligatoriamente una API.

Meta ha publicado versiones optimizadas para hardware de consumo y también proporciona artefactos para diferentes runtimes. (Hugging Face)

Puedes utilizar, entre otros:

llama.cpp

vLLM

SGLang

Docker Model Runner

Y también existen cuantizaciones compatibles con herramientas como Ollama, LM Studio y otros runtimes locales. (Hugging Face)

Por ejemplo, Hugging Face proporciona directamente un ejemplo para levantarlo con vLLM:

pip install vllm

vllm serve "meta-models/Muse-Glimmer-30B"

A partir de ahí puedes utilizar una API compatible con OpenAI desde tu propia máquina. (Hugging Face)

Para una GPU de consumo, sin embargo, merece la pena utilizar una de las versiones cuantizadas y aprovechar DFlash para acelerar la generación.

¿Merece la pena probarlo?

Creo que sí.

Pero no porque sea simplemente “otro modelo de 30B”.

Lo interesante de Muse Glimmer es la combinación.

30B de parámetros

Multimodalidad

Razonamiento

Tool use

Capacidades agenticas

Contexto de más de 128K tokens

Cuantización para hardware de consumo

Speculative decoding

Todo ello en un modelo con licencia Apache 2.0. (Hugging Face)

Y esto representa una tendencia que me parece especialmente importante.

Cada vez estamos viendo más modelos que no compiten únicamente por ser más grandes.

Compiten por ser más eficientes.

Modelos que pueden ejecutarse localmente.

Modelos que utilizan cuantización.

Modelos que utilizan speculative decoding.

Modelos que están diseñados alrededor de agentes y herramientas.

Porque el futuro de los modelos no va a consistir únicamente en preguntarles cosas.

Va a consistir en darles un objetivo y dejar que hagan el trabajo.

Y para eso, la arquitectura que rodea al modelo importa tanto como el modelo en sí.

Para probarlo ahora mismo

Si quieres experimentar con Muse Glimmer sin instalar nada, esta es probablemente la forma más sencilla:

Probar Muse Glimmer 30B en Hugging Face

Si quieres entender cómo funciona la capa que permite utilizar diferentes proveedores desde Hugging Face:

Hugging Face Inference Providers

Y si quieres utilizar Together AI directamente para desplegar modelos mediante inferencia serverless:

Together AI Serverless Models

Y si estás buscando una plataforma en la que ejecutar todos los modelos open source de forma sencilla, yo estoy empezando a usar Novita.AI. Super intuitiva y con todos los modelos actualizados.

Probar Novita.AI

Si tienes una GPU con suficiente memoria, entonces el siguiente paso es todavía más interesante:

ejecutarlo localmente y comparar su rendimiento con otros modelos de ~30B.

Ahí es donde realmente podemos empezar a ver qué significa que un modelo esté diseñado para ejecutarse localmente.

Está muy bien sacar información estructurada de fotos

pero si no validamos que los datos son correctos antes de meterlos en la base de datos…

tendremos problemas en el futuro

Así que hoy nos hemos centrado en:

• evitar tickets duplicados

• validar el nombre del supermercado en base a los valores de las tablas

Recuerda que llevamos varias sesiones levantando este sistema desde cero: una API en FastAPI que recibe la imagen de un ticket, un LLM que extrae los datos de forma estructurada, y una base de datos SQL normalizada donde todo queda guardado con upsert para evitar duplicados.

Como siempre, si quieres apoyar el canal puedes hacerlo a través de mis enlaces de afiliado:

DigitalOcean — la plataforma que uso para desplegar APIs y servicios. Con mi código te llevas 200$ de crédito gratis para empezar: m.do.co/c/eddc62174250

Netlify — la mejor forma de desplegar proyectos frontend de forma sencilla y rápida: join.netlify.com/uk2itht31g7b

Hace seis meses, la conversación pasó a los AI Agents.

Y durante las últimas semanas hay un nuevo término apareciendo en todos lados:

Graph Engineering.

No es una nueva librería.

No es un nuevo framework.

Y tampoco es una palabra de moda inventada por alguna startup para vender consultoría.

Es un cambio de mentalidad sobre cómo diseñamos sistemas de agentes.

Y creo que va a ser una de las habilidades más importantes de los próximos años.

El problema de los agentes lineales

La mayoría de agentes que veo construidos hoy siguen exactamente el mismo patrón.

Leer información
      ↓
Pensar
      ↓
Escribir respuesta
      ↓
Revisar
      ↓
Terminar

Es cómodo.

Es fácil de entender.

Y funciona.

Pero tiene un problema enorme.

Todo ocurre de forma secuencial.

Cada paso espera al anterior, incluso cuando realmente no existe ninguna dependencia.

Imagina que quieres revisar un repositorio con 200 archivos.

La forma tradicional sería:

Archivo 1
Archivo 2
Archivo 3
...
Archivo 200

Un agente.

Una tarea.

Un contexto.

Mucho tiempo esperando.

El trabajo nunca fue una línea

Cuando empiezas a analizar los problemas reales descubres algo curioso.

La mayoría de tareas son independientes.

Revisar el archivo auth.py no necesita esperar a que termine database.py.

Buscar vulnerabilidades en una carpeta no depende de analizar otra.

Resumir cinco documentos distintos tampoco requiere hacerlo uno detrás de otro.

Entonces...

¿Por qué seguimos diseñando agentes como si todo fuera una cadena?

La respuesta es sencilla.

Porque pensamos en prompts.

No pensamos en grafos.

¿Qué es realmente Graph Engineering?

Graph Engineering consiste en diseñar el trabajo como un grafo de dependencias.

Cada nodo representa una tarea.

Cada arista representa una dependencia real.

Si dos nodos no necesitan compartir información...

...pueden ejecutarse al mismo tiempo.

Eso cambia completamente la escala.

En lugar de esto:

A → B → C → D

empiezas a construir algo así:

          A
      /   |   \
     B    C    D
      \   |   /
          E

Ahora tienes múltiples agentes trabajando en paralelo y únicamente sincronizando cuando realmente hace falta.

No estás optimizando el prompt.

Estás optimizando la arquitectura.

La pregunta más importante

Hay una pregunta que me parece brillante.

Cada vez que escribas:

“Y después...”

pregúntate:

¿El siguiente paso necesita realmente el resultado del anterior?

Si la respuesta es no...

...esa dependencia sobra.

Y probablemente puedas ejecutar ambos pasos simultáneamente.

Es una forma extremadamente sencilla de descubrir paralelismo que normalmente pasa desapercibido.

Lo interesante no es la velocidad

Mucha gente piensa que Graph Engineering sirve para hacer las cosas más rápidas.

Sí.

Pero eso es casi un efecto secundario.

Lo realmente importante es la escala.

Imagina un agente encargado de revisar un monorepo enorme.

En lugar de analizar un archivo tras otro...

puede lanzar decenas de agentes especializados.

Uno revisa autenticación.

Otro busca secretos expuestos.

Otro analiza calidad del código.

Otro ejecuta pruebas.

Otro verifica los resultados de todos los anteriores.

Cada uno trabaja con su propio contexto.

Cada uno toma decisiones independientes.

Y al final existe un nodo que sintetiza todo.

Eso sería prácticamente imposible dentro de una única conversación con un LLM.

El enemigo invisible: el contexto compartido

Aquí aparece otro concepto interesante.

Muchos sistemas crean varios agentes...

...pero todos comparten exactamente el mismo historial.

Eso no son varios agentes.

Es el mismo agente con varias pestañas abiertas.

Si un agente revisa su propio trabajo usando exactamente el mismo contexto...

no está verificando nada.

Simplemente está reafirmando su respuesta anterior.

Los buenos sistemas aíslan el contexto.

Cada nodo recibe únicamente la información que necesita.

Y eso hace que las verificaciones sean mucho más fiables.

Graph Engineering no significa “más agentes”

Uno de los errores más comunes es pensar:

“Si un agente funciona bien...

diez funcionarán diez veces mejor.”

No.

Un mal diseño con cien agentes sigue siendo un mal diseño.

De hecho será más caro.

Más lento de depurar.

Y muchísimo más difícil de mantener.

La clave nunca es el número de agentes.

La clave es diseñar correctamente las dependencias entre ellos.

Esto ya está ocurriendo

Durante mucho tiempo los agentes fueron simplemente una secuencia de llamadas al modelo.

Ahora herramientas como Claude Code, OpenAI Codex, LangGraph o los sistemas internos de muchas empresas empiezan a construir flujos mucho más parecidos a grafos que a conversaciones.

La conversación está dejando paso a la orquestación.

Y creo que esa diferencia será enorme.

Dentro de unos años probablemente dejaremos de preguntar:

“¿Qué prompt utilizaste?”

Para empezar a preguntar:

“¿Cómo diseñaste el grafo?”

Porque el valor ya no estará únicamente en escribir mejores instrucciones.

Estará en saber dividir un problema complejo en cientos de tareas independientes que colaboran entre sí.

Mi predicción

Creo que estamos viviendo exactamente el mismo cambio que ocurrió hace años con los sistemas distribuidos.

Al principio escribíamos programas secuenciales.

Después aprendimos concurrencia.

Más tarde llegaron los sistemas distribuidos.

Y finalmente apareció toda una disciplina dedicada únicamente a diseñar arquitecturas escalables.

Con los agentes está ocurriendo lo mismo.

El prompt fue el primer paso.

Los agentes fueron el segundo.

El siguiente paso es aprender a diseñar el sistema completo.

No importa si utilizas Claude Code, Codex, LangGraph o cualquier otra plataforma.

Lo importante es dejar de pensar en una conversación...

...y empezar a pensar en un grafo.

Si todo esto te resulta nuevo, probablemente te falta una pieza

En este artículo hemos hablado de cómo conectar agentes.

Pero hay una pregunta que hemos dado por hecha:

¿Qué hace exactamente cada nodo del grafo?

La respuesta son las Skills.

Una Skill encapsula conocimiento, procesos y buenas prácticas para una tarea concreta. Cuando empiezas a construir sistemas complejos, descubres que el verdadero trabajo no está en escribir un prompt gigantesco, sino en reutilizar pequeñas capacidades especializadas que puedes combinar una y otra vez.

Hace unas semanas escribí una guía completa sobre este tema que puedes leer aquí:

Después vuelve a este artículo. Verás Graph Engineering con otros ojos.

Si prefieres no construir todas esas Skills desde cero, la Claude OS Collection reúne las mismas arquitecturas y componentes reutilizables que utilizo en mis proyectos para acelerar el desarrollo de sistemas agénticos.

Consigue mi set de skills

Puedes registrarte gratis aquí

StackNotes

si quieres revisar el resto de la documentación te la dejo por aquí

Documentación

Si el nombre se lo ha inventado nuestra becaria Clauda

Recuerda que llevamos varias sesiones levantando este sistema desde cero: una API en FastAPI que recibe la imagen de un ticket, un LLM que extrae los datos de forma estructurada, y una base de datos SQL normalizada donde todo queda guardado con upsert para evitar duplicados.

Hoy ha tocado hacer esos datos visibles.

Hemos diseñado el endpoint GET /api/v1/dashboard/report, implementado las queries de agregación sobre tickets, productos y supermercados, y conectado la vista HTML para que se hidrate en tiempo real con fetch. También hemos generado más de 500 tickets de prueba para poder ver el dashboard con datos reales y validar que las métricas tienen sentido.

Al final de la sesión, Luma Spend tiene un cuadro de mando funcional que muestra gasto por supermercado, productos más comprados y evolución mensual del gasto.

Como siempre, si quieres apoyar el canal puedes hacerlo a través de mis enlaces de afiliado:

DigitalOcean — la plataforma que uso para desplegar APIs y servicios. Con mi código te llevas 200$ de crédito gratis para empezar: m.do.co/c/eddc62174250

Netlify — la mejor forma de desplegar proyectos frontend de forma sencilla y rápida: join.netlify.com/uk2itht31g7b

Hasta hace muy poco, probar un modelo de este tamaño implicaba descargar cientos de gigabytes de pesos, configurar una infraestructura de inferencia con herramientas como vLLM o SGLang y disponer de una o varias GPUs capaces de ejecutarlo. En otras palabras, era una barrera de entrada importante para cualquiera que simplemente quisiera experimentar con él.

Eso acaba de cambiar.

DigitalOcean ha incorporado Kimi K3 a su servicio de Serverless Inference, permitiendo utilizar el modelo mediante una API administrada, sin preocuparse por servidores, GPUs o despliegues. Si ya has trabajado con APIs compatibles con OpenAI, la experiencia resulta prácticamente idéntica: obtienes una clave, realizas una llamada HTTP y comienzas a generar respuestas en cuestión de minutos.

Más allá del propio modelo, este lanzamiento representa una tendencia muy interesante: los mejores modelos open-source ya no solo compiten en calidad con muchos modelos propietarios, sino que además empiezan a ofrecer una experiencia de uso igual de sencilla.

En este artículo veremos qué hace especial a Kimi K3, por qué tanta gente está hablando de él y cómo puedes empezar a utilizarlo desde DigitalOcean en menos de cinco minutos.

¿Qué es Kimi K3?

Kimi K3 es el último modelo desarrollado por Moonshot AI, una de las empresas chinas que más rápido está evolucionando en el ecosistema de modelos fundacionales.

A diferencia de muchos modelos propietarios, Kimi K3 es un modelo open-weight, lo que significa que sus pesos están disponibles públicamente para que cualquiera pueda desplegarlo, estudiarlo o adaptarlo a sus necesidades.

Sin embargo, que un modelo sea abierto no significa necesariamente que sea fácil de utilizar. Ejecutar un modelo de estas dimensiones sigue requiriendo una infraestructura considerable, especialmente si queremos obtener una latencia baja o atender múltiples usuarios simultáneamente.

Ahí es donde entran en juego plataformas como DigitalOcean.

¿Por qué está generando tanto interés?

La razón principal no es únicamente su rendimiento en benchmarks. Lo realmente interesante es la combinación de varios factores que hacen que Kimi K3 resulte especialmente atractivo para desarrolladores e ingenieros de IA.

Una arquitectura Mixture of Experts

Kimi K3 utiliza una arquitectura Mixture of Experts (MoE).

En lugar de activar todos los parámetros del modelo en cada inferencia, el sistema selecciona únicamente los expertos más adecuados para responder a cada token.

Esto permite construir modelos enormes sin que el coste computacional crezca de forma proporcional.

En la práctica obtenemos un modelo con una gran capacidad de representación, pero con un coste de inferencia mucho menor que un modelo denso de tamaño equivalente.

Una gestión mucho más eficiente de la memoria

Uno de los aspectos más interesantes del paper es la optimización del uso de la KV Cache.

Cuando un modelo genera texto, necesita almacenar información sobre todos los tokens anteriores para mantener el contexto de la conversación.

En modelos tradicionales, esta memoria crece rápidamente conforme aumenta el contexto, convirtiéndose en uno de los principales cuellos de botella.

Kimi K3 introduce una representación mucho más eficiente que reduce significativamente ese consumo de memoria sin perder calidad.

Si has visto alguno de los diagramas técnicos del paper probablemente parezca un mecanismo extremadamente complejo. Sin embargo, la idea es bastante sencilla: almacenar únicamente la información realmente necesaria para reconstruir el contexto en lugar de guardar una copia completa de todas las representaciones intermedias.

Es precisamente esta optimización la que permite manejar contextos largos de forma mucho más eficiente.

Muy competitivo en programación

Otro de los motivos por los que Kimi K3 ha llamado tanto la atención es su rendimiento en tareas relacionadas con el desarrollo de software.

Según los resultados publicados por Moonshot AI, el modelo obtiene resultados muy competitivos en benchmarks de programación, razonamiento matemático y resolución de problemas complejos, situándose sorprendentemente cerca de algunos modelos propietarios mucho más conocidos.

Para muchos desarrolladores, esto convierte a Kimi K3 en una alternativa muy interesante para tareas de generación de código, revisión de proyectos o asistencia durante el desarrollo.

La verdadera noticia no es Kimi K3

Curiosamente, la parte más interesante de este lanzamiento no es el propio modelo.

La verdadera noticia es que empieza a ser posible consumir modelos open-weight exactamente igual que utilizamos GPT-4, Claude o Gemini.

Hace apenas un año el proceso habitual era algo parecido a esto:

• Descargar cientos de gigabytes de pesos.

• Configurar CUDA.

• Instalar vLLM.

• Desplegar uno o varios servidores.

• Gestionar GPUs.

• Configurar balanceadores y escalado.

Hoy el proceso se reduce prácticamente a tres pasos:

• Crear una API Key.

• Copiar un endpoint.

• Enviar una petición HTTP.

Ese cambio reduce enormemente la barrera de entrada y hace que experimentar con nuevos modelos sea mucho más sencillo.

Probando Kimi K3 desde DigitalOcean

Una vez accedemos al panel de inferencia de DigitalOcean, únicamente necesitamos crear una API Key y seleccionar Kimi K3 como modelo disponible.

Después podemos utilizar un script tan sencillo como este:

import requests

url = "https://inference.do-ai.run/v1/chat/completions"
headers = {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_MODEL_ACCESS_KEY"
}
data = {
    "model": "kimi-k3",
    "messages": [
        {
            "role": "user",
            "content": "What is the capital of France?"
        }
    ],
    "max_tokens": 100
}

response = requests.post(url, headers=headers, json=data)
print(response.json())

Y eso es todo.

No hay GPUs.

No hay despliegues.

No hay servidores que mantener.

Simplemente realizamos una llamada a la API y comenzamos a utilizar el modelo.

Repositorio de ejemplo

Para facilitar las pruebas he preparado un pequeño repositorio con el ejemplo completo.

El proyecto incluye:

• Un ejemplo mínimo utilizando el cliente oficial de OpenAI.

• Configuración mediante variables de entorno.

• Un README con todos los pasos necesarios para comenzar en menos de cinco minutos.

La idea es que puedas clonar el repositorio, añadir tu API Key y empezar a experimentar inmediatamente.

¿Y si quieres utilizarlo desde Claude Code?

Una de las ventajas de que DigitalOcean exponga una API compatible con OpenAI es que podemos reutilizarla en prácticamente cualquier herramienta del ecosistema.

Si utilizas Claude Code, no necesitas modificar tu flujo de trabajo.

Basta con utilizar LiteLLM como proxy y configurar DigitalOcean como proveedor del modelo.

Hace unas semanas publiqué una guía completa explicando cómo realizar esta configuración paso a paso, por lo que no voy a repetir todo el proceso aquí.

Si todavía no la has leído, te recomiendo empezar por ese artículo y volver después para probar Kimi K3 como backend.

De esta forma podrás utilizar uno de los modelos open-weight más interesantes del momento directamente desde Claude Code sin cambiar tu forma habitual de trabajar.

Conclusión

Hace apenas un año, ejecutar un modelo open de este nivel estaba reservado para quienes disponían de una infraestructura considerable.

Hoy basta con registrarse en un proveedor de inferencia serverless, generar una API Key y escribir unas pocas líneas de Python.

Ese cambio es mucho más importante que el lanzamiento de un nuevo modelo.

Significa que cada vez resulta más sencillo probar, comparar e integrar modelos abiertos en aplicaciones reales sin asumir el coste operativo de mantener la infraestructura.

Kimi K3 probablemente no será el último modelo que llegue a plataformas como DigitalOcean. De hecho, todo apunta a que este será el camino habitual durante los próximos años: modelos abiertos, APIs compatibles con OpenAI y una experiencia de desarrollo prácticamente idéntica independientemente del proveedor que elijamos.

Y eso es una gran noticia para cualquiera que construya aplicaciones basadas en inteligencia artificial.

Recursos

Si quieres seguir profundizando, aquí tienes algunos recursos que pueden resultarte útiles:

• Mi guía para utilizar Claude Code con LiteLLM y DigitalOcean como proveedor de inferencia.

• El repositorio de ejemplo con el cliente de Python utilizado en este artículo.

• La documentación oficial de DigitalOcean Serverless Inference.

• El paper técnico de Kimi K3 publicado por Moonshot AI.

Estamos creando una app para extraer información de tickets de la compra y almacenarlos en una base de datos para poder explotarlos en el futuro.

Utilizando LLMs como palanca para extraer toda la información necesaria.

Sin hoja de ruta, todo es improvisado.

Para que puedas ver como es el proceso lógico de una persona que trabaja esto en el día a día.

En el video de hoy nos dedicamos a ajustar la extracción de datos con IA y a generar el primer modelo de datos para guardar esa información.

La semana que viene tendremos nuestro primer dashboard completo.

Obtén más de Daniel en la app de Substack

Disponible para iOS y Android

Descargar la app

Más servidores MCP.

Más integraciones.

Pero después de pasar el último año construyendo agentes para producción, he llegado a una conclusión: hemos estado optimizando la capa equivocada.

El mayor salto en el rendimiento de un agente no viene de darle una API más.

Viene de enseñarle cómo pensar.

La analogía del ingeniero de software

Imagina que contratas a un nuevo ingeniero de software.

El primer día le das acceso a:

• GitHub

• VS Code

• Slack

• Jira

• Docker

• AWS

Enhorabuena.

Ahora tiene acceso a las mismas herramientas que utilizan tus ingenieros senior.

¿Eso significa que ya es un ingeniero senior?

Por supuesto que no.

La diferencia no está en las herramientas.

Está en la experiencia acumulada.

Los ingenieros senior saben:

• cómo depurar problemas de forma sistemática

• cómo revisar código

• cómo planificar grandes refactorizaciones

• cómo comunicarse con el equipo

• cuándo merece la pena optimizar

• cuándo no merece la pena optimizar

Nada de eso son herramientas.

Son habilidades.

Y con los agentes de IA ocurre exactamente lo mismo.

Las tres capas de un agente de IA

La mayoría de la gente solo piensa en una de ellas.

Capa 1: Herramientas

Las herramientas son acciones.

Permiten que un agente interactúe con el mundo exterior.

Por ejemplo:

• Leer archivos

• Ejecutar código en Python

• Buscar en Internet

• Llamar a una API

• Consultar una base de datos

• Crear Pull Requests en GitHub

Sin herramientas, un agente no puede hacer mucho más que generar texto.

Son el equivalente a darle manos a una persona.

Capa 2: Conocimiento

El conocimiento responde preguntas.

Aquí es donde entran tecnologías como RAG, bases de datos vectoriales, bases de conocimiento o los recursos expuestos mediante MCP.

En lugar de depender únicamente de lo que aprendió durante el entrenamiento, el modelo puede recuperar información externa como:

• documentación de la empresa

• especificaciones técnicas

• wikis internas

• documentos PDF

• datos de clientes

• conversaciones anteriores

La recuperación de conocimiento responde a una pregunta muy concreta:

¿Qué necesito saber antes de tomar esta decisión?

Es la memoria del agente.

Capa 3: Habilidades

Esta es la capa de la que casi nadie habla.

Una habilidad es conocimiento experto reutilizable.

Le enseña al agente cómo abordar una tarea.

Piensa en las habilidades como playbooks ejecutables.

Por ejemplo:

Habilidad de depuración

En lugar de decir simplemente:

“Arregla este bug.”

La habilidad podría indicar al agente que:

1. Reproduzca el problema.

2. Aísle el componente que falla.

3. Revise los cambios recientes.

4. Genere hipótesis.

5. Valide cada hipótesis.

6. Implemente la solución más pequeña posible.

7. Escriba pruebas de regresión.

El modelo no se ha vuelto más inteligente.

Simplemente está siguiendo un mejor proceso.

Las habilidades no son prompts

Este es uno de los errores más comunes.

Una buena habilidad es mucho más que un prompt largo.

Los frameworks modernos de agentes suelen empaquetar las habilidades junto con:

• instrucciones estructuradas

• flujos de trabajo

• ejemplos

• árboles de decisión

• plantillas reutilizables

• scripts auxiliares

• documentación de apoyo

Después, el propio agente decide cuándo cargar esa habilidad.

Curiosamente, es muy parecido a cómo trabajamos los humanos.

Un ingeniero de software no memoriza todas las soluciones posibles.

Recupera modelos mentales que ha ido construyendo durante años.

Las habilidades permiten que los agentes hagan exactamente eso.

¿Dónde encaja MCP en todo esto?

MCP (Model Context Protocol) se ha vuelto enormemente popular.

Pero mucha gente interpreta mal cuál es su función.

Un servidor MCP es, principalmente, una interfaz estandarizada para exponer capacidades.

Esas capacidades pueden incluir:

• herramientas

• recursos

• prompts

• datos estructurados

Por ejemplo, un servidor MCP de GitHub podría exponer:

• búsqueda de repositorios

• creación de issues

• apertura de Pull Requests

• acceso a documentación

Mientras que un servidor MCP de Notion podría ofrecer:

• documentación de proyectos

• notas de reuniones

• diagramas de arquitectura

MCP no sustituye a las habilidades.

Simplemente da acceso a capacidades externas.

Las habilidades enseñan al agente cómo utilizar esas capacidades de forma eficaz.

Un modelo mental útil

Piensa en un agente como si fuera un chef.

Las herramientas son el equipamiento de la cocina.

El cuchillo.

El horno.

La batidora.

El conocimiento es el libro de recetas.

Los ingredientes.

Las temperaturas.

Las proporciones.

Las habilidades son los años de experiencia cocinando.

Saber cuándo algo está demasiado hecho.

Cómo equilibrar sabores.

Cómo salvar un plato cuando algo sale mal.

Comprar un horno mejor no convierte a nadie en un chef con estrella Michelin.

Del mismo modo, darle otra API a un LLM tampoco lo convierte en un mejor agente.

Por qué las habilidades serán la verdadera ventaja competitiva

Todos los modelos de frontera son cada vez más inteligentes.

El uso de herramientas se está estandarizando.

La adopción de MCP está creciendo rápidamente.

Dentro de poco, prácticamente todo el mundo tendrá acceso a los mismos modelos y a herramientas muy parecidas.

La diferencia ya no será el acceso.

Será la experiencia.

Las organizaciones que consigan capturar sus mejores prácticas en forma de habilidades reutilizables estarán encapsulando años de conocimiento interno.

Cada nuevo agente heredará automáticamente esa experiencia.

Y ese es un multiplicador mucho más potente que añadir otra integración.

Construyendo tu propio sistema operativo para agentes

Esta idea cambió por completo mi forma de diseñar agentes.

Antes me preguntaba:

“¿Qué herramientas debería darle a este agente?”

Ahora me hago otra pregunta:

“¿Qué experiencia debería heredar este agente?”

Por eso empecé a construir colecciones de sistemas operativos y habilidades reutilizables que encapsulan flujos de trabajo reales de ingeniería, y no simplemente prompts.

Ya sea para depurar sistemas en producción, diseñar arquitecturas, revisar código, escribir documentación técnica u orquestar flujos de trabajo complejos con IA, el objetivo siempre es el mismo:

Darles experiencia a los agentes, no solo acceso.

Si estás construyendo agentes de IA para proyectos serios, empieza a pensar más allá de las APIs y las integraciones.

Enséñales cómo trabajan los expertos.

Ahí es donde llegará la próxima gran revolución en productividad.

¿Quieres agentes que trabajen como ingenieros senior desde el primer día?

He empaquetado muchas de estas metodologías en una colección de sistemas operativos y habilidades reutilizables que puedes instalar directamente en Claude Code.

Incluye flujos de trabajo para ingeniería de software, estrategias de depuración, diseño de arquitectura, revisión de código, desarrollo con IA y mucho más.

Puedes ver la colección completa aquí:

Claude OS Collection

https://iamdgarcia.gumroad.com/l/claude-os-collection

y… si te gustaría que hiciese una recopilación de algún otro sector…

Aprovechamos los primeros minutos para comentar un tema algo polémico:

Está dejando de tener sentido el término “AI Engineer”??

Deja un comentario

En la segunda parte del directo nos lanzamos directamente a crear un mini proyecto para aprender a generar un extractor de documentos utilizando IA.

La idea es ver hasta donde llegamos sin escribir una línea de código.

De momento ya hemos creado la estructura de nuestra API y procesado nuestro primer documento.

El objetivo a largo plazo será tener una pequeña app conectada a telegram para poder subir los tickets de la compra y poder realizar distintos análisis posteriormente.

En paralelo, otro agente conversacional nos permitirá analizar nuestras estadísticas de foma conversacional.

La idea es ir continuando con este proyecto en directo para que podáis ver la realidad de hacer proyectos personales usando IA.

Intentaré seguir mejorando la calidad de los directos durante las próximas semanas.

Como siempre, todo tipo de feedback es bienvenido:

Deja un comentario

Si este contenido te resulta útil y quieres que sigamos publicando recursos sobre IA para equipos de desarrollo, puedes apoyar la comunidad haciéndote mecenas:

Si usas Claude Code en equipo, lo más probable es que estés pagando por el mismo trabajo varias veces. No porque Claude sea caro. Sino porque no tienes ninguna capa en medio que recuerde lo que ya procesó.

Eso tiene solución. Y se llama prompt caching con LiteLLM.

El problema en cuestión

Cuando haces una pregunta con Claude Code, le mandas mucho más que tu pregunta. Le mandas el contexto completo: las instrucciones del proyecto, el fichero que tienes abierto, el historial de la conversación. Todo eso son tokens. Y todos esos tokens se cobran.

Ahora imagina que tú y un compañero trabajáis en el mismo repositorio. Los dos usáis Claude Code. Los dos le preguntáis cosas sobre el mismo código.

¿Qué ocurre? Que Claude recibe el mismo contexto dos veces. Lo procesa dos veces. Os cobra a los dos.

Es como contratar a un consultor para que lea tu documentación, te responda y te cobre. Al día siguiente mandas a otra persona con la misma documentación. El consultor la vuelve a leer entera. Y te vuelve a cobrar.

En un equipo de cinco personas trabajando sobre el mismo repositorio, esto se multiplica. Pagas cinco veces por contexto que podría procesarse una sola vez.

La solución: un gateway en medio

LiteLLM es un proxy open source que se sienta entre tu equipo y la API de Claude. En lugar de que cada desarrollador llame directamente a Anthropic, todos llaman a LiteLLM. Y LiteLLM se encarga de hablar con Claude.

La gracia está en el prompt caching de Anthropic. Claude puede guardar en memoria partes del contexto — el system prompt, el contenido de un fichero, las instrucciones del proyecto — y reutilizarlos sin volver a procesarlos. Los tokens cacheados cuestan un 90% menos que los tokens normales.

LiteLLM activa esto automáticamente. No tienes que cambiar nada en tu forma de trabajar.

Cómo funciona el flujo

Primera petición — Cache MISS

Dev 1 hace una pregunta sobre el código. La petición llega a LiteLLM. LiteLLM no tiene nada guardado aún — es la primera vez que alguien pregunta con ese contexto. Reenvía la petición a Claude con la cabecera de caché activada. Claude procesa todo, responde, y guarda el contexto en memoria.

Pagas el 100% del coste. Normal. Es la primera vez.

Segunda petición — Cache HIT

Dev 2 entra a trabajar. Mismo repositorio, contexto similar. La petición llega a LiteLLM. Esta vez sí tiene algo guardado.

LiteLLM no necesita mandarle a Claude el contexto completo otra vez. Claude ya lo tiene en memoria. Solo procesa la parte nueva — la pregunta específica de Dev 2.

El coste se desploma. En contextos típicos de trabajo en equipo — 10.000, 20.000 tokens de contexto compartido — el ahorro real se acerca al 80%.

Por qué es especialmente potente en equipos

El prompt caching funciona bien en cualquier caso. Pero escala de forma extraordinaria cuando hay contexto compartido.

Un equipo que trabaja sobre el mismo monorepo comparte el mismo system prompt, los mismos ficheros de configuración, las mismas instrucciones de proyecto. Ese contexto es el que más tokens consume. Y es exactamente el que se cachea.

Cuanto más grande el equipo y más cohesionado el contexto de trabajo, mayor es el ahorro.

Esto también aplica a ti solo: si haces varias preguntas seguidas sobre el mismo fichero, cada pregunta posterior aprovecha la caché de la anterior. El sistema aprende a ser eficiente sin que hagas nada diferente.

Cómo montarlo

La configuración es más sencilla de lo que parece. Instalas LiteLLM, lo arrancas con tu clave de Anthropic, y apuntas Claude Code a tu instancia local en lugar de a Anthropic directamente. Todo lo demás es transparente — el mismo Claude, la misma calidad de respuestas, a una fracción del coste.

Tengo un vídeo dedicado a la instalación paso a paso aquí:

El vídeo completo

Si prefieres verlo explicado visualmente, con el diagrama del flujo de datos y la narración completa, lo tienes aquí. Dura menos de siete minutos.

Si este contenido te resulta útil y quieres que sigamos publicando recursos sobre IA para equipos de desarrollo, puedes apoyar la comunidad haciéndote mecenas:

Gracias por leer.

Matamos dos pájaros de un tiro.

Como os digo en el video, me gustaría que esta sección empiece a estar algo más enfocada en resolver vuestras dudas.

También podemos intentar traer invitados!

Dime en los comentarios

Deja un comentario

Obtén más de Daniel en la app de Substack

Disponible para iOS y Android

Descargar la app

Hoy te explico el proceso exacto que seguí. No los detalles técnicos de la feature, sino cómo trabajar con un agente de IA para ir desde una idea hasta código en producción.

Son tres fases: doc funcional, doc técnico, implementación. Y entre cada una hay un paso que la mayoría se salta: el análisis adversario.

El punto de partida: una idea sin forma

Alguien de mi comunidad me pasó un enlace a un producto de la competencia — una extensión de Chrome de pago que enviaba DMs masivos a suscriptores de Substack.

Cobran 20$ por algo que para mi no tiene mucho valor

y ya sabéis que yo me debo a mi comunidad

asi que…

Quería replicarlo como feature gratuita en StackNotes.

Problema: tenía una idea vaga y capturas de pantalla. No sabía exactamente qué hacía, cómo funcionaba por dentro, ni qué necesitaba para construirlo.

y, por supuesto, tampoco me sobra el tiempo para hacer estas cosas.

Ahí empieza el proceso.

inciso.

Por si eres nuevo por aquí, te cuento que hace unos meses construí una herramienta gratuita para gestionar la publicación de notas en substack y ha ido creciendo poco a poco hacia una herramienta completa de gestión de substack.

Se llama Stacknotes y si eres creador, seguro que te interesa.

Fase 1: El documento funcional

El documento funcional responde a una pregunta simple: ¿qué hace el usuario?

No qué hace el sistema. No cómo se implementa. Solo: ¿qué ve el usuario, qué puede hacer, qué pasa cuando lo hace?

Cómo generarlo con Claude

Lo primero que hice fue darle a Claude toda la información de entrada que tenía: el texto de la página de venta del competidor y siete capturas de pantalla de la extensión en uso.

El prompt fue:

Claude extrajo:

- Campo de mensaje con `{{USER_NAME}}` para personalización

- Delay configurable entre envíos para no parecer spam

- Filtros por tipo de suscriptor (free / paid / todos)

- Toggle “Only Empty Chat” para no molestar a quien ya tienes conversación

- Toggle “Unique Message” para no repetir mensajes

- Barra de progreso con pausa y reanudación en tiempo real

En tres minutos tenía el inventario completo de lo que necesitaba construir.

Lo que el doc funcional NO incluye

Aquí es donde mucha gente se equivoca: el doc funcional no menciona tecnología. No dice “edge function”, no dice “base de datos”, no dice “API”. Solo describe comportamiento desde el punto de vista del usuario.

Si empiezas a hablar de implementación en esta fase, contaminas el diseño. Las decisiones técnicas deberían seguir a los requisitos funcionales, no al revés.

El primer análisis adversario

Antes de pasar a la doc técnica, hice algo que cambió el diseño por completo.

Un truquito made in Daniel

que a mi me funciona de lujo siempre

le pedí a Claude que atacara su propio trabajo

Hay mil formas de hacerlo, incluso ya he compartido con alguno de vosotros por privado alguna forma más avanzada de robustecer un diseño

Si quieres que hable más en profundidad de ello, déjame un comentario con tus dudas al respecto

Deja un comentario

Claude me devolvió algo que no había pensado: ¿y si quieres hacer esto automáticamente para cada nuevo suscriptor?

Auto-welcome. Mensaje automático de bienvenida cuando alguien se suscribe.

Una pregunta adversaria cambió el alcance del proyecto. Y lo descubrimos antes de escribir una línea de código, no después de desplegar.

Esta es la clave del análisis adversario en la fase funcional: no es un ejercicio académico. Es encontrar los requisitos ocultos antes de que el diseño técnico los excluya por omisión.

Fase 2: El documento técnico

Con el doc funcional cerrado y validado, pasé a la arquitectura técnica. Esta fase responde a: ¿cómo construye el sistema lo que el usuario necesita?

El prompt:

“Dame opciones, no una sola solución” — esto es importante. Si no lo pides explícitamente, Claude tenderá a darte la primera opción que encuentre. Pedir múltiples opciones te fuerza a tomar una decisión informada.

Claude presentó tres arquitecturas diferentes. Para cada una describió: cómo funciona, qué ventajas tiene, qué problemas podría causar.

Cómo elegir entre opciones

No le pedí a Claude que eligiera (aunque si no tienes ni idea de lo que está hablando, quizás tu mejor opción es que lo haga).

Yo elegí, con criterios que Claude no podía tener: qué parte del sistema necesito que sea fácil de depurar, cuánto complejidad quiero asumir, qué prefiero que falle de una forma visible.

Claude sabe sobre patrones de arquitectura. Yo sé sobre mis prioridades.

El doc técnico también descubre potenciales fallos

Al diseñar la arquitectura, Claude identificó algo que el doc funcional no había resuelto: para enviar un DM a alguien en Substack necesitas su ID numérico, no su email. ¿Los datos que ya tenemos incluían ese ID?

Claro, para saber esto tuve que hacer alguna prueba manual desde el navegador para ver cómo se mandaban los mensajes.

Aproveché algunos DMs que tenía pendientes de contestar para ver la estructura de la petición

Abrí DevTools en Substack, inspeccioné la respuesta de la API de suscriptores, y le copié lo que veía. Claude lo confirmó: sí, el ID estaba ahí.

Esto ilustra algo que pasa constantemente: el doc técnico descubre incógnitas que el doc funcional asumía resueltas. Es normal. No es un fallo del proceso.

Como siempre digo, esto es algo iterativo

El segundo análisis adversario

Antes de implementar, con la arquitectura sobre la mesa, hice el análisis adversario técnico:

Claude identificó varios riesgos: que las cookies de sesión podrían expirar, que Substack podría limitar la frecuencia de peticiones, que los delays entre mensajes necesitarían ajuste.

Pero hubo uno que no identificó correctamente — y aquí está la lección más importante del proceso.

Claude propuso que el proxy del servidor podría hacer peticiones a Substack con las cookies del usuario. Eso sonaba razonable. Era incorrecto.

Lo que Claude no sabía (y yo no me acordaba) es que Substack usa Cloudflare Bot Management, que emite cookies de seguridad ligadas a la IP del navegador y su fingerprint TLS. Un servidor en un datacenter, por mucho que tenga las cookies correctas, siempre recibe 403.

Esto no era algo que el análisis adversario sobre papel pudiera descubrir. Solo lo descubrimos al ejecutar el código y leer los logs.

El análisis adversario reduce riesgos, no los elimina. Su valor está en encontrar los problemas obvios antes de implementar. Los problemas no obvios se encuentran en producción.

Fase 3: La implementación

Con doc funcional, doc técnico y análisis adversario completados, la implementación fue la parte más mecánica del proceso.

Agentes en paralelo

En lugar de pedirle a Claude que construyera todo secuencialmente, usé cuatro agentes en paralelo, cada uno con una tarea independiente:

- Agente 1: la migración de base de datos

- Agente 2: las funciones del backend

- Agente 3: el hook de React con la lógica de estado

- Agente 4: la interfaz de usuario

En paralelo. Sin esperar a que uno terminara para empezar el siguiente.

Esto funcionó porque la spec era precisa. Cuando la especificación es ambigua, los agentes toman decisiones de diseño implícitas, y esas decisiones son las que luego provocan bugs difíciles de diagnosticar. Cuando la spec es clara, el código generado es predecible.

Ojo, esto no es necesario, pero te ahorra bastante tiempo. Siempre que los trabajos no se solapen, yo suelo paralelizar lo máximo posible para ahorrar tiempo

Cómo dar contexto a cada agente

Cada agente recibió tres cosas:

1. El fragmento del doc técnico relevante para su tarea

2. El contexto del proyecto (qué stack, qué patrones existen)

3. Una instrucción de límites: qué NO debe tocar

Sin los límites, los agentes tienden a refactorizar cosas que no debían tocar, a añadir abstracciones que no pediste, o a cambiar convenciones existentes porque les parecen mejores.

El debugging como proceso, no como magia

La implementación inicial no funcionó perfectamente. Hubo varios bugs. Aquí es donde mucha gente pierde la fe en el proceso: “la IA rompió algo”.

No es así como funciona. El debugging con IA es un proceso de darle información específica y pedirle hipótesis específicas.

Qué no hacer

Esta instrucción es inútil. Claude no puede ver los logs, no sabe qué está pasando, y va a proponer hipótesis a ciegas.

Aquí viene el principal problema del vibe coding cuando lo hace alguien que no sabe ni por donde le da el aire

Qué hacer

1. Copia los logs exactos

2. Describe el comportamiento observado vs el esperado

3. Pide hipótesis ordenadas por probabilidad

4. Valida cada hipótesis antes de pasar a la siguiente

Con información específica, Claude puede diagnosticar con precisión. Sin ella, adivina.

Cuándo el diagnóstico de Claude no puede funcionar

Hubo un momento donde Claude identificó una causa probable pero la solución propuesta era arquitecturalmente imposible — el servidor no puede hacer ciertas peticiones a Substack, sin importar cómo se configure.

Esto requirió juicio humano: reconocer que el problema no era de configuración sino de diseño. La solución fue cambiar la arquitectura, no parchear el código.

Claude puede diagnosticar dentro del espacio de soluciones que conoce. Detectar que estás fuera de ese espacio es trabajo tuyo.

El proceso completo

Lo que el humano hace en cada paso:

- Doc funcional: proveer inputs reales (capturas, texto), validar que cubre todos los casos de uso

- Análisis adversario: hacer las preguntas incómodas, no aceptar la primera respuesta

- Doc técnico: elegir entre opciones con criterios propios, no delegar la decisión

- Implementación: definir límites claros para cada agente, revisar que el código generado sea coherente con la spec

- Debugging: proveer información específica, detectar cuándo la solución propuesta no puede funcionar

Lo que Claude hace en cada paso:

- Estructurar y completar lo que describes

- Proponer opciones con trade-offs

- Generar código sobre especificaciones claras

- Diagnosticar con la información que le das

Lo que cambia cuando sigues este proceso

El error más común que veo es saltarse la doc funcional y la doc técnica, ir directamente a “construye esto” y luego intentar arreglar lo que sale.

El código que sale de “construye esto” sin spec es funcional pero frágil. Las decisiones de diseño quedan implícitas en la generación, no en un documento que puedes revisar y cuestionar. Cuando algo falla, no sabes si el error es en los requisitos, en la arquitectura, o en el código.

Cuando sigues el proceso completo, sabes exactamente en qué capa está el problema.

No quiero alargarme mucho, tengo un post explicando por qué es mala idea acumular deuda técnica

Si has llegado hasta aquí, déjame recordarte varias cosas:

Una parte de mi trabajo consiste en ayudar a empresas y particulares en temas de Inteligencia artificial

Bien desarrollado

o bien aconsejando y/o acompañando

si quieres más información, puedes rellenar el formulario de mi web

AQUÍ

Por otro lado, ya sabéis que The Learning Curve es una comunidad gratuita

Considero que la mayoría de contenido de pago que hay por ahí no merece la pena (la herramienta sobre la que hemos trabajado en este post es un ejemplo de ello)

hay gente cobrando 20$/mes por cosas similares

yo intento traerlas gratis

porque entiendo que no todo el mundo está en la misma situación.

Stacknotes para mí es un gasto

Sin embargo, tengo un sistema de mecenas para apoyar el contenido que hago

Es un precio simbólico de 5$/mes pero para mí significa un mundo

Te dejo aquí el enlace

Apoyar The Learning Curve

Si eres de los que siente que se pierde todos los trenes tecnológicos, tranquil@, no estás sol@.

Lecturas relacionadas:

Curso gratuito sobre desarrollo de sistemas agénticos

• Observabilidad para LLMs con Langfuse

Langfuse Documentation

• Evaluación de aplicaciones RAG

Ragas Framework

• Versionado de prompts y tracing

LangSmith

• OpenTelemetry para sistemas de IA

OpenTelemetry

Nos vemos en el próximo episodio.

Si te gusta lo que hago y quieres colaborar para que pueda seguir siendo gratis para el resto del público, te recomiendo echarle un vistazo al sistema de mecenas: