Dos motores, una auditoría

Pide a dos revisores con experiencia que lean la misma pull request y obtendrás dos listas distintas. Uno nota que el identificador de la URL nunca se contrasta con la sesión; el otro ve que el bucle de reintentos deja abierta una conexión a la base de datos en cada fallo. Ninguno se equivoca y ninguno está completo. Los modelos de lenguaje se comportan igual, por el mismo motivo: lo que un revisor nota depende de lo que ha visto antes.

El acuerdo es una señal

Un modelo solo te dice cuánta confianza tiene. Ese número vale algo, pero lo declara él mismo: el modelo corrige su propio examen. Cuando dos modelos entrenados por laboratorios distintos, con datos distintos y debilidades distintas, llegan de forma independiente a la misma debilidad en el mismo archivo, ese acuerdo es evidencia que viene de fuera del modelo. Es lo más parecido a una segunda opinión que tiene una revisión automática.

Lo contrario importa igual. Un hallazgo que informa un solo motor no es falso por ello, y descartarlo sería tirar justo los errores que un revisor único detecta bien. Debe informarse y atribuirse, para que seas tú quien lo valore.

Dónde se queda callado un motor

En la práctica los dos motores divergen sobre todo en las clases de error que exigen razonar en lugar de reconocer patrones:

• Fallos de lógica: un descuento aplicado dos veces, una máquina de estados que acepta un reembolso después de otro, una comprobación de propiedad hecha sobre el objeto equivocado.
• Autorización propia del framework: middleware que protege un grupo de rutas pero no el manejador de API montado al lado.
• Fugas de recursos y memoria: escuchadores, temporizadores y conexiones que se abren por petición y se liberan solo en el camino feliz.
• Inyección de prompt escondida en comentarios o fixtures, que se lee como texto inofensivo si no la estás buscando.

Cómo dos informes se vuelven uno

La fusión es donde el segundo motor se paga solo o te duplica el ruido. Las reglas que fijamos:

• Los hallazgos se emparejan por lo que identifica al error, no por la redacción: su clase CWE y el archivo donde vive.
• Una coincidencia se informa una vez, con la más estricta de las dos severidades, porque la lectura segura es sobre la que se actúa.
• Se conserva la redacción con la que un desarrollador puede trabajar: la evidencia más larga, el parche concreto, los pasos ordenados.
• Un hallazgo corroborado sube a confianza alta y queda etiquetado con ambos motores.
• Un hallazgo que vio un solo motor se mantiene, marcado con el motor que lo encontró.

Ambos motores leen la misma fuente a la vez, así que la auditoría no tarda el doble; cuesta el doble de ejecutar, y por eso pertenece al plan Pro. Si el segundo motor no está disponible o devuelve algo inservible, la auditoría termina con el primero en lugar de fallar.

Nada de esto hace verdadero un informe. Dos motores pueden coincidir y equivocarse los dos; la evidencia citada bajo cada hallazgo está ahí precisamente para que compruebes en vez de confiar. Lo que aporta la corroboración es un orden: cuando llegan cien hallazgos y solo tienes una tarde, empieza por los que vieron dos revisores independientes.