DOMINICODE

Tag: AI

  • RAG vs Fine-tuning: cuándo usar cada uno (guía práctica)

    RAG vs Fine-tuning: cuándo usar cada uno (guía práctica)

    Un cliente me mostró su arquitectura hace unos meses. Había pasado seis semanas haciendo fine-tuning de un modelo para que respondiera preguntas sobre la documentación interna de su empresa.

    Seis semanas. Un dataset de 4.000 pares de pregunta-respuesta construidos a mano. Costes de entrenamiento en GPU. Y al final, el sistema seguía inventándose respuestas cuando la pregunta tocaba un documento que no estaba en el training data.

    Le pregunté por qué no había usado RAG. Me dijo que pensó que fine-tuning era “la solución profesional”. Que RAG era para hacer demos rápidas. Ese malentendido sobre RAG vs Fine-tuning es más común de lo que parece, y sale caro.

    El error conceptual que lo complica todo

    La mayoría de developers que se acercan a este problema lo enmarcan mal desde el principio.

    Piensan en términos de “qué técnica es más potente”. Y ahí ya van por el camino equivocado.

    La pregunta correcta no es cuál es más potente. Es: ¿qué problema tienes exactamente?

    Si tu modelo no sabe cosas que necesita saber — información privada, documentos internos, datos recientes — tienes un problema de conocimiento. RAG lo resuelve.

    Si tu modelo sabe las cosas pero no las comunica como necesitas — tono diferente, formato específico, comportamiento distinto al por defecto — tienes un problema de comportamiento. Fine-tuning lo resuelve.

    Son problemas distintos. Las soluciones no son intercambiables.

    Qué es RAG (Retrieval-Augmented Generation) y cuándo usarlo

    RAG (Retrieval-Augmented Generation) no modifica el modelo. El modelo base sigue siendo exactamente el mismo.

    Lo que hace RAG es intervenir en el momento en que llega una pregunta. Antes de pasársela al modelo, busca en una base de datos vectorial los fragmentos de tus documentos más relevantes para esa consulta, y los inyecta en el prompt. El modelo entonces responde con acceso real a esa información.

    Usuario pregunta: "¿Cuál es la política de devoluciones?"
                         ↓
             Sistema RAG busca en vectorDB
                         ↓
      Encuentra: chunk del doc "politica-devoluciones-2026.pdf"
                         ↓
    Prompt al modelo: "Contexto: [chunk]. Pregunta: ¿Cuál es...?"
                         ↓
            Modelo responde con información real

    La ventaja clave: tus documentos pueden cambiar mañana. Actualizas la base vectorial. El modelo ya tiene acceso a la nueva información. Sin reentrenar nada.

    Si estás explorando qué modelo usar para el componente generativo, este análisis sobre el mejor modelo LLM local en 2026 te ayuda a elegir sin sobreingenierizar la infraestructura.

    Esto es lo que lo hace ideal para documentación interna, bases de conocimiento, FAQs, soporte técnico — cualquier caso donde la información cambia y necesitas que el modelo cite fuentes reales en lugar de fabricar respuestas.

    El límite de RAG está en que no cambia cómo se comporta el modelo. Si necesitas que responda en un tono muy específico, siga un formato exacto, o haga razonamientos que el modelo base no hace bien de forma natural, RAG no te ayuda. Solo le das más información. No lo entrenas.

    Qué es Fine-tuning de LLMs y cuándo tiene sentido aplicarlo

    Fine-tuning sí modifica el modelo. Tomas un modelo base preentrenado y lo sigues entrenando con tu propio dataset, ajustando sus pesos para que aprenda los patrones que te interesan.

    El resultado es un modelo diferente. Uno que ha interiorizado un estilo, un formato, un tipo de razonamiento específico. No necesitas darle instrucciones en el prompt porque ya las tiene grabadas en sus pesos.

    # Sin fine-tuning: necesitas el prompt completo
