DOMINICODE

Category: Blog

Your blog category

  • MCP server para empresas: por qué necesitas el tuyo en 2026

    MCP server para empresas: por qué necesitas el tuyo en 2026

    Un cliente llega a tu empresa con su propio agente de IA. Ha construido workflows con Claude, con GPT-4o, con lo que sea. Quiere que ese agente use tu plataforma — consultar datos, lanzar acciones, integrarse con lo que tú ya tienes.

    Tu equipo responde: “Tenemos una API REST. Aquí está la documentación.”

    El cliente asiente, se va, y dos semanas después vuelve con una lista de preguntas sobre autenticación, rate limits y por qué el agente no entiende el schema de tu respuesta. Tu equipo dedica tres sprints a construir un wrapper custom. El cliente queda satisfecho. Pero el siguiente cliente viene con el mismo problema. Y el siguiente.

    Ese es el problema que un MCP server para empresas resuelve de raíz.

    Qué es MCP y por qué importa ahora

    Si ya leíste MCP explicado para developers: conecta Claude a tus herramientas, tienes el contexto técnico. El resumen ejecutivo es este: MCP (Model Context Protocol) es el protocolo abierto que estandariza cómo los agentes de IA se comunican con herramientas y servicios externos. Lo creó Anthropic en noviembre de 2024. En menos de 18 meses alcanzó 97 millones de descargas mensuales del SDK.

    OpenAI lo adoptó en marzo de 2025. Microsoft en mayo, durante el Microsoft Build. La Agentic AI Foundation — con Anthropic, OpenAI, Google, AWS y Cloudflare como cofundadores — lo recibió bajo la Linux Foundation en diciembre de 2025. Ya no es el protocolo de Anthropic. Es el estándar del sector.

    Forrester predice que el 30% de los vendors de software empresarial lanzarán su propio MCP server en 2026. Si tu empresa tiene una API, ese porcentaje incluye a tu competencia. Puedes ver el listado oficial de MCP servers en el repositorio de la especificación.

    El problema de las integraciones N×M que un MCP server resuelve

    Antes de MCP, el problema era sencillo de enunciar e imposible de escalar: cada cliente que quería conectar su agente de IA a tu servicio necesitaba una integración custom. Tú necesitabas mantenerla. Ellos necesitaban documentarla para cada LLM que usaran.

    Un cliente con Claude, otro con GPT, otro con Gemini. Tres integraciones. Cinco clientes, quince integraciones. La complejidad crece de forma cuadrática.

    MCP colapsa esa matriz. Un server, muchos clientes. Cualquier agente compatible con MCP — Claude, Cursor, tu herramienta interna — puede usar tu servidor sin que tú ni tu cliente escriban una línea de código de integración adicional.

    Empresas con MCP server en producción: Stripe, Cloudflare, GitHub

    No es teoría. Hay empresas que ya tienen MCP servers en producción y que están redefiniendo cómo sus clientes interactúan con ellas.

    Cloudflare expone toda su API — más de 2.500 endpoints de Workers, R2, D1, DNS y Zero Trust — a través de un MCP server con solo dos herramientas: search() y execute(). Un agente puede desplegar un Worker, configurar un dominio o gestionar reglas de acceso sin que un humano abra el dashboard. Cloudflare no creó una integración por cada herramienta de IA. Creó un punto de entrada único.

    Stripe tiene un MCP server que permite a los agentes inspeccionar clientes, suscripciones, pagos y disputas. El caso de uso es claro: un agente de soporte o de análisis financiero puede consultar el estado de una transacción directamente, sin que alguien tenga que entrar al dashboard o llamar a la API manualmente.

    GitHub expone issues, pull requests y búsqueda de código. Los agentes de desarrollo — como Claude Code — pueden abrir issues, revisar PRs o buscar en el código base directamente desde el contexto de trabajo del desarrollador.

    Notion, Linear, Sentry, Asana y Atlassian convergen en el mismo patrón: un servidor MCP alojado en su propia infraestructura, protegido por OAuth, que cualquier agente compatible puede usar sin configuración adicional.

    El patrón que se está convirtiendo en referencia de la industria es el que estableció Cloudflare: un MCP server remoto alojado en Workers, expuesto como endpoint público, autenticado con OAuth. Stripe, Linear y Sentry siguieron exactamente ese camino.

    MCP server vs API REST: la diferencia que importa

    Dimensión API REST MCP Server
    Consumidor Un programador (o su código) Un agente de IA de forma autónoma
    Autodescripción Documentación externa (OpenAPI, etc.) Nombre, descripción y schema integrados
    Integración por cliente Una por LLM / plataforma Una sola, vale para todos los clientes MCP
    Mantenimiento N adaptadores en paralelo Un único punto de entrada
    Compatibilidad Depende del cliente Cualquier agente que soporte MCP

    La diferencia no está en el transporte HTTP — está en quién consume y cómo lo hace.

    Por qué esto es una ventaja competitiva, no solo una feature técnica

    Aquí está la tesis central de este post: exponer tu servicio como MCP server no es una integración más. Es posicionarte en la capa de infraestructura de los agentes de IA.

    En los próximos dos o tres años, los workflows empresariales se van a orquestar mediante agentes. Esos agentes van a conectarse con los servicios que estén disponibles en su ecosistema. Si tu empresa no está accesible vía MCP, tus clientes van a usar el servicio de tu competidor que sí lo está. No porque sea técnicamente superior — sino porque es el que el agente puede usar sin fricción.

    Piénsalo como los plugins de ChatGPT en 2023, pero con el soporte de toda la industria detrás y un estándar real. O como tener presencia en el App Store en 2010 — todavía temprano, todavía diferenciador.

    Las ventajas concretas son estas:

    1. Distribución sin esfuerzo de integración. Cualquier agente MCP-compatible puede usar tu server el día que lo publicas. Sin SDK propio. Sin documentación de integración por plataforma.

    2. Reducción drástica del coste de integración. Mantener un único MCP server en lugar de N adaptadores custom elimina la mayor parte del trabajo de integración. En la práctica, organizaciones que han estandarizado en MCP reportan reducciones superiores al 60% frente a conectores custom independientes.

    3. Posicionamiento como infraestructura. Los servicios que se convierten en infraestructura para otros tienen una tasa de churn históricamente baja. Si los workflows de tus clientes dependen de tu MCP server, la barrera de salida sube.

    4. Acceso al ecosistema de agentes sin inversión en partnerships. Cuando Cursor, Claude Code o cualquier nuevo cliente MCP busque herramientas disponibles, tu server ya estará ahí. No necesitas acuerdos con Anthropic ni con OpenAI para aparecer en su ecosistema.

    5. Datos de uso más ricos. Un MCP server te dice exactamente qué operaciones realizan los agentes de tus clientes, con qué frecuencia, con qué parámetros. Eso es señal de producto que una API tradicional no te da con la misma granularidad.

    6. Velocidad de adopción por parte de clientes técnicos. Los developers y los equipos de ingeniería que ya trabajan con agentes van a evaluar tu producto por si tiene MCP server. Es una señal de que entiendes el ecosistema en el que operan.

    Cuándo tiene sentido construirlo — y cuándo no

    No todo servicio necesita un MCP server hoy. Tiene sentido si se cumplen al menos dos de estas condiciones:

    • Tu API ya tiene clientes externos que la integran en sus workflows.
    • Tus clientes son developers o equipos técnicos que trabajan con agentes de IA.
    • Tienes operaciones discretas y definibles — acciones que un agente puede invocar con claridad.
    • Tu competencia ya está evaluando o construyendo el suyo.

    No tiene sentido si tu producto es puramente transaccional sin lógica de negocio expuesta, si tus clientes no tienen ninguna adopción de IA aún, o si tu API no está estabilizada. Un MCP server mal diseñado puede crear más fricción que eliminarla.

    La clave es pensar en términos de herramientas, no de endpoints. Un MCP server no expone rutas HTTP — expone acciones con nombre, descripción y schema de parámetros que un LLM puede entender sin documentación adicional.

    El momento es ahora, no en 2027

    En 12 meses, tener un MCP server no será una ventaja competitiva. Será la línea de base. Como tener una API REST en 2015 o estar en el App Store en 2012. Los que entraron antes construyeron workflows y convenciones que son difíciles de desplazar.

    El patrón de adopción de MCP sigue exactamente la curva que siguieron los SDKs de OAuth, los webhooks y las APIs GraphQL. Primero una empresa pionera. Luego los líderes del sector. Luego todos. El mercado está en la segunda fase.

    Si estás construyendo un producto con IA o evaluando cómo posicionar tu servicio en el ecosistema de agentes, en el curso Construye con IA trabajamos exactamente este tipo de decisiones arquitectónicas: desde la idea hasta el producto, con las herramientas que el sector ya usa en producción.

    Cómo empezar sin un proyecto completo

    El punto de entrada mínimo no es construir un MCP server completo. Es identificar las tres o cinco operaciones de tu API que más valor aportarían a un agente externo.

    Para Stripe, son: consultar cliente, listar pagos, ver disputa. Para Cloudflare, son: buscar recurso, ejecutar acción. Para tu empresa, probablemente sean las mismas operaciones que ya documentas como “casos de uso principales” en tu developer portal.

    El SDK oficial de MCP en TypeScript y Python tiene menos de 200 líneas para un servidor funcional. El coste de entrada es bajo. El coste de no entrar ahora es más alto de lo que parece.

    Si quieres explorar esto con más profundidad junto a otros developers que ya están construyendo con agentes, en Dominicode Labs tenemos recursos, proyectos y conversaciones activas sobre arquitectura MCP en producción.

    FAQ

    ¿Es MCP solo para empresas grandes como Stripe o Cloudflare?

    No. El SDK es open source, la implementación mínima es trivial y los casos de uso más interesantes están en productos medianos con APIs bien definidas. Las empresas grandes lo lanzaron antes porque tienen más exposición pública, no porque sea técnicamente más accesible para ellas. Una startup con una API limpia puede tener un MCP server en producción en días.

    ¿MCP funciona con todos los modelos de IA, no solo con Claude?

    Sí. Aunque MCP lo desarrolló Anthropic, OpenAI lo adoptó en abril de 2025 y Microsoft en julio de 2025. Hoy es un estándar de la industria bajo la Agentic AI Foundation (Linux Foundation). Cualquier cliente que implemente el protocolo — Claude, GPT, Cursor, tu agente interno — puede consumir tu MCP server sin cambios en el servidor.

    ¿Qué diferencia hay entre un MCP server y una API REST normal?

    Una API REST expone endpoints que un humano (o un código que alguien escribió) llama con parámetros concretos. Un MCP server expone herramientas con nombre, descripción semántica y schema de parámetros que un LLM puede interpretar, seleccionar y usar de forma autónoma dentro de un workflow. La diferencia no es en el transporte — es en que el consumidor es un modelo de lenguaje, no un programador.

    ¿Hay riesgos de seguridad al exponer un MCP server?

    Los mismos riesgos que tiene cualquier API expuesta: autenticación, autorización, rate limiting y auditoría. El patrón de referencia de la industria (Cloudflare, Stripe) usa OAuth 2.0 con tokens de acceso limitados al scope que el usuario autoriza. El MCP server no añade superficie de ataque nueva — la gestiona con el mismo modelo que ya usan las APIs modernas. Lo importante es no exponer herramientas destructivas sin confirmación explícita del usuario.

    ¿Necesito cambiar toda mi arquitectura para tener un MCP server?

    No. El MCP server es una capa adicional, no un reemplazo. Tu API REST sigue funcionando igual. El MCP server actúa como un adaptador que traduce las herramientas del protocolo a llamadas a tu API existente. En la mayoría de los casos es una capa delgada de 200-500 líneas de TypeScript o Python sobre lo que ya tienes.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Astro v7: novedades clave y cómo crear tu landing desde cero

    Astro v7: novedades clave y cómo crear tu landing desde cero

    Un developer me escribió hace unas semanas. Tenía una landing page para un producto que estaba a punto de lanzar. La había montado con Next.js porque “era lo que conocía”. El tiempo de build era de 4 minutos. El bundle pesaba más de lo que debería. Y lo único que necesitaba era una página estática con una sección hero, tres features y un formulario de contacto.

    Next.js para eso es como usar un martillo neumático para clavar un cuadro.

    La respuesta que le di fue una sola palabra: Astro. Y ahora, con Astro v7, esa respuesta es más sólida que nunca.

    Qué es Astro, por si llevas tiempo mirando para otro lado

    Astro es un framework de generación de sitios estáticos que tiene una idea central brillante: envía cero JavaScript al cliente por defecto. Solo envía HTML y CSS. Si necesitas interactividad en algún componente concreto, la añades con lo que quieras: React, Vue, Svelte, Lit — Astro lo llama “islands”.

    Para landings, blogs, documentación y cualquier sitio orientado al contenido, no hay nada más rápido ni más sencillo de mantener.

    Astro v7 lleva esa idea más lejos que nunca. Y los números lo avalan.

    Las novedades reales de Astro v7

    Astro v7 es la séptima versión mayor del framework, lanzada en 2026, que introduce un compilador reescrito en Rust, Vite 8 con Rolldown y Route Caching estable como cambios principales. Es la versión con el mayor salto de rendimiento desde el lanzamiento del framework.

    El compilador se reescribió en Rust — y se nota

    La parte más importante de esta versión no es una nueva API. Es que el compilador de .astro pasó de estar escrito en Go a estar escrito en Rust.

    El resultado: builds entre un 15% y un 61% más rápidos en benchmarks reales. El sitio de documentación oficial de Astro pasó de tardar 114 segundos en construirse a 73. El propio astro.build bajó de 62 segundos a 24 (datos oficiales del blog de Astro).

    Eso es el tipo de mejora que no se consigue ajustando configuraciones. Es un cambio de arquitectura.

    El tradeoff: el compilador Rust es más estricto con HTML inválido. Antes, si dejabas una etiqueta sin cerrar, Astro la corregía silenciosamente. Ahora lanza un error. Lo cual, seamos honestos, es el comportamiento correcto.

    Vite 8 con Rolldown — el bundler en Rust también

    Astro v7 actualiza a Vite 8, que trae Rolldown: un bundler escrito en Rust que reemplaza tanto a esbuild como a Rollup con una sola herramienta unificada. En benchmarks, es 10-30 veces más rápido que Rollup.

    La compatibilidad con la API de plugins de Rollup y Vite se mantiene. Si tienes plugins existentes, seguirán funcionando.

    Nuevo procesador Markdown: Sätteri

    El pipeline de Markdown ha cambiado por completo. El procesador anterior basado en unified, remark y rehype ha sido reemplazado por Sätteri, un procesador escrito también en Rust.

    Sätteri incluye de serie: GitHub Flavored Markdown, tipografía inteligente, IDs de encabezados, directivas, matemáticas y frontmatter. Sin configuración adicional.

    Si tenías plugins personalizados de remark o rehype, puedes volver al pipeline anterior instalando @astrojs/markdown-remark y configurándolo explícitamente. No pierdes nada — solo dejas de tenerlo por defecto.

    Route Caching ahora es estable

    El sistema de caché de rutas, que estaba en experimental, ya es parte de la API estable. Puedes controlar el caché de cada respuesta con una API agnóstica a la plataforma:

    // En cualquier página .astro o endpoint
Astro.cache.set({
  maxAge: 120,     // 2 minutos en caché de cliente/servidor
  swr: 60,         // 1 minuto de revalidación en background
  tags: ['products']
});

    Y cuando necesitas invalidar:

    await cache.invalidate({ tags: ['products'] });

    Para Netlify, Vercel y Cloudflare hay CDN cache providers experimentales que traducen estas directivas a la capa edge de cada plataforma.

    Advanced Routing — control total del pipeline

    Astro v7 introduce un archivo src/fetch.ts que te da acceso completo al pipeline de solicitudes, antes de que Astro las procese. Compatible con Hono para middleware:

    // src/fetch.ts
