¿Cómo los profesionales del software juzgan realmente el código generado por IA?

Un Registered Report arXiv ataca la pregunta que evitábamos: ¿qué criterios, qué sesgos, movilizan los desarrolladores al aceptar —o rechazar— el código de un LLM? Es la base empírica que faltaba en el debate.

En términos sencillos

Un artículo de arXiv publicado el 13 de julio de 2026 (arXiv:2607.09434) formaliza, en Registered Report, un estudio sobre cómo los desarrolladores profesionales evalúan el código generado por herramientas como Copilot, ChatGPT o Claude. En otras palabras: el primer intento riguroso de medir qué significa realmente "aceptar código de IA" en la práctica.

Lo que aporta el enfoque

Un Registered Report publica el protocolo (pregunta, hipótesis, plan de análisis) ANTES de recopilar los datos: metodología revisada por pares de antemano, resultados publicados independientemente de su signo. Este formato, importado de la psicología experimental, elimina el p-hacking y el storytelling posterior. Su presencia en Ingeniería de Software es en sí misma una señal: el campo finalmente exige pruebas construidas, no anécdotas de demostraciones. El resumen de arXiv lo anuncia con claridad: varios años después de Copilot, la literatura carece de fundamentos empíricos sobre el gesto central: la revisión humana del código de IA.

Análisis: por qué importa para la profesión

1. El vacío en la ecuación. Medimos la velocidad de generación, la aceptación en el editor, los tokens facturados. No medimos —en serio— la calidad de los criterios que los desarrolladores usan al hacer clic en "aceptar". Este artículo apunta justo a ese punto ciego.

2. La conexión con el hilo de "hype-fatiga". Otro artículo de arXiv publicado el mismo día ("Programmers Are Poor and Overconfident Judges of LLM-Generated Assertions", arXiv:2607.08885) sugiere que los desarrolladores sobrestiman su capacidad para juzgar las salidas de los LLM. Cruzados, ambos dibujan un cuadro incómodo: juzgamos rápido, juzgamos mal y estamos seguros de nosotros mismos. Esto obliga a repensar los flujos de trabajo: más protecciones automatizadas aguas abajo, menos fe en el ojo humano aguas arriba.

3. Lo que el craft puede extraer de inmediato. Dos gestos concretos: (a) hacer explícita la revisión de un código de IA (checklist corta: intención, invariantes, casos límite) en lugar de implícita; (b) medir en casa los incidentes posteriores a la fusión relacionados con código de IA "aceptado sin discusión".

¿Y entonces?

Para un director técnico: no esperar los resultados finales para actuar. La demanda de fundamentos empíricos sobre "cómo juzgamos el código de IA" ya es una demanda estratégica. Instrumenten sus propios flujos de aceptación: las organizaciones que tengan datos sobre sus desarrolladores tendrán una ventaja real sobre aquellas que dirigen la revisión por intuición.