En su artículo Claude Code is Great, Leo Godin formula una idea que me repito a mí mismo y a mis colegas al menos una vez por semana: using LLMs effectively is a skill we all need in 2026
. Estoy completamente de acuerdo, y creo que la mayoría de las discusiones online sobre LLM descarrilan porque la gente debate sobre los modelos en lugar de debatir sobre su propia habilidad para usarlos. He pasado el último año y medio con Claude Code como ingeniero DevOps, así que quiero repasar varias de sus tesis: dónde estoy de acuerdo, dónde añadiría mi propia experiencia y dónde discreparía con cuidado.
El contexto es la única habilidad que importa
Godin lo llama la Zona Goldilocks: ni demasiado, ni muy poco, justo lo necesario. Mi experiencia coincide. En la práctica he llegado a una división: las reglas globales viven en CLAUDE.md y se cargan en cada sesión, el conocimiento recuperable vive en un sistema de memoria aparte con un índice que se trae por relevancia. Una línea dura entre ambos: regla universal — CLAUDE.md; específica de proyecto o tema — memoria. Los duplicados están prohibidos porque divergen.
Por qué funciona: el modelo no recuerda lo que no le diste en el contexto. Cualquier intento de "meterlo todo por si acaso" termina con Claude perdiendo el hilo al quinto o sexto paso. Godin tiene una buena metáfora: treinta minutos hablando de café y queso antes de preguntar por Krokus, y el interlocutor obviamente no recordará a qué versión te referías. Con los LLM ocurre lo mismo.
Context management is the difference between success and failure.
Firmado. Solo matizaría: la disciplina con el contexto no es un esfuerzo puntual, es higiene continua. Una vez por semana reviso mi CLAUDE.md y el índice de memoria y tiro todo lo que está obsoleto. Sin esa rutina, cualquier sistema razonable se convierte en un cementerio de reglas en un mes — reglas que el modelo lee con diligencia y aplica con la misma diligencia, en el lugar equivocado.
El orquestador debe ser ciego
La sección más práctica es aquella en la que Godin afirma your job is orchestration, not comprehension
. Él lo integra en su skill implement-sprint; yo lo integro en mis equipos de agentes: el agente principal solo conoce el paso actual y tiene prohibido leer documentos de arquitectura. De eso se ocupan los sub-agentes ejecutores, cada uno con su propia ventana de contexto.
Este diseño es contraintuitivo desde la óptica humana. Un buen tech lead es precisamente quien mantiene el cuadro completo en la cabeza. Pero un orquestador LLM no es humano: cuanto más amplia es su vista, más rápido se degrada. Yo choqué con esa pared por mi cuenta antes de leer a Godin — mis skills power-plan y self-improve deambulaban por el proyecto hasta que convertí "lee solo estos dos archivos" en una regla explícita. El efecto coincide con el que él describe: la tarea se completa de forma autónoma en lugar de perder el rumbo constantemente.
"Culpa a los procesos, no a las personas ni a los LLM"
Godin propone un truco: cuando Claude entra en autoflagelación tras un fallo, lo redirige con I believe in blaming processes not people or LLMs
. Lo probé. Funciona. La magia no está en las palabras exactas. La magia está en que desplazas la atención del modelo de qué hice mal a qué del proceso permitió que esto pasara. Dos modos de razonamiento distintos, y el segundo es mucho más productivo.
Añado un truco contiguo: cuando una sesión descarrila, pido a Claude que analice su propio log — qué pasó, qué decisiones llevaron al callejón sin salida. De ese análisis sale después un cambio de proceso: una regla nueva en CLAUDE.md, una rama nueva en algún skill, un checklist nuevo. Sin ese bucle, las mejoras no se acumulan. Sin él, "los LLM se han vuelto más tontos" no es un diagnóstico del modelo — es el diagnóstico de una práctica de ingeniería que no existe.
Framework o andamiaje propio
Godin confiesa: probó Spec Kitty, BMAD, Open Spec — y se quedó con su propio starter. Yo también. Lo interesante no es el resultado, sino el argumento: un framework externo decreases your learning
. Es una postura rara y honesta. Una envoltura lista acelera tus primeras cinco tareas y frena tu crecimiento en las siguientes cincuenta — no entiendes por qué funciona, y cuando se rompe (nuevo modelo, nuevo release de Claude Code, cambio en el backend) no tienes herramienta para repararla.
Una salvedad, eso sí: escribir lo tuyo tiene sentido solo si usas la herramienta a diario. Para un script aislado o un proyecto de fin de semana, coge lo que ya está hecho. Para trabajo continuo, monta un andamiaje ligero y déjalo evolucionar. Mis /power-plan, /self-improve, /publish-note son justo eso — un andamiaje crecido a partir de dolores recurrentes concretos.
Donde discreparía
Godin escribe: /clear is your friend. /compact is not
. Acertado en espíritu, pero con un matiz. /compact no es malvado — es una herramienta con una ventana de utilidad estrecha. Si atrapas la sesión antes de la degradación (no cuando el modelo ya está confundido), la compactación funciona: conserva el hilo y te deja seguir. El problema no es el comando, es que la gente lo invoca demasiado tarde. Es un clásico fallo de percepción humana: solo notamos que el contexto está lleno cuando el modelo ya se ha descarriado — y entonces no queda nada que compactar.
Conclusión
Buen artículo. No sobre la herramienta — sobre la habilidad. Ahí está su valor: cura la frustración a través de la responsabilidad. Si hoy no funciona, hoy tu proceso está mal. Mala noticia y gran noticia a la vez: un proceso es reparable, una habilidad es entrenable, el contexto es podable. Esperar a que Anthropic "devuelva el Claude bueno" es inútil — nunca se fue.
El original es más corto que mi comentario y se lee fácil: Claude Code is Great. Recomendado.