DOMINICODE

Author: Dominicode

  • Cómo crear un plugin para Anthropic Claude usando MCP

    Cómo crear un plugin para Anthropic Claude usando MCP

    Crear tu primer plugin para Anthropic Claude (Claude Code)

    Crear tu primer plugin para Anthropic Claude (Claude Code) no es magia. Es arquitectura. En vez de «pegar texto en el prompt», vas a exponer funciones ejecutables que Claude puede invocar como herramientas reales. Aquí tienes una guía práctica, técnica y directa para hacerlo funcionar en minutos.

    Tiempo estimado de lectura: 5 min

    • Convierte prompts en herramientas: expón funciones (tools) que Claude invoca mediante MCP en lugar de meter contexto en el prompt.
    • Implementa un servidor MCP: el servidor genera schemas automáticamente y maneja llamadas desde Claude (ej.: FastMCP en Python).
    • Seguridad y fiabilidad: docstrings claros, timeouts, manejo de errores y principio de menor privilegio son imprescindibles.
    • Observabilidad y versionado: registra llamadas, latencias y versiona schemas para evitar rupturas en producción.
    • Integración: estas tools pueden orquestarse en n8n u otros workflows como nodos reutilizables.

    Introducción

    Un “plugin” en Claude es, en realidad, Tool Use o Function Calling via Model Context Protocol (MCP). No le estás metiendo código al modelo: le das una API estructurada y el modelo decide cuándo llamarla. Tu servidor ejecuta la lógica real (Python/TS/Go) y el modelo actúa como cliente que conoce las herramientas disponibles mediante un schema.

    Resumen rápido (lectores con prisa)

    Qué es: Exponer funciones ejecutables (tools) que Claude puede invocar vía MCP.

    Cuándo usarlo: Cuando necesites que el asistente consulte sistemas externos, ejecute acciones o maneje datos sin inflar el prompt.

    Por qué importa: Permite acciones deterministas, auditables y seguras desde un asistente LLM.

    Cómo funciona: El modelo selecciona una tool, genera parámetros según el schema y llama al servidor MCP; el servidor responde con texto estructurado.

    ¿Qué es un “plugin” en Claude?

    Conceptualmente:

    • Claude = cliente que conoce las herramientas disponibles mediante un schema.
    • MCP = protocolo que negocia llamadas entre Claude y tu servicio (stdio, HTTP, WebSocket).
    • Tu servidor = el plugin: código real que ejecuta la lógica (Python/TS/Go).

    No le estás metiendo código al modelo. Le das una API estructurada y el modelo decide cuándo llamarla.

    ¿Qué necesitas y por qué importa?

    ¿Por qué hacerlo? Porque así conviertes un asistente en un agente capaz de:

    • consultar bases de datos internas,
    • ejecutar comprobaciones de infra,
    • automatizar workflows en n8n,

    sin inundar el prompt con contexto ni exponer credenciales en texto.

    Requisitos mínimos:

    Código mínimo: servidor MCP en Python

    Este ejemplo expone una tool que verifica el estado HTTP de una URL usando FastMCP. Copia, ajusta y ejecuta.

    from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("WebChecker")

@mcp.tool()
async def check_website_status(url: str) -> str:
    """
    Verifica el estado HTTP de una URL.
    Args:
      url: URL completa (ej: https://dominicode.com)
    Returns:
      Mensaje con código y razón, o error legible.
    """
    try:
        async with httpx.AsyncClient(timeout=5.0) as client:
            r = await client.get(url, follow_redirects=True)
            return f"Status: {r.status_code} - {r.reason_phrase}"
    except Exception as e:
        return f"Error: {str(e)}"

if __name__ == "__main__":
    mcp.run()

    FastMCP genera automáticamente el schema de la tool a partir de los type hints y docstrings. No escribes JSON a mano.

    Registrar el plugin en Claude Desktop / CLI

    Para que Claude vea tu servidor local, añade una entrada en la configuración de Claude Desktop:

    – macOS/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
    – Windows: %APPDATA%\Claude\claude_desktop_config.json

    Ejemplo:

    {
  "mcpServers": {
    "web-checker": {
      "command": "python",
      "args": ["/ruta/absoluta/a/server.py"]
    }
  }
}

    Reinicia Claude. Deberías ver el servidor activo (icono de enchufe).

    Flujo de ejecución (Thinking Loop)

    Cuando pides: “Claude, comprueba si dominicode.com responde”, sucede:

    1. Claude detecta necesidad de herramienta.
    2. Selecciona check_website_status.
    3. Genera parámetros (url).
    4. Llama al plugin vía MCP.
    5. El plugin responde con texto estructurado.
    6. Claude formatea la respuesta humana.

    Todo ordenado, trazable y auditable.

    Buenas prácticas imprescindibles

    Docstrings son contratos

    Escribe docstrings claros. El modelo usa esa información para construir la llamada. Ambigüedad = invocación errónea.

    Errores controlados

    Nunca dejes que tu plugin haga crash. Captura excepciones y devuelve mensajes legibles. Si tu proceso muere, Claude pierde acceso a todo ese servidor.

    Timeouts defensivos

    Usa timeouts explícitos (ej. httpx timeout=5s). No querrás procesos colgados.

    Principio de menor privilegio

    No implementes tools como exec_shell(cmd) a la ligera. Restringe rutas, usuarios y operaciones. Si necesitas ejecutar comandos, envuelve y valida cada input.

    Observabilidad

    Loguea prompts recibidos, respuestas, latencias y costes. Traza cada call LLM ↔ tool. Para infra, añade métricas que permitan alertas (ERRORES, RETRIES, LATENCIA).

    Gestión de versiones

    Versiona schemas y tools. Cambiar la firma de una función sin versionado rompe agentes y workflows en producción.

    Escalada humana

    Si el agente entra en loop o baja de confianza, define una regla clara: cortar, crear ticket y notificar a un responsable.

    Integración con workflows y n8n

    Estas tools son bloques reutilizables. Úsalas como nodos en n8n o como pasos en un orquestador de agentes. Por ejemplo:

    • Nodo n8n invoca tu API plugin para obtener estado.
    • Resultado condicional dispara un PR automático o un Slack alert.

    Recursos y lectura adicional

    Cierre operativo

    Crear un plugin para Claude Code es convertir una idea en una API que el modelo puede invocar de forma determinista. No es magia; es ingeniería de interfaces. Empieza con una tool pequeña, aplícala en un workflow y añade observabilidad. Si lo haces bien, tu Claude dejará de hablar y empezará a actuar.

    Esto no acaba aquí: construye la siguiente tool, versiona el schema y orquesta esas tools con un agente. Tu siguiente despliegue será la prueba.

    Dominicode Labs

    Si quieres prototipar y validar pipelines de agentes y automatizaciones, revisa Dominicode Labs. Es una continuación natural para integrar tools, pruebas y orquestación en entornos de trabajo técnico.

    FAQ

    ¿Qué diferencia hay entre un plugin y poner contexto en el prompt?

    Un plugin expone funciones ejecutables con schemas; el modelo invoca esas funciones. Poner contexto en el prompt implica enviar datos y lógica de forma textual, sin capacidad de ejecución externa ni trazabilidad.

    ¿Qué es MCP?

    MCP (Model Context Protocol) es el protocolo que negocia llamadas entre el modelo y tu servicio (stdio, HTTP, WebSocket), permitiendo que el modelo conozca y llame herramientas.

    ¿Por qué usar docstrings en lugar de JSON manual?

    Frameworks como FastMCP generan schemas automáticamente a partir de type hints y docstrings, reduciendo errores y manteniendo documentación y contratos sincronizados.

    ¿Cómo manejo errores para que Claude no pierda acceso?

    Captura excepciones, devuelve mensajes legibles y usa timeouts defensivos. No permitas que el proceso principal haga crash; implementa reinicios supervisados y health checks.

    ¿Qué precauciones de seguridad debo tomar?

    Aplica principio de menor privilegio, valida y sanitiza inputs, restringe rutas y comandos, y evita exponer credenciales en texto plano.

    ¿Puedo integrar estas tools en n8n?

    Sí. Usa las tools como nodos o llamadas API desde n8n; el resultado puede condicionar flujos, crear PRs o enviar alertas en Slack.

  • Cómo medir LLM Evals y Observabilidad en Producción

    Cómo medir LLM Evals y Observabilidad en Producción

    LLM Evals, Alignment y Observabilidad en Producción

    Tiempo estimado de lectura: 3 min

    • Ideas clave:
    • Las métricas operativas (Accuracy, Hallucination Rate, Latency, Cost per Task, Consistencia) son indispensables para pasar de prototipo a servicio escalable.
    • Construye un Golden Dataset, valida outputs estructurados y usa un modelo juez para tareas generativas.
    • Observabilidad en vivo (tracing, sampling, alertas) y guardrails de salida son necesarios para seguridad y estabilidad.

    Cómo medir si tu sistema AI realmente funciona en producción empieza por entender que “parece que responde bien” no es una métrica. LLM Evals, Alignment y Observabilidad en Producción son las piezas que convierten un prototipo bonito en infraestructura operable: Accuracy, Goal Completion, Toxicity, Hallucination Rate, Latency, Cost per Task y Consistencia. Si no mides esto, no escalas —solo maquillas el riesgo.

    Resumen rápido (lectores con prisa)

    LLM Evals: pruebas con un Golden Dataset y un modelo juez para medir factualidad y cumplimiento de objetivos. Observabilidad: tracing, sampling y alertas en vivo para detectar degradación y drift. Alineación y safety: guardrails en la salida y revisión humana cuando la confianza es baja.

    LLM Evals, Alignment y Observabilidad en Producción: qué medir y por qué

    La evaluación de modelos en producción debe ser multidimensional. Aquí están las métricas que importan y cómo interpretarlas:

    Métricas específicas

    Accuracy / Factuality

    ¿La respuesta es correcta? En sistemas RAG separa Context Recall (¿se recuperó lo relevante?) de Context Precision (¿la respuesta se basa en lo recuperado o lo inventa?).

    Hallucination Rate

    % de respuestas con información inventada. Target operativo: <3–5% según criticidad.

    Goal Completion

    Métrica binaria/medible ligada al negocio (email extraído, ticket resuelto). Es la métrica ROI.

    Toxicity / Safety

    Puntuaciones automáticas (ej. Perspective API) y guardrails para bloquear salidas peligrosas.

    Latency (TTFT y Total Latency)

    TTFT <2s para chat aceptable; objetivos más estrictos para aplicaciones UX sensibles.

    Cost per Task

    tokens * precio/modelo → $ por ejecución. Debe compararse con coste humano.

    Consistencia

    Desviación en resultados en ejecuciones repetidas; alta variabilidad indica prompts inestables o temperatura mal gestionada.

    Cómo construir Evals útiles (práctico)

    1. Golden Dataset

    Golden Dataset

    • Crea un conjunto curado de 100–500 ejemplos por workflow (80% casos comunes, 20% edge).
    • Human-label para ground truth inicial. Sin esto no hay baseline.

    Deterministic vs Model-Graded

    • Deterministic: para outputs estructurados valida formato/JSON con schema checks.
    • Model-graded: usa un LLM “juez” (más capaz) con una rúbrica para puntuar respuestas textuales. Ejemplo: pedir al juez “evalúa factualidad (1–5) y da evidencia”.

    Pipeline de CI

    • Ejecuta el Golden Dataset en cada PR que cambie prompts, chain logic o modelo.
    • Rechaza merges si Accuracy/Goal Completion bajan más de X%.

    Ejemplo simple (pseudocódigo de evaluación):

    # enviar respuesta + contexto + prompt de evaluación a un modelo juez
