SPONSORED by NoCODEoPENsOURCE

🚀 ¿Quieres que tu negocio aparezca aquí?
Da a conocer tus servicios ante una comunidad de profesionales del mundo digital, startups y desarrolladores.

👉 Anúnciate por solo 120 € y gana visibilidad real

Hola,

Llevamos años escribiendo `switch/case`. Una API te devuelve un rango "100 a 200 €", otra te devuelve "99 a 200", otra "80 a 250", y tú abres el editor y empiezas a mapear casuísticas. Cuando aparece una nueva, vuelves al `switch`. Otro `case`. Otro mapeo. Hasta que un día Marco se da cuenta de que en lugar de gastar dos tardes mapeando, podría meter un Haiku en medio que decida en tiempo real cuál es el match correcto.

Esta semana va de eso. El patrón se llama decision-maker — meter un LLM como pieza dentro de una arquitectura determinista, no para reemplazarla, sino para resolver el trozo concreto que la lógica humana resuelve mejor que la algorítmica. Marco lo descubre con cuatro APIs distintas que no debería haber tenido que normalizar a mano.

Pero el episodio tiene también su contrapunto. Oriol cuenta en el G33K TEAM cómo casi mete un agente IA en una arquitectura donde no aportaba absolutamente nada — y la frase que le ha quedado grabada: "cuando tienes un martillo, todos te parecen clavos". Aprender cuándo meter un LLM importa tanto como aprender cuándo no meterlo. Las dos lecciones van juntas.

En el podcast Néstor entra y sale desde Shanghai con la cobertura del demonio, Oriol enseña su forecasting de autonomía del SAI conectado a Home Assistant, hablamos de Kestra como capa de orquestación de sistemas y del lío del open source que monetiza lo que tú necesitas (la API de Cal.com, la gestión de acceso de Kestra). Y un patrón que va a aparecer dos veces este número: agentes como A2A para tareas que antes ejecutabas tú a mano.

Vamos al lío 👇

📅 G33K TEAM de la Semana

🎙️ Episodio 47 — Decision-maker pattern, Kestra, Sai con forecasting y Shanghai a trozos

Sesión número 47. Néstor entrando desde Shanghai con cobertura del demonio (su SIM de viaje rutea por Texas, descubierto en directo). Oriol y yo llevando el peso. El episodio sale denso: el tema central fue cuándo meter un LLM en una arquitectura determinista —y cuándo no—, con ejemplos reales de los dos lados. De ahí derivamos a Kestra, al lío del open source que monetiza la API, al stack agéntico de Oriol con MiTube y Whisper como A2A, y al cierre con su Sai conectado a Home Assistant.

El patrón decision-maker (el tema central): el caso de Oriol fue cristalino. Cuatro APIs distintas devolviendo rangos de ingresos: una "100-200 €", otra "99-200", otra "80-250". Antes tenía que normalizar a mano con `switch/case`, un mapping por cada API. Cada vez que aparecía una nueva, vuelta al editor. Ahora mete un Haiku como decisor en medio del flujo: el LLM lee el output de cada API y devuelve el rango normalizado. Cero alucinación, porque el modelo solo tiene que mapear input a output sobre un espacio acotado. La conclusión: "para tareas donde la lógica humana opera mejor que la algorítmica, y donde las casuísticas son demasiadas para mapearlas a mano, el LLM en medio del flujo es brutal."

Mi caso: el LLM como capa de UX: añadí otro caso al patrón. Aplicaciones con formularios complejos donde el campo tiene una descripción ambigua o insuficiente. En lugar de hacer documentación que nadie va a leer, despliegas un modelo pequeño como servicio interno, le pasas en el system prompt el rol y la parametrización del contexto del usuario, y genera descripciones humanizadas a-doc de qué está seleccionando y qué va a hacer. La aplicación sigue funcionando igual, pero tiene helpers en línea que no tendrías capacidad de mantener a mano para cada combinación.

