Lo que quedó después de dos años de IA en mi equipo

Un producto de video en vivo, un equipo de ingenieros y dos años metiendo IA en el flujo de trabajo. Las prácticas que aguantaron producción y las que no.

Teníamos cuarenta feature flags para sacar de un proveedor y llevar a otro. Trabajo tedioso, de esos que se comen un sprint y no le enseñan nada a nadie. Hice una a mano, con calma, y le pasé el diff más las treinta y nueve restantes a un agente.

Terminó en una tarde. Cada cambio se podía revisar, la mayoría estaba bien, y los cuatro que estaban mal fallaron de la misma manera, así que fueron fáciles de encontrar. Cuando alguien me pregunta si esto sirve, esa migración es lo más concreto que tengo para mostrar.

Dirijo el equipo detrás de un aula online. Alumno y tutor se encuentran por video a la hora acordada, miles de veces por día, y una falla ahí significa clase interrumpida, no página recargada. Esa restricción moldea todo lo que sigue. No podemos subir un experimento y ver qué pasa.

La forma de tarea que un agente sí resuelve

Acotada, mecánica, verificable. La migración de flags era las tres cosas. Cambiar la herramienta de tests por otra también, y actualizar un SDK en todo el código.

Definir el alcance es la habilidad entera. “Migrá estas cuarenta flags, mirá esta hecha como corresponde” rinde una tarde productiva. “Ordená nuestras feature flags” rinde un resultado confuso que cuesta más revisar de lo que habría costado escribir. La diferencia es si alguien ya tomó todas las decisiones de criterio y quedó solo tipear.

Revisión, no generación

La ganancia real apareció en la revisión.

Pasamos el código, propio y generado, por un agente con instrucción adversarial antes de que lo mire una persona. Encontrá la entrada que rompe esto. Señalá el caso que el autor no consideró. Agarra una clase específica de bug de borde por centavos, y cuando el humano abre el diff los problemas obvios ya no están, así que su atención se va al diseño.

Lo segundo fue el conocimiento interno. Las decisiones del equipo vivían en hilos de Slack, que es donde las decisiones se van a morir. Empezamos a volcar eso en una wiki que nuestras herramientas pueden consultar, así cuando alguien nuevo pregunta por qué el grabador de sesión funciona de esa manera, la respuesta viene con enlaces en vez de arqueología. Nadie confió hasta que hubo citas. Después de eso, lo usó todo el mundo.

Lo que no quedó

El autocompletado como evento principal. La sugerencia línea por línea está bien y optimiza la parte del trabajo que nunca fue lenta. Tipear no era el cuello de botella.

Delegar sin alcance, siempre. Nuestros fracasos tienen la misma forma: tarea ambigua, ninguna etapa de verificación, y un resultado lo bastante seguro de sí como para parecer competente. Un agente equivocado no avisa. Entrega algo plausible, y lo plausible cuesta más desarmar que lo roto.

Comprar licencias y anunciarlas en el canal. Nada cambió en mi equipo hasta que cambió el proceso alrededor de las herramientas. La adopción llegó cuando “listo para revisión” pasó a incluir la pasada adversarial, y cuando los tickets de migración empezaron a escribirse con la forma que un agente puede tomar.

Lo que le digo a otros equipos

Elegí el modelo según la tarea. Modelos de punta para arquitectura y depuración, más baratos para transformación en volumen. Parece control de costos y lo es. También te obliga a decir qué implica la tarea antes de delegarla, y la mitad de las veces ahí te das cuenta de que estaba mal definida.

Los equipos que consiguen retorno acumulado no son los que escriben los mejores prompts. Son los que reorganizaron la mitad aburrida del proceso para que la sostenga una máquina, y gastaron la atención liberada en decidir qué construir. Esa reorganización es más lenta que comprar licencias, y es la única versión que vi durar.