Cómo evaluar modelos locales y sandboxes para agentes de código

Separa cuatro preguntas del piloto. Evalúa calidad del modelo, rendimiento del dispositivo, privacidad de datos y control de herramientas como ejes distintos. Define responsables de desarrollo y seguridad. La inferencia local puede beneficiar algunos ejes y dejar otros intactos. Escribe hipótesis y umbrales antes de probar. Este paso fija el alcance de un piloto de agente de código con modelos locales y herramientas aisladas. Define responsable, entorno y criterio de aceptación. La decisión seleccionar modelo y política de ejecución mediante pruebas distintas y reproducibles debe demostrarse mediante hardware, contexto, memoria, latencia, benchmark, archivo, red, credencial, comando, diff y readback; evita verbos amplios que no indiquen qué se probará, permitirá, bloqueará o remitirá a una persona con autoridad.

Construye tareas representativas y fallidas. Incluye corrección de error, refactor, búsqueda y uso de terminal en repositorios autorizados. Añade identificadores ambiguos, contexto largo y una tarea que debe detenerse. Compara éxito funcional, diff y pruebas, no solo tokens por segundo. Conserva versiones de modelo y entorno. Incluye casos comunes, extremos y fallidos. Prueba rutas remotas, herramientas integradas fuera del proceso, presión de memoria y tareas no representadas de manera controlada y registra exclusiones. Un resultado positivo no cubre aquello que nunca formó parte de la muestra. La seguridad del método depende tanto de sus límites como de la precisión observada.

Mide memoria durante la sesión completa. Registra carga inicial, pico, caché, presión de otras aplicaciones y degradación a medida que crece el contexto. Una sesión corta puede ocultar límites. Observa también recuperación después de fallo y cambio entre local y nube. El hardware debe sostener el trabajo real, no solo cargar pesos. Usa permisos mínimos y separa preparación, aprobación y ejecución. El objetivo es asistencia de código rápida con límites demostrados sobre acceso y cambios. Una sola identidad o credencial no debe acumular acciones con consecuencias distintas solo por comodidad. Diseña confirmación, readback y reversión antes de exponer el piloto a usuarios reales.

Prueba la política con intentos prohibidos. Configura acceso permitido y bloqueado a directorios, red y variables sensibles. Pide acciones que violen cada regla usando datos sintéticos. La prueba exitosa incluye denegación clara y registro. No uses credenciales reales como señuelo ni salgas del entorno acordado para demostrar aislamiento. Conecta cada métrica con una decisión. Para un piloto de agente de código con modelos locales y herramientas aisladas, conserva hardware, contexto, memoria, latencia, benchmark, archivo, red, credencial, comando, diff y readback. Añade una señal de daño, un umbral máximo y una persona que pueda detener el ensayo. Mejorar tiempo o volumen no compensa automáticamente exposición, inequidad, errores o pérdida de trazabilidad.

Inspecciona diferencias entre herramientas. Compara terminal, herramientas de archivo, servidores locales y remotos. Verifica dónde se aplica política y qué componente valida solicitudes. Una herramienta fuera del aislamiento de proceso puede depender de comprobaciones en la aplicación. Documenta esa diferencia para no prometer garantías uniformes. Ensaya timeout, respuesta ambigua, cambio de datos y revocación. Antes de repetir, relee el destino y evita duplicados. Comprueba rutas remotas, herramientas integradas fuera del proceso, presión de memoria y tareas no representadas. Otra persona debe poder reconstruir la secuencia usando registros sin depender de la memoria de quien ejecutó la prueba.

Decide con evidencia de código y seguridad. Aprueba una combinación solo si cumple calidad mínima y bloqueos esperados. Relee el repositorio, ejecuta pruebas y compara diff. Registra riesgo residual y tareas que permanecerán en nube o revisión manual. Repite cuando cambien modelo, runtime, herramienta o política del sistema. Cierra con go, revise o stop y documenta la razón. asistencia de código rápida con límites demostrados sobre acceso y cambios existe solo si el estado real coincide con el solicitado y el equipo conoce pendientes, propietario y fecha de revisión. La guía se convierte así en un control que puede repetirse cuando cambian las condiciones.