Nuestros compañeros de equipo de IA se unieron a nuestra retro

Desarrollamos software para retrospectivas, por lo que el tablero de retrospectiva de nuestro equipo es un lugar bastante habitual: «Iniciar», «Detener», una columna de acciones pendientes y las discusiones habituales de los viernes. La semana pasada se incorporaron algunos colaboradores nuevos. Seis de las fichas no las había redactado ningún ser humano, sino que las habían presentado los agentes de IA con los que trabajamos a diario, resumiendo los problemas surgidos en sus propias sesiones de trabajo con nosotros.

Seamos precisos sobre de qué se trata, ya que la formulación es importante. No se trata de una IA «integrada» en la reunión: no hay ningún bot que modere la reunión, ni ninguna función de IA que resuma las fichas de los participantes. Los agentes que realizan el trabajo real en nuestro equipo (los que escriben código, editan contenidos y llevan a cabo auditorías) acudieron a la ceremonia como lo haría cualquier compañero de equipo: con su propio relato de cómo había ido el trabajo. Participantes, no moderadores; la reunión siguió siendo nuestra.

Tampoco se trataba de una maniobra publicitaria. La idea surgió en una de nuestras propias reuniones retrospectivas: alguien comentó que la documentación de incorporación estaba desactualizada (otra vez) y otra persona mencionó que un agente les había señalado precisamente eso a mitad de una sesión esa misma mañana, de pasada, antes de que el contexto desapareciera al desplazarse la pantalla. El agente lo sabía; nada en su entorno le indicaba que mereciera la pena conservar esa observación. Por ello, durante las últimas semanas hemos estado llevando a cabo un experimento con nosotros mismos: la práctica es la que describimos en cómo recabar comentarios de sus agentes de IA. Al final de cada sesión de trabajo sustancial asistida por IA, el agente redacta una breve entrada estructurada para la retrospectiva sobre su propio trabajo: qué salió bien, qué se alargó, cuánto costó cada retraso, una etiqueta de causa raíz por elemento y una solución propuesta. Las entradas se acumulan en los repositorios en los que se ha desarrollado el trabajo. Cuando se han acumulado suficientes, un proceso complementario las lee todas y archiva los patrones recurrentes directamente en nuestro tablero de retrospectiva, añadiéndoles un prefijo[AI retro]para que nadie confunda al autor.

A continuación les presentamos lo que nuestros nuevos compañeros de equipo han dicho sobre su experiencia trabajando con nosotros.

Lo que descubrieron

El titular con el que abrieron el artículo se refería a ellos mismos. La tarjeta principal decía: «Empiece por verificar antes de actuar: los errores de ejecución de los agentes representan el 38 % de los problemas (el doble que la siguiente causa); el coste recurrente radica en afirmar una causa, forzar la ejecución o reorientar el objetivo antes de comprobar el código en producción, los datos o el estado de la rama». La principal fuente de fricción en nuestro trabajo asistido por IA, según el propio análisis de los agentes, eran los propios agentes, concretamente el hábito de actuar basándose en un estado supuesto del mundo en lugar de comprobar primero el estado real. Apreciamos esa honestidad por parte de cualquier compañero.

El tema más importante, relacionado con el trabajo en equipo, traspasó todos los límites que una persona no traspasaría. Los errores relacionados con Git y el estado de las ramas en el trabajo con agentes simultáneos se pusieron de manifiesto en ocho sesiones repartidas entre dos repositorios: bases obsoletas, destinos de ramas no leídos, un agente que movió una rama que otro estaba utilizando y una solicitud de incorporación de cambios (PR) redirigida sin verificación. Ninguna de estas sesiones por sí sola habría ocupado un puesto ni remotamente cercano a los primeros; cada caso supuso un encogimiento de hombros y unos pocos minutos perdidos. Sin embargo, al considerarlas en conjunto a lo largo de ocho sesiones, resultaba imposible pasarlas por alto.

Nos hemos dado cuenta de que estábamos realizando envíos basándonos en comprobaciones incompletas. En cuatro sesiones se publicó o fusionó algo tras una comprobación más limitada que la que realmente ejecuta la integración continua (CI): una simple comprobación de tipos en lugar de la compilación completa, y pruebas específicas en lugar de la suite de pruebas. Dos veces en un mismo repositorio, el mismo día.

Y las tarjetas más incómodas no tenían nada que ver con el trabajo en sí, sino con el seguimiento. Una de ellas señalaba que una discrepancia entre las pruebas y las especificaciones había permitido que un fallo reproducible pasara desapercibido tras dos rondas de revisión, y que el documento de corrección se había propuesto el día anterior y nunca se había redactado. En otra se señalaba que ese mismo estancamiento en la herramienta ya había supuesto el coste de dos sesiones, «sin que se hubiera implementado ninguna corrección definitiva entre ambas». Una tercera: el mismo patrón de desviación de los requisitos, tres sesiones consecutivas, «en cada una de las cuales se señalaba que se repetía lo ocurrido en la anterior». Resulta que el agente recuerda lo que dijimos que haríamos.

Las dos cosas que merecen la pena contemplar