judge_prompt = "Evalúa si la respuesta es fiel al contexto. Score 1-5. Explica brevemente."
score = call_judge_model(input=context + answer, prompt=judge_prompt)

    Observabilidad en producción: trazas, sampling y alertas

    Las Evals funcionan offline; la Observabilidad te dice qué pasa en vivo.

    Tracing completo

    Registra input, documentos recuperados, prompts enviados, tokens, latencias por etapa. Usa LangSmith, LangFuse o Arize Phoenix para visualizar trace chains.

    Sampling inteligente

    Evalúa en línea entre 0.5–5% del tráfico para balancear coste y cobertura.

    Drift detection

    Monitoriza cambios en la distribución de inputs; alerta cuando un feature importante sale del rango esperado.

    Alertas por SLA

    Accuracy drop, Hallucination spike, o coste por task anómalo disparan rollback o canary throttling.

    Integra traces con OpenTelemetry para correlación con logs y métricas infra.

    Alineación operativa y safety

    • Implementa guardrails en la capa de salida (post‑processing) que validen seguridad y formato antes de exponer la respuesta (ej. NVIDIA NeMo Guardrails).
    • Para respuestas sensibles, requiere verificación secundaria: LLM-as-a-Judge + schema check + citation check (si es RAG).
    • Mantén un “human-in-the-loop” para casos de baja confianza: si la confianza < umbral, encolar para revisión humana.

    Métricas objetivo y SLOs realistas

    Define SLOs por workflow, p. ej.:

    • Accuracy > 95% en Golden Dataset.
    • Hallucination Rate < 3%.
    • TTFT < 2s.
    • Cost per Task < $0.05 (ajusta según caso de negocio).

    Monitoriza y versiona SLOs junto al código/infra.

    Errores comunes que debes evitar

    • No tener Golden Dataset.
    • Medir solo calidad, ignorar coste.
    • No versionar prompts ni modelos.
    • Silenciar drift: sin alertas el modelo se degrada sin aviso.

    Cierre operativo

    LLM Evals, Alignment y Observabilidad en Producción no son funciones accesorias: son el núcleo del ciclo de vida de una IA productiva. Empieza por construir tu Golden Dataset, versiona prompts como código, añade un juez para tareas generativas y despliega tracing por etapas. Con esas piezas, transformarás la IA de experimento a servicio confiable, escalable y justificable en costes.

    Lecturas y herramientas prácticas

    Para equipos que implementan pipelines de Evals y observabilidad como parte de workflows de producto, una continuación lógica es revisar recursos y experimentos prácticos disponibles en Dominicode Labs. Ahí puedes encontrar ejemplos aplicados y plantillas para integrar tracing y CI de evaluación en flujos de trabajo.

    FAQ

    ¿Qué es un Golden Dataset y por qué lo necesito?

    Un Golden Dataset es un conjunto curado y etiquetado de ejemplos (100–500 por workflow) que sirve como baseline para evaluar Accuracy y Goal Completion. Sin él no tienes una referencia objetiva para medir degradación o mejoras.

    ¿Cómo medir hallucinations en producción?

    Combina sampling en línea con evaluaciones humanas y modelos juez que comparen respuestas contra contexto o fuentes. Mide el porcentaje de respuestas con información inventada y fija umbrales operativos (<3–5%).

    ¿Qué es un modelo juez (model-graded)?

    Es un LLM más capaz que puntúa respuestas humanas/modelo según una rúbrica (p. ej. factualidad 1–5) y devuelve evidencia o explicación para el score.

    ¿Cuánto tráfico debo muestrear para Evals en línea?

    Generalmente entre 0.5–5% del tráfico, para equilibrar coste y cobertura. Ajusta según criticidad y coste por task.

    ¿Qué abandonar ante un spike de hallucinations?

    Accionar alertas: revertir cambios recientes (rollback), activar canary throttling, aumentar muestreo y encolar casos para revisión humana hasta estabilizar la tasa.

    ¿Cómo integrar tracing con OpenTelemetry?

    Instrumenta puntos clave (entrada, recuperación de documentos, llamada al modelo, post‑processing), exporta traces a tu backend y correlaciona con logs y métricas infra para análisis de causa raíz.

    ¿Cuáles son SLOs realistas para chatbots?

    Ejemplos: Accuracy >95% en Golden Dataset, Hallucination Rate <3%, TTFT <2s. Ajusta según el workflow y coste/humano de fallback.

  • Mejorando la Recuperación de Información con RAG Avanzado

    Mejorando la Recuperación de Información con RAG Avanzado

    RAG Avanzado: Híbrido, Jerárquico y Multi-Vector

    RAG Avanzado: Híbrido, Jerárquico y Multi-Vector. Si eso suena a demasiada ingeniería comparado con “chunk + embeddings”, es porque lo es —y la diferencia entre demo y producto está justo ahí. En producción no vale con que el LLM “suene bien”; necesitas precisión, contexto y control de coste. Este artículo explica qué técnicas añadir, por qué y cuándo.

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • La recuperación es el 80% de una buena respuesta: combina sparse (BM25) y dense (embeddings).
    • Arquitectura jerárquica (child + parent) equilibra precisión de fragmento y contexto coherente.
    • Re-ranking con cross-encoders y compresión de contexto reducen hallucinations y coste token.

    Introducción

    La calidad de las respuestas generadas por un sistema RAG depende mayoritariamente de la recuperación. Los vectores aportan semántica; los métodos sparse (BM25) aportan exactitud. En producción necesitas precisión, contexto y control de coste; esto implica añadir capas: híbrido, jerarquía, re-ranking, rewriting y compresión de contexto.

    Resumen rápido (lectores con prisa)

    RAG avanzado combina búsquedas sparse (BM25) y dense (embeddings) para precisión y semántica. Usa indexing jerárquico child→parent para fragmentos precisos con contexto. Re-rank con cross-encoders para reducir ruido. Reescribe y descompone queries; comprime contexto antes del LLM.

    RAG Avanzado: implementación práctica

    1) Hybrid retrieval: BM25 + embeddings

    Problema: buscas “ERR-9921” y el vector devuelve “error de sistema” porque semánticamente es parecido. Solución: híbrido.

    • Sparse: BM25/Elasticsearch para coincidencias literales.
    • Dense: embeddings (OpenAI, Cohere, etc.) para intención.
    • Fusión: Reciprocal Rank Fusion (RRF) o combinación ponderada. Pinecone hybrid search

    Patrón práctico:

    • Ejecuta BM25 y vector search en paralelo.
    • Normaliza scores.
    • Fusiona con RRF.
    • Si BM25 tiene match exacto para tokens sensibles (IDs, SKUs), priorízalo.

    2) Multi-vector / Parent-Child indexación

    Dilema clásico: chunks pequeños = mejor match; chunks grandes = mejor contexto. La arquitectura jerárquica arregla ambos.

    • Indexa embeddings a nivel child (p. ej. 200 tokens).
    • Mantén parent docs grandes (p. ej. 2000 tokens) con metadata.
    • Al recuperar un child relevante, sube el parent completo al contexto.

    Implementación: LangChain ParentDocumentRetriever — LangChain ParentDocumentRetriever

    Beneficio: precisión de fragmento + contexto coherente para razonamiento.

    3) Re-ranking con cross-encoders

    Bi-encoders: rápidos, aproximados. Cross-encoders: lentos, precisos.

    Flujo:

    1. Fast retrieval → top N (50).
    2. Cross-encoder rerank en top N.
    3. Selecciona top K final para el LLM.

    Herramientas: sentence-transformers, Cohere Rerank. Costo: aumenta latencia; recompensa: reduce ruido que provoca hallucinations.

    4) Query rewriting y decomposition

    Muchos fallos vienen por queries ambiguas. No todos los problemas se arreglan en el índice.

    • Query rewrite: un LLM rápido reescribe la consulta con contexto de la sesión.
    • Multi-query: genera 3–5 variantes de la pregunta y busca por cada una.
    • Decomposition: divide preguntas complejas en sub-queries paralelas.

    Técnica HyDE (Hypothetical Document Embeddings) es útil: genera la “respuesta hipotética”, embeddea eso y busca. Idea en práctica: mejora recall sin cambiar el índice.

    5) Context compression antes del LLM

    Enviar 10 documentos de 8k tokens es suicida. Comprime:

    • Filtrado selectivo: extrae párrafos con más evidencia.
    • Summarization condensado (con cuidado: pierde citas).
    • Algoritmos de compresión semántica como LLMLingua

    Objetivo: maximizar densidad informativa dentro de la ventana del LLM.

    Criterio para decidir qué añadir (roadmap pragmático)

    No implementes todo a la vez. Sigue este orden iterativo:

    1. Naive RAG. Mide recall@5 y tasa de hallucination.
    2. Si fallan exact matches → añade Hybrid (BM25).
    3. Si falta contexto coherente → añade Parent-Child multi-vector.
    4. Si llega ruido que confunde al LLM → añade Re-ranking.
    5. Si tokens exceden la ventana → añade Context Compression.

    Mide antes y después. No hay excusas.

    Operacional: latencia, coste y caching

    • Re-ranking y cross-encoders aumentan latencia 10x en la etapa de ranking. Mitiga con caching de top-N por query fingerprint.
    • Hybrid search añade coste infra (Elasticsearch + vector DB). Mide Cost/Accuracy.
    • Batch embeddings nocturnos para contenido estático. Mantén refresh policies.
    • Telemetría: trace request → retrieval steps → rerank → LLM call. LangFuse y LangSmith ayudan a visualizar traces (LangFuse, LangSmith).

    Integración con agentes y workflows (n8n)

    Pipeline ejemplo en n8n:

    1. Node: Query Rewrite (LLM pequeño)
    2. Node: Hybrid Search (ES + Pinecone/Qdrant)
    3. Node: Rerank (Cross-Encoder)
    4. Node: Parent Expander + Context Compressor
    5. Node: LLM final (generation)
    6. Node: Post-check (schema validation / guardrails)

    Versiona prompts, registra fingerprints y alertas en drift.

    Referencias operativas

    Implementar RAG avanzado es menos glamour y más disciplina: medir, añadir la capa correcta y repetir. Hazlo así y tu sistema dejará de improvisar respuestas y empezará a dar respuestas que puedes explicarle al CTO.

    Dominicode Labs

    Si trabajas con pipelines de agentes, workflows o IA aplicada, considera explorar integraciones y experimentos prácticos en Dominicode Labs. Es una continuación lógica para prototipos operacionales y pruebas de telemetría.

    FAQ

     

    Respuesta: ¿Por qué combinar BM25 con embeddings?

    BM25 proporciona coincidencias literales útiles para IDs, SKUs y frases exactas; los embeddings capturan intención y sinónimos. El híbrido reduce falsos positivos semánticos y mejora precisión en búsquedas sensibles.

     

    Respuesta: ¿Qué ventaja tiene la indexación parent-child?

    Permite mantener chunks pequeños para alta precisión en matching mientras se conserva contexto amplio subiendo el documento parent al LLM cuando un child es relevante.

     

    Respuesta: ¿Cuándo usar cross-encoders para re-ranking?

    Úsalos cuando el top-N recuperado contenga ruido que provoca hallucinations o respuestas incorrectas. Son adecuados para reducir falsos positivos aunque aumenten latencia y coste.

     

    Respuesta: ¿Qué es HyDE y por qué usarlo?

    HyDE (Hypothetical Document Embeddings) genera una “respuesta hipotética” desde un LLM, la embeddea y busca con esa representación. Mejora recall sin tocar el índice.

     

    Respuesta: ¿Cómo mitigar la latencia al re-rankear?

    Cachea top-N por huella de consulta, ejecuta re-ranking asíncrono donde sea posible y usa cross-encoders solo en escenarios críticos o por lotes nocturnos para contenido estático.

     

    Respuesta: ¿Qué técnicas de compresión de contexto son seguras?

    Filtrado selectivo de párrafos con evidencia, resúmenes condensados con control de citas y algoritmos semánticos como LLMLingua. Ten cuidado: la compresión puede perder citas y detalles verificables.

  • El futuro de los programadores en un mundo de IA

    El futuro de los programadores en un mundo de IA

    Dejarán de existir los programadores debido a la AI, cuál será el futuro ?

    Tiempo estimado de lectura: 4 min

    • La profesión no desaparece: se transforma hacia orquestación, seguridad y responsabilidad técnica.
    • Habilidades críticas: testeo semántico, control de agentes, observabilidad de LLMs, FinOps y seguridad.
    • Roles emergentes: orquestadores de agentes, AI FinOps, observability y security engineers especializados en IA.

    Dejarán de existir los programadores debido a la AI, cuál será el futuro? No: la profesión no desaparece, se transforma. Lo que muere es la recompensa por saber cerrar un paréntesis. Lo que surge es la demanda por gente que tenga criterio para diseñar, orquestar y responsabilizar una capa de IA dentro de sistemas reales.

    Los LLMs generan código. Bien. Eso no es la mitad del problema; es solo la parte fácil. El verdadero trabajo será asegurar que ese código no rompa la seguridad, no arruine las finanzas del proyecto y funcione 1.000 veces en producción sin alucinar.

    Resumen rápido (lectores con prisa)

    Qué es: La automatización con LLMs transforma el rol de programador hacia orquestación, seguridad y fiabilidad.

    Cuándo usarlo: Al integrar LLMs en sistemas productivos que requieren disponibilidad, coste controlado y seguridad.

    Por qué importa: Implementar IA sin pruebas semánticas, observabilidad y control de costes puede generar fallos graves y gastos inesperados.

    Cómo funciona (resumen): Orquesta agentes, traza prompts/embeddings/tool-calls, aplica tests semánticos y controles financieros por flujo.

    Dejarán de existir los programadores debido a la AI, diagnóstico técnico

    No estamos ante la extinción del oficio, sino ante su re-especialización. La automatización desplaza tareas repetitivas; obliga a los ingenieros a evolucionar hacia roles donde el juicio técnico y la orquestación valen más que teclear rápido.

    Los puntos clave

    • La IA reduce el coste de producción de implementación, no el coste de responsabilidad técnica.
    • El valor pasa de la implementación a la arquitectura, la seguridad y la fiabilidad.
    • Aparecen roles nuevos: orquestadores de agentes, ingenieros FinOps de IA, responsables de observabilidad de LLMs.

    Estos cambios ya son prácticos: n8n y LangChain no son hobbies; son infra para orquestar lógica humana + IA. Pinecone es la memoria cuando el modelo no puede cargar todo el contexto. OpenTelemetry y Arize son los instrumentos para medir lo que antes sólo se infería.

    El nuevo skill set crítico (cinco prioridades)

    Si quieres seguir siendo indispensable, domina estas cinco áreas. No son “buenas ideas”; son requisitos de producción.

    1) Testeo automático inteligente (Evals)

    Los tests string-to-string fallan con LLMs. Necesitas evaluadores semánticos: datasets de respuestas esperadas, pruebas basadas en esquemas (JSON Schema) y LLMs que actúen como juez. Herramientas y patrones: golden datasets, pruebas adversariales y evaluación automática de coherencia y factualidad.

    2) Evaluación de agentes y control de flujo

    Un agente que funciona una vez es un experimento. Uno que opera a escala requiere máquinas de estado, grafos de flujo y guardrails. Usa FSMs, límites de iteración y validaciones por step para evitar loops, fugas de datos o ejecuciones no deseadas.

    3) Observabilidad de LLMs

    La traza del stack ya no es suficiente. Tienes que recolectar: prompt original, embeddings usados (RAG), tool calls, respuesta del modelo, tokens consumidos y latencia por paso. Implementa tracing end-to-end con OpenTelemetry y tableros que correlacionen degradación de calidad con cambios en prompts o datos.

    4) Cost control (FinOps para IA)

    Un bug puede costar miles en una noche. Controla tokens, cachea respuestas recurrentes (Redis), enruta cargas a modelos baratos para operaciones simples y reserva modelos caros solo para razonamientos complejos. Mide coste por petición y ROI por cada flujo automatizado.

    5) Seguridad y prompt injection

    La seguridad ya no es sólo SQLi o XSS. Es impedir que una instrucción de usuario manipule el prompt o que un agente ejecute acciones peligrosas. Aplica mínimo privilegio en cada tool que expongas, valida outputs con esquemas y aisla tokens/credenciales. Considera frameworks de guardrails como NVIDIA NeMo Guardrails y políticas de ejecución restringidas.

    Roles que emergen: quiénes ganan

    • Orquestador de agentes: diseña flujos, define límites y asegura estabilidad.
    • AI FinOps Engineer: controla coste, optimiza rutas de modelos y define SLAs económicos.
    • Observability Engineer para IA: instrumenta trazas y define alertas sobre calidad, no solo sobre latencia.
    • Security Engineer de IA: modela amenazas específicas de LLM y aplica mitigaciones.

    La diferencia entre un “operador” y un “orquestador” será la diferencia entre un puesto reemplazable y uno que aguante la próxima década.

    Qué hacer desde ya (práctico)

    1. Empieza por auditar: ¿qué procesos usan IA y cuánto cuestan en tokens al mes?
    2. Implementa tracing básico: persistir prompts, respuestas y metadatos por petición.
    3. Define 10 pruebas de “smoke” semánticas para tus agentes: respuestas que siempre deben cumplirse.
    4. Añade límites de ejecución y una ruta de escalado humano si el agente falla.
    5. Establece un plan de costes: modelos baratos para lo trivial, modelos caros para lo crítico.

    Cierre — no se acaba aquí

    La IA no borrará a los programadores; los forzará a subir de nivel. Si te niegas a aprender testeo semántico, observabilidad y FinOps para IA, estarás desapareciendo a cámara lenta. Si lo aprendes, pasarás de escribir funciones a diseñar sistemas confiables que realmente automaten trabajo de valor.

    Empieza hoy: instrumenta un flujo con tracing, añade una prueba semántica y pon límites de coste. Lo siguiente será orquestarlo a escala.

    Si trabajas en automatización, agentes o workflows y buscas recursos prácticos para prototipar trazas y pruebas semánticas, consulta Dominicode Labs. Es una continuidad lógica para equipos que quieren pasar de experimentos a pipelines reproducibles y observables.

    FAQ

    Respuesta: No. La profesión se transforma: disminuye el valor de tareas repetitivas y aumenta la demanda de roles que gestionen, orquesten y aseguren sistemas con IA.

    Respuesta: Testeo semántico, control de agentes/flow, observabilidad de LLMs, FinOps para IA y seguridad frente a prompt injection.

    Respuesta: Empieza creando golden datasets de respuestas esperadas, define pruebas basadas en esquemas (JSON Schema) y automatiza evaluaciones usando LLMs como juez y pruebas adversariales.

    Respuesta: Es trazar prompts, embeddings, tool calls, respuestas, tokens y latencias end-to-end para correlacionar degradación de calidad con cambios en datos o prompts.

    Respuesta: Mide coste por petición, cachea respuestas recurrentes, enruta cargas simples a modelos baratos y reserva modelos caros para razonamiento complejo; aplica límites y alertas.

    Respuesta: Aplica mínimo privilegio a tools, valida outputs con esquemas, aísla tokens/credenciales y usa frameworks de guardrails para mitigar prompt injection.

  • Prácticas para crear skills efectivas en agentes

    Prácticas para crear skills efectivas en agentes

    Best Practices for Creating Agent Skills

    Tiempo estimado de lectura: 5 min

    • Diseña SKILL.md como orquestador compacto: no como una enciclopedia; enumera pasos y triggers claros.
    • Externaliza lo frágil: scripts deterministas en scripts/, reglas densas en references/, templates en assets/.
    • Progressive Disclosure (JiT): carga solo archivos cuando surge un trigger explícito.
    • Validación en tres fases con LLMs: discovery, lógica y edge-case testing.

    Introducción

    ¿Quieres que tus agentes dejen de fallar por cosas tontas? La mayoría lo hace porque sus skills son documentación para humanos disfrazada de herramienta para máquinas. Los agentes no leen; ejecutan. Y para ejecutar necesitan reglas claras, rutas exactas y scripts que no improvisen.

    Aquí va la arquitectura práctica que uso cuando diseñamos skills que realmente funcionan en producción.

    Resumen rápido (lectores con prisa)

    Qué es: Un conjunto de reglas, scripts y plantillas organizadas para que un agente tome decisiones deterministas.

    Cuándo usarlo: Al diseñar skills que interactúan con repositorios, migraciones, o tareas automatizadas que requieren reproducibilidad.

    Por qué importa: Evita ambigüedades que causan alucinaciones y resultados inconsistentes.

    Cómo funciona: SKILL.md orquesta; scripts ejecutan validaciones; references/ y assets/ se cargan sólo mediante triggers explícitos.

    Estructura de una skill: la regla de hierro

    skill-name/
