En mi primera clase de programación de la universidad me pidieron escribir código en papel, según ellos para que no hiciera trampa buscando en Google. Yo creo que lo siguen haciendo así, pero la realidad en la industria es que cada vez se escribe menos código tecleando (mucho menos con papel) y cada vez más a través de modelos de lenguaje.
Productos como Claude Code, Codex y Cursor se han vuelto una especie de prisma a través del cual se interactúa con el código: una capa de abstracción que incluso ha iniciado el fenómeno del vibecoding, donde ni siquiera importa entender el código o la arquitectura de un sistema y solo importa describir en lenguaje natural el resultado al que se quiere llegar.
Esto ha iniciado una ola de productividad, pero también algunos errores garrafales como cuando Claude, a través de Cursor, borró una base de datos de producción y todos los backups de PocketOS, una SaaS para negocios automotrices.
Por eso encuentro importante entender cómo funcionan las herramientas con las que trabajamos, incluso si ya no escribimos código a mano.
El harness o los arneses
Mucho de lo que hace especial a herramientas como Claude Code es todo lo que rodea al modelo, lo que se denominó como el “harness” (arnés en inglés). Este se refiere a las herramientas que puede utilizar el modelo, el system prompt, las restricciones y también el ciclo de retroalimentación que utiliza. El harness es tan importante como el modelo en sí mismo.
El modelo
El modelo de lenguaje sigue siendo una especie de autocompletado que intenta predecir el siguiente token. Los tokens son la manera en la que los modelos de lenguaje (o LLMs por sus siglas en inglés) ven el texto. Un token es un pedazo de una palabra, aunque no hay una regla clara del tamaño de cada token porque depende del tokenizer de cada modelo.Puedes ver cómo hace OpenAI para desglosar un texto en tokens en la siguiente página: https://platform.openai.com/tokenizer. Los humanos manipulamos palabras, pero los modelos manipulan tokens. Para nosotros “Fintual” es una sola palabra, pero para un LLM podrían ser tres tokens: F-int-ual.
Los modelos no tienen memoria, no saben quién eres, no tienen recuerdos de ninguna conversación y solo conocen lo que está en su contexto. Por eso se dice que los modelos son “stateless”, porque no almacenan información entre interacciones. Aunque hay maneras de simular la memoria a través de archivos de texto o bases de datos, el truco sigue siendo ir a buscar esa información por fuera del modelo e incluir los textos relevantes en el contexto.
Que los modelos sean stateless significa que cada vez que envías una instrucción a Claude Code, el modelo termina recibiendo todo el historial de conversación. Por eso en conversaciones largas comienza a alucinar o a tomar malas decisiones.
El system prompt
Los modelos son como los innies de Severance despertando en un cuarto sin recordar quiénes son, pero sabiendo que Delaware es un estado de EE.UU. Por eso hay que darles una identidad, eso es lo que hace el system prompt: les dice quiénes son, dónde están, las reglas y cuál es su objetivo.
El system prompt podría ser algo como “You are Mark, an autonomous software engineering assistant running inside a developer’s local project...”.
Sin el system prompt, Claude se puede confundir y pensar que es DeepSeek, como ya ocurrió con el modelo Sonnet 4.6.https://x.com/stevibe/status/2026227392076018101
Las herramientas
Además de darles una identidad, hay que darles las herramientas que pueden usar. Esto también se incluye en el prompt. Por ejemplo si se quiere que el modelo pueda ejecutar comandos de terminal se le puede pasar una herramienta de bash y explicarle para qué sirve:
{
"type": "custom",
"name": "bash",
"description": "Run a bash command on the local machine. Input should be a single safe bash command. Do not use destructive commands, network access, privilege escalation, or commands that modify files unless explicitly requested."
}
Entonces, cada vez que envías una instrucción el modelo termina recibiendo el system prompt, las herramientas y el historial de conversación en su contexto.
Las restricciones
En la programación estamos acostumbrados a que el código es determinista: el mismo input nos dará siempre el mismo output. El problema con los modelos de lenguaje es que su naturaleza es probabilística, o sea que no siempre el mismo input nos dará el mismo output. Eso hace que no se pueda confiar en los modelos: hay que incluir restricciones fuera del modelo y esas restricciones deben ser deterministas.
En el ejemplo de herramienta de bash de arriba, puede ser problemático confiar en la instrucción “Do not use destructive commands”. El modelo puede desobedecer la orden o puede simplemente olvidarla porque quedó sepultada en su contexto. Por eso, cada vez que el modelo quiera llamar a una herramienta hay que verificar, con código, fuera del modelo, que no haga una acción destructiva.
El ciclo de retroalimentación
Como los modelos no tienen memoria, cada vez que una herramienta devuelve un resultado, hay que pasarle ese resultado de regreso al modelo junto con todo lo demás (el system prompt, el historial de conversación y las herramientas que tiene disponibles). Esto hace un ciclo de retroalimentación que le permite al modelo tener todo el contexto para decidir si necesita llamar a otra herramienta o escribir una respuesta final al usuario.
Todo junto
Esos son los componentes fundamentales que hacen a Claude Code funcionar, aunque por supuesto hay mucha creatividad e ingeniería detrás del system prompt, las descripciones de las herramientas y las restricciones. Que sean componentes tan entendibles nos recuerda que no es magia y que quizás hay que seguir desconfiando un poquito de estas herramientas, al menos hasta el siguiente gran salto en capacidades de los modelos.
