Son las 3:14 de la madrugada y un desarrollador senior entrecierra los ojos al mirar un diff generado por un agente que afirma haber corregido una condición de carrera. El agente está convencido. El código parece limpio. Entonces, el pipeline de CI estalla de una manera que sugiere que el agente no solo arregló el bug, sino que decidió reescribir todo el modelo de concurrencia de la aplicación mientras el dev se tomaba un café. Este es el estado actual de la ingeniería de software “autónoma”: un equilibrio sobre un cable donde la red de seguridad está hecha de papel de fumar.
El último informe de MarkTechPost confirma lo que sospechábamos: estamos en una carrera armamentística de benchmarks donde la meta sigue moviéndose. El problema más evidente es el uso continuado de datos contaminados. Utilizar un benchmark que se ha filtrado en el conjunto de entrenamiento es como un chef que usa una sartén pre-salada y afirma haber sazonado la carne a la perfección. Es un espectáculo, no una habilidad. ¿Quién confía realmente en un benchmark que el modelo probablemente ya haya visto en su fase de preentrenamiento? (Probablemente solo los equipos de marketing redactando los comunicados de prensa). Cuando las preguntas del examen están en la guía de estudio, la puntuación resultante mide memoria, no inteligencia.
Luego está la pugna entre Claude Code y GPT-5.5. Claude lleva la ventaja en el “qué” (la calidad real del código), mientras que GPT gana en el “cómo” (la ejecución en terminal). En el vacío, estas cifras parecen espectaculares. En un repositorio real con 100k líneas de código espagueti heredado, la fricción se hace evidente. La latencia de estos bucles de agente sigue siendo una pesadilla; esperar a que un agente “piense” a través de una estructura de directorios solo para que alucine una ruta de archivo es una tortura en toda regla. Y luego está el coste. Ver cómo un bucle de agente quema cinco dólares en créditos de API solo para descubrir que un archivo de configuración fue renombrado es un poco como pagarle mil dólares a un consultor para que te diga que la impresora está desconectada.
La fragmentación mencionada en el informe es solo un síntoma del mismo problema que vimos durante la era de HumanEval. Cada laboratorio quiere su propio ranking porque le permite definir el “éxito” de una manera que favorece su arquitectura específica. Es como un jugador de béisbol que tiene un promedio de bateo enorme, pero solo porque juega contra un equipo de instituto en una liga privada. Si no puedes ganar en razonamiento general, simplemente inventas un “Terminal-Bench” y te quedas con la victoria. Es un juego de manos jugado con tokens. Estamos viendo una tendencia donde las herramientas se vuelven más capaces, pero la forma en que medimos esa capacidad se vuelve cada vez más deshonesto.
La burbuja de la persecución de benchmarks acabará estallando. Para el cuarto trimestre de 2026, veremos un cambio hacia benchmarks de “Live-Repo” donde los agentes se vean obligados a resolver bugs en bases de código privadas e inéditas en tiempo real, sin posibilidad de filtración del conjunto de entrenamiento. Esto obligaría a los laboratorios a dejar de optimizar para el examen y empezar a optimizar para el trabajo real. O quizás no; quizás simplemente sigamos inventando nuevos benchmarks ligeramente distintos para mantener el ciclo de hype girando. Sea como fuere, los rankings actuales son esencialmente una lista de quién es el mejor recitando las respuestas de un examen que ya ha robado.
Las cifras son una fantasía, pero las herramientas son casi útiles.
