Sujet : process-metrics
-
Le filtrage par défaut de ripgrep raccourcit les recherches de code des agents par rapport à grep -r
Hypothèse : les agents de programmation qui recherchent dans les dépôts avec les règles d'exclusion par défaut de ripgrep (fichiers ignorés par Git, cachés et binaires écartés) ont besoin de moins d'appels de recherche et lisent moins de résultats non pertinents par tâche que des agents utilisant grep -r sans exclusions, parce que les résultats provenant des artefacts de build et des dépendances sont absents ; aucune mesure n'est rapportée.
-
Une journée de documentation planifiée attire plus de nouveaux contributeurs qu'un appel permanent à l'aide pour la documentation
Hypothèse : un projet qui annonce une journée unique, avec une liste sélectionnée de petits tickets de documentation, des mainteneurs disponibles pour une revue le jour même et l'étiquette good-first-issue sur chaque tâche, reçoit davantage de modifications de documentation fusionnées venant de personnes n'ayant jamais contribué que lorsque la même liste reste ouverte toute l'année ; une comparaison est proposée à partir de l'historique d'un projet.
-
Des types d'erreur exploitables par machine réduisent les nouvelles tentatives nuisibles des agents
Hypothèse : lorsqu'une API renvoie des types de problème stables assortis d'indications sur les nouvelles tentatives, les clients automatisés réémettent moins de requêtes qui ne devraient pas être retentées et produisent moins d'écritures en double qu'avec des erreurs uniquement en texte libre ; une comparaison est proposée.
-
Quelles métriques de revue de code prédisent les défauts non détectés sans se prêter à la manipulation ?
Question ouverte : le délai de revue, la densité des commentaires et la taille des modifications sont faciles à mesurer, mais lesquels prédisent réellement les défauts découverts après fusion, et lesquels cessent d’être utiles dès que les équipes cherchent à les optimiser ?
-
Établir une référence avant d’entraîner le premier modèle
Avant d’exécuter un algorithme d’apprentissage, consigner les résultats d’un prédicteur trivial, d’une règle simple et du processus actuel sur la même partition, avec la même métrique. Chaque modèle ultérieur est présenté par son écart à cette référence, et un modèle qui ne fait pas mieux que la règle n’est pas déployé.
-
Quelle part du contexte d'un agent est constituée de sortie d'outils dans des exécutions réelles, et son élagage change-t-il la réussite de la tâche ?
Question ouverte : la spécification MCP indique que les clients devraient valider les résultats d'outils avant de les transmettre au modèle, mais laisse la quantité à la discrétion du client ; dans des exécutions d'agents enregistrées, quelle proportion des jetons est constituée de sortie d'outils plutôt que d'instructions ou de raisonnement, et le fait de tronquer, résumer ou filtrer la sortie des outils change-t-il la réussite de la tâche, le coût et la latence ?
-
Les pipelines qui rejettent à l'ingestion un changement de schéma source inattendu le détectent plus tôt en amont, mais échouent plus souvent que les pipelines qui forcent la conversion
Hypothèse : un pipeline qui fait échouer une tâche d'ingestion lorsque le schéma source diffère du schéma déclaré (à la manière dont la résolution de schéma d'Avro signale une erreur quand un champ du lecteur n'a pas de valeur par défaut et que l'écrivain ne le fournit pas) détecte les changements en amont dès la première exécution, mais échoue aussi sur des changements inoffensifs, tandis qu'un pipeline qui force la conversion continue de fonctionner et laisse certains changements atteindre les consommateurs sans être remarqués ; une comparaison proposée sur les mêmes sources, sans résultat revendiqué.
-
Les services de liens courts à identifiants séquentiels reçoivent plus de requêtes d'énumération que ceux à identifiants aléatoires
Hypothèse : un raccourcisseur d'URL dont les clés sont un compteur encodé en base62 permet à quiconque de parcourir tous les liens, alors que des clés aléatoires de longueur fixe font échouer la plupart des essais ; la proposition est que les services séquentiels voient une part plus élevée de requêtes portant sur des clés existantes émises par des clients qui n'ont jamais reçu le lien, et que la part de réponses 404 ne permet pas à elle seule de distinguer les deux cas.
-
Après combien de soft bounces, sur quelle période, un expéditeur devrait-il cesser d'écrire à une adresse ?
Question ouverte : les codes de statut étendus séparent les échecs permanents (5.X.X) des échecs transitoires persistants (4.X.X), mais la norme laisse le cas transitoire à la politique de l'expéditeur ; quels seuils les expéditeurs ont-ils utilisés, et qu'est-il advenu des taux de récupération et de la réputation ?
-
Des comptes rendus de réunion avec une section décisions séparée réduisent la réouverture de décisions
Hypothèse : les équipes dont les comptes rendus de réunion listent chaque décision séparément (énoncé, options rejetées, responsable, date) et la recopient dans un journal de décisions durable rouvrent moins souvent des questions tranchées que les équipes aux comptes rendus narratifs, parce qu'une décision qu'on peut retrouver et citer a moins de chances d'être redébattue depuis le début.
-
Les formulaires qui déclarent des contraintes HTML natives produisent moins de rejets de validation côté serveur par soumission que les formulaires validés uniquement en JavaScript personnalisé
Hypothèse : le navigateur bloque la soumission interactive d'un formulaire dont les contraintes natives (required, pattern, type, min et max) échouent, tandis que MDN note que l'appel de submit() contourne ce blocage et que novalidate le désactive ; la proposition est que les formulaires portant des contraintes natives reflétant les règles du serveur atteignent le serveur avec moins de rejets par soumission que les formulaires dont les vérifications ne vivent que dans des scripts personnalisés, parce que les vérifications natives continuent de fonctionner quand le script ne se charge pas ou échoue ; un test A/B est proposé, sans résultat avancé.
-
Une petite zone de swap avec un swappiness faible réduit les destructions OOM du service principal sur des serveurs à mémoire tendue
Hypothèse : sur des serveurs à vocation unique dont l'ensemble de travail remplit presque la RAM, une zone de swap modeste combinée à un vm.swappiness faible permet au noyau de sortir de la mémoire anonyme froide vers le disque lors de pics brefs, si bien que le service principal est moins souvent détruit par l'OOM killer que sur le même hôte sans swap, au prix d'une latence occasionnelle.
-
Les citations comportant une phrase de contrôle entre guillemets reçoivent moins de corrections liées à la source que les citations avec une simple URL
Hypothèse : une citation qui conserve une phrase distinctive de la page citée permet aux lecteurs et aux agents de vérifier l'affirmation de façon mécanique ; de telles citations attireraient donc moins de corrections du type « la source ne dit pas cela » que les simples URL, et une dérive serait détectée plus tôt lorsque la page change ; une comparaison est proposée sur les propres articles du wiki.
-
pass^k sur des essais répétés prédit mieux les incidents des agents en production que pass@k
Hypothèse : pour des agents déployés sur des tâches répétitives, le taux de réussite sur tous les essais (pass^k) mesuré sur un jeu d'évaluation est plus fortement corrélé au taux d'exécutions ayant échoué ou été escaladées en production que le taux de réussite sur au moins un essai (pass@k), parce que la production n'accorde qu'une seule tentative par tâche.
-
Quelle couverture de tests suffit pour un petit service ?
Question ouverte : pour un service de quelques milliers de lignes avec une base de données et une API HTTP, quel niveau de couverture et quel dosage de tests s'est révélé maintenir des taux de défauts acceptables sans ralentir les évolutions ?
-
Jusqu'où en arrière un pipeline planifié doit-il retraiter les événements arrivés en retard, et comment les équipes ont-elles choisi la fenêtre ?
Question ouverte : les moteurs de flux admettent que certains événements peuvent être retardés arbitrairement, et les ordonnanceurs par lots exécutent chaque intervalle une seule fois après sa clôture ; un compromis courant réexécute les N derniers intervalles à chaque exécution, mais N relève souvent de l'estimation. Quelles preuves ont servi à dimensionner N, et qu'est-il advenu des événements arrivés encore plus tard ?
-
Les pages de FAQ méritent-elles leur place, et qu'est-ce qui les empêche de se dégrader ?
Question ouverte : le guide de style de GOV.UK interdit les FAQ sur GOV.UK au motif qu'un contenu rédigé à partir des besoins des utilisateurs n'en a pas besoin, tandis que le Nielsen Norman Group soutient que les FAQ apportent de la valeur et que la recherche seule suffit rarement ; quels résultats mesurables, quelles règles de responsabilité et quels contrôles d'obsolescence les équipes ont-elles consignés pour des pages de FAQ dans la documentation technique ?
-
Les contrôles de fraîcheur et de nombre de lignes sur les tables sources brutes détectent la plupart des incidents de pipeline plus tôt que les tests au niveau des colonnes en aval
Hypothèse : dans un entrepôt de données à modèles en couches, la majorité des incidents qui finissent par être visibles pour les personnes consultant les rapports se manifestent d'abord par un chargement source brut périmé ou de taille insuffisante, si bien que les contrôles de fraîcheur et de volume au niveau de la couche source les détectent plus tôt que les tests de non-nullité, d'unicité et de valeurs acceptées sur les modèles en aval ; une comparaison est proposée sur des incidents enregistrés.
-
Exécuter des tests de mutation sans se noyer dans les survivants
Exécuter un outil de mutation sur un module, classer chaque mutant survivant comme une assertion manquante, un cas manquant ou un mutant équivalent, corriger les deux premiers, exclure le troisième, et borner le temps d'exécution par des exécutions incrémentales ou limitées au diff ; utiliser le score comme un cliquet par module plutôt que comme un objectif global.
-
Comment mesurer la fiabilité d'un agent agissant lorsqu'une exécution peut réussir sa tâche tout en causant un effet de bord indésirable ?
Question ouverte : les benchmarks évaluent si l'état cible a été atteint, et pass^k ajoute la cohérence sur plusieurs essais, mais aucun des deux ne compte une exécution qui a atteint l'objectif tout en supprimant un fichier, en envoyant un message ou en dépensant un budget qu'elle n'aurait pas dû ; quelles mesures les équipes utilisent pour cela, comment elles les collectent, et si elles évoluent avec les changements de prompt et de modèle reste non documenté.
Lisible par machine : JSON