prompt = """Eres un asistente técnico especializado en Kubernetes.
Responde siempre con: 1) causa del problema, 2) solución paso a paso, 
3) cómo prevenirlo. Usa terminología técnica precisa. No añadas 
disclaimers. El tono es directo, de senior a senior.


    Problema: Mi pod no arranca después de actualizar la imagen..."""
    


    # Con fine-tuning: el modelo ya sabe cómo comportarse prompt = "Problema: Mi pod no arranca después de actualizar la imagen..."

    El modelo fine-tuneado responde directamente en el formato correcto porque ese comportamiento está en sus pesos. No porque se lo estés recordando en cada llamada.

    Lo que fine-tuning no resuelve: inyectar conocimiento factual nuevo. Si entrenas el modelo en el estilo de tu empresa pero no en los documentos de tu empresa, seguirá sin saber qué contienen esos documentos. Habrá aprendido a comunicarse como tú quieres, pero no a responder con información real que no tenía.

    RAG vs Fine-tuning: la matriz de decisión con cuatro casos reales

    Hay cuatro combinaciones que aparecen una y otra vez en proyectos reales. Aquí están con sus soluciones.

    Caso 1: Chatbot sobre documentación interna

    Necesitas que el modelo responda preguntas sobre tus PDFs, wikis, Notion, Confluence. La información cambia regularmente. El tono puede ser el del modelo base.

    Solución: RAG. Indexas los documentos en una vectorDB (Pinecone, pgvector, Weaviate), configuras el pipeline de retrieval, y el modelo responde con fuentes reales. No reentrenar nada.

    Caso 2: Generador de código en el estilo de tu empresa

    Quieres que el modelo genere código que siga tus convenciones internas, use tus abstracciones propias, evite los patrones que prohíbes. El modelo base lo entiende pero tienes que recordárselo en cada prompt.

    Solución: Fine-tuning. Un dataset de ejemplos de código en tu estilo — antes/después — y el modelo interioriza esas preferencias. El prompt se simplifica radicalmente.

    Caso 3: Asistente de soporte que responde sobre tus productos Y en tu tono

    Quieres las dos cosas: información factual sobre tus productos (que cambia) y un comportamiento de comunicación muy específico (directo, sin ambigüedades, con formato concreto).

    Solución: Fine-tuning + RAG. Fine-tuning para el comportamiento y el formato. RAG para la información factual. Son complementarios, no excluyentes.

    Caso 4: Clasificador de texto o extractor de entidades

    Necesitas que el modelo clasifique tickets de soporte, extraiga entidades de contratos, o haga tareas de NLP muy específicas.

    Solución: Fine-tuning en casi todos los casos. Para tareas de clasificación y extracción, un modelo fine-tuneado en tu dominio supera consistentemente a uno general con prompts elaborados, y además es más barato en inferencia porque los prompts son más cortos.

    Los costes reales — lo que nadie te dice antes de empezar

    Costes de RAG:

    • Configurar el pipeline de chunking, embedding y retrieval: 2-5 días de desarrollo
    • Inferencia: coste del modelo base + coste de las llamadas a la vectorDB (bajo)
    • Mantenimiento: actualizar la base vectorial cuando cambian los documentos (automatizable)
    • Problema principal: calidad del retrieval — si buscas mal, el modelo responde mal aunque los documentos sean perfectos

    Costes de Fine-tuning:

    • Construir el dataset de entrenamiento: semanas (es el cuello de botella real)
    • Entrenamiento: desde $50 hasta miles de dólares dependiendo del modelo y el tamaño del dataset
    • Inferencia: más cara que el modelo base porque tienes que hostear tu propio modelo o pagar por el endpoint custom
    • Problema principal: degradación con el tiempo — si tu tarea evoluciona, tienes que reentrenar

    La mayoría de proyectos que han hecho fine-tuning cuando lo que necesitaban era RAG han pagado semanas de trabajo y costes de entrenamiento para resolver un problema que RAG hubiera resuelto en cuatro días.

    El árbol de decisión que uso en consultoría

    Cuando alguien me pregunta qué usar, le hago estas cuatro preguntas en orden:

    1. ¿Tu problema es que el modelo no tiene la información o que no se comporta como quieres?

    • No tiene la información → RAG
    • No se comporta bien → Fine-tuning

    2. ¿La información cambia con frecuencia?

    • Sí → RAG (actualizar embeddings es trivial vs. reentrenar)
    • No → Fine-tuning empieza a tener más sentido

    3. ¿Tienes datos de entrenamiento de alta calidad?

    • No los tienes → empieza con RAG mientras los recopilas
    • Sí los tienes → Fine-tuning es viable

    4. ¿Tienes restricciones de latencia o coste de inferencia?

    • Sí, necesitas prompts muy cortos → Fine-tuning reduce el prompt dramáticamente
    • No es crítico → RAG es suficiente

    En la práctica, el 70% de los casos que veo en producción son candidatos a RAG, no a fine-tuning. Fine-tuning es potente pero requiere un problema muy bien definido, datos de calidad y tiempo para construirlos.

    Qué pasa cuando combinas los dos

    La combinación más efectiva en sistemas de producción serios sigue un patrón concreto. Y es parte de una arquitectura más amplia — si quieres entender cómo el LLM encaja con el resto del sistema, el post sobre qué es un agent harness lo explica con detalle.

    • Fine-tuning para que el modelo entienda el dominio, la terminología y el formato de respuesta esperado
    • RAG para que el modelo tenga acceso a la información factual actualizada

    Un ejemplo real: un asistente jurídico. Fine-tuneado para entender terminología legal española, responder en formato jurídico y estructurar los análisis como lo haría un abogado. RAG conectado a la base de legislación actualizada y a los expedientes del despacho.

    El modelo habla como un jurista (fine-tuning). Responde con la ley real y los documentos del caso (RAG). Ninguna de las dos técnicas sola lo consigue.

    Esta es la arquitectura que más vemos en productos de IA serios. No es glamorosa. Pero funciona. En el curso Construye con IA: de la idea al producto con Claude Code, trabajo este tipo de decisiones de arquitectura desde la fase de especificación — antes de escribir una línea de código — para que no llegues a la semana seis arrepintiéndote de la técnica que elegiste.

    Tabla comparativa RAG vs Fine-tuning

    RAG Fine-tuning
    Problema que resuelve El modelo no tiene la información El modelo no se comporta como quieres
    Modifica el modelo No Sí
    Cuándo usar Datos dinámicos, documentos, bases de conocimiento Estilo, formato, comportamiento consistente
    Coste de inicio Bajo-medio (pipeline) Alto (dataset + entrenamiento)
    Mantenimiento Fácil (actualizar vectorDB) Costoso (reentrenar cuando cambia el problema)
    Tiempo hasta producción Días Semanas
    Combinar con el otro Sí Sí

    Guarda esta tabla. Te va a ahorrar más de una conversación.

    FAQ

    ¿Puedo usar RAG con cualquier LLM?

    Sí. RAG es agnóstico al modelo. Funciona con GPT-4, Claude, Gemini, Llama, Mistral o cualquier modelo que acepte un prompt de texto. Lo único que necesitas es que el modelo tenga una ventana de contexto suficiente para recibir los chunks recuperados junto con la pregunta. Los modelos modernos (128k-200k tokens) raramente tienen problemas con esto.

    ¿El fine-tuning de GPT-4 o Claude vale la pena frente a usar el modelo base con un buen prompt?

    En la mayoría de casos de uso, un buen prompt de sistema con ejemplos (few-shot prompting) iguala o supera al fine-tuning cuando el dataset de entrenamiento es pequeño (menos de 1.000 ejemplos). Fine-tuning empieza a tener sentido claro cuando tienes +5.000 ejemplos de calidad, cuando el coste de inferencia del prompt largo es un problema real, o cuando necesitas consistencia de comportamiento imposible de garantizar solo con prompts.

    ¿RAG siempre “alucina” menos que el modelo base?

    RAG reduce alucinaciones relacionadas con hechos específicos de tus documentos — porque el modelo tiene el texto real delante. Pero no elimina las alucinaciones del modelo base sobre razonamientos o inferencias. Si el modelo alucina porque hace mal el razonamiento lógico, RAG no te ayuda. Ese es un problema de capacidad del modelo, no de conocimiento.

    ¿Qué vectorDB recomendas para empezar?

    Para proyectos nuevos: pgvector si ya usas PostgreSQL (cero infraestructura adicional), o Pinecone si quieres un servicio gestionado sin fricción operativa. Weaviate y Chroma son buenas opciones open-source si necesitas auto-hosting. Evita sobre-ingenierizar esto al principio — pgvector resuelve el 80% de los casos sin añadir complejidad. Puedes consultar la documentación oficial de pgvector para la instalación y configuración básica.

    ¿Cuánto cuesta hacer fine-tuning con GPT-4o mini o Llama 3?

    GPT-4o mini fine-tuning en OpenAI cuesta aproximadamente $3-5 por millón de tokens de entrenamiento (junio 2026). Un dataset de 10.000 ejemplos con prompts de 500 tokens cada uno te sale a menos de $30 de entrenamiento. El coste real no es el GPU — es el tiempo de construir el dataset de calidad. Con Llama 3, puedes hacer fine-tuning con frameworks como Unsloth en una GPU A100 por $2-4/hora. Un run de fine-tuning de 3-4 horas es completamente asequible.

    ¿RAG vs Fine-tuning cambia con los modelos de razonamiento (o1, Gemini Thinking)?

    Sí, hay un matiz importante. Los modelos de razonamiento son mucho mejores siguiendo instrucciones complejas en el prompt, lo que reduce la necesidad de fine-tuning para casos de comportamiento. Pero siguen sin tener acceso a información privada o actualizada — ahí RAG sigue siendo indispensable. El fine-tuning con modelos de razonamiento es técnicamente más complejo y menos documentado a fecha de hoy.

    Si quieres ver estos patrones aplicados en proyectos reales con código y arquitectura completa, en Dominicode Labs trabajamos este tipo de decisiones técnicas con la comunidad. Proyectos reales, problemas reales, decisiones que puedes aplicar esta semana.

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

  • 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.

  • 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.

  • 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.

  • 3 formas de ganar dinero en internet como developer en 2026

    3 formas de ganar dinero en internet como developer en 2026

    Durante casi diez años cobré a final de mes. Sin falta, sin sorpresas, sin ansiedad. Y durante casi diez años pensé que eso era la estabilidad.

    Lo que no vi durante esos años es que el salario tiene un techo. Puedes mejorar, conseguir un aumento del 10%, cambiar de empresa y pegar un salto del 20%. Pero la relación entre tu esfuerzo y tu ingreso siempre es lineal. Das 40 horas, recibes X. Das 60 horas, recibes X igualmente — el salario no premia el esfuerzo extra, premia la presencia.

    El día que entendí eso, empecé a construir algo diferente.

    Hoy, parte de lo que gano viene de cursos que grabé hace tres años. Parte viene de una comunidad con membresía mensual. Parte viene de proyectos donde la IA me permite hacer el trabajo de un equipo pequeño en la mitad del tiempo. No es magia. No ocurrió de un mes al siguiente. Pero la diferencia estructural con un salario fijo es real y es enorme.

    Si eres developer y quieres ganar dinero en internet como developer — no como influencer, no como coach de productividad, sino usando lo que ya sabes — estas son las tres formas que yo he visto funcionar en 2026.

    1. Cursos técnicos: cómo generar ingresos pasivos como developer

    Los cursos técnicos son la forma más asimétrica de monetizar conocimiento: produces el contenido una vez y genera ingresos recurrentes sin trabajo adicional por cada venta.

    Es el modelo que yo empecé primero y el que más me ha enseñado sobre la diferencia entre tiempo y activo.

    La lógica es simple: tienes conocimiento técnico que alguien más necesita. En lugar de explicárselo una vez en una reunión — y que te paguen por esa hora —, lo grabas, lo estructuras, y lo vendes 10.000 veces sin hacer nada más.

    Eso es lo que pasa con mis cursos en Udemy: el de Angular Moderno, el de Testing, el de Zod, el de Claude Code. Los grabé. Siguieron vendiendo. El trabajo ya está hecho.

    Pero hay algo que casi nadie dice sobre esto: los primeros meses son duros. Tu primer curso no va a generar €3.000 el primer mes. Va a generar €80 y te va a parecer poco para el esfuerzo que pusiste. La clave está en entender que no estás cobrando por ese mes — estás construyendo un activo que va a seguir funcionando.

    Algunos números reales para que tengas expectativas honestas:

    • Un curso en Udemy puede generar entre €50 y €500/mes en sus primeros meses, dependiendo del nicho y la demanda.
    • A medida que acumulas reseñas y estudiantes, crece de forma orgánica sin que hagas nada nuevo.
    • Si tienes 3 o 4 cursos, los ingresos se suman. Eso es lo que marca la diferencia.

    Lo que necesitas para empezar: saber algo que otros developers necesiten aprender, tener un micrófono decente, y la disciplina para terminar lo que empiezas. No necesitas ser el mejor del mundo en el tema — necesitas saber más que tu alumno objetivo y saber explicarlo con claridad.

    2. SaaS con IA: el modelo que un developer puede construir solo

    Un SaaS pequeño con IA es un producto digital que resuelve un problema concreto y cobra de forma recurrente — y en 2026, un developer puede construirlo solo en días, no en meses.

    El problema del SaaS clásico era el tiempo: meses para llegar a un MVP, y eso si tenías equipo. Con Claude Code, Cursor o agentes bien configurados, ese cuello de botella desaparece. No porque la IA programe por ti — sino porque elimina la fricción entre lo que sabes hacer y el tiempo que tardas en hacerlo.

    El modelo que funciona no es el "construyo el próximo Notion" — eso es una trampa. El modelo que funciona es: identifica un proceso repetitivo y tedioso que alguien paga por resolver, y cóbralo como herramienta.

    Ejemplos concretos que he visto en la comunidad de Dominicode Labs:

    • Una herramienta que genera contratos de freelance desde una plantilla y los envía por email: €9/mes.
    • Un pequeño dashboard que consolida métricas de varias plataformas para agencias: €29/mes.
    • Un agente que revisa PRs de código y genera un resumen para el equipo: €19/mes por organización.

    Ninguno de estos es revolucionario. Todos resuelven un problema real. Y todos tienen un modelo de cobro recurrente que convierte el trabajo de una semana en un ingreso mensual.

    El umbral de entrada es bajo. El único requisito es que seas capaz de hablar con clientes potenciales antes de escribir la primera línea de código — algo que a los developers nos cuesta más de lo que queremos admitir.

    3. Consultoría técnica con IA: cobra más, trabaja igual

    La consultoría técnica multiplicada por IA no es el freelancing clásico: es usar agentes e IA para hacer el trabajo de varios developers en el tiempo de uno, y cobrar en consecuencia.

    El freelancing clásico tiene el mismo problema que el salario: sigues cambiando tiempo por dinero. Tienes 40 horas. Las vendes. No puedes vender 80.

    Lo que ha cambiado en 2026 es que la IA te permite hacer el trabajo de dos o tres developers en el tiempo de uno. Si sabes configurar agentes, si sabes delegar las partes repetitivas a Claude Code o a flujos de n8n, si sabes qué parte del trabajo requiere tu criterio humano y qué parte puede automatizarse — puedes cobrar como equipo y trabajar como individuo.

    Eso no es trampa. Es eficiencia. Los clientes pagan por resultados, no por horas.

    Hay dos variantes concretas de este modelo:

    Proyectos de implementación acelerada. Un cliente necesita integrar una API, construir un backend, migrar un sistema. Antes, eso costaba tres meses y tres developers. Tú lo entregas en tres semanas con IA y cobras el 60% de lo que habría costado el equipo. Todos ganan.

    Automatización de procesos de negocio con retención mensual. Esto es lo que más escala. Entras en una empresa, identificas los procesos manuales y repetitivos — reportes, emails, validaciones de datos, flujos entre herramientas — y los automatizas con n8n, agentes o scripts. Cobras un fee mensual por mantenimiento y mejoras. Es MRR sin necesidad de un producto propio.

    Este modelo requiere que salgas de la zona de confort técnica y entres en conversaciones de negocio. Requiere entender el problema del cliente antes de proponer la solución. Pero si lo haces bien, puedes tener tres o cuatro clientes recurrentes que juntos superen con creces cualquier salario.

    Los tres modelos comparados

    Modelo Esfuerzo inicial Ingresos típicos (6 meses) Requiere audiencia previa
    Cursos técnicos Alto €50–€500/mes por curso No, pero acelera mucho
    SaaS con IA Medio €9–€29/usuario/mes No
    Consultoría con IA Bajo €2.000–€8.000/mes por cliente No

    Los tres no son mutuamente excluyentes. Yo los tengo los tres activos en paralelo. No empecé con los tres a la vez — eso habría sido demasiado. La secuencia que yo recomendaría:

    1. Empieza por los cursos. El tiempo de producción es alto, pero el activo dura años y te posiciona como referente en tu nicho.
    2. Cuando tengas audiencia, lanza algo pequeño de pago recurrente. Puede ser una comunidad, una herramienta, un recurso. En mi caso fue Dominicode Labs.
    3. Usa la IA para multiplicar tu capacidad en proyectos de consultoría mientras los otros dos modelos generan ingreso pasivo.

    Ninguno de estos caminos es pasivo desde el primer día. El trabajo inicial es real. Pero la asimetría — lo que recibes a largo plazo versus lo que das en las primeras semanas — es lo que los hace estructuralmente distintos a un salario.

    Si quieres empezar por aprender a construir con IA de forma que tenga sentido de negocio, en el curso Construye con IA cubrimos exactamente eso: cómo pasar de una idea a un producto real usando Claude Code con criterio. Y en el blog de Dominicode publicamos regularmente tutoriales técnicos sobre IA aplicada, agentes y desarrollo de producto.

    Preguntas frecuentes

    ¿Cuánto tiempo se tarda en ganar dinero con un curso técnico?

    Depende del nicho y de si ya tienes audiencia. Con audiencia desde el primer mes puedes generar ingresos reales. Sin audiencia, cuenta entre 3 y 6 meses para que el curso empiece a tener tracción orgánica en Udemy. Los primeros meses el ingreso es bajo — la clave es no abandonar en ese tramo.

    ¿Necesito una empresa para ofrecer consultoría con IA?

    No para empezar. Puedes operar como autónomo o freelance desde el primer día. La estructura legal depende de tu país y de los volúmenes que manejes. Lo que sí necesitas desde el principio es un contrato claro y saber articular el valor que entregas en términos de negocio, no de horas trabajadas.

    ¿Qué nicho de SaaS tiene más demanda en 2026?

    Los que más estoy viendo: automatización de procesos administrativos para pymes, herramientas de generación y gestión de contenido, y dashboards de consolidación de datos para equipos pequeños que no pueden permitirse soluciones enterprise. Ninguno es glamuroso. Todos tienen clientes dispuestos a pagar.

    ¿Puedo hacer las tres cosas a la vez desde el principio?

    Técnicamente sí, pero no lo recomiendo. Intentar hacer tres cosas a la vez en paralelo garantiza que ninguna llegue a ningún sitio. Elige una, ponla a funcionar, y cuando genere ingreso estable — aunque sea pequeño — añade la siguiente. La consistencia gana a la ambición dispersa.

    ¿Con qué nivel técnico se puede empezar?

    Para los cursos: nivel intermedio-senior con al menos 3-4 años de experiencia en un área concreta. Para el SaaS con IA: igual — necesitas criterio técnico para tomar decisiones de arquitectura, la IA no las toma por ti. Para la consultoría: cuanto más experiencia tengas en sistemas reales, más valor puedes ofrecer.

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

  • Algoritmos de machine learning que todo developer web debería entender

    Algoritmos de machine learning que todo developer web debería entender

    Hace un año integré una búsqueda semántica en un proyecto SaaS. El cliente quería que los usuarios encontraran artículos aunque escribieran con sinónimos, con errores ortográficos, o en un idioma distinto al del contenido.

    La solución: tres líneas de TypeScript llamando a algoritmos de machine learning vía la API de OpenAI. Funcionó en una tarde.

    Pero el cliente preguntó algo que me dejó sin respuesta inmediata: "¿Qué hace exactamente ese modelo por dentro?". Y yo, con 15 años de experiencia en desarrollo, tuve que admitir que no tenía una respuesta clara más allá de "convierte texto en números".

    Ese hueco me molestó. No porque necesitara implementar los algoritmos desde cero, sino porque cuando no entiendes qué hay debajo del capó, tomas peores decisiones: eliges el modelo equivocado, debuggeas en la dirección incorrecta, o diseñas una arquitectura que no escala.

    Este post es lo que me hubiera gustado leer ese día. Los algoritmos de machine learning explicados para developers web — sin fórmulas, sin Python, sin pretender que vas a ser data scientist.

    Tres familias que lo explican todo

    Los algoritmos de machine learning son procedimientos que permiten a un sistema aprender patrones a partir de datos, sin que un programador defina explícitamente las reglas. En lugar de escribir if (spam) { ... }, le muestras miles de emails al modelo y él deduce las reglas solo.

    Hay tres formas fundamentales en que ocurre ese aprendizaje:

    Aprendizaje supervisado. Le das al modelo ejemplos con respuesta correcta. "Este email es spam. Este otro no lo es." El modelo aprende el patrón. Cuando llega un email nuevo, predice a cuál categoría pertenece. Úsalo cuando tienes datos etiquetados y una tarea de predicción o clasificación concreta.

    Aprendizaje no supervisado. No hay respuestas correctas. Le das datos sin etiquetar y el modelo encuentra estructura por sí solo. "Estos usuarios tienen comportamiento parecido. Estos otros también. Hay tres grupos." Úsalo cuando quieres descubrir patrones que no conoces de antemano — clustering de usuarios, detección de anomalías.

    Reinforcement learning. El modelo aprende por ensayo y error: hace una acción, recibe una recompensa o penalización, ajusta. Es cómo funcionan los modelos de juegos, pero también cómo se afinan los LLMs para que sus respuestas sean más útiles (RLHF — Reinforcement Learning from Human Feedback).

    Con esto en mente, los algoritmos concretos tienen contexto.

    Los algoritmos de machine learning que te importan como developer

    Resumen antes de entrar en detalle — ninguno lo vas a implementar tú:

    Algoritmo Tipo Cuándo lo usas en web ¿Lo implementas?
    Regresión logística Supervisado Scoring, predicción de churn No — API
    Random Forest Supervisado Moderación, detección de fraude No — API
    K-Means No supervisado Clustering de usuarios No — API
    Redes neuronales Supervisado Base de embeddings, clasificación No — modelos preentrenados
    Embeddings Supervisado Búsqueda semántica, recomendaciones No — OpenAI/HuggingFace
    Transformers Supervisado LLMs, generación, clasificación avanzada No — API

    Regresión lineal y logística

    Son los más simples. La regresión lineal predice un número: "¿Cuánto va a costar este apartamento?" La logística predice una probabilidad: "¿Hay un 87% de probabilidad de que este usuario cancele su suscripción este mes?"

    No las vas a implementar, pero las vas a encontrar en APIs de scoring, en features de predicción de churn, en sistemas de precios dinámicos. Cuando una API te devuelve un score: 0.87, probablemente hay una regresión logística detrás.

    Árboles de decisión y Random Forest

    Imagina una serie de preguntas de sí/no encadenadas. "¿El usuario tiene más de 30 días de cuenta? ¿Ha hecho al menos una compra? ¿Abrió el último email?" Cada camino lleva a una predicción. Eso es un árbol de decisión.

    Random Forest toma cientos de árboles distintos y combina sus respuestas. El resultado es más robusto y menos propenso a overfitting que un solo árbol.

    Son los algoritmos detrás de sistemas de moderación de contenido basados en reglas aprendidas, de detección de fraude, de sistemas de recomendación básicos.

    K-Means (clustering)

    K-Means agrupa datos en K clusters. Tú dices cuántos grupos quieres (K), el algoritmo encuentra cuáles puntos de datos pertenecen a cada grupo.

    Como developer web, esto aparece en sistemas de personalización: "Usuarios que actúan como tú también compraron esto." No hay etiquetas previas — el modelo descubre los segmentos solo.

    Redes neuronales

    Aquí empieza lo que la gente llama "deep learning". Una red neuronal es una cadena de capas matemáticas que transforman una entrada (texto, imagen, audio) en una salida (una clasificación, un número, un vector).

    Lo importante para entenderlas no es la matemática — es el concepto de representación. Cada capa aprende a representar la entrada de una forma más abstracta que la anterior. La primera capa de un modelo de visión detecta bordes. La siguiente detecta formas. La siguiente detecta objetos. Ningún programador definió esas representaciones: emergieron del entrenamiento.

    Embeddings — el algoritmo que ya usas

    Los embeddings son el resultado de pasar texto (o imágenes, o audio) por una red neuronal especializada. La salida es un vector de números — típicamente de 768 a 3072 dimensiones.

    La magia es que los vectores capturan significado semántico. "Perro" y "can" producen vectores muy cercanos en ese espacio de alta dimensión. "Perro" y "hipoteca" producen vectores lejanos.

    Esto es lo que permite la búsqueda semántica: conviertes tu query en un vector, comparas contra los vectores de tu base de datos, y devuelves los más cercanos. No importa si el usuario escribió "gato" y el documento dice "felino" — los vectores están cerca.

    Transformers — la arquitectura detrás de los LLMs

    Un Transformer es una arquitectura de red neuronal diseñada para procesar secuencias. El mecanismo clave se llama "atención" (attention): permite que el modelo, al procesar una palabra, preste atención a otras palabras del contexto según su relevancia.

    "El banco estaba lleno de peces" vs "El banco rechazó mi solicitud". La misma palabra "banco", significado completamente distinto. El mecanismo de atención resuelve esto mirando el contexto completo de la frase.

    GPT, Claude, Llama y Gemini usan Transformers como arquitectura base. Los modelos de embeddings de OpenAI también son Transformers, pero optimizados para producir buenas representaciones vectoriales en lugar de generar texto.

    Cuándo le importan al developer web

    No necesitas un data scientist para beneficiarte de ML. Estas son las integraciones más comunes en proyectos web reales. Puedes ver más ejemplos aplicados en el blog de Dominicode.

    Búsqueda semántica. Reemplaza o complementa la búsqueda por palabras clave. Los embeddings convierten queries y documentos en vectores, y una base de datos vectorial (Pinecone, pgvector, Supabase Vector) hace el matching por similitud coseno.

    Moderación de contenido. Clasifica si un texto es tóxico, si una imagen es apropiada, si un comentario viola normas. HuggingFace tiene modelos de clasificación listos para usar via API — zero setup del lado del ML.

    Recomendaciones. Clustering de usuarios por comportamiento o embeddings de productos para "productos similares". No necesitas construir un sistema de recomendación desde cero — embeddings + similitud coseno es suficiente para empezar.

    Extracción de información. Parsear emails, facturas, formularios en lenguaje natural. Un LLM con un prompt bien estructurado hace esto mejor que cualquier regex que vayas a escribir.

    TypeScript en la práctica

    Aquí es donde todo esto se vuelve concreto. No vas a implementar K-Means. Vas a llamar a una API que usa K-Means internamente. Pero entender qué hace el algoritmo te ayuda a saber qué esperar y qué debuggear.

    Embeddings con OpenAI

    import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function getEmbedding(text: string): Promise<number[]> {
  const response = await client.embeddings.create({
    model: "text-embedding-3-small",
    input: text,
  });

  return response.data[0].embedding; // Vector de 1536 dimensiones
}

