El flujo de trabajo con Claude Code que sustituyó a mi equipo

El flujo de trabajo con Claude Code que sustituyó a mi equipo

Hace seis semanas, vi a una ingeniera senior lanzar un sistema de autenticación completo, una integración de pagos y el rediseño de un panel de control, todo en una sola tarde. No eran prototipos. No eran demos desechables. Código de producción, con pruebas, tipado seguro y un historial limpio en Git. Tenía tres sesiones de Claude Code ejecutándose en paralelo, cada una en su propio worktree, cada una encargándose de una funcionalidad distinta mientras revisaba los pull requests del lote anterior.

Le pregunté cuánto tiempo le tomó construir este flujo de trabajo. “Aproximadamente una semana de práctica deliberada”, me dijo. “Pero la verdadera respuesta es que dejé de tratar a Claude como un chatbot y empecé a tratarlo como a un ingeniero junior que necesita estructura para dar lo mejor de sí.”

Esa perspectiva se me quedó grabada. Yo llevaba meses usando Claude Code en ese momento: lanzando proyectos, construyendo sistemas de agentes, escribiendo sobre ello constantemente. Pero mi flujo de trabajo seguía siendo mayormente reactivo. Prompt, generar, revisar, corregir, volver a pedir. El ciclo funcionaba, pero estaba dejando una enorme productividad sobre la mesa.

Entonces me encontré con el desglose de Maddy. Maddy es una ingeniera de software senior que ha trabajado en Google, Amazon, IBM y Microsoft; no es alguien propensa al hype. Su enfoque con Claude Code no se basa en prompts ingeniosos ni en funciones ocultas. Es una metodología completa: nueve prácticas interconectadas que transforman a Claude de un chatbot generador de código en algo que funciona como un equipo de ingeniería autónomo. He pasado el último mes implementando cada parte, y los resultados me obligaron a replantear cómo estructuro cada proyecto.

Aquí tienes el sistema, pieza por pieza, con todo lo que aprendí intentando hacerlo funcionar en la práctica.

Por qué la mayoría de los desarrolladores topan con un techo usando Claude Code

Hay un patrón que observo en las comunidades de desarrolladores que es tan consistente que podría considerarse una ley de la naturaleza. Alguien descubre Claude Code. Genera algunos componentes, siente la emoción del desarrollo asistido por IA y empieza a decirle a todo el mundo que es el futuro. Dos semanas después, está frustrado. Los bugs se multiplican. La IA sugiere funciones que no existen. Las ventanas de contexto se desbordan y Claude comienza a contradecir sus propias sugerencias anteriores.

La reacción habitual es culpar al modelo. "No es lo suficientemente inteligente para proyectos reales" o "funciona para ejemplos de juguete pero no para código de producción". Yo mismo dije ambas cosas en distintos momentos.

El problema real casi nunca es el modelo. Es la ausencia de estructura alrededor del modelo.

Piénsalo así: si contratas al ingeniero junior más talentoso del planeta y no le das ninguna inducción, ni estándares de codificación, ni proceso de revisión, ni suite de pruebas, lo que producirá será caos. No por falta de habilidad, sino porque la habilidad sin estructura genera resultados inconsistentes. Con Claude Code ocurre lo mismo. La inteligencia en bruto es extraordinaria. Pero la inteligencia sin un flujo de trabajo produce exactamente los síntomas de los que se quejan los desarrolladores: implementaciones desalineadas, aumento de bugs y la sensación creciente de que pasas más tiempo corrigiendo la salida de la IA que el que habrías invertido escribiendo el código tú mismo.

La metodología de Maddy soluciona esto envolviendo Claude Code en el mismo tipo de disciplina de ingeniería que aplicarías a un equipo humano. Cada paso existe para prevenir un modo de fallo específico que he experimentado personalmente. Y el efecto compuesto —las nueve prácticas funcionando en conjunto— es lo que genera esas mejoras de productividad "esto no puede ser real" que suenan a marketing hasta que las experimentas.

¿La trampa? Tienes que implementarlas de forma deliberada. Saltarse pasos no solo reduce el beneficio: socava todo el sistema. Lo aprendí por las malas cuando intenté saltarme el modo de planificación para tareas "simples" y terminé pasando tres horas depurando lo que debería haber sido una funcionalidad de quince minutos.

Paso 1: Crea un CLAUDE.md Que Realmente Funcione

Todo flujo de trabajo estructurado con Claude Code comienza con CLAUDE.md, y el enfoque de Maddy hacia este archivo es mucho más disciplinado de lo que suelo ver.

Cuando ejecutas /init en cualquier nueva base de código, Claude realiza un análisis estructural y genera este archivo automáticamente. Captura la descripción de tu proyecto, la estructura de archivos, rutas clave, comandos de desarrollo, convenciones de codificación y stack tecnológico. La versión autogenerada es un excelente punto de partida — mucho mejor que escribirlo desde cero, que era lo que solía hacer antes de aceptar que el autoanálisis de Claude detecta detalles que yo olvidaría.

