Hace tres años, «agente de código» significaba un plugin de autocompletado. Hoy significa un runtime que lee tu repositorio, planifica ediciones, ejecuta tests y abre un pull request, y las diferencias interesantes entre productos están en el runtime —el harness—, no en el modelo que resulta que llaman.

La categoría salió a la luz esta semana: Earendil publicó Pi 1.0 como un «harness de agente endurecido, minimalista y extensible»; DeepSeek publicó un harness construido sobre la idea de que todo es un plugin, y Offrun se posiciona como un único espacio para gestionar todos los agentes de código. Elegir entre ellos es una decisión de arquitectura, así que evalúa la arquitectura, no la demo.

01Qué hace realmente un harness de agente de código

El modelo no puede leer tus archivos ni ejecutar tus tests. El harness lo hace y le devuelve los resultados. En la práctica asume cuatro responsabilidades:

• Ensamblado de contexto: qué archivos, diffs, logs e instrucciones entran en el prompt, y qué se resume o se descarta cuando la ventana se llena.
• Ejecución de herramientas: los comandos de shell, ediciones de archivos, búsquedas y llamadas de red que el modelo puede pedir.
• Aplicación de permisos: cuáles de esas llamadas se ejecutan solas, cuáles necesitan aprobación y cuáles están prohibidas.
• Estado de sesión: qué sobrevive entre turnos, entre sesiones y entre máquinas.

Todo lo demás es empaquetado. Cuando dos harness se sienten radicalmente distintos sobre el mismo modelo, una de estas cuatro cosas es la causa.

02Las opciones actuales, comparadas con honestidad

Los diseños centrados en plugins son los más interesantes y los más difíciles de evaluar, porque en cuanto un harness carga extensiones de terceros, esas extensiones heredan sus permisos. Un modelo de plugins es una decisión de cadena de suministro tanto como una función.

Un plugin se ejecuta con los permisos del harness

Una extensión que puede leer archivos, ejecutar comandos de shell o llamar a la red amplía el radio de impacto de cada error del modelo. Trata el registro de plugins como un árbol de dependencias, no como una tienda de temas.

03Decide con siete preguntas

1. ¿Qué modelo puede ejecutar? Si la respuesta es un solo proveedor, estás eligiendo un modelo, no un harness. La portabilidad importa sobre todo a dos años.
2. ¿Cómo gestiona el contexto? Pregunta cómo maneja un monorepo de 200.000 líneas: ¿indexa, recupera, resume o trunca a ciegas?
3. ¿Cuál es el modelo de permisos? Prefiere reglas por herramienta, por ruta y por comando antes que un único interruptor de «permitir todo».
4. ¿Se puede aislar en sandbox? Contenedores, montajes de solo lectura y reglas de salida de red convierten un incidente en una molestia.
5. ¿Dónde vive el estado de sesión? Archivos locales, un servicio hospedado o tu propia base de datos: esto decide tu postura de datos.
6. ¿Cómo revisas su trabajo? Un harness que produce diffs y registros revisables encaja en un equipo; uno que escribe directo en la rama, no.
7. ¿Cuánto cuesta extenderlo? Cuenta los plugins que de verdad necesitarás antes de comprometerte con un diseño plugin-first.

04Autohospédalo sin entregar el repositorio

La forma del despliegue importa tanto como la lista de funciones. Una base defendible:

• Ejecuta el harness dentro de un contenedor con el repositorio montado en lectura-escritura y nada más montado.
• Deniega la salida de red por defecto y luego permite el endpoint del modelo y los registros de paquetes que uses.
• Mantén las credenciales fuera del contenedor; inyecta tokens de corta vida en el momento de la llamada si el agente los necesita.
• Exige aprobación para git push, instalaciones de paquetes y cualquier cosa que borre archivos.
• Captura la transcripción completa para que un revisor vea cada comando que se ejecutó, no solo el diff final.

# Forma de una política restrictiva de agente: rutas concretas, denegaciones primero.
permissions:
  read: ["src/**", "tests/**", "docs/**"]
  write: ["src/**", "tests/**"]
  shell:
    allow: ["pnpm test", "pnpm lint", "git diff", "git status"]
    deny: ["git push", "rm -rf", "curl"]
  network: ["api.example.internal"]

Las reglas de denegación van antes que las de permiso, porque un patrón como pnpm * se tragaría pnpm publish. Esta configuración es YAML o JSON corriente, así que formatea y valida como cualquier otro archivo de configuración de tu repositorio.

05Apúntalo a un modelo que controles

Los harness agnósticos de modelo se ganan su sitio aquí. Un harness que habla la API de chat compatible con OpenAI puede apuntar hoy a un modelo hospedado y mañana a una instancia de llama-server en localhost, sin cambiar el flujo del agente. Si ejecutas un endpoint local, recuerda que un modelo más pequeño necesita más andamiaje: contexto más ajustado, descripciones de herramientas más explícitas y un paso de revisión más estricto.

Lo contrario también se cumple. El modelo más grande del mundo no rescatará a un harness que vuelca todo el repositorio en cada prompt, porque en casi toda tarea real la calidad del contexto supera a la cantidad.

06Evalúa en una tarea real en una hora

Salta la demo del proveedor y da a cada candidato el mismo trabajo: un bug no trivial en tu propio repositorio con un test que lo reproduzca. Puntúa cuatro cosas.

El harness que gana suele ser el que da menos sorpresas, no el que terminó más rápido en una tarea preparada.

07Errores comunes y soluciones

El resumen honesto: el harness es ahora el producto. Elige aquel cuyo modelo de permisos, estrategia de contexto y superficie de extensión puedas tolerar, y verifícalo en tu peor repositorio en lugar de en la mejor demo del proveedor.