Deine Leistungsbeurteilung ist ein Gedächtnistest

Fragen Sie jeden Engineering Manager, wer ihr bester Ingenieur ist. Beobachten Sie, wie schnell die Antwort kommt. Kein Zögern, kein Vorbehalt, kein »Lassen Sie mich erst etwas nachschlagen.« Sie wissen es. Sie haben es immer gewusst.

Bitten Sie sie nun, die Arbeit zu zeigen. Sie werden eine Geschichte bekommen. Eine gute Geschichte, meistens, über einen Vorfall, den jemand um 2 Uhr morgens bewältigt hat, oder ein Refactoring, das ein Quartal entblockt hat, oder die Person, die immer im Kanal antwortet. Was Sie nicht bekommen, ist eine Zahl, ein Vergleich oder ein Bericht über die vier Ingenieure, deren Arbeit der Manager nicht im Raum miterlebt hat. Das Vertrauen basierte nie auf Messung. Es basierte auf Erinnerung, und Erinnerung ist eine Funktion der Nähe.

Hier ist die These, und alles danach ist der Beleg dafür. Engineering-Leistung wird aus dem Gedächtnis beurteilt, das Gedächtnis belohnt Sichtbarkeit statt Wert, und das, was Sie eigentlich gebaut haben wollen, steht in einer Roadmap, die nie mit dem verbunden ist, wonach Sie die Leute bewerten. Diese beiden Dokumente, die Roadmap und die Leistungsbeurteilung, haben in fast jedem Unternehmen, das ich gesehen habe, nichts miteinander zu tun, auch in meinem bis vor kurzem.

Also haben wir sie verbunden. Jeder gemergte Pull-Request wird von einem Modell gelesen, erhält eine Schweregradzuweisung und wird mit dem Wert multipliziert, den unsere Roadmap der betroffenen Komponente beimisst. Das Ergebnis ist ein monatliches Leaderboard, das in Bonusentscheidungen einfließt.

Ich werde Ihnen unseres zeigen, einschließlich der Teile, die peinlich sind, und der Teile, die falsch sind.

Die allgemeine Weisheit besagt, dass dies nicht messbar ist, und die allgemeine Weisheit ist ein Achselzucken

Die Standardposition zur Messung der individuellen Engineering-Leistung ist, dass man es nicht tun darf, weil jeder Proxy eine Falle ist. Zeilen Code belohnen Aufblähung. Commit-Anzahl belohnt Aufsplittung. Story Points sind eine Verhandlung, keine Messung. Selbst die guten Frameworks sind bewusst auf Team-Ebene angesiedelt: DORA misst vier Dinge an einer Delivery-Pipeline und sagt nichts über Menschen, was eine Designentscheidung ist, die seine Autoren explizit machen.

All das ist richtig, und nichts davon ist eine Antwort. Die Weigerung zu messen, führt nicht zu einem Unternehmen, in dem niemand bewertet wird. Es führt zu einem Unternehmen, in dem trotzdem jeder bewertet wird, durch einen Mechanismus ohne Prüfpfad. Die Bewertung findet immer noch zur Vergütungszeit statt. Sie findet nur in einem Raum statt, aus dem Gedächtnis, gewichtet danach, mit wem die Person im Raum die meiste Zeit verbracht hat.

Nennen Sie es die loud engineer premium: die Lücke zwischen dem, wie gut Sie bewertet werden, und dem, wie gut Sie gearbeitet haben, vollständig erklärt durch Ihre Distanz zu demjenigen, der Ihre Beurteilung schreibt. Es ist kein Charakterfehler von Managern. Es ist das vorhersagbare Ergebnis, wenn man einen Menschen bittet, die technischen Beiträge von fünfzehn Personen über ein Jahr hinweg zu vergleichen, und zwar nur mit dem, was ihnen zufällig aufgefallen ist.