import { astro } from 'astro/fetch';


    export default {   fetch(request: Request) {     const url = new URL(request.url);
    


    // Intercepta rutas /api antes de que lleguen a Astro     if (url.pathname.startsWith('/api')) {       return fetch('https://mi-backend.com' + url.pathname, request);     }
    


    return astro(request);   } }

    Si ya tienes un src/fetch.ts propio en tu proyecto, Astro v7 lo detectará y te pedirá que lo renombres o que desactives esta feature.

    Modo para agentes IA

    Esto es interesante si construyes herramientas con IA o trabajas con Claude Code, Cursor u otros coding agents. Astro v7 detecta automáticamente cuando está corriendo dentro de un agente y activa dos comportamientos:

    1. Inicia el servidor de desarrollo en modo background con astro dev --background
    2. Cambia los logs a formato JSON estructurado para que el agente los pueda parsear
    # Arranque idempotente — no lanza otro servidor si ya hay uno corriendo
astro dev --background


    # Estado del servidor astro dev status
    


    # Logs en JSON astro dev --json

    Astro v6 vs v7 — qué cambió exactamente

    Área Astro v6 Astro v7
    Compilador .astro Go Rust (15-61% más rápido)
    Bundler Vite 7 + Rollup Vite 8 + Rolldown (Rust)
    Procesador Markdown unified / remark / rehype Sätteri (Rust, GFM incluido)
    Route Caching Experimental Estable (Astro.cache.set)
    Routing avanzado No disponible src/fetch.ts estable
    Modo agente IA No disponible astro dev --background + logs JSON
    HTML inválido Corregido silenciosamente Error de compilación (más estricto)
    @astrojs/db Disponible Eliminado → migrar a node:sqlite

    Cómo crear tu landing con Astro v7 — paso a paso

    Paso 1 — Instalación

    npm create astro@latest mi-landing

    El wizard te preguntará si quieres una plantilla vacía, con blog, o con un starter. Para una landing, elige “Empty” o “A basic, minimal starter”.

    cd mi-landing
npm run dev

    Tu servidor de desarrollo estará en http://localhost:4321.

    Paso 2 — Estructura del proyecto

    mi-landing/
├── public/
│   └── favicon.svg
├── src/
│   ├── components/
│   │   ├── Header.astro
│   │   ├── Hero.astro
│   │   ├── Features.astro
│   │   └── Footer.astro
│   ├── layouts/
│   │   └── BaseLayout.astro
│   └── pages/
│       └── index.astro
├── astro.config.mjs
└── package.json

    Paso 3 — El layout base

    ---
// src/layouts/BaseLayout.astro
interface Props {
  title: string;
  description: string;
}


    const { title, description } = Astro.props; 
    


    <!doctype html> <html lang="es">   <head>     <meta charset="UTF-8" />     <meta name="viewport" content="width=device-width, initial-scale=1.0" />     <meta name="description" content={description} />     <title>{title}</title>   </head>   <body>     <slot />   </body> </html>

    Paso 4 — Los componentes de la landing

    ---
// src/components/Hero.astro
interface Props {
  headline: string;
  subheadline: string;
  ctaText: string;
  ctaHref: string;
}


    const { headline, subheadline, ctaText, ctaHref } = Astro.props; 
    


    <section class="hero">   <h1>{headline}</h1>   <p>{subheadline}</p>   <a href={ctaHref} class="cta-btn">{ctaText}</a> </section>
    


    <style>   .hero {     display: flex;     flex-direction: column;     align-items: center;     padding: 4rem 1rem;     text-align: center;     gap: 1.5rem;   }
    


    h1 {     font-size: clamp(2rem, 5vw, 3.5rem);     font-weight: 800;     line-height: 1.1;   }
    


    .cta-btn {     display: inline-block;     padding: 0.9rem 2rem;     background: #7c3aed;     color: white;     text-decoration: none;     border-radius: 0.5rem;     font-weight: 600;     transition: opacity 0.2s;   }
    


    .cta-btn:hover {     opacity: 0.85;   } </style>

    ---
// src/components/Features.astro
const features = [
  {
    icon: "⚡",
    title: "Velocidad real",
    description: "HTML puro en el cliente. Sin JavaScript innecesario."
  },
  {
    icon: "🧩",
    title: "Componentes modulares",
    description: "Divide la UI en piezas reutilizables con props tipadas."
  },
  {
    icon: "🚀",
    title: "Deploy en segundos",
    description: "Estático por defecto. Netlify, Vercel o Cloudflare Pages."
  }
];

    


    <section class="features">   <h2>Por qué esto funciona</h2>   <ul class="features-grid">     {features.map((feature) => (       <li>         <span class="icon">{feature.icon}</span>         <h3>{feature.title}</h3>         <p>{feature.description}</p>       </li>     ))}   </ul> </section>
    


    <style>   .features {     padding: 4rem 1rem;     max-width: 900px;     margin: 0 auto;   }
    


    h2 {     text-align: center;     font-size: 2rem;     margin-bottom: 2.5rem;   }
    


    .features-grid {     display: grid;     grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));     gap: 2rem;     list-style: none;     padding: 0;   }
    


    .icon {     font-size: 2rem;     display: block;     margin-bottom: 0.75rem;   }
    


    h3 {     font-size: 1.1rem;     margin-bottom: 0.5rem;   } </style>

    Paso 5 — La página principal que lo une todo

    ---
// src/pages/index.astro
import BaseLayout from '../layouts/BaseLayout.astro';
import Hero from '../components/Hero.astro';
import Features from '../components/Features.astro';

    


    <BaseLayout   title="Mi Producto — La forma más rápida de hacer X"   description="Descripción de 160 caracteres para el SEO." >   <Hero     headline="Resuelve X sin Y"     subheadline="La frase que convierte la curiosidad en intención de compra."     ctaText="Empieza gratis"     ctaHref="#registro"   />   <Features /> </BaseLayout>

    Paso 6 — Build y deploy

    # Build de producción
npm run build


    # Preview local del build npm run preview

    El output es estático por defecto: la carpeta dist/ contiene HTML, CSS y los assets optimizados. Sube esa carpeta a Netlify, Vercel o Cloudflare Pages y estás listo.

    Los breaking changes que tienes que revisar si migras desde v6

    Si ya usas Astro y estás actualizando, el comando oficial es:

    npx @astrojs/upgrade

    Pero antes de ejecutarlo, ten en cuenta estos cuatro puntos:

    1. Etiquetas HTML sin cerrar ahora son errores. El compilador Rust no las corrige. Revisa tus componentes .astro buscando

    ,

  • o cualquier etiqueta no-void sin su cierre correspondiente.

    2. @astrojs/db ha sido eliminado. Si lo usabas, migra a node:sqlite (disponible desde Node.js 22.5.0), Drizzle ORM, Turso o cualquier alternativa SQL moderna.

    3. Los eventos de astro:transitions cambiaron. TRANSITION_BEFORE_PREPARATION y similares desaparecen. Sus equivalentes son strings directos como 'astro:after-swap'.

    4. Si tenías features en experimental, sácalas de ahí. queuedRendering, advancedRouting, cache y logger ya son estables. Muévelos al nivel raíz de astro.config.mjs.

    Por qué Astro v7 importa ahora mismo

    Astro es la respuesta correcta para landings y sites de documentación. No porque React sea malo, sino porque la herramienta correcta para contenido estático no es un SPA. Si estás construyendo productos con IA y quieres entender cómo encaja el frontend en ese stack, el post sobre el stack IA agéntica en 2026 te da el mapa completo de herramientas.

    El patrón que más se repite en los proyectos con IA que veo últimamente: alguien genera una landing con un agente y lo hace con el stack que “siempre ha usado”. El resultado: un bundle de React para servir contenido estático.

    Astro es la respuesta correcta para ese caso de uso. No porque React sea malo, sino porque la herramienta correcta para una landing o un site de documentación no es un SPA.

    El hecho de que Astro v7 ahora detecte agentes IA automáticamente no es un detalle menor — es una señal de hacia dónde va el ecosistema. Si usas Claude Code o Cursor para generar código, el post sobre cómo funciona el agentic loop explica el mecanismo detrás de esa integración.

    En el curso de Construye con IA trabajamos exactamente este tipo de decisiones: cuándo elegir Astro, cuándo Next.js tiene sentido, y cómo pasar de una idea a un producto sin arrastrar deuda técnica desde el primer día.

    Con el enfoque de Spec-Driven Development, diseñar la arquitectura de este tipo de landing antes de escribir la primera línea de código es lo que separa una landing que escala de una que se convierte en un problema de mantenimiento en seis meses.

    FAQ

    ¿Astro v7 es compatible con React, Vue o Svelte?

    Sí. Astro sigue siendo agnóstico al framework de UI. Puedes usar componentes de React, Vue, Svelte, Solid o cualquier otro framework compatible mediante el sistema de integraciones. Lo que cambia es que Astro no envía el runtime de esos frameworks al cliente a menos que marques explícitamente un componente con una directiva client:*.

    ¿Necesito migrar a Sätteri si tengo plugins de remark personalizados?

    No es obligatorio. Puedes instalar @astrojs/markdown-remark y configurar markdown: { processor: unified() } en tu astro.config.mjs para mantener el pipeline anterior. Sätteri es el nuevo default, pero el viejo pipeline sigue disponible.

    ¿Puedo usar Astro v7 para sitios con contenido dinámico, no solo estático?

    Sí. Astro soporta SSR (Server-Side Rendering) con adaptadores para Node.js, Netlify, Vercel y Cloudflare Workers. Con el nuevo Advanced Routing y src/fetch.ts tienes control total sobre el pipeline de solicitudes. Para contenido que cambia con frecuencia, el nuevo sistema de Route Caching con invalidación por tags es especialmente útil.

    ¿Cuánto cuesta migrar un proyecto de Astro v5 o v6 a v7?

    Depende del proyecto, pero el comando npx @astrojs/upgrade automatiza la mayor parte. Los cambios manuales más comunes son: cerrar etiquetas HTML que el compilador anterior perdonaba, eliminar @astrojs/db si lo usabas, y sacar las features que estaban en experimental al nivel raíz de la configuración. En un proyecto mediano, una tarde es suficiente.

    ¿Astro v7 es una buena opción para documentación técnica?

    Es probablemente la mejor opción disponible. El procesador Sätteri maneja GFM, directivas y matemáticas de serie. El sistema de content collections te permite estructurar MDX como si fuera una base de datos. Y los builds son ahora significativamente más rápidos, lo que importa cuando tienes cientos de páginas de documentación. No en vano, el propio sitio de documentación de Astro corre sobre Astro.

    Si quieres ver cómo integramos herramientas como Astro en un flujo de trabajo completo con IA — desde el spec hasta el deploy — en Dominicode Labs tenemos proyectos activos donde exploramos exactamente ese proceso.

    Y si prefieres empezar con vídeo, en el canal de YouTube de Dominicode hay contenido regular sobre desarrollo con IA, Angular, TypeScript y herramientas de producción.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Cómo medir la productividad en equipos que usan IA

    Cómo medir la productividad en equipos que usan IA

    Un tech lead me escribió hace unas semanas con una pregunta que no esperaba: “Bezael, ¿cómo le demuestro a mi CTO que la IA está funcionando?”

    El equipo llevaba tres meses usando GitHub Copilot y Claude Code. Los developers estaban contentos. Las entregas se sentían más rápidas. Pero cuando llegó el momento de justificar la licencia ante dirección, el tech lead no tenía un solo número sólido que presentar.

    El CTO le preguntó lo de siempre: “¿Cuántas líneas de código más estáis produciendo?”

    Y ahí empezó el problema.

    Medir la productividad en equipos que usan IA requiere sustituir métricas de output (líneas de código, tickets cerrados) por métricas de flujo y calidad: cycle time, ciclos de revisión por PR, defect escape rate y confianza del equipo. Sin ese cambio de marco, los datos dicen que la IA no funciona cuando en realidad el problema es la regla con la que mides.

    El error de medir lo que siempre has medido

    Las métricas tradicionales de productividad —líneas de código, tickets cerrados por sprint, commits por semana— no estaban diseñadas para un equipo que delega trabajo a una IA.

    Cuando un developer usa Claude Code para generar el esqueleto de un servicio, los tickets no cambian. Los commits pueden ser los mismos. Pero el tiempo que ese developer tardó en llegar a ese commit pasó de cuatro horas a cuarenta minutos.

    Eso no aparece en ningún dashboard de Jira.

    El problema no es que la IA no mejore la productividad. El problema es que medir la productividad en equipos que usan IA con métricas de 2015 produce datos que no dicen nada, o peor, datos que contradicen lo que el equipo siente que está pasando.

    Y cuando los datos no cuentan la historia real, la dirección toma decisiones basadas en una historia falsa.

    Por qué las métricas tradicionales fallan con IA

    Hay tres razones concretas por las que las métricas clásicas se rompen en cuanto entra la IA.

    Primera: la unidad de medida cambia. Antes, un developer hacía una cosa a la vez. Con IA, puede mantener contexto de tres o cuatro tareas en paralelo. Los tickets cerrados por semana pueden ser los mismos, pero la complejidad por ticket se multiplica.

    Segunda: el trabajo invisible desaparece. La IA absorbe el trabajo de bajo valor — boilerplate, documentación inicial, tests unitarios básicos — que antes inflaba las métricas sin añadir valor real. Al desaparecer ese trabajo, las métricas caen aunque la productividad suba.

    Tercera: la calidad pasa a ser la variable crítica. Un equipo con IA puede producir más código en menos tiempo. Pero si ese código no está bien especificado, va a producir más código malo en menos tiempo. Las métricas de velocidad no capturan esto. El ciclo de revisión, sí.

    Métrica tradicional Por qué falla con IA
    Líneas de código No refleja el tiempo ahorrado en generación automática
    Tickets cerrados por sprint No captura el aumento de complejidad por ticket
    Commits por semana El mismo número, pero con 10x menos tiempo de escritura
    Velocidad de sprint (story points) Se mantiene estable aunque la dificultad técnica suba

    Las métricas que sí funcionan para medir productividad con IA

    Estas son las cinco métricas que tienen sentido cuando el equipo trabaja con asistencia de IA. No son nuevas — algunas vienen del marco DORA, otras son adaptaciones directas. Lo nuevo es el contexto en que las usas.

    1. Cycle time por tarea (tiempo de ciclo real)

    Mide cuánto tiempo pasa desde que una tarea entra en “en progreso” hasta que está en “revisión”. No en “cerrada” — en revisión. Ese delta captura la velocidad de producción antes de que el proceso de PR y QA añada ruido.

    Si el equipo usa IA y el cycle time no baja, hay un problema de especificación o de prompting, no de herramienta.

    2. PR review cycles (iteraciones por pull request)

    Cuántas veces vuelve un PR del revisor al autor. Con IA, el código puede ser correcto sintácticamente pero incorrecto semánticamente — hace lo que el prompt pedía, no lo que el ticket decía. Un aumento en ciclos de revisión es la primera señal de que el equipo está usando IA sin un proceso de especificación previo. Si quieres entender por qué la especificación es la clave aquí, el post sobre vibe coding sin sistema lo explica desde el ángulo del proyecto completo.

    Benchmark útil: según datos de LinearB y el SPACE framework de Microsoft Research, un equipo sano sin IA tiene entre 1,2 y 1,8 ciclos de revisión por PR. Con IA bien implementada, debería bajar a menos de 1,2.

    3. Defect escape rate (bugs que llegan a producción)

    El número de bugs que pasan el proceso de revisión y llegan a producción. La IA genera código con menos bugs de sintaxis pero puede introducir errores de lógica más sutiles cuando el contexto está mal definido. Esta métrica captura si la calidad real del output está subiendo o bajando.

    4. Time to first meaningful contribution (tiempo al primer output de valor)

    Cuánto tarda un developer nuevo —o uno que empieza en una nueva área del código— en hacer su primera contribución significativa. Con IA, este tiempo debería caer drásticamente porque los modelos actúan como documentación interactiva del codebase. Si no cae, el equipo no está usando IA para onboarding.

    5. Developer-reported confidence score (autoconfianza técnica)

    Una encuesta semanal de una pregunta: “Del 1 al 10, ¿cómo de seguro te has sentido tomando decisiones técnicas esta semana?” No mide lo que el developer produce — mide si la IA lo está empoderando o creando dependencia. Una caída sostenida en esta métrica es una alarma: el equipo está delegando decisiones que no debería delegar.

    Cómo implementar estas métricas en tu equipo

    No necesitas una plataforma nueva. Con lo que ya tienes, puedes empezar esta semana.

    1. Extrae cycle time de tu gestor de tareas actual. Linear, Jira y Notion tienen este dato. Calcula la media de los últimos tres sprints antes de implementar IA. Eso es tu baseline.
    2. Añade un campo “ciclos de revisión” a tu flujo de PRs. En GitHub puedes automatizarlo con un simple script que cuente las veces que un PR pasa a “changes requested” y vuelve a “review”. No necesitas nada sofisticado.
    3. Activa el tracking de bugs por origen. ¿El bug vino de código generado con IA o de código escrito a mano? Añadir esa etiqueta a los issues de producción durante dos meses te da datos que nadie más tiene en tu organización.
    4. Envía el confidence score cada viernes. Un Google Form de una pregunta. Anónimo. Cinco minutos de setup. Los datos que obtienes en ocho semanas son más útiles que cualquier encuesta de engagement anual.
    5. Revisa las cinco métricas cada dos semanas, no cada sprint. El impacto de la IA no es lineal al principio. Los primeros cuatro sprints suelen mostrar un plateau o incluso una caída mientras el equipo ajusta workflows. La mejora real aparece en la semana seis o siete.

    Errores comunes al medir productividad con IA

    Error 1: medir demasiado pronto. Implementar IA y medir el impacto al sprint siguiente no funciona. El equipo necesita entre cuatro y seis semanas para ajustar su forma de trabajar con los modelos. Medir antes genera datos negativos que no reflejan el potencial real.

    Error 2: medir al individuo en lugar de al equipo. “¿Cuánto usa la IA este developer?” es la pregunta equivocada. La adopción de IA es un comportamiento social — si el tech lead no la usa, el equipo no la usa. Mide adopción a nivel de equipo, no de persona.

    Error 3: ignorar el coste de contexto. La IA produce output rápido, pero alguien tiene que escribir el prompt, revisar el output y decidir qué parte usar. Ese tiempo no aparece en los tickets. Si no lo contabilizas, tus métricas de velocidad quedan artificialmente infladas en comparación con el coste real.

    Error 4: no tener un baseline previo. Es imposible demostrar mejora sin un punto de partida. Antes de dar acceso a la IA al equipo, captura dos sprints de datos de cycle time, PR cycles y defect rate. Sin eso, cualquier número que presentes es opinión, no evidencia.

    Error 5: confundir actividad con impacto. El número de prompts enviados a un LLM no es una métrica de productividad. Es una métrica de uso. El impacto se mide en los outputs que importan: tiempo de entrega, calidad del código, confianza del equipo.

    Preguntas frecuentes

    ¿Qué métricas DORA son las más relevantes cuando el equipo usa IA?

    Las cuatro métricas DORA —deployment frequency, lead time for changes, change failure rate y time to restore service— siguen siendo válidas, pero el contexto cambia. Con IA, el “lead time for changes” debería bajar significativamente porque la fase de escritura de código se acelera. Si no baja, el cuello de botella está en el proceso de revisión o en la especificación, no en el coding. La “change failure rate” es la que más debes vigilar: un aumento aquí con IA activa indica que el equipo está delegando contexto que los modelos no tienen — exactamente lo que explicamos en el post sobre context engineering para proyectos con IA.

    ¿Cuánto tiempo tarda en verse el impacto real de la IA en productividad?

    En la mayoría de equipos que he visto, los primeros resultados medibles aparecen entre las semanas seis y ocho. Las primeras cuatro semanas son de ajuste: el equipo aprende qué delegar, qué especificar antes de delegar, y cómo revisar output de IA. A partir de la semana ocho, el cycle time baja y la autoconfianza sube de forma sostenida.

    ¿Cómo justifico ante dirección el coste de las licencias de IA si las métricas tardan en mostrarse?

    El argumento más sólido no son las métricas de productividad — es el coste de oportunidad. Un developer senior en España cuesta entre 50.000 y 80.000 euros al año. Si la IA reduce su ciclo de desarrollo un 30%, el retorno de una licencia de 20 euros al mes se justifica en las primeras dos horas de uso. Presenta ese cálculo antes de presentar las métricas.

    ¿Vale la pena usar herramientas específicas de medición de productividad IA como Uplevel o Faros?

    Para equipos de más de quince developers, sí. Estas plataformas integran datos de GitHub, Jira y Slack para calcular métricas de flujo de trabajo con granularidad que un tracker manual no puede dar. Para equipos menores, el setup de estas herramientas consume más tiempo del que ahorran. Empieza con las métricas manuales descritas en este post y migra a plataformas dedicadas cuando el equipo supere los veinte developers.

    ¿El confidence score realmente sirve o es demasiado subjetivo?

    Es subjetivo por diseño. Las métricas objetivas miden el output. El confidence score mide el proceso interno del developer: si está tomando decisiones con criterio o si está dependiendo de la IA para decisiones que debería tomar él. Un developer que valora su confianza en 4 sobre 10 de forma sostenida no está usando IA como amplificador — la está usando como muleta. Eso es información que ningún dashboard de GitHub te da.

    Lo que puedes hacer mañana

    No esperes a tener el sistema perfecto. Esta semana, haz una sola cosa: calcula el cycle time medio del último sprint de tu equipo. Ese número es tu baseline.

    La próxima vez que alguien te pregunte si la IA está funcionando, tendrás un punto de referencia real en lugar de una sensación.

    Si quieres ir más lejos — ver cómo integramos estas métricas dentro de un proceso estructurado de desarrollo con IA, de la especificación al deploy — en el curso Construye con IA trabajamos exactamente ese flujo: no solo usar la IA para escribir código, sino construir el sistema alrededor de ella para que los resultados sean medibles y repetibles.

    Y si tu equipo ya está en ese punto y quieres ir más profundo, en Dominicode Labs tenemos recursos sobre workflows de desarrollo con IA, plantillas de tracking y acceso directo a la comunidad para resolver dudas en contexto.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Nuevo Vite 8.1

    Nuevo Vite 8.1

    El lunes arrancas la semana, abres el proyecto, y ves que hay una nueva versión de Vite disponible. La actualizas casi en automático — llevas años confiando en que las minor no rompen nada.

    Esta vez, una advertencia en la consola: está deprecado. Buscas en la documentación. El nombre cambió. Nada grave, pero te detiene cinco minutos.

    Eso es exactamente lo que hace Vite 8.1: llega sin hacer ruido, resuelve cosas que probablemente ya te estaban molestando sin que lo supieras, y mete una feature experimental que puede cambiar cómo experimentas el desarrollo en proyectos grandes. Si todavía no la has revisado, este post te ahorra el tiempo de buscarla tú.

    se publicó el 23 de junio de 2026 y, según las propias métricas del proyecto, ya hay 41,6 millones de descargas semanales — casi las mismas que acumuló toda la era de Vite 7.

    Vite 8.1 es la versión minor del bundler de frontend que introduce bundled dev mode experimental, soporte WASM ESM nativo, chunk import maps y mejoras en LightningCSS — todo sobre la base de Rolldown, el motor Rust que reemplazó a esbuild y Rollup en Vite 8.0.

    El dev server de Vite siempre ha funcionado en modo _unbundled_: sirve cada módulo como un fichero independiente aprovechando ESM nativo del navegador. Es lo que lo hace rápido en proyectos medianos. El problema viene cuando el proyecto crece.

    En una app con 10.000 componentes React, el navegador tiene que resolver 10.000 requests en cadena. El HMR se mantiene instantáneo, pero la carga inicial y los reloads completos se vuelven lentos.

    junta los módulos antes de servirlos — igual que haría un build de producción, pero con la ventaja de que el HMR sigue siendo incremental y preciso. Los números que publica el equipo de Vite:

    • ~15x de arranque más rápido para apps grandes
    • ~10x de reloads completos más rápidos
    • 10x menos requests de red

    El equipo de Linear (la herramienta de gestión de proyectos) lo probó en producción: cold start 3x más rápido, reloads 40% más rápidos.

    Para activarlo, tienes dos opciones:

    # Desde la CLI
