Por qué abandoné los git worktrees haciendo vibe coding con Claude

Hace un mes empecé a usar git worktrees para trabajar con Claude Code en varias ramas a la vez. Era el patrón perfecto sobre el papel: una carpeta por rama, una instancia de Claude por carpeta, todas independientes, todas sincronizadas con el mismo repo. Tres ramas, tres ventanas, tres conversaciones en paralelo. Diez días después lo abandoné por completo.

Esto es lo que pasó, por qué la idea elegante no aguanta una sesión de vibe coding intensivo, y a qué patrón volví.

La promesa de los worktrees

Para quien no los conozca: git worktree permite tener varias copias del mismo repositorio en distintas carpetas, cada una en su propia rama, todas compartiendo el mismo .git. Así:

cd ~/Code/agentikas-blog          # main
git worktree add ../agentikas-feat-auth feat/auth
git worktree add ../agentikas-fix-images fix/images

# Tres carpetas hermanas, tres ramas distintas, cero clonado
ls ~/Code/
# agentikas-blog/   agentikas-feat-auth/   agentikas-fix-images/

El atractivo para vibe coding es obvio. Abres tres terminales. Lanzas Claude Code en cada una. La instancia de la rama feat/auth trabaja en autenticación. La de fix/images resuelve un bug de carga de imágenes. La de main revisa PRs y hace merges. Tres flujos simultáneos. Tu cerebro hace switching mental entre ventanas, no entre ramas.

Sobre el papel, es maravilloso. En la realidad, mi MacBook empezó a caer.

Lo que rompe en un monorepo Next.js

El primer problema apareció en la primera hora. Cada worktree tiene su propio node_modules hoisted. En un monorepo de tres apps con npm workspaces, eso son ~80.000 archivos por carpeta. Tres worktrees: 240.000 archivos en total, y Spotlight intentando indexarlos todos en paralelo (sí, ese mismo bug del MacBook arrodillándose — está en otro post).

El segundo problema fue más sutil. Cada worktree corría su propio npm run dev. Next.js genera .next/ con caché de build, manifests, hot module replacement state. Tres dev servers, tres carpetas .next/, tres servidores ocupando puertos distintos. Hasta aquí, manejable.

El tercer problema fue letal. Turbopack — el bundler nuevo de Next.js — tiene un caché global compartido en ~/.cache/turbo. Tres dev servers escribiendo a la misma carpeta de caché simultáneamente generaba race conditions imposibles de debuggear: builds que se rompían sin razón, hot reloads que mostraban contenido de otra rama, errores de "module not found" sobre módulos que sí existían. La caché no estaba diseñada para múltiples consumidores en paralelo.

Pasé dos sesiones intentando configurarlo bien. Variable TURBO_CACHE_DIR distinta por worktree. Lockfiles separados. Workspaces mode "isolated". Cada solución resolvía un problema y abría dos. Cuando me vi añadiendo wrappers de shell para "garantizar que el worktree usa su propia caché", entendí que estaba peleando contra el flujo.

Lo que hice antes — y a lo que volví

El patrón al que volví es radicalmente más simple: una sola checkout, switching de rama con git switch. Una instancia de Next.js corriendo en main. Una conversación con Claude. Cuando termino con una rama, hago commit, vuelvo a main, sigo.

El argumento contra esto era "pierdo paralelismo". Resultó ser falso. Lo que perdía con worktrees no era paralelismo de mi cabeza — era de la máquina. Mi cabeza no puede sostener tres conversaciones agénticas a la vez sin perder hilo. Aunque los worktrees estuvieran funcionando bien, mi calidad de decisión bajaba al saltar entre contextos.

Lo que sí gané: focus determinista. Una rama, una historia, una conversación con Claude que recuerda lo de hace cinco minutos porque está en el mismo proceso. Si necesito pausar una rama y empezar otra, hago git stash o commit-WIP, switcheo, hago lo nuevo, vuelvo. La fricción de switchear es de segundos, no de minutos.

Cuándo los worktrees sí valen

No estoy diciendo que los worktrees sean siempre mala idea. Hay tres escenarios donde sí compensan:

1. Code review serio. Quieres revisar un PR sin perder tu trabajo en curso. Un worktree dedicado a "review" donde haces git fetch && git checkout origin/feat/whatever es limpio. No interfiere con tu rama actual ni con tus build artifacts.
2. Comparación lado a lado. Quieres ver cómo cambia el comportamiento de la app entre dos versiones. Dos worktrees, dos servidores en puertos distintos, comparas en el navegador. No es para desarrollo continuo — es para una sesión específica.
3. Builds reproducibles que tardan. Si tu build tarda diez minutos y necesitas comparar resultados de dos ramas, dos worktrees con dos builds en paralelo es más rápido que builds secuenciales en la misma carpeta.

Para vibe coding diario en un monorepo Next.js — que es el caso del 90% de devs que considera worktrees por primera vez — la respuesta es no. La ganancia teórica no compensa el coste real en la máquina y en la cabeza.

La regla que me llevo

Después de este experimento, una regla que aplico a otras decisiones de tooling: antes de añadir paralelismo, verifica que tienes el problema que el paralelismo resuelve.

Los worktrees resuelven "necesito varias ramas activas a la vez sin recompilar". Esa es una afirmación específica. Si tu problema es "salto entre ramas y los compilados se invalidan", la respuesta puede ser tan simple como un build cache compartido (Turborepo lo da gratis) o aceptar la fricción de los rebuilds. No siempre necesitas un worktree para resolver una molestia menor.

El elegante git worktree add de mi terminal sigue ahí. No lo uso para vibe coding diario. Lo uso para revisar PRs y para comparaciones puntuales. Es la dosis correcta de la herramienta, no la dosis máxima.

---

Si vienes haciendo vibe coding con Claude Code y te tienta la promesa de los worktrees, prueba primero con una sola checkout y disciplina de git switch. La diferencia en consumo de máquina es enorme y la calidad de decisión sube. Solo si el flujo se queda corto, considera worktrees — y solo para los tres escenarios concretos de arriba.