Claude Code para principiantes

Claude Code es un asistente de programación con IA que se ejecuta dentro de tu propio proyecto: puede leer tus archivos, proponer y escribir código, ejecutar comandos en la terminal y explicarte lo que hace, todo en lenguaje natural. No es autocompletado — le puedes pedir una tarea entera ("crea una página de contacto con un formulario") y te propone cómo hacerla.

Necesitas dos cosas antes de empezar: VS Code ya instalado (ruta anterior) y una cuenta en claude.com.

La forma más sencilla de instalarlo es como extensión de VS Code:

1. Abre VS Code y pulsa el icono de Extensiones en la barra de actividades.
2. Busca "Claude Code" (de Anthropic) e instálala.
3. Se abrirá un panel lateral nuevo. La primera vez te pedirá iniciar sesión con tu cuenta de Claude — sigue el proceso en el navegador que se abre solo.
4. Abre la carpeta de tu proyecto en VS Code (igual que en la lección de interfaz de la ruta VS Code) antes de empezar a pedirle nada — Claude Code trabaja sobre esa carpeta.

Al pedirle algo así, Claude Code no cambia tus archivos a ciegas: te muestra exactamente qué va a crear o modificar (como un diff, en verde lo que añade) y te pide confirmación antes de tocar nada. Tú decides si aceptar, pedir un cambio, o rechazarlo.

También puedes usarlo sin VS Code, directamente en una terminal — es la misma herramienta por debajo, sin panel gráfico de por medio. Útil si trabajas contra un servidor remoto por SSH (como en la ruta Servidor) o simplemente prefieres la terminal.

Necesita Node.js instalado. El comando claude arranca una sesión interactiva en la carpeta donde estés — igual de conversación, mismo diff antes de aceptar. La extensión de VS Code no es más que una capa visual sobre este mismo CLI.

En la lección 1 le pediste crear un archivo desde cero — el caso más fácil. La mayoría de encargos reales son sobre código que ya existe, y ahí la calidad del resultado depende sobre todo de cómo pidas el cambio. Un prompt vago da un resultado vago; uno concreto da un resultado concreto.

Tres cosas que marcan la diferencia en cualquier instrucción:

• Nombra el archivo o la zona exacta — "cambia el color del botón" es ambiguo si hay diez botones; "cambia el color del botón .btn-primary en estilos.css" no lo es.
• Describe el resultado, no solo la acción — no solo "añade validación al formulario", sino qué debe pasar si el email está vacío o mal escrito.
• Da una pista de por qué, cuando la haya — "el título no debe superar 60 caracteres, es para SEO" evita que el asistente elija un límite al azar.

Cuando la tarea es grande, no hace falta metértela entera de golpe: puedes pedirla por pasos, revisando cada uno antes de seguir. Es más lento al principio, pero mucho más fácil de corregir si algo se tuerce, porque el error queda acotado a un paso concreto en vez de mezclado con todo lo demás.

Si no estás seguro de si el asistente ha entendido bien lo que quieres, pídele que te lo explique antes de tocar nada — es una instrucción tan válida como cualquier otra, y sirve para detectar un malentendido antes de que se convierta en código.

En las lecciones 1 y 2 ya viste que Claude Code no toca ningún archivo sin mostrarte antes qué va a hacer. Esta lección es sobre esa pantalla intermedia: qué mirar exactamente antes de pulsar "aceptar", porque ahí es donde de verdad decides tú, no la IA.

Cuando propone cambiar un archivo, verás un diff — el mismo formato que ya conoces de Git (ruta VS Code, lección 4): en rojo lo que se borra, en verde lo que se añade. Antes de aceptar, comprueba tres cosas rápidas:

• ¿Toca solo lo que pediste? — si le pediste cambiar un color y el diff incluye líneas sueltas en otra función o archivo, pregunta por qué antes de aceptar.
• ¿Borra algo que no esperabas? — una línea en rojo que no tiene relación con tu petición es la señal más clara de que algo se ha entendido mal.
• ¿Vas a poder deshacerlo si algo falla? — si el archivo está en Git (lección 4 de la ruta VS Code) y tienes commits recientes, siempre puedes volver atrás. Si no está versionado, piénsatelo dos veces antes de aceptar un cambio grande de golpe.

No hace falta aceptar todo el diff de golpe si el editor te deja revisar por partes — y si no te convence nada, la respuesta correcta no es aceptar "total, seguro que está bien", sino escribir qué está mal y dejar que lo corrija. Es exactamente el mismo criterio de la lección 2: cuanto más concreto seas al rechazar, mejor sale el segundo intento.

El otro caso a vigilar es cuando te propone ejecutar un comando en la terminal, no solo editar un archivo — por ejemplo, instalar algo, borrar archivos o conectarse a un servidor. Ahí el riesgo ya no es "una línea de código rara", es una acción real sobre tu ordenador o, peor, sobre un servidor en producción. La misma regla de oro de la lección 1 se aplica con más fuerza todavía: lee el comando entero antes de aceptar, y si no entiendes qué hace alguna parte, pregúntaselo primero a la propia IA — es una pregunta válida, no una pérdida de tiempo.