Hace menos de un mes escribí un post entero explicando cómo usar tres capas de memoria con Claude Code: Linear para estrategia, Beads para táctica y Tasks para ejecución. Una pirámide bonita y elegante.
Pues va a ser que no.
Hoy jubilo Beads. Y no por capricho, sino porque la realidad se ha encargado de demostrarte que una herramienta que te da más problemas de los que resuelve no es una herramienta. Es un lastre.
Qué aportaba Beads
Para quien no leyese el post original, Beads era un issue tracker git-backed. Un plugin para Claude Code que almacenaba issues en ficheros JSONL dentro de tu repo. La idea era brillante sobre el papel:
- Persistencia en git: los issues vivían en
.beads/y se commiteaban con tu código. - Dependencias: un issue podía bloquear a otro.
- Offline: funcionaba sin conexión.
- El LLM lo veía directamente: sin APIs, sin configuración. El agente leía los ficheros y ya.
La promesa: una capa intermedia entre «lo que quiero hacer esta semana» (Linear) y «lo que estoy haciendo ahora mismo» (Tasks). El pegamento táctico.
Qué fue mal
Todo fue bien hasta que dejó de ir bien. Y dejó de ir bien de formas creativas.
El daemon del infierno
Beads corre un daemon en background para gestionar la base de datos SQLite y sincronizar con git. Suena razonable. En la práctica:
DATABASE MISMATCH DETECTED!
This database belongs to a different repository:
Database repo ID: d1f9ca0c
Current repo ID: 01eac8ea
⚠️ CRITICAL: This mismatch can cause beads to incorrectly
delete issues during sync!
Ese mensaje te sale al arrancar cualquier sesión. El daemon falla, la sincronización falla, y te quedas con issues que existen en tu SQLite local pero no en git, o al revés. Un estado cuántico de bugs: tus issues están y no están a la vez.
La sincronización fantasma
bd sync es el comando para sincronizar tus issues con el remoto git. Excepto cuando no funciona:
→ Pulling from remote...
Error: pulling: git pull failed: exit status 1
remote: Repository not found
fatal: repository 'https://git.frr.dev/frr/wuwei.git/' not found
Resulta que beads coge el remote de git, pero si tienes varios remotes (cosa común), puede elegir el equivocado. Y si ese remote apunta a un repo que no existe o ha cambiado de nombre, el daemon te escupe errores en cada operación. Silenciosamente, tus issues dejan de sincronizarse y no te enteras hasta que abres otra sesión y todo ha desaparecido.
El coste cognitivo
Cada sesión con Claude Code empezaba así:
- Claude lee el prompt de beads (inyectado vía hooks)
- El daemon intenta arrancar
- Falla con un error de mismatch
- Claude intenta
bd sync - Falla con un error de remote
- Tú le dices «ignora eso»
- Ahora sí, a trabajar
Seis pasos de fricción antes de hacer nada productivo. Seis pasos que consumen contexto, tiempo y paciencia.
Lo que ha cambiado
Dos cosas han hecho que Beads pase de «herramienta útil con bugs» a «overhead innecesario»:
1. Tasks ha madurado
Cuando escribí el post de las tres capas, Tasks era básico. Ahora tiene:
TaskCreatecon descripciones, activeForm para spinners, y metadatosTaskUpdatecon dependencias (addBlocks,addBlockedBy)TaskListyTaskGetpara inspección- Persistencia opcional entre sesiones con
CLAUDE_CODE_TASK_LIST_ID
Dicho en cristiano: Tasks ya hace todo lo que Beads hacía para el trabajo intra-sesión. Y lo hace sin daemon, sin SQLite, sin sincronización git, y sin errores fantasma.
2. Linear CLI ha llegado
El MCP de Linear era, siendo generoso, una mierda. Intermitente, lento, y con una manía especial por fallar justo cuando más lo necesitabas.
La alternativa era el API a pelo con GraphQL. Que funciona, sí, hasta que intentas meter caracteres especiales en las descripciones de los issues:
# Intento 1: bash con interpolación de strings
# Resultado: JSON roto por paréntesis y flechas
# Intento 2: Python con urllib
# Resultado: 401 porque op read no se evalúa dentro de Python
# Intento 3: llorar un poco
# Resultado: catártico pero improductivo
Y entonces descubrí linear CLI:
brew install schpet/tap/linear
linear auth login -k "$(op read 'op://FRR DEV/Linear/api-key')"
Y crear un issue se convierte en:
linear issue create --team RST --no-interactive \
-t "Port: agent/loop" \
--project "Phase 1: Core Loop" \
--priority 1 \
-l port \
-d "Port agent loop (476 LOC). Heart of the agent."
Sin escaping de GraphQL. Sin daemon. Sin sincronización rota. He creado 49 issues en menos de un minuto con un script de bash. Con el MCP de Linear y con la API habría tardado una hora y media de peleas con el escapado de caracteres.
La nueva pirámide (que ya no es pirámide)
El modelo de tres capas era bonito. Pero la realidad es que dos capas son suficientes:
| Necesidad | Antes | Ahora |
|---|---|---|
| Visión estratégica | Linear (MCP/API) | Linear (linear CLI) |
| Trabajo táctico | Beads | Linear (linear CLI) |
| Ejecución en sesión | Tasks | Tasks |
Linear + su CLI cubre estrategia y táctica. Tasks cubre ejecución. Beads no cubre nada que no cubran mejor las otras dos.
Antes:
Linear (semanas) → Beads (días) → Tasks (horas)
Ahora:
Linear (semanas/días) → Tasks (horas)
Menos capas, menos fricción, menos cosas que se pueden romper.
Lección aprendida
Esto me recuerda a algo que digo siempre: la complejidad innecesaria es el enemigo silencioso. Beads resolvía un problema real (la amnesia del LLM entre sesiones), pero lo hacía añadiendo una capa de infraestructura que, a la larga, generaba más problemas que los que resolvía.
Es la misma historia de siempre en ingeniería: la solución correcta a veces no es añadir algo, sino darte cuenta de que lo que ya tienes ha mejorado lo suficiente como para no necesitarlo.
El MCP de Linear era una mierda → llegó el CLI. Tasks era básico → maduró. Beads quedó en medio, sin hueco.
El rm -rf definitivo
rm -rf .beads/
git add -A && git commit -m "chore: remove beads"
Dos líneas. Así se jubila una herramienta. Sin ceremonia, sin drama.
Beads fue útil mientras lo fue. Ahora ya no lo es. Y eso está bien.
TL;DR: Retiro Beads de mi flujo de trabajo con Claude Code. El CLI de Linear (schpet/linear-cli) resuelve la gestión de issues sin los dolores del MCP ni del API GraphQL. Tasks ha madurado lo suficiente para cubrir el tracking intra-sesión. Dos capas bastan: Linear para estrategia y táctica, Tasks para ejecución.
Posts anteriores sobre el tema: – Linear y Beads: cómo evitar que tu IA tenga Alzheimer – Linear, Beads y Tasks: tres capas de memoria para Claude Code
Read this article in English.