vite --experimental-bundle
    // vite.config.ts
export default defineConfig({
  experimental: {
    bundledDev: true,
  },
})

    Es experimental. No lo actives en CI ni en producción todavía — el equipo todavía lo está refinando. Pero en desarrollo local, sobre todo si tu proyecto tiene cientos de rutas o módulos, pruébalo esta semana.

    Hasta ahora, importar un módulo WebAssembly en Vite requería configuración extra o un plugin. En Vite 8.1 ya es nativo con la integración de :

    import { add } from './add.wasm'


    console.log(add(1, 2)) // 3

    Sin configuración adicional. Sin plugins. El módulo expone sus funciones directamente como named exports de ES Module.

    Esto es relevante si estás construyendo herramientas de procesamiento de datos, encoders, parsers, o cualquier lógica computacionalmente intensiva que tenga sentido compilar desde Rust o C. El flujo de trabajo Rust → → Vite ya no tiene fricción.

    El problema de los hashes en cascada es conocido: cambias una línea en un componente, el hash de ese chunk cambia, y ese cambio se propaga al chunk que lo importa, que cambia su hash también, y así en cadena. El resultado: el navegador invalida más caché de la necesaria.

    Vite 8.1 introduce soporte para como feature experimental. En lugar de que los hashes de los módulos dependientes cambien cuando cambia un imported chunk, el import map actúa como capa de indirección. El chunk padre sigue apuntando al mismo nombre lógico; el import map resuelve el nombre al hash real.

    // vite.config.ts
export default defineConfig({
  experimental: {
    bundledDev: true,
    // chunkImportMap se activa automáticamente con bundledDev
  },
})

    No requiere configuración adicional en . Limitación actual: no es compatible con . Si lo usas, espera a que lo resuelvan antes de activarlo.

    Vite lleva varios releases preparando el terreno para que LightningCSS sustituya a PostCSS como procesador CSS por defecto. En 8.1 llegan dos adiciones concretas:

    1. dentro de archivos CSS cuando usas LightningCSS
    2. mediante plugins — necesario para que el HMR funcione correctamente cuando un plugin modifica ficheros que no están directamente en el grafo de dependencias

    Para activar LightningCSS:

    // vite.config.ts
export default defineConfig({
  css: {
    transformer: 'lightningcss',
  },
})

    Si ya estás en , estas dos adiciones te llegan sin hacer nada. Si sigues con PostCSS, no hay prisa — pero la dirección del proyecto es clara.

    tiene un bug silencioso en el que la opción funcionaba en la resolución inicial de módulos pero no en el matching del HMR. Cambiabas un fichero, y Vite no lo detectaba si el nombre diferenciaba mayúsculas/minúsculas de forma inesperada.

    En 8.1 ya está corregido:

    const modules = import.meta.glob('./dir/module*.js', {
  caseSensitive: false,
})

    Ahora tanto la resolución inicial como el HMR respetan la misma sensibilidad a mayúsculas. Si tenías workarounds para esto, puedes eliminarlos.

    Vite detecta assets en el HTML buscando atributos conocidos: , , , etc. Si tienes elementos o atributos custom que referencian assets, Vite los ignoraba.

    Ahora puedes configurarlo explícitamente:

    // vite.config.ts
export default defineConfig({
  html: {
    additionalAssetSources: [
      { tag: 'my-image', attribute: 'data-src' },
      { tag: 'x-video', attribute: 'poster-url' },
    ],
  },
})

    Útil si trabajas con Web Components o frameworks que usan atributos no estándar para referenciar recursos.

    Vite ahora amplía la lista de ficheros denegados por defecto en . Ficheros comunes que no deberían exponerse en el dev server quedan bloqueados sin que tengas que configurarlo manualmente.

    Si tienes una configuración explícita de , revísala — puede haber solapamientos. Si confías en el comportamiento por defecto, simplemente tienes una superficie de ataque más pequeña sin hacer nada.

    Este es el cambio que genera la advertencia de deprecación que mencioné al principio.

    La opción tenía un nombre ambiguo — HMR es el protocolo, pero la configuración afectaba al WebSocket server completo, que también se usa para comunicaciones que no son HMR. El nuevo nombre refleja mejor qué estás configurando.

    // Antes (deprecado en 8.1)
export default defineConfig({
  server: {
    hmr: {
      port: 24678,
      host: 'localhost',
    },
  },
})


    // Ahora export default defineConfig({   server: {     ws: {       port: 24678,       host: 'localhost',     },   }, })

    La opción antigua sigue funcionando — verás el warning pero no se rompe nada. Migra cuando puedas, no es urgente.

    Vite 8.1 integra soporte para con caché de build zero-config. Si ya estás usando Vite Task (la nueva API de tareas del ecosistema), los builds se cachean automáticamente sin configuración adicional.

    Es una adición menor para la mayoría de proyectos, pero importante si tienes monorepos donde los builds repetidos son costosos.

    La migración desde 8.0 es prácticamente sin fricción. Los pasos concretos:

    # npm