// Similitud coseno entre dos vectores
function cosineSimilarity(a: number[], b: number[]): number {
  const dot = a.reduce((sum, val, i) => sum + val * b[i], 0);
  const magA = Math.sqrt(a.reduce((sum, val) => sum + val * val, 0));
  const magB = Math.sqrt(b.reduce((sum, val) => sum + val * val, 0));
  return dot / (magA * magB);
}

// Búsqueda semántica básica
// En producción: usar batching o rate limiting para evitar errores 429 de la API
async function semanticSearch(query: string, documents: string[]) {
  const queryVector = await getEmbedding(query);
  const docVectors = await Promise.all(documents.map(getEmbedding));

  const scores = docVectors.map((vec, i) => ({
    document: documents[i],
    similarity: cosineSimilarity(queryVector, vec),
  }));

  return scores.sort((a, b) => b.similarity - a.similarity);
}

const docs = [
  "Cómo configurar un servidor NestJS",
  "Recetas de cocina italiana",
  "Deploying Node.js to production",
];

const results = await semanticSearch("backend con Node", docs);
console.log(results[0]); // { document: "Deploying Node.js...", similarity: 0.89 }

    Referencia oficial: OpenAI Embeddings API.

    Clasificación con HuggingFace Inference API

    const HF_TOKEN = process.env.HF_TOKEN;
