Zeilenzahl im Code hat nur eine bessere PR bekommen

• Die Bewertung der Produktivität von Entwicklerinnen und Entwicklern sollte anhand von Ergebniskennzahlen wie Kundennutzen, Umsatz und Zuverlässigkeit erfolgen, nicht anhand der Code-Menge
• Die jüngsten PR-Zahlen zum KI-Coding von Google, Anthropic, OpenAI und Cursor konzentrieren sich alle auf Mengenangaben wie den Anteil generierten Codes oder die Zahl der Codezeilen
• Die frühere Behauptung von GitHub Copilot, die Arbeitsgeschwindigkeit um 55 % zu steigern, war ein überprüfbares Ergebnis; der „Anteil von KI geschriebenen Codes“ kann dagegen wachsen, ohne dass sich irgendetwas verbessert
• Die tatsächliche Forschung ist widersprüchlich: von +26 % Abschlussrate bei Cui et al. über METRs „19 % langsamer“ und späteren Widerruf bis zu Umfragen, nach denen 90 % der Unternehmen keinen messbaren Effekt sehen — der Effekt auf Organisationsebene liegt bei etwa 10 %
• KI-Einführung ist notwendig, aber die Leistungsmessung sollte auf DORA-Metriken, Zuverlässigkeit, Geschwindigkeit sinnvoller Änderungen, Umsatz und Kundennutzen beruhen — also auf bewährten Kriterien

---

Die Rückkehr der Metrik „Codezeilen“

• Vor 15 Jahren hätte man in einem SaaS-Unternehmen nicht allein deshalb sagen können, dass einer von zwei Senior-Entwicklern besser ist, nur weil er 40 % mehr Code geschrieben hat
  • Entscheidend ist, was tatsächlich ausgeliefert wurde und welchen Beitrag das zu Kundinnen und Kunden, Umsatz und Stabilität geleistet hat; Codezeilen und PR-Anzahl gelten seit Jahrzehnten als schlechte Messgrößen
• Die wichtigsten Kennzahlen, mit denen die Branche 2026 wirbt, konzentrieren sich alle auf den Anteil von KI geschriebenen Codes
  • Google: 75 % des neuen Codes werden von KI erzeugt
  • Anthropic: etwa 80 % des zusammengeführten Produktionscodes von Claude geschrieben, Ingenieurinnen und Ingenieure liefern pro Quartal „8-mal mehr Code“ aus
  • OpenAI: ebenfalls rund 80 %
  • Cursor: „mehr als 100 Millionen Zeilen Enterprise-Code pro Tag geschrieben“
• All diese Zahlen sind Volumenbehauptungen, und der „Anteil von KI geschriebenen Codes“ ist letztlich nur Codezeilen mit raffinierterer PR
  • Dass es sich bei all diesen Unternehmen um KI-Anbieter handelt, ist ein starker Anreiz, die Adoptionsrate aufzublähen

Früher wurden Ergebnisse behauptet

• Vor einigen Jahren unterschieden sich die zentralen Kennzahlen nicht nur im Ausmaß, sondern grundlegend in ihrer Art
  • GitHubs zentrale Behauptung war, dass sich Aufgaben mit Copilot 55 % schneller erledigen lassen
  • Das wurde viel kritisiert, war aber eine Ergebnisbehauptung: gewagt, widerlegbar und auf Wert bezogen — wenn sie falsch war, konnte man das nachweisen
• Die Behauptungen von 2026 sind so aufgebaut, dass sie nicht scheitern können
  • „75 % des Codes sind von KI geschrieben“ kann wahr sein und weiter steigen, ganz unabhängig davon, ob tatsächlich schneller ausgeliefert wird, weniger Ausfälle auftreten oder die Kundenzufriedenheit steigt
  • Volumenkennzahlen enttäuschen nur dann, wenn die Adoption stagniert — und dass die Adoption real ist, bestreitet kaum jemand
• Die Behauptungen sind größer geworden, aber sie sagen weniger aus

