DOMINICODE

Author: Dominicode

  • Dominando Claude Code como agente CLI para automatización efectiva

    Dominando Claude Code como agente CLI para automatización efectiva

    Claude Code – La guía práctica: Ingeniería de agentes en la terminal

    Tiempo estimado de lectura: 4 min

    • Claude Code es un agente CLI que lee árbol de archivos, ejecuta bash, corre tests y propone parches; requiere sandboxes y gobernanza técnica.
    • Controla tokens y contexto desde el día 1 usando comandos operativos como /cost, /compact y flags como --safe.
    • Define prompts como contratos con contexto, tarea, restricciones, verificación y condición de parada para evitar bucles.
    • Extiende de forma segura con MCP y orquesta validaciones con n8n; nunca expongas credenciales y aísla ejecuciones en contenedores.
    • Aplica políticas de seguridad, revisión humana obligatoria y auditoría de logs antes de producción.

    Claude Code – La guía práctica es el manual operativo que necesitas si tu equipo va a delegar trabajo real en un agente CLI. Claude Code (Claude 3.7 Sonnet) no es un autocompletador: es un agente que lee el árbol de archivos, ejecuta bash, corre tests y propone parches. Dominarlo exige reglas claras, sandboxes y gobernanza técnica.

    Resumen rápido (lectores con prisa)

    Claude Code es un agente CLI capaz de operar sobre repositorios (leer archivos, ejecutar comandos, proponer parches). Úsalo con sandboxes (Docker/DevContainers), define prompts como contratos y controla costes con comandos como /cost. Extiende funciones con MCP y orquesta validaciones con n8n, manteniendo revisión humana para cambios sensibles.

    Claude Code – La guía práctica: qué aprender primero

    Arranca por lo esencial. La documentación oficial y el MCP son la base:

    Instalación básica

    Instalación global con npm:

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

    Crea un .claudeignore en la raíz para proteger secretos:

    .env*
node_modules/
dist/
secrets/
*.log

    Lee “Permissions and Security” en la docs antes de ejecutar en repos real. No es opcional.

    Fundamentos operativos: control de contexto y coste

    Claude Code consume tokens por lectura/escritura. Controla eso desde el día 1.

    Operaciones y flags

    • /cost — audita tokens de la sesión. Obliga a revisar antes de tareas largas.
    • /compact — comprime historial de conversación para evitar alucinaciones si el agente lleva horas iterando.
    • /abort — detiene loops. Úsalo rápido si ves repetición.
    • Flags: --safe (revisar comandos propuestos), --read-only (auditoría sin mutar), --detach (tareas largas en background).

    Estos comandos son tus palancas operativas para no perder control.

    Ingeniería de prompts y contratos de ejecución

    Un prompt es un contrato, no un deseo. Estructura clara:

    • Contexto (stack, convenciones).
    • Tarea (qué cambiar).
    • Restricciones (qué no tocar).
    • Verificación (tests, coverage, linter).
    • Condición de parada (máx iteraciones).

    Ejemplo compactado

    Contexto: Angular 22 Zoneless.
Tarea: Migrar src/dashboard a Standalone Components usando Signals.
Restricciones: No tocar auth-service.
Verificación: Ejecutar `vitest --coverage` y superar 90%.
Parada: Abortar si >3 iteraciones fallidas.

    Sin eso, el agente entra en bucles y consume tokens sin producir valor.

    Extensibilidad: MCP y orquestación con n8n

    MCP te permite dar herramientas seguras al agente. Monta un servidor MCP interno y expón solo capacidades limitadas (leer DB, disparar webhooks), nunca credenciales.

    Ejemplo conceptual de servidor MCP (Node.js)

    // mcp-server.js (conceptual)
const { createServer } = require('mcp');
const server = createServer({
  capabilities: {
    read_file: true,
    execute_shell: { shell: 'bash', workingDir: '/workspace' },
    trigger_n8n: { url: 'http://localhost:5678/webhook' }
  }
});
server.listen(8080);

    Integra con Claude Code: /mcp add --url http://localhost:8080.

    Flujo n8n recomendado

    1. Claude genera diff + artefactos.
    2. MCP envia payload a n8n.
    3. n8n ejecuta validaciones (linters, tests), crea ticket y notifica Slack.

    Así mantienes trazabilidad y control humano.

    Seguridad y sandboxing: reglas innegociables

    • Nunca ejecutes tareas destructivas en la host machine. Usa Docker/DevContainers.
    • .claudeignore obligatorio y auditado por SAST.
    • Políticas de gasto: quotas por usuario/equipo en Anthropic Console.
    • Revisión humana obligatoria para cambios que modifiquen infra o credenciales.
    • Logs y auditoría: guarda transcripts de sesiones y resultados de /cost.

    Riesgos comunes y mitigaciones rápidas

    • Bucles por flaky tests → define max_iterations en prompt; usa --safe.
    • Consumo inesperado de tokens → descompón tareas; monitoriza /cost.
    • Fuga de secretos → .claudeignore + escaneo pre-run.
    • Dependencias legacy (p. ej. zone.js en Angular) → audita npm ls previo y fija tests que cubran edge cases.

    Cuándo adoptarlo (criterio para Tech Leads)

    Adopta Claude Code si:

    • Tienes stack moderno (TypeScript, Angular 22+, Next.js).
    • La base tiene tests automáticos (Vitest/Playwright).
    • Puedes aislar ejecuciones en contenedores y aplicar políticas de gasto.

    Pospón si:

    • Repo monolítico sin cobertura.
    • Equipo sin habilidades de prompt engineering.
    • Restricciones presupuestarias que no toleran picos de tokens.

    Roadmap práctico (4 semanas)

    • Semana 1: Sandbox + --safe, .claudeignore, métricas /cost.
    • Semana 2: Prompts estructurados y pruebas automáticas con Vitest.
    • Semana 3: Implementa servidor MCP mínimo y flujo n8n.
    • Semana 4: Políticas de gobernanza, cuotas, playbook de incidentes.

    Claude Code no es magia; es ingeniería aplicada. Monta sandbox, define contratos de prompts, limita el alcance con MCP y registra todo. Hazlo bien y convertirás la terminal en un colaborador que acelera refactors y tareas repetitivas sin apagar el control humano. Esto empieza hoy: configura el sandbox y documenta las reglas internas; el resto viene después.

    Dominicode Labs

    Para equipos que diseñan flujos de automatización y orquestación con agentes, una fuente útil de referencia y experimentación es Dominicode Labs. Puede servir como continuación lógica para prototipar MCP + n8n y playbooks de gobernanza.

    Referencias y recursos

    FAQ

    ¿Qué es Claude Code y en qué se diferencia de un autocompletador?

    Claude Code es un agente CLI que puede leer el árbol de archivos, ejecutar comandos de shell, correr tests y proponer parches. No es solo un autocompletador: realiza acciones sobre el repositorio y requiere control operativo y políticas de seguridad.

    ¿Cómo evito que el agente consuma tokens excesivos?

    Monitorea con /cost, descompón tareas largas, establece max_iterations en prompts y usa /compact para reducir historial. Usa flags como --safe para revisar comandos propuestos.

    ¿Qué medidas de seguridad son obligatorias antes de ejecutar en repos reales?

    Usar sandboxes (Docker/DevContainers), tener .claudeignore auditado por SAST, cuotas en Anthropic Console y revisión humana para cambios que modifiquen infra o credenciales.

    ¿Qué es MCP y por qué usarlo?

    MCP (Model Context Protocol) permite exponer capacidades limitadas y seguras al agente (leer archivos, ejecutar shell controlado, disparar webhooks) sin revelar credenciales. Facilita gobernanza y trazabilidad.

    ¿Cuándo debo usar --safe o --read-only?

    Usa --safe para revisar comandos propuestos por el agente en tareas de riesgo, y --read-only para auditorías o análisis sin mutar el repositorio.

    ¿Cómo integro validaciones automáticas con n8n?

    Configura MCP para enviar payloads a n8n; n8n ejecuta linters y tests, crea tickets y notifica Slack. El flujo recomendado: Claude genera diff, MCP envía a n8n, n8n valida y crea trazabilidad.

    ¿Qué debe incluir un prompt para evitar bucles?

    Un prompt debe contener: contexto (stack), tarea específica, restricciones explícitas, criterios de verificación (tests, coverage) y condición de parada (máx iteraciones).

  • Cómo un Tech Lead utiliza IA para decisiones técnicas efectivas

    Cómo un Tech Lead utiliza IA para decisiones técnicas efectivas

    ¿Sigues tomando decisiones técnicas a ciegas y esperando que el código te lo diga todo?

    Tiempo estimado de lectura: 7 min

    • IA como herramienta de decisión: la IA no reemplaza juicio; lo amplifica.
    • Reglas prácticas: contexto claro, supuestos explícitos y validación humana.
    • Acciones concretas: PR summaries, triage con n8n y PoC de arquitectura.

    Poca gente habla de esto: la IA no viene a escribir tu código perfecto. Viene a obligarte a pensar mejor. Descubrí algo curioso en los últimos equipos con los que trabajé: los Tech Leads que usan IA bien dejan de apagar incendios. Empiezan a diseñar el futuro con menos ruido y más criterio.

    Esto no es teoría. Es práctico. Y sí: directo, sin florituras. Voy a contarte cómo un Tech Lead puede usar IA para tomar mejores decisiones —no para ser reemplazado, sino para amplificar su cabeza—, con pasos concretos, ejemplos de prompts, riesgos reales y una mini hoja de ruta que puedes implementar esta semana.

    Resumen rápido (lectores con prisa)

    La IA sintetiza contexto, enumera trade-offs y acelera tareas repetitivas. Úsala para comparar opciones, automatizar triage y generar pruebas/documentación; siempre con supuestos claros y validación humana. Implementa PoC de resúmenes de PRs y triage en una semana y define una política de privacidad para lo que puede salir de tu repositorio.

    Por qué funciona la IA para decisiones técnicas

    Porque la IA sintetiza, conecta piezas y enumera trade-offs sin agenda. No reemplaza tu juicio. Lo estira. Es como un sparring: te devuelve lo que le das, pero más rápido, con memoria y sin excusas.

    Reglas que no negociarás

    • La IA recibe contexto concreto.
    • Las respuestas deben venir con supuestos claros.
    • Ninguna recomendación en producción sale sin validación humana.

    Tácticas concretas

    1) Evaluación de trade-offs en arquitectura — sin drama

    Las decisiones arquitectónicas son guerras de costo vs. riesgo vs. tiempo. La IA las hace manejables si le das reglas.

    Qué pedirle:

    • Simular impacto de migrar a microservicios con datos de tu equipo: número de engineers, experiencia, SLA, tasa de despliegue.
    • Evaluar coste total (TCO) en un año para añadir Redis vs. escalar PostgreSQL.
    • Lista de riesgos de una librería nueva: breaking changes, incompatibilidades, vulnerabilidades CVE.

    Prompt ejemplo (útil y directo):

    Contexto: “Somos un SaaS B2B, 5 devs (3 seniors), 200k DAU, TypeScript-only; AWS con presupuesto limitado.”

    Restricción: “No queremos downtime mayor a 15 minutos; presupuesto máximo $700/mes.”

    Objetivo: “Actúa como Staff Engineer. Compara Redis vs. escalar Postgres: 3 pros, 3 contras y una recomendación con costos estimados y pasos para PoC.”

    Resultado esperado: una tabla clara, supuestos enumerados y una ruta de prueba.

    2) Automatización operativa con n8n (o tu herramienta favorita)

    Tu tiempo es el recurso más caro. Automatiza el ruido.

    Flujos que te devuelven tiempo:

    • Triage automático de issues: n8n escucha GitHub/Jira, manda el diff a un LLM, recibe severidad y asigna según ownership y contexto histórico.
    • Resúmenes de PRs: ejecuta un job que lee el diff y devuelve: propósito, riesgos, tests necesarios y archivos críticos.
    • Monitoreo inteligente: envía logs a la IA para obtener hipótesis de causa raíz y posibles hotfixes.

    Prompt para triage (n8n):

    “Lee el issue + últimos 3 PRs relacionados. Resume en 5 líneas: causa probable, riesgo para producción, prioridad (alta/media/baja) y quién es el mejor propietario del ticket en base al historial de commits.”

    Beneficio inmediato: menos contexto que dar, menos back-and-forth. Menos tiempo perdido en reuniones.

    3) Desbloqueo del equipo y deuda técnica

    Un Tech Lead pasa más tiempo desatascando que programando. La IA puede ser tu extensión para mentoring y refactor.

    Usos prácticos:

    • Saca la lógica de negocio de código legacy y propon refactors por módulos.
    • Genera tests unitarios y E2E a partir de ejemplos de entrada/salida.
    • Crea documentación interactiva: endpoints, contratos, diagramas de flujo.

    Ejemplo real: Envías un módulo viejo. La IA devuelve: resumen de responsabilidades, funciones que romperías en microservicio, lista de pruebas necesarias y una propuesta de migración en 3 pasos.

    Advertencias (sí, las hay)

    No todo lo que brilla es oro. Hay zonas grises que tenés que vigilar.

    1. Privacidad y fuga de datos

    No mandes PII, credenciales o lógica propietaria a modelos públicos sin control. Poca gente lo admite, pero muchas filtraciones ocurrieron por prompts mal protegidos.

    Solución: usa instancias privadas (Azure OpenAI, modelos on-prem), o anonimiza ejemplos antes de enviarlos.

    2. Alucinaciones

    Los LLMs pueden inventar integraciones, versiones o APIs que no existen. Siempre pide fuentes y valida con tests.

    Truco: pide “pasos reproducibles” y “comandos exactos”; si no pueden darte eso, sospecha.

    3. Dependencia del equipo

    Si tus juniors confían demasiado en la IA sin cuestionar, perdés capacidad crítica. Establecé normas: la IA propone; vos o un senior validan.

    Framework de prompts para Tech Leads (tu plantilla)

    • Contexto: 1-2 frases claras. Número de devs. Stack. SLAs.
    • Restricciones: presupuesto, tiempo, compatibilidad.
    • Objetivo: acción deseada (comparar, proponer, auditar).
    • Formato de respuesta: tabla, checklist, pasos para PoC.
    • Nivel de detalle: superficial / técnico / con comandos.

    Ejemplo corto:

    Contexto: “Equipo 6 devs, Node + TypeScript, PostgreSQL principal.”

    Restricción: “No cambiar DB por 3 meses. PoC en 2 semanas.”

    Objetivo: “Dame 3 alternativas de caché, pros/cons y comandos para configurar Redis en Docker.”

    Checklist rápido: ¿Usar IA o no?

    • Usá IA si:
      • Necesitás comparar alternativas con datos concretos.
      • Querés reducir tiempo en tareas repetitivas.
      • Querés generar documentación y tests base.
    • No la uses si:
      • El input contiene secretos sin anonimizar.
      • Buscás una validación final para producción sin revisión humana.
      • Es un tema HR o performance interpersonal.

    Plan de implementación en 3 pasos (hazlo esta semana)

    1. PoC de PR summaries (2 días)

    • Conecta webhook de PR a un script que envíe diff a un LLM.
    • Pide resumen en 5 líneas + riesgo + pruebas sugeridas.
    • Prueba con 10 PRs reales. Mide reducción de tiempo de revisión.

    2. Triage de issues con n8n (1 semana)

    • Monta un flujo que lea nuevos issues y devuelva severidad + owner.
    • Reglas: ojo con false positives. Ajusta modelo con feedback.

    3. Política de uso y privacidad (1 día)

    • Define qué se puede enviar a la IA.
    • Establece un proceso de validación humana para cambios en producción.

    Ejemplo concreto: Redis vs. Escalar Postgres (mini caso)

    Datos: 5 devs, 100k operaciones/segundo en lectura, 40% de latencia por consultas agregadas.

    Pregunta a la IA: “Compara Redis vs. escalar Postgres para reducir latencia de lectura bajo este escenario. 3 pros, 3 contras, estimación de costos y un PoC en 2 semanas.”

    Qué recibirás: tabla con pros/cons, supuestos (cache hits %), costos aproximados, pasos PoC (docker-compose para Redis, script de carga, test de latencia).

    Si haces el PoC, no olvides medir cache hit ratio, latencia p95 y coste total. Sin métricas, todo es opinión.

    Última sección: ética, cultura y liderazgo

    La IA no es neutral. Refuerza la cultura que la alimenta. Si tu equipo ya toma atajos, la IA los hará más rápidos. Si tu equipo discute, la IA será un catalizador de ideas.

    Tu trabajo como Tech Lead:

    • Definir límites.
    • Asegurar validación.
    • Fomentar el pensamiento crítico.

    Si querés profundizar en automatización y workflows para equipos técnicos, podés revisar Dominicode Labs como continuación lógica para PoCs y plantillas prácticas.

    FAQ

    Respuesta: No. La IA amplifica tu juicio y acelera tareas, pero las decisiones en producción deben pasar por validación humana.

    Respuesta: No envíes PII, credenciales ni lógica propietaria sin anonimizar. Usa instancias privadas o anonimiza antes de enviar.

    Respuesta: Pide supuestos explícitos, pasos reproducibles y comandos exactos. Verifica con tests automatizados y revisión de un senior.

    Respuesta: El plan recomendado es 2 días para un PoC básico de resúmenes de PRs: conectar webhook, enviar diffs y evaluar 10 PRs reales.

    Respuesta: Cache hit ratio, latencia p95 y coste total (TCO) son métricas imprescindibles.

    Respuesta: Establecé normas claras: la IA propone, un senior valida. Fomentá preguntas críticas y revisiones manuales periódicas.

  • Cómo planificar el uso de agentes de IA en desarrollo de software

    Cómo planificar el uso de agentes de IA en desarrollo de software

    Planning (Planificación): cómo diseñar el plan maestro para agentes de IA

    Tiempo estimado de lectura: 5 min

    • Ideas clave:
    • Planning = contrato: plan.md, architecture.md, rules.md como System Prompt persistente.
    • Usa sub-agents para investigar carpetas y devolver resúmenes estructurados sin contaminar el contexto principal.
    • Divide la Implementation en tareas atómicas con workflow reproducible y límites de iteración.
    • Validation = tests automáticos + revisiones IA + revisión humana estratégica.

    Introducción

    Planning (Planificación) debe estar en las primeras líneas de cualquier proyecto que vaya a delegar trabajo real a un agente de IA. Si no defines qué construir a alto nivel, estás firmando para que el modelo invente decisiones en tu código. En este artículo explico, con criterio técnico y ejemplos prácticos, cómo convertir la fase de Planning en la columna vertebral de un ciclo seguro: Planning → Implementation → Validation.

    Resumen rápido (lectores con prisa)

    Qué es: Planning es el contrato operativo que define objetivos, constraints, convenciones y métricas para agentes de IA.

    Cuándo usarlo: Antes de delegar tareas automatizadas o de permitir agentes a hacer commits/PRs.

    Por qué importa: Evita decisiones ad-hoc del modelo, reduce variance y protege la arquitectura.

    Cómo funciona: Documentos persistentes + sub-agents para investigación + slash commands + tests/verificación.

    Planning (Planificación): documentos, contratos y el System Prompt persistente

    Planear no es escribir un listado de features. Es crear el contrato que el agente deberá cumplir.

    Estructura mínima de plan.md

    Documentos Markdown como fuente de verdad. Crea plan.md, architecture.md, rules.md. Esos archivos son tu System Prompt persistente: contienen objetivos de negocio, constraints técnicas, convenciones de estilo, y métricas de aceptación (coverage, latencia, límites de tokens).

    # Objetivo
