01 Trabajar con Opus 4.7 todo el día
Lo que yo hacía:
Tenía Claude Code configurado por defecto en Opus 4.7 y trabajaba todo el día con ese modelo, pensando que el más potente siempre era el más adecuado. Lo abría por la mañana, no miraba el modelo activo y me ponía a trabajar.
Por qué es un error:
Opus 4.7 consume aproximadamente siete veces más tokens que Sonnet 4.6 para hacer la misma tarea. Y la mayoría de tareas del día a día (escribir, modificar, depurar cosas pequeñas, explicar conceptos, formatear texto) las resuelve Sonnet exactamente igual de bien. Trabajar siempre en Opus por defecto es como conducir todo el día en quinta marcha por ciudad: gasta el doble sin ir más rápido.
La solución:
Sonnet 4.6 como modelo por defecto. Comprueba con /model al empezar cada sesión: si está en Opus por inercia, bájalo. Solo subes a Opus cuando la tarea concreta lo pide (problemas complejos de razonamiento, decisiones de arquitectura, depuración difícil). El comando /model está explicado en la Clase 10.
Coste de mi error: meses gastando cuota a un ritmo absurdo. Cuando me lo señalaron, mi consumo bajó a la quinta parte sin perder calidad de trabajo.
02 Meter PDFs en los proyectos
Lo que yo hacía:
Cualquier documento importante (informes, propuestas, manuales, documentación de proyectos) lo metía como PDF directamente en el workspace y le pedía al agente que trabajara con él.
Por qué es un error:
Un PDF es un contenedor complejo: texto, imágenes, columnas, codificaciones distintas, OCR variable. Los modelos extraen aproximadamente la mitad del contenido y a veces lo extraen desordenado. Si le das un PDF de cien páginas y le pides un análisis, te va a inventar la mitad de los datos con cara seria. Y a ti te va a parecer un análisis correcto porque tú tampoco te has leído las cien páginas.
La solución:
Convertir todo a markdown antes de meterlo en el workspace. Existen pipelines de OCR más limpieza que hacen la conversión en segundos. La Clase 05 explica por qué markdown sí y PDFs no, con la metáfora de la vitrina empañada vs el papel limpio.
Coste de mi error: decisiones tomadas con información que el agente había rellenado con su mejor adivinación. Y yo creyéndomelo.
03 Aceptar permisos uno a uno
Lo que yo hacía:
Cada vez que Claude Code me pedía permiso para tocar algo (crear un archivo, ejecutar un comando, modificar una línea), me paraba a leer el botón, dudaba, pensaba si era seguro. Avanzaba a tirones.
Por qué es un error:
Si has decidido confiar en la herramienta, tienes que confiar a la velocidad de la herramienta. Cuando dudas en cada permiso, el agente pierde el hilo, las conexiones con el servidor se entrecortan y la sesión dura el doble por una falsa sensación de control. Los permisos paso a paso tienen sentido cuando estás aprendiendo a usar la herramienta. Una vez que conoces tu workspace, son fricción pura.
La solución:
Configura Claude Code en modo de acceso completo dentro del workspace de tu proyecto. Acepta de una vez. Si no te fías de la herramienta, no la uses. Si te fías, déjala correr. Es una cosa o la otra; el modo “te permito casi todo pero te freno cada quince segundos” es el peor de los dos mundos.
Coste de mi error: sesiones de tres horas que podrían haber sido de una. Multiplicado por días, fui yo la que perdí ese tiempo.
04 Usar el almacenamiento como base de datos
Lo que yo hacía:
Tenía datos críticos del trabajo (clientes, contactos, contratos, registros operativos) en carpetas de OneDrive, organizados con subcarpetas y archivos de Excel y PDFs sueltos. Y le pedía a la IA que buscara cosas ahí dentro.
Por qué es un error:
OneDrive (o cualquier servicio similar de almacenamiento de archivos) es eso, un almacén. No es una base de datos. No tiene lenguaje SQL, no permite consultas estructuradas, la IA tiene que ir abriendo archivo por archivo para encontrar algo. Es como pedirle a alguien que te encuentre un cliente concreto entre quinientas carpetas de cartón apiladas en un trastero. Lo va a hacer, pero le va a costar lo mismo cada vez.
La solución:
Migrar los datos estructurados a una base de datos real dentro de tu servidor. Es una inversión inicial (alguien con conocimiento técnico te la monta o te enseña a montarla), pero la primera vez que pides “dame todos los registros que cumplen tal condición” y lo tienes en dos segundos, ya no vuelves atrás. Lo que pertenece a un almacén se queda en el almacén; lo que se consulta de verdad va a la base de datos.
Coste de mi error: meses haciendo búsquedas manuales que un select bien escrito habría resuelto en una línea.
05 Preguntar sin pedir deep research
Lo que yo hacía:
Le hacía preguntas a la IA sobre cosas que requerían información actualizada o documentación oficial (precios, versiones de productos, normativa, decisiones de arquitectura técnica) sin pedirle nunca que buscara. Le hacía la pregunta en seco y aceptaba la primera respuesta.
Por qué es un error:
Los modelos tienen fecha de corte de conocimiento. Cuando preguntas algo y no le pides explícitamente que busque, contesta con lo que recuerda de su entrenamiento, que puede ser de hace meses o años. Y como siempre te lo dice con la misma seguridad que cuando sí sabe, te lo crees. Las decisiones tomadas con información obsoleta presentada como actual son uno de los errores más caros que se pueden cometer trabajando con IA.
La solución:
Cuando la pregunta requiera datos actuales, escribe explícitamente “haz un deep research y busca en documentación oficial”. Vuélvelo tu valor por defecto para cualquier pregunta técnica, de mercado, de producto o de normativa. Si la respuesta no necesita búsqueda, el agente te lo dice. Si la necesita, la hace. Mejor preguntar y que sobre que no preguntar y que falte.
Coste de mi error: dos decisiones reales tomadas con información que ya no era cierta cuando las apliqué. No las cuento aquí, pero no fueron baratas.
06 Decirle a la IA “eres una experta en X”
Lo que yo hacía:
Empezaba conversaciones con “actúa como una experta en X” o “eres una consultora especializada en Y”, convencida de que esa instrucción transformaba al modelo en algo distinto. Lo hacía incluso cuando ya tenía mis propias estructuras (como Spec Builder) que sí funcionaban.
Por qué es un error:
Decirle a un modelo de lenguaje que es algo no lo convierte en algo. Solo le pide que improvise con lo poco que recuerde de su entrenamiento sobre el tema. Lo que de verdad cambia el resultado es entregarle una skill: pasos exactos, errores típicos, fuentes de verdad, formatos de salida. La diferencia entre “eres experta” y una skill bien hecha es la diferencia entre alguien que finge saber y alguien que ha leído el manual.
La solución:
Cuando una tarea se va a repetir, dedica una sesión a destilar la skill, como explica la Clase 06. Después la dejas hacer su trabajo en silencio. La instrucción “eres experta” la abandonas: si necesitas que sepa algo concreto, le das el conocimiento; si no lo necesitas, no le pidas que lo finja.
Coste de mi error: respuestas mediocres pasando por buenas. Y rehacer cosas que no estaban tan bien hechas como yo creía.
07 Repartir tu trabajo entre varios equipos
Lo que yo hacía:
Trabajaba en el ordenador de casa, en el de la oficina, en otro despacho cuando estaba fuera. Cada uno tenía un estado distinto: una skill actualizada en uno, una versión vieja del proyecto en otro, las claves de un servicio en un tercero.
Por qué es un error:
Cuando tu trabajo consiste en tocar tu propia infraestructura todo el día (skills, archivos del workspace, configuraciones, conexiones al servidor), no puedes permitirte que esté repartida entre máquinas que no se actualizan entre sí. Llegas a una y descubres que la skill que cambiaste anteayer no está. Llegas a otra y la versión del proyecto es de hace dos semanas. Acabas pasando más tiempo sincronizando que trabajando.
La solución:
Un único dispositivo principal, potente, que vaya contigo. Si pasas casi todo el tiempo en un mismo sitio, fijo. Si te mueves, portátil bueno. Que cada cosa que toques se quede contigo y no se quede atrás en ningún equipo. Si trabajas en varios sitios, lo que sí está bien repartido es el servidor (al que conectas desde cualquier sitio); pero el equipo de trabajo principal es uno solo.
Coste de mi error: días enteros sincronizando entre máquinas. Y la frustración cada vez que abría un equipo y no estaba lo que necesitaba.
08 Tener contraseñas a la vista
Lo que yo hacía:
Contraseñas críticas (de servidores, de bases de datos, de servicios profesionales) escritas en sitios visibles. A veces de pasada en una llamada compartiendo pantalla. A veces en una captura subida a redes. A veces en un papel pegado al monitor.
Por qué es un error:
Una contraseña de root de un servidor es la llave de toda tu infraestructura. Que aparezca de pasada en una videollamada, en una captura, en un papel sobre la mesa, es como dejar la llave de tu casa pegada con cinta adhesiva en la puerta. “Pero no la ha visto nadie” no es seguridad: es suerte. Y la suerte se acaba.
La solución:
Gestor de contraseñas (1Password, Bitwarden, KeePass, el que prefieras). Las contraseñas críticas no se visualizan nunca: se pegan desde el gestor cuando hacen falta y se cierra. Las que ya hayan podido verse en algún momento se cambian de inmediato. La regla práctica es: si te has visto la contraseña de ese servicio en pantalla en los últimos 30 días, esa contraseña ya no vale. Cámbiala.
Coste de mi error: una noche sin dormir cuando me di cuenta. Una cadena de cambios urgentes al día siguiente. Y la sensación rara durante semanas de revisar dónde más podía haber salido.
09 No tener una skill para lo que se atasca cada semana
Lo que yo hacía:
Había tareas concretas que la IA no resolvía bien por defecto (configurar un servidor Samba en Windows es el ejemplo clásico), y cada vez que me tocaba volver a hacerlas, me ponía a explicárselas al agente desde cero. Otra vez. Y otra. Con los mismos errores intermedios.
Por qué es un error:
Cualquier proceso que se repite y que requiere una explicación cada vez es un candidato perfecto para una skill. Las skills son exactamente para eso: cristalizar el conocimiento operativo de una tarea concreta para que el agente no tenga que reaprenderla. La Clase 06 lo explica entero. Si llevas tres veces explicando lo mismo, la cuarta vez ya tendrías que tener skill.
La solución:
Cada vez que te encuentres explicando lo mismo a la IA por tercera vez, frena. Pídele al agente que destile esa explicación en un SKILL.md y guárdala en skills/ dentro del workspace. La próxima vez ya no tienes que explicárselo. Tareas concretas que casi siempre piden skill propia: configuración de Samba o SMB en Windows, despliegues con Docker, conexiones a APIs de servicios concretos, formatos de exportación específicos.
Coste de mi error: explicar la misma cosa veinte veces. La cara que ponía el agente al volver a tropezarse con el mismo paso. Y la cara que ponía yo al darme cuenta de que el problema no era el agente.