El capítulo 1 iba del modelo mental. Este capítulo va de ponerse manos a la obra. El objetivo es uno solo: sacar adelante tu primera instrucción contra tu propio repositorio.
Los comandos que teclearás son unas pocas líneas. El resto del tiempo se dedica a entender qué estás aprobando. Si te lo saltas, tendrás que volver aquí más adelante.
Hay cinco puertas de entrada: elige la tuya
A Claude Code se lo suele presentar como «una herramienta de terminal», pero hay cinco puertas de entrada. El interior es el mismo y lo único que cambia es la envoltura.
La forma nativa. Basta con escribir claude. Es la referencia de este curso.
Convive dentro del editor. Lees los diffs con el aspecto de siempre.
Para los IDE de la familia IntelliJ. Si desarrollas ahí, no tienes que moverte.
Se usa sin abrir la terminal. El modo se elige en el selector junto al campo de entrada.
Puedes usarlo aunque no tengas un entorno de desarrollo a mano. Aquí también se cambia con el selector.
Para la primera hora recomiendo la terminal. No por comodidad, sino por cantidad de información. Cuando algo se atasca, los mensajes se ven tal cual, y las soluciones publicadas están escritas dando por hecho que estás en la terminal. Por otro lado, el reparto de papeles frente a las herramientas integradas en el editor (Cursor o GitHub Copilot) está en el capítulo 1 del curso de coding con IA.
Instalarlo
La vía estándar es npm. Si tienes Node.js instalado, se resuelve en una línea (si node -v te devuelve una versión, ya está todo listo). El -g significa «instálalo de forma que se pueda invocar desde cualquier carpeta».
npm install -g @anthropic-ai/claude-code
claude
En entornos donde npm queda bloqueado por un proxy o por restricciones regionales, puedes instalarlo desde el gestor de paquetes del sistema.
brew install --cask claude-code # macOS / Homebrew
winget install Anthropic.ClaudeCode # Windows / WinGet
Decídete por una única forma de instalarlo. Si después de npm lo instalas también con Homebrew, aparecerá Multiple claude installations found. No saber cuál de los dos está funcionando complica todo el trabajo de diagnóstico posterior. Los requisitos cambian según el entorno, así que ante la duda ve a la documentación oficial.
Iniciar sesión: cuenta o clave de API
En el primer arranque eliges el método de acceso. Si entras con tu cuenta de Claude, se abre el navegador y, tras iniciar sesión y conceder el permiso, queda autenticado. Lo que consumes es el cupo de tu plan, y ese consumo se manifiesta en forma de límites y horas de reinicio. La clave de API no funciona con cupo sino con saldo, y se detiene cuando se agota. Para uso personal, lo primero; para CI y automatizaciones, lo segundo.
Cuál de los dos tienes disponible depende de tu contrato, así que no lo damos por sentado. Solo hay un punto que conviene recordar.
La clave de API en una variable de entorno tiene prioridad sobre el inicio de sesión de la suscripción. Si escribiste ANTHROPIC_API_KEY en la configuración de tu shell durante alguna prueba antigua y lo has olvidado, aunque inicies sesión correctamente esa sesión se ignora. La mayoría de los «tengo contrato y me dice que no hay saldo» son esto.
Con qué credencial está funcionando ahora mismo te lo contesta /status. Míralo antes de sospechar.
/status # con qué credencial está funcionando ahora
env | grep ANTHROPIC # si queda alguna clave en las variables de entorno
unset ANTHROPIC_API_KEY # si queda, quítala. Bórrala también del archivo de configuración
/login # vuelve a entrar y confírmalo de nuevo con /status
Qué ocurre en el primer arranque
Una vez autenticado, arráncalo después de moverte a la carpeta en la que quieres trabajar. Claude Code toma «la carpeta en la que estás» como objeto de trabajo, así que si te equivocas empezará a leer un sitio que no tiene nada que ver.
cd my-project
claude
La pantalla que espera tu entrada es la puerta del diálogo. Aquí recomiendo no pedir de entrada una reescritura. El primer movimiento debería ser una petición que se resuelva solo con lectura: «lee el README y los directorios principales y explícame qué hace este proyecto».
Por tres razones. La lectura no exige confirmación ni siquiera por defecto, así que sale adelante sin conocer aún la mecánica de la aprobación. Como tú conoces el proyecto, puedes contrastar la respuesta. Y verificas de golpe la conexión, la autenticación y la carpeta de trabajo sin romper nada. Si aparece algún comportamiento raro, lo resuelves antes de pasar a las reescrituras.
El bucle de instrucción, diff y aprobación
Cuando la lectura ha funcionado, pídele una reescritura pequeña. De aquí en adelante siempre son los mismos cuatro tiempos.
Díselo tal cual, en español. Si puedes indicar dónde hay que tocar, indícalo.
Busca y lee los archivos que puedan estar implicados. Es el STEP 1 del capítulo 1.
Sale línea por línea el «esto lo cambio así» y ahí se detiene.
Si lo dejas pasar, se aplica. Si no encaja, rechaza y explica con palabras qué falla.
Tú: «Añade al README el caso de Windows»
↓
[BUSCAR] localizar el README ← lectura. no se detiene
↓
[LEER] leer README.md ← lectura. no se detiene
↓
[EDITAR] añadir 3 líneas ← aparece el diff y se detiene
↓
Tú: apruebas / rechazas y explicas la corrección
Rechazar no es un fracaso. Como puedes hablar con concreción después de ver el diff, no necesitas acertar de pleno con la primera instrucción: esa es la virtud de este formato.
Cada petición debe tener «un tamaño de diff que puedas leer entero». Cuanto mayor es la petición, más largo es el diff, y los diffs largos se aprueban sin leerlos. Una aprobación que pulsas sin leer no es una aprobación: es una aprobación automática. Cómo trocear el trabajo lo vemos en el capítulo 3.
Con qué modo conviene empezar
Lo que decide dónde se detiene es el modo de permisos. En la terminal se cambia con Shift+Tab; en VS Code, en la aplicación de escritorio y en el navegador, con el selector que hay junto al campo de entrada.
La lectura es automática. Las ediciones y la ejecución de comandos se confirman siempre. El primer día, este.
Deja pasar automáticamente las ediciones dentro de la carpeta de trabajo. Para quien prefiere leer los diffs todos juntos después.
Investiga, pero no edita el código fuente. Al aprobar el plan pasa a ejecutarlo.
Otro modelo evaluador detiene solo las operaciones peligrosas y el resto avanza sin confirmación. Sujeto a condiciones.
Sin confirmaciones y sin comprobaciones de seguridad. Solo para entornos aislados. No es algo que se toque el primer día.
Lo que recorre Shift+Tab son los tres primeros. El modo automático se suma al ciclo cuando se cumplen sus condiciones, y la primera vez aparece una confirmación de aceptación explícita. Saltarse los permisos solo está activo si arrancas con su propia opción. Para fijar el modo desde el arranque, indica claude --permission-mode plan. Además existe dontAsk, que no aparece en el selector: ejecuta únicamente lo que hayas permitido y solo existe en la configuración y en la CLI.
La respuesta para el primer día es «déjalo como está». Cada confirmación que aparece es práctica para distinguir si aquello es una lectura, una escritura o una ejecución. Primero distinguir y luego aflojar; al revés acabas aflojando sin saber qué has aflojado. El segundo modo que conviene conocer es el modo plan.
Hay lugares que quedan protegidos en cualquier modo. La escritura en rutas críticas como .git, .claude o los archivos de configuración del shell no se aprueba de forma automática en ningún modo salvo en el de saltarse los permisos. Aflojar no significa que se afloje todo.
El detalle de cada modo está en el artículo sobre los modos de permisos, y cómo escribir permisos y denegaciones herramienta por herramienta, en el artículo sobre reglas de permisos y configuración. Y ojo: la respuesta a «las confirmaciones son un fastidio» no es saltarse los permisos. Ese modo no protege ni frente a un error de manejo ni frente a instrucciones incrustadas en el contenido que se ha leído. Si quieres reducirlas, escribe primero reglas que permitan solo las operaciones en las que confías. El diseño se ve en el capítulo 5.
CLAUDE.md: dejar de repetirte
Con dos días de uso ya notas que «estoy dando siempre el mismo aviso». «No toques esta carpeta», «pasa el lint antes de confirmar los cambios»: teclearlo cada vez es una pérdida de tiempo y de contexto. Para eso colocas un CLAUDE.md en la raíz del proyecto. Claude Code lo lee automáticamente al arrancar y trabaja dando por supuesto lo que hayas escrito ahí.
# Este proyecto
- TypeScript / Next.js. El gestor de paquetes es npm
- Respuestas y comentarios en el código, en español
## No tocar
- Todo lo que cuelga de src/legacy/ (lo lleva otro equipo)
- .env y sus derivados
## Verificación
- Tras un cambio, pasa npm run lint y npm test
- No lo des por terminado mientras queden errores de tipos
Lo que va dentro lo decide «aquello que la IA no tiene forma de saber».
Con qué comando se comprueba. Es lo que más rinde, porque hace posible el STEP 3 del capítulo 1.
Artefactos generados, territorio de otros equipos, archivos con secretos. Y las reglas que no se deducen mirando el código, como «las páginas nuevas van aquí».
Cosas del tipo «escribe código legible». No hay forma de juzgar si se han cumplido y lo único que hacen es diluir las líneas que de verdad quieres que se respeten.
La forma de hacerlo crecer también está clara. Empieza con unas pocas líneas. Cuando des el mismo aviso dos veces, añade una línea. Si intentas escribirlo todo de golpe, te sale un archivo largo y ambiguo que deja de respetarse. Cuando algo «no se respeta», la causa suele ser una de estas tres: demasiado, demasiado abstracto o contradictorio.
Las reglas de permisos y la elección de modelo pueden repartirse entre .claude/settings.json (del proyecto) y ~/.claude/settings.json (personal), pero el primer día basta con unas líneas en CLAUDE.md. Cuándo usar cada cosa se ve en el capítulo 6.
Las tres cosas que más se rompen el primer día
Los atascos no se reparten al azar, y el primer día casi siempre son estos tres.
Está instalado, pero no está donde se puede invocar. Añade ~/.local/bin (en Windows, %USERPROFILE%\.local\bin) al PATH. A veces la causa es una instalación duplicada.
El clásico: una ANTHROPIC_API_KEY antigua está sobrescribiendo la suscripción. Compruébalo con /status y vuelve a entrar después de quitar la variable de entorno.
Claude Code consume entre 10 y 100 veces los tokens de un chat. Es lo que suman las idas y venidas y la lectura de archivos.
Sobre el tercero hay un malentendido. El mensaje que viene a decir «el servidor está limitando temporalmente las peticiones» no habla del cupo de tu plan, sino de una restricción temporal del lado del servidor, y con esperar un poco vuelve a pasar. Si has llegado o no al cupo lo distingues con /usage.
claude doctor # diagnóstico global de instalación, configuración, MCP y contexto
/status # con qué autenticación está funcionando ahora
/context # desglose de qué se está comiendo el contexto
claude update # si no lo ves claro, sube a la última versión (arregla bastantes fallos)
El último, claude update, funciona más de lo que parece. Hay bastantes fallos que desaparecen solo con subir de versión, así que pasarlo antes de empezar a investigar te ahorra perseguir un problema que ya no existe. Las soluciones por síntoma están en el artículo de errores frecuentes y su remedio. El procedimiento de diagnóstico lo vemos en el capítulo 4.
Resumen
- Hay cinco puertas de entrada. El interior es el mismo, pero para la primera hora conviene la terminal, que da más información
- La vía estándar es
npm install -g @anthropic-ai/claude-code. Si no pasa, Homebrew o WinGet. Quédate con una sola forma de instalarlo - El acceso es por cuenta (cupo) o por clave de API (saldo). La clave en una variable de entorno sobrescribe la suscripción: ante la duda,
/status - El primer movimiento debe ser una petición de solo lectura. Verifica conexión, autenticación y carpeta de trabajo de una vez, y no rompe nada
- Lo que gira es instrucción, diff y aprobación. Trocea las peticiones a un tamaño de diff que puedas leer entero. Aprobar sin leer equivale a aprobar de forma automática
- El modo del primer día es el de por defecto (pedir permiso), y el segundo, el modo plan. Las rutas protegidas como
.gitse respetan siempre salvo al saltarse los permisos CLAUDE.mdva en la raíz y empieza con unas líneas. Escribe cómo verificar, qué no tocar y las convenciones de este sitio, y deja fuera las generalidades- Los atascos del primer día son el PATH, la clave en variables de entorno y el consumo. Los primeros movimientos son
claude doctor,/statusy/context
Cuando tu primera instrucción salga adelante, toca montarlo sobre el trabajo de cada día. Pasa al capítulo 3, «El flujo de trabajo diario».