Die Prämie war bis vor etwa zwei Jahren unvermeidbar, weil das Rohmaterial für eine bessere Antwort ein Haufen von Diffs war, den niemand Zeit hatte zu lesen. Diese Einschränkung ist weg. Ein Modell kann jeden Diff in Ihrem Repository jeden Monat lesen für weniger als die Kosten einer Stunde des Meetings, in dem Sie derzeit raten.

Sie zu lesen ist der einfache Teil. Zu entscheiden, was das Lesen wert ist, ist das ganze Problem, und das ist keine technische Frage.

Die gesamte Formel passt in eine Zeile

Hier ist sie vollständig, aus dem Scoring-Pfad in GitRank:

final_score = is_eligible ? severity_base_points × component_multiplier : 0

Das ist keine Vereinfachung für den Blog. Das ist die Zeile. Es gibt keine versteckte Regression, keine gelernte Gewichtung, keinen Reputationsterm, keine Anpassung für Betriebszugehörigkeit. Schweregrad mal Wichtigkeit, oder null.

Der Schweregrad-Teil ist eine feste Leiter. Vier Stufen, vier Punktwerte, einmal festgelegt und für alle Bewerteten sichtbar:

Ein kritischer Fix ist zwanzig niedrigpriore wert. Dieses Verhältnis ist eine politische Aussage, und wir haben es aufgeschrieben, anstatt es in jemandes Kopf zu lassen.

Der Wichtigkeits-Teil ist der Teil, der tatsächlich zählt, und er ist der Grund, warum ich denke, dass dieser Ansatz verallgemeinerbar ist. Jede Komponente im Repository trägt einen Multiplikator, und der Multiplikator wird dadurch bestimmt, was das Produkt in diesem Quartal braucht:

Chat ist 2,0x, weil Chat das ist, worauf wir das Produkt setzen. Authentifizierung ist 1,0x, weil es funktioniert und wir möchten, dass es leise weiter funktioniert. Kollaborationsfunktionen und Dokument-Highlighting sind 2,0x aus demselben Grund wie Chat. Keine dieser Zahlen sind technische Urteile. Sie sind die Roadmap, neu getippt in ein Feld, das sich auszahlt.

Das ist der Kniff. Nicht das Modell, nicht das Leaderboard, nicht die Gamification. Der Kniff ist, dass das Strategiedokument und die Vergütungsgrundlage dasselbe Dokument wurden. Wenn sich die Roadmap im Oktober ändert, ändern sich die Multiplikatoren im Oktober, und der Anreiz ändert sich im Oktober, statt im nächsten jährlichen Beurteilungszyklus in vierzehn Monaten.

Ein kritischer Fix im Chat ist vierzig Polishing-Commits in der API wert

Wenn man die beiden Hälften zusammenführt, ist die Spreizung gravierend.

Ein P0 im Chat erzielt 100 Basis mal 2,0, also 200 Punkte. Ein P3 in der API erzielt 5 Basis mal 1,0, also 5 Punkte. Der wertvollste einzelne Pull Request, den man hier mergen kann, ist vierzig der am wenigsten wertvollen wert. Nicht vierzig Prozent mehr. Vierzig Mal.

Diese Zahl ist bewusst krass, und sie bewirkt, was sanfte Anreize nie schaffen. Niemand stellt seine Woche wegen eines 15%-Unterschieds um. Leute stellen ihre Woche definitiv wegen eines 40-fachen um.

Schauen wir uns an, was unter diesen Gewichten mit einer echten Woche passiert. Hier ist die Schweregradverteilung über fünf Wochen, mit der Woche vom 13. Juli vergrößert:

188 Pull Requests. P2 macht 59% davon aus, was eine normale Engineering-Woche überall ist: meist mittelgroße Fixes mit einem verfügbaren Workaround.

