Category: Blog

Your blog category

  • Construyendo Agentes Rápidos con TypeScript y Vercel AI SDK

    Construyendo Agentes Rápidos con TypeScript y Vercel AI SDK

    TypeScript + Vercel AI SDK: la combinación que uso para construir agentes rápido

    Tiempo estimado de lectura: 4 min

    • Tipado + validación: TypeScript en la superficie y Zod en runtime reducen errores silenciosos y permiten refactors seguros.
    • API unificada: Vercel AI SDK conecta proveedores y ofrece streaming y herramientas tipadas.
    • Extracción y control: generateObject y esquemas evitan ingeniería de prompt frágil y JSON truncado.
    • UX y operaciones: streamText mejora la percepción de latencia; métricas y circuit breakers mantienen robustez en producción.

    TypeScript + Vercel AI SDK: la combinación que uso para construir agentes rápido. Si vas a poner agentes en producción, necesitas que la capa que conecta al LLM con tus herramientas sea predecible, tipada y validada desde el primer día. Esa combinación reduce errores silenciosos, acelera refactors y convierte promesas estocásticas en contratos verificables.

    Resumen rápido (lectores con prisa)

    TypeScript para tipado estático, Zod para validación en runtime y Vercel AI SDK como API unificada. Juntos: herramientas tipadas, extracción estructurada (generateObject), y streaming (streamText) para agentes más seguros y previsibles.

    TypeScript + Vercel AI SDK: por qué funciona para agentes rápidos

    Tres problemas recurrentes al construir agentes:

    1. El LLM alucina parámetros para las herramientas (tool calls)

    Los modelos pueden generar parámetros inválidos o inventados para llamadas a herramientas, lo que puede llevar a ejecuciones peligrosas si no se validan antes.

    2. Las respuestas JSON vienen envueltas en markdown o truncadas

    Solemos ver JSON con backticks, texto adicional o respuestas incompletas que complican el parsing confiable.

    3. Cambios en la API del proveedor rompen integraciones silenciosamente

    Actualizar modelos o proveedores puede introducir cambios incompatibles si no hay contratos y pruebas robustas.

    La solución práctica es simple: tipos en la superficie (TypeScript), contratos ejecutables (Zod) y una API que integra ambas cosas (Vercel AI SDK). Beneficios concretos:

    • Autocompletado que evita buscar docs.
    • Tool calls que no se ejecutan si los datos no validan.
    • Extracción de objetos estructurados (generateObject) sin ingeniería de prompt frágil.
    • Streaming nativo (streamText) para UX reactiva.

    Tool calls tipados: la barrera que evita ejecuciones peligrosas

    Definir herramientas con esquemas evita que el agente ejecute acciones con parámetros inventados. Ejemplo:

    import { tool } from 'ai';
    import { z } from 'zod';
    
    const searchOrders = tool({
      description: 'Busca pedidos por ID de cliente',
      parameters: z.object({
        customerId: z.string().uuid(),
        status: z.enum(['pending','shipped','delivered']).optional(),
      }),
      execute: async ({ customerId, status }) => {
        return queryOrdersDatabase({ customerId, status });
      },
    });
    

    Si el LLM devuelve un customerId inválido, Zod lo rechazará antes de llamar a execute. Resultado: menos excepciones en la base de datos y trazabilidad clara del fallo (prompt → validación → rechazo).

    generateObject: extracción fiable de datos estructurados

    generateObject obliga al modelo a respetar un esquema y te devuelve un objeto tipado sin hacer JSON.parse() manual. Ejemplo práctico:

    import { generateObject } from 'ai';
    import { openai } from '@ai-sdk/openai';
    import { z } from 'zod';
    
    const schema = z.object({
      sentiment: z.enum(['positive','neutral','negative']),
      confidence: z.number().min(0).max(1),
      topics: z.array(z.string()).max(5)
    });
    
    const { object } = await generateObject({
      model: openai('gpt-4o'),
      schema,
      prompt: 'Analiza la reseña y devuelve sentiment, confidence y topics.'
    });
    
    // object ya está tipado según schema
    

    Esto reduce la ingeniería de prompts (“Devuelve SOLO JSON”) y aumenta la tasa de respuestas utilizables desde el primer intento.

    streamText: UX que comunica progreso y permite pasos intermedios

    Los agentes suelen ejecutar varias herramientas en cadena. streamText permite emitir texto progresivo y reflejar estados intermedios (p. ej. “consultando base de datos…”) en la UI sin arquitectura adicional:

    • Emite tokens progresivamente al frontend.
    • Reporta eventos de invocation/execute de herramientas.
    • Funciona tanto en Server (Next.js) como en cliente con hooks (useChat).

    Esto mejora la percepción de latencia y permite interacciones más naturales con agentes multi‑paso.

    Integración práctica y operaciones en producción

    Patrón recomendado

    1. Diseña esquemas Zod como fuente única de verdad.
    2. Expón el esquema (o ejemplo) en el prompt para guiar al LLM.
    3. Usa safeParse() para reintentos y autocorrección de prompts; usa parse() para endpoints que deben fallar rápido.
    4. Loguea prompt, raw response y error de Zod (flatten) para trazabilidad.

    Medidas operativas

    • Métricas: tasa de validación fallida, latencia media por herramienta, reintentos por prompt.
    • Retries limitados con backoff y contador de intentos (p. ej. 2 reintentos de autocorrección antes de degradar a humano).
    • Circuit breaker para evitar invocar herramientas costosas si la validación falla en cascada.

    Limitaciones y decisions trade‑offs

    • No eliminas la estocasticidad del LLM; la controlas. Algunos casos requerirán supervisión humana.
    • generateObject y Structured Outputs reducen errores de formato, pero no sustituyen la validación semántica (p. ej. números positivos). Zod sigue siendo necesaria.
    • Tipar desde el día 0 impone disciplina, pero acelera onboarding y refactors.

    Conclusión

    TypeScript + Vercel AI SDK: la combinación que uso para construir agentes rápido no es un truco de marketing. Es una estrategia concreta: tipos para detectar cambios, Zod para validar en runtime, y un SDK que une proveedores, streaming y herramientas tipadas. Si tu objetivo es desplegar agentes que actúen sobre sistemas reales—bases de datos, pedidos, o infraestructuras—esta pila reduce fallos silenciosos y convierte iteración rápida en ingeniería sostenible.

    Para equipos que exploran automatización y agentes como flujo de trabajo productivo, una guía práctica y recursos adicionales están disponibles en Dominicode Labs. Es una continuación lógica para quienes quieren aterrizar estas prácticas en sistemas reales.

    FAQ

    ¿Por qué combinar TypeScript con Zod y un SDK como Vercel AI SDK?

    TypeScript aporta seguridad estática y autocompletado; Zod proporciona validación en runtime; y Vercel AI SDK unifica la interacción con proveedores, streaming y herramientas tipadas. La combinación reduce errores silenciosos y facilita refactors.

    ¿Cómo evitan las herramientas tipadas ejecuciones peligrosas?

    Al definir parámetros con esquemas Zod, cualquier dato que no valide se rechaza antes de ejecutar la función execute, evitando operaciones con parámetros inventados o inválidos.

    ¿Qué ventaja ofrece generateObject frente a parsear JSON manualmente?

    generateObject obliga al modelo a respetar un esquema y devuelve un objeto ya tipado, evitando la ingeniería de prompt para forzar JSON y reduciendo errores por markdown, texto adicional o truncado.

    ¿Cuándo debo usar streamText?

    Cuando quieras mejorar la UX en interacciones multi‑paso: emitir tokens progresivamente, mostrar estados intermedios y reportar eventos de invocation/execute sin añadir complejidad arquitectónica.

    ¿Qué métricas operativas son críticas?

    Métricas como tasa de validación fallida, latencia media por herramienta y reintentos por prompt son esenciales para monitorear la salud y eficacia del agente.

    ¿Cuáles son las limitaciones principales de esta pila?

    No elimina la estocasticidad del LLM; solo la controla. También requiere validación semántica adicional (p. ej. asegurar números positivos). Tipar desde el día 0 impone disciplina, aunque acelera onboarding y refactors.

  • Adopta TDD para implementar pruebas efectivas con agentes de IA

    Adopta TDD para implementar pruebas efectivas con agentes de IA

    Testing en la era de los agentes — TDD + agents, qué tests escribir tú vs cuáles el agente, snapshot testing inteligente

    Tiempo estimado de lectura: 5 min

    Ideas clave:

    • Usa tests como especificación (Test-Driven Prompting) y pide al agente implementar hasta que el test pase.
    • Los humanos deben definir contratos y tests críticos; los agentes pueden generar unit tests, edge cases y boilerplate bajo supervisión.
    • Cambia snapshots textuales por evaluaciones semánticas (LLM-judge) para reducir fragilidad.
    • Implementa un pipeline two-speed con sandboxes efímeros y telemetría sobre prompts y evaluaciones.

    Tabla de contenidos

    Introducción

    Testing en la era de los agentes — TDD + agents, qué tests escribir tú vs cuáles el agente, snapshot testing inteligente debe aparecer en tu playbook desde hoy. Si vas a dejar que un agente (Claude Code, Aider, Cursor u otros) escriba código en tu repo, tienes que reordenar qué pruebas son autoritativas, cuáles automatizas y cómo evitas cobertura falsa.

    Aquí está la estrategia práctica y accionable: cómo usar TDD como especificación, qué pruebas deben ser humanas, cuáles delegar a la IA, y cómo evolucionar los snapshots desde diffs frágiles a evaluaciones semánticas.

    Resumen rápido (lectores con prisa)

    Test-Driven Prompting aplica TDD a agentes: escribe el test como especificación y pide al agente implementar hasta que pase. Usa humanos para contratos, integración crítica y regresiones reales; delega unit tests deterministas y generación de edge cases al agente. Reemplaza snapshots textuales por una evaluación semántica (LLM-judge) que decide si un cambio es cosmético o funcional.

    Test-Driven Prompting: TDD + agents, qué tests escribir tú vs cuáles el agente

    Test-Driven Prompting es TDD adaptado a agentes. Escribes el test primero —no como un ejercicio de documentación, sino como la especificación no ambigua— y pides al agente que implemente hasta que el test pase. El test se convierte en el prompt más estricto que existe.

    Beneficios inmediatos:

    • El agente no improvisa requisitos; el test define el contrato.
    • Evitas cambios colaterales porque la suite actúa como guardrail.
    • La revisión humana se traslada de “¿funciona?” a “¿es esto sostenible y seguro?”.

    Pero atención: si el agente escribe la implementación y el test, obtendrás tautologías. Por eso la división de responsabilidades es crítica.

    División práctica: qué escribe el humano y qué el agente

    Lo que debe escribir el humano (no delegues)

    • Tests de integración críticos: pagos, auth, sincronización entre servicios. Requieren contexto de negocio y pruebas contra fallos reales.
    • Flujos E2E y guiones de usuario (Playwright, Cypress): definen la experiencia que no puede ser inferida por el agente. Playwright / Cypress
    • Tests de regresión con historial real: errores de producción documentados como tests que no pueden ser reinterpretados.
    • Setup de entornos y fixtures confiables: seeds de DB, contratos de mock globales.

    Lo que el agente puede generar (con supervisión)

    • Tests unitarios para funciones puras: transformaciones deterministas, utilidades, algoritmos puros.
    • Generación de edge cases y fuzzing estructurado: inputs nulos, límites, arrays extremos.
    • Boilerplate de mocks simples y factories (bajo reglas estrictas definidas por humanos).

    Pauta de revisión

    Cualquier test con mocking complejo (p. ej. jest.mock con comportamiento dinámico) debe pasar revisión manual antes de merge. Los LLMs tienden a “alucinar” APIs de mocking o a asumir comportamiento de librerías.

    Snapshot testing inteligente: de fragilidad a semántica

    Cómo funciona

    Los snapshots textuales mueren rápidos en repos de ritmo alto. La alternativa es snapshot testing inteligente: comparar semánticamente en lugar de por texto.

    Cómo funciona:

    • Generas snapshot tradicional (DOM/JSON).
    • Si cambia, un módulo de evaluación semántica (LLM-as-a-Judge) recibe: snapshot antiguo, snapshot nuevo y una rúbrica.
    • El modelo decide si el cambio es cosmético (aprobable) o funcional (falla y requiere revisión).

    Aplicaciones

    • UI: detectar si un botón cambió de estilo (aprobable) vs desapareció el control de envío (fallo).
    • APIs: admitir la adición de campos no utilizados por clientes y bloquear cambios en campos requeridos.

    Herramientas/ideas

    Construir un servicio interno que use un modelo de evaluación (ej. GPT-4o / Claude avanzado) y registre justificaciones estructuradas para auditoría.

    Pipeline recomendado y consideraciones operativas

    1. Golden Dataset de tests

    Golden Dataset de tests: 20–50 casos representativos versionados en Git. Sirve como baseline para evaluar cambios de spec.

    2. Two-speed CI

    • Cada PR: ejecución determinista rápida (linters, unit tests generados por agente, AST checks).
    • Merge/main: evaluación semántica completa (LLM-judge, snapshots semánticos).

    3. Sandbox seguro para deterministas

    Sandbox seguro para deterministas: ejecuta tests en contenedores efímeros sin red ni credenciales. Usa Firecracker o gVisor para aislamiento si ejecutas código generado automáticamente.

    4. Métricas y guardrails

    • Pass rate determinista por PR.
    • Delta semántico medio por cambio de spec.
    • Flakiness score (casos inestables entre ejecuciones).
    • Cost per eval (tokens, tiempo).

    Integración de herramientas de observabilidad: Promptfoo para orquestación local de evals, LangSmith para tracing, Braintrust para gestión de datasets.

    Checklist mínimo antes de confiar en un agente

    • Tests críticos escritos por humanos y en el repo.
    • Golden Dataset versionado y ejecutable en CI.
    • Sandbox efímero con timeouts y sin acceso a prod.
    • Reglas claras de qué puede commitear el agente automáticamente.
    • LLM-judge configurado para snapshots y revisiones semánticas.
    • Telemetría: registro de prompts, respuestas, tokens y justificación del juez.

    Conclusión: el rol del Tech Lead

    Testing en la era de los agentes no elimina la responsabilidad humana; la traslada a la definición de contratos, gobernanza y métricas. El Tech Lead debe decidir qué pruebas son la fuente de verdad, cómo se auditan las decisiones del agente y cuándo intervenir manualmente. Si tratas los tests como especificaciones inmutables y habilitas snapshots semánticos, los agentes dejan de ser generadores de ruido y pasan a ser máquinas de productividad que se pueden gobernar.

    Dominicode Labs

    Para equipos que exploran evaluaciones semánticas y pipelines con agentes, Dominicode Labs ofrece recursos y patrones reproducibles para integrar LLM-judges y sandboxes en CI. Considera esta referencia como una continuación práctica de las ideas descritas arriba.

    FAQ

    Respuesta: Test-Driven Prompting aplica la práctica de escribir tests como especificaciones antes de implementar. El test actúa como el prompt más estricto para el agente y define el contrato que debe cumplirse.

    Respuesta: No delegues tests de integración críticos (pagos, auth), flujos E2E, tests de regresión con historial real y el setup de entornos/fixtures. Estos requieren contexto de negocio y control humano.

    Respuesta: Los snapshots semánticos usan un módulo de evaluación (LLM-judge) que recibe el snapshot antiguo, el nuevo y una rúbrica, y decide si el cambio es cosmético o funcional, registrando justificación para auditoría.

    Respuesta: Un Golden Dataset incluye 20–50 casos representativos, versionados en Git y ejecutables en CI. Sirve como baseline para validar cambios de especificación.

    Respuesta: Ejecuta código en contenedores efímeros sin red ni credenciales, aplica timeouts y usa tecnologías como Firecracker o gVisor para aislamiento.

    Respuesta: Sigue métricas como pass rate determinista por PR, delta semántico medio por cambio de spec, flakiness score y cost per eval (tokens, tiempo). Complementa con telemetría de prompts y decisiones del juez.

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