El QA de Yandex delegó en un agente de IA checklists y autotests por 15 000 ₽ al mes

Toda QA-team tiene una rutina que a nadie le gusta: abrir el ticket, entender qué ha cambiado en el PR, esbozar un checklist, escribir los casos, automatizarlos y, después, arreglar los tests que fallan en CI. El equipo de testing de la página principal de Yandex decidió delegar buena parte de ese trabajo en un agente y contó en Habr cómo funciona, cuánto cuesta y dónde se dio algún golpe.

Del plugin del IDE al evento en Tracker

La primera versión vivía en Roo Code para VS Code. El ingeniero abría el editor, elegía un modo y escribía «haz un checklist para la tarea»; el agente iba por su cuenta a Tracker, leía el PR y entregaba el resultado. Funcionaba, pero solo lo usaban quienes ya sabían automatizar. Al resto le habría tocado montar el entorno y comprobar accesos, es decir, cambiar un trabajo manual por otro.

Por eso el agente pasó a funcionar por eventos. Cuando una tarea cambia al estado «Se puede probar», Tracker envía un HTTP POST a CI, este levanta un contenedor con el agente y el tester abre el ticket con el checklist ya listo. Hay un segundo disparador: una palabra clave en un comentario, útil para regenerar el resultado tras actualizar el PR. Con los autotests el esquema es parecido, pero el agente primero pide confirmación al ingeniero y solo después crea el PR. Es una protección contra el spam.

Subagentes en lugar de un prompt grande

La primera versión era un monolito: un solo agente leía la tarea, analizaba el PR, redactaba el checklist y lo publicaba. Era lento y caro, porque todo el contexto viajaba en cada petición. Ahora el proceso se divide en pasos: recopilación de contexto, análisis del PR, generación y publicación. Entre ellos se pasa un JSON validable.

La ventaja es práctica. Cada paso ve solo el contexto que necesita, cada uno tiene sus propios logs y, si uno falla, se reinicia un único job, no todo el pipeline.

Con los autotests no bastaron tres pasos. Por motivos de seguridad se prohibió al agente usar un navegador real, así que los localizadores del primer borrador salían imprecisos. La solución: ejecutar el test en CI (esto ya no es un LLM), darle el informe al agente para que corrija él mismo los localizadores y ejecutar de nuevo. El resultado son seis pasos, dos de los cuales son ejecuciones normales sin modelo.

Hubo un detalle menor que irritaba a muchos: el PR lo crea un robot, no un ingeniero. Para que una persona pueda ajustar los localizadores de inmediato, el login del autor se arrastra a lo largo de toda la cadena y, al final, el robot lo añade como coautor y propietario de la rama.

Skills y banco de memoria

El conocimiento del agente está en dos lugares, ambos en el repositorio. Un skill es una instrucción paso a paso, como para un junior: qué hacer, qué plantillas usar, cómo comprobar el resultado. Por ejemplo, un test con mocks va a integration, uno sin mocks va a e2e, y las comprobaciones que no figuran en el caso no se inventan. El equipo tiene skills separados para recopilar contexto, analizar el PR, exportar casos desde el TMS, escribir el test, revisar código y reparar fallos. Cuanto más acotado es el skill, más barato y estable resulta el paso.

El banco de memoria responde a la pregunta «cómo se hace aquí»: un conjunto de archivos Markdown con el stack, los fixtures, los antipatrones y los fallos típicos. La regla es simple: se anota solo lo que servirá en tareas futuras, sin detalles de un ticket concreto y sin duplicados. El banco también cuesta tokens, así que una guía corta y actualizada es mejor que doscientas páginas de documentos obsoletos.

Cuánto costó

Para el equipo de cinco personas se asignaron 15 000 ₽ al mes. Los gastos por mes fueron 11 600, 9 300, 14 600 y 15 000 ₽. En el cuarto mes el límite se agotó por completo. Por eso el equipo calcula por separado el coste de cada paso: registra los tokens de entrada y de salida y vigila adónde va el dinero. El final de la sección de conclusiones se corta en el texto original, de modo que los detalles sobre el volumen de peticiones quedan fuera.

Qué llevarse

El esquema no depende de Yandex ni del modelo. Para replicarlo hacen falta un CI con disparador externo, una cuenta de robot y un runtime de agentes. El papel de Tracker puede asumirlo Jira Automation o Linear Webhooks; el del tasklet, GitHub Actions o GitLab CI; y de la orquestación se encargarán Claude Code, OpenAI Agents SDK o LangGraph.

Cinco reglas del artículo: fijar la revisión del código, guardar las instrucciones junto al código, dividir el trabajo en pasos con JSON, contar los tokens por paso y limitar con dureza los accesos del agente.

Las limitaciones también son claras. El agente entrega un borrador, no una solución terminada. Los escenarios complejos, los casos límite y la lógica de negocio los revisa una persona, que además decide si se hace merge del PR. Sin acceso a la página real, los tests pasan por un ciclo adicional de autocorrección. Es una forma económica de preparar la base para el tester, pero no sustituye al tester.