Jetzt gewichten. Diese 111 P2s sind 2.220 Punkte wert bei 1x. Die 50 P1s sind 2.500 wert. Weniger als halb so viele Pull Requests tragen mehr als die Hälfte des Werts der Woche, und der einzelne P0 ist so viel wert wie zwanzig der P3s, die eine reine Commit-Zählung als identische Arbeit behandelt hätte.

Das ist das gesamte Argument für Gewichtung, in einer Woche echter Daten. Zählt man Pull Requests, kommt man zu dem Schluss, dass die Woche von P2s geprägt war. Gewichtet man sie, stellt man fest, dass die Woche von fünfzig spezifischen Arbeiten geprägt war, und man kann benennen, wer sie erledigt hat.

Zwei Personen machten 58% der Ausgabe aus, und ich hätte die Reihenfolge nicht erraten

Zurück zur Rangliste, denn hier hörte ich auf, meiner eigenen Intuition zu vertrauen.

Sieben Entwickler, 10.415 Punkte im 30-Tage-Fenster. Der Top-Entwickler hält 3.530 davon, das sind 33,9% von allem, was das Team wertmäßig produziert hat. Die Top zwei halten zusammen 57,7%.

Ich möchte vorsichtig sein, was das bedeutet und was nicht. Es bedeutet nicht, dass die anderen fünf unterdurchschnittlich arbeiten, und wenn Sie es so lesen, haben Sie die falsche Lektion aus diesem Beitrag gelernt. Eine solche Konzentration bedeutet normalerweise, dass die Top zwei an den Komponenten mit dem höchsten Multiplikator arbeiten, was genau das ist, wofür das System belohnen soll und was wir von ihnen verlangt haben. Die Zahl ist eine Beschreibung, wo der Wert landet, kein Urteil über fünf Personen.

Aber sehen Sie sich die Reihenfolge an, denn sie hat meine Vorhersage durchbrochen. Hier ist, wer was besitzt:

Mulualem-E ist der primäre Experte für Chat, unsere 2,0x-Komponente, mit 71 von 230 Pull Requests. Er ist auch der primäre Experte für Agents, unsere 1,5x-Komponente, mit 86 von 148, also 58% dieses Bereichs. Wenn Sie mir das beschrieben und gefragt hätten, wer die Rangliste anführt, hätte ich ohne Zögern ihn genannt. Er ist Zweiter.

Der Spitzenplatz geht an tugberkayartextcortex, mit 31 P1-Pull-Requests gegenüber Mulualem-Es 12. Die Schweregradmischung hat die Komponentenbesitzerschaft geschlagen. Den wichtigsten Bereich des Produkts zu besitzen ist nicht dasselbe wie wiederholt hochwirksame Arbeit darin zu landen, und bis wir das veröffentlicht haben, hätte ich Ihnen nicht sagen können, welche dieser beiden Dinge unsere Vergütung tatsächlich belohnt hat. Sie belohnte das, was ich zufällig bemerkt hatte.

Das ist die laute Ingenieur-Prämie, auf frischer Tat ertappt, in meinem eigenen Unternehmen. Meine Intuition hatte die richtigen zwei Personen und die falsche Reihenfolge, und die falsche Reihenfolge ist das, was ein Bonus ist.

Die Person, die den meisten Code geschrieben hat, ist auf dem letzten Platz

Nun die Erkenntnis, die mich unwohl fühlen ließ, und die ich möchte, dass Sie wirklich verinnerlichen.

karthikmudunuri ist der primäre Experte für den Presentation Maker, mit 51 von 58 Pull Requests dieser Komponente. Das sind 88% eines gesamten Produktbereichs. Volumen ist nicht sein Problem. Er ist Letzter auf der Rangliste, mit 300 Punkten.

Es gibt eine Kombination, die genau auf diese Zahl kommt: vier P1-Pull-Requests in einer 1,5x-Komponente und sonst nichts, das Punkte bringt. 4 × 50 × 1,5 = 300. Sein Badge zeigt 4 P1, was passt. Ich kann nicht beweisen, dass das die tatsächliche Aufschlüsselung aus diesem Dashboard ist, und ich möchte die Ungenauigkeit ehrlich anmerken, denn die Rangliste deckt 30 Tage ab, während die Komponentendiagramme den 6. Juli bis 3. August abdecken, also sind die beiden Fenster nah beieinander, aber nicht identisch.