npm install vite@^8.1 --save-dev


    # pnpm pnpm update vite@^8.1
    


    # yarn yarn upgrade vite@^8.1
    


    # bun bun update vite

    Después de actualizar, revisa estos tres puntos:

    si tienes configuración explícita del WebSocket server. La advertencia en consola te lo indica exactamente.

    si tienes reglas custom. Los nuevos defaults pueden solapar con las tuyas y crear comportamientos inesperados.

    si usas la opción directamente. Migra al sistema estándar de ficheros .

    Si vienes de Vite 7.x, revisa primero la — hay cambios más sustanciales en el salto de major, como el motor Rolldown que reemplaza a esbuild+Rollup. Precisamente, si te interesa cómo Astro v7 aprovecha Vite 8 en producción, tienes el análisis completo en .

    Si estás en Vite 7 y quieres pasar directamente a 8.1, el cambio más importante es . Vite 8.0 reemplazó esbuild (para transform) y Rollup (para bundle) por Rolldown, un bundler escrito en Rust. El resultado es hasta 30x más rápido en builds grandes, pero hay diferencias de comportamiento en edge cases.

    La documentación oficial tiene la guía completa. Lo que suele dar problemas en la práctica:

    • Plugins que asumen comportamientos específicos de Rollup en hooks de resolución
    • Configuraciones de — pasan automáticamente a pero no todo es compatible 1:1
    • Targets de CSS con PostCSS si usas configuraciones muy custom

    Mi recomendación: si tienes un proyecto en producción con Vite 7, dedica una tarde a la migración en una rama separada antes de mergearla. Si además estás evaluando qué herramientas usar en un stack moderno con IA, el post sobre el te da el mapa completo de qué merece la pena y qué ignorar. No es un upgrade de dos minutos, pero tampoco es traumático si el proyecto no tiene plugins exóticos.

    Sí. Vite 8.1 es agnóstico al framework. Los plugins oficiales (@vitejs/plugin-react, @vitejs/plugin-vue, @analogjs/vite-plugin-angular, @sveltejs/vite-plugin-svelte) ya tienen versiones compatibles con Vite 8.x. Verifica en el de cada plugin que el peerDependency incluye .

    Cuando notes que tu dev server tarda más de 3-5 segundos en arrancar o que los reloads completos son lentos. En proyectos pequeños y medianos (menos de 500 módulos), el modo unbundled sigue siendo más rápido. El beneficio de bundled dev mode es proporcional al tamaño del proyecto.

    Casi. LightningCSS cubre la mayoría de casos: prefixing, nesting nativo, variables CSS, imports. Lo que todavía puede requerir PostCSS son plugins muy específicos del ecosistema (px a rem, ciertas transformaciones custom). Si tu stack CSS es estándar, prueba a migrar — las mejoras de velocidad son notables.

    No. Esta opción solo afecta al servidor de desarrollo. En producción, Vite no levanta un WebSocket server — esa configuración es irrelevante. El cambio es puramente de nomenclatura en el dev server.

    Vite 8 requiere Node.js 18+ (igual que Vite 7). Si estás en Node 16 o inferior, tendrás que actualizarlo antes de poder usar Vite 8.x.

    Rolldown es el motor por defecto desde Vite 8.0 y se considera estable para uso en producción. Los flags experimentales son para features específicas (bundled dev mode, chunk import map) — no para Rolldown en sí. Para la mayoría de proyectos, Rolldown funciona como un drop-in replacement de Rollup.

    Vite 8.1 no es una release que te obligue a cambiar cómo trabajas. La mayor parte de las features son opt-in o correcciones de bugs que funcionan transparentemente.

    Lo que sí cambia si lo adoptas activamente:

    El puede hacer que trabajes diferente en proyectos grandes — menos tiempo esperando recargas, más tiempo en el problema real. El abre la puerta a traer lógica Rust o C al frontend sin fricción. Y el empieza a resolver uno de los problemas crónicos del caching en producción.

    Si trabajas con agentes de IA para acelerar tu desarrollo — donde cada segundo de feedback loop importa — el bundled dev mode encaja directamente en ese flujo. Es parte del tipo de optimizaciones que exploramos en el : no solo usar IA para generar código, sino construir un entorno donde iterar sea rápido de verdad.

    Y si quieres ver cómo aplico estas decisiones de toolchain en proyectos reales con código completo, pásate por — ahí está el material avanzado que no llega al blog.

  • sdd-creator: genera spec, plan y tasks con cualquier agente IA

    sdd-creator: genera spec, plan y tasks con cualquier agente IA

    Llevaba tres horas implementando un sistema de autenticación con JWT cuando me di cuenta de que no había especificado nada.

    ¿El token debía expirar en la sesión o persistir entre reinicios? ¿Qué pasaba cuando el refresh token vencía estando el usuario activo? ¿El endpoint de logout invalidaba en servidor o solo limpiaba el cliente?

    Yo respondí esas preguntas sobre la marcha. Sin coherencia, sin registro de decisiones. El código resultó funcional pero arquitectónicamente un desastre.

    Eso no es un problema del agente. Es un problema de proceso. Para eso existe sdd-creator.

    El problema de codear sin especificar

    Los agentes de IA son extremadamente buenos ejecutando instrucciones. También son extremadamente buenos ejecutando instrucciones mal definidas — y el resultado es lo que imaginas.

    Cuando le das a Claude Code o a Cursor un prompt del tipo “implementa login con JWT”, el agente toma decisiones. Muchas. Las toma rápido, sin preguntarte, porque así trabajan. El output es código funcional que responde a una interpretación del problema, no necesariamente a tu interpretación.

    El fallo no está en la IA. Está en que nunca estableciste qué querías exactamente.

    Spec-Driven Development (SDD) resuelve esto con una premisa simple: antes de generar código, genera el spec. Un documento que responde qué hace la feature, por qué existe, quién la usa, qué flujos cubre y bajo qué criterios está terminada.

    El problema es que hacer bien un spec lleva disciplina. Y cuando tienes el agente abierto y las ganas de construir, la tentación de saltártelo es enorme.

    Qué es sdd-creator y cómo funciona

    sdd-creator es un skill para agentes de IA que impone el proceso de especificación antes de ejecutar cualquier implementación. No es un generador de documentos — es un interrogador. El agente no escribe código hasta que el spec esté completo y confirmado.

    A diferencia de pedirle directamente al agente que “genere un spec libre”, sdd-creator impone siempre las mismas 6 secciones y bloquea la implementación hasta recibir confirmación explícita. Sin esa estructura, los specs se convierten en párrafos de texto libre que el agente interpreta como quiere.

    El flujo tiene siete pasos:

    1. Describes el feature o proyecto que quieres construir
    2. sdd-creator detecta la complejidad (LOW / MEDIUM / HIGH)
    3. Te hace una entrevista interactiva — te pregunta lo que no especificaste
    4. Genera spec.md con 6 secciones estructuradas
    5. Espera tu confirmación antes de continuar
    6. Genera plan.md con las decisiones técnicas y la planificación por fases
    7. Genera tasks.md con las tareas ordenadas para TDD — y solo entonces empieza la implementación

    El repositorio está en GitHub: bezael/sdd-creator — MIT, v1.2.0.

    Si quieres entender la metodología detrás con más profundidad, el libro SDD cubre los principios completos, con patrones reales de proyectos en producción.

    Instalación

    Una sola línea:

    npx skills@latest add bezael/sdd-creator

    El CLI detecta tu herramienta y copia el skill al directorio correcto automáticamente. Como referencia, los directorios destino son:

    • Claude Code: ~/.claude/skills/
    • Cursor: .cursor/rules/ del proyecto

    No hay configuración adicional. No hay API keys. No hay dependencias de runtime. El skill vive como un archivo de instrucciones que el agente carga en contexto cuando lo invocas.

    Para instalación manual o integración con otros agentes, consulta la documentación oficial de Claude Code o los docs de tu herramienta.

    Tutorial paso a paso — feature de login con JWT

    Vamos con un ejemplo concreto. Tienes una app NestJS y quieres implementar autenticación con JWT. Sin sdd-creator, abres el agente y escribes: “implementa autenticación con JWT”. Con sdd-creator, el proceso es diferente.

    Paso 1 — Invoca el skill

    En Claude Code o en Cursor, activa sdd-creator. Luego describe tu feature:

    Quiero implementar un sistema de autenticación con JWT para una API NestJS.
Incluye registro, login, refresh de token y logout.

    Paso 2 — La entrevista interactiva

    sdd-creator detecta complejidad media y empieza a preguntarte:

    • ¿El token de acceso expira en cuánto tiempo?
    • ¿El refresh token se invalida en servidor o solo en cliente?
    • ¿El endpoint de logout invalida todos los dispositivos activos o solo el actual?
    • ¿La app requiere rate limiting en los endpoints de auth?
    • ¿Los usuarios pueden tener múltiples sesiones simultáneas?

    Preguntas incómodas. Preguntas que el agente habría respondido solo — con su mejor criterio — si no le hubieras forzado a preguntarte.

    Paso 3 — Confirmas el spec.md

    El agente genera el spec.md completo. Lo revisas, corriges lo que no cuadra, y confirmas. Solo entonces avanza.

    Paso 4 — plan.md y tasks.md

    sdd-creator genera el plan técnico (decisiones de arquitectura, librerías, estructura de módulos) y la lista de tareas ordenadas para TDD. Primero los tests de los casos de error — token expirado, credenciales inválidas, refresh token revocado. Luego el código que los hace pasar.

    Resultado: el agente implementa exactamente lo que especificaste. Sin sorpresas. Sin decisiones implícitas. Sin “lo hice así porque parecía razonable”.

    Los 3 archivos que genera

    spec.md — La especificación en 6 secciones

    La estructura es fija e invariable:

    1. Visión — qué problema resuelve y por qué existe esta feature
    2. Usuarios — quién la usa y cuáles son sus necesidades reales
    3. Funcionalidades — qué puede hacer el sistema (listado concreto)
    4. Flujos — cómo se comporta el sistema en los escenarios principales
    5. Arquitectura — cómo está organizado técnicamente
    6. NFRs — requisitos no funcionales: performance, seguridad, disponibilidad

    La estructura fija es deliberada. Cuando el spec siempre tiene las mismas 6 secciones, puedes revisarlo en segundos y saber exactamente qué falta. Un spec libre en prosa no tiene esa propiedad.

    Si quieres ver cómo aplicar estas 6 secciones en un proyecto greenfield completo, este post sobre SDD con slices verticales lo cubre en detalle.

    plan.md — Las decisiones técnicas

    El plan responde: ¿cómo vamos a construir esto? Librerías seleccionadas y por qué. Estructura de módulos. Fases de implementación. Dependencias entre componentes. Riesgos identificados.

    No es un documento académico — es el registro de las decisiones que tomarías antes de empezar, aunque fueran en tu cabeza. Externalizar ese razonamiento tiene valor: el agente lo usa como referencia durante la implementación, y tú lo usas para hacer review.

    tasks.md — La lista ordenada para TDD

    Las tareas están ordenadas para Test-Driven Development. Los tests de los contratos del sistema van primero. El código que los satisface, después. Cada tarea es atómica — una sola responsabilidad, verificable por sí sola.

    Cuando tienes esta lista, puedes darle una tarea al agente y pedirle que haga solo esa. Sin divagar. Sin añadir “mejoras” que no pediste. La tarea acotada, con su test, con su criterio de aceptación.

    Esta es exactamente la forma de trabajar que desarrollamos en el curso Construye con IA — de la idea al producto real, con agentes IA y sin perder el control del código.

    Cuándo NO usar sdd-creator

    sdd-creator añade valor cuando el problema tiene suficiente complejidad para merecer una especificación. Hay casos donde el overhead no compensa:

    • Scripts de un solo uso: automatizaciones de 20-30 líneas que se ejecutan una vez y se descartan
    • Prototipos desechables: experimentos para validar si algo es técnicamente posible, sin intención de iterar sobre el código
    • Hotfixes triviales: corregir un typo, cambiar un color, ajustar un literal de texto

    La regla práctica: si el feature va a producción y va a ser mantenido, usa sdd-creator. Si es exploración o descarte, ve directo al código.

    Compatible con cualquier agente de IA

    sdd-creator no está atado a un agente específico. Funciona con todos los entornos de desarrollo con IA más usados:

    Agente Tipo de integración Directorio
    Claude Code Skills nativo ~/.claude/skills/
    Cursor Rules .cursor/rules/ del proyecto
    Codex CLI (OpenAI) AGENTS.md / system prompt Configuración de proyecto
    Gemini CLI System prompt Configuración de proyecto
    Aider Contexto personalizado .aider.conf.yml
    Continue config.json .continue/

    El formato MIT también significa que puedes adaptarlo a tu equipo. Si tienes convenciones de nomenclatura propias, o secciones adicionales en tus specs, puedes forkear el repositorio y ajustarlo.

    FAQ

    ¿Qué es sdd-creator?

    sdd-creator es un skill para agentes de IA que implementa el flujo de Spec-Driven Development. Cuando lo activas, el agente no escribe código directamente — primero te hace una entrevista para entender el problema, luego genera tres documentos estructurados (spec.md, plan.md, tasks.md), y solo después implementa. Es la diferencia entre darle instrucciones a un agente y darle una especificación.

    ¿Con qué agentes de IA funciona sdd-creator?

    Con Claude Code, Cursor, Codex CLI (OpenAI), Gemini CLI, Aider y Continue. El skill es un archivo de instrucciones, no una integración específica — cualquier agente que soporte archivos de contexto puede usarlo. La instalación varía: en Claude Code se copia a ~/.claude/skills/, en Cursor va a .cursor/rules/.

    ¿Cuánto tiempo lleva generar la spec con sdd-creator?

    Entre 5 y 20 minutos, dependiendo de la complejidad del feature. Una feature simple puede especificarse en 5 minutos. Una feature con múltiples flujos, integraciones externas y requisitos de seguridad puede tomar 20. Ese tiempo es siempre menor que el que cuesta refactorizar código que el agente implementó sin especificación.

    ¿Es sdd-creator compatible con proyectos legacy?

    Sí. SDD no requiere empezar desde cero — puedes aplicarlo feature a feature sobre una base de código existente. El spec refleja las restricciones reales del sistema existente: qué puedes cambiar, qué no, y qué deuda técnica tienes que tener en cuenta durante la implementación.

    ¿Puedo usar sdd-creator en equipos?

    Sí, y es donde más valor aporta. El spec.md generado es el contrato de la feature — cualquier miembro del equipo puede revisarlo, cuestionarlo y aprobarlo antes de que empiece la implementación. Elimina el “yo entendí que…” de las reuniones de review.

    Ahora, cuando tengo el agente abierto y las ganas de construir, lo primero que activo es sdd-creator. Los 15 minutos de spec se pagan solos. Esas tres horas de JWT no se van a repetir.

    Si quieres ver cómo SDD encaja en el ciclo completo de desarrollo con IA — desde la idea hasta el producto desplegado — en Dominicode Labs tienes acceso a proyectos reales donde aplicamos este flujo de principio a fin.

    Por Bezael Pérez — Fundador de Dominicode.

  • Plan, Steer, Decompose: el framework de agentic engineering

    Plan, Steer, Decompose: el framework de agentic engineering

    Llevaba tres horas con el agente.

    Tres horas corrigiendo. El agente seguía haciendo lo mismo: tomaba decisiones razonables para el contexto que tenía, pero el contexto que tenía era incompleto desde el principio. Yo le daba feedback, él ajustaba, y en la siguiente iteración el problema aparecía en otro sitio. Dos pasos adelante, uno y medio atrás.

    No era el modelo. Era yo — y el problema era la ausencia de agentic engineering en mi flujo de trabajo.

    No había planificado lo que quería construir antes de empezar. No había descompuesto el problema en piezas que el agente pudiera manejar sin ambigüedad. Le había dado un objetivo vago y esperado que el agente lo resolviera. Y el agente hacía lo que podía — que no era suficiente para lo que yo necesitaba.

    Eso es lo que diferencia a alguien que usa agentic engineering de alguien que simplemente le pide cosas a la IA: un framework de trabajo. Un ciclo operativo que convierte la delegación caótica en colaboración sistemática.

    El framework tiene cinco pasos: Plan → Steer → Decompose → Delegate → Systematize.

    El agentic engineering es la disciplina de orquestar agentes de IA de forma sistemática — definiendo objetivos, descomponiendo problemas, delegando tareas con el contexto preciso y capturando los patrones que funcionan para reutilizarlos. Es la diferencia entre usar la IA como herramienta de texto y tratarla como un sistema de producción.

    Por qué el prompting no es suficiente

    Hay un malentendido que veo constantemente en developers que llevan meses usando IA sin resultados consistentes: creen que el problema es el prompt.

    Mejoran el prompt. Añaden más contexto. Usan few-shot examples. Prueban otro modelo. Y los resultados mejoran marginalmente pero el problema de fondo persiste — siguen obteniendo outputs que tienen que reescribir, completar o corregir antes de poder usar.

    El problema no es el prompt. Es que no hay agentic engineering en el proceso — están tratando al agente como un oráculo al que preguntas. Y los oráculos funcionan bien para respuestas, no para construcción.

    Construir con IA no es preguntar. Es orquestar. Y orquestar requiere un proceso, no una técnica de redacción.

    El framework de agentic engineering: los 5 pasos

    Paso Objetivo Señal de que lo estás haciendo bien
    Plan Define qué construir antes de abrir el editor Tienes objetivo, contexto y criterios de éxito escritos
    Steer Guía la dirección durante la ejecución Intervienes en los puntos de decisión, no en cada acción
    Decompose Rompe el problema en tareas atómicas y verificables Cada tarea tiene bordes claros, sin decisiones implícitas
    Delegate Asigna la tarea correcta con el contexto mínimo necesario El agente no necesita hacer preguntas para empezar
    Systematize Convierte lo que funciona en proceso repetible Tienes CLAUDE.md, templates y hooks activos

    1. Plan — Define antes de abrir el editor

    El Plan no es el prompt inicial. Es la decisión de qué quieres construir, para quién, con qué criterios de éxito, y qué contexto necesita el agente para no tener que improvisar.

    La mayoría de los problemas de agentic engineering empiezan aquí — o mejor dicho, por saltarse este paso.

    Cuando no hay Plan, el agente trabaja con hipótesis. Asume el stack que le parece más probable. Asume la arquitectura que ha visto más en su entrenamiento. Asume que los casos edge no existen porque no se los mencionaste. Y esas hipótesis se propagan a través de todo el trabajo posterior.

    Un Plan mínimo tiene tres elementos:

    Objetivo concreto — No "implementa el módulo de usuarios". Sí: "Implementa el endpoint POST /users que recibe { email, name }, valida con Zod, crea el registro en la tabla users de Supabase y devuelve { id, email, createdAt }. Error 409 si el email ya existe."

    Contexto relevante — El stack, las convenciones de naming que ya usa el proyecto, las decisiones de arquitectura tomadas, las restricciones conocidas. Esto es lo que va en el CLAUDE.md del proyecto — no como documentación, sino como memoria estructurada que el agente lee al inicio de cada sesión.

    Criterios de éxito — Cómo sabes que el agente terminó bien su trabajo. Tests que deben pasar. Comportamientos que debes poder demostrar. Sin criterios de éxito explícitos, "listo" significa cosas distintas para ti y para el agente.

    El Spec-Driven Development es la metodología que formaliza este paso: especificar el sistema antes de construirlo, con contratos concretos que el agente puede implementar sin inventar.

    2. Steer — Guías la dirección, no desapareces

    El Steer es el feedback loop activo durante la ejecución.

    Hay un patrón que veo repetidamente: el developer escribe un prompt elaborado, lanza el agente y vuelve veinte minutos después esperando encontrar la tarea completada. A veces funciona. Cuando no funciona, el agente ha pasado esos veinte minutos construyendo en la dirección equivocada con mucha confianza.

    Steer no significa microgestionar. Significa estar presente en los puntos de decisión que importan.

    La señal de que necesitas intervenir: el agente está a punto de tomar una decisión con consecuencias amplias sin haber pedido confirmación. Cambiar la estructura de un módulo. Renombrar una abstracción clave. Elegir entre dos arquitecturas posibles. Esos son los momentos en que tu presencia tiene más palanca.

    En práctica, Steer implica:

    • Revisar el output de las primeras iteraciones antes de que el agente avance demasiado
    • Corregir la dirección cuando el agente toma una decisión incorrecta — y hacerlo en el momento, no cuando ya hay diez archivos afectados
    • Hacer preguntas explícitas al agente sobre sus decisiones: "¿Por qué elegiste este enfoque sobre el alternativo?" — no para cuestionar todo, sino para verificar que el razonamiento es el correcto antes de comprometerte con esa dirección

    El objetivo del Steer no es hacer el trabajo del agente. Es hacer que el agente haga el trabajo correcto. Sin Steer, el agentic engineering se convierte en delegación ciega — y la delegación ciega escala los errores, no los resultados.

    3. Decompose — Rompe el problema en tareas atómicas

    La Decompose es donde más se gana en calidad de output y donde menos developers invierten tiempo.

    Un agente que recibe "implementa el sistema de autenticación completo" toma demasiadas decisiones implícitas. Qué estrategia de sesiones. Qué campos en el token. Cómo manejar el refresh. Qué pasa cuando el token expira durante una request. Cada una de esas decisiones tiene consecuencias, y el agente las toma sin consultarte porque no sabe que importan.

    La descomposición transforma decisiones implícitas en decisiones explícitas.

    Una tarea bien descompuesta tiene estas características:

    Atómica — Se puede completar en una sola sesión sin depender de otras tareas que no estén terminadas.

    Sin ambigüedad en los bordes — Define qué entra, qué sale y cómo interactúa con lo que ya existe. "Implementa el endpoint de login que recibe { email, password } y devuelve { accessToken, refreshToken, user } usando el servicio AuthService ya existente" — eso es una tarea sin ambigüedad en los bordes.

    Verificable — Al terminar puedes saber con certeza si la tarea está bien hecha o no. Si no puedes verificar, la tarea está mal definida.

    // Tarea mal definida — demasiado scope, demasiadas decisiones implícitas
