Wildberries mostró cómo un agente local de AI empezó a escribir pruebas unitarias para Android

Wildberries & Russ publicó un análisis práctico de cómo un tech lead del equipo Android transformó un LLM local de un juguete curioso en un asistente funcional para unit tests. El experimento tardó aproximadamente dos meses: inicialmente la IA cometía errores consistentes y alucinaba, pero después de reconfigurar comenzó a producir tests compilables e incluso a corregir comentarios de revisión de código por su cuenta.

Del escepticismo a la tarea

El autor describe un camino familiar para muchos desarrolladores: desde el entusiasmo inicial con ChatGPT en 2023 hasta el agotamiento del hype y las dudas sobre si las redes neuronales realmente aportan ganancias de productividad en el desarrollo de productos a gran escala. Tras estudiar charlas, artículos y casos de uso, llegó a una conclusión más realista: en las bases de código existentes, normalmente no se trata de reemplazar el equipo, sino de ganancias de eficiencia aproximadamente del 10–20%, si la herramienta está correctamente integrada en el proceso.

"La diferencia entre un junior y un senior en el uso de redes

neuronales es de 3–4 meses."

Desde esta perspectiva, el autor eligió no una meta abstracta de "implementar IA", sino una tarea muy específica y poco popular: escribir unit tests para un proyecto Android en Kotlin. Una limitación importante: solo se podía utilizar un LLM local o un modelo en un entorno corporativo. Debido a los requisitos de seguridad, se descartaron los escenarios en la nube, donde el código del proyecto se indexa y se envía a servidores externos, por lo que se apostó por herramientas compatibles con infraestructura local.

Por qué no funcionó

El primer intento parecía lógico pero fracasó. El desarrollador armó un prompt de sistema grande, describió el proyecto en detalle, añadió un archivo markdown con instrucciones para el agente y una plantilla de prompt para tests, esperando que el máximo contexto resultaría en máxima calidad. En la práctica, el modelo local escribió un test para un mapper pequeño en aproximadamente 20 minutos, y produjo no un resultado funcional, sino un conjunto de avisos, errores de importación y código no compilable. Cuanto mayor era la clase, peores eran las alucinaciones y peor entendía el modelo qué herramientas de testing necesitaba aplicar. Los principales problemas de la primera iteración fueron:

• instrucciones demasiado detalladas sobrecargaban el modelo e ignoraba requisitos importantes;
• la salida de Gradle después de compilar y ejecutar tests atascaba el contexto y empeoraba las respuestas posteriores;
• ejecutar múltiples sesiones en paralelo no aceleraba el trabajo, solo multiplicaba el número de tests rotos;
• intentar probar ViewModels grandes inmediatamente terminaba en pérdida de enfoque y soluciones ficticias.

El refinamiento manual de tales resultados tampoco salvaba la situación. Corregir un test generado frecuentemente llevaba más tiempo que escribirlo desde cero. En definitiva, la primera fase produjo una conclusión útil pero desagradable: un LLM por sí solo no se convierte en un asistente confiable simplemente porque recibió un prompt largo y acceso al código. Lo que se necesitaba era una estructura de contexto diferente, filtrado de ruido y una división más clara del trabajo dentro del sistema de agentes.

Lo que realmente funcionó

En la segunda iteración, el autor cambió no solo el modelo sino el enfoque en sí. Añadió RAG con un índice del proyecto para acelerar la búsqueda de archivos relevantes y configuró el procesamiento de la salida de Gradle para que solo información útil entrara en el prompt, no todo el ruido técnico de compilación. Después de eso, sobre OpenCode se construyó una estructura de un agente principal, subagentos y skills separadas.

La idea es simple: en lugar de una instrucción gigante, el modelo recibe reglas cortas para cada etapa específica de trabajo. El sistema de generación de tests fue dividido en tres roles: un planificador analizaba la clase y recogía tareas con casos de test, un escritor de tests implementaba las verificaciones propriamente dichas, y un revisor comprobaba compilación, completitud de cobertura y conformidad de estilo. Fue solo después de tal descomposición que el modelo produjo por primera vez un test compilable listo para usar en un mapper pequeño.

El merge request pasó revisión con un comentario de estilo, ese comentario se añadió a la skill correspondiente, y la corrección fue ejecutada por el modelo nuevamente. En hardware local, un test aún tardaba aproximadamente 19 minutos, pero esto ya era útil en el ritmo real de trabajo: el agente podía escribir tests mientras el desarrollador estaba en una llamada. Más tarde, después de ejecutar en infraestructura más potente, el tiempo se redujo a aproximadamente 5–10 minutos por test.

Lo que esto significa

El caso Wildberries demuestra que un agente de IA corporativo comienza a entregar valor no después de "mágicamente" conectar un modelo, sino después de configuración de ingeniería: con un índice de proyecto, filtrado de ruido, roles y verificación obligatoria de resultados. El reemplazo completo de desarrolladores está lejos de ocurrir, pero tareas rutinarias como unit tests o pequeños ajustes ya pueden delegarse a la máquina—especialmente donde la contención local y el control del código son importantes.