Pero aquí es donde Maddy se aparta del consejo típico: mantiene CLAUDE.md entre 100 y 200 líneas. No 300. No 500. Entre cien y doscientas.

Esa restricción me pareció agresiva al principio. Mis propios archivos CLAUDE.md habían superado las 400 líneas en algunos proyectos — decisiones arquitectónicas, patrones de codificación, fragmentos de ejemplo, contexto histórico. Parecía exhaustivo. En realidad, era un desperdicio. Cada token en CLAUDE.md se carga en cada conversación. Un archivo de 500 líneas consume silenciosamente una parte significativa de tu ventana de contexto antes de que hayas escrito tu primer prompt. Ya cubrí esto en detalle en mi guía de 50 consejos para Claude Code, pero la versión corta es: los archivos de contexto inflados son una de las principales razones por las que la calidad de salida de Claude se degrada a mitad de sesión.

Lo que debe incluir el archivo: descripción del proyecto y funcionalidad principal, estructura de archivos y rutas clave, comandos de build/test/lint (para que Claude pueda validar su propio trabajo), convenciones de codificación y stack tecnológico, y reglas estrictas que Claude nunca debe violar. Lo que no debe incluir: ejemplos de código (Claude puede leer tu base de código real), explicaciones extensas de decisiones pasadas, cualquier cosa que duplique tu README y cualquier cosa que no haya sido relevante en las últimas dos semanas.

La restricción de 100-200 líneas te obliga a priorizar. Cada línea debe ganarse su lugar. Y esa priorización implacable es exactamente lo que hace que la ventana de contexto sea lo suficientemente eficiente para que el resto de este flujo de trabajo funcione.

Una cosa más que Maddy enfatiza y que ahora practico religiosamente: trata CLAUDE.md como un documento vivo. Cuando Claude comete un error y tú lo corriges, añade una regla que evite que ese error vuelva a ocurrir. Con el tiempo, el archivo se convierte en un registro destilado de cada lección que tu proyecto le ha enseñado a la IA. Boris Cherny, el creador de Claude Code, hace exactamente esto con un archivo lessons.md — cada corrección se convierte en una regla permanente. El archivo literalmente se enseña a sí mismo a ser mejor en tu base de código específica.

Paso 2: Modo Planificación Antes de Cada Cambio

Esta es la práctica de mayor impacto en todo el flujo de trabajo de Maddy, y la que más desarrolladores omiten porque sienten que les hace ir más despacio.

El modo planificación (se activa con Shift+Tab en la CLI) le indica a Claude que analice tu base de código y redacte un plan de implementación antes de escribir una sola línea. Revisa qué archivos deben modificarse, qué rutas lógicas se ven afectadas, dónde están los riesgos y cómo encaja el cambio en la arquitectura existente. Obtienes un desglose claro de lo que Claude planea hacer — y, lo más importante, puedes aprobar, modificar o rechazar ese plan antes de que se toque el código.

El umbral práctico al que he llegado: usa el modo planificación para cualquier tarea que afecte a más de un archivo. Para cambios en un solo archivo — renombrar una variable, corregir un error tipográfico, añadir un comentario — deja que Claude ejecute directamente. Para cualquier cosa estructural, primero planifica.

Esta es la razón por la que esto importa tanto en la práctica. Sin el modo planificación, Claude a veces escribe código perfectamente funcional en el lugar completamente equivocado. Una vez le pedí que añadiera limitación de tasa a una API y creó un archivo de middleware nuevo en vez de añadirlo al existente que ya gestionaba la autenticación. El código era correcto. La arquitectura estaba equivocada. No me di cuenta hasta tres funcionalidades después, cuando descubrí que tenía dos cadenas de middleware funcionando de forma independiente.

Con el modo planificación, habría visto "Crear archivo nuevo: middleware/rateLimiter.js" en el plan y lo habría corregido de inmediato a "Modificar archivo existente: middleware/auth.js — añadir lógica de limitación de tasa". Diez segundos de revisión me habrían ahorrado tres horas de refactorización.

El ciclo planificar-revisar-ejecutar que defiende Maddy — y que ahora considero innegociable — se ve así:

1. Describe la tarea en detalle (cuanto más específico, mejor)
2. Activa el modo planificación y deja que Claude analice la base de código
3. Revisa el plan: corrige rutas de archivos, cuestiona decisiones arquitectónicas, añade restricciones
4. Aprueba el plan y deja que Claude ejecute
5. Revisa el resultado frente al plan original

Algunos ingenieros llevan esto aún más lejos. He visto flujos de trabajo donde una sesión de Claude redacta el plan y luego una segunda sesión lo revisa "como ingeniero senior" antes de ejecutar. Probé esto para una migración de base de datos compleja y la sesión de revisión detectó dos casos límite que la sesión de planificación pasó por alto. Exagerado para la mayoría de tareas. Invaluable para cualquier cosa que toque datos en producción.

