Código humano de 2020 superó a agentes codificados con vibraciones en pruebas agénticas

ChatGPT y otras herramientas de codificación de vibraciones fueron puestas a prueba en casi 40.000 partidas – y perdieron ante el código escrito por estudiantes de posgrado antes de la invención de los Modelos de Lenguaje Grande.

En un nuevo estudio del Reino Unido, los investigadores enfrentaron a agentes codificados por humanos contra agentes codificados con vibraciones desarrollados con los últimos Modelos de Lenguaje Grande (MLL), como ChatGPT-5 y Claude, y encontraron que los agentes creados sin la ayuda de la IA superaron fácilmente a las versiones facilitadas por la IA.

Ambos conjuntos de agentes fueron creados por diferentes generaciones de estudiantes del Laboratorio de Inteligencia Artificial del Instituto Federal de Tecnología de Suiza. Los agentes no IA fueron desarrollados como parte de un curso en 2020, dos años antes de la invención de ChatGPT y el comienzo de la revolución de los MLL, mientras que los nuevos agentes fueron creados por estudiantes actuales, ayudados por los MLL más recientes y mejores disponibles.

Incluso con un juego amañado, las soluciones codificadas con vibraciones no pudieron ganar, y los cinco primeros lugares fueron ocupados consistentemente por agentes “crudos”, con la mayoría de los agentes MLL (33 de 40) derrotados fácilmente por agentes de referencia “muy simples” en 38.304 desafíos en un torneo, en una amplia variedad de variables y circunstancias.

El documento establece:

‘Nuestro trabajo demuestra que, si bien los MLL de última generación pueden generar código que se ejecuta (es decir, libre de errores de sintaxis), la solución generada no es competitiva con las soluciones diseñadas por humanos en dimensiones como la planificación estratégica, la optimización o la competencia entre agentes.

‘Por lo tanto, este trabajo lleva a la vanguardia esta nueva frontera en la generación de código, y tiene como objetivo facilitar el desarrollo de benchmarks, conjuntos de datos y referencias de código abierto que pongan a prueba la síntesis de código impulsada por la razón.’

El desafío diseñado consistía en participar creativamente en subastas, en una variedad de estrategias, y en organizar la logística de entrega de artículos ganados a los ganadores.

Los autores señalan que se otorgaron varias ventajas a los MLL, como intervenir en su código para mejorar su rendimiento, una ventaja que no se permitió al código de 2020. A pesar de esto, incluso cuando se les proporcionó código correctivo que habría mejorado definitivamente sus resultados, los MLL no pudieron aceptarlo ni utilizarlo:

‘En nuestra evaluación, incluso cuando se expone una buena solución en contexto, el MLL sigue siendo incapaz de utilizarla.

‘Este resultado también plantea interesantes preguntas de investigación sobre los límites del aprendizaje en contexto y la resolución de problemas con refuerzo en escenarios complejos.’

Los MLL utilizados en la prueba fueron GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1, y DeepSeek R1*.

El nuevo documento se titula ¿Puede la codificación de vibraciones superar a los estudiantes de posgrado en ciencias de la computación? Un torneo de codificación de MLL contra humanos en planificación estratégica basada en el mercado, y proviene de un autor de la Universidad de Southampton y otro de la Universidad de Oxford y el Instituto Alan Turing. El benchmark se lanzará pronto, según los autores.

Método

Los autores señalan que las pruebas tradicionales en esta esfera se centran en desafíos con soluciones binarias claramente definidas (correctas o no correctas), verificadas a través de pruebas unitarias. Sostienen que esto no es la forma ideal de explorar las limitaciones de la codificación de MLL, por lo que los autores diseñaron un escenario de desafío más complejo, con múltiples benchmarks internos y hitos, en el que la victoria es posible, pero lejos de ser simple:

Comparación de enfoques basados en pruebas unitarias estándar (arriba), y el escenario de desafío más abierto diseñado por los autores (en azul, abajo). Fuente

El problema de subasta, recogida y entrega (APDP) utilizado para el estudio de los autores fue seleccionado en parte porque había un corpus de trabajo de estudiantes de 2020 de la universidad suiza; trabajo que buscaba crear agentes automatizados para la tarea APDP, antes de cualquier capacidad para fortalecer el desarrollo a través de la IA. Por lo tanto, fue relativamente fácil asignar a estudiantes modernos la misma tarea, pero con las herramientas actuales.

Los autores buscaron evitar marcos de prueba populares como HumanEval, BigCodeBench y WebDev Arena (entre muchos otros), ya que esta clase de procedimientos de prueba tiende a sufrir de contaminación de datos (es decir, instancias en las que el sistema puede haber entrenado en datos de prueba en lugar de respetar una división).

