Este artículo argumenta que los puntos de referencia de codificación actuales están fundamentalmente desalineados con la realidad de la ingeniería de software agéntica moderna. Los autores sostienen que las evaluaciones existentes confunden erróneamente el rendimiento de los modelos de lenguaje subyacentes con los sistemas más amplios —las complejas capas de orquestación que incluyen herramientas, bucles de retroalimentación y entornos— que realmente determinan los resultados. Además, critican la dependencia de soluciones de referencia únicas para la calificación, señalando que este método no considera las diversas opciones arquitectónicas de alta calidad ni las implementaciones alternativas válidas. Para abordar estos problemas, los investigadores proponen un nuevo marco de evaluación que prioriza las señales a nivel de componente sobre las puntuaciones opacas de extremo a extremo. Al abogar por verificadores de comportamiento de múltiples formas e informes de metadatos detallados, buscan crear una medición más precisa de cómo operan los sistemas autónomos en escenarios de desarrollo reales. Este cambio permitiría a los desarrolladores aislar y mejorar partes específicas de un sistema agéntico en lugar de depender de una única tasa de éxito, que podría ser engañosa.
Enlace al artículo científico, para aquellos interesados en profundizar en el tema: "Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering", por Maria I. Gorinova y colegas de Tessl, Londres. Publicado el 16 de Junio de 2026.
El resumen, la transcripción, y la traducción fueron hechas usando herramientas de software de Inteligencia Artificial.
El resumen se presenta en la forma de un diálogo entre dos personajes sintéticos que llamaremos Alicia y Beto.
Resumen
Beto
Imagina por un segundo, ¿verdad?, que eres una gerente de contratación en una firma tecnológica de primer nivel. Y necesitas incorporar a un nuevo ingeniero de software líder.
Alicia
Bien. Un puesto de alto riesgo.
Beto
Exacto. Así que tienes a este candidato justo frente a ti. ¿Cómo lo pruebas? Quiero decir, no simplemente lo pondrías en una habitación vacía, le darías un marcador de pizarra y le dirías: "Escribe un algoritmo de ordenación perfecto, de memoria. ¡Vamos!".
Alicia
Bueno, algunas partes hacían eso, pero sí, es una práctica terrible.
Beto
Totalmente poco realista. Querrías ver cómo trabajan en el mundo real.
Alicia
Sí. Cómo usan sus herramientas, cómo manejan la presión.
Beto
Correcto. Querrías saber cómo buscan a través de documentación densa o, cómo aprovechan su entorno de desarrollo, incluso cómo interpretan un mensaje de Slack súper vago de un gerente de producto.
Alicia
Sí. Los mensajes vagos de Slack son la prueba real.
Beto
Y fundamentalmente, cómo responden cuando su código falla, una prueba de compilación. Porque la ingeniería de software real no es solo escribir líneas de código aisladas en un vacío. Es interactuar con este ecosistema masivo y desordenado.
Alicia
Es todo un proceso. Sí.
Beto
Pero aquí está la parte loca: este escenario de pizarra en una habitación vacía artificial. Eso es casi exactamente cómo la industria tecnológica está calificando a nuestros ingenieros de software de IA más avanzados actualmente.
Alicia
Es una desconexión masiva. Estamos construyendo estos sistemas de IA interactivos y altamente complejos, pero los estamos evaluando con rúbricas diseñadas solo para una era completamente diferente de la tecnología.
Beto
Es como si estuviéramos probando un smartphone moderno para ver si puede hacer un pisapapeles decente.
Alicia
Básicamente, sí, los estamos probando como si existieran en un vacío, completamente aislados del entorno real en el que se supone que deben operar.
Beto
Bien, vamos a desglosar esto porque estaba mirando la pila de investigación que nos enviaste esta semana. Y, un documento realmente me llamó la atención.
Alicia
Ah, el paper Tessl.
Beto
Sí, el artículo de posición provocador de los investigadores de Tessl. Se titula: "Los puntos de referencia de codificación están desalineados con la ingeniería de software agéntico".
Alicia
Es una gran lectura. Realmente sacude las cosas.
Beto
Lo hace. Así que nuestra misión para este análisis profundo de hoy es descubrir exactamente por qué nuestras calificaciones actuales para los agentes de IA están fundamentalmente rotas.
Alicia
Y están muy rotas.
Beto
Correcto. Y más importante aún, necesitamos entender de estas fuentes cómo arreglar estos puntos de referencia es absolutamente crucial, si realmente queremos confiar en el software del futuro.
La Brecha en los Puntos de Referencia: Por qué los Agentes de Codificación Necesitan una Mejor Evaluación.
Alicia
Sí, es una conversación crítica para tener ahora mismo. Quiero decir, estamos entrando por completo en la era de la ingeniería de software de agentes.
Beto
Lo que significa, ¿qué exactamente para el oyente que tal vez no sea desarrollador?
Alicia
Bueno, significa que ya no estamos pidiendo a la IA que complete una línea de Python automáticamente. Como los días de solo un corrector ortográfico elegante para código han terminado. Estamos pidiendo a los agentes de IA que, eh, abran solicitudes de extracción ("pull requests"), naveguen por repositorios masivos, escriban bibliotecas internas, ...
Beto
... que gestionen tareas de ingeniería de varios días.
Alicia
Exacto. Pero si las métricas que usamos para decidir qué IA es, cito, "la mejor", nuestra industria entera corre el riesgo de optimizar por las cosas equivocadas, tenemos que aplicar cierto pensamiento crítico serio a nuestras propias herramientas de medición antes de que el sistema escale más.
Beto
Para entender por qué el sistema de calificación está roto, tenemos que cambiar completamente nuestro modelo mental de lo que es un codificador de IA.
Alicia
Correcto. Tenemos que tirar las definiciones antiguas.
Beto
Sí, porque este paper habla sobre alejarse de esta idea de la IA como solo un modelo. Creo que todos tenemos esta tendencia a pensar en la IA como "un cerebro en una jarra".
Alicia
El cerebro omnisciente.
Beto
Sí. ¿Verdad? Sabes, el intelecto independiente, descorporeado, que simplemente se sienta allí, piensa muy duro y escupe código perfecto.
Alicia
Lo cual es una imagen de ciencia ficción muy convincente, pero no es la realidad.
Beto
No, para nada. Los autores argumentan que un codificador de IA es en realidad un sistema de armazón ("harness"). Así que vamos a desglosar la mecánica de esa distinción, porque siento que cambia todo sobre cómo medimos el éxito aquí.
Alicia
Realmente lo hace. Ese concepto del cerebro en una jarra, realmente se refiere solo al modelo de lenguaje grande, el LLM en sí.
Beto
Como GPT-4 o Claude.
Alicia
Exacto. Pero en la práctica, no simplemente liberas un LLM crudo en una base de código empresarial. No sabría qué hacer. El LLM está envuelto en lo que llamamos un "armazón de agente" ("agent harness").
Beto
¿Un armazón de agente? Bien. ¿Qué hace eso?
Alicia
Es la capa inmediata alrededor del modelo que le da la capacidad de interactuar con herramientas. Así que incluye el sistema impulsado, la interfaz para ejecutar comandos de terminal. Es el bucle específico que le permite intentar algo, ver un error e intentarlo de nuevo.
Beto
Así que es como darle al cerebro un cuerpo.
Alicia
Correcto. Ejemplos de esto serían Claude code o el agente SWE. El armazón de agente esencialmente le da al modelo subyacente sus manos y sus ojos.
Beto
Bien, tenemos el cerebro y tenemos el armazón dándole manos y ojos. Pero según la investigación que compartiste, la arquitectura se vuelve mucho más grande cuando escalamos hasta tareas de nivel empresarial.
Alicia
Oh, sí. Los datos lo llevan un paso más allá, porque por encima de ese armazón de agente, está el armazón del sistema.
Beto
El armazón del sistema.
Alicia
Sí. Esta es la capa de orquestación exterior. Toma una meta de alto nivel masiva, como construir una nueva función de autenticación, y la descompone en tareas concretas.
Beto
Como un gerente de proyecto.
Alicia
Exacto, como un gerente de proyecto. Despacha esas tareas a múltiples armazones de agente. Gestiona el entorno en el que operan y enruta sus salidas a través de varios mecanismos de retroalimentación.
Beto
Vaya.
Alicia
Entonces, cuando hablamos de ingeniería de software de IA a escala, estamos hablando de este sistema compuesto masivo, no solo del modelo subyacente.
Beto
Y aquí está el punto de datos del paper que me voló la cabeza con respecto a ese sistema compuesto. Los investigadores miraron el leaderboard de la terminal, ¿verdad?
Alicia
Sí, el que prueba a los agentes en tareas realistas de línea de comandos.
Beto
Bien. Y aislaron un solo modelo subyacente específico. Claude Opus 4.6.
Alicia
Exactamente el mismo cerebro.
Beto
Exactamente el mismo cerebro. Pero cuando cambiaron el armazón a su alrededor, la tasa de éxito se movió salvajemente. Bajo un armazón, Claude Code, obtuvo un 58.0%.
Alicia
Lo cual es decente.
Beto
Decente. Sí. Pero bajo un armazón diferente llamado Forge code, ese mismo modelo obtuvo un 79.8%.
Alicia
Eso es un salto masivo.
Beto
Es casi un cambio de 20 puntos basado enteramente en el andamiaje.
Alicia
Sí. Y lo fascinante aquí es cómo esto expone la falacia de nuestra actual cultura de leaderboard. Quiero decir, cuando ves un titular que dice que el modelo X logró un 75% en un punto de referencia de codificación, es inherentemente engañoso.
Beto
Porque le da todo el crédito al modelo.
Alicia
Exacto. Atribuimos esa puntuación únicamente al modelo al cerebro. Pero ese número está midiendo en realidad el sistema compuesto. Está midiendo el modelo más el prompt más la interfaz de herramientas más las convenciones del entorno.
Beto
Lo veo como si fuera una carrera de Fórmula Uno, ¿sabes?
Alicia
Oh, esa es una buena analogía.
Beto
Sí. Como el modelo de IA, el LLM es el conductor. Pero el armazón del sistema, eso es el equipo de boxes, los ingenieros de telemetría, la aerodinámica del coche, la estrategia de neumáticos, la condición de la pista.
Alicia
Correcto. Todo el paquete.
Beto
Y si un conductor gana una carrera, no simplemente le entregas un trofeo al conductor y dices, "wow, los humanos son naturalmente rápidos". Elogias a todo el equipo de ingeniería.
Alicia
Pero ahora mismo nuestros puntos de referencia de IA están fingiendo que el coche ni siquiera existe.
Beto
Simplemente ponen el nombre del conductor en un leaderboard.
Alicia
Y el costo de esa ilusión es increíblemente alto porque si confundimos el modelo con el armazón, atribuimos erróneamente de dónde vienen nuestras mejoras.
Beto
Ni siquiera sabemos qué estamos mejorando. ¿Verdad?
Alicia
Correcto. Los investigadores señalan que incluso factores como las asignaciones de contenedores o las semillas de evaluación, que son básicamente las condiciones de inicio aleatorias de la prueba, pueden mover materialmente la tasa de aprobación.
Beto
Solo las condiciones de inicio, eso es salvaje.
Alicia
Sí. Entonces, el remedio que propone el paper como estructural. Los administradores de puntos de referencia y los mantenedores de leaderboards deben exigir metadatos estrictos para cada envío.
Beto
No solo el nombre del modelo.
Alicia
Correcto. No deberíamos solo ver el nombre del modelo. Necesitamos ver la versión del armazón de agente, el hash del entorno, la versión del conjunto de datos. Si otro desarrollador quiere reproducir un resultado, necesita saber las especificaciones exactas de todo el vehículo.
Beto
No solo el nombre del conductor. Me encanta eso.
Bien, si el modelo es solo el conductor, vamos a levantar el capó de este vehículo.
El artículo proporciona un diagrama muy detallado de cómo se ve realmente un sistema agéntico moderno.
El Armazón de un agente
Alicia
Es un diagrama de flujo muy complejo.
Beto
Lo es. Empieza con una meta, que alimenta el repo y el contexto del agente. Cosas como wikis de proyectos, reglas de codificación, especificaciones. Luego tienes herramientas y servicios, que incluye chat, tickets de soporte, políticas de seguridad.
Alicia
Todo el contexto y las necesidades del agente.
Beto
Correcto. Pero el núcleo absoluto de este motor, la parte en la que los autores se enfocan mucho son los mecanismos de retroalimentación.
Alicia
Sí. Los mecanismos de retroalimentación son los sensores y la telemetría de tu coche de carreras. Sin ellos, el agente está volando a ciegas.
Beto
Entonces, ¿cómo los categorizan?
Alicia
El paper los divide en tres niveles distintos basados en la latencia y el alcance. Así que el primer nivel es el bucle interno.
Beto
El bucle interno.
Alicia
Sí. Estas son señales rápidas y baratas que tardan quizás segundos o minutos. Estamos hablando de pruebas unitarias, verificación de tipos, linting básico, o incluso un LLM rápido como juez que mira criterios específicos.
Beto
Sí. Solo verificaciones de sensatez básicas.
Alicia
Correcto. Le da al agente una dirección estrecha inmediata sobre si el código que acaba de escribir es realmente ejecutable y cumple con la política.
Beto
Así que déjame entrar aquí. Porque cuando pienso en una IA escribiendo código, ¿verdad? Y golpea un error en el bucle interno, ajusta ligeramente el código y lo vuelve a ejecutar. Suena menos a ingeniería y más a un cerrador de candados que no entiende realmente el mecanismo del cilindro.
Alicia
Solo forzándolo.
Beto
Sí. Simplemente meten cada llave en una llavero masivo en la cerradura hasta que finalmente gira. No están razonando sobre el código. Solo están forzando el texto rojo hasta que se vuelve verde.
Alicia
Quiero decir, si solo tuviéramos el bucle interno, estarías totalmente en lo correcto. Forzar una prueba unitaria no significa que el código esté bien diseñado o sea arquitectónicamente sólido.
Beto
Correcto. Solo significa que no explotó.
Alicia
Exacto. Solo significa que no se bloqueó inmediatamente. Y esa limitación es por la que un armazón de sistema productivo requiere el siguiente nivel, que es el bucle medio.
Beto
El bucle medio. Bien.
Alicia
Estas señales tardan minutos u horas en ejecutarse. Esto incluye cosas como la jardinería automatizada de documentos y las evaluaciones sintéticas. En el paper, realmente hacen referencia a un sistema de código abierto que construyeron en NS2 donde el bucle medio incluye la revisión arquitectónica de agentes.
Beto
Vamos a bajar la velocidad y definir algunos de esos. Porque son cruciales para cómo la IA realmente "piensa" sobre el proyecto en general. ¿Cómo funciona exactamente algo como la jardinería automatizada de puntos o las pruebas de mutación en el bucle medio?
Alicia
Entonces, la "jardinería automatizada de documentos" ("automated doc-gardening") es un gran ejemplo de razonamiento de nivel superior. En lugar de solo verificar si el código compila, el sistema lee toda la base de código, identifica comentarios o documentación obsoletos que ya no coinciden con la lógica real del nuevo código y propone actualizaciones.
Beto
Oh, vaya. Así que requiere una comprensión contextual real.
Alicia
Sí. Y las "pruebas de mutación" ("mutation testing") son aún más rigurosas.
Beto
Las pruebas de mutación suenan intensas. ¿Qué es eso?
Alicia
Es donde el sistema inyecta intencionalmente pequeños errores, mutaciones, en la base de código para ver si las pruebas unitarias recién escritas por la IA realmente las atrapan.
Beto
Espera, ¿en serio? Intencionalmente rompe el código para probar la prueba.
Alicia
Exacto. Si el error artificial sobrevive, demuestra que las pruebas de la IA son débiles. Esto toma minutos u horas porque el sistema tiene que compilar y ejecutar suites de pruebas masivas a través de diferentes ramas. Pero asegura que el código sea estructuralmente robusto, no solo sintácticamente correcto.
Beto
Así que el bucle medio es como el desarrollador sénior revisando tu solicitud de extracción, ejecutando verificaciones de seguridad exhaustivas y, asegurándose de que no solo ensamblaste una solución que va a romper toda la base de datos la próxima semana.
Alicia
Esa es una forma perfecta de decirlo. Y más allá del desarrollador sénior, finalmente tienes el bucle exterior.
Beto
El bucle exterior.
Alicia
Estas señales tardan días o semanas. Esta es la verdad fundamental. ¿Se aceptó realmente la solicitud de extracción por un mantenedor humano?
Beto
El jefe final.
Alicia
Correcto. ¿Cuál es la tasa de incidentes y producción donde son las quejas de los clientes? ¿Tuvo que revertirse el código?
Beto
Consecuencias en el mundo real.
Alicia
Exacto. Y la belleza del armazón de sistema es que estos tres bucles se informan constantemente entre sí. El bucle exterior calibra en qué proxies de los bucles internos y medios deberías confiar realmente.
Beto
Porque si tus pruebas del bucle interno están pasando con holgura, pero tu bucle exterior muestra un pico masivo en los informes de errores de clientes, bueno, tu bucle interno te está fallando.
Alicia
Tu telemetría está completamente rota.
Beto
Tu telemetría está rota. Y lo loco que la fuente se menciona, es que estos sistemas de agente se están volviendo tan avanzados que el armazón puede reescribir sus propias verificaciones.
Alicia
Sí, autocorrección.
Beto
Los agentes están escribiendo y manteniendo las mismas reglas de lint y rúbricas que les restringen. Están ajustando sus propios bucles de retroalimentación basándose en esos resultados de bucle exterior a largo plazo.
Alicia
Lo cual es increíble porque esa relación dinámica es el punto central de un sistema de IA moderno. Pero cuando retrocedes y miras cómo calificamos actualmente estos sistemas dinámicos de múltiples bucles, es absurdo.
Beto
No tiene sentido.
Alicia
Tomamos esta masiva capa de orquestación, que está diseñada para adaptarse y evolucionar. Y la forzamos a conformarse con una única métrica histórica estática.
Beto
Y aquí es donde se vuelve realmente interesante porque golpeamos el próximo síntoma de esta desalineación, lo que el paper llama "la tiranía de la respuesta correcta".
Alicia
La tiranía de la respuesta correcta. Sí.
Beto
Tenemos estos sistemas increíblemente complejos, pero la forma en que los probamos en puntos de referencia populares como SWE Bench es simplemente notablemente rígida.
Alicia
SWE Bench es el estándar de la industria ahora mismo.
Beto
Lo es, pero mira cómo funciona. Básicamente toma un problema histórico real de un repositorio de GitHub. Y aísla el parche exacto que un desarrollador humano escribió para solucionarlo hace años. Luego le pide a la IA que resuelva el problema. Y califica a la IA basándose en qué tan de cerca su solución refleja lo que hizo el humano, específicamente verificando si pasa exactamente las mismas pruebas que el humano escribió para ese parche.
Alicia
Sí. Si miras cómo opera un SWE Bench, usa fallar para pasar y pasar para pruebas de aprobación, que se derivan directamente de la solicitud de extracción original humana.
Beto
Así que está sesgado desde el principio.
Alicia
Inherentemente, el punto de referencia asume que el parche humano histórico es el estándar de oro. Asume que solo hay una forma correcta de resolver el problema y que las pruebas unitarias asociadas con esa solución específica son los árbitros finales e incuestionables de la verdad.
Beto
Lo cual es una locura. Para poner eso en perspectiva para ti que estás escuchando, es exactamente como un estudiante brillante de matemáticas toma el examen final, ¿verdad?
Alicia
Okay. Sí.
Beto
El estudiante mira un problema de cálculo complejo, se da cuenta de que hay una forma totalmente innovadora y elegante de resolverlo que ahorra tres pasos y obtiene la respuesta correcta. Pero el profesor lo califica como erróneo, porque no usó el método clunky de cinco pasos escrito en la clave de respuestas del profesor.
Alicia
Eso es exactamente lo que está sucediendo. Y el paper destaca investigaciones donde usan "pruebas diferenciales" ("differential testing") en estos parches de IA supuestamente resueltos para demostrar este punto exacto.
Beto
¿Pruebas diferenciales?
Alicia
Sí, las pruebas diferenciales son una técnica donde tomas el sistema original y el sistema modificado por la IA. Le tiras una gran cantidad de entradas variadas a ambos y comparas las salidas.
Beto
Como una prueba de estrés.
Alicia
Exacto. Si las salidas difieren, la IA ha cambiado el comportamiento de ejecución subyacente.
Y los hallazgos aquí fueron asombrosos. Encontraron que el 7.8% de los parches de IA que "pasan la prueba de SWE Bench", en realidad fallan en las pruebas escritas por el desarrollador en el repositorio.
Beto
Espera, ¿entonces pasaron el punto de referencia pero rompieron el código real?
Alicia
Sí. Y aún más impactante, el 29.6% de las soluciones de IA divergen del comportamiento de ejecución del parche original de oro.
Beto
Esa estadística del 29.6% es enorme, pero desglosémoslo para ver por qué divergieron. ¿Verdad?, porque no es necesariamente porque la IA estuviera equivocada.
Alicia
Para nada.
Beto
Digamos que la IA analiza el código y se da cuenta de que el código humano original tenía una fuga de memoria masiva.
Alicia
Un escenario muy común.
Beto
Bien. Así que la IA decide refactorizar el código. Reestablece la API en un nivel de abstracción diferente y elimina por completo la fuga de memoria. Arregla la causa raíz del error hermosamente.
Alicia
Una solución mucho mejor.
Beto
Pero, puesto que cambió la estructura del código, las pruebas humanas originales ya no se aplican perfectamente. Así que el SWE Bench falla a la IA. Estamos penalizando activamente a la IA por ser un ingeniero mejor que el humano fue.
Alicia
Es tan retroactivo. En la teoría de la medición, llamamos esto "un problema clásico de validez constructo". Estamos usando el parche humano histórico como un proxy para el constructo de, sabes, arreglar el error. Pero como acabas de señalar, no son lo mismo. La calificación de referencia única penaliza alternativas igualmente válidas y a veces superiores.
Beto
Sofoca la innovación.
Alicia
Completamente. Además, esas pruebas unitarias ocultas en el punto de referencia solo califican el comportamiento local. No pueden ver el bosque por los árboles.
Beto
Dame un ejemplo de eso.
Alicia
Bueno, una IA podría pasar la prueba específica duplicando código por todas partes, o creando un ciclo de dependencia masivo. Funciona técnicamente, pero un mantenedor humano rechazaría la solicitud de extracción en el sitio porque la arquitectura está arruinada.
Beto
Así que si no podemos calificar la salida final contra una respuesta humana histórica, parece que la única alternativa es evaluar las barreras de protección mismas, como probar el proceso en lugar de solo el producto.
Alicia
Sí, exactamente.
Beto
Necesitamos una forma de decirle al sistema de IA lo que queremos hacer, sin prescribir estrictamente cómo debe escribir el código.
Alicia
Y ese es el problema abierto central en la evaluación de codificación de agentes ahora mismo.
El remedio requiere un cambio fundamental en cómo escribimos las especificaciones. El paper argumenta que necesitamos verificadores de comportamiento multiforma ("multi-shape behavioral verifiers").
Beto
Verificadores de comportamiento multiforma. ¿Cómo se ve eso en lenguaje sencillo?
Alicia
Significa que necesitamos evaluar basándonos en la invariancia, que son condiciones que deben mantenerse verdaderas independientemente de la implementación.
Beto
Okay, ¿como qué?
Alicia
Por ejemplo, declarar que una consulta a una base de datos debe devolver dentro de 50 milisegundos o que se debe usar un estándar de cifrado específico, sin dictar las líneas de código específicas que la IA usa para lograr ese estado. Tenemos que desacoplar el verificador de cualquier solución candidata única.
Beto
Porque ya no podemos simplemente verificar la respuesta final contra el código de un humano, nos encontramos con un problema masivo de visibilidad cuando el código del agente finalmente falla, como que simplemente no podemos ver lo que salió mal.
Alicia
Es una caja negra.
Beto
El paper le llama "la ausencia de señal a nivel de componente". Me gusta pensar en ello como una necesidad desesperada de visión de rayos X.
Alicia
Me gusta esa visión de rayos X.
Beto
Porque evaluar un agente de IA en estas tareas complejas es un juego de espera masivo. Una ejecución de extremo a extremo en una sola tarea puede llevar horas. Y al final de esas horas, obtienes una sola puntuación, aprobado o fallido.
Alicia
Y si conectamos esto con la imagen más grande, piensa en ese diagrama del armazón de sistema que discutimos antes.
Beto
Con todas las diferentes partes.
Alicia
Correcto. Tienes el modelo, el mapa de contexto, las reglas de linting, el revisor agéntico, las verificaciones del grafo de dependencia. Si esa tarea de extremo a extremo falla después de tres horas de cómputo, ¿qué parte se rompió?
Beto
Exacto. ¿Falló el mapa de contexto al extraer la documentación correcta? ¿El linter proporcionó un error demasiado pedante que envió al modelo por un callejón sin salida? ¿O el LLM en sí no logró razonar a través de la lógica?
Alicia
Una sola puntuación de fallo en la pasada te dice absolutamente nada sobre el punto interno de fallo.
Beto
Es literalmente como conducir por la autopista y se enciende tu luz de advertencia del motor. Así que lo llevas al mecánico y el mecánico solo te mira y dice, "sí, el coche está roto. Buena suerte".
Alicia
"Págame mil dólares".
Beto
Y se negaron a abrir el capó. Se negaron a decirte si es la transmisión, las bujías o la batería.
Entonces, ¿qué hacen los desarrolladores de IA ahora mismo? El paper usa la frase "ablación guiada por intuición" ("intuition guided ablation"). Guíanos a través de cómo se ve eso realmente para un desarrollador sentado en su escritorio.
Alicia
Oh, es una forma increíblemente lenta y agónica de hacer ingeniería.
Beto
Puedo imaginarlo.
Alicia
Imagina que eres un desarrollador y presionas ejecutar en una evaluación de agente a la 1:00 PM a las 4:00 PM, la prueba falla.
Beto
Tres horas desperdiciadas.
Alicia
Claro. Y no tienes telemetría de componentes. Así que usas tu intuición. Supones que tal vez el prompt fue demasiado restrictivo.
Beto
Solo adivina.
Alicia
Solo una adivinanza. Cambias tres palabras en el prompt. Vuelves a presionar ejecutar a las 4:45 PM. A las 7:45 PM, falla de nuevo.
Beto
Oh, hombre, eso es brutal.
Alicia
Okay, así que tal vez el prompt estaba bien, pero la ventana de contexto era demasiado pequeña. Expandes la ventana de contexto, presionas ejecutar y esperas otras tres horas. Estás cambiando una variable a la vez en un sistema masivo interconectado, completamente ciego a cómo interactúan los subcomponentes.
Beto
Entonces, ¿qué significa todo esto? ¿Cómo devolvemos a los desarrolladores su visión de rayos X? ¿Para que no desperdicien semanas completas de trabajo solo adivinando y probando?
Alicia
Bueno, esto plantea una pregunta importante sobre cómo probamos software en general. En la ingeniería de software tradicional, no solo escribimos pruebas de integración que revisan toda la aplicación a la vez.
Beto
Correcto. Probamos las piezas.
Alicia
Escribimos pruebas unitarias. Probamos funciones individuales en aislamiento estricto. Los autores del paper exigen que apliquemos esta misma lógica al armazón del sistema de IA. Debemos empezar a evaluar los componentes del armazón de forma independiente.
Beto
Así que en lugar de solo probar la salida final del código, necesitamos un punto de referencia específicamente para la capacidad de la IA para leer y filtrar un mapa de contexto, o un punto de referencia solo para qué tan bien el revisor agéntico proporciona retroalimentación sobre una solicitud deficiente. Necesitamos aislar las variables.
Alicia
Necesitamos una pila de verificadores.
Beto
La pila de verificadores para nuestros verificadores.
Alicia
Bien. Por ejemplo, si tienes un agente de mantenimiento cuyo trabajo es limpiar un repositorio, no deberías calificarlo solo por si la solicitud de extracción fue fusionada. Deberías reportar métricas a nivel de componente.
Beto
¿Como qué tipo de métricas?
Alicia
Como, ¿Si identificó y redujo la complejidad del código? ¿Cómo eliminó el código muerto sin romper dependencias? ¿Resolvió ciclos de dependencia existentes?
Si evalúas los componentes en aislamiento, entonces cuando el sistema de extremo a extremo inevitablemente falla, tienes la telemetría para señalar exactamente dónde ocurrió la ruptura.
Beto
Puedes ver realmente la bujía que falla.
Alicia
Exacto. Puedes arreglar el componente defectuoso específico en lugar de ajustar aleatoriamente toda la máquina y solo esperar lo mejor.
Beto
Tiene perfecto sentido cuando lo mapeas así.
Hemos hecho un viaje considerable hoy a través de las fuentes que proporcionaste y honestamente, remodela completamente cómo vemos la IA en el mundo del software.
Alicia
Es un cambio de paradigma, sin duda.
Beto
Empezamos por destrozar la solución de la IA como un cerebro mágico en una jarra, dándonos cuenta en cambio que es este vasto y complejo armazón de sistema completo con un conductor, un equipo de boxes y un vehículo altamente complejo.
Alicia
Todo el equipo de F1.
Beto
Correcto. Luego exploramos cómo este motor de blog depende de bucles internos y externos de retroalimentación solo para sobrevivir y cómo nuestras calificaciones actuales castigan estos sistemas exigiendo estas respuestas humanas históricas estrictamente copiadas en lugar de encontrar soluciones arquitectónicamente sólidas e innovadoras.
Alicia
Estamos fallando al estudiante brillante de matemáticas.
Beto
Exacto. Y finalmente, vimos lo desesperadamente que la industria necesita visión de rayos X, esta prueba a nivel de componente, para realmente entender y mejorar estas herramientas sin depender de conjeturas ciegas.
Alicia
Y el tema general aquí es que la medición moldea el comportamiento.
Beto
Esa es la clave.
Alicia
Si continuamos usando puntos de referencia diseñados para la era pre-agente, puntos de referencia que confunden el modelo con el armazón, que se basan en referencias humanas únicas y que ocultan fallos de componentes, inevitablemente construiremos sistemas frágiles y desalineados.
Si queremos que la IA actúe como ingenieros de software verdaderamente confiables, tenemos que empezar a evaluarlos como evaluamos a los ingenieros.
Beto
Y como oyente, tienes un interés profundamente arraigado en esto. Quiero decir, piensa en cuánto de tu vida está dictada por software complejo, desde los algoritmos bancarios que gestionan tus finanzas hasta los sistemas de navegación en tu coche, hasta los protocolos de seguridad que protegen tus datos personales.
Alicia
Está en todas partes.
Beto
Quieres que los ingenieros que construyen tu mundo estén pasando pruebas que realmente signifiquen algo en la realidad, no solo jugando con una prueba estandarizada defectuosa.
Alicia
Absolutamente.
Beto
Pero quiero dejarte con una última reflexión, ligeramente alucinante, extraída directamente de las realidades de sistemas como NS2 que describe el paper anteriormente.
Hablamos de cómo los agentes en el bucle medio están escribiendo y manteniendo activamente sus propias reglas vinculadas, sus propios parámetros de jardinería de documentos, su propia retroalimentación.
Alicia
Su auto-corrección.
Beto
La IA se está convirtiendo tanto en el estudiante que toma la prueba, como en el examinador que escribe la rúbrica de calificación. A medida que estos sistemas escalan y la IA ejerce más y más control sobre las mismas definiciones de lo que constituye "código bueno", ¿quién asegura que el punto de referencia en sí no se haya desviado secretamente de lo que los humanos realmente quieren?
Alicia
Esa es la pregunta de mil millones de dólares.
Beto
Si la IA está calificando meticulosamente su propia tarea basada en reglas que escribió ella misma, ¿cuánto tiempo pasará hasta que la tarea no parezca nada que un humano pueda comprender? Algo para reflexionar la próxima vez que presiones "actualizar" en tu aplicación favorita.
Entradas
