Author: Dominicode

  • Recursos prácticos para aprender Spec-Driven Development

    Recursos prácticos para aprender Spec-Driven Development

    Listado de recursos para aprender SDD en castellano

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • Spec-Driven Development (SDD) propone escribir especificaciones deterministas antes de codificar.
    • Un buen spec es el contrato entre el equipo humano y los agentes de IA; cuando es claro, reduce fragilidad en el código generado.
    • Lee la teoría primero, aplica en un proyecto pequeño y luego usa agentes (por ejemplo Claude Code) para cerrar el ciclo.
    • Versiona specs junto al código, declara contratos formales (OpenAPI/JSON Schema) y valida en runtime.

     

    Introducción

    El Spec-Driven Development (SDD) ya no es una moda: es la forma práctica de obtener código fiable cuando trabajas con agentes de IA. Si buscas un listado de recursos para aprender SDD en castellano, este artículo reúne lo esencial —teoría, práctica y pasos accionables— y muestra cómo convertir especificaciones en artefactos ejecutables por agentes como Claude Code.

    En las primeras líneas: el Spec-Driven Development consiste en escribir especificaciones deterministas antes de codificar. Esa especificación es el contrato que el equipo humano y el agente de IA van a cumplir. Si no está clara, el código generado será frágil; si está bien definida, el agente actúa como un ejecutor reproducible.

    Resumen rápido (lectores con prisa)

    SDD = escribir especificaciones deterministas y ejecutables antes de codificar. Úsalo cuando delegues trabajo repetible a agentes de IA o necesites contratos claros entre equipos. Importa porque reduce errores de generación y facilita trazabilidad. Funciona definiendo contratos formales (OpenAPI/JSON Schema), validándolos en runtime y versionándolos junto al código.

    Listado de recursos para aprender SDD en castellano

    SDD — Spec-Driven Development (libro)

    SDD — Spec-Driven Development

    Por qué leerlo: es la base conceptual sobre cómo diseñar especificaciones que funcionen tanto para personas como para modelos. Explica estructura de especificaciones, convenciones de contratos, ejemplos de modelos de datos y patrones para casos límite. Ideal para tech leads y arquitectos que deben estandarizar cómo se escribe el “qué” antes de generar el “cómo”.

    Construye con IA: de la idea al producto con Claude Code (curso Udemy)

    Construye con IA: de la idea al producto con Claude Code (curso Udemy)

    Por qué hacerlo: Claude Code es un agente que opera en tu entorno de desarrollo. El curso enseña a estructurar especificaciones que el agente pueda ingerir, supervisar la ejecución y corregir desviaciones. Es la práctica necesaria para ver cómo una especificación bien escrita reduce iteraciones y errores de generación.

    Cómo usar estos recursos de forma práctica (secuencia recomendada)

    1. Lee el libro primero. Construye el marco mental: ¿qué debe contener una especificación? ¿cómo documentar invariantes, límites y errores esperados?

    2. Aplica lo leído a un pequeño proyecto: escribe una especificación completa (archivo Markdown) para una funcionalidad simple: endpoint, modelo de datos y flujos de error.

    3. Realiza el curso y usa Claude Code para ejecutar la especificación. Observa dónde el agente alucina o omite pasos; corrige la especificación y repite.

    Esta secuencia cierra el ciclo: teoría → especificación real → ejecución con agente → ajuste de especificación.

    Paso 1

    Lee el libro y define la estructura mínima de tu spec: título, objetivo, invariantes y errores esperados.

    Paso 2

    Escribe la especificación en Markdown dentro del repo y convierte contratos en OpenAPI/JSON Schema.

    Paso 3

    Usa Claude Code para ejecutar; recopila fallos, ajusta la spec y repite hasta estabilidad.

    Plantilla mínima de una especificación SDD (práctica)

    Incluye estos apartados en un archivo Markdown dentro del repo (Docs-as-code):

    • Título y objetivo (1–2 frases).
    • Requisitos no funcionales (latencia, SLAs, seguridad).
    • Modelos de datos (ej. JSON Schema / OpenAPI snippets).
    • Casos de uso y flujos (máquina de estados simplificada).
    • Invariantes y restricciones (qué no debe pasar).
    • API contract (endpoint, métodos, parámetros, errores).
    • Tests de aceptación (inputs esperados y resultados).
    • Checklist de despliegue y rollback.

    Guardar la especificación cerca del código facilita que los agentes la lean como contexto y que el equipo la mantenga sincronizada.

    Buenas prácticas técnicas para equipos que adoptan SDD

    • Versiona las especificaciones en el mismo repo que el código. Nada de Confluence aislado.
    • Declara contratos formales (OpenAPI, JSON Schema). Convierte esos esquemas en herramientas ejecutables por agentes.
    • Usa prompts y archivos de contexto estándar (por ejemplo .cursorrules o system prompts) para que los agentes carguen las convenciones del proyecto.
    • Implementa validación: transforma tus schemas en validadores runtime (Zod o Ajv) y aplícalos a cada tool_use.
    • Instrumenta trazabilidad: cada ejecución automatizada debe dejar un rastro del prompt, la versión del spec y el resultado del agente.

    Limitaciones y siguientes pasos

    El ecosistema en castellano está creciendo; estos dos recursos son el núcleo. Para necesidades avanzadas —memoria a largo plazo, flujos que duran días, trazabilidad distribuida— añade prácticas e infraestructuras: persistencia (PostgreSQL/pgvector), orquestadores (n8n, LangGraph) y observabilidad (OpenTelemetry). Pero no conviertas la arquitectura en excusa: domina la especificación primero.

    Conclusión

    Si vas a trabajar con agentes de IA, aprender SDD es priorizar el acto más rentable: especificar bien. Empieza por leer el libro en Leanpub y practica con Claude Code en Udemy. Transforma la especificación en contrato vivo, versionado y ejecutable. Con eso, reduces iteraciones, controlas costos por token y, sobre todo, dejas de depender de la suerte cuando delegas en agentes.

    Para equipos interesados en implementar prácticas de SDD y automatización con agentes, una continuación lógica es revisar recursos y experimentos en Dominicode Labs.

     

    FAQ

    Respuesta: SDD consiste en escribir especificaciones deterministas antes de codificar; estas actúan como contrato entre equipos humanos y agentes de IA.

    Respuesta: Versionar las especificaciones en el mismo repo garantiza sincronía con el código, facilita revisiones y evita documentación aislada que se queda obsoleta.

    Respuesta: Se recomiendan contratos formales como OpenAPI y JSON Schema porque son legibles por herramientas y agentes, y permiten generar validadores y mocks.

    Respuesta: Transforma tus schemas en validadores runtime (por ejemplo Zod o Ajv) y ejecútalos en cada tool_use o etapa donde el agente entregue artefactos.

    Respuesta: Agentes como Claude Code ejecutan especificaciones en tu entorno; su papel es reproducir flujos definidos por la spec y permitir iteración rápida sobre fallos.

    Respuesta: Tras la teoría, aplica en un proyecto pequeño: escribe una spec, ejecútala con un agente, corrige las desviaciones y automatiza validaciones y trazabilidad.

  • Errores comunes al migrar a React Server Components en producción

    Errores comunes al migrar a React Server Components en producción

    React Server Components en producción: errores que nadie te cuenta

    Tiempo estimado de lectura: 5 min

    • Fronteras claras: mezclar datos pesados del servidor con Client Components provoca serialización y payloads enormes.
    • No convertir todo a client: usar “use client” globalmente anula los beneficios de RSC y regresa a una SPA pesada.
    • Latencia y caching: llamadas secuenciales y caché agresiva generan TTFB alto y fugas de datos entre usuarios.
    • Audita dependencias: muchas librerías no están preparadas para ejecución en server; lazy-load o wrappers client son necesarios.

    Introducción

    React Server Components en producción: errores que nadie te cuenta. Lo digo sin rodeos: los tutoriales y demos no te preparan para operarlos en tráfico real. En ese salto es donde aparecen fugas de datos, payloads monstruosos y cuellos de botella invisibles que desarman la promesa de “menos JS, mejor rendimiento”.

    Este artículo enumera los fallos concretos que verás en proyectos reales, aporta soluciones técnicas y define cuándo NO migrar a RSC. Incluye referencias y enlaces oficiales para que puedas profundizar: Suspense y caching en Next.js.

    Resumen rápido (lectores con prisa)

    Qué es: Patrón que permite renderizar parte de la UI en el servidor y enviar un árbol serializado al cliente.

    Cuándo usarlo: cuando puedas controlar la frontera server/client, minimizar datos pasados al cliente y beneficiarte de menos JS inicial.

    Por qué importa: mejora rendimiento y seguridad si se adopta con disciplina en serialización, caché y orquestación de datos.

    Cómo funciona: Server Components pueden acceder a recursos de servidor; Client Components se hidratan en cliente y deben recibir solo datos mínimos.

    1. React Server Components en producción: la frontera que rompe todo

    El error raíz es conceptual: tratar la frontera server/client como una línea estética en lugar de una decisión arquitectónica. Un Server Component puede acceder a la BD y luego pasar objetos enormes como props a un Client Component. Eso obliga a React a serializar todo en el HTML/JSON de respuesta. Resultado: la reducción del bundle se convierte en megabytes de payload.

    Ejemplo típico (malo)

    • Server Component hace SELECT * FROM orders WHERE user_id = ? y pasa todos los registros a <OrdersTable use client />.
    • El navegador recibe un payload serializado de decenas de MB.

    Solución: procesar, paginar y resumir en el servidor. Pasa al cliente solo el minimum viable (IDs, count, primeros N items) y provee endpoints client-side para cargar la página de datos al interactuar.

    2. El pánico del “use client” y la regresión a SPA

    Cuando algo falla (proveedores, librerías de UI, hooks), el atajo más común es colocar "use client" en el layout. Eso convierte todo el árbol en Client Components y anula el beneficio de RSC: vuelves a una SPA grande, con mayor complejidad y sin reducción de JS.

    Patrón correcto:

    • Mantén providers y estado en componentes hoja que realmente necesitan interactividad.
    • Diseña la composición para que los Client Components reciban props mínimos y, si requieren datos pesados, llamen a endpoints específicos (fetch desde cliente) o utilicen streaming.

    3. Waterfalls invisibles: el backend secuencial que mata TTFB

    Código like-this en Server Component:

    const user = await getUser(id);
    const prefs = await getPrefs(user.configId);
    const orders = await getOrders(user.id);
    

    Eso es secuencial: suma latencias. Aunque ocurre en servidor, el usuario espera. Paraleleza con Promise.all cuando no hay dependencia, y usa Suspense para streaming progresivo cuando sí hay dependencias parciales.

    Patrón secuencial y solución

    • Identifica llamadas independientes y ejecútalas en paralelo.
    • Usa streaming y Suspense para mostrar partes de la vista cuando están listas.
    • Mide TTFB en staging bajo carga para detectar waterfalls invisibles.

    4. Caché agresiva = fuga de datos entre usuarios

    Next.js y otros frameworks aplican caching por defecto en render server. Si renderizas una ruta con datos privados y no marcas la petición como dinámica, puedes cachear la vista de un usuario y servirla a otro. Es real y está pasando en producción.

    Contramedidas:

    • Para datos privados usa { cache: 'no-store' } en fetch o llama a APIs que leen cookies()/headers() (esto fuerza render dinámico en Next.js).
    • Revisa la documentación de caché de Next.js: caching en Next.js.
    • Considera políticas CDN más conservadoras para rutas autenticadas.

    5. Integraciones de terceros que no están listas para server execution

    Muchas librerías npm asumen un entorno DOM. Al ejecutar en server, aparecen errores en build o comportamiento inesperado. Resultado: el equipo marca "use client" masivo y pierde las ventajas. Revisa dependencias: algunas requieren reemplazo o lazy-loading estricto.

    Táctica práctica:

    • Audita las dependencias con npm ls y pruebas de build en CI que marquen dónde fallan.
    • Si una librería solo se usa en un widget, envuélvela en un Client Component lazy-loaded.

    Cuándo NO usar React Server Components

    No migres a RSC si tu producto encaja en alguno de estos casos:

    • Aplicaciones offline-first o PWAs que deben funcionar sin servidor.
    • Interfaces de hiper-interactividad: editores gráficos, juegos, vídeo en tiempo real o UIs con WebSockets a alta frecuencia.
    • Bases de código legacy sin presupuesto de reescritura: migrar Redux heavy/class components = reescritura, no refactor.

    Checklist práctico antes de migrar a producción

    1. Delimita claramente boundaries: quién corre en server y qué mínima data pasa al cliente.
    2. Añade tests de integración que simulen carga y validen payloads.
    3. Forza políticas de cache por ruta (privada vs pública).
    4. Instrumenta logs de tamaño de respuesta y tokenización/serialización.
    5. Adopta streaming/Suspense para vistas complejas; usa Promise.all para llamadas paralelas.
    6. Audita dependencias y evita convertir el layout en client por comodidad.

    Conclusión: RSC exige disciplina, no solo adopción

    React Server Components entregan ventajas claras (menos JS inicial, mayor seguridad para secretos, mejor SEO). Pero funcionan en producción solo si el equipo re-aprende backend: serialización, caching, latencia y orquestación de datos. La migración exitosa no es técnica aislada; es un cambio de modelo mental: pasar de “componentes” a “árboles de dependencias de red”. Si no estás dispuesto a trazar fronteras con rigor, no migres: estarás complicando tu arquitectura sin ganar sus beneficios.

    FAQ

    ¿Qué es exactamente un React Server Component?

    Un React Server Component se renderiza en el servidor y puede acceder a recursos del backend. No se hidrata en el cliente como un Client Component y se envía serializado al navegador.

    ¿Cuándo debo evitar migrar a RSC?

    Evita migrar si necesitas soporte offline completo, tienes UIs de hiper-interactividad (editores, juegos, video en tiempo real) o una base de código legacy sin presupuesto para reescritura.

    ¿Cómo evito pasar payloads gigantes al cliente?

    No pases objetos completos como props. Resumir, paginar y enviar solo lo mínimo necesario (IDs, count, primeros N items). Usa endpoints client-side para cargar datos adicionales bajo demanda.

    ¿Qué problemas de caché debo vigilar en Next.js?

    Cuidado con el render estático por defecto: rutas con datos privados pueden quedar cacheadas. Para datos privados usa { cache: 'no-store' } en fetch o APIs que lean cookies()/headers() para forzar render dinámico.

    ¿Cómo detectar y arreglar waterfalls en Server Components?

    Mide TTFB en staging bajo carga, revisa llamadas secuenciales en Server Components y paraleliza con Promise.all cuando sea posible. Usa streaming y Suspense para render progresivo.

    ¿Qué hago con librerías que fallan en server?

    Audita dependencias con npm ls, añade pruebas de build en CI y envuelve las librerías problemáticas en Client Components lazy-loaded o busca alternativas compatibles con server execution.

  • Aprende a escribir especificaciones efectivas para LLMs

    Aprende a escribir especificaciones efectivas para LLMs

    Por qué dejé de escribir código desde cero y empecé a hacer specs primero

    Tiempo estimado de lectura: 3 min

    • Menos correcciones manuales: las specs reducen el tiempo invertido en ajustar código generado por LLMs.
    • Contratos ejecutables: una spec bien definida evita ambigüedades y deuda técnica.
    • Escalabilidad y previsibilidad: la spec es la fuente de verdad para cambios y nuevos colaboradores.

    ¿Sabes qué consume más tiempo que escribir código? Corregir el código que generó la IA porque nadie le dejó claro qué hacer.

    Hace un par de años disfrutaba abrir un editor en blanco. Era adrenalina pura: estructura, imports, resolver problemas “sobre la marcha”. Parecía productividad. Era ilusión.

    La transición a escribir specs primero cambió eso por completo. No porque sea más elegante, sino porque es más efectivo. Aquí te cuento por qué dejé de escribir código desde cero y empecé a hacer specs primero, qué contiene una spec útil y cómo eso transforma la relación entre humanos, agentes y código.

    Resumen rápido (lectores con prisa)

    Spec‑Driven Development: definir specs precisas antes de implementar reduce ambigüedades, minimiza correcciones manuales y convierte la spec en la fuente de verdad. Útil cuando el producto se mantiene, la lógica es compleja o hay múltiples integradores. Implementación: especifica stack, datos, contratos de API, reglas de negocio y casos de aceptación.

    Por qué dejé de escribir código desde cero y empecé a hacer specs primero

    El catalizador fue simple: gastaba horas ajustando código generado por LLMs. No es culpa de la IA. Es culpa de la ambigüedad. Un modelo no conoce tus convenciones, tus límites ni las decisiones que tomaste el martes. Para un LLM, lo que no está escrito no existe.

    Cuando trabajas sin spec, cada prompt es un microcontrato mal redactado. Resultado: fragmentos que funcionan aisladamente y rompen la coherencia global. El coste no es solo tiempo; es deuda técnica que aparece en sprint 3 y se siente en el cuello del repo.

    Escribir specs primero no es volver a la documentación de los 90. Es escribir contratos ejecutables: lo suficiente para que un agente implemente sin inventar nada. Eso cambió mi productividad: menos correcciones, menos parches, más iteraciones reales.

    ¿Qué lleva una spec que funcione con IA?

    No basta con una descripción bonita. Una spec útil es precisa, limitada y accionable. Esto es lo que siempre incluyo:

    • Stack exacto con versiones. No “React moderno”. React 18.3, Next.js 14, etc.
    • Modelo de datos. Tablas, campos, tipos y restricciones. Si usas UUID, dilo.
    • Contratos de API. Endpoints, payloads de ejemplo, códigos de error y formatos.
    • Reglas de negocio explícitas. Qué hacer y, más importante, qué no hacer.
    • Casos de aceptación. Escenarios claros que definen el comportamiento visible.
    • Límites del MVP. Qué se queda fuera en esta iteración y por qué.

    El documento vive en el repo (spec.md), versionado. Si algo cambia, la spec cambia primero. No al revés.

    Si quieres una guía práctica para redactar specs que funcionen con LLMs, uso y recomiendo el libro Spec‑Driven Development.

    Cómo cambiaron mis sesiones con agentes

    Antes: abría un chat, pedía componentes, pegaba código. Después de dos horas, el sistema era Frankenstein.

    Ahora: escribo la spec, lanzo al agente en terminal con la instrucción clara—lee spec.md e implementa la Fase X—y reviso diffs. El agente crea archivos, instala dependencias y propone un conjunto coherente desde la raíz. Mi rol pasa de “peón que teclea” a “arquitecto que aprueba”.

    Regla de oro

    Nunca corrijo el código directamente para resolver una ambigüedad. Actualizo la spec y mando al agente a refactorizar. Si corriges el código sin tocar la spec, el día siguiente volverás a ver el mismo fallo cuando el agente regenera algo incompatible.

    Beneficios reales (sin poesía)

    • Menos tiempo en ajustes menudos. Más tiempo en decisiones estratégicas.
    • Menos deuda técnica porque las reglas de diseño se establecen antes.
    • Cambios más predecibles: si una feature cambia, la spec es la fuente de verdad.
    • Escalabilidad del equipo: nuevos desarrolladores o agentes arrancan en horas, no en días.

    Cuando esto no aplica

    No todos los proyectos necesitan SDD. Si estás escribiendo un script de 50 líneas o prototipando algo desechable para validar una idea, un prompt rápido tiene sentido. SDD brilla cuando el producto crece, hay datos críticos o múltiples integradores.

    Regla práctica: si la base de código será mantenida más de un mes o la lógica de negocio es compleja, escribe la spec.

    El cambio de rol del developer

    Adoptar specs no elimina el trabajo humano; lo eleva. Ahora se pide que tomes decisiones tempranas y explícitas: límites, trade-offs, casos borde. La ejecución se delega, la responsabilidad de diseño sigue siendo humana.

    Ese es el valor real: profesionales que saben diseñar sistemas se vuelven más valiosos porque delegan la repetición y retienen la toma de decisiones estratégicas.

    El libro Spec‑Driven Development recoge las plantillas, patrones y ejemplos que uso todos los días para que un LLM implemente sin inventos. Si estás cansado de arreglar lo que la IA rompe, empieza por escribir la spec. Es incómodo al principio, pero harás más en menos tiempo y sin excusas.

    La próxima iteración de tu proyecto debería empezar con un archivo spec.md, no con un editor en blanco. Hazlo y verás que tu trabajo deja de parecer frenético: se vuelve deliberado.

    Para equipos que adoptan automatización y agentes como parte del flujo de desarrollo, una práctica centralizada de especificaciones acelera la coordinación entre humanos y máquinas. Si estás explorando flujos donde agentes y workflows son críticos, mira iniciativas y recursos prácticos en Dominicode Labs para ejemplos aplicables y plantillas.

    FAQ

    Respuesta: Spec‑Driven Development es la práctica de definir especificaciones precisas y accionables antes de implementar. Las specs actúan como contratos ejecutables para equipos humanos y agentes.

    Respuesta: Escribe una spec cuando la base de código será mantenida más de un mes, la lógica de negocio es compleja o hay múltiples integradores. Para scripts pequeños o prototipos muy tempranos, un prompt rápido puede bastar.

    Respuesta: Una spec mínima incluye: stack y versiones, modelo de datos, contratos de API con ejemplos, reglas de negocio claras y casos de aceptación. También define los límites del MVP.

    Respuesta: Mantén la spec en el repo, lanza al agente con instrucciones que apunten al archivo (por ejemplo, “lee spec.md e implementa la Fase X”) y revisa diffs en lugar de editar código directamente.

    Respuesta: Si alguien modifica código sin actualizar la spec, la siguiente regeneración por parte del agente puede reintroducir el fallo. La regla de oro es: actualiza la spec y vuelve a ejecutar al agente.

    Respuesta: Guarda las specs en el repositorio como archivos versionados (ej.: spec.md). Cualquier cambio debe pasar por control de versiones para que la spec sea la fuente de verdad.

  • Cómo tipar las respuestas de una LLM utilizando Zod y TypeScript

    Cómo tipar las respuestas de una LLM utilizando Zod y TypeScript

    Cómo tipar las respuestas de una LLM con Zod + TypeScript

    Tiempo estimado de lectura: 4 min

    • Valida en runtime: TypeScript desaparece en runtime; usa Zod para convertir datos inciertos en contratos verificables.
    • Esquema primero: diseña el esquema Zod como fuente única, extrae tipos con z.infer<> y serializa el esquema en el prompt.
    • Elige parse vs safeParse: .parse() para fallos severos, .safeParse() para autocorrección y reintentos.
    • Producción robusta: logging contextual, reintentos limitados, métricas y SLOs para gestionar errores LLM.

    Saber cómo tipar las respuestas de una LLM con Zod + TypeScript aparece en las primeras líneas porque es lo que evita que un agente, workflow o microservicio se rompa en producción. El modelo devuelve JSON, a menudo; nunca con la forma exacta que esperabas. .parse() y z.infer<> no son trucos: son la defensa que convierte datos inciertos en contratos verificables.

    Resumen rápido (lectores con prisa)

    Qué: Usa Zod para validar y transformar respuestas de LLM en runtime.

    Cuándo: Siempre que vayas a persistir datos o ejecutar acciones críticas basadas en la salida de una LLM.

    Por qué importa: TypeScript no valida en runtime; sin validación, datos malformados pueden romper sistemas en producción.

    Cómo funciona: Diseña el esquema Zod como fuente única, extrae tipos con z.infer<>, limpia la salida si es necesario y valida con .parse() o .safeParse().

    Por qué JSON.parse() + as es una trampa (y qué rompe)

    El patrón clásico:

    const obj = JSON.parse(response) as MyType;

    Es práctico. Es una mentira. TypeScript desaparece en runtime; as no valida nada. Los fallos típicos de LLMs:

    • JSON envuelto en bloques Markdown (“`json … “`).
    • Strings donde esperabas números (“15” vs 15).
    • Campos faltantes, claves renombradas o truncamiento por token limit.
    • Estructuras válidas pero semánticamente inválidas (amount: -5).

    Si confías en casts, esos problemas llegan a tu base de datos o a la lógica que ejecuta acciones. Validación en runtime es obligatoria.

    El patrón sólido: esquema primero, prompt segundo

    1. Diseña el esquema Zod como la única fuente de verdad.
    2. Extrae el tipo estático con z.infer<>.
    3. Incluye una versión legible del esquema en el prompt.
    4. Valida la respuesta con .safeParse() / .parse() antes de usarla.

    Este patrón convierte la salida estocástica de la LLM en una entrada controlada para tu sistema.

    Ejemplo práctico mínimo

    import { z } from 'zod';
    
    const TaskSchema = z.object({
      title: z.string().min(5),
      priority: z.enum(['low','medium','high']),
      estimatedHours: z.number().positive().optional(),
    });
    
    type Task = z.infer;

    Al pedir al modelo que devuelva JSON, serializa el esquema (o su forma) en el prompt para guiar la salida.

    Limpieza defensiva y parse()

    Los LLMs suelen añadir markdown. Limpia antes de parsear:

    function cleanJson(raw: string) {
      return raw.replace(/```json\n?|\n?```/g, '').trim();
    }
    
    const parsed = JSON.parse(cleanJson(rawOutput));
    const valid = TaskSchema.parse(parsed); // lanza ZodError si falla

    Usa .parse() cuando quieras detener el flujo y tratar la anomalía como error severo (útil en endpoints HTTP que deben devolver 4xx/5xx claros).

    .safeParse() y auto‑corrección de prompts

    En agentes autónomos o workflows escalables (n8n, agentes con herramientas), es preferible no lanzar. .safeParse() devuelve { success, data?, error? } para manejar fallos:

    const result = TaskSchema.safeParse(parsed);
    if (!result.success) {
      // registrar, emitir métricas y reintentar con autocorrección
      const zodErrors = result.error.flatten();
      // reintentar: enviar a la LLM el error y pedir JSON corregido
    }

    Patrón de autocorrección: incluye los errores de Zod en un nuevo prompt — el LLM suele corregir la estructura en el siguiente intento.

    Structured Outputs no elimina Zod

    Structured Outputs de OpenAI ayuda a reducir errores de formato (Structured Outputs). Aun así:

    • No controla cortes por token o fallos de red.
    • No valida la semántica (p. ej., números positivos).
    • No sustituye la necesidad de validar localmente antes de persistir o ejecutar acciones.

    Zod sigue siendo la última línea de defensa.

    Operativa en producción: logging, reintentos y SLOs

    • Registra errores de validación con contexto (prompt, response, zod.flatten()).
    • Implementa reintentos limitados con backoff y un máximo de autocorrecciones.
    • Mide métricas: tasa de validación fallida por modelo y prompt, latencia de corrección.
    • Decide SLOs: p. ej., si tras 2 reintentos sigue fallando, encolar para revisión humana.

    Esto transforma un fallo LLM en un incidente manejable, no en una caída silenciosa.

    Consejos prácticos y anti‑patrones

    • No uses as para confiar en la salida del modelo. Siempre valida.
    • Mantén los esquemas Zod como fuente única; evita duplicar interfaces manualmente.
    • Evita validaciones laxas (p. ej., z.any()) en bordes críticos.
    • Serializa el esquema de forma legible en el prompt, no como dump técnico que el modelo no entenderá.
    • Usa discriminated unions para estados exclusivos; obligan a la LLM a responder con casos válidos.

    Conclusión técnica

    Tipar las respuestas de una LLM con Zod + TypeScript no es una cuestión de estilo: es ingeniería de fiabilidad. .parse() y z.infer<> convierten la salida no determinista de una IA en datos verificables. Si construyes agentes, pipelines en n8n o features que actúan sobre sistemas críticos, aplicar este patrón es la diferencia entre sistemas que escalan y sistemas que requieren vigilancia humana constante. Implementa el esquema primero, valida siempre y deja que la LLM vuelva a intentarlo cuando falle — pero que falle donde tú lo controles.

    Para equipos que implementan flujos autónomos y pipelines de IA, una práctica útil es centralizar patrones de validación y autocorrección; esto es exactamente el tipo de trabajo que se experimenta en Dominicode Labs, donde se documentan plantillas y prácticas para agentes y workflows.

    FAQ

    ¿Qué es Zod y por qué usarlo?

    Zod es una librería de validación y parsing para JavaScript/TypeScript que permite definir esquemas y validar datos en runtime. Se usa para asegurar que los datos provenientes de fuentes no confiables (como LLMs) cumplen un contrato antes de ser consumidos por la aplicación.

    ¿Por qué no usar JSON.parse() + as?

    Porque as es solo una aserción en TypeScript y no realiza validación en runtime. JSON.parse() + as asume que la estructura es correcta; si no lo es, introducirás datos inválidos en tu sistema.

    ¿Cuándo usar .parse() vs .safeParse()?

    Usa .parse() cuando quieras que una anomalía detenga el flujo y sea tratada como error severo (por ejemplo, en endpoints HTTP que deben devolver 4xx/5xx). Usa .safeParse() cuando prefieras manejar el fallo (registrar, reintentar con autocorrección) sin lanzar una excepción.

    ¿Cómo incluir el esquema en el prompt?

    Serializa una versión legible del esquema en el prompt (por ejemplo, un objeto JSON con tipos esperados o una tabla de campos requeridos/formatos). Evita dumps técnicos largos; prioriza ejemplos y restricciones clave que la LLM entienda fácilmente.

    ¿Los Structured Outputs de OpenAI reemplazan a Zod?

    No. Structured Outputs reduce errores de formato, pero no controla cortes por token, fallos de red ni valida semántica (p. ej., números positivos). Zod sigue siendo necesario para validación en runtime.

    ¿Qué debo registrar cuando falla la validación?

    Registra el prompt, la respuesta cruda, el resultado de result.error.flatten() o el stack de la excepción, e información contextual (modelo, versión del prompt, intento actual). Estos datos facilitan autocorrección y análisis de causa.

  • Cómo elegir entre Hono, NestJS y Express en 2026

    Cómo elegir entre Hono, NestJS y Express en 2026

    Hono vs Express vs NestJS: cuál usar en 2026

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Decide por ejecución y mantenimiento: Edge/Serverless → Hono; contenedores y equipos grandes → NestJS; Express solo para legacy.
    • Hono sigue estándares Web (Fetch API) → despliegue directo en Cloudflare Workers, Deno y Bun; bundles mínimos y cold starts bajos.
    • NestJS aporta estructura, DI y patterns enterprise que facilitan gobernanza en equipos grandes.
    • Patrón recomendado: combinar Hono en el perímetro y NestJS en el core para optimizar latencia y mantenibilidad.

    Tabla de contenidos

    Resumen rápido (lectores con prisa)

    Hono es un microframework basado en la Fetch API ideal para despliegues Edge/Serverless con cold starts mínimos. NestJS es un framework estructurado con DI pensado para equipos grandes y aplicaciones empresariales. Express queda como opción legacy; para nuevo desarrollo en Node considera Fastify. Usa Hono en el perímetro y NestJS en el core cuando necesitas ambas propiedades.

    Introducción

    Hono vs Express vs NestJS: cuál usar en 2026 es la pregunta que debes resolver antes del primer commit. No es trivia: elegir mal condiciona latencia, coste, pruebas y, sobre todo, la capacidad del equipo para mantener código sano durante años.

    Si vas a desplegar en Cloudflare Workers, Deno o Bun, Hono cambia las reglas. Si tu sistema vive en Kubernetes y lo mantienen varios equipos, NestJS también cambia las reglas. Express… debería quedarse en mantenimiento.

    Hono vs Express vs NestJS: criterio de elección en 2026

    Primera regla: responde a dos preguntas concretas antes de elegir.

    • ¿Dónde se ejecutará el código? (Edge / Serverless vs contenedor)
    • ¿Quién lo mantendrá? (1–3 devs vs equipos >5)

    Hono está diseñado sobre estándares Web (Fetch API). Eso le da dos ventajas técnicas inmediatas: ejecuta sin cambios en Cloudflare Workers y Deno, y los bundles son mínimos → cold starts casi nulos. Ideal para servicios perimetrales: autenticación perimetral, proxies, transformaciones ligeras y APIs públicas de alta concurrencia.

    NestJS es lo opuesto deliberado: peso inicial mayor, pero estructura y DI que escalan en equipos grandes. Si necesitas módulos, interceptores, pipes, testing con mocks y un modelo mental homogéneo entre 10–50 ingenieros, NestJS reduce la deuda humana.

    Express sigue vivo por legacy. Técnicamente tiene problemas: acoplamiento a primitivas de Node (IncomingMessage/ServerResponse), soporte TypeScript no nativo y mala compatibilidad con runtimes Edge sin polyfills. Para proyectos nuevos, Fastify es una alternativa Node que merece consideración por rendimiento y plugins modernos.

    Performance y cold starts: cuándo importa realmente

    Si tu SLA pide latencia global baja y tus endpoints reciben picos distribuidos geográficamente, los cold starts importan. Hono arranca en milisegundos; NestJS arranca en cientos. Esa diferencia se traduce en UX y factura cuando se escala en funciones serverless.

    Ejemplo práctico:

    • API pública de alta concurrencia (CDN + Edge): Hono en Workers.
    • Sistema de facturación con colas, auditoría y scheduling: NestJS en contenedores.

    No mezcles requisitos. Si necesitas ambos, separa responsabilidades: Hono en el perímetro, NestJS en el núcleo.

    Escalabilidad de equipo y mantenibilidad

    NestJS gana por goleada en proyectos donde:

    • Múltiples equipos aportan features.
    • Necesitas contratos claros (interfaces, DTOs, guards).
    • Quieres testing coherente con DI y mocks.

    Hono exige disciplina. Sin una capa organizativa —convenios de carpeta, inyección manual, testing— terminas con endpoints inconexos. Aún así, para equipos pequeños o equipos senior que aceptan convenciones internas, Hono es una opción mantenible.

    Seguridad, observabilidad y ecosistema

    NestJS integra patterns enterprise: interceptores para logging, guards para auth, módulos para integración de colas (BullMQ), microservicios gRPC, etc. Si necesitas trazabilidad distribuida y middlewares estandarizados, te lo pone más fácil.

    Hono no te impide instrumentar trazas, pero requiere que diseñes la integración desde cero. Para infra ligera y métricas puntuales está bien; para auditoría y cumplimiento, NestJS acelera la adopción.

    Reglas prácticas para decidir (lista accionable)

    1. Despliegue Edge (Cloudflare Workers, Deno, Bun) → Hono. Docs: https://hono.dev, Cloudflare Workers: https://developers.cloudflare.com/workers
    2. Núcleo empresarial en Kubernetes → NestJS. Docs: https://docs.nestjs.com
    3. Proyecto nuevo pequeño, necesitas rendimiento en Node → Fastify sobre Express. Fastify: https://www.fastify.io
    4. Mantener app legacy en Express → parche, migración gradual a Fastify/NestJS o mantener si coste de migración es mayor.
    5. Necesitas tipado extremo end-to-end con frontend TS → Hono RPC o compartir DTOs desde NestJS.
    6. Requisito de cold starts <20ms → Hono (Edge); NestJS requiere contenedores siempre calientes.

    Patrón recomendado: combinar, no elegir a ciegas

    La arquitectura más práctica en 2026 no es monolítica en framework. Usa NestJS para la lógica de negocio, colas, trabajos en background y microservicios críticos; usa Hono para la capa perimetral, autenticación global, webhooks y endpoints que deben estar cerca del usuario.

    Ventaja: reduces coste y latencia donde importa, y mantienes previsibilidad y pruebas allí donde importa más: en el core.

    Conclusión

    Hono vs Express vs NestJS: cuál usar en 2026 no es una competición de popularidad. Es una cuestión de contexto. Si necesitas extremar latencia y desplegar en Edge, Hono gana. Si necesitas gobernanza de código, DI y un stack mantenible por equipos grandes, NestJS gana. Express sigue siendo válido solo para mantener legacy; para nuevo desarrollo, elige Fastify si trabajas exclusivamente en Node.

    Decide según ejecución y mantenimiento, no por hype. La mejor arquitectura combina herramientas: perímetro ligero (Hono) + corazón estructurado (NestJS). Eso te dará velocidad hoy y coherencia mañana.

    FAQ

    Respuesta: ¿Cuándo debo usar Hono en lugar de NestJS?

    Usa Hono cuando despliegues en runtimes Edge/Serverless (Cloudflare Workers, Deno, Bun) y necesites cold starts mínimos y alta concurrencia en endpoints públicos. Usa NestJS cuando necesites estructura, DI y gobernanza para equipos grandes.

    Respuesta: ¿Express todavía tiene sentido para proyectos nuevos?

    No para la mayoría de proyectos nuevos. Express se mantiene por legacy. Para nuevo desarrollo en Node, considera Fastify por rendimiento y plugins modernos.

    Respuesta: ¿Cómo afecta el entorno de ejecución a la elección del framework?

    El entorno define compatibilidad y cold starts. Hono está diseñado para la Fetch API y funciona en Workers/Deno/Bun sin polyfills. NestJS está pensado para contenedores y necesita procesos calientes para minimizar latencia.

    Respuesta: ¿Qué alternativas a Express recomiendan para Node moderno?

    Fastify es la alternativa recomendada por rendimiento y ecosistema de plugins. Evalúa Fastify sobre Express para proyectos nuevos en Node.

    Respuesta: ¿Puedo mezclar Hono y NestJS en la misma plataforma?

    Sí. Patrón recomendado: Hono en el perímetro (autenticación global, webhooks, endpoints edge) y NestJS en el núcleo (lógica de negocio, colas, trabajos). Separar responsabilidades reduce coste y mejora latencia.

    Respuesta: ¿Qué considerar sobre cold starts en serverless?

    Si tu SLA requiere latencias muy bajas y tienes picos geográficos, los cold starts importan. Hono puede arrancar en milisegundos en Edge; NestJS suele requerir contenedores calientes y arranques en cientos de ms.

  • Aprende a convertirte en AI Engineer en 2026

    Aprende a convertirte en AI Engineer en 2026

    De dev a AI Engineer: qué necesitas aprender en 2026

    Tiempo estimado de lectura: 3 min

    Ideas clave

    • Prompt Engineering como contrato tipado y versionable para reducir alucinaciones.
    • Tool Calling y agentes: definir herramientas con responsabilidades únicas y schemas JSON.
    • RAG en producción usando embeddings, chunking y pgvector para memoria privada eficiente.
    • LLMOps con tracing y LLM-evaluadores para medir costes y alucinaciones.

    Introducción

    Buscar De dev a AI Engineer: qué necesitas aprender en 2026 ya no es curiosidad de fin de semana; es una decisión profesional con impacto directo en tu carrera. Si vienes de React, Angular o NestJS, tienes la base técnica. Lo que falta es reaprender cómo estructurar sistemas cuando la lógica principal es probabilística y depende de modelos externos.

    En las siguientes líneas encontrarás un roadmap concreto, orientado a ingenieros web/backend, con prioridades prácticas, enlaces a documentación útil y criterios para decidir qué aprender primero.

    Resumen rápido (lectores con prisa)

    Prompt Engineering: diseñar prompts como artefactos versionables que produzcan salidas tipadas y validables.

    Tool Calling / Agentes: definir herramientas con schemas JSON y orquestar invocaciones desde un Agent Loop.

    RAG: almacenar embeddings por chunk (pgvector), recuperar top-k y re-rankear antes de inyectar contexto.

    LLMOps: traza sesiones, registra tokens y usa un LLM evaluador para medir pertinencia y alucinaciones.

    De dev a AI Engineer: qué necesitas aprender en 2026 (roadmap concreto)

    No te doy una lista genérica. Te doy cuatro pilares con tareas prácticas y recursos.

    1) Prompt Engineering estructurado — De texto a contrato

    • Qué aprender: diseñar prompts como artefactos versionables: system prompts, ejemplos (few-shot), y salidas tipadas.
    • Práctica concreta: escribe prompts que devuelvan JSON con un esquema Zod; automatiza tests que validen esos esquemas en CI.
    • Por qué importa: reduce alucinaciones y permite integrar respuestas en pipelines sin parsing frágil.
    • Recurso: Vercel AI SDK para integrar outputs tipados en TypeScript.

    2) Tool Calling y diseño de agentes — Orquesta, no suplentes

    • Qué aprender: definir herramientas (APIs) como JSON-schema que el LLM puede invocar (function/tool calling).
    • Práctica concreta: implementa un Agent Loop mínimo en NestJS:
      • Enviar mensaje + herramientas (schemas) al LLM.
      • Si respuesta indica tool_use, validar args y ejecutar el Service correspondiente.
      • Devolver tool_result y repetir hasta end_turn.
    • Criterio: cada herramienta = responsabilidad única (no “herramienta dios”).
    • Recurso: Anthropic Tool Use

    3) RAG (Retrieval-Augmented Generation) avanzado — Memoria privada usable

    • Qué aprender: embeddings, chunking semántico, re-ranking y vectores en producción.
    • Práctica concreta: usa pgvector sobre PostgreSQL para empezar; implementa pipeline:
      • Normaliza y chunkea documentos.
      • Genera embeddings por chunk.
      • Recupera top-k por similitud y re-rankea por señal de negocio antes de inyectar al prompt.
    • Criterio: prioriza latencia y coste. Evita enviar “todo” en cada petición.
    • Recurso: pgvector

    4) LLMOps y Evaluaciones — Operar lo no determinista

    • Qué aprender: tracing por sesión, LLM-as-a-judge y métricas de negocio.
    • Práctica concreta: registra cada interacción (tokens, latencia, tools invocadas). Configura un job que use un LLM evaluador para puntuar respuestas por pertinencia y alucinaciones.
    • Herramientas: Langfuse para trazabilidad, LangSmith para visualización.
    • Métricas clave: coste por sesión, iteraciones por solicitud, p95 latencia por tool, tasa de fallos por tool.

    Stack técnico recomendado (práctico y defendible)

    Si trabajas en TypeScript, prioriza estos componentes (con orden de adopción):

    1. SDKs oficiales

    Recomendación: Anthropic/OpenAI — aprende sus modelos, límites y formatos de tool-calling.

    2. Backend

    Recomendación: NestJS — implementa providers para LLM, ToolRegistry y AgentService.

    3. Vector DB inicial

    Recomendación: pgvector + PostgreSQL; escala a Pinecone/Qdrant si el volumen lo exige.

    4. Orquestación y workflows

    Recomendación: n8n para pipelines asíncronos y conectores empresariales.

    5. Observabilidad

    Recomendación: Langfuse o LangSmith para tracing y análisis de coste.

    Evita caer en frameworks que abstraen demasiado al principio. Aprende la API real: sabes más cuanto menos le pidas al framework que haga por ti.

    Errores que vas a cometer (y cómo evitarlos)

    • No versionar prompts: guarda prompts junto al código y pruébalos.
    • Herramientas multifunción: separa responsabilidades y aplica autorización por herramienta.
    • No medir tokens: integra métricas de coste desde el primer día.
    • Tests ausentes: mockea LLMs y valida esquemas de salida en CI.

    Prioridad de aprendizaje (3 pasos rápidos)

    1. Practica Tool Calling con un mini-proyecto en NestJS: define 4 herramientas y un Agent Loop.
    2. Implementa RAG con pgvector para un dominio de 100 documentos. Mide latencia y coste.
    3. Añade tracing (Langfuse) y un evaluador LLM que puntúe respuestas en lotes.

    Conclusión

    Convertirse en AI Engineer en 2026 no implica abandonar lo que ya sabes. Implica extender tu disciplina: convertir prompts en contratos, convertir respuestas probabilísticas en flujos controlados y operar sistemas con métricas reales. Si dominas eso, liderarás la integración de IA en producto, no sólo la experimentación.

    Dominicode Labs

    Para equipos que implementan agentes, RAG y pipelines de observabilidad, un siguiente paso natural es consolidar prácticas en proyectos pilotos y reproducibles. Una opción para explorar experimentos y plantillas es Dominicode Labs, que puede servir como repositorio de referencia para workflows y pruebas de concepto.

    FAQ

    ¿Qué es Prompt Engineering estructurado?

    Diseñar prompts como artefactos versionables que incluyan system prompts, ejemplos (few-shot) y produzcan salidas tipadas. El objetivo es generar respuestas que se puedan validar automáticamente (por ejemplo, JSON con esquema Zod).

    ¿Cómo funciona Tool Calling y por qué usarlo?

    Se definen herramientas con schemas JSON que el LLM puede invocar. Un Agent Loop envía mensajes y herramientas al LLM; si el LLM indica uso de herramienta, se validan los argumentos, se ejecuta el servicio y se devuelve el resultado, repitiendo hasta finalizar.

    ¿Por qué usar pgvector para RAG?

    pgvector sobre PostgreSQL permite comenzar con una solución integrada para embeddings y búsquedas vectoriales. Es práctica para dominios iniciales antes de escalar a Pinecone o Qdrant.

    ¿Qué incluye LLMOps en producción?

    Tracing por sesión, registrar tokens, latencia y tools invocadas; configurar jobs que usen un LLM evaluador para puntuar respuestas por pertinencia y alucinaciones; y medir métricas como coste por sesión y p95 latencia por tool.

    ¿Qué stack priorizar si trabajo en TypeScript?

    Prioriza SDKs oficiales (Anthropic/OpenAI), backend en NestJS, pgvector + PostgreSQL, orquestación con n8n y observabilidad con Langfuse o LangSmith.

    ¿Cuáles son los primeros proyectos prácticos recomendados?

    Tres pasos rápidos: (1) mini-proyecto en NestJS para Tool Calling con 4 herramientas y un Agent Loop; (2) implementar RAG con pgvector para ~100 documentos; (3) añadir tracing y un evaluador LLM para puntuar respuestas.

  • Implementación de @supabase/server para Edge Functions Seguras

    Implementación de @supabase/server para Edge Functions Seguras

    npm install @supabase/server@latest npx skills add supabase/server — Cambia cómo piensas la seguridad y la infraestructura de tus Edge Functions

    Tiempo estimado de lectura: 4 min

    • Reduce boilerplate: @supabase/server entrega SupabaseContext por petición y primitives para evitar repetir validación de JWT, clientes anon/admin y CORS.
    • Seguridad declarativa: auth modes visibles por ruta ({ auth: ‘user’ }, ‘secret’, ‘none’, etc.) que simplifican auditorías.
    • Automatización para equipos: npx skills add supabase/server añade conocimiento a agentes para migraciones y scaffolds fiables.

    Hoy no es sobre instalar una dependencia. Es sobre cambiar cómo piensas la seguridad y la infraestructura de tus Edge Functions. Si ejecutas npm install @supabase/server@latest y luego npx skills add supabase/server, obtienes dos cosas: una librería que elimina el boilerplate y una “skill” para agentes de código que conoce la API, los patrones y las rutas de migración. Esto no es marketing; es ingeniería que reduce errores y acelera migraciones.

    Resumen rápido (lectores con prisa)

    Qué es: Un paquete que entrega SupabaseContext preconfigurado por petición y una skill para agentes.

    Cuándo usarlo: Al migrar o crear Edge Functions que requieran autenticación, roles o admin operations.

    Por qué importa: Reduce código repetido y errores; hace la seguridad declarativa.

    Cómo funciona: Wrapper middleware (withSupabase) o primitivas (createSupabaseContext) que validan auth y exponen clientes y claims.

    Qué hace la instalación (breve)

    npm install @supabase/server@latest

    Instala el paquete que crea un SupabaseContext preconfigurado por petición.

    npx skills add supabase/server

    Entrega ese contexto a agentes como Claude Code o Codex, para que puedan generar migraciones y scaffolds fiables.

    Fuentes y documentación

    Qué obtienes realmente: contextos y patrones repetibles

    Instalar @supabase/server no es solo añadir un helper: introduces un patrón consistente. El núcleo es el SupabaseContext que te dan los wrappers como withSupabase:

    • ctx.supabase: cliente con scope de usuario (respeta RLS)
    • ctx.supabaseAdmin: cliente con service role (operaciones privilegiadas)
    • userClaims / jwtClaims: identidad verificada
    • authMode: cómo se autenticó la petición

    Ejemplo mínimo (edge handler compatible con cualquier runtime)

    import { withSupabase } from 'npm:@supabase/server'
    
    export default {
      fetch: withSupabase({ auth: 'user' }, async (req, ctx) => {
        const { data } = await ctx.supabase.from('todos').select()
        return Response.json(data)
      }),
    }
    

    Eso es todo. Declaras auth y recibes contexto. Si la petición no tiene token válido, el middleware corta la ejecución antes de tocar tu lógica.

    Modos de autenticación: explícitos y visibles

    La seguridad deja de ser código disperso y pasa a ser una declaración:

    • { auth: 'user' } — solo usuarios con JWT válido
    • { auth: 'none' } — webhooks y health checks
    • { auth: 'secret' } — server-to-server con clave secreta
    • { auth: 'publishable' } — publishable key
    • { auth: ['user', 'secret'] } — acepta JWT o secret key

    Ventaja práctica: el modelo de seguridad de una función es legible en una línea. Auditar políticas, cumplir requisitos de cumplimiento o revisar riesgo queda mucho más simple.

    Migrar a JWT asimétricos sin dolor

    Antes de @supabase/server, migrar a las nuevas claves asimétricas significaba instalar jose, montar JWKS, exponer nuevos secretos y actualizar función por función. Con este paquete la validación asimétrica y la resolución de JWKS se gestionan internamente. Resultado: menos oportunidades de equivocarte y menos código repetido.

    Cuando necesitas control fino: createSupabaseContext y las primitivas

    No todo el mundo usa el wrapper. Si necesitas flujo imperativo o respuestas personalizadas, existe createSupabaseContext:

    import { createSupabaseContext } from 'npm:@supabase/server'
    
    export default {
      fetch: async (req) => {
        const { data: ctx, error } = await createSupabaseContext(req, { auth: 'user' })
        if (error) return Response.json({ error: error.message }, { status: error.status })
    
        const { data } = await ctx.supabase.from('todos').select()
        return Response.json(data)
      },
    }
    

    Y si tu arquitectura es aún más compleja (MCP servers, adaptadores personalizados) las primitivas core están disponibles: createAdminClient, createContextClient, resolveEnv, verifyAuth — las mismas funciones que alimentan los adaptadores oficiales.

    Hono y adaptadores: patrón simple para frameworks

    Hono fue el primer adaptador oficial. Un ejemplo con Hono muestra lo limpio que queda:

    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 }
    

    El adaptador inyecta supabaseContext en c.var y lista. Si necesitas otro framework, busca un adaptador o usa las primitivas core.

    Agentes y automatización: por qué añadir la “skill” es útil

    npx skills add supabase/server le da a un agente el conocimiento de la API y patterns. Eso permite prompts robustos:

    • “Analyze all Edge Functions and plan a migration to @supabase/server”
    • “Scaffold a Hono REST API with per-route auth for todos”
    • “Create an admin Edge Function that accepts user or secret auth and logs audits”

    Si tu equipo usa agentes para refactorizaciones o scaffolding, esta skill reduce la tasa de alucinaciones y acelera entregas.

    Criterio práctico para equipos técnicos

    • Empieza migrando endpoints críticos: aquellos con manipulación de roles o auditoría.
    • Sustituye shared utilities por withSupabase o createSupabaseContext: menos código repetido, menos errores.
    • Usa modes combinados (['user','secret']) para endpoints mixtos (frontend + cron jobs).
    • Revisa variables de entorno: SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS en lugar de keys singulares.
    • Prueba con agentes para migraciones masivas, pero añade revisión humana.

    Conclusión

    npm install @supabase/server@latest y npx skills add supabase/server no son trucos de productividad; son una inversión en consistencia y seguridad. Si gestionas Edge Functions, adoptar este patrón reduce la superficie de error, acelera auditorías y libera tiempo para construir la lógica que realmente importa. Revisa la documentación en Documentación general y el repositorio en Repositorio Supabase para empezar.

    Dominicode Labs

    Para equipos que automatizan migraciones y workflows con agentes, una referencia práctica y recursos adicionales están disponibles en Dominicode Labs. Integrar estas prácticas con pipelines de automatización puede acelerar adopciones y reducir errores humanos.

    FAQ

    ¿Qué hace exactamente @supabase/server?

    Entrega un SupabaseContext preconfigurado por petición que incluye clientes (usuario y admin), claims y el modo de autenticación. También ofrece primitivas para escenarios imperativos o adaptadores de framework.

    ¿Necesito cambiar todas mis funciones para usarlo?

    No necesariamente. Puedes migrar endpoints críticos primero y sustituir utilidades compartidas por los wrappers o primitivias según prioridades del equipo.

    ¿Cómo maneja la validación de JWT asimétricos?

    La validación asimétrica y la resolución de JWKS se gestionan internamente por el paquete, evitando tener que instalar y montar jose y JWKS manualmente en cada función.

    ¿Qué diferencia hay entre withSupabase y createSupabaseContext?

    withSupabase es un wrapper middleware que inyecta contexto automáticamente y corta ejecución si la auth falla. createSupabaseContext es una primitiva imperativa útil cuando necesitas control fino sobre la respuesta o flujo.

    ¿La skill para agentes reemplaza la revisión humana?

    No. La skill reduce la tasa de alucinaciones y acelera la generación de migraciones y scaffolds, pero se recomienda revisión humana antes de despliegues críticos.

    ¿Dónde encuentro más documentación y ejemplos?

    Consulta la Documentación general y el Repositorio Supabase para ejemplos, adaptadores y guías de migración.

  • Cómo integrar Codex CLI en tu flujo de trabajo de manera segura

    Cómo integrar Codex CLI en tu flujo de trabajo de manera segura

    posts sobre codex cli — repositorio en GitHub

    Tiempo estimado de lectura: 4 min

    • Ideas clave:
    • Codex CLI demostró la capacidad de transformar lenguaje natural en comandos de shell; su valor actual está en el patrón arquitectónico más que en copiar la herramienta tal cual.
    • Flujo seguro: captura del prompt → contexto mínimo → petición al modelo → plan → revisión humana → ejecución (sandbox opcional).
    • Reglas operativas: uso estricto de git, human-in-the-loop, .codexignore, sandboxing y logs.
    • Considera alternativas modernas (Copilot CLI, Aider, Claude Code) según modelo, coste y conciencia git.

    Buscar “posts sobre codex cli https://github.com/openai/codex” es algo que cualquier developer que pasa tiempo en la terminal hace tarde o temprano. El repositorio de OpenAI en GitHub contiene código que convirtió instrucciones en lenguaje natural en comandos de shell ejecutables; aquí tienes un análisis técnico, práctico y con criterio para decidir si merece entrar en tu flujo de trabajo —y cómo hacerlo sin romper nada.

    Resumen rápido (lectores con prisa)

    Codex CLI traduce prompts en comandos de shell con confirmación humana. Úsalo para automatizar refactorizaciones y tareas repetitivas, pero siempre con git, .codexignore y sandboxing. No lo ejecutes en producción sin revisión.

    posts sobre codex cli https://github.com/openai/codex — qué era y qué es hoy

    Codex CLI nació como experimento para demostrar que un modelo podía traducir prompts a comandos de bash, zsh o PowerShell. El repositorio en https://github.com/openai/codex contiene el código fuente, ejemplos y el patrón básico: capturar prompt → enriquecer con contexto mínimo → pedir al modelo → mostrar comando para confirmación.

    Con el tiempo el ecosistema evolucionó. Los modelos Codex originales fueron consolidados dentro de las familias GPT y las implementaciones prácticas deben adaptarse a nuevas APIs y consideraciones de seguridad. El valor técnico del repositorio no está tanto en copiar y pegar la herramienta tal cual, sino en entender su arquitectura: contexto, plano de acción propuesto por el modelo y control humano en el loop.

    Arquitectura práctica del Codex CLI (resumen técnico)

    Un flujo seguro y repetible que tomes del repo:

    Paso 1: Captura del prompt en la CLI

    Captura del prompt en la CLI.

    Paso 2: Construcción de contexto

    Construcción de contexto: sistema operativo, shell, archivos relevantes.

    Paso 3: Petición al modelo

    Petición al modelo con instrucciones claras (incluyendo límites).

    Paso 4: Recepción de plan

    Recepción de plan: comandos y diffs.

    Paso 5: Capa de revisión humana

    Capa de revisión humana (confirmación Y/N).

    Paso 6: Ejecución en sandbox o contexto real

    Ejecución en sandbox o en contexto real según el modo.

    El repositorio muestra esa cadena end-to-end y facilita experimentar. Link: https://github.com/openai/codex

    Cómo integrar Codex CLI hoy sin liarla

    Si vas a usar ideas o código del repo, aplica estas reglas operativas:

    • Git obligatorio: nunca en modo autónomo sin control de versiones. Todo cambio debe poder revertirse con un git reset o revert.
    • Human-in-the-loop: exige confirmación explícita (Y/N) para cualquier comando que altere el FS fuera de una carpeta de prueba.
    • .codexignore: crea un archivo para excluir node_modules, dist, build, archivos binarios y .env. Reduce coste de tokens y evita filtrar secretos.
    • Sandboxing: para experimentos, usa contenedores Docker con red deshabilitada. Configura volúmenes limitados.
    • Tokens y coste: limita el contexto que envías al modelo. No adjuntes todo el repo; adjunta solo los ficheros necesarios o extractos relevantes.
    • Logs y auditoría: guarda los prompts y las respuestas (hashed si hay datos sensibles) para trazabilidad.

    Ejemplo mínimo de instalación (adaptado del repo)

    npm install -g @openai/codex
    export OPENAI_API_KEY="sk-…"
    codex
    

    No copies sin validar; el repo original puede requerir adaptaciones a la API actual.

    Casos de uso donde realmente aporta valor

    No todo para todo. Usa Codex CLI (o una implementación basada en su diseño) cuando:

    • Necesites refactorizaciones a escala: renombrar símbolos en todo el repo siguiendo reglas concretas.
    • Generación de tests coherentes con la base existente: pide que imite la convención de tests del proyecto.
    • Automatización de infra/DevOps repetitiva: plantillas de Dockerfile, small CI changes, hooks de Git.
    • Onboarding: un agente que explique snippets o genere tareas repetitivas para nuevos miembros.

    No lo uses para operaciones críticas sin revisión (migraciones de BD sin script probado, cambios en infra prod).

    Alternativas y posición en el ecosistema

    El diseño del repo de OpenAI es la semilla. Hoy existen herramientas más pulidas y con integraciones específicas (Copilot CLI, Aider, Claude Code). La decisión práctica se basa en tres factores: modelo y coste, git-awareness (capacidad para trabajar con commits y diffs), y controles de seguridad integrados.

    • Si quieres integración empresarial y soporte nativo con GitHub: considera Copilot CLI.
    • Si necesitas un agente git-aware que haga commits atómicos: mira Aider.
    • Si trabajas con repositorios enormes y razonamiento arquitectónico: Claude Code es fuerte en contexto pesado.

    Codex CLI (repositorio) sigue siendo un recurso para aprender el patrón arquitectónico y prototipar. En https://github.com/openai/codex encontrarás el material de referencia.

    Conclusión: lee los posts, adapta las ideas, no copies el script

    Los posts sobre codex cli https://github.com/openai/codex deben leerse con criterio. El valor real está en el patrón: contexto mínimo, plan claro, revisión humana y ejecución controlada. Si vas a incorporar agentes en tu terminal, hazlo con Git como red de seguridad, ignores claros y entornos aislados. Empieza por prototipos en carpetas no productivas, automatiza tareas repetitivas y escala solo cuando la trazabilidad y la seguridad estén resueltas.

    El repo es útil. Pero la responsabilidad técnica es tuya: la IA puede sugerir un comando brillante y peligroso a la vez. Mantén el control, y usa la terminal como un asistente, no como un sustituto de tu juicio.

    Dominicode Labs

    Si trabajas en automatización, agentes o workflows y quieres prototipar con control de seguridad, considera explorar recursos adicionales en Dominicode Labs. Sirve como continuación lógica para experimentar con patrones de agente git-aware y sandboxing.

    FAQ

    ¿Qué es Codex CLI y dónde está el código?

    Codex CLI fue un experimento que convierte prompts en comandos de shell con confirmación humana. El código está disponible en el repositorio de OpenAI en GitHub; accede a él desde el enlace proporcionado en el artículo.

    ¿Por qué no debo ejecutar comandos sin control de versiones?

    Sin git no puedes revertir fácilmente cambios peligrosos. Usar control de versiones permite deshacer operaciones con git reset o revertir commits, reduciendo el riesgo al probar comandos generados por IA.

    ¿Qué debe incluir un .codexignore?

    Incluye node_modules, dist, build, archivos binarios y .env. Esto reduce coste de tokens y evita filtrar secretos al modelo.

    ¿Cómo aplicar sandboxing para experimentos?

    Usa contenedores Docker con la red deshabilitada y volúmenes limitados para ejecutar comandos de prueba. Esto aísla el entorno y minimiza el impacto de cambios inesperados.

    ¿Para qué casos de uso es recomendable usar Codex CLI?

    Es útil para refactorizaciones a escala, generación de tests coherentes, automatización repetitiva de infra/CI, y onboarding que requiera generación de tareas o explicaciones de snippets.

    ¿Qué alternativas existen hoy?

    Alternativas mencionadas incluyen Copilot CLI, Aider y Claude Code, cada una con puntos fuertes según integración con GitHub, git-awareness y capacidad para contextos grandes.

    ¿Cómo auditar prompts y respuestas?

    Guarda los prompts y respuestas en logs. Si contienen datos sensibles, almacena versiones hasheadas. Mantén trazabilidad para revisar decisiones y reproducir resultados.

  • Cómo Zod resuelve la validación de datos en TypeScript

    Cómo Zod resuelve la validación de datos en TypeScript

    Zod: la librería que todo dev TypeScript debería conocer en 2026

    Tiempo estimado de lectura: 3 min

    Ideas clave

    • Zod valida, transforma e infiere tipos en runtime, cerrando la brecha de type erasure de TypeScript.
    • Define esquemas una sola vez: validación runtime y tipos TypeScript derivados automáticamente.
    • Para DX y rapidez de integración en apps empresariales, Zod suele ser la mejor opción; para bundle size en edge, considera Valibot.
    • Patrones prácticos: esquema + inferencia, safeParse y transformaciones/refinements.

    Introducción

    Zod: la librería que todo dev TypeScript debería conocer en 2026. Lo digo sin dramatismos: si trabajas con TypeScript y datos externos, Zod debería ser parte de tu kit. Resuelve el problema fundamental que TypeScript no puede cubrir en tiempo de ejecución: validar, transformar y garantizar contratos cuando el compilador ya no está.

    Resumen rápido (lectores con prisa)

    Zod es una librería de validación y transformación de datos para runtime que infiere tipos TypeScript a partir de esquemas. Úsalo donde recibes datos externos (APIs, formularios, ficheros) para asegurar contratos en producción. Priorízalo por su balance entre experiencia de desarrollador e integración con herramientas modernas.

    Por qué Zod importa (y qué problema técnico resuelve)

    TypeScript y la brecha en runtime

    TypeScript te protege durante el desarrollo, pero los tipos se pierden al compilar (type erasure). Eso deja una brecha entre “lo que esperamos” y “lo que llega” — APIs externas, formularios, cron jobs, ficheros CSV. Sin validación en runtime, esa brecha se traduce en bugs impredecibles en producción.

    Zod colapsa dos responsabilidades que históricamente iban por separado: definición de esquema (validación runtime) y tipos TypeScript (tipado estático). Defines un esquema una sola vez; Zod infiere el tipo para que no haya duplicidad ni desincronización entre validación y tipado.

    Zod: la librería que todo dev TypeScript debería conocer en 2026 — comparación técnica

    No es magia; es diseño de librería pensado para TypeScript. Frente a alternativas:

    Yup

    • Yup: nació para JavaScript. Su soporte TypeScript es parcheado; la inferencia es frágil y obliga a aserciones manuales en proyectos estrictos.

    Valibot

    • Valibot: arquitectura modular y tree-shaking superior. Excelente para entornos edge donde cada KB cuenta.

    Zod

    • Zod: equilibrio entre DX, integración y robustez. API legible, transformaciones y refinements potentes, y amplia adopción en herramientas (tRPC, React Hook Form).

    Decisión práctica:

    • Si priorizas DX y rapidez de integración en aplicaciones empresariales: Zod.
    • Si necesitas minimizar bundle en Workers/Edge: Valibot.
    • Si mantienes legado con Yup y no puedes refactorizar ahora: sigue con Yup, pero planifica migración.

    Tutorial práctico: patrones esenciales con Zod

    Tres patrones que uso en producción: esquema + inferencia, safeParse y transformaciones.

    1) Definir esquema e inferir tipo

    // TypeScript
    import { z } from "zod";
    
    export const ProductSchema = z.object({
      id: z.string().uuid(),
      name: z.string().min(1, "Nombre obligatorio"),
      price: z.number().positive("Precio > 0"),
      category: z.enum(["tech", "food"]),
      publishedAt: z.coerce.date().optional(),
    });
    
    export type Product = z.infer<typeof ProductSchema>;

    Nota: z.coerce.date() convierte strings ISO a Date durante la validación. No necesitas un DTO separado.

    2) safeParse: predecible en producción

    const result = ProductSchema.safeParse(raw);
    
    if (!result.success) {
      // result.error.format() -> errores por campo listos para UI/LOG
      console.error(result.error.format());
      throw new Error("Payload inválido");
    }
    
    const product: Product = result.data;

    Nota: parse lanza excepciones; safeParse devuelve un objeto discriminado que encaja mejor en flujos robustos.

    3) Transformaciones y refinements

    const PriceSchema = z.string()
      .regex(/^\d+(\.\d{1,2})?$/)
      .transform(v => parseFloat(v));
    type Price = z.infer<typeof PriceSchema>; // number
    const PasswordSchema = z.object({
      password: z.string().min(8),
      confirm: z.string(),
    }).refine(data => data.password === data.confirm, {
      message: "Las contraseñas no coinciden",
      path: ["confirm"]
    });

    Integración con Angular y formularios reactivos

    El error arquitectónico común: mezclar reglas de negocio con validators en el componente. Mejor patrón: extraer la lógica a Zod y mapear errores a los controles.

    Flujo sugerido

    1. spec/schema.ts con esquemas Zod como fuente de verdad.
    2. Validador personalizado en Angular que ejecuta schema.safeParse(form.getRawValue()).
    3. Mapear error.format() a control.setErrors({ zod: mensaje }).

    Así la lógica es portable (frontend/backend), testeable y mantiene tipado estricto. Para patrones completos con Signals y Standalone Components ve el curso de integración.

    Cuando preferir otra opción

    • Valibot si tu constraint es bundle size en entornos edge.
    • Yup si tienes una base de código legacy donde migrar no es viable a corto plazo.
    • Pero en la mayoría de proyectos empresariales, Zod ofrece mejor balance entre seguridad, DX e integración con herramientas modernas.

    Conclusión y siguiente paso práctico

    Zod no es una moda: es una decisión arquitectónica que reduce errores por desincronía entre tipos y datos reales. Centraliza contratos, facilita transformaciones y mejora la trazabilidad de errores.

    Si quieres llevar esto al siguiente nivel —transformaciones avanzadas, validaciones asincrónicas y patrones de dominio— el curso práctico es la forma más rápida de internalizar buenas prácticas: Zod: Validación y Transformación de datos con TypeScript

    Aprender Zod hoy evita bugs mañana. Y eso, en producción, paga más que cualquier micro-optimización.

    FAQ

    ¿Qué es Zod?

    Zod es una librería de validación y transformación de datos para JavaScript/TypeScript que permite definir esquemas en runtime y derivar tipos TypeScript automáticamente.

    ¿Cuándo debería validar con Zod?

    Valida en cualquier borde del sistema donde recibas datos no confiables: llamadas API, formularios del usuario, ficheros externos o integraciones de terceros.

    ¿Zod reemplaza los tipos de TypeScript?

    No reemplaza los tipos estáticos del compilador; los complementa. Zod permite derivar tipos TypeScript desde un esquema único y aplica validación en runtime donde el compilador no llega.

    ¿Qué diferencia hay entre parse y safeParse?

    parse lanza una excepción si la validación falla. safeParse devuelve un objeto discriminado con success booleano y datos o error, lo que facilita flujos robustos sin excepciones inesperadas.

    ¿Puedo usar Zod en el frontend y backend con el mismo esquema?

    Sí. Mantener esquemas Zod compartidos permite que la lógica de validación y las transformaciones sean portables y consistentes entre cliente y servidor.

    ¿Cuándo elegir Valibot o Yup en lugar de Zod?

    Elige Valibot si la restricción principal es el tamaño del bundle en entornos edge. Mantén Yup solo si tienes un legado amplio que no puedes refactorizar aún; planifica migración a librerías con mejor tipado si es posible.

  • Cómo usar SDKs de AI tipados en TypeScript para reducir errores

    Cómo usar SDKs de AI tipados en TypeScript para reducir errores

    Typed AI SDKs: por qué usar el SDK de Anthropic o OpenAI en TypeScript y no JavaScript puro

    Tiempo estimado de lectura: 3 min

    • TypeScript tipado reduce errores silenciosos: convierte fallos indetectables en errores visibles en desarrollo.
    • Zod aporta validación en runtime: evita confiar en casts y valida la forma real de respuestas del modelo.
    • Patrón “esquema primero, prompt segundo”: serializa el esquema en el prompt y valida antes de persistir.

    Typed AI SDKs: por qué usar el SDK de Anthropic o OpenAI en TypeScript y no JavaScript puro — si vas a poner LLMs en producción, esa decisión cambia el perfil de riesgo de tu sistema. TypeScript no arregla la aleatoriedad del modelo, pero convierte fallos indetectables en errores visibles mientras desarrollas. Eso es todo; y es suficiente.

    Resumen rápido (lectores con prisa)

    Un SDK tipado (OpenAI o Anthropic) + validación runtime (Zod) convierte errores silenciosos en errores detectables durante desarrollo. Diseña el esquema primero, serialízalo en el prompt, parsea y valida la respuesta antes de usarla.

    Introducción

    Cuando integras un LLM en un flujo de trabajo (agentes, pipelines n8n, microservicios de extracción) no luchas contra la IA: luchas contra su impredecibilidad. JavaScript puro acepta promesas rotas y propiedades ausentes hasta que explotjan en producción. Un SDK tipado (OpenAI o Anthropic) empuja la mayoría de esos errores al compilador.

    Fuentes prácticas:

    Errores en compile time, no en producción

    – Modelos como valores literales: los SDK tipados exponen uniones de strings para modelos. Intentar model: 'gpt-5' fallará en el editor, no en prod.

    – Parámetros obligatorios: el compilador te obliga a rellenar lo que la API realmente necesita.

    – Propiedades opcionales: TS fuerza comprobaciones (?., if) antes de operar con datos potencialmente nulos.

    Resultado: menos hotfixes nocturnos. Detectas que algo está mal cuando escribes, no cuando lo usan clientes.

    Autocompletado real: productividad que importa

    IntelliSense deja de ser un lujo y pasa a ser documentación viva. Parámetros como temperature, response_format o function_call aparecen en el editor con sus tipos exactos. En equipos, esto reduce discusiones sobre “¿qué forma tenía ese objeto?” y evita JSON mal formado en llamadas a herramientas.

    La trampa del casting y por qué Zod es obligatorio

    TypeScript desaparece en runtime. Hacer const x = JSON.parse(s) as MyType es mentirle al compilador. Si el modelo devuelve "age":"veinticinco" habrás metido basura en tu flujo.

    Zod ofrece validación en tiempo de ejecución y genera el tipo TypeScript desde el esquema. Patrones recomendados:

    Patrones recomendados

    • Definir el esquema Zod como fuente única de verdad.
    • Incluir el esquema (o un resumen) en el prompt para guiar al LLM.
    • Parsear y validar la respuesta con Zod antes de usarla.

    Ejemplo práctico (OpenAI/Anthropic + Zod):

    import { z } from 'zod';
    import OpenAI from 'openai'; // o Anthropic desde '@anthropic-ai/sdk'
    
    const UserProfileSchema = z.object({
      fullName: z.string(),
      age: z.number().int().positive(),
      email: z.string().email(),
      tags: z.array(z.string()).max(5),
    });
    
    type UserProfile = z.infer<typeof UserProfileSchema>;
    
    const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
    
    async function extractUserProfile(text: string): Promise<UserProfile> {
      const resp = await client.chat.completions.create({
        model: 'gpt-4o',
        messages: [
          { role: 'system', content: `Devuelve solo JSON válido que cumpla este esquema: ${JSON.stringify(UserProfileSchema.shape)}` },
          { role: 'user', content: text },
        ],
        // response_format o similar según SDK
      });
    
      const raw = resp.choices?.[0]?.message?.content;
      if (!raw) throw new Error('Respuesta vacía del modelo');
    
      // Validación runtime: si falla, aquí lo capturas y reintentas o lo registras
      const parsed = UserProfileSchema.parse(JSON.parse(raw));
      return parsed;
    }

    Si usas Anthropic, adapta la llamada al cliente: la idea es la misma: pedir JSON estructurado y validar con Zod.

    Patrones que escalan: esquema primero, prompt segundo

    1. Diseña el esquema Zod.
    2. Infiere tipos TypeScript con z.infer.
    3. Serializa el esquema (o una versión legible) en el prompt.
    4. Valida la respuesta antes de persistir o procesar.

    Este patrón convierte al LLM en una fuente estocástica que vive dentro de un perímetro controlado. No reduces la tasa de “alucinaciones”, pero transformas una alucinación en un error tratable y reproducible.

    Cuándo aplicar este enfoque

    – Sistemas críticos: facturación, reconciliaciones, autorizaciones.

    – Workflows orquestados en n8n donde agentes ejecutan cambios de estado.

    – Microservicios que procesan datos externos y alimentan otras partes del sistema.

    Evítalo solo en prototipos desechables donde la velocidad de exploración sea prioritaria frente a la robustez.

    Conclusión

    Usar Typed AI SDKs de Anthropic o OpenAI en TypeScript y validarlos con Zod no es postureo técnico: es una estrategia de mitigación de riesgo. Cambias errores silenciosos por fallos detectables en desarrollo, mejoras la DX y pones una barrera defensiva entre la naturaleza impredecible del LLM y la integridad de tus datos. Implementa el patrón “esquema primero, prompt segundo” y tu siguiente incidente nocturno será opcional, no inevitable.

    Para trabajos relacionados con automatización, agentes y workflows en entornos de producción puedes explorar más prácticas y experimentos en Dominicode Labs. Se integra como una continuación lógica de los patrones descritos y recursos para orquestación y pruebas.

    FAQ

    Respuesta: TypeScript detecta discrepancias de tipos en tiempo de compilación, obligando a llenar parámetros obligatorios y a tratar opcionales. Reduce errores silenciosos que aparecerían solo en producción.

    Respuesta: Comprobaciones manuales ayudan, pero son repetitivas y propensas a olvidos. Zod ofrece esquemas reutilizables y validación automatizada en runtime que complementa a TypeScript.

    Respuesta: No. Zod aporta validación en runtime; TypeScript aporta seguridad en compile time. Juntos cubren ambos límites: desarrollo y ejecución.

    Respuesta: Serializa el esquema o un resumen legible (ej.: propiedades y tipos esperados) y pídelo explícitamente en el prompt. Luego parsea y valida la respuesta con Zod antes de usarla.

    Respuesta: Sí. El enfoque es independiente del proveedor: adapta la llamada al cliente de Anthropic pero mantiene la misma estrategia de pedir JSON estructurado y validar con Zod.

    Respuesta: Evítalo en prototipos desechables donde la velocidad de exploración prima sobre la robustez. Para sistemas críticos, es la opción recomendada.