// "Implementa el sistema de autenticación con JWT y manejo de sesiones"

// Tarea bien definida — atómica, verificable, bordes claros
// "Implementa la función generateTokenPair(userId: string): Promise<TokenPair>
// que genera accessToken (15min) y refreshToken (7d) firmados con RS256.
// TokenPair = { accessToken: string; refreshToken: string; expiresAt: Date }
// Usa la clave privada de process.env.JWT_PRIVATE_KEY.
// Test: genera un par, verifica que accessToken expira correctamente."

    La diferencia no está en la complejidad. Está en quién toma las decisiones.

    4. Delegate — Asigna al agente correcto con el contexto mínimo necesario

    Delegate es donde muchos developers confunden prompt engineering con delegación real.

    Prompt engineering es refinar las instrucciones para obtener un output mejor del mismo agente. La delegación dentro del agentic engineering es asignar la tarea correcta al agente correcto con el contexto que necesita para ejecutarla — ni más ni menos.

    Dos errores opuestos destruyen la delegación:

    Delegación sin contexto suficiente. El agente no tiene acceso a las decisiones de arquitectura previas, no conoce las convenciones del proyecto, no sabe qué existe ya. El resultado es código que no encaja — funcionalmente correcto, arquitecturalmente incorrecto.

    Delegación con contexto excesivo. Pegas en el prompt el README completo, los últimos cinco commits, tres archivos relacionados y la descripción del sistema entero. El modelo procesa todo ese contexto pero el ruido diluyente reduce la precisión. Más contexto no siempre es mejor contexto.

    El contexto mínimo necesario es el que responde a: ¿qué necesita saber el agente para tomar las mismas decisiones que yo tomaría? No el contexto que me tranquiliza a mí — el que necesita el agente.

    En Claude Code esto se traduce en ser deliberado sobre qué archivos mencionas explícitamente (@auth.service.ts, @user.schema.ts) y qué instrucciones incluyes en el CLAUDE.md del proyecto para que estén disponibles en cada sesión sin tener que repetirlas.

    5. Systematize — Lo que funciona una vez se convierte en proceso

    El Systematize es el paso que separa a los developers que mejoran semana a semana de los que repiten los mismos errores en cada proyecto nuevo.

    Cuando un flujo de trabajo de agentic engineering funciona bien — un tipo de tarea, un patrón de prompt, una estructura de descomposición — el Systematize lo captura como proceso reutilizable. No como documentación que nadie leerá. Como artefacto operativo que puedes invocar directamente.

    Tres formas concretas de systematizar:

    CLAUDE.md por proyecto — Las decisiones de arquitectura, las convenciones, las restricciones del proyecto. Este archivo es la memoria del proyecto que persiste entre sesiones. Sin él, cada sesión nueva parte de cero.

    Templates de tareas — Si descompones el mismo tipo de problema una y otra vez (endpoints REST, componentes Angular, tests de integración), el template captura la estructura de descomposición que ya demostró funcionar. No vuelves a pensar cómo descomponer — aplicas el template y ajustas los detalles.

    Hooks y workflows — En Claude Code, los hooks de PreToolUse y PostToolUse permiten ejecutar validaciones automáticas antes o después de que el agente actúe. Un hook que ejecuta tsc --noEmit antes de cada escritura de archivo previene que el agente introduzca errores de tipos que luego tienes que depurar a mano. Automatizas la verificación, no solo la generación.

    // .claude/settings.json — hook que valida TypeScript antes de escribir
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit 2>&1 | head -20"
          }
        ]
      }
    ]
  }
}

    El Systematize convierte el conocimiento tácito en proceso explícito. Y el proceso explícito escala — a proyectos futuros, a otros developers del equipo, a agentes que ejecutan workflows sin supervisión.

    Cómo se conectan los 5 pasos en un ciclo

    Los cinco pasos del agentic engineering no son lineales. Son un ciclo que se repite a dos escalas.

    Escala de proyecto:

    • Una vez al inicio: Plan global
    • Primera Decompose en bloques grandes
    • Primera ronda de Delegate al agente
    • Steer durante la ejecución
    • Systematize los patrones que funcionaron para el siguiente proyecto

    Escala de tarea:

    • Plan de la tarea concreta
    • Decompose en subtareas si es necesario
    • Delegate al agente con el contexto mínimo
    • Steer durante la ejecución
    • Systematize si el patrón vale la pena capturar

    Lo que conecta los dos niveles es el contexto acumulado. Cada Systematize en una tarea pequeña alimenta el Plan del bloque siguiente. El CLAUDE.md que actualizas después de cada sesión hace que la siguiente sesión parta de un estado mejor que la anterior.

    El ciclo se mejora a sí mismo. Eso es lo que distingue un sistema de una técnica.

    Aplica el framework construyendo un producto real

    Leer el framework es útil. Aplicarlo en un proyecto real con presión de tiempo y decisiones concretas es lo que lo hace tuyo.

    El Workshop Beyond Prompts (https://workshop.dominicode.com/) del 9 de julio es exactamente eso: 3 horas donde aplicamos el agentic engineering construyendo un producto real con Claude Code — de idea a producto deployado usando Plan → Steer → Decompose → Delegate → Systematize en vivo. No es una clase magistral. Es una sesión de trabajo donde tomas decisiones, te equivocas, corriges y sales con un sistema que puedes replicar.

    Si quieres prepararte antes del workshop, el curso Construye con IA: de la idea al producto con Claude Code cubre los fundamentos de agentic engineering con el mismo enfoque: criterio para cada decisión, no solo instrucciones que seguir.

    Y si quieres trabajar el framework con proyectos concretos en comunidad — revisar tu arquitectura, discutir las decisiones que no están claras, ver cómo otros developers aplican estos pasos — en Dominicode Labs hacemos exactamente eso semana a semana.

    FAQ

    ¿Cuál es la diferencia entre el agentic engineering y el Spec-Driven Development?

    SDD es la metodología que cubre en detalle el paso Plan — cómo especificar un sistema antes de construirlo, con contratos y criterios de éxito concretos. El framework de agentic engineering Plan → Steer → Decompose → Delegate → Systematize es más amplio: cubre todo el ciclo de trabajo con agentes, desde antes de escribir la spec hasta capturar los patrones que funcionaron para reutilizarlos. SDD y agentic engineering son complementarios — SDD es la respuesta detallada a "cómo hacer bien el Plan".

    ¿El agentic engineering funciona con cualquier herramienta de IA o solo con Claude Code?

    Los cinco pasos son agnósticos a la herramienta. La lógica de Plan, Steer, Decompose, Delegate y Systematize aplica igual si usas Claude Code, Cursor, Copilot o la API directamente. Lo que cambia son los artefactos concretos: en Claude Code el contexto persistente vive en CLAUDE.md y los hooks en .claude/settings.json; en Cursor vive en .cursor/rules/; en otros entornos en AGENTS.md. El framework es la estructura. Los artefactos son la implementación específica de cada herramienta.

    ¿Cuánto tiempo tarda implementar este framework en un proyecto que ya existe?

    Para un proyecto existente sin ningún sistema, el mínimo viable —un CLAUDE.md básico con el stack y las convenciones principales, más una primera descomposición del backlog pendiente— tarda entre dos y cuatro horas. No es un proceso de migración completa. Es añadir las piezas que hacen que cada sesión futura sea más efectiva que las anteriores. El Systematize es acumulativo — mejora con el tiempo, no requiere estar completo desde el día uno.

    ¿El paso Steer no anula el beneficio de la autonomía del agente?

    No. Steer es intervención en los puntos de decisión de alto impacto, no supervisión constante de cada acción. Un agente ejecutando tareas bien definidas puede trabajar durante decenas de ciclos sin necesitar tu input — eso es autonomía real. Steer te pide que estés presente cuando el agente enfrenta una bifurcación arquitectural, no cuando está implementando un endpoint que ya tiene todos los criterios claros. La diferencia práctica: Steer activo tarda minutos por sesión. Steer ausente puede costar horas de corrección cuando el agente ha tomado veinte decisiones incorrectas en cadena.

    ¿Por dónde empiezo si nunca he trabajado de forma estructurada con agentes?

    Empieza por el Plan y el Decompose. Son los dos pasos del agentic engineering que más impacto tienen en la calidad del output y los que más developers saltan. Coge una tarea concreta de tu backlog y antes de lanzar el agente escribe: objetivo específico, contexto relevante y criterios de éxito. Luego divídela en subtareas que tengan bordes claros. Esas dos prácticas solas van a mejorar notablemente la calidad de lo que obtienes. El resto del framework puedes añadirlo gradualmente.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Cómo automatizar usabilidad con agentes de IA en tu app

    Cómo automatizar usabilidad con agentes de IA en tu app

    Un cliente me enseñó su aplicación de onboarding hace unos meses. Cinco pasos. Diseño limpio. Todo funcional en los tests.

    La tasa de abandono era del 68% en el paso tres.

    Revisamos los tests de integración: pasaban todos. El formulario enviaba datos correctamente. La validación funcionaba. El CI estaba en verde. Y aun así, casi siete de cada diez usuarios salían del flujo antes de terminar.

    El problema no era que la aplicación no funcionara. Era que nadie había auditado cómo se usaba.

    Ahí está la diferencia que muchos developers no distinguen hasta que lo ven en métricas reales: una cosa es que el código haga lo que debe, y otra muy distinta es que el usuario pueda usarlo sin fricción. La primera la resuelves con tests. La segunda la resuelves con automatizar usabilidad con agentes de IA — que es exactamente lo que vamos a ver aquí.

    Automatizar usabilidad con agentes de IA consiste en delegar la auditoría de accesibilidad, flujos de usuario y fricciones de interfaz a un agente — como Claude Code con MCP de Playwright — que controla el navegador de forma programática, navega flujos reales y genera un reporte estructurado de hallazgos sin intervención manual.

    Testing funcional vs. testing de usabilidad

    Un test funcional pregunta: ¿el botón de "Enviar" llama a la función correcta?

    Un test de usabilidad pregunta: ¿el usuario sabe que tiene que hacer clic ahí? ¿Lo ve? ¿Entiende qué va a pasar después?

    Son preguntas distintas y se responden con herramientas distintas.

    Los tests funcionales los escribes tú, los corre un CI, comprueban comportamiento esperado. Eso ya lo sabes hacer. Lo que un agente de IA aporta es la capacidad de navegar tu aplicación como si fuera un usuario — explorar rutas no documentadas, detectar elementos sin etiquetas accesibles, medir cuánto tarda en responder una pantalla, o identificar que un campo de error aparece debajo del scroll y el usuario nunca lo ve.

    No te reemplaza un test de usabilidad con personas reales. Pero te da un nivel de auditoría automatizada que antes no existía — y que tú nunca harías manualmente en cada PR. Si quieres ver cómo encaja esto en un pipeline completo de desarrollo, tienes la explicación en el post sobre automatizar el proceso de desarrollo con IA.

    Qué puede detectar un agente

    Cuando conectas Claude Code con el MCP de Playwright o Chrome DevTools, el agente puede controlar el navegador de forma programática. Eso significa que puede:

    • Navegar a cualquier ruta de tu aplicación
    • Hacer clic en elementos, rellenar formularios, desplazarse por la página
    • Leer el DOM y el árbol de accesibilidad (el que usa un lector de pantalla)
    • Medir tiempos de respuesta entre interacciones
    • Ejecutar axe-core para detectar violaciones WCAG
    • Capturar screenshots en cada paso del flujo
    • Generar un reporte estructurado con los hallazgos

    Lo que un agente detecta bien:

    1. Accesibilidad técnica: imágenes sin alt, botones sin aria-label, contraste insuficiente entre texto y fondo, formularios sin etiquetas asociadas, skip navigation ausente, foco de teclado atrapado en un componente modal.
    2. Fricciones estructurales: mensajes de error fuera del viewport, campos obligatorios que no se identifican como tales hasta el submit, pasos de onboarding que no guardan el progreso si el usuario recarga.
    3. Performance percibida: cuánto tarda en aparecer el primer elemento interactivo después de una navegación, si hay loaders sin indicación de progreso, si el layout shift hace que el usuario haga clic en el elemento equivocado.
    4. Cobertura de flujos: si una ruta de error (credenciales incorrectas, sesión expirada, red caída) termina en una pantalla sin instrucciones claras.

    Cómo configurar el agente para automatizar la auditoría de usabilidad

    La combinación que funciona en producción: Claude Code + MCP de Playwright.

    Para instalarlo: npx @playwright/mcp@latest. Una vez activo en tu configuración de Claude Code, el agente tiene acceso a las herramientas de control del navegador sin que escribas una línea de Playwright.

    El MCP de Playwright expone herramientas al agente para controlar el navegador: browser_navigate, browser_click, browser_type, browser_snapshot, browser_evaluate. Claude puede encadenar esas herramientas para ejecutar flujos completos.

    Un ejemplo de instrucción al agente para auditar el onboarding de una app:

    ## Tarea: Auditoría de usabilidad — flujo de onboarding

URL base: http://localhost:4200

Flujo a auditar:
1. Navega a /register
2. Rellena el formulario con datos válidos: nombre, email, contraseña
3. Haz clic en "Crear cuenta"
4. Completa los pasos del onboarding hasta llegar al dashboard

En cada paso:
- Captura un screenshot
- Extrae el árbol de accesibilidad del contenido principal
- Identifica elementos interactivos sin aria-label o sin texto visible
- Mide el tiempo hasta que el siguiente paso es interactivo
- Detecta si hay mensajes de error o advertencia y si son visibles sin scroll

Al terminar, genera un reporte en formato JSON con esta estructura:
{
  "paso": string,
  "url": string,
  "tiempo_carga_ms": number,
  "violaciones_accesibilidad": [],
  "fricciones_detectadas": [],
  "screenshot": string
}

    El agente ejecuta eso de forma autónoma. Navega, interactúa, observa, y vuelve con un reporte estructurado.

    Accesibilidad automática con axe-core

    Para violaciones WCAG, la integración más sólida es axe-core. El agente puede ejecutarlo sobre cualquier página activa en el navegador mediante browser_evaluate:

    // Si axe-core no está en el bundle de la app, inyectarlo primero:
// await page.addScriptTag({ url: 'https://cdn.jsdelivr.net/npm/axe-core/axe.min.js' });

// Ejecutar la auditoría en el contexto de la página
const results = await axe.run();
return {
  violaciones: results.violations.map(v => ({
    impacto: v.impact,
    descripcion: v.description,
    elementos: v.nodes.map(n => n.target)
  }))
};

    Lo que devuelve axe-core son violaciones categorizadas por impacto: critical, serious, moderate, minor. El agente puede filtrar solo las críticas, agregar el selector del elemento afectado, y generar una lista accionable para el developer.

    Esto detecta cosas como:

    • Contraste de color insuficiente (ratio menor a 4.5:1 para texto normal)
    • Imágenes sin atributo alt o con alt vacío en imágenes informativas
    • Elementos <div> y <span> usados como botones sin rol ARIA
    • Formularios sin <label> asociado o con placeholder como único identificador
    • Encabezados fuera de jerarquía (<h4> después de <h2> sin <h3>)

    Esta es una de las capacidades que trabajamos en detalle en el curso Construye con IA: cómo delegar auditorías estructuradas al agente para que el developer se centre en las decisiones de producto, no en el checklist técnico.

    El reporte de hallazgos

    Un agente que navega y detecta problemas no sirve de nada si los hallazgos terminan en un log de consola que nadie lee.

    El formato que mejor funciona para integrar en un workflow de desarrollo es un JSON estructurado que puedas convertir en un issue de GitHub, una tarea en Linear, o un comentario en un PR.

    Estructura mínima de reporte que el agente genera:

    {
  "auditoria": {
    "fecha": "2026-06-17",
    "url_base": "https://app.ejemplo.com",
    "flujo": "onboarding",
    "duracion_total_ms": 8420
  },
  "resumen": {
    "violaciones_criticas": 3,
    "violaciones_serias": 7,
    "fricciones_detectadas": 4,
    "pasos_con_retraso": 2
  },
  "hallazgos": [
    {
      "paso": "registro",
      "tipo": "accesibilidad",
      "impacto": "critical",
      "descripcion": "Campo de contraseña sin label asociado. Solo usa placeholder.",
      "selector": "#password-input",
      "referencia_wcag": "1.3.1"
    },
    {
      "paso": "paso-2-perfil",
      "tipo": "friccion",
      "impacto": "serious",
      "descripcion": "Mensaje de validación aparece 280px por debajo del campo en mobile. No visible sin scroll.",
      "selector": ".validation-message",
      "screenshot": "paso-2-error-state.png"
    }
  ]
}

    Este reporte lo puedes consumir directamente en tu pipeline de CI, enviarlo a un webhook de Slack, o procesarlo con otro agente que abra los issues correspondientes.

    Agentes IA vs Lighthouse

    Capacidad Lighthouse Agente IA + MCP Playwright
    Métricas de rendimiento (LCP, CLS, FID) ✅ ❌
    Accesibilidad estática (axe-core) ✅ ✅ más granular
    Flujos interactivos multipaso ❌ ✅
    Estados de error y modales ❌ ✅
    Reporte adaptado al contexto del proyecto ❌ ✅ JSON estructurado
    Requiere código de automatización ❌ ❌ lenguaje natural
    Integración en CI/CD ✅ ✅

    Lighthouse mide el estado de una página en un instante. Un agente mide cómo un usuario real la recorre.

    Lo que el agente no puede hacer

    Esto es importante. Un agente mide lo que puede observar en el DOM y en el comportamiento de la interfaz. No puede medir lo que ocurre dentro del usuario.

    No detecta:

    • Frustración emocional. Si el flujo es técnicamente correcto pero genera ansiedad porque el lenguaje es frío o las instrucciones son ambiguas, el agente no lo sabe.
    • Preferencias estéticas. El contraste puede pasar el ratio WCAG y aun así resultar incómodo visualmente en contextos específicos.
    • Contexto cultural. Un ícono que es intuitivo para un usuario europeo puede no serlo para un usuario latinoamericano. El agente no tiene ese mapa cultural.
    • Carga cognitiva subjetiva. Puede detectar que hay ocho campos en un formulario, pero no puede decirte si eso es demasiado para tu audiencia específica.
    • Microcopy y confianza. El texto de un CTA puede ser técnicamente legible y aun así no generar suficiente confianza para que el usuario haga clic.

    Esas decisiones siguen siendo tuyas — o del diseñador, o del researcher de UX. Lo que el agente elimina es el trabajo de auditoría técnica repetitiva que de otra forma no harías en cada ciclo de desarrollo.

    Cómo integrarlo en tu workflow

    El patrón que funciona sin complicar el pipeline:

    1. Local, bajo demanda: el developer lanza la auditoría sobre la rama antes de abrir el PR. El agente revisa el flujo afectado por el cambio.
    2. En CI, sobre entornos de preview: cada PR despliega a un entorno de preview (Vercel, Netlify, Railway), y el agente audita ese entorno de forma automática antes del merge.
    3. Semanal, sobre producción: un job programado lanza la auditoría completa sobre la app en producción y genera un reporte que llega al equipo.

    El tercer nivel es el más valioso a largo plazo: detecta regresiones de accesibilidad que se cuelan en producción sin que nadie las vea en los tests unitarios.

    El paso de code review automático antes del PR — que complementa esta auditoría de usabilidad — lo explico en detalle en el post sobre agentic code review con Claude Code.

    Si quieres ver cómo construir este tipo de pipelines con agentes desde cero, en Dominicode Labs tenemos proyectos completos que aplican exactamente este enfoque — desde la configuración del MCP hasta la generación del reporte final.

    FAQ

    ¿Necesito conocer Playwright para esto?
    No necesitas escribir código Playwright. El MCP abstrae las herramientas de control del navegador y el agente las usa directamente. Basta con que describas el flujo que quieres auditar en lenguaje natural.

    ¿axe-core cubre todos los criterios WCAG?
    Cubre los criterios que son detectables automáticamente — menos de la mitad de los criterios de WCAG 2.1. El resto requiere evaluación humana. Pero ese 30-40% incluye los problemas más comunes y los más graves.

    ¿El agente puede auditar aplicaciones con autenticación?
    Sí. Puedes darle al agente las credenciales de una cuenta de prueba, o configurar el MCP para que arranque el navegador con una sesión ya autenticada. El agente navega como un usuario real, incluyendo el flujo de login.

    ¿Qué diferencia hay entre esto y Lighthouse?
    Lighthouse audita métricas de performance, SEO básico y accesibilidad en un snapshot estático. Un agente con MCP de Playwright puede auditar flujos interactivos completos — formularios multipaso, modales, estados de error, interacciones con el teclado — y generar reportes adaptados a tu contexto específico, no a un checklist genérico.

    ¿Puedo usar esto con cualquier framework frontend?
    Sí. El agente interactúa con el navegador, no con el framework. Funciona igual con Angular, React, Vue o cualquier app renderizada en el cliente o en el servidor.

    La próxima vez que un cliente te muestre métricas de abandono con todos los tests en verde, ya sabes qué está pasando — y cómo resolverlo.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Mejor modelo LLM local en 2026: ranking y configuración

    Mejor modelo LLM local en 2026: ranking y configuración

    Hace unos meses un developer de la comunidad me preguntó algo que parecía sencillo: "Bezael, ¿qué modelo instalo en local?". Me tardé más en responder de lo que debería porque la respuesta honesta no es un nombre — es una pregunta de vuelta: ¿para qué?

    Un modelo LLM local es un modelo de lenguaje que corre enteramente en tu máquina, sin enviar datos a servidores externos ni depender de una API de pago. Elegir el mejor modelo LLM local en junio de 2026 depende de si escribes código, procesas documentos largos, necesitas razonamiento complejo o simplemente quieres un asistente offline que no te cueste un euro al mes. En 2026 la calidad de los modelos open source ha cerrado la brecha con los modelos cloud de forma dramática — y en este ranking te doy mis recomendaciones concretas con configuración paso a paso.

    Por qué correr modelos en local en 2026

    La razón número uno ya no es el coste. Es el control.

    Cuando mandas un prompt a OpenAI, Anthropic o Google estás mandando tus datos a un servidor externo bajo sus términos de servicio. Para prototipado personal eso no importa. Pero si trabajas con código propietario de un cliente, documentos legales, datos médicos o cualquier información sensible, eso es un problema real — contractual y a veces legal.

    Los modelos en local resuelven eso de raíz: los datos nunca salen de tu máquina.

    Además hay dos casos de uso donde local gana sin discusión:

    Iteración sin fricción. Durante el prototipado puedo hacer mil llamadas al día probando prompts, ajustando pipelines, explorando comportamientos del modelo. Con una API de pago eso se acumula. En local, es gratis. En los proyectos que construyo en el curso de Construye con IA, usamos modelos locales para todo el desarrollo y solo movemos llamadas críticas a cloud cuando el producto llega a producción con usuarios reales.

    Disponibilidad total. Sin límites de rate. Sin outages del proveedor. Sin latencia de red. Si construyes herramientas de developer experience internas, un servidor con Ollama es más predecible que cualquier API externa.

    Las herramientas de runtime: Ollama primero, el resto después

    Antes de hablar de modelos, necesitas una herramienta para correrlos. Hay tres opciones principales en 2026.

    Ollama — el estándar para developers

    Ollama es la herramienta que uso y la que recomiendo sin reservas si eres developer. Es una CLI + servidor HTTP que gestiona la descarga, cuantización y ejecución de modelos como si fueran imágenes Docker. Un comando para descargar, otro para correr, y una API REST disponible en localhost:11434 lista para integrar en cualquier stack.

    Lo que lo hace especialmente útil: su API es compatible con el formato de OpenAI. Eso significa que puedes apuntar tu código existente a Ollama cambiando solo la baseURL.

    LM Studio — para exploración visual

    LM Studio es la alternativa con UI. Tiene un explorador de modelos, un chat visual y un servidor local compatible con OpenAI. Ideal para probar modelos sin escribir una línea de código o para mostrarlos a stakeholders. No es mi herramienta principal de trabajo, pero la uso para comparar modelos rápidamente.

    llama.cpp — para control máximo

    llama.cpp es el motor que hay debajo de Ollama. Si necesitas control granular sobre la cuantización, el número de capas que van a GPU, o quieres empaquetar un modelo en una aplicación nativa, llama.cpp es el camino. Tiene una curva de entrada más alta pero es el runtime más eficiente disponible.

    Para el 90% de los casos: Ollama. Es lo que cubre el resto de este post.

    Requisitos de hardware: la realidad sin marketing

    Antes de descargar nada, necesitas saber qué puede correr tu máquina.

    La variable crítica es la RAM disponible (RAM del sistema o VRAM de GPU). Un modelo cuantizado a Q4 ocupa aproximadamente 0.5 GB por cada mil millones de parámetros más un margen de contexto. Un modelo de 8B a Q4_K_M necesita unos 5-6 GB.

    Tu hardware Qué puedes correr Velocidad esperada
    8 GB RAM, sin GPU dedicada Modelos 3B–4B (Q4) Lento pero funcional (~3-5 tok/s)
    16 GB RAM / 8 GB VRAM Modelos 7B–8B (Q4) Buena para uso diario (~15-30 tok/s)
    32 GB RAM / 12-16 GB VRAM Modelos 13B–14B (Q4) Muy buena (~20-40 tok/s)
    64 GB RAM / 24 GB VRAM Modelos hasta 32B (Q4) Excelente
    Apple Silicon M2/M3 16GB Modelos hasta 13B (Q4) Muy buena (memoria unificada)
    Apple Silicon M3 Max 48GB+ Modelos 34B–70B (Q4) Sorprendentemente buena

    Una nota sobre Apple Silicon: la memoria unificada cambia el juego. Un MacBook Pro M3 Pro con 36 GB puede correr un modelo de 30B con una velocidad que en una PC requeriría una GPU de cuatro mil euros.

    Si tienes una NVIDIA RTX 3090 o 4090 (24 GB VRAM), puedes correr modelos de hasta 30B enteramente en GPU, lo que es la experiencia de inferencia más rápida que vas a tener en local.

    El mejor modelo LLM local para cada caso (junio 2026): mis recomendaciones reales

    Aquí está mi opinión directa. No es la lista más larga — es la más útil.

    Para código: Qwen3 8B — el que instalo primero

    Qwen3 de Alibaba es el modelo de código open source más sólido disponible en local a día de hoy. La variante de 8B parámetros supera a modelos mucho más grandes en benchmarks de programación (SWE-bench, HumanEval), y en uso real genera TypeScript, Python y código de infraestructura con una precisión que hace seis meses solo veías en GPT-4.

    Soporta más de 29 idiomas de forma nativa, tiene modo de razonamiento activable (thinking mode) y un contexto de hasta 256K tokens. Para trabajar con código de producción en local, es mi primera elección.

    ollama pull qwen3:8b

    Si tienes más RAM, la variante de 14B da un salto de calidad significativo:

    ollama pull qwen3:14b

    Para razonamiento: DeepSeek-R1 14B

    DeepSeek-R1 es el modelo de razonamiento open source por excelencia. Usa chain-of-thought interno antes de responder, lo que lo hace especialmente bueno para problemas que requieren múltiples pasos de lógica: debugging complejo, análisis de arquitectura, decisiones técnicas con trade-offs.

    La variante de 14B cabe cómodamente en una máquina con 16 GB de RAM.

    ollama pull deepseek-r1:14b

    Advertencia honesta: DeepSeek-R1 es más lento que Qwen3 porque piensa antes de responder. Ese thinking visible es un feature, no un bug — pero si necesitas velocidad para autocompletado de código, no es tu modelo.

    Para uso general y agentes: Llama 4 Scout

    Meta lanzó Llama 4 Scout en abril de 2026 y es una propuesta diferente: una arquitectura MoE (Mixture of Experts) con 17B parámetros activos sobre 109B totales, lo que significa que activa solo la parte del modelo que necesita para cada token. El resultado es eficiencia sin sacrificar calidad.

    Su característica más destacada es el contexto de 10 millones de tokens — literalmente puedes meterle una codebase completa en el contexto. Para tareas de análisis de proyectos grandes, revisión de PRs completos o procesamiento de documentos extensos, no hay nada comparable en local.

    Requiere unos 12-14 GB de VRAM para correr en GPU, o 24 GB de RAM para correr en CPU.

    ollama pull llama4:scout

    ⚠️ Licencia requerida: Llama 4 Scout necesita que aceptes la licencia de Meta en Hugging Face antes de descargarlo vía Ollama. Si el pull falla con error de autenticación, visita huggingface.co/meta-llama, acepta la licencia del modelo y vuelve a intentarlo.

    Para agentes y tool calling: Gemma 3 de Google

    Gemma 3 (marzo 2025) está diseñado específicamente para function calling y visión. Si construyes agentes que necesitan llamar herramientas, procesar imágenes o hacer structured output de forma fiable, Gemma 3 es la mejor opción local en su familia.

    La variante 27B es la que más me gusta para este caso de uso, pero la 12B ya da muy buenos resultados si tienes menos RAM disponible:

    ollama pull gemma3:12b
# variante más potente (requiere ~20 GB)
ollama pull gemma3:27b

    Para máquinas con poca RAM: Phi-4 Mini y Qwen3 4B

    Si tienes 8 GB de RAM o menos, o quieres algo que responda rápido para autocompletado, los modelos de 3B–4B son tu opción.

    Phi-4 Mini (Microsoft, 3.8B) tiene un rendimiento por encima de su tamaño en razonamiento y código. Es mi recomendación para máquinas limitadas.

    ollama pull phi4-mini

    Nota: Phi-4 Mini incluye thinking mode interno — produce cadenas de razonamiento antes de responder, lo que aumenta la latencia. Si necesitas velocidad para autocompletado, Qwen3 4B responde más rápido.

    Qwen3 4B es la opción cuando necesitas el mismo ADN de Qwen3 en un modelo pequeño, con modo thinking incluido:

    ollama pull qwen3:4b

    Tabla resumen

    Caso de uso Modelo recomendado RAM necesaria Comando
    Código (principal) Qwen3 8B 8-10 GB ollama pull qwen3:8b
    Código (mejor calidad) Qwen3 14B 10-12 GB ollama pull qwen3:14b
    Razonamiento complejo DeepSeek-R1 14B 10-12 GB ollama pull deepseek-r1:14b
    Contexto largo / análisis Llama 4 Scout 14-24 GB ollama pull llama4:scout
    Agentes y tool calling Gemma 3 12B 8-10 GB ollama pull gemma3:12b
    Máquinas con poca RAM Phi-4 Mini 4-6 GB ollama pull phi4-mini
    General rápido y ligero Qwen3 4B 4-6 GB ollama pull qwen3:4b

    Cómo configurar Ollama paso a paso

    1. Instalación

    macOS:

    brew install --cask ollama

    Linux:

    curl -fsSL https://ollama.com/install.sh | sh

    Windows:
    Descarga el instalador desde ollama.com/download. Se instala como servicio y arranca automáticamente al iniciar el sistema.

    Verifica que funciona:

    ollama --version

    2. Descargar y correr un modelo

    # Descargar y abrir chat interactivo
ollama run qwen3:8b

# Solo descargar (sin abrir chat)
ollama pull qwen3:8b

# Gestionar modelos
ollama list          # modelos descargados
ollama rm deepseek-r1:14b   # eliminar modelo
ollama show qwen3:8b        # info del modelo

    3. Usar la API REST

    Cuando Ollama está corriendo, expone una API en http://localhost:11434. La ruta /v1/chat/completions es compatible con el formato de OpenAI:

    curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "messages": [
      { "role": "user", "content": "Escribe un type guard TypeScript para User" }
    ]
  }'

    4. Cambiar el modelo por defecto o el puerto

    Ollama usa variables de entorno para configuración:

    # Exponer en todas las interfaces (para acceso desde red local)
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# Limitar los modelos cargados en memoria
OLLAMA_MAX_LOADED_MODELS=2 ollama serve

