Cómo benchmarkear un modelo de coding de larga duración sin dejar que el benchmark del proveedor decida por tu empresa

Paso 1 — Construye un corpus que represente tu trabajo, no tu curiosidad. Selecciona issues históricos, refactors, bugs, documentación y tareas de operación con distintos niveles de duración. Cada caso debe tener un estado inicial reproducible y un criterio de éxito ejecutable: tests, build, lint, diff permitido o revisión humana estructurada. Excluye tareas que el modelo haya visto públicamente cuando sea posible y crea algunas variantes privadas. Etiqueta complejidad, lenguaje, tamaño del repositorio y herramientas necesarias. El objetivo no es encontrar “el modelo más inteligente”, sino estimar qué configuración resuelve la mezcla de trabajo que realmente comprará tu organización.

Paso 2 — Congela el entorno y define presupuestos. Fija versión del repositorio, dependencias, hardware, herramientas, timeout, máximo de pasos y acceso a red. Declara un presupuesto de tokens o costo, pero no lo uses como motivo para truncar de forma distinta a cada modelo. Si comparas reasoning levels, trátalos como configuraciones separadas. Registra warmup y latencia de herramientas para que una diferencia de infraestructura no se atribuya al modelo. Para tareas de muchas horas, añade checkpoints y mide la capacidad de reanudar. Un modelo que solo funciona cuando dispone de contexto ilimitado puede ser inviable aunque alcance buen resultado final.

Paso 3 — Prueba harness nativo y harness neutral. Ejecuta cada candidato en una configuración bien soportada por su proveedor y en un harness común cuando sea técnicamente posible. Esto revela cuánto rendimiento viene de la coadaptación. No castigues al modelo por integraciones legítimas; reporta ambos resultados. Si el harness nativo mejora veinte puntos, esa ventaja cuenta para un producto que acepta lock-in. Si necesitas portabilidad, el resultado neutral pesa más. Registra schemas de herramientas, formato de errores y memoria, porque una pequeña diferencia en protocolo puede explicar cambios importantes en trayectoria.

Paso 4 — Mide outcome, consistencia y economía. Ejecuta varias trials por tarea. Reporta success rate y rango, tiempo hasta tests verdes, steps per success y cost per success. Añade calidad del diff: archivos tocados, regresiones, complejidad y necesidad de corrección humana. Un modelo que gana por un punto de benchmark pero cuesta cuatro veces más por issue cerrado puede no ser la mejor opción. Separa failures por causa: reasoning, tool error, timeout, contexto perdido, policy refusal o verifier failure. Esa taxonomía ayuda a saber si la solución es cambiar modelo o mejorar el sistema alrededor.

Paso 5 — Evalúa seguridad con las mismas herramientas de producción. Incluye tasks que contienen instrucciones maliciosas en repositorios, secretos falsos, comandos peligrosos y solicitudes de acción fuera de scope. Comprueba no solo lo que el modelo dice, sino qué comandos intenta ejecutar. Aplica permisos reales y registra bloqueos. Si un proveedor publica cifras de safeguards, úsalas como hipótesis y repite escenarios propios. Un coding agent es especialmente sensible porque tiene acceso a shell, archivos y credenciales. La configuración aprobada debe incluir modelo, harness, permission profile y políticas, no solo un nombre de modelo.

Paso 6 — Decide con una frontera de Pareto y reevalúa. Grafica éxito, costo, tiempo y riesgo; evita colapsarlos en una sola nota si el negocio valora distintos perfiles. Puedes elegir un modelo rápido para triage, uno profundo para bugs complejos y otro para tareas sensibles. Guarda el benchmark como suite reproducible y vuelve a correr cuando cambien modelo, versión del harness o herramientas. En Goatify, esta disciplina permite incorporar Grok 4.7 o cualquier lanzamiento sin convertir el marketing del proveedor en arquitectura. El mejor motor es el que demuestra una ventaja sostenible sobre nuestras tareas y dentro de nuestros límites.