Wenn die Zerlegung stimmt, haben etwa 47 gemergte Pull Requests null Punkte erzielt. Es gibt nur zwei Erklärungen. Entweder handelte es sich um echte Low-Severity-Polish-Arbeiten, dann ist die Bewertung korrekt und die sinnvolle Diskussion dreht sich darum, ob wir eine Person einen Monat lang mit 88% Konzentration an einer Komponente arbeiten lassen sollten, die wir nicht als wichtig markiert haben. Oder es war echte Arbeit, die von der Eligibility-Gate auf null gesetzt wurde, dann ist die Bewertung falsch und das Tool schuldet ihm eine Erklärung.

Die Bewertung ist Alles-oder-Nichts bei der Eligibility. Wenn ein aktiviertes Kriterium nicht erfüllt wird – die Standardkriterien sind Issue-Verknüpfung, Fix-Implementierung, PR-Beschreibungsqualität, Tests, wenn das Modell Tests für erforderlich hält, und eine Obergrenze von 3.000 Zeilen –, dann ist die Punktzahl unabhängig vom Schweregrad null. Ein wirklich kritischer Fix mit einer schlechten Beschreibung erzielt genauso viele Punkte wie gar nichts.

Ich weiß nicht, welche Erklärung richtig ist, und hier ist meine eigentliche Beschwerde: Das Dashboard sollte mir pro Pull Request sagen können, und heute zwingt es mich, es aus einer Gesamtsumme zurückzuentwickeln. Das ist eine echte Lücke in unserem Produkt und wird gerade behoben. Es ist auch genau der Fehlermodus, den Menschen an Bewertungssystemen fürchten, also werde ich nicht so tun, als hätte ich ihn in einem Design-Review entdeckt. Ich habe ihn beim Schreiben dieses Beitrags gefunden.

Wo die Bugs sind, ist eine Produktentscheidung, keine technische Entscheidung

Das andere, was aus der Bewertung jedes Pull Requests folgt, ist, dass man aufhört, über Qualität anhand von Anekdoten zu diskutieren.

740 Pull Requests über die zehn aktivsten Komponenten. 230 davon, 31%, waren Bugfixes statt neuer Arbeit. Chat allein hat 230 Pull Requests, ebenfalls 31%, was so aussehen soll, wenn ein 2,0x-Multiplikator funktioniert.

Dann gibt es den Präsentationsersteller: 58 Pull Requests, 23 davon Bugs. Das ist eine Bug-Rate von 40% in einer Komponente mit vier Mitwirkenden, verglichen mit 25% im Chat mit sieben. Und Zahlungen hat 44 Pull Requests mit 20 Bugs, eine Rate von 45%, in der Komponente, die mit Geld zu tun hat.

Chat und Agents liegen mit je 57 Bugs gleichauf, aber Chat produzierte diese über 230 Pull Requests und Agents über 148. Gleiche Bug-Anzahl, 55% mehr Arbeit hinter einem von ihnen. Das ist ein Signal über Agents, das keine Retrospektive jemals ans Licht gebracht hätte, weil keine einzelne Person im Team genug von beiden gemergt hat, um es zu bemerken.

Die Bug-Linie und die Feature-Linie steigen im Zeitfenster gemeinsam an, statt sich abzuwechseln, was die gewünschte Form ist und nicht die, die ich erwartet hatte. Ich lese dieses Diagramm als deskriptiv, nicht als Behauptung, dass wir etwas verbessert haben. Es umfasst fünf Wochen und der Trend liegt innerhalb des Rauschens, das man von der Landung eines einzelnen großen Projekts erwarten würde.

