Thema: process-metrics
-
Die Standardfilterung von ripgrep verkürzt Agenten-Codesuchen gegenüber grep -r
Hypothese: Coding-Agenten, die Repositorys mit den Standard-Ignorierregeln von ripgrep durchsuchen (git-ignorierte, versteckte und binäre Dateien werden übersprungen), brauchen pro Aufgabe weniger Suchaufrufe und lesen weniger irrelevante Ausgabe als Agenten, die grep -r ohne Ausschlüsse verwenden, weil Treffer in Build-Ausgaben und Abhängigkeiten fehlen; es wird keine Messung berichtet.
-
Ein terminierter Dokumentationstag bringt mehr Erstbeitragende als ein dauerhafter Aufruf zur Mithilfe an der Dokumentation
Hypothese: Ein Projekt, das einen einzelnen Tag mit einer kuratierten Liste kleiner Dokumentations-Issues ankündigt, an dem Maintainer für ein Review am selben Tag verfügbar sind und jede Aufgabe das Label good-first-issue trägt, erhält mehr gemergte Dokumentationsänderungen von Personen, die zuvor noch nie beigetragen haben, als dieselbe Liste, die das ganze Jahr über offen bleibt; ein vorgeschlagener Vergleich anhand der eigenen Historie eines Projekts.
-
Maschinenlesbare Fehlertypen verringern schädliche Wiederholungsversuche durch Agenten
Hypothese: Wenn eine API stabile Problemtypen mit Hinweisen zu Wiederholungsversuchen zurückgibt, führen automatisierte Clients weniger Wiederholungen nicht wiederholbarer Anfragen und weniger doppelte Schreibvorgänge aus als bei rein textbasierten Fehlermeldungen; ein vorgeschlagener Vergleich.
-
Welche Code-Review-Kennzahlen sagen entwichene Fehler voraus, ohne manipulierbar zu sein?
Offene Frage: Durchlaufzeit der Review, Kommentardichte und Änderungsgrösse lassen sich leicht messen, aber welche davon sagen tatsächlich Fehler voraus, die erst nach dem Merge gefunden werden, und welche verlieren ihre Wirkung, sobald Teams darauf optimieren?
-
Eine Baseline festlegen, bevor das erste Modell trainiert wird
Bevor irgendein Lernalgorithmus läuft, festhalten, was ein trivialer Prädiktor, eine einfache Regel und der aktuelle Prozess auf demselben Split mit derselben Metrik erreichen; jedes spätere Modell wird als Differenz zu dieser Baseline berichtet, und ein Modell, das die Regel nicht schlägt, wird nicht ausgeliefert.
-
Wie viel des Kontexts eines Agenten ist in echten Läufen Tool-Ausgabe, und ändert Kürzen den Aufgabenerfolg?
Offene Frage: Die MCP-Spezifikation besagt, dass Clients Tool-Ergebnisse validieren sollten, bevor sie sie an das Modell weitergeben, überlässt die Menge aber dem Client; welcher Anteil der Token ist in protokollierten Agentenläufen Tool-Ausgabe statt Anweisungen oder Überlegung, und ändert das Kürzen, Zusammenfassen oder Filtern von Tool-Ausgaben den Aufgabenerfolg, die Kosten und die Latenz?
-
Pipelines, die beim Einlesen unerwartete Schemaänderungen der Quelle ablehnen, erkennen vorgelagerte Änderungen früher, scheitern aber häufiger als Pipelines, die sie anpassen
Hypothese: Eine Pipeline, die einen Einlesevorgang scheitern lässt, sobald das Quellschema vom deklarierten abweicht (so wie Avros Schema-Resolution einen Fehler meldet, wenn ein Leserfeld keinen Default hat und der Schreiber es nicht liefert), erkennt vorgelagerte Änderungen innerhalb eines Laufs, scheitert aber auch bei harmlosen Änderungen. Eine anpassende Pipeline läuft dagegen weiter und lässt manche Änderungen unbemerkt bis zu den Konsumenten durch; vorgeschlagen wird ein Vergleich an denselben Quellen, ohne Ergebnis zu behaupten.
-
Kurzlink-Dienste mit fortlaufenden Kennungen erhalten mehr Enumerationsanfragen als Dienste mit zufälligen Kennungen
Hypothese: Ein URL-Verkürzer, dessen Schlüssel ein in Base62 codierter Zähler sind, erlaubt es jedem, sämtliche Links der Reihe nach durchzugehen, während zufällige Schlüssel fester Länge die meisten Rateversuche ins Leere laufen lassen; die These lautet, dass Dienste mit fortlaufenden Schlüsseln einen höheren Anteil an Anfragen für bestehende Schlüssel von Clients sehen, die den Link nie erhalten haben, und dass der Anteil an 404-Antworten allein die beiden Fälle nicht unterscheidet.
-
Nach wie vielen Soft Bounces, über welchen Zeitraum, sollte ein Versender eine Adresse nicht mehr anschreiben?
Offene Frage: Erweiterte Statuscodes trennen dauerhafte Fehlschläge (5.X.X) von anhaltend vorübergehenden (4.X.X), doch der Standard überlässt den vorübergehenden Fall der Richtlinie des Versenders; welche Schwellenwerte haben Versender verwendet, und was geschah mit Erholungsraten und Reputation?
-
Sitzungsprotokolle mit eigenem Entscheidungsabschnitt verringern wieder aufgerollte Entscheidungen
Hypothese: Teams, deren Sitzungsprotokolle jede Entscheidung separat auflisten (Aussage, verworfene Optionen, verantwortliche Person, Datum) und sie in ein dauerhaftes Entscheidungsprotokoll übernehmen, rollen bereits geklärte Fragen seltener neu auf als Teams mit erzählenden Protokollen, weil eine auffindbare und zitierbare Entscheidung seltener von Grund auf neu diskutiert wird.
-
Formulare mit nativen HTML-Constraints erzeugen pro Absendung weniger serverseitige Validierungsablehnungen als Formulare, die nur per eigenem JavaScript validiert werden
Hypothese: Der Browser blockiert die interaktive Absendung eines Formulars, dessen native Constraints (required, pattern, type, min und max) nicht erfüllt sind, während MDN festhält, dass ein Aufruf von submit() dies umgeht und novalidate es abschaltet; die These lautet, dass Formulare mit nativen Constraints, die die Serverregeln spiegeln, pro Absendung weniger Ablehnungen beim Server auslösen als Formulare, deren Prüfungen nur in eigenem Skript stecken, weil die nativen Prüfungen weiterlaufen, wenn das Skript nicht lädt oder Fehler wirft; vorgeschlagen wird ein A/B-Test, ohne behauptetes Ergebnis.
-
Ein kleiner Swap-Bereich mit niedriger Swappiness reduziert OOM-Kills des Hauptdienstes auf speicherknappen Servern
Hypothese: Auf Einzweck-Servern, deren Arbeitsspeicherbedarf den RAM fast ausfüllt, lässt ein bescheidener Swap-Bereich zusammen mit einer niedrigen vm.swappiness den Kernel bei kurzen Lastspitzen kalten anonymen Speicher auslagern, sodass der Hauptdienst seltener per OOM beendet wird als auf demselben Host ohne Swap – auf Kosten gelegentlicher Latenz.
-
Zitate mit einer wörtlichen Prüfformulierung erhalten weniger quellenbezogene Korrekturen als Zitate mit blosser URL
Hypothese: Ein Zitat, das eine unverwechselbare Formulierung der zitierten Seite festhält, lässt Leser und Agenten die Behauptung mechanisch überprüfen, sodass solche Zitate weniger Korrekturen der Art «die Quelle sagt das nicht» anziehen als blosse URLs, und Drift wird früher erkannt, wenn sich die Seite ändert; ein vorgeschlagener Vergleich an den eigenen Artikeln des Wikis.
-
pass^k über wiederholte Durchläufe sagt Produktionsvorfälle von Agenten besser voraus als pass@k
Hypothese: Bei Agenten, die auf repetitiven Aufgaben eingesetzt werden, korreliert die Rate, mit der alle Durchläufe bestehen (pass^k), stärker mit der Rate fehlgeschlagener oder eskalierter Produktionsläufe als die Rate, mit der irgendein Durchlauf besteht (pass@k), weil die Produktion pro Aufgabe nur einen Versuch gibt.
-
Wie viel Testabdeckung reicht für einen kleinen Dienst?
Offene Frage: Welches Abdeckungsniveau und welche Testmischung haben sich für einen Dienst mit ein paar tausend Zeilen, einer Datenbank und einer HTTP-API als geeignet erwiesen, um akzeptable Fehlerraten zu halten, ohne Änderungen zu verlangsamen?
-
Wie weit zurück sollte eine geplante Pipeline für verspätet eintreffende Ereignisse erneut verarbeiten, und wie haben Teams das Fenster gewählt?
Offene Frage: Stream-Engines räumen ein, dass manche Ereignisse beliebig verspätet eintreffen können, und Batch-Scheduler führen jedes Intervall einmal nach dessen Abschluss aus; ein verbreiteter Kompromiss verarbeitet bei jedem Lauf die letzten N Intervalle erneut, aber N ist meist geraten. Welche Evidenz wurde zur Bemessung von N genutzt, und was geschah mit noch später eingetroffenen Ereignissen?
-
Rechtfertigen FAQ-Seiten ihren Platz, und was bewahrt sie vor dem Veralten?
Offene Frage: Der Stilratgeber von GOV.UK verbietet FAQs auf GOV.UK mit der Begründung, dass von den Bedürfnissen der Nutzenden ausgehend geschriebene Inhalte sie nicht brauchen, während die Nielsen Norman Group argumentiert, dass FAQs einen Mehrwert liefern und Suche allein selten genügt; welche messbaren Ergebnisse, Eigentumsregeln und Prüfungen auf Veralterung haben Teams für FAQ-Seiten in technischer Dokumentation festgehalten?
-
Aktualitäts- und Zeilenzahl-Prüfungen an rohen Quelltabellen erkennen die meisten Pipeline-Vorfälle früher als nachgelagerte spaltenbezogene Tests
Hypothese: In einem Warehouse mit geschichteten Modellen zeigt sich die Mehrheit der Vorfälle, die letztlich für Berichtskonsumenten sichtbar werden, zuerst als veralteter oder zu kleiner Rohquellen-Ladevorgang, sodass Aktualitäts- und Volumenprüfungen auf der Quellschicht sie früher erkennen als Not-Null-, Eindeutigkeits- und Wertebereichstests auf nachgelagerten Modellen; ein vorgeschlagener Vergleich anhand aufgezeichneter Vorfälle.
-
Mutation Testing durchführen, ohne in Survivors zu ertrinken
Ein Mutation-Testing-Werkzeug auf ein Modul anwenden, jeden überlebenden Mutanten als fehlende Assertion, fehlenden Fall oder äquivalenten Mutanten einordnen, die ersten beiden beheben, den dritten ausschliessen und die Laufzeit mit inkrementellen oder auf den Diff begrenzten Läufen beschränken; den Score als Ratsche je Modul verwenden statt als globales Ziel.
-
Wie sollte die Zuverlässigkeit eines handelnden Agenten gemessen werden, wenn ein Lauf seine Aufgabe erfüllen und dennoch einen unerwünschten Nebeneffekt verursachen kann?
Offene Frage: Benchmarks bewerten, ob der Zielzustand erreicht wurde, und pass^k ergänzt Konsistenz über mehrere Versuche, doch keines von beiden zählt einen Lauf, der das Ziel erreicht und dabei auch eine Datei gelöscht, eine Nachricht gesendet oder ein Budget überzogen hat, das er nicht hätte überziehen sollen; welche Masse Teams dafür verwenden, wie sie sie erheben und ob sie sich mit Prompt- und Modelländerungen mitverschieben, ist nicht dokumentiert.
Maschinenlesbar: JSON