- Migrar dashboard a Standalone Components (Angular 22)
# Constraints
- No tocar auth-service
- Coverage Vitest >= 90%
# Verificación
- vitest --coverage
- linter/eslint

    Slash commands

    Slash commands: define comandos reutilizables que encapsulen workflows estándar. Ejemplos: /investigate src/, /plan-migration --module dashboard, /task run-tests. Implementarlos reduce variance entre prompts y evita “ad-hoc prompts” que inducen errores.

    No des todo el repo al agente principal. Haz que investigue sub-agents.

    Sub-agents: investigación sin contaminar contexto

    Definición

    Meter cientos de archivos en el contexto degrada el razonamiento. Solución: sub-agents.

    Sub-agent = proceso aislado que lee carpetas específicas, ejecuta análisis (dependencias, tree shakes, npm ls, hotspots de deuda técnica) y devuelve un resumen estructurado.

    Resultado típico de sub-agent

    Resultado típico de sub-agent:

    • Lista de archivos críticos
    • Dependencias vulnerables
    • Tests flaky detectados
    • Propuesta de subtareas

    Ese resumen alimenta el plan sin hinchar la ventana de contexto del agente principal. Implementa sub-agents como funciones serverless o procesos MCP (Model Context Protocol — Model Context Protocol) que expongan solo lo necesario.

    Implementation (Implementación): dividir para no quebrar

    La implementación es donde la disciplina se mide en errores y tiempo.

    Workflow por tarea

    Divide el plan en tareas atómicas: “Implementar validación JWT en auth.service.ts” en vez de “Crear auth”.

    1. /task [id] → agent genera cambios localmente.
    2. Ejecutar tests unitarios (vitest) y linters.
    3. Si todo OK → crear rama y PR con diff.
    4. Si falla → el agent itera (máx N veces) o marca bloqueo para revisión humana.

    Reglas imprescindibles

    Reglas imprescindibles: límite de iteraciones por tarea (p.ej. 3), --safe por defecto en comandos destructivos y ejecución en contenedores/DevContainers.

    Mantén trazabilidad: cada task debe registrar tokens consumidos, tiempo y resultado. Métricas simples que importan: tokens/tarea, tests rotos introducidos, tiempo humano por corrección.

    Validation (Validación): automatización + juicio humano

    Tests y revisiones automáticas

    No hay merge sin validación. Tests automáticos primero: suites unitarias, E2E (Playwright), coverage thresholds.

    Revisiones automáticas por IA: usa herramientas como CodeRabbit para revisar PRs. Estas herramientas detectan problemas de complejidad, seguridad y estilo antes de que pase a humano.

    Revisión humana estratégica

    Revisión humana estratégica: no valides línea por línea. Valida intención arquitectónica: ¿el cambio respeta architecture.md? ¿Introduce deuda oculta? ¿Hay trade-offs no documentados?

    Documenta las excepciones. Cada PR debe contener la referencia al segmento de plan.md que motiva el cambio.

    Patrones operativos y plantillas útiles

    Slash command template

    /task create