Paso 3: Limpia el contexto después de cada tarea

Esto suena casi demasiado simple para ser importante. No lo es. De hecho, podría ser la práctica más subestimada de todo el flujo de trabajo.

Después de completar cada tarea discreta, ejecuta /clear para restablecer la ventana de contexto de Claude. Cada archivo que Claude lee, cada salida de comando que procesa, cada mensaje en la conversación: todo se acumula en un presupuesto de contexto compartido. Cuando ese presupuesto se llena, Claude empieza a perder de vista las instrucciones anteriores. Los síntomas son sutiles al principio: código un poco menos preciso, inconsistencias ocasionales con tus estándares de codificación, sugerencias que no terminan de alinearse con lo que pediste. Luego se agravan hasta que terminas depurando una salida de IA que contradice sus propias sugerencias de hace veinte minutos.

Antes solía tratar /clear como algo que se hace cuando las cosas salen mal. Maddy lo trata como higiene: algo que haces después de cada tarea exitosa, antes de que las cosas salgan mal. La diferencia es preventiva frente a reactiva, y el enfoque preventivo es mucho más eficiente.

El flujo de trabajo se convierte en: completa la tarea, verifica que funcione, haz commit y luego ejecuta /clear antes de empezar la siguiente tarea. Borrón y cuenta nueva. Presupuesto de contexto completo disponible para el siguiente problema. Sin ruido acumulado de la conversación anterior.

Una consideración práctica: si tu próxima tarea depende mucho del contexto de la actual, puedes trasladar los detalles esenciales en tu siguiente prompt en lugar de depender de que Claude los recuerde. "Acabo de añadir limitación de tasa al middleware de autenticación. Ahora necesito agregar las pruebas correspondientes para el comportamiento de limitación de tasa" le da a Claude exactamente el contexto que necesita, sin la carga de todo lo que ocurrió en la sesión anterior.

Solo esta práctica eliminó aproximadamente el 40% de los momentos en los que “Claude se comporta raro” que solía experimentar. Y combina perfectamente con el modo plan: siempre empiezas cada tarea con un contexto limpio y un plan deliberado, en lugar de construir sobre el ruido acumulado.

Paso 4: Comandos Slash para Prompts Repetitivos

Todo desarrollador tiene prompts que escribe una y otra vez. "Revisa este código en busca de vulnerabilidades de seguridad." "Escribe pruebas unitarias para esta función." "Refactoriza esto para seguir el patrón de repositorio." Escribirlos repetidamente no solo es tedioso, sino que introduce variaciones. El prompt que usas el jueves para la revisión de código no estará redactado exactamente igual que el del lunes, y esa variación produce resultados diferentes (y a menudo peores).

Los comandos slash resuelven esto convirtiendo tus mejores prompts en disparadores reutilizables. Son archivos Markdown almacenados en .claude/commands/ (o .claude/skills/ — a principios de 2026, estos están prácticamente unificados) que Claude ejecuta cuando escribes el comando slash correspondiente.

Aquí tienes un ejemplo práctico. Tengo un comando llamado /security-review que contiene un prompt detallado que perfeccioné tras decenas de iteraciones:

# Security Review

Review the current changes for security vulnerabilities. Check for:

1. SQL injection vectors in any database queries
2. XSS vulnerabilities in rendered output
3. Authentication/authorization bypass opportunities
4. Sensitive data exposure in logs or error messages
5. CSRF protection on state-changing endpoints
6. Input validation gaps on user-supplied data

For each issue found:
- Classify severity (Critical / High / Medium / Low)
- Show the vulnerable code
- Provide the fixed version
- Explain the attack vector

If no issues found, confirm the code passes review with a brief summary.

Ahora, en lugar de intentar recordar las seis categorías de verificación cada vez, solo escribo /security-review y obtengo resultados consistentes y exhaustivos. El prompt ha sido probado en batalla. El resultado es fiable. Y me ahorro los tres minutos que de otro modo gastaría componiendo la instrucción de memoria.

Maddy recomienda crear comandos slash para cada prompt que hayas escrito más de tres veces. Yo iría más allá: créalos para cualquier prompt donde la consistencia importe más que la creatividad. Revisión de código, generación de pruebas, actualización de documentación, scaffolding de endpoints de API, planificación de migraciones de base de datos. Estos son flujos de trabajo donde quieres resultados predecibles y de alta calidad cada vez.

Los comandos son simplemente archivos Markdown, así que están bajo control de versiones. Puedes compartirlos con tu equipo. Puedes iterar sobre ellos con el tiempo — y cada mejora beneficia a todas las futuras ejecuciones. Mantengo unos quince comandos slash activos en mis proyectos. Los tres que más uso probablemente me ahorran treinta minutos al día.

Paso 5: Hooks de Validación que Permiten a Claude Autocorregirse

Aquí es donde el flujo de trabajo pasa de un “prompting estructurado” a algo que realmente se siente como trabajar con un ingeniero autónomo.

Los hooks de validación son comprobaciones automatizadas que se ejecutan después de cada edición que realiza Claude. Compila el proyecto. Ejecuta la suite de tests. Ejecuta el verificador de tipos. Si algo falla, Claude ve la salida de error e intenta corregirlo automáticamente, sin que tengas que intervenir. La IA entra en un bucle de autocorrección: edita, valida, detecta el fallo, corrige, valida de nuevo, repite hasta que todo pasa.

Esta es la función que Maddy atribuye como la mayor mejora de calidad individual en su flujo de trabajo. Y Boris Cherny, creador de Claude Code, sostiene que darle a Claude un ciclo de retroalimentación mejora la calidad del resultado final entre dos y tres veces en comparación con el método de “generar y rezar”.

Configurar hooks en tu archivo de configuración de Claude Code se ve así:

{
  "hooks": {
    "postEdit": [
      "npm run build",
      "npm run test",
      "npm run typecheck"
    ]
  }
}

Cada vez que Claude modifica un archivo, estos tres comandos se ejecutan automáticamente. Si la compilación falla, Claude ve el error. Si un test falla, Claude ve qué aserción no pasó y por qué. Si el verificador de tipos detecta un tipo incompatible, Claude ve el archivo y la línea exacta.

La clave: sin hooks, Claude verifica su trabajo usando su propio criterio. Lo cual suena razonable hasta que recuerdas que el criterio de Claude se degrada a medida que se llena el contexto. Los tests y las comprobaciones de compilación son una fuente externa de verdad que permanece precisa sin importar la presión de contexto. Cada ciclo de rojo a verde le da a Claude una retroalimentación inequívoca y verificada por máquina sobre la que puede actuar sin esperar por ti.

Quiero ser honesto sobre las limitaciones aquí. Los hooks añaden tiempo a cada ciclo de edición. Si tu suite de tests tarda 90 segundos, eso son 90 segundos de espera tras cada cambio. Para iteraciones rápidas en componentes de UI donde el feedback es visual, a veces desactivo los hooks temporalmente. Pero para cualquier cosa que toque lógica de negocio, endpoints de API o modelos de datos, los hooks siempre están activos. El tiempo que añaden es una fracción del tiempo de depuración que previenen.

Un matiz más que Maddy enfatiza y que he comprobado en la práctica: los hooks son deterministas. CLAUDE.md es orientativo — Claude lo sigue aproximadamente el 80% del tiempo. Los hooks se ejecutan el 100% de las veces. Si algo debe ocurrir después de cada edición sin excepción — formateo, linting, comprobaciones de seguridad — hazlo un hook, no una regla en CLAUDE.md.

Paso 6: Sesiones paralelas y Git Worktrees

Aquí es donde el multiplicador de productividad se vuelve absurdo.

La mayoría de los desarrolladores ejecutan una sola sesión de Claude Code a la vez. Una tarea, una rama, un pipeline secuencial. Maddy ejecuta varias sesiones simultáneamente — algunas en pestañas de terminal, otras en paneles del IDE — cada una manejando una tarea completamente independiente. El secreto que hace que esto funcione sin caer en el caos de conflictos de Git: cada sesión opera en su propio worktree de Git.

Un worktree es un directorio de trabajo separado vinculado al mismo repositorio. Cada uno tiene su propia rama revisada. Los cambios en uno no afectan a los demás. Claude Code tiene soporte nativo para worktrees — puedes iniciar una sesión en su propio espacio de trabajo aislado con un solo comando.

El flujo de trabajo práctico:

1. Crea un worktree para cada funcionalidad: git worktree add ../auth-feature feature/auth
2. Abre una sesión de Claude Code en cada worktree
3. Asigna a cada sesión su tarea y deja que trabajen de forma independiente
4. Revisa y haz merge cuando cada funcionalidad esté completa

Normalmente ejecuto tres sesiones paralelas. Más de eso y la sobrecarga de revisión empieza a comerse el tiempo ahorrado. Tres parece el punto óptimo donde cada sesión recibe suficiente atención sin convertirse en una pesadilla de cambio de contexto para mí.

El cambio mental aquí es significativo. Dejas de verte como un desarrollador que programa con ayuda de IA. Empiezas a verte como un gerente de ingeniería dirigiendo un equipo de desarrolladores IA. Tu trabajo no es escribir código — es planificar el trabajo, asignarlo a las sesiones correctas, revisar los resultados y tomar decisiones arquitectónicas. La generación real de código ocurre en paralelo, a través de múltiples flujos de trabajo independientes.

Si quieres una guía completa sobre cómo configurar worktrees con Claude Code — incluyendo el sutil detalle donde los commits pueden aterrizar en main cuando crees que van a una rama de funcionalidad — escribí un tutorial completo que cubre todos los casos límite que me he encontrado.

Si prefieres que alguien configure este tipo de entorno de desarrollo multi-agente para tu equipo, acepto encargos de automatización de flujos de trabajo. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Paso 7: Subagentes para Subtareas Aisladas