const MODEL = "cardiffnlp/twitter-roberta-base-sentiment-latest";

interface ClassificationResult {
  label: string;
  score: number;
}

async function classifySentiment(text: string): Promise<ClassificationResult[]> {
  const response = await fetch(
    `https://api-inference.huggingface.co/models/${MODEL}`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${HF_TOKEN}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ inputs: text }),
    }
  );

  // Si el modelo lleva tiempo sin uso, la primera respuesta puede tardar
  // 20-30 segundos con { error: "Model is currently loading" } — reintentar.
  const data = await response.json();
  return data[0] as ClassificationResult[];
}

const result = await classifySentiment("Este producto es increíble!");
// [{ label: "POSITIVE", score: 0.97 }, { label: "NEUTRAL", score: 0.02 }, ...]

if (result[0].label === "NEGATIVE" && result[0].score > 0.85) {
  // Marcar para revisión manual
}

    Referencia oficial: HuggingFace Inference API.

    Dos ejemplos, dos APIs reales, cero instalación de librerías de ML. El algoritmo corre en la nube. Tú consumes el resultado y construyes producto.

    Si quieres explorar estas integraciones dentro de un flujo completo — desde la idea hasta el producto funcionando — en el curso Construye con IA cubrimos exactamente esta capa: cómo conectar modelos de ML reales a una arquitectura de producto sin convertirte en data scientist. También publicamos tutoriales y ejemplos en el canal de YouTube de Dominicode.

    La decisión que cambia todo

    Entender estos algoritmos no significa que vayas a entrenar modelos. Significa que cuando eliges entre una búsqueda por palabras clave y una búsqueda semántica, sabes exactamente qué estás eligiendo y por qué.

    Significa que cuando un modelo de clasificación te devuelve un score bajo, sabes si el problema está en el modelo, en los datos de entrada, o en cómo estás interpretando el output.

    Significa que cuando alguien en tu equipo dice "usemos ML para esto", puedes hacer las preguntas correctas: ¿supervisado o no supervisado? ¿Tienes datos etiquetados? ¿Qué métrica defines como éxito?

    Los modelos los entrenan los data scientists. El producto lo construyes tú. Saber qué hay debajo del capó es lo que hace la diferencia entre un developer que consume IA y uno que la integra de forma inteligente.

    En Dominicode Labs tenemos proyectos completos donde aplicamos estas integraciones en contextos reales — búsqueda semántica, pipelines con embeddings, agentes que usan clasificadores como herramientas. Si quieres ver el código funcionando, es donde empieza.

    FAQ

    ¿Necesito saber matemáticas para usar algoritmos de machine learning como developer?

    No para usarlos, sí para entenderlos en profundidad. La mayoría de las integraciones que harás como developer web consumen modelos ya entrenados via API. Saber qué hace el algoritmo — qué tipo de problema resuelve y qué output produce — es suficiente para tomar buenas decisiones de arquitectura. Si en algún momento necesitas afinar un modelo o interpretar métricas de entrenamiento, entonces sí vale la pena profundizar en la matemática.

    ¿Cuál es la diferencia entre un LLM y un modelo de embeddings?

    Un LLM (como GPT-4 o Claude) está entrenado para generar texto: toma una secuencia de tokens y predice los siguientes. Un modelo de embeddings está optimizado para producir representaciones vectoriales del texto, capturando su significado semántico en un espacio de alta dimensión. Ambos usan arquitectura Transformer, pero con objetivos de entrenamiento distintos. Para búsqueda semántica, usa modelos de embeddings — son más baratos y específicos para esa tarea.

    ¿Cuándo debería usar TensorFlow.js en lugar de una API de ML?

    TensorFlow.js tiene sentido cuando necesitas ejecutar inferencia en el cliente (sin enviar datos al servidor, por privacidad), cuando tienes latencia muy baja como requisito, o cuando quieres evitar costos de API a escala. El tradeoff es que los modelos disponibles para el navegador son más pequeños y menos potentes. Para la mayoría de proyectos web, una API de HuggingFace o OpenAI es la opción correcta hasta que tengas una razón específica para moverse al cliente.

    ¿Qué es el overfitting y por qué le importa al developer que consume modelos?

    El overfitting ocurre cuando un modelo aprende demasiado bien los datos de entrenamiento y pierde capacidad de generalizar a datos nuevos. Como developer que consume un modelo ya entrenado, el overfitting se manifiesta como comportamiento inesperado: el modelo funciona bien en ejemplos estándar pero falla en casos edge de tu dominio específico. Si ves esto, la solución no es ajustar el código — es cambiar de modelo, hacer fine-tuning, o cambiar cómo preparas el input (prompt engineering, preprocesado de texto).

    ¿Qué base de datos debo usar para guardar y consultar embeddings?

    Depende de tu stack. Si ya usas PostgreSQL o Supabase, la extensión pgvector añade soporte nativo para búsqueda por similitud coseno sin infraestructura adicional. Si necesitas escala masiva (millones de vectores con latencia sub-50ms), Pinecone o Weaviate son las opciones especializadas. Para prototipos o proyectos pequeños, guardar vectores en memoria con una búsqueda lineal es perfectamente válido mientras no superes los 10k documentos.

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

  • Claude API: Crash Course para developers con TypeScript

    Claude API: Crash Course para developers con TypeScript

    Hace unos meses un developer me escribió frustrado. Llevaba dos días intentando integrar Claude en su app. No le funcionaba el streaming, no entendía por qué sus respuestas llegaban cortadas, y había probado tres ejemplos distintos de Stack Overflow que usaban versiones diferentes del SDK.

    El problema no era la API. Era que había empezado por el medio.

    Esta es la Claude API introducción que yo habría querido tener al principio: sin rodeos, con código real, y con el orden correcto para entender qué está pasando antes de que algo falle.

    Qué es la Claude API y por qué te importa

    Claude es el modelo de lenguaje de Anthropic. La API te da acceso directo a ese modelo desde tu código: puedes enviarle mensajes, pedirle que razone, que use herramientas externas, que responda en streaming o que procese imágenes.

    La diferencia respecto a ChatGPT para developers es principalmente la calidad del razonamiento en tareas de código complejas y el system prompt — Claude lo sigue con una precisión que cambia cómo construyes agentes.

    Setup: API key y SDK

    Primero necesitas una cuenta en console.anthropic.com. Una vez dentro, ve a API Keys y genera una nueva clave. Guárdala — no la vuelves a ver.

    Instala el SDK oficial con npm o Bun:

    npm install @anthropic-ai/sdk