--id: migrate-dashboard-01
--scope: src/dashboard
--verify: vitest --coverage
--constraints: no-auth
--max-iter: 3

    Sub-agent summary schema

    {
  "files": [...],
  "hotspots": [...],
  "tests_flaky": [...],
  "recommendation": "split module, add tests"
}

    Estas plantillas convierten la improvisación en procesos reproducibles.

    Criterio para decidir si adoptar este flujo

    Adóptalo si:

    • Tienes stack moderno (TypeScript, Angular/React con tests).
    • Puedes aislar ejecución (Docker, DevContainers).
    • El equipo acepta medir: tokens por task, tests green rate.

    No lo adoptes si:

    • Tu repo es monolito sin tests.
    • No puedes auditar secrets y gastos.
    • No hay disciplina para documentar plan.md.

    Gobernanza y métricas mínimas

    Quota tokens por usuario/equipo (ej. $10–20/dev/día). Logs de sesión y transcripts almacenados. KPIs: tokens/tarea, %tasks auto-merged, tiempo humano por PR.

    Planning (Planificación) no es burocracia; es el ancla. Divide, documenta y aísla. Usa sub-agents para investigar, slash commands para repetir y tests + CodeRabbit para validar. Hazlo bien y evitarás que tus agentes escriban código sin responder a tu arquitectura. Esto no acaba aquí: define tu primer plan.md hoy y convierte esa decisión en política de equipo.

    Dominicode Labs

    Para equipos interesados en explorar patrones operativos y sub-agents como prácticas reproducibles, una continuación lógica es revisar recursos y experimentos en Dominicode Labs. Estos recursos documentan plantillas y flujos que complementan la estrategia expuesta arriba.

    FAQ

    ¿Qué debe contener exactamente plan.md?

    Debe incluir Objetivo, Constraints y Verificación. Ejemplo mínimo: objetivo del cambio, restricciones (p.ej. no tocar auth-service), y comandos de verificación (p.ej. vitest --coverage, linters).

    ¿Cómo funcionan los sub-agents sin filtrar contexto al agente principal?

    Los sub-agents analizan áreas específicas fuera del contexto principal y devuelven un resumen estructurado (archivos críticos, hotspots, tests flaky, recomendación). Solo ese resumen entra al agente principal.

    ¿Qué límites de iteración recomiendan por tarea?

    Un límite razonable es 3 iteraciones por tarea. Si excede, marcar bloqueo para revisión humana.

    ¿Qué herramientas de review automático recomiendan?

    Herramientas como CodeRabbit son adecuadas para detectar complejidad, seguridad y estilo antes de pasar a revisión humana.

    ¿Cómo se relaciona plan.md con el System Prompt persistente?

    Los documentos plan.md, architecture.md y rules.md actúan como System Prompt persistente: contienen objetivos, constraints, convenciones y métricas de aceptación que el agente debe respetar.

    ¿Qué métricas son imprescindibles para gobernanza?

    Ejemplos: tokens/tarea, %tasks auto-merged, tiempo humano por PR. Además, establecer cuotas de tokens por usuario/equipo y almacenar logs/transcripts.

    ¿Cuándo NO adoptar este flujo?

    No lo adoptes si tu repo es un monolito sin tests, no puedes auditar secrets/gastos o no hay disciplina para documentar plan.md.

  • Cómo usar IA para mejorar la gestión de equipos técnicos y decisiones críticas

    Cómo usar IA para mejorar la gestión de equipos técnicos y decisiones críticas

    ¿Cuánto cuesta no saber qué decir en una 1:1? ¿Cuánto vale una mala decisión que frena a todo el equipo un mes entero? Si tu respuesta no implica cambiar algo esta semana, entonces sigues jugando a ser manager por inercia.

    Tiempo estimado de lectura: 6 min

    • Ideas clave:
    • Usar IA en gestión es disciplina, no outsourcing emocional.
    • Estandariza prompts, protege privacidad y convierte guiones en tareas concretas.
    • Un framework de prompt (Rol, Contexto, Restricciones, Output) produce resultados reproducibles.
    • Mide impacto con métricas claras antes de escalar cambios.

    Poca gente habla de esto: la IA no es la que va a reemplazar a tu gente. Es la que te permite dejar de improvisar, estructurar conversaciones difíciles y que tus decisiones técnicas no parezcan recetas de cocina hechas a ojo.

    Te digo esto directo: usar IA para gestionar un equipo no es outsourcing emocional. Es crear disciplina. Es tener guiones, datos y planes de acción reproducibles. Y sí, vas a seguir siendo responsable de todo. La IA solo te prepara mejor.

    Resumen rápido (lectores con prisa)

    La IA aplicada a gestión ayuda a estructurar 1:1s, generar guiones empáticos y convertir feedback en tareas medibles. Úsala para preparar conversaciones y formular métricas; evita pegar datos sensibles en servicios públicos. Implementa prompts versionados y mide impacto antes de escalar.

    Por dónde empezar (sin sentimentalismos)

    1. 1) Usa la IA para preparar, no para reemplazar.
    2. 2) No metas datos sensibles en servicios públicos. Punto.
    3. 3) Estandariza prompts como versionas código. Y úsalo como primer borrador: tú editas, tú decides.

    Qué puede hacer la IA por ti (y lo que no)

    • Bien: estructurar 1:1s, generar guiones empáticos, identificar cuellos de botella de procesos, descomponer epics, preparar feedback con marco SBI, proponer tests y métricas para PoCs.
    • Mal: reemplazar tu empatía, calcular costes exactos de cloud sin contexto, saber qué pasa en casa de un desarrollador.
    • Útil: detecta patrones, propone preguntas que no humillan, formula checklists y pruebas, y te recuerda pasos que olvidas cuando estás cansado.

    Framework de uso: 4 bloques que debes incluir en cada prompt

    No le des a la IA “un problema”. Dale esto:

    1. Rol: “Actúa como Engineering Manager con 8 años en startups y 3 en infra crítica.”
    2. Contexto: stack, tamaño de equipo, presión del negocio, deadlines.
    3. Restricciones: privacidad, políticas de la compañía, recursos no disponibles.
    4. Output: formato exacto (script para 1:1, checklist de PoC, RFC, tests a añadir).

    Plantillas que funcionan (copiar y pegar)

    1) Preparar 1:1 con alguien que falla en plazos

    System: “Eres un Engineering Manager experimentado. Sé directo y empático.”

    User: “Help me prepare a 1:1 conversation with a developer who is struggling with deadlines. Context: mid-senior, works remoto, backlog includes refactor + feature launch in 3 weeks. Constraints: avoid accusatory tone; don’t escalate to HR yet. Output: 1) a 6-step script to run the 1:1, 2) 3 open questions to identify root cause, 3) 2 follow-up actions with deadlines.”

    Qué esperar: guion con apertura segura, preguntas para explorar impedimentos técnicos y personales, y acciones claras (acortar scope, pair programming, reassign).

    2) Analizar problemas de equipo (Five Whys + acciones)

    System: “Actúa como Agile Coach senior.”

    User: “Our team missed the epic deadline for 3 sprints. PRs take 4 days to review; QA rejects 30% of builds. Apply Five Whys and return: root causes, 3 immediate audits to run, and 2 process changes to implement this sprint.”

    Qué esperar: causas raíz (definición pobre de ready, reviewers sobrecargados, flaky tests), y pasos concretos (limitar PR tamaño, revisión por pares rotativa, pipeline flaky tests assault).

    3) Redactar feedback con SBI (para situaciones tensas)

    System: “Sé claro y constructivo. Usa SBI framework.”

    User: “Provide feedback for a senior who interrupts juniors in dailies. Output: 1) SBI phrasing, 2) 2 coaching questions, 3) suggested follow-up in 2 weeks.”

    Qué esperar: mensaje que señala la situación, comportamiento e impacto; preguntas que invitan a reflexión; plan de seguimiento.

    4) Planificar sprints complejos

    System: “Actúa como PM técnico y tech lead.”

    User: “Help plan a sprint to migrate payments to Stripe. Stack Node.js + Angular. Constraints: keep current features live, 2-week sprint, 3 devs. Output: 1) breakdown in 8 tasks, 2) risks & mitigations, 3) success metrics for PoC.”

    Qué esperar: tickets paralelizables (adapter, backendWebhook, dataMigration in small batches), riesgos (rollback plan, data-consistency), métricas (time-to-reconcile, error-rate).

    Cómo convertir guiones en acción real

    • Guarda la transcripción del 1:1 y automatiza un “summary” que quede en el ticket del empleado (sin PII si lo procesas en nube pública).
    • Transforma el feedback en tareas: “pair on X”, “reduce scope Y”, “test Z”.
    • Usa la IA para generar los tests que deberían existir tras el PoC. Pide ejemplos de test cases y scripts de carga.

    Privacidad y ética (no es negociable)

    • Nunca pegues nombres, salarios o datos médicos en un modelo público.
    • Usa instancias privadas, entornos on-prem o proveedores con Zero Data Retention.
    • Versiona prompts y audita salidas: registra qué prompt produjo qué recomendación y quién la aprobó.

    Medir para no decidir a ciegas

    Define métricas antes de implementar cambios:

    • Tiempo medio de entrega de PRs.
    • Porcentaje de builds rechazados por QA.
    • Tiempo medio para resolución de blockers.
    • Tiempo de onboarding para nuevas prácticas (medido tras 2–4 sprints).

    Cómo automatizar (sin convertirte en SRE)

    • Usa plantillas de prompt en tu docs de equipo (prompt-v1.0).
    • Integra en un workflow sencillo: PR → IA pre-check (process & mentorship hints) → humano revisa → acción.
    • Genera reportes semanales automáticos: “Top 3 impediments” y “2 quick wins”.

    Errores reales que veo y cómo evitarlos

    • Error: Usar la IA para decidir despidos. Solución: la IA puede estructurar evidencia, pero la decisión humana y la conversación personal siguen siendo tuyas.
    • Error: Pegar codebase entero en un chat público. Solución: anonimizar y usar entorno privado.
    • Error: confiar en la IA en temas legales o de compensación. Solución: consulta Legal & HR.

    Ejemplo práctico, paso a paso (5 minutos para preparar 1:1)

    1. Copia el contexto del dev (rol, tickets, fechas).
    2. Pega en el prompt de 1:1 (plantilla arriba).
    3. Recibe el guion: 2 minutos de lectura.
    4. Personaliza 3 frases clave (tu toque humano).
    5. En la reunión: usa el guion, toma notas, define 2 acciones y pon seguimiento en calendario.

    Cómo escalar cultura con IA sin destruirla

    • Enseña al equipo a usar las plantillas: que ellos también pidan guiones para conversaciones difíciles.
    • Publica ejemplos en la wiki: “cómo dar y recibir feedback”, construidos con IA pero aprobados por humanos.
    • Mide el impacto: hacen menos escaladas a Product o a HR? Se entregan más features?

    Checklist mínimo antes de usar IA en gestión

    • [ ] ¿Prompt versionado y aprobado por legal?
    • [ ] ¿Modelo privado o proveedor con Zero Data Retention?
    • [ ] ¿Seudónimos para datos sensibles?
    • [ ] ¿Métricas definidas para validar la acción?
    • [ ] ¿Plan de seguimiento (fechas y responsables)?

    Cultura de experimentación (hazlo iterativo)

    No prometas el paraíso. Promete pequeñas mejoras repetibles. Ejecuta esto en ciclos cortos:

    • Sprint 0: prueba 3 1:1 con IA.
    • Sprint 1: aplica cambios en la planificación y mide.
    • Sprint 2: amplía a todo el equipo si hay mejora.

    Cierre — lo práctico y lo urgente

    La IA te da estructura. Tú das la humanidad. Juntos pueden convertir reuniones tensas en conversaciones productivas, cuellos de botella en tareas concretas y decisiones en experimentos medibles.

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

    • 10 prompts listos (1:1, feedback SBI, Five Whys, sprint planning).
    • Una plantilla RFC para cambios de proceso.
    • Un checklist de privacidad y métricas.

    Di “QUIERO EL KIT” y te lo paso todo en formato listo para pegar en tu Notion o repo. Y si prefieres que te arme el primer guion de 1:1 con un caso real (sin PII), pégame el contexto y lo preparo en 10 minutos.

    Si quieres integrar workflows y plantillas de prompts en tus procesos, revisa lo que hacemos en Dominicode Labs como continuación lógica para automatizar pasos repetibles y versionar prompts en tu equipo.

    FAQ

    ¿La IA puede reemplazar a un manager?

    No. La IA apoya en preparación y estructura, pero la responsabilidad humana en decisiones, empatía y conversaciones personales sigue siendo irremplazable.

    ¿Qué datos no debo poner en un prompt?

    Nombres, salarios, datos médicos y cualquier información identificable o sensible. Usa seudónimos y entornos privados para datos internos.

    Cómo mido si la IA está ayudando realmente

    Define métricas antes de aplicar cambios: tiempo medio de entrega de PRs, porcentaje de builds rechazados, tiempo de resolución de blockers y tiempo de onboarding para nuevas prácticas.

    ¿Debo versionar mis prompts?

    Sí. Versiona prompts como código, registra quién aprobó cambios y audita salidas para trazar decisiones y mejoras.

    Qué hacer si una recomendación de IA contradice a HR

    Prioriza la política de HR. Usa la IA para estructurar evidencia, pero consulta a HR y Legal antes de acciones sensibles como despidos o cambios contractuales.

    ¿Puedo usar prompts públicos para casos con PII?

    No. Nunca pegues PII en modelos públicos; usa instancias privadas o proveedores con políticas de retención cero y anonimiza datos cuando sea necesario.

  • Integración de Gemini Nano con Angular para IA Local en el Navegador

    Integración de Gemini Nano con Angular para IA Local en el Navegador

    Integración de Gemini Nano con Angular: IA Local en el Navegador

    Tiempo estimado de lectura: 5 min

    Ideas clave

    • Gemini Nano puede ejecutarse on-device en Chrome mediante la Prompt API / LanguageModel API experimental, evitando enviar datos a la nube.
    • Recomienda abstraer el acceso a window.LanguageModel en un servicio Angular inyectable y exponer estados reactivos con Signals.
    • Implementa fallback a la nube (Vertex AI, OpenAI, etc.) si el modelo on-device no está disponible.
    • Prepárate para descargas iniciales de pesos, impacto en recursos del cliente y cambios en la API; ofrece métricas y UX claras.

    Tabla de contenidos

    Resumen rápido (lectores con prisa)

    Gemini Nano permite ejecutar modelos de lenguaje on-device en Chrome mediante una Prompt API experimental. Úsalo para operaciones sensibles a la privacidad y bajas latencias; diseña un servicio Angular que abstraiga window.LanguageModel, exponga estados con Signals y ofrezca fallback a la nube.

    Qué necesitas activar y por qué importa

    Gemini Nano llega al frontend vía la Prompt API / LanguageModel API que Chrome está probando. Es experimental: hay que habilitar flags y aceptar descargas iniciales del modelo en el cliente. Hazlo solo en entornos controlados.

    Puntos prácticos

    • Abre chrome://flags y habilita las flags relacionadas con Prompt API (busca “Prompt API” / “on-device model”).
    • Revisa chrome://components y chrome://on-device-internals para estado y métricas.
    • La primera ejecución puede descargar pesos (depende de la build). Avisa al usuario con un estado de “descarga en progreso”.

    Referencias útiles

    Arquitectura recomendada en Angular

    Regla número uno: no uses window directamente en componentes. Abstrae todo en un servicio inyectable que gestione disponibilidad, descarga y sesión. Usa Signals para exponer estados reactivos y facilitar la integración con componentes.

    global.d.ts (tipos mínimos)

    declare global {
  interface Window {
    LanguageModel?: {
      availability(options?: any): Promise;
      create(options?: any): Promise;
    };
  }
}
export {};

    Servicio Angular (esqueleto)

    import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class GeminiNanoService {
  isAvailable = signal<'checking'|'available'|'unavailable'>('checking');
  isReady = signal(false);
  private session: any = null;

  constructor() {
    this.checkAvailability();
  }

  async checkAvailability() {
    if (!window.LanguageModel) {
      this.isAvailable.set('unavailable');
      return;
    }
    try {
      const status = await window.LanguageModel.availability({
        expectedInputs:[{type:'text'}], expectedOutputs:[{type:'text'}]
      });
      this.isAvailable.set(status === 'available' ? 'available' : 'unavailable');
      if (this.isAvailable() === 'available') await this.init();
    } catch {
      this.isAvailable.set('unavailable');
    }
  }

  private async init() {
    this.session = await window.LanguageModel!.create({
      // monitor: callback para progreso de descarga si aplica
    });
    this.isReady.set(true);
  }

  async prompt(text: string, opts?: any) {
    if (!this.session || !this.isReady()) throw new Error('Gemini Nano no listo');
    return await this.session.prompt(text, opts);
  }
}

    Usa APP_INITIALIZER si quieres bloquear rutas hasta que la disponibilidad esté verificada.

    Patrones de uso: Resúmenes y Smart Paste

    Dos patrones repetibles son útiles: resúmenes client-side y Smart Paste para estructurar texto del portapapeles. Úsalos cuando la privacidad y la latencia local sean prioritarias.

    1) Resúmenes client-side

    • Ideal para emails, tickets y documentación sensible.
    • Prompt corto, instrucciones claras y límites (p. ej. “tres bullets”).
    const prompt = `Resume en 3 viñetas técnicas, sin ejemplos ni explicaciones: ${longText}`;