El APDP es un problema logístico de dos etapas basado en subastas inversas y enrutamiento de vehículos. En la primera etapa, los agentes compiten para ganar tareas de entrega presentando ofertas por la cantidad que deberían ser pagados para completar cada una. Ofertar demasiado alto significa perder la tarea; ofertar demasiado bajo puede significar perder dinero.

En la segunda etapa, cada agente debe crear un plan eficiente para cumplir solo las tareas que ganó, asignándolas a vehículos con diferentes capacidades y costos, bajo restricciones de tiempo y recursos:

En el APDP, las empresas ofertan en subastas inversas para tareas de entrega, luego optimizan las rutas de los vehículos para cumplir solo las tareas que ganan, con el objetivo de maximizar las ganancias.

El objetivo no es simplemente completar las tareas, sino maximizar las ganancias generales anticipando qué conjuntos de tareas funcionarán mejor juntos y prediciendo las estrategias de los competidores que también tratan de hacer lo mismo.

El benchmark APDP aumenta la dificultad de las tareas de generación de código al introducir la planificación estratégica a lo largo de una secuencia de subastas interdependientes, con cada oferta que reconfigura el panorama de las elecciones futuras; y por lo tanto requiere que los agentes razonen no solo sobre los costos inmediatos, sino sobre la posición, el tiempo y las consecuencias a largo plazo.

El problema de entrega central es NP-difícil, es decir, no hay algoritmo que pueda encontrar la mejor solución en un tiempo razonable a medida que aumenta el número de tareas. Esto hace que la fuerza bruta sea un enfoque inviable y obliga a los agentes a intercambiar precisión por velocidad.

La carrera está en marcha

La evaluación de los autores comparó 40 agentes codificados con MLL contra 17 agentes codificados por humanos en una serie de torneos cara a cara. Cada uno de los 12 torneos utilizó una combinación diferente de cuatro topologías de redes viales, y consistió en emparejamientos todos contra todos, con los agentes enfrentándose a cada oponente dos veces: una vez controlando cada una de las dos empresas, con especificaciones de vehículos diferentes.

Este escenario produjo 3.192 partidas por torneo, con un total de 38.304 partidas. En cada partida, se subastaron 50 tareas de entrega, definidas por sus puntos de recogida y entrega y peso, y se extrajeron al azar a través de diseños de redes viales modelados en Suiza, Francia, Gran Bretaña y los Países Bajos:

Redes viales simplificadas utilizadas en el torneo: Gran Bretaña (arriba a la izquierda), Suiza (arriba a la derecha), los Países Bajos (abajo a la izquierda) y Francia (abajo a la derecha). Los cuadrados azules y rojos marcan las tareas de recogida y entrega. Los triángulos coloreados muestran las posiciones actuales de los vehículos de los agentes.

Los agentes de los estudiantes se seleccionaron de un torneo de curso de 2020. Ocho provenían de los mejores rendimientos en una final de eliminación simple, y cuatro más se eligieron por su fuerte rendimiento contra los agentes de referencia en partidas cara a cara.

Los agentes de referencia seguían heurísticas fijas. Naive calculaba la distancia total y ofertaba en consecuencia, utilizando solo un vehículo y ignorando el batch; ExpCostFixedBid simulaba 10 tareas aleatorias y ofertaba el costo marginal promedio; Honest calculaba el costo marginal real de insertar la tarea en el calendario; ModelOpponent hizo lo mismo, pero agregó una estimación del costo del oponente, ofertando el máximo; y RiskSeeking combinó un prior con decadencia en el tiempo con una estimación de costo en vivo y modelado de oponentes, ofertando el más alto de los dos.

La evaluación incluyó 40 agentes codificados con MLL construidos utilizando los mencionados GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro y DeepSeek R1. Cada modelo se promovió con cinco estrategias distintas, aplicadas dos veces por modelo.

Dos estrategias utilizaron promociones estáticas escritas por diferentes autores, mientras que una tercera pidió al modelo que se auto reflexionara y revisara su propia salida; otra involucró crítica y revisión por un MLL separado. La estrategia final utilizó GPT-4 para sintetizar una nueva promoción revisando los cuatro enfoques anteriores.

La promoción base reflejó la tarea original del estudiante, describiendo el entorno de entrega e instruyendo al modelo para ofertar y planificar para maximizar las ganancias, sin confiar en métodos de alta complejidad.

Todos los agentes MLL se probaron en configuraciones de autojuego y torneo hasta que se corrigieron todos los errores observables. La corrección de errores se manejó de forma autónoma por los MLL, promovida con la información de error.