La trampa del martillo y los clavos (el contrapunto): Oriol contó el caso opuesto. Estaba montando una arquitectura con Kestra orquestando playbooks de Ansible, y se le ocurrió meter un agente IA en medio para "decidir cosas". Al cabo de un día se paró: "¿para qué me estoy complicando si tengo una aplicación algorítmica que llama a una API que al final ejecuta una CLI? El agente no aporta nada aquí." Lección operativa: cuando aparece la idea, apuntarla y darle 15 días. Si en 15 días sigue teniendo sentido, hacerlo. La mayoría de las veces se le pasa el calentón al detectarlo a tiempo.

Kestra como capa de orquestación: Oriol enseñó Kestra en pantalla, la herramienta donde estaba metiendo todo el flujo de Ansible. Es como N8N pero a otro nivel: si N8N es flow-based con un enfoque de oficina, Kestra apunta a sistemas técnicos (despliegues, plataformas, infraestructura). Asistido por IA dentro del editor de flows. Cuando ejecutas un flow te muestra un timeline tipo Gantt con cada paso y su duración, observabilidad estilo OpenTelemetry de serie. Listo para Google API keys por defecto.

El problema del open source que monetiza la API: Oriol está dejando de usar Kestra porque la API en open source no tiene gestión de acceso — solo usa las mismas credenciales que la UI. La feature de IAM (Keycloak integration) está solo en Business. "Buena decisión de diseño, pero me das por saco si quiero usar open source." El otro ejemplo del mismo patrón: Cal.com, que hace unos meses quitó la API en open source y dejó solo webhooks. La solución de Oriol: monta un workaround tirando del webhook como API. Recurrente este año — el open source que se reserva las features que tú necesitas.

El debate del business model del open source: derivó a un debate más amplio. Oriol defendiendo el modelo "págame poco pero págame de por vida" — licencias testimonio de menos de 50€ vitalicias. Crítica abierta a las licencias de 10.000€/año por productos discontinuados sin parches. Contó cómo refactorizó un producto entero en dos o tres meses para no pagar una licencia abusiva de un software que ya ni evolucionaba.

El proyecto interno con 7 stacks que se va a Kubernetes: anuncio que cae a media conversación. Oriol y yo llevamos meses con un proyecto que integra siete stacks independientes pero comunicados. Esta noche Oriol le va a dar a Claude Sonnet 4.8 en modo Ultracode con el goal de reorganizar el repo entero: pasar a monorepo, migrar los stacks de Docker Compose a namespaces de Kubernetes, adaptar backlog.md (la herramienta de gestión de tareas que están usando en la UI) a la nueva estructura. "A gastar tokens como si no hubiera un mañana." Continúa la línea de Ultracode del episodio anterior — tareas que antes te llevaban días, ahora 40 minutos.

MiTube y Whisper como agentes A2A: Oriol contó el patrón que está aplicando sistemáticamente. MiTube lo extendió hace unas semanas para que se comportara como agente A2A registrado en el marketplace de agentes — desde Claude Code puede pedirle que descargue vídeos de YouTube. Esta semana ha replicado el patrón con Whisper: UI propia que gestiona colas de transcripciones, API para gestionarlas, y exposición A2A. La gracia es lo que viene después.

El skill "Getting Things Done" cerrando el ciclo: la pieza más bonita del episodio. Oriol tiene un agente con un skill que cuando recibe la URL de una reunión grabada: llama a Whisper A2A para que ponga el vídeo en cola y devuelva el VTT con marcas de tiempo. Recibe el VTT. Genera el acta de reunión. Llama al MCP de Notion. Sube el vídeo, el VTT y el acta a Notion. Todo encadenado, automático. "De 20 minutos a 2 minutos. Mi esfuerzo se reduce a pedirlo, revisar el borrador y darle al enter."

