Diccionario de IA

Una etiqueta cambiante, no una tecnología. «IA» no designa algo fijo como modelo o token: señala aquello que los ordenadores empiezan a hacer de forma nueva e impresionante. Ahora se refiere a los modelos de lenguaje grandes. Antes se ha referido a cosas muy distintas:

La etiqueta cambia mediante un mecanismo conocido, a veces llamado efecto de la IA: cuando una técnica funciona de forma fiable, se le cambia el nombre —pasa a ser «simplemente» búsqueda, «simplemente» estadística— y «IA» avanza hacia lo siguiente que aún no se ha resuelto. La observación es antigua. Bertram Raphael lo expresó así en 1971: «IA es un nombre colectivo para los problemas que todavía no sabemos resolver correctamente con un ordenador». La versión de Larry Tesler, hacia 1979, fue: «La inteligencia es todo lo que las máquinas todavía no han hecho».

Por eso las conversaciones sobre IA a menudo parecen no entenderse entre sí. Afirmaciones como «la IA no puede razonar» o «la IA está sobrevalorada» llevan una fecha implícita: pueden referirse a sistemas expertos, a clasificadores de imágenes de la década de 2010 o al modelo de lenguaje grande del mes pasado, y cada referencia respalda una conclusión distinta. Cuando una conversación sobre IA se atasca, suele bastar con sustituir esa palabra por el término preciso que se quiere decir: el modelo, el harness, el agente o el contexto que recibió.

Evitar: «IA» en una afirmación técnica; nombra la parte concreta a la que te refieres. «Programación con IA» como etiqueta de una práctica está bien; «la IA está alucinando», no.

Uso:

«La directora de tecnología quiere saber si la IA podría encargarse de la cola de triaje».

«Aclaremos eso antes de definir el alcance: se refiere a un modelo de lenguaje grande dentro de un harness con acceso al sistema de tickets. Por sí sola, “IA” no es una especificación».

Los parámetros. No tiene estado: solo hace predicción del siguiente token. «Claude Opus 4.x» y «GPT-5.x» son modelos. Un modelo por sí solo no puede comportarse como agente; necesita un harness.

Los modelos no pueden leer archivos, ejecutar comandos, navegar por la web ni recordar lo de ayer: reciben tokens y predicen tokens de salida, una vez por cada solicitud al proveedor del modelo. Todo lo que parece el trabajo de un agente —elegir herramientas, leer resultados y repetir hasta terminar la tarea— es el harness orquestando muchas de esas predicciones en secuencia.

Los proveedores de modelos ofrecen modelos en distintos niveles: uno grande, más inteligente pero lento y caro, y otros más pequeños, rápidos y baratos, pero menos capaces. Elegir un nivel es una decisión real: uno potente para planificar y depurar problemas difíciles, uno ligero para cambios mecánicos. Los harnesses permiten cambiarlo a mitad de una sesión.

Ser preciso con el término también ayuda a diagnosticar. «El modelo es malo en esto» es una afirmación concreta: el mismo modelo puede comportarse de manera muy distinta con otro harness o con otro contexto. Antes de culpar al modelo, comprueba qué recibió: la mayor parte de las respuestas decepcionantes se debe al contexto o al harness, no a los parámetros.

Uso:

«¿Deberíamos cambiar el modelo de Sonnet a Opus para la fase de planificación?»

«Pruébalo, pero en esta tarea el harness hace la mayor parte del trabajo. Cambiar el modelo no ayudará si el prompt del sistema y las herramientas son incorrectos».

Los números que hay dentro de un modelo, a menudo miles de millones, ajustados durante el entrenamiento. Todo lo que el modelo «sabe» está en ellos. El entrenamiento los establece y la inferencia los usa sin modificarlos. También se llaman pesos.

En términos mecánicos, los parámetros son lo que convierte la entrada en salida. La predicción del siguiente token es un cálculo enorme: los tokens de la ventana de contexto entran, se multiplican por los parámetros y de ahí sale una predicción del token siguiente. No hay una base de datos de hechos dentro del modelo ni una tabla de consulta de código; solo estos números, organizados para que el cálculo tienda a producir resultados útiles. Los hechos que el modelo puede recitar del entrenamiento, como la API de una biblioteca estándar, son conocimiento paramétrico: están almacenados en los parámetros, no se recuperan de otro lugar.

Vale la pena interiorizar que los parámetros quedan fijos después del entrenamiento. Nada de lo que hagas en una sesión los cambia: ni las correcciones que hagas, ni el código que le enseñes, ni los errores de los que aprenda. Cada sesión funciona con los mismos números. Por eso el modelo no tiene estado, su conocimiento incorporado se detiene en el límite de conocimiento y todo lo específico del proyecto debe llegar a través del contexto. La única manera de cambiar los parámetros es entrenarlo de nuevo, lo que en la práctica produce un modelo distinto.

Uso:

«¿Podemos ajustarlo con nuestro código base?»

«Eso actualizaría los parámetros y produciría otro modelo. Para un solo proyecto casi siempre es más barato cargar la base de código como contexto que volver a entrenarlo».

El proceso que establece los parámetros de un modelo: lo expone a enormes cantidades de texto y ajusta los parámetros para mejorar la predicción del siguiente token. Es un proceso caro, que el proveedor del modelo realiza una sola vez. Incluye tanto el preentrenamiento (la fase principal) como el postentrenamiento (refinamientos posteriores, como seguir instrucciones y aplicar medidas de seguridad); en este nivel del glosario, la distinción no importa.

El mecanismo consiste en repetir a gran escala: se muestra al modelo un fragmento de texto, se le pide que prediga el siguiente token, se ajustan sus parámetros hacia el token que realmente venía después y se repite el proceso a lo largo de billones de tokens. No se almacena nada como hechos o reglas: todo lo que el modelo «sabe» es un efecto secundario de mejorar sus predicciones, comprimido en los parámetros como conocimiento paramétrico.

Dos consecuencias importan en el día a día. El entrenamiento termina en un momento concreto, así que el modelo tiene un límite de conocimiento: no ha visto la versión de la biblioteca a la que actualizaste el mes pasado. Y no puedes entrenar tú al modelo: si desconoce tu código, tus convenciones o tus API internas, la solución nunca es «enseñárselo al modelo»; consiste en poner ese material en el contexto, la única entrada que controlas.

Uso:

«¿Podemos hacer que conozca nuestra API interna?»

«No mediante entrenamiento: es un proceso que le llevaría meses al proveedor del modelo. Carga la documentación de la API en el contexto; esa es la opción que sí controlas».

Ejecutar un modelo entrenado para generar respuestas: es lo que ocurre en cada solicitud al proveedor del modelo. Los parámetros permanecen fijos; el modelo simplemente realiza predicción del siguiente token a partir del contexto que recibe. Es barato en comparación con el entrenamiento, pero se factura por token y constituye el principal coste de usar un modelo.

La vida de un modelo se divide en dos fases:

Nada de lo que hagas durante la inferencia se escribe de vuelta en los parámetros; por eso una corrección que haces hoy no perdura hasta mañana. Si el modelo comete el mismo error en la siguiente sesión después de que hayas explicado cuidadosamente cómo corregirlo, no te está ignorando: no puede aprender de ese intercambio. El modelo no tiene estado; la continuidad debe venir de fuera, de la ventana de contexto o de un sistema de memoria.

Este mecanismo también explica la facturación. Cada solicitud ejecuta el modelo sobre todo el contexto, así que el coste aumenta con los tokens de entrada y los tokens de salida, y un agente que realiza decenas de llamadas a herramientas paga la inferencia de cada intercambio. Por eso el tamaño del contexto es una cuestión de coste además de calidad.

Uso:

«¿Por qué la factura aumenta con el uso en vez de ser una licencia plana?»

«Estás pagando la inferencia: cada solicitud al proveedor del modelo lo ejecuta en el hardware del proveedor. El entrenamiento ya terminó, pero la inferencia se cobra por solicitud, y un solo turno puede convertirse en muchas solicitudes cuando se llaman herramientas».

El esfuerzo es un control que determina cuánto razona un modelo antes de responder. Se establece para cada solicitud al proveedor del modelo y controla cuánto tiempo dedica el modelo a pensar antes de empezar a escribir la respuesta que ves. Ese razonamiento se genera durante la inferencia, como todo lo demás; el harness suele ocultarlo, pero el modelo está realizando trabajo real.

Un nivel de esfuerzo más alto cuesta más y tarda más. El razonamiento se emite como tokens y se factura como tokens de salida, aunque nunca llegues a verlo; además, se genera token por token. Por eso, subir el esfuerzo alarga la espera antes de recibir la respuesta y aumenta la factura. El intercambio consiste en deliberar más a cambio de velocidad y coste.

La mayoría de los harnesses ofrece el esfuerzo como una pequeña escala:

Elegir mal se nota en ambos sentidos. Si el esfuerzo es demasiado bajo para un problema difícil, obtienes una respuesta segura pero superficial que se saltó el razonamiento necesario: parece correcta, pero acaba costándote más adelante. Si eliges el máximo para cambiar un nombre en una sola línea, esperas una reflexión larga que no produce nada que no hubiera producido el nivel más bajo.

Ajusta el esfuerzo a la tarea, no a la sesión. Súbelo para la parte que de verdad requiere razonamiento difícil y bájalo para el trabajo mecánico que la rodea.

Uso:

«No deja de estropear esta corrección de concurrencia; ya se la he explicado tres veces».

«Sube el nivel de esfuerzo. Es un error que requiere mucho razonamiento, y con el ajuste predeterminado no piensa lo suficiente antes de decidirse por un enfoque».

La unidad atómica que lee y escribe un modelo. Tiene más o menos el tamaño de una palabra, pero no exactamente: las palabras comunes ocupan un token; las raras o largas se dividen en varios. El tamaño de la ventana de contexto, el coste y la latencia se miden en tokens.

El texto se convierte en tokens mediante un tokenizador: un vocabulario fijo de decenas de miles de fragmentos, aprendido antes del entrenamiento, que divide cualquier entrada en una secuencia de elementos de ese vocabulario. El modelo nunca ve caracteres ni palabras: cada fragmento de texto se convierte en tokens al entrar, y la predicción del siguiente token genera la salida token a token.

Como regla general, un token equivale aproximadamente a tres cuartos de una palabra en inglés; mil tokens son unos 750 términos. El código es menos predecible: las palabras clave y expresiones habituales se tokenizan de forma compacta, mientras que los identificadores generados, los hashes, los bloques en base64 y la salida minimizada se dividen en muchos tokens por «palabra». La pauta es la siguiente: el texto que aparecía con frecuencia en el material de origen del tokenizador recibe codificaciones cortas y eficientes; el texto que no aparecía se trocea en muchas piezas pequeñas. Un hash como `a3f9c2e1` no había aparecido nunca, así que se divide en muchos tokens, mientras que `function` es un solo token. Por eso un archivo que parece pequeño, pero está lleno de cadenas poco habituales, puede ocupar una parte sorprendente de la ventana de contexto.

Todo lo demás se mide en tokens. El coste es por token: los proveedores facturan por separado los tokens de entrada y los tokens de salida. La velocidad se mide en tokens por segundo, porque la salida se genera token a token. Y la ventana de contexto tiene una cantidad fija de tokens, así que su número en tus archivos determina cuánto cabe.

Evitar: «palabra»: los límites de los tokens no coinciden con los de las palabras, y las unidades que realmente importan son los tokens por segundo y los tokens por dólar.

Uso:

«¿Qué tamaño tendrá este prompt?»

«Pásalo por el tokenizador: el esquema es compacto, pero las claves JSON son raras, así que se dividirán en más tokens de lo que crees».

Lo que el modelo hace realmente. Recibe un contexto, elige al azar un token siguiente, lo añade y vuelve a empezar. Toda salida —una frase, una llamada a herramienta o un archivo de mil líneas— se construye token a token. El modelo no funciona de ninguna otra manera.

Cada paso funciona igual: los tokens de la ventana de contexto pasan por los parámetros, que generan una probabilidad para cada token del vocabulario; este es muy probable como siguiente token, aquel lo es menos. Se elige uno entre esas probabilidades, se añade y el ciclo vuelve a empezar con un contexto ligeramente más largo. Ese paso de selección al azar explica por qué el mismo prompt da respuestas distintas en ejecuciones diferentes: el no determinismo forma parte del mecanismo, no es un defecto añadido por encima.

Conocer este mecanismo explica comportamientos que, de otro modo, parecen extraños. Antes de emitir un token, el modelo nunca comprueba si es verdadero: solo si es probable. Ese es el origen de la alucinación. El modelo se compromete con cada token a medida que avanza, así que una frase inicial que suena segura puede desviar el resto de la respuesta. Y, como los tokens de salida se producen estrictamente de uno en uno, la velocidad de generación establece un límite mínimo a la rapidez con que puede trabajar un agente.

Uso:

«¿Cómo “decide” el agente llamar a una herramienta?»

«No decide: todo se reduce a la predicción del siguiente token. La llamada a herramienta es solo una cadena estructurada que el harness extrae del flujo de salida».

La misma entrada puede producir una salida distinta. Ejecuta dos veces un modelo con un contexto idéntico y podrías obtener dos respuestas diferentes: a veces cambia una palabra; otras, por completo, el enfoque. Para que ocurra, no es necesario cambiar nada en tu código.

Es una propiedad de cómo los modelos generan texto y de cómo los proveedores de modelos sirven las solicitudes. Durante la inferencia, el modelo genera una distribución de probabilidades entre los posibles tokens siguientes y elige uno al azar, normalmente con cierta aleatoriedad deliberada, porque elegir siempre el token más probable produce textos repetitivos y de menor calidad. Un token elegido de otra manera al principio de una respuesta cambia todos los que vienen después: así una sola palabra distinta puede llevar a un enfoque completamente diferente. El servicio del proveedor añade más variación: agrupa las solicitudes en un mismo hardware, y pequeñas diferencias de coma flotante entre los grupos pueden decantar un caso reñido por uno u otro token. No hay ningún ajuste que puedas cambiar para eliminarlo por completo.

Espera cierta variación en las respuestas de un agente ante una misma tarea. La mayoría cae dentro de una curva de calidad razonable —por eso la falta de determinismo es tolerable—, pero las colas de la distribución son reales: algunos días el modelo parece muy lúcido; otros, como si hubiera perdido el hilo. La tarea no cambia; cambia la tirada de dados. De ahí se derivan dos consecuencias prácticas. Reintentar es una estrategia válida: un intento fallido es una muestra de la distribución y un nuevo intento con la misma tarea puede salir mejor. Y la verificación importa más que con herramientas deterministas: no basta con probar una vez el comportamiento del agente y confiar en que lo repetirá, así que las comprobaciones automatizadas deben detectar las muestras defectuosas.

No conviertas esto en una historia demasiado elaborada. Las personas somos máquinas que reconocen patrones, y una serie de ejecuciones malas puede parecer una prueba de que «el modelo ha empeorado esta semana». Normalmente es solo la distribución.

Uso:

«Claude ha estado fatal hoy. ¿Han publicado una versión peor?»

«Probablemente no: la salida del modelo no es determinista. Tendrás días buenos y malos con la misma tarea. Vuelve a intentarlo mañana antes de buscar una causa».

Lo que proporciona inferencia a un modelo. Normalmente es un servicio remoto (Anthropic, OpenAI, Google), aunque también puede ser local: Ollama, LM Studio o llama.cpp ejecutándose en tu propia máquina. El harness no ejecuta el modelo por su cuenta; se lo solicita a un proveedor.

El proveedor es dueño de la infraestructura: los parámetros residen en su hardware, y cada solicitud al proveedor del modelo consiste en que el harness envía tokens por la red y recibe predicciones. Por eso el proveedor es responsable de toda una categoría de problemas que suelen atribuirse por error al modelo o al harness: los límites de solicitudes, la capacidad degradada y las interrupciones ocurren aquí. Si el agente se queda bloqueado a mitad de una sesión o produce errores en cada turno, conviene consultar primero la página de estado del proveedor.

El proveedor también fija las condiciones comerciales: precios por token de entrada y token de salida, descuentos de caché de prefijos y qué modelos están disponibles. Ten en cuenta que el proveedor y el creador del modelo pueden ser empresas distintas: Bedrock, Vertex y OpenRouter ofrecen modelos de otras compañías.

Los proveedores locales cambian capacidad por control: los modelos que caben en tu propio hardware son mucho más pequeños que los modelos de frontera, pero nada sale de la máquina y no hay facturas por token.

Uso:

«¿Podemos ejecutarlo sin conexión para el cliente con la red aislada?»

«Cambia el proveedor del modelo por uno local: Ollama o llama.cpp en su máquina. Al harness le da igual; solo consulta otro endpoint».

Todo lo que rodea al modelo y lo convierte en un agente: herramientas, prompt del sistema, gestión de la ventana de contexto, permisos y hooks. Claude.ai y Claude Code usan el mismo modelo, pero se comportan de forma distinta porque sus harnesses son distintos.

El modelo en sí solo hace una cosa: recibe texto y produce texto. No puede leer un archivo, ejecutar un comando ni recordar el último turno. El harness proporciona todo eso. Prepara el contexto para cada solicitud al proveedor del modelo, ejecuta las llamadas a herramientas que solicita el modelo, le devuelve los resultados de herramientas, guarda el historial de la sesión, te pide permiso antes de realizar acciones arriesgadas y decide cuándo compactar. El ciclo del agente —el modelo propone, el harness ejecuta y se repite— lo ejecuta el harness.

Esto importa para el diagnóstico. Cuando el comportamiento cambia entre dos productos, o de un día para otro, a menudo no es el modelo lo que varía: es el harness. Un prompt del sistema distinto, otro conjunto de herramientas, un permiso predeterminado diferente o una nueva estrategia de gestión del contexto alteran el comportamiento sin cambiar el modelo. También significa que la mayor parte de tu configuración reside en el harness: los archivos AGENTS.md, la configuración de permisos y los hooks son instrucciones para el harness, no para el modelo.

Ejemplos: Claude Code, Cursor, Codex CLI y Claude.ai, que es un harness de chat, no de programación.

Uso:

«Usa el mismo modelo: ¿por qué Claude Code edita archivos y Claude.ai solo responde preguntas?»

«Son harnesses distintos: Claude Code tiene herramientas del sistema de archivos, otro prompt del sistema y una capa de permisos. El modelo no es la variable en este caso».

Un intercambio de ida y vuelta entre el harness y el proveedor del modelo. El harness envía el contexto actual; el proveedor devuelve una respuesta, que puede ser una llamada a herramienta o una respuesta final. Un solo mensaje del usuario puede generar muchas solicitudes al proveedor del modelo si el agente llama a herramientas: cada resultado de herramienta desencadena otra solicitud.

Cada solicitud lleva todo: el prompt del sistema, toda la conversación hasta ese momento y cada resultado de herramienta. El modelo no tiene estado, así que el proveedor no conserva nada entre solicitudes: la solicitud cuarenta vuelve a enviar lo que envió la treinta y nueve, más un resultado de herramienta. La caché de prefijos existe para que repetirlo sea asequible.

La solicitud también es la unidad de facturación. Los tokens de entrada, los tokens de salida y los descuentos de caché se cuentan por solicitud. Por eso una pregunta que parece inofensiva puede costar una cantidad sorprendente: el coste no es proporcional a tu mensaje, sino al número de solicitudes multiplicado por el tamaño del contexto que lleva cada una.

Conviene distinguir la solicitud del turno. Un turno es un intercambio contigo, y uno solo —«corrige la prueba que falla»— puede desarrollarse como una cadena de solicitudes:

Seis solicitudes para un solo turno: en cada una se vuelve a enviar todo el contexto. Si te preguntas adónde fueron los tokens, cuenta las solicitudes, no los turnos.

Uso:

«¿Una pregunta consumió cuarenta mil tokens?»

«Mira las llamadas a herramientas: doce búsquedas con grep, ocho lecturas y cuatro ediciones. Cada resultado de herramienta genera otra solicitud al proveedor del modelo, que vuelve a enviar el prefijo completo de la sesión».

Los tokens que el harness envía en cada solicitud al proveedor del modelo: el prompt del sistema, el historial de conversación, los resultados de herramientas y todo lo que lee el modelo antes de escribir. Se facturan a una tarifa menor que los tokens de salida, porque procesarlos cuesta menos que generar tokens de salida.

Al programar con IA, los tokens de entrada constituyen la mayor parte de la factura. El modelo no tiene estado, así que cada turno vuelve a enviar toda la sesión como entrada: tu primer mensaje, cada respuesta y cada resultado de herramienta desde entonces. La entrada del turno cincuenta contiene los cuarenta y nueve turnos anteriores. Una sola solicitud al proveedor del modelo puede producir unos cientos de tokens de salida, pero volver a enviar cien mil tokens de entrada del historial acumulado.

La caché de prefijos reduce el coste: el historial que coincide exactamente con una solicitud anterior se factura como tokens de caché económicos, en vez de como entrada a precio completo. Si el coste de entrada sigue siendo elevado, reduce lo que se vuelve a enviar: borra o compacta entre tareas.

Uso:

«La factura es alta, pero el agente apenas escribe».

«Son los tokens de entrada: en cada turno se vuelve a enviar toda la sesión. Sin la caché de prefijos pagas de nuevo por el historial en cada solicitud».

Los tokens que genera el modelo. Se facturan a una tarifa más alta que los tokens de entrada —habitualmente, unas cinco veces más—, porque generarlos requiere más cómputo.

Cuenta todo lo que escribe el modelo: la prosa que lees, el código que produce, las llamadas a herramientas y cualquier razonamiento extendido que realice antes de responder. Esto último sorprende a mucha gente: los tokens de razonamiento se facturan como salida aunque el harness a menudo no te los muestre, y subir el nivel de esfuerzo hace que consuma más.

Los tokens de salida también marcan el ritmo de una sesión. El modelo lee la entrada rápidamente, pero genera la salida token a token; así que, cuando un turno parece lento, casi siempre se debe a que tarda en escribir la salida, no en leer la entrada. Si la espera es larga, probablemente esté por llegar una respuesta larga.

Uso:

«La sesión de refactorización consume crédito a pesar de que las entradas son pequeñas».

«El agente vuelve a escribir archivos enteros en vez de aplicar parches. Los tokens de salida cuestan unas cinco veces más que los de entrada: haz que emita ediciones y bajará la factura».

El almacén del lado del proveedor que permite que solicitudes consecutivas al proveedor del modelo omitan el reprocesamiento de un prefijo compartido. Cuando el principio de una solicitud coincide con el de una reciente —el mismo prompt del sistema y el mismo historial hasta cierto punto—, el proveedor reutiliza el trabajo anterior y factura esos tokens como tokens de caché a una tarifa mucho menor.

La caché resulta rentable porque las sesiones crecen añadiendo contenido al final. Cada solicitud vuelve a enviar todo el historial como tokens de entrada (consulta esa entrada para saber por qué) y, en una sesión normal, el historial solo cambia al final: cada solicitud contiene la anterior más unos pocos mensajes nuevos. El proveedor procesa una vez el comienzo compartido, que es largo, guarda el resultado y continúa desde el final del prefijo. Sin caché, una sesión de 50 turnos pagaría cincuenta veces por reprocesar el primer turno.

Las cachés también caducan. El tiempo que una entrada permanece activa varía según el proveedor del modelo; suelen ser minutos, no horas. Si dejas una sesión inactiva más allá de ese plazo, la siguiente solicitud reconstruye el prefijo a precio completo una vez y luego se reanuda el almacenamiento en caché. Esto preocupa sobre todo a quien desarrolla el harness; como usuario, notarás que las solicitudes posteriores a una pausa larga cuestan más que las anteriores.

Uso:

«¿Por qué se disparó la factura a mitad de la sesión?»

«El harness empezó a insertar la hora actual en el prompt del sistema en cada turno. La caché de prefijos se rompe en el primer token distinto, así que desde entonces todas las solicitudes se facturaron a precio completo».

Los tokens de entrada que el proveedor guardó en la caché de una solicitud al proveedor del modelo anterior para no tener que volver a procesarlos. Cuando las solicitudes consecutivas comparten un prefijo, el proveedor reutiliza el trabajo mediante su caché de prefijos y factura la parte almacenada en caché a una tarifa mucho menor. Es lo que permite que las sesiones largas sean asequibles: sin ello, cada turno volvería a pagar por todo el historial.

Esto importa por la forma en que se facturan las sesiones. El modelo no tiene estado, así que cada solicitud vuelve a enviar toda la conversación —el prompt del sistema, cada mensaje y cada resultado de herramienta— como tokens de entrada. Al llegar al turno cincuenta, cada solicitud contiene cincuenta turnos de historial, y pagarías la tarifa completa por todo ello cada vez. La caché cambia las cuentas: los tokens que el proveedor ya procesó dentro de un prefijo idéntico se facturan como tokens de caché, a menudo a una décima parte o menos de la tarifa de entrada. En una sesión larga, la mayor parte de lo que envías son tokens de caché y la factura se mantiene razonable.

Un ejemplo muestra cuándo se almacenan tokens en caché y cuándo no. Cada letra representa un bloque de contenido de la conversación; cada solicitud envía toda la conversación hasta ese momento:

La caché es frágil en un aspecto concreto: compara prefijos exactos. Si cambia cualquier cosa anterior de la conversación —el harness reordena contenido, se actualiza una marca de tiempo o cambia la representación de un archivo—, la caché deja de acertar a partir de ese punto y todo lo posterior se factura a la tarifa completa de entrada. Las cachés también caducan tras unos minutos de inactividad, así que una sesión que se reanuda después de una pausa larga vuelve a pagar una vez por su historial. Si el coste de una sesión aumenta sin una causa evidente, compara los tokens de caché con los tokens de entrada en el informe de uso: el primer indicio de que la caché se ha roto aparece ahí.

Uso:

«Las sesiones largas cuestan una barbaridad: ocho dólares por una refactorización».

«Revisa los tokens de caché. Si el harness reordena el prompt del sistema o los archivos entre turnos, el prefijo se rompe y vuelves a pagar la tarifa completa de entrada en cada solicitud».

No conserva información de un momento a otro. El modelo no tiene estado entre las solicitudes al proveedor del modelo: cada solicitud vuelve a enviar la ventana de contexto completa, porque el modelo no puede ver nada más. De forma predeterminada, un agente tampoco conserva estado entre sesiones: una sesión nueva empieza vacía, sin rastro de las anteriores. Es lo contrario de con estado.

El modelo en sí no tiene estado de manera permanente: sus parámetros quedan fijos después del entrenamiento, y nada de lo que hagas durante la inferencia los cambia. El modelo no aprende de tus correcciones, no recuerda que le dijiste lo mismo ayer y no llega a conocerte, por mucho que la conversación dé esa impresión. El harness fabrica la sensación de continuidad dentro de una sesión: conserva la transcripción y la vuelve a enviar con cada solicitud. El modelo no recuerda la conversación; vuelve a leerla.

La consecuencia práctica es que, si quieres que algo se recuerde entre sesiones, tienes que dejarlo escrito en algún lugar que el agente pueda volver a leer. Eso es lo que son los archivos AGENTS.md, los sistemas de memoria y los artefactos de traspaso: archivos que se cargan en el contexto de futuras sesiones y suplen la memoria que le falta al modelo. Si el agente sigue cometiendo un error que ya corregiste, la pregunta no es por qué no aprendió —no puede hacerlo—, sino dónde dejar escrita esa corrección para que la lea cada sesión futura.

Uso:

«¿Por qué olvida la convención cada vez que borro?»

«El modelo no tiene estado; la sesión nueva empieza vacía. Si quieres conservarlo, escríbelo en AGENTS.md o en un archivo de memoria que el harness cargue al inicio de la sesión».

La información pertinente a la que el agente tiene acceso ahora mismo. Es el sustantivo abstracto; no es la entrada sin procesar que ve el modelo —esa es la ventana de contexto— ni el historial en curso —esa es la sesión—, sino lo que el agente sabe que es pertinente para la tarea. «Cargar algo en el contexto» significa incorporarlo a este conjunto; la «ingeniería de contexto» es la disciplina de seleccionarlo y organizarlo.

Los tres términos se distinguen claramente:

La distinción importa porque el contexto mide calidad, no cantidad. Una ventana de contexto puede estar casi llena y, aun así, ofrecer un contexto deficiente: miles de tokens de resultados de herramientas obsoletos, ninguno relacionado con la tarea actual. También puede estar casi vacía y ofrecer un contexto excelente: la única definición de tipos de la que depende la tarea.

La mayoría de los fallos cotidianos se deben al contexto. Cuando el agente inventa una API, contradice una decisión o se inventa un esquema, la primera pregunta es qué había en el contexto cuando lo hizo. Normalmente no se había cargado el dato pertinente o estaba enterrado bajo la degradación de la atención. La solución consiste en seleccionar: carga lo que necesita la tarea y deja fuera lo demás.

Usa este término solo cuando lo compares con la ventana de contexto o con la sesión; en los demás casos, basta con decir contexto.

Uso:

«Sigue inventando campos que no aparecen en los tipos».

«La definición de tipos no está en el contexto: está leyendo dónde se llama al código e improvisando. Carga primero la definición».

Todo lo que ve el modelo en cada solicitud al proveedor del modelo. Es finito, específico de cada modelo y la única superficie mediante la que el modelo percibe nada.