Der Teil, der es nicht aufs Werbeplakat schafft

• Inzwischen ist die Evidenz zu Ergebnissen deutlich komplizierter geworden

• Ergebnisse, die die Adoption stützen

  • Cui et al.: Bei rund 5.000 Entwicklerinnen und Entwicklern +26 % erledigte Aufgaben, mit den größten Verbesserungen bei Junior-Entwicklern — daran gibt es kaum etwas zu rütteln

• Evidenz in die andere Richtung

  • GitClear: Mit tieferer Copilot-Adoption nimmt das Code Churn zu, Refactoring zerfällt
  • METR: Erfahrene Open-Source-Entwickler waren bei Nutzung von KI in ihrer eigenen Codebasis 19 % langsamer, glaubten aber selbst, sie seien 20 % schneller

• METRs Kurswechsel

  • Im Februar 2026 zog METR die Position faktisch zurück — eine Folgeschätzung kippte in Richtung Beschleunigung (speedup), bei sehr großer Fehlerspanne
  • Entwicklerinnen und Entwickler weigerten sich inzwischen, ohne KI zu arbeiten, und konnten den Zeitaufwand agentischer Arbeit nicht zuverlässig selbst berichten, sodass das Studiendesign selbst verworfen wurde
  • Die aktuelle Position lautet: 2026 erhöht KI wahrscheinlich die Entwicklungsgeschwindigkeit, aber das Ausmaß lässt sich nicht sauber messen

• Effekt auf Unternehmensebene

  • NBER-Umfrage unter rund 6.000 Führungskräften: 69 % der Unternehmen nutzen KI, etwa 9 von 10 berichten aber keinen messbaren Produktivitätseffekt
  • Der forschungsübergreifende Konsens liegt bei etwa 10 % Verbesserung auf Organisationsebene — nützlich, aber weit entfernt von „Entwickler werden nicht mehr gebraucht“
• Auch Skeptiker, die weiterhin nur „19 % langsamer“ zitieren, betreiben Cherry-Picking; die Forschung wird laufend aktualisiert, und die Branche hat lediglich den Messgegenstand gewechselt

Die KI-Version der Vanity-Metrik

• Das Problem betrifft nicht nur Behauptungen von KI-Anbietern

• Reifegradmodelle und Leitern

  • Carnegie Mellon SEI und Accenture haben vor wenigen Tagen das AI Adoption Maturity Model veröffentlicht — 5 Stufen, 8 Dimensionen, mit der Statistik „95 % der Organisationen haben keinen Ertrag“ als Marketingmaterial
  • Steve Yegges „8 levels of AI-assisted development“ ordnen danach, welche Tools genutzt werden und wie stark überwacht wird
  • Jeder Tool-Anbieter veröffentlicht Reifegradleitern, und an der Spitze steht meist „mehr vom eigenen Produkt verwenden“
  • Diese Leitern messen in Wahrheit die Intensität der Adoption und nennen das Reife — dieselbe Ersetzung in anderer Verpackung

• Begriffsverwirrung

  • Als Augment 219 Engineering-Leads fragte, wie sie „AI-native engineering“ definieren, kamen 219 unterschiedliche Antworten heraus

• Die zwei Seiten von Anthropic

  • Gleichzeitig wird behauptet, man liefere „8-mal mehr Code“ aus, und es wird eine der methodisch strengsten Studien des Jahres vorgelegt
  • Das RCT-Ergebnis: Mit KI-Unterstützung entwickelnde Personen erzielten beim Verständnis des gerade veröffentlichten Codes 17 % schlechtere Werte, bei statistisch nicht signifikantem Produktivitätsgewinn
  • Der Forschungsteil aktualisiert seine Aussagen, der Marketingteil zählt Volumen — beides kann gleichzeitig wahr sein

Warum das wichtig ist

• Diese Zahlen sind keine Dekoration, sondern bewegen Budgets, Leistungserwartungen und Personalplanung

