Claude Code es una IA que vive en tu terminal y lee y escribe directamente en tu repositorio. Pegar código en la caja de chat del navegador y copiar de vuelta lo que responde: ese viaje de ida y vuelta desaparece.

Este capítulo construye el modelo mental sobre el que se apoyan los seis capítulos restantes. Si te lo saltas, en los capítulos siguientes nunca acabarás de entender por qué las cosas están diseñadas así.

Primero, dónde se sitúa: en qué lugar funciona esta herramienta

Las herramientas que hacen que la IA escriba código se dividen en tres grupos según el lugar donde funcionan. Claude Code pertenece al primero.

TYPE 1
Agentes CLI

Funcionan en la terminal y tocan los archivos directamente. Claude Code, Codex CLI y similares. Buenos para encargarles un bloque entero de trabajo.

TYPE 2
Editores con IA

Van integrados en el editor y sugieren justo al lado de lo que estás escribiendo. Cursor, GitHub Copilot y similares. Buenos para escribir viéndolo.

TYPE 3
Generadores en la nube

Todo ocurre en el navegador y desde ahí mismo puedes publicar. v0, Bolt, Lovable y similares. Buenos porque no exigen montar un entorno.

La comparación de los tres tipos en sí la tratamos en el capítulo 1 del curso de coding con IA. Este curso se ciñe al primer tipo y entra a fondo.

Por cierto, Claude Code no es exclusivo de la terminal. Lo mismo está disponible como extensión de VS Code o de JetBrains, como aplicación de escritorio y desde el navegador. Pero su forma de pensar nace en la terminal, y en cuanto entiendes eso ninguna de las otras puertas de entrada te desorienta.

La diferencia decisiva frente a las herramientas de chat

«Si Claude en el navegador también escribe código, ¿qué cambia en realidad?»: esa pregunta sale siempre la primera. La diferencia no está en la inteligencia, sino en el alcance.

Estilo chat (Claude en el navegador)

Solo ve lo que tú pegas. Lo que devuelve es texto. Quien lo aplica eres tú. Cuando el cambio abarca 10 archivos, son 10 pegados y 10 viajes de vuelta.

Estilo agente (Claude Code)

Busca y lee por su cuenta. Lo que devuelve es un diff. Ejecuta las pruebas y, si fallan, las arregla y las vuelve a ejecutar. Esos 10 archivos los localiza él solo.

La diferencia se nota cuando el trabajo incluye averiguar cosas. «Rastrea desde dónde se llama a esta función y arréglalo todo» significa que el rastreo lo haces tú, con una herramienta de chat. Un agente lanza la búsqueda él mismo.

Dale la vuelta y verás que, cuanto mayor es el alcance, mayor es el daño cuando se equivoca. Por eso hay que diseñar los permisos (capítulo 5). Que sea listo no significa que sea seguro.

El bucle del agente: reunir, actuar, verificar

Mientras Claude Code trabaja, por debajo gira siempre el mismo ciclo.

STEP 1
Reunir el contexto

Busca archivos, los lee y hace búsquedas cuando hace falta. Lo que le dejas leer aquí decide el resultado.

STEP 2
Actuar

Reescribe archivos y ejecuta comandos. Aquí es donde se sitúa la barrera de permisos.

STEP 3
Comprobar el resultado

Lee la salida de las pruebas y de la comprobación de tipos. Si han fallado, vuelve al STEP 1.

Lo importante es que el STEP 3 exista. Una herramienta de chat se queda en «esto probablemente esté bien». Un agente puede ejecutar su propia salida y salir de dudas. Poder seguir corrigiendo hasta que las pruebas pasen viene de este bucle.

Lo cual significa también que la ventaja desaparece en las tareas que no puedes verificar. «Limpia este código» no tiene definición de éxito, así que el bucle gira en vacío. El patrón que vemos en el capítulo 3, darle de antemano una forma de verificar, sale justo de aquí.

Herramientas y permisos: qué puede hacer y qué puedes detener

Lo que Claude Code puede hacer lo fija el conjunto de «herramientas» que se le han dado. Leer un archivo, escribir un archivo, ejecutar un comando, buscar: cada cosa es una herramienta aparte.

Y cada llamada a una herramienta pasa por una comprobación de permisos. Por defecto te pide aprobación cada vez que reescribe un archivo o ejecuta un comando. Existen ajustes que se saltan esa aprobación, y el capítulo 5 explica qué hay que vigilar ahí.

