DoMe Dynamics
AI Agent Systems
Messdaten & Methodik

Woher die Zahlen kommen.

Diese Website zeigt an vielen Stellen Messwerte: Commit-Verläufe, Projektstände, Ereignisse aus laufenden Sitzungen. Auf dieser Seite erkläre ich, wie diese Daten entstehen — und warum ich sie von Anfang an gesammelt habe.

Meine Ausbildung liegt in der Messtechnik. Wer misst, lernt früh: Ein einzelner Wert sagt wenig, eine lückenlose Reihe dagegen viel. Deshalb habe ich beim Aufbau der Werkstatt mitgeschrieben, sobald es technisch möglich war oder mir die Idee dazu kam. Jeder Messwert ist am Ende ein Datenpunkt, und mehr Datenpunkte sind besser.

Zuletzt aktualisiert:

Erhebung

Vier Wege, auf denen Daten entstehen

Commit-Verläufe aus der Git-Historie

Die Werkstattchronik zählt Commits pro Projekt und Monat. Grundlage ist ein datierter Auszug aus der Git-Historie aller Projekt-Repositories; der Stichtag steht direkt an der Chronik. Die Zahlen werden nicht von Hand gepflegt, sondern aus der Historie erzeugt und gegen sie geprüft.

Ereignisse aus laufenden Sitzungen

Hooks (kleine Programme, die an definierten Stellen einer Agenten-Sitzung anspringen) melden jeden Werkzeugaufruf als Ereignis. Aus diesen Ereignissen entstehen die Live-Ansicht und das Replay der Kontrollschicht. Die Demo auf dieser Website läuft mit synthetischen Beispieldaten; die echten Ereignisse bleiben auf meinem Rechner.

Verbrauch und Kosten

Was die Arbeit mit den Agenten verbraucht, rechne ich täglich aus den Sitzungsprotokollen beider Rechner zusammen (ccusage, ein Kommandozeilenwerkzeug für Claude-Code-Verbrauchsdaten). Dabei habe ich gelernt, dass sich die hinterlegten Preistabellen über Nacht ändern können — seitdem ist die Version festgehalten, damit die Messreihe vergleichbar bleibt. Konkrete Beträge veröffentliche ich hier nicht.

Projektstände aus Scannern

Ein täglicher Scan kartiert die Projektlandschaft für die Systemkarte. Die Kennzahlen des DCO übernimmt die Website aus einer Betriebsdatei, die vor jeder Übernahme validiert wird; schlägt die Validierung fehl, bleibt der letzte gute Stand stehen.

Verifikation

Der Build prüft mit

Bevor eine Seite dieser Website gebaut wird, prüft der Build die öffentlichen Zahlen gegen ihre Quelldaten. Die „Zuletzt aktualisiert"-Stempel und die Sitemap-Daten kommen aus der Git-Historie der jeweiligen Seite, nicht aus einer Handeingabe. Und ob ein Projekt-Repository wirklich öffentlich ist, wird gegen GitHub abgeglichen, bevor die Seite es behauptet.

  1. 1

    Quellen

    Git-Historie · Hook-Ereignisse · Scans

  2. 2

    Generator-Skripte

    erzeugen die Datendateien der Site

  3. 3

    Build-Prüfung

    gleicht Aussagen gegen die Quelldaten ab

  4. 4

    Seite

    zeigt nur, was die Prüfung bestanden hat

Ehrlichkeit

Grenzen dieser Messungen

Drei Grenzen gehören dazu. Snapshots veralten zwischen den Stichtagen — eine Zahl auf der Chronik ist so aktuell wie ihr Stichtag. Die Replay-Demo der Kontrollschicht zeigt synthetischen Beispieldaten nachempfundene Abläufe, weil die echten Sitzungsprotokolle privat bleiben. Und private Repositories lassen sich hier nur beschreiben, nicht öffnen; auf Anfrage zeige ich sie im Gespräch.