Las sesiones paralelas gestionan funciones separadas. Los subagentes gestionan aspectos distintos dentro de una sola función.

Un subagente es un agente de IA ligero y aislado, generado por tu sesión principal de Claude para encargarse de una subtarea específica. La palabra clave es "aislado": cada subagente recibe su propio prompt de sistema, sus propios permisos de herramientas y su propia ventana de contexto. Cumple su función y reporta resultados sin contaminar el contexto de la sesión principal.

Claude Code incluye tres tipos de subagentes integrados: Explore (solo lectura, optimizado para velocidad y coste), Plan (recopila contexto antes de presentar una estrategia) y un agente de propósito general que gestiona tareas que requieren tanto exploración como modificación.

Pero el verdadero poder está en los subagentes personalizados. El ejemplo de Maddy que me hizo clic: lanzar un subagente enfocado en seguridad que revisa los cambios de código desde una perspectiva de seguridad mientras la sesión principal sigue construyendo funcionalidades. El agente de seguridad tiene su propio prompt de sistema cargado con los controles OWASP Top 10 y las políticas de seguridad de tu organización. Opera de forma independiente, señala problemas y sus hallazgos no saturan el contexto de la sesión principal.

Así es como uso los subagentes en la práctica:

• Agente de revisión de seguridad: Se ejecuta en paralelo al desarrollo de funcionalidades, revisando cada cambio en busca de vulnerabilidades
• Agente de documentación: Genera y actualiza la documentación a medida que evoluciona la base de código, aislado del contexto de implementación
• Agente de generación de tests: Escribe casos de prueba para las funcionalidades completadas mientras avanzo a la siguiente tarea con la sesión principal

El aislamiento es lo que hace que los subagentes sean fundamentalmente diferentes a simplemente pedirle a Claude que "también revise los problemas de seguridad" en tu prompt principal. Ese enfoque consume contexto. Divide la atención de Claude. Y produce análisis de seguridad superficiales porque el modelo está gestionando simultáneamente la implementación y la revisión. Un subagente dedicado se enfoca completamente en su área asignada, con un prompt de sistema optimizado para esa tarea específica.

Algo que aprendí experimentando: los subagentes funcionan mejor para tareas claramente separables del flujo de trabajo principal. Si la subtarea requiere mucha interacción con la sesión principal —"espera, revisa este archivo antes de que continúe"— es mejor gestionarla en la sesión principal. Los subagentes brillan cuando puedes lanzarlos y olvidarte.

Paso 8: Skills — Codificando el conocimiento de tu equipo

Los comandos slash gestionan disparadores de acción única. Las skills gestionan flujos de trabajo de varios pasos.

La distinción es importante. Un comando slash dice "haz esta única cosa". Una skill dice "aquí tienes un procedimiento completo para resolver esta categoría de problema, incluyendo árboles de decisión, casos límite y criterios de calidad". Escribí extensamente sobre esta arquitectura en mi guía sobre skills de agentes, pero la versión corta es: las skills son la forma de codificar el conocimiento institucional en manuales reutilizables y ejecutables por IA.

Maddy lo plantea como la diferencia entre dar a alguien un atajo y darle formación. Ambos son útiles. La formación es lo que se multiplica.

Una skill es un archivo Markdown (almacenado en .claude/skills/) que contiene un flujo de trabajo de varios pasos. Aquí tienes un ejemplo abreviado de una skill de revisión de código:

# Revisión de Código Integral
---

## Paso 1: Evaluación de la Arquitectura
- Verifica si los cambios se alinean con los patrones existentes en la base de código
- Comprueba que los archivos nuevos estén en los directorios correctos según la convención del proyecto
- Señala cualquier decisión arquitectónica que deba ser documentada

## Paso 2: Revisión de la lógica
- Sigue el camino ideal a través del nuevo código
- Identifica los casos límite que no están contemplados
- Verifica la exhaustividad en el manejo de errores

## Paso 3: Comprobación de Rendimiento
- Señalar patrones de consultas N+1
- Comprobar renders innecesarios en componentes React
- Verificar que existan índices de base de datos para los nuevos patrones de consulta

## Paso 4: Análisis de Seguridad
- Verifica la validación de entradas en todos los datos proporcionados por el usuario
- Comprueba los controles de autenticación/autorización
- Revisa posibles vulnerabilidades de inyección

## Paso 5: Evaluación de la Cobertura de Pruebas
- Verifica que los caminos críticos tengan cobertura de pruebas
- Comprueba que los casos límite del Paso 2 tengan pruebas correspondientes
- Señala cualquier ruta de manejo de errores sin pruebas

## Formato de salida
Para cada hallazgo:
- **Archivo:** [ruta]
- **Línea:** [número]
- **Severidad:** Crítica | Alta | Media | Baja | Info
- **Hallazgo:** [descripción]
- **Recomendación:** [solución específica]

