Cómo usar Claude: mi método sobre proyectos reales

La respuesta corta: se usa de dos maneras y las dos valen. En el chat le escribes y te contesta, y le sacas mucho más si le das contexto de por qué haces las cosas, iteras sobre su respuesta en vez de quedarte con la primera, y le pides que te cuestione. Y con Claude Code, que corre en tu computadora, le das una carpeta de proyecto con dos cosas dentro —un archivo CLAUDE.md con el contexto y una carpeta de documentación— y a partir de ahí trabaja dentro de tus archivos en vez de darte texto para copiar. Lo que sigue es cómo monto yo esa carpeta y cómo trabajo con ella todos los días.

El chat sirve, y le puedes sacar más

Empiezo por aquí porque es donde está casi todo el mundo, y porque usarlo en el chat no es usarlo mal. Subir un Excel y pedirle que te saque un reporte funciona. Pedirle que te ayude a redactar funciona. No hace falta montar nada para eso.

Lo que sí cambia el resultado, sin cambiar de herramienta, son tres cosas:

Dale el contexto del porqué. Es lo que más se salta y lo que más se nota. Si le pides «hazme una tabla de precios» te la hace; si le dices para quién es, qué decisión tiene que tomar esa persona y qué te preocupa de cómo se va a leer, te hace otra cosa.

Cuando das poco contexto y eres cuadrado, las ejecuciones sí las hace — pero salen más pobres.

Itera en vez de quedarte con lo primero. Casi nunca acepto el primer resultado. Le digo qué me sirve, qué no y por qué, y vamos dos o tres vueltas. Es más rápido que escribir la instrucción perfecta a la primera, y sale mejor.

Dale permiso para cuestionarte. Se lo digo explícitamente: si ves una mejor forma de hacerlo, o algo que se me está pasando, dímelo o hazlo. Es una frase y cambia lo que recibes — sin ella se limita a ejecutar lo que pediste, aunque lo que pediste no fuera lo mejor.

Qué cambia cuando le das un proyecto

El escalón siguiente no es un modelo mejor ni un prompt más largo. Es dejar de pegarle trozos y darle una carpeta.

Con Claude Code, que corre en la terminal de tu computadora, la herramienta lee los archivos que hay en esa carpeta, los modifica y ejecuta cosas. Eso es lo que separa un chat de un agente, y decidir cuál abro depende justo de si el trabajo tiene carpeta o es una pregunta suelta.

Y un proyecto no tiene que ser de programación. Los míos son de tres tipos y solo uno lo es: sitios web de clientes, un sistema en Laravel, y uno que es puros archivos y scripts para redactar posts. Lo que hace que algo sea un proyecto es que haya archivos que van a cambiar más de una vez y contexto que no quieres volver a explicar.

Qué hay dentro de la carpeta

Depende del tipo de proyecto, pero dos cosas están siempre, y son las dos que hacen el trabajo:

1. 1

   Un archivo CLAUDE.md

   Es lo primero que lee. Ahí van las especificaciones y el contexto del proyecto: qué es esto, cómo se trabaja aquí y qué reglas no se rompen.

2. 2

   Una carpeta docs o knowledge

   Donde se acumulan las heurísticas y el contexto largo. Lo que no cabe en un archivo y no quieres tener que contar otra vez.

Lo que va escrito dentro del contexto importa más que dónde lo pongas. Son cinco cosas, y ninguna es técnica:

La última es la que más se salta y la que más rinde. Si sabe por qué estás haciendo algo, las decisiones que tome por su cuenta van en la dirección correcta; si solo sabe qué le pediste, acierta en la tarea y falla en el criterio.

Un cliente es un proyecto, aunque le hagas dos cosas

Ésta va contra lo que haría cualquiera. Si a un cliente le hago el sitio web y además le llevo Google Ads, no monto dos proyectos: monto uno con carpetas separadas dentro.

El motivo es que las dos cosas están conectadas de verdad. El sitio tiene landing pages que reciben las campañas, y los reportes que le mando al cliente hablan de las dos. Con un solo proyecto, Claude conoce la estructura completa y puede cruzarlas; con dos, cada mitad sabe la mitad.

Es la misma carpeta que hay detrás de las auditorías web que hago, por cierto. Sigo, que lo que viene es la parte que no cuenta nadie.

