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

Índice

Realmente esto puede cambiar tu forma de trabajar por completo.

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

1. Repetirle quién soy en cada chat nuevo

Un Proyecto es una carpeta donde guardas tus instrucciones y tus archivos. Todas las conversaciones que abras dentro los usan. Lo escribes una vez y ya está puesto para siempre.

Antes yo empezaba cada chat explicando quién soy, a qué me dedico y cómo escribo, y subiendo otra vez los mismos archivos. Ahora abro el Proyecto y voy directo a lo que necesito.

Y díselo explícito, no vayas soltando pistas a ver si lo pilla. «Recuerda que trabajo en esto, que vendo aquello y que escribo en español de España.» Tres frases dentro de las instrucciones que escribes una vez para no escribirlas nunca más.

2. Pedirle que escriba «en tono cercano»

«Escribe en tono cercano» no sirve de nada. Léelo así: mira la respuesta que te dé e intenta decidir si ha cumplido esa orden. No puedes. Pues él tampoco.

Lo que sí funciona son órdenes que se pueden comprobar: «frases de menos de veinte palabras», «no uses nunca estas quince palabras» y tres textos míos de ejemplo dentro del Proyecto. Con eso escribe como yo. Con «tono cercano» escribe como todo el mundo.

3. Cerrar el portátil sin que apunte lo aprendido

Tengo un fichero que se llama rules y que es la memoria del proyecto: cómo escribo, qué no quiero ver nunca, cómo está montado por dentro, qué decisiones ya se tomaron y por qué, y los errores que ya cometió una vez.

Y lo importante no es tenerlo: es actualizarlo. Antes de cerrar cada sesión le digo que lo actualice con lo que hayamos aprendido ese día. No lo que hemos hecho, que eso ya está en el código: lo que hemos aprendido. La corrección que le tuve que hacer dos veces, la decisión que tomamos y el motivo, la cosa que dio por supuesta y no era.

Al día siguiente empieza sabiéndolo. Sin ese paso, cada sesión repite los mismos tres errores y tú repites las mismas tres correcciones para siempre. Con él, el fichero crece solo y a las pocas semanas ya no hace falta explicar casi nada.

4. Preguntarle si mi plan es bueno y creérmelo

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. Fiarme de lo que dice un solo agente

Un modelo revisando su propio trabajo se da la razón. Es el mismo problema del punto anterior, pero dentro del código: le pides que revise lo que acaba de escribir y te dice que está bien.

Lo que hago es poner a dos a hablar. Claude Code escribe el plan o el código, y se lo paso a Codex para que lo revise sin haber visto la conversación. Luego le paso a Claude lo que ha dicho Codex y le pido que responda: dónde tiene razón, dónde no y por qué. Y si no se ponen de acuerdo, otra vuelta.

Funciona porque son modelos distintos, entrenados distinto, y no comparten los mismos puntos ciegos. Lo que a uno se le pasa, el otro lo ve. Yo leo las dos versiones y decido, que sigue siendo mi trabajo, pero decido con dos opiniones que se han contradicho de verdad en vez de con una que me está dando la razón.

6. Pedirle el código a la primera

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.

Y la otra mitad, que se me olvidó durante meses: que me pregunte antes de empezar. Le digo que si algo del encargo es ambiguo no lo decida él, que me haga las preguntas que necesite primero. Tres preguntas al principio evitan doscientas líneas escritas contra lo que yo tenía en la cabeza, y casi siempre me enseñan que el encargo lo había explicado peor de lo que creía.

7. Creerme un dato sin abrir el fichero

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.

8. Repetir a mano lo que puede repetir él

Un bucle es esto: mides dónde estás, cambias una cosa, vuelves a medir y te quedas con el cambio solo si el número ha mejorado. Y otra vuelta. Suena obvio y casi nadie lo hace: lo normal es preguntar, leer la respuesta y decidir a ojo.

Estos son mis tres mejores. Cada uno es un prompt que se lanza y se queda dando vueltas hasta que no queda nada que arreglar.

📚 Documentación siempre actualizada. El que menos glamour tiene y el que más disgustos evita, porque la documentación desfasada engaña más que la que no existe.

Revisa todo el código y comprueba que la documentación refleja la implementación actual. Actualiza lo que esté desfasado, verifica los cambios y abre una pull request.

🧪 Auditoría completa de producto. Este es el que de verdad encuentra cosas: recorre la aplicación como un usuario real, documenta cada fallo con la forma de reproducirlo y vuelve a empezar hasta que una pasada entera sale limpia.

Crea datos locales seguros y realistas. Revisa todas las funciones, roles, rutas, botones, formularios, modales, estados y flujos como un usuario real.

Define criterios de aceptación, prueba casos límite y documenta cada error con pruebas para reproducirlo.

Busca causas, corrige los problemas, añade tests y repite toda la auditoría hasta conseguir una pasada limpia.