• Entlassungen mit KI als Begründung

  • Im Februar strich Jack Dorsey bei Block mehr als 40 % der Belegschaft (4.000+ Personen), wobei KI ausdrücklich als zentrales Argument genannt wurde — „kleinere Teams können mit den Tools, die wir bauen, mehr und besser leisten“
  • Wenige Wochen später baute Atlassian 10 % (rund 1.600 Personen) ab und räumte ein, es sei unehrlich zu tun, als würde KI die benötigte Skill-Zusammensetzung oder die Zahl der Rollen nicht verändern
  • Dorsey erwähnte in derselben Ankündigung, dass das Geschäft solide sei und der Bruttogewinn wachse

• Zweifel an Produktivitätsbehauptungen

  • Wenn „mit KI alle produktiver werden und deshalb weniger Personal nötig ist“, dann möchte man dafür Belege sehen — und derzeit gibt es sie aus Sicht des Autors nicht
  • Es müsste nachgewiesen werden, dass Teile der Belegschaft tatsächlich untätig oder unterausgelastet sind; Produkt- und SaaS-Unternehmen haben endlose Roadmaps, daher sollte zusätzliche Kapazität normalerweise in Kundennutzen und Geschwindigkeit fließen — sichtbar in MAU, Conversion und Umsatz
  • Wer sich stattdessen für Entlassungen entscheidet, signalisiert damit, dass Produktivitätsbehauptungen eher die PR-Rolle für Entscheidungen spielen, die aus anderen Gründen bereits getroffen wurden, etwa Überbesetzung oder Investorendruck
• Effizienzbasierter Personalabbau kann manchmal gerechtfertigt sein, aber dann sollte man nicht Token-Zahlen, den „Anteil von KI geschriebenem Code“ oder Reifegradleiter-Ränge nutzen, sondern bereits bestehende individuelle Leistungssysteme
  • Wenn die Auswahlgrundlage Vanity-Metriken sind, ist diese Auswahl nichts weiter als eine „Lotterie mit Lippenstift“

Fazit

• Das ist keine Anti-KI-Position; vielmehr sollten alle Ingenieurinnen und Ingenieure täglich KI nutzen
  • Ob man es AI-first oder AI-proficient nennt, spielt keine Rolle; wichtig ist, neue Tools und die neuesten Modelle neugierig auszuprobieren
  • Die Branche hat Hochsprachen, IDEs, Autovervollständigung, Agile und DevOps absorbiert, und es gab immer Nostalgiker, die sich dagegen sträubten — am Ende sind sie doch mitgegangen
  • Anders ist diesmal das Tempo — die Einführung der „Cloud“ konnte man jahrelang verschieben und trotzdem überleben, bei KI sind es vielleicht nur Monate
• KI-Adoption ist die Startlinie, nicht die Anzeigetafel
  • Wie man Engineering-Leistung misst, ist längst bekannt — DORA-Metriken, Zuverlässigkeit, Anteil sinnvoller Änderungen und letztlich Umsatz und Kundennutzen
  • Es gibt keinen Grund, bewährte Verfahren aufzugeben und durch KI-Vanity-Scores zu ersetzen
• Die Frage, die man in Vendor-Pitches, Executive-Reviews und im LinkedIn-Feed stellen sollte, lautet: „Ist das Ergebnis oder Volumen?“
• Die Arbeitsweise sollte AI-first sein, die Messweise bewährt (battle-tested)

[GN⁺]

Hacker-News-Kommentare