# Especificar cuántas capas van a GPU
OLLAMA_NUM_GPU=35 ollama serve

    En macOS y Linux puedes definir estas variables en /etc/systemd/system/ollama.service (Linux) o en la configuración del servicio (macOS).

    Integración con herramientas de desarrollo

    Continue.dev + VS Code — autocompletado local

    Continue.dev es la extensión que convierte VS Code en un asistente de código con Ollama como backend. Instala la extensión y modifica el archivo ~/.continue/config.yaml:

    models:
  - name: Qwen3 8B Local
    provider: ollama
    model: qwen3:8b
    roles:
      - chat
      - edit

  - name: Qwen3 4B Autocomplete
    provider: ollama
    model: qwen3:4b
    roles:
      - autocomplete

tabAutocompleteModel:
  name: Qwen3 4B Autocomplete
  provider: ollama
  model: qwen3:4b

    Con esta configuración tienes chat de código y autocompletado en línea usando modelos locales, sin mandar una sola línea de código a servidores externos.

    Integración desde código TypeScript

    La API de Ollama es compatible con el SDK de OpenAI. El patrón que más uso:

    import OpenAI from "openai";

const isLocal = process.env.USE_LOCAL_LLM === "true";

const client = new OpenAI({
  baseURL: isLocal
    ? "http://localhost:11434/v1"
    : "https://api.openai.com/v1",
  apiKey: isLocal ? "ollama" : process.env.OPENAI_API_KEY!,
});