El Galaxy S25 que grita consignas: Oriol contó su experimento de la semana con Home Assistant. Quería que el móvil se volviera loco si pasaba algo crítico (por ejemplo, una intrusión). No consigue hacer que se encienda la pantalla con texto desde Home Assistant, pero sí consigue que el TTS hable. "El móvil te grita consignas. Muy divertido." Patrón general: la integración entre Home Assistant y notificaciones críticas de Android sigue siendo limitada en S25 a pesar de updates recientes.

Sai online + Home Assistant + forecasting: cierre del episodio. Oriol enseñó su Salicrú SLC 1500 Twin Pro 2 (unidad de control + baterías) integrado con Home Assistant. La interface HID-USB del Sai expone estados que él descubrió en su día por ingeniería inversa, y ahora Home Assistant lo lee nativo. La pieza que se ha currado: un forecasting de autonomía en tiempo real basado en el consumo de las últimas 3 horas (676W instantáneos cuando me lo enseñó). Histórico de input voltage (que baja a veces a 200V por su zona), output estable. Caso de uso real: los vecinos cultivaban marihuana hace años y reventaban electrodomésticos por picos. El Sai online es la solución desde entonces.

Néstor desde Shanghai entrando a trozos: novedades de su viaje, contadas entre cortes de conexión. ByteDance trayendo cosas tochas para Q3-Q4 (no podía decir qué pero la pista era equipo de RSPack). El equipo de Links presentando algo en multiplataforma desplegado con Cloudflare. Alibaba con base de datos vectoriales open source para devices, equipo de 15-20 personas todos jóvenes con potencial real. Descubrimiento operativo: las SIM de viaje "para extranjeros" rutean por Texas, lo que explica que funcione Google Maps en China. Y por tercera o cuarta vez en la historia del podcast, se cruzó con otro ferrolano en Shanghai. "Así es mi vida."

🔗 Links del episodio:

• Kestra — Orquestador de workflows técnicos con observabilidad OpenTelemetry de serie
• Kestra plugins catalog — El listado de conectores disponibles
• Semaphore UI — UI para gestionar despliegues con Ansible (la alternativa ligera a AWX)
• Ansible AWX — La UI oficial de Ansible (la que decidieron descartar por demasiado pesada)
• Cal.com — Calendario open source con el lío de la API solo en Business
• yt-dlp — La CLI base sobre la que está construido MiTube
• Home Assistant — La plataforma de Oriol para integrar el S25 y el Sai
• Salicrú SLC Twin Pro 2 — El modelo de Sai online de Oriol

ℍ𝕠𝕣𝕚𝕫𝕠𝕟𝕥𝕖 𝔸𝕣𝕥𝕚𝕗𝕚𝕔𝕚𝕒𝕝

Te presentamos "Horizonte Artificial", la nueva y flamante sección de nuestra newsletter dedicada exclusivamente a la Inteligencia Artificial. Pero no esperes el contenido convencional que inunda TikTok o YouTube. Aquí, nos sumergiremos en el fascinante mundo del OpenSource, explorando proyectos libres que puedes desplegar en tu propio servidor. Y para guiarnos en esta travesía, contamos con la experticia de Jesús Pacheco, mejor conocido en nuestra comunidad HiveAgile como "Pachecodes". Prepárate para una perspectiva fresca y auténtica sobre la IA. ¡Bienvenidos al horizonte!

🌟 TopGit - Resumen Semanal (2026-06-13)

📚 Repositorios Destacados de la Semana

Los siguientes repositorios han sido seleccionados por su relevancia, calidad y métricas de GitHub:

🔧 💻 CodeBurn: Seguimiento de tokens de IA