• Dieser seltsame Trend scheint seinen Höhepunkt im OpenAI-Blogpost vom Februar 2026 [1] erreicht zu haben. Das war kürzlich auf der Startseite [2] und beschrieb den Prozess, etwas zu bauen, das zu 100 % von einem Agenten geschrieben wurde
  Was dieses Ding eigentlich ist und welchen Wert es den Nutzern bietet, wird allerdings nicht erklärt. Die treffendste Beschreibung ist noch: „Dieses Produkt wurde intern von Hunderten genutzt, und es gibt auch interne Power-User, die es täglich verwenden.“
  Dass es sich um 1 Million Zeilen Code handelt, wird dagegen schon in den ersten paar Hundert Wörtern gleich zweimal wiederholt
  [1] https://openai.com/index/harness-engineering/
  [2] https://news.ycombinator.com/item?id=48416264

  • Wenn „dieses Produkt intern von Hunderten genutzt wurde und es interne Power-User gibt, die es täglich verwenden“, dann ist es wahrscheinlich ein E-Mail-Filter
    Wenn es „1 Million Zeilen Code“ sind und „zu 100 % von einem Agenten geschrieben“ wurde, dann erst recht. Oder vielleicht ist es ein JS-Menü für ein Abteilungs-Wiki, das im Grunde jquery in MS JScript neu implementiert und nach JS 5 transpiliert
  • Der gesamte Linux-Kernel hat etwa 40 Millionen Zeilen, und ohne Treiber sind es grob 16 Millionen. Selbst wenn dieses Ding, von dem OpenAI spricht, 6 % der Codezeilen des Linux-Kernels hat, ist kaum vorstellbar, dass sein Nutzen auch nur annähernd bei 6 % liegt
    So leistungsfähig LLMs auch sein mögen, wartbar dürfte das Ganze kaum sein
  • Auch um Anthropic herum ist das Reality-Distortion-Field stark. Anthropic veröffentlicht ebenfalls jede Menge inhaltsleere, unsinnige Blogposts, die komplett von AI geschrieben wirken, landen aber auf der Startseite und bekommen zuverlässig Hunderte Upvotes
  • War das nicht das hier?
    https://github.com/openai/symphony
  • Ich war enttäuscht, dass es so wenige Details gab. Deshalb denke ich, dass bald Open-Source-Projekte oder Versuche auftauchen werden, die zeigen, wie effektiv so etwas in der Praxis wirklich ist
    In einem Podcast-Interview hieß es, es sei eine Electron-App, die Nutzer herunterladen, und deshalb würden regelmäßig neue Builds erstellt. Siehe hier den Abschnitt „Autonomous Merging Flow“: https://www.latent.space/p/harness-eng