Tú: «Arregla las pruebas de la autenticación» ↓ [BUSCAR] localizar los archivos de auth ← lectura. sin confirmación por defecto ↓ [LEER] leer auth.test.ts ← lectura ↓ [EDITAR] reescribir auth.test.ts ← escritura. aquí llega el aviso ↓ [EJECUTAR] lanzar npm test ← ejecución. otro aviso aquí ↓ leer el fallo y volver a [EDITAR]

En cuanto ves este flujo, sabes por qué se ha parado donde se ha parado. No se ha atascado. Ha chocado con una barrera de permisos.

La ventana de contexto como limitación

Hay un techo para lo que Claude Code puede «tener presente» a la vez. Ese techo es la ventana de contexto. Cuanto más se alarga la conversación y más archivos lee, más se llena.

A medida que se llena, pasan dos cosas.

Las respuestas se vuelven pesadas

Relee un historial enorme en cada turno, así que va más lento y cuesta más. Esto enlaza directamente con el capítulo 7, dedicado al coste.

Se olvida la primera parte

Las premisas que fijaste al principio quedan desplazadas. El «pero si ya te lo había dicho» suele ser esto.

El remedio es plegar la conversación: resumirla y comprimirla, o cortarla y empezar una nueva. Saber cuándo plegarla exige criterio, así que ¿conviene ejecutar /compact a mano? repasa las pautas. Los pasos prácticos están en el capítulo 3.

Para qué sirve y para qué no

El contorno de una herramienta se capta aprendiendo en qué es mala.

Buen encaje

Correcciones que abarcan varios archivos / investigar código existente / iterar hasta que pasen las pruebas / trabajos de migración rutinarios / rastrear la causa a partir de un mensaje de error

Mal encaje

Trabajos sin definición de lo correcto / terreno que no puedes ejecutar y comprobar / decisiones de negocio que solo conoces tú / correcciones de una línea (sale más caro el ida y vuelta de la aprobación)

El lado del «mal encaje» no es cuestión de capacidad. Es estructural: el bucle de verificación no puede girar. Por eso cambiar a un modelo más listo no lo resuelve.

El mapa de este curso

Aquí tienes dónde se sitúan los seis capítulos restantes. Leerlos en orden es lo normal, pero si ya estás atascado, empezar por el capítulo 4 es perfectamente válido.

2. Instalación y la primera hora

Instalarlo, conectarlo y sacar adelante tu primera instrucción.

3. El flujo de trabajo diario

Montar el trabajo sobre los raíles de explorar, planificar, implementar y confirmar.

4. Salir de los atascos

Un procedimiento para bajar del síntoma a la causa.

5. Permisos y seguridad

Diseñar hasta dónde delegar y dónde detenerlo.

6. Ampliarlo

Cuándo echar mano de CLAUDE.md, hooks, subagents y MCP.

7. Coste y límites

Los detalles operativos para usarlo a largo plazo.

También hay un sitio de formación oficial. Anthropic mantiene una plataforma de aprendizaje gratuita, Claude Academy, que incluye un curso de Claude Code. Este curso no pretende sustituirla. Se inclina por las explicaciones en español y por el razonamiento inverso a partir de casos reales en los que la gente se atascó. Usar ambos debería ser el camino más rápido.

Resumen

  • Claude Code es una herramienta de estilo agente que funciona en la terminal y lee y escribe directamente en tu repositorio
  • Lo que la separa de las herramientas de chat no es la inteligencia, sino el alcance. Busca por su cuenta, devuelve diffs y ejecuta para comprobar
  • Por debajo hay un bucle de reunir, actuar y verificar. Como el STEP 3 existe, puede seguir corrigiendo hasta que pasen las pruebas
  • Lo que puede hacer lo fija el conjunto de sus herramientas, y cada llamada a una herramienta pasa por una barrera de permisos
  • Cuando la ventana de contexto se llena, se vuelve pesado y olvida la primera parte. Decidir cuándo plegarla exige criterio
  • Encaja mal en las tareas donde el bucle de verificación no puede girar. Cambiar de modelo no lo resuelve

A estas alturas ya deberías tener claro qué clase de herramienta es Claude Code. Lo siguiente es ponerla en marcha de verdad. Pasa al capítulo 2, «Instalación y la primera hora».