├── SKILL.md              # Metadatos + instrucciones core (<500 líneas)
├── scripts/              # CLIs pequeños para tareas deterministas
├── references/           # Reglas densas, cheatsheets, esquemas
└── assets/               # Templates y archivos estáticos

    SKILL.md es “el cerebro”: orquesta, no enciclopedia. scripts/ ejecuta lo que no puede fallar. references/ y assets/ guardan lo pesado, pero el agente sólo los lee cuando se lo indicas.

    Naming y frontmatter: haz que la skill sea visible

    El agente decide cargar una skill solo por el frontmatter. Si tu nombre y descripción son vagos, la skill es invisible.

    Reglas:

    • name = 1–64 chars, minúsculas, números y guiones. Debe coincidir exactamente con el nombre del directorio.
    • descripción = máximo 1,024 caracteres, en tercera persona e incluye negative triggers.

    Ejemplo práctico:

    name: angular-vite-migrator
description: Migra proyectos Angular CLI de Webpack a Vite y esbuild. Usar para actualizar builders o reemplazar plugins de Webpack por equivalentes de Rollup. No usar para proyectos React, Svelte o para sólo actualizar la versión de Angular.

    Eso reduce falsos positivos. Punto.

    Progressive Disclosure: carga solo lo necesario

    Los LLMs tienen memoria limitada. Meter 800 líneas de vite.config.ts en el prompt es pedir perdón por las alucinaciones.

    Patrón: JiT (Just-in-Time).

    • SKILL.md enumera pasos altos y dice exactamente cuándo abrir un archivo.
    • Coloca plantillas complejas en assets/ y reglas en references/.
    • Instrucción clara: “Si detectas @angular-builders/custom-webpack en angular.json, abre references/webpack-fallbacks.md”.

    El agente no ve nada hasta que el trigger ocurre. Menos tokens, más precisión.

    Escribe para máquinas: imperativo y pasos numerados

    Las skills son código en lenguaje natural. Escribe en tercera persona, imperativo y con pasos numerados.

    Correcto:

    1. Ejecuta scripts/env-validator.mjs