• Ich muss ständig an die Aussage von jemandem bei Microsoft denken, man wolle so etwas wie 1 Million Zeilen Code pro Ingenieur und Monat. Für die meisten Ingenieure, mit denen ich darüber gesprochen habe, klang das wie Satire, aber offenbar war es überhaupt nicht satirisch und spiegelte die Haltung vieler CEOs zu LLM-generiertem Code ziemlich gut wider
  Allerdings habe ich das Gefühl, dass die Überhitzung rund um das Erzeugen nicht wartbarer Mengen an Codezeilen in den letzten Monaten etwas nachgelassen hat. Praktischere und realistischere Sichtweisen werden öffentlich häufiger geteilt und scheinen nach und nach auch die obersten Ebenen einiger Tech-Unternehmen zu erreichen. Vielleicht ist noch nicht alles verloren

  • Ich habe früher einmal in einer Firma gearbeitet, die 80 % Code Coverage verlangte. Ein cleverer Contractor hatte ein Skript, das eine einzelne Datei mit skalierbarer Größe samt eigener Test-Suite erzeugte, sodass man auf 80 % bezogen auf die gesamte Codebasis kam
    In Wirklichkeit blieb der Großteil des Codes ungetestet
  • 1.000.000 / 25 / 8 / 60 = mehr als 83 Zeilen pro Minute
    1 Million Zeilen pro Monat / 25 Tage im Monat / 8 Stunden pro Tag / 60 Minuten pro Stunde
    Für die Person, die den Code Review machen soll, wirkt das nach einem ziemlich großen Problem
  • Es war wirklich lustig zu sehen, wie Führungskräfte plötzlich merkten, dass Tokens Geld kosten, und sofort die Richtlinien zur AI-Nutzung ihrer Mitarbeiter änderten
    Ingenieure jeden Monat 1 Million Zeilen Code erzeugen zu lassen, ohne darüber nachzudenken, wie diese Zeilen dem Unternehmen Geld einbringen sollen oder wie viele Tokens dabei zu welchen Kosten verbrannt werden, war offenbar kein besonders gut durchdachter Plan
  • Das Wort slop war eine gute Wahl, um massenhaft von AI generierten Code zu beschreiben. Es funktioniert auch bei Nicht-Technikern und transportiert den Ekel. Es ist sofort klar, dass slop etwas ist, das man vermeiden sollte
    Technische Schulden hingegen packen das Management nicht auf die gleiche Weise. Schulden gelten im Allgemeinen zwar als potenzielles Problem, aber als etwas, das man aufschieben kann, bis es tatsächlich zum Problem wird
  • Ich frage mich, ob der Rückgang der Überhitzung beim Produzieren nicht wartbarer Codezeilen in den letzten Monaten auch ein wenig damit zu tun hat, dass Leute aus Business und Produkt angefangen haben, AI tatsächlich in ihre tägliche Arbeit einzubauen
    Ich habe das in beiden kleinen Unternehmen gesehen, in denen ich arbeite. Vor ein paar Monaten bekamen wir Claude Cowork, alle waren total begeistert, und wir nutzen es immer noch täglich, aber verglichen mit der erwarteten Magie war es eher enttäuschend
    Es gibt Beschwerden, dass die Ergebnisse mittelmäßig und langatmig sind, selbst sehr einfache Dinge falsch machen, ständig an Token-Limits stoßen und man am Ende doch wieder lieber von Hand arbeitet, weil das schneller ist
    Anfangs mag ein Teil davon falsche Tool-Nutzung sein, aber die Leute merken inzwischen, dass zwischen dem, was AI-CEOs, LinkedIn-Händler und YouTube-Verkäufer von AI-Nahrungsergänzungsmitteln erzählen, und der Realität noch immer eine Lücke besteht

• Wenn ein Unternehmen sagt: „AI hat alle produktiver gemacht, deshalb brauchen wir weniger Leute“, würde ich dafür gern die Belege sehen. Im Moment glaube ich nicht, dass es solche Belege gibt
  In Wirklichkeit reden sie Unsinn und benutzen AI als Vorwand, um die Überbesetzung aus der Corona-Zeit zurückzudrehen. Gleichzeitig sieht es gegenüber Investoren so aus, als hätte man die neueste Mode-Technologie übernommen und sei nun schlanker und kosteneffizienter organisiert

  • Sich gegenüber Investoren als schlanker und kosteneffizienter darzustellen, weil man die neueste Mode-Technologie übernommen hat, ist nichts Neues. Es hat nur einen neuen Namen bekommen
  • Von Überbesetzung in der Corona-Zeit zu sprechen, ist eine ziemlich großzügige Ausrede. Für mich sieht das insgesamt eher nach einem Versuch aus, die Löhne zu drücken. Seitdem gab es mehrere Entlassungsrunden, deshalb klingt diese sechs Jahre alte Ausrede besonders hohl
    Ich dachte immer, Investoren legen mehr Wert auf Gewinne als auf die Übernahme der neuesten Mode-Technologie
    Und eine Firma, die sagt: „Wir benutzen auch die glänzende Technik, die jeder beliebige Idiot im Schlafzimmer nutzen kann!“, ist ohnehin eine Firma ohne jeden Wettbewerbsvorteil

