Cómo el flywheel mejora un revisor con IA

Un flywheel de mejora continua es el mecanismo que convierte los errores de un revisor automático en aprendizaje real. Si trabajas con sistemas de revisión de código o policy gates apoyados en IA, aquí entiendes cómo cada falso positivo y falso negativo se transforma en datos que suben la precisión con el uso.

Piensa en un gate que lleva semanas activo en payments. Ha acertado mucho, pero también falló: marcó cosas que no eran problema y dejó pasar otras que sí lo eran. En un sistema estático, esos fallos son solo fallos. En uno bien diseñado, son insumos para mejorar.

Por qué un flywheel refuerza la precisión con cada uso

Un flywheel es un ciclo de retroalimentación que se refuerza a sí mismo. La lógica es sencilla y encadenada: la fricción operativa y los errores del revisor se capturan para refinar el sistema, eso sube la precisión, la precisión sube la confianza del equipo, la confianza sube el uso, y más uso significa capturar más casos borde. Y vuelta a empezar.

¿Qué es un flywheel en un sistema de revisión con IA? Es un ciclo que se refuerza solo: los errores capturados refinan el sistema, eso mejora la precisión, aumenta la confianza y el uso, y el mayor uso genera más casos para seguir mejorando.

El motor que hace girar todo eso es un dataset de regresión. Sin ese dataset, el ciclo no gira [00:22].

Cómo funciona el dataset de regresión

Cada falso positivo reportado y cada falso negativo descubierto se convierte en una nueva fila del dataset. Esa es la regla central que sostiene la mejora continua [00:38].

Antes de desplegar cualquier cambio en el prompt o en el modelo, se exige que el revisor pruebe contra ese dataset. Así garantizas con evidencia dos cosas:

• Que no estás rompiendo lo que ya funcionaba.
• Que un error del pasado no se vuelva a repetir.

En la práctica, esto se apoya en un histórico de revisiones anteriores guardado en formato JSON. Lo valioso de ese archivo es que recopila las decisiones de la IA y del humano lado a lado [01:07].

Qué compara el histórico de revisiones

Cada entrada muestra qué política sugirió la IA y qué decidió el humano. En los ejemplos del histórico, para un caso ambos coincidieron en bloquear, en otro ambos en pasar, y en otro nuevamente en bloquear [01:20]. Esa comparación es la materia prima de todo el análisis.

Para medirla, un script genera una estadística de esa comparación. Con solo tres casos ya muestra un acuerdo cercano al 100%, sin falsos positivos ni falsos negativos [01:45]. La idea es que construyas un histórico real y extenso, tal como se trabajó a lo largo del curso.

¿Qué diferencia hay entre falso positivo y falso negativo en una revisión? Un falso positivo ocurre cuando la IA marca como problema algo que no lo era. Un falso negativo es cuando deja pasar algo que sí era un problema.

Cómo una discrepancia se convierte en ajuste de política

Aquí viene lo interesante. Supón que en una revisión saltó un warning porque faltaba un test. Para la IA eso era bloqueante, pero el humano lo consideró solo un warning [02:11]. ¿Qué haces con esa diferencia?

La incluyes en el historial como una nueva entrada. La IA puede ayudarte a agregarla, pero en el ejemplo se trajo preparada en un PR [02:28].

Al correr ese PR, el regression report muestra que ya existe un falso positivo, exactamente el mismo cálculo del script original. La clave es que ese script se integró dentro del workflow del reviewer: cada vez que corre un PR, vuelve a revisar y va agregando casos automáticamente [02:47].

Con más casos, el acuerdo empieza a disminuir, y eso es una buena señal. El reporte llega a sugerir un cambio concreto: en un caso etiquetado como Test missing critical part, recomienda cambiar la política del reviewer para que ese tipo de caso sea solo un warn y no un bloqueante [03:12].

Con ese hallazgo, vas a los archivos de políticas y ajustas la regla. Por ejemplo, cuando falte un test, que el sistema no bloquee sino que solamente alerte [03:35]. Así la discrepancia entre humano e IA deja de ser un problema y se vuelve una decisión de diseño.

¿Cómo saber si mi revisor con IA está mejorando? Revisa el regression report: a medida que crece el histórico, la métrica de acuerdo debería subir y ser más precisa. Un porcentaje alto y estable indica un sistema que madura.

Cómo el sistema mejora solo con el uso continuo

Con pocos casos, cuatro en el ejemplo, el porcentaje aún no es representativo. Con el histórico completo, la meta es ver un porcentaje de acuerdo cada vez más alto [03:50].

Tres piezas hacen que el sistema mejore solo:

• Cada falso positivo y falso negativo se convierte en una fila nueva del dataset.
• La auditoría activa muestrea revisiones pasadas para detectar patrones.
• El protocolo de override captura en vivo las discrepancias entre el humano y la IA.

Con estas tres, el sistema mejora únicamente con el uso continuo, sin intervención manual constante. Ese es el verdadero valor del flywheel.

Pero un sistema que emite veredictos, incluso uno que aprende, no está completo sin una política estricta que le diga al equipo cómo accionar esa información. Esa política es lo último por construir. ¿Cómo se define esa política de acción? Cuéntame en los comentarios cómo la aplicarías en tu propio flujo de revisión.