2. Si el exit code es 1, reporta: "Node version incompatible. Upgrade required." Termina.

    Incorrecto: “Quizá quieras comprobar la versión de Node…” — frase que confunde y genera ambigüedad.

    Scripts deterministas: no pidas improvisación

    No le pidas al LLM que escriba parsers complejos en cada ejecución. Empaqueta esos parsers y detectores como scripts pequeños y probados en scripts/. El agente los invoca con parámetros y actúa según stdout/stderr.

    Ejemplo de stdout útil:

    CRITICAL: Found legacy CommonJS 'legacy-lib' that uses dynamic require(). Recommendation: add to optimizeDeps.include or shim with esm-adapter. See references/commonjs-guide.md

    Ese mensaje debe permitir al agente decidir el siguiente paso sin adivinar.

    Templates y outputs parseables

    Coloca un template en assets/ (por ejemplo, assets/vite.config.template.ts). Instrucción en SKILL.md:

    • “Copia assets/vite.config.template.ts a vite.config.ts y rellena los placeholders según el mapeo en references/mapping.md.”

    Los LLMs reconocen patrones; darles la plantilla evita salidas rotas y archivos inválidos.

    Validación con LLMs: prueba en tres fases

    Las skills las usarán LLMs, así que valídalas con LLMs.

    1. Discovery Validation

    Pega solo el frontmatter en un LLM limpio. Pide 3 prompts que deben activar la skill y 3 que no. Ajusta la descripción hasta que el modelo acierte.

    2. Logic Validation

    Pasa el SKILL.md y la estructura de archivos. Pide al LLM que actúe como agente y escriba su monólogo paso a paso: qué lee, qué ejecuta, y dónde se ve obligado a adivinar.

    3. Edge Case Testing (Red Team)

    Pide al LLM que te rompa la skill con preguntas concretas: Node antiguo, builders custom, imports dinámicos. Si responde con huecos, rellena referencias y scripts hasta que no queden ambigüedades.

    Ejemplos de fallas comunes y cómo prepararlas

    • CommonJS legacy en esbuild: añade scripts/detect-commonjs.mjs que devuelvan JSON con las dependencias problemáticas y recomendaciones.
    • @angular-builders/custom-webpack en angular.json: stop automatic migration. Instruye a abrir references/webpack-fallbacks.md y proponer un plan híbrido (mantener Webpack para producción, migrar dev a Vite).
    • Entorno Node no compatible: scripts/env-validator.mjs debe chequear process.version y salir con mensaje accionable.

    Cierre con criterio

    Construir skills no es arte ni redacción creativa: es ingeniería. Nombra con precisión, externaliza lo frágil a scripts, usa templates y obliga a los agentes a cargar sólo lo que necesitan. Haz esto y tus agentes dejarán de inventar soluciones —y empezarán a producir resultados reproducibles.

    Reestructura una skill bajo estas reglas hoy y verás cómo el agente deja de improvisar. Esto no acaba aquí; las skills bien diseñadas son la base de la automatización fiable.

    Dominicode Labs

    Para equipos que diseñan workflows y agentes, recursos y experimentos prácticos en automatización y agentes están disponibles en Dominicode Labs. Considera revisarlo como complemento para validar skills y pipelines en entornos reales.

    FAQ

     

    ¿Qué debe contener SKILL.md?

    SKILL.md debe ser el orquestador: metadatos (frontmatter), pasos numerados claros, triggers explícitos sobre cuándo abrir archivos en references/ o assets/, y referencias a scripts/ ejecutables. Mantenerlo por debajo de 500 líneas.

     

    ¿Por qué externalizar parsers en scripts/?

    Porque los parsers y detectores complejos son frágiles si se piden al LLM en cada ejecución. Scripts deterministas devuelven stdout/stderr o JSON que permite decisiones automáticas sin ambigüedad.

     

    ¿Cómo funciona Progressive Disclosure?

    El agente solo carga información adicional cuando un trigger en SKILL.md lo indica (JiT). Así se evita saturar el prompt con archivos largos y se mejora la precisión.

     

    ¿Qué formato deben tener los outputs de los scripts?

    Outputs legibles por máquina: líneas con prefijos (ej. CRITICAL:) o JSON. Deben contener suficiente contexto y una recomendación accionable para que el agente decida el siguiente paso.

     

    ¿Cuándo incluir references/webpack-fallbacks.md?

    Incluirlo cuando detectes @angular-builders/custom-webpack en angular.json. La instrucción en SKILL.md debe ordenar abrir ese archivo y proponer un plan híbrido si aplica.

     

    ¿Cómo validar una skill con LLMs?

    Validación en tres fases: Discovery Validation con solo frontmatter, Logic Validation con SKILL.md y estructura de archivos (monólogo del agente), y Edge Case Testing (Red Team) para cerrar huecos.

  • Integrando Pinecone para memoria de largo plazo en sistemas RAG

    Integrando Pinecone para memoria de largo plazo en sistemas RAG

    Introducción a Pinecone: la memoria de largo plazo para agentes y RAG

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • Pinecone es una base de datos vectorial fully managed para búsquedas por similitud semántica.
    • Prototipa con Serverless; migra a Pods solo por métricas de p99 o throughput.
    • Namespaces y metadatos permiten multitenancy y filtrado híbrido en RAG.
    • Integra fácilmente con LangChain, n8n y pipelines de embeddings para reducir coste y alucinaciones.

    Introducción

    Introduccion a Pinecone es el punto de partida para cualquier equipo que quiera que sus agentes y sistemas RAG dejen de depender de la ventana de contexto. Pinecone es una base de datos vectorial gestionada que convierte embeddings en una memoria externa rápida, escalable y filtrable. Aquí tienes lo esencial técnico, criterios de diseño y ejemplos prácticos para tomar decisiones de arquitectura.

    Resumen rápido (lectores con prisa)

    Pinecone es una base de datos vectorial fully managed para búsquedas por similitud semántica. Prototipa con Serverless y usa namespaces y metadatos para multitenancy y filtrado híbrido. En runtime, conviertes la consulta en embedding, recuperas documentos relevantes y pasas ese contexto al LLM.

    Introduccion a Pinecone: qué es y qué problema resuelve

    Pinecone es una base de datos vectorial fully managed. En lugar de buscar coincidencias textuales (SQL), Pinecone busca por similitud semántica: guarda vectores (embeddings) y responde con los ítems más cercanos en el espacio de alta dimensión.

    ¿Por qué importa?

    • Los LLMs no retienen contexto histórico. Inyectar todo en cada prompt es caro y lento.
    • Con Pinecone haces retrieval: conviertes la consulta en embedding, recuperas documentos relevantes y das ese contexto al LLM.
    • Resultado: menos alucinaciones, menor coste y respuestas más relevantes.

    Fuentes: documentación oficial de Pinecone y ejemplos de integración con LangChain y n8n.

    Arquitectura y opciones: Serverless vs Pods

    Elegir entre Serverless y Pod-based cambia coste, operación y latencia.

    • Serverless: recomendado para la mayoría. Separación de cómputo y almacenamiento, autoescalado, facturación por uso. Ideal para SaaS multi-tenant y proyectos que empiezan.
    • Pods: hardware reservado, coste fijo. Útil si necesitas p99 ultrabajo y throughput constante en producción.

    Criterio práctico: empieza Serverless. Mueve a Pods solo si tienes métricas que demuestren que el p99 o el throughput justifican el coste fijo.

    Documentación: https://docs.pinecone.io/docs/overview

    Componentes esenciales y decisiones técnicas

    A continuación los elementos centrales para diseñar tu arquitectura de RAG con Pinecone.

    1. Índices (Indexes)

    Define la dimensión del vector (ej. 1536 para embeddings OpenAI) y la métrica (cosine, euclidean, dot). Elige la métrica según tu pipeline de embeddings (cosine es la más común para texto).

    2. Namespaces

    Soportan multitenancy dentro de un índice. Úsalos para aislar clientes sin crear múltiples índices. Ejemplo: namespace="cliente_123" por tenant en SaaS.

    3. Metadatos y filtrado híbrido

    Adjunta JSON a cada vector (fecha, documento_id, tipo). Permite combinar búsqueda semántica con filtros estructurados (“solo artículos 2024”). Esto reduce falsos positivos y mejora precisión en RAG.

    Integración práctica (ejemplo mínimo)

    Flujo típico

    • Fragmentas documentos (chunks) y generas embeddings (OpenAI, Cohere, etc.).
    • Upsert de vectores en Pinecone con metadatos.
    • En runtime, generas embedding de la consulta, haces query top-k y pasas los resultados al LLM.

    Ejemplo Python (SDK ligero)

    import pinecone
