Claude Code y Codex en paralelo: un pequeño experimento con Git worktree

Antes de encargar a Claude Code una revisión de textos mientras Codex corrige la exportación, dale a cada tarea su propio directorio de trabajo.

Si ambas conversaciones apuntan al mismo directorio, un archivo que modifica un agente se convierte en la entrada del otro. Al leer «las pruebas han pasado», puede que ya no sepas a qué cambios corresponde el resultado.

Actualizar una descripción en los ajustes y corregir la exportación de fechas vacías son tareas que puedes hacer en paralelo y revisar por separado. Este experimento reproducible muestra cómo preparar los directorios, repartir el trabajo y comprobar el resultado conjunto. El experimento lo ejecuta un script; los prompts son ejemplos que puedes adaptar a tu proyecto.

Define primero el alcance y los criterios de cada tarea

El proyecto de ejemplo contiene un archivo de textos de ajustes y una función que convierte marcas de tiempo en fechas para la exportación.

La tarea de textos modifica solo settings.zh-CN.json: cambia la descripción de «管理设备» por «查看已登录设备，并撤销不再使用的设备访问». La tarea de fechas corrige únicamente los valores ausentes y conserva la regla de exportar las marcas de tiempo válidas como fechas UTC.

Las cadenas en chino simplificado se mantienen para reproducir el experimento. La primera significa «Gestionar dispositivos»; la nueva descripción, «Ver los dispositivos con sesión iniciada y revocar el acceso de los que ya no se utilizan».

La función original es:

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

Para null devuelve 1970-01-01; con una cadena vacía lanza una excepción. Ningún resultado cumple el requisito de dejar vacías las fechas ausentes.

Ejecuta primero las cuatro pruebas: fallan los dos casos de valores ausentes y pasan los de marca de tiempo UTC y marca de tiempo con zona horaria. Esta referencia deja claro qué debe corregirse y qué comportamiento debe mantenerse.

Crea dos directorios desde el mismo commit

En un repositorio que ya tenga una rama main, confirma el commit de partida. Los siguientes comandos requieren que los nombres de las nuevas ramas y los directorios de destino no estén ya en uso:

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

Cada worktree tiene su propio directorio de trabajo e índice o área de preparación, y puede conservar cambios en una rama distinta. Todos pertenecen al mismo repositorio Git. Los directorios parten del commit indicado; los cambios sin commit del directorio original no se trasladan automáticamente. Prepara las dependencias y la configuración local según el proyecto. Consulta la documentación oficial de Git worktree.

Los directorios y ramas quedan así:

Cada tarea conserva su propia copia de trabajo disponible. Cambiar de rama dentro de un único directorio no proporciona esa separación.

Elige el directorio correcto para cada conversación en Tactic Remote

Conéctate al ordenador de desarrollo, abre la selección de proyecto en Nueva conversación (New Conversation) y, si es necesario, utiliza Elegir otra carpeta (Choose another folder) para seleccionar la ruta real del worktree. Después, elige el agente.

Si ya has creado los worktrees, selecciona sus directorios directamente. Crear un espacio de trabajo independiente (Independent Workspace) no incluye automáticamente ese repositorio ni su relación con la rama.

Puedes empezar con esta petición a Claude Code:

Modifica solo la descripción de dispositivos en settings.zh-CN.json para explicar que se pueden ver los dispositivos con sesión iniciada y revocar su acceso. Confirma primero el directorio y la rama. No cambies la exportación de fechas. Al terminar, muestra el diff de los textos y verifica que el JSON sea válido.

Y esta a Codex:

Corrige export-date.mjs: null y una cadena vacía deben devolver una cadena vacía, mientras que las marcas de tiempo válidas deben seguir exportándose como fechas UTC. Confirma primero el directorio y la rama, ejecuta las cuatro pruebas existentes, reproduce el problema y haz el cambio mínimo. No modifiques los textos de ajustes. Informa de los resultados antes y después.

Limitar los archivos en un prompt facilita la revisión, pero no crea un entorno aislado de seguridad. Los archivos que un agente puede leer y escribir dependen de sus permisos en el ordenador.

Comprueba cada tarea por separado

La corrección mínima del ejemplo comprueba las entradas ausentes antes de convertir la fecha:

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

Solo se tratan los valores ausentes acordados. El comportamiento de otras cadenas de fecha inválidas necesita una definición aparte. Las marcas de tiempo válidas siguen exportándose como fechas UTC.

En cada directorio, ejecuta:

git status --short
git diff --name-only
git diff

En este experimento, solo cambió settings.zh-CN.json en el directorio de textos y solo export-date.mjs en el de fechas. También leímos los archivos para confirmar que el directorio de textos conservaba la función original y que el de fechas conservaba los textos originales.

Los resultados reales fueron:

La rama de textos superó la validación JSON, pero mantuvo los dos fallos de fechas conocidos. Registra la situación inicial y el alcance de cada comprobación para que quien revise sepa qué demuestra el resultado.

Integra al final en una rama identificada

Una vez revisados y guardados ambos cambios mediante commits, crea una rama de integración en el directorio original del repositorio de ejemplo:

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

Se supone que el directorio original no tiene cambios pendientes y que ambas ramas de trabajo tienen sus commits. En un proyecto real, respeta su proceso habitual de pull requests y fusiones. Si hay conflictos, comprende primero las dos modificaciones y ejecuta después las comprobaciones conjuntas.

Verifica la fusión: los cambios pueden interactuar aunque cada rama pase sus propias pruebas. Separar directorios no elimina la necesidad de coordinar configuraciones, dependencias, bases de datos o puertos compartidos.

Cuando hayas confirmado que los cambios se conservan, que el árbol de trabajo está limpio y que los directorios ya no se usan, retíralos con git worktree remove. Si Git se niega porque hay cambios, atiende primero al contenido sin commit que indique.

En el teléfono, confirma la tarea y el resultado verificado

Para consultar tareas paralelas desde el móvil, confirma el ordenador, el proyecto y la conversación. Lee luego el último resultado e identifica las decisiones pendientes.

En los textos quizá solo debas confirmar un término. En las fechas puede ser necesario decidir entre UTC y hora local. Conserva la decisión en la conversación correspondiente para que su motivo esté disponible durante la revisión.

Puedes empezar con dos tareas: un directorio, una petición clara y un resultado de verificación para cada una, y una comprobación del comportamiento combinado. Al añadir más tareas, mantén identificables los directorios, las peticiones y los resultados.

El experimento se realizó en un repositorio Git local temporal, sin llamar a ningún agente. Puedes inspeccionar cada paso mediante el script de reproducción y los resultados originales.