Qué es un arnés y por qué importa más que el modelo
Pasé los primeros meses comparando modelos. Cuál razonaba mejor, cuál escribía más limpio, cuál era más barato por millón de tokens. Cambiaba de proveedor cada vez que salía una versión nueva, rearmaba los prompts, volvía a empezar.
En algún momento me di cuenta de que estaba corriendo contra una rueda que no se iba a detener. Los modelos cambian cada tres meses. Si todo mi sistema vive dentro de uno, cada nueva versión me obliga a rearmar el sistema.
Lo que cambió mi forma de trabajar no fue elegir un modelo “definitivo”. Fue dejar de pensar en el modelo como el centro del proyecto.
Llegué a pensar que lo que rodea al modelo importa más que el modelo en sí. No lo entendí de entrada. Lo entendí después de perder tiempo rearmando lo mismo cada vez que salía algo nuevo.
Hay un término técnico para ese alrededor. Se llama arnés. La analogía es directa: el modelo es el caballo, potente y rápido, pero por sí solo va para cualquier lado. El arnés es lo que te permite montarlo y dirigirlo.
Técnicamente, un arnés tiene cuatro piezas: el contexto que le pasás al modelo, las herramientas que puede usar, la memoria que lo deja recordar entre sesiones, y un sistema de verificación que comprueba si lo que hizo está bien hecho.
Ninguna de esas cuatro cosas vive dentro del modelo. Todas viven en archivos, en scripts, en convenciones que vos definiste. Son tuyas. Si mañana cambiás de proveedor, el arnés sigue ahí.
Karpathy lo formuló desde otro lugar.
Andrej Karpathy, uno de los nombres más serios del campo, propuso que dejáramos de hablar de “ingeniería de prompt” y empezáramos a hablar de “ingeniería de contexto”. La diferencia parece sutil pero no lo es.
Un prompt es una instrucción puntual: lo que escribís en el chat. El contexto es todo lo que el modelo lee antes y mientras trabaja: archivos de reglas, decisiones previas, estructura del proyecto, qué tiene permitido tocar y qué no.
Cuando los modelos eran malos, el prompt importaba mucho porque había que guiarlos paso a paso. Ahora son lo suficientemente buenos como para que la pregunta ya no sea cómo hablarles, sino qué información tienen alrededor cuando trabajan. El arnés es esa información ordenada.
Por qué el arnés es portable y el modelo no.
El modelo lo alquilás: pagás suscripción o llamadas a la API, y cuando salga uno mejor te vas a cambiar. Es lo que tiene sentido.
El arnés lo construís. Los CLAUDE.md con las reglas del proyecto, las skills que escribiste, los scripts de verificación, la forma en que decidiste separar carpetas, los sub-agentes con roles específicos. Todo eso es código y texto plano que vive en tu repositorio.
El día que aparezca un modelo mejor, conectás el modelo nuevo al arnés viejo. Funciona. Probablemente funcione mejor, porque el arnés ya estaba bien armado y ahora le pusiste un mejor motor.
Yo lo viví al revés antes de entenderlo: me obsesionaba con el modelo y rearmaba todo cada tres meses. Cuando empecé a obsesionarme con el arnés, cambié el motor sin tocar el chasis.
Las skills son piezas del arnés que se distribuyen.
Una de las partes que más me cambió la forma de trabajar son las skills: archivos que describen cómo hacer una tarea específica, con sus reglas, sus ejemplos y sus checks. El agente las invoca cuando detecta que aplican.
Lo importante no es solo que existan. Es que son portables. Una skill que escribí para mí me la puedo llevar a otro proyecto. Una skill que escribió alguien del equipo la usamos todos. Una skill probada por miles de personas en GitHub la uso yo sin tener que armarla.
Esa es la diferencia entre tener un asistente y tener un sistema. El asistente arranca cada conversación desde cero. El sistema arranca con todo lo que ya construiste alrededor.
La memoria fuera del modelo.
Una de las cosas que más me costó internalizar es que la memoria del agente no vive dentro del modelo. La ventana de contexto se llena rápido y, cuando se satura, el modelo se vuelve más torpe, no más inteligente.
Los arneses bien armados sacan la memoria afuera. El modelo carga lo esencial al arrancar — un archivo de entrada corto — y el resto lo va leyendo a demanda en archivos del proyecto: notas de progreso, decisiones tomadas, qué se hizo y qué falta.
El efecto práctico: el agente puede trabajar en sesiones largas sin que se le caigan los detalles. Cuando arranca una sesión nueva, no le tengo que volver a explicar lo que ya decidimos. Lee la carpeta de progreso y sigue.
Este mismo workspace es mi arnés.
Lo que estás leyendo se escribió dentro de un arnés. Hay un CLAUDE.md en la raíz con las reglas del proyecto: cómo escribo, qué tono uso, qué no hago. Hay sub-CLAUDE.md en cada subcarpeta con lo específico de esa carpeta — drafts, web, bot, transcripciones.
Hay un archivo formatos.md con los seis formatos de contenido que uso y la estructura exacta de cada uno. Hay drafts ya aprobados que sirven de referencia para los nuevos. Hay una carpeta de transcripciones de videos con timestamps, citas y fuentes.
Cuando le pido al agente que escriba algo, no le explico nada de eso. Lo lee solo. Si cambio de modelo mañana, sigo teniendo el mismo arnés. Si abandono este workspace y armo otro proyecto distinto, las piezas portables vienen conmigo.
Lo que cambió cuando acepté esto.
Dejé de chatear con el modelo y empecé a construir un sistema. Es un cambio chico de marco que tuvo consecuencias grandes para mí.
Cuando algo falla, ya no es culpa del modelo “que está más tonto hoy”. Es algo del arnés: una regla que faltaba, un archivo desactualizado, un sub-agente que tendría que estar haciendo otra tarea. Cuando algo funciona bien, no es suerte del prompt. Es que la pieza correcta del arnés estaba en su lugar.
Y la próxima vez que aparece un modelo mejor — aparece todo el tiempo — la pregunta deja de ser “¿lo cambio o no?”. Lo enchufo, lo pruebo, lo dejo o lo saco. El sistema sigue corriendo.
Lo que me llevo.
El activo durable de quien aplica IA en una empresa no son las suscripciones que paga. Es el repositorio que va dejando atrás de cada sesión: las reglas, los archivos de contexto, las skills, los sub-agentes, los scripts de verificación.
Lo que me cambió fue gastar menos tiempo eligiendo modelo y más tiempo armando el alrededor. No lo entendí al principio. Lo entendí después de varias vueltas en falso, y todavía lo sigo refinando.
¿A ustedes les pasó algo parecido? ¿En qué momento dejaron de obsesionarse con qué modelo usar?
Comentarios