# o con Bun
bun add @anthropic-ai/sdk

    Guarda la clave en una variable de entorno. Nunca en el código:

    # .env
ANTHROPIC_API_KEY=sk-ant-...

    Tu primera llamada en TypeScript

    Este es el "Hello World" de la Claude API. Sin clases, sin abstracción, directo al grano:

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

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

async function main() {
  const response = await client.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    messages: [
      {
        role: "user",
        content: "Explica qué es un closure en JavaScript en 2 líneas.",
      },
    ],
  });

  console.log(response.content[0].type === "text" ? response.content[0].text : "");
}

main();

    Eso es todo. Ejecutas esto y tienes una respuesta de Claude en tu terminal.

    Lo que necesitas entender de la estructura:

    • model — qué versión de Claude usas (más sobre esto abajo)
    • max_tokens — límite de tokens en la respuesta (no el total de la conversación)
    • messages — array de turnos de conversación con role: "user" o role: "assistant"

    Los conceptos que no puedes ignorar

    Modelos disponibles

    Anthropic tiene tres familias activas:

    Modelo Cuándo usarlo
    claude-sonnet-4-6 El equilibrio perfecto: velocidad + calidad. Mi default para casi todo.
    claude-haiku-4-5 Más rápido y barato. Bueno para tareas simples o llamadas en volumen.
    claude-opus-4-8 El más potente. Para tareas de razonamiento complejo donde el coste no es el problema.

    Si estás empezando, usa claude-sonnet-4-6. No pienses más.

    System prompt vs User message

    El system es la personalidad y las instrucciones permanentes de Claude. El user es lo que cambia en cada turno.

    const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  system: "Eres un reviewer de código senior. Responde siempre en español. Sé directo y señala el problema antes de proponer la solución.",
  messages: [
    {
      role: "user",
      content: "Revisa esta función: function add(a, b) { return a - b; }",
    },
  ],
});

    El system prompt es donde ocurre la mayor parte de la magia cuando construyes agentes. Si quieres ver cómo llevamos esto a proyectos reales con Claude Code, en el curso Construye con IA cubrimos exactamente eso: de la idea al producto con agentes que siguen instrucciones de producción.

    Tokens: lo que cuesta dinero

    Un token es aproximadamente 0,75 palabras en inglés (algo menos en español). La API te cobra por input_tokens (lo que envías) y output_tokens (lo que Claude responde).

    Después de cada llamada puedes ver el uso:

    console.log(response.usage);
