Antes de Claude Code: IA, LLM, agentes y herramientas

El mapa: IA, aprendizaje automático, LLM y Claude Code

Si empiezas desde cero, la primera dificultad no es técnica: es entender que palabras muy parecidas indican cosas distintas. Pongamos orden ahora, para que más adelante siempre sepas quién está produciendo una respuesta y quién, en cambio, está actuando de verdad sobre tus archivos.

Inteligencia artificial, o IA, es un nombre amplio para sistemas que realizan tareas asociadas con la inteligencia humana, como reconocer imágenes, predecir valores o producir texto. El aprendizaje automático es una familia de técnicas con la que un sistema aprende regularidades a partir de muchos ejemplos en lugar de recibir una regla escrita para cada caso. La IA generativa es la parte que crea nuevos contenidos, como texto, imágenes, audio o código.

Un Large Language Model, abreviado LLM, es un modelo generativo entrenado con grandes cantidades de texto y código. Claude es una familia de LLM. Claude Code es una aplicación que usa un modelo Claude y añade instrucciones operativas, acceso controlado a herramientas y un ciclo de verificación para trabajar en un proyecto. Estos nombres no son sinónimos: Claude Code conecta el modelo con capacidades operativas que el LLM por sí solo no posee.

1. Empieza por el conjunto más amplio: IA.
2. Dentro encuentras el aprendizaje automático y, entre sus usos, la IA generativa.
3. Un LLM es un tipo de modelo generativo especializado en lenguaje.
4. Claude es una familia de LLM; Claude Code los conecta con un entorno de trabajo.

Cómo nace una respuesta: tokens, probabilidad y límites

Una respuesta fluida puede parecer el resultado de un razonamiento infalible. En realidad nace de muchas pequeñas predicciones sucesivas. Entender este paso evita el error más común: confundir una frase bien escrita con un hecho ya verificado.

Un LLM no busca una respuesta completa en un archivo. Recibe una secuencia, la divide en unidades llamadas tokens y estima qué token es plausible después de los ya presentes. Un token puede ser una palabra breve, una parte de palabra, un signo o un espacio: no siempre coincide con una palabra. La respuesta nace un token a la vez, repitiendo la predicción muchas veces.

Durante el entrenamiento, el modelo aprendió patrones estadísticos del lenguaje y del código. Esto le permite explicar, resumir y proponer soluciones, pero no le da automáticamente consciencia, intenciones ni acceso a hechos actualizados. Una frase muy segura todavía puede estar equivocada. Además, pequeñas diferencias en la solicitud o en la generación pueden producir respuestas distintas.

El modelo es, por tanto, útil como motor de interpretación y propuesta, no como fuente infalible. Para una tarea real debes darle el contexto correcto y contrastar la salida con pruebas externas: archivos existentes, documentación fiable, tests u observaciones directas.

Prompt, contexto, ventana y memoria no son lo mismo

Prompt, contexto y memoria se usan a menudo como si fueran lo mismo. No lo son. El prompt es la petición que haces ahora; el contexto es lo que el modelo puede ver ahora; la memoria es una forma de conservar y recuperar cierta información a lo largo del tiempo.

El prompt es lo que pides en un momento dado. El contexto es el conjunto de información que el modelo puede usar mientras genera la respuesta: la conversación disponible, las instrucciones, los archivos aportados y los resultados de las herramientas. La ventana de contexto es el límite de capacidad de ese conjunto. Cuando el trabajo crece, algunas partes pueden resumirse, excluirse o volverse menos relevantes.

La memoria es información conservada y recuperada entre momentos o sesiones; no es toda la ventana de contexto ni significa que el modelo recuerde todo. Incluso un dato guardado puede estar incompleto o no ser recuperado. Más adelante usarás archivos de instrucciones y mecanismos de memoria, pero siempre tendrás que comprobar que la regla importante de verdad esté presente en el contexto actual.

Un buen contexto no es el más largo posible. Contiene los hechos que cambian una decisión: objetivo, estado real, límites, ejemplos pertinentes y criterio de éxito. La información vieja o contradictoria puede empeorar la respuesta tanto como la información que falta.

Alucinaciones, incertidumbre y evidencias

Cuando un modelo inventa un nombre de archivo o una función, no está intentando engañarte: está completando un vacío con una continuación plausible. Para ti, sin embargo, el efecto práctico es el mismo que el de una información falsa. Por eso hace falta un método para reconocerlo antes de que guíe un cambio.

Se habla de alucinación cuando el modelo produce una afirmación plausible pero no sostenida por los hechos: puede inventar un archivo, citar una función que no existe o describir un test que nunca se ejecutó. No es una mentira intencional; es el efecto de generar la continuación lingüísticamente plausible sin una verificación suficiente.

Reduce el riesgo pidiendo al sistema que observe antes de concluir. Si habla de un proyecto, debe indicar los archivos reales que ha leído. Si propone un cambio, debe mostrar el diff. Si declara que el comportamiento funciona, debe ejecutar una comprobación pertinente e informar del resultado. Una prueba no vuelve verdadero todo lo demás: debe sostener exactamente la conclusión declarada.

1. Separa lo que se ha observado de lo que solo se ha supuesto.
2. Pide la fuente o el artefacto que sostiene la conclusión.
3. Comprueba que el test realmente mida el comportamiento prometido.
4. Mantén explícitas las dudas, los límites y las verificaciones no realizadas.

De chatbot a agente: quién decide y quién actúa

Un agente no es simplemente un chatbot que escribe más. Es un sistema que puede observar un resultado, elegir un paso, usar una herramienta y decidir qué hacer después. La parte decisiva es el ciclo, no la cantidad de autonomía declarada.