CodeBurn es una herramienta interactiva que permite rastrear el uso de tokens, costos y rendimiento en más de 25 herramientas de codificación de IA, como Claude Code, Codex y Cursor. Con CodeBurn, puedes desglosar el gasto por tipo de tarea, modelo, herramienta y proyecto, lo que te permite ver exactamente a dónde va tu presupuesto. La aplicación funciona de forma local sin necesidad de proxies o claves API, leyendo datos de sesión directamente desde el disco. ¡Optimiza el uso de tus herramientas de IA y controla tus gastos!

📊 Estadísticas de GitHub:
- ⭐ 7,937 estrellas
- 🔄 610 forks
- 👀 24 observadores
- 📝 49 issues abiertos
- 🔤 Principal lenguaje: TypeScript

🔧 👻 Ghosler - Newsletters para Ghost

Ghosler permite el envío fácil de boletines utilizando tu propio correo electrónico y credenciales SMTP. Ideal para aquellos que están comenzando y tienen una base de usuarios pequeña a moderada, ayudando a superar las limitaciones del sistema de Mailgun predefinido.
Este sistema soporta múltiples cuentas de correo e incluye características analíticas para optimizar tus envíos.

📊 Estadísticas de GitHub:
- ⭐ 83 estrellas
- 🔄 10 forks
- 👀 3 observadores
- 📝 8 issues abiertos
- 🔤 Principal lenguaje: EJS

📊 Análisis de Distribución por Categorías

La siguiente gráfica muestra la distribución de proyectos por categoría en TopGit:

📈 Estadísticas Semanales

🏆 Top 3 Categorías

📊 Distribución Detallada

🤖 IA & Machine Learning ████████████████████ 100%  (2 repos)

🚀 Tendencias Destacadas

📈 Métricas Clave

• Repositorios Totales: 2
• Promedio Diario: 0.3 repos/día
• Categorías Activas: 1

🎯 Categorías Dominantes

1. IA & Machine Learning
   - 2 repositorios
   - 100.0% del total

💡 Análisis de Tendencias

No se pudo generar el análisis de tendencias.

El día que Marco metió un Haiku entre dos APIs

Marco lleva tres tardes mapeando rangos de ingresos de cuatro APIs distintas en un switch/case que cada semana le pide otro case más. Un martes a las tres y media, después de comer, se le ocurre la idea más obvia del año.

Tres y media de la tarde. Marco vuelve del comer con un café en la mano y abre el editor. Tiene siete tabs abiertas — el código del módulo de scoring crediticio, las docs de las cuatro APIs que tiene que normalizar, y un Slack del CTO preguntando para cuándo está lista la integración.

El problema es estúpido. Cuatro APIs distintas le devuelven el mismo dato — el rango de ingresos del cliente para calcular su score — pero cada una con su propio formato. La primera lo devuelve como "100-200 €". La segunda como "99-200 EUR". La tercera como "80 to 250". La cuarta, la más reciente, ha empezado a devolver "€100k-€200k" porque el cliente que la consume principalmente es B2B.

Marco lleva tres tardes con esto. El código del normalizador es ya un monstruo:

function normalizeIncomeRange(raw, source) {
  if (source === 'api-a') {
    const match = raw.match(/^(\d+)-(\d+)\s*€$/);
    if (match) return { min: +match[1], max: +match[2] };
  }
  if (source === 'api-b') {
    const match = raw.match(/^(\d+)-(\d+)\s*EUR$/);
    if (match) return { min: +match[1], max: +match[2] };
  }
  if (source === 'api-c') {
    const match = raw.match(/^(\d+)\s+to\s+(\d+)$/);
    if (match) return { min: +match[1], max: +match[2] };
  }
  if (source === 'api-d') {
    const match = raw.match(/^€(\d+)k-€(\d+)k$/);
    if (match) return { min: +match[1] * 1000, max: +match[2] * 1000 };
  }
  // y mañana la api-e, la api-f, ...
}

Cada semana aparece una variante nueva. La api-a ahora a veces devuelve "100 - 200 €" con espacios. La api-c ha empezado a devolver "80–250" con guion largo en vez de corto. La api-d para clientes premium devuelve "€1M+" sin rango superior. Marco lleva tres tardes añadiendo ifs.

