Por qué tu flujo de trabajo no ha cambiado a pesar de usar Claude Code a diario
«Recuerdo haber ejecutado /init. Pero no tengo ni idea de cuándo fue la última vez que lo actualicé».
¿Te suena? Instalaste Claude Code, pasaste los primeros días configurándolo y conversas con él a diario. Sin embargo, en comparación con hace tres meses, la estructura de tu trabajo sigue siendo prácticamente la misma.
Esto no es un problema de uso; es un problema de posicionamiento.
Si sigues usando Claude Code como una «herramienta que responde cuando se le habla», acabarás escribiendo las mismas instrucciones cada mañana, obteniendo respuestas similares y copiándolas en tu trabajo. Puede que seas más eficiente, pero la forma en que avanza tu trabajo no ha cambiado fundamentalmente.
El cambio se produce cuando empiezas a tratar a Claude Code como un «objetivo de diseño». ¿Quién sabe qué en qué contexto? ¿Qué tareas se delegan a quién? ¿Qué se mueve incluso cuando no hay ningún humano presente? Cuando empiezas a pensar en esto como diseño, Claude Code comienza a comportarse de manera completamente diferente.
Las 27 características publicadas por @sairahul1 (https://x.com/sairahul1/status/2070428662080618607) enumeran sistemáticamente las funciones que deberían usarse desde esta perspectiva de diseño. Swarm las ha interpretado a través del prisma del diseño de agentes y las ha organizado en un formato aplicable a contextos empresariales reales.
Veintisiete puede parecer mucho, pero solo hay tres principios fundamentales. Explicaremos esta estructura en orden a partir del siguiente capítulo.
Las tres disciplinas que conectan las 27 características
Si observamos las 27 características, pueden parecer dispersas. Hay accesos directos, configuraciones de archivos, entrada de voz y ejecución de pruebas. Sin embargo, cuando se descodifican, se pueden organizar en grupos que responden a tres preguntas.
Disciplina 1: Diseño de contexto (Características 1–5)
Crear un estado en el que Claude sepa «de quién es el proyecto, con qué propósito y cuánto entiende actualmente». Si esto falla, tienes que explicarlo todo desde cero cada vez.
Disciplina 2: Diseño de delegación (Características 6–14)
Transferir estructuralmente tareas y autoridad a Claude. En lugar de decir «arregla el error», organizas y entregas «qué está roto y cuáles son las limitaciones», lo que cambia la probabilidad de una resolución a la primera.
Disciplina 3: Diseño de autonomía (Características 15–27)
Diseñar un mecanismo en el que Claude pueda seguir moviéndose sin instrucciones humanas constantes.
Estas tres etapas también son el orden en que deberías usarlas. Si el contexto no está establecido, la delegación se vuelve descuidada. Si la delegación no está diseñada, la autonomía se descontrola.
Lo que debes tener en cuenta aquí es cómo cambiar la estructura de «yo instruyendo a Claude cada mañana». Si estás lanzando las mismas tareas al chat cada mañana, el humano sigue siendo el sujeto. Cuando el diseño cambia a una estructura que mueve a Claude, lo que haces por la mañana cambia.
Primero, veamos las cinco características del Diseño de Contexto.
Fundamentos del diseño de contexto
El objetivo del diseño de contexto es proporcionar a Claude el «contexto de este proyecto». Sin contexto, cada conversación empieza desde cero.
Lo primero que hay que ejecutar es `/init`.
Cuando abras un proyecto por primera vez, ejecuta esto primero. Claude escanea la estructura del código base, las dependencias y los comandos de compilación para generar automáticamente CLAUDE.md. Este archivo se convierte en el «modelo» del proyecto.
Aquí es donde muchos se detienen. Recuerdan haber ejecutado /init, pero no saben cuándo se actualizó por última vez. Si se deja tal como se generó, el contenido de CLAUDE.md se alejará de la realidad a medida que el proyecto cambie. Al operar bajo la premisa de actualizaciones semanales, Claude siempre puede moverse dentro del contexto más reciente.
A continuación, es útil configurar `/statusline`.
Aparecerá una línea de estado en la parte inferior de la pantalla. Puedes visualizar qué se está ejecutando y qué procesos están activos. También se puede integrar con líneas de estado personalizadas en Vim o Neovim, lo que te permite configurarlo según tu entorno de editor existente.
El tercero es la entrada de voz.
Puedes transmitir requisitos complejos hablando usando ⌃⌘Espacio en Mac o la entrada de voz nativa en iOS y Android. Puedes pasar instrucciones largas como «Quiero que este componente se mueva así por esta razón, pero no cambies los estilos existentes» sin tener que escribir. Como puedes transmitir los pensamientos tal como fluyen, ahorras tiempo dedicado a organizar mientras escribes.
Usa `/context` para comprobar el estado del contexto.
Puedes ver qué hay actualmente en la conversación y el uso de la ventana de contexto en tiempo real. En sesiones largas, el contenido del modelo inicial tiende a desvanecerse. Este comando te permite monitorear eso.
Las operaciones de reinicio para eso son `/compact` y `/clear`.
/compact comprime todo el contexto en un resumen. /clear es un reinicio completo. Si continúas una sesión larga, las respuestas de Claude pueden volverse vagas. Esta es una señal de que el contexto está obstruido. Al usar /compact periódicamente, puedes mantener la calidad de la salida.
Antes: En la segunda mitad de una sesión larga, Claude da una respuesta desalineada incluso cuando dice «siguiendo la política de diseño discutida anteriormente».
Después: Comprimir con /compact antes de continuar mantiene la salida precisa según la política.
Las cinco características hacen una cosa: mantener el estado de Claude «sabiendo» como diseño. Eso se convierte en la base para el siguiente paso, el Diseño de Delegación.
El arte de transmitir problemas
Una vez que el contexto está establecido, el siguiente paso es cómo transmitir el problema. La precisión de la respuesta cambia completamente dependiendo de si dices «arregla el error» o lo transmites de manera estructurada.
Primero, usa el modo plan (`Mayús+Tab`).
Antes de cambios importantes, este modo genera «solo el plan» en lugar de ejecutar. Puedes comprobar de antemano qué pretende cambiar Claude y en qué orden.
En lugar de corregir errores después de que ocurran, puedes señalar «eso está mal» en la etapa de planificación. Incorporar este paso en tu diseño cambia significativamente la frecuencia de cambios inesperados. A medida que lo sigas usando, te darás cuenta de que reduce el esfuerzo de comprobar «¿por qué se reescribió este archivo?» después del hecho.
Segundo es la estructuración de problemas, restricciones y contexto.
Si solo dices «arregla el error», Claude intenta completar las suposiciones por sí mismo. Si esas suposiciones son incorrectas, la solución también lo será.
El formato recomendado oficialmente es escribir «qué está roto» en la primera línea, y «qué se intentó, restricciones y formato de salida esperado» a partir de la segunda línea. Simplemente transmitirlo en este formato cambia la tasa de resoluciones a la primera. La forma en que transmites el problema se convierte en una habilidad.
Tercero es `AskUserQuestion`.
Esta es una función en la que Claude pide aclaraciones antes de proceder cuando se encuentra con requisitos ambiguos. El retrabajo causado por la implementación que avanza con requisitos vagos a menudo ocurre cuando no se usa esta función. Es un diseño que paga el costo de la confirmación antes de la implementación.
Cuarto es el paso de autoverificación.
Al final de una tarea, dile que «ejecute las pruebas y confirme que la compilación pasa antes de terminar». En lugar de agregar esto manualmente cada vez, escribirlo en CLAUDE.md asegura que se ejecute automáticamente al final de cada tarea. En lugar de que Claude se detenga en un estado donde las cosas no funcionan después de un cambio, el bucle que incluye la verificación se completa como una sola tarea.
Tomar medidas proactivas con el modo plan y automatizar los pasos reactivos con la autoverificación. La estructura del flujo de desarrollo cambia en el momento en que estos dos se incorporan al diseño.
En el próximo capítulo, veremos el diseño de la delegación de tareas continuas a Claude.
Diseñando la delegación
En los capítulos anteriores, organizamos cómo comunicarnos con Claude y cómo permitirle retener la memoria. El siguiente trata sobre cambiar «quién se convierte en el sujeto».
10. Subagentes
Si un humano gestiona los procedimientos durante tareas largas, inevitablemente se atascará. Decir constantemente «haz esto a continuación, luego haz esto cuando termines» significa que el humano, no Claude, está manejando la coordinación.
Usando las herramientas TodoWrite o Task, Claude descompone las tareas en subtareas y las ejecuta en paralelo. En términos oficiales, esto es «ejecución concurrente de subagentes»: una estructura donde múltiples Claudes hijos se mueven simultáneamente. Diferentes Claudes ejecutan investigación, implementación y pruebas al mismo tiempo. Los humanos no necesitan retener el procedimiento.
11. Habilidades personalizadas (Archivos de plantilla de flujo de trabajo)
Colocar archivos Markdown en el directorio .claude/commands/ te permite llamar a conjuntos de instrucciones con /nombre-comando. En el contexto de Swarm, es más fácil pensar en ellos como «SKILL.md (Archivos de plantilla de flujo de trabajo)».
Antes: Escribir «Por favor, realiza una encuesta de competidores. Los pasos son 1, 2, 3...» cada vez.
Después: Simplemente escribir /competitive-research en una línea.
El tiempo dedicado a escribir las mismas instrucciones repetidamente desaparece. Si se comparte con un equipo, se convierte en una plantilla donde cualquiera puede obtener la misma calidad de salida.
12. Selección de modelo
Puedes cambiar de modelo dentro de una sesión presionando Alt+P. Un uso realista de tres etapas es: modelos de alto razonamiento para fases de diseño y concepto, modelos ligeros para implementación simple y modelos de gama media para depuración.
Emparejar la potencia del modelo con el peso del proceso mejora tanto la eficiencia de costos como la velocidad de respuesta simultáneamente.
13. Actualizaciones automáticas de CLAUDE.md
Si le dices a Claude que «añada lo que aprendiste en este proyecto a CLAUDE.md», Claude actualizará CLAUDE.md por sí mismo. Es una estructura donde el modelo crece por sí solo.
Al agregar este comando una vez a la semana, CLAUDE.md se convierte en un «documento vivo». Incluso si los humanos no escriben reflexiones, Claude acumula lo que ha aprendido.
14. Vinculación de archivos externos
Puedes pasar archivos, URL o Issues como contexto usando @{ruta_del_archivo}. Es un mecanismo para completar «lee este archivo antes de trabajar» en una línea.
Antes: Copiar y pegar el contenido del archivo en el mensaje.
Después: Simplemente escribir «Consulta la configuración consultando @src/config.yaml».
Diseñar la delegación significa crear un sistema que entregue el sujeto a Claude. Cuando los procedimientos, las plantillas, las referencias y la memoria están en su lugar, los humanos solo necesitan pensar en «qué crear».
Sin embargo, a medida que aumenta la delegación, también lo hace el riesgo de que «Claude se mueva en una dirección diferente a la intención». En el próximo capítulo, veremos cómo detener esa desviación temprano.
Detener la desviación temprano
A medida que aumenta la delegación a Claude, un problema se vuelve más probable: darse cuenta de que ha ido en una dirección completamente diferente a la prevista. Llamamos a esto desviación.
La desviación no es algo que se corrija después; se puede prevenir tomando medidas de diseño proactivas.
15. Detención inmediata
Si sientes que la salida se dirige en una dirección obviamente incorrecta, puedes detenerla inmediatamente con la tecla Escape. «Lo arreglaré después de que termine» es un error. Cuanto más avanza la generación, mayor es el costo de corrección. Detenerse a mitad de camino y corregir el mensaje ahorra tiempo y tokens.
Si intuitivamente piensas que algo está mal, detente sin dudar. La velocidad de este juicio impacta directamente en la precisión.
16. Solicitar la primera salida como evidencia
Un diseño proactivo es decir «muéstrame solo la primera salida primero, y decidiré si continuar» antes de comenzar a trabajar.
En lugar de dejar que se tome 10 minutos en la dirección equivocada, confirma con la primera salida antes de dejarlo correr. Esta es la idea de cortar la desviación de raíz. Es esencial para tareas de larga duración o trabajos que comienzan con direcciones ambiguas.
Antes de decir «te dejo el resto», inserta «déjame verificar el principio». Es solo un paso, pero este movimiento proactivo cambia el resultado.
17. Enlaces de notificación
Mirar fijamente la pantalla esperando que termine una tarea larga es una pérdida de tiempo. Al colocar un script en ~/.claude/hooks/, puedes recibir notificaciones de escritorio cuando se complete una tarea.
Configúralo una vez. A partir de entonces, incluso si estás haciendo otro trabajo, Claude te notificará cuando haya terminado. Es un diseño que elimina el acto de esperar.
18. Pasar capturas de pantalla
Explicar errores de UI con palabras es sorprendentemente difícil. En lugar de decir verbalmente «apareció un error rojo en la esquina superior izquierda y el botón no se puede presionar», pasar una captura de pantalla es más rápido.
Claude recibe la imagen y devuelve el contenido del error, la causa y las sugerencias de corrección tal como están. Se completa con «mira esta pantalla».
Las 18 características presentadas hasta ahora se basan en la premisa de que una sola persona opera. En el próximo capítulo, entramos en la estructura de «usar en equipo», donde múltiples Claudes se ejecutan en paralelo y se integran.
Operación en paralelo e integración
Mientras usas Claude Code como una herramienta de chat, no puedes comenzar la siguiente tarea hasta que una esté terminada. Pero al cambiar el diseño, puedes crear una estructura donde múltiples Claudes se muevan simultáneamente.
Comienza con la integración de Chrome DevTools. Dado que puedes pasar registros de errores del navegador y registros de red directamente a Claude Code, ya no necesitas explicar verbalmente situaciones como «hay un error rojo en la consola pero no sé qué está pasando». La documentación oficial tiene una página dedicada para esto, posicionándolo como la puerta de entrada a la depuración.
La gestión de sesiones también cambia. Puedes reanudar la sesión más reciente tal como está con claude --continue, o elegir de una lista de sesiones con claude --resume. Además, al nombrar sesiones con /rename, puedes gestionar múltiples tareas en paralelo con la misma sensación que las ramas de Git. Al usar sesiones llamadas «Auth», «Payment» y «Dashboard», el costo de cambiar de contexto se vuelve casi cero.
Y el núcleo de la operación en paralelo es la combinación con git worktrees. Escribir claude --worktree feature-auth lanza una sesión donde la rama está completamente aislada por el worktree. Si ejecutas Auth, Payment y Dashboard en worktrees separados, tres Claudes procederán con el desarrollo en paralelo. Como cada uno está en un espacio de trabajo independiente, no ocurren conflictos. La estructura para terminar una semana de desarrollo en un día se establece aquí como diseño.
También es necesario organizar pensamientos sobre MCP. Un servidor MCP no es siempre la solución óptima. La documentación oficial establece que «las herramientas CLI son la forma más eficiente en contexto de interactuar con servicios externos», y se dice que herramientas CLI como gh o aws tienen alta eficiencia de contexto y es menos probable que alcancen límites de velocidad. Con solo el comando gh, Claude Code puede crear, actualizar y cerrar Issues de GitHub de forma autónoma. Tener un eje de juicio para verificar si se puede usar una herramienta CLI antes de agregar un MCP mantiene el diseño simple.
Cuando el diseño en paralelo es posible, los humanos ya no necesitan gestionar la secuencia. Esto se debe a que el diseño cambia a pasar múltiples sujetos a Claude simultáneamente. A continuación, evolucionaremos este procesamiento en paralelo diseñado en un sistema que sigue moviéndose incluso cuando estás fuera de tu escritorio.
Operación autónoma
La siguiente pregunta después del diseño en paralelo es: «¿Dónde necesito estar durante ese tiempo?». Cuando se diseña la operación autónoma, se crea un estado en el que el trabajo progresa incluso sin un humano presente.
/loop es una función que ejecuta sondeos automáticos dentro de una sesión. La explicación oficial es «Sondeo rápido mientras una sesión está abierta», y repite las operaciones especificadas mientras la sesión está abierta. Usar --resume o --continue permite reanudar sesiones que no han expirado, y según informes de experiencia en el artículo original, se han reportado casos de operación no tripulada de hasta tres días. Aunque no hemos confirmado ese número de días directamente con fuentes oficiales, ciertamente funciona como un punto de entrada para la operación autónoma de larga duración.
Control Remoto, añadido en el primer trimestre de 2026, es una función para operar sesiones de Claude Code que se ejecutan localmente desde un teléfono inteligente o un navegador de PC. Mientras el código permanece local, solo se intercambian mensajes a través de un canal cifrado. Se lanzó como una vista previa de investigación en febrero de 2026. Se establece un escenario donde el Claude Code local sigue moviéndose solo con enviar «comprueba si las pruebas pasaron» desde un teléfono inteligente mientras estás fuera.
Las consultas en lenguaje natural a bases de datos también se pueden incorporar al diseño. Conectarse a SQLite, PostgreSQL o MySQL a través de MCP te permite recuperar datos usando español (o inglés) como «dime los usuarios registrados la semana pasada». La guía oficial sugiere ejecutar claude mcp add para conectar herramientas externas como tu base de datos, lo que te permite delegar rutinas de confirmación de datos a Claude sin escribir SQL.
También hay cuatro funciones para controlar la profundidad del pensamiento. ultrathink desencadena un pensamiento extendido de hasta 31,999 tokens solo con incluir esa palabra clave en el mensaje. Hay una jerarquía: think son 4,000 tokens, megathink son 10,000 tokens y ultrathink son 31,999 tokens. La forma correcta de usarlo es solo para el 10% de los problemas realmente difíciles, como decisiones arquitectónicas complejas, implementaciones de seguridad, optimización del rendimiento y refactorización a gran escala. Usarlo para cada consulta inflará los costos innecesariamente.
/effort ultracode es una configuración para habilitar el razonamiento xhigh y los flujos de trabajo dinámicos para toda la sesión. Mientras que ultrathink es una palabra clave de un solo turno, ultracode permanece activo durante toda la sesión. Es adecuado para «trabajo pesado de toda la sesión» como auditar un código base completo, migrar cientos de archivos o tareas de alto riesgo. Sin embargo, dado que los costos de tokens aumentan significativamente, discernir la situación determina la efectividad.
Claude Code, que comenzó escribiendo en un chat para moverlo, ha llegado a la puerta de un sistema que detecta eventos y se mueve de forma autónoma. En lugar de que los humanos lo muevan, el diseño mueve a Claude. A continuación, confirmaremos dónde surge esencialmente la diferencia en productividad a través de todas estas características.
Por qué los resultados difieren con el mismo Claude Code
Las personas que desarrollan rápido no necesariamente tienen habilidades especiales. Simplemente están diseñando de manera más sistemática.
Por ejemplo, considera la situación de ejecutar /init. Incluso si se escribe el mismo comando, la calidad de la salida varios meses después será completamente diferente entre un CLAUDE.md que se actualiza semanalmente y uno que se ha dejado desde la configuración. Esto se debe a que la frescura y precisión del contexto que Claude lee impactan directamente en la calidad de la salida.
Usando una analogía de cocina, el nivel de cocina está determinado más por cómo está organizada la propia cocina que por qué ingredientes se utilizan. El rendimiento del modelo de Claude se proporciona por igual a todos los usuarios. La diferencia radica en la precisión de estos tres puntos: cómo se organizó el contexto, cómo se sistematizaron las instrucciones y cómo se diseñó la operación autónoma.
Antes de discutir «qué modelo usar», intenta comprobar cuándo se actualizó por última vez tu CLAUDE.md actual. Eso te dirá el estado actual de tu diseño.
Entonces, ¿por dónde deberías empezar realmente? En el próximo capítulo, organizaremos una secuencia de introducción paso a paso.
Por dónde empezar: una guía de introducción paso a paso
No tienes que intentar recordar los 27 a la vez.
En la primera semana, limítalo a solo cuatro.
- Crea un mapa del proyecto con
/init. - Comprime el contexto periódicamente con
/compact. - Separa la exploración y la ejecución con el modo plan (
Mayús+Tab). - Transfiere los pasos de autoverificación (pruebas, compilaciones) a Claude.
Con solo estos cuatro, la calidad de la sesión cambiará fundamentalmente. Dado que Claude comienza a moverse con una comprensión precisa de «lo que se debe hacer», la cantidad de retrabajo disminuirá visiblemente.
A partir de la segunda semana, añade el Diseño de Delegación sobre esta base. Resume las instrucciones en un formato reutilizable con Habilidades Personalizadas, ajusta el peso y la velocidad del procesamiento con la selección de modelo (Alt+P), y establece el hábito de actualizar CLAUDE.md semanalmente. Esta es la etapa en la que cambias las instrucciones de «algo escrito cada vez» a «algo que se acumula».
Después de un mes, procede a subagentes, git worktrees y sesiones en paralelo. Tendrás un sistema en el que puedes concentrarte en el diseño y la confirmación mientras desarrollas múltiples funciones simultáneamente.
ultrathink y ultracode son herramientas que se usan por primera vez en este flujo cuando te encuentras con «problemas realmente difíciles». No son herramientas para sacar para cada problema.
Siguiendo estos pasos, llegarás a comprender por experiencia «por qué cada característica es necesaria». Comienza con los cuatro elementos de la primera semana.
Todo cambia en el momento en que lo tratas como un objetivo de diseño
En el momento en que empiezas a tratar a Claude Code como un objetivo de diseño, la calidad de la sesión cambia fundamentalmente.
Resumiré el contenido presentado en este artículo en un formato que puedas guardar y consultar.
- Los cuatro elementos—
/init+/compact+ modo plan + autoverificación—son los diseños básicos más fundamentales. - Sistematiza la reutilización de instrucciones con Habilidades Personalizadas y haz crecer
CLAUDE.mdcomo un «modelo vivo» actualizado semanalmente. - Cuando empieces a usar subagentes, la productividad pasará de la suma a la multiplicación.
- La regla de hierro es detectar la desviación temprano y detenerla inmediatamente. Siempre solicita evidencia en la primera salida.
- Puedes desarrollar múltiples funciones simultáneamente con
git worktrees+ sesiones en paralelo. - Configura la operación autónoma con
/loop, y confirma o instruye desde un teléfono inteligente con Control Remoto. ultrathinkes una herramienta dedicada al «10% realmente difícil». No es para cada problema.
Si pruebas aunque sea una de las funciones mencionadas en este artículo, tu relación con Claude Code comenzará a cambiar gradualmente.
Para aquellos interesados en los Agentes de IA
Swarm (@swarm_japan) comparte filosofías de diseño esenciales y casos de uso empresarial para agentes.
Síguenos para adquirir el conocimiento empresarial necesario para la era de los agentes de IA 👇
★ Explicando la información más reciente sobre agentes de IA desde una perspectiva única
★ Presentando casos de uso empresarial para agentes
★ Publicando know-how original
Si estás interesado, ¡síguenos y échales un vistazo! 👀
