T-Bank apprend à un agent IA à écrire des tests unitaires iOS avec AGENTS.md et SKILL.md

L'équipe de développement iOS de T-Bank a décrit sur Habr comment elle a appris à un agent LLM à écrire des tests unitaires dans le style du projet : avec de vrais objets Mock, les bons utilitaires et du code qui compile du premier coup. L'auteur du billet, le développeur iOS Artem Jitko, explique que le réglage de prompts n'a pas suffi. Ce qui a fonctionné, c'est un système de règles reposant sur les fichiers AGENTS.md et SKILL.md. L'annonce ne donne aucun chiffre, ni pourcentage de tests qui compilent, ni heures économisées. Ces données figurent sans doute dans l'article complet.

Ce qui a cloché lors de la première tentative

On écrit généralement les tests en fin de tâche, quand la logique est terminée et que la motivation retombe. C'est un candidat évident à la délégation à un agent. T-Bank a confié ce travail à ChatLLM et a obtenu une série de défauts typiques :

• le code ne compilait pas ;
• le modèle inventait des objets Mock qui n'existent pas dans le projet ;
• les conventions d'architecture de l'équipe étaient ignorées ;
• les utilitaires de test employés n'étaient pas ceux que la base de code utilise habituellement.

Ces quatre problèmes ont la même racine : le modèle ne voyait pas le projet de l'intérieur. Il sait à quoi ressemblent des tests Swift en général, mais ignore le nom de vos helpers, l'emplacement des stubs et la couche de dépendances qu'il convient de substituer. Il comble donc les trous par des inventions plausibles. Pour du code, c'est le pire scénario : l'invention paraît convaincante et ne casse qu'à la compilation.

Des règles plutôt que des prompts

L'équipe a conclu que la cause tenait à l'absence de contexte, non à la faiblesse du modèle, et a sorti la connaissance du projet dans des fichiers. AGENTS.md sert d'instruction générale pour l'agent dans le dépôt : structure, conventions, pratiques obligatoires. SKILL.md décrit une compétence précise, ici l'écriture de tests : l'ordre des opérations, les utilitaires à employer, la façon de nommer les cas, ce qui définit un résultat terminé. L'annonce ne précise pas comment les règles sont réparties entre les deux fichiers.

Le vrai changement tient à l'approche elle-même. Un prompt vit dans la tête de quelqu'un ou dans un chat, et le résultat dépend de la personne qui l'a rédigé et de la manière dont elle l'a fait. Un fichier de règles réside dans le dépôt : il est relu, versionné et fonctionne de la même façon pour chaque développeur. Selon l'auteur, la génération de tests passe ainsi d'une requête ponctuelle à un processus d'ingénierie reproductible.

Faits clés de l'annonce

• Plateforme : iOS, tests unitaires.
• Modèle de départ : ChatLLM, dont le résultat sans contexte a été jugé inutilisable.
• Outils : AGENTS.md et SKILL.md.
• Thèse de l'équipe : de bonnes règles comptent plus que le choix du modèle le plus intelligent.
• L'annonce ne fournit aucune métrique de qualité ni de gain de temps.

La thèse sur les règles et le modèle se lit avec une réserve : c'est la conclusion d'une seule équipe sur une seule base de code, pour l'instant sans chiffres publiés. Elle rejoint toutefois ce que beaucoup constatent avec les agents de code : les gains de qualité viennent souvent de la description de l'environnement et de la vérification du résultat, pas du passage à un modèle plus coûteux.

Comment l'appliquer chez vous

Si vous voulez reproduire cette approche, commencez par analyser les erreurs plutôt que par rédiger des règles. Rassemblez 10–20 tests que l'agent a mal générés et classez les causes : classe inventée, mauvais utilitaire, architecture non respectée. Chaque cause récurrente devient une règle concrète.

Dans AGENTS.md, placez ce qui vaut pour tout le dépôt : structure des modules, conventions de nommage, interdictions. Dans une compétence distincte, isolez la procédure étroite, par exemple l'écriture de tests, et ajoutez-y un ou deux exemples de référence tirés du code réel. Listez explicitement les objets Mock et les utilitaires de test existants, et interdisez d'en créer de nouveaux sans demande. C'est une réponse directe au principal défaut décrit par l'équipe.

Enfin, bouclez systématiquement la boucle par une vérification : l'agent doit lancer la compilation et les tests, puis corriger lui-même les erreurs. Les règles réduisent le nombre d'inventions, mais le compilateur reste le relecteur le plus fiable. Il faut relire les fichiers de règles comme du code ordinaire et les mettre à jour en même temps que l'architecture, sans quoi ils vieilliront vite et finiront par nuire.