DOMINICODE

Category: Claude Code

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

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

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

    Tiempo estimado de lectura: 6 min

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

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

    Resumen rápido (lectores con prisa)

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

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

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

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

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

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

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

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

    Resumen rápido de cada harness

    Cursor — editor visual AI-first

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

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

    Claude Code — CLI para razonamiento extendido

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

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

    Aider — control Git como seguridad

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

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

    Cline — extensión VS Code con MCP

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

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

    Codex CLI / Copilot CLI — utilidades tácticas

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

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

    Criterios técnicos para elegir

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

    Ejemplos prácticos

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

    Recomendación práctica para equipos

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

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

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

    Recursos y lecturas

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

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

    FAQ

    ¿Qué es exactamente un agentic harness?

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

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

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

    ¿Claude Code reemplaza un CI tradicional?

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

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

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

    ¿Puedo usar Codex/Copilot CLI para refactorizaciones?

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

    ¿Cómo audito las acciones de un agente?

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

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

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

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

    Tiempo estimado de lectura: 4 min

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

    Resumen rápido (lectores con prisa)

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

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

    Requisitos mínimos

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

    Instalación rápida

    Instala la CLI de Claude Code y autentica:

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

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

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

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

    Contenido recomendado:

    Eres un Staff Engineer realizando una revisión de código.
Recibirás un `git diff`. Tu objetivo es identificar problemas críticos.

Reglas:
1. Ignora formato y estilo (linters ya hacen eso).
2. Busca: vulnerabilidades, condiciones de carrera, mutaciones de estado no controladas y complejidad innecesaria.
3. Si hay nueva lógica sin tests, marca "Missing Tests" como error crítico.
4. Responde en Markdown. Si todo está correcto, responde solo: "✅ Código limpio. Listo para PR."

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

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

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

    #!/bin/bash
DIFF=$(git diff main...HEAD -- ':!**/package-lock.json' ':!**/dist/**')

if [ -z "$DIFF" ]; then
  echo "No hay cambios para revisar."
  exit 0
fi

PROMPT=$(cat .claude-reviewer-prompt.md)

claude --print --prompt "$PROMPT