Pide permiso antes de usar producción, datos sensibles o acciones destructivas.

🔎 Auditoría SEO y GEO. Ordena los problemas por impacto y arregla primero el que más pesa, en vez de la lista de cien cosas menores que suelen devolver estas herramientas.

Revisa rastreo, indexación, intención de búsqueda, títulos, enlaces internos, datos estructurados, fuentes y contenido preparado para responder directamente.

Ordena los problemas por impacto, corrige primero el más importante y repite la auditoría y las búsquedas de referencia.

Continúa hasta que no queden errores críticos ni búsquedas prioritarias sin una página clara y optimizada.

Estos y unos cuantos más los tienes en la biblioteca de loops de Forward Future, que es de donde saqué la idea de montarlos así.

Es lo mismo de lo que hablaba en el artículo de por qué este momento es como el de BTC en 2012: lo que ha cambiado no es que la IA acierte más, es que puedes probar y descartar mucho más rápido. El que itera diez veces mientras tú iteras una, gana.

Dos reglas para que el bucle sirva de algo. La primera: mide siempre igual, porque si cambias el criterio entre vueltas no estás comparando nada. La segunda: toca una sola cosa cada vez, porque si tocas tres no vas a saber cuál funcionó.

9. Dejarlo sin enchufar a mis herramientas

Un MCP es un enchufe estándar. La herramienta dice lo que sabe hacer y el modelo lo usa directamente, sin que tú copies y pegues nada en medio. Es la diferencia entre que te cuente lo que haría y que lo haga.

Los dos que más uso: el de NotebookLM, que le da acceso a mis cuadernos y a las fuentes que tengo guardadas ahí, así que responde con mis documentos y no con lo que recuerde de internet. Y el de Canva, que le deja crear y editar diseños de verdad, no describírmelos para que luego los haga yo a mano.

Y hay uno para casi todo: tu base de datos, GitHub, Figma, tu gestor de tareas. Cada uno que enchufas es una cosa menos que haces tú de intermediario. Ahí es donde deja de ser un chat listo y empieza a ser algo que trabaja.

10. Usarlo copiando y pegando

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.

11. Contestar los correos de clientes a mano

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.

12. Escribir a mano el resumen de cada reunión

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.

Y siendo honesto: si esto es tu problema todos los días, hay herramientas que ya lo hacen mejor que un prompt montado por ti. Granola es la que más me gusta, y Fathom y Circleback van por lo mismo: se meten en la reunión, toman las notas y te dan el resumen sin que muevas un dedo. Yo sigo con mi versión porque me la llevo a mi formato, pero si solo quieres el resumen, empieza por ahí.

13. Escribir a mano el informe de los lunes

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.

14. Instalar una skill y no volver a tocarla

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.

15. Darle acceso a producción

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.

16. Usar el modelo caro para todo

Hay cuatro y no son intercambiables. De más caro a más barato: Fable 5, Opus 5, Sonnet 5 y Haiku 4.5. Entre el primero y el último hay diez veces de diferencia en lo que cuesta cada respuesta.

Mi reparto: Sonnet 5 por defecto, que es donde está el noventa por ciento de lo que hago y va sobrado para escribir código. Haiku 4.5 para lo mecánico: resumir, clasificar, extraer, ordenar. Y subo a Opus 5 o a Fable 5 solo cuando el problema es de verdad difícil: una decisión de arquitectura, un fallo que llevo dos horas sin encontrar, algo largo que el agente tiene que sostener durante muchos pasos.

Usar Fable para clasificar correos es pagar por pensar donde solo hacía falta leer. Y al revés es peor: usar Haiku para decidir una arquitectura sale carísimo, porque ese error no lo pagas en tokens, lo pagas en semanas de trabajo en la dirección equivocada.

17. Tenerlo apagado hasta que lo necesito

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.

18. Teclear los prompts en vez de dictarlos

Esta es la que menos parece importar y la que más me ha cambiado el día. Ya no escribo los prompts: los dicto. Uso Typeless, y WisprFlow hace lo mismo. Pulsas una tecla, hablas, y aparece escrito donde tengas el cursor.

La diferencia no es la velocidad de tecleo, es cuánto le cuentas. Escribiendo pones cuatro líneas porque escribir cansa, y luego el resultado no es lo que querías porque le faltaba la mitad del contexto. Hablando le sueltas un párrafo entero con el porqué, lo que ya has probado y lo que no quieres que haga, en el mismo tiempo que tardabas en escribir el título.

El cuello de botella nunca fue el modelo: era lo poco que le contabas. Y le contabas poco porque escribirlo daba pereza. Con esto desaparece esa pereza y las respuestas cambian de golpe, sin tocar nada más.

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 siete: pídele el plan antes que el código, y que te pregunte lo que no tenga claro. Es la que menos cuesta y la que más tiempo te devuelve desde el primer día.