Claude Code en 2026: las capas importan más que las herramientas

Instalé gstack, Superpowers y Compound Engineering en la misma semana. Tres extensiones de Claude Code bien valoradas, cada una con sus propios seguidores. Mi expectativa era un efecto acumulativo en la productividad. Lo que obtuve fue funcionalidades solapadas, huecos en la cobertura y la sensación persistente de que estaba coleccionando herramientas sin ningún marco para evaluarlas.

Después de unos días ejecutando las tres a la vez, encontré el verdadero problema. No era malo eligiendo herramientas. Era malo viendo las capas.

Cómo se manifiestan las capas en la práctica

La programación asistida por IA ha desplazado el papel humano: de escribir código a coordinar agentes. Coordinar exige un modelo mental, y el que por fin me cuadró tiene tres capas: decisión, proceso y conocimiento. Cada herramienta que analicé era fuerte en una capa y débil en las demás. Una vez que lo vi, tanto los solapamientos como los huecos tenían sentido.

La capa de decisión

El comando /plan-ceo-review de gstack examina el trabajo desde una perspectiva de producto. /plan-eng-review lo examina desde una perspectiva de arquitectura. Ambos se ejecutan antes de escribir una sola línea de código. El objetivo es matar las malas ideas a tiempo.

Esperaba que la fase de codificación fuera el cuello de botella. No lo era. El mayor sumidero de tiempo era construir funcionalidades que nunca deberían haberse empezado. Tras dos semanas usando las puertas de validación de gstack, comprobé que la diferencia de calidad venía menos de escribir mejor código y más de escribir menos código innecesario. Se dice que Garry Tan entregó 600 000 líneas en 60 días con esta configuración. El comando /qa abre un navegador real y navega por la aplicación como un usuario, detectando problemas que los tests unitarios pasan por alto por completo.

Donde gstack se queda corto: no tiene memoria entre sesiones. Cada revisión empieza desde cero.

La capa de proceso

Superpowers estructura el trabajo en un ciclo de brainstorming, planificación, ejecución y revisión. Las 120 000 estrellas en GitHub están bien ganadas. Pasar de “pedirle a la IA que lo haga” a un flujo de trabajo repetible supuso una diferencia inmediata en la consistencia de los resultados.

Supuse que eso sería suficiente. No lo fue. El flujo funciona bien dentro de una sesión, pero en cuanto empecé una nueva sesión al día siguiente, todo lo que había aprendido había desaparecido. Se incluyen revisores de especificaciones y revisores de calidad de código basados en subagentes, y funcionan bien. Pero ninguna parte del sistema registra lo que ocurrió ayer para informar lo que ocurre hoy.

La capa de conocimiento

El comando /ce:compound de Compound Engineering se ejecuta después de terminar una tarea. Cinco subagentes se activan en paralelo: rastrean el contexto de la conversación, extraen la solución, comprueban si hay documentación duplicada, generan una estrategia de prevención y categorizan el resultado. Todo aterriza en docs/solutions/.

Una semana después de empezar a usarlo, me topé con un error similar a uno que ya había resuelto. Durante la fase de planificación, el sistema encontró el registro anterior y presentó la solución. Una sesión de depuración que habría llevado horas tardó unos minutos. /ce:review ejecuta al menos seis revisores independientes en paralelo. /ce:plan consulta los registros de git y el historial del proyecto antes de proponer nada.

Si los archivos de progreso de Anthropic son notas de traspaso entre trabajadores, el docs/solutions/ de Compound Engineering es un recetario que todo el equipo consulta a diario.

Encontrar la capa vacía propia

La cuestión no es que debas instalar estas tres herramientas concretas. La cuestión es que, una vez que puedes ver las tres capas, puedes evaluar cualquier herramienta, o construir la tuya propia.

Estuve usando las tres juntas durante una semana antes de darme cuenta de que la redundancia estaba concentrada en la capa de proceso mientras la capa de conocimiento llevaba meses vacía. Identificar ese hueco resultó más útil que cualquier funcionalidad individual de cualquiera de las herramientas.

Mira tu propio flujo de trabajo. ¿Hay una puerta de decisión que frene las malas ideas antes de que se conviertan en código? ¿Hay un proceso definido que funcione igual cada vez? ¿Hay un sistema de conocimiento que recuerde lo que aprendiste la semana pasada? Encuentra primero la capa vacía. Luego rellénala, aunque eso signifique escribir tú mismo un único archivo SKILL.md en lugar de instalar el framework de otro.

La capacidad de ver las capas durará más que cualquier herramienta concreta del ecosistema.