Cuando invocas esta skill, Claude no se limita a ejecutar un escaneo rápido. Realiza un proceso de revisión estructurado en cinco pasos que detecta categorías de problemas que una revisión superficial pasaría por alto. Y como la skill está en Markdown bajo control de versiones, todo tu equipo se beneficia de cada mejora.

El efecto compuesto que describe Maddy —y que he experimentado de primera mano— es que las skills acumulan el conocimiento arduamente ganado por tu equipo con el tiempo. Cada caso límite que detectas se añade a la skill relevante. Cada error se convierte en una verificación. Seis meses después de adoptar esta práctica, tus skills contienen la experiencia destilada de todos los proyectos en los que has trabajado. Los nuevos miembros del equipo heredan ese conocimiento al instante.

Actualmente mantengo unas veinte skills en mis proyectos. Las que más valor aportan: revisión de código (proceso en cinco pasos), generación de endpoints de API (genera ruta, controlador, validación, pruebas y documentación en una sola pasada), planificación de migraciones de base de datos (analiza el esquema existente, sugiere pasos de migración, señala riesgos de integridad de datos) y checklist de despliegue (revisa variables de entorno, secretos, DNS, SSL y monitoreo antes de cualquier push a producción).

## Paso 9: Servidores MCP — Extendiendo Claude Más Allá de Tu Base de Código

La pieza final del flujo de trabajo de Maddy conecta Claude con el resto de tu entorno de desarrollo.

Los servidores MCP (Model Context Protocol) son programas independientes que exponen herramientas y recursos a Claude Code mediante un protocolo estandarizado. El concepto es sencillo: Claude ya puede leer archivos y ejecutar comandos. Los servidores MCP le permiten también interactuar con GitHub, Slack, bases de datos, APIs y cualquier otro servicio externo del que dependa tu flujo de trabajo.

[La configuración práctica es más simple de lo que parece](https://alexop.dev/posts/understanding-claude-code-full-stack/). Añades servidores MCP mediante configuración de alcance — alcance `user` para servidores disponibles en todos los proyectos, alcance `local` para herramientas por proyecto, y alcance `project` (escrito en `.mcp.json`) para herramientas compartidas con tu equipo a través de Git.

Algo que me sorprendió la primera vez que conecté servidores MCP: Claude Code no carga todas las herramientas de todos los servidores en el contexto al mismo tiempo. Utiliza búsqueda de herramientas para descubrirlas bajo demanda, trayendo los esquemas solo cuando son necesarios. Esto reduce el uso de contexto aproximadamente en un 95% comparado con clientes que cargan todas las definiciones de herramientas de una vez. Una decisión de diseño inteligente que hace viable ejecutar varios servidores MCP sin que el contexto sea un obstáculo.

Los servidores MCP que uso a diario:

- **GitHub MCP:** Claude puede leer comentarios de PR, crear issues, revisar diferencias y publicar feedback de revisión — todo sin salir de la sesión de terminal
- **Filesystem MCP:** Operaciones de archivos extendidas más allá de lo que Claude Code soporta de forma nativa
- **Slack MCP:** Notificaciones cuando se completan tareas, alertas de errores y actualizaciones de estado publicadas directamente en los canales del proyecto

El punto de Maddy sobre los servidores MCP me resultó muy relevante: convierten a Claude de un asistente de codificación en algo mucho más cercano a un ingeniero semi-autónomo que opera en todo tu entorno de desarrollo. Cuando Claude puede leer un issue de GitHub, planificar la implementación, escribir el código, ejecutar las pruebas, crear el PR y publicar un resumen en Slack, el cuello de botella humano pasa de escribir código a tomar decisiones.

Ese es el cuello de botella correcto.

## El Efecto Compuesto: Por Qué los Nueve Pasos Importan en Conjunto

Quiero ser directo con algo: implementar cualquier paso individual de este flujo de trabajo mejorará tu experiencia con Claude Code. El modo plan por sí solo ya justifica la lectura. Los hooks de validación por sí solos reducirán tu tiempo de depuración. Los comandos slash por sí solos harán que tu flujo diario sea más consistente.

Pero la verdadera transformación ocurre cuando los nueve pasos funcionan como un sistema.

Así es como se potencian entre sí. `CLAUDE.md` le da a Claude comprensión del proyecto. El modo plan le otorga conciencia arquitectónica. `/clear` previene la degradación del contexto. Los comandos slash aseguran calidad constante en la entrada. Los hooks de validación proporcionan bucles de retroalimentación automatizados. Las sesiones paralelas multiplican el rendimiento. Los subagentes ofrecen análisis especializados y aislados. Las skills codifican el conocimiento institucional. Los servidores MCP amplían el alcance más allá del código fuente.

Si quitas una pieza, el sistema sigue funcionando. Pero funciona como un coche con una rueda pinchada: técnicamente operativo, pero visiblemente degradado. Las piezas están diseñadas para compensar las limitaciones de las demás. El modo plan detecta errores arquitectónicos que `CLAUDE.md` por sí solo no puede evitar. Los hooks de validación detectan errores de implementación que el modo plan no puede prever. Limpiar el contexto previene ese tipo de degradación progresiva de calidad que hace que todo lo demás sea menos fiable con el tiempo.

El flujo de trabajo al que he llegado tras un mes de práctica:

1. Comenzar cada proyecto con un `CLAUDE.md` conciso (menos de 150 líneas)
2. Iniciar cada tarea en modo plan — revisar y aprobar antes de ejecutar
3. Dejar que los hooks de validación detecten errores automáticamente durante la ejecución
4. Limpiar el contexto tras cada tarea completada
5. Usar comandos slash para cada flujo de trabajo repetido
6. Ejecutar 2-3 sesiones paralelas en features independientes mediante worktrees
7. Lanzar subagentes para revisión de seguridad y generación de tests
8. Mantener skills para flujos de trabajo multi-paso que comparte el equipo
9. Conectar servidores MCP para GitHub, Slack y cualquier integración específica del proyecto

La curva de aprendizaje es real. La primera semana de práctica deliberada fue más lenta que mi flujo de trabajo anterior. Estaba constantemente alternando el modo plan, escribiendo comandos slash, configurando hooks — una sobrecarga que no producía resultados visibles inmediatos. Para la segunda semana, esa sobrecarga se volvió automática. Para la tercera, estaba entregando más en una mañana de lo que antes entregaba en un día.

## Lo que hice mal — Y lo que haría diferente

Voy a ser honesto sobre los errores que cometí al implementar este flujo de trabajo, porque te ahorrarán tiempo si estás empezando desde cero.

**Error 1: Implementar todo de una vez.** Leí la metodología completa de Maddy e intenté adoptar las nueve prácticas el primer día. La sobrecarga cognitiva fue brutal. Estaba tan enfocado en el proceso que apenas escribía código. Mejor enfoque: empieza con `CLAUDE.md` + modo plan + `/clear`. Añade validaciones en la segunda semana. Agrega comandos slash y sesiones paralelas en la tercera semana. Deja los subagentes, habilidades y MCP para la cuarta semana.

**Error 2: Complicar demasiado los comandos slash.** Mi primer lote de comandos slash eran prácticamente ensayos. Trescientas palabras de instrucciones cada uno. Funcionaban, pero consumían muchísimo contexto. Desde entonces los he reducido para que sean tan concisos como mi `CLAUDE.md`: cada palabra debe ganarse su lugar. Un comando enfocado de 50 palabras supera a uno de 300 casi siempre.

**Error 3: Ejecutar demasiadas sesiones paralelas.** Me entusiasmé y traté de ejecutar cinco sesiones simultáneas. La carga de revisión destruyó las ganancias de productividad. Tres es mi punto óptimo. Dos si las tareas son complejas. Cinco fue un caos.

**Error 4: Olvidar limpiar el contexto.** Las viejas costumbres cuestan. Me metía en la dinámica, completaba tres tareas sin limpiar y luego me preguntaba por qué las sugerencias de Claude empeoraban progresivamente. Al final puse una nota adhesiva física en mi monitor: "¿Hiciste /clear?" Poco elegante. Efectivo.

**Error 5: Usar subagentes para tareas que necesitaban el contexto de la sesión principal.** Intenté crear un subagente para refactorizar una función que dependía mucho de la conversación que había tenido con la sesión principal sobre decisiones de arquitectura. El subagente no tenía ese contexto y produjo una refactorización que contradecía todo lo que habíamos discutido. Los subagentes funcionan para tareas independientes. Para trabajos que dependen mucho del contexto, mantenlo en la sesión principal.

Ninguno de estos errores fue catastrófico. Pero cada uno me costó tiempo que no necesitaba perder. El flujo de trabajo es realmente potente — y lo es aún más cuando respetas sus límites en vez de intentar atajarlos.

## El cambio en la forma de pensar sobre tu rol

Hay una idea más profunda detrás de los nueve pasos que me llevó un tiempo poder expresar.

Cuando implementas este flujo de trabajo por completo, tu rol cambia. Pasas menos tiempo escribiendo código y más tiempo tomando decisiones. Planificas la arquitectura en lugar de implementarla. Revisas resultados en vez de generarlos. Diseñas sistemas en vez de teclearlos.

A algunos desarrolladores esto les resulta incómodo. Para muchos de nosotros, programar es parte de nuestra identidad. La sensación de construir algo línea por línea —ese estado de flujo donde tus dedos y tu mente están perfectamente sincronizados— es realmente gratificante. Renunciar a eso, aunque sea en parte, se siente como una pérdida.

Así me sentí durante las dos primeras semanas. Luego me di cuenta de que las decisiones que estaba tomando —las elecciones arquitectónicas, las prioridades, los juicios de calidad— eran más difíciles y valiosas que el código que solía escribir. El código era ejecución. Las decisiones eran estrategia. Y la estrategia es lo que realmente determina si un software tiene éxito.

El marco de trabajo de Maddy no reemplaza la habilidad de ingeniería. La redirige. Tu comprensión de algoritmos, estructuras de datos, patrones de diseño y arquitectura de sistemas se vuelve más importante, no menos, porque eres tú quien guía a una IA que puede ejecutar a velocidad sobrehumana, pero que no puede tomar decisiones estratégicas sin ti.

Los ingenieros que he visto tener dificultades con este flujo de trabajo son los que no pueden soltar el teclado. Los que prosperan son aquellos que siempre desearon tener más tiempo para pensar en la arquitectura y menos tiempo escribiendo código repetitivo. Este flujo de trabajo te da exactamente ese intercambio.

## Hacia Dónde Nos Dirigimos

No creo que hayamos terminado. La brecha entre lo que Claude Code puede hacer hoy y lo que podrá hacer en doce meses probablemente sea mayor de lo que la mayoría de los desarrolladores espera.

El patrón que observo: cada una de estas nueve prácticas existe debido a una limitación actual. El modo de planificación existe porque Claude a veces escribe código correcto en el lugar equivocado. Los hooks de validación existen porque Claude no siempre puede verificar su propio trabajo internamente. El borrado de contexto existe porque las ventanas de contexto tienen una capacidad finita. Los subagentes existen porque un solo contexto no puede albergar todas las preocupaciones simultáneamente.

A medida que las ventanas de contexto se expandan, que los modelos mejoren en la autoverificación y que el uso de herramientas se vuelva más sofisticado, algunas de estas prácticas dejarán de ser tan críticas. El modo de planificación podría volverse innecesario cuando el razonamiento arquitectónico del modelo sea lo suficientemente confiable como para omitir ese paso explícito. Los hooks de validación podrían volverse redundantes cuando la verificación interna del modelo iguale la precisión de las pruebas externas.

Pero la meta-práctica —construir estructura alrededor de las capacidades de la IA— solo se volverá más importante. Los modelos mejorarán. Los ingenieros que sepan cómo diseñar flujos de trabajo en torno a esos modelos serán quienes extraigan el mayor valor. Esa es la verdadera habilidad que enseña esta metodología: no cómo usar Claude Code específicamente, sino cómo pensar el desarrollo aumentado por IA como una disciplina.

Los nueve pasos de Maddy son el mejor punto de partida que he encontrado para construir esa disciplina. Comienza con `CLAUDE.md` y el modo de planificación. Añade una práctica por semana. En un mes, tendrás un flujo de trabajo que hará que tu enfoque actual se sienta como conducir con el freno de mano puesto.

La pregunta con la que vale la pena quedarse esta noche no es si este flujo de trabajo merece ser implementado —la evidencia es abrumadora de que sí lo merece—. La pregunta es cuáles de tus hábitos actuales son tan cómodos que te están impidiendo dar el salto.

## Preguntas Frecuentes

### ¿Cómo configuro el modo plan en Claude Code?

Activa el modo plan con `Shift+Tab` en la CLI de Claude Code antes de describir tu tarea. Claude analizará tu base de código y generará un plan de implementación para revisión antes de escribir cualquier código. Úsalo para cualquier cambio que afecte a más de un archivo.

### ¿Cuál es la diferencia entre los comandos slash y las skills en Claude Code?

Los comandos slash son indicaciones de una sola acción almacenadas como archivos Markdown en `.claude/commands/`. Las skills son flujos de trabajo de varios pasos almacenados en `.claude/skills/` que codifican procedimientos complejos con árboles de decisión y criterios de calidad. Desde 2026, ambos utilizan la misma interfaz de comandos slash.

### ¿Cuántas sesiones paralelas de Claude Code debería ejecutar?

Comienza con dos sesiones paralelas usando worktrees de Git para aislarlas. Tres sesiones es el punto óptimo práctico para la mayoría de los desarrolladores. Ejecutar más de tres suele generar una sobrecarga de revisión que anula las ganancias de productividad de la paralelización.

### ¿Los hooks de validación de Claude Code ralentizan el desarrollo?

Los hooks añaden un tiempo de ejecución igual a la duración de tu build y pruebas después de cada edición. Para proyectos con suites de pruebas de menos de 30 segundos, la sobrecarga es insignificante comparada con el tiempo de depuración que previenen. Para suites de pruebas más largas, considera ejecutar solo un subconjunto relevante como hooks y la suite completa antes de los commits.

### ¿Qué servidores MCP debo instalar para Claude Code?

La mayoría de los desarrolladores necesita de dos a tres servidores MCP: GitHub (para gestión de PR e issues), una extensión de sistema de archivos y un servidor específico de dominio. Agrégalos con la configuración de scope — `user` para disponibilidad global, `project` para herramientas compartidas en equipo mediante `.mcp.json` en tu repositorio.

## Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

* **Fiverr** (desarrollos e integraciones a medida): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portafolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (soluciones empresariales): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (diseño y branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (servicios de seguridad): [xcybersecurity.io](https://www.xcybersecurity.io)
---