demo técnica · software
Señalar qué cambios piden una segunda mirada antes de integrarse
El objetivo: que la segunda mirada llegue antes de que algo salga caro.
Vale para más que el código: cualquier flujo donde casi todo es rutina y de vez en cuando algo merece que otra persona lo mire dos veces, un pago fuera de lo normal, un alta con permisos de más, un cambio de configuración en caliente.
este cambio pide una segunda mirada
se integra un cambio pequeño, en un fichero que llevaba más de un año dormido
No es que sea culpable: es que despertar código antiguo es justo lo que, en la historia de este proyecto, acaba deshecho más a menudo. Merece un par de ojos más.
el coste, siempre al lado del beneficio
2,1×
más reversiones en la franja señalada que en la media
73:1
cambios frenados por cada reversión capturada
Ese segundo número, no el primero, es la decisión de negocio: un peaje razonable si la segunda mirada es barata; carísimo si no.
resumen
- los datos
- Los repositorios de VS Code y Kubernetes en GitHub: 300.000 cambios de código reales, con el registro completo de cuáles hubo que deshacer.
- la pregunta
- De vez en cuando un cambio sale mal y hay que deshacerlo. ¿Se puede saber de antemano qué cambios merecen una revisión extra?
- la prueba
- Mirando solo lo que se sabía en el momento de cada cambio, el sistema marca unos pocos como "mirar dos veces". Luego comprobamos cuáles acabaron deshechos.
- lo que salió
- En la franja que el sistema marcó hubo el doble de cambios deshechos que en la media. Y la sorpresa: el mismo detector, llevado a otro proyecto, dejó de funcionar.
Las demos anteriores miraban el archivo para entender lo que ya pasó. Esta intenta algo más incómodo: que el archivo te agarre del brazo ANTES de que algo salga mal.
El escenario: dos de los proyectos de software más activos del mundo (el editor VS Code y Kubernetes). Cientos de cambios integrándose cada semana. De vez en cuando uno sale mal y hay que revertirlo: deshacerlo, oficialmente y con registro. La pregunta: mirando solo lo que se sabía en el momento de cada cambio, ¿se puede señalar cuáles tienen probabilidad anormal de acabar revertidos?
Importante: esto NO va de encontrar culpables. Las identidades ni siquiera entran al análisis. Y no afirma causas: es un freno de precaución, como el médico que pide una prueba más por tu historial. Señala dónde mirar dos veces, nada más.
Las reglas de siempre, y una vara extra. Cada cambio se evalúa solo con la historia hasta ese instante. Parámetros congelados con huella criptográfica (42ad6d7). Y el sistema entrena en un proyecto y se examina, sin tocar un parámetro, en otro completamente distinto.
Pásalo por el freno: cuatro cambios reales
Cuatro cambios del tramo de examen de VS Code (2021-2024), puntuados con los parámetros congelados. Sin autor ni identificador: solo lo que el freno veía en ese momento. Elige uno, mira el semáforo y luego comprueba el desenlace real.
el examen, en directo 42ad6d7
pide una segunda mirada
probabilidad de acabar deshecho 3,1%, frente al 0,7% de media del examen. Cruza el umbral congelado: aviso.
lo que el freno vio
- El fichero llevaba 4,3 años sin tocarse. Despertar código dormido es la señal más fuerte en este proyecto.
- Quien lo firma llevaba 294 cambios en el proyecto, pero ninguno en ese fichero.
el peaje De cada 73 cambios que el freno paró en el examen, solo 1 acabó revertido. El aviso compensa si la segunda mirada es barata.
el desenlace, en el archivo real
aviso acertado Revertido 57 días después. Uno de los 126 que el freno cazó.
Lo que salió
En VS Code (46.333 cambios de examen), la franja que el freno señaló concentró 2,1 veces más reversiones que la media, capturando el 41% de todas las que hubo. El intervalo de confianza excluye el azar, y la ventaja sobre el mejor detector simple es limpia: los intervalos ni se tocan.
la ventaja sobre el azar, con la cura de humildad
73:1 cambios frenados por cada reversión capturada
La cura de humildad, también publicada: el mismo freno, transferido a Kubernetes sin tocar un parámetro, apenas se distingue del azar (1,3 veces, con intervalo que roza el 1). No existe el freno universal: cada casa tiene sus propias grietas, y hay que aprenderlas de su propia historia.
Dos cosas que no nos esperábamos
- Los cambios grandes NO son los peligrosos. El tamaño del cambio tiene correlación negativa con acabar revertido. El "cuidado, que es un cambio gordo" no sobrevive al backtest.
- Lo frágil es lo dormido. La señal más fuerte: ficheros que llevaban mucho tiempo sin tocarse. Despertar código antiguo es lo que pide la segunda mirada.
Cómo leer esto sin engañarse
- Medimos reversiones registradas, no bugs. Un cambio malo que se parcheó sin revertir no aparece. El freno predice "esto acabará deshecho", que es la huella pública del problema, no el problema entero.
- Sin la pista fácil también funciona. Quitando la señal "este fichero ya se revirtió antes" (que un escéptico llamaría tautológica, con razón), el resultado se mantiene: 2,15. El mérito no era la trampa.
- El umbral se congeló antes del examen y en el examen frenó al 19,7% de los cambios, no al 10% previsto: los scores derivaron. Nada de recolocar el listón después de saltar.
- Reversiones de trabajo en curso fuera: el 60% de las reversiones de VS Code son del propio autor el mismo día (deshacer un paso a medias). Contarlas habría inflado todo; el filtro es robusto (relajarlo a 2-3 días no mueve nada).
Los peros
- Sesgo de detección: una reversión existe porque alguien la vio y decidió revertir. Los negativos contienen fallos silenciosos que nadie deshizo.
- La etiqueta de "salió mal" viene del propio historial: son las reversiones registradas, identificadas de forma automática, sin revisión humana caso a caso. Parte de esas reversiones son decisiones de producto, no fallos, y esa contaminación no la hemos separado a mano.
- El 8,7% de las reversiones no se pudo trazar a su cambio original, y ese grupo está sesgado hacia cambios grandes: se declara y acota.
- Es un estudio sobre dos proyectos públicos con su cultura concreta de revisión; los números no viajan solos (la transferencia a Kubernetes lo demuestra).
Referencias
La predicción de riesgo por cambio es un campo con clásicos, y los gigantes lo usan internamente. Lo que esta demo añade: pre-registro público, probabilidades calibradas, el coste de la política publicado y una transferencia a otro proyecto que salió débil y se cuenta.
- Kamei et al. (IEEE TSE 2013), A Large-Scale Empirical Study of Just-in-Time Quality Assurance.
- Sistemas industriales de riesgo por cambio en Meta (Diff Risk Score) y Google (speculative testing).
Datos y agradecimientos
Pudimos hacerla porque VS Code y Kubernetes desarrollan en abierto, con su historia completa a la vista. Gracias.
Sin afiliación con Microsoft ni con la CNCF. Identidades hasheadas antes del análisis; ningún ejemplo público permite señalar a una persona.
¿Puedes usar esto? Sí. Nuestro análisis, las probabilidades del backtest y los textos de esta página se publican bajo licencia CC BY 4.0: úsalos, compártelos o analízalos libremente, citando la fuente, Team Banzai (team-banzai.com). Los datos de terceros (los historiales públicos de VS Code y Kubernetes en GitHub) conservan las condiciones de sus fuentes originales, y el código de cada proyecto conserva su licencia propia.
Hecho con Python y SQLite sobre la historia de git. Regresión logística con calibración isotónica, señales calculadas al instante de cada cambio. Ningún modelo de lenguaje decide nada.
Sobre esta demo
Estudio retrospectivo con fines ilustrativos, sobre los repositorios públicos de VS Code y Kubernetes. Mide reversiones registradas en cambios históricos ya resueltos; no mide calidad del software ni evalúa a los proyectos ni a sus colaboradores. Las identidades de autor quedan fuera del análisis y de toda superficie visible.
¿Y en tu empresa?
El mismo enfoque vale para marcar qué apuntes contables piden una segunda mirada antes de cerrar el mes, para señalar qué pedidos de compra se salen de lo normal antes de aprobarlos, o para avisar de qué altas de cliente conviene revisar dos veces antes de darlas por buenas.
Si alguno de estos experimentos te recuerda a un problema tuyo, despliegues que dan miedo sin saber por qué, un cambio de mil líneas y otro de tres revisados igual, controles que van por corazonada y no por dónde duele, escríbenos y lo comentamos. Sin rollo: te decimos si se puede o no.