Cómo le pido las cosas, con una instrucción real

Escribo o mando audios, y siempre trato de que la instrucción lleve el porqué. En vez de explicarlo, te dejo una mía de esta semana — con el cliente cambiado:

No tiene nada de sofisticado, y por eso sirve de ejemplo. Fíjate en que lleva cuatro cosas: para qué y para cuándo es, qué existe ya en el proyecto, la tarea concreta y dónde, y el objetivo — que es la que casi nadie escribe.

Esa última frase es la que hace la diferencia entre recibir un gráfico y recibir el gráfico correcto. Si sabe que el objetivo es que el cliente entienda una estacionalidad, elige otra forma de graficarla que si solo sabe que quiero «un widget de gráficas».

Cómo reviso lo que hizo

Depende del material: si es un HTML, lo abro en el navegador; si es un Markdown, en el editor o en la misma terminal. Y en los dos casos doy feedback e itero varias veces antes de dar algo por bueno.

Trabajo con Claude en modo automático, para que no me pregunte paso por paso — preguntando cada cosa se pierde la ventaja entera. Pero eso tiene una contrapartida que no es negociable:

Automático para avanzar, y auditoría propia en permisos y en cualquier cosa sensible.

Y hay tres costumbres que hacen que trabajar así no dé miedo, y que son más viejas que la IA:

Un detalle de seguridad que casi nadie menciona

Si el proyecto es un sitio web, en la carpeta también viven cosas que no son el sitio: el conocimiento del cliente, presentaciones, material de operación interna. Y como están en el repositorio, viajan al servidor cuando despliegas.

Tienen que estar ahí —es lo que me deja compartirlo con mi equipo y trabajar desde mis distintas computadoras—, así que el cuidado va en otro sitio: restrinjo esas carpetas en el .htaccess para que desde un navegador solo se pueda abrir el sitio web y no la operación interna.

El sembrado no es un paso: es un ciclo

Al proceso de preparar todo esto lo llamo sembrar, y lleva su tiempo: entre unas horas y un día. No es solo escribir el contexto — es dejar la estructura, conectar las llaves SSH o el FTP si voy a desplegar a un servidor, y dejar los repositorios listos.

Durante mucho tiempo lo conté como la parte lenta del principio. Y está mal contado, porque lo que de verdad lo sostiene es una regla que le pongo desde el primer día: que documente cada avance.

Cada tarea que terminamos deja documentación escrita. Esa documentación es el contexto con el que empieza la sesión siguiente.

Por eso retomar un proyecto que no toco desde hace tres semanas es fácil: lee el CLAUDE.md, lee las heurísticas y lo que quedó documentado, y seguimos. No tengo que acordarme de nada ni volver a explicar por qué las cosas están como están.

Y ahí está lo que cambia el trabajo de verdad: lo que cosechas vuelve a sembrar. El proyecto no se queda como lo dejaste el primer día — se hace más útil cada vez que lo usas, siempre que le hayas puesto la regla de documentar. Es un hábito mío, no una función de la herramienta.

Qué se rompe cuando el proyecto crece

Todo el mundo cuenta el arranque; casi nadie cuenta el mes cuatro. Lo que se rompe es la ventana de contexto: cuando una sesión acumula demasiado, empieza a cometer errores y a no ser tan preciso.

La solución no es un truco de prompt. Es cerrar la sesión y abrir una ventana nueva, y tener el proyecto lo bastante ordenado como para que eso no cueste nada: carpetas clasificadas y documentación al día. En un proyecto grande, documentar por partes.

Divide y vencerás, que es de siempre y sigue siendo verdad.

Cuándo no abro Claude Code

Cuando todavía no hay proyecto. Con un cliente nuevo que está en proceso de cotización, o cuando es una asesoría suelta, no hay nada que desarrollar — y montar una carpeta para eso es trabajo que no rinde.

Ahí uso ChatGPT como chat y le voy dando contexto de la conversación con el cliente. Y cuando eso deriva en un proyecto de verdad —un sitio, campañas, algo que hay que construir— hago el traspaso: le pido a ChatGPT todo el contexto acumulado y con eso creo el proyecto en Claude Code.

Así que el chat no es el escalón que dejas atrás. Es donde se piensa, y de ahí sale la semilla de lo que después se siembra.