from openai import OpenAI  # o cualquier generador de embeddings

pinecone.init(api_key="PINECONE_API_KEY", environment="us-west1-gcp")
index = pinecone.Index("mi-indice-rag")

query_embedding = [0.1, 0.2, ...]  # generado por tu modelo de embeddings
res = index.query(vector=query_embedding, top_k=5, include_metadata=True)

    Guía rápida: https://docs.pinecone.io/docs/quickstart

    Integración en automatizaciones y agentes

    • n8n: nodo Pinecone para upsert y query. Útil para pipelines sin código (webhook → extracción → embeddings → upsert).
    • LangChain: Pinecone como VectorStore. Compatible con prompt templates y chains de RAG.
    • Agentes: Pinecone actúa como memoria episódica (recupera acciones anteriores, decisiones o documentos relevantes).

    Ejemplo de uso en Dominicode: indexar manuales, repositorios y workflows; un agente recupera pasos previos y propone el siguiente paso con contexto.

    Comparativa técnica: cuándo elegir Pinecone

    • Elige Pinecone si:
      • Necesitas escalar sin operar infraestructura vectorial.
      • Requieres búsquedas de similitud con filtrado híbrido y baja latencia.
      • Quieres integración rápida con n8n, LangChain y frameworks LLM.
    • Considera pgvector si:
      • Ya usas Postgres y el dataset es pequeño/mediano.
      • Prioritizas mantener todo en la misma base de datos.
    • Considera Chroma/Weaviate self-hosted si:
      • Tienes requisitos on‑premise o regulaciones estrictas de datos.

    Comparativa y más detalles: https://docs.pinecone.io/docs/compare

    Limitaciones y guardrails

    • Coste por lectura: monitoriza el patrón de consultas (hot vs cold) para evitar sorpresas.
    • Vendor lock-in: Pinecone ofrece conveniencia; documenta tu export/import strategy.
    • Cold start y caching: la primera consulta puede ser más lenta; implementa caché si necesitas micro-latencias.

    Conclusión

    Pinecone es la pieza de infraestructura que transforma LLMs amnésicos en agentes con memoria. Para Tech Leads, la recomendación práctica es: prototipa con Serverless, estructura tus metadatos y namespaces desde el primer día, y añade observabilidad por lecturas/latencias. Integrado con n8n o LangChain, Pinecone convierte RAG y workflows en algo reproducible y mantenible — no en hacks de prompt.

    Recursos

    Para equipos que trabajan en automatización, agentes y workflows, una exploración adicional y prototipado suele ser la siguiente iteración natural. Más experimentación práctica y observabilidad ayudan a decidir entre Serverless y Pods. Continúa la exploración en Dominicode Labs, donde se documentan proyectos y pruebas de concepto aplicadas a RAG y pipelines de agentes.

    FAQ

    ¿Qué es Pinecone y para qué sirve?

    Pinecone es una base de datos vectorial fully managed diseñada para búsquedas por similitud semántica. Guarda embeddings como vectores y responde con los ítems más cercanos en espacio de alta dimensión, facilitando retrieval para LLMs y sistemas RAG.

    ¿Cuándo debería usar Serverless en lugar de Pods?

    Usa Serverless para la mayoría de proyectos: es más barato al inicio, escala automáticamente y separa cómputo de almacenamiento. Migra a Pods solo si las métricas (p99 o throughput constante) justifican el coste fijo de hardware reservado.

    ¿Cómo funcionan los namespaces?

    Los namespaces permiten multitenancy dentro de un mismo índice. Sirven para aislar datos por cliente o contexto sin crear múltiples índices, por ejemplo namespace="cliente_123".

    ¿Qué son los metadatos y cómo ayudan al filtrado híbrido?

    Los metadatos son JSON asociados a cada vector (fecha, documento_id, tipo). Permiten aplicar filtros estructurados junto a la búsqueda semántica (por ejemplo, “solo artículos 2024”), reduciendo falsos positivos.

    ¿Cómo se integra Pinecone con LangChain y n8n?

    LangChain usa Pinecone como VectorStore para chains de RAG y templates de prompt. n8n ofrece nodos para upsert y query, permitiendo pipelines sin código (webhook → extracción → embeddings → upsert).

    ¿Cuáles son las principales limitaciones a considerar?

    Considera coste por lectura, riesgo de vendor lock-in y latencias por cold start. Implementa monitorización de lecturas/latencias y una estrategia de export/import si necesitas portabilidad.

    ¿Dónde encontrar la documentación oficial y guías rápidas?

    Documentación y guías rápidas están en documentación oficial de Pinecone y en la guía rápida disponible en su sitio.

  • Implementa Amazon Ads MCP Server para optimizar integraciones publicitarias

    Implementa Amazon Ads MCP Server para optimizar integraciones publicitarias

    Pero, ¿qué es Amazon Ads MCP Server?

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Amazon Ads MCP Server actúa como middleware MCP para exponer la API de Amazon Advertising como herramientas consumibles por agentes IA.
    • Reduce integraciones punto a punto: traduce prompts/llamadas MCP a REST de Amazon con OAuth.
    • Ofrece lectura de estructura, reportes KPI, operaciones CRUD y gestión de pujas (según permisos).
    • Riesgos: latencia, rate limiting, seguridad y alucinaciones operativas del LLM.
    • Flujo recomendado: levantar en testing, comenzar con solo lectura y añadir guardrails para escrituras.
    Pero, ¿qué es Amazon Ads MCP Server? Es la pregunta que están haciendo hoy los equipos que quieren dejar de pelearse con APIs, scripts rotos y automatizaciones que fallan en producción. Aquí tienes una respuesta técnica, práctica y sin ruido.

    Amazon Ads MCP Server es una implementación de middleware que sigue el estándar Model Context Protocol (MCP). Su propósito: exponer la funcionalidad de la API de Amazon Advertising como “herramientas” que un agente de IA (un LLM) puede descubrir e invocar de forma segura y estructurada. En lugar de tener múltiples integraciones punto a punto, tienes una capa de traducción que convierte prompts en llamadas API consistentes.

    Resumen rápido (lectores con prisa)

    Qué es: Un middleware MCP que expone la API de Amazon Advertising como herramientas JSON-RPC para agentes IA.

    Cuándo usarlo: Cuando quieres que un LLM ejecute consultas y acciones sobre advertising-api.amazon.com sin integrar cada endpoint manualmente.

    Por qué importa: Reduce deuda técnica, centraliza permisos y disminuye alucinaciones operativas del LLM.

    Cómo funciona: Cliente MCP → JSON-RPC → MCP Server → REST Amazon (con OAuth) → respuesta JSON al LLM.

    Pero, ¿qué es Amazon Ads MCP Server? — definición técnica y flujo

    Técnicamente, es un servidor que ofrece primitivas MCP (tools, resources) vía JSON-RPC para que un cliente MCP —Claude Desktop, un agente custom o un orquestador tipo n8n con adaptador— hable con advertising-api.amazon.com.

    Flujo resumido

    • Usuario: “Analiza ROAS de las campañas de zapatillas, última semana.”
    • LLM: decide qué herramienta usar (ej. get_campaign_metrics).
    • Cliente MCP: envía la solicitud JSON-RPC al MCP Server.
    • MCP Server: traduce la llamada a la REST de Amazon, añade OAuth (Bearer token), ejecuta y devuelve JSON.
    • LLM: interpreta y genera respuesta o acción.

    Documentación oficial: Documentación oficial

    Anuncio de beta: Anuncio de beta

    Qué expone y para qué sirve (capabilities)

    Una implementación típica ofrece:

    • Lectura de estructura: cuentas, portafolios, campañas, ad groups.
    • Reportes KPI: impresiones, clics, costo, ventas, ROAS, ACOS con filtros temporales.
    • Operaciones CRUD: crear/actualizar campañas y grupos de anuncios.
    • Gestión de pujas y presupuestos (si se habilitan permisos de escritura).
    • Endpoints de facturación y perfil.

    Eso permite que un agente haga tareas de alto valor: detectar anomalías, reequilibrar presupuestos, ejecutar reglas de puja o generar reportes complejos con un único prompt.

    ¿Por qué te importa como equipo técnico?

    Porque cambia el coste de propiedad de una integración. En lugar de mantener docenas de scripts que se rompen cuando Amazon cambia un endpoint, mantienes una capa estable que define qué herramientas están disponibles y cómo usarlas. Ventajas prácticas:

    • Menor deuda técnica.
    • Integración agnóstica del LLM: funciona con Claude, ChatGPT u otros que implementen MCP.
    • Menos alucinaciones: el LLM opera sobre herramientas y metadatos claros.

    Requisitos y ejemplo mínimo de configuración

    Necesitas:

    • Cuenta de desarrollador Amazon Ads y una app registrada.
    • Credenciales OAuth: CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN, PROFILE_ID.
    • Entorno Node.js (v18+) o Python 3.10+ para ejecutar el servidor.

    Ejemplo mínimo (configuración cliente MCP)

    {
  "mcpServers": {
    "amazon-ads-service": {
      "command": "node",
      "args": ["./dist/index.js"],
      "env": {
        "AMAZON_CLIENT_ID": "amzn1.application-oa2-client...",
        "AMAZON_CLIENT_SECRET": "tu_secreto",
        "AMAZON_REFRESH_TOKEN": "tu_refresh_token",
        "AMAZON_PROFILE_ID": "1234567890"
      }
    }
  }
}

    (El JSON anterior es un trozo de config real que usan clientes como Claude Desktop para lanzar servidores MCP locales.)

    Limitaciones y riesgos que no puedes ignorar

    Esto no es magia. Considera:

    • Latencia: LLM → MCP → API añade retraso. No esperes microsegundos en operaciones complejas.
    • Rate limiting: Amazon impone límites estrictos. Un agente en bucle puede provocar throttling y bloqueos.
    • Seguridad: dar permiso de escritura es peligroso. Audita el código del MCP Server antes de poner credenciales en producción.
    • Alucinaciones operativas: el MCP reduce errores, pero el LLM todavía puede elegir parámetros inadecuados si la especificación de la herramienta es ambigua.
    • Ecosistema joven: muchas librerías y ejemplos están en alpha; prueba y versiona con cuidado.

    Cómo empezar hoy (práctico)

    1. Registra la app en Amazon Advertising y obtén tus credenciales OAuth.
    2. Levanta un MCP Server en un entorno de testing (local o staging).
    3. Conecta tu cliente MCP (Claude Desktop, agente propio o n8n con adaptador).
    4. Ejecuta prompts de solo lectura primero (reportes, métricas).
    5. Añade controles para escrituras: validaciones, límites de cambio y un modo “simulación” antes de aplicar pujas reales.

    Documentación recomendada: Documentación recomendada

    Anuncio y guía inicial: Anuncio y guía inicial

    Conclusión breve

    Amazon Ads MCP Server es la infraestructura que permite a los agentes de IA operar sobre tu stack publicitario con menos fricción y más contexto. No es la bala de plata, pero sí la base para construir agentes de supervisión que detecten anomalías, propongan optimizaciones y, cuando esté permitido, las ejecuten bajo reglas guardadas.

    Empieza en testing, audita todo, y deja que el agente haga lo repetitivo. Lo inteligente —lo que realmente crea ventaja— es diseñar las reglas y guardrails; el resto lo ejecuta la máquina. En el próximo artículo mostraremos un ejemplo práctico conectando MCP Server con n8n y Claude para automatizar una regla de puja segura.

    Puedes profundizar en experimentos y guías prácticas relacionadas con automatización y agentes en Dominicode Labs. Es una continuación lógica para equipos que quieran prototipar flujos MCP y automatizaciones seguras.

    FAQ

    Respuesta

    Amazon Ads MCP Server es un servidor middleware que implementa el estándar MCP para exponer la funcionalidad de la API de Amazon Advertising como herramientas consumibles vía JSON-RPC por clientes MCP y agentes IA.

    Respuesta

    Reduce la deuda técnica al centralizar traducciones y autenticación (OAuth). Evita mantener múltiples scripts frente a cambios de endpoint y define un conjunto claro de herramientas para el LLM.

    Respuesta

    Latencia adicional, riesgo de throttling por rate limits, seguridad de credenciales y posibles alucinaciones operativas del LLM si las herramientas no están bien especificadas.

    Respuesta

    Sí, se pueden habilitar escrituras, pero es de alto riesgo. Audita el código, añade validaciones y pruebas, y usa modos de simulación antes de permitir cambios reales.

    Respuesta

    Necesitas una cuenta de desarrollador Amazon Ads, una app registrada y credenciales OAuth (CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN, PROFILE_ID). Además, un entorno Node.js (v18+) o Python 3.10+ para ejecutar el servidor.

    Respuesta

    Implementa backoff y límites en el agente, monitoriza llamadas y prueba en staging. Evita bucles automáticos que multipliquen peticiones sin control.

    Respuesta

    Clientes como Claude Desktop, agentes custom y orquestadores tipo n8n con adaptador pueden comunicarse vía MCP con el servidor.

    Respuesta

    Consulta la Documentación oficial y el Anuncio de beta para guías y noticias.

  • Configuración y uso de GraphQL en Angular 21 para desarrolladores

    Configuración y uso de GraphQL en Angular 21 para desarrolladores

    Introduccion a GraphQL con Angular 21

    Tiempo estimado de lectura: 4 min
    • GraphQL + Angular 21: consulta declarativa y reactividad granular con Signals para menos deuda técnica.
    • Configuración mínima: providers standalone y Apollo + InMemoryCache para normalización y SSR compatible.
    • Patrón recomendado: convertir Observables a Signals (toSignal) para plantillas limpias; conservar Observables en la capa de servicios.
    • Mutations: usar optimisticResponse y update junto a typePolicies para evitar parpadeos y duplicados.
    • Codegen: generar tipos y servicios Angular; fallos de contrato en compilación, no en runtime.

    Introducción

    Introduccion a GraphQL con Angular 21 es más que “añadir Apollo”: es reconciliar dos ideas que cambian la capa de datos del frontend —consultas declarativas y reactividad granular con Signals— para obtener rendimiento real y menos deuda técnica. En las primeras líneas: esta guía muestra configuración, patrones y criterios prácticos para llevar GraphQL a una app Angular 21 standalone sin convertir el cliente en una pesadilla de suscripciones.

    Resumen rápido (lectores con prisa)

    Qué es: integración de GraphQL con Angular 21 usando Apollo e InMemoryCache para datos tipados y normalizados.

    Cuándo usarlo: vistas que combinan múltiples recursos o requieren minimizar tráfico.

    Por qué importa: menos overfetching/underfetching, tipado end-to-end y caché cliente coherente.

    Cómo funciona (resumen): configura providers standalone, genera tipos con codegen, convierte Observables a Signals para la UI y usa políticas de caché para mutaciones.

    Por qué usar GraphQL con Angular 21

    GraphQL resuelve dos problemas frecuentes frente a REST: overfetching (descargas de datos innecesarios) y underfetching (múltiples llamadas para construir una vista). Angular 21 aporta Signals y providers standalone que facilitan inyectar un cliente GraphQL tipado y consumir datos de forma síncrona en la UI.

    • Peticiones precisas por vista → menos bytes y mejores Core Web Vitals.
    • Tipado end-to-end con GraphQL Code Generator → fallos detectados en compilación.
    • Caché cliente (Apollo) con normalización → menos refetches y estado local coherente.

    Lecturas oficiales: GraphQL, Apollo Angular, Angular Reactivity.

    Configuración mínima en Angular 21 (Standalone + Zoneless)

    Angular 21 favorece providers en app.config.ts. Usaremos Apollo Angular y InMemoryCache para normalización.

    Proveedores (app.config.ts)

    import { ApplicationConfig, inject } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideApollo } from 'apollo-angular';