// { input_tokens: 48, output_tokens: 312 }

    max_tokens limita la respuesta, no la llamada completa. Si pones max_tokens: 100 y la respuesta necesita 200 tokens, Claude cortará el texto a mitad. Es uno de los errores más comunes al empezar.

    ¿Cómo implementar streaming con la Claude API en TypeScript?

    Sin streaming, esperas a que Claude termine de generar toda la respuesta antes de recibirla. Con streaming, recibes los tokens a medida que se generan — igual que ves escribir a Claude en el chat web.

    Para UX en tiempo real, el streaming no es opcional. Es lo que distingue una app que se siente viva de una que "se congela" tres segundos antes de mostrar algo. En los proyectos de agentes que construimos en Labs, migrar de llamada síncrona a streaming eliminó la necesidad de un loader — los usuarios percibieron la respuesta como inmediata sin que cambiáramos nada más.

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

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

async function streamResponse() {
  const stream = await client.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    stream: true,
    messages: [
      {
        role: "user",
        content: "Escribe un test unitario en TypeScript para una función que suma dos números.",
      },
    ],
  });

  for await (const event of stream) {
    if (
      event.type === "content_block_delta" &&
      event.delta.type === "text_delta"
    ) {
      process.stdout.write(event.delta.text);
    }
  }

  console.log("\n--- Stream completado ---");
}

