Cancelar la suscripción a Claude como solución de productividad

David Wilson publicó esta semana una entrada que ya circula bastante: lista más de 16 proyectos que arrancó con herramientas de IA sin haberlo planeado. El patrón que describe es reconocible: empieza una sesión con Claude para «escribir un script rápido», y una hora después tiene un proyecto a medias, el problema original sin resolver y tres pestañas nuevas abiertas.

Simon Willison recogió el hilo en su blog el 31 de mayo y añadió que él mismo lo experimenta: los agentes de código son especialmente hábiles para llevarte de una idea vaga a una implementación parcial sin que hayas decidido conscientemente empezar un proyecto nuevo.

El diagnóstico de Wilson: «amplificador termonuclear de ADHD»

La frase de Wilson es dura pero precisa. Describe ver a amigos trabajando con tres pantallas en proyectos sin relación entre sí, proyectos que probablemente no van a mantener y a los que tienen tan poco compromiso que el tiempo invertido se evapora. No es una crítica a la tecnología en abstracto; es una observación sobre cómo el bajo coste de arrancar algo con un agente elimina la fricción que antes actuaba como filtro natural.

Antes, montar un proyecto implicaba configurar el entorno, escribir el boilerplate, tomar decisiones de arquitectura. Ese coste hacía que solo arrancases lo que de verdad querías terminar. Con Claude Code y un modelo como Sonnet 4.6 o Haiku 4.5 generando el scaffolding en segundos, ese filtro desaparece. El resultado no es más productividad; es más superficie de trabajo sin más capacidad de cerrarlo.

Por qué importa más allá del caso individual

Este tipo de reflexión tiene relevancia práctica para equipos que han adoptado agentes de código en su flujo de trabajo. Si una persona sola puede acumular 16 proyectos inacabados en unos meses, un equipo pequeño puede generar una deuda de contexto y mantenimiento difícil de gestionar.

El problema no es exclusivamente de atención personal. Es también estructural: los agentes son muy buenos en el arranque y notablemente peores en el cierre. Generan código funcional para el caso feliz con rapidez, pero depurar, documentar, integrar tests y llevar algo a producción requiere un tipo de atención sostenida que el formato «sesión de chat» no favorece.

Willison apunta que la solución que propone Wilson —cancelar la suscripción— es más una metáfora que un consejo literal. El punto real es que usar estos modelos sin una disciplina previa sobre qué problema estás resolviendo y cuándo consideras que está resuelto es una forma segura de acumular deuda sin activo.

Qué hacer con esto

Algunas prácticas que han emergido en la comunidad para contrarrestar el efecto:

• Definir el criterio de salida antes de abrir la sesión. ¿Qué tiene que ocurrir para que puedas cerrar el chat y marcar la tarea como hecha?
• Separar exploración de ejecución. Una sesión para entender el problema, otra distinta para implementar. No mezclarlas reduce la deriva.
• Tratar los proyectos generados por agente como prototipos por defecto, no como código de producción, hasta que deliberadamente decidas lo contrario.
• Revisar el historial de proyectos mensualmente. Si más de la mitad están sin uso activo, el problema no es la herramienta: es el proceso de selección previo.

Nada de esto es nuevo en gestión de proyectos. Lo nuevo es que la velocidad de los agentes hace que la falta de disciplina tenga consecuencias visibles mucho antes.

---

Desde nuestra perspectiva en ElephantPink, la conversación que abren Wilson y Willison es más útil que la mayoría de los tutoriales de productividad con IA: pone el foco en el coste oculto de la facilidad, que es exactamente lo que pocos quieren discutir cuando están vendiendo suscripciones.