Häufig gestellte Fragen

Nein — keine Zeiterfassung, keine Bildschirmaufzeichnung, kein Erfassen von Tastenanschlägen. Wir analysieren nur die Code-Änderungen selbst und schätzen ihre kognitive Schwierigkeit in Referenz-Entwicklerstunden. Es ist ein Maßstab, kein Stundenzettel.

Wie lange ein Entwickler mittlerer Erfahrung (3–4 Jahre), der die Codebasis kennt und ohne KI arbeitet, für die Änderung bräuchte. Sie misst die Schwierigkeit der Arbeit — nicht Zeilen und nicht die tatsächlich am Schreibtisch verbrachte Zeit. Sie umfasst das Schreiben von Code, manuelles Testen und Review-Korrekturen; Meetings, Planung und Wartezeiten auf Reviews sind ausgeschlossen.

Es ist nicht „ein Aufruf an ein neuronales Netz“, sondern eine mehrstufige Pipeline, in der KI nur eine Ebene ist. Zuerst liest ein Modell die Code-Änderungen selbst — was sich tatsächlich geändert hat — und beurteilt die kognitive Schwierigkeit für einen Referenz-Entwickler, statt Zeilen oder Commits zu zählen. Darauf läuft eine deterministische, algorithmische Schicht: Das System klassifiziert die Art jeder Änderung, erkennt risikoreiche Arbeit gesondert (zum Beispiel Infrastruktur, Datenmigrationen, Sicherheit), filtert mechanische und generierte Änderungen heraus (massenhaftes Suchen und Ersetzen, generierter und verschobener Code, Formatierung) und wendet Korrekturregeln und Schutzmechanismen an, sodass eine einzelne Modellschätzung das Ergebnis nicht verzerren kann. Große und kombinierte Commits werden detaillierter behandelt. Derselbe Maßstab wird automatisch auf alle angewendet, jeder Commit wird einmal bewertet und das Ergebnis festgehalten — daher sind die Zahlen vergleichbar und reproduzierbar.

Sie ist aus realer Enterprise-Entwicklung entstanden: Die algorithmische Schicht bildet empirische Muster ab, die in echten Projekten gesammelt wurden — welche Änderungen meist aufwendiger sind, als sie zunächst wirken, und welche trotz ihrer Größe wenig Aufwand verursachen. Diese Regeln werden gegen echte Referenzschätzungen geprüft (Kalibrierung). So verhält sich das System eher wie ein erfahrener Tech Lead, der Arbeit beurteilt, als wie ein einfacher Zeilenzähler.

Im Gegenteil — genau darum geht es. Wir vergleichen Ihr Team mit einem Referenz-Entwickler, der ohne KI arbeitet; wenn KI es Ihnen ermöglicht, pro Tag mehr zu liefern, steigt Ghost%, und genau diese Lücke zur „Norm vor KI“ macht DevGhost sichtbar. Das ist keine Verzerrung — das ist das Ergebnis.

Das Verhältnis Ihrer Tagesleistung zur Leistung des Referenz-Entwicklers. 100 % entspricht der Referenz; höher bedeutet, dass Sie pro Tag mehr liefern, niedriger bedeutet weniger. Es sind keine Stunden und keine Überstunden: Eine hohe Zahl bedeutet nicht „Burnout“, und ein niedriger Wert allein bedeutet nicht „schwach“.

Es ist ein Modell, keine Messung. Niemand kann die reale Zeit rekonstruieren, daher liegt der Wert in einem einheitlichen Regelsatz für alle: aussagekräftig für Trends und Vergleiche, nicht für stundengenaue Präzision bei einer einzelnen Person. Ein Werkzeug, um bessere Fragen zu stellen, nicht um Urteile zu fällen.

Aufteilen und Kombinieren von Commits haben kaum Einfluss — bewertet werden Substanz und Schwierigkeit der Änderungen, nicht die Anzahl der Commits oder Zeilen. Wichtiger noch: Jede Kennzahl, an der Menschen direkt gemessen werden, wird irgendwann optimiert, statt die eigentliche Arbeit zu verbessern. Nutzen Sie sie also als Team-Signal und Trend, nicht als persönliche KPI — dann gibt es nichts auszutricksen.

Das System sieht Code, nicht die gesamte Rolle: Design, Reviews, Mentoring, Planung und Meetings sind nicht in der Schätzung enthalten. Eine Diskrepanz bedeutet oft, dass ein Großteil des Wertes einer Person außerhalb von Commits liegt — was an sich bemerkenswert ist.

Nicht automatisch: Es sieht nur Code und kennt die reale Rolle und Auslastung einer Person nicht (Reviews, Mentoring, Meetings, Support). Nur die Führungskraft kennt die volle Auslastung. Dafür gibt es den Parameter „Anteil“ — den Anteil der Zeit, die eine Person tatsächlich mit dem Schreiben von Code verbringt (0–100 %). Standardmäßig sind es 100 % (wir nehmen an, dass die Person vollständig am Code arbeitet); die Führungskraft senkt ihn manuell, um Arbeit außerhalb des Codings abzubilden — hier gelangt Kontext in das System, den der Code nicht enthält. Dann wird der Vergleich mit der Referenz auch für diejenigen fair, die nicht den ganzen Tag programmieren.

Nicht isoliert. Es ist ein Team-Signal und ein Trend, um ein Gespräch zu beginnen, kein individuelles Urteil: Eine einzelne Kennzahl erfasst weder Qualität noch Wirkung noch Kontext.

Kosten geben grob an, was die gelieferte Arbeit zu einem Standardsatz gekostet hat; Wert gibt grob an, was es kosten würde, dieses Volumen ohne KI von Hand zu reproduzieren. Die Lücke zwischen beiden ist ein näherungsweiser Indikator für Hebelwirkung (Tooling/KI), keine Gewinn- und Verlustrechnung.