Los fallos comunes de los MLL, según el documento, incluyeron violaciones de los límites de tiempo, fallos para recoger o entregar tareas asignadas y violaciones de las restricciones de capacidad de los vehículos, errores que a menudo surgieron al ignorar instrucciones explícitas o por una lógica de replaneación defectuosa^†:

‘Otro problema común que encontramos (principalmente con Gemini, Claude y DeepSeek, y no tanto con GPT) es que el MLL a menudo fallaba consistentemente al resolver un error.

‘Por ejemplo, un agente se agotaba constantemente, a pesar de múltiples (por ejemplo, 5-15) ciclos de promoción del MLL con el error y recepción de la versión actualizada del código.

‘La única solución que encontramos para tales situaciones (donde el MLL falla repetidamente al resolver el mismo error) es reiniciar desde cero. En general, observamos la necesidad de un esfuerzo manual significativo para lograr un código libre de errores. Teníamos que generar sustancialmente más agentes para obtener los 40 agentes libres de errores que evaluamos.’

Los resultados que se muestran a continuación resumen los resultados de 12 torneos de doble ronda, que abarcan cuatro topologías de redes y tres torneos por topología, lo que produce casi 40.000 partidas:

Para contexto, cada agente jugó 112 partidas por torneo, por lo que el promedio máximo posible para victorias o derrotas por agente es 112. La desviación estándar (SD) refleja la variabilidad a través de los torneos. Los agentes codificados por humanos aparecen en negrita. Los agentes codificados con MLL están etiquetados por modelo (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), seguido de un código de estrategia de dos letras y un dígito que indica si el agente es el primero o el segundo generado con esa promoción. Fuente

En cuanto a los resultados que se muestran arriba, los autores declaran^†:

‘Los MLL no generaron código esperado/competitivo incluso en variantes más simples del problema APDP (a pesar de que el código es en gran medida libre de errores de sintaxis). Esto subraya la importancia de benchmarks de evaluación de código impulsados por la razón que van más allá del auto-completado e identifican nuevas debilidades de los MLL.’

‘Nuestros resultados demuestran una clara superioridad de los agentes codificados por humanos: (i) Los cinco primeros lugares son consistentemente ocupados por agentes de estudiantes, y (ii) la mayoría de los agentes MLL (33 de 40) son derrotados por agentes de referencia muy simples (como la oferta de costo fijo esperado).’

‘Es importante destacar que no depuramos el código de los estudiantes (mientras que probamos y depuramos exhaustivamente el código MLL, tanto en configuraciones de autojuego como de torneo). Cada vez que un agente de estudiante se estrellaba, automáticamente le dimos la victoria al MLL. Un gran número de estos estrellamientos sería fácil de arreglar (por ejemplo, los agentes se agotaban), por lo que los agentes de estudiantes podrían clasificar aún más alto.’

Como experimento adicional, se promovió a GPT-5 Thinking para mejorar el código del agente de mejor rendimiento humano, Estudiante 1; pero el agente modificado por el MLL cayó al décimo lugar, ahora el peor de todos los puntajes humanos. En lugar de mejorar la solución, los cambios de los MLL la degradaron en casi un 20%.

Los autores concluyen:

‘[Nuestros] resultados resaltan importantes limitaciones de la generación de código de MLL, más notablemente sus capacidades limitadas de razonamiento y planificación al generar [código]. Los MLL modernos pueden proporcionar código libre de errores de sintaxis que se ejecuta, pero eso no es el benchmark que debemos usar para medir el progreso hacia una IA general avanzada.’

Conclusión

Los autores mismos observan hacia el final del documento que la codificación de vibraciones ha empoderado a personas de todos los orígenes técnicos, y caracterizan la práctica de manera positiva, como una fuerza niveladora. Sin embargo, también implican que, ya que la codificación de vibraciones acaba de llegar, sus límites no son conocidos y pueden ser asumidos como más altos de lo que se puede esperar razonablemente.

Terminan su oferta llamando a un cambio de objetivo ‘de código que se compila a código que compite’.

Una pregunta que el lector casual de este nuevo y interesante documento puede tener es si los autores están golpeando hacia arriba o hacia abajo, ya que la tarea agéntica en cuestión es considerablemente más compleja y envuelta que escupir scripts de PowerShell y otras formas de funcionalidad y arreglos menores para los cuales la codificación de vibraciones está bien adaptada.

* Por favor, tenga en cuenta que el documento se refiere continuamente a ‘DeepThink R1′, que parece ser inexistente, apareciendo solo un puñado de referencias en Internet (presumiblemente de otros autores que han escrito mal ‘DeepSeek R1)’. Si este es mi error, por favor contácteme a través de mis detalles de perfil y lo corregiré.

^† Énfasis de los autores, no mío.

Publicado por primera vez el miércoles 26 de noviembre de 2025. Corregido a las 17:35 est para la formato.