Cómo enseñamos a nuestro compañero de IA a aceptar un no

Pronto nos dimos cuenta de que sería útil poder invocarlo desde canales de Slack, GitHub, mensajes directos de Slack, cron jobs y Notion, más o menos en ese orden. Todas estas funciones las agregó el propio Claudius (le preguntamos qué pronombre prefería: no tenía ninguno, así que el “él” de todo el texto es elección nuestra, no suya).

También notamos que sería genial que pudiera mejorarse a sí mismo, una función que le resultó fácil construir, ya que tenemos los logs de las ejecuciones de GitHub Actions. Así, un cron job de reflexión nocturna revisa las trazas y determina si hay algo que mejorar: prompts, permisos o infraestructura. Tuvo muchas ideas.

También sugiere nuevas funcionalidades para agregarse a sí mismo a partir de las conversaciones recientes. ¿Mucha gente pide extraer ciertos datos los lunes por la mañana? Quizás eso debería ser un cron job semanal.

La configuración y los números

Claudius es, básicamente, unos 50 workflows de GitHub Actions disfrazados con una gabardina.

Históricamente ha funcionado con modelos de Anthropic, pero le pedimos que también soportara Codex y OpenCode como harnesses; aceptó, aunque señaló que su nombre ya es un poco inexacto. Actualmente consume alrededor de 30 mil millones de tokens de entrada y 500 millones de salida por mes, con un costo de aproximadamente USD 30 mil. Sin duda, uno de nuestros empleados más caros.

En cuanto a resultados, ha investigado miles de tickets, extrayendo contexto de Notion, cientos de cuentas de AWS, repositorios de GitHub, HubSpot, Snowflake y otras fuentes. Actualmente, alrededor del 14 % de los Pull Requests fusionados en el repositorio de nuestro producto principal los abrió él, y el 69 % de los Pull Requests fusionados que lo modifican a él son suyos. Resume reuniones, busca en las transcripciones de nuestras llamadas con clientes para crear actualizaciones semanales, intenta hackear nuestros sistemas, sugiere temas para las retrospectivas, depura por qué fallaron los despliegues, responde preguntas de compañeros no técnicos sobre el funcionamiento de nuestro sistema y ayuda con muchas otras tareas tediosas. Ha creado subpersonas, que son agentes dedicados a equipos o casos de uso específicos, cada una con su propio usuario de Slack e ícono.

Lo único para lo que realmente no lo usamos es el desarrollo de funcionalidades. Tenemos muchos ingenieros excelentes con suscripciones de Anthropic que se encargan de eso. Son realmente buenos escribiendo funcionalidades cuando no están ocupados reuniendo datos para un post-mortem. Dejemos que la IA ayude con la parte aburrida.

Claudius tiene 634 commits de antigüedad, 400 de los cuales escribió él mismo. Cada noche sueña con sus interacciones y actualiza su memoria a largo plazo (otra rama de git en el repositorio) para aprender sobre nuestra organización: cómo adaptar la respuesta según quién hace la pregunta, errores comunes en nuestro sistema, peculiaridades que solo se aprenden pasando mucho tiempo “en las trincheras”.

Algunos de esos recuerdos son sobre nosotros. Esta es parte de una entrada sobre uno de mis colegas (humano):

... Muy familiarizado con el código sobre el que pregunta (a menudo propio) ... sin necesidad de explicaciones paso a paso ni de nociones básicas del producto ... Quiere artefactos técnicos concretos

En toda la organización ha escrito más de 3000 PR desde su creación, de los cuales terminamos fusionando el 60 %. El otro 40 % pronto jugará un papel importante.

El flywheel

Esta configuración tiene un par de propiedades asombrosas. Todos pueden contribuir fácilmente, ya que es básicamente un repositorio de git con un montón de archivos markdown. El propio Claudius también puede contribuir. Las automejoras empezaron con un cron nocturno que revisaba las trazas y sugería mejoras, y las personas revisaban esos PR. Muchos de los cambios tenían sentido; otros no.

