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

Un Registered Report arXiv aborda 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 formato 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.

Qué aporta este enfoque

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

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

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

2. El vínculo con el debate "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 ello. Esto obliga a repensar los flujos de trabajo: más salvaguardas automatizadas aguas abajo, menos fe en el ojo humano aguas arriba.

3. Qué puede sacar el craft de esto, ya mismo. Dos gestos concretos: (a) hacer explícita la revisión de código de IA (checklist breve: intención, invariantes, casos límite) en lugar de implícita; (b) medir en casa los incidentes post-merge vinculados a código de IA "aceptado sin discusión".

Conclusión

Para un director técnico: no esperar a los resultados finales para actuar. La demanda de bases empíricas 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.