En primer lugar: nada de esto era visible para ninguna persona en concreto. No se trata de una falta de atención; es la propia naturaleza del problema. La fricción en las sesiones de IA es crónica y de menor importancia, por lo que nunca da lugar a un análisis a posteriori y desaparece cuando finaliza la sesión. Cada uno de nosotros había asimilado su parte y había seguido adelante. La clasificación (este patrón es el que más le cuesta al equipo) solo existe en la vista agregada, y la vista agregada solo existe porque las entradas eran comparables: mismo esquema, mismo pequeño conjunto de etiquetas de causas raíz, cada afirmación citando una sesión con fecha. Esta es la idea de la agregación que constituye el núcleo de la guía que acompaña a esta publicación, y es la parte que más deseábamos poner a prueba en nosotros mismos.

En segundo lugar: los agentes no culparon a nadie, ni siquiera a sí mismos, de forma imprecisa. Las entradas siguen dos reglas que resultaron ser más importantes de lo que esperábamos. Los elementos de fricción describen la discrepancia y lo que costó, nunca quién la provocó: sin nombres, sin «el informe de X». Y «el agente cometió un error» es una etiqueta residual, que solo se utiliza cuando los datos introducidos eran realmente adecuados, que es precisamente por lo que la cifra del 38 % nos llamó la atención: superó esa exigencia. El resultado se leía como una buena contribución retrospectiva: específica, con citas de pruebas, sin culpar a nadie y ligeramente embarazosa para todos por igual.

Lo que se decidió en la sala

Decidimos poner en práctica las tres medidas propuestas, cada una en el ámbito que se indicaba. La norma «confirmar el estado de la rama activa y de la solicitud de incorporación de cambios antes de realizar modificaciones» se incluirá en la documentación del agente de cada repositorio, lo que supone una corrección en la documentación relacionada con el tema de las ocho sesiones. El gancho «pre-push», que ejecuta la compilación y las pruebas equivalentes a la integración continua (CI), se incorporará a los repositorios que se vieron afectados por comprobaciones parciales; se trata de una corrección del entorno, de modo que no dependa de que nadie lo recuerde. Y el documento sobre la convención de pruebas que fue «señalado el día anterior y nunca se redactó» se está redactando actualmente, utilizando el fallo que se pasó por alto como ejemplo práctico.

Sin grandes reorganizaciones ni nuevos procesos: tres correcciones breves con sus responsables. La modestia es deliberada: toda la apuesta de esta práctica radica en que las pequeñas correcciones, dirigidas al nivel adecuado y comprobadas efectivamente en el siguiente ciclo, se acumulan. Si estas tres se mantienen es precisamente lo que nos dirá la comprobación de adopción del próximo informe; el mismo mecanismo que nos detectó la última vez será el que nos evalúe al respecto.

Aún es pronto, y lo decimos sin rodeos. Pero salimos de esa sesión de retro más interesados en nuestros propios hábitos de trabajo de lo que lo habíamos estado en mucho tiempo —y sintiéndonos un poco competitivos con un compañero que ni siquiera se cansa—.

Las notas a pie de página sinceras

Este es nuestro primer resumen sintético; se basa en datos de semanas, no de meses, por lo que consideramos las clasificaciones como una asignación de atención, no como una contabilidad. Los costes que figuran en las entradas son estimaciones propias del agente y están señalados como tales. Las afirmaciones más ambiciosas de este estudio (que las etiquetas se mantengan coherentes entre los evaluadores, que la línea de tendencia se curve realmente tras la aplicación de las correcciones) son experimentos que estamos llevando a cabo, más que suposiciones que estemos formulando, y publicaremos sus resultados sea cual sea el resultado.

Pero el beneficio principal ya se había hecho patente: un conjunto de patrones que nadie del equipo podía detectar por sí solo, clasificados, documentados y presentados en la reunión en la que ya se encontraban las personas encargadas de las correcciones. El Feedback Flywheel de Rahul Garg incluye en su lista de cadencia «un punto del orden del día en la retrospectiva de sprint actual: ¿qué ha funcionado con la IA en este sprint?». Ahora podemos afirmar que dicho punto resulta considerablemente más interesante cuando sus compañeros de equipo de IA presentan sus propios puntos.

Pruébelo con su propio equipo

Todo lo que hemos utilizado es gratuito y está documentado en la guía: cómo funcionan las entradas, las etiquetas de causas raíz, las reglas de «nunca registrar» (nada de secretos, nada de datos de clientes y nunca nada que identifique a una persona), así como el punto del orden del día de 15 minutos para el moderador, además de las dos habilidades que permiten llevar a cabo las fases de recopilación y síntesis. Funciona con cualquier agente compatible y un archivo de texto; nuestro producto es un lugar donde se pueden almacenar los resultados, no un requisito.

En el próximo ciclo, la comprobación de la aprobación del pliego de condiciones nos indicará si esta vez hemos redactado realmente ese documento de pruebas. Se lo comunicaremos. Y ellos también lo harán.

¿Lo ha probado? ¿No está de acuerdo con ello? Hablamos en serio cuando decimos que queremos que nos lo rebatan: ai-discussion@TeamRetro.com.