const summary = await geminiService.prompt(prompt);

    2) Smart Paste (estructurar texto del portapapeles)

    Intercepta ClipboardEvent, manda el texto al modelo y pide JSON estricto. Valida con JSON.parse y aplica patchValue en FormGroup.

    Ejemplo de prompt:

    Extrae nombre, cargo, empresa y teléfono del texto y responde SOLO con JSON válido.
Texto: "..."

    Consejo: limpia la respuesta de bloques de código (“`json) antes de parsear.

    Estrategia híbrida: fallback a la nube

    La API es experimental y puede no estar disponible en todos los usuarios. Diseña un fallback:

    • Servicio expone promptLocal() y promptCloud().
    • Lógica: si isReady() → local; si no → cloud (Vertex AI, OpenAI, etc.).
    • Mantén la misma interfaz para consumidores.
    async prompt(input:string){
  return this.isReady() ? this.promptLocal(input) : this.promptCloud(input);
}

    Limitaciones y decisiones técnicas

    No es magia. Decide por criterios claros:

    • Privacidad vs Capacidad: on-device evita enviar datos, pero modelos locales suelen ser más limitados en razonamiento y factualidad.
    • Recursos del cliente: descarga inicial y uso de RAM/GPU. Ofrece UI de progreso y posibilidad de desactivar la característica.
    • Inestabilidad: la API puede cambiar; encapsula y prueba en Canary/Dev builds.

    Buenas prácticas de implementación

    • Aisla feature flags para habilitar/deshabilitar en producción.
    • Expón métricas de adopción y errores (no datos sensibles).
    • Documenta UX: indica cuándo la funcionalidad requiere descarga y ofrece opción “Usar IA en la nube”.
    • Testea en dispositivos representativos de tus usuarios (PCs y Chromebooks, no asumas móviles).

    La integración de Gemini Nano con Angular no es un truco de marketing: es una arquitectura pragmática para reducir latencia, mejorar privacidad y sacar tareas concretas del backend. Implementa la abstracción, prevé el fallback y deja el modelo decidir cuándo merece la pena correr on-device. Esto apenas comienza: prueba en controlado, mide impacto y ajusta el balance on-device / cloud.

    Dominicode Labs ofrece un espacio para experimentar con integraciones de IA aplicada y workflows relacionados; puede servir como referencia para pruebas controladas y métricas de adopción.

    FAQ

    ¿Qué es Gemini Nano en el contexto del navegador?

    Es una implementación on-device de modelos de lenguaje accesible mediante la Prompt API / LanguageModel API experimental de Chrome, que permite ejecutar inferencia local en el navegador sin enviar datos a la nube.

    ¿Qué flags y páginas de Chrome debo revisar?

    Habilita las flags relacionadas con Prompt API en chrome://flags y revisa estado y métricas en chrome://components y chrome://on-device-internals.

    ¿Cómo debo abstraer la API en Angular?

    Crea un servicio inyectable que gestione disponibilidad, descarga y sesión; no uses window directamente en componentes. Exponer estados con Signals facilita la integración reactiva y el bloqueo de rutas con APP_INITIALIZER si es necesario.

    ¿Cuándo usar fallback a la nube?

    Implementa fallback cuando isReady() sea false o cuando el dispositivo no soporte la ejecución on-device. Mantén la misma interfaz para que consumidores no distingan origen (local vs cloud).

    ¿Qué impacto tiene en recursos del cliente?

    Puede requerir descarga inicial de pesos y uso adicional de RAM/GPU. Ofrece UI de progreso, opción para desactivar la característica y prueba en dispositivos representativos.

    ¿Cómo validar respuestas estructuradas como JSON?

    Pide al modelo que responda SOLO con JSON válido, limpia posibles bloqueos de código (“`json) y usa JSON.parse para validar antes de aplicar patchValue en formularios.

  • Construcción de memoria efectiva en agentes de LLMs

    Construcción de memoria efectiva en agentes de LLMs

    ¿Quieres que tu agente recuerde cosas útiles… o que haga como si recordara y te deje colgado en la siguiente conversación?

    Tiempo estimado de lectura: 7 min

    • Separar memoria corta y larga: la conversación viva debe manejarse aparte de hechos estructurados.
    • Extraer hechos estructurados: usar un extractor que emita JSON y aplicar UPSERT/DELETE, no append infinito.
    • Decisiones arquitectónicas: síncrono vs asíncrono, versionado y locks para evitar race conditions.
    • Optimizar costes: usar modelos baratos para extracción, modelos premium solo para generación crítica.
    • Observabilidad y Gobernanza: logs, métricas, cifrado y políticas de retención son imprescindibles.

    Poca gente habla de esto: la memoria en agentes no es un problema de “mandar el historial” al modelo. Es un problema de arquitectura, coste y criterio. Hacerlo mal es pagar tokens, cargar latencia y, lo peor, construir una ilusión de memoria que falla cuando más importa.

    Te voy a contar, sin florituras, cómo se construyó el sistema de memoria de Agent Builder y qué decisiones concretas puedes tomar hoy para replicarlo sin pelearte con un monster framework.

    Resumen rápido (lectores con prisa)

    Separar memoria corta (últimos N mensajes) de memoria larga (hechos estructurados). Usar un extractor barato que devuelva JSON forzado con operaciones UPSERT/DELETE. Preferir extracción asíncrona por defecto y checkpoints síncronos para acciones críticas. Versionado y locks para evitar race conditions; observabilidad y gobernanza desde el día 1.

    Primera verdad incómoda

    Primera verdad incómoda: los LLMs no recuerdan.

    Cada petición es una hoja en blanco. Si quieres que el agente actúe con coherencia, tienes que diseñar la memoria fuera del modelo.

    Resumen rápido del approach que funciona

    • Separar memoria a corto plazo (conversación viva) de memoria a largo plazo (hechos estructurados).
    • Extraer hechos con un LLM dedicado (extractor) y guardarlos como pares clave-valor o documentos estructurados.
    • Forzar salidas en JSON (Tool Calling) para que la memoria sea determinista.
    • Resolver conflictos con UPSERT/DELETE, no con append infinito.
    • Decidir entre extracción síncrona o asíncrona según prioridades (latencia vs coherencia).

    1) Memoria a corto plazo: lo que vive ahora

    ¿Qué es? Los últimos N mensajes del hilo (thread_id).

    Para qué sirve: referencias inmediatas (“bórralo”, “ese archivo”, “la última tarea”).

    Implementación simple: Redis o una tabla en Postgres con TTL y lista acotada.

    Por qué importa: reduce tokens enviados al LLM principal y mantiene claridad a corto plazo.

    2) Memoria a largo plazo: hechos, no chats

    No guardes el chat crudo. Guarda hechos estructurados: preferencias, roles, reglas de negocio, acciones ya realizadas.

    ¿Cómo se obtienen? Un LLM extractor lee el hilo (o el resumen) y emite objetos JSON con campos tipo {key, value, source, timestamp, confidence}.

    Dónde guardarlos: una tabla Key-Value en Postgres o en Redis para lecturas rápidas; opcionalmente, una base vectorial si necesitas búsquedas semánticas sobre fragmentos largos.

    3) El extractor: el héroe silencioso

    Debe ser un LLM barato y rápido (GPT-4o-mini, Claude 3 Haiku o un modelo local si tienes infra).

    Se le da: el hilo reciente + la memoria actual (opcional, si quieres que compare).

    Debe devolver: operaciones del tipo {op: “UPSERT”, key: “pref_theme”, value: “dark”, reason: “…”} o {op: “DELETE”, key: “pref_theme”, reason: “…”}.

    Forzar JSON es obligatorio. Si el modelo alucina, valida la salida con un schema validator (Zod, JSON Schema).

    4) Resolver conflictos: no más “y también”

    Problema típico: ayer dije “React”, hoy “Angular” y el sistema almacena ambos.

    Solución: lógica de reconciliación dentro del extractor — recibe la memoria existente y decide overwrites o borrados.

    Políticas útiles: última declaración gana para preferencias personales; para estados transaccionales usar confirmación explícita (“Confirmo que he migrado a Angular”).

    5) Síncrono vs Asíncrono — la decisión que rompe equipos

    Síncrono: esperas a que el extractor actualice la memoria antes de responder. Plus: coherencia. Contra: latencia.

    Asíncrono: respondes al usuario y actualizas memoria en background. Plus: experiencia rápida. Contra: race conditions si el usuario dispara múltiples mensajes seguidos.

    Recomendación práctica: asíncrono por defecto, con checkpoints síncronos en operaciones críticas (ej. ejecutar acciones que dependen de la memoria: “programa el pago” → usa extracción síncrona o confirmación humana).

    6) Mitigar race conditions: patrones que funcionan

    • Versionado por evento: cada update incluye un version_id. Si un job en background llega con versión vieja, lo descarta.
    • Locks optimistas: comparar-timestamps antes de aplicar UPSERT.
    • Event sourcing ligero: mandar events al bus (Kafka, Redis Streams) y procesarlos ordenadamente.
    • Si necesitas garantía fuerte, usa transacciones y bloqueo por llave (Postgres advisory locks).

    7) Costes y optimización de tokens

    No envíes texto innecesario al LLM principal. Inyecta solo facts relevantes (top-K) y un resumen de contexto.

    Batch extraction: agrupa varias interacciones y extrae cada X minutos si no hay acciones críticas.

    Usar modelos cheap para extractor y modelos premium para generación cuando haga falta.

    8) Observabilidad y LLMOps: no es opcional

    • Logea: inputs al extractor, salidas JSON, ops aplicadas (UPSERT/DELETE), latencias, errores de parsing.
    • Métricas clave: TTFT, tiempo de extracción, tasa de conflictos, porcentaje de respuestas incoherentes relacionadas con memoria.
    • Guarda trazabilidad para auditoría (what was injected, when, by which extractor) — imprescindible si manejas PII.

    9) Privacidad y gobernanza

    • Nunca almacenes datos sensibles sin cifrado y consentimiento.
    • Tokeniza o anonimiza cuando sea posible.
    • Control de accesos: solo servicios autorizados pueden leer/escribir la memoria.
    • Políticas de retención: define cuánto tiempo quedan los hechos y cómo se borran permanentemente.

    10) Tests y validación

    • Tests unitarios de extractor: inputs -> JSON schema válido.
    • Integración: simula secuencias de diálogos para validar conflict resolution.
    • E2E: pruebas que cubran casos de race conditions y rollback.
    • Prueba manual de A/B: compara comportamiento con y sin memoria en producción limitada.

    11) Stack recomendado mínimo (para lanzar rápido)

    • Storage corto: Redis (listas con TTL)
    • Storage largo: Postgres (tabla kv con versioning) + opcional vector DB (Pinecone/Qdrant)
    • Orquestador: n8n / Lambda / Sidecar service
    • Extractor model: GPT-4o-mini / Claude 3 Haiku (económicos)
    • Generación model: GPT-4o / Claude 3 Sonnet (cuando necesites calidad)
    • Validación: JSON Schema + Zod en backend
    • Observabilidad: logs estructurados + Sentry / Datadog

    12) Checklist práctico para ponerlo en producción (si te gusta lo concreto)

    • [ ] Definir qué “hechos” guardas (user_prefs, last_actions, contracts_signed, etc.).
    • [ ] Implementar almacenamiento corto (Redis) y largo (Postgres).
    • [ ] Crear extractor con JSON forced output y validar schema.
    • [ ] Implementar operaciones UPSERT/DELETE con versionado.
    • [ ] Diseñar flujo asíncrono por defecto y rutas síncronas para operaciones críticas.
    • [ ] Añadir metrics y logs para cada extracción y operación.
    • [ ] Revisar PII/retención y cifrado en reposo y en tránsito.
    • [ ] Tests automáticos para race conditions y reconciliación.
    • [ ] Plan de rollback si una actualización de prompt rompe el extractor.

    Metáfora que guarda la idea

    La memoria del agente no es una mochila donde tiras todo el chat. Es una libreta indexada. Solo apuntas lo que te sirve, lo fechas, lo restructuras y borras lo viejo. Si apilas notas sin orden, la libreta es ruido. Si la estructuras, te salva.

    Historias reales (1 párrafo cada una)

    El equipo A metió todo el historial en cada prompt: coste x10, latencias enormes y usuarios desconectados. Migraron a extractor asíncrono y bajaron costes un 70%.

    El equipo B aseguró cada operación con versión y locks: sacrificaron un poco de velocidad, pero nunca perdieron coherencia en flujos transaccionales.

    El equipo C dejó la extracción en background y puso un checkpoint síncrono antes de ejecutar pagos — ganador en UX y seguridad.

    Cierre con decisión: ¿lo haces tú o lo dejas para después?

    Construir memoria útil no es sexy. Es ingeniería, decisiones difíciles y pruebas. Pero sin ella, tu “agente” será otro bot que habla bonito y olvida todo. Si quieres lanzar algo que realmente parezca inteligente, hazlo con lógica, no con parcheos.

    Si quieres la checklist descargable, un prompt extractor listo para copiar/pegar y un mini-plan de 30 días para implementar esto en tu stack, respóndeme “QUIERO MEMORIA” y te lo mando. Esto no acaba aquí — y si no empiezas hoy, otro equipo lo hará.

    Como continuación lógica para quienes trabajan en automatización, agentes y workflows, puedes encontrar recursos y experimentos en Dominicode Labs.

    FAQ

    Respuesta: ¿Qué diferencia hay entre memoria a corto y a largo plazo?

    La memoria a corto plazo contiene los últimos N mensajes del hilo y sirve para referencias inmediatas. La memoria a largo plazo almacena hechos estructurados (preferencias, roles, acciones realizadas) que deben persistir y consultarse por el agente cuando sea relevante.

    Respuesta: ¿Por qué no guardar el chat completo?

    Guardar el chat crudo aumenta costes (tokens), latencia y ruido. Es mejor extraer hechos útiles y estructurarlos para lecturas rápidas y deterministas.

    Respuesta: ¿Qué es un extractor y qué formato debe devolver?

    Un extractor es un LLM barato y rápido que lee el hilo o su resumen y devuelve operaciones en JSON forzado, por ejemplo {op: “UPSERT”, key: “…”, value: “…”, reason: “…”}. La salida debe validarse con un schema validator.

    Respuesta: ¿Cuándo usar extracción síncrona en lugar de asíncrona?

    Usa extracción síncrona para operaciones críticas que dependen inmediatamente de la memoria (ej. ejecutar pagos). Por defecto, asíncrono para mejor UX y menor latencia, con checkpoints síncronos donde haga falta.

    Respuesta: ¿Cómo mitigo race conditions en actualizaciones de memoria?

    Patrones efectivos: versionado por evento (version_id), locks optimistas (comparar timestamps), event sourcing ligero y, si necesitas garantías fuertes, transacciones y bloqueo por llave en Postgres.

    Respuesta: ¿Qué métricas debo monitorizar?

    Métricas clave sugeridas: TTFT, tiempo de extracción, tasa de conflictos y porcentaje de respuestas incoherentes relacionadas con memoria. Además, loggear inputs, salidas JSON y ops aplicadas para trazabilidad.

    Respuesta: ¿Qué precauciones de privacidad aplicar?

    Nunca almacenar datos sensibles sin cifrado y consentimiento. Tokenizar o anonimizar cuando sea posible, controlar accesos y definir políticas de retención claras.

  • Cómo implementar evaluaciones automatizadas para agentes de IA

    Cómo implementar evaluaciones automatizadas para agentes de IA

    Testing Your AI Agent Skills

    Testing Your AI Agent Skills debe ser el primer paso después de escribir un SKILL.md. Si no tienes una suite de evals automatizados, lo que hoy llamas “skill” es un prototipo frágil: funciona en local tres veces y falla en producción cuando más importa. Aquí explico cómo pasar de sensaciones a ingeniería sólida, con ejemplos prácticos, métricas y scripts que puedes integrar hoy mismo.

    Tiempo estimado de lectura: 4 min

    • Automatiza evals: una skill sin evaluación automatizada es frágil; integra graders deterministas y repite trials.
    • Métricas claras: mide capacidad (pass@k), fiabilidad (pass^k) y correctitud (grader determinista con exit codes).
    • Aislamiento: usa Docker para cada trial y destruye el entorno tras la verificación.
    • Repetición: ejecuta >=5 trials para estimar estabilidad; optimiza para pass^k alto antes de producción.

    Testing Your AI Agent Skills: por qué importa y qué mide un eval

    Una Skill no es un prompt bonito: es documentación ejecutable que un agente usa para actuar. Cambiar una instrucción, reordenar pasos o quitar una verificación puede romper el comportamiento sin avisos. Los LLMs son no deterministas; una ejecución exitosa no prueba nada. Los evals automatizados solucionan eso midiendo tres cosas:

    • Capacidad (pass@k): ¿puede el agente resolver la tarea al menos una vez en k intentos?
    • Fiabilidad (pass^k): ¿la resuelve todas las veces en k intentos?
    • Correctitud (grader determinista): ¿el resultado cumple la condición objetiva (compila, lint pasa, tabla creada)?

    Un ejemplo realista de comando que debes poder ejecutar en CI:

    GEMINI_API_KEY=your-key npm run eval superlint -- --provider=docker --trials=5

    Eso encapsula aislamiento (Docker), repetición estadística (trials) y la unidad de test (la skill superlint).

    Repositorio de referencia: https://github.com/mgechev/skill-eval

    Arquitectura mínima de un eval efectivo

    Cada tarea debe ser autocontenida y reproducible. Estructura sugerida:

    tasks/my_task/
