Author: Dominicode

  • Guía para migrar funciones Edge y simplificar autenticación en Supabase

    Guía para migrar funciones Edge y simplificar autenticación en Supabase

    npm install @supabase/server@latest y npx skills add supabase/server: guía práctica para migrar Edge Functions, Hono y agentes IA

    Tiempo estimado de lectura: 4 min

    • Reduce boilerplate de autenticación gracias a un modelo declarativo y SupabaseContext por petición.
    • Automatiza migraciones con agentes usando npx skills add supabase/server para dar contexto y patrones a agentes de código.
    • Flujo incremental y seguro: withSupabase para la mayoría de endpoints; primitives o createSupabaseContext para casos complejos.
    • Soporta rotación de claves y despliegues controlados con variables plurales y canary deploys.

    Introducción

    npm install @supabase/server@latest y npx skills add supabase/server son las dos acciones que debes ejecutar si quieres adoptar el nuevo flujo de trabajo de Supabase: un paquete que elimina el boilerplate de autenticación y un “skill” que da contexto a agentes de código. En las primeras líneas: estos comandos son el punto de partida para migrar funciones Edge, automatizar refactors con agentes y levantar APIs Hono seguras en minutos.

    Resumen rápido (lectores con prisa)

    Instala @supabase/server para obtener contexto de autenticación y clientes por petición. Añade el skill supabase/server para que agentes de código puedan identificar y actualizar inicializaciones antiguas. Usa withSupabase para la mayoría de endpoints; recurre a primitives o createSupabaseContext para casos compuestos.

    npm install @supabase/server@latest — qué instala y qué te da

    Instalar @supabase/server provoca algo más que añadir una dependencia: introduce un modelo declarativo para control de acceso y un SupabaseContext listo para usar. Tras la instalación obtienes primitives y wrappers que:

    • Verifican JWT asimétricos sin jose/JWKS manual.
    • Inicializan dos clientes por petición: ctx.supabase (usuario, respeta RLS) y ctx.supabaseAdmin (service role).
    • Inyectan userClaims, jwtClaims y authMode en el contexto.
    • Ofrecen withSupabase (wrapper), createSupabaseContext (imperativo) y primitives en @supabase/server/core.

    Documentación oficial: Documentación oficial y repo: Repositorio en GitHub

    npx skills add supabase/server — por qué lo necesitas si usas agentes

    npx skills add supabase/server alimenta a herramientas como Claude Code, Codex o Cursor con la superficie de la API, patrones de adaptadores y rutas de migración. Resultado práctico: un agente puede escanear tu repo, identificar inicializaciones antiguas, reemplazarlas por withSupabase y migrar claves a las nuevas variables sin equivocarse.

    Prompts útiles (ejemplos que puedes dar al agente):

    • “Analyze all Edge Functions and plan a full migration to use the new API keys with @supabase/server”
    • “Scaffold a Hono REST API with CRUD for todos using per-route auth”
    • “Create an Edge Function that accepts user or secret auth, reads profile with RLS and writes audit logs with admin client”

    Plan de migración: pasos prácticos y ordenados

    1. Auditoría rápida

    Busca patrones repetidos (creación de clientes, verificación JWT, _shared/*.ts).

    2. Añade la dependencia e instala el skill

    Ejecuta los comandos:

    npm install @supabase/server@latest
    npx skills add supabase/server

    3. Sustitución incremental

    • Reemplaza inicializaciones manuales por withSupabase({ auth }) en funciones individuales.
    • Para funciones multifunción, usa createSupabaseContext o primitives (verifyAuth, createContextClient).

    4. Variables de entorno

    Cambia a formas plurales si es necesario: SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS (soporta rotación). Valida inyección en plataformas (Supabase CLI, Vercel, Cloudflare).

    5. Test y rollout

    • Tests unitarios sobre handlers con contexto mockeado.
    • Canary deploy para funciones críticas.

    6. Limpieza

    • Elimina utilidades compartidas de verificación JWT (ya no necesarias).
    • Actualiza docs internas y runbooks.

    Ejemplo rápido: Hono + withSupabase (CRUD /todos)

    El adaptador Hono inyecta el contexto en c.var.supabaseContext:

    import { withSupabase } from '@supabase/server/adapters/hono'
    import { Hono } from 'hono'
    
    const app = new Hono()
    
    app.get('/todos', withSupabase({ auth: 'user' }), async (c) => {
      const { supabase } = c.var.supabaseContext
      const { data } = await supabase.from('todos').select()
      return c.json(data)
    })
    
    export default { fetch: app.fetch }

    Per-route auth es explícito y visible en la firma: mantenimiento y auditoría mucho más sencillos.

    Edge Function protegida con operaciones admin (patrón recomendado)

    Cuando necesitas dual-mode auth (usuario o secret) y escribir logs de auditoría:

    • Declara auth: ['user','secret'].
    • Usa ctx.supabase para lecturas que respetan RLS.
    • Usa ctx.supabaseAdmin para escribir auditoría o tareas privilegiadas.

    Si necesitas control imperativo sobre errores, usa createSupabaseContext:

    import { createSupabaseContext } from 'npm:@supabase/server'
    
    const { data: ctx, error } = await createSupabaseContext(req, { auth: ['user','secret'] })
    if (error) return Response.json({ error: error.message }, { status: error.status })

    Recomendaciones prácticas y criterios técnicos

    • Prioriza withSupabase para la mayoría de endpoints: claridad y seguridad por defecto.
    • Usa primitives solo cuando debas combinar múltiples auth en una función o manipular headers de forma estricta.
    • Aprovecha npx skills para automatizar auditoría y migración; reduce errores humanos en refactors masivos.
    • Mantén tests que mockeen SupabaseContext para evitar dependencia de la red en unit tests.
    • Revisa el repo y docs oficiales para edge-cases y actualizaciones: Repositorio en GitHub y Documentación oficial

    Conclusión

    Instalar @supabase/server y añadir el skill cambia la ergonomía del backend: elimina la repetición, reduce superficie de ataque y hace tus funciones Edge predecibles para humanos y agentes por igual. Empieza migrando funciones críticas con canary deploys, automatiza el resto con el skill y conserva primitives para los casos realmente especiales. El resultado: menos fontanería, más foco en la lógica que aporta valor.

    Mención: Dominicode Labs

    Si estás planificando automatizaciones o migraciones con agentes, puede resultar útil ver recursos y experimentos aplicados a workflows y agentes. Más información y proyectos relacionados en Dominicode Labs.

    FAQ

    Respuesta: Instalar @supabase/server introduce un modelo declarativo de control de acceso y un SupabaseContext por petición, con clientes ctx.supabase y ctx.supabaseAdmin, verificación de JWT asimétrica y utilidades como withSupabase y createSupabaseContext.

    Respuesta: npx skills add supabase/server aporta la superficie de la API y patrones a agentes de código, permitiendo que escaneen repos, identifiquen inicializaciones antiguas y automaticen refactors de forma segura.

    Respuesta: Cambia a variables plurales como SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS para soportar rotación. Valida la inyección en plataformas como Supabase CLI, Vercel o Cloudflare antes del despliegue.

    Respuesta: Usa withSupabase por defecto para claridad y seguridad. Emplea createSupabaseContext o primitives cuando necesites combinar múltiples modos de auth en una sola función o manipular headers de forma estricta.

    Respuesta: Escribe tests unitarios que mockeen el SupabaseContext para evitar llamadas de red. Realiza canary deploys para funciones críticas antes del rollout completo.

    Respuesta: Sí: una vez migradas las funciones a @supabase/server, las utilidades compartidas de verificación JWT que replican lógica ya gestionada por el paquete dejan de ser necesarias y pueden eliminarse tras validar el comportamiento.

  • Comparativa técnica de Agentic Harness: Claude Code, Cursor y más

    Comparativa técnica de Agentic Harness: Claude Code, Cursor y más

    Agentic Harness comparado — Claude Code vs Cursor vs Codex CLI vs Aider vs Cline

    Tiempo estimado de lectura: 6 min

    • Un agentic harness convierte un LLM en un actor sobre tu repo: necesita contexto eficiente, aplicación segura de cambios y bucles de verificación.
    • Elige la herramienta según dominio: Cursor para UI y revisión visual, Aider para refactors y auditabilidad, Claude Code para pipelines, Cline para acceso a infra, Codex/Copilot CLI para utilidades tácticas.
    • Prioriza: context slicing (RAG/AST), rollback y trazabilidad, integración CI/CD, permisos/extensibilidad y observabilidad.
    • Gobernanza: define qué puede hacer el agente sin revisión, qué debe proponer como PR y cómo auditar acciones.

    El desarrollo asistido por IA dejó de ser un experimento cuando los equipos empezaron a pedir algo concreto: no sólo sugerencias, sino ejecución fiable. Aquí tienes un análisis técnico y accionable de Agentic Harness comparado — Claude Code vs Cursor vs Codex CLI vs Aider vs Cline, pensado para Tech Leads y equipos reales que deben decidir estrategia, integraciones y límites de autonomía.

    Resumen rápido (lectores con prisa)

    Un agentic harness es la capa que permite a un LLM operar sobre un repositorio con seguridad y trazabilidad.

    Úsalo cuando necesites ejecutar cambios repetibles, verificables y revertibles — no sólo sugerencias.

    Elige según dominio: UI (Cursor), refactor/legacy (Aider), pipelines/infra (Claude Code), acceso a infra interna (Cline).

    Prioriza RAG/AST para contexto, commits/diffs para trazabilidad y bucles de tests para verificación.

    Agentic Harness comparado — por qué importa y qué debes exigirle

    Un agentic harness no es un plugin bonito: es la capa que convierte un LLM en un actor capaz de operar sobre tu repo. A nivel técnico debe resolver tres problemas simultáneos:

    • Resolución de contexto: indexación del repo + selección de snippets relevantes (RAG, AST-aware slicing).
    • Aplicación segura de cambios: diffs atómicos, commits, PRs y rollback.
    • Bucle de verificación: pruebas, linters y reintentos automáticos leyendo stderr/exit codes.

    Si la herramienta que evalúas no cubre esas tres piezas de forma explícita, la estás usando como un asistente, no como un agente.

    Resumen rápido de cada harness

    Cursor — editor visual AI-first

    Cursor es un fork de VS Code que trae IA integrada a la experiencia del editor. Su valor es UX: Composer permite editar múltiples archivos en contexto y previsualizar diffs antes de aplicar. Técnica clave: contexto calculado desde archivos abiertos y navegación del cursor, útil para producción de features frontend donde la verificación visual es crítica. URL: Cursor

    Cuándo elegirlo: equipos Full Stack que quieren control visual y revisión humana inmediata. Fricción: migración de editor.

    Claude Code — CLI para razonamiento extendido

    Claude Code (Anthropic) es un CLI pensado para ejecución en terminal. Diseñado para Claude 3.7 con extended thinking, ejecuta bucles autónomos: corre tests, inspecciona logs y corrige iterativamente. Técnica clave: integración terminal-native y capacidad de manejar workflows en CI/CD. URL: Claude Code docs

    Cuándo elegirlo: backend, infra y pipelines automatizados donde no necesitas UI pero sí razonamiento arquitectónico.

    Aider — control Git como seguridad

    Aider es Open Source y opera en CLI con filosofía “Git-first”: cada cambio satisfactorio produce un commit automático. Técnica clave: mapeo del repo vía AST para minimizar el contexto enviado al modelo y trazabilidad total mediante commits. URL: Aider

    Cuándo elegirlo: repos grandes, legacy codebases y equipos que exigen revertibilidad y auditoría precisa.

    Cline — extensión VS Code con MCP

    Cline implementa MCP (Model Context Protocol) y permite que el agente consulte servicios externos (DBs, docs internas) antes de escribir código. Técnica clave: permisos explícitos por acción y extensibilidad mediante MCP. URL: Cline

    Cuándo elegirlo: organizaciones con infra y APIs internas que quieren que el agente actúe con contexto real y seguro.

    Codex CLI / Copilot CLI — utilidades tácticas

    Herramientas como Codex CLI o Copilot CLI están enfocadas en traducir NL a comandos de terminal. Útiles para scripting y tareas puntuales, no para refactorizaciones autónomas: carecen del bucle iterativo sobre el repo. Recurso: Codex (OpenAI)

    Cuándo elegirlo: tareas de DevOps ad-hoc, scripting, comandos complejos — no para “delega la refactorización”.

    Criterios técnicos para elegir

    1. Context slicing: ¿la herramienta usa RAG o análisis AST para minimizar tokens? Si no, pagarás tokens y recibirás ruido.
    2. Rollback y trazabilidad: commits automáticos + mensajes generados por IA (Aider) vs diffs aprobados por UI (Cursor). Decide si prefieres control humano o commits automáticos.
    3. Integración CI/CD: ¿el harness puede operar en pipelines sin UI y corregir builds? Claude Code brilla aquí.
    4. Extensibilidad y permisos: MCP (Cline) permite consultas reales a infra interna; obligatorio si necesitas que el agente lea DBs o docs privadas.
    5. Observabilidad y métricas: tokens, fallos de parseo, reintentos y coste por sesión. Sin métricas no puedes gobernar autonomía.

    Ejemplos prácticos

    • Refactorización de API en un monorepo grande: usa Aider por AST-mapping + commits automáticos. Revertir es simple y el contexto es eficiente.
    • Corregir fallo en CI que rompe build: lanza Claude Code en la pipeline; ejecutará tests, leerá logs y propondrá patches iterativos.
    • Añadir componente UI y actualizar rutas: Cursor acelera al mostrar previews y permitir aceptar diffs por pantalla.
    • Integración con servicio interno (consulta de esquema DB antes de generar ORM): Cline + MCP para consultas reales antes de generar código.

    Recomendación práctica para equipos

    No hay una sola herramienta “mejor”. La arquitectura razonable es híbrida:

    • Cursor para trabajo de producto diario y revisión rápida.
    • Aider para refactors críticos y control de cambios.
    • Claude Code en pipelines automatizados y tareas de infra.
    • Cline cuando necesites que el agente hable con infra interna.
    • Codex/Copilot CLI para utilidades puntuales de scripting.

    Antes de adoptar, define: qué puede hacer el agente sin revisión humana, qué debe proponer como PR, y cómo auditarás cada acción (logs, commits, approvals). Sin estas reglas, la herramienta genera ruido o riesgos.

    Recursos y lecturas

    Si vas a integrar agentes en producción, no lo hagas por moda. Prepara contexto (CLAUDE.md / AGENTS.md / memory files), define límites y selecciona el harness según el dominio: UI, infra, refactor o integración con sistemas internos. Así, la IA deja de ser un “showroom” y pasa a ser una herramienta medible y auditable.

    Como continuación lógica para equipos que diseñan flujos de agentes y gobernanza técnica, consulta los experimentos y recursos de Dominicode Labs. Allí encontrarás guías prácticas para implementar context slicing, auditoría de commits y métricas de observabilidad en flujos con agentes.

    FAQ

    ¿Qué es exactamente un agentic harness?

    Es la capa que permite a un modelo de lenguaje operar sobre un repositorio con procesos definidos: resolución de contexto, aplicación segura de cambios y bucle de verificación mediante tests/linters.

    ¿Cuándo debo usar Aider en lugar de Cursor?

    Usa Aider para refactors en repos grandes o legacy donde necesitas commits automáticos y trazabilidad. Usa Cursor cuando la experiencia visual y la revisión humana inmediata son prioritarias (UI, previews, aceptación de diffs).

    ¿Claude Code reemplaza un CI tradicional?

    No necesariamente. Claude Code facilita la automatización y el razonamiento en pipelines (ejecutar tests, leer logs, proponer parches), pero suele integrarse con CI/CD existente como una herramienta para corregir y iterar en builds.

    ¿Qué es MCP y por qué importa con Cline?

    MCP es el Model Context Protocol: permite que el agente consulte servicios externos (DBs, docs internas) antes de escribir código. Es crítico si el agente necesita contexto real y permisos explícitos para interactuar con infra interna.

    ¿Puedo usar Codex/Copilot CLI para refactorizaciones?

    No son la mejor opción para refactorizaciones autónomas. Están pensados para traducir lenguaje natural a comandos de terminal y scripting; carecen del bucle iterativo y la gestión de diffs sobre el repo que requieren refactors complejos.

    ¿Cómo audito las acciones de un agente?

    Define trazabilidad mediante commits/diffs, logs de sesión, métricas de tokens y reintentos. Decide qué acciones requieren aprobación humana vs commit automático y conserva archivos de contexto (CLAUDE.md / AGENTS.md / memory files) para replicabilidad.

  • Cómo utilizar OpenSpec para gestionar especificaciones en Brownfield

    Cómo utilizar OpenSpec para gestionar especificaciones en Brownfield

    ¿Es OpenSpec la herramienta para las specs en Brownfield?

    Tiempo estimado de lectura: Calculando con ~220 palabras por minuto.

    Tiempo estimado de lectura: 3 min

    • OpenSpec acelera la obtención de una spec base desde comportamiento observable.
    • Su valor real aparece al combinar generación automática con revisión humana y guardrails en CI/CD.
    • No es una solución mágica: puede cristalizar deuda si se usa sin enriquecimiento semántico.
    • Proceso recomendado: discovery → human-in-the-loop → guardrails → evolución controlada.

    Introducción

    ¿Es OpenSpec la herramienta para las specs en Brownfield? Sí —pero no como solución mágica. OpenSpec (entendido como el ecosistema de herramientas que generan y mantienen OpenAPI/AsyncAPI automáticamente) es el punto de partida más práctico para recuperar contratos en sistemas heredados. Su valor real aparece cuando lo combinas con juicio humano, revisión semántica y guardrails en CI/CD.

    Resumen rápido (lectores con prisa)

    OpenSpec: conjunto de herramientas que generan especificaciones (OpenAPI/AsyncAPI) automáticamente desde tráfico o análisis estático. Útil para Brownfield cuando se usa como extractor inicial, no como fuente final sin revisión. Importante integrarlo con revisión humana y validaciones en pipelines.

    ¿Es OpenSpec la herramienta para las specs en Brownfield? — contexto y por qué importa

    Problema en Brownfield

    En Brownfield tienes código en producción, dependencias cruzadas y documentación que normalmente no refleja la realidad. El problema no es generar YAML: es detener el sangrado de cambios no esperados en producción. Aquí OpenSpec aporta dos cosas fundamentales:

    Qué aporta OpenSpec

    • Rapidez para obtener una línea base estructural a partir del comportamiento real del sistema.
    • Mecanismos para convertir una spec en infraestructura (drift detection, validación en pipelines).

    Herramientas de referencia: Optic, Akita, Specmatic. Para extracción desde código: Springdoc, tsoa. Consulta la especificación OpenAPI.

    Qué puede y qué no puede hacer OpenSpec en un Brownfield

    Lo que sí hace bien

    • Extrae la estructura observable de endpoints, métodos y esquemas de payloads.
    • Produce specs rápidamente desde tráfico en staging o desde análisis estático.
    • Habilita detección de deriva en CI: bloquea merges que cambian respuestas esperadas.

    Lo que no hace

    • No captura semántica de negocio: no sabe que status: 2 significa “Cuenta suspendida”.
    • No documenta edge cases que no aparecieron en el tráfico observado.
    • No corrige malos diseños: puede cristalizar inconsistencias si aceptas la spec sin filtrar.

    Si tratas la generación automática como la verdad absoluta, produces un contrato falso-seguro. Si la usas como un extractor inicial, reduces semanas de trabajo manual a horas.

    Estrategia práctica para implantar OpenSpec en Brownfield

    Implementarlo sin generar más deuda exige disciplina. Siguientes pasos probados en equipos técnicos:

    1. Generación de baseline (Discovery)

    • Captura tráfico en staging o usa análisis estático según el stack.
    • Herramientas: Optic para captura/visualización, Akita para inferencia basada en tráfico, Springdoc/tsoa para extracción desde código.
    • Objetivo: obtener un OpenAPI.yaml que represente el comportamiento observado, no la versión final.

    2. Enriquecimiento semántico (Human-in-the-loop)

    • Asigna a domain owners para revisar y documentar campos críticos, códigos de estado y reglas de negocio.
    • Corrige nombres ambiguos y elimina endpoints internos expuestos por accidente.
    • Añade ejemplos y descripciones para cada campo sensible.

    3. Control automático (Guardrails)

    • Integra la spec en CI: Specmatic u Optic pueden ejecutar contract tests o comparar contratos en PR.
    • Fallo en la spec = bloqueo del merge hasta revisión explícita.
    • Mantén logs de cambios automáticos y un proceso claro para aprobar modificaciones del contrato.

    4. Evolución controlada

    • No distribuyas la spec al consumidor externo hasta que se haya ratificado por el equipo.
    • Versiona la spec y comunica breaking changes con políticas (semver, fechas, deprecations).

    Ejemplo real y conciso

    Situación: monolito en Node que sirve APIs REST sin spec.

    • Paso 1: Instrumenta un proxy de captura en staging con Optic. Ejecuta suites de integración para generar tráfico representativo.
    • Paso 2: Optic genera un OpenAPI básico. Equipo revisa y detecta 3 endpoints con campos inconsistentes.
    • Paso 3: Ajustes manuales, se añaden descripciones de status y se documentan errores 422 y 503 que no aparecieron en tráfico.
    • Paso 4: Integra Specmatic en CI para validar que cambios en PR no alteren respuestas esperadas sin aprobación.

    Resultado: en semanas tienes una spec utilizable y protección automática contra cambios no controlados.

    Riesgos y mitigaciones operativas

    • Riesgo: cristalizar deuda técnica. Mitigación: obligar enriquecimiento semántico antes de promover spec a “source of truth”.
    • Riesgo: cobertura incompleta por tráfico insuficiente. Mitigación: complementar capture con tests orientados a edge cases y análisis estático.
    • Riesgo: falsa confianza en herramientas. Mitigación: auditorías periódicas de la spec por arquitectos y product owners.

    Conclusión — criterio técnico

    OpenSpec es la herramienta indicada para arrancar specs en Brownfield. No reemplaza la discusión humana sobre contratos ni el trabajo de diseño del dominio. Su fuerza está en reducir trabajo mecánico y convertir documentación en infraestructura verificable. Si tu equipo integra generación automática con revisión semántica y guardrails en CI, OpenSpec deja de ser una “herramienta” y pasa a ser una palanca que reduce riesgo y acelera refactors con seguridad.

    Para equipos que trabajan con automatización de workflows, captura de tráfico e integración CI, puede interesar explorar más recursos y experimentos en Dominicode Labs. Es una referencia complementaria para prototipos y pruebas de integración de herramientas OpenSpec en pipelines.

    FAQ

  • Implementación efectiva de Angular Aria para accesibilidad en UI

    Implementación efectiva de Angular Aria para accesibilidad en UI

    Angular Aria — nueva librería de accesibilidad

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • Angular Aria ofrece primitivas “headless” que implementan patrones APG para teclado, foco y lectores de pantalla.
    • Diferencia con Material y CDK: Material provee UI completa, CDK utilidades low‑level, Aria patrones sin estilo.
    • Beneficios: reduce deuda técnica, mejora consistencia y facilita cumplimiento de auditorías WCAG.
    • Riesgos: API inicial puede cambiar; requiere disciplina de integración con el Design System.

    Introducción

    Angular Aria — nueva librería de accesibilidad llega para resolver lo que suele hacerse mal una y otra vez: la lógica de interacción accesible. En las primeras líneas: no es un tema de añadir atributos; es una capa de comportamiento (gestión de foco, navegación por teclado, anuncios a lectores de pantalla) que ahora Angular ofrece como primitivas headless, complementando Angular Material y el CDK.

    Resumen rápido (lectores con prisa)

    Qué es: Colección de patrones UI headless que implementan prácticas APG para accesibilidad.

    Cuándo usarlo: Cuando necesitas control visual propio y comportamiento accesible consistente.

    Por qué importa: Reduce errores de interacción al estandarizar foco, teclado y anuncios a lectores de pantalla.

    Cómo encaja: Primitivas headless que exponen estado y handlers; tú aplicas estilos desde tu Design System.

    Qué es Angular Aria — nueva librería de accesibilidad y por qué importa

    Angular Aria es una colección de patrones de UI “headless” diseñada para implementar las prácticas recomendadas de WAI-ARIA (APG) sin imponer estilos. La idea es separar semántica y comportamiento de la capa visual: tú pones los estilos, Angular Aria se encarga de que el componente responda correctamente a teclado, foco y tecnologías asistivas.

    Documentación relevante:

    ¿Por qué importa? Porque los errores de accesibilidad no son solo reputacionales ni legales: son errores de interacción. Un Combobox mal implementado deja fuera a usuarios con teclado o lectores de pantalla. La complejidad real no está en el atributo aria-label; está en coordinar foco, roles, aria-live, y atajos de teclado en todas las plataformas.

    Diferencias claras: Angular Material vs CDK vs Angular Aria

    Angular Material

    Componentes completos con estilo y accesibilidad integrada. Ideal si aceptas Material Design y quieres velocidad.

    Docs: Docs

    Angular CDK

    Utilidades de bajo nivel (Overlays, FocusMonitor, LiveAnnouncer). Es la caja de herramientas para construir componentes.

    CDK a11y: CDK a11y

    Angular Aria

    Patrones de componentes sin estilo (Accordion, Dialog, Combobox, Menu, etc.) con semántica ARIA y gestión de interacción resuelta. Tú aplicas CSS.

    Piensa en Aria como la “implementación canónica” de las APG para Angular: reduce la deuda técnica y la variabilidad entre implementaciones de distintos equipos.

    Ejemplo conceptual (cómo encaja en un Design System)

    No entraré a nombrar APIs finales —las convenciones pueden evolucionar—, pero un flujo habitual sería:

    1. Importas la primitiva headless (p. ej. DialogBehavior).
    2. Montas el markup semántico y enlazas directivas/servicios que exponen estado y handlers.
    3. Aplicas estilos desde tu sistema (Tailwind, Sass, CSS Modules).

    Pseudocódigo conceptual:

    <app-dialog *ariaDialog>
      <div ariaDialogTrigger>Abrir diálogo</div>
      <div ariaDialogContent>
        <!-- foco gestionado, escape cierra, roles y aria-hidden se aplican automáticamente -->
      </div>
    </app-dialog>

    Resultado: el comportamiento accesible ya está cubierto; el equipo sólo diseña la apariencia.

    Impacto en equipos y auditorías de accesibilidad

    • Time to Market: menor, porque no rehaces la lógica de interacción en cada componente.
    • Consistencia: menos variaciones entre módulos y menos fallos en auditorías WCAG 2.1 AA.
    • Mantenibilidad: actualizaciones de patrones centralizadas en la librería oficial reducen riesgo técnico.

    Si tu organización debe pasar auditorías (WCAG, EN 301 549), Angular Aria reduce la superficie de riesgo técnico al ofrecer implementaciones alineadas con APG.

    Riesgos, limitaciones y puntos de decisión

    • Estabilidad de API: siendo lanzamiento reciente, algunas APIs pueden cambiar. Revisa changelogs antes de adopciones masivas.
    • Superposición con CDK a11y: es probable que parte del CDK siga existiendo como utilidades de bajo nivel; Aria levantará patrones completos.
    • Integración visual: necesitas disciplina en el Design System para unir las primitivas headless con tokens y utilidades de estilos.

    Criterio técnico para la adopción (resumen accionable)

    Adopta Angular Aria si:

    • Estás construyendo un Design System white‑label o con identidad visual propia.
    • Tu equipo usa CSS utilitario (Tailwind) o quiere control total sobre la apariencia.
    • Tienes requisitos normativos o usuarios con necesidades de accesibilidad.

    No es prioritaria si:

    • Estás plenamente integrado con Angular Material y aceptas su estética.
    • Tu proyecto es un prototipo o MVP donde la prioridad es velocidad visual sin personalización.

    Checklist de integración mínima:

    • Añade pruebas de accesibilidad automatizadas (axe, Pa11y) en CI.
    • Mantén lockfiles y revisa cambios en dependencias a nivel de PR.
    • Planifica migración por componentes: empezar por Dialogs/Comboboxes reduce riesgo.

    Conclusión

    Angular Aria no es “otro paquete” más; es la pieza que permite a Angular competir en el terreno del Headless UI con garantías de accesibilidad. Para equipos que construyen componentes a medida, representa una inversión de tiempo recuperable en forma de consistencia, cumplimiento y reducción de deuda técnica. Implementa pruebas y políticas de adopción por fases, y usa Aria para que la accesibilidad deje de ser un añadido y pase a ser la base del comportamiento de tus interfaces.

    FAQ

    ¿Qué es Angular Aria?

    Una colección de patrones UI headless para implementar prácticas WAI-ARIA (APG) en Angular, separando comportamiento accesible de la capa visual.

    ¿En qué se diferencia de Angular Material?

    Material ofrece componentes completos con estilo; Angular Aria ofrece patrones sin estilo que gestionan interacción y semántica accesible.

    ¿Tengo que dejar de usar CDK a11y?

    No necesariamente. CDK seguirá siendo útil como utilidades de bajo nivel; Angular Aria ofrece patrones completos construidos sobre prácticas APG.

    ¿Qué beneficios trae para auditorías WCAG?

    Reduce la superficie de riesgo técnico al proporcionar implementaciones alineadas con APG, lo que ayuda a pasar auditorías WCAG 2.1 AA y otras normativas.

    ¿Cuáles son los riesgos al adoptar Angular Aria ahora?

    La API puede cambiar en etapas tempranas; es recomendable revisar changelogs y planificar migraciones por componentes para mitigar riesgo.

    ¿Dónde puedo leer las prácticas y ejemplos relacionados?

    Revisa la WAI-ARIA Authoring Practices Guide y la documentación oficial de Angular. También hay ejemplos en React Aria y Radix UI.

  • Cuatro herramientas de IA esenciales para emprendedores técnicos

    Cuatro herramientas de IA esenciales para emprendedores técnicos

    IA para emprendedores: las 4 herramientas que uso todos los días

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Un stack de cuatro herramientas (Perplexity, Cursor, n8n y v0) cubre investigación, código, orquestación y UI para MVPs productivos.
    • Cada plataforma resuelve un problema concreto y se integra sin fricción con las demás.
    • Usa Perplexity para evidencia, Cursor para código con contexto, n8n para automatización controlada y v0 para prototipado UI rápido.
    • Este enfoque prioriza velocidad sin sacrificar calidad; no es para scripts one‑off ni entornos regulados sin políticas claras.

    Tabla de contenidos

    Introducción

    IA para emprendedores: las 4 herramientas que uso todos los días. Si eres fundador técnico y estás cansado de probar aplicaciones brillantes que no escalan, este artículo te dice exactamente qué usar —y por qué— para convertir IA en multiplicador de fuerza real.

    No es una lista de modas. Es el stack operativo que cubre investigación, desarrollo, orquestación y prototipado. Cada herramienta la uso a diario porque resuelve un problema concreto en mi flujo de trabajo y se integra con las demás sin fricción.

    Resumen rápido (lectores con prisa)

    Perplexity: evidencia y referencias para decisiones técnicas. Cursor: generación y refactorización con visibilidad del repo. n8n: automatizaciones autoalojables y controladas. v0: scaffolding UI React + Tailwind para MVPs.

    IA para emprendedores: las 4 herramientas que uso todos los días

    Estas cuatro plataformas no son intercambiables. Juntas forman un sistema: Perplexity para la evidencia, Cursor para el código con contexto, n8n para la automatización con control y v0 para llevar la interfaz del MVP al campo de batalla.

    1) Perplexity Pro — investigación técnica fundamentada

    Perplexity

    Usos concretos

    • Auditar una dependencia antes de añadirla: pedir benchmarks y CVEs documentados.
    • Extraer endpoints relevantes de una API y generar esquemas TypeScript a partir de la doc.
    • Diagnóstico de errores raros con enlaces a issues de GitHub y soluciones reales.

    Cuando buscas decisiones arquitectónicas, Google devuelve ruido SEO; necesitas hechos y referencias. Perplexity actúa como motor de respuestas fundamentadas: cita fuentes, enlaza documentación y evita alucinaciones sobre versiones o APIs recientes.

    Por qué lo tengo abierto antes de empezar un pull request: reduce el riesgo de elegir la solución “popular” en vez de la adecuada.

    2) Cursor — desarrollo asistido por contexto de repositorio

    Cursor

    Cómo lo uso

    • Flujo Spec-First: escribo interfaces y tipos, pido a Cursor los tests (TDD) y luego la implementación.
    • Refactorizaciones cross-módulo sin romper imports ni tipos.
    • Integración con modelos Anthropic (Claude) para tareas de razonamiento complejas.

    Cursor deja de ser un autocompletador para convertirse en un IDE con memoria de todo el repo. Eso cambia la conversación: cuando pides una refactorización o que genere tests, el modelo ve las interfaces, dependencias y convenciones reales del proyecto.

    Resultado: menos correcciones manuales, menos “import not found” y código que encaja de verdad con la base existente.

    3) n8n — orquestación y automatización controlada

    n8n

    Casos de uso diarios

    • Triaje automático de soporte: correo → clasificación LLM → crear ticket en Jira/Slack.
    • Pipelines ETL: extraer Stripe → transformar con JS → cargar en PostgreSQL.
    • Backend de herramientas para asistentes GPT: el agente razona, n8n ejecuta los permisos y las acciones.

    Zapier sirve al marketing; n8n sirve a ingeniería. Autoalojable, nodos de código y soporte para agentes/LLMs lo convierten en el backbone cuando necesitas ejecutar lógica real sobre tus datos, mantener privacidad y controlar errores.

    Si la automatización toca datos sensibles o requiere lógica personalizada, n8n es la única opción que no te dejará con dudas de cumplimiento.

    4) v0 (Vercel) — prototipado UI rápido y utilizable

    v0

    Qué me ahorra

    • Scaffolding de dashboards y formularios validados.
    • Código que respeta patterns de Next.js y facilita integración con Server Components.
    • Iteraciones de diseño que van directamente al repo, no a un diseñador externo.

    v0 genera componentes React + Tailwind listos para producción desde descripciones en lenguaje natural. No es magia estética; es velocidad para convertir hipótesis en interfaces conectables a tu backend.

    Para MVPs que necesitan verse y funcionar rápido, v0 reduce semanas de trabajo a horas.

    Cómo encajan estas piezas en un flujo real

    1. Decisión arquitectónica: Perplexity te da la evidencia y los enlaces (docs, issues).
    2. Diseño del contrato: escribes tipos/interfaces y casos límite.
    3. Implementación y pruebas: Cursor genera tests y código con visión de repo.
    4. Orquestación y producto: n8n automatiza flujos operativos; v0 entrega la UI del MVP.

    URLs de referencia rápidas

    Cuándo usar este stack y cuándo no

    Úsalo si quieres velocidad sin sacrificar calidad: MVPs productivos, equipos pequeños, founders técnicos que necesitan iterar rápido. No lo uses para scripts one-off sin mantenimiento o en entornos regulados donde las políticas corporativas prohíban modelos generativos.

    La diferencia es sencilla: las herramientas ejecutan; tú decides. Quien domine el “qué” y el “por qué” seguirá teniendo ventaja competitiva. Estas cuatro plataformas reducen la fricción operativa, no sustituyen el criterio técnico.

    Empieza mañana

    Define dos tipos, genera los tests con Cursor, monta un flujo simple en n8n y pide a v0 el scaffold del dashboard. Verás que el tiempo que ahorras no es solo horas: es autocontrol técnico. Esto no acaba aquí; el próximo paso es convertir esa prueba en una rutina reproducible para todo tu equipo.

    Dominicode Labs

    Si trabajas en automatización, agentes o workflows y quieres ejemplos reproducibles que integren investigación, código, orquestación y UI, revisa Dominicode Labs. Encontrarás plantillas y guías prácticas para aplicar este stack en proyectos reales.

    FAQ

    ¿Para qué sirve Perplexity en un flujo técnico?

    Perplexity sirve para obtener evidencia, referencias y enlaces a documentación o issues que apoyen decisiones arquitectónicas. Reduce riesgo al proveer fuentes verificables en lugar de resultados orientados a SEO.

    ¿Cómo mejora Cursor el desarrollo en equipo?

    Cursor aporta contexto del repo al proceso de generación de código: permite generar tests, refactorizaciones y código que respeta interfaces y convenciones ya existentes, reduciendo errores de integración.

    ¿Por qué elegir n8n sobre Zapier?

    n8n es autoalojable, soporta nodos de código y ofrece control de datos y errores, por lo que es más adecuado para ingeniería y workflows que manejan información sensible o lógica personalizada.

    ¿v0 reemplaza a un diseñador?

    No reemplaza a un diseñador en todos los casos. v0 acelera el scaffolding y genera componentes listos para producción, especialmente útil en MVPs donde velocidad e integración con el backend son prioritarias.

    ¿Este stack es adecuado para entornos regulados?

    No se recomienda sin revisar las políticas corporativas y de cumplimiento. En entornos regulados hay que validar uso de modelos generativos y requisitos de privacidad antes de adoptar el stack.

    ¿Qué pruebas recomendar para integrar este flujo?

    Recomiendo pruebas unitarias y de integración generadas desde el contrato (types/interfaces), pipelines ETL validados en n8n y pruebas end-to-end del UI scaffolded por v0. Vitest es una referencia recomendada para tests.

  • Cómo construir un subagente en Claude Code para revisión de PRs

    Cómo construir un subagente en Claude Code para revisión de PRs

    Cómo construir tu primer subagente en Claude Code — Tutorial paso a paso con un caso útil: por ejemplo, un agente revisor de PRs o generador de tests

    Tiempo estimado de lectura: 4 min

    • Patrón práctico: contexto acotado + reglas estrictas + output accionable para integrar IA en pipelines.
    • Dos casos: revisor de PRs (diff) y generador de tests (por archivo).
    • Implementación: scripts CLI que usan Claude Code, prompts versionados y hooks/CI para automatizar.
    • Precauciones: controlar tokens, contexto parcial y mantener revisión humana para decisiones críticas.
    Entender cómo construir tu primer subagente en Claude Code — Tutorial paso a paso con un caso útil: por ejemplo, un agente revisor de PRs o generador de tests, es el salto práctico entre usar IA como chat y convertirla en un componente automatizado de tu pipeline de desarrollo. Aquí tienes un tutorial accionable, sin humo: código, prompts y reglas para que funcione de verdad.

    Resumen rápido (lectores con prisa)

    Un subagente es un script que envía contexto limitado (diff o archivo) a Claude Code con un prompt versionado. Úsalo cuando la tarea sea repetitiva y pueda expresarse con reglas claras. La clave: reducir contexto, reglas estrictas y automatizar en hooks/CI.

    Cómo construir tu primer subagente en Claude Code — paso a paso

    Requisitos mínimos

    • Node.js y npm.
    • Cuenta y credenciales de Anthropic (Claude Code).
    • Repositorio Git con cambios en una rama distinta a main.

    Instalación rápida

    Instala la CLI de Claude Code y autentica:

    npm install -g @anthropic-ai/claude-code
    claude auth
    

    (Referencia: npm package @anthropic-ai/claude-code)

    1. Define el System Prompt (qué puede y qué no puede hacer)

    El System Prompt es la barrera entre ruido y valor. Guarda uno en la raíz: .claude-reviewer-prompt.md.

    Contenido recomendado:

    Eres un Staff Engineer realizando una revisión de código.
    Recibirás un `git diff`. Tu objetivo es identificar problemas críticos.
    
    Reglas:
    1. Ignora formato y estilo (linters ya hacen eso).
    2. Busca: vulnerabilidades, condiciones de carrera, mutaciones de estado no controladas y complejidad innecesaria.
    3. Si hay nueva lógica sin tests, marca "Missing Tests" como error crítico.
    4. Responde en Markdown. Si todo está correcto, responde solo: "✅ Código limpio. Listo para PR."
    

    Sé explícito: lo que no está en las reglas, está fuera del subagente.

    2. Script que orquesta el subagente (claude-pr-review.sh)

    Extrae el diff y pásalo al modelo. Crea /scripts/claude-pr-review.sh:

    #!/bin/bash
    DIFF=$(git diff main...HEAD -- ':!**/package-lock.json' ':!**/dist/**')
    
    if [ -z "$DIFF" ]; then
      echo "No hay cambios para revisar."
      exit 0
    fi
    
    PROMPT=$(cat .claude-reviewer-prompt.md)
    
    claude --print --prompt "$PROMPT
    
    Aquí tienes el diff:
    \`\`\`diff
    $DIFF
    \`\`\`"
    

    Notas:

    • Excluye archivos generados para ahorrar tokens (-- ':!path').
    • claude --print muestra la respuesta en terminal; puedes redirigirla a un archivo.

    3. Variante: generador de tests por archivo

    Mismo patrón, distinto input. Crea /scripts/claude-gen-tests.sh:

    #!/bin/bash
    FILE_PATH=$1
    if [ ! -f "$FILE_PATH" ]; then
      echo "Archivo no encontrado: $FILE_PATH"
      exit 1
    fi
    
    claude --print --prompt "Actúa como SDET especializado en TypeScript.
    Genera tests unitarios con Jest para el siguiente archivo. Usa mocking donde aplique. Devuelve solo el código del test.
    
    Archivo:
    $(cat $FILE_PATH)" > "${FILE_PATH%.*}.test.ts"
    

    El resultado es un punto de partida. No lo aceptes ciegamente: revisa los mocks y aserciones.

    4. Integración práctica: Hooks y CI

    Un script manual se olvida. Integra el revisor en un hook pre-push (Husky) o como job en CI.

    Ejemplo Husky (.husky/pre-push):

    #!/bin/sh
    ./scripts/claude-pr-review.sh || exit 1
    

    Si detecta un problema crítico, el script puede devolver exit 1 y bloquear el push.

    En CI, ejecuta el script y falla el job si el output contiene palabras clave (ej. “Missing Tests” o “Error crítico”).

    5. Limitaciones y buenas prácticas

    • Coste de tokens: pasar un diff enorme puede ser caro. Filtra archivos irrelevantes. Regla práctica: apunta a menos de ~20k tokens por invocación.
    • Contexto parcial: el subagente solo ve lo que le das (diff o archivo). Los falsos positivos aparecen cuando la lógica depende de archivos no incluidos.
    • No es reemplazo de humanos: automatiza lo repetitivo; deja decisiones arquitectónicas a desarrolladores senior.
    • Versiona prompts y scripts: audítalos como cualquier herramienta crítica.

    6. Decisión rápida: cuándo usar un subagente local

    Usa subagentes locales si:

    • La tarea es repetitiva y repite reglas claras (seguridad simple, checklists de arquitectura).
    • Tienes un disparador claro (push, PR, commit).
    • Puedes limitar el contexto para controlar coste y precisión.

    Evítalos cuando:

    • Requieres análisis de arquitectura completa de un monorepo.
    • Necesitas pruebas end-to-end dependientes de infra externa.

    Conclusión (y lo que sigue)

    El patrón es simple y poderoso: reduce ruido dando contexto acotado y reglas firmes. Implementa el revisor y el generador de tests como base, obsérvalos un par de semanas, afina el prompt y automatiza su ejecución en hooks o CI. Esto no acaba aquí: un subagente bien definido se convierte en una pieza de infraestructura que reduce fricción y libera criterio humano para lo que realmente importa.

    Dominicode Labs

    Para equipos que investigan automatización y agentes en pipelines, puede ser útil explorar recursos y experimentos adicionales en Dominicode Labs. Considera esto como una continuación lógica para prototipar y versionar subagentes en un entorno experimental controlado.

    FAQ

    ¿Qué es un subagente en este contexto?

    Un subagente es un componente automatizado que envía contexto específico (por ejemplo, un git diff o el contenido de un archivo) a un modelo (Claude Code) junto con un prompt versionado y reglas, para producir output accionable usado en pipelines de desarrollo.

    ¿Cómo protejo credenciales y datos sensibles?

    Almacena credenciales en entornos seguros (secrets en CI, variables de entorno en el sistema) y evita pasar archivos que contengan secretos en los diffs enviados al modelo. Versiona prompts pero no incluyas secretos en ellos.

    ¿Cuándo el subagente debe fallar un push?

    Haz que falle cuando detecte errores críticos claramente definidos en el prompt (por ejemplo, “Missing Tests” o “Error crítico”). Mantén una lista pequeña y precisa de condiciones que realmente justifiquen bloquear un push.

    ¿Cómo controlo el coste de tokens?

    Filtra archivos irrelevantes, limita el tamaño del diff y prioriza invocaciones por carpeta o por cambios significativos. Regla práctica: apunta a menos de ~20k tokens por invocación.

    ¿Puedo usar otros modelos o proveedores?

    Sí. El patrón (contexto acotado + reglas estrictas + output accionable) es agnóstico al proveedor. Ajusta comandos y prompts según la API/CLI del proveedor seleccionado.

    ¿Cómo versiono y audito prompts?

    Guarda prompts en el repositorio (por ejemplo, .claude-reviewer-prompt.md) y trata los cambios como código: revisiones, PRs y registro de cambios. Audítalos como cualquier herramienta crítica operativa.

  • Cómo implementar TDD y Spec-First para mejorar el uso de IA en desarrollo

    Cómo implementar TDD y Spec-First para mejorar el uso de IA en desarrollo

    TDD + Spec-First: el combo que cambia cómo trabajas con IA

    Tiempo estimado de lectura: 5 min

    • Ideas clave:
    • Spec-First define contratos claros (tipos, OpenAPI, GraphQL) antes de implementar.
    • TDD convierte esos contratos en especificaciones ejecutables: tests rojos → implementación → tests verdes.
    • Con LLMs, contrato + tests limitan alucinaciones y convierten a la IA en colaborador predecible.
    • Práctica: versiona specs, entrega solo interfaz + test al modelo, ejecuta CI y refactoriza con seguridad.

    TDD + Spec-First: el combo que cambia cómo trabajas con IA no es una moda. Es la forma práctica de convertir asistentes de código (Cursor, Copilot, Claude, etc.) en colaboradores fiables en lugar de generadores caóticos. Si quieres que la IA entregue código mantenible y predecible, primero le pones un contrato; después, le pones pruebas.

    Resumen rápido (lectores con prisa)

    Spec-First: define el contrato (types/OpenAPI/GraphQL) antes de implementar. TDD: escribe tests que describen comportamiento antes de la lógica. Juntos: contrato define el “qué”, los tests el “cuándo” y la IA queda confinada al “cómo”.

    TDD + Spec-First: el combo que cambia cómo trabajas con IA — qué es y por qué importa

    Qué es Spec-First

    Spec-First significa diseñar el contrato antes de implementar: tipos TypeScript, OpenAPI/Swagger o un esquema GraphQL (GraphQL). Definir la interfaz y errores esperados aclara responsabilidades y límites.

    Qué es TDD

    TDD (Test-Driven Development) obliga a escribir pruebas que expresen comportamiento antes de cualquier línea de lógica. Los tests actúan como una especificación ejecutable que guía la implementación y protege el diseño frente a regresiones.

    Flujo práctico: cómo aplicarlo día a día

    1) Define el contrato (Spec-First)

    • Escribe interfaces o un OpenAPI minimal.
    • Versiona ese archivo en el repo.
    • Hazlo lo más explícito posible: tipos, errores esperados, límites de paginación.

    Por qué? Cambiar una especificación es barato; cambiar la implementación ya entregada cuesta tiempo y bugs.

    2) Escribe los tests antes (Red)

    • Genera tests unitarios que describan casos reales: éxito, validaciones y fallos (timeouts, errores de red).
    • Usa frameworks previstos: Jest, pytest, etc.
    • Aísla dependencias con mocks para que el test sea una especificación ejecutable del comportamiento.

    3) Implementa con la IA (Green)

    • Entrega a la IA solo la interfaz y el test fallido. Nada de documentación amplia ni contexto innecesario.
    • Pide explícitamente: “Implementa X para que pase estos tests. No añadas métodos públicos que no estén en la interfaz.”
    • Ejecuta los tests; si fallan, pega el error en el prompt y haz que la IA itere.

    4) Refactoriza y repite (Refactor)

    Con tests en verde, pide mejoras estructurales (limpieza, reducción de complejidad) y deja que los tests validen que no hay regresiones.

    Ejemplo rápido (esquema)

    – Spec-First: IUserService { getById(id): Promise | throws NotFound }
    – Tests (Jest): caso exitoso, user no existe, DB timeout.
    – Implementación: la IA crea UserService respetando la interfaz; los tests pasan.

    Ese flujo evita que la IA invente un método “findUserOrCreate()” si no estaba en la spec.

    Ventajas reales en equipos técnicos

    • Arquitectura consistente: los tech leads definen límites arquitectónicos, la IA implementa sin salirse de ellos.
    • Documentación viva: specs + tests = documentación ejecutable.
    • Escalabilidad del trabajo: developers junior pueden entregar valor siguiendo contratos y tests claros.
    • Refactor seguro: la suite de tests permite que la IA haga cambios con garantía.

    Riesgos y cómo mitigarlos

    1. Tests tautológicos

    Riesgo: si la IA escribe spec, tests e implementación, todo estará autoconsistente pero puede no cubrir requerimientos reales.

    Mitigación: la spec inicial la define un humano con conocimiento del dominio. Revisa y aprueba los tests generados.

    2. Overfitting en tests

    Riesgo: tests que verifican la implementación concreta y no el comportamiento observable.

    Mitigación: escribe tests orientados a contratos (inputs/outputs/efectos observables), no a estructuras internas.

    3. Explosion de tests irrelevantes

    Riesgo: la IA puede generar multitud de casos triviales que aumenten la carga de mantenimiento.

    Mitigación: prioriza tests del Core Domain; define criterios claros de cobertura (p. ej. casos críticos y límites).

    Integración práctica y mejores prácticas

    • Prompts minimalistas y restrictivos: entrega solo interface + test. Menos contexto = menos alucinaciones.
    • Versiona prompts y ejemplos de tests en el repo para auditar cambios.
    • CI como guardián: exige que todos los PRs pasen la suite antes de merge.
    • Métricas: trackea flakiness de tests y tiempo medio hasta tests verdes cuando la IA implementa; son indicadores de calidad del flujo.

    Recursos y lectura recomendada

    Spec-First + TDD no es una camisa de fuerza; es un marco que transforma a la IA en una herramienta que ejecuta diseño, no que lo inventa. Si quieres resultados reproducibles y menos deuda técnica, deja de pedir “escribe esto” y comienza a exigir contratos y pruebas. El resto viene solo.

     

    FAQ

     

    ¿Por qué empezar por la spec en lugar de por el código?

    Porque la spec define límites y responsabilidades antes de que alguien implemente. Cambiar una spec es más barato y menos propenso a introducir bugs que ajustar implementaciones ya en producción.

    ¿Qué pruebas debería escribir primero?

    Empieza por casos críticos: caminos felices, validaciones y fallos esperados (timeouts, errores de red). Prioriza comportamiento observable sobre detalles de implementación.

    ¿Cómo evitar que la IA genere funciones fuera de la interfaz?

    Entrega al modelo sólo la interfaz y el test fallido; pide explícitamente que no añada métodos públicos que no estén en la spec. Usa revisión humana y CI para bloquear cambios no autorizados.

    ¿Qué frameworks de tests son recomendables?

    Depende del stack: Jest para JavaScript/TypeScript, pytest para Python, y frameworks nativos para otros lenguajes. Lo importante es que permitan mocks y pruebas aisladas.

    ¿Cómo integrar esto en CI?

    Configura la pipeline para ejecutar la suite completa en cada PR. Rechaza merges si hay tests fallidos. Versiona specs y prompts en el repo para auditar cambios.

    ¿Qué métricas debo trackear?

    Trackea flakiness de tests, tiempo medio hasta tests verdes cuando la IA implementa, y número de PRs que requieren intervención humana. Esos indicadores reflejan calidad y estabilidad del flujo.

  • Cómo Crear una Especificación Técnica Efectiva para Claude

    Cómo Crear una Especificación Técnica Efectiva para Claude

    ¿Quieres convertir una idea brillante en un plan técnico que no se desmorone en la primera integración?

    Tiempo estimado de lectura: 6 min

    • Empieza por el porqué: describir el valor antes de pedir diseño técnico.
    • Documenta y estructura: volcado de contexto organizado en secciones claras.
    • Limita y pide artefactos: define stack, restricciones y solicita outputs machine-readable.
    • Itera con pruebas: divide en fases, genera tests y checklist de aceptación desde el inicio.

    Introducción

    Poca gente habla de esto en voz alta: usar a Claude sin método es como dar un GPS a alguien que no sabe leer mapas. Te lleva rápido. Te deja en medio de la nada.

    Descubrí algo curioso trabajando con equipos: los proyectos con mejor documentación no son los más lentos. Son los que sobreviven. Y con IA, la supervivencia depende de tu habilidad para traducir intuiciones en contratos técnicos claros. Claude puede ser el mejor compañero para eso —si sabes cómo pedirle las cosas.

    Esto no es un manual académico. Es un plan para usar Claude y salir del “hacer que funcione” hacia “hacer que dure”.

    Resumen rápido (lectores con prisa)

    Qué es: método para convertir intuiciones en especificaciones técnicas usando Claude.

    Cuándo usarlo: cuando las decisiones afectan contratos, seguridad o arquitectura.

    Por qué importa: reduce ambigüedad, acelera integración y baja la deuda técnica.

    Cómo funciona: estructura el prompt, define stack y límites, pide artefactos machine-readable y tests en fases.

    Guía paso a paso

    1) Empieza por el porqué, no por el cómo

    No le sueltes al modelo: “Hazme el CRUD.” Suéltale: “Esto existe porque…”

    Explica el negocio en 3–5 frases. Quién usa el producto. Qué métricas importan. Qué es un éxito y qué es un fallo. Claude necesita entender el valor antes de diseñar la estructura. Si no sabe el porqué, propondrá soluciones bonitas que no resuelven nada real.

    2) Brain dump: vacía la cabeza en orden

    Haz un volcado de contexto. Todo. Usuarios, roles, integraciones, datos sensibles, presupuestos, deadlines. Todo en bruto. Luego organízalo en secciones:

    • Objetivo del producto.
    • Requisitos no negociables.
    • Integraciones externas.
    • Restricciones de coste o tiempo.

    Si no lo pones por escrito, la IA lo “olvidará” cuando la conversación crezca. La ventana de contexto es grande, pero limitada. La spec fija el rumbo.

    3) Define límites claros: el terreno de juego

    Un LLM sin límites propone arquitectura épica. Kubernetes para un formulario. Event Sourcing para un blog. Fija el stack y las reglas: Next.js o Angular, Postgres o Mongo, monolito o microservicios. Di lo que está permitido y lo que está prohibido.

    Esto no es control por control. Es evitar decisiones peligrosas. Cuanto más concreto seas, más útiles serán las propuestas de Claude.

    4) Usa a Claude como auditor: Red Teaming

    Hazle preguntas desagradables. Pídele que rompa el diseño.

    “Si la base de datos recibe 10k req/s, ¿qué falla?”

    “¿Qué pasa si el OAuth provider devuelve 500 por 30 segundos?”

    “Describe tres formas en que esto puede ser explotado.”

    Pedir a Claude que actúe como Staff Engineer es oro. Suele encontrar cuellos de botella y escenarios que no ves en la primera pasada.

    5) Pide un Plan Técnico Estructurado (no un ensayo)

    No le pidas “un diseño”. Pide un plan accionable y dividido en entregables. Que incluya:

    • Arquitectura general (componentes y responsabilidades).
    • Modelos de datos (tablas o colecciones, relaciones).
    • Contratos de API (endpoints, métodos, payloads).
    • Reglas de seguridad y manejo de secretos.
    • Estrategia de testing y despliegue.
    • Checklist de aceptación.

    Exige formatos concretos: interfaces TypeScript, OpenAPI, diagramas Mermaid. Claude los produce con disciplina si se lo pides.

    6) Prompt maestro: estructura rígida para resultados deterministas

    Empaqueta la solicitud final con bloques semánticos. Ejemplo sencillo que Claude entiende bien:

    <contexto_negocio>
    Resumen del problema en 3–5 frases.
    </contexto_negocio>

    <stack_requerido>
    Frontend: Next.js 14. Backend: Node 20. DB: PostgreSQL 15.
    </stack_requerido>

    <restricciones>
    Monolito. No sugerir microservicios. Cumplir GDPR.
    </restricciones>

    <output_esperado>
    Markdown con: arquitectura, modelos TypeScript, OpenAPI y Mermaid.
    </output_esperado>

    Sí: usa algo parecido. Claude procesa estructura. Evita “hazme algo bueno” y usa “hazme esto exacto”.

    7) Itera en pequeños pasos: divide para conquistar

    No le pidas “termina todo en un prompt”. Divide el plan en fases:

    • Fase 1: Modelo de datos y contratos.
    • Fase 2: Endpoints principales + seguridad.
    • Fase 3: Estrategia de despliegue y observabilidad.

    Aprueba cada fase antes de avanzar. Así mantienes coherencia y controlas la complejidad.

    8) Genera pruebas desde el principio

    Pide a Claude que escriba tests de aceptación junto al contrato. Un endpoint sin test es un contrato sin firma.

    Solicita ejemplos de payloads válidos e inválidos. Solicita tests automáticos que fallen si no cumples las reglas. Así la implementación se vuelve una verificación automática del plan.

    9) Convierte la spec en artefactos machine-readable

    No dejes todo en texto. Pide:

    • OpenAPI / Swagger.
    • Esquema DB (SQL o Prisma).
    • Interfaces TypeScript.
    • Mermaid para diagramas.

    Estos artefactos alimentan la fase de implementación y reducen la ambigüedad cuando uses Copilot o agentes de coding.

    10) Añade reglas de guardia: políticas y anti-patrones

    Incluye en la spec lo que NO se debe hacer. Ejemplos útiles:

    • No exponer tokens en el frontend.
    • No usar dependencias sin CVE review.
    • Todas las APIs deben ser idempotentes.
    • Tiempo máximo de respuesta: 500ms en endpoints críticos.

    La IA responde bien a instrucciones negativas si las formulas claras.

    11) Implantación práctica: .cursorrules y SPEC.md

    Pon la spec en el repo. No escondas nada en Google Docs. Dos archivos mínimos:

    • SPEC.md: objetivo, reglas, contratos, checklist de aceptación.
    • .cursorrules (o el archivo que tu herramienta use): reglas automáticas consumibles por agentes.

    Que la spec sea la primera lectura del modelo cada vez que se genere código.

    12) Checklist de revisión para PRs generados por IA

    No es lo mismo revisar un PR humano que uno generado por IA. Usa una checklist específica:

    • ¿Respeta la spec? (sí/no)
    • ¿Hay tests que cubren casos límite?
    • ¿Se siguen convenciones de seguridad?
    • ¿Hay duplicación innecesaria de lógica?
    • ¿Los nombres reflejan la intención del dominio?

    Si falla cualquiera, rechaza y pide reescritura a la IA con referencia a la sección exacta de SPEC.md.

    13) Historias reales (sin fantasías)

    Equipo A: arrancó sin spec. 10 librerías distintas, 3 sistemas de auth, un pico y nada funcionó. Reescritura completa en 3 semanas.

    Equipo B: escribió spec en 2 días, usó Claude para generar contratos y tests. Demo en 48 horas. Integración estable en producción. ¿Qué prefieres?

    14) Cuándo no usar Claude para esto

    Claude es excelente en diseño. No lo necesitas para:

    • Tiny fixes en funciones locales.
    • Tests unitarios triviales.
    • Autocompletado en IDE (usa Copilot si quieres velocidad inline).

    Usa Claude cuando la decisión impacte contratos, seguridad o arquitectura.

    15) Plantilla mínima de SPEC.md (pégala ya)

    Pon esto en la raíz del repo. No la copies palabra por palabra sin adaptar. Pero hazlo.

    – Título y objetivo en una frase.

    – Stack aprobado (y versiones).

    – Reglas arquitectónicas innegociables (3).

    – Interfaces/contratos principales.

    – Criterios de aceptación (tests que deben pasar).

    – Política de secretos.

    – Responsables y permisos de cambio.

    Hazlo ahora. No mañana.

    16) Metáfora que pega y no falla

    La spec es la brújula. Claude es el marinero diestro. Sin brújula, el marinero navega. Rápido. Pero a la deriva. Con la brújula, llega al puerto. A salvo.

    17) Urgencia real: la deuda técnica no perdona

    Cada PR aceptado sin spec es una deuda invisible. Se acumula. Multiplica el coste de cada iteración futura. Actuar ahora es barato. Reescribir después es caro.

    CTA: hazlo en 60 minutos

    Abre el repo. Crea SPEC.md con las seis secciones mínimas que te di.

    Si quieres, te doy la plantilla lista para pegar. Respóndeme con “Quiero la plantilla” y te la envío ahora mismo.

    Esto no acaba aquí. Si quieres, te enseño:

    • Un prompt maestro listo para Claude.
    • Un SPEC.md completo para un proyecto típico (Next.js + PostgreSQL).
    • Un .cursorrules ejemplo para que la spec sea leída por agentes.

    Dime cuál quieres y te lo mando. Tus commits lo agradecerán. Y dentro de seis meses, tu equipo también.

    Si quieres recursos y experimentos prácticos sobre automatización, agentes y workflows, revisa Dominicode Labs. Es una continuación lógica para quienes aplican estas prácticas en repos reales y pipelines de integración continua.

    FAQ

    Respuesta

    Debe resumir en una frase el problema que se resuelve, los usuarios principales, y las métricas que determinan éxito o fallo. Manténlo en 2–3 líneas claras.

    Respuesta

    Usa bloques semánticos: contexto negocio, stack requerido, restricciones y output esperado. Entrega ejemplos concretos y formatos de salida (TypeScript, OpenAPI, Mermaid).

    Respuesta

    Prioriza OpenAPI, esquema de BD (SQL/Prisma) e interfaces TypeScript. Estos permiten plug-and-play con herramientas de generación y tests automáticos.

    Respuesta

    Usa Copilot para autocompletado y fixes locales. Usa Claude para diseño, contratos, análisis de riesgos y generación de artefactos estructurados que guían implementaciones.

    Respuesta

    Incluye verificación de spec, cobertura de tests (casos límite), cumplimiento de reglas de seguridad y ausencia de duplicación. Si falla cualquiera, rechaza el PR.

    Respuesta

    Añádelo al repo raíz y configura el pipeline para validar que la spec se carga antes de generar artefactos. Automatiza checks que garanticen que los agents leen .cursorrules en cada run.

  • Mejorando rendimiento y SEO al migrar de Angular a Next.js 16

    Mejorando rendimiento y SEO al migrar de Angular a Next.js 16

    De Angular a Next.js 16: lo que aprendí migrando un proyecto real

    Tiempo estimado de lectura: 4 min

    • Rendimiento y SEO fueron el motor: migramos por Core Web Vitals malos, TTFB lento y bundle que penalizaba conversión móvil.
    • Server-first cambia la mentalidad: Next.js 16 y React Server Components mueven carga y lógica al servidor, reduciendo JavaScript en cliente.
    • Menos boilerplate para mutaciones: Server Actions permiten llamar funciones server-side desde formularios sin endpoints REST intermedios.
    • Fricciones reales: cache, alcance de “use client” y observabilidad requieren disciplina adicional en producción.

    De Angular a Next.js 16: lo que aprendí migrando un proyecto real empezó como un problema de negocio: Core Web Vitals malos, TTFB lento y un bundle que penalizaba conversión móvil. La migración no fue una moda técnica; fue una necesidad para reducir fricción de usuario y mejorar SEO técnico. Esto marcó cada decisión técnica que tomamos.

    Resumen rápido (lectores con prisa)

    Qué es: Next.js 16 (App Router) usa React Server Components para renderizar HTML en servidor y enviar JavaScript mínimo al cliente.

    Cuándo usarlo: cuando SEO, Core Web Vitals o TTFB afectan métricas de negocio y necesitas ejecutar lógica sensible en servidor.

    Por qué importa: reduce bundle inicial, mejora TTFB y simplifica flujos de datos server-side.

    Cómo funciona (resumen): renderizado server-side con funciones asíncronas para fetch/ORM, Server Actions para llamadas server desde forms y control explícito de caché y revalidación.

    De Angular a Next.js 16: por qué no es solo “aprender otra sintaxis”

    Angular es un framework opinado para SPAs: inyección de dependencias, RxJS y templates declarativos. Next.js 16 (App Router) invierte ese paradigma con React Server Components (RSC): renderizado en servidor, HTML entregado al cliente y JavaScript mínimo para interactividad. Documentación oficial Next.js.

    La diferencia no es menor: pasas de pensar “qué corre en el cliente” a “qué debe correr en el servidor”. Ese cambio impacta performance, seguridad y la forma en que estructuras estado y dependencias.

    Tres lecciones técnicas que cambiaron nuestro código

    1) RxJS se queda fuera del camino principal

    En Angular, RxJS orquesta peticiones, eventos y sincronizaciones. Eso ofrece control fino (cancelaciones, operadores), pero añade complejidad de mantenimiento (unsubscribe, memory leaks).

    En Next.js 16, Server Components son funciones async: await fetch() o llamadas al ORM desde el servidor. La simplicidad reduce boilerplate y evita parpadeos de carga en el cliente. Ejemplo real: reemplazar múltiples subscriptions por una única llamada asíncrona en el server simplificó la lógica y redujo errores de sincronización.

    Nota práctica: para cancelaciones del lado del cliente hay que usar explícitamente AbortController; la ergonomía de RxJS no existe por defecto.

    2) La inyección de dependencias se reimagina

    El contenedor DI de Angular es una comodidad arquitectónica (services providedIn: 'root'). React/Next no tienen un DI integrado. Las alternativas que adoptamos:

    • Instancias únicas exportadas desde módulos ES6 (clientes DB, SDKs).
    • React Context solo para estado UI que vive en cliente (tema, sesión).
    • Props/Composición para inyección explícita en componentes que dependen de servicios.

    Resultado: más explicitud y trazabilidad, pero más disciplina para no propagar dependencias globales por accidente.

    3) Server Actions: menos endpoints, menos boilerplate

    Migrar formularios del flujo Angular (form → HttpClient → endpoint REST → backend) a Server Actions colapsó la cadena. En Next.js 16 puedes llamar funciones en el servidor directamente desde el form:

    export async function updateUser(formData: FormData) {
      'use server';
      const name = formData.get('name') as string;
      await db.user.update({ where: { id: session.userId }, data: { name } });
      revalidatePath('/profile');
    }

    El beneficio es claro: menos endpoints internos y menos código repetitivo. El riesgo: mezclar lógica de negocio en componentes si no separamos responsabilidades adecuadamente. Docs de Server Actions

    Fricciones reales que te van a doler en producción

    • Cache y freshness: Next.js App Router tiene capas de caché (memoization, data cache, route cache). Sin revalidate o cache: 'no-store' puedes servir datos obsoletos. Leer.
    • “use client” propagate cost: marcar un componente como cliente arrastra su subárbol y puede romper los beneficios del SSR si importas librerías pesadas.
    • Observabilidad de comportamiento: la frontera servidor/cliente exige testing más exhaustivo (end-to-end + integración server actions) y pipelines de CI que validen rendimiento.
    • Seguridad y surface area: Server Actions facilitan lógica server-side, pero exigen revisar permisos y sanitización con más rigor.

    Criterio práctico para Tech Leads: ¿vale la pena migrar?

    No migres por moda. Migra si:

    • Tu producto es público y SEO o Core Web Vitals impactan conversiones (ver métricas en web.dev/vitals).
    • El bundle inicial y TTFB están bloqueando métricas de negocio.
    • Necesitas ejecutar lógica sensible en servidor para reducir exposición o proteger IP.

    Mantén Angular si:

    • Es un dashboard interno con poca necesidad SEO.
    • El equipo domina RxJS y la arquitectura actual es sostenible.
    • El coste de migración supera el beneficio económico esperado.

    Conclusión

    La migración De Angular a Next.js 16: lo que aprendí migrando un proyecto real fue menos una reescritura técnica y más una reorganización de responsabilidades: qué corre en el servidor, cómo se inyectan dependencias y cómo se gestionan mutaciones. Next.js 16 ofrece ganancias reales en rendimiento y simplicidad operativa, pero exige disciplina (caché, límites use client, separación de responsabilidades). Si tu negocio lo justifica, la inversión devuelve rendimiento y una arquitectura más alineada con un futuro server-first. Si no, Angular sigue siendo una opción sólida y productiva.

    FAQ

    Respuesta: Migramos porque Core Web Vitals malos, TTFB lento y un bundle grande estaban afectando conversión móvil y SEO. La migración fue una decisión de negocio para reducir fricción de usuario y mejorar SEO técnico.

    Respuesta: No hay un reemplazo directo. En Next.js 16 se usa programación asíncrona en Server Components (await fetch(), llamadas al ORM) y, para cancelaciones cliente, AbortController. La lógica de orquestación que RxJS ofrecía suele simplificarse en el servidor o con patrones de composición en cliente.

    Respuesta: Server Actions son funciones que se ejecutan en el servidor y se pueden invocar desde formularios en el cliente. Reducen la necesidad de endpoints REST intermedios. Requieren separar responsabilidades para no mezclar lógica de negocio en componentes. Más detalles.

    Respuesta: Los riesgos principales son caché y freshness (servir datos obsoletos sin revalidate), el coste de marcar componentes como cliente que arrastran subárboles pesados y la necesidad de mayor observabilidad y testing para la frontera servidor/cliente.

    Respuesta: No conviene migrar si el proyecto es un dashboard interno con poca necesidad SEO, si el equipo domina la arquitectura actual o si el coste de migración supera el beneficio económico esperado.

    Respuesta: Usar instancias únicas exportadas desde módulos ES6 (clientes DB, SDKs), React Context para estado UI cliente y props/composición para inyección explícita en componentes. Esto aporta trazabilidad a costa de disciplina para evitar dependencias globales indeseadas.

  • Crea un agente en TypeScript con Mastra para soporte técnico

    Crea un agente en TypeScript con Mastra para soporte técnico

    Crea tu primer agente en TypeScript con Mastra

    Tiempo estimado de lectura: 6 min

    • Mastra es un framework nativo en TypeScript para construir agentes y flujos de IA con validación de esquemas en runtime.
    • Separar Agent, Tool y Model permite pruebas unitarias y facilita cambiar proveedor de LLM.
    • Usa Zod para convertir inputs/outputs del LLM en contratos verificables.
    • Incluye un ejemplo práctico listo para ejecutar (agente de soporte técnico) y reglas operativas para producción.

    Crear tu primer agente en TypeScript con Mastra es la forma más práctica de evitar la fragmentación entre Node.js y microservicios Python. Si tu stack es TypeScript, mantener todo en el mismo lenguaje reduce latencia, elimina fricciones en despliegue y preserva tipos end-to-end. En las siguientes secciones veremos qué es Mastra, su arquitectura y un ejemplo práctico listo para ejecutar.

    Resumen rápido (lectores con prisa)

    Mastra es un framework en TypeScript para agentes de IA que integra validación de esquemas con Zod.

    Separa responsabilidades en Agent, Tool y Model para pruebas y cambio de proveedor de LLM.

    Usa Zod para que las invocaciones a tools sean contratos verificables en runtime.

    Incluye un ejemplo práctico (agente de soporte) y recomendaciones para producción.

    Documentación y repositorio oficiales están disponibles para referencia.

    Crea tu primer agente en TypeScript con Mastra: por qué importa y cuándo usarlo

    Mastra es un framework nativo en TypeScript para construir agentes y flujos de IA. Su ventaja principal no es solo técnica: es contractual. Al integrar Zod para la validación de esquemas como parte del runtime, convierte las llamadas del LLM en contratos verificables, no en texto libre que “parece correcto”. Documentación: mastra.ai/docs. Repositorio: github.com/mastra-ai/mastra.

    Úsalo cuando quieras:

    • Ejecutar agentes dentro del mismo proceso Node/Next.js.
    • Forzar esquemas de entrada/salida con Zod.
    • Testear herramientas aisladas sin invocar modelos.

    No es la solución si necesitas capacidades avanzadas aún no soportadas por Mastra; evalúa la madurez del proyecto antes de producción.

    Arquitectura mínima: Agent, Tool y Model

    Divide responsabilidades desde el inicio:

    • Agent: orquesta la conversación, mantiene historial e instrucciones del sistema.
    • Tool: funciones asíncronas fuertemente tipadas (Zod). Son la única forma controlada en la que el agente “toca” el mundo.
    • Model: abstracción del proveedor de LLM (OpenAI, Anthropic, etc.). Cambiar proveedor debe ser un cambio mínimo.

    Esa separación permite testing unitario de herramientas y garantiza que la lógica de negocio no quede oculta en un prompt.

    Paso a paso: ejemplo práctico (Agente de soporte técnico)

    Instalación rápida

    mkdir mastra-agent && cd mastra-agent
    npm init -y
    npm install @mastra/core zod
    npm install -D typescript @types/node tsx
    npx tsc --init
    export OPENAI_API_KEY="tu_api_key"

    1) Define la herramienta (Tool)

    Controla exactamente qué parámetros acepta el LLM:

    // src/tools/check-service.ts
    import { createTool } from '@mastra/core';
    import { z } from 'zod';
    
    export const checkServiceTool = createTool({
      id: 'check-service-status',
      description: 'Consulta el estado operativo de un servicio interno por nombre.',
      inputSchema: z.object({
        service: z.enum(['api', 'database', 'frontend']),
      }),
      execute: async ({ context }) => {
        // Reemplaza por consultas reales a monitorización/DB
        const statuses = { api: 'degraded', database: 'operational', frontend: 'operational' };
        return { service: context.service, status: statuses[context.service], checkedAt: new Date().toISOString() };
      },
    });

    2) Instancia el agente

    Define instrucciones claras (system prompt) que actúen como contrato operativo:

    // src/agent.ts
    import { Agent } from '@mastra/core/agent';
    import { checkServiceTool } from './tools/check-service';
    
    export const supportAgent = new Agent({
      name: 'TechSupportAgent',
      instructions: `
        Eres un ingeniero de soporte de nivel 1.
        Antes de concluir que un servicio está caído, INVÓCAME la herramienta de estado.
        Responde con datos y recomendaciones técnicas claras.
      `,
      model: { provider: 'OPENAI', name: 'gpt-4o-mini' },
      tools: { checkServiceTool },
    });

    3) Ejecuta el flujo

    Ejecuta el agente y deja que Mastra coordine modelo y tools:

    // src/main.ts
    import { supportAgent } from './agent';
    
    async function main() {
      const prompt = 'Los usuarios reportan lentitud. ¿Está la API bien?';
      const res = await supportAgent.generate(prompt);
      console.log(res.text);
    }
    
    main().catch(console.error);

    Lanza con npx tsx src/main.ts. Mastra coordina al LLM y las herramientas: si el modelo decide invocar checkServiceTool, el framework valida el input con Zod, ejecuta la función y alimenta la respuesta final.

    Reglas prácticas para llevar esto a producción

    1. Observabilidad desde el día 0: logs estructurados en cada invocación de tool (request id, input validado, tiempo, resultado).

    2. Errores como datos: las herramientas deben devolver errores tipados que el agente pueda razonar y comunicar (no lanzar excepciones sin contexto).

    3. Testing aislado: tests unitarios para execute y tests de integración para la orquestación. No confundas velocidad con cobertura.

    4. CI/CD: bloquea merges que introduzcan nuevas dependencias sin revisión de licencia/reputación. En entornos corporativos, valida paquetes recomendados por LLMs.

    5. Ownership y ADRs: cualquier herramienta crítica debe tener un Architecture Decision Record que explique por qué existe y cómo se prueba.

    Para guiar verificaciones de seguridad y dependencia sigue prácticas de NIST/OWASP (por ejemplo: owasp.org).

    Conclusión: Mantén el criterio humano donde importa

    Mastra te da la ergonomía de TypeScript y contratos verificables con Zod. Eso reduce alucinaciones estructurales y acelera integración en stacks web. Pero la ganancia real viene cuando aplicas disciplina: diseño previo, validación estricta, observabilidad y pruebas. Implementa el agente, mide cómo toma decisiones y exige que cualquier acción en producción esté documentada y testeada. En la próxima entrega de Dominicode mostraremos cómo añadir memoria persistente y encadenar múltiples tools para workflows complejos.

    Dominicode Labs

    Si trabajas en automatización, agentes o workflows y quieres ejemplos prácticos y guías operativas, consulta Dominicode Labs. Encontrarás recursos que complementan patrones de diseño y pruebas para agentes en producción.

    FAQ

    Mastra es un framework nativo en TypeScript para construir agentes y flujos de IA que integra Zod para validación de esquemas en runtime.

    Cuando tu stack principal es TypeScript/Node.js y quieres ejecutar agentes en proceso, forzar esquemas de entrada/salida y testear herramientas sin invocar modelos externos.

    Integra Zod como parte del runtime: las entradas a las tools se validan contra esquemas definidos y solo se ejecutan si cumplen el contrato tipado.

    Sí. La arquitectura separa Model como una abstracción, de modo que cambiar proveedor (OpenAI, Anthropic, etc.) debe ser un cambio mínimo en la configuración.

    Observabilidad desde el día 0, errores como datos tipados, testing aislado, control de dependencias en CI/CD y ADRs para herramientas críticas.

    La documentación oficial está en mastra.ai/docs y el repositorio en github.com/mastra-ai/mastra.