Al empezar a trabajar con Claude Code, utilicé un ordenador que todavía necesitaba preparación. La instalación y los permisos consumieron tiempo que podría haberse dedicado al proyecto. Lo que extraigo de aquel episodio es sencillo: comprueba el entorno antes de la sesión y llega con una tarea pequeña y bien definida.
Suscripción y requisitos antes de empezar
Confirma el método de acceso e instalación en la documentación oficial de Claude Code. Hay suscripciones compatibles y otras formas de acceso, como Claude Console. El instalador nativo recomendado no necesita Node.js para ejecutar Claude Code; tu proyecto puede necesitar sus propias dependencias.
He trabajado con distintos límites de uso. Esa experiencia corresponde a las condiciones disponibles entonces. Al elegir el acceso, confirma las condiciones aplicables y sigue el consumo de tu propio trabajo, porque una sesión corta de revisión y una construcción más extensa pueden exigir recursos diferentes.
Si falla la instalación, guarda el mensaje de error y consulta las instrucciones para tu sistema operativo. Evita intentar resolver un error de permisos dando acceso de administrador a todo. Primero entiende qué componente ha fallado y qué permiso es realmente necesario para continuar.
Aislar la carpeta del proyecto
Nunca abras Claude Code en la carpeta general de tu usuario. Crea una carpeta nueva dedicada al proyecto y abre el terminal dentro de ella. En mi caso creé «cloud test» y avancé solo después de que el terminal preguntara si confiaba en esa carpeta específica.
Una carpeta dedicada mantiene organizados los archivos del proyecto, pero no es por sí sola una barrera de seguridad. Las acciones posibles dependen de los permisos, las herramientas conectadas y la configuración del entorno. Revisa esos accesos y mantén fuera del proyecto los documentos y las credenciales que no sean necesarios para la tarea.
Cómo usar la IA en el negocio más allá de las preguntas al chatbot
El riesgo de las claves de API expuestas
Si conectas APIs de anuncios, correo o bases de datos y escribes sus claves directamente en el código, quien lo vea publicado tendrá acceso a esos recursos. He visto circular casos de cuentas publicitarias vaciadas tras publicar un proyecto con claves de API visibles en el código fuente.
Lo mínimo que puedes hacer es pedir al propio Claude Code que revise el proyecto en busca de fallos de seguridad y confirmar que ninguna clave haya quedado expuesta en el código publicado en GitHub. Es lo mínimo, pero no basta por sí solo: si el proyecto incluye datos que deberían ser privados, conviene involucrar a alguien con conocimientos de programación antes de hacerlo público.
Probar en localhost antes de publicar
Durante el desarrollo, usa un entorno local y confirma cómo está expuesto el servidor. Un servicio limitado a la dirección de loopback, como 127.0.0.1, es distinto de uno accesible por la red o mediante un túnel. Antes de compartir una dirección, comprueba los accesos y los datos mostrados.
Construí una landing page entera durante una sesión de trabajo y la mantuve siempre en localhost, sin publicarla en GitHub ni en Vercel, precisamente porque estaba en directo y no quería arriesgarme a exponer mis propias claves. Plataformas como Vercel y Netlify hacen que publicar resulte tan sencillo que a veces se olvida la seguridad: una vez online, los rastreadores automáticos recorren internet buscando subdominios con fallos.
Usar el modo de planificación para solicitudes más complejas
Cuando haces una solicitud vaga a Claude Code, puede modificar partes de tu proyecto sin pedir confirmación previa. Activar el modo de planificación obliga a la herramienta a presentar primero todo lo que pretende hacer. Este paso te permite revisar y rechazar sugerencias antes de aplicar cualquier cambio al código.
Una persona compartió un ejemplo concreto: hizo una solicitud y Claude Code la interpretó como un cambio y modificó la página sin confirmar antes. Esto ocurre cuando la petición es demasiado abierta, y en esas situaciones conviene activar el plan mode con algo como: «quiero estar ahora en modo plan, sin ejecutar; planifica y solo después pídeme editar». Así puedes rechazar sugerencias antes de que se haga cualquier modificación.
Qué construir en la primera sesión
Un primer proyecto sencillo, como una landing page o un formulario, basta para entender la dinámica de pedir, revisar y aprobar antes de arriesgarte con algo complejo. Construí una página básica con ajustes graduales y seguí el consumo de la cuota. Sirve perfectamente para practicar el flujo de trabajo.
Construí en directo una landing page para recoger inscripciones a la sesión, con una petición inicial sencilla: recoger nombre, correo y teléfono, usando como referencia los colores y la tipografía de una web existente. Después fui pidiendo ajustes incrementales: destacar el formulario, convertir las preguntas en un formulario de varios pasos e incluso una barra de progreso que subiera más rápido al principio para dar sensación de avance. Cada petición consumió un porcentaje visible de la cuota de uso, que fui siguiendo durante la sesión. Es solo un ejemplo del tipo de ejercicio que se puede hacer en una primera sesión, no una receta fija que seguir al pie de la letra.
Una solicitud que puedes llevar a la primera sesión
Imagina que quieres organizar las solicitudes comerciales de tu empresa. Antes de pedir código, escribe de dónde llegan, quién las lee, qué información suele faltar y qué ocurre después. Añade un ejemplo ficticio con los campos que necesitas, sin nombres, contactos ni datos de clientes reales. Ya tienes material concreto para hablar de la estructura de la aplicación.
Después explica qué quieres poder comprobar al terminar la primera sesión. Puede ser simplemente abrir una página, registrar una solicitud de prueba y entender en qué estado ha quedado. Ese objetivo pequeño permite evaluar si el agente ha comprendido el proceso antes de pedirle integraciones con otros sistemas.
Por último, indica qué necesita todavía una decisión tuya. Si no has elegido dónde guardar los datos o quién tendrá acceso, déjalo por escrito. Pide al agente que identifique esas decisiones en el plan y explique las consecuencias de las opciones. Así puedes revisar la propuesta a partir de tu negocio y confirmar el siguiente paso sabiendo qué se va a construir.