No es una herramienta. Son tres.
El error de base que contamina todo lo demás.
Cuando la gente habla de "usar Claude" habla como si fuera una sola cosa. No lo es. Yo trabajo con tres versiones distintas, cada una con un objetivo concreto y una forma de operar diferente.
Mezclarlas sin entenderlas no es un error menor. Es la causa del 80% de las frustraciones que veo — y que viví yo — cuando algo no funciona como se espera.
No es que Claude falle. Es que estás usando la herramienta equivocada para la tarea equivocada.
Claude.ai — el cerebro
Es el Claude del navegador. El chat. Donde piensas, construyes, redactas, diseñas sistemas, generas código, trabajas con proyectos. Es donde vive toda la arquitectura de contexto: instrucciones, memoria, archivos, especificaciones.
Es la herramienta más versátil de las tres. Y la que más contexto necesita para funcionar bien. Si el contexto está sucio — instrucciones contradictorias, memoria obsoleta, archivos desactualizados — los resultados son impredecibles. No porque Claude sea malo. Porque está leyendo un mapa que tú dejaste caducar.
Para qué lo uso
Todo lo que requiere pensamiento, estructura y creación. Artículos, sistemas, estrategia, código base, contenido. Es mi centro de operaciones.
Claude Cowork — el ejecutor
Cowork es un agente autónomo. No conversa contigo — actúa. Abre el navegador, hace clic, rellena formularios, ejecuta tareas en tu ordenador mientras tú haces otra cosa.
Opera con mucha más autonomía que Claude.ai. Si no le das instrucciones muy precisas sobre cuándo parar y confirmar, no para. Crea archivos sin preguntar. Ejecuta acciones sin confirmación. Avanza.
Lo que parece un fallo no siempre lo es
Si Cowork hace algo que no esperabas, probablemente no lo definiste con suficiente precisión. No es que Claude "haga cosas sin permiso" — es que tú no le dijiste dónde parar. Eso no es un fallo de la herramienta. Es un fallo de las instrucciones.
Para qué lo uso
Automatizar tareas repetitivas y concretas con instrucciones muy cerradas. Cuando intenté usarlo para tareas abiertas y complejas, fue cuando empezaron los errores.
Claude Code — el constructor
Claude Code es una herramienta de línea de comandos. Vive en el terminal. Está diseñada para desarrollo de software: construir, editar y ejecutar código en proyectos reales.
Es la más potente de las tres para trabajo técnico. Y la más exigente. No perdona el caos. Si tu entorno no está limpio, si las dependencias no están bien configuradas, si el contexto del proyecto no es preciso — falla. Y cuando falla en producción, falla de verdad.
Para qué lo uso
Construir sistemas técnicos complejos: agentes, automatizaciones, infraestructura. Pero aprendí a usarlo después de haberlo quemado una vez.
Qué modelo usar y para qué
Dentro de cada herramienta, no todos los modelos son iguales. Elegir mal tiene coste.
Anthropic publica varios modelos dentro de la familia Claude. Opus, Sonnet, Haiku. Cada uno tiene un perfil distinto de velocidad, coste y capacidad. Y dentro de cada herramienta — Claude.ai, Code, Cowork — la elección del modelo cambia el resultado.
Esta es la lógica que uso en producción real. No la que dice el marketing. La que funciona cuando tienes sistemas corriendo y no puedes permitirte pruebas de coste sin cabeza.
La tabla completa con la decisión herramienta + modelo:
| Herramienta | Modelo recomendado | Para qué | Cuándo subir de modelo |
|---|---|---|---|
| Claude.ai (chat) | Sonnet — uso diario | Redacción, estrategia, código base, diseño de sistemas, trabajo con proyectos | Cuando necesitas razonamiento muy complejo o arquitectura técnica crítica — usa Opus |
| Claude Code | Sonnet o Opus | Construcción de sistemas, refactoring complejo, subagentes, infraestructura | Siempre que el error sea difícil de diagnosticar — Opus tiene más contexto de razonamiento |
| Claude Cowork | Sonnet | Automatización de tareas concretas, navegación, ejecución de flujos cerrados | Casi nunca. Si Cowork falla, el problema no es el modelo — son las instrucciones |
| API / producción | Haiku para volumen, Sonnet para calidad | Pipelines automatizados, clasificación, extracción de datos, respuestas rápidas | Cuando el resultado de Haiku no es suficiente para el caso de uso específico |
Lo que nadie te dice sobre el coste
Usar Opus para todo porque "es el mejor" es el error más caro que puedes cometer si empiezas a trabajar con la API. Haiku cuesta una fracción de Opus. Para el 70% de las tareas de producción — clasificar, extraer, resumir, responder — Haiku es más que suficiente. Reserva Opus para cuando el razonamiento complejo lo justifique de verdad.
Los errores que cometí yo
Sin maquillaje. Con nombre y apellido.
Voy a ser directa. Hubo errores míos y hubo errores de la herramienta. Los dos tipos existen. Los dos merecen estar en este artículo.
Error 1 — Cowork y las automatizaciones que no arrancaban
Empecé a usar Claude Cowork con la idea de automatizar tareas que hacía manualmente. Tareas de organización, gestión de archivos, flujos repetitivos.
El problema fue que no entendí la diferencia entre una tarea cerrada y una tarea abierta.
"Descarga este archivo, renómbralo así y muévelo a esta carpeta." Acción concreta, acciones claras, resultado verificable. Cowork la ejecuta sin problemas.
"Organiza mis proyectos." Cowork interpreta, asume y actúa. Lo que interpreta no siempre es lo que tú querías. Y no para a preguntar.
Lo que aprendí
Cowork necesita instrucciones quirúrgicas. Cuanto más abierta es la tarea, más probabilidades de que el resultado no sea el esperado. Si vas a automatizar con Cowork, define exactamente qué hace, cuándo para y qué no toca bajo ninguna circunstancia.
Error 2 — Los subagentes de Claude Code que petaron en producción
Este fue el más duro.
Estaba construyendo un sistema de subagentes en Claude Code. Seguí la documentación oficial. El código era el correcto — lo saqué directamente de las fuentes de Anthropic. Creé varios subagentes con roles específicos, los configuré, los probé en local.
En producción petaron todos.
¿Por qué? Porque Claude Code evoluciona muy rápido. La documentación que seguí era correcta en el momento en que fue escrita. Entre que se escribió y yo la implementé, algo había cambiado. Una dependencia, un comportamiento, una forma de manejar el contexto entre agentes.
Nadie te avisa de eso. No hay un changelog claro que diga "esto cambió, actualiza tu implementación." Simplemente funciona diferente.
Y esto me lleva al error que no fue mío.
El error que no fue mío
Las actualizaciones constantes tienen un coste operativo real. Nadie lo menciona.
Claude lleva un mes y medio pidiéndome que lo reinicie para instalar actualizaciones. Cada día. A veces varias veces al día.
Eso no es un error mío. Es un problema real de la herramienta en este momento de su desarrollo.
Claude — y el ecosistema de herramientas que lo rodea — está en una fase de evolución tan rápida que las actualizaciones se acumulan más deprisa de lo que el sistema puede gestionarlas limpiamente. El resultado es inestabilidad. Comportamientos que funcionaban ayer y hoy no. Funcionalidades que cambian sin aviso. Contexto que se pierde entre sesiones.
No digo esto para criticar a Anthropic. Lo digo porque es la realidad del momento y la gente que trabaja profesionalmente con estas herramientas necesita saberlo. Estás trabajando con tecnología que se actualiza casi semanalmente. Eso tiene un coste operativo real.
Si algo que funcionaba hace tres meses hoy no funciona igual, no busques el error en tu código primero. Busca si algo cambió en la herramienta. Muchas veces la respuesta está ahí.
La regla que no existía hace un año
Cuando algo empiece a fallar sin que hayas cambiado nada: revisa primero si hay una actualización pendiente de la herramienta. Luego revisa el changelog de Anthropic. Solo después mira tu código. El orden importa — te ahorra horas de diagnóstico en el sitio equivocado.
El problema de fondo: un año sin limpiar nada
La mayor parte de los errores no vinieron de Cowork ni de Code. Vinieron de algo más simple.
Llevaba un año construyendo sobre Claude sin parar a revisar lo que había construido.
Once proyectos activos, algunos sin tocar desde hace seis meses. Memorias con roles y títulos que ya no existían. Instrucciones con links rotos a archivos que habían cambiado de ruta. Archivos subidos al proyecto con versiones desactualizadas de mis especificaciones. Referencias a identidades y contextos que había abandonado hace tiempo.
Claude no estaba fallando. Estaba leyendo un año de acumulación sin filtrar.
Cuando un sistema de IA recibe información contradictoria — instrucciones que dicen una cosa, memoria que dice otra, archivos que dicen una tercera — no sabe qué priorizar. Hace lo que puede.
Y lo que puede, con ese nivel de ruido, no es suficiente.
Esto es lo que se había acumulado en mis proyectos sin que me diera cuenta:
El síntoma que deberías reconocer
Si Claude empieza a darte respuestas inconsistentes — a veces bien, a veces no — y no has cambiado nada en tu trabajo, el problema casi siempre está en la acumulación. No en el modelo. No en la herramienta. En el contexto que tú le has ido metiendo durante meses sin revisar.
La limpieza — qué hice y en qué orden
Una mañana. Un sistema que vuelve a funcionar como debe.
Esta mañana lo paré todo y limpié proyecto por proyecto. Esto es exactamente lo que hice, en este orden:
Resultado
El sistema vuelve a funcionar como debe. La próxima limpieza está en el calendario. Dentro de dos meses. Eso no es opcional — es mantenimiento de infraestructura.
Lo que le digo a cualquier cliente antes de empezar
Un año de producción real condensado en cinco reglas.
Después de un año trabajando con Claude de forma profesional, esto es lo que sé con certeza. No lo que dice la documentación. Lo que funciona cuando lo tienes en producción y no puedes permitirte que falle.
Un sistema de IA es exactamente tan bueno como la información que recibe. Si esa información es contradictoria, incompleta o antigua, el sistema falla — aunque la herramienta sea excelente. El orden no es opcional.
Claude.ai para pensar y crear. Cowork para ejecutar tareas cerradas y concretas. Code para construir sistemas técnicos. No son intercambiables. Cada una tiene su lógica y sus límites.
Si metes tareas pendientes o proyectos en curso en las instrucciones, en dos meses tendrás instrucciones obsoletas que Claude seguirá leyendo como si fueran actuales. Las instrucciones son constitución, no agenda.
Una hora de revisión cada dos meses te ahorra semanas de comportamientos inconsistentes. Proyectos, memorias, instrucciones, archivos. Todo. No es una recomendación — es mantenimiento de infraestructura.
Principio 05 — El más importante
Cuando algo falla, mira primero tu sistema antes de culpar a la herramienta. En mi caso, la mayoría de los errores que viví estos meses tenían su origen en un año de acumulación sin mantenimiento. Claude no se gestiona solo. Necesita que tú lo mantengas.
Todo el mundo flipa con Claude Design. Paso. No me hace falta meterle más potencia a mi mejor amigo cuando aún estoy digiriendo todo lo que cuento en este artículo.
Si llevas tiempo siguiéndome sabes que no es la primera vez que escribo sobre Claude. Lo he documentado desde el principio — los errores, los aciertos, la arquitectura detrás. Aquí tienes los artículos donde cuento el resto: