Claude Code Projects: guía para coordinar tareas en paralelo

Claude Code Projects permite convertir una conversación en el centro de coordinación de un flujo de desarrollo: desde ahí, Claude abre y supervisa hilos independientes en la nube para cada tarea. La ventaja no está en acumular ventanas de chat, sino en dejar de repetir el contexto del repositorio, iniciar sesiones a mano y buscar qué rama o pull request requiere atención.

La experiencia rediseñada comenzó a desplegarse el 17 de septiembre de 2026 y el acceso todavía es limitado. Esta guía explica cómo comprobar si la cuenta ya tiene la beta, configurar un repositorio desechable, enviar dos tareas que no se superpongan, revisar el trabajo resultante y saber con precisión qué contexto recibe cada hilo.

Claude Code Projects coordina el trabajo; no es una carpeta

Un proyecto de Claude Code es una conversación persistente con Claude y el conjunto de sesiones en la nube que esa conversación inicia como hilos. Conviene imaginarlo como el jefe de un taller: recibe el encargo y distribuye los trabajos entre puestos separados. Cada puesto dispone de su propio espacio de trabajo, ventana de contexto y rama de Git; el coordinador recibe los informes y mantiene la cola ordenada.

No es lo mismo que la experiencia anterior de Projects en el chat de Claude y Cowork, diseñada para agrupar conversaciones y archivos de referencia. La nueva beta de Claude Code Projects incorpora un coordinador que reparte el trabajo entre hilos en la nube, sigue su estado y transmite el contexto del proyecto a cada hilo nuevo.

Cada hilo arranca con los repositorios y archivos del proyecto, sus instrucciones y memoria, el entorno en la nube seleccionado, los conectores de la cuenta y los archivos CLAUDE.md, skills y plugins presentes en los repositorios. No hereda las herramientas que solo existen en el equipo local.

Si ya se paga un plan de Claude compatible, el cálculo directo de software resulta favorable. Claude Pro cuesta $20 al mes, o $17 al mes con un pago anual de $200; Max parte de $100 al mes. Projects no añade un cargo independiente por la máquina virtual en la nube. La contrapartida es el consumo: cada hilo equivale a una sesión completa de Claude Code, de modo que trabajar en paralelo agota antes los límites del plan.

Como referencia, las suscripciones individuales de agentes de programación revisadas para esta guía van de $10 a $200 al mes entre GitHub Copilot y Cursor. Si Claude ya es el agente de programación, Projects no representa otro puesto que sumar a ese conjunto. Cambia la partida de coordinación, no la de criterio técnico.

Cómo comprobar si la cuenta tiene la beta de Claude Code

No basta con encontrar alguna función llamada Projects dentro de Claude.

1. Inicia sesión con una cuenta Claude Pro o Max.
2. Abre claude.ai/code o la pestaña Code en la aplicación de escritorio.
3. Busca Projects en la barra lateral izquierda.
4. Si no aparece, el despliegue todavía no llegó a esa cuenta. Es posible apuntarse a la lista de espera de Anthropic y usar sesiones normales en la nube mientras tanto.

La primera fase favorece a las cuentas Pro y Max que ya utilizaron sesiones en la nube y que no tienen los Projects anteriores en el chat de Claude o Cowork. Las cuentas Team y Enterprise todavía no cuentan con esta beta rediseñada. Los Projects anteriores siguen funcionando durante la migración de la experiencia.

Si aún falta instalar Claude Code, autenticarlo y darle contexto mediante un CLAUDE.md en el repositorio, conviene empezar por la guía general de configuración de Claude Code. Projects se apoya en esas prácticas del repositorio, no las sustituye.

Cómo configurar el primer proyecto de Claude Code

Lo mejor para la primera prueba es un repositorio pequeño de GitHub que pueda descartarse sin consecuencias. El objetivo consiste en observar cómo se reparten las tareas, qué contexto llega a cada hilo, cómo se crean las ramas y cuánto se consume; no en confiar una migración de producción a un coordinador que sigue en beta.

1. Resuelve el acceso a GitHub antes de crear el proyecto

Para trabajar con código, el repositorio debe estar alojado en github.com. La cuenta de GitHub conectada necesita permiso para hacer push y la aplicación Claude GitHub App debe estar instalada en ese repositorio. Un token creado mediante /web-setup puede permitir que una sesión normal en la nube clone un repositorio, pero no basta para un hilo de proyecto.

En esta beta no se admiten repositorios de GitHub Enterprise Server, GitLab ni Bitbucket como repositorios de código del proyecto. Si el repositorio pertenece a una organización, quizá un propietario deba aprobar tanto la instalación de GitHub App como la autorización SSO.

2. Crea un proyecto con alcance reducido

Abre Projects, selecciona New project y añade:

• Name: un nombre que deje claro que se trata de una prueba, por ejemplo Parser Project Test.
• Goal: una sola frase, como Improve parser coverage and documentation without changing behavior.
• Context: únicamente el repositorio desechable.

El único campo obligatorio es el nombre. Un objetivo acotado marca un límite útil para el coordinador, y trabajar con un solo repositorio evita las diferencias de configuración propias de los proyectos con varios repositorios.

3. Añade una instrucción permanente

Entra en Project settings > Memory > Project instructions. Todos los hilos deberían recibir la misma definición de trabajo terminado y los mismos límites de aprobación. Por ejemplo:

Parte de la rama predeterminada. Usa una rama por hilo. Ejecuta las pruebas pertinentes antes de informar que el trabajo está terminado. No fusiones ramas, cambies el CI ni añadas dependencias sin consultarlo en el hilo. Si falta acceso, indica exactamente qué elemento falta y detente.

Las instrucciones del proyecto pueden tener hasta 16,000 caracteres, aunque para la primera prueba conviene mantenerlas breves. Los comandos de compilación específicos del repositorio deben permanecer en su CLAUDE.md. Los requisitos, las decisiones y los problemas descubiertos a lo largo del proyecto pertenecen a la memoria del proyecto.

4. Revisa el entorno en la nube

Abre Project settings > Environment. Todos los hilos nuevos utilizan el entorno elegido en esta sección, que determina el acceso a la red, las variables de entorno, las credenciales de API y las herramientas instaladas por un script de configuración.

El entorno predeterminado alojado por Anthropic puede acceder a una lista de servicios habituales y ya incluye varias herramientas. Eso no le concede acceso automático a la base de datos local, la VPN, el emulador de dispositivos, la configuración de shell ni las credenciales que solo están en el equipo. El entorno debe configurarse antes de encargar tareas que dependan de cualquiera de esos recursos.

5. Envía dos tareas que no puedan entrar en conflicto

Incluye las dos tareas en un único mensaje para comprobar cómo el coordinador separa trabajos sin relación entre sí. Procura que afecten archivos distintos. Por ejemplo:

Empieza ahora sin pedir confirmación. Crea un hilo para añadir pruebas unitarias de entradas incorrectas del parser. Crea un segundo hilo para corregir ejemplos desactualizados en la guía de la API. No cambies el comportamiento del parser en producción ni fusiones ninguna de las ramas.

Según Anthropic, varias tareas independientes incluidas en un mensaje se convierten en hilos distintos. Cada hilo de código crea una rama a partir de la rama predeterminada del repositorio, salvo que se le indique otra cosa. Separar los archivos es importante porque dos ramas distintas aún pueden generar conflictos si ambos hilos modifican el mismo código.

6. Revisa los hilos, no solo el resumen del coordinador

Abre la tarjeta de cada hilo y registra lo siguiente:

Overview agrupa el trabajo en Ready for review, Waiting on you, Working, Landing, Idle y Resolved. Las otras pestañas reúnen los archivos del proyecto, los pull requests y las rutinas. El coordinador recibe los informes de cada hilo, pero no observa todos sus pasos; para auditar el trabajo sigue siendo necesario consultar la transcripción del hilo.

7. Comprueba si el trabajo posterior recibe el contexto guardado

Cuando terminen ambos hilos, pide al coordinador que recuerde una regla inocua, como Documentation changes must preserve every runnable example. Después abre un hilo nuevo y pequeño de documentación, y solicita que indique la regla de ramas y la regla de documentación del proyecto antes de editar.