Aquí tienes el diff:
\`\`\`diff
$DIFF
\`\`\`"

    Notas:

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

    3. Variante: generador de tests por archivo

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

    #!/bin/bash
FILE_PATH=$1
if [ ! -f "$FILE_PATH" ]; then
  echo "Archivo no encontrado: $FILE_PATH"
  exit 1
fi

claude --print --prompt "Actúa como SDET especializado en TypeScript.
Genera tests unitarios con Jest para el siguiente archivo. Usa mocking donde aplique. Devuelve solo el código del test.

Archivo:
$(cat $FILE_PATH)" > "${FILE_PATH%.*}.test.ts"

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

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

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

    Ejemplo Husky (.husky/pre-push):

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

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

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

    5. Limitaciones y buenas prácticas

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

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

    Usa subagentes locales si:

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

    Evítalos cuando:

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

    Conclusión (y lo que sigue)

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

    Dominicode Labs

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

    FAQ

    ¿Qué es un subagente en este contexto?

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

    ¿Cómo protejo credenciales y datos sensibles?

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

    ¿Cuándo el subagente debe fallar un push?

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

    ¿Cómo controlo el coste de tokens?

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

    ¿Puedo usar otros modelos o proveedores?

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

    ¿Cómo versiono y audito prompts?

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

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

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

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

    Tiempo estimado de lectura: 6 min

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

    Introducción

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

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

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

    Resumen rápido (lectores con prisa)

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

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

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

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

    Guía paso a paso

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

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

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

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

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

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

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

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

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

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

    4) Usa a Claude como auditor: Red Teaming

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    8) Genera pruebas desde el principio

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

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

    9) Convierte la spec en artefactos machine-readable

    No dejes todo en texto. Pide:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    13) Historias reales (sin fantasías)

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

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

    14) Cuándo no usar Claude para esto

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

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

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

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

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

    – Título y objetivo en una frase.

    – Stack aprobado (y versiones).

    – Reglas arquitectónicas innegociables (3).

    – Interfaces/contratos principales.

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

    – Política de secretos.

    – Responsables y permisos de cambio.

    Hazlo ahora. No mañana.

    16) Metáfora que pega y no falla

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

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

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

    CTA: hazlo en 60 minutos

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

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

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

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

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

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

    FAQ

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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

  • Errores comunes al adoptar Claude Code en equipos de desarrollo

    Errores comunes al adoptar Claude Code en equipos de desarrollo

    Errores comunes al adoptar Claude Code en un equipo

    Tiempo estimado de lectura: 4 min

    • Onboarding: enseñar la herramienta no es suficiente; hay que enseñar el paradigma de agentes autónomos.
    • Spec-First: ejecutar cambios sin especificaciones claras genera deuda y decisiones inventadas por el agente.
    • Costes y contexto: control de iteraciones, .claudeignore y límites para evitar facturas y pérdida de foco.
    • Guardrails operativos: PR gating, auditoría y human-in-the-loop previenen cambios destructivos.

    Los primeros días de uso no muestran los verdaderos errores comunes al adoptar Claude Code en un equipo. Aparecen cuando el agente empieza a operar a escala: facturas inesperadas, PRs que compilan pero rompen la arquitectura, y bucles que consumen tokens hasta que alguien corta la ejecución. Si vas a introducir Claude Code en tu flujo, entiende esto desde la primera semana.

    Claude Code no es un autocompletador: es un agente de terminal. Lee archivos, ejecuta comandos y modifica el repositorio. Esa autonomía multiplica la productividad—y los riesgos—si no impones disciplina.

    Resumen rápido (lectores con prisa)

    Claude Code es un agente autónomo que puede leer, ejecutar y modificar un repositorio. Úsalo cuando tengas specs claros y boundaries operativos. Controla contexto y costes; automatiza tareas repetitivas, pero requiere revisión humana para cambios de arquitectura y acciones destructivas.

    Errores comunes al adoptar Claude Code en un equipo: lecciones aprendidas

    1) Onboarding enfocado en la herramienta y no en el paradigma

    Error: enseñar “cómo instalar la CLI” y asumir que el equipo sabe usar un agente autónomo. Resultado: uso ineficiente o delegación total.

    Solución práctica:

    • Onboarder por paradigma: sesiones que enseñen “qué preguntar”, “qué no delegar” y cómo interpretar salidas de la IA.
    • Política obligatoria: cualquier PR generado por Claude pasa por revisión humana con checklist (seguridad, tests, dependencias).
    • Define tareas delegables: por ejemplo, generación de tests unitarios a partir de interfaces, refactorizaciones pequeñas bajo spec, o scaffolding de componentes que ya respetan convenciones.

    Referencia útil: documentación de Claude Code en Anthropic

    2) Lanzar prompts sin specs (Spec-First)

    Error: pedir “implementa autenticación” en la raíz del repo. El agente inventa ORM, mezcla infra y dominio, y produce deuda.

    Solución práctica:

    • Escribe specs antes de ejecutar la CLI: feature-auth.md que incluya interfaces TypeScript, endpoints, casos de error, y tests esperados.
    • Invocación por referencia: claude "Implementa lo descrito en feature-auth.md; respeta interfaces y pruebas".
    • Mantén un CONVENTIONS.md o .claude/instructions.md con reglas de estilo, librerías permitidas y antipatrones a evitar.

    Esto convierte al agente en un ejecutor de decisiones, no en un arquitecto improvisado.

    3) Ignorar costos y permitir bucles infinitos

    Error: ejecutar Claude en la raíz de un monorepo o dejar que itere tests sin límite. Token-cost + ejecuciones = facturas altas y uso indiscriminado.

    Solución práctica:

    • .claudeignore es obligatorio (igual que .gitignore). Ejemplo:
    node_modules/
.next/
dist/
*.sqlite
logs/
package-lock.json
    • Imponer límites en el prompt: "Si los tests no pasan después de 3 intentos, detén la ejecución y reporta errores con stack traces".
    • Monitorización y alertas: trackea consumo de tokens y costes con dashboards; define budgets por equipo y bloquea continuaciones si se supera el umbral.

    4) Saturar la ventana de contexto (Lost in the Middle)

    Error: dar al agente el repo entero para “entender el proyecto”. El modelo pierde foco—más contexto = peor señal en el medio. Documentado en Lost in the Middle.

    Solución práctica:

    • Contexto quirúrgico: navega al directorio relevante antes de invocar la CLI. Alimenta al agente con fragmentos semánticos (interfaces, esquema DB, tests relacionados), no con 50 controladores.
    • Usa grafos de dependencia o resúmenes (README de módulo, esquema ER, list of public APIs) para que el agente comprenda impacto sin leer todo el código.
    • Divide tareas grandes en sesiones pequeñas y contractuales con outputs claros entre ellas.

    Controles operativos y guardrails que funcionan

    • PR gating: cualquier cambio propuesto por Claude debe pasar por pipeline CI que incluya lint, tests y políticas SCA (software composition analysis).
    • Auditoría: almacenar hashes del contexto inyectado y logs de comandos ejecutados para auditoría forense.
    • Human-in-the-loop para acciones destructivas: merges automáticos solo si cambios son triviales (docs, comentarios). Para código, siempre revisión humana.
    • Backstop de seguridad: sanitiza PII antes de permitir lectura por el agente.

    Conclusión breve y accionable

    Claude Code acelera trabajos repetitivos y eleva la productividad, pero no sustituye la disciplina de ingeniería. La herramienta amplifica lo que ya existe: si tu arquitectura es modular y tienes specs y tests, el agente te hará avanzar más rápido. Si tu repo es un monolito sin reglas, el agente producirá deuda técnica en modo turbo.

    Implementa Spec-First, controla el contexto que das, limita iteraciones y monitoriza costes. Si sigues esos principios, convertirás a Claude Code en un multiplicador de valor en vez de un generador de problemas.

    Para equipos que diseñan workflows y guardrails para agentes, recursos prácticos y experimentos están disponibles en Dominicode Labs. Estos materiales complementan políticas de PR gating, auditoría y límites de coste descritos arriba, sirviendo como punto de partida para pruebas internas.

    FAQ

    Respuesta: Enseñar la CLI cubre cómo ejecutar la herramienta, pero no enseña el paradigma de agentes autónomos: qué delegar, cómo formular prompts seguros y cómo interpretar acciones que modifican el repo. Sin ese contexto, el equipo tiende a delegar decisiones arquitectónicas a la IA o a usarla de forma ineficiente.

    Respuesta: Spec-First es la práctica de definir interfaces, endpoints, casos de error y tests antes de ejecutar el agente. Se aplica mediante documentos como feature-auth.md y convención de invocación que referencia ese spec; así el agente ejecuta decisiones ya tomadas, no inventa arquitectura.

    Respuesta: Impone límites en el prompt (por ejemplo, máximo 3 intentos de test), usa .claudeignore para reducir el volumen de datos procesados y monitoriza consumo de tokens con dashboards y budgets por equipo. Bloquea continuaciones automáticas si se supera el umbral.

    Respuesta: .claudeignore funciona como .gitignore para el agente: evita enviar al modelo directorios pesados o irrelevantes (node_modules, dist, logs, etc.), reduciendo costes y ruido en la señal.

    Respuesta: Proporciona contexto quirúrgico: archivos relevantes (interfaces, esquema DB, tests relacionados), resúmenes de módulo y grafos de dependencia. Divide tareas grandes en sesiones pequeñas para evitar que el agente lea un monolito entero.

    Respuesta: Siempre que el cambio afecte arquitectura, dependencias críticas, seguridad o datos sensibles, debe haber revisión humana. Merges automáticos pueden permitirse solo para cambios triviales como documentación o comentarios.

  • Agentic Coding: Automatizando el Ciclo de Desarrollo con IA

    Agentic Coding: Automatizando el Ciclo de Desarrollo con IA

    Qué es el Agentic coding?

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Agentic coding es un paradigma donde un agente de IA recibe un objetivo de alto nivel y ejecuta el ciclo completo de implementación.
    • Combina planificación, uso de herramientas y un bucle de retroalimentación que incluye tests y correcciones iterativas.
    • Funciona bien para scaffolding, pruebas y tareas repetitivas; requiere documentación, TDD y revisión humana para evitar riesgos.

     

    Qué es el Agentic coding? Es el paradigma en el que un agente de IA recibe un objetivo de alto nivel y ejecuta el ciclo completo de implementación: planifica subtareas, escribe y modifica archivos, ejecuta tests y se autocorrige hasta cumplir el criterio de éxito. No es autocompletar: es automatizar el flujo de trabajo de desarrollo con bucles de razonamiento y acción.

    Resumen rápido (lectores con prisa)

    Agentic coding transforma LLMs en agentes que planifican, usan herramientas (editar archivos, ejecutar comandos, llamar APIs) y se corrigen mediante un bucle de feedback con tests. Es útil para scaffolding, pruebas y tareas repetitivas, pero requiere documentación, TDD y revisión humana por riesgos de seguridad, coherencia y alucinaciones.

    Qué es el Agentic coding? — definición y componentes técnicos

    Técnicamente, un sistema agéntico combina tres capacidades:

    • Planificación: el modelo descompone una tarea compleja en pasos ejecutables antes de tocar código.
    • Uso de herramientas (tool use): el agente puede leer/editar archivos, ejecutar comandos en la terminal, abrir el navegador o llamar APIs externas.
    • Bucle de retroalimentación (feedback loop): ejecuta tests o builds, analiza fallos (stack traces) y corrige el código iterativamente.

    Esa combinación transforma al LLM de generador de texto en un motor de ejecución: piensa, actúa, verifica, corrige. Ejemplo real: pedir “añade rate limiting al endpoint /api/auth y crea tests unitarios” y recibir, tras múltiples ejecuciones, un PR con código que pasa el pipeline de CI (o al menos repite intentos hasta que los tests locales pasan).

    Herramientas y ecosistema (URLs)

    Las herramientas que ya incorporan capacidades agénticas o facilitan su adopción son relevantes para entender el estado práctico del Agentic coding:

    Estas herramientas muestran dos enfoques: editores/CLI que actúan dentro del flujo de desarrollo, y orquestadores que integran agentes en pipelines y automatizaciones.

    Limitaciones prácticas y riesgos técnicos

    El Agentic coding funciona, pero con condiciones. No es una panacea.

    1. Context window y coherencia arquitectónica

    Los agentes pierden visión global en repositorios grandes. La ventana de contexto de los LLMs mejora, pero no sustituye el conocimiento arquitectónico humano. Técnicas como RAG (retrieval-augmented generation) ayudan a indexar documentación, pero no garantizan decisiones coherentes a nivel sistema.

    2. Seguridad y dependencias

    Un agente optimiza la entrega de la tarea, no la seguridad. Puede introducir dependencias vulnerables o atajos que rompen principios de Clean Architecture. La revisión humana sigue siendo obligatoria antes del merge.

    3. Alucinaciones técnicas

    Los modelos pueden generar llamadas a APIs inexistentes o usar firmas obsoletas. Sin ejecución automática de tests y análisis estático, esas alucinaciones pasan desapercibidas.

    4. Escalabilidad y mantenimiento

    Generar cambios rápidos aumenta la deuda técnica si no se adoptan reglas de estilo, ADRs o documentación que orienten al agente.

    Buenas prácticas para adoptar Agentic coding

    Si vas a integrar agentes en tu flujo, aplica estas reglas mínimas:

    • Documenta el contexto: RULES.md, guías de estilo y ADRs reducen ambigüedad y guían las decisiones del agente.
    • Adopta TDD como protocolo de interacción: escribir tests primero ofrece un criterio de éxito claro para el agente y reduce la supervisión humana.
    • Modula y desacopla: los agentes funcionan mejor en componentes pequeños; refactoriza monolitos antes de delegar tareas significativas.
    • Pipelines de CI como árbitro: ejecuta builds y análisis estático automáticamente en cada PR generado por un agente.
    • Revisión humana con checklist: seguridad, licencias de dependencias y arquitectura deben validarse manualmente antes del merge.

    Cuándo usar y cuándo no usar agentes

    Usa agentes para:

    • Scaffolding y generación de pruebas.
    • Refactorizaciones locales y tareas repetitivas.
    • Automatizar revisiones preliminares de PRs o generar PRs iniciales para revisión humana.

    Evítalos en:

    • Decisiones arquitectónicas críticas.
    • Código con requisitos regulatorios o de seguridad estrictos.
    • Repositorios legacy masivos sin documentación ni tests.

    Conclusión

    Qué es el Agentic coding? Es la evolución de la IA desde asistente pasivo a actor autónomo en el ciclo de desarrollo. Ofrece un multiplicador de productividad si se integra con disciplina: documentación explícita, tests como contrato de aceptación, CI robusto y revisión humana en los puntos críticos. Mal usado acelera la deuda técnica; bien usado multiplica la capacidad del equipo.

    Si exploras integración de agentes, pipelines y automatización en equipos de ingeniería, puede resultar útil revisar recursos y experimentos prácticos. Una continuación lógica para equipos interesados en estos temas es Dominicode Labs, que agrupa proyectos y guías sobre automatización e IA aplicada en flujos de desarrollo.

     

    FAQ

     

    Respuesta: Agentic coding implica que el agente planifique, ejecute cambios en archivos, ejecute tests y se autocorrija mediante bucles de feedback. Un autocompletador solo sugiere fragmentos de texto o código sin ejecutar ni verificar el resultado.

    Respuesta: Planificación de tareas, capacidad de usar herramientas (editar archivos, ejecutar comandos, llamar APIs) y un bucle de retroalimentación con tests o builds son los componentes esenciales.

    Respuesta: Riesgos clave: pérdida de coherencia arquitectónica en repositorios grandes, introducción de dependencias inseguras, alucinaciones técnicas y aumento de deuda si no hay reglas y documentación.

    Respuesta: Documenta contexto y reglas (RULES.md, ADRs), añade tests y adopta TDD, modula componentes y habilita pipelines de CI para validar PRs generados por agentes.

    Respuesta: No. La revisión humana sigue siendo obligatoria para validar seguridad, licencias y decisiones arquitectónicas críticas antes del merge.

    Respuesta: Practicas que ayudan: adoptar TDD, ejecutar tests y análisis estático en CI automáticamente, usar RAG para documentar contexto y contar con reglas y ADRs que guíen al agente.

  • Implementando IA Generativa con Claude Code en la Terminal

    Implementando IA Generativa con Claude Code en la Terminal

    IA generativo con Claude Code: programación agéntica en la terminal

    “Tiempo estimado de lectura: 4 min”

    • Claude Code lleva modelos de razonamiento y acción al flujo CLI: inspecciona repos, ejecuta tests y realiza commits.
    • Es potente para refactorizaciones a gran escala, debugging iterativo y automatización de commits/PRs, pero peligroso en repos sin tests o infra crítica.
    • Requiere entornos aislados, confirmaciones humanas para cambios sensibles y límites de consumo de tokens.

    Poca gente lo dice en voz alta: esto no es un plugin más. Hacer IA generativo con Claude Code cambia quién escribe código y quién aprueba los cambios. El agente vive en la terminal, lee tu repo, ejecuta tests y puede hacer commits. No te sugiere; actúa.

    Resumen rápido (lectores con prisa)

    Claude Code es un agente CLI que opera sobre tu repo: indexa código, planea cambios, ejecuta tests y aplica parches. Úsalo para refactorizaciones, debugging iterativo y automatización de PRs —pero solo en entornos aislados con buena cobertura de tests. Es una capa operativa para pipelines CLI y se integra con flujos de CI/CD y herramientas como n8n.

    ¿Qué es IA generativo con Claude Code y cómo funciona?

    IA generativo con Claude Code significa llevar el modelo Claude al flujo de trabajo CLI. En lugar de pedir snippets en una ventana de chat, le pides al agente que opere sobre tu código: inspeccione archivos, ejecute npm test o pytest, lea el stack trace y vuelva a intentar hasta que los tests pasen o se quede sin opciones.

    Arquitectura mínima del flujo

    • Percepción: indexa la base de código, deps y el historial de Git.
    • Razonamiento: traza un plan de cambios (planificando antes de editar).
    • Acción: modifica archivos, corre builds y tests.
    • Iteración: revisa errores, corrige y repite.

    Anthropic documenta Claude Code como una interfaz para operar Claude desde la terminal (Anthropic – Claude Code). El modelo base en estas capacidades es Claude 3.7 Sonnet, pensado para razonamiento extendido y ciclos iterativos.

    ¿Dónde aporta valor real —y dónde no?

    Dónde aporta

    • Refactorizaciones a gran escala: cambiar patrones en cientos de archivos, mantener imports y tests coherentes.
    • Debugging iterativo: ejecutar el código, capturar logs, proponer y aplicar parches.
    • Automatización de commits y PRs: descripciones técnicas generadas a partir de los cambios reales, no de lo que tú crees haber cambiado.
    • Integración en pipelines y flujos n8n: ideal cuando quieres validar artefactos en CI sin intervención manual.

    Dónde falla o es peligroso

    • Bases de código legacy sin tests: el agente puede producir código que compila pero rompe reglas de negocio.
    • Sistemas con secretos o infraestructura crítica: permitir ejecuciones en máquinas no aisladas es un riesgo real.
    • Presupuesto: cada lectura de archivos y cada iteración consume tokens de API. Un loop largo se nota en la factura.

    Si tu repo tiene buena cobertura de tests y puedes aislar el entorno (Docker), la relación riesgo/recompensa inclina hacia el sí.

    Claude Code vs Copilot vs Cursor: una decisión técnica

    No hablo de marcas por postureo. Comparo por arquitectura:

    • GitHub Copilot: autocompletado en el editor. Útil para micro-productividad.
    • Cursor / Windsurf: IA integrada en IDE; buena experiencia GUI.
    • Claude Code: agente autónomo en CLI; pensado para acciones completas sobre el repo.

    El criterio no es “me gusta más”. Es: ¿quieres que la IA sujete el martillo o que haga todo el trabajo de carpintería? Si tu flujo es terminal-first (Neovim, tmux) y tus tareas necesitan ejecución y verificación real, Claude Code encaja mejor. Si prefieres trabajar con una GUI y autocompletados, Copilot o Cursor siguen siendo la opción.

    Riesgos técnicos y cómo mitigarlos

    No seas el que apaga las alarmas cuando la factura llega o cuando un despliegue hace “pop”.

    Medidas prácticas

    • Siempre ejecutar agentes en entornos aislados (contenedores, runners de CI) — nunca con acceso directo a producción.
    • Forzar confirmaciones humanas en cambios críticos y desactivar commits automáticos si el repo contiene secretos.
    • Monitorizar consumo de tokens y establecer límites por proyecto para evitar facturas sorpresa.
    • Mantener cobertura de tests mínima antes de delegar refactorizaciones al agente.

    Estas son medidas técnicas, no buenas prácticas bonitas para slides.

    Qué cambia en la cultura de ingeniería

    Esto no reemplaza ingenieros; los hace mejores —o los deja obsoletos. El valor real pasa de escribir código repetitivo a:

    • definir límites del dominio,
    • orquestar agentes,
    • auditar cambios con criterio técnico.

    El rol del Tech Lead se parece menos a “pedir features” y más a “vigilar la caja negra que genera features”. El que entiende cuándo parar al agente y cómo leer su output gana tiempo real y reduce errores.

    Claude Code está aquí para quedarse como capa operativa en pipelines CLI. Dominarlo es, hoy, tan relevante como dominar Git hace una década.

    Próxima entrega

    En la próxima entrega veremos ejemplos prácticos: un flujo de refactorización en React controlado por Claude Code, con comandos, límites de tokens y checklist de seguridad para no romper producción. Esto no acaba aquí.

    Si quieres profundizar en flujos de agentes, automatización y validación en CI, considera explorar Dominicode Labs como espacio para experimentos y guías prácticas. Es una continuación lógica para trabajar protocolos, checklists y plantillas de seguridad antes de desplegar agentes en proyectos reales.

    FAQ

    Respuesta: Claude Code es un agente CLI que opera directamente sobre el repositorio: indexa archivos, planifica cambios, ejecuta tests y puede aplicar commits. A diferencia de un chat, no se limita a sugerir snippets: actúa en el repo y puede iterar hasta que las pruebas pasen o se agote su plan.

    Respuesta: Permitir commits automáticos puede ser útil en workflows controlados, pero es recomendable desactivarlo si el repo contiene secretos o recursos críticos. Forzar confirmaciones humanas en cambios sensibles es la práctica prudente.

    Respuesta: Es ideal para refactorizaciones a gran escala, arreglar regresiones detectadas por tests y tareas que requieran ejecutar el código (logs, builds, tests). Es menos seguro en código legacy sin cobertura de tests o en dominios donde las reglas de negocio no están codificadas en pruebas.

    Respuesta: Establece límites de tokens por proyecto, monitoriza el consumo y ejecuta agentes en entornos donde puedas controlar la granularidad de las iteraciones. Considera estrategias de cache y segmentación de tareas para reducir lecturas innecesarias del repo.

    Respuesta: Exige una cobertura mínima de tests automatizados que verifiquen las reglas de negocio críticas. Además, usa ambientes aislados (Docker/CI) y revisiones humanas para cambios de alto impacto.

    Respuesta: Claude Code está pensado para flujos terminal-first y pipelines CLI, pero puede integrarse en flujos más visuales mediante orquestación. Si prefieres autocompletados en el IDE, herramientas como Copilot o Cursor ofrecen mejor experiencia GUI.
  • Cómo evitar la amnesia del agente en Claude Code entre sesiones

    Cómo evitar la amnesia del agente en Claude Code entre sesiones

    Cómo evitar la amnesia del agente entre sesiones con Claude Code

    Tiempo estimado de lectura: 5 min

    Ideas clave

    • Externalizar el estado del agente al repositorio (archivos versionados) para persistencia entre sesiones.
    • Usar un archivo TASK_STATE.md como fuente de verdad y exigir su lectura al iniciar cada sesión.
    • Dividir el trabajo por módulos y actualizar TASK_STATE.md antes de cada commit para evitar pérdida de contexto.
    • Mantener ventanas de contexto pequeñas cargando sólo archivos relevantes del módulo más TASK_STATE.md.
    • Medir retoma y reducción de rework para validar la efectividad del sistema.

    Tabla de contenidos

    Introducción

    Saber exactamente cómo evitar la amnesia del agente entre sesiones es lo que separa las automatizaciones frágiles de las que realmente escalan. Si cierras una terminal con Claude Code a mitad de tarea, la siguiente sesión no recordará decisiones, bugs ni el alcance ya cubierto. Esa falta de persistencia —junto a la contaminación de contexto dentro de sesiones largas— exige una solución estructural: externalizar el estado del agente en el repositorio.

    Resumen rápido (lectores con prisa)

    Externaliza el estado del agente en archivos versionados (ej. TASK_STATE.md). Lee TASK_STATE.md al iniciar cada sesión y actualízalo antes de cada commit. Divide el trabajo por módulos para mantener la ventana de contexto pequeña y evitar contaminación. Usa commits atómicos y especifica tareas en /tasks para handoffs confiables.

    Cómo evitar la amnesia del agente entre sesiones: sistema de tareas en disco

    La estrategia que funciona en entornos productivos es simple y técnica: tratar el árbol de archivos como la memoria persistente del agente. En vez de confiar en la memoria efímera de la sesión, haces que Claude escriba su estado, incidencias y decisiones en archivos versionados antes de cada commit. Al abrir una nueva sesión, el agente lee ese archivo y retoma exactamente donde quedó.

    Referencias útiles: la documentación de Claude Code y la página de Claude explican las capacidades de ejecución y acceso a repositorio que hacen esto posible.

    Componentes del sistema de estado

    • TASK_STATE.md — memoria de trabajo (temporal, versionada)
    • /tasks/*.md — specs atómicas por tarea (entradas para subagentes)
    • CLAUDE.md — contrato del proyecto (stack, convenciones, patrones prohibidos)

    Estructura mínima recomendada

    /CLAUDE.md
/TASK_STATE.md
/tasks/
  auth-migration.md
  billing-refactor.md

    Ejemplo práctico: TASK_STATE.md (plantilla)

    ## Estado actual
- Tarea: Migración AuthService → AuthV2
- Fase: 2/4
- Último commit: a3f92c1

## Módulos completados
- [x] UserModel
- [x] AuthService
- [ ] AuthController

## Bugs identificados
- UserService.getById no valida usuarios inactivos (línea 47)
- Token refresh: edge-case con cambio de email

## Notas de diseño
- Mantener compatibilidad token-legacy 30 días
- No migrar OAuth hasta fase 3

    Prompt de recuperación (instrucción inicial)

    Al iniciar una nueva sesión, la primera instrucción debe ser innegociable:

    Lee TASK_STATE.md antes de ejecutar cualquier acción. Retoma desde la fase indicada y no repitas trabajo ya marcado como completado.

    Ese prompt convierte el archivo en la “fuente de verdad” para el agente.

    Cómo evita esto la contaminación de contexto

    La contaminación ocurre cuando una sesión larga excede la ventana de tokens y el modelo comienza a “olvidar” detalles previos. La solución práctica es dividir la tarea en sesiones acotadas por módulo:

    • Cada sesión se centra en un módulo concreto.
    • Solo se cargan en contexto los archivos del módulo, las firmas de interfaces adyacentes y TASK_STATE.md.
    • Los bugs se registran inmediatamente en TASK_STATE.md antes de pasar al siguiente módulo.

    Así mantienes la ventana de contexto pequeña y relevante, y cualquier hallazgo se persiste en disco aunque el modelo lo “olvide” en memoria volátil.

    Flujo operativo recomendado (paso a paso)

    1. Preparación: crea CLAUDE.md y una spec por tarea en /tasks.
    2. Inicio: abre sesión y ejecuta prompt de recuperación para leer TASK_STATE.md.
    3. Trabajo por módulo: el agente modifica archivos permitidos, añade tests y actualiza TASK_STATE.md antes del commit.
    4. Commit atómico: cada checkpoint importante tiene commit con mensaje estructurado.
    5. Handoff: si otro desarrollador o sesión retoma, lee TASK_STATE.md y continúa.
    6. Cierre: cuando la tarea se completa, merge y eliminación de TASK_STATE.md.

    Regla clave: actualizar TASK_STATE.md antes de cada commit. Si la terminal cae, el estado queda preservado hasta el último punto sincronizado.

    Decisiones de cuándo aplicar esto

    Implementa este sistema cuando:

    • La tarea requiere múltiples sesiones o días.
    • Debes auditar y modificar más de 5–6 archivos interconectados.
    • Necesitas handoffs confiables entre sesiones o personas.

    No lo uses para cambios triviales que se completan en una sesión corta; el overhead no compensa.

    Medir si funciona

    Indicadores prácticos:

    • Tiempo medio de retoma (desde abrir sesión hasta reanudar trabajo) < 5 minutos.
    • % de tareas que requieren rework por amnesia o contexto < 5%.
    • Reducción en reverts por decisiones olvidadas.
    • Número de bugs registrados en TASK_STATE.md vs. bugs no documentados detectados tras merge (debe bajar).

    Límites y advertencias

    Esto no convierte a Claude en un “ingeniero permanente”. Externalizar estado aumenta resiliencia, pero no suple la necesidad de especificaciones claras. Si la spec es ambigua, el agente persistirá ambigüedades más rápido. Tampoco es sustituto de revisiones humanas en handoffs críticos (auth, infra, contratos externos).

    Dominicode Labs

    Para equipos que aplican automatización y agentes en flujos de trabajo, una continuación natural es explorar prácticas y experimentos en Dominicode Labs. Allí se documentan plantillas y patrones aplicables a sistemas de estado basados en repositorio.

    FAQ

    ¿Qué es TASK_STATE.md y para qué sirve?

    TASK_STATE.md es un archivo versionado que actúa como memoria de trabajo del agente: registra el estado de la tarea, módulos completados, bugs y notas de diseño. Sirve como fuente de verdad para retomar trabajo entre sesiones.

    ¿Cómo se usa TASK_STATE.md al inicio de una sesión?

    La primera instrucción al iniciar una sesión debe ser leer TASK_STATE.md antes de ejecutar cualquier acción. El agente debe retomar desde la fase indicada y evitar repetir trabajo ya marcado como completado.

    ¿Qué información debe contener TASK_STATE.md?

    Debe incluir estado actual (tarea, fase, último commit), módulos completados, bugs identificados y notas de diseño relevantes. El ejemplo en el artículo muestra una plantilla con secciones claras para cada aspecto.

    ¿Por qué dividir el trabajo por módulos?

    Dividir por módulos mantiene la ventana de contexto pequeña y relevante, reduce la contaminación de contexto y facilita la persistencia de hallazgos en disco aunque el agente pierda memoria en la sesión.

    ¿Cuándo no es apropiado este sistema?

    No es apropiado para cambios triviales que se completan en una sola sesión; el overhead de mantener TASK_STATE.md y specs por tarea puede no compensar en esos casos.

    ¿Qué hacer si la spec es ambigua?

    Externalizar ambigüedades amplifica problemas: el agente persistirá decisiones ambiguas. La medida correcta es clarificar la spec durante el proceso y registrar las decisiones en TASK_STATE.md, además de mantener revisiones humanas en handoffs críticos.

  • Automatización de la Revisión de Código con IA en 2026

    Automatización de la Revisión de Código con IA en 2026

    Revisión de código con IA y validación automatizada de especificaciones (2026)

    Tiempo estimado de lectura: 4 min

    • Automatizar validaciones contra especificaciones convierte las specs en guardrails operativos, no en mera documentación.
    • Pipeline agentico: inyección de contexto (RAG), validación determinista en entornos aislados y bucle agentico con autocorrección controlada.
    • Riesgos reales: especificaciones ausentes/contradictorias, sesgo de automatización, límites de contexto y responsabilidades legales.
    • Checklist operativo para Tech Leads: versionar OpenAPI/ADRs, cobertura de tests, modularidad y políticas de autocorrección.

    La revisión de código con IA y validación automatizada de especificaciones (2026) ya no es un experimento: es una capa que muchos equipos productivos están integrando en sus pipelines. Escribir código dejó de ser el cuello de botella; ahora lo es verificar que ese código cumpla contratos, reglas de negocio y decisiones arquitectónicas. Este artículo explica cómo funciona hoy la automatización, qué riesgos reales merece tu atención y qué pasos prácticos debe ejecutar un Tech Lead antes de activar agentes en CI.

    Resumen rápido (lectores con prisa)

    La automatización combina RAG para extraer contexto del repo, entornos efímeros para ejecutar tests y validaciones deterministas contra OpenAPI/AsyncAPI. Se puede permitir autocorrección en cambios triviales y bloquear cambios de diseño para revisión humana. Requiere especificaciones versionadas, cobertura de tests y modularidad.

    Revisión de código con IA y validación automatizada de especificaciones: cómo funciona hoy

    El salto respecto a herramientas tradicionales (SonarQube, Semgrep) es que los agentes modernos cruzan el diff del PR con documentación estructurada y ejecutan validaciones deterministas:

    • Capturan contexto del repositorio (ADRs, OpenAPI, tests y convenciones).
    • Vectorizan y recuperan fragmentos relevantes vía RAG (retrieval‑augmented generation).
    • Levantan entornos efímeros para ejecutar tests y comprobar contratos OpenAPI/AsyncAPI.
    • Pueden proponer o aplicar parches automáticos y re‑ejecutar la suite antes de notificar al revisor humano.

    Herramientas y referencias relevantes

    El resultado: PRs más rápidos, menos fricción y menos errores de contrato que escapan a producción —siempre que el sistema esté bien montado.

    Arquitectura práctica: pipeline agentico y validación de especificaciones

    Implementarlo con seguridad implica estructurar el pipeline en tres bloques:

    1. Inyección de contexto (RAG para repositorios)

    • Indexa ADRs, OpenAPI, README, tests y convenciones del repo en un vector store (p. ej. Pinecone).
    • Cuando abre un PR, extrae el contexto específico del área afectada para construir prompts y reglas de validación.

    2. Validación determinista en entorno aislado

    • Levanta un contenedor efímero con la rama del PR.
    • Ejecuta tests unitarios, contract tests (Specmatic/Optic) y llamadas end‑to‑end contra la API.
    • Compara respuestas reales con la especificación OpenAPI versionada.

    3. Agentic loop (autocorrección controlada)

    • Si hay desviaciones menores (tipos, campos faltantes), el agente genera un parche y abre un commit automático.
    • Re‑ejecuta tests; si todo pasa, marca la verificación como “verde” y agrega una nota en el PR.
    • Las acciones que implican diseño (breaking changes, cambios semánticos) quedan bloqueadas para revisión humana.

    Este flujo convierte la spec en guardrail operativo, no en mera documentación.

    Límites reales y riesgos que no puedes ignorar

    • Especificaciones inexistentes o contradictorias: la IA solo puede validar lo que está formalizado. En Brownfield, primero escribe specs consumibles por máquinas.
    • Ventana de contexto: los modelos actuales pierden precisión al razonar sobre cambios transversales en monolitos enormes; la modularidad importa.
    • Automation bias: equipos que confían ciegamente en un “check verde” aceleran fallos operativos. El humano sigue siendo responsable.
    • Seguridad y liability: un agente puede aprobar un PR que introduce vulnerabilidad lógica; la responsabilidad legal recae en la organización.

    Checklist operativo para Tech Leads antes de activar agentes

    1. Mantén OpenAPI/AsyncAPI actualizados y versionados en el repo (source of truth).
    2. Versiona ADRs junto al código y define reglas claras en CONVENTIONS.md o .repo_rules.
    3. Asegura cobertura de tests: unitarios, contract tests (Specmatic/Optic) y un set mínimo de E2E para paths críticos.
    4. Modulariza dominios (DDD, bounded contexts) para acotar la precisión del agente.
    5. Implementa un entorno de staging efímero en CI donde el agente pueda ejecutar validaciones reales.
    6. Define políticas claras de autocorrección: qué puede commitear automáticamente y qué queda bloqueado.
    7. Añade auditoría y logging: cada parche automático debe tener trazabilidad y motivación textual.

    Cómo medir si te funciona

    Métricas accionables:

    • Reducción del tiempo medio de revisión (MTTR para PRs).
    • Porcentaje de PRs con fallos de contrato detectados en CI vs. en producción.
    • Número de commits automáticos revertidos por humanos (indicador de sobre‑autonomía).
    • Tiempo que el equipo destina a revisiones de criterio vs. a correcciones triviales.

    Conclusión técnica

    La revisión de código con IA y validación automatizada de especificaciones en 2026 es una palanca real: acelera ciclos y reduce errores de contrato si y solo si la organización invierte antes en especificación, tests y modularidad. Sin ese trabajo previo, la IA añade ruido y riesgo. Haz la inversión estructural primero; luego deja que los agentes hagan lo repetible. Así, tus ingenieros podrán dedicar su juicio a lo que realmente importa: arquitectura, impacto en el negocio y diseño de largo plazo.

    Para equipos que exploran flujos de automatización y agentes dentro de pipelines, una continuación natural de este trabajo es revisar proyectos y experimentos en Dominicode Labs, donde se documentan plantillas y patrones aplicables a pipelines agenticos.

    FAQ

    ¿Qué tipo de especificaciones debo versionar en el repo?

    Versiona OpenAPI/AsyncAPI como source of truth y mantén ADRs alineados con el código. Estas especificaciones deben ser consumibles por máquinas y estar en la misma rama o en rutas versionadas del repo.

    ¿Qué puede commitear automáticamente un agente?

    Cambios triviales y deterministas: correcciones de tipos, campos faltantes obvios o parches que no alteren la semántica. Las políticas deben definir límites claros: breaking changes y decisiones de diseño requieren revisión humana.

    ¿Cómo evito el automation bias en el equipo?

    Establece métricas de calidad, revisiones periódicas de commits automáticos revertidos y responsabilidades claras. Mantén a los revisores enfocados en criterio y diseño, no en correcciones triviales.

    ¿Qué pruebas son imprescindibles antes de activar agentes en CI?

    Cobertura de tests unitarios, contract tests (Specmatic/Optic) y un set mínimo de E2E para paths críticos. Además, entornos de staging efímeros donde el agente pueda ejecutar validaciones reales.

    ¿Cómo audito los parches automáticos?

    Registra trazabilidad y motivación textual para cada parche, conserva commits con mensajes generados por el agente y almacena logs completos de ejecución en un sistema de auditoría accesible al equipo de seguridad y arquitectura.

    ¿Qué límites de contexto tienen los modelos actuales?

    Los modelos pierden precisión en cambios transversales dentro de monolitos enormes debido a la ventana de contexto. La modularidad y bounded contexts reducen este problema y mejoran la precisión del agente.

  • Implementa Plum para Mejorar la Trazabilidad en tus Commits

    Implementa Plum para Mejorar la Trazabilidad en tus Commits

    ¿Te da pánico pensar que la IA pueda llenar tu repo de código que nadie entiende? Bienvenido a la nueva crisis del software.

    Tiempo estimado de lectura: 5 min

    • La velocidad de generación de código por IA supera la capacidad humana de registrar intención.
    • Plum captura decisiones en el momento del commit para mantener spec, tests y código sincronizados.
    • Sin checkpoints canónicos (hooks de Git) la intención se evapora y se pierde propiedad intelectual.

    Introducción

    Poca gente lo dice claro: ahora la IA escribe más rápido de lo que podemos entender. Y velocidad sin intención es solo ruido estructural.

    This is her code. This is what she was managing. This is her VS code. Margaret Hamilton tenía la plomada mental de la arquitectura. Hoy tenemos agentes que empiezan a escribir habitaciones enteras sin planos. ¿Quién firma eso cuando se cae el techo?

    Resumen rápido (lectores con prisa)

    Plum captura y versiona decisiones (humanas y de agentes) en el momento del commit mediante hooks de Git; obliga a validar intenciones y sincroniza spec ↔ tests ↔ código. Es un checkpoint canónico para trazabilidad y responsabilidad.

    ¿Qué hace Plum en una frase?

    Captura decisiones (humano + agente) en el momento del commit, te pide que las valides, las convierte en artefactos versionables y sincroniza spec ↔ tests ↔ código.

    ¿Por qué no puede ser simplemente “una skill” dentro del agente?

    Porque una skill es una sugerencia. Una sugerencia se ignora cuando el plazo aprieta. Necesitamos un checkpoint canónico que no puedas saltar: un hook de Git que detenga el commit hasta que la intención quede registrada. Eso es lo que hace Plum.

    Cómo se ve en la práctica (sin tecnicismos aburridos)

    • Instalas Plum.
    • Ejecutas plum init en la raíz del repo.
    • Plum crea una carpeta .plum, un .plumignore y agrega hooks a Git.
    • Haces cambios usando un agente.
    • Intentas git commit.
    • Plum analiza diffs + traces del agente.
    • Si hay decisiones detectadas, el commit falla hasta que las apruebes, edites o rechaces.
    • Si apruebas, Plum actualiza la spec (Markdown) y genera un registro en JSONL con la decisión, quién la aprobó, branch, timestamps y si el LLM sugirió o el humano decidió.

    Ventajas prácticas que notarás rápido

    • Un agente ya no “olvida” reglas que le dijiste hace semanas. El agente puede consultar el árbol de decisiones antes de actuar.
    • Cuando alguien pregunta “¿por qué esto está así?”, la respuesta no es “creo que lo discutimos en Slack”. Es un enlace a la decisión y su justificación.
    • El code review pasa de revisar sintaxis a revisar intención. Eso reduce regresiones silenciosas.

    Limitaciones honestas (sí, las tiene)

    • Hoy Plum enlaza pruebas vía Pytest. Si tu pipeline usa otro runner, la cobertura spec→tests no funcionará todavía.
    • Identificar decisiones no es perfecto. La deduplicación es fuzzy y repo-específica. Hay parámetros que ajustar.
    • Reversión automática al rechazar decisiones aún no es robusta. Si rechazaste una decisión en la CLI, el rollback con el agente es un flujo que requiere trabajo fino.
    • En proyectos extremadamente grandes sin spec previa (legacy), Plum no hace magia: necesita spec por delante para funcionar bien. Backfilling masivo aún está en la hoja de ruta.

    Diseños críticos que no puedes ignorar

    • Debe ser externa al LLM. Si la gobernanza vive dentro del agente, la gente la ignorará.
    • Debe fallar commits. Sin ese checkpoint, es teoría bonita y nadie la respeta.
    • Usa DSPy u otro framework para estructurar LLM calls cuando sea absolutamente necesario. Pero siempre que puedas, valida con código determinista: la verificación debe ser programable, repetible y testeable.
    • La experiencia humana importa. Si cada hotfix genera 5 decisiones triviales, la herramienta se vuelve molesta. Debe existir un umbral de interrupción configurable. Tú decides: banca cero tolerancia para banca; modo “dangerously approve all” para experimentos.

    Casos reales, concretos

    • PM cambia la regla de comisiones a las 3am. El agente aplica el hotfix. Plum detecta 3 decisiones: cambio de fórmula, invalidación de cache, ajuste de test. Te las muestra. Apruebas. Plum actualiza el spec y enlaza el test que cubre la nueva regla. Un auditor te lo agradece en el futuro.
    • Fix urgente en prod. Actúas rápido. Plum puede configurarse para no interrumpir decisiones triviales en ramas específicas. O puedes exigir aprobación humana para cambios en main o en módulos críticos.
    • Refactor mayor. Plum obliga a agrupar decisiones y a shardar la spec. El árbol de decisiones te ayuda a no romper invariantes.

    Checklist para empezar hoy (sin dramas)

    1. Poner spec en Markdown y versionarla. Sí, en el repo.
    2. Tener tests automatizados. Si usas Python: Pytest. Si no, prepara el adapter.
    3. pip install plum-dev
    4. plum init (apunta a tu carpeta de specs y al directorio de tests)
    5. Añade .plumignore para excluir archivos ruidosos
    6. Configura tolerancias: qué decisiones bloquean commit y cuáles no
    7. Empieza con una rama pequeña y haz dogfooding: úsenlo para gestionar el proyecto que desarrolla Plum. Si no duele, no funciona.

    Comportamientos que salvarán tu empresa (si los adoptas)

    • Nunca permitas que un cambio de negocio se quede solo en Slack.
    • No confíes en mensajes de commit como única fuente de intención.
    • Exige artefactos: decisión aprobada, spec actualizada, test que falla sin la decisión.

    Metáfora rápida porque las metáforas funcionan

    Tu repo es un edificio. Los agentes son obreros hiperactivos con taladros. Si no tienes planos actualizados y un inspector que firme cada cambio, terminarás con un edificio que parece Frankenstein. Plum es la plomada. No construye paredes. Te dice si las paredes están verticales.

    Lo práctico, ahora mismo

    • Sí, puedes pip install plum-dev y jugar en una rama de feature.
    • Sí, puedes ajustar el umbral para que no te moleste en hotfixes.
    • No, no es todavía plug-and-play para proyectos legacy gigantes.
    • Sí, si usas agentes en producción sin registrar decisiones, estás acelerando una deuda técnica que alguien pagará caro.

    ¿Quieres el template JSONL + flujo de PR listo para copiar en tu repo? Respóndeme este mensaje y te lo envío.
    Quieres algo más directo: pip install plum-dev, plum init, haz un commit con un agente y verás cómo el commit falla hasta que registras la intención. Prueba en una rama de sandbox.

    No es sexy. Es aburrido. Y es exactamente lo que separa equipos que escalan de equipos que heredarán un desastre técnico eterno.

    Dominicode Labs

    Si trabajas con automatización, agentes o workflows y quieres seguir explorando prácticas de gobernanza y trazabilidad, revisa Dominicode Labs como continuación lógica de estas ideas. Encontrarás recursos y experimentos sobre integración de agentes y control de intención.

    FAQ

    ¿Qué es Plum?

    Plum es una herramienta que captura decisiones (humanas y de agentes) en el momento del commit mediante hooks de Git, convierte esas decisiones en artefactos versionables y sincroniza spec, tests y código para mantener trazabilidad.

    ¿Por qué necesito un hook de Git para registrar decisiones?

    Porque un hook crea un checkpoint canónico que no se puede saltar: obliga a registrar intención antes de completar el commit. Sin ese mecanismo la gobernanza se vuelve opcional y se pierde trazabilidad.

    ¿Cómo integra Plum spec y tests?

    Plum analiza diffs y traces de agente, propone cambios en la spec (Markdown) y genera enlaces entre requisitos atómicos, tests y commits. Además crea un registro JSONL con las decisiones para auditoría.

    ¿Qué pasa en hotfixes de emergencia?

    Plum puede configurarse para reducir la interrupción en ramas específicas o para exigir aprobación humana en ramas críticas como main. También puedes ajustar umbrales para decisiones que no bloqueen el commit.

    ¿Funciona con pipelines que no usan Pytest?

    Hoy Plum enlaza pruebas vía Pytest por defecto. Si tu runner es otro, necesitarás un adapter: la cobertura spec→tests no funcionará hasta que exista soporte para tu runner.

    ¿Cómo evita Plum el ruido en cambios triviales?

    Plum usa un .plumignore para excluir archivos ruidosos y tiene parámetros configurables que definen umbrales de interrupción para que no genere decisiones por cada cambio menor.

    ¿Dónde están los registros de decisiones?

    Plum genera un archivo JSONL con entradas que incluyen la decisión, quién la aprobó, branch, timestamps y si fue sugerida por LLM o aprobada por humano. Es un fichero indexable y enlazable a PRs.

  • Cómo garantizar gobernanza en especificaciones y código usando Plum

    Cómo garantizar gobernanza en especificaciones y código usando Plum

    ¿Y si te dijera que tu “spec perfecta” es solo un espejismo que te está dejando con más ruina que beneficio?

    Tiempo estimado de lectura: 7 min

    • Ideas clave:
    • Specs y tests no capturan intención; la implementación revela decisiones que deben registrarse.
    • Sin trazabilidad y gobernanza, la velocidad con agentes de IA genera deuda técnica no asignable.
    • Convierte decisiones efímeras en artefactos auditables: captura, exige aprobación humana y sincroniza spec↔tests↔código.

    Introducción

    Poca gente habla claro de esto: en el mundo real, sometimes specs and tests aren’t sufficient. Y cuando metes agentes de IA en la ecuación, la ilusión se convierte en problema de verdad. No es opinable. Es práctico. Y te va a doler si no te preparas.

    La promesa era bonita. Escribe la especificación, lanza unos tests, suelta un agente, y voilà: código. Suena como un truco de magia barato. Pero la magia no limpia deudas técnicas. La magia solo las acelera.

    Resumen rápido (lectores con prisa)

    Qué es: Capturar decisiones técnicas efímeras como artefactos auditable (spec, tests y registro de decisiones).

    Cuándo usarlo: Siempre que agentes de IA o cambios rápidos modifiquen comportamiento crítico.

    Por qué importa: Sin trazabilidad las decisiones quedan en chats y commits huérfanos; eso genera deuda técnica no atribuible.

    Cómo funciona (resumido): Leer diffs, extraer decisiones, pedir aprobación humana y actualizar spec/tests con registro.

    Por qué las specs y los tests fallan

    Un código que pasa todos los tests puede ser un desastre elegante. Puede consumir memoria, colapsar bajo concurrencia o romper la invariant que nadie documentó.

    Los tests —por sí solos— no capturan intención. Capturan salida. Y la intención es lo que de verdad se rompe cuando un Product Manager cambia una regla a las tres de la madrugada.

    Tests vs intención

    Recuerda a Margaret Hamilton con su pila de papeles y cinta adhesiva. Ella no estaba haciendo “scripts”; estaba diseñando resiliencia. Llevaba la arquitectura en la cabeza porque no había alternativa. Hoy no se trata de memoria humana: se trata de contexto. Y los LLMs lo tienen fragmentado.

    Escribir el código no es el paso final. Es la lupa que revela lo que la spec olvidó. Implémentalo y la spec te devolverá correcciones. No al revés. Ese es el flujo honesto que muchos olvidan.

    Implementación y decisiones

    Speedrun histórico: estamos reinventando problemas ya resueltos. La comunidad de IA está “speedrunneando” la historia del software: volver a tropezar con acoplamientos, incoherencias, dependencias ocultas. Cuando ni tú ni la IA pueden sostener la visión completa, lo que obtienes no es progreso: es ruido estructural.

    Esto no es una discusión teórica. Mira los proyectos que intentan ejecutar Python en Rust. Tests completos. Especificaciones martilladas. Y aún así—hilos de 20 comentarios sobre cómo debería comportarse una función. ¿Por qué? Porque el comportamiento observado y el comportamiento deseado no siempre coinciden en el mundo real. La implementación revela las zonas grises. Y las zonas grises necesitan decisiones, no conjeturas.

    Decisión = intención registrada. Si una IA sugiere “arreglar X así” y nadie lo documenta, ¿quién responde cuando eso explota? Sin trazabilidad, la autoría desaparece. Los commits quedan huérfanos. Las decisiones quedan atrapadas en chats. Eso es un cáncer técnico que se expande silencioso.

    Necesitas convertir intención en artefacto. No más “lo arreglé en local”. No más “lo discutimos en Slack”. Necesitas un registro auditable: qué se decidió, por qué, quién lo aprobó, y en qué rama quedó.

    Plum y trazabilidad

    Ahí entra Plum. No porque sea mágico, sino porque cumple una tarea concreta: transforma decisiones efímeras en evidencia material. Lee diffs. Escanea traces. Extrae decisiones. Te pregunta “¿lo apruebas?”.

    Si dices que sí, actualiza la spec y genera un registro .jsonl con la decisión, la autoría y la traza. Es la plomada para tu triángulo spec ↔ tests ↔ código.

    No es la única forma, pero la idea es la idea:

    • captura las decisiones,
    • exige aprobación humana,
    • sincroniza spec y tests,
    • y audita la intención.

    Práctico: cómo empezar sin reinventar la rueda

    1. Escribe la spec como contrato, no como aspiración. Si falta un caso límite, añádelo. Si no se puede automatizar, hazlo explícito.
    2. Invierte en tests que describan intención, no solo outputs. Los property tests y las invariantes sistémicas son el equivalente a los checks de seguridad en un avión.
    3. Captura los traces del agente. Que estén en el repo. Que no vivan solo en la ventana del chat.
    4. Extrae decisiones en cada commit. Pide aprobación humana antes de actualizar la spec.
    5. Bloquea merges si la spec—tests—código no están sincronizados. Sí: pon reglas duras en CI.

    Si tu respuesta inmediata es “nuestra organización no hará eso”, entonces ya perdiste. La opción no es hacerlo o no hacerlo. Es hacerlo hoy o pagar por horas de desastre mañana.

    Modularidad extrema, o el arte de no romper todo con una línea

    Si un agente necesita entender 50 archivos para cambiar una feature, tu arquitectura es culpable. Divide, desacopla, define boundaries estrictas. Interfaces claras. Contratos pequeños y firmes. Haz que los cambios sean locales y verificables. Así los agentes tienen probabilidades reales de acertar.

    Limitaciones de los LLMs

    No te engañes: los LLMs son herramientas brutales. También son miopes por diseño: ventana de contexto, sesgo de prompt, falta de visión de producto. Los modelos pueden sugerir refactors; no pueden entender roadmaps ni retener trade-offs históricos. La validación humana no es ornamental. Es esencial.

    Valor actual: tests y especificaciones vivas

    El valor actual ya no está en la sintaxis. Está en la suite de tests. En las especificaciones vivas. En los artefactos de decisión. El código se deja atrás. Los tests y las especificaciones sobrevivirán a generaciones de actores.

    Un ejemplo real —y sencillo

    Imagina que tu PM cambia la regla de cálculo de una comisión. Un ingeniero empuja el hotfix, el test unitario pasa. ¿Y el resto?

    • ¿Se actualizaron las pruebas de integración?
    • ¿Las reglas de caching se siguen cumpliendo?
    • ¿Se respetan las invariantes fiscales?

    Si la respuesta es “no lo sé”, fallaste en gobernanza. Si la respuesta es “sí, lo sabemos y está registrado”, ganaste.

    Cultura + Herramienta = Supervivencia

    No puedes automatizar cultura. Pero puedes diseñarla. Exige que cada decisión relevante tenga un artefacto. Añade a tu pipeline la obligatoriedad de reconciliar spec↔tests↔código antes del merge.

    Esto suena duro. Lo es. Pero sin esas reglas, el “move fast” vuelve rápidamente a ser “move fast and break everything—and then no one knows why”.

    ¿Quieres algo fácil de ejecutar ahora?

    Instala plum-dev en una rama pequeña. Apunta Plum a tu carpeta de specs y a tu suite de tests. Ejecuta un par de commits con agentes. Observa cómo las decisiones dejan de evaporarse en chat. Si no puedes hacerlo hoy, al menos empieza a exigir que cada PR documente la decisión que justifica el cambio.

    No se trata de quitar velocidad. Se trata de mantenerla con control. Agentes que generan código a la velocidad de la luz + procesos que no controlan la intención = desorden a escala.

    FAQ

     

     

    Respuesta: ¿Qué hace Plum y por qué es relevante?

    Plum transforma decisiones efímeras en evidencia material: lee diffs, escanea traces, extrae decisiones y solicita aprobación humana para actualizar specs y generar registros .jsonl con decisión, autoría y traza.

    Respuesta: ¿Por qué registrar decisiones en vez de confiar en commits y chats?

    Porque los commits y chats no proporcionan trazabilidad estructurada: la autoría se pierde, las decisiones quedan huérfanas y no hay un artefacto auditable que explique el porqué de un cambio.

     

    Respuesta: ¿Cómo se integra esto en CI sin frenar al equipo?

    Implementando reglas de bloqueo en CI que exijan sincronía spec—tests—código y aprobaciones humanas para cambios relevantes. Esto añade pasos obligatorios, no burocracia: evita horas futuras de investigación y corrección.

    Respuesta: ¿Qué tipo de tests son prioritarios?

    Tests que describan intención: property tests, pruebas de integración e invariantes sistémicas. Prioriza pruebas que validen contratos y comportamientos críticos, no solo outputs unitarios.

    Respuesta: ¿Cómo evito que los agentes provoquen ruido estructural?

    Diseña arquitectura modular con boundaries claros, interfaces pequeñas y cambios locales verificables. Captura traces y decisiones en el repo y exige aprobación humana antes de aplicar cambios en specs.

    Respuesta: ¿Qué límites tienen los agentes y los LLMs?

    Son herramientas con ventana de contexto y sesgos de prompt; no retienen trade-offs históricos ni entienden roadmaps. Pueden sugerir refactors, pero requieren validación humana para decisiones estratégicas.