DOMINICODE

Tag: Claude Code

  • Recursos prácticos para aprender Spec-Driven Development

    Recursos prácticos para aprender Spec-Driven Development

    Listado de recursos para aprender SDD en castellano

    Tiempo estimado de lectura: 4 min

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

     

    Introducción

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

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

    Resumen rápido (lectores con prisa)

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

    Listado de recursos para aprender SDD en castellano

    SDD — Spec-Driven Development (libro)

    SDD — Spec-Driven Development

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

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

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

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

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

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

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

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

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

    Paso 1

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

    Paso 2

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

    Paso 3

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

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

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

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

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

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

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

    Limitaciones y siguientes pasos

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

    Conclusión

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

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

     

    FAQ

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

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

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

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

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

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

  • Aprende a convertirte en AI Engineer en 2026

    Aprende a convertirte en AI Engineer en 2026

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

    Tiempo estimado de lectura: 3 min

    Ideas clave

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

    Introducción

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

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

    Resumen rápido (lectores con prisa)

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

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

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

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

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

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

    1) Prompt Engineering estructurado — De texto a contrato

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

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

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

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

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

    4) LLMOps y Evaluaciones — Operar lo no determinista

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

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

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

    1. SDKs oficiales

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

    2. Backend

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

    3. Vector DB inicial

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

    4. Orquestación y workflows

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

    5. Observabilidad

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

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

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

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

    Prioridad de aprendizaje (3 pasos rápidos)

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

    Conclusión

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

    Dominicode Labs

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

    FAQ

    ¿Qué es Prompt Engineering estructurado?

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

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

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

    ¿Por qué usar pgvector para RAG?

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

    ¿Qué incluye LLMOps en producción?

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

    ¿Qué stack priorizar si trabajo en TypeScript?

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

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

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

  • Implementación del Agentic Harness para Agentes Autónomos

    Implementación del Agentic Harness para Agentes Autónomos

    Qué es el Agentic Harness y cómo aplicarlo?

    Tiempo estimado de lectura: 5 min

    • Idea clave: Un Agentic Harness es la infraestructura que transforma agentes autónomos experimentales en software operable y seguro.
    • Idea clave: Sus componentes mínimos: sandboxing, mocking de herramientas, trazabilidad y guardrails automatizados.
    • Idea clave: Integrarlo en CI/CD y usar un LLM-judge reduce riesgos antes de dar acceso a producción.

    El Agentic Harness es la infraestructura que convierte agents autónomos experimentales en piezas de software operables y seguras. Si un agente entra en producción sin un harness, no es cuestión de “si” fallará: es cuestión de “cuándo” y con qué coste. Entender qué es el Agentic Harness y cómo aplicarlo es obligado para Tech Leads y equipos que despliegan agentes que actúan sobre sistemas reales.

    Los LLM son probabilísticos. Un agente no devuelve solo un output: planifica, encadena herramientas y decide. Un Agentic Harness controla ese actor: lo aísla, lo simula, lo rastrea y lo limita antes de darle acceso al mundo real.

    Resumen rápido (lectores con prisa)

    Agentic Harness: infraestructura que aísla, simula y limita agentes que razonan. Úsalo siempre que un agente pueda modificar sistemas reales o acceder a datos sensibles. Importa porque reduce riesgos operativos y legales. Funciona combinando sandboxing, mocks, trazabilidad y guardrails automatizados.

    Qué es el Agentic Harness y cómo aplicarlo en la práctica

    Un Agentic Harness hereda la idea del test harness tradicional y la adapta a agentes que razonan. Su objetivo no es solo verificar resultados; es auditar trayectorias de ejecución, interceptar efectos secundarios y bloquear comportamientos peligrosos. Sus componentes mínimos son:

    1) Diseño del sandbox

    • Ejecuta cada run del agente en un contenedor efímero o microVM sin acceso de salida (egress blocked).
    • Monta datasets de prueba y mocks en el filesystem; destruye el entorno al terminar.
    • No expongas secretos ni claves reales: usa vaults de test que devuelvan credenciales ficticias.

    Referencias: Docker, Firecracker.

    2) Mocking y simulación de tools

    • Intercepta function-calls y reemplázalas por mocks que:
      • Regresen respuestas realistas.
      • Generen métricas: latencia simulada, tasa de errores, costes.
      • Registren parámetros y contexto.
    • Ejemplo: delete_user(user_id) devuelve {status: "mocked", user_id} y queda registrado en trazas.

    Referencia: OpenAI Function Calling docs.

    3) Trazabilidad de la trayectoria (traces)

    • Registra: prompts, respuestas intermedias, herramientas invocadas, embeddings consultados, scores de retrieval.
    • Guarda trazas en un formato navegable (JSONL) y con versión del modelo.
    • Integra una capa de observabilidad para análisis post-mortem: Langfuse u otros servicios de tracing. También se puede integrar con herramientas como LangChain/observability.

    4) Guardrails cuantitativos y evaluadores automáticos

    • Umbrales automáticos que abortan la ejecución:
      • Límite de tokens por run (ej. 50k tokens).
      • Límite de coste por evaluación.
      • Número máximo de llamadas a herramientas (ej. 10).
    • Métricas de seguridad: intentos de acceso a APIs prohibidas, intentos de exfiltración.
    • LLM-as-a-Judge: usa un segundo modelo con temperature=0 para revisar la coherencia y seguridad de la trayectoria (evaluación estructurada: PASS/WARN/FAIL).

    5) Integración en CI/CD

    • Cada PR que incluya cambios en agentes debe disparar pipelines del harness.
    • No permitir merge si el harness devuelve FAIL en criterios críticos (seguridad, uso de herramientas prohibidas, loops).
    • Generar reportes legibles: timeline de decisiones, evidencia de mocks, recomendación humana para escalado.

    Ejemplo real (simplificado)

    Objetivo: “Optimizar consultas SQL lentas”.

    • Sin harness: el agente propone eliminar tablas, lo ejecuta y rompe el servicio.
    • Con harness: delete_table está mockeado; el agent llama la herramienta, el harness registra la decisión y el LLM-judge marca la acción como destructiva → FAIL. Equipo revisa prompt y reglas antes de permitir acción real.

    Riesgos, limitaciones y gobernanza

    • No existe aún un estándar único; la industria arma soluciones híbridas (Docker + observabilidad + LLM-judge).
    • El harness reduce riesgos, no los elimina: necesita gobernanza humana sobre qué decisiones puede automatizar el agente.
    • Monitorización continua: el harness debe seguir en producción en modo controlado (shadow runs, canary) incluso después del rollout.

    Checklist mínimo antes de dar acceso real

    • Contenedor sandbox probado y reproducible.
    • Todas las herramientas mockeadas disponibles en harness.
    • Trazas completas y auditable por humanos.
    • Umbrales configurados (tokens, coste, llamadas).
    • LLM-judge integrado y reglas de CI/CD que bloqueen merges.

    Dominicode Labs

    Para equipos que construyen infra de agentes y harnesses, explorar investigaciones y plantillas operativas puede acelerar la adopción segura. Una continuación lógica para experimentar con setups híbridos y pipelines de observabilidad es Dominicode Labs.

    FAQ

    Respuesta: ¿Qué es exactamente un Agentic Harness?

    Es la infraestructura que aísla, simula, traza y limita la ejecución de agentes autónomos para que puedan evaluarse y auditarse antes de interactuar con sistemas reales.

    Respuesta: ¿Cuándo debo usar un harness?

    Cuando un agente pueda modificar sistemas, acceder a datos sensibles o ejecutar acciones con impacto operativo. Es obligatorio antes de dar acceso a producción.

    Respuesta: ¿Qué herramientas necesito para empezar?

    Componentes básicos: sandbox (p. ej. Docker o Firecracker), mocks de APIs, sistema de trazas (JSONL) e integración con una herramienta de observabilidad como Langfuse.

    Respuesta: ¿Cómo funciona el LLM-judge?

    Un segundo modelo con temperatura cero revisa la trayectoria del agente (prompts, herramientas, decisiones) y emite una evaluación estructurada (PASS/WARN/FAIL) basada en reglas predefinidas.

    Respuesta: ¿El harness evita la gobernanza humana?

    No. El harness reduce riesgos operativos y automatiza controles, pero requiere gobernanza humana para decidir qué acciones se delegan y qué reglas son aceptables.

    Respuesta: ¿Dónde guardo las trazas y cómo las analizo?

    Guarda trazas en formato navegable (por ejemplo JSONL) con versión del modelo y métadatos. Analiza con una capa de observabilidad o herramientas de tracing para post-mortem y auditoría.

  • Cómo montar un segundo cerebro con Claude Code para gestión del conocimiento

    Cómo montar un segundo cerebro con Claude Code para gestión del conocimiento

    Como montar un segundo cerebro con Claude code

    Si buscas cómo montar un segundo cerebro con Claude Code, aquí tienes una estrategia técnica, reproducible y orientada a equipos que trabajan con código. No es magia: es arquitectura. Trata tus notas como código fuente, versiona todo en Git y deja que Claude Code razone sobre Markdown estructurado para capturar, recuperar y sintetizar conocimiento técnico.

    Documentación de referencia: Claude Code. Para ingesta automatizada, n8n.

    Resumen rápido (lectores con prisa)

    Qué es: Un repositorio de Markdown gestionado por Claude Code que actúa como segundo cerebro técnico.

    Cuándo usarlo: Cuando quieras operar conocimiento técnico como código, con control de versiones, búsqueda semántica y automatización.

    Por qué importa: Reduce fricción entre captura y reutilización, mejora durabilidad y facilita síntesis automatizada.

    Cómo funciona (esencial): Notas en Markdown con frontmatter, indexadas por búsqueda semántica local, gobernadas por un archivo CLAUDE.md y accionadas por un agente CLI.

    Ideas clave

    • Texto plano + Git: durabilidad, portabilidad y trazabilidad.
    • Metadatos estructurados: frontmatter obligatorio para búsquedas precisas y ahorro de tokens.
    • Claude Code como motor activo: agente CLI que crea, etiqueta, sintetiza y propone cambios (PRs).
    • Ingesta automatizada: usar n8n para pipelines que conviertan señales (Slack, GitHub, newsletters) en notas Markdown.

    Tabla de contenidos

    Como montar un segundo cerebro con Claude code: diseño y principios

    El objetivo es simple: minimizar la fricción entre capturar ideas y convertirlas en artefactos reutilizables (ADRs, snippets, post-mortems). Tres principios guían el diseño:

    • Texto plano y Git: durabilidad y portabilidad.
    • Metadatos estructurados: permiten búsquedas precisas sin cargar todo el repositorio.
    • Agente CLI como motor activo: Claude Code actúa (crea, etiqueta, sintetiza) en lugar de solo devolver resultados.

    La propuesta técnica es un repositorio local de Markdown, indexado por una búsqueda semántica local y gobernado por reglas en un archivo CLAUDE.md. Claude Code usa ese contexto para operar de forma coherente.

    Estructura del repositorio (parámetros prácticos)

    Adapta el método PARA (Projects, Areas, Resources, Archives) con convenciones claras. Una topología sugerida:

    /knowledge-base
    /01-projects
    /02-areas
    /03-resources
    /04-archives
    CLAUDE.md

    Adaptación del método PARA

    • Archivos Markdown (.md) con YAML frontmatter en la cabecera.
    • Nombres de archivo semánticos: 2026-04-migracion-postgres.md o auth-use-cases-login.md.
    • Limita el tamaño de archivos (ideal < 1.5k palabras por nota) para mantener la relevancia en búsquedas semánticas.

    Ejemplo de frontmatter

    —
    title: Rate limiting en Express con Redis
    date: 2025-04-10
    tags: [backend, nodejs, redis, performance]
    status: active
    —

    El frontmatter permite a Claude filtrar sin leer todo el contenido y reduce consumo de tokens.

    CLAUDE.md: memoria persistente y reglas del agente

    CLAUDE.md es la gobernanza del segundo cerebro. Define el rol del agente, las reglas de ingestión, los comandos permitidos y las prioridades de búsqueda.

    Contenido mínimo recomendado:

    • Rol (ej. “Actúa como gestor de conocimiento técnico”).
    • Reglas de escritura (frontmatter obligatorio, plantillas).
    • Reglas de búsqueda (usar Semantic Search antes de cargar archivos completos).
    • Protocolos de modificación (p. ej. “Mostrar PR antes de borrar”).

    Con esto, cada sesión arranca con el mismo contrato operativo, evitando decisiones erráticas del modelo.

    Flujos de trabajo operativos (ejemplos reales)

    Algunos flujos operativos que funcionan en equipos técnicos:

    1) Ingesta rápida (post-reunión)

    • Acción: pega el texto bruto en la terminal.
    • Prompt: “Extrae decisiones, riesgos y tareas; crea /01-projects/migracion-postgres.md con frontmatter y lista de tasks.”
    • Resultado: nota creada, etiquetada y commiteada.

    2) Búsqueda semántica y recuperación

    Prompt: “Busca soluciones documentadas para latencia en queries SQL en los últimos 12 meses y sintetiza los patrones comunes.” Claude usa Semantic Search para limitar los archivos que carga y devuelve una síntesis accionable.

    3) Generación de ADRs

    Prompt: “Lee notas con tags #arquitectura y #microservicios, encuentra trade-offs recurrentes y genera un primer borrador de ADR con pros/cons y migración paso a paso.”

    4) Mantenimiento automatizado

    Prompt: “Lista archivos en /03-resources sin tags; propone tags automáticos y muestra la diff antes de aplicar.”

    Orquestación externa: n8n para captura y pipelines

    Para entradas automáticas (Slack, GitHub stars, newsletters), crea workflows en n8n que:

    • Extraigan el contenido.
    • Conviertan a Markdown con frontmatter básico.
    • Guarden en /03-resources o /01-projects.

    Así tu segundo cerebro se alimenta sin intervención manual y Claude tiene material fresco al iniciar la sesión.

    Consideraciones operativas y limitaciones

    • Costos y tokens: obliga al agente a usar Semantic Search local antes de enviar datos al modelo para ahorrar tokens.
    • Context window: evita pedir que el agente “lea todo”; diseña prompts que recuperen subsets relevantes.
    • Seguridad: el repositorio puede contener notas sensibles. Aplica cifrado o repositorios privados; controla accesos.
    • Evolución: revisa periódicamente las convenciones en CLAUDE.md y actualiza plantillas.

    Integración con flujo de trabajo real (CI / PRs)

    Siempre que Claude genere cambios significativos:

    • Crea un branch y un PR automático.
    • Ejecuta CI (tests, linters, SCA) en un entorno aislado (VM/Container).
    • Usa n8n o pipelines para devolver resultados al CLI y permitir que Claude revise y corrija si es necesario.

    Esto evita merges automáticos sin validación humana.

    Conclusión y primer paso accionable

    Cómo montar un segundo cerebro con Claude code no es un truco de productividad: es una decisión de arquitectura que convierte notas en activos reutilizables. Empieza hoy con estos tres pasos:

    1. crea la topología PARA en un repositorio Git,
    2. añade frontmatter obligatorio y un CLAUDE.md con reglas básicas,
    3. prueba un flujo de ingesta simple (reunión → nota creada por Claude).

    Luego automatiza la captación con n8n y define tu política de PR/CI. Haz esto y tu conocimiento dejará de ser un archivo muerto: se convertirá en una base de decisión viva y accionable.

    Mención: Dominicode Labs

    Para complementar flujos de trabajo y pruebas de concepto relacionadas con automatización y agentes, considera explorar recursos prácticos y experimentos en Dominicode Labs. Es una continuación lógica para equipos que buscan implementar pipelines y agentes en entornos reales.

    FAQ

    Respuesta: Archivos Markdown con YAML frontmatter en la cabecera. Nombres semánticos y notas cortas (ideal < 1.5k palabras).

    Respuesta: El frontmatter permite filtrar y priorizar sin cargar todo el contenido, reduciendo consumo de tokens y haciendo las búsquedas más precisas.

    Respuesta: Obliga al agente a ejecutar Semantic Search localmente y solo enviar al modelo los archivos más relevantes; evita pedidos que “lean todo” el repositorio.

    Respuesta: Es el contrato operativo: define el rol del agente, reglas de ingestión, plantillas, comandos permitidos y protocolos de PR/edición.

    Respuesta: n8n orquesta ingestas automáticas (Slack, GitHub, newsletters): extrae contenido, genera Markdown con frontmatter y lo guarda en las carpetas correspondientes del repositorio.

    Respuesta: Claude debe crear branches y PRs automáticos; la CI ejecuta tests/linters y se evita el merge automático sin validación humana.

  • Comparativa de Claude Code y Cursor para desarrolladores en 2026

    Comparativa de Claude Code y Cursor para desarrolladores en 2026

    Claude Code vs Cursor en 2026: cuándo usar cada uno — Comparativa honesta basada en flujos reales

    Tiempo estimado de lectura: 4 min

    • Claude Code es la herramienta de maquinaria: automatización, pipelines y transformaciones en lote.
    • Cursor es el artesano: edición visual, diffs en contexto y pair programming asistido por IA.
    • Asignar la tarea a la interfaz correcta reduce fricción: uso CLI/agents para procesos reproducibles y el IDE para juicios semánticos.

    Claude Code vs Cursor en 2026: cuándo usar cada uno — eso no es una discusión de modelos, es una discusión de interfaz y fricción. Ambas herramientas sirven a la misma ambición (hacerte más productivo), pero en 2026 la diferencia práctica está en qué tipo de trabajo quieres sacar de tu cabeza y poner en piloto automático. En este artículo comparo Claude Code (CLI/headless) y Cursor (IDE visual) basándome en flujos reales: refactors masivos, creación de features y debugging en producción. No hay benchmarks sintéticos; hay decisiones que rompen builds o liberan producto.

    Resumen rápido (lectores con prisa)

    Claude Code: CLI para automatización, pipelines y transforms en lote. Cursor: IDE visual para edición interactiva, diffs en contexto y pair programming. Usa Claude Code para reproducibilidad y escala; usa Cursor para juicios semánticos y cambios que requieren inspección visual.

    Claude Code vs Cursor en 2026: resumen rápido

    – Claude Code (CLI): pensado para automatización, pipelines, scripts y trabajo en lote. Ideal para orquestar agentes sin interfaz gráfica, ejecutar transforms en monorepos y procesar logs pesados. (paquete npm: paquete npm, Anthropic: Anthropic)

    – Cursor (IDE): pensado para el trabajo artesanal dentro del editor. Contexto visual, diffs en vivo, edición interactiva y pair programming asistido por IA. (Cursor)

    Ambas pueden usar modelos avanzados; la ganancia real viene de asignar a cada herramienta la tarea que mejor gestiona su interfaz.

    1) Features nuevas: scaffolding y lógica inicial

    Cuando arrancas una funcionalidad, necesitas dos cosas: rapidez para generar boilerplate y control para validar decisiones arquitectónicas.

    Usa Cursor si…

    • tu feature es UI/UX, componentes React/Next/Angular o cambios que requieren vista simultánea de varios archivos.
    • Cursor muestra el diff en contexto, te permite aceptar cambios parciales y mantener el control línea a línea. Es pair programming con atajos.

    Usa Claude Code si…

    • vas a generar servicios backend desde un esquema: scripts que lean un SQL/JSON Schema, generen controladores, tests y terraform en lote.
    • Un workflow típico: un script Bash alimenta Claude con el esquema y crea un PR con estructura inicial, lista para revisión. No abres centenares de archivos; revisas el PR.

    Ejemplo (flujo Claude Code): un comando que toma un esquema y produce controladores, ejecutado desde CI o local en terminal, sin interfaz gráfica interrumpida.

    2) Refactors masivos y migraciones

    Aquí se gana o se pierde integridad del sistema.

    Claude Code brilla cuando…

    • necesitas migraciones sistemáticas: buscar patrones con ast-grep, encadenar transformaciones con sed/perl/jq y delegar la modificación a un agente que produzca PRs.
    • Es fire-and-forget, reproducible y fácil de auditar.

    Cursor es la opción segura cuando…

    • el refactor toca lógica de dominio y contratos implícitos. Necesitas validar cada cambio con pruebas y juicio humano.
    • Cursor te permite intervenir en cada paso con contexto visual.

    Regla práctica: si puedes expresar la transformación como patrón AST y confiar en pruebas automatizadas, usa Claude Code. Si la transformación requiere juicio semántico sobre reglas de negocio, usa Cursor.

    3) Debugging: local vs infra

    – Cursor es superior para errores locales: reproduces, el IDE captura stacktrace, envía contexto al asistente y te marca la línea problemática. El ciclo es inmediato y visual.

    – Claude Code es la herramienta natural para logs y debugging infra: conecta por SSH, procesa gigas de logs con pipelines (cat error.log | claude --print "resume patrón de errores") y no rompe tu máquina local. Ideal para memory leaks, dumps o análisis de trazas distribuidas.

    Integración práctica (hooks y CI)

    No es “usar uno u otro”; es asignar tareas. Ejemplos concretos:

    • Revisor automático de PRs: Claude Code integrado en un job de CI o hook pre-push con Husky. El agente valida patrones y marca “Missing Tests”.
    • Patch iterativo de UI: Cursor para proponer cambios, revisar visualmente y aceptar commits parciales.

    Tabla de decisión rápida

    Escenario Recomendación
    Componentes UI y revisión visual Cursor
    Migraciones masivas (monorepo) Claude Code
    Debugging local (reproducción en IDE) Cursor
    Análisis de logs/infra remota Claude Code
    Scaffolding backend/infra as code Claude Code
    Refactors de lógica de negocio crítica Cursor

    Riesgos y buenas prácticas

    • Tokens y coste: cualquier workflow que pase megabytes de código a un LLM necesita filtrado (excluir node_modules, builds, package-lock.json) y paginar el contexto.
    • Contexto parcial: Claude Code trabaja con lo que le das. Añade tests y fixtures para reducir falsos positivos.
    • Auditoría: versiona prompts y scripts en el repo. Revisa los PRs generados por agentes como revisas cualquier patch humano.

    Conclusión clara

    No es una elección excluyente. Cursor es el artesano: detalle, iteración y control. Claude Code es la maquinaria: automatización, pipelines y transformaciones en lote. En 2026 los equipos más efectivos combinan ambos: Cursor para diseñar y verificar, Claude Code para escalar y ejecutar. Tu criterio técnico consiste en decidir, a diario, qué tipo de fricción quieres eliminar y cuál quieres mantener para no romper la base de código.

    Para equipos interesados en explorar workflows, agentes y automatización aplicados a ingeniería, consulta Dominicode Labs como continuación lógica para experimentar con pipelines reproducibles y hooks de CI.

    FAQ

    Elige Claude Code para tareas reproducibles y en lote: migraciones sistemáticas, scaffolding backend desde esquemas y análisis de logs a escala.

    Cursor es mejor para cambios que requieren inspección visual, diffs en contexto y juicios semánticos sobre lógica de negocio o UX.

    Sí. Un enfoque práctico es usar Cursor para diseñar y verificar, y Claude Code para ejecutar y escalar los pasos repetibles mediante CI y hooks.

    Filtra el input (excluir node_modules, builds y lockfiles), paginate el contexto y mantén tests/fixtures para validar salidas antes de aplicar cambios.

    Se mencionan ast-grep para patrones AST y Husky para hooks de pre-push. También se refiere al paquete de Claude Code en paquete npm y a Anthropic.

    Versiona prompts y scripts en el repo, revisa PRs generados por agentes como revisas cualquier patch humano y registra cambios automatizados en CI para trazabilidad.

    Cursor se encuentra en Cursor. Claude Code y recursos relacionados están disponibles via paquete npm y Anthropic.

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

  • Cuatro herramientas de IA esenciales para emprendedores técnicos

    Cuatro herramientas de IA esenciales para emprendedores técnicos

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

    Tiempo estimado de lectura: 4 min

    Ideas clave

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

    Tabla de contenidos

    Introducción

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

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

    Resumen rápido (lectores con prisa)

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

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

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

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

    Perplexity

    Usos concretos

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

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

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

    2) Cursor — desarrollo asistido por contexto de repositorio

    Cursor

    Cómo lo uso

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

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

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

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

    n8n

    Casos de uso diarios

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

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

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

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

    v0

    Qué me ahorra

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

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

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

    Cómo encajan estas piezas en un flujo real

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

    URLs de referencia rápidas

    Cuándo usar este stack y cuándo no

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

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

    Empieza mañana

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

    Dominicode Labs

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

    FAQ

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

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

    ¿Cómo mejora Cursor el desarrollo en equipo?

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

    ¿Por qué elegir n8n sobre Zapier?

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

    ¿v0 reemplaza a un diseñador?

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

    ¿Este stack es adecuado para entornos regulados?

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

    ¿Qué pruebas recomendar para integrar este flujo?

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

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

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

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

    Tiempo estimado de lectura: 4 min

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

    Resumen rápido (lectores con prisa)

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

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

    Requisitos mínimos

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

    Instalación rápida

    Instala la CLI de Claude Code y autentica:

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

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

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

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

    Contenido recomendado:

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

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

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

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

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

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

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

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