En un chat, el ciclo típico es pregunta y respuesta. En cambio, un agente recibe un objetivo, interpreta el contexto, elige una acción, usa una herramienta, observa el resultado y decide si detenerse o continuar. Podemos describirlo así: agente = LLM + instrucciones + contexto + herramientas + feedback + permisos + condición de parada.

El modelo propone el siguiente paso; la herramienta realiza la acción concreta. Leer un archivo, ejecutar un test o buscar en la web no ocurre por el solo hecho de que el modelo lo describa: hace falta una capacidad conectada y autorizada. El resultado de la herramienta vuelve al contexto, para que el agente pueda corregir el plan.

Autonomía no significa ausencia de control. Eres tú quien define el objetivo, el alcance, los checkpoints y cuándo puede aceptarse un resultado. Un agente fiable también debe saber detenerse cuando falta un permiso, se encuentra una sorpresa o no dispone de una prueba adecuada.

Herramientas, permisos y límites de seguridad

Un permiso no es un botón burocrático que se acepta para poder continuar. Es el límite dentro del cual un error puede producir efectos reales. Antes de concederlo debes entender acción, destino y posibilidad de recuperación.

Una herramienta es un puente hacia una acción: puede leer una carpeta, modificar un archivo, lanzar un comando o contactar un servicio. Un permiso establece qué acciones están permitidas. Sin embargo, autorizar una herramienta no demuestra que la acción sea correcta, y la aprobación de una persona no sustituye la verificación del resultado.

Concede lo mínimo necesario. Para entender un proyecto basta con empezar en solo lectura; para corregir un archivo local hace falta escritura limitada a la carpeta del proyecto; para publicar, borrar o enviar datos al exterior hace falta un checkpoint explícito. Cuanto más amplia, irreversible o externa sea la acción, más fuerte debe ser el control humano.

Antes de aprobar, lee la acción propuesta en términos concretos: qué comando, qué archivos, qué destino y qué efecto. Si no los entiendes, pide una explicación o una simulación. Detenerse no es un fracaso: es el comportamiento correcto cuando la autoridad o la información no bastan.

1. Identifica la acción real detrás de la solicitud de permiso.
2. Limita el permiso a la carpeta, al comando y al tiempo necesarios.
3. Prevé una confirmación separada para acciones remotas o irreversibles.
4. Comprueba el resultado con una prueba independiente de la aprobación.

Archivos, carpetas, terminal y Git: el lugar de trabajo

El terminal puede parecer hostil porque responde con texto seco, pero su comportamiento es regular: ejecuta un comando en una carpeta y devuelve un resultado. Git añade un historial de cambios. Juntos te permiten ver qué ha pasado, en vez de confiar en la memoria.

Un proyecto es una carpeta que contiene archivos y, a menudo, otras carpetas. Una ruta indica dónde se encuentra un elemento. El terminal es una interfaz textual: muestra un prompt, recibe un comando, lo ejecuta en la carpeta actual y devuelve salida más un estado de éxito o error. No necesitas memorizar muchos comandos; necesitas saber dónde estás y leer qué ha ocurrido.

Git registra la historia de los archivos de un proyecto. `git status` distingue archivos no rastreados, cambios preparados y cambios aún fuera del próximo commit. De forma predeterminada, `git diff` muestra los cambios no preparados de los archivos ya rastreados; `git diff --staged` muestra los ya preparados. Un commit registra intencionalmente el estado preparado con un mensaje. Git no es automáticamente una copia de seguridad completa: antes de restaurar o borrar, comprueba siempre el estado real.

Para la primera misión te bastan cuatro conceptos: carpeta actual, archivo modificado, diferencia observable y comprobación ejecutada. El agente puede teclear o proponer comandos, pero la salida pertenece al proceso real. Si el comando falla, ese fallo es información que debe leerse, no texto que deba ocultarse.

La primera misión guiada, de la observación a la prueba

Ahora unimos las piezas en una misión minúscula. El objetivo no es demostrar que el agente puede hacer mucho; es demostrar que tú sabes mantener visibles objetivo, autorización, cambio y prueba de principio a fin.

En esta simulación guiada, una pequeña app local llamada Task Notes debe cambiar una sola etiqueta: de «Mis cosas» a «Mis actividades». No necesitas tener la app ni ejecutar comandos. Usas el escenario para ensayar las decisiones en orden; en el Módulo 2 aplicarás el mismo método a un entorno real.

La secuencia empieza con una lectura sin cambios. Haces que te indiquen dónde aparece el texto y pides un plan de una línea. Concedes una escritura limitada, imaginas revisar el diff y eliges una prueba pertinente. Aceptas el trabajo solo si archivo, diferencia y comportamiento cuentan la misma historia.

1. En el escenario, sitúa la misión en la carpeta Task Notes e identifica los archivos disponibles.
2. Formula la solicitud de solo lectura: «Encuentra dónde aparece “Mis cosas”. No modifiques nada».
3. Prevé contrastar la respuesta con el archivo indicado antes de autorizar cambios.
4. Formula un cambio limitado a esa etiqueta y pide un plan breve.
5. Elige el permiso mínimo: escritura solo en la carpeta del proyecto local.
6. Pide como evidencia un `git diff` limitado a lo que has solicitado.
7. Elige un test o una comprobación del resultado visible como segunda prueba.
8. Define el criterio: aparece «Mis actividades» y todo lo demás sigue funcionando.
9. Establece la parada: ante un cambio inesperado, no continúes y pide una explicación.