Agentes de IA revisaron más de 2000 artículos de ICML 2026 y hallaron errores que los revisores pasaron por alto

La revisión por pares en las principales conferencias de ML se apoya en gran medida en la confianza. Un revisor recibe varios artículos, dispone de un par de semanas y normalmente no va a ejecutar el código ajeno solo para comprobar una tabla. En el verano de 2026 se decidió poner esto a prueba de frente, con la ayuda de agentes de IA.

Qué ocurrió

Hugging Face, junto con alphaXiv, un servicio para debatir publicaciones científicas, organizó el hackatón ICML 2026 Open Reproductions. La tarea: tomar los trabajos aceptados en la conferencia (eran más de dos mil) e intentar reproducir los resultados declarados. Los participantes lo hicieron con la ayuda de agentes de IA. En los artículos aparecieron errores que los revisores no habían notado.

ICML es una de las principales conferencias de aprendizaje automático, y un artículo aceptado suele percibirse como una señal de calidad. Pero el revisor ve un PDF, y el código adjunto a menudo queda sin ejecutar: no hay tiempo ni incentivos para ello.

Es importante señalar lo que no dice el comunicado original. No se indica cuántos trabajos se lograron reproducir por completo, cuántos errores se encontraron ni cuán graves son: si se trata de una errata en una fórmula o de un resultado que se desmorona. Sin estas cifras, es pronto para afirmar que los agentes «refutaron» una parte de la ciencia. Pero el formato en sí es revelador: revisar de nuevo dos mil artículos antes chocaba con la falta de personas y de tiempo.

Cómo funciona en la práctica

El esquema para el agente es más o menos este: leer el artículo, encontrar el repositorio o reconstruir el método a partir de la descripción, ejecutar el código, obtener las cifras y compararlas con la tabla del texto. Cada paso por separado es aburrido, pero justo en esos pasos es donde se rompen los resultados.

Supongamos que un artículo declara una mejora de 3 puntos porcentuales en un benchmark. El agente ejecuta el código con los ajustes indicados y obtiene una mejora de medio punto. A partir de ahí hay varias posibilidades: un hiperparámetro del texto no coincide con el del código, los datos de prueba se filtraron al entrenamiento, o el modelo base de comparación estaba peor ajustado que el propio. Una persona que no ejecute el código no lo verá. El agente no se cansa y puede lanzar cientos de comprobaciones en paralelo.

Estas son causas típicas de discrepancias, no una lista de hallazgos del hackatón: los tipos concretos de errores no se revelan en los datos de origen.

Qué hacer con esto: desarrolladores y product managers

No tome la tabla de un artículo como garantía. Si construye un producto sobre un «estado del arte» de un trabajo reciente, sus cifras siguen siendo una hipótesis. Reserve tiempo para su propia reproducción y compruebe primero si alguien ya lo intentó.

Aplique el mismo método dentro de su empresa. Un agente que toma su informe interno de un experimento o la evaluación de un modelo e intenta repetirla desde cero a partir de la descripción es una forma barata de encontrar la brecha entre lo escrito y lo realmente ejecutado. Para los equipos que publican benchmarks y comparativas, es casi una etapa de QA ya preparada.

Observe el mercado. Para los fundadores, el hackatón destaca un nicho: herramientas de verificación de reproducibilidad, verificadores de metodología y auditoría de investigaciones para inversores y departamentos de I+D corporativos.

Limitaciones

Un agente que no logró reproducir un resultado todavía no ha demostrado el error de los autores. La causa puede ser falta de recursos de cómputo, datos cerrados, una descripción incompleta del método o un fallo del propio agente. Por eso los hallazgos deben ser confirmados por una persona. Lo realista es un esquema en el que el agente reúne candidatos a error y un experto emite el veredicto.

Existe también el riesgo inverso. Un torrente de falsos positivos inundaría a los autores de reclamaciones que habría que revisar a mano, y la confianza en las comprobaciones automáticas caería rápidamente.

Los revisores siguen ahí, pero ahora tienen un compañero que sí ejecuta el código. La reproducibilidad deja de ser un lujo y se convierte en un procedimiento automatizable, algo así como CI para la ciencia. Los equipos que dependen de investigaciones recientes deberían acostumbrarse a esto antes que los autores de los artículos.