Human-in-the-Loop: desarrollar con IA sin perder el control
Terminé el artículo anterior de esta serie con una pregunta: ¿algún agente de vuestra configuración sigue sabiendo cosas que no debería? Este trata sobre un fallo relacionado, pero distinto: no sobre qué sabe un agente, sino sobre cuándo lo detenéis para revisar su trabajo.
La automatización no tiene por qué implicar perder el control. Pero la forma en que la mayoría configura sus puntos de aprobación acaba dando una sensación de control sin que ese control sea realmente efectivo.
El punto de control al que dejé de prestar atención
Después de añadir pasos de aprobación entre cada etapa de un pipeline, noté algo incómodo: hacía clic en «todo bien» más rápido de lo que habría podido leer el diff.
Había puntos de control por todas partes: después de la especificación, después de la implementación, después de la verificación y, a veces, después de modificar un solo archivo. Revisarlos todos como es debido habría sido un trabajo a tiempo completo, así que, sin decidirlo conscientemente, empecé a echarles un vistazo por encima. Después, ni eso. Simplemente aprobaba, porque el pipeline estaba esperando y yo tenía otras cosas que hacer.
Sobre el papel, esa configuración no tenía nada de inseguro. En cada paso intervenía una persona. Pero un punto de control que nadie revisa de verdad no es supervisión: es un trámite disfrazado de revisión. En cierto modo, es peor que no tener ningún punto de control, porque genera una falsa sensación de seguridad: yo creía tener control sobre lo que llegaba a producción, pero no era así.
Cuándo dejar que el agente avance solo
No todos los pasos merecen un punto de control que obligue a detenerse y esperar. La autonomía tiene sentido cuando un error es poco costoso, reversible y fácil de detectar a posteriori: ejecutar una batería de pruebas, aplicar un formateador, hacer una refactorización que ya sigue una especificación y un patrón aprobados o realizar cualquier cambio que una comprobación de CI detectaría igualmente si se colara.
Poner un punto de control en estos pasos no añade seguridad. Añade una fricción que os acostumbra a dejar de prestar atención, que es exactamente lo que me pasó a mí.
Cuándo insistir en detenerlo
Los pasos que merecen un punto de control real son aquellos en los que equivocarse sale caro, es difícil de revertir o resulta difícil de detectar más adelante. Aprobar una especificación antes de implementarla deja fijados sus supuestos. También merecen una pausa los cambios que afectan a datos de producción, cualquier trabajo que estéis a punto de presentar como terminado a otra persona y las decisiones de arquitectura en las que se apoyará el trabajo posterior.
La regla que aplico es sencilla: multiplicad el coste de equivocaros por lo tarde que descubriríais el error. Si cualquiera de los dos factores es alto, merece un punto de control real. Si ambos son bajos, el punto de control es totalmente inútil.
Qué significa «revisar de verdad»
Esta es la prueba que hago ahora antes de aprobar nada: ¿puedo explicar en una frase por qué este resultado concreto es correcto? No basta con decir «parece que está bien»; necesito saber por qué cumple lo que se pedía.
Si no puedo formular esa frase, no estoy revisando, sino limitándome a dar el visto bueno. Normalmente, eso indica que el punto de control está en el lugar equivocado, no que yo deba esforzarme más: o el paso no merece ningún punto de control o agrupa demasiadas cosas como para revisarlas de verdad en una sola pasada.
Pocos puntos de control tomados en serio son mejores que muchos ignorados
Cuando algo sale mal, el primer impulso suele ser añadir otro paso de aprobación. Normalmente, esa no es la solución. Cuantos más puntos de control hay, más se dispersa vuestra atención, y esa falta de atención es precisamente lo que convierte un punto de control en algo prescindible.
La mejor solución es tener menos puntos de control y colocarlos bien: allí donde equivocarse tiene un coste real. Y hay que dar a cada uno la atención que merece, en lugar de responder con un clic sin pensar. Agrupad las aprobaciones triviales u omitidlas por completo. Reservad la revisión minuciosa para los momentos en los que realmente puede cambiar el resultado.
Conclusión
El objetivo nunca fue que el agente decidiera en mi lugar. El objetivo es que trabaje dentro de un sistema en el que yo siga controlando las decisiones que de verdad importan y cuyos puntos de control reflejen con honestidad cuáles son esas decisiones.
Un pipeline en el que interviene una persona en cada paso no es necesariamente más seguro que otro con menos puntos de control, pero mejor definidos. Solo lo es si esa persona está prestando atención de verdad.
En el próximo artículo de esta serie hablaré de lo que ocurre cuando esa disciplina se relaja: Code Slop and AI-Generated Technical Debt — cómo reconocer un resultado que superó todos los puntos de control y que, aun así, no era realmente bueno.
Hasta entonces, la pregunta que merece la pena hacerse sobre vuestra propia configuración no es:
¿Tengo una persona en el bucle?
Es:
La última vez que aprobé algo, ¿podría haber explicado por qué estaba bien?
Si habéis encontrado una forma de colocar los puntos de control que de verdad os funciona, me gustaría saber dónde los ponéis. No dudéis en escribirme.