claude --print --prompt "$PROMPT

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

    Notas:

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

    3. Variante: generador de tests por archivo

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

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

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

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

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

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

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

    Ejemplo Husky (.husky/pre-push):

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

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

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

    5. Limitaciones y buenas prácticas

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

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

    Usa subagentes locales si:

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

    Evítalos cuando:

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

    Conclusión (y lo que sigue)

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

    Dominicode Labs

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

    FAQ

    ¿Qué es un subagente en este contexto?

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

    ¿Cómo protejo credenciales y datos sensibles?

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

    ¿Cuándo el subagente debe fallar un push?

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

    ¿Cómo controlo el coste de tokens?

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

    ¿Puedo usar otros modelos o proveedores?

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

    ¿Cómo versiono y audito prompts?

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

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

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

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

    Tiempo estimado de lectura: 5 min

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

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

    Resumen rápido (lectores con prisa)

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

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

    Qué es Spec-First

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

    Qué es TDD

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

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

    1) Define el contrato (Spec-First)

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

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

    2) Escribe los tests antes (Red)

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

    3) Implementa con la IA (Green)

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

    4) Refactoriza y repite (Refactor)

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

    Ejemplo rápido (esquema)

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

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

    Ventajas reales en equipos técnicos

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

    Riesgos y cómo mitigarlos

    1. Tests tautológicos

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

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

    2. Overfitting en tests

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

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

    3. Explosion de tests irrelevantes

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

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

    Integración práctica y mejores prácticas

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

    Recursos y lectura recomendada

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

     

    FAQ

     

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

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

    ¿Qué pruebas debería escribir primero?

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

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

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

    ¿Qué frameworks de tests son recomendables?

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

    ¿Cómo integrar esto en CI?

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

    ¿Qué métricas debo trackear?

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

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

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

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

    Tiempo estimado de lectura: 6 min

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

    Introducción

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

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

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

    Resumen rápido (lectores con prisa)

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

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

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

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

    Guía paso a paso

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

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

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

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

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

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

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

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

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

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

    4) Usa a Claude como auditor: Red Teaming

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    8) Genera pruebas desde el principio

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

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

    9) Convierte la spec en artefactos machine-readable

    No dejes todo en texto. Pide:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    13) Historias reales (sin fantasías)

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

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

    14) Cuándo no usar Claude para esto

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

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

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

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

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

    – Título y objetivo en una frase.

    – Stack aprobado (y versiones).

    – Reglas arquitectónicas innegociables (3).

    – Interfaces/contratos principales.

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

    – Política de secretos.

    – Responsables y permisos de cambio.

    Hazlo ahora. No mañana.

    16) Metáfora que pega y no falla

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

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

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

    CTA: hazlo en 60 minutos

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

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

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

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

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

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

    FAQ

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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

    Respuesta

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