• Es ist endlos absurd, dass unsere Branche jahrzehntelang erklärt hat: „Was wir tun, ist komplex und dauert lange, daher lässt sich Produktivität nicht einfach messen“, und dann mit dem Aufkommen von AI plötzlich Codezeilen, x-fache Multiplikatoren oder die Zahl der Tickets pro Woche als nützliche oder objektive Kennzahlen hochgejubelt werden.
  Die Gründe, warum wir Kennzahlen wie Codezeilen abgelehnt haben, haben sich nicht geändert. Entscheidend ist nicht die Menge des erzeugten Codes, sondern die Qualität des Ergebnisses. AI hat dieselben Probleme wie Menschen. Dass wir trotzdem alles Gelernte über Bord werfen, ist ehrlich gesagt peinlich.

  • Nicht-Techniker haben die Macht und sind nicht wie Ingenieure an die Realität gebunden. Am Ende wird die objektive Realität gewinnen, aber kurzfristige Schäden verhindert das nicht.
  • Haben wir wirklich jahrzehntelang erklärt, dass Produktivität sich nicht leicht messen lässt? In den letzten zehn Jahren habe ich nur gesehen, wie sowohl Ingenieure als auch Nicht-Ingenieure immer mehr den Github activity graph verehren. Meiner Meinung nach hatte sich dieser Basar schon vor AI verirrt.
  • Manche Gruppen von Softwareingenieuren haben vielleicht das Bedürfnis nach sorgfältiger Messung gestärkt. Aber das gesamte Feld der Programmierung hat sich nie wirklich von der Idee einfacher Kennzahlen gelöst.
    Denn lose eingebundene, aber aggressive und fordernde Manager gab es schon immer. Leider haben auch Manager, deren Hauptaufgabe darin besteht, mehr Einsatz aus Mitarbeitern herauszupressen und die zu Koordination oder Ähnlichem nichts beitragen, einen wirtschaftlichen Wert.
    Deshalb gab es immer zwei sich überlappende Denkwolken: den Ansatz mit realer Leistung und den mit Messgrößen wie Codezeilen.
    AI liefert all die Werkzeuge, um genau diese lose eingebundenen, aber fordernden Manager zufriedenzustellen. Daher werden jetzt noch mehr Menschen Codezeilen und hinzugefügte Features als Kennzahlen mögen. Einfach, weil es jetzt leichter ist.
  • Im Grunde wird das alles getan, damit die Milliardärsklasse slop machines vorantreiben kann, mit denen Menschen auf die Straße gesetzt werden.

• Wenn ein A+-Senior-Entwickler acht Monate lang an einem Feature arbeitet und es am Ende nicht veröffentlicht wird oder das MVP verworfen wird, dann war dieser A+-Senior-Entwickler verschwendet, und seine Produktivität entspricht der von zwei B+-Ingenieuren im selben Projekt.
  Das ist in der Praxis ein sehr häufiges Problem, wird aber bei Einstellungen oder der Zuteilung von Projektressourcen meist ignoriert. AI wird daran wohl nichts Wesentliches ändern.
  Teams können ihre Arbeit vielleicht viel schneller abschließen, aber die bürokratische Schicht darüber bleibt wahrscheinlich bestehen, und dann fallen die Gewinne aus AI-Coding nur gering aus. Um sich an AI anzupassen, müsste man das Unternehmen von oben neu aufbauen, und das wird fast nie passieren.

  • Ingenieure neigen dazu, so etwas übermäßig als Verschwendung zu sehen. Diese Investition war keine Verschwendung, sondern der Preis für die Option, das Feature oder MVP veröffentlichen zu können, und für die Forschung, um herauszufinden, ob eine Veröffentlichung überhaupt sinnvoll wäre.
  • Bist du sicher, dass diese acht Monate wirklich nur für „Coding“ draufgingen? Da gibt es Design, Input vom Produktteam, Iterationen und so weiter. Ich weiß nicht, woher dieses Bild kommt, dass ein A+-Ingenieur allein in eine Kabine geht und nach X Monaten isoliert mit einem MVP wieder herauskommt.