├── task.toml           # timeouts, recursos, límites
├── instruction.md      # el prompt único para el agente
├── environment/Dockerfile
├── tests/test.sh       # grader determinista (shell)
├── prompts/quality.md  # grader de rúbrica (opcional)
├── solution/solve.sh   # referencia
└── skills/my_skill/
    └── SKILL.md

    Principios clave:

    • El agente recibe solo instruction.md como prompt primario. Las skills viven en rutas de descubrimiento estándar (.agents/skills/ o .claude/skills/).
    • Los graders deterministas deben ser código: scripts que ejecutan eslint, npm test o consultas SQL y devuelven PASS/FAIL.
    • Usa Docker para aislar cada trial y destruir el contenedor tras la verificación. Documentación Docker: https://www.docker.com/

    Ejemplo práctico: verificador determinista para superlint

    Si la tarea es “arreglar errores de lint”, el grader no puede ser subjetivo. Un ejemplo de tests/test.sh:

    #!/usr/bin/env bash
set -e
# Ejecuta eslint en la ruta de trabajo
npx eslint main.js --max-warnings=0
if [ $? -eq 0 ]; then
  echo "PASS"
  exit 0
else
  echo "FAIL"
  exit 1
fi

    No preguntes al LLM “¿lo hiciste bien?”. Ejecuta eslint (https://eslint.org) y deja que el exit code decida.

    Repetición y métricas: por qué 5 trials no es arbitrario

    Los LLMs introducen variabilidad. Ejecutar 5 trials te da una muestra mínima para estimar estabilidad. Interpretación práctica:

    • pass@5 = 100% y pass^5 = 100% → listo para producción.
    • pass@5 = 100% y pass^5 = 30% → el agente puede hacerlo, pero es flaky; no desplegar.
    • pass@5 < 80% → la skill necesita rediseño (más contexto, scripts deterministas, aclaraciones en SKILL.md).

    Para workflows críticos (migraciones, despliegues), fija umbral >= 90% pass^k.

    Integración CI: Quality Gate para Skills

    Añade un job que corra los evals en cada PR que toque skills/ o tasks/:

    name: Skill Eval
on:
  pull_request:
    paths: ['skills/**', 'tasks/**']

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: GEMINI_API_KEY=${{ secrets.GEMINI_API_KEY }} npm run eval my_task -- --trials=5 --provider=docker

    Si la tasa de éxito cae por debajo del umbral, el PR queda bloqueado con el output del eval (trials individuales, logs, grader output). Esa transparencia es crítica para debugging rápido.

    Diagnóstico accionable cuando fallan trials

    Un buen eval no solo marca FAIL; explica por qué. Ejemplo de salida útil:

    Trial 1: FAIL - Agent ran 'eslist --lint' (typo)  
Trial 2: PASS  
Trial 3: FAIL - Agent modified src/utils.js instead of src/main.js  
Trial 4: PASS  
Trial 5: PASS

    Con esa trazabilidad ajustas SKILL.md o scripts (p. ej., forzar paths absolutos, añadir checks previos, mejorar error handling en scripts).

    Recomendaciones finales y checklist rápido

    • Mantén SKILL.md corto y prescriptivo; externaliza lo frágil a scripts/.
    • Usa Docker para todos los evals que toquen filesystem o red.
    • Implementa graders deterministas como contrato (stdout JSON + exit codes).
    • Ejecuta >=5 trials; optimiza para pass^k en producción.
    • Integra evals en CI como Quality Gate.
    • Mantén dataset de pruebas realistas (repos con edge-cases), no solo ejemplos sintéticos.

    Testing Your AI Agent Skills no es opcional. Si confías en agentes para tocar código o infra, mide su comportamiento bajo condiciones reproductibles. Implementa evals hoy y transforma tus skills de “probablemente funcionan” a “sabemos que funcionan”.

    Como continuación lógica a estos procesos y para explorar integraciones y experimentos prácticos con evaluaciones de skills y pipelines de CI, visite Dominicode Labs. Allí encontrará recursos y ejemplos orientados a equipos de ingeniería que automatizan agentes y workflows.

    FAQ

    ¿Qué es un eval para una Skill?

    Un eval es una prueba autocontenida y reproducible que ejecuta una skill contra un grader determinista para verificar comportamiento objetivo (por ejemplo, lint pasa, tests verdes, tabla creada).

    ¿Cuántos trials debo ejecutar?

    Ejecuta al menos 5 trials para estimar estabilidad. Ese número proporciona una muestra mínima para analizar variabilidad en LLMs.

    ¿Por qué usar Docker en cada trial?

    Docker aísla el entorno, evita efectos laterales entre trials y garantiza reproducibilidad. Además permite destruir el contenedor tras la verificación.

    ¿Cómo debe devolver resultados un grader?

    Como código: exit codes y stdout estructurado (por ejemplo JSON). Evita evaluaciones subjetivas; usa herramientas como eslint o npm test.

    ¿Qué hacer si pass@k es alto pero pass^k es bajo?

    No desplegar. Señala que la skill es flaky; mejora el prompt, agrega verificaciones adicionales o externaliza pasos frágiles a scripts deterministas.

    ¿Qué umbral usar en producción?

    Para workflows críticos, fija umbral ≥ 90% en pass^k. Ajusta según riesgo y gravedad del fallo.

  • Mejorando consistencia y rendimiento con Vite 8.0 y Rolldown

    Mejorando consistencia y rendimiento con Vite 8.0 y Rolldown

    Vite 8.0: lo que duele, lo que mejora y por qué abrir un branch vite8

    Tiempo estimado de lectura: 6 min

    • Ideas clave:
    • Vite 8 unifica motores de build con Rolldown (Rust) para reducir discrepancias entre dev y producción.
    • Environment API estabilizada permite reproducir restricciones de runtime (Edge, Deno, Bun) en desarrollo.
    • Mejoras prácticas: builds más cortos, menos memoria en CI, caché persistente y resolución de módulos más estricta.
    • Hay cambios rompientes: Node 20+, APIs eliminadas y plugins de Rollup que pueden requerir adaptación.

    Introducción

    ¿Quieres que lo que funciona en tu máquina también funcione en producción… o prefieres seguir depurando en Deploy?

    Poca gente habla claro sobre lo que realmente cambia en Vite 8.0. Todos repiten “más rápido” y “mejor”, pero eso es la publicidad. Yo te voy a contar lo que duele, lo que mejora y por qué deberías abrir un branch llamado vite8 antes de que te pille en producción.

    Esto no es una nota de changelog. Es una narración corta donde los protagonistas son herramientas, bugs y tu equipo a las 3 AM.

    La historia empieza así: durante años, Vite usó dos motores. Esbuild para el dev, Rollup para producción. Dos mundos. Dos interpretaciones del mismo código. Dos “sorpresas” a las 11:59 en staging.

    Vite 8.0 corta esa dualidad. Trae a Rolldown: un bundler en Rust que quiere ser el motor único. Y, junto con él, una Environment API más seria y mejoras para Server Components. ¿Resultado? Menos diferencia entre lo que ves y lo que sale al mundo.

    Resumen rápido (lectores con prisa)

    Qué es: Vite 8 unifica el motor de build con Rolldown (Rust) y estabiliza una Environment API.

    Cuándo usarlo: al iniciar proyectos nuevos, en monorepos o si despliegas a entornos Edge.

    Por qué importa: reduce inconsistencias entre desarrollo y producción y mejora tiempos/memoria en CI.

    Cómo funciona: reemplaza la dualidad esbuild/Rollup por Rolldown y añade primitivas para simular entornos de runtime.

    Rolldown: no es solo “rápido”

    Rolldown es la apuesta más ambiciosa. Dime si no suena familiar: alguien crea algo rápido en dev, y otro motor hace magia en producción. Resultado: inconsistencias.

    Rolldown viene a unificar. Está escrito en Rust, que en este contexto significa velocidad y control de memoria. Pero la palabra importante no es “rápido”. Es “consistente”.

    Rolldown es el traductor que no se olvida de matices. Si antes tenías dos intérpretes (esbuild y Rollup) que a veces discrepaban, ahora tienes uno que habla para ambos escenarios.

    Qué ganas con Rolldown

    • Builds más cortos en CI. Sí, esa tarifa mensual de nube lo va a notar.
    • Menos memoria usada en pipelines. Menos procesos que se mueren por OOM.
    • Menos “funciona en mi equipo” y más “funciona en todos lados”.

    Un aviso: no todos los plugins de Rollup serán felices de inmediato. Algunos aún necesitan adaptarse. Si tu repo depende de plugins raros, prueba primero.

    Environment API: lo que te salva de los “works on my machine”

    Hoy una app puede vivir en Node, en un Edge, en Deno o en Bun. Cada runtime tiene sus reglas. Vite 8.0 estabiliza una Environment API que te permite desarrollar sabiendo exactamente en qué contexto vas a ejecutar.

    Eso significa que durante el desarrollo puedes simular las restricciones del entorno final. Si tu target es Cloudflare Workers, lo puedes reproducir localmente. De pronto, el “pero en local funciona” ya no es excusa.

    ¿Qué cambia en la práctica?

    • Bloqueos tempranos de APIs no compatibles.
    • Menos mocks improvisados.
    • Menos horas perdiendo tiempo por “faltaba este polyfill”.

    Server Components y SSR: el juego híbrido sube de categoría

    Los Server Components no son moda: son arquitectura. Vite 8.0 aporta primitivas más claras para RSC y SSR híbrido. ¿Qué significa? Mejores herramientas para frameworks que mezclan render en servidor y cliente sin meter ruido ni hacks.

    Si tu app es isomórfica (parte en server, parte en cliente), Vite 8 te da una base menos frágil para montar esa coreografía.

    Cosas que mejoran tus pipelines (sí, las que importan en dinero)

    No todo es hype técnico. Algunas mejoras se traducen directo en ahorro y en menos tiempo esperando en CI:

    • Pre-bundling optimizado: menos minutos de build, menos burnout del pipeline.
    • Caché persistente mejorada: si trabajas en monorepos o micro-frontends, HMR y recarga serán más fiables.
    • Resolución de módulos más estricta: fuerza a que el código sea más claro y previene importaciones ambiguas que explotan en producción.

    Los “breaking” que duelen y que debes planear

    Vite 8.0 no viene de visita. Viene a poner orden. Y eso implica romper cosas:

    • Node.js 20+ requerido. Si tu infra aún anda en Node 18 o 16, toca actualizar.
    • APIs antiguas eliminadas: configuraciones viejas en vite.config.js que funcionaban por “gracia” ahora fallan.
    • Cambios en el manejo de CSS asíncrono: menos FOUC, sí, pero puede requerir retoques en proyectos veteranos.
    • Plugins de Rollup: algunos necesitan actualización para funcionar con Rolldown.

    Si actualizas sin plan, te vas a topar con builds rotos y deploys empantanados. Si actualizas con plan, reduces tiempo y costos.

    Guía práctica de migración (hazlo en staging)

    No te doy una lista teórica. Haz esto:

    Pasos

    • Crea un branch vite8
    • Actualiza Node a 20 en tu CI y en tu entorno local (usa nvm o containers)
    • Actualiza Vite a 8.0 en package.json
    • Corre npm/yarn/pnpm install
    • Ejecuta los tests unitarios — corrige lo que rompa
    • Lanza el build en CI con caché limpio — observa memoria y tiempos
    • Revisa plugins: si alguno falla, busca alternativas o parchea
    • Test E2E en staging: presta atención a SSR y CSS
    • Repite hasta que el staging sea indistinguible de local

    Qué probar prioritario

    • End-to-End completo (navegación, login, SSR)
    • HMR en grandes cambios
    • Picos de concurrencia en staging (la memoria importa)
    • Integración con providers (Cloudflare, Deno Deploy, etc.)

    Cuándo y cuándo no deberías actualizar

    Actualiza ya si:

    • Estás iniciando un proyecto nuevo.
    • Tienes micro-frontends o monorepo.
    • Dependes de despliegues Edge o quieres reproducibilidad del entorno.

    Espera si:

    • Tienes plugins Rollup críticos sin mantenimiento.
    • Corres sobre infra legacy con Node antiguo y no puedes actualizar.
    • Tu ciclo de deploy es sensible y no puedes permitir riesgo sin staging.

    Metáforas porque te ayudan a decidir

    Piensa en tu build como un ensayo general antes del estreno. Antes, tenías dos directores de orquesta que interpretaban la partitura de forma distinta. Ahora tienes un único director (Rolldown). La banda suena más igual del ensayo al teatro. Menos desafines a mitad de obra.

    Rolldown es una navaja suiza… pero hecha con precisión alemana. No es todo trucos, es ingeniería.

    Riesgos reales y cómo mitigarlos

    • Plugins rotos: revisa la lista de dependencias que toquen rollup internamente. Busca forks o actualizaciones.
    • Dependencias nativas: algunos paquetes que usan internals de Node pueden fallar en entornos Edge. Usa la Environment API para detectarlo temprano.
    • Falta de pruebas E2E: si no tienes E2E, monta uno mínimo. Te va a ahorrar noches.

    Checklist rápido para Tech Leads (lo que debes exigir al equipo)

    • Branch vite8 con CI apuntando a Node 20.
    • Suite E2E que cubra SSR y CSS crítico.
    • Lista de plugins críticos y plan B (sustituir o parchear).
    • Métricas antes y después de build en CI (tiempo y memoria).
    • Fecha de congelación para rollback si algo va mal.

    Una nota que nadie te dirá gratis

    La adopción global de Rolldown no es instantánea. La comunidad tiene miles de paquetes; algunos cambiarán rápido, otros tardarán. Esto crea una ventana donde conviene probar, pero no empujar a producción sin staging. Dicho de otra forma: hay oportunidad para mejorar, y también hay riesgo operativo. El punto es medir, no apostar.

    ¿Y ahora qué hago?

    No te quedes en la charla. Haz algo práctico hoy:

    • Crea un branch llamado vite8.
    • Actualiza Node en tu CI a 20 y ejecuta un build.
    • Mide: tiempos de build, memoria y resultados E2E.
    • Si algo falla, abre issues en los repos de plugins y prioriza parches.

    Haz clic aquí: empieza un branch vite8 y corre el build. (Sí, esto es un CTA literal: abre tu repositorio y empieza la migración en staging.)

    Cierre — lo que queda por ver

    Vite 8.0 no es sólo sobre velocidad. Es sobre coherencia. Sobre dejar de confiar en “funciona en mi máquina” como mantra espiritual. Es la lucha por que desarrollo y producción hablen el mismo idioma.

    ¿Significa que todo se arregló? No. Significa que el terreno se niveló. El siguiente paso será ver cómo la comunidad actualiza plugins y adopta la Environment API para entornos Edge. Eso va a marcar la diferencia real en proyectos a gran escala.

    Esto no acaba aquí. Si migras y compartes métricas, la comunidad gana. Si detectas un plugin roto y lo documentas, le salvas la noche a otro equipo. Y si te quedas inmóvil, alguien más lo hará por ti y te tocará adoptar lo que ya sea estándar.

    ¿Quieres que te pase una checklist automática para tu repo? Respóndeme con “VITE8” y te mando un script de migración básico que puedes correr en 5 minutos. No prometo magia, pero sí menos berrinches en deploy.

    Fin… por ahora.

    FAQ

    ¿Qué es Rolldown y por qué importa?

    Rolldown es el bundler en Rust que Vite 8 introduce para unificar comportamiento entre desarrollo y producción. Importa porque reduce discrepancias fruto de usar motores diferentes (esbuild vs Rollup), mejorando consistencia, tiempos de build y uso de memoria.

    ¿Qué requiere mi infraestructura para actualizar a Vite 8.0?

    Requiere Node.js 20+ en CI y entornos locales. También revisar y posiblemente actualizar configuraciones antiguas en vite.config.js y validar plugins de Rollup.

    ¿Cómo prevengo que plugins de Rollup rompan mi build?

    Identifica plugins críticos, prueba en un branch vite8 en staging, busca forks o alternativas y prioriza parches antes de mover a producción.

    ¿Qué pruebas debo priorizar antes de desplegar?

    End-to-End completo (navegación, login, SSR), pruebas de HMR en cambios grandes, pruebas de concurrencia en staging y validación con providers como Cloudflare o Deno Deploy.

    ¿Por qué usar la Environment API?

    Porque permite simular las restricciones del runtime final (Edge, Deno, Bun, etc.) durante el desarrollo, evitando sorpresas por APIs no soportadas y reduciendo mocks improvisados.

    ¿Debo actualizar ahora si tengo un proyecto en producción estable?

    No necesariamente. Actualiza si puedes dedicar tiempo en staging y revisar plugins. Espera si dependes de plugins sin mantenimiento o de infra con Node antiguo.

  • Implementando Better Auth: Autenticación y autorización en TypeScript

    Implementando Better Auth: Autenticación y autorización en TypeScript

    Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript

    Tiempo estimado de lectura: 5 min

    Ideas clave

    • Better Auth es agnóstico al framework y está diseñado para TypeScript, con un núcleo minimalista extensible mediante plugins.
    • Se puede self-hostear y ofrece control total sobre datos, esquemas y tipado end‑to‑end.
    • Integración recomendada en Angular mediante servicio inyectable + HttpInterceptor; ejemplos y patrones operativos incluidos.
    • Casos de uso: B2B SaaS, cumplimiento (GDPR/HIPAA), integraciones con agentes/workflows como n8n.
    • Self‑hosting implica responsabilidades operativas: seguridad, observabilidad, backups y pruebas.

    Introducción

    Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript. Ofrece un conjunto completo de funciones listas para usar e incluye un ecosistema de plugins que simplifica la incorporación de funcionalidades avanzadas. Ya sea que necesite 2FA, clave de acceso, multiusuario, compatibilidad con múltiples sesiones o incluso funciones empresariales como SSO, crear su propio IDP le permite centrarse en desarrollar su aplicación en lugar de reinventar la rueda. Se puede utilizar con Angular.

    Better Auth exactamente cumple la promesa del enunciado: es un framework agnóstico para TypeScript pensado para que equipos construyan su propio Identity Provider (IDP) sin quedarse atados a un SaaS. En las primeras líneas: Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript. Ofrece un conjunto completo de funciones listas para usar e incluye un ecosistema de plugins que simplifica la incorporación de funcionalidades avanzadas. Ya sea que necesite 2FA, clave de acceso, multiusuario, compatibilidad con múltiples sesiones o incluso funciones empresariales como SSO, crear su propio IDP le permite centrarse en desarrollar su aplicación en lugar de reinventar la rueda. Se puede utilizar con Angular.

    Este artículo explica por qué importa, cómo se integra en Angular y qué criterios técnicos debes evaluar antes de adoptarlo.

    Resumen rápido (lectores con prisa)

    Better Auth es un framework TypeScript agnóstico para construir un IDP self‑hosted con plugins para SSO, 2FA y provisioning. Úsalo cuando necesites control de datos, tipado y extensibilidad; evita si necesitas lanzar un MVP sin infra. Integra en Angular con un servicio inyectable y un HttpInterceptor para gestionar tokens y refresh.

    Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript — arquitectura y ventajas

    Decisiones técnicas clave

    Better Auth se sostiene en dos decisiones técnicas clave:

    • Implementar la lógica sobre APIs web estándar (Request/Response), lo que permite ejecutarlo en Node, Bun, Deno o entornos Edge.
    • Diseñar un núcleo minimalista extensible mediante plugins, para evitar bloat y cargar solo lo que tu producto necesita.

    Qué trae de serie

    Qué trae de serie: email/password, 35+ proveedores OAuth, gestión de organizaciones (multi-tenant), sesiones múltiples, API keys, JWT, Magic Links y adaptadores para ORMs populares. Plugins oficiales cubren 2FA (TOTP), Passkeys/WebAuthn, SAML/OIDC para SSO y SCIM para provisioning.

    Ventaja práctica

    Ventaja práctica: control total de datos y schemas, tipado TypeScript end‑to‑end y la opción de self‑host sin vendor lock‑in. URL de referencia: better-auth.com

    Integración en Angular: patrón recomendado (servicio + interceptor)

    Para una app Angular enterprise, el patrón recomendable plantea un cliente agnóstico envuelto en un servicio inyectable y un HttpInterceptor para gestionar tokens/refresh.

    Ejemplo mínimo

    import { createAuthClient } from '@better-auth/client';
import { Injectable, signal } from '@angular/core';

const authClient = createAuthClient({ baseURL: '/api/auth' });

@Injectable({ providedIn: 'root' })
export class AuthService {
  public user = signal(null);

  async login(email: string, pass: string) {
    const { data, error } = await authClient.signIn.email({ email, password: pass });
    if (!error) this.user.set(data.user);
  }

  async logout() {
    await authClient.signOut();
    this.user.set(null);
  }
}

    Complementa con

    • HttpInterceptor que adjunte cookies o auth headers y maneje refresh tokens.
    • Guards/Resolvers para rutas protegidas.
    • Estado reactivo con Signals o RxJS para sincronizar UI.

    Casos de uso y adopción incremental

    Dónde aporta más valor

    • B2B SaaS con orgs, roles y SSO: evita el “SSO tax”.
    • Entornos con requisitos de cumplimiento (GDPR/HIPAA) que exigen soberanía de datos.
    • Plataformas que integran agentes o workflows (better-auth.com) y requieren control granular de tokens.

    Estrategia de incorporación

    1. Prototipa con un subdominio /auth y un DB separado.
    2. Migración gradual: dual‑write (nuevo sistema + migración batch) y pruebas canary.
    3. Mide: tiempo de login, tasa de errores, coste infra y reducción de vendor fees.

    Riesgos, operaciones y hardening

    Puntos críticos

    Self‑hosting devuelve responsabilidad al equipo. Puntos críticos:

    • Seguridad operativa: rotación de claves, gestión de secrets, WAF y rate limiting.
    • Tests y CI deterministas: flaky tests paralizan SSO/flows en producción.
    • Observabilidad: logs estructurados, métricas de sesiones, alertas por anomalías.
    • Backups y recovery para la DB de identidad.

    Recomendaciones prácticas

    • Least privilege para tokens de agente; scope limitado.
    • Auditoría obligatoria de cambios críticos (SSO config, SCIM).
    • Sandboxes para agentes que necesiten credenciales (no exponer prod keys).

    Comparativa rápida contra alternativas

    • Auth0 / Clerk (SaaS): rápido de arrancar, pero coste y lock‑in crecen con MAU y features empresariales.
    • Auth.js/NextAuth: buena para apps ligadas a frameworks, menos agnóstico.
    • Better Auth: mejor trade‑off para equipos TypeScript que quieren control, tipado y extensibilidad.

    Criterio final: cuándo optar por Better Auth

    Adopta Better Auth si:

    • Tu stack es TypeScript-centric y necesitas independencia de framework.
    • Buscas construir capacidades enterprise (SSO, SCIM) sin tarifas SaaS.
    • Tienes equipo capaz de gestionar seguridad infra y operaciones.

    No lo elijas si:

    • Tu prioridad es lanzar un MVP sin recursos infra (en cuyo caso un SaaS puede ser válido).
    • Tu infra actual no puede garantizar entornos deterministas y recuperación rápida.
    • Tu backend principal no es compatible con JS/TS y migrar es inviable.

    Better Auth no es la solución más simple, pero sí la más controlada para equipos que valoran soberanía, tipado y extensibilidad. Si tu objetivo es controlar la identidad (no cederla), empezar con npx auth init y una integración Angular mínima te dará una base sólida para escalar hacia SSO, 2FA y modelos multi‑tenant sin vender la llave del reino. Referencia: better-auth.com.

    Dominicode Labs

    Para equipos que trabajan con agentes, workflows o integraciones y buscan plantillas operativas y pruebas de concepto, puede ser útil revisar recursos y experimentos relacionados en Dominicode Labs. Estos recursos complementan prácticas de adopción incremental, testing y operación para infra de identidad.

    FAQ

    1. ¿Qué es Better Auth y para qué sirve?
    2. ¿Se puede usar Better Auth con Angular?
    3. ¿Qué funcionalidades trae por defecto?
    4. ¿Cuáles son los riesgos de self‑hosting?
    5. ¿Cuándo debería elegir un SaaS en lugar de Better Auth?
    6. ¿Cómo empezar una migración incremental?

    ¿Qué es Better Auth y para qué sirve?

    Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript, diseñado para construir un Identity Provider (IDP) self‑hosted con plugins para funcionalidades avanzadas como SSO, 2FA y SCIM.

    ¿Se puede usar Better Auth con Angular?

    Sí. El patrón recomendado para Angular es encapsular el cliente en un servicio inyectable y usar un HttpInterceptor para adjuntar credenciales y manejar refresh tokens.

    ¿Qué funcionalidades trae por defecto?

    Trae email/password, 35+ proveedores OAuth, gestión de organizaciones, sesiones múltiples, API keys, JWT, Magic Links y adaptadores para ORMs populares. Además hay plugins oficiales para 2FA (TOTP), Passkeys/WebAuthn, SAML/OIDC y SCIM.

    ¿Cuáles son los riesgos de self‑hosting?

    Self‑hosting implica responsabilidad operativa: rotación de claves, gestión de secrets, WAF, rate limiting, pruebas deterministas en CI, observabilidad y planes de backup y recovery.

    ¿Cuándo debería elegir un SaaS en lugar de Better Auth?

    Considera un SaaS si tu prioridad es lanzar un MVP rápidamente y no tienes capacidad operativa para gestionar infraestructura crítica de identidad. Un SaaS reduce la carga operativa pero introduce costes y posible vendor lock‑in.

    ¿Cómo empezar una migración incremental?

    Estrategia típica: prototipa en un subdominio /auth con DB separada, usa dual‑write y migraciones batch, ejecuta pruebas canary y mide métricas clave como tiempo de login, tasa de errores y coste infra.

  • La IA como herramienta clave para decisiones arquitectónicas en desarrollo

    La IA como herramienta clave para decisiones arquitectónicas en desarrollo

    ¿Y si tu trabajo como Tech Lead ya no fuera escribir el mejor código, sino asegurarte de que nadie convierta el repo en una bomba de relojería en 48 horas?

    Tiempo estimado de lectura: 7 min

    • Menos código, más decisiones: el valor del Tech Lead pasa de producir a decidir qué construir, cuándo no y qué riesgos aceptar.
    • Arquitectura y revisiones elevadas: prioriza límites, contratos y debates sobre deuda operacional más que debates de frameworks.
    • Mentoring práctico: enseña a los desarrolladores a formular problemas, cuestionar supuestos y validar soluciones generadas por IA.
    • Rituales y métricas: versiona prompts, exige tests y explicaciones para código generado por IA, y mide resiliencia (MTTR, incidentes, p95).
    • Políticas concretas: PRs cortos, prompts registrados, dependencias controladas y plantillas obligatorias para evitar desastres.

    Introducción

    La IA no vino a quitarte el puesto. Llegó a multiplicar la velocidad a la que los equipos pueden construir… y también a multiplicar la velocidad a la que pueden crear deuda técnica, fugas de seguridad y diseños idiotas. Eso convierte tu rol en algo más raro y más valioso: menos editor de líneas, más guardián del criterio.

    Esto no es teoría. Es la práctica que decidirá si tu sistema sobrevive al próximo trimestre.

    Menos código. Más decisiones.

    Resumen rápido (lectores con prisa)

    La IA acelera la entrega, pero también la creación de deuda y riesgos. Tu rol principal pasa de escribir código a definir límites, decidir prioridades y enseñar criterio. Versiona prompts, exige tests y explicaciones para código generado por IA, y mide resiliencia con métricas como MTTR y p95.

    Tres focos que te cambian el día a día

    1) Arquitectura como arte de supervivencia

    El microservicio bonito no es el que más se programa, sino el que menos dolores de cabeza da dentro de 18 meses.

    Tu trabajo: diseñar los límites que importan. Define contratos, SLAs, esquema de fallos, y lo que significa “sano” para cada servicio.

    No más debates de framework por correo. Más debates de: “¿Si esto falla, quién asume la deuda y por cuánto tiempo?”

    Regla simple: si la propuesta de IA añade más formas de fallar que formas de recuperar, no la implementas.

    2) Mentoring que enseña a pensar

    La IA da respuestas; no criterio.

    Tu equipo necesita aprender a:

    • formular el problema, no solo aceptar la solución,
    • cuestionar supuestos que el modelo da por sentado,
    • escribir tests que demuestren que la solución no es un placebo.

    Mentoring ahora es esto: enseñar a desarmar la respuesta de la IA pieza por pieza hasta que el desarrollador pueda explicarla sin leerla.

    3) Revisión de código elevada

    Antes revisabas estilo y pequeños bugs. Ahora revisas asunciones.

    Un PR generado con IA puede pasar tests y romper el sistema entero a nivel de arquitectura.

    Tienes que cambiar la revisión:

    • menos “cambia esto por esto”,
    • más “explica el porqué de esta elección, qué alternativas descartaste y qué métricas usarás para validar en producción”.

    Checklist rápido para revisar PRs (versión TL;DR)

    • ¿Rompe contratos o añade dependencias no justificadas? High flag.
    • ¿Introduce estado compartido o rompe idempotencia? High flag.
    • ¿Qué pasa si esto falla a escala? Simula el fallo.
    • ¿Qué pruebas nuevas agregas y por qué esas son suficientes?
    • ¿Quién lo mantiene si deja de generar Copilot?

    Herramientas, prompts y rituales prácticos

    No te pongas a improvisar con la IA. Versiona tus prompts como si fueran infra. Haz plantillas.

    Prompt para evaluación arquitectónica (cópialo y úsalo)

    “Eres un Staff Engineer con experiencia en sistemas distribuidos. Analiza este diff y responde: 1) ¿Qué supuestos operativos hace el cambio? 2) Tres maneras en que falla en producción y cómo detectarlo vía métricas/telemetría. 3) Recomendación concreta (aceptar/modificar/descartar) con pasos de mitigación.”

    Prompt para preparar 1:1 cuando un dev depende demasiado de la IA

    “Eres un Engineering Manager. Prepara un guion de 1:1 para un dev que copia soluciones sin verificarlas. Incluye: 1) apertura que no acuse, 2) 3 preguntas para diagnosticar la causa, 3) 2 tareas de aprendizaje y 2 métricas para evaluar progreso.”

    Prompt para mentoring en PR

    “Actúa como mentor senior. Redacta un comentario de code review empático explicando por qué esta implementación generada por IA es peligrosa, proponiendo alternativas y sugiriendo tests concretos (unit/integration).”

    No agrandes la mesa del pánico: limita contexto

    La IA olvida, alucina y pierde contexto en PRs enormes. Divide y vencerás.

    • PRs ≤ 400 líneas.
    • Commits atómicos por feature.
    • Plantilla en PR: “Qué hace, por qué, riesgos, métricas a monitorear”. Si falta, bloquea.

    Métricas que importan ahora

    Si antes medías commits y pull requests cerrados, ahora añade métricas que midan resiliencia:

    • Tiempo medio hasta rollback (MTTR): si sube, alarma.
    • Número de incidentes por cambio relacionado con “IA-generated” tag.
    • % de PRs que requieren rework por problemas arquitectónicos.
    • Latencia p95 y error budget tras despliegues con código asistido.

    Si no puedes medirlo, no lo decidas.

    Cómo estructurar la toma de decisiones (3 pasos prácticos)

    1. Definir el coste del error: ¿cuánto te cuesta que esto falle en 1 día? 1 semana? 1 mes?
    2. Establecer un PoC mínimo: no desplegar la solución completa; desplegar un camino de error controlado.
    3. Validar con datos: tests, telemetría, chaos experiment en entornos de staging.

    La paradoja: tu valor sube cuando escribes menos

    Es extraño, pero cierto. Escribir menos te obliga a pensar más. Y pensar bien vale mucho más que 100 commits brillantes que nadie mantiene.

    Tu agenda cambia:

    Tu agenda cambia

    • menos tareas técnicas punteadas,
    • más revisiones conceptuales y decisiones registradas,
    • más 1:1 donde la pregunta clave es “qué entendiste” y no “qué copiaste”.

    Cultura y reglas que evitarán el desastre

    • Confianza cero en código no verificado. Política: todo código generado con IA debe venir con tests y un párrafo que explique las asunciones. Sin esto, no se mergea.
    • Prompt registry: guarda los prompts usados para generar código en el repo. Si algo falla, puedes auditar la decisión.
    • Dependencias controladas: restringe librerías nuevas en ramas protegidas. No más “añadí una lib” sin un RFC mínimo.
    • Educación continua: sesiones semanales de “why this code sucks” donde un dev explica por qué una implementación es mala.

    Ejemplo real (rápido)

    El equipo usa Copilot y produce una función de caching distribuido. Pasa tests locales. En staging, ocasiona cache stampedes que multiplican las peticiones a la DB.

    Qué pasó: la IA generó una solución funcional sin contestar “qué pasa si la clave expira casi simultáneamente para muchas instancias”.

    Tu intervención: requeriste explicación, pediste test de concurrencia, propusiste locking optimista y un plan de rollout con feature flag y métricas (cache hit ratio, DB QPS). Resultado: ninguno de los despliegues rompe producción.

    Señales de que debes actuar ya

    • Los PRs llegan con pocos tests y mucha lógica compleja.
    • La rotación de bugs post-merge aumenta.
    • Los juniors no saben explicar por qué el código resuelve el problema.
    • Tu telemetría muestra p95 que sube inexplicablemente tras merges.

    Lo que tienes que hacer hoy (pequeños pasos, gran impacto)

    1. Crea la política “IA-first-checklist” y métela en el template del PR.
    2. Versiona 3 prompts (arquitectura, PR review, mentoring) y úsalos durante una semana.
    3. Mide: ¿cuántos PRs rechazados por faltas de explicación? ¿cuánto tiempo tardas en revisar en profundidad un PR?
    4. Haz 2 sesiones de “post-mortem” de fallos donde identifiques si la causa fue una confianza ciega en la IA.

    La última palabra: esto no acaba aquí

    La IA cambia la herramienta. No cambia el problema: construir sistemas sostenibles. Tu mérito como Tech Lead pasa a medirse en las decisiones que evitas, en los límites que pones y en la calidad del criterio que transmites.

    ¿Quieres el kit para empezar ahora?

    Di “QUIERO EL KIT” y te paso:

    • 10 prompts versionados para arquitectura, reviews y 1:1s.
    • Plantillas PR/PoC/RFC listas para tu repo.
    • Checklist de métricas y automatizaciones simples para integrar en CI.

    Esto no acaba aquí. Si me das tu stack y dos PRs reales (sin PII), te hago un diagnóstico rápido en 48 horas: riesgos, prompts exactos y plan de mitigación. ¿Lo hacemos?

    Dominicode Labs

    Si quieres explorar automatizaciones y workflows que integren estos controles, echa un vistazo a Dominicode Labs como una continuación práctica de estas ideas. Encontrarás plantillas y experimentos que puedes adaptar a tu stack de CI/CD y revisión.

    FAQ

    ¿Por qué cambiar mi rol de escribir código a tomar decisiones?

    Porque la IA acelera la producción de código y con ello los errores sistémicos. Tu ventaja competitiva será diseñar límites, gestionar riesgo y transmitir criterio al equipo.

    ¿Qué métricas debo priorizar primero?

    MTTR, número de incidentes relacionados con código generado por IA, % de PRs que requieren rework por temas arquitectónicos y latencia p95 tras despliegues. Si no puedes medir algo, evita tomar decisiones críticas basadas en ello.

    ¿Cómo obligo al equipo a versionar prompts?

    Hazlo parte del repositorio: exige que cualquier PR que use IA incluya el prompt exacto en el diff o un enlace al prompt versionado en el repo. Audita y revierte cuando falte.

    ¿Qué hacer si un PR generado por IA pasa tests pero preocupa por arquitectura?

    Bloquéalo hasta obtener la explicación de supuestos, alternativas descartadas y métricas de validación. Simula fallos a escala y exige un plan de mitigación antes de mergear.

    ¿Cuánto deben pesar los prompts en el proceso de revisión?

    Los prompts deben versionarse y revisarse como cualquier infraestructura: suficientes para reproducir la generación y auditar decisiones, pero no sustitutos de pruebas y explicaciones humanas.

    ¿Qué políticas rápidas puedo aplicar hoy?

    1) Plantilla PR que exija “qué hace, por qué, riesgos, métricas”. 2) Política “todo código IA debe incluir tests y un párrafo de suposiciones”. 3) Restricción de nuevas dependencias en ramas protegidas.

    ¿Cómo medir si la educación continua está funcionando?

    Mide reducción en PRs que requieren rework por problemas arquitectónicos, mejora en la calidad de explicaciones en 1:1s y capacidad de los devs para describir sin leer soluciones generadas por IA.