import { HttpLink } from 'apollo-angular/http';
import { InMemoryCache } from '@apollo/client/core';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    provideApollo(() => {
      const httpLink = inject(HttpLink);
      return {
        link: httpLink.create({ uri: '<a href="https://api.example.com/graphql" style="color: #00c2ff !important;">https://api.example.com/graphql</a>' }),
        cache: new InMemoryCache({
          typePolicies: {
            Query: { fields: {} }
          }
        }),
      };
    })
  ]
};

    Este patrón funciona con SSR/Hydration si añades lógica de serialización del caché (Apollo persist).

    Queries con Signals: patrón recomendado

    Apollo expone Observables. Convierte esos streams a Signals para plantillas libres de | async y suscripciones manuales.

    Consulta ejemplo

    # src/graphql/user.graphql
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    avatar
    projects { id name }
  }
}

    Componente standalone usando toSignal

    import { Component, inject, input, effect, computed } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { GetUserGQL } from './generated/graphql'; // codegen
import { map } from 'rxjs';

@Component({ standalone: true, template: `...` })
export class UserCard {
  private gql = inject(GetUserGQL);
  userId = input.required<string>();

  // watch() viene del servicio generado por codegen
  private obs = this.gql.watch({ id: this.userId }).valueChanges;
  private result = toSignal(obs);
  user = computed(() => this.result()?.data?.user ?? null);

  // reaccionar a cambios del input: refetch en un effect
  effect(() => {
    const id = this.userId();
    if (id) this.gql.fetch({ id }); // o this.gql.watch(...).refetch()
  });
}

    Criterio: usa toSignal para lectura en la UI; para flujos complejos conserva Observables en la capa de servicios.

    Documentación codegen: https://www.graphql-code-generator.com/

    Mutations y estrategias de caché

    Para mutaciones, usa async/await, optimisticResponse y update para evitar parpadeos:

    await this.apollo.mutate({
  mutation: UPDATE_USER_NAME,
  variables: { id, name },
  optimisticResponse: { updateUser: { __typename: 'User', id, name } },
  update: (cache, { data }) => {
    cache.modify({
      id: cache.identify({ __typename: 'User', id }),
      fields: { name: () => data.updateUser.name }
    });
  }
});

    TypePolicies y keyFields son esenciales para normalizar y evitar duplicados. Documentación InMemoryCache: InMemoryCache

    Codegen y contrato cliente-servidor

    No escribas interfaces a mano. GraphQL Code Generator genera:

    • Tipos TypeScript exactos.
    • Servicios Angular (watch/mutate) listos para inyectar.

    Ejemplo codegen.ts:

    schema: "<a href="https://api.example.com/graphql" style="color: #00c2ff !important;">https://api.example.com/graphql</a>",
documents: "src/**/*.graphql",
generates: { "src/generated/": { plugins: ["typescript","typescript-operations","typescript-apollo-angular"] } }

    Esto convierte errores de contrato en fallos de build, no bugs runtime.

    ¿Cuándo elegir GraphQL en Angular 21?

    Úsalo si:

    • Vistas combinan datos de múltiples recursos.
    • Móviles requieren minimizar tráfico.
    • Equipo backend provee un grafo unificado.

    Evítalo si:

    • App es CRUD simple (HttpClient es más liviano).
    • Necesitas caching CDN agresivo con rutas REST estáticas.
    • Equipo no puede mantener esquema y codegen sincronizados.

    Buenas prácticas rápidas

    • Versiona y valida tu esquema en CI.
    • Ejecuta codegen en CI; falla la build si tipos cambian inesperadamente.
    • Define typePolicies tempranamente (pagination, merge).
    • Monitoriza latencia y cache hit-rate (Apollo DevTools).
    • Considera BFF si tu backend no puede evolucionar a GraphQL.

    Esta introduccion a GraphQL con Angular 21 es práctica: configura, genera tipos y consume con Signals. No es mágico, pero reduce considerablemente deuda técnica cuando se aplica con criterio. En Dominicode veremos patrones avanzados (cursor pagination, cache eviction, SSR hydration) —esto no acaba aquí.

    FAQ

    1. ¿Qué problemas resuelve GraphQL frente a REST?
    2. ¿Por qué usar Signals en Angular 21 con GraphQL?
    3. ¿Cómo evito parpadeos cuando actualizo datos?
    4. ¿Qué aporta GraphQL Code Generator al flujo de trabajo?
    5. ¿Es Apollo obligatorio?
    6. ¿Cómo encaja esto con SSR y Hydration?

    Respuesta: Reduce overfetching y underfetching al permitir peticiones precisas por vista; evita múltiples llamadas necesarias para componer una UI.

    Respuesta: Signals permiten lectura síncrona en plantillas sin pipes ni suscripciones manuales; facilitan reactividad granular y menos complejidad en la UI.

    Respuesta: Usa optimisticResponse y la función update del cliente para modificar el caché inmediatamente; define typePolicies para mantener consistencia y evitar duplicados.

    Respuesta: Genera tipos TypeScript y servicios Angular que detectan errores de contrato en build; evita escribir interfaces manualmente y reduce bugs runtime.

    Respuesta: No es obligatorio. Apollo aporta InMemoryCache y herramientas maduras para normalización; podrías usar otro cliente GraphQL, pero perderías integraciones y patrones documentados aquí.

    Respuesta: Funciona con SSR/Hydration si serializas y rehidratas el caché (Apollo persist), y si colocas providers correctamente en el arranque standalone de Angular 21.

  • Cómo evaluar habilidades de agentes AI efectivamente

    Cómo evaluar habilidades de agentes AI efectivamente

    Testing Your AI Agent Skills — GEMINI_API_KEY=your-key npm run eval superlint — –provider=docker –trials=5

    Testing Your AI Agent Skills empieza con un comando. Si tu flujo de trabajo no incluye algo parecido a:

    GEMINI_API_KEY=your-key npm run eval superlint -- --provider=docker --trials=5

    estás confiando en “vibes” y no en ingeniería. Las Skills son código que otros agentes ejecutan. Si no las pruebas, fallan en silencio y rompen cosas.

    Resumen rápido (lectores con prisa)

    Un eval correcto ejecuta la skill en un entorno aislado (Docker), repite la prueba varias veces y valida resultados con un grader determinista. Esto mide tanto capacidad (pass@k) como fiabilidad (pass^k). Automatiza el gate en CI para evitar merges que degraden la calidad.

    Testing Your AI Agent Skills: por qué este comando importa

    Ese comando condensa tres principios no negociables:

    • Aislamiento: --provider=docker ejecuta la skill en un contenedor efímero. Si el agente borra archivos o instala paquetes, no rompe tu máquina.
    • Repetición: --trials=5 reconoce la no-determinismo de los LLMs. Una ejecución no prueba nada; cinco sí dan una métrica.
    • Foco: superlint es la unidad de prueba —una Skill— no el modelo entero. Testear por skill te da trazabilidad y responsabilidad.

    Si quieres ejemplos y un framework listo, clona: skill-eval

    ¿Qué mide un buen eval? (y cómo diseñarlo)

    Un eval efectivo combina tres capas:

    1. Dataset realista

    Usa repositorios con errores reales, no ejemplos limpios. Capturan edge cases.

    2. Ejecución sandboxed

    Docker + skill completa (scripts, assets, references).

    3. Grader determinista

    Código que valida outcomes, no prompts que se autoevalúan.

    Métricas que realmente importan: pass@k y pass^k

    Los LLMs varían. Dos métricas clave:

    • pass@k: ¿lo resuelve al menos una vez en k intentos? Mide capacidad.
    • pass^k: ¿lo resuelve todas las veces en k intentos? Mide fiabilidad.

    Para producción, prioriza pass^k. Recomendación práctica: 90%+ pass^k para skills críticas (migraciones, despliegues, cambios en infra).

    Recuerda la ley compuesta: si cada paso tiene 95% de éxito y encadenas 5 pasos, la probabilidad de éxito compuesto cae a ~77%. Las pruebas end-to-end capturan eso.

    Tipos de graders y cuándo usarlos

    – Graders deterministas (script): imprescindibles. Validan artefactos: archivos creados, tests que pasan, DB migrada.

    – Graders de rúbrica LLM: útiles para intencionalidad (¿siguió el workflow correcto?). Úsalos con peso menor. Nunca dependas solo de ellos.

    Combina ambos. Pondera, por ejemplo, 0.8 para el grader determinista y 0.2 para la rúbrica.

    Integración CI: Quality Gate para Skills

    No dejes que una PR rompa el comportamiento del agente. Añade esto al pipeline:

    name: Skill Eval
on:
  pull_request:
    paths: ['skills/', 'tasks/']

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run eval my_task -- --trials=5 --provider=docker
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}

    Si la tasa de éxito cae bajo el umbral, bloquea el merge. Esto transforma tests en barrera de calidad, no en opción.

    Diagnósticos útiles que debe entregar un eval

    Un buen sistema no solo dice PASS/FAIL. Debe decir por qué:

    Trial 1: FAIL - Agent used 'eslist' (typo) instead of 'eslint'
