Habr analiza el sesgo del oráculo: la IA acelera el código, pero la confianza en él no crece

La segunda parte de la serie «Programación fiable: del código a la tecnología», publicada en Habr, aborda una paradoja incómoda. Tras la adopción masiva de asistentes LLM, las métricas de proceso (velocidad, número de commits, tareas cerradas) suben, pero la seguridad de los ingenieros de que el código hace exactamente lo que debe no aumenta. El autor lo explica mediante el sesgo del oráculo y se apoya en estudios de DORA y Veracode y en el dataset FormAI. El anuncio de la publicación es breve, así que a continuación se desglosan la idea en sí y los datos a los que remite.

El problema del oráculo en la era de la generación

El oráculo de pruebas es lo que determina qué resultado se considera correcto. Antes, su fuente era una persona: leía el requisito, pensaba y anotaba el comportamiento esperado. Ahora, con frecuencia es el mismo modelo quien escribe la función y sus pruebas.

En eso consiste el sesgo del oráculo. Si el asistente ha entendido mal la tarea, fijará el error dos veces: en la implementación y en las comprobaciones. Las pruebas salen en verde, la cobertura es alta y el dashboard satisface, pero no hay confianza en el código. La verificación ha dejado de ser independiente, aunque formalmente siga existiendo.

Qué muestran los estudios

El panorama que describe el autor de la serie lo respaldan varias fuentes independientes:

• DORA, informe de 2024: un aumento del 25% en la adopción de IA se correlacionó con una caída de aproximadamente el 1,5% en el rendimiento de la entrega y de aproximadamente el 7,2% en su estabilidad.
• DORA, informe de 2025: alrededor del 90% de los encuestados usa IA, y cerca del 30% casi no confía en el código generado.
• Veracode, 2025: se hallaron vulnerabilidades en el 45% de las muestras de código generadas por más de un centenar de modelos sobre un conjunto de tareas.
• FormAI: unos 112 000 programas en C escritos por LLM. La verificación formal encontró vulnerabilidades en aproximadamente la mitad.

El último punto es importante desde el punto de vista metodológico. Las vulnerabilidades no se buscaron con otra red neuronal, sino con un verificador formal, es decir, con un oráculo que no depende del modelo.

Dónde se acumula la deuda

Generar es cada vez más barato; verificar, no. Hay más código, pero la atención del revisor sigue siendo la misma. El cuello de botella pasa de la escritura a la verificación, y si la revisión se reduce a un vistazo rápido al diff, la deuda técnica crece sin que se note. Esta conclusión se deriva de la lógica del proceso y no es una cifra concreta de los informes, pero concuerda con la caída de la estabilidad de la entrega en los datos de DORA.

Qué se puede hacer ya

La medida principal: no entregar al modelo a la vez la implementación y los criterios de corrección. En la práctica, esto significa:

• Formular a mano los requisitos y las pruebas de aceptación clave, antes de generar el código.
• Añadir comprobaciones que no dependan del asistente: análisis estático, pruebas basadas en propiedades (property-based), pruebas de mutación y, para las zonas críticas, verificación formal.
• Mirar el mutation score y no solo la cobertura. Una prueba que no falla cuando se rompe el código no demuestra nada.
• Marcar el código creado por IA y tener en cuenta la proporción de retrabajo y reversiones, no solo la velocidad de entrega.
• Reservar tiempo específico para la revisión y no tratarlo como un gasto adicional.

En la tercera parte de la serie, el autor promete un auditor final, una escala de confianza L0–L4 y recomendaciones prácticas. Por ahora, una cosa está clara: si solo se mide la velocidad, la confianza en el código seguirá cayendo, incluso cuando todos los gráficos suban.