Así se ponen a prueba dos rutas de contexto diferentes. Las instrucciones del proyecto deberían llegar a cada hilo nuevo como una directriz fija. La memoria del proyecto debería transmitir la decisión guardada a través de MEMORY.md. El CLAUDE.md de cada repositorio constituye una tercera capa independiente para las reglas propias del código.

Qué contexto recibe cada hilo y qué se queda fuera

El error más común al interpretar Projects es pensar que un hilo en la nube equivale a una copia remota del equipo local. No es así: se trata de una sesión nueva en la nube, construida con contexto del proyecto, el repositorio, la cuenta y el entorno.

Los proyectos con varios repositorios tienen una trampa importante. Se cargan los archivos CLAUDE.md, las skills y los plugins de todos los repositorios, pero no sus reglas de permisos, hooks ni ajustes de env. Las reglas que atraviesen varios repositorios deben ir en las instrucciones del proyecto, y las variables de entorno, en el entorno en la nube.

Los hilos paralelos de Claude Code no son ilimitados

Anthropic no documenta una cantidad fija de hilos que puedan ejecutarse al mismo tiempo. Se puede pedir al coordinador que ejecute dos de forma simultánea, pero es una preferencia, no una cuota obligatoria. El límite estricto independiente es de 200 hilos nuevos al día entre todos los proyectos.

Los hilos activos consumen el plan. El coordinador también lo utiliza mientras lee informes y decide el siguiente paso. Un hilo que vigila un pull request vuelve a activarse —y a consumir el plan— cuando falla el CI o aparece un comentario de revisión. Un proyecto inactivo, sin hilos en ejecución, pull requests vigilados ni mensajes nuevos, no consume nada mientras permanece en espera.

En los proyectos nuevos, la configuración predeterminada asigna Opus con esfuerzo alto a los hilos y esfuerzo bajo al coordinador. Antes de lanzar un lote grande, abre Project settings > General y elige el modelo y el nivel de esfuerzo menos costosos que puedan resolver cada trabajo. Luego solicita una concurrencia pequeña. La cifra útil no es cuántos hilos puede abrir Projects, sino cuántos resultados se pueden revisar antes de que la cola se convierta en ruido.

Los siete casos de uso que más aprovechan Claude Code Projects

1. Un responsable de plataforma coordina una migración con varios repositorios

Conecta los repositorios de servidor, web y aplicaciones móviles, y define para el proyecto un único objetivo: retirar un endpoint obsoleto. Varios hilos pueden actualizar cada cliente en ramas separadas mientras el coordinador controla el orden y los bloqueos. La ventaja es tener una sola cola de revisión en vez de sincronizar manualmente tres sesiones de agentes. Es el mejor encaje porque el objetivo dura más que una sesión y el trabajo puede dividirse con claridad por repositorio.

2. Un mantenedor gestiona la cola de errores de un servicio

A medida que llegan nuevos informes de errores y trazas de pila, el mantenedor puede pegarlos en el mismo proyecto. El coordinador puede dirigir una regresión al hilo que ya investiga esa zona o iniciar otro con los problemas conocidos que guarda la memoria del proyecto. Se repiten menos instrucciones y queda un registro duradero de cada error pendiente de acceso, revisión o decisión.

3. Un responsable de lanzamiento ejecuta controles independientes

Asigna a hilos distintos la suite de pruebas, los enlaces de documentación, la auditoría de dependencias y el borrador de notas de la versión. Mantén cada tarea en modo de solo lectura hasta revisar los hallazgos. El coordinador puede mostrar qué pasó las comprobaciones y qué requiere una respuesta sin mezclar toda la evidencia en una transcripción enorme. Así se acorta el camino entre la lista de control y la decisión, que sigue en manos del responsable del lanzamiento.

4. Un responsable de refactorización divide un cambio grande por límites

Si una migración supera una ventana de contexto, asigna módulos o paquetes independientes a hilos separados y coloca la condición invariable en las instrucciones del proyecto. Cada hilo valida su propia rama e informa al coordinador. El resultado es avance en paralelo con una definición común de trabajo terminado. El riesgo está en las dependencias arquitectónicas: dos ramas que toquen la misma abstracción compartida aún pueden producir conflictos de fusión normales.

5. Un ingeniero de agencia mantiene la aplicación de un cliente

Crea un proyecto privado para el repositorio, las instrucciones y el entorno de un solo cliente. Durante el trabajo, aliméntalo con pequeñas correcciones, solicitudes de revisión y tareas de documentación. Así se conserva la continuidad sin mezclar el contexto de varios clientes. En la beta, cada proyecto pertenece a un solo usuario y no puede compartirse; funciona como cabina personal de entrega, no como portal de colaboración con el cliente.

6. Un responsable de soporte analiza errores de integración recurrentes

Projects no exige un repositorio. Es posible cargar una exportación de tickets de soporte y la documentación de integración, y después encargar a varios hilos que clasifiquen los errores, verifiquen los ejemplos y redacten un informe de corrección. Los archivos producidos aparecen en Library. La ventaja es disponer de un cuerpo de contexto reutilizable y de rastros de evidencia separados para el análisis y la redacción.

7. Un fundador en solitario despeja una lista de pendientes variada

Envía un lote pequeño con una tarea de pruebas, otra de documentación y una auditoría del repositorio. Indica al coordinador que solo ejecute dos hilos y que proponga cualquier cambio destructivo antes de realizarlo. El beneficio está en la atención: el fundador revisa ramas ya terminadas en lugar de vigilar cada sesión. El encaje es malo si todas las tareas necesitan el mismo archivo o un servicio al que solo se puede acceder desde el equipo del fundador.

Tres productos complementarios que vale la pena crear

La beta no ofrece una API documentada de Projects, así que, a corto plazo, las oportunidades razonables están junto al flujo de trabajo. Estos productos pueden preparar el contexto, inspeccionar el estado de GitHub o facilitar la revisión humana de los resultados.

1. Project Readiness Auditor, la oportunidad más sólida

Desarrolla una aplicación de GitHub de solo lectura que determine si un repositorio está listo para agentes de programación en la nube. Revisaría las instrucciones del repositorio, los comandos de prueba, las protecciones de ramas, la cobertura de GitHub App, los secretos necesarios y las dependencias de red; después generaría un borrador de instrucciones para el proyecto y una lista de control del entorno en la nube.

La demanda de esta tarea ya es visible: la consulta “ai powered coding agent” registra 8,100 búsquedas mensuales en Estados Unidos con intención comercial. Los planes individuales oficiales de agentes de programación revisados para esta guía cuestan entre $10 y $200 al mes, pero pagar una licencia no convierte un repositorio en un entorno seguro para trabajar con varios agentes en paralelo.

La versión mínima que puede venderse analiza un repositorio de GitHub, plantea seis preguntas sobre el entorno y exporta instrucciones listas para pegar. El riesgo es la plataforma: Anthropic o GitHub podrían incorporar rápidamente sus propias comprobaciones, por lo que el producto necesitaría compatibilidad con varios agentes y un historial de auditorías útil, no una única plantilla para Claude.

2. Tablero del ciclo de entrega con IA

Crea un tablero respaldado por GitHub que agrupe ramas, pull requests, estado del CI, comentarios de revisión y aprobaciones humanas según el objetivo de entrega. Serviría a un responsable técnico que utiliza varios agentes de programación y necesita una superficie neutral para revisar su trabajo.

“AI software development life cycle” registra 720 búsquedas mensuales en Estados Unidos, tiene dificultad de palabra clave 4 y un CPC de $18.13. La versión más pequeña puede leer eventos de GitHub y convertirlos en cuatro estados: en curso, bloqueado, listo e integrado. No necesita acceso privado a la transcripción de un proyecto de Claude.

El desafío es diferenciarse. GitHub y los proveedores de agentes ya muestran buena parte de ese estado. El producto solo destaca si conecta el trabajo entre distintos proveedores, conserva evidencia de las aprobaciones y explica por qué un cambio está bloqueado en vez de limitarse a dibujar una cola más atractiva.