Lo peor no son los ifs. Lo peor es el código que rompe en producción cuando aparece una variante nueva sin avisar. El monitor le pinta un pico de errores. Marco abre Sentry, busca el payload, añade otro if, despliega. Y a esperar al siguiente pico.

La idea obvia que tarda tres tardes en aparecer

Marco se levanta a por otro café. De camino se acuerda de algo que leyó la semana pasada en el newsletter — un patrón que llamaban decision-maker. La idea era simple hasta el ridículo: meter un LLM como pieza dentro del flujo determinista, no para sustituir el algoritmo, sino para resolver el trozo que el algoritmo resuelve mal.

Su switch lo resuelve mal. No porque sea técnicamente malo, sino porque las variantes son infinitas en la práctica. Cada API es un proveedor distinto con su propio ritmo de cambio, y cada cambio es un parche en producción.

Vuelve a la mesa. Abre Claude. Le pasa el problema sin más:

"Tengo cuatro APIs que devuelven rangos de ingresos en formatos distintos: 100-200 €, 99-200 EUR, 80 to 250, €100k-€200k. A veces aparecen variantes con espacios o guiones distintos. Necesito normalizarlos a { min: número, max: número | null } siempre en euros."

Claude le devuelve una idea distinta a la suya. Le dice: "para esto no necesitas Claude, te basta con Haiku. Es exactamente el tipo de tarea para la que el modelo más barato funciona perfecto."

El modelo más barato como pieza de arquitectura

Marco no se lo había planteado así. Haiku no es "el modelo más barato porque es peor". Es el modelo más barato porque la tarea es acotada. Para una decisión con input bien definido y output con esquema fijo, el modelo grande es overkill — gasta más tokens, tarda más, y no decide mejor.

Reescribe el normalizador en quince minutos:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function normalizeIncomeRange(raw) {
  const response = await client.messages.create({
    model: "claude-haiku-4-5",
    max_tokens: 100,
    system: `Eres un normalizador de rangos de ingresos a JSON.
Recibes un string con un rango (puede tener € o EUR o sin moneda, 
puede ser anual en miles con sufijo k, puede tener guion corto o largo).
Devuelves SIEMPRE JSON con el shape:
{ "min": number, "max": number | null, "currency": "EUR" }
Asume EUR si no hay moneda explícita.
Si el rango es "X+" (sin tope), max es null.
NO añadas comentarios, NO uses markdown, devuelve solo el JSON.`,
    messages: [{ role: "user", content: raw }]
  });

  return JSON.parse(response.content[0].text);
}

Lo prueba con los cuatro formatos que tiene. Lo prueba con el formato con espacios. Lo prueba con el guion largo. Lo prueba con "€1M+". Lo prueba con "unknown", donde el modelo razonablemente le devuelve { "min": null, "max": null, "currency": "EUR" } y un comentario que le pide que quite.

Quince minutos. Cero parches en producción durante la semana siguiente.

Lo que cuesta y lo que ahorra

Marco mide a la semana siguiente. El normalizador procesa unas 4.000 peticiones al día. Cada llamada a Haiku son unos 80 tokens de input y 30 de output. A precios de Haiku en junio de 2026, son unos 15 céntimos al día. Cinco euros al mes.

Compara contra el coste oculto del switch: tres tardes de Marco a la semana siguiente, cada vez que aparecía una variante nueva. Tres tardes de Marco al mes son unas 24 horas de senior engineer. Aunque solo paguen las que están en producción —la mitad— son 12 horas. A su tarifa interna, 600 €. Para ahorrar cinco euros al mes en tokens.

El análisis tradicional dice "meter LLM en el camino crítico es caro". El análisis honesto dice "no meter LLM ahí porque me da miedo es caro de otra manera".