SENAR introduit des portails de qualité pour le développement de l'IA : comment les spécifications et les métriques réduisent les erreurs

Un quatrième article de la série SENAR a été publié sur Habr — une méthodologie ouverte pour le développement avec des agents d'IA. Andrey Yumashev décrit comment les "portes" formelles d'entrée et de sortie devraient remplacer la discipline personnelle des responsables de la spécification des tâches et réduire le nombre d'erreurs qui ne font surface qu'après la clôture d'une tâche.

Comment Fonctionne SENAR

SENAR est ce que l'auteur appelle une méthodologie d'ingénierie pour travailler avec des agents d'IA dans le développement. Elle est née non pas de la théorie, mais de la pratique : selon Yumashev, au cours d'un peu plus d'un an et demi, plus de trente projets ont traversé un tel régime, où le code était de plus en plus écrit par un agent, tandis que les humains s'occupaient de la spécification, de l'acceptation et de l'analyse des défaillances. L'idée principale de l'article est simple : un agent ne maintient pas le contexte entre les exécutions, suit littéralement la formulation et optimise facilement localement si une tâche est décrite de manière négligente.

Au sein d'une seule tâche, SENAR s'appuie sur plusieurs éléments obligatoires :

• objectif formel de la tâche dans la logique produit
• critères d'acceptation vérifiables
• un bloc séparé de scénarios négatifs
• limites des changements et contexte architectural
• métriques de signal pour la qualité du processus

L'auteur souligne que ce n'est pas une tentative de remplacer les tests, les linters ou l'examen du code. La logique est différente : les vérifications normales examinent le code, tandis que les portes examinent la tâche elle-même avant le démarrage et la qualité de son acceptation après l'achèvement. Dans l'implémentation pratique de TAUSIK, ces étapes sont intégrées directement dans l'outil, ils ne peuvent donc pas être ignorés sans contourner le système lui-même. Cela, selon la pensée de l'auteur, protège l'équipe de la fatigue du "vendredi", lorsque les plus petites tâches glissent le plus souvent en production avec des défauts.

Ce que Vérifient les Portes

À l'entrée, SENAR utilise la porte QG-0. Elle n'autorise pas une tâche à commencer le travail tant qu'elle n'a pas une spécification minimale : un objectif, des critères d'acceptation, des scénarios négatifs, des limites de changement et un lien vers le contexte architectural. Yumashev conteste séparément l'hypothèse populaire selon laquelle les petites tâches peuvent être remises à un agent « en une seule ligne ». Ce sont précisément ces tâches qui, selon son observation, se cassent le plus souvent en production, car celui qui spécifie la tâche garde les détails importants dans sa tête mais ne les fixe pas dans le ticket.

"L'étape a été ignorée non pas par l'agent, mais par moi."

À la sortie, QG-2 fonctionne — une porte qui bloque la clôture de la tâche jusqu'à ce que le résultat soit vérifié par rapport aux promesses faites à l'entrée. Dans l'article, l'auteur met en évidence trois vérifications obligatoires : confirmation de chaque critère d'acceptation par test, vérification manuelle ou artefact ; fixation de toutes les corrections manuelles après le travail de l'agent ; mise à jour de la mémoire du projet si la tâche a découvert un nouveau cas limite ou une particularité d'infrastructure. Un tel mode est nécessaire non pour des raisons bureaucratiques, mais pour que l'agent dans la tâche suivante ne répète pas les mêmes erreurs en raison de corrections silencieuses apportées par un humain.

Métriques et Limites

Une section séparée de l'article est consacrée aux métriques que SENAR utilise comme signaux de l'état du processus. FPSR montre la proportion de tâches résolues à la première tentative ; MIR — la fréquence à laquelle la correction manuelle était nécessaire après l'agent ; DER mesure les branches sans issue et les pertes de temps ; ERR reflète les tâches qui ont dû être corrigées après leur clôture.

Selon le journal de travail de l'auteur, pour les tâches de serveur dans un domaine familier, FPSR a augmenté d'environ 40% à 75–80% ; MIR sur le projet Sortule a diminué de 20% à 5–7%, et ERR a baissé à environ 6% depuis 15%. En même temps, Yumashev décrit honnêtement les limites de la méthodologie. Les portes aident peu là où le résultat est difficile à formaliser : dans les tâches portant sur la "sensation" de l'interface, le ton du texte ou l'intuition produit.

Elles n'aident pas non plus au travail avec des services externes, si la documentation d'une tierce partie contredit le comportement réel de l'API. Dans de tels cas, le processus formel peut maintenir la structure de la tâche, mais ne remplace pas la connaissance du domaine, les tests manuels d'hypothèses et la recherche préalable d'intégration.

Ce Que Cela Signifie

SENAR est formalisé non pas comme un ensemble de recommandations, mais comme une boucle opérationnelle rigide pour le développement de l'IA : sans une spécification appropriée, l'agent ne démarre pas ; sans acceptation confirmée, la tâche ne se ferme pas. Pour les équipes qui confient déjà du code à des agents, c'est un signal fort : le risque principal réside désormais non seulement dans le modèle, mais dans la qualité de la spécification des tâches, la mémoire du projet et la discipline du processus.