3. Enrutador automático de políticas de revisión

Crea una aplicación de GitHub que aplique la política de revisión propia de cada repositorio a los pull requests generados por agentes. Podría exigir un artefacto de prueba cuando cambia el parser, enviar los cambios de facturación a una persona concreta e impedir que comentarios de corrección automática activen automatizaciones con privilegios.

“Automated code review” registra 210 búsquedas mensuales en Estados Unidos y alcanza un CPC de $63.33, una señal fuerte de que esta audiencia más pequeña tiene una intención valiosa. El MVP requiere un archivo de políticas, una comprobación de pull request y una explicación breve de las evidencias que faltan.

También existe solapamiento. Los hilos de Claude ya vigilan pull requests y reaccionan a errores del CI y comentarios de revisión. Un producto nuevo debe gobernar el riesgo entre diferentes agentes y repositorios, no imitar a otro bot de revisión.

Lo que Claude Code Projects no resuelve

Projects funciona mejor cuando el trabajo puede dividirse y el contexto necesario cabe en GitHub, archivos cargados, conectores o un entorno en la nube. No es la herramienta adecuada para una corrección puntual que cabe en una sola sesión, un trabajo vinculado a un dispositivo local o una VPN, ni un equipo en el que varias personas necesitan dirigir el mismo proyecto.

Tampoco elimina los riesgos habituales de entrega:

• Los hilos separados pueden generar conflictos de fusión cuando sus ramas se superponen.
• Pedir cierta concurrencia es una instrucción para el coordinador, no un control estricto del presupuesto.
• Los hilos paralelos pueden consumir con rapidez los límites de Pro.
• Un sandbox en pausa puede reanudarse desde un clon nuevo, por lo que el trabajo sin commit podría perderse.
• La beta es personal: no permite compartir proyectos ni ofrece controles para toda la organización.
• Un hilo no puede moverse después a otro proyecto.

La conclusión es sencilla: conviene usar Projects para coordinar trabajos que puedan separarse, no para delegar la arquitectura ni la aprobación. Empieza con dos tareas, revisa ambas transcripciones y aumenta la concurrencia solo cuando las ramas y el consumo sean previsibles.

Preguntas frecuentes sobre Claude Code Projects

¿Claude Code tiene acceso a Projects?

Algunas cuentas Claude Pro y Max ya pueden utilizar la beta rediseñada de Projects en claude.ai/code, en la pestaña Code de la aplicación de escritorio y en las aplicaciones móviles de Claude. Si Projects no aparece en la barra lateral de Code, el despliegue aún no llegó a esa cuenta. El comando de terminal claude project administra un estado de directorio local que no guarda relación con esta función.

¿Cómo se usa Projects en Claude Code?

Crea un proyecto en Claude Code, añade un objetivo y el mínimo de repositorios o archivos necesarios, redacta una instrucción permanente breve, elige el entorno en la nube y envía una o más tareas a la conversación del coordinador. Antes de fusionar cambios, revisa cada hilo en Overview y comprueba su rama, transcripción, validación y consumo.

¿Claude Code puede trabajar en un proyecto existente?

Sí. Se puede crear un proyecto a partir de un repositorio existente en github.com o elegir Continue as a project desde una sesión existente en la nube. Para usar un repositorio de código, la cuenta de GitHub conectada necesita acceso de escritura y la aplicación Claude GitHub App debe estar instalada en ese repositorio.

¿Cuál es la diferencia entre Claude Projects y Claude Code?

Claude Code es el agente de programación que funciona en una sesión local o en la nube. Un proyecto rediseñado de Claude Code añade la capa de coordinación: una conversación inicia y supervisa varias sesiones de Claude Code en la nube, les entrega contexto común del proyecto y recopila su estado. Hasta que la migración llegue a esas cuentas, los Projects anteriores del chat de Claude y Cowork mantienen el modelo de espacio de trabajo para archivos y conversaciones.

Si se necesita un flujo de agentes listo para trabajar con los repositorios, las aprobaciones y el entorno en la nube de una organización, consulta sistemas de IA para producción.