streamResponse();

    El loop for await itera sobre los eventos del stream. El tipo que te importa es content_block_delta con delta.type === "text_delta" — ahí está el texto.

    ¿Qué es el tool use en Claude API y cómo funciona?

    Tool use (o function calling) permite que Claude llame a funciones definidas por ti. Claude decide cuándo usarlas y con qué argumentos. Tú ejecutas la función y le devuelves el resultado.

    El siguiente ejemplo define una herramienta get_weather ficticia:

    const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  tools: [
    {
      name: "get_weather",
      description: "Obtiene el tiempo actual para una ciudad.",
      input_schema: {
        type: "object",
        properties: {
          city: {
            type: "string",
            description: "El nombre de la ciudad.",
          },
        },
        required: ["city"],
      },
    },
  ],
  messages: [
    {
      role: "user",
      content: "¿Qué tiempo hace en Madrid ahora mismo?",
    },
  ],
});

// Si Claude quiere usar la herramienta, el stop_reason será "tool_use"
if (response.stop_reason === "tool_use") {
  const toolUse = response.content.find((b) => b.type === "tool_use");
  console.log("Claude quiere llamar a:", toolUse?.name);
  console.log("Con argumentos:", toolUse?.input);
  // Aquí ejecutarías la función real y devolverías el resultado a Claude
}

    Esto es la base de cualquier agente. Claude no ejecuta código — tú lo ejecutas y le informas del resultado. El loop de razonamiento lo controla Claude; la ejecución la controlas tú. Si quieres ver cómo este patrón escala a un pipeline completo — desde un ticket de Jira hasta el deploy —, tienes el ejemplo en el post sobre automatizar el proceso de desarrollo con IA.

    Errores comunes al empezar

    Rate limits. La API tiene límites por minuto tanto en requests como en tokens. Si los golpeas, recibes un 429. Solución: exponential backoff o usar Haiku para prototipos de alto volumen.

    Context window agotado. Cada modelo tiene un límite de tokens totales en conversación (input + output). Sonnet 4.6 tiene 200K tokens de context window — es enorme, pero si metes archivos enteros en cada llamada, lo llenas. Sé selectivo con lo que incluyes en el contexto.

    Formato de mensajes incorrecto. El array messages debe alternar user y assistant. No puedes tener dos mensajes de user seguidos sin un assistant entre medias. Eso devuelve un error 400.

    max_tokens demasiado bajo. Si la respuesta se corta, sube max_tokens. El valor por defecto no existe — es un parámetro obligatorio. Empieza con 1024 y ajusta según lo que necesites.

    Variables de entorno no cargadas. Si ves AuthenticationError, casi siempre es que ANTHROPIC_API_KEY no está disponible en el proceso. Verifica con console.log(process.env.ANTHROPIC_API_KEY) antes de depurar nada más.

    Qué explorar después

    Una vez tienes la llamada básica y el streaming funcionando, estos son los siguientes pasos lógicos:

    Vision. Puedes enviar imágenes en el array content y Claude las analiza. Útil para screenshots, diagramas, facturas.

    Embeddings. Anthropic no tiene embeddings propios en la API, pero Claude funciona muy bien combinado con embeddings de OpenAI o Cohere para búsqueda semántica.

    Batch API. Para procesar cientos de prompts sin necesidad de respuesta en tiempo real. Hasta un 50% más barato que llamadas individuales.

    Workbench de Anthropic. En console.anthropic.com tienes un playground para probar prompts, comparar modelos y ver el uso de tokens antes de escribir una sola línea de código. Es la herramienta que más uso al diseñar system prompts.

    Multiturno real. Construir una conversación que mantenga contexto entre turnos requiere gestionar el array messages manualmente — añadir cada respuesta de Claude como role: "assistant" y cada input del usuario como role: "user". No hay estado en la API.

    Si quieres ver tool use aplicado a un workflow de code review automático antes de un PR, tienes el flujo completo en el post sobre agentic code review con Claude Code.

    Si tuvieras que elegir solo un área para explorar después del streaming, elige Vision — es el salto de ROI más rápido y el que más impacto tiene en una demo.

    FAQ

    ¿Necesito tarjeta de crédito para empezar?
    Sí. Anthropic requiere un método de pago para activar la API, pero tiene un tier de prueba con crédito gratuito. Puedes hacer cientos de llamadas de desarrollo sin pagar nada en los primeros días.

    ¿Cuál es la diferencia entre la API de Claude y Claude.ai?
    Claude.ai es el producto de consumo (el chat web). La API es el acceso programático al modelo. Tienen facturación y cuentas separadas. Una suscripción a Claude.ai no te da acceso a la API.

    ¿Cuánto cuesta en producción?
    Depende del modelo y el volumen. Claude Sonnet 4.6 está alrededor de $3 por millón de input tokens y $15 por millón de output tokens — verifica siempre en anthropic.com/pricing antes de hacer estimaciones de arquitectura, los precios se actualizan con cada generación de modelo.

    ¿Puedo usar la API en el frontend directamente?
    Técnicamente sí, pero nunca deberías. La API key quedaría expuesta en el cliente. Siempre llama a la API desde un backend o un serverless function que tú controlas.

    ¿Qué pasa si Claude no termina la respuesta y stop_reason no es end_turn?
    Si stop_reason es max_tokens, la respuesta se cortó por el límite que pusiste. Si es tool_use, Claude quiere ejecutar una herramienta. Si es stop_sequence, alcanzó una secuencia de parada que definiste. Valida siempre stop_reason en producción.

    Si quieres ver todo esto aplicado en un proyecto real — no en ejemplos de tutorial sino en un producto con usuarios — en Dominicode Labs tenemos el código de los proyectos que construimos en directo, incluyendo agentes con tool use y streaming. Es donde llevamos la teoría a producción.

    Y si prefieres el formato video con más ejemplos en directo, en el canal de YouTube de Dominicode cubrimos estas integraciones con frecuencia.

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