Trial 2: FAIL - Ignored extends in .eslintrc; used default rules
Trial 3: PASS
Trial 4: PASS
Trial 5: FAIL - Fixed src/utils.js instead of src/main.js

    Con eso rehaces el SKILL.md: aclaras paths, ajustas templates, añades checks previos.

    Reglas prácticas para diseñar Skills testeables

    • SKILL.md = orquestador, <500 líneas. No cargues reglas densas ahí.
    • Scripts deterministas en scripts/. No pidas al LLM escribir parsers complejos en tiempo real.
    • Assets y references planos. Usa JiT loading: “Si ocurre X, abre references/X.md”.
    • Frontmatter claro para discovery: name exacto, descripción con negative triggers.

    Referencia práctica: skill-eval

    Checklist rápido antes de mergear una skill

    • [ ] Eval pasa 5/5 en provider=docker
    • [ ] pass^5 ≥ 90% para skills críticas
    • [ ] Grader determinista cubre outcomes principales
    • [ ] Transcripts almacenados para debugging
    • [ ] PR bloqueado si la tasa baja

    Cierre: deja de confiar en sensaciones

    Testing Your AI Agent Skills no es un lujo: es el último seguro antes de que tu agente se convierta en riesgo operativo. Ejecuta evals en contenedores, repite pruebas, mide pass^k y automatiza la puerta en CI. Hazlo y tus agentes dejarán de ser promesas para convertirse en herramientas confiables. Esto no acaba aquí: empieza con un eval, recoge datos y depura la skill hasta que el Pass Rate deje de ser una estadística y pase a ser garantía.

    Como continuación natural para equipos que exploran automatización y evaluación de agentes, visita Dominicode Labs para recursos y proyectos experimentales. Encontrarás plantillas y ejemplos que facilitan implementar pipelines de evaluación reproducibles y seguros.

    FAQ

    Respuesta: Docker aísla la ejecución, evitando que la skill modifique el entorno del host. Esto protege la máquina y garantiza reproducibilidad en entornos controlados.

    Respuesta: No hay número mágico, pero --trials=5 es un buen compromiso práctico para capturar no-determinismo. Aumenta k para mayor confianza en pass@k/pass^k.

    Respuesta: El grader determinista debe validar artefactos concretos: archivos creados/actualizados, tests unitarios que pasen, migraciones aplicadas, salidas esperadas y códigos de salida del proceso.

    Respuesta: No. Los graders LLM son útiles para evaluar intención, pero deben tener peso menor. Nunca dependas exclusivamente de evaluaciones subjetivas.

    Respuesta: Añade un job en el pipeline que ejecute el eval con --provider=docker y --trials. Bloquea merges si la tasa de éxito es inferior al umbral establecido.

    Respuesta: Prioriza pass^k para producción (fiabilidad) y usa pass@k como métrica secundaria para capacidad. Objetivo práctico: 90%+ pass^k para operaciones críticas.

    Respuesta: Revisa diagnósticos por trial, ajusta dataset y grader, corrige SKILL.md y scripts deterministas, y reitera hasta mejorar la tasa. Guarda transcripts para depuración.

  • ¿Angular 21 va a cambiar todo? No del todo. Pero va a hacer que lo que queda por cambiar parezca obsoleto.

    ¿Angular 21 va a cambiar todo? No del todo. Pero va a hacer que lo que queda por cambiar parezca obsoleto.

    Tiempo estimado de lectura: 10 min

    • Angular 21 cierra el capítulo de la “magia negra”.
    • Zoneless y Signals transforman la arquitectura de las aplicaciones.
    • Mejoras significativas en SSR y consumo de APIs con rxResource.
    • Nuevas herramientas y metodologías para un desarrollo más ágil.
    • Auditorías y migraciones para adaptarse a los nuevos cambios.

    Tabla de contenidos

    Introducción

    Poca gente habla de esto sin ponerse épico. La verdad: Angular 21 no es una versión más. Es la versión que cierra el capítulo de la “magia negra” y convierte el framework en algo predecible, rápido y menos pesado para tu equipo. Y sí: trae decisiones que van a reordenar la arquitectura de muchas apps en producción.

    Te lo cuento sin florituras. Aquí está lo que importa, por qué importa y qué tienes que hacer antes de que alguien te pregunte por qué tu app sigue lenta.

    Contexto rápido (porque nadie quiere leer la historia completa)

    • Angular lanza mayor cada 6 meses.
    • Angular 19 fue el punto donde Signals dejó de ser un experimento.
    • Angular 20 maduró Zoneless.
    • Angular 21 (noviembre 2025) es la consolidación: lo experimental se vuelve estándar.

    1) Zoneless: entierra a Zone.js, pero no lo hace por decreto

    Zone.js fue útil. Permitió reactividad fácil cuando nadie quería pensar en microtasks. También fue un pegamento que hacía difíciles los stack traces y añadía kilos inútiles al bundle.

    Angular 21 dice: basta. Zoneless será el modo por defecto para nuevos proyectos. ¿Qué obtienes?

    • Menos bundle. Unos ~30KB gzipped que se pueden quitar de inicio. En apps críticas, eso cuenta.
    • Stack traces limpios. Debugging humano, no magia negra.
    • Change detection granular. Gracias a Signals, ya no necesitas re-renderizar árboles enteros.

    Implementación típica en main.ts:

    bootstrapApplication(AppComponent, {
  providers: [ provideZonelessChangeDetection() ]
});

    No esperes que todo deje de funcionar en legacy. La transición está pensada, con migradores y patrones de compatibilidad. Pero sí: si arrastras librerías que dependen internamente de Zone, tendrás trabajo.

    2) Signal-based Components: reactivo por defecto

    Signals no es moda: es el latido nuevo de Angular. En Angular 21 verás la madurez de los Signal Components. ¿Qué cambia para ti como autor de UI?

    • Inputs como Signals: input() sustituye a @Input().
    • Outputs modernos: output() reemplaza EventEmitter.
    • Queries devuelven Signals. Olvida ngOnChanges y ngAfterViewInit para muchos casos.

    Imagina componentes donde todo es una señal. Menos boilerplate. Más intención. Y menos errores por sincronización.

    No es solo sintaxis. Es una filosofía. Los componentes pasan de ser objetos con ciclos de vida a pequeñas máquinas reactivas y composables.

    3) SSR y la boda con Wiz: partial hydration y event replay

    Angular se ha apretado el cinturón con el equipo de Wiz (sí, el framework interno de Google). Resultado: mejoras de SSR que no son adorno.

    Lo importante:

    • Partial Hydration: no hidratas toda la página. Hidratación por bloques con @defer. Menos CPU en cliente, mejor TTI.
    • Event Replay: el usuario hace click antes de que cargue tu JS y no se pierde nada. El evento se replaya tras la hidratación.

    Esto cambia métricas críticas: FCP y TTI bajan, y las experiencias percibidas suben. Si trabajas en e-commerce o dashboards con mucho SSR, esto es oro.

    4) rxResource: la forma pragmática de consumir APIs

    rxResource llega para poner orden en el caos de las peticiones asíncronas. No es un sustituto milagroso, pero sí una herramienta que:

    • Provee state reactivo: value, error, isLoading.
    • Se integra con Signals.
    • Cancela peticiones cuando cambian los parámetros (sí, el switchMap que siempre quisiste).

    Resultado: menos suscripciones manuales, menos leaks, menos ifs esparcidos por componentes.

    5) El backend también importa. Aquí entra Dominicode Labs

    Frontend rápido sin backend inteligente es solo apariencia. Si tus datos llegan tarde o tus workflows son manuales, nada salva la UX.

    Dominicode Labs diseña workflows con n8n y agentes IA que convierten datos sucios en APIs limpias. Automatizamos onboarding, validaciones, pipelines y acciones que antes pedían un full-time developer.

    No es palabrería. Es orquestación. Si quieres que tus Signals consuman datos listos y que no dependan de un backend que tarda 2s en responder, hablamos.

    6) Tooling: Esbuild, Vite y un dev loop que ya no da vergüenza

    Webpack fue necesario. Pero ya huele a viejo. Angular 21 consolida Esbuild y Vite:

    • HMR real. Cambias un template y la app se actualiza sin recargar.
    • Builds de producción rápidos.
    • Mejor soporte para microfrontends y module federation.

    Para equipos, esto significa menos tiempo muerto y deploys más frecuentes. Para managers, menos tickets de “mi build tardó una hora”.

    7) Signal Forms: forms que piensan por ti (experimental)

    Angular Forms era poderoso y a veces tortuoso. Signal Forms viene a reducir callbacks y boilerplate.

    Cada control es una señal. Validaciones declarativas. Menos code para cross-field validation. Aún experimental, pero promete reducir a la mitad el ruido en formularios complejos.

    Úsalo en prototypes. No lo metas en la parte crítica de facturación sin pruebas.

    8) AI tools: MCP Server y ai_tutor — asistente, no oráculo

    Angular 21 introduce Model Context Protocol Server (MCP) y ai_tutor. ¿Qué hacen?

    • Explican y generan código contextual.
    • Ayudan con migraciones automáticas (legacy → signals).
    • Integran con tu editor para sugerencias prácticas.

    No es “copia y pega mágico”. Es DX asistida. Para equipos de producto esto reduce ramp-up y acelera refactors.

    9) Angular Aria: accesibilidad ya pensada

    Angular Aria llega con patrones accesibles por defecto: buttons, modals, live regions. Signals-based.

    Si tu app necesita compliance (WCAG), esto te ahorra horas de tweaks y fallos en QA.

    10) Testing: Vitest/Jest en vez de Karma forever

    Karma y Jasmine ya no son la experiencia por defecto. Vitest y Jest son más rápidos y mejor integrados con el nuevo builder. TestBed se aligera cuando pasas a standalone y signals.

    Si eres de esos que mide “tiempo para correr tests”, vas a agradecerlo.

    Guía mínima de migración (práctica)

    1. Empieza por standalone. Divide tu app en componentes independientes.
    2. Introduce Signals para estado local. No todo a la vez; parte por módulos pequeños.
    3. Prueba Zoneless en un entorno staging.
    4. Migraciones automáticas: usa ng g @angular/core:zoneless cuando estés listo.
    5. Sustituye Karma por Vitest en CI.
    6. Aprovecha rxResource para endpoints que cambian rápido.

    No esperes un “breaking change” extremo. El equipo de Angular ha seguido la estrategia incremental. Pero el costo de no moverte se acumula: bundle, dev speed, experiencia de usuario.

    Quién gana y quién pierde

    • Gana: nuevas apps, equipos que invierten en DX y performance, proyectos con SSR intensivo.
    • Pierde: librerías que dependen de Zone internamente sin plan de migración.
    • Neutral: apps pequeñas que no sufren por bundle o TTI.

    Metáfora rápida: Zone.js era un tabloide que tapaba la verdad. Signals son lentes de lectura que dejan ver la información clara. No te engañes: la lectura cambia.

    Urgencia real (no clickbait)

    Si lanzas features que dependen del primer paint y la interacción temprana, no puedes esperar. Experimenta con partial hydration y zoneless ahora. Los que empiecen a moverse hoy estarán listos para noviembre 2025. Los que esperen al “perfecto momento” verán a la competencia cortar distancias.

    Dominicode Labs — lo que ofrecemos (y por qué tiene sentido ahora)

    • Auditoría de compatibilidad zoneless. Detectamos librerías problemáticas y proponemos fixes.
    • Plantillas de n8n + Angular para automatizar data flows.
    • Migraciones progresivas: standalone + signals + rxResource.
    • Integración con MCP Server para derivar tasks de IA en tu flujo de desarrollo.

    Plazas limitadas para migraciones aceleradas este trimestre. Si quieres una auditoría práctica y sin humo, responde este correo con “Auditoría Angular 21” y te damos un slot.

    Cierre que no es cierre

    Angular 21 no es el final del camino. Es la etapa donde las buenas prácticas dejan de ser opcionales. Donde el framework se vuelve más pequeño, más claro y más predecible. Donde las decisiones que antes eran doctrinas devuelven control al desarrollador.

    Si te interesa un plan paso a paso —no un PDF eterno— responde este correo. O apúntate a la consultoría limitada. Pero sobre todo: empieza a experimentar hoy. Porque esto no acaba aquí. Lo que viene después depende de lo que empieces a construir ahora.

    FAQ

    ¿Qué es Angular 21?

    Angular 21 es la última versión del framework Angular, que introduce cambios significativos en su arquitectura y mejoras en rendimiento y facilidad de uso, como Zoneless y Signal-based components.

    ¿Cuáles son las mejoras más destacadas?

    Las mejoras más destacadas incluyen la adopción de Zoneless, la maduración de Signals, optimizaciones en el SSR y nuevas herramientas de desarrollo como Esbuild y Vite.

    ¿Cómo puedo migrar a Zoneless?

    Para migrar a Zoneless, comienza por dividir tu aplicación en componentes independientes y utiliza el comando ng g @angular/core:zoneless para realizar la migración automática una vez estés listo.

    ¿Qué herramientas recomienda Angular 21?

    Angular 21 recomienda utilizar Esbuild y Vite por su rendimiento en builds y en el desarrollo en general, proporcionando HMR real y tiempos de despliegue más rápidos.

    ¿Qué es Dominicode Labs y cómo puede ayudarme?

    Dominicode Labs ofrece servicios de auditoría de compatibilidad zoneless, plantillas de automatización con n8n y ayuda en migraciones progresivas para adaptarse a Angular 21 y sus nuevas funcionalidades.