T-Bank enseñó a un agente de IA a escribir tests unitarios de iOS con AGENTS.md y SKILL.md

El equipo de desarrollo iOS de T-Bank describió en Habr cómo enseñó a un agente LLM a escribir tests unitarios al estilo del proyecto: con objetos Mock reales, las utilidades correctas y código que compila a la primera. El autor del artículo, el desarrollador iOS Artem Zhitko, cuenta que ajustar prompts no sirvió de nada. Lo que funcionó fue un sistema de reglas basado en los archivos AGENTS.md y SKILL.md. El anuncio no ofrece cifras, como el porcentaje de tests que compilan o las horas ahorradas; es probable que se queden dentro del artículo completo.

Qué falló en el primer intento

Los tests suelen escribirse al final de una tarea, cuando la lógica ya está lista y queda poca motivación. Es un candidato evidente para delegar en un agente. T-Bank probó a encargárselo a ChatLLM y obtuvo el conjunto típico de defectos:

• el código no compilaba;
• el modelo inventaba objetos Mock que no existen en el proyecto;
• se ignoraban las convenciones de arquitectura del equipo;
• se usaban utilidades de testing distintas de las habituales en la base de código.

Los cuatro puntos tienen una raíz común: el modelo no veía el proyecto por dentro. Sabe cómo son los tests en Swift en general, pero no sabe cómo se llaman vuestros helpers, dónde están los stubs ni qué capa de dependencias se suele sustituir. Por eso rellena los huecos con invenciones verosímiles. En código es el peor escenario: la invención parece convincente y solo falla al compilar.

Reglas en lugar de prompts

El equipo concluyó que la causa era la falta de contexto y no la debilidad del modelo, así que trasladó el conocimiento del proyecto a archivos. AGENTS.md funciona como instrucción general para el agente en el repositorio: estructura, convenciones y prácticas obligatorias. SKILL.md describe una habilidad concreta, aquí la escritura de tests: el orden de los pasos, qué utilidades usar, cómo nombrar los casos y qué se considera un resultado terminado. El anuncio no explica cómo se reparten exactamente las reglas entre los dos archivos.

El cambio principal está en el enfoque. Un prompt vive en la cabeza de alguien o en un chat, y el resultado depende de quién lo escribió y cómo. Un archivo de reglas está en el repositorio, pasa por revisión, tiene control de versiones y funciona igual para todos los desarrolladores. Según el propio autor, la generación de tests deja de ser una petición puntual y se convierte en un proceso de ingeniería reproducible.

Datos clave del anuncio

• Plataforma: iOS, tests unitarios.
• Modelo de partida: ChatLLM; sin contexto, el resultado se consideró inservible.
• Herramientas: AGENTS.md y SKILL.md.
• Tesis del equipo: unas buenas reglas importan más que elegir el modelo más inteligente.
• El anuncio no incluye métricas de calidad ni de ahorro de tiempo.

La tesis sobre las reglas y el modelo conviene leerla con cautela. Es la conclusión de un solo equipo sobre una sola base de código y, por ahora, sin cifras publicadas. Aun así, coincide con lo que muchos observan al trabajar con agentes de código: la calidad suele mejorar al describir el entorno y verificar el resultado, no al cambiar a un modelo más caro.

Cómo aplicarlo en tu equipo

Si quieres replicar el enfoque, empieza por analizar los errores, no por escribir reglas. Reúne entre 10 y 20 tests que el agente generó mal y clasifica las causas: clase inventada, utilidad incorrecta, arquitectura vulnerada. Cada causa que se repite se convierte en una regla concreta.

En AGENTS.md incluye lo que vale para todo el repositorio: la estructura de módulos, las convenciones de nomenclatura y las prohibiciones. En una skill aparte deja el procedimiento específico, por ejemplo la escritura de tests, y añade uno o dos ejemplos de referencia tomados de código real. Enumera de forma explícita los objetos Mock y las utilidades de testing existentes y prohíbe crear otros nuevos sin que se pida. Es la respuesta directa al principal problema que describe el equipo.

Y cierra siempre el ciclo con una verificación: que el agente ejecute la compilación y los tests y corrija los errores por sí mismo. Las reglas reducen las invenciones, pero el compilador sigue siendo el revisor más fiable. Los archivos de reglas deben revisarse como cualquier otro código y actualizarse junto con la arquitectura; de lo contrario, quedan obsoletos enseguida y empiezan a perjudicar.