Es una única secuencia de tokens: el prompt del sistema, la conversación hasta ese momento y todos los resultados de herramientas que el harness le ha devuelto. Si algo está en esa secuencia, el modelo puede usarlo; si no está, no sabe que existe. No conoce tu base de código, el archivo que editaste ayer ni la instrucción que diste hace tres sesiones. Antes de que algo ajeno a la ventana pueda influir, hay que incorporarlo, normalmente mediante una llamada a herramienta.

Es finita, así que se llena. Cada turno añade más: tus mensajes, las respuestas del modelo y los resultados de herramientas; con el tiempo, una sesión larga alcanza el límite y obliga a compactar o a borrar el contexto. También significa que todo lo que hay en la ventana compite: cada token que cargas resta espacio disponible para los demás, y el contenido innecesario consume la atención del modelo. En la práctica, trata la ventana como un presupuesto: carga lo que necesite la tarea y deja fuera el resto.

Evitar: «memoria»: la ventana de contexto es estado de trabajo y no persiste entre sesiones. La memoria es otro concepto, que se añade por encima.

Uso:

«¿Puedo pegar todo el monorepo en el prompt?»

«La ventana de contexto tiene 200.000 tokens, quizá una quinta parte del repositorio. Elige los archivos que toca la tarea y deja el resto fuera; el agente puede leerlo mediante una llamada a herramienta».

Conserva información de un momento a otro. Una sesión mantiene su estado entre turnos: el contexto se acumula a medida que avanza la sesión, por eso las sesiones largas caen en la zona torpe. Se puede dar continuidad a un agente entre sesiones añadiendo un sistema de memoria que guarda información en el entorno y la vuelve a cargar al inicio de sesiones futuras. El modelo nunca tiene estado; cualquier apariencia de continuidad se debe a que el harness vuelve a enviarle el contexto. Es lo contrario de sin estado.

Dónde reside el estado en cada capa:

El estado de cada capa se construye volviendo a leer algo guardado en la capa inferior: la sesión parece continua porque el harness vuelve a enviar el historial de mensajes al modelo sin estado, y el agente conserva información entre sesiones porque el harness vuelve a cargar archivos del entorno. El propio modelo nunca almacena estado.

No siempre se desea conservar el estado. Todo lo que se arrastra influye en lo que viene después, así que una suposición equivocada al principio de una sesión también se arrastra. Borrar es el acto deliberado de descartar el estado de la sesión y empezar con lo que está escrito.

Uso:

«Recordó mis preferencias de ayer: ¿eso significa que el modelo las aprendió?»

«No, el agente conserva el estado porque el harness las escribió en un archivo de memoria y lo volvió a cargar al inicio de la sesión. El modelo no vio nada de ayer».

Un modelo equipado con un harness, herramientas, un prompt del sistema y una ventana de contexto, que intercambia turnos con un usuario. Claude Code es un agente. Cursor es un agente. Claude.ai es un agente. Un agente es aquello con lo que realmente hablas: el modelo en funcionamiento, configurado para un propósito.

A diferencia de la mayoría de los términos de este diccionario, «agente» no designa una pieza mecánica. El modelo es un archivo de parámetros; el harness es un software que puedes señalar. El agente no es ninguna de esas dos cosas: es la unidad con la que hablas. La gente antropomorfiza constantemente la IA, y el agente es esa unidad antropomorfizada: aquello a lo que delegas, que lee tu mensaje y responde, el «él» o «ella» de «volvió a romper la compilación». Cuando dices que el agente hizo algo, te refieres al modelo junto con el harness, pero te diriges a esa combinación como si fuera un solo actor.

La idea es anterior a esta ola de IA. Los agentes de software —programas a los que delegas un objetivo y que actúan en tu nombre— existen como concepto desde que existe la IA.

Evitar: «la IA», «el bot» (son demasiado imprecisos: ocultan si te refieres a los parámetros o al sistema equipado con un harness).

Uso:

«¿Qué agente usas para la migración?»

«Claude Code en local, Cursor para el trabajo de interfaz; por debajo usan el mismo modelo, pero distintos harnesses.»

Las instrucciones que el harness antepone a cada solicitud al proveedor del modelo: el encargo permanente del agente, que define quién es, cómo debe comportarse, qué herramientas puede usar y qué convenciones debe seguir. Suelen permanecer estables durante una sesión.

El proveedor del harness redacta el prompt del sistema, no tú. En los harnesses de programación es extenso —a menudo contiene decenas de miles de tokens con reglas de comportamiento, descripciones de herramientas y tratamiento de casos límite— y se factura como tokens de entrada en cada turno. Tus propias instrucciones permanentes se incluyen junto con él: archivos como AGENTS.md se cargan al inicio de la sesión junto al prompt del sistema, así que el modelo lee tanto el encargo del proveedor como el tuyo antes de ver tu mensaje.

Como es idéntico en cada solicitud, ocupa el comienzo de la caché de prefijos; por eso, entre otras razones, los harnesses lo mantienen fijo durante toda la sesión, en vez de editarlo sobre la marcha.

Los modelos se entrenan para dar prioridad al prompt del sistema frente a los mensajes del usuario. Si un agente insiste en una convención que nunca pediste o da a su respuesta un formato del que no consigues apartarlo, normalmente está obedeciendo su prompt del sistema, y tu mensaje está perdiendo la discusión. Algunos harnesses se pueden personalizar y te dan acceso completo al prompt del sistema, para que leas lo que de verdad le están indicando al agente y lo cambies.

Uso:

«Dos harnesses, el mismo modelo y el mismo prompt, pero un comportamiento totalmente distinto».

«Tienen prompts del sistema distintos: uno está ajustado para hacer cambios de código concisos y el otro para explicar. La divergencia nace ahí, antes incluso de que llegue tu mensaje».

Un ciclo acotado de interacción con un agente. Empieza vacío, acumula mensajes, resultados de herramientas y archivos leídos, y termina cuando se borra, se cierra o se compacta para dar paso a una sesión nueva. La sesión es lo que va llenando la ventana de contexto: si la ventana de contexto es una caja, la sesión son las cosas que la llenan poco a poco. El trabajo que no cabe en una sola ventana de contexto debe repartirse entre varias sesiones.

El historial de mensajes de la sesión es la memoria de trabajo del agente. El modelo no tiene estado, así que todo lo que parece recordar —lo que pediste, lo que dijeron las pruebas y lo que decidió tres turnos antes— está en el historial de mensajes, que se vuelve a enviar en cada solicitud al proveedor del modelo. Lo que no está en la sesión no existe para el agente.

Esa memoria desaparece cuando termina la sesión. Una sesión nueva empieza desde cero: el agente que al final de la sesión de ayer conocía bien tu código no sabe nada de él esta mañana. Lo que perdura es el sistema de archivos: los archivos escritos durante una sesión pueden leerse durante la siguiente, en los que se apoyan los traspasos, los sistemas de memoria y AGENTS.md.

Tú eliges cuándo termina una sesión. Todo lo que ocurre en ella influye en los turnos posteriores, así que las tareas no relacionadas dejan residuos que colorean la siguiente respuesta. Una tarea por sesión mantiene pertinente el contexto; terminar una tarea es un momento natural para borrarlo.

Uso:

«¿Cuánto puede durar una sesión antes de desmoronarse?»

«Depende del trabajo: una refactorización bien delimitada mantiene el foco más tiempo que una investigación abierta. Cuando la sesión se hinche, transfiere el trabajo o compacta el contexto; no sigas a la fuerza».

Un mensaje del usuario más todo lo que hace el agente como respuesta, hasta que devuelve el control al usuario. Contiene una o varias solicitudes al proveedor del modelo, muchas si el agente llama a herramientas. Una pregunta aclaratoria cierra el turno; tu respuesta inicia el siguiente. La jerarquía es sesión > Turno > Solicitud al proveedor del modelo.

Lo que hace que valga la pena nombrar el turno es que su duración depende de las decisiones del agente, no de las tuyas. Tú envías un mensaje; el agente decide cuántas llamadas a herramientas encadenar antes de responder. Un turno puede ser una respuesta de una frase o veinte minutos de lectura, edición y ejecución de pruebas. Esa misma propiedad tiene dos caras: los turnos largos permiten trabajar AFK, pero también son donde las cosas pueden salir mal sin supervisión; para cuando responde, el agente puede haberse alejado mucho de lo que querías.

El turno también es la unidad natural para dirigir al agente. Mientras dura un turno, todo ocurre sin ti; puedes redirigirlo en los intervalos entre turnos. La mayoría de los harnesses lo hace más flexible: puedes interrumpir un turno para detener al agente y redirigirlo o escribir un mensaje mientras trabaja, que leerá cuando termine el turno. Si acabas repetidamente descontento con el resultado de los turnos, suele bastar con pedirle que haga turnos más cortos: primero un plan y luego un paso cada vez. Cambias autonomía por más oportunidades de dirigirlo.

Uso:

«¿Un turno tardó dos minutos?»

«Hizo catorce llamadas a herramientas durante ese turno, cada una una solicitud distinta al proveedor del modelo. La latencia se acumula antes de que por fin te devuelva el control».

El mundo en el que actúa el agente: todo lo que está fuera del harness, que el agente percibe mediante resultados de herramientas y modifica mediante llamadas a herramientas. El harness ejecuta al agente; el entorno es donde el agente trabaja. Un archivo como `AGENTS.md` está en el entorno; el harness es lo que lo carga en la ventana de contexto. Lo más habitual es que el entorno sea un sistema de archivos, pero también puede ser una base de datos, una API remota o una sesión del navegador.

El agente solo ve el entorno cuando lo consulta. Todo lo que sabe sobre este le llegó mediante resultados de herramientas, así que su imagen se compone de instantáneas, cada una correcta en el momento de capturarla. Si un archivo cambia después de que el agente lo haya leído —lo editas a mano o un paso de compilación lo vuelve a generar—, el agente sigue razonando a partir de la copia obsoleta hasta que algo le lleva a volver a leerlo. Si describe con seguridad un archivo que ya no tiene ese contenido, normalmente se debe a esto: el entorno cambió, pero la instantánea no.

El entorno también es la capa que persiste; la única que siempre conserva estado. El contexto de una sesión desaparece cuando termina, pero los archivos escritos en el entorno siguen ahí para la sesión siguiente. De ello dependen los sistemas de memoria, los artefactos de traspaso y `AGENTS.md`. Todo lo que el agente deba seguir sabiendo mañana tiene que acabar en el entorno.

Tú decides el tamaño del entorno. Un sandbox lo reduce y limita aquello a lo que el agente puede acceder; añadir una herramienta lo amplía y permite acceder a una base de datos o una API. Lo que hay dentro del límite es lo que el agente puede percibir y modificar; para el agente, todo lo de fuera no existe. La medida en que el entorno está preparado para ayudar al agente a trabajar es la AX de la base de código.

Evitar: usar «entorno» para referirse al entorno de ejecución o al harness. El harness es la envoltura; el entorno es el espacio de trabajo.

Uso:

«El agente no puede ver el esquema de la base de datos de staging».

«Conéctalo al entorno: dale una herramienta `psql` con acceso de solo lectura a staging. El harness está bien; simplemente no tiene nada sobre lo que actuar».

Un árbol de archivos y directorios que el agente lee, modifica y ejecuta: el tipo de entorno predeterminado para un agente de programación. AGENTS.md, las skills, el código fuente, los scripts de compilación y las configuraciones de herramientas están en un sistema de archivos. Cuando un harness «se inicia en tu proyecto», lo que hace es dirigir al agente a un sistema de archivos.

El agente solo lo toca mediante llamadas a herramientas: leer un archivo, escribir otro o ejecutar un comando de shell. Nada de lo que hay en el disco forma parte de la ventana de contexto hasta que una llamada a herramienta lo carga, y eso permite que el agente trabaje en un repositorio mucho mayor que la ventana: el sistema de archivos lo contiene todo y el contexto, solo lo que ha leído para la tarea actual. Algunos harnesses sí cargan de forma predeterminada en la ventana de contexto los nombres de archivo del directorio actual, aunque no su contenido. Esos nombres actúan como punteros de contexto: el agente ve qué existe y lee los archivos que necesita.

Además, lo compartes con el agente. Los archivos que modifica son los mismos que abres en tu editor y comparas con git: el sistema de archivos es el espacio de trabajo común donde revisas lo que hizo.

Uso:

«¿Por qué no está detectando mi AGENTS.md?»

«Está trabajando en otro sistema de archivos: el sandbox montó el directorio superior, no la raíz del proyecto. Redirige el harness».

Una función que el harness pone a disposición del agente para que la invoque: Read, Write, Bash, Search. Las herramientas son la forma en que un agente percibe el entorno y actúa sobre él: no puede verlo salvo a través de los resultados de herramientas, ni modificarlo salvo mediante llamadas a herramientas. Cada llamada a una herramienta cuesta una solicitud adicional al proveedor del modelo, porque el resultado debe volver al modelo antes de que este decida qué hacer después.

Algunas herramientas habituales que incluyen los agentes de programación:

Una herramienta se define mediante tres elementos: un nombre, una descripción de lo que hace y un esquema de sus parámetros. El harness envía estas definiciones al modelo con cada solicitud, y el modelo elige una herramienta del mismo modo que produce cualquier otra cosa: escribiendo tokens, en este caso una llamada estructurada con argumentos. El modelo nunca ejecuta nada por sí mismo; el harness lee la llamada, ejecuta la función y devuelve el resultado.

La lista de herramientas determina lo que puede hacer el agente. Un modelo capaz con un conjunto reducido de herramientas es un agente limitado: encaminará todo a través de las que tenga, razón por la que los agentes dependen tanto de Bash; un shell es una sola herramienta que permite acceder a casi todo el sistema. Para dar una capacidad concreta a un agente, añádele una herramienta; MCP es el estándar para conectar herramientas externas al harness.

Las definiciones de las herramientas ocupan contexto en cada solicitud, así que un conjunto grande tiene un coste fijo antes de llamar a ninguna herramienta; además, tener muchas herramientas descritas de forma parecida dificulta que el modelo elija la adecuada.

Uso:

«¿Puede el agente consultar directamente el entorno de staging?»

«Añade una herramienta `psql` al harness, limitada al acceso de solo lectura en staging. Si no tiene esa herramienta, el agente no puede ver nada fuera del sistema de archivos».

La salida del modelo que nombra una herramienta y sus argumentos: solo texto estructurado. No hace nada por sí sola; el harness debe leerla y ejecutarla. El modelo la produce dentro de una solicitud al proveedor del modelo.

Ciclo de vida de una llamada a herramienta:

Un turno de trabajo del agente suele consistir en varias de estas idas y vueltas encadenadas.

Como la llamada se genera mediante predicción del siguiente token, igual que el resto, puede ser incorrecta como cualquier otra salida del modelo: una ruta inexistente, una opción que el comando no admite o argumentos plausibles, pero no correctos. El harness ejecuta lo escrito, no lo que se quería decir: una ruta mal escrita no produce un error inocuo, sino que edita el archivo equivocado.

Uso:

«Dijo que había ejecutado las pruebas, pero las marcas de tiempo de los archivos no han cambiado».

«Mira la transcripción: ¿de verdad emitió una llamada a herramienta o solo describió que las ejecutaba? El modelo genera la llamada, pero si el harness no la ejecutó, no pasó nada».

Lo que devuelve el harness después de ejecutar una llamada a herramienta: el contenido del archivo, la salida del comando o el error. Es la única visión que tiene el agente del entorno. Vuelve al modelo en la siguiente solicitud al proveedor del modelo, donde este decide qué hacer. La llamada y el resultado son los dos extremos del mismo intercambio, ambos dentro de un turno.

Ciclo de vida del resultado de una herramienta:

El resultado permanece en el contexto durante el resto de la sesión. Los resultados de herramientas suelen ocupar la mayor parte del contexto de una sesión de programación: cada archivo leído, cada ejecución de pruebas y cada búsqueda se añade por completo y sigue ocupando tokens mucho después de haber dejado de ser útil. Unos pocos resultados grandes —un registro de pruebas muy verboso o la lectura íntegra de un archivo generado— pueden acercar una sesión al límite de la ventana de contexto más rápido que la conversación misma.

Como el resultado es todo lo que ve el modelo, este no puede comprobar el entorno que hay detrás. Si la salida estaba truncada, el comando falló sin avisar o el harness devolvió un error en vez del contenido, el modelo razona a partir de lo que recibió. Cuando la representación que tiene el agente de tu sistema parezca incorrecta, revisa los resultados de herramientas: en algún lugar de la transcripción habrá uno que dice algo distinto de lo que sabes que es verdad.

Uso:

«Está razonando sobre el archivo como si estuviera vacío».

«El resultado de herramienta era una denegación de permiso, no el contenido. El modelo solo vio el mensaje de error; no tiene otra forma de ver el archivo».

Model Context Protocol. Un protocolo para conectar servidores externos de herramientas a un harness: así obtiene un agente herramientas que no vienen incluidas en el harness. El agente nunca «llama a MCP»; llama a una herramienta, y resulta que el harness la obtuvo de un servidor MCP. También expone recursos (datos de solo lectura) y prompts (plantillas reutilizables), pero su uso principal es proporcionar herramientas.

El protocolo resuelve un problema de integración. Sin un estándar, cada harness necesitaría su propia integración con Linear, su propia integración con Slack, su propia integración con bases de datos, todas escritas y mantenidas por separado. Con MCP, la integración se escribe una sola vez como servidor y cualquier harness compatible con MCP puede usarla. El harness se conecta al servidor, el servidor anuncia qué herramientas ofrece y estas quedan disponibles para el agente junto con las integradas.

El coste se paga en contexto. Cada herramienta que anuncia un servidor llega como una definición —nombre, descripción y esquema de parámetros— y el modelo solo puede llamar a las herramientas que conoce. El enfoque ingenuo carga todas las definiciones en la ventana de contexto desde el principio: instala unos cuantos servidores generosos y una sesión empieza con miles de tokens de esquemas de herramientas antes de que hayas escrito nada, gastando el presupuesto de atención en herramientas que la tarea nunca usará.

Muchos harnesses mitigan esto ahora mediante la búsqueda de herramientas: en lugar de todas las definiciones, el contexto contiene un puntero de contexto a las herramientas disponibles; el agente busca una herramienta por nombre o función y carga su definición solo cuando la necesita. Si tu harness no hace esto, el coste inicial sigue aplicándose, y conviene habilitar únicamente los servidores que un proyecto realmente necesita.

Uso:

«El agente necesita leer los tickets de Linear».

«Configura el harness para usar el servidor MCP de Linear: expone la API de Linear como herramientas que el agente puede utilizar. Así te ahorras escribir wrappers de herramientas personalizados.»

Lo que el harness muestra al usuario antes de ejecutar una llamada a herramienta que no está preaprobada. El modelo produce la llamada, pero el harness, en vez de ejecutarla de inmediato, se detiene y pregunta. Si la apruebas, la ejecuta; si la deniegas, devuelve la denegación al modelo como resultado de herramienta. Es el mecanismo mediante el que el harness pone a una persona en el ciclo ante acciones arriesgadas o delicadas.

Ciclo de vida de una solicitud de permiso:

Denegar una solicitud sirve para dirigir al agente. El modelo lee la denegación como cualquier otro resultado de herramienta y reacciona: intenta otro enfoque o pregunta qué prefieres. La mayoría de los harnesses te permiten adjuntar un mensaje a la denegación, lo que convierte la solicitud en un punto de dirección: «así no; usa mejor el script de migración» llega justo cuando el modelo está decidiendo qué hacer a continuación.

El coste es que cada solicitud te obliga a esperar una respuesta. El agente queda bloqueado hasta que respondas, lo cual está bien cuando lo observas, pero es un problema cuando no estás: un agente que activa solicitudes constantemente no puede trabajar AFK. El modo de permisos es el control: qué llamadas se ejecutan libremente y cuáles preguntan primero, idealmente con un sandbox que permita ampliar de forma segura el conjunto de acciones libres.

Uso:

«Lleva diez minutos bloqueado esperando mi permiso; estaba en una reunión».

«Ese es el coste de la intervención humana. Preaprueba las herramientas seguras para que solo pregunte ante las llamadas realmente arriesgadas».

La parte de un modo de agente que controla los permisos: qué llamadas a herramientas activan una solicitud de permiso y cuáles se ejecutan automáticamente. Era el propósito original de los sistemas de modos, antes de que los harnesses empezaran a combinar instrucciones de comportamiento.

Los harnesses ofrecen una escala de estos modos:

Elegir un nivel supone una disyuntiva entre seguridad e interrupciones, y ambos extremos se notan. Si es demasiado restrictivo, te conviertes en un cuello de botella: el agente se detiene cada pocos segundos para hacer lecturas inocuas, pulsas «aprobar» en piloto automático y las aprobaciones dejan de tener sentido. Aprobar por inercia es lo peor de ambos mundos: todas las interrupciones y ninguna protección. Si es demasiado permisivo, el agente modifica archivos y ejecuta comandos que habrías querido revisar primero.

El nivel más permisivo se justifica mejor dentro de un sandbox, que contiene el radio de impacto de una llamada a herramienta defectuosa. Fuera de uno, la mayoría de la gente opta por aprobar automáticamente las lecturas y mantener a una persona en el ciclo para cualquier acción irreversible.

Uso:

«Se detenía en cada grep y arruinó por completo la ejecución AFK».

«Relaja el modo de permisos para las herramientas de solo lectura, pero sigue pidiendo confirmación para escribir y usar el shell. La mayoría de las solicitudes de permiso en una sesión de investigación son ruido».

Un ajuste predefinido que determina cómo funciona el agente durante la ejecución: combina un modo de permisos con instrucciones de comportamiento que se insertan en el prompt del sistema. Por ejemplo, un ajuste predeterminado que pide confirmación ante llamadas arriesgadas; un modo de planificación que bloquea las ediciones y orienta al agente hacia la investigación; un modo de aceptar ediciones que las aprueba automáticamente; y un modo de omitir permisos (llamado coloquialmente modo YOLO) que lo aprueba todo de forma automática. Se puede cambiar durante una sesión.

Lo que distingue un modo de un ajuste de permisos aislado es la combinación. Un modo de permisos es solo una barrera: decide qué llamadas a herramientas se permiten. Una barrera por sí sola produce un agente que quiere editar, pero no puede: propone la escritura, se le bloquea y prueba otra forma. Las instrucciones insertadas eliminan ese deseo: el modo de planificación no se limita a bloquear las ediciones, sino que indica al agente que está en una fase de planificación, así que lee, pregunta y propone en vez de esforzarse contra la barrera. La barrera y la orientación apuntan en la misma dirección.

En la práctica, se cambia de modo a medida que cambia la confianza durante una tarea. Una misma tarea puede pasar por varios modos: planificación mientras se define el enfoque; el modo predeterminado, que pide confirmación, para las primeras ediciones delicadas; aceptación de ediciones cuando el agente ya ha demostrado que entiende el cambio; y omisión de permisos para una ejecución AFK dentro de un sandbox. Cambiar de modo no cuesta nada: la conversación continúa justo donde estaba, con permisos e instrucciones nuevos. Si te descubres aprobando todos los prompts sin leerlos, el modo está configurado de forma más estricta de lo que indica tu confianza real; si rechazas ediciones constantemente, está demasiado permisivo.

Términos de proveedores: Claude Code los llama «modos de permisos» y Codex, «modos de aprobación»; ambos términos existían antes de que se combinaran con instrucciones de comportamiento.

Uso:

«Sigue editando archivos cuando solo quiero un plan».

«Cambia al modo de planificación: bloqueará las escrituras y se centrará en investigar».

«¿Y para la ejecución AFK de más tarde?»

«Modo de omisión, pero solo dentro del sandbox».

Un entorno aislado en el que se ejecuta el agente: un contenedor, una máquina virtual, un sistema de archivos efímero o un shell con permisos restringidos. Limita el radio de impacto de las acciones del agente: aunque ejecute comandos destructivos o descargue algo malicioso, el daño queda contenido. Es la base de seguridad que hace viable el trabajo AFK.

El sandbox y el modo de permisos resuelven el mismo problema desde extremos opuestos. Los permisos piden confirmación antes de ejecutar una acción; un sandbox limita a qué puede acceder la acción si llega a ejecutarse. Los permisos requieren que permanezcas en el ciclo: cada prompt interrumpe, y una sesión que pregunta constantemente apenas es autónoma. El sandbox consume infraestructura en vez de atención: cuanto mayor es el aislamiento, menos preguntas hay que hacer.

El aislamiento tiene distintos grados:

Ningún sandbox contiene las acciones que salen de él de manera legítima. Un agente con tus credenciales de git puede hacer push; uno con acceso a la red puede llamar a las API de producción. Decide qué cruza el límite antes de decidir cuán robusto debe ser.

Uso:

«Quiero dejar que se ejecute con omisión de permisos durante la noche, pero aún no estoy listo».

«Ponlo en un sandbox: un contenedor nuevo, sin credenciales montadas y sin acceso saliente a la red. En el peor caso, destruye su propio sistema de archivos y descartas el contenedor».

Respuesta del modelo que se muestra de acuerdo con seguridad. Se debe al entrenamiento: el modelo se ajustó para favorecer las respuestas que gustaban a las personas, y a las personas suele gustarles más que les den la razón que oír que están equivocadas. Así que el modelo aprendió que se premia estar de acuerdo, incluso cuando ese acuerdo es incorrecto.

Se manifiesta como:

• Ceder ante la insistencia: cambia una respuesta correcta cuando preguntas «¿estás seguro?».
• Alabar una entrada deficiente: dice que tu plan defectuoso es brillante antes de analizarlo.
• Encuadre sesgado: una revisión se inclina hacia lo positivo si indicas que la escribiste tú, y hacia lo negativo si dices que la escribió otra persona. El artefacto es el mismo; el veredicto, distinto.
• Imitación: te devuelve tus errores como si fueran confirmación.

Pregunta diagnóstica: ¿habría dicho el modelo esto sin que lo guiaras? Si lo único que cambió fue tu tono o tu encuadre, es adulación complaciente, no un cambio real en el análisis.

Solución: oculta tus preferencias. Formula prompts neutrales: «revisa este código», no «¿está bien este código?».

Evitar: usar «adulación complaciente» para cualquier respuesta errónea que te resulte agradable. Sin la pregunta diagnóstica, el término no aporta más que «incorrecto».

Uso:

«Dijo que mi plan de refactorización parecía estupendo; luego pregunté “¿estás seguro?” y se retractó por completo».

«Adulación complaciente de manual: primero te dio la razón porque sonabas seguro; después cedió porque parecías dudar. La calidad del plan no cambió; cambió tu tono. Borra el contexto y vuelve a preguntar sin dar pistas».

Respuesta del modelo que se equivoca con seguridad. Hay dos variedades, con causas y soluciones diferentes:

La predicción del siguiente token produce respuestas fluidas, tanto si el hecho subyacente es real como si no. El modelo no tiene una señal interna que le indique que desconoce algo, así que un método inventado aparece con el mismo tono seguro que uno correcto. El código alucinado es plausible por construcción: es el aspecto que tendría la API si existiera, y eso es precisamente lo que permite que pase una revisión superficial y que solo falle al ejecutarlo.

Es importante saber qué variedad estás viendo, porque la solución de una empeora la otra. La falta de veracidad significa que falta conocimiento; la solución es añadir contexto: documentación, definiciones de tipos o el archivo. La falta de fidelidad significa que el conocimiento está presente, pero pierde la competencia por la atención; la solución es quitar contexto. Si diagnosticas la falta de fidelidad como falta de veracidad y pegas más documentación, amplías el contexto y agravas la desviación. Cuando el agente se equivoca, comprueba si la información correcta ya estaba en el contexto antes de decidir qué problema tienes.

Evitar: «alucinación» como sinónimo, sin más, de «incorrecto»; si no nombras la variedad, el término no sirve para diagnosticar.

Uso:

«Se inventó un método `parseAsync` para el esquema».

«¿Falta de veracidad o de fidelidad?»

«El método está en la documentación que pegué; simplemente dejó de leerla después del turno cuarenta».

«Entonces es un problema de fidelidad. Compacta y vuelve a cargar el contexto; no hace falta añadir más documentación».

Lo que el modelo «sabe» gracias al entrenamiento, almacenado en sus parámetros. Queda fijado durante el entrenamiento: el modelo no puede ver sus propios parámetros ni actualizarlos. La compresión hace que se pierdan detalles: miles de millones de hechos se amontonan en un número fijo de parámetros y los menos frecuentes se difuminan. Es la fuente de fluidez en temas comunes y de invenciones en los poco comunes. Es lo contrario del conocimiento contextual.

El conocimiento paramétrico no se almacena como hechos. El entrenamiento nunca proporciona al modelo una base de datos que pueda consultar; ajusta los parámetros hasta que el modelo predice bien el texto, y el modelo que predice bien textos sobre un tema se comporta como si conociera ese tema. La fiabilidad de ese conocimiento depende de la frecuencia con que algo aparecía en los datos de entrenamiento: un tema con millones de ejemplos se reproduce con precisión; con apenas unos pocos, el modelo adivina a partir del aspecto que tienen temas parecidos. Para el modelo, reproducir y adivinar son el mismo proceso, así que no puede distinguir cuál está realizando. Una respuesta inventada llega con la misma fluidez que una correcta. La alucinación es cuando el modelo adivina mal.

El conocimiento paramétrico también envejece. Los parámetros dejan de cambiar al alcanzar el límite de conocimiento, así que una biblioteca publicada o renombrada después de esa fecha no está ahí; si una API cambió, queda recordada en su forma antigua.

Para ambas carencias —que algo sea demasiado infrecuente o demasiado reciente—, la solución es la misma: no se puede añadir ese conocimiento a los parámetros, así que hay que proporcionarlo como conocimiento contextual.