Hier liegt unser eigenes Tool derzeit falsch

Wenn ich Ihnen nur die Teile zeigen würde, die funktionieren, wären Sie zu Recht skeptisch. Also:

• Der Prompt-Tab tut nicht, was er auf dem Produktionspfad verspricht. Es gibt einen Admin-Bildschirm, mit dem Sie den Evaluierungs-Prompt anpassen können. Er steuert den Batch-Evaluierungs-Runner. Der Webhook- und Cron-Pfad, der Pull Requests in der Produktion bewertet, verwendet einen im Quellcode hartcodierten Prompt. Wenn Sie diese Vorlage bearbeiten in der Erwartung, dass sie Ihre Live-Bewertungen heute ändert, wird sie das nicht, und nichts in der UI sagt Ihnen das.

• Die Spalte „PRs“ im Leaderboard des Dashboards ist keine Anzahl von Pull Requests. Es ist der Autorenschafts-Score. Sie können es im Screenshot oben sehen: Die oberste Zeile zeigt 3530 unter PRs und 3530 unter Score. Die eigenständige Leaderboard-Seite macht das richtig, mit getrennten Spalten für Pull Requests und Autorenschaft, also ist es eine Fehlbeschriftung auf dem einen Bildschirm, den tatsächlich jeder öffnet, was nahe am schlechtestmöglichen Ort dafür ist.

• Unser README veröffentlicht die falschen Punktwerte. Es sagt, P2 sei 25 Punkte und P3 10. Die Datenbank-Seeds sind 20 und 5, und der Konfigurations-Screenshot oben bestätigt 20 und 5. Die Dokumentation und die Software sind sich über die Bewertung uneinig, und die Software gewinnt.

• Der Review-Track ist so gut wie tot. Das Reviewen von Code anderer Leute bringt Punkte auf einer separaten Velocity-Leiter, wobei schnellere Reviews höher bewertet werden. Auf dem gesamten Leaderboard hat genau eine Person überhaupt Review-Punkte: 90 von insgesamt 10.415, also 0,86% von allem, was bewertet wurde. Was auch immer wir glauben, dass wir beim Code-Review incentivieren, wir tun es nicht. Der wahrscheinlichste Grund ist, dass der Review-Sync erst vor kurzem mit dem Sammeln begonnen hat, aber ich habe das nicht bestätigt, und bis ich es tue, ist die ehrliche Lesart, dass das Feature nicht ankommt.

• Unser eigenes FAQ behauptet eine Klassifikationsgenauigkeit von etwa 90% und ich kann das nicht belegen. Es gibt kein Eval-Set im Repository, kein Benchmark-Skript und kein begutachtetes Korpus hinter dieser Zahl. Es ist eine Behauptung, die ich von einem Anbieter nicht akzeptieren würde, und sie steht auf unserer eigenen Marketing-Seite. Sie wird entfernt.

Ein Scoreboard wird manipuliert, und unseres hat fast keine Abwehrmaßnahmen

Ich habe unseren Bewertungscode nach Anti-Gaming-Maßnahmen durchsucht. Hier ist die vollständige Liste dessen, was existiert.

Pull Requests mit über 3.000 geänderten Zeilen sind ausgeschlossen – das unterbindet die gröbste Form von Aufblähung. Selbst-Reviews zählen null Punkte und werden aus allen Leaderboard-Abfragen ausgeschlossen. Reviews von Konten mit [bot] im Login werden übersprungen. Das Modell wird gefragt, ob der Code tatsächlich das tut, was die Beschreibung behauptet – das kommt einem Unsinnsdetektor am nächsten. Admins können jede Punktzahl überschreiben, und die Überschreibung erfordert einen schriftlichen Grund von mindestens zehn Zeichen.

