Chiosa
FR
Software & Code

PACE-Bench vérifie si les agents de code répondent à toute la demande

When Coding Agents Outpace Review: Evaluating PRD-Driven Development in Mature Enterprise Repositories · arXiv:2610.26394

4 min
Mis à jour
PACE-Bench turns production requirements into frozen acceptance criteria, evidence-grounded judgments, and traceable diagnoses for agent improvement.
PACE-Bench turns production requirements into frozen acceptance criteria, evidence-grounded judgments, and traceable diagnoses for agent improvement.Figure 1 · When Coding Agents Outpace Review: Evaluating PRD-Driven Development in Mature Enterprise Repositories · Tianqi Liu et al. · CC BY 4.0

En termes simples

Un agent de programmation peut modifier un projet existant sans répondre à toutes les parties de la demande. PACE-Bench sert à vérifier si la demande a été satisfaite dans son ensemble, y compris les règles métier et les liens avec le code déjà présent.

La méthode transforme de vraies demandes de développement en listes de contrôle examinées par des experts, puis compare le code des agents à ces listes. Dans la comparaison portant sur 43 tâches, la meilleure configuration a entièrement satisfait la règle d’acceptation dans 6 cas : la livraison complète est donc restée rare dans ce jeu de test.

La recherche

Un agent de programmation peut réussir les tests de composants individuels tout en laissant inachevée une règle métier ou une connexion au code existant.

Pour les demandes qui comportent plusieurs conditions d’acceptation, comment savoir si la demande entière a été satisfaite et repérer ce qui manque encore ?

PACE-Bench compare les modifications des agents de programmation à des exigences figées et examinées par des experts, puis relie les conditions non satisfaites aux éléments du code et aux traces d’exécution.

Dans les projets logiciels établis, un agent de programmation peut réussir des vérifications isolées tout en laissant de côté une règle métier ou une exigence d’intégration.

Comment évaluer la demande entière et montrer quelles conditions restent insatisfaites, plutôt que de réduire différentes lacunes à un seul score ?

PACE-Bench compare les correctifs à des critères d’acceptation figés et examinés par des experts, puis relie les exigences non satisfaites aux éléments du code et aux traces d’exécution. Sur 43 tâches, la meilleure configuration rapportée a satisfait la règle de livraison complète dans 6 cas.

Lors d’une vérification distincte, l’évaluateur a correspondu au consensus d’annotateurs techniques pour 95.2% des 750 verdicts portant sur les correctifs de Qwen Run 1.

Ces résultats portent sur les 43 tâches de production et les configurations testées. La comparaison entre versions ne comprend qu’une configuration d’Opus-4.5 par version ; elle ne montre donc pas que les changements apportés au dispositif d’évaluation ont, à eux seuls, causé la hausse du score.

Le jeu de tâches ne couvre pas non plus d’autres sources, comme les demandes de fusion ou la structure des dépôts.

Ce que montrent les preuves

  • Évaluer toute la demande

    PACE-Bench est un benchmark et une méthode d’évaluation des agents de programmation qui répondent à des documents décrivant les besoins d’un produit (PRD) dans des dépôts d’entreprise existants. Le problème de départ est que réussir des tests isolés ou produire un composant peut laisser de côté des règles métier ou des exigences d’intégration. L’évaluation vise à examiner la demande entière et à rendre visibles les lacunes précises.

  • Figer les critères d’acceptation

    Pour définir ce qui compte comme une demande satisfaite, PACE-Bench tire des conditions d’acceptation individuelles, appelées Code Points, d’un PRD consolidé et d’une modification de référence analysée indépendamment.

    Des experts vérifient que les critères sont fondés sur la demande et qu’ils couvrent les exigences ; les critères et leur pondération sont ensuite figés. Les agents reçoivent le PRD et le dépôt de départ, sans le correctif de référence ni les critères.

  • Comparer les éléments aux exigences

    La méthode examine les changements proposés par étapes : elle vérifie les contraintes explicites, repère les éléments de code et d’intégration pertinents, puis évalue ces éléments au regard de chaque critère figé.

    Des règles déterministes combinent les jugements sur les critères en scores pondérés. Pour compter comme une livraison complète, il faut obtenir au moins 95 et ne laisser aucun Code Point manquant ; la méthode distingue ainsi une satisfaction partielle du respect de l’ensemble du contrat d’acceptation.

  • Mesurer la livraison et ses lacunes

    Sur les 43 tâches, GPT-5.6-Sol avec le dispositif commun OpenHands a obtenu le taux de livraison complète le plus élevé rapporté : 6 cas sur 43 ont satisfait la règle correspondante. Le benchmark a aussi classé les exigences non satisfaites.

    Parmi les huit principaux modèles évalués avec le dispositif commun, les lacunes d’implémentation et celles d’intégration ou d’enregistrement représentaient 72.0% de la perte pondérée de crédit d’acceptation cumulée. Ces catégories décrivent les résultats manquants, pas leurs causes.

  • Vérifier les verdicts et guider les révisions

    Une vérification distincte de l’évaluateur a comparé les verdicts de PACE-Bench au consensus d’annotateurs techniques sur les correctifs de Qwen Run 1. Le processus complet a obtenu un accord exact de 95.2% sur les 750 verdicts ; les versions auxquelles certains composants avaient été retirés obtenaient un accord moindre.

    L’équipe s’est aussi servie d’indices issus des traces pour examiner des révisions du dispositif sur le même jeu de tâches, mais cette comparaison entre versions ne permet pas d’isoler la cause du changement de score.

Détails

Article suivantLe travail logiciel hérité met en évidence une limite des agents de programmation