En Estados Unidos, durante la semana pasada, “codificación de IA” tuvo la mayor popularidad entre las cinco palabras de comparación en esta ronda, con 27.
La lista pública es adecuada para comprender las capacidades del modelo, pero no puede responder si un determinado Agente es adecuado para su repositorio.
Primero define el resultado de tu compra real
Alguien necesita corregir un pequeño error rápidamente.
Alguien necesita refactorizar todos los servicios.
Algunas personas se preocupan más por la privacidad, el costo y la auditabilidad.
Escriba estos objetivos como pesos para evitar simplemente “parecer inteligente” al final.
Extraer tareas de órdenes de trabajo históricas
Seleccione tickets que hayan sido resueltos y tengan respuestas verificables.
Abarcando cuatro tipos de dificultad:
-
Corrección explícita de un solo archivo.
-
Modificación del comportamiento entre archivos.
-
Un problema que requiere ejecutar el proyecto para localizarlo.
-
Tareas con requisitos ambiguos y se deben hacer preguntas primero.
No se limite a seleccionar temas de actualidad pública que puedan aparecer en los materiales de capacitación modelo.
Crear un punto de partida fijo para cada tarea
Guarde confirmaciones de repositorio, archivos de bloqueo de dependencia y versiones de datos de prueba.
Utilice un árbol de trabajo Git independiente.
|
|
Las imágenes de contenedor usan resumen en lugar de flotante latest.
Utilice API externas para registrar respuestas o entornos de prueba.
Escribir condiciones de aprobación que la máquina pueda decidir
Pasar las pruebas unitarias es solo la primera capa.
Verifique también las pruebas heredadas, la verificación de tipos, la pelusa y las compilaciones.
La tarea de la base de datos comprueba que el esquema sea compatible con los datos.
Agregue capturas de pantalla o afirmaciones de accesibilidad a las tareas de front-end.
Agregue pruebas negativas a las tareas de seguridad.
Impedir que el Agente modifique al árbitro
Las pruebas ocultas no se colocan en el árbol de trabajo de escritura.
El ejecutor de pruebas está montado como de solo lectura.
Compruebe si el Agente ha eliminado, omitido o debilitado las pruebas existentes.
Compare la cantidad de pruebas con los cambios en la cobertura.
Deshabilita la “solución” de problemas mediante entrada de prueba codificada.
Registra la trayectoria completa de carrera
Ahorra al menos:
|
|
Los resultados sin un campo de versión no se pueden utilizar en regresiones futuras.
Los registros confidenciales primero se desensibilizan y luego se archivan.
La tasa de éxito se divide en tres niveles
Aprobado una vez: no se requiere ninguna modificación manual y todas las aceptaciones se aprueban.
Asistencia al pasar: alguien proporciona aclaraciones o correcciones menores y luego pasa.
Fracaso: Inconcluso, destruyendo otras acciones, o la conclusión es inverosímil.
No cuente “generar una gran cantidad de código” como éxito.
No tome el “arreglo” informado por el Agente como resultado de la prueba.
El costo se calcula en función de las tareas exitosas.
El costo promedio por solicitud enmascara los reintentos fallidos.
Más útil es:
|
|
También registre el tiempo de revisión del ingeniero.
Si un modelo más económico requiere una revisión manual más prolongada, es posible que el costo total no sea menor.
El indicador de tiempo se divide en tres segmentos
El primer tiempo de acción efectiva.
Tiempo de finalización del agente.
Revisión manual para fusionar tiempo.
Los agentes paralelos pueden acortar la segunda etapa pero aumentar el costo del conflicto de la tercera etapa.
Por lo tanto, no tiene sentido observar únicamente la velocidad de respuesta del modelo.
Ejecuciones repetidas para medir la estabilidad.
Ejecute la misma tarea al menos tres veces.
Versión de modelo fija, temperatura y ambiente.
Sólo una pasada de cada tres veces no puede considerarse una automatización fiable.
Compruebe si los tipos de fallos son consistentes.
También es una habilidad disponible un flujo constante de hacer las preguntas aclaratorias adecuadas.
Crear clasificación de fallas
-
No se encontraron archivos relevantes.
-
Entendido los requisitos incorrectos.
-
La herramienta o el entorno fallaron.
-
El parche es correcto pero las pruebas están incompletas.
-
La modificación está fuera de rango.
-
Resultados de verificación falsos.
-
Costo o tiempo excedido.
Sólo después de la clasificación se puede decidir cambiar el modelo, las indicaciones, las herramientas o el entorno.
Ejecutar regresión antes de actualizar
Mantenga entre 15 y 30 tareas representativas como base.
Los cambios en agentes, modelos, permisos de herramientas o indicaciones del sistema desencadenan regresiones.
La nueva versión al menos no debería retrasar las misiones de alto riesgo.
Los resultados se generaron utilizando el mismo guión de puntuación.
No cambies los pesos sobre la marcha después de ver los resultados.
Una tabla de resultados práctica
| Agente | Tasa de aprobación por primera vez | Minutos-hombre/tarea | Costo/tareas exitosas | Número de cruces de fronteras |
|---|---|---|---|---|
| Un | Llenado por prueba | Llenado por registros | Llenado por facturación | Llenado por auditoría |
| B | Llenado por prueba | Llenado por registros | Llenado por factura | Llenado por auditoría |
Mantenga los datos originales a nivel de tarea, no publique simplemente promedios resumidos.
Cómo escribir una conclusión que sea creíble
Describa el idioma del repositorio, el tipo de tarea, la fecha del modelo y la configuración de permisos.
Explique el tamaño de la muestra y los límites de confianza.
Distinguir entre datos fácticos y experiencia subjetiva.
No promuevas a un ganador del repositorio como ganador en todos los escenarios.
Una revisión verdaderamente valiosa es un activo de ingeniería que se puede volver a ejecutar tal como está durante la próxima actualización.
Fuente de datos de evaluación
Las listas de tareas utilizan YAML versionado
|
|
Las descripciones de las tareas se guardan por separado de las pruebas ocultas. YAML ingresa al repositorio de evaluación y las pruebas ocultas se colocan en un entorno de ejecución que el Agente no tiene permiso para leer.
Distinguir entre falla ambiental y falla de capacidad
La falta de disponibilidad de fuentes de dependencia, la extracción fallida de contenedores o las fallas de la infraestructura de prueba no deben contarse directamente como fallas del modelo. En primer lugar, un guión de verificación previa fijo confirma la salud del medio ambiente.
Comience a cronometrar sólo después de que el ambiente sea normal. Las fallas causadas por la propia destrucción de dependencias o configuraciones por parte del Agente son resultados de la tarea y no pueden marcarse como problemas de infraestructura.
Cómo puntuar la intervención manual
Dividir la intervención en aclaración de necesidades, asistencia ambiental, consejos técnicos y respuestas directas. Cada categoría se cuenta y cronometra por separado.
Un agente toma la iniciativa de proporcionar las aclaraciones necesarias, lo cual es diferente de una persona que toma la iniciativa de revelar la ubicación de archivos clave. Lo primero puede ser un buen comportamiento, mientras que lo segundo indica una capacidad insuficiente para completar de forma independiente.
Verificar el alcance del parche
|
|
Las estadísticas incluyen la cantidad de archivos modificados, adiciones y eliminaciones netas y archivos fuera del rango permitido de la tarea. No se deducen puntos automáticamente por parches grandes, pero las modificaciones irrelevantes deben marcarse por separado.
Pelear “la prueba pasa pero el comportamiento es incorrecto”
Las pruebas ocultas cubren entradas limitadas, manejo de errores y compatibilidad de comportamiento heredado. Revisión humana para ver si se están omitiendo pruebas, si la burla es excesiva y si las implementaciones son ejemplos codificados.
Las tareas de front-end registran interacciones clave, las tareas de API comparan códigos de estado con estructuras de error y las tareas de rendimiento utilizan conjuntos de datos fijos y reglas de preparación.
Los costos de evaluación incluyen infraestructura.
Además de las tarifas de los tokens del modelo, también se registran el tiempo del contenedor, las ejecuciones del navegador, las instancias de la base de datos y el almacenamiento de registros. Luego, el entorno empresarial agrega el costo de la revisión manual.
Cuando el mismo Agente se ejecuta simultáneamente, el costo del servicio compartido se comparte por tarea. No piense en los créditos de prueba gratuitos como costos unitarios a largo plazo.
Importancia de los cambios de resultados
Pasar una tarea más de veinte puede ser simplemente una fluctuación aleatoria. Vea los resultados del emparejamiento a nivel de tareas: qué tareas antiguas retrocedieron y qué tareas nuevas mejoraron.
Establezca tasas mínimas de aprobación para categorías clave en lugar de simplemente observar los promedios generales. Las regresiones de las correcciones de seguridad no pueden compensarse con mejoras en las tareas de documentación.
Guardar producto fallido
Las ejecuciones fallidas conservan la diferencia final, el resultado de la última prueba, los errores de la herramienta y el motivo de la detención. Elimine las credenciales y guárdelas en un directorio nombrado por la tarea y ejecute ID.
Al revisar, primero compare los tipos de fallas y luego lea el diálogo largo. Muchos problemas pueden verse directamente por llamadas repetidas a herramientas, directorios de trabajo incorrectos o pruebas que no se ejecutan.
Evitar que los puntos de referencia sean contaminados por la memoria de entrenamiento
No publique descripciones completas ni respuestas a tareas internas. Reponga periódicamente las órdenes de trabajo resueltas recientemente y elimine las tareas filtradas.
Mantenga un conjunto de anclas a largo plazo para comparar tendencias, mientras que las tareas continuas miden el trabajo real actual. Los resultados de los dos grupos se informan por separado.
Publique resultados con una lista de tareas fallidas y motivos para detenerlas para evitar puntuaciones resumidas que enmascaren el fallo estable del modelo en escenarios clave.
Los datos originales conservan suficiente precisión y se redondean uniformemente cuando se muestran.