Der Satz, dass KI die Kosten gesenkt hat, überzeugende Belege für Produktivität zu produzieren, trifft genau den wunden Punkt. Bei uns war das Erste, was sich verändert hat, nicht der Code, sondern die PR-Beschreibungen. Plötzlich liest jeder Pull Request wie ein Design Doc, drei Absätze Begründung für eine Zeile Änderung. Das Schwierige im Engineering war nie das Tippen. Es war die Entscheidung, einer Race Condition unter Last nachzugehen statt sie als Flaky abzustempeln, und genau die Entscheidung lässt sich nicht prompten. Die Metrik, die das belohnt, gibt es bis heute nicht.
Lässt sich mit KI kaum noch unterscheiden, wer wirklich gut programmiert und wer nur Lärm macht?
Öffentlich
14 Gespräche
19 Gedanken
68 Zustimmungen
14 Ablehnungen
0 Serien
Ich höre dasselbe Feedback in immer neuen Formen: „starke Velocity“, „toller Throughput“, „schöner Einsatz von KI“. Von außen sieht es wirklich so aus, als würde mehr passieren: mehr Code Reviews, mehr angefasste Tickets, mehr Updates, mehr E-Mails, mehr Tasks, mehr Designs. Mit KI lässt sich diese Schlagzahl mühelos halten, ohne die übliche Reibung des Schreibens, des Denkens oder auch nur des Zögerns. Aber mitten in der Arbeit steckt ein Dilemma, das immer größer wird.
In groups
Gedanke
Gedanke
Der Satz, dass KI die Kosten gesenkt hat, überzeugende Belege für Produktivität zu produzieren, trifft genau den wunden Punkt. Bei uns war das Erste, was sich verändert hat, nicht der Code, sondern die PR-Beschreibungen. Plötzlich liest jeder Pull Request
Beitragsinhalt
Ich höre dasselbe Feedback in immer neuen Formen: „starke Velocity“, „toller Throughput“, „schöner Einsatz von KI“.
Von außen sieht es wirklich so aus, als würde mehr passieren: mehr Code Reviews, mehr angefasste Tickets, mehr Updates, mehr E-Mails, mehr Tasks, mehr Designs. Mit KI lässt sich diese Schlagzahl mühelos halten, ohne die übliche Reibung des Schreibens, des Denkens oder auch nur des Zögerns. Aber mitten in der Arbeit steckt ein Dilemma, das immer größer wird.
Da ist das eigentliche Engineering: einer Race Condition nachjagen, die nur unter Last auftaucht, oder merken, dass ein „simpler“ Bug in Wahrheit eine kaputte Annahme im Design ist. Oder entscheiden, ein System nicht zu refactoren, nur weil es unordentlich ist, weil es noch läuft und das Risiko es nicht wert ist. Dieser Teil wird mit KI nicht schneller. Machst du die Arbeit, die KI auch kann, und hast dann viel niedrigere Metriken als die anderen Engineers? Oder promptest du einfach den ganzen Tag und produzierst durchgehend Code und Designs? Suchst du nach Lösungen ganz OHNE Code, oder lässt du dir von der KI einen Haufen Features, Systeme, Designs hinwerfen? Tja … ich weiß es auch nicht.
Dann ist da das ganze Drumherum. Mit KI ist es trivial, einen großen „Cleanup“-Refactor zu erzeugen, der Dateien umbenennt und Module umsortiert, damit der Code in einem PR besser aussieht. Oder eine breite Test Suite hochzuziehen, die den Eindruck von Coverage macht, ohne die Failure Modes zu treffen, auf die es ankommt. Oder eine einzige zusammenhängende Änderung in zehn kleinere PRs zu zerlegen, damit der Activity-Graph gesünder wirkt. Sogar die Dokumentation wird da reingezogen, polierte, ausufernde Docs, die sich gut lesen … aber nie mehr wirklich gelesen werden, weil zu viel Rauschen unterwegs ist. Wir prompten die KI, Designs zu erzeugen, und dann prompten unsere Reviewer die KI, sie zusammenzufassen und zu reviewen. Und das Management scheint es zu lieben.
Das Verhalten im Engineering richtet sich nach den KPIs, die zählen. Mehr inkrementelle Commits, mehr PR-Fragmente, mehr „dabei hat mir KI geholfen“-Notizen, die signalisieren, dass man im erwarteten Workflow mitspielt. Selbst wenn die eigentliche Arbeit nach wie vor der langsame Teil ist, Debugging, Durchdenken, Nein sagen zu unnötigen Änderungen, muss sie immer öfter in Artefakte verpackt werden, die nach Momentum aussehen. Wir wollen alle unseren Job behalten.
Das Unangenehme daran ist, dass KI nicht einfach die Produktivität erhöht hat. Sie hat die Kosten dafür gesenkt, überzeugende Belege für Produktivität zu produzieren. Und sobald das leicht wird, fängt es an, mit der schwierigeren Frage zu konkurrieren, ob überhaupt irgendetwas davon wirklich etwas gebracht hat.
Thoughts
-
Ich sehe das Problem, aber das ist nicht neu, KI hat es nur billiger gemacht. Vor zwei Jahren hat jemand seine Arbeit in zehn Commits zerteilt, damit der Graph grün aussieht, heute lässt er es die KI tun und schafft hundert. Was sich wirklich geändert hat, ist das Verhältnis. Wer die Pipeline am Laufen hält, einen Flaky Test debuggt, der nur dienstags um drei kippt, produziert weiterhin genau ein Artefakt: das System läuft. Daneben sieht jeder Prompt-Tag aus wie ein Feuerwerk.
-
Aus der Product-Ecke betrachtet ist das fast vorhersehbar. Du beschreibst sauber, was passiert, wenn Output messbar ist und Urteil nicht:
Sichtbares wird belohnt, also wandert die Arbeit dorthin, wo sie sichtbar wird.
Das Management liest Activity-Graphen, weil sie existieren, nicht weil sie etwas bedeuten.
Das Nein zu einer unnötigen Migration taucht in keinem Dashboard auf, kostet aber am meisten Mut.
Das eigentliche Versagen ist nicht die KI, es ist, dass wir nie eine Sprache hatten, um zurückgedrehtes Risiko zu belohnen. Jetzt fällt das nur stärker auf, weil die Gegenseite so laut geworden ist.
-
Dein stärkster Punkt ist der über die Dokumentation, die sich gut liest und nie wieder gelesen wird. Das passiert im Frontend seit Jahren, lange vor der KI. Du baust eine saubere Komponente, die einen kaputten Datenfluss zwei Ebenen weiter oben kaschiert, und alle loben das UI, weil das UI das Einzige ist, das sie anklicken können. KI hat das nur skaliert: Jetzt kannst du die Verwirrung im Designprozess auch noch poliert ausformulieren lassen. Die Arbeit, die wirklich zählt, war immer das Weglassen, und Weglassen erzeugt kein Artefakt.
-
Der Satz, dass KI die Kosten gesenkt hat, überzeugende Belege für Produktivität zu produzieren, trifft genau den wunden Punkt. Bei uns war das Erste, was sich verändert hat, nicht der Code, sondern die PR-Beschreibungen. Plötzlich liest jeder Pull Request wie ein Design Doc, drei Absätze Begründung für eine Zeile Änderung. Das Schwierige im Engineering war nie das Tippen. Es war die Entscheidung, einer Race Condition unter Last nachzugehen statt sie als Flaky abzustempeln, und genau die Entscheidung lässt sich nicht prompten. Die Metrik, die das belohnt, gibt es bis heute nicht.
-
Eine einzige Änderung in zehn PRs zu zerlegen, damit der Activity-Graph gesünder wirkt. Schön, dass das jetzt jemand ausspricht. Bei uns hieß das „inkrementell liefern“ und stand in den Engineering Values an der Wand, gleich neben dem Konferenzraum, der freitags um 17:30 gebucht war. Du baust dir einen Friedhof aus kleinen grünen Quadraten und nennst es Momentum.