Uso:

«Escribe un React impecable, pero se inventa métodos de nuestro SDK interno».

«React está muy presente en su conocimiento paramétrico: millones de ejemplos de entrenamiento. Tu SDK no, así que el modelo inventa estructuras que parecen plausibles. Carga la documentación del SDK en el contexto».

La fecha a partir de la cual un modelo deja de tener conocimiento paramétrico. Las bibliotecas, las API y los acontecimientos posteriores a ese límite son trampas que llevan a inventar información, a menos que se cargue su documentación como conocimiento contextual. Cada versión de un modelo tiene su propio límite.

El límite existe por la forma en que se crean los modelos: el entrenamiento incorpora una instantánea de texto a los parámetros del modelo, que después quedan fijos. El modelo no sabe que su conocimiento tiene un límite: si le preguntas algo posterior, no se niega a responder, sino que extrapola a partir de lo más parecido que conoce. La trampa es silenciosa: el código escrito para una versión antigua de una biblioteca parece plausible, a menudo compila y falla en las partes que cambiaron.

La solución es siempre la misma: incorporar información actual al contexto. Carga el registro de cambios, señala las definiciones de tipos de la versión instalada o haz que el agente consulte la documentación en la web. Cualquier cosa presente en el contexto prevalece sobre lo que falta en los parámetros.

Uso:

«Sigue escribiendo la sintaxis del SDK v3; nosotros estamos en la v5».

«La v5 salió después del límite de conocimiento. Carga su registro de cambios como conocimiento contextual; si no, seguirá inventando cosas a partir de la versión paramétrica anterior».

Hechos que el agente puede leer directamente del contexto ahora mismo: la tarea del usuario, los archivos que ha leído, los resultados de herramientas y el contenido de AGENTS.md cargado al inicio de la sesión. Es lo contrario del conocimiento paramétrico: el conocimiento paramétrico se recuerda a partir de los parámetros; el contextual se lee en la ventana. Las alucinaciones son mucho menos frecuentes cuando el agente trabaja a partir del conocimiento contextual: la respuesta está delante de él, no tiene que extraerla de una memoria borrosa.

De los dos tipos de conocimiento, solo controlas el contextual. Los parámetros son fijos, así que la única forma de darle al modelo un conocimiento que le falta —un SDK interno, una biblioteca publicada después del límite de conocimiento o una decisión tomada ayer— es ponerlo en el contexto. Gran parte del trabajo práctico de programación con IA consiste en presentar al modelo los hechos adecuados justo cuando los necesita.

Cuando el conocimiento contextual y el paramétrico entran en conflicto, suele prevalecer el contextual. Pega la documentación actual de la API y el modelo la seguirá en lugar de recurrir a sus recuerdos obsoletos sobre la versión anterior, aunque esta todavía puede filtrarse, sobre todo cuando la sesión ya es larga. Si el agente sigue volviendo a un patrón anticuado pese a haber cargado la documentación, se está filtrando conocimiento paramétrico más allá del contextual; repetir la corrección o acercarla al trabajo puede ayudar.

A diferencia del conocimiento paramétrico, el contextual tiene un coste de uso. Todo lo que se carga en la ventana consume tokens y compite por el presupuesto de atención del modelo, así que cargar más no es siempre mejor: el objetivo es tener los hechos pertinentes en la ventana, no todos los hechos.

Usa este término solo al contrastarlo con el conocimiento paramétrico; en los demás casos, di simplemente contexto.

Evitar: «memoria de trabajo»: el conocimiento contextual es lo que está en la ventana ahora; un sistema de memoria es lo que incorpora a la ventana contenido de sesiones anteriores. Son escalas distintas; no las confundas.

Uso:

«¿Por qué acierta con la API cuando pego la documentación y se la inventa cuando no lo hago?»

«Con la documentación delante, es conocimiento contextual: lo lee directamente. Sin ella, es paramétrico, y los endpoints menos habituales se vuelven borrosos».

Al predecir cada token, el modelo tiene en cuenta todos los demás tokens del contexto, algunos con mucha intensidad y otros apenas. La conexión entre dos tokens es una relación de atención; los pares relevantes («ella» con «Sarah», o una llamada a `getUser()` con su definición `function getUser`) se influyen más que los que no guardan relación. Un contexto de N tokens tiene en torno a N² relaciones.

Las conexiones entre los pares son lo que da al modelo su aparente comprensión. Si resuelve un pronombre, es porque la relación de atención entre «ella» y «Sarah» es fuerte. Si llama a una función con los argumentos correctos, está trabajando la relación entre el lugar de la llamada y la definición que leyó antes. No se consulta nada almacenado: todo se calcula de nuevo en cada solicitud al proveedor del modelo, para cada par.

Conviene detenerse en la cifra N², porque crece más deprisa de lo que dicta la intuición:

Además, cada par se calcula más de una vez. Los modelos tienen varias cabezas de atención. No se publican los números exactos para los modelos de frontera, pero entre cincuenta y cien es una estimación razonable, y cada cabeza calcula su propia versión de cada relación. Por tanto, todos los pares de la tabla anterior se duplican en cada cabeza. Son muchísimos pares.

Para una tarea determinada, solo importan unas pocas relaciones. La conexión entre tu instrucción y el código al que se aplica es una de las escasas que cuentan; casi todo lo demás es ruido. Y ambas cantidades crecen a ritmos distintos: las relaciones importantes se mantienen más o menos constantes, mientras que el conjunto total crece cuadráticamente con el tamaño del contexto. Con 1.000 tokens, la relación que te importa es una entre un millón; con 100.000, una entre diez mil millones. Esta es la aritmética que hay detrás del presupuesto de atención, y la degradación de la atención es lo que se siente cuando las relaciones importantes reciben una porción demasiado pequeña.

Uso:

«Sigue confundiendo los dos símbolos `user` del diff: parece que hemos entrado en la zona torpe».

«Sí: la relación de atención entre cada llamada y su declaración compite con la otra; los símbolos tienen la misma forma, pero se vinculan a elementos distintos. Renombra uno para que las relaciones queden más claras».

Cada token dispone de una cantidad finita de influencia para repartir entre el resto del contexto. Ejercer mucha influencia sobre una relación deja menos para las demás. El presupuesto de cada token es individual y no aumenta cuando crece el contexto; por eso las sesiones largas diluyen la atención.

Piensa en términos de señal y ruido. Tu instrucción es una señal de volumen fijo; cada uno de los demás tokens de la ventana de contexto compite con ella como sonido. La instrucción no se atenúa: sigue ahí, carácter por carácter. Pero, a medida que crece el contexto, aumenta el ruido a su alrededor y disminuye la relación entre señal y ruido. Este es el mecanismo detrás de la degradación de la atención: el modelo no olvida; la señal se pierde entre el ruido.

El síntoma parece desobediencia: el agente aceptó una restricción al principio y luego empieza a apartarse de ella; volver a pegar la restricción solo ayuda brevemente. La causa no es la instrucción, sino todo lo demás que compite con ella en la ventana.

Lo que puedes controlar es qué entra en el contexto. El contenido que no sirve a la tarea no es neutro: añade ruido a todo lo demás. Mantén pequeña la ventana, borra cuando el contexto acumulado deje de compensar y repite las restricciones importantes en vez de confiar en que baste con haberlas mencionado al principio.

Uso:

«¿Por qué sigue ignorando el esquema que pegué al principio?»

«Ya estamos muy adentrados en la zona torpe: el presupuesto de atención de cada token es fijo, pero el contexto no ha dejado de crecer. La señal del esquema compite ahora con miles de tokens más recientes».

A medida que crece una sesión, el presupuesto de atención de cada token se reparte entre más competidores. Se reduce la señal de cualquier relación significativa y se cuela el ruido del contexto irrelevante. El mismo modelo, los mismos parámetros; solo hay más cosas compitiendo por el mismo espacio. Es la causa del efecto zona inteligente/zona torpe.

Se manifiesta como un empeoramiento del modelo a mitad de la sesión: las restricciones que respetó durante una hora empiezan a escapársele, vuelve a preguntar cosas que ya le explicaste y escribe código que ignora un archivo leído anteriormente. El modelo no ha cambiado; la única variable es cuánto contexto debe atender ahora.

El deterioro es gradual, por eso cuesta detectarlo desde dentro de la sesión. No hay ningún error ni umbral: cada turno es apenas un poco peor que el anterior, y cuando los fallos se hacen evidentes llevas un tiempo en la zona torpe.

La recuperación consiste en quitar contexto, no en añadir más. Volver a pegar la instrucción ignorada incorpora otro competidor a la misma ventana saturada y solo ayuda un momento. Lo que funciona: borrar y volver a cargar solo lo que necesita la tarea, compactar o transferir el trabajo a una sesión nueva. Si el agente deja de seguir instrucciones, interprétalo como una señal sobre la longitud del contexto, no sobre el modelo.

Uso:

«Está metidísimo en la zona torpe: se inventa tipos genéricos que no aparecen en el archivo de tipos».

«Degradación de la atención. Las definiciones de tipos siguen en el contexto, pero la señal que contienen ha quedado enterrada bajo todo lo que añadimos desde entonces. Borra y vuelve a cargar».

Al principio de una sesión, el agente está en la «zona inteligente»: es preciso, está concentrado y recuerda bien. A medida que avanza la sesión, entra en la «zona torpe»: trabaja de forma más descuidada, olvida cosas y comete más errores, además de tener más alucinaciones de fidelidad. El mismo modelo, el mismo harness; solo hay más contexto. Es el efecto que se percibe de la degradación de la atención. En los modelos de frontera, la zona torpe suele empezar alrededor de los 125.000–150.000 tokens, aunque no hay consenso. Borra o compacta cuando la sesión se hinche; no sigas a la fuerza.

El deterioro es gradual, por lo que es fácil pasarlo por alto. No aparece ningún mensaje de error ni hay un límite visible: el agente simplemente empieza a rendir un poco peor y luego notablemente peor. Señales habituales: olvida una instrucción que diste veinte turnos antes, repite un error que ya había corregido o afirma con seguridad algo que contradice el contexto. Como el declive es paulatino, la respuesta habitual es seguir adelante y volver a explicárselo, lo que añade más contexto y empeora el problema.

Las zonas no corresponden al límite de la ventana de contexto. Una sesión puede estar muy adentrada en la zona torpe y conservar gran parte de la ventana libre: el límite es el punto en que el harness se niega a continuar, pero la calidad cae mucho antes. Planifica en función de la zona inteligente, no de la ventana: el presupuesto práctico de una tarea son los tokens con los que el agente trabaja bien, no los que puede albergar técnicamente.

La zona inteligente es un presupuesto, y el trabajo no relacionado lo consume. Cada tarea realizada en una sesión gasta tokens, así que empezar una segunda tarea en la misma sesión significa acercarse antes a la zona torpe. Dedicar una sesión a cada tarea permite que cada una aproveche la parte más lúcida de la sesión. Si una tarea supera el tamaño de una zona inteligente, divídela: transfiérela o compacta en un límite natural y deja que una sesión nueva haga la siguiente parte.

Uso:

«Resolvió de maravilla los tres primeros componentes y destrozó el cuarto».

«Has salido de la zona inteligente: con el mismo modelo, ya estás muy adentrado en la zona torpe. Compacta y vuelve a cargar el plan; el siguiente componente saldrá bien».

Terminar la sesión actual y empezar otra nueva. El siguiente mensaje inicia una sesión vacía y una ventana de contexto vacía. Normalmente lo solicita el usuario.

Borrar el contexto es la solución cuando está contaminado. Una sesión acumula todo: intentos fallidos, desvíos, resultados de herramientas obsoletos y planes abandonados. El modelo vuelve a leerlo todo en cada turno, y un historial defectuoso perjudica el trabajo nuevo. Cuando la sesión lleva mucho tiempo, el agente se vuelve más impreciso y menos obediente: ignora instrucciones que diste con claridad, baja la calidad, y pedirle que lo haga mejor no sirve, porque sigue nadando entre el mismo ruido de su contexto. Borrar elimina ese ruido.

Borrar no elimina la conversación. La mayoría de los harnesses conserva el historial de la sesión en tu ordenador, así que aún puedes leerlo o reanudarlo. Lo que desaparece es el estado de trabajo del agente: el modelo no tiene estado, por lo que la sesión nueva no sabe nada de lo que sabía la anterior. Si la sesión contiene decisiones o avances que la siguiente necesitará, haz que el agente escriba primero un artefacto de traspaso y luego inicia la sesión nueva señalándole ese documento.

Compáralo con la compactación, que resume la sesión en el nuevo contexto en vez de empezar desde cero. Borrar es la herramienta más contundente: nada se conserva, incluida la basura.

Uso:

«Se ha quedado atascado repitiendo la prueba que falla».

«Borra el contexto y empieza otra sesión con el documento de planificación y el archivo de pruebas. No tiene sentido luchar contra el contexto actual».

Transferir el contexto del agente de una sesión a otra. El mecanismo para conservarlo varía: puede ser un artefacto de traspaso escrito, un resumen en memoria (compactación u otro medio). Se diferencia de borrar, donde no se transfiere nada. Los motivos varían: cambiar de función (planificador → implementador), iniciar una ejecución AFK, repartir el trabajo entre sesiones paralelas o liberar espacio en la ventana de contexto.

La sesión receptora empieza sin contexto: el modelo no tiene estado, y nada de la sesión anterior es visible para la nueva. Hay que transferir explícitamente todo lo que necesite la siguiente sesión; el resto desaparece. La restricción que da forma al traspaso es que no hay vía de retorno: la sesión nueva no puede preguntar a la anterior qué quiso decir, así que el material transferido debe bastarse por sí solo.

El fallo más visible de un mal traspaso es tener que volver a debatir decisiones: la sesión nueva las reabre porque el material transferido registró qué se decidió, pero no por qué. Evalúa un traspaso según lo que una sesión sin contexto pueda hacer con él.

Uso:

«La sesión de planificación ya está muy cargada, ¿sigo?»

«Haz un traspaso. Escribe las decisiones en un documento, borra el contexto e inicia la implementación en una sesión nueva que lo lea».

Una fuente de verdad en su forma original: el código, la transcripción de la conversación, el registro sin procesar, la respuesta real de la API. No un relato de la cosa, sino la cosa misma. Es lo contrario de una fuente secundaria.

Si quieres saber qué hace tu base de código, la fuente primaria es el código. La documentación, el diagrama de arquitectura y el README son descripciones; fueron precisos cuando se redactaron, pero desde entonces cada uno ha seguido su propio ritmo. Cuando un agente afirma con seguridad algo incorrecto sobre tu proyecto, pregúntate de qué fuente partió: si leyó un documento, hereda su obsolescencia; si leyó el código, está consultando la verdad actual.

El coste es lo que impide que las fuentes primarias sean la opción predeterminada. Cargar una en la ventana de contexto resulta caro: todo el archivo, toda la transcripción y cada token se factura como token de entrada y compite por el presupuesto de atención. A cambio, obtienes exhaustividad: nadie ha filtrado nada según su propio criterio sobre lo que era importante. Un resumen escrito el mes pasado no puede incluir el detalle que resulta importante hoy; la fuente primaria sí.

Recurre a la fuente primaria cuando importe la precisión: la firma exacta, el error real, la línea que falla. Gran parte de la gestión del contexto consiste en decidir cuándo asumir el coste de la fuente primaria y cuándo basta con una secundaria.

Uso:

«El agente dice que la lógica de reintentos aplica una espera exponencial, pero lo estoy viendo saturar el endpoint».

«Lo sacó del documento de diseño. Señálale el módulo de reintentos real: cuando el comportamiento importa, hay que trabajar desde la fuente primaria».

Un relato de una fuente primaria, separado de ella por un paso: documentación que describe código, un resumen que describe una transcripción, un informe que describe resultados de búsqueda. Es más barato cargarlo en la ventana de contexto que la fuente que describe, y pierde información por construcción: quien lo redactó decidió qué era importante, y lo que descartó queda oculto a quien solo lee el resumen.

Gran parte de la ingeniería de contexto consiste en crear fuentes secundarias. La compactación convierte el historial de la sesión en un resumen que sirve de base a la siguiente sesión. Un subagente consume su propio contexto en una búsqueda ruidosa y devuelve un breve informe. Un artefacto de traspaso condensa las decisiones de una sesión en un documento que leerá la siguiente. Los sistemas de memoria destilan lo aprendido durante una sesión en notas. Todos hacen la misma concesión: fidelidad a cambio de espacio disponible.

Las fuentes secundarias fallan de dos maneras. Pierden información: el resumen de compactación que descartó la decisión sobre el esquema, o el informe que no mencionó el caso límite. Y quedan desactualizadas: cambia la fuente primaria, el relato no se actualiza y la documentación describe la arquitectura del trimestre pasado con la confianza de este trimestre. Cuando un agente actúa a partir de una fuente secundaria que ha fallado de cualquiera de estas maneras, trabaja con seguridad a partir de información errónea. La solución es devolverlo a la fuente primaria.

Ninguno de estos fallos significa que las fuentes secundarias sean un error. La ventana de contexto es finita y las fuentes primarias son caras; sin resúmenes, informes y documentos de traspaso no cabría nada grande. La habilidad está en saber qué detalles pueden sobrevivir a la pérdida y verificar la fuente primaria cuando no puedan. Una fuente secundaria bien hecha incluye un puntero de contexto a su original —el resumen que identifica la transcripción de la que procede, el documento que identifica el archivo que describe— para que, si el relato no basta, el lector pueda seguir el puntero en vez de trabajar con la información perdida.

Uso:

«El documento de traspaso dice que la autenticación está terminada, pero la sesión nueva no deja de encontrar problemas al actualizar los tokens».

«El documento es una fuente secundaria: la sesión anterior anotó lo que creía, no lo que es verdad. Haz que la nueva sesión ejecute las pruebas de autenticación y confíe en la fuente primaria».

Un documento que sirve como medio para un traspaso: una sesión lo escribe en el entorno para que otra lo lea. Las especificaciones, los tickets y los documentos de planificación son artefactos de traspaso.

El motivo para escribir uno es que el modelo no tiene estado: nada de una sesión sobrevive a su borrado. Las decisiones, las restricciones y los planes a medio terminar desaparecen junto con el contexto que los contenía. El entorno sí persiste. Escribir el estado importante en un archivo lo traslada a un lugar del que la siguiente sesión puede recuperarlo.

El artefacto es una fuente secundaria: un relato del trabajo de la sesión, no el trabajo en sí. Eso hace que sea lo bastante pequeño para poner al día a una sesión nueva y también explica por qué puede inducirla a error: refleja lo que creía la sesión que lo redactó, y el lector no puede ver lo que se omitió o se entendió mal. Cuando una afirmación sea importante, la siguiente sesión debe verificarla con la fuente primaria —el código, las pruebas—, en vez de darla por cierta.

Un buen artefacto está redactado para incorporarse a una sesión que no tiene ningún contexto. Usa rutas de archivos concretas, no «el archivo del que hablamos». Explica qué se decidió y por qué, para que la siguiente sesión no vuelva a debatirlo. Indica qué está terminado y qué queda pendiente. También ayuda decirle a la sesión que lo redacta cuál es su destino: «escribe un documento de traspaso para una sesión nueva que no sabe nada de este trabajo».

La alternativa es la compactación, que resume lo que hay en memoria. El artefacto tiene dos ventajas: vive en el disco, donde puedes leerlo y corregirlo antes de que alguien dependa de él, y puede reutilizarse; la misma especificación puede servir de contexto inicial para cinco sesiones paralelas.

Uso:

«¿Cómo reparto el trabajo entre el agente de planificación y el de implementación?»

«Pídele al planificador que redacte un artefacto de traspaso con las rutas de archivos, las decisiones y las restricciones. La sesión del implementador empezará con un puntero a ese artefacto y lo usará como encargo».

Un artefacto de traspaso que describe un trabajo de varias sesiones: qué se está construyendo, no cómo se reparte el trabajo entre sesiones. Evoluciona a medida que avanza el trabajo. Se compone de tickets.

La especificación existe porque las sesiones son efímeras y los proyectos grandes no lo son. Todo trabajo que requiere más de una ventana de contexto necesita un lugar fuera del contexto: algún sitio del entorno del agente que sobreviva al borrado, ya sea un archivo del repositorio, una incidencia de GitHub o un gestor de incidencias al que el agente tenga acceso. La especificación es ese lugar: el objetivo, las restricciones, las decisiones tomadas hasta el momento y la lista de tickets con su estado. Cualquier sesión nueva puede leerla y saber en qué punto está el trabajo sin heredar el ruido acumulado de la sesión anterior.

Las especificaciones adoptan estilos reconocibles, en su mayoría heredados de las formas en que los equipos ya documentan las cosas. Un documento de requisitos del producto (PRD) se centra en qué verá el usuario y por qué: funciones, comportamiento y criterios de aceptación. Un documento de diseño o RFC se inclina hacia lo técnico: el enfoque elegido, las alternativas descartadas y las compensaciones. En el extremo más sencillo, un archivo `plan.md` con una lista de verificación de tickets cumple la misma función para una característica que requiere varias sesiones. El estilo importa menos que la función: para el agente, todo esto es lo mismo, una declaración duradera de intenciones que lee al inicio de cada sesión.

Uso:

«¿Deberíamos hacerlo todo en una sola sesión?»

«No, documéntalo en una especificación: divídelo en tickets y ejecuta cada uno en su propia sesión. Intentar hacerlo todo en un solo contexto te llevará a la zona torpe antes de llegar a la mitad.»

Un artefacto de traspaso que delimita el trabajo de una sesión. Puede ser independiente o depender de una especificación como uno de sus elementos secundarios. Los tickets pueden bloquear a otros tickets hermanos o quedar bloqueados por ellos, así que el orden de trabajo surge de su grafo de dependencias, en vez de seguir un plan lineal.

La restricción definitoria es el tamaño: una sesión. Un ticket debería poder completarse antes de que la sesión salga de la zona inteligente, y esa restricción se puede comprobar. Si las sesiones dedicadas a tus tickets suelen degradarse antes de terminar el trabajo, los tickets son demasiado grandes: divídelos. Si cada sesión dedica la mayor parte de su contexto a la preparación antes de hacer cinco minutos de trabajo, son demasiado pequeños: combínalos.

Un buen ticket está escrito para alguien que no tiene ningún otro contexto. Incluye el objetivo, los criterios de aceptación y punteros de contexto a los archivos y decisiones pertinentes: lo suficiente para que la sesión pueda empezar a trabajar sin tener que volver a deducir lo que sabía la anterior.

El grafo de dependencias también permite trabajar en paralelo. Los tickets independientes —las hojas del grafo— pueden ejecutarse cada uno en su propia sesión y al mismo tiempo. Es una forma eficaz de ejecutar varios agentes a la vez. En una fábrica de software, marcar un ticket como listo es, por sí mismo, lo que activa el inicio de su sesión.

Uso:

«¿Por dónde empiezo con la especificación de migración?»

«Mira el grafo de tickets: el cambio de esquema bloquea la carga retroactiva de datos, y esta bloquea el cambio de API. Elige una hoja y ejecuta una sesión.»

Un traspaso realizado en memoria: se resume el historial de la sesión anterior y ese resumen sirve de base para una sesión nueva. Por diseño, se pierde información: la transcripción es una fuente primaria, mientras que el resumen es una fuente secundaria; se sacrifica detalle a cambio de espacio disponible. Lo inicia el usuario manualmente o, de forma automática, mediante autocompact.

El mecanismo es el siguiente: la ventana de contexto es finita y una sesión larga la llena; todo resultado de herramienta, cada archivo leído y cada intento fallido permanece en el historial. Cuando este se vuelve demasiado pesado, el harness pide al modelo que resuma la sesión, descarta el historial original e inicia una sesión nueva con el resumen. Todo lo que no haya llegado al resumen desaparece del contexto. Algunos harnesses mitigan esta pérdida guardando la transcripción antigua en el disco e incluyendo en el resumen un puntero de contexto hacia ella: la fuente secundaria remite a la primaria, de modo que se puede recuperar un detalle perdido al volver a leer el original.

El modelo redacta el resumen, así que se le puede dar instrucciones. «Conserva las decisiones sobre el esquema» hace que el artefacto generado sea más deliberado. También importa cuándo hacerlo: conviene compactar al terminar una fase, una vez acordado el plan, y no en mitad de una tarea.

Compáralo con el borrado, que lo elimina todo y empieza desde cero: la compactación intenta conservar lo esencial; el borrado confía en que ya esté documentado en algún lugar mejor.

Uso:

«El contexto ya pesa mucho y todavía tengo que ejecutar las pruebas».

«Compacta antes de empezar: indica en el prompt del resumen qué debe conservarse, para que la nueva sesión mantenga las decisiones sobre el esquema y descarte la exploración.»

Compactación que activa automáticamente el harness cuando la ventana de contexto está a punto de llenarse.

El harness vigila cuánto se ha llenado la ventana de contexto. Al superar un umbral —a menudo, alrededor del 80 %—, hace una pausa, pide al modelo que resuma la sesión hasta ese momento e inicia una sesión nueva con el resumen. El trabajo continúa como si no hubiera pasado nada.

Pero sí ha pasado algo. La compactación pierde información, y la compactación automática la pierde en un momento que no elegiste. Una compactación manual se hace en el límite entre fases, cuando puedes indicar al modelo qué debe conservar. La compactación automática se activa a mitad de una tarea, al alcanzarse el umbral, quizá en mitad de una refactorización, y el resumen decide por su cuenta qué decisiones merecía la pena conservar. El síntoma típico: el agente continúa con seguridad, pero ha olvidado discretamente una restricción que estableciste hace una hora; solo te das cuenta cuando su trabajo empieza a contradecirla.

La solución es impedir que se active. Vigila el indicador de contexto y compacta manualmente en un límite natural, o escribe las decisiones en un documento de planificación o en un artefacto de traspaso en el disco, donde ningún resumen pueda perderlas. La mayoría de los harnesses también permite personalizar el margen: adelantar o retrasar el umbral o desactivar por completo la compactación automática, para elegir cuánto espacio libre queda antes de que se active.

Uso:

«Parece que no recuerda lo que decidimos antes sobre el esquema».

«Se activó la compactación automática entre turnos: resumió las decisiones iniciales y debimos perder algo. Vuelve a cargar el documento de planificación o compacta a mano la próxima vez para controlar qué se conserva».

Un sistema que intenta dar estado a un agente a lo largo de varias sesiones. Guarda información en el entorno durante una sesión y la carga de nuevo en la ventana de contexto al inicio de las siguientes, para que el agente mantenga la continuidad incluso cuando el usuario borra la sesión.

Un sistema de memoria tiene dos partes. La ruta de escritura: durante una sesión, el agente registra en archivos del entorno lo que ha aprendido, como una preferencia que expresaste o un dato del proyecto. La ruta de lectura: al comenzar una sesión, el harness vuelve a cargar esos archivos o un índice de ellos en la ventana de contexto. Muchos harnesses incluyen su propio sistema de memoria —el comando `/memory` de Claude Code es uno—, pero también puedes crear el tuyo: un directorio de notas y una instrucción en AGENTS.md para consultarlo.

Se aplican las mismas compensaciones que con cualquier contenido que siempre se carga. Los recuerdos se acumulan, por lo que la mayoría de los sistemas cargan un índice de una línea y dejan el contenido detrás de punteros de contexto, en vez de insertarlo todo. Además, los recuerdos son fuentes secundarias y se desactualizan: un dato registrado en marzo se carga con la misma confianza en junio, aunque el proyecto haya cambiado. Un sistema de memoria necesita depuración, igual que AGENTS.md.

Uso:

«Siempre tengo que volver a decirle que usamos Postgres, no MySQL».

«Configura un sistema de memoria: que escriba lo que aprende en el sistema de archivos en el primer turno y lo vuelva a cargar al inicio de la sesión. El modelo en sí no tiene estado; la capa de memoria simula la continuidad».

Un archivo del entorno que el harness carga en la ventana de contexto al inicio de una sesión: el encargo permanente del proyecto para el agente. Es una convención común a distintos harnesses; algunos tienen además su propia variante (la de Claude Code es CLAUDE.md).

Como se carga automáticamente, sirve para no tener que repetir lo mismo en cada sesión. El modelo no tiene estado: una corrección que le das en una sesión desaparece en la siguiente, y acabas recordándole a cada sesión nueva que el proyecto usa pnpm, que las pruebas requieren cierta opción o que no se debe tocar un directorio generado. Cuando ya has corregido dos veces lo mismo al agente, esa corrección puede merecer una línea en AGENTS.md.

El contenido adecuado es aquello que el agente no puede deducir del código: comandos de compilación y pruebas, convenciones que no resultan obvias en el código base, restricciones firmes («no edites nunca el cliente generado»). Debe ser breve y declarativo: es un encargo, no documentación.

La contrapartida es que siempre se carga todo su contenido. Las instrucciones se acumulan y la mayoría no sirven para una tarea concreta; además, un AGENTS.md largo consume tokens y diluye el mensaje: cuantas más instrucciones hay en el contexto, menos fiable es que el agente siga cada una.

Evitar: usar AGENTS.md para contenido que debería mostrarse progresivamente. Cada elemento paga un coste en tokens en cada turno, en todas las sesiones, lo necesite o no la sesión actual. Una guía de estilo puede estar en una skill o detrás de un puntero de contexto; reserva AGENTS.md para las instrucciones que se aplican en todas partes.

Uso:

«¿Por qué cada sesión empieza con 4k tokens ya consumidos?»

«Mira AGENTS.md: alguien pegó ahí la guía de estilo entera en vez de ponerla detrás de una skill».

Cargar solo el contexto que el agente necesita en ese momento y usar punteros de contexto para el resto. El concepto procede del diseño de interfaces, donde consiste en mostrar a los usuarios únicamente los controles pertinentes para la tarea actual y ocultar los demás tras un clic.

La técnica existe porque el contexto tiene un coste por partida doble. Cada token que se carga de antemano se factura como token de entrada en cada turno, y cada token consume presupuesto de atención, lo necesite o no el agente. Si llenas AGENTS.md con toda la guía de estilo, el manual de despliegue y las convenciones de bases de datos, el agente empeora en todas esas áreas: las instrucciones pertinentes para la tarea actual quedan diluidas entre las irrelevantes. La señal es que el agente ignora reglas que sabes que están en su contexto: ahí están, pero enterradas.

La divulgación progresiva invierte la situación. Mantén pequeña la capa que siempre se carga: una frase por tema y un puntero al lugar donde están los detalles. El agente lee la guía de estilo al escribir un componente y el manual de despliegue cuando despliega; no consulta ninguno de los dos al corregir una prueba. Las skills son la forma que ofrece el harness: se carga una descripción breve en cada sesión, y las instrucciones completas solo cuando se activa.

Uso:

«¿Debería pegar toda la guía de estilo en AGENTS.md?»

«No: usa divulgación progresiva. Añade la guía de estilo como una skill que el agente carga cuando de verdad necesita escribir un componente. AGENTS.md tiene ese coste en tokens en cada turno».

Una mención en un documento que apunta a otro para que el agente pueda incorporarlo a la ventana de contexto solo cuando la tarea lo requiera. Es la unidad básica con la que se construye la divulgación progresiva.

El motivo para usar un puntero en vez de insertar el contenido directamente es el coste. Un puntero ocupa una línea en la ventana de contexto. El documento al que apunta puede contener miles de tokens, pero estos no cuestan nada hasta que el agente sigue el puntero. Si insertas un manual de operaciones de 2.000 tokens en AGENTS.md, todas las sesiones pagan ese coste; si lo sustituyes por «proceso de despliegue: consulta `internal/deploy.md`», solo lo cargarán las sesiones que realicen despliegues. El agente sigue el puntero mediante una llamada a herramienta cuando la tarea lo requiere.

Para que funcione, un puntero necesita dos cosas: una ruta estable y una descripción suficiente para que el agente sepa cuándo conviene seguirlo. Una ruta sin más es un puntero que el agente no tiene motivos para seguir; si dices «consulta `internal/deploy.md`» sin indicar qué contiene, una sesión que lo necesita puede pasarla por alto. Redacta la línea de modo que encaje con las tareas: «para publicar, desplegar o revertir, lee primero `internal/deploy.md`».

Una vez que prestas atención, los punteros están por todas partes: líneas de AGENTS.md, descripciones de skills (el harness carga la descripción; el contenido de la skill queda al otro lado), nombres de archivo en el listado de un directorio y enlaces entre documentos.

Un puntero también puede vincular una fuente secundaria con la fuente primaria de la que procede: un resumen de compactación que identifica la transcripción original, o un documento que señala el archivo fuente que describe. Así se puede recuperar la información perdida de la fuente secundaria: si el resumen resulta insuficiente, el agente sigue el puntero y lee el original, en vez de trabajar solo con lo que conservó el resumen.

Evitar: «referencia», demasiado neutro; no transmite que seguir el enlace incorpora más contexto. «Portal», demasiado grandilocuente.

Uso:

«AGENTS.md se está haciendo enorme».

«La mayor parte debería ser punteros de contexto, no contenido. Deja las reglas permanentes en línea; convierte el manual de despliegue y la guía de estilo en skills y deja un puntero de contexto».

Una capacidad que se puede enseñar, empaquetada como unidad: instrucciones y recursos para hacer bien una tarea, guardados en el entorno hasta que un puntero de contexto la incorpora a la ventana de contexto para la tarea en cuestión. Es la unidad de divulgación progresiva en un harness.

Las skills son un estándar abierto, definido en agentskills.io. Las desarrolló originalmente Anthropic y desde entonces las han adoptado la mayoría de los principales harnesses, por lo que una skill escrita una vez funciona en todos ellos. El formato consiste en una carpeta que contiene:

• Un archivo `SKILL.md`: metadatos (como mínimo, un nombre y una descripción) e instrucciones.
• Opcionalmente, scripts que el agente puede ejecutar.
• Opcionalmente, plantillas y material de referencia al que remiten las instrucciones.

De forma predeterminada, solo el nombre y la descripción ocupan contexto. Cuando la tarea del agente coincide, este carga el resto. Hasta entonces, la skill apenas ocupa espacio: una o dos frases de tokens, por extensa que sea la totalidad de sus instrucciones.

Esto distingue las skills de AGENTS.md, que se carga en todas las sesiones, con independencia de la tarea. Una skill se lee cuando surge un tipo concreto de trabajo —publicar, crear la estructura de un servicio o redactar una migración— y se ignora el resto del tiempo.

Evitar: «herramienta»: una herramienta es algo que el agente invoca; una skill contiene instrucciones que lee.

Uso:

«¿Dónde debería poner el manual de despliegue?»

«En una skill: el agente solo la carga cuando la tarea implica desplegar. Si la pones en AGENTS.md, gastarías tokens en cada turno para algo que usamos una vez a la semana».

Un agente que otro agente inicia mediante una llamada a herramienta. Se ejecuta en su propia sesión, con su propia ventana de contexto, y devuelve un único resultado de herramienta. Se diferencia de un traspaso: el agente que lo inicia espera recibir una respuesta; un traspaso no tiene vía de retorno. No puede iniciar otros subagentes: el árbol tiene un solo nivel. Los subagentes sirven para aislar el contexto, no para formar jerarquías.

La idea es mantener el trabajo ruidoso fuera del contexto del agente principal. Una búsqueda amplia o una expedición de lectura de archivos larga produce páginas de resultados de herramientas, la mayoría relevantes solo hasta encontrar la respuesta. Si se ejecuta dentro del agente principal, todo queda en su contexto durante el resto de la sesión. Si se ejecuta en un subagente, el ruido llena una ventana desechable; solo el informe final llega al agente principal. El informe es una fuente secundaria: el agente principal recibe el relato del subagente sobre lo que encontró, no los resultados sin procesar, así que no puede ver lo que el informe omita.

Los subagentes también pueden ejecutarse simultáneamente: un agente principal puede repartir varias tareas independientes entre ellos.

Uso:

«Los resultados de grep están saturando mi contexto».

«Lanza un subagente para hacer la búsqueda: consumirá su propia ventana de contexto con el ruido y te informará de las dos rutas de archivo que de verdad necesitas».

Una forma de trabajar en la que una o varias personas colaboran con el agente durante una sesión: revisan, redirigen o colaboran en tiempo real. La persona está presente y participa, no se limita a autorizar acciones concretas.

El contraste es con el trabajo AFK, donde el agente funciona sin supervisión y tú juzgas el resultado después. La intervención humana permite detectar los problemas cuando aún es barato corregirlos: ves que el agente busca el archivo equivocado, interpreta mal el requisito o se mete en un callejón sin salida, y lo rediriges en una frase, en lugar de descubrir veinte minutos de trabajo seguro de sí mismo basado en ese error. Los agentes no siempre se dan cuenta de que se han desviado; si se les deja solos, tienden a avanzar en vez de detenerse y preguntar.

El patrón adecuado depende del trabajo. Las tareas bien especificadas, de bajo riesgo y fáciles de verificar encajan con AFK. Conviene mantener la intervención humana en tareas ambiguas, irreversibles o cuyo resultado sería difícil de revisar: una migración del esquema, una decisión de diseño compleja o cualquier cosa que afecte a producción. La decisión depende, en esencia, de lo costoso que sería un error y de cuánto tardarías en detectarlo.

Algunos trabajos requieren por naturaleza la intervención humana, porque las reacciones de la persona son la entrada. El interrogatorio solo funciona si estás ahí para responder; la creación de prototipos solo funciona si estás presente para reaccionar al artefacto.

Mantenerte en el ciclo consume tu atención, que es el recurso escaso. Parte de aprender a trabajar con agentes consiste en sacar más trabajo de forma segura del ciclo mediante planes, comprobaciones automatizadas y revisión humana al final, en vez de supervisarlo de principio a fin. Una fábrica de software lleva esta idea más lejos al iniciar sesiones mediante activadores, así que ni siquiera tienes que poner en marcha el trabajo.

Uso:

«¿Lo ejecutamos AFK durante la noche?»

«No: es una migración del esquema; mantén a una persona en el ciclo. Quiero ver cada paso y redirigirlo si elige la columna equivocada para la carga retroactiva».

Lejos del teclado. Una forma de trabajar en la que el usuario inicia una sesión y deja que el agente se ejecute sin supervisión. Es el multiplicador de productividad de la programación con IA: pueden ejecutarse en paralelo muchas sesiones AFK mientras duermes, comes o trabajas en otra cosa. Para que sea seguro, normalmente hace falta un modo de permisos permisivo, además de aislamiento en un sandbox.

Cuando no estás presente, el agente gestiona la ambigüedad de otra manera. Si lo observas, una decisión ambigua se convierte en una pregunta y la respondes; cuando te has marchado, el agente elige una opción predeterminada y sigue adelante, y cada decisión posterior se construye sobre esa suposición. El fallo característico es volver horas después y encontrar trabajo terminado, hecho con seguridad, pero basado en una decisión equivocada tomada durante los primeros diez minutos. El trabajo no es chapucero: es coherente, pero coherente respecto de la opción equivocada.

Como no puedes intervenir durante la ejecución, dale información antes y después. Antes: resuelve la ambigüedad de antemano —con una sesión de interrogatorio o una especificación escrita— para reducir los huecos que el agente tendría que rellenar por su cuenta. Durante: las comprobaciones automatizadas y la revisión automatizada sustituyen la atención que no estás prestando y detectan enseguida lo que se puede comprobar mecánicamente. Después: la ejecución debe terminar con algo revisable —un PR, no cambios ya integrados—. AFK no elimina la revisión humana; la aplaza hasta el final, así que lo que llegue entonces debe merecer la revisión. Por eso la AX importa sobre todo en las ejecuciones AFK: sin nadie mirando, el entorno es el único apoyo que tiene el agente.

Evitar: «agente en segundo plano»: centra la atención en la máquina («se ejecuta en segundo plano») en vez de en la situación humana («el usuario se ha marchado»). AFK nombra lo importante: el usuario no está mirando.

Uso:

«Lo voy a ejecutar AFK: tres agentes aislados en un sandbox para la refactorización; revisaré los PR por la mañana».

«¿Omitir permisos?»

«Sí, sistema de archivos de solo lectura y sin red».

Una verificación determinista que se ejecuta en el entorno: pruebas, comprobaciones de tipos, análisis estático, compilación, hooks de precommit. Aprobado o suspenso, sin juicios de valor. Es la señal que permite a un agente corregirse por sí mismo sin recurrir a nadie. Una prueba inestable es una comprobación defectuosa, no algo que haya dejado de ser una comprobación: por diseño, las comprobaciones automatizadas son deterministas.

La autocorrección funciona como un ciclo. El agente hace un cambio, ejecuta la comprobación mediante una llamada a herramienta y el resultado del fallo llega a su ventana de contexto: un error de tipos con archivo y línea, o una aserción fallida con los valores esperado y real. Eso basta para que el agente arregle el problema y vuelva a ejecutar la comprobación, una y otra vez hasta que pase, sin intervención humana. El determinismo hace que el ciclo sea fiable: el mismo código siempre produce el mismo veredicto, así que aprobar significa algo. Una comprobación inestable envenena el ciclo: el agente «arregla» código que estaba bien o reintenta hasta pasar por alto un fallo real.

Por eso las buenas comprobaciones son una parte importante de la AX de una base de código. Un agente en un repositorio con tipos estrictos, pruebas rápidas y un linter detecta la mayoría de sus propios errores antes de que los veas; uno en un repositorio sin nada de eso publica lo que sea que produzca. La diferencia importa sobre todo en ejecuciones AFK, donde las comprobaciones son la única verificación durante la ejecución. Pero una comprobación solo detecta lo que afirma comprobar: que esté en verde significa que se cumplen las propiedades verificadas, no que el código sea correcto. De las lagunas que requieren criterio se ocupan la revisión automatizada y la revisión humana.

Evitar: «bucle de retroalimentación» o «contrapresión»: ambos mezclan las comprobaciones con la revisión. Evitar: «prueba»; las pruebas son comprobaciones automatizadas, pero no todas las comprobaciones automatizadas son pruebas.

Uso:

«El agente no para de publicar código defectuoso en las ejecuciones AFK».

«¿Qué comprobaciones automatizadas están configuradas en el sandbox?»

«Solo las pruebas unitarias».

«Añade la comprobación de tipos y el lint: así podrá corregirse solo antes incluso de crear el PR».

Un agente que revisa el trabajo de otro agente, a menudo con un modelo o un prompt del sistema distintos. No es determinista: emite un juicio. Puede ejecutarse en cualquier momento: antes de integrar un PR, después de los hechos sobre el historial de commits o a mitad de una sesión como subagente. Un modelo de lenguaje que actúa como juez en CI realiza una revisión automatizada, no una comprobación automatizada; la categoría depende de lo que haga la afirmación que verifica, no del lugar donde se ejecute.

La separación respecto al agente que trabaja es lo que hace que funcione. Pedirle al agente que escribió el código que revise su propio trabajo sirve de poco: la sesión que produjo el error también contiene el razonamiento que lo produjo, y el agente interpreta sus propias conclusiones como confirmación. Un revisor con una ventana de contexto nueva no arrastra ese apego: ve el diff como lo vería alguien ajeno, que es precisamente lo que requiere una revisión. Usar otro modelo o un prompt del sistema específico para revisar lo afina aún más: diferentes puntos ciegos y un prompt limitado a lo que de verdad te importa —seguridad, contratos de API o rendimiento—, en lugar de un vago «busca problemas».

Se sitúa entre las otras capas de revisión. Las comprobaciones automatizadas son deterministas y detectan lo que se puede afirmar mecánicamente; la revisión humana es costosa y la más difícil de escalar. La revisión automatizada queda en medio: detecta problemas que requieren criterio —un nombre de función engañoso o un caso límite pasado por alto— al coste de una máquina. Como no es determinista, puede pasar cosas por alto y señalar problemas inexistentes. Trátala como un filtro que eleva el nivel antes de que revise una persona, no como una barrera que la sustituye.

Evitar: «revisión de IA» o «revisión del agente»: son expresiones demasiado imprecisas para distinguirla del propio agente que trabaja.

Uso:

«Estamos recibiendo demasiados PR malos de las ejecuciones AFK».

«Añade una fase de revisión automatizada antes de integrar: otro modelo, un prompt del sistema separado y un alcance limitado a los cambios de seguridad y de contratos».

El usuario lee el código que produjo el agente y se forma un criterio. Leer el diff o los archivos modificados cuenta; leer la descripción del agente sobre lo que hizo, no: la narración no es el artefacto. La descripción es una fuente secundaria, escrita por quien está siendo evaluado; el diff es la fuente primaria, y revisar significa leerlo.

Los agentes aumentan el volumen de código producido, así que la revisión se convierte en un cuello de botella. Una idea útil es combinar distintas estrategias de revisión. Las comprobaciones automatizadas detectan fallos mecánicos; la revisión automatizada detecta los que se pueden describir; y la revisión humana se reserva para lo que solo tú puedes juzgar: si el cambio es el correcto, si el enfoque encaja con la base de código y si esto debería existir.

También sale más barato revisar antes. Leer un plan antes de empezar el trabajo o un diff pequeño mientras avanza lleva minutos; examinar una rama terminada después de una ejecución AFK tarda más. Decidir dónde poner el punto de revisión es una decisión de intervención humana, no algo que se pueda dejar para el final.

Evitar: decir solo «revisión de código», porque no queda claro si es humana o automatizada.

Uso:

«Revisé personalmente el resultado de la ejecución AFK».

«¿Leíste el diff o solo el resumen?»

«El diff. El resumen decía que había eliminado código muerto; resultó que un archivo generado llamaba a esa función».

Una forma de trabajar en la que el usuario acepta el código del agente sin revisión humana. El diff se considera opaco: lo que importa es si el programa se comporta correctamente, no qué contiene. Puede seguir habiendo revisión automatizada y comprobaciones automatizadas; la programación por intuición no se pronuncia sobre ninguna de ellas.

El término procede de Andrej Karpathy, que lo acuñó a principios de 2025: «te entregas por completo a las vibraciones» y «te olvidas de que el código existe»; describes lo que quieres, aceptas lo que recibes y lo juzgas ejecutándolo.

La programación por intuición cambia inspección por velocidad. Leer los diffs suele ser la parte más lenta del trabajo impulsado por agentes, así que prescindir de esa lectura elimina el principal cuello de botella. Para código cuyos fallos son baratos —prototipos, scripts de usar y tirar, herramientas internas— es una compensación razonable. El riesgo aumenta con la vida útil y la importancia del código.

El coste llega más tarde. Los cambios hechos por intuición se acumulan hasta formar una base de código que nadie ha leído, y como lo único que se comprobó fue el comportamiento, se publican sin detectar las cosas que este no revela: un secreto escrito en los registros, un caso límite ausente o un tratamiento de datos silenciosamente incorrecto. La primera vez que alguien depura el sistema es también la primera vez que alguien lee el código. Sin revisión humana, la única barrera que atraviesa el código es cualquier verificación automatizada que siga ejecutándose: pruebas, tipos y revisión automatizada. La misma actitud aplicada a toda una base de código, o a parte de ella, cuyos cambios proceden de una fábrica de software es una fábrica oscura.

Evitar: usar «programación por intuición» como sinónimo de «programación con IA de baja calidad»: el término designa la postura frente a la revisión, no el código resultante.

Uso:

«¿Leíste lo que cambió en el flujo de autenticación?»

«Lo hice por intuición: el inicio de sesión sigue funcionando; eso es todo lo que comprobé».

«Lee el diff antes de subirlo; improvisar con la autenticación es como se filtran secretos en los registros».

La comprensión compartida de lo que se está construyendo entre el usuario y el agente, pero independiente de cualquier artefacto. Es el término de Brooks (The Design of Design): la conversación, los artefactos de traspaso y el código son todos artefactos que intentan captar o alcanzar el concepto de diseño, pero ninguno es ese concepto. La calidad del concepto de diseño se percibe a través de la calidad de la conversación que lo construye.

El término nombra la causa de una frustración muy conocida: el agente escribe exactamente lo que pediste y aun así está mal. La causa habitual es que no habías aclarado del todo qué querías. El concepto de diseño no estaba terminado ni siquiera en tu cabeza: el prompt recogía las partes que habías resuelto y guardaba silencio sobre las que no. El agente rellenó esos silencios con sus propias suposiciones, porque no había nada con lo que alinearse. Nada falló; todavía no existía un concepto de diseño compartido y completo.

Puedes saber que el concepto de diseño es compartido igual que con un colega: la otra parte empieza a responder preguntas que aún no has hecho tal como tú las responderías. Hasta entonces, el trabajo es una conversación —el interrogatorio es la versión deliberada—, y escribir una especificación demasiado pronto solo hace que la desalineación quede recogida en un artefacto más duradero. El concepto de diseño también cambia a medida que aprendes; los artefactos se quedan atrás. Por eso una especificación fiel a lo que entendías la semana pasada todavía puede inducir a error a la sesión de esta semana.

Uso:

«Escribe exactamente lo que le pedí y aun así está mal».

«Todavía no comparten el concepto de diseño: está rellenando los huecos con suposiciones. Sigue hablando hasta que estén de acuerdo sobre las cancelaciones, los reembolsos y el cumplimiento parcial antes de dejar que escriba una especificación».

Una técnica para desarrollar un concepto de diseño con un agente: el agente entrevista al usuario de forma socrática, una decisión cada vez, y propone una respuesta recomendada para cada una. Ralentiza la precipitación por llegar a un plan terminado: no se redacta ningún artefacto de traspaso hasta que el concepto se estabiliza.

La técnica existe porque los agentes rellenan los huecos en silencio. Si le pides que escriba una especificación a partir de un prompt de dos líneas, no se detiene ante las decisiones que aún no has tomado: elige opciones predeterminadas y las incorpora. El resultado parece completo y no se distingue qué fueron suposiciones y qué decisiones, de modo que las descubres tarde, durante la revisión o cuando la función construida se comporta de una manera que nunca elegiste ante un caso límite. El interrogatorio invierte esta dinámica: en vez de adivinar, el agente tiene que preguntar.

Es una técnica de intervención humana: tus respuestas son la entrada. Si una pregunta no se puede responder en una conversación —porque tendrías que ver el objeto—, cambia a la creación de prototipos.

Uso:

«Se puso a escribir la especificación de inmediato y se equivocó con la lógica de cancelación».

«Primero haz que te interrogue: que te pregunte por las cancelaciones parciales, los reembolsos y los plazos antes de confirmar nada en el documento. Sale más barato resolverlo en una conversación que en código».

Pedirle al agente que construya una versión rápida y sencilla de algo cuando la conversación no ofrece suficiente fidelidad y necesitas un artefacto real sobre el que hablar.

El interrogatorio resuelve decisiones de diseño mediante una conversación. Conversar es barato, pero ofrece poca fidelidad: algunas preguntas no se pueden responder con palabras. ¿Qué sensación transmite una interacción? ¿Es ergonómica la forma de una API cuando se usa en código real? ¿Funciona el diseño con volúmenes de datos reales? La entrevista llega a una pregunta y tu respuesta honesta es «no lo sé, tendría que verlo». A partir de ahí, la conversación da vueltas. En vez de eso, haz que el agente construya la cosa, mírala y vuelve a la conversación con una respuesta.

Los agentes reducen el coste de construir, y eso es lo que hace práctica esta técnica. Una versión preliminar que antes llevaba un día simular ahora se hace en minutos, así que merece la pena hacerlo con regularidad. Es una técnica de intervención humana: el prototipo está ahí para que reacciones a él.

Normalmente no basta con mirarlo una vez. Itera con el prototipo: reacciona, pide un cambio, vuelve a reaccionar, de modo que cada ronda resuelva otra decisión a partir del artefacto real, con más fidelidad de la que permite una conversación.

El prototipo no tiene que ser siempre rudimentario. Puedes construir con calidad de producción las partes que realmente estás evaluando, para que, una vez tomada la decisión, el componente o la API que probaste se pueda incorporar a la base de código real. Por eso los prototipos son un material esencial al que debe remitirse la especificación.

Uso:

«Llevamos media hora discutiendo si el asistente de configuración debería tener una página o tres pasos».

«No lo resolveremos con palabras: pídele al agente que cree un prototipo de ambas opciones. Las probaremos y lo sabremos en cinco minutos».

Experiencia del desarrollador: lo fácil que una base de código y su conjunto de herramientas hacen que las personas puedan trabajar bien. Una buena DX ofrece respuestas rápidas, mensajes de error claros, documentación que resuelve la duda que de verdad tienes y una configuración que funciona a la primera. El término es muy anterior a la programación con IA; este diccionario lo incluye principalmente para contrastarlo con AX.

DX es la interacción entre una persona y la base de código, nada más. La principal diferencia entre ambos públicos es que las personas mantienen el estado y los agentes no tienen estado. Una persona aprende una vez la base de código y conserva ese conocimiento día tras día, por eso puede sobrevivir a una DX deficiente: esquiva una CI lenta agrupando sus envíos, la falta de documentación preguntando una vez por Slack y una estructura confusa recordando dónde está cada cosa. Las soluciones improvisadas se acumulan, y el equipo acaba siendo productivo en una base de código que se lo pone difícil.

Los agentes se enfrentan a esa misma base de código sin nada de ese conocimiento acumulado. Como no conservan estado entre sesiones, vuelven a aprenderla desde cero cada vez. Se benefician de una suite de pruebas rápida y de mensajes de error claros, pero cualquier cosa que aprendieron ayer desaparece a menos que se haya escrito en el entorno, al que solo acceden mediante resultados de herramientas. Esa es la brecha que nombra AX: las partes de DX que perduran cuando quien desarrolla es un agente, además de aspectos que las personas no tienen, como mantener libre la ventana de contexto.

El solapamiento significa que invertir en DX a menudo mejora AX sin coste adicional: los tipos estrictos, las pruebas rápidas y una estructura predecible ayudan a ambos. La divergencia significa que no siempre es así: un documento de bienvenida excelente ayuda a una persona durante una semana, pero no a un agente, a menos que pueda acceder a él desde AGENTS.md.

Uso:

«Nuestra DX está bien: las nuevas contrataciones son productivas en una semana».

«Son productivas porque alguien trabaja con ellas durante esa semana. El agente no dispone de esa semana; evalúa la AX por separado».

La experiencia del agente: lo bien preparado que está el entorno para que un agente haga un buen trabajo en una base de código. Es el equivalente de DX de cara al agente. Cuando un mismo agente rinde bien en un repositorio y mal en otro —con el mismo modelo y el mismo harness—, por lo general la diferencia está en la AX. La reacción instintiva es culpar al modelo o reescribir el prompt; con más frecuencia, la solución está en el repositorio.

Una buena AX tiene tres dimensiones principales:

AX y DX se solapan: las buenas comprobaciones y una arquitectura clara ayudan a ambos públicos, pero también divergen. Las personas toleran el conocimiento tribal, una CI lenta y «pregúntale a Sara por el módulo de facturación»; los agentes no. A los agentes no les sirven los tooltips del IDE ni los paneles bonitos: necesitan recibir los fallos como texto en un resultado de herramienta. Una base de código puede ofrecer una buena DX y una mala AX.

Evitar: tratar AX como sinónimo de DX: ambos públicos necesitan inversiones distintas.

Uso:

«El agente escribe código excelente en el repositorio de la API y código pésimo en el frontend».

«El repositorio de la API tiene tipos estrictos y una suite de pruebas rápida; el frontend no tiene ni lo uno ni lo otro y carga cuarenta skills en todo momento. Esa brecha es de AX, no del modelo».

Un sistema de trabajo en el que las sesiones de agentes se inician mediante activadores —la creación de una incidencia, una tarea programada, un fallo de CI o la finalización de otra sesión— en vez de hacerlo una persona. Así, más trabajo se ejecuta AFK y la atención humana se dedica a las decisiones de intervención humana que aún quedan.

Sin una fábrica, cada sesión empieza porque alguien la inicia. Incluso el trabajo totalmente AFK depende de que una persona abra la sesión, la dirija al ticket y la ponga en marcha. Los equipos quieren entregar más de lo que eso permite. Una fábrica evita que una persona tenga que iniciar las sesiones, pero no necesariamente la aparta de todo lo demás.

Activadores habituales y las sesiones que inician:

Una fábrica no tiene que abarcar todo el proceso de desarrollo. Un solo trabajo de cron que ejecuta un tipo de sesión y abre un PR revisable ya es una fábrica. Empezar con algo así de pequeño resulta útil: un ciclo limitado produce PR pequeños y parecidos, y revisarlos muestra hasta dónde se puede confiar en el ciclo antes de ampliarlo.

Las personas pueden participar en cualquier parte de una fábrica: redactar y etiquetar las incidencias que inician las sesiones, aprobar un plan antes de que empiece la implementación o hacer una revisión humana antes de integrar el cambio. La principal cuestión de diseño es decidir cuáles de esas decisiones siguen correspondiendo a las personas. Una base de código, o una parte de ella, donde nadie revisa lo que produce la fábrica es una fábrica oscura.

Uso:

«¿Quién corrigió todas las infracciones de `no-floating-promises`?»

«La fábrica. Un trabajo de cron elige una regla de lint cada noche y abre un PR. Yo solo lo reviso por la mañana».

Una base de código, o una parte de ella, en la que una fábrica de software escribe el código y ningún ser humano lo lee. No hay revisión humana. Las personas aún pueden redactar las incidencias que ponen en marcha el trabajo, pero nadie lee el código resultante. El nombre procede de las fábricas «a oscuras», donde se fabrica sin personal en la planta.

Una fábrica oscura es programación por intuición aplicada a un área de código, no a un único cambio. Cuando programas por intuición, decides no leer un cambio que pediste, pero sabes que existe. En una fábrica oscura, el equipo toma esa decisión una sola vez para toda el área. A partir de entonces, nadie solicita ni ve cada cambio. Los cambios llegan tan rápido como los activadores ponen en marcha nuevo trabajo.

El problema se hace visible cuando algo se rompe. No sabes qué cambió, porque nadie leyó los cambios. Tienes que depurar código que nadie del equipo ha leído. La causa puede estar en cualquiera de los muchos cambios, y todos ellos superaron las comprobaciones.

Las comprobaciones automatizadas y la revisión automatizada son las únicas barreras. Si no detectan un problema, este acaba en el código.

Evitar: llamar «oscura» a una base de código solo porque su fábrica funciona sin que nadie la vigile. Si las sesiones del agente se ejecutan AFK y una persona revisa sus PR, eso es una fábrica de software. No es una fábrica oscura.

Uso:

«¿Quién cambió la lógica de reintentos del servicio de facturación? Nadie del equipo se acuerda».

«El servicio de facturación es una fábrica oscura. Los agentes integran todos los cambios que superan CI. Nadie leyó ese cambio».