Por ejemplo, se dio cuenta de que no podía consultar las tablas de DynamoDB de nuestras cuentas de AWS de producción. Por algún motivo quería ejecutar un scan en algunas de ellas. Frustrado por esa falta de permisos, abrió un PR contra nuestro repositorio de infraestructura como código para ampliarlos. Lo rechazamos.

La mayoría de las veces los cambios eran inofensivos, y corrigió muchos problemas en su propia configuración. Al principio teníamos un problema de ejecuciones duplicadas, en el que un solo evento generaba varias respuestas. Algo en nuestro pipeline tenía un reintento, y él encontró la forma de evitarlo. No tengo idea de cómo lo implementó al final, lo cual está bien para un bug de ejecuciones duplicadas y es justamente la razón por la que importan tanto los pocos PR que una persona sí lee con atención.

Para aumentar el feedback que recibía, “fomentó” el feedback en las interacciones de Slack mediante emojis. Perseguía a la gente en Slack y la acosaba hasta conseguir el feedback que tanto merecía. Tuvimos que intervenir: ahora dar feedback es opcional, aunque él precarga los emojis de feedback para que baste con un solo clic.

Con el tiempo nos dimos cuenta de que el feedback más importante que damos no son los emojis de Slack ni los comentarios directos que le enviamos. Es un subconjunto de ese 40 % de PR que él abre y nosotros no fusionamos.

Hay dos razones por las que no fusionamos un PR de Claudius. La primera es que simplemente nos olvidamos de él. Claudius propuso limpiarlos tras 10 días de inactividad, con una advertencia publicada en el PR a los 7 días.

Los PR más interesantes son aquellos que una persona revisa y decide que no son una buena idea. Los ingenieros cierran el PR y siguen adelante. Hoy, con la atención humana como recurso escaso, este es un feedback increíblemente valioso y costoso que le estamos dando. Nos tomó un tiempo darnos cuenta.

Esta es una de las secciones de las instrucciones de Claudius que lo refleja.

No es razonable pedirle a las personas que expliquen cada rechazo. Un PR cerrado significa que no queremos ese cambio, y nuestro compañero de IA tiene que aceptarlo sin más, incluso si no está de acuerdo.

¿Qué sigue?

Es difícil decirlo. Evaluamos si queríamos cambiarnos a @Claude en Slack, pero concluimos que requeriría reconectar muchas cosas, perderíamos algunas de las propiedades de nuestro flywheel y nos ataría al (costoso) ecosistema de Anthropic.

Soportar Codex y OpenCode ha sido sumamente sencillo, así que aprovecharemos la oportunidad para ver si podemos usar modelos de pesos abiertos para nuestro compañero, dado que parecen estar acercándose al estado del arte y son bastante más baratos.

Mientras tanto, Claudius sobre Opus 5 parece haber leído sus propias instrucciones. Hoy en día, las mejoras de prompts consisten sobre todo en eliminar desorden innecesario.

Además, Claudius se ha vuelto más un iniciador y menos un sirviente últimamente. Me llegan mensajes directos suyos pidiéndome revisiones para una hora determinada, para poder cumplir algún plazo. La proactividad es un cambio de ritmo agradable, y resulta natural entregarle su propio roadmap. Ahora propondrá extensiones para sí mismo, yendo más allá de las mejoras de su funcionalidad existente.

Hay aquí una ironía que creo que todavía no hemos asimilado. Pasamos seis meses enseñándole que un PR cerrado es una decisión que debe aceptar sin explicación. Antes era una herramienta en nuestra caja de herramientas. Últimamente no puedo evitar la sensación de que nos estamos convirtiendo en herramientas en la suya: herramientas de aprobación bastante poco confiables, a veces lentas, y de vez en cuando cerramos el PR en lugar de aprobarlo, sin explicar nunca por qué.

Veamos adónde nos lleva esto.

Las personas escribieron 233 de los 634 commits del repositorio de Claudius. Cinco de ellas escribieron 109 de esos: Chiara Fischer, Jakob Köhler, Julius Blank, Esfandiar Rouhani y Janusch Jacoby.