Wildberries a montré comment un agent local d’AI s’est mis à écrire des tests unitaires pour Android

Wildberries & Russ a publié une analyse pratique de la façon dont un tech lead de l'équipe Android a transformé un LLM local d'une curiosité intéressante en un assistant fonctionnel pour les unit tests. L'expérience a duré environ deux mois : initialement, l'IA commettait des erreurs systématiques et hallucina, mais après reconfiguration, elle a commencé à produire des tests compilables et même à corriger les commentaires d'examen du code d'elle-même.

Du scepticisme à la tâche

L'auteur décrit un parcours familier à de nombreux développeurs : du premier enthousiasme autour de ChatGPT en 2023 à la fatigue du battage médiatique et aux doutes quant à savoir si les réseaux de neurones apportent vraiment des gains de productivité dans le développement de produits à grande échelle. Après avoir étudié des présentations, des articles et des cas d'usage, il est arrivé à une conclusion plus réaliste : dans les bases de code existantes, il ne s'agit généralement pas de remplacer l'équipe, mais de gains d'efficacité d'environ 10–20%, si l'outil est correctement intégré au processus.

«

La différence entre un junior et un senior dans l'utilisation des réseaux de neurones est de 3–4 mois. »

De ce point de vue, l'auteur a choisi non pas un objectif abstrait d'« implémenter l'IA », mais une tâche très spécifique et impopulaire : écrire des unit tests pour un projet Android en Kotlin. Une contrainte importante : seul un LLM local ou un modèle dans un environnement d'entreprise pouvait être utilisé. En raison des exigences de sécurité, les scénarios en nuage ont été écartés, où le code du projet est indexé et envoyé à des serveurs externes, l'enjeu a donc été placé sur des outils compatibles avec l'infrastructure locale.

Pourquoi cela n'a pas fonctionné

La première tentative semblait logique mais a échoué. Le développeur a assemblé un grand prompt système, décrit le projet en détail, ajouté un fichier markdown avec les instructions pour l'agent et un modèle de prompt pour les tests, en supposant que le contexte maximum produirait une qualité maximale. En pratique, le modèle local a écrit un test pour un petit mapper en environ 20 minutes et a produit non pas un résultat fonctionnel, mais un ensemble d'avertissements, d'erreurs d'importation et de code non compilable. Plus la classe était grande, plus les hallucinations s'aggravaient et plus le modèle comprenait mal quels outils de test appliquer. Les principaux problèmes de la première itération étaient :

• les instructions trop détaillées surchargeaient le modèle, qui ignorait les exigences importantes ;
• la sortie de Gradle après la compilation et l'exécution des tests encrassait le contexte et dégradait les réponses ultérieures ;
• l'exécution de plusieurs sessions en parallèle n'accélérait pas le travail, mais multipliait simplement le nombre de tests cassés ;
• les tentatives de tester immédiatement de grands ViewModels se terminaient par une perte de concentration et des solutions fictives.

Le raffinement manuel de tels résultats ne sauvait pas non plus la situation. Corriger un test généré prenait souvent plus de temps que de l'écrire de zéro. En fin de compte, la première phase a produit une conclusion utile mais désagréable : un LLM ne devient pas un assistant fiable simplement parce qu'on lui a donné un long prompt et l'accès au code. Ce qui était nécessaire, c'était une structure de contexte différente, un filtrage du bruit et une division plus claire du travail au sein du système d'agents.

Ce qui a réellement fonctionné

Lors de la deuxième itération, l'auteur a changé non seulement le modèle, mais aussi l'approche elle-même. Il a ajouté RAG avec un index du projet pour accélérer la recherche de fichiers pertinents et configuré le traitement de la sortie de Gradle de sorte que seules les informations utiles entrent dans le prompt, et non tout le bruit technique de la compilation. Après cela, au-dessus d'OpenCode, a été construite une structure d'un agent principal, de sous-agents et de skills séparées.

L'idée est simple : au lieu d'une instruction géante, le modèle reçoit des règles courtes pour chaque étape spécifique du travail. Le système de génération de tests a été divisé en trois rôles : un planificateur analysait la classe et collectait des tâches avec des cas de test, un rédacteur de tests implémentait les vérifications elles-mêmes, et un examinateur vérifiait la compilation, l'exhaustivité de la couverture et la conformité au style. C'est seulement après une telle décomposition que le modèle a produit pour la première fois un test compilable prêt à l'emploi sur un petit mapper.

La demande de fusion a réussi l'examen avec un commentaire de style, ce commentaire a été ajouté à la skill correspondante, et la correction a été exécutée par le modèle à nouveau. Sur du matériel local, un test prenait toujours environ 19 minutes, mais c'était déjà utile dans le rythme de travail réel : l'agent pouvait écrire des tests pendant que le développeur était en appel. Plus tard, après exécution sur une infrastructure plus puissante, le temps a été réduit à environ 5–10 minutes par test.

Ce que cela signifie

Le cas Wildberries démontre qu'un agent d'IA d'entreprise commence à fournir de la valeur non pas après avoir « magiquement » connecté un modèle, mais après une configuration technique : avec un index de projet, un filtrage du bruit, des rôles et une vérification obligatoire des résultats. Le remplacement complet des développeurs est loin de se profiler, mais les tâches routinières comme les unit tests ou les petites corrections peuvent déjà être déléguées à la machine—particulièrement là où le confinement local et le contrôle du code sont importants.