const model = isLocal ? "qwen3:8b" : "gpt-4o-mini";

const response = await client.chat.completions.create({
  model,
  messages: [{ role: "user", content: prompt }],
});

    Con USE_LOCAL_LLM=true en tu .env de desarrollo, todo el tráfico va a Ollama. En producción, cambia la variable y apunta a tu proveedor cloud. Sin tocar una línea de lógica.

    FAQ

    ¿Cuál es el mejor modelo LLM local para empezar desde cero?

    El mejor modelo LLM local de entrada es Qwen3 8B: buena calidad en código y texto, compatible con 8-10 GB de RAM, y con la misma arquitectura que los modelos grandes de la familia Qwen3. Si tu máquina tiene menos de 8 GB libres, empieza con Qwen3 4B o Phi-4 Mini.

    ¿Necesito GPU para correr modelos en local?

    No obligatoriamente, pero marca la diferencia. Sin GPU dedicada, un modelo de 7B en CPU genera entre 3 y 8 tokens por segundo, lo que es funcional pero lento. Con una GPU de 8 GB VRAM (RTX 3060 o equivalente) subes a 20-40 tok/s, que ya es una experiencia fluida. En Apple Silicon la memoria unificada hace que CPU e iGPU compartan el mismo pool de memoria, lo que los hace especialmente eficientes.

    ¿Qué diferencia hay entre Q4 y Q8 en cuantización?

    La cuantización reduce la precisión de los pesos del modelo para ahorrar memoria. Q4 usa 4 bits por peso (el formato más comprimido), Q8 usa 8 bits (más cercano al original). En la práctica, Q4_K_M retiene el 92-95% de la calidad del modelo a fp16, ocupando la mitad de memoria. Para uso en local, Q4_K_M es el punto dulce entre calidad y eficiencia. Ollama descarga Q4 por defecto.

    ¿Puedo usar Ollama en un pipeline de CI/CD?

    Sí. Ollama corre en Linux sin interfaz gráfica y tiene imagen Docker oficial. El caso de uso habitual: un runner self-hosted de GitHub Actions con Ollama instalado que ejecuta validaciones de calidad de código o generación de tests sin coste por llamada. Para proyectos donde quieras integrar esto en un flujo estructurado, en Dominicode Labs tenemos ejemplos completos de pipelines con agentes locales en producción.

    ¿Qwen3 supera a modelos de OpenAI en código?

    En benchmarks de código como SWE-bench (según datos publicados por Alibaba en el lanzamiento de Qwen3, verificables en lmarena.ai), Qwen3 72B supera a GPT-4o. La variante de 8B ya es comparable a GPT-3.5-turbo en la mayoría de tareas de código. Para cosas que GPT-4o o Claude Sonnet hacen bien —razonamiento complejo, código muy largo con dependencias sutiles— los modelos cloud siguen ganando. Pero para el 80% de las tareas diarias de un developer, Qwen3 8B en local funciona perfectamente.

    ¿Cómo comparo modelos sin descargarlos todos?

    Usa ollama.com/search para ver los modelos disponibles con sus benchmarks. Para comparativas rápidas de calidad sin instalación, lmarena.ai (antes LMSYS Chatbot Arena) tiene evaluaciones humanas actualizadas. Mi recomendación práctica: descarga el modelo, pruébalo con tres de tus casos de uso reales, y decide. Los benchmarks orientan pero el uso real es el que manda.

    ¿Llama 4 Scout es realmente mejor que Llama 3?

    Para la mayoría de tareas, sí. El salto más notorio es el contexto: Llama 3.1 tiene 128K tokens, Llama 4 Scout tiene 10 millones. Para uso como asistente de chat o código simple, Llama 3.3 70B sigue siendo una opción excelente si tienes el hardware. Para análisis de documentos grandes o proyectos completos en el contexto, Llama 4 Scout es otro nivel.

    El paso siguiente

    Tener el mejor modelo LLM local corriendo en tu máquina es el primer paso. El segundo —y donde la mayoría de developers se quedan atascados— es estructurar cómo ese modelo encaja en un producto real.

    ¿Cómo se organiza el contexto? ¿Cuándo usas local y cuándo nube? ¿Cómo construyes un agente que funcione con ambos backends? Eso es exactamente lo que cubrimos en el curso Construye con IA: De la Idea al Producto — desde la especificación hasta el despliegue, con arquitectura real y sin atajos.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Neon vs Supabase: comparación técnica honesta (2026)

    Neon vs Supabase: comparación técnica honesta (2026)

    Hace unos meses estaba arrancando un proyecto nuevo. Stack limpio, decisiones por tomar. Y en cuestión de minutos tuve el debate de siempre en el canal de decisiones técnicas: ¿Neon o Supabase?

    Los dos son Postgres. Los dos tienen free tier. Los dos aparecen en casi cualquier lista de "stack moderno para SaaS". Y los dos hacen cosas completamente distintas.

    Este post es la Neon vs Supabase comparación técnica que me hubiera ahorrado dos horas de lectura de docs.

    Qué es cada uno en una línea

    Neon: Postgres serverless puro con branching de base de datos y scale-to-zero.

    Supabase: Plataforma BaaS construida sobre Postgres — incluye Auth, Storage, Realtime y Edge Functions en un solo sitio.

    La diferencia de fondo: Neon es una base de datos. Supabase es un backend completo que usa Postgres como motor.

    Tabla comparativa

    Criterio Neon Supabase
    Tipo Postgres serverless BaaS completo sobre Postgres
    Scale-to-zero Sí, nativo No en producción (pausa en free tier)
    Branching de DB Sí, copy-on-write instantáneo Solo Pro+ (beta); provisiona DB nueva + migraciones
    Auth nativo No Sí (JWT, OAuth, Magic Link)
    Storage nativo No Sí (S3-compatible)
    Realtime No Sí (WebSockets sobre Postgres)
    Edge Functions No Sí (Deno runtime)
    Free tier DB 0.5 GB, 100 CU-h 500 MB, pausa tras 7 días idle
    Plan de pago Desde ~$19/mes (usage-based) $25/mes (Pro, todo incluido)
    ORM compatible Cualquiera (Drizzle, Prisma, pg) Cliente JS/TS propio + cualquier ORM
    Tipado auto-generado Via ORM Sí, con supabase gen types
    Adquirida por Databricks (2025, ~$1B) Independiente

    Arquitectura de Neon vs Supabase: la diferencia que más importa

    Neon separa compute y storage. Cuando no hay peticiones, el compute se apaga solo — y cuando llega la primera query, arranca en milisegundos. El storage usa copy-on-write, lo que hace que crear una rama de base de datos sea instantáneo y casi sin coste.

    Supabase no funciona así. Tu base de datos corre en una instancia dedicada. Si estás en el free tier, Supabase pausa el proyecto tras 7 días sin actividad. En Pro, la instancia corre siempre — pagas compute 24/7 aunque tu app esté durmiendo.

    Para proyectos en producción con tráfico real, esto no es necesariamente un problema. Para proyectos con muchos entornos (staging, feature branches, demos de clientes), la diferencia de coste es brutal.

    Branching: por qué Neon gana en CI/CD

    Esta es la feature que más me ha cambiado el flujo de trabajo.

    Con Neon puedes crear una rama de base de datos por PR. Misma estructura, mismos datos (o un subconjunto). La rama vive mientras dura el PR y desaparece al hacer merge. No hay que mantener un entorno de staging contaminado con datos de otras features. Si tienes un pipeline con code review automático antes del merge, tienes el flujo completo en el post sobre agentic code review con Claude Code.

    # Crear una rama de DB para una PR concreta
neon branches create --name feature/payment-refactor --parent main

    Supabase también tiene branching, pero funciona diferente: aprovisiona una base de datos nueva, ejecuta tus migraciones y carga el seed. Es más lento y consume más recursos. Para un equipo pequeño o un proyecto personal, puede ser suficiente. Para un pipeline de CI/CD que crea y destruye entornos constantemente, Neon gana por goleada.

    SDK y DX: dos filosofías distintas

    Supabase tiene un cliente JS/TS que abstrae casi todo. Queries, auth, storage, realtime — todo desde el mismo objeto.

    // Supabase: cliente unificado con tipado auto-generado
import { createClient } from '@supabase/supabase-js'
import type { Database } from './database.types' // generado con supabase gen types

const supabase = createClient<Database>(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
)

const { data, error } = await supabase
  .from('products')
  .select('id, name, price')
  .eq('active', true)

    Neon apuesta por Postgres nativo. Usas tu ORM de siempre — Drizzle, Prisma, o pg directo — contra un connection string estándar. Sin abstracciones propias, sin vendor lock-in de cliente.

    // Neon: Drizzle sobre el driver serverless de Neon
import { neon } from '@neondatabase/serverless'
import { drizzle } from 'drizzle-orm/neon-http'
import { products } from './schema'
import { eq } from 'drizzle-orm'

const sql = neon(process.env.DATABASE_URL!)
const db = drizzle(sql)

const activeProducts = await db
  .select({ id: products.id, name: products.name, price: products.price })
  .from(products)
  .where(eq(products.active, true))

    Si ya tienes un ORM configurado en tu proyecto, migrar a Neon es cambiar el connection string. Con Supabase, el cliente propio es más cómodo para proyectos nuevos pero añade una dependencia específica a la plataforma.

    Precios Neon vs Supabase: cuándo cada modelo tiene sentido

    Neon (usage-based):

    • Free: $0 — 100 CU-horas, 0.5 GB storage
    • Launch: ~$19/mes — $0.106/CU-hora, $0.35/GB storage
    • Scale: desde ~$701/mes — con SLA e HIPAA incluidos

    Supabase (plataforma flat + overages):

    • Free: $0 — 500 MB DB, 50K MAU, 1 GB storage (pausa tras 7 días idle)
    • Pro: $25/mes — 8 GB DB, 100K MAU, Auth + Storage + Edge Functions incluidos
    • Team: $599/mes — SSO, SOC 2

    Para un proyecto con tráfico irregular o muchos entornos temporales, el modelo de Neon puede salir significativamente más barato. Para un SaaS en crecimiento que necesita Auth + Storage + DB y quiere una sola factura, el Pro de Supabase a $25 es imbatible en relación precio/funcionalidad.

    Precios verificados en junio 2026. Consulta las páginas oficiales de Neon y Supabase para tarifas actualizadas — los modelos usage-based cambian con frecuencia.

    Cuándo elegir Neon

    • Quieres Postgres puro sin opiniones sobre tu stack de auth o storage.
    • Tu pipeline de CI/CD se beneficia de tener una rama de DB por PR.
    • Tienes cargas de trabajo variables o intermitentes — el scale-to-zero te ahorra dinero real.
    • Ya tienes Drizzle o Prisma configurado y no quieres añadir un cliente propio.
    • Estás construyendo agentes de IA que necesitan provisionar bases de datos efímeras. La arquitectura serverless de Neon (y el respaldo de Databricks) la convierte en la opción natural para cargas de trabajo agénticas — incluidos los pipelines donde el agente lee un ticket, implementa y despliega de forma autónoma, como los que explico en el post sobre automatizar el proceso de desarrollo con IA.

    Cuándo elegir Supabase

    • Necesitas Auth desde el día uno — OAuth, magic link, JWT — sin montar Clerk ni Auth.js.
    • Tu proyecto necesita file storage y no quieres gestionar un bucket S3 por tu cuenta.
    • Quieres Realtime (subscripciones en tiempo real) sin añadir Redis ni WebSockets propios.
    • Valoras tener un solo proveedor para DB + Auth + Storage con una sola factura.
    • El free tier te basta para empezar y no te molesta que el proyecto se pause tras 7 días idle.

    Edge cases que nadie menciona

    Supabase no hace scale-to-zero en producción. Esto es intencionado — una instancia siempre activa garantiza latencia consistente. Pero si tienes 10 entornos de staging o un proyecto que duerme la mayor parte del tiempo, estás pagando compute en vacío.

    Neon no tiene Auth ni Storage nativos. Si los necesitas, tienes que añadirlos tú: Clerk, Better Auth, Auth.js para autenticación; Cloudflare R2, AWS S3 o Uploadthing para ficheros. No es un problema técnico, pero sí es trabajo de integración que con Supabase viene resuelto de fábrica.

    El branching de Supabase requiere CLI y configuración previa. No es tan plug-and-play como en Neon. Si quieres branching en Supabase, necesitas tener migraciones bien organizadas desde el principio.

    FAQ

    ¿Puedo usar Drizzle con Supabase?
    Sí. Supabase es Postgres estándar — puedes conectar cualquier ORM con el connection string del proyecto. El cliente propio de Supabase es opcional, no obligatorio.

    ¿Neon tiene Realtime o Auth?
    No de forma nativa. Puedes añadir LISTEN/NOTIFY de Postgres para eventos básicos, pero no hay un sistema de auth ni storage integrado. Para eso necesitas otra capa.

    ¿El scale-to-zero de Neon afecta a producción?
    Depende de tu configuración. El cold start de Neon suele estar por debajo de 500ms en condiciones normales. Para la mayoría de apps es aceptable. Si tienes requisitos de latencia muy estrictos, puedes configurar un mínimo de compute activo en el plan de pago.

    ¿Qué pasa con la adquisición de Neon por Databricks?
    Databricks compró Neon en 2025 por aproximadamente $1B. La apuesta es que los agentes de IA van a necesitar provisionar bases de datos efímeras a escala. Para el usuario, de momento se traduce en mejoras de precios — el storage bajó de $1.75 a $0.35/GB-mes. El roadmap a largo plazo aún está por verse.

    ¿Puedo migrar de Supabase a Neon (o al revés) más adelante?
    La base de datos en sí migra sin problema — es Postgres estándar en los dos casos. El trabajo real está en reemplazar el cliente de Supabase (auth, storage, realtime) si decides cambiar. Si usas Drizzle o Prisma desde el principio, cambiar el connection string es trivial.

    La decisión no es técnica en el fondo — es de qué quieres gestionar tú y qué quieres que gestione la plataforma. Si quieres Postgres puro con control total y branching en CI/CD, Neon. Si quieres un backend completo sin ensamblar piezas, Supabase.

    Ninguna de las dos es la respuesta correcta en abstracto. Ambas son la respuesta correcta para el problema adecuado.

    Si en tu proyecto estás usando IA para construir features o automatizar flujos, en el curso Construye con IA trabajamos exactamente con este tipo de decisiones de arquitectura — desde la elección de herramientas hasta el producto en producción.

    Si quieres profundizar en cómo tomar este tipo de decisiones de arquitectura en proyectos reales — con IA en el loop — en Dominicode Labs tenemos proyectos completos con el stack detallado y la justificación técnica detrás de cada decisión.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • DuckDB + Obsidian: analiza tu vault con SQL sin exportar nada

    DuckDB + Obsidian: analiza tu vault con SQL sin exportar nada

    Tenía más de 800 notas en Obsidian. Tres años de journaling técnico, decisiones de arquitectura, apuntes de libros, ideas de proyectos. Todo bien organizado, con frontmatter YAML, tags consistentes, links entre notas.

    Y seguía buscando con Cmd+Shift+F como si fuera 2010.

    El buscador de Obsidian es bueno para encontrar una nota específica. Es inútil para responder preguntas como: ¿cuántos proyectos he apuntado en el último trimestre que no tienen ninguna nota de seguimiento? ¿Qué tecnologías aparecen más en mis journals de este año? ¿Cuántas notas de tipo "idea" no tienen ningún link interno hacia otro documento?

    Esas preguntas no son búsquedas de texto. Son queries sobre datos estructurados. Y eso es exactamente lo que hace DuckDB.

    La configuración de DuckDB con Obsidian que voy a enseñarte te permite tratar tu vault como una base de datos relacional — y correr SQL directamente sobre tus archivos .md.

    DuckDB con Obsidian es la combinación de DuckDB — un motor SQL embebido de alto rendimiento — con un vault de Obsidian para tratar los archivos .md como filas de una base de datos consultable. A través de la extensión duckdb-obsidian, puedes ejecutar SQL directamente sobre tu frontmatter YAML, links internos y estructura de headings, sin exportar ni transformar ningún archivo.

    Por qué DuckDB y no algo más "normal"

    Podrías exportar todo tu vault a CSV y abrirlo en SQLite. O parsear el frontmatter con un script en Python y cargarlo en Pandas. Lo he hecho. Funciona, pero tienes que mantener ese pipeline de sincronización, gestionar el esquema cuando cambias tus propiedades, y el resultado no vive dentro de Obsidian — vive en otro sitio.

    DuckDB resuelve esto de dos formas distintas según lo que necesites:

    1. La extensión CLI duckdb-obsidian — una extensión no oficial que expone una función obsidian_notes() que parsea tu vault en tiempo real directamente desde el CLI de DuckDB. Sin exportar nada. Sin pipeline. Lanzas DuckDB, cargas la extensión, y tu vault es una tabla.

    2. El plugin Obsidian DuckDB and MotherDuck — un plugin que vive dentro de Obsidian, corre DuckDB WASM en el navegador, y te permite escribir bloques SQL en tus notas que renderizan como tablas markdown. El resultado se puede "congelar" como texto plano para que persista sin necesidad de re-ejecutar.

    Son dos herramientas distintas para dos flujos distintos. Te explico ambas.

    Opción 1: DuckDB CLI + extensión duckdb-obsidian

    Esta es la opción para cuando quieres hacer análisis ad-hoc desde la terminal, escribir scripts, o conectar los resultados a otras herramientas.

    Instalación

    Primero necesitas DuckDB instalado. La forma más limpia dependiendo de tu sistema:

    # macOS con Homebrew
brew install duckdb

# Windows con WinGet
winget install DuckDB.cli

# O directamente desde los binarios de duckdb.org/docs/installation

    Verifica que funciona:

    duckdb --version
# v1.2.2
# La extensión duckdb-obsidian es compatible con DuckDB 1.1.x y 1.2.x

    Ahora descarga la extensión. Ve a github.com/puzan/duckdb-obsidian/releases y descarga el archivo que corresponde a tu versión de DuckDB y tu sistema operativo. El nombre del archivo tiene el formato obsidian.duckdb_extension.

    Configuración

    La extensión no está firmada por DuckDB, así que tienes que lanzar la CLI con extensiones sin firmar habilitadas:

    duckdb --allow-unsigned-extensions

    Dentro de la sesión, carga la extensión con la ruta absoluta al archivo que descargaste. Si el archivo viene comprimido (.duckdb_extension.gz), descomprímelo primero antes del LOAD:

    LOAD '/ruta/absoluta/a/obsidian.duckdb_extension';

    Si no quieres escribir esto cada vez, crea un archivo .duckdbrc en tu home. DuckDB lo ejecuta automáticamente al arrancar:

    SET allow_unsigned_extensions = true;
LOAD '/ruta/absoluta/a/obsidian.duckdb_extension';

    Para apuntar al vault, tienes dos opciones. La primera: navega al directorio del vault antes de lanzar DuckDB — la función obsidian_notes() sin argumentos escanea el directorio actual:

    cd /Users/bezael/vault
duckdb --allow-unsigned-extensions

    La segunda: pasa la ruta directamente como argumento a la función:

    SELECT * FROM obsidian_notes('/Users/bezael/vault') LIMIT 5;

    La única restricción es que el directorio debe contener una carpeta .obsidian — es como la extensión verifica que es un vault válido.

    Esquema disponible

    La función obsidian_notes() expone estas columnas sobre cada nota:

    Columna Tipo Contenido
    basename VARCHAR Nombre del archivo sin .md
    filepath VARCHAR Ruta absoluta al archivo
    first_header VARCHAR Primer H1 de la nota, o NULL
    headers STRUCT[] Todos los headings con su nivel
    properties JSON Frontmatter YAML parseado como JSON
    internal_links STRUCT[] Wikilinks con target, nombre y referencia

    Queries SQL reales sobre tu vault de Obsidian

    Aquí es donde esto se vuelve útil de verdad.

    Analizar la distribución de tags

    ¿Cuáles son los tags que más usas y cuántas notas tienen cada uno?

    SELECT
  tag,
  count(*) AS total_notas
FROM (
  SELECT unnest(
    from_json(properties->'$.tags', '["VARCHAR"]')
  ) AS tag
  FROM obsidian_notes()
  WHERE properties->>'$.tags' IS NOT NULL
)
GROUP BY tag
ORDER BY total_notas DESC
LIMIT 20;

    Esto parsea el array tags del frontmatter de cada nota y te da un ranking. Tres años de vault analizados en menos de un segundo.

    Encontrar notas huérfanas

    Notas que nadie enlaza — las que más probablemente estés olvidando:

    WITH todas_las_notas AS (
  SELECT basename FROM obsidian_notes()
),
notas_referenciadas AS (
  SELECT DISTINCT unnest(
    list_transform(internal_links, l -> l.target)
  ) AS target
  FROM obsidian_notes()
  WHERE len(internal_links) > 0
)
SELECT basename
FROM todas_las_notas
WHERE basename NOT IN (SELECT target FROM notas_referenciadas)
ORDER BY basename;

    Cuando corrí esto en mi vault por primera vez encontré 340 notas huérfanas. 340. Notas que había creado, nunca enlazado desde ningún otro sitio, y que esencialmente estaban muertas dentro del vault.

    Grafo de links entre notas

    Para exportar el grafo completo a CSV y procesarlo en otra herramienta:

    COPY (
  SELECT
    basename AS origen,
    unnest(list_transform(internal_links, l -> l.target)) AS destino
  FROM obsidian_notes()
  WHERE len(internal_links) > 0
) TO '/tmp/grafo-vault.csv' (HEADER, DELIMITER ',');

    Cruzar propiedades del frontmatter

    Si usas frontmatter consistente (por ejemplo status, type, project), puedes hacer queries cruzadas:

    SELECT
  properties->>'$.type' AS tipo,
  properties->>'$.status' AS estado,
  count(*) AS total
FROM obsidian_notes()
WHERE properties->>'$.type' IS NOT NULL
GROUP BY tipo, estado
ORDER BY total DESC;

    Esto responde preguntas como: ¿cuántos documentos de tipo "project" están en estado "in-progress" vs "done"?

    Buscar patrones en journals

    Si guardas journals diarios con una estructura de frontmatter predecible, puedes cruzarlos:

    SELECT
  basename,
  properties->>'$.mood' AS mood,
  properties->>'$.energia' AS energia
FROM obsidian_notes()
WHERE properties->>'$.type' = 'journal'
  AND properties->>'$.date' >= '2026-01-01'
ORDER BY properties->>'$.date' DESC;

    Opción 2: Plugin DuckDB + MotherDuck dentro de Obsidian

    Si prefieres no salir de Obsidian, el plugin oficial te mete DuckDB directamente en el editor.

    Instalación

    Abre Obsidian → Settings → Community plugins → Browse. Busca "DuckDB and MotherDuck". Instala y activa.

    El plugin corre DuckDB WASM — no necesita instalación local de DuckDB, corre directamente en memoria dentro de Obsidian.

    Cómo escribir queries

    Crea un bloque de código con el lenguaje duckdb:

    ```duckdb
SELECT
  o_orderpriority AS priority,
  count(*) AS orders,
  round(sum(o_totalprice), 2) AS revenue
FROM read_parquet('https://shell.duckdb.org/data/tpch/0_01/parquet/orders.parquet')
GROUP BY 1
ORDER BY revenue DESC
```

    Cuando ejecutas la query (con el comando "Refresh query at cursor"), el resultado se renderiza como una tabla markdown directamente debajo del bloque.

    La feature más útil del plugin es Freeze: convierte el resultado en texto plano markdown que persiste en la nota sin necesidad de re-ejecutar. El archivo .md queda con la query y su resultado como texto estático — lo que significa que funciona en cualquier plataforma que renderice markdown, incluyendo tu vault público en Quartz.

    Limitaciones reales del plugin vs. CLI

    El plugin tiene un caso de uso claro: consultas sobre datos externos o remotos (CSV, Parquet, JSON en URLs, MotherDuck) que quieres mostrar como tablas vivas dentro de tus notas.

    Para consultar el vault en sí — los archivos .md, el frontmatter, los links — la extensión CLI es más potente. El plugin no expone obsidian_notes() porque DuckDB WASM no tiene acceso al sistema de archivos local de Obsidian de la misma forma.

    Para análisis del vault completo: CLI. Para datos externos integrados en notas: plugin.

    Cuándo usas esto en la práctica

    Llevo usando este setup tres meses. Estos son los casos donde realmente lo abro:

    Revisiones semanales. Tengo un script .sql que me lista todas las notas con status: in-progress que no he modificado en más de siete días. Corro el script los viernes. Lo que aparece en esa lista o lo priorizo o lo cierro.

    Auditoría del vault cada dos meses. La query de notas huérfanas + la query de distribución de tags me da una foto de hacia dónde está derivando mi sistema de notas sin que me haya dado cuenta.

    Análisis de proyectos. Cuando empiezo a trabajar en un cliente nuevo, tengo notas del sector o la tecnología dispersas por el vault. Una query me saca todo lo que he apuntado sobre ese dominio aunque no recuerde los nombres exactos de las notas.

    Exportar datos a otras herramientas. DuckDB puede escribir directamente a CSV, Parquet, JSON. Si quiero hacer un análisis más visual en una hoja de cálculo o en una herramienta de BI, exporto el resultado de la query y lo importo. Sin copiar a mano.

    Este enfoque encaja exactamente con la filosofía que aplicamos en el curso Construye con IA: tratar tus propios datos como un asset que puedes interrogar, no como un archivo que tienes que recordar dónde dejaste. Tu vault no es una colección de texto — es una base de conocimiento que merece una capa de consulta real.

    Lo que puedes hacer hoy

    Instala DuckDB. Descarga la extensión duckdb-obsidian. Corre la query de notas huérfanas sobre tu vault.

    Eso solo ya te va a dar información que no tienes ahora mismo: qué parte de tu vault está desconectada del resto. A partir de ahí decides si quieres ir más lejos con análisis de tags, patterns en journals, o cruzar propiedades del frontmatter.

    No necesitas un pipeline. No necesitas exportar nada. Lanzas DuckDB, cargas la extensión, y en un minuto estás corriendo SQL sobre años de notas.

    Si quieres ver más flujos donde los datos y las herramientas de IA se conectan así de forma directa, en Dominicode Labs tenemos proyectos completos que aplican exactamente esta filosofía — tratar tu entorno de trabajo como datos consultables, no como texto disperso.

    El patrón es el mismo que aplicamos cuando conectamos Claude a una fuente de datos externa: datos estructurados + una herramienta que los entiende = velocidad real. Si quieres ver cómo funciona ese loop completo desde el lado de la API, mira Claude API: Crash Course para developers con TypeScript.

    FAQ

    ¿Necesito tener DuckDB instalado localmente para el plugin de Obsidian?

    No. El plugin DuckDB and MotherDuck usa DuckDB WASM, que corre completamente en memoria dentro de Obsidian sin instalación adicional. La extensión CLI (duckdb-obsidian) sí requiere DuckDB instalado localmente porque necesita acceder al sistema de archivos.

    ¿La extensión duckdb-obsidian funciona con vaults grandes?

    Sí, con matices. DuckDB está diseñado para procesar grandes volúmenes de datos de forma eficiente. En un vault de 2.000-3.000 notas las queries simples tardan menos de un segundo. Para vaults muy grandes (5.000+ notas) con queries que cruzan múltiples propiedades JSON, puede ser recomendable usar SET threads TO 4; dentro de la sesión para aprovechar todos los cores.

    ¿El frontmatter tiene que seguir algún formato específico?

    Solo tiene que ser YAML válido al inicio del archivo, delimitado por ---. La extensión lo parsea como JSON en la columna properties. Anidamiento, arrays de tags, fechas — todo funciona. La única restricción es que las propiedades que quieras consultar deben existir en el frontmatter de esas notas.

    ¿Puedo conectar los resultados de estas queries a un agente de IA?

    Sí, y es uno de los casos de uso más interesantes. DuckDB puede exportar a JSON con COPY (...) TO '/tmp/output.json' (FORMAT JSON). Ese JSON lo puedes pasar como contexto a un agente o a la API de Claude para que razone sobre el estado de tu vault. MotherDuck tiene incluso documentación oficial sobre cómo usar el vault de Obsidian como fuente de datos para agentes de IA. También puedes conectar DuckDB directamente a un servidor MCP para que el agente ejecute queries de forma autónoma — ese es el siguiente nivel de este setup. Para entender la base de cómo funciona ese patrón con la API de Claude, tienes la guía completa en Claude API: Crash Course para developers con TypeScript. Si te interesa explorar esa dirección con proyectos en producción, tenemos más en Dominicode Labs.

    ¿Por qué DuckDB y no SQLite para esto?

    SQLite requiere que crees y mantengas el esquema manualmente. DuckDB infiere el esquema sobre la marcha: lee los archivos .md a través de la extensión, parsea el frontmatter como JSON, y expone todo como columnas consultables sin que hayas definido nada. Además, DuckDB tiene soporte nativo para arrays, structs y JSON anidado — que es exactamente el tipo de datos que tienes en el frontmatter de Obsidian. Con SQLite tendrías que escribir código de parseo adicional. Con DuckDB la extensión se encarga de todo.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.