• Das AI-Drücken am Ende ist seltsam schlecht begründet. Ohne Begründung, Ziel oder Behauptung über den Nutzen heißt es nur: „Nutzt einfach AI, Entwickler müssen Neues annehmen.“
  Unter den Artikeln, die ich zuletzt gelesen habe, war auch einer, der mit kurzem Kontext so tat, als würde er AI kritisieren, und am Ende doch als AI-Werbung endete, ohne dass es eine Verbindung zwischen beidem gab.

  • AI ist das neue Cloud. Für Menschen oder Unternehmen, die sich AI nicht verschreiben, gibt es keinen Markt. Entwickler, die den Einsatz von AI verweigern, wird kein Unternehmen einstellen, und wenn sich ein Unternehmen entscheidet, kein AI zu nutzen, wird es schwer sein, Entwickler zu halten. Denn man wird mehr Entwickler brauchen.
    Auch Investoren und große Kunden werden es sich noch einmal überlegen, bevor sie wichtige Verträge unterschreiben.
    Also muss man AI nutzen. Man sollte Kosten und Nutzen nicht kleinlich gegeneinander aufrechnen. Die Welt bewegt sich in diese Richtung, und wenn man vom Softwareentwickeln leben will, muss man sich ebenfalls in diese Richtung bewegen.
  • Trotzdem liegt der Wert von AI über null. Das ist keine kontroverse Aussage.

• Die Stelle „Diesmal ist der Unterschied die Geschwindigkeit. Cloud konnte man um Jahre verspätet übernehmen und trotzdem überleben. Bei AI können es nur Monate sein“ wirkt seltsam.
  Der Autor scheint zu verstehen, dass die pro-AI-Behauptungen von AI-Unternehmen über die Unverzichtbarkeit ihrer Produkte nicht widerlegbar sind, um dann sofort mit „Moment, denkt nicht, ich sei anti-AI“ zurückzurudern.
  Wieso ist diese Behauptung strenger als die Produktivitätsbehauptungen, die der Rest des Textes kritisiert? Die Aussage, man werde nicht „überleben“, wenn man AI nicht innerhalb weniger Monate annimmt?
  Selbst wenn ein AI-CEO das sagt, wird es dadurch nicht wahr; und wenn jemand, der den Unsinn eines AI-CEO anprangert, aus irgendeinem Grund dasselbe sagt, wird es auch nicht wahr.

  • AI-CEOs sagen so etwas, um den Aktienkurs hochzutreiben. Ich habe AI-CEOs nie geglaubt, weil sie nicht überprüfbare Behauptungen ohne Belege aufstellen.
    Wenn gesagt wird, Menschen würden wegen AI entlassen, ist das viel zu interpretationsfähig und verschiebt die Verantwortung von einem selbst auf AI. In Wirklichkeit sollte man das, was der CEO getan hat, nicht AI in die Schuhe schieben. Man hätte die Mitarbeiter auch für AI umschulen können, hat es aber nicht getan. Warum wohl? Vielleicht, weil es gar nicht an AI lag.
  • Er spricht nicht über Produktivität, sondern über kulturelle Überlegungen im Zusammenhang mit der Einstellbarkeit.
  • Hier der Autor. Berechtigte Kritik, und danke fürs Lesen. Mit „Monate“ wollte ich eigentlich nicht das Überleben von Unternehmen meinen, sondern die praktischen Arbeitsgewohnheiten einzelner Menschen, aber ich habe das nicht klar genug geschrieben.
    Ich habe den Text tatsächlich selbst geschrieben und nicht, wie man anderswo sagt, als „AI slop“ erzeugt, also ist er gegen Ende vielleicht einfach „menschlich sloppy“ geworden.
    Du hast recht, dass ich den „Moment“-Teil nicht ausreichend untermauert habe, aber ich bleibe dabei, dass Menschen AI ausprobieren sollten. Sie sollten experimentieren und Wege finden, wie es ihnen hilft. Selbst unter ähnlichen Ingenieuren war das Spektrum sehr breit, wie sie daraus Nutzen gezogen haben.
    Die Kosten, ein Tool ernsthaft auszuprobieren, sind fast null, und die Haltung „gezielt einführen und mit bewährten langweiligen Methoden messen“ ist nicht dasselbe wie „wenn du es nicht einführst, stirbst du“.
  • Es ist richtig, dass Menschen die Motive hinter einer Aussage berücksichtigen. Hier sind die Motive meiner Ansicht nach unterschiedlich genug, dass es einen Unterschied macht. Ein AI-CEO hat ein klares Motiv zu lügen, während dieses Motiv bei jemandem, der es Unsinn nennt, nicht so offensichtlich ist.

• Wenn ein Unternehmen sagt: „AI hat alle produktiver gemacht, also brauchen wir weniger Leute“, sagt es implizit eigentlich, dass das Unternehmen nicht produktiver werden will.
  Es will dieselbe Produktivität, indem es weniger produktiven Leuten weniger zahlt.
  Warum gibt es dieses Ungleichgewicht zwischen dem Geld, das der Arbeitgeber pro Produktionseinheit erhält, und dem Geld, das die Beschäftigten bekommen?

  • Weil Arbeit ausgebeutet wird, um Eigentümer reicher zu machen. Das ist die grundlegende Tatsache, und die Eigentümerklasse hat viel Geld in Propaganda gesteckt, um das zu rechtfertigen und zu verschleiern.
  • Ist nicht eher derselbe Output mit weniger Menschen gemeint statt „dieselbe Produktivität“? Per Definition wäre dann die Produktivität des Unternehmens gestiegen. Produktivität auf Unternehmens- oder Landesebene ist schließlich das Verhältnis von Output zu Input.
    Wenn man mit weniger Menschen denselben Output erzielt, hat sich die Produktivität des Unternehmens oder des Landes verbessert.
    Bei weniger Menschen und gleicher Produktivität würde auch der Output entsprechend sinken, also gäbe es für das Unternehmen keinen Vorteil, und bei Fixkosten könnte es sogar schlechter dastehen.
    https://www.mckinsey.com/featured-insights/mckinsey-explaine...

• Ich finde, die Zahl der Codezeilen unterscheidet sich nicht groß von der Zeit, die man im Büro verbringt. Vor der Pandemie hieß es ständig: „Wenn sie nicht im Büro sind, woher weiß ich dann, dass sie arbeiten?“
  Ganz einfach. Man schaut mit den Output-Metriken, die man ohnehin für alle Mitarbeiterbewertungen verwendet, was sie zum Geschäft beitragen.

• Dass Codezeilen immer noch eher als Vermögenswert denn als Verbindlichkeit gesehen werden, liegt meiner Meinung nach zu einem großen Teil an uns Ingenieuren. Wir sind stolz auf das, was wir gebaut haben, aber um zu beschreiben, wie „groß“ etwas ist, brauchen wir eine Metrik, und am Ende greifen wir auf die am leichtesten zu zählende zurück.
  Wir müssen die Begrifflichkeit ändern. Vor allem sollten wir viel öfter Formulierungen wie „... und die Kosten dafür waren N Zeilen Code“ verwenden. Man sollte auch sagen, wofür diese Codezeilen eingesetzt wurden.
  „Ich habe das neue Feature X implementiert, und es hat nur 200 Zeilen gekostet.“
  „Diesen Bug zu finden war wirklich schwer, aber am Ende hat er nur 6 Zeilen Code gekostet.“
  „Im Fall X haben wir etwas getan, was wir im Fall Y nicht getan haben, und es stellte sich heraus, dass diese Unterscheidung gar nicht nötig war. Also habe ich beim Beheben des Problems gleichzeitig 20 Zeilen Code eingespart.“
  Codezeilen sind der Preis, den wir zahlen. Wir prahlen auch nicht damit, 200 Dollar ausgegeben zu haben, ohne zu sagen, was wir dafür gekauft haben. Warum tun wir das dann bei Codezeilen?
  „Ich habe mich zu spät angemeldet und musste 200 Dollar mehr zahlen“ und „Ich habe einen handbemalten Lampenhalter aus Töpferhandwerk für nur 200 Dollar gekauft; die fabrikgefertigte Version von Amazon kostet über 1.200 Dollar“ sind völlig verschiedene Aussagen, und bei Code entspricht das exakt demselben Unterschied.