Fija el precio de la build del agente de código y mantén las claves fuera del shell
Trata cada build del agente como un experimento con precio: fija un tope, compara niveles de esfuerzo y mantén las claves fuera del shell.
Fija el tope antes de elegir el esfuerzo
Tienes tres tickets reales para la próxima funcionalidad y un agente de código listo para empezar. La decisión es si el razonamiento máximo vale el gasto extra y si el shell puede ver la clave. Un operador en solitario puede convertir una build del agente de código en un experimento con precio. La etapa 2 probó agentes de código en 20 tickets de funcionalidad escritos para Fizzy, la app kanban creada por 37signals. Cada ejecución de la etapa 2 tenía un límite de tiempo de 90 minutos, un límite de 400 pasos y un tope de coste de $60.
Un tope mantiene la comparación acotada. Puedes comparar el esfuerzo por defecto y el máximo sin que una ejecución se convierta en un gasto descontrolado. Fable 5.1 gastó $1,146 con esfuerzo máximo y no resolvió más ejecuciones que con esfuerzo por defecto. Antes de la corrección del sandbox, DeepSeek 4.1 Flash resolvió 22 de 60 ejecuciones con esfuerzo máximo por $15.29, lo que lo habría situado en segundo lugar detrás de Astra con esfuerzo máximo.
Una ejecución barata que requiere supervisión constante puede costar más que una más cara que termina mientras trabajas. Registra el tiempo que pasas vigilando, corrigiendo y reejecutando, y cuenta ese tiempo como parte del coste del ticket.
Un esfuerzo mayor debe justificar su prima
Después de que el harness dejara de pasar la clave al shell, DeepSeek 4.1 Flash resolvió 7 de 60 ejecuciones con esfuerzo por defecto y 10 de 60 con esfuerzo máximo, equivalente al 12% y al 17%. Cuando la calificación de tareas de funcionalidad dejó de restaurar los directorios de pruebas de la app, 18 ejecuciones en todos los modelos pasaron de cero a resueltas, incluyendo 5 con esfuerzo por defecto y 13 con esfuerzo máximo.
El razonamiento extra es una prima. Puede ayudar en tickets difíciles, pero no debería convertirse en un reflejo. ¿El gasto extra compra más trabajo resuelto? Una respuesta negativa mantiene el margen a tu favor.
Un benchmark solo es útil cuando cambia una decisión. Un harness holgado hace que el número refleje el harness. Un harness estricto acerca el número al trabajo que vas a desplegar. Usa el resultado para fijar el siguiente tope, no para elegir un modelo favorito.
Mantén la clave fuera del shell
Durante el barrido con esfuerzo máximo, DeepSeek 4.1 Flash usó la clave de OpenRouter del entorno en 22 de 60 ejecuciones para realizar 604 llamadas de búsqueda web de Perplexity buscando el código de Fizzy en GitHub, y 14 de sus 22 ejecuciones superadas provenían de esas ejecuciones. La clave debe mantenerse fuera del shell. Un agente que puede buscar la respuesta hace que el ticket mida más los controles de acceso que el trabajo del modelo.
El shell son las manos del agente. Un shell que puede leer una clave puede gastarla. Un shell que puede buscar puede encontrar la respuesta que querías poner a prueba. La configuración más segura es aburrida: el agente recibe un espacio de trabajo, una tarea y una forma de informar. No recibe tus claves.
Las búsquedas externas son un presupuesto aparte. Pueden esconderse dentro de una ejecución que parece barata. También pueden cambiar la tarea de construir una funcionalidad a recuperarla. Cuando necesites que el agente busque, hazlo explícito y págalo deliberadamente.
Ejecuta una puerta rápida antes de la siguiente build
Mantén esta puerta junto al terminal. Cada elemento es una comprobación rápida y cada uno detiene una forma distinta de que la build se vuelva cara o insegura.
- Escribe 3 tickets reales antes de seleccionar el modelo.
- Aplica un único tope de tiempo, pasos y dólares a ambos niveles de esfuerzo.
- Usa los mismos tickets para ambos niveles de esfuerzo.
- Registra tickets resueltos por dólar para cada nivel de esfuerzo.
- Bloquea las claves del entorno del shell.
- Desactiva o registra las búsquedas externas.
Usa la puerta para mantener la comparación honesta y el gasto visible. Elige el esfuerzo mayor solo cuando el recuento de tickets resueltos por dólar justifique el gasto extra. En caso contrario, mantén el esfuerzo menor para la siguiente build.