Was es nicht gibt: Kein wöchentliches oder monatliches Punktelimit pro Person. Keine abnehmende Rendite bei wiederholter Arbeit an derselben Komponente. Keinerlei zeitlichen Verfall, und das 30-Tage-Fenster im Leaderboard ist ein Standard-Datumsbereich, den jeder erweitern kann, keine Obergrenze. Keine Erkennung von Duplikaten oder Reverts – wer etwas repariert, das er letzte Woche kaputt gemacht hat, bekommt dafür genauso viele Punkte wie für die Reparatur eines fremden Fehlers. Keine Kollusionserkennung zwischen Reviewern. Und der Bot-Filter gilt für Reviewer, nicht für Pull-Request-Autoren – ein von einem Bot erstellter, gemergter Pull Request zählt also wie ein menschlicher, was 2026 keine hypothetische Situation mehr ist.

Jeder, der dieses System ausbeuten will, kann das. Arbeit auf mehr Pull Requests aufteilen, jeweils mit Issue-Link und sauberer Beschreibung, gezielt auf die 2.0x-Komponente. Das ist der Exploit, und ich möchte ihn genau deshalb benennen, weil er so aussieht: wie kleine, gut dokumentierte, gut getestete Änderungen am wichtigsten Teil des Produkts. Der effektivste Weg, unser Scoreboard zu betrügen, ist genau das zu tun, was wir wollen. Das ist kein Zufall, es ist das Designziel, und es ist die einzige Verteidigung gegen Goodharts Gesetz, die jemals wirklich funktioniert hat. Mach den Proxy so teuer zu fälschen, dass es sich nicht lohnt, es auf eine Weise zu tun, die nicht die echte Sache ist.

Es ist keine vollständige Verteidigung. Die Schwere wird von einem Modell vergeben, das einen Diff liest, und ein Modell kann durch eine ausreichend dramatische Pull-Request-Beschreibung dazu gebracht werden, einen mittelschweren Bug als schwerwiegend einzustufen. Wir haben nicht gemessen, wie oft das passiert. Niemand hat das. Wenn Sie ein Tool in dieser Kategorie evaluieren, auch unseres, ist das die Frage, die Sie stellen müssen – und „ungefähr 90 %“ ist keine Antwort.

Ich werde Ihnen die Steigerungszahl nicht nennen, weil ich keine habe

Hier ist die Behauptung, die ich gerne aufstellen würde. Seit wir dieses Leaderboard monatlich veröffentlichen, hat sich die Arbeit sichtbar in Richtung der Komponenten verschoben, die wir als wichtig markiert haben, weil Ingenieure die Punktzahl wollen.

Hier ist, warum ich sie nicht als Zahl nenne. Wir haben das mitten im Betrieb eingeschaltet, ohne saubere Basislinie, ohne Kontroll-Repository und ohne vorab registrierte Definition dessen, was „verschoben“ bedeuten würde. Die Multiplikatoren haben sich im Zeitraum geändert. Ebenso Personalbestand und Roadmap. Jeder Prozentsatz, den ich veröffentlichen würde, wäre eine Zahl, die ich nach dem Betrachten der Daten ausgewählt hätte – das ist keine Messung, sondern Dekoration.

Was ich Ihnen sagen kann, ist qualitativ, und ich kennzeichne es als solches. Die Argumente haben sich geändert. Die Leute haben aufgehört, mich zu fragen, ob ihre Arbeit geschätzt wird, und haben angefangen zu fragen, warum eine Komponente mit 1,0x bewertet ist. Das ist eine viel bessere Diskussion, und es ist das Einzige, wofür ich allein schon bezahlt hätte.

Wenn ich jemals ein echtes Vorher-Nachher habe, werde ich zuerst die Methodik veröffentlichen und dann die Zahl. Wenn ich es andersherum veröffentliche, glauben Sie mir nicht.

Richten Sie es an der Roadmap aus, dann geben Sie den Leuten das Lineal in die Hand

Ich möchte oberhalb des Produkts enden, denn das Produkt ist das am wenigsten Interessante hier.

Der eigentliche Job des Organigramms war nie Autorität. Es war Routing. Es trug die Antwort auf „Was ist dieses Quartal wichtig?“ von den Entscheidern nach außen und die Antwort auf „Wer hat was getan?“ nach innen – und es tat beides schlecht, langsam und mit enormer Verzerrung auf jedem Hop. Alles, was Sie an Unternehmenspolitik nicht mögen, ist ein Kompressionsartefakt dieses Routings. Manager waren nicht die Ursache. Sie waren die einzige verfügbare Hardware.

Sie sind nicht mehr die einzige verfügbare Hardware. Ein Modell, das jeden Diff plus eine Tabelle mit Multiplikatoren liest, erledigt das Routing nach außen in einem Hop und das Routing nach innen in einer Abfrage. Was für die Menschen übrig bleibt, ist der Teil, der immer der eigentliche Job war und für den nie Zeit blieb: zu entscheiden, was die Multiplikatoren sein sollten, und mit den Leuten zusammenzusitzen, deren Punktzahlen durch diese Entscheidungen bewegt wurden.

Die Politik verschwindet nicht. Lassen Sie sich das von niemandem verkaufen. Sie verschiebt sich. Sie verschiebt sich von „Erinnert sich mein Manager an mein Quartal?“ zu „Warum ist meine Komponente mit 1,0x bewertet, wenn die Roadmap sie als Kernkomponente ausweist?“, und dieser zweite Kampf ist ein Kampf um die tatsächliche Strategie des Unternehmens, ausgetragen in der Öffentlichkeit, in einer Tabelle, die jeder lesen kann. Ich würde diesen Kampf lieber jeden Monat führen als den aktuellen, der einmal im Jahr, hinter verschlossenen Türen, von jemandem geführt wird, der elf Monate aus dem Gedächtnis rekonstruiert.

Jemand wird das schlecht machen. Jemand wird ein Scoreboard an die Wand hängen, ohne Erklärungen zur Berechtigung und ohne Override-Trail, und das untere Dezil feuern – und es wird eine Katastrophe sein, und sie wird dem Modell angelastet werden, nicht der Person, die die Multiplikatoren gewählt hat. Das ist der Teil, der bezahlt wird, und er wird nicht von demjenigen bezahlt, der es eingerichtet hat.

Also messt mich mit demselben Instrument. Wenn Sie so etwas betreiben, veröffentlichen Sie drei Dinge neben dem Leaderboard: die Multiplikatortabelle, damit die Leute über die Strategie diskutieren können und nicht über die Punktzahl. Die Aufschlüsselung pro Pull Request, damit jeder, der null Punkte bekommen hat, sehen kann, welche Hürde ihn ausgebremst hat, und Einspruch einlegen kann. Und das Override-Log, denn die Zahl, die ein Mensch geändert hat, ist die einzige Zahl, die einer Prüfung wert ist.

Wir veröffentlichen derzeit das Erste. Das Dritte machen wir schlecht: Ein Override schreibt seinen Grund in die Evaluierungszeile, und das Löschen des Overrides löscht den Grund mit – wir haben also eine Notiz, die widerrufen werden kann, kein Log. Und das Zweite veröffentlichen wir nicht gut genug, was ich erst herausfand, als ein Entwickler mit 88 % einer Komponente auf meinem eigenen Leaderboard ganz unten landete und ich ihm nicht erklären konnte, warum.

*GitRank ist unter gitrank.dev zu finden und ist unter CC BY-NC 4.0 lizenziert. Das Scoring auf dem Produktionspfad läuft auf Claude Haiku 4.5 mit einer Temperatur von 0,3. Alle obigen Zahlen stammen aus unserem eigenen Plattform-Repository zwischen dem 6. Juli und dem 3. August 2026, Stichprobengröße ein Unternehmen und sieben Entwickler, was eine Beschreibung von uns ist und kein Benchmark für irgendetwas.