Cosas que NUNCA haría después de utilizar Claude +1000 horas

Índice

Llevo más de mil horas trabajando con Claude. No usándolo de vez en cuando: trabajando con él todos los días, en mi negocio y en mi código. Y lo que más me ha cambiado la forma de trabajar no es lo que hago con él, es lo que he dejado de hacer.

Esto son catorce cosas que ya no hago. Cada una me costó tiempo aprenderla, y casi todas las hacía mal durante meses sin darme cuenta.

1. No empiezo cada conversación desde cero

Un Proyecto es una carpeta de conversaciones que comparten las mismas instrucciones y los mismos archivos. Lo que escribes una vez ahí dentro se aplica a todo lo que abras después, y esa es toda la diferencia entre repetir el mismo prompt cien veces y no repetirlo nunca más.

Antes de tenerlos, cada conversación empezaba explicando quién soy, a qué me dedico, cómo escribo y volviendo a subir los mismos tres archivos. Ahora abro el Proyecto y escribo directamente lo que necesito. El contexto ya está puesto antes de que yo teclee una palabra.

2. No le doy instrucciones genéricas

«Escribe en tono cercano» no significa nada. Es una instrucción que no se puede comprobar: no hay forma de mirar la respuesta y decir si la ha cumplido. Y lo que no se puede comprobar, no se cumple.

Lo que sí funciona son reglas concretas: frases de menos de veinte palabras, una lista de palabras prohibidas, y tres textos míos de ejemplo dentro del Proyecto. Con eso la salida se parece a lo que escribo yo. Con «tono cercano» sale lo que escribe todo el mundo.

3. No espero a que me vaya adivinando

Hay quien va soltando pistas y espera que el modelo se haga una idea con el tiempo. Es una pérdida de tiempo: se lo dices directamente y se acabó. «Recuerda que trabajo en esto, que vendo aquello y que escribo en español de España.»

Eso, guardado en la memoria o en las instrucciones del Proyecto, entra solo en cada conversación nueva. Son tres frases que escribes una vez y dejas de escribir para siempre, y cambian todas las respuestas que vienen después.

4. No dejo que me dé la razón sin más

Estos modelos tienden a estar de acuerdo contigo, y eso los vuelve inútiles justo cuando más falta hacen: cuando tienes que decidir algo. Si le cuentas tu plan, te va a decir que es un buen plan.

Lo que hago es abrir cuatro conversaciones separadas con el mismo caso, cada una con un papel distinto: el que mira el dinero, el que mira el riesgo, el que mira al usuario y el que tiene que llevarme la contraria. Sin que se vean entre ellas. Y luego una quinta, en blanco, con las cuatro respuestas pegadas para que decida. Ahí es donde salen los agujeros que yo no veía.

5. No le dejo escribir código sin un plan antes

El error más caro es pedir directamente el código. Te lo escribe, y te lo escribe rápido, y te lo escribe entero en la dirección equivocada. Cuando te das cuenta ya hay cuatrocientas líneas escritas y arreglarlas cuesta más que tirarlas.

Le pido el plan primero y le digo explícitamente que no toque nada. Diez líneas explicando qué va a hacer, en qué ficheros y en qué orden. Ese plan lo corrijo en un minuto, y a partir de ahí el código va donde yo quiero. Es el cambio que más tiempo me ha ahorrado de todos.

6. No me creo nada sin fichero y línea

Se equivoca con exactamente la misma seguridad con la que acierta, y ese es el problema. No hay ningún cambio en el tono que te avise de que lo que acabas de leer se lo acaba de inventar.

Así que la regla es fija: si me dice que algo funciona de una manera, que me diga en qué fichero y en qué línea lo ha visto, y lo abro. Y le digo desde el principio que «no lo sé» es una respuesta perfectamente válida. Cuando le das permiso para no saber, deja de rellenar huecos.

7. No lo uso como un chat

Mientras lo uses copiando y pegando, tienes un buscador con mejor conversación. El salto está en los conectores: le das permiso para leer tu correo, tu calendario y tus archivos, y pasa a trabajar con tus datos reales en vez de con lo que le cuentas.

Empieza siempre por los de solo lectura, que es donde no puede romper nada. El permiso de enviar o de escribir se da cuando llevas una semana leyendo lo que redacta y te fías. Ese orden no es prudencia: es que la primera semana vas a corregirle cosas.

8. No redacto a mano las respuestas a los interesados

Una tarea programada mira el correo cada hora, encuentra lo que parece una consulta de cliente, lee el hilo entero y redacta la respuesta con mi forma de escribir. La deja en borradores.

Yo la leo, cambio lo que haga falta y le doy a enviar. Treinta segundos por interesado en vez de veinte minutos. Y fíjate en lo que no está automatizado: el botón de enviar. Eso se queda conmigo, y creo que se queda conmigo para siempre.

9. No escribo los resúmenes de las reuniones

Entra la transcripción, que ya te la da cualquier aplicación de videollamadas, y sale un resumen con la misma forma siempre: qué se decidió, qué tarea es de quién, y el correo de seguimiento ya redactado.

Dos minutos en vez de veinte. Pero lo que de verdad importa no es el tiempo: es que la salida sea idéntica todas las semanas. Un resumen que cada vez tiene una forma distinta no lo lee nadie, y volvemos a estar donde estábamos.

10. No escribo los informes semanales

El lunes por la mañana, una tarea programada saca los números de la hoja de cálculo, del correo y del calendario, escribe el informe con la estructura de siempre, lo guarda en la carpeta del cliente y deja el correo redactado con el informe enlazado.

Está hecho antes de que yo abra el portátil. Leo, cambio dos frases y lo mando. Esto es lo que separa usar IA de tener IA trabajando: la diferencia entre pedirle algo y encontrártelo hecho.

11. No instalo una skill y me olvido

Una skill es lo que convierte a un modelo generalista en uno que trabaja como tú: diseño de interfaz con tu criterio, documentos con tu plantilla, presentaciones con tu estructura, tu forma de escribir y tu manera de revisar.

Y no se instalan y se olvidan. Cada vez que algo sale mal, en lugar de resoplar, le añado la línea que faltaba. A las tres semanas la skill sabe lo que yo sé sobre eso, y eso no se consigue escribiendo un prompt perfecto el primer día.

12. No le doy permisos que no necesita

Puede leer el repositorio, proponer cambios, escribir en una rama que no es la principal y correr los tests. No toca producción, no toca la base de datos de verdad y no ejecuta nada que yo no pueda deshacer.

La pregunta antes de dar un permiso es siempre la misma: si esto sale mal, ¿puedo volver atrás en un minuto? Si la respuesta es no, ese permiso no se da. Y esto vale igual para un agente que para un becario, con la diferencia de que el agente va mucho más rápido.

13. No uso el mismo modelo para todo

Usar el modelo grande para clasificar correos es pagar por pensar donde solo hace falta leer. Y usar el rápido para decidir una arquitectura sale mucho más caro todavía, porque el error no lo pagas en tokens: lo pagas en semanas.

El reparto que uso: el grande para pensar, decidir y escribir código; el rápido para resumir, clasificar, extraer y ordenar. La mayoría de lo que pides todos los días es de lo segundo, y ahí es donde está el ahorro sin perder nada.

14. No lo trato como una herramienta

Esto es lo que resume todo lo anterior. Una herramienta la abres cuando la necesitas, le pides algo y la cierras. La infraestructura está funcionando aunque tú no la mires.

Cuando tienes los Proyectos con tus instrucciones, las skills con tu criterio, los conectores con tus datos y las tareas programadas corriendo por la mañana, ya no estás usando una herramienta: tienes montado un sistema que trabaja mientras haces otra cosa. Ese es el cambio de verdad, y es el que casi nadie da.

Por dónde empezar mañana

Si de aquí solo te llevas una cosa, que sea el punto uno: monta un Proyecto con tus instrucciones y tus archivos. Es media hora y es lo que hace posible todo lo demás.

Y si te llevas dos, que la segunda sea el punto cinco: pídele el plan antes que el código. Es la que menos cuesta y la que más tiempo te devuelve desde el primer día.