- Engineering-Produktivität lässt sich nicht sinnvoll über Dashboard-Metriken oder die Anzahl neuer Features messen
- Die meisten Unternehmen fixieren sich geradezu darauf, nur Outputs zu managen (neue Features, Deployment-Geschwindigkeit usw.), statt das eigentliche Wesen des Engineerings zu verstehen: die Pflege der Struktur
- AI-Coding-Tools erzeugen leicht oberflächlich gut aussehende Outputs, gehen aber mit dem Fundament, der Komplexität und dem Kontext realer Systeme nicht angemessen um
- Wenn erfahrene Engineering-Teams durch AI oder günstige Arbeitskräfte ersetzt werden, wirkt das kurzfristig oft unproblematisch, doch mit der Zeit zerfällt die grundlegende Struktur
- Management und AI-Einführung ohne „gesunden Menschenverstand“ können ernste Risiken verursachen; letztlich ist ein echtes Verständnis von Technik und Business entscheidend
Das wahre Engineering, das Dashboards und Metriken übersehen
- In „Big Agile“-Umgebungen wird Engineering nur anhand sichtbarer Outputs wie neuer Features oder Deployment-Geschwindigkeit bewertet
- Es gibt Produktivitäts-Dashboards und Tools im Wert von Milliarden Dollar, doch sie messen das Wesentliche in der Praxis nicht
- Echtes Engineering ist die komplexe und miteinander verknüpfte Arbeit des Aufbauens, Wartens und Weiterentwickelns von Systemen
- Strukturelle Abhängigkeiten, Ressourcenallokation, Architekturmanagement und andere „unsichtbare Arbeit“ sind für das Überleben einer Organisation essenziell
- Doch die meisten Managementmethoden und Metriken behandeln diese grundlegenden Aktivitäten, als wären sie unsichtbar
Technische Schulden und der blinde Fleck des Managements
- Technische Schulden werden oft so behandelt, als seien sie nur „etwas, das Entwickler gern machen möchten“
- Wenn die Behebung technischer Schulden tatsächlich nötig ist, wird sie oft nur genehmigt, wenn sie unauffällig in neue Features eingebaut wird
- So wird die Pflege der Kernstruktur nach hinten geschoben, und die gesamte Organisation wird in Richtung Output-Fixierung verzerrt
Die Risiken einer outputgetriebenen AI-Einführung
- AI-Codegenerierung ist hervorragend darin, oberflächliche Funktionen schnell zu erzeugen
- Oberflächliche Arbeiten (etwa die Implementierung von Interfaces) sind leicht sichtbar, doch tatsächlich sind die Struktur und der Kontext des Systems entscheidend
- „Ein Haus zu bauen“ ist nicht bloß die Summe einfacher Arbeiten wie Tapezieren oder Toilettenmontage
- AI versteht diese wesentlichen Verbindungsstrukturen nicht, verknüpft Dinge falsch oder erzeugt logische Brüche
- Das Problem der Halluzinationen bei AI: plausibel wirkend, aber möglicherweise völlig falsch
Die kurzfristige Täuschung eines strukturblinden Managements
- Selbst wenn erfahrene Teams entlassen und durch AI oder billige Arbeitskräfte ersetzt werden, zeigt sich das Problem kurzfristig oft nicht
- Weil bereits eine gut gebaute Struktur (ein Fundament) vorhanden ist, ist ein unmittelbarer Kollaps nicht sichtbar
- Doch mit der Zeit beginnt das Fundament zu bröckeln, und irgendwann ist der Punkt erreicht, an dem es kein Zurück mehr gibt
- Kritische Infrastruktur, Wartungs-Know-how und Kontextwissen gehen verloren
Das gesellschaftliche Risiko des Engineerings
- Engineering ist heute das Fundament aller gesellschaftlichen Infrastruktur (Gesundheitswesen, Finanzwesen, Medien, Staat, Verteidigung usw.)
- Die meisten Menschen und Führungskräfte verstehen dieses strukturelle Wesen nicht wirklich
- Falsch eingesetzte AI und der oberflächliche Ansatz von „Big Agile“ können zentrale Systeme in Gefahr bringen
Das Fehlen von „gesundem Menschenverstand“ und seine Folgen
- Wenn zum Beispiel ein AI-Reinigungsroboter Pappteller in die Spülmaschine räumt, erkennt ein gewöhnlicher Mensch das Problem sofort
- In Softwaresystemen fehlt Führungskräften, Managern und Nicht-Entwicklern dieser grundlegende gesunde Menschenverstand jedoch oft
- Sie haben die praktische Arbeit nie erlebt und managen nur über formelhafte Begriffe wie „T-Shirt-Größen“ oder „Poker Planning“
- So bleibt eine ineffiziente Industrie im Umfang von 200 Milliarden Dollar und eine sich selbst reproduzierende Bürokratie bestehen
Die wahre Wettbewerbsfähigkeit im AI-Zeitalter: intuitives Verständnis und gesunder Menschenverstand
- Um AI richtig zu nutzen, sind echtes Fachverständnis und gesunder Menschenverstand im jeweiligen Bereich unverzichtbar
- Entscheidend ist nicht der Blick auf oberflächliche Metriken und Outputs, sondern auf die tatsächliche Struktur und den Kontext
- Führungskräfte und Organisationen, denen das fehlt, werden am Ende entweder an sich selbst scheitern oder von Wettbewerbern verdrängt werden
- Fazit: Nicht AI und Tools, sondern gesunder Menschenverstand und ein Verständnis für das Wesentliche sind die wahre Wettbewerbsstärke
2 Kommentare
Der Text liest sich sehr angenehm.
Hacker-News-Kommentare
Ich habe Erfahrung als SWE, Produktmanager und inzwischen sogar in der im Artikel erwähnten Rolle des Comic-Bösewichts im Vorstandszimmer. Der Punkt in diesem Artikel, mit dem ich mich am meisten identifizieren kann, ist der Glaube vieler Softwareingenieure, ihre Arbeit sei das komplexeste und am wenigsten durchschaubare Geschäft überhaupt. Ich kann dem Satz zustimmen: „Die meisten nichttechnischen Führungskräfte haben sich nie ernsthaft mit der tatsächlichen Arbeit von Software- und Systempflege befasst und wissen daher nicht, was es bedeutet, große Abhängigkeiten zu aktualisieren, ein Refactoring abzuschließen oder eine neue Sprache zu lernen.“ In allen Bereichen eines Tech-Unternehmens gibt es versteckte Komplexität, und viele Bereiche tragen zusätzlich noch menschliche und zwischenmenschliche Komplexität mit sich herum, oft in weit größerem Maß als die Technik. Tatsächlich ist Engineering vergleichsweise schlicht, weil es sich nur mit deterministischen Systemen namens Computer befasst. Deshalb lernen viele Ingenieure nie, die Risiken der Komplexität, mit der sie arbeiten, dem Business verständlich zu vermitteln. Es ist alltäglich, die menschliche Realität der Zusammenarbeit auszublenden und sich dann darüber zu beklagen, dass ein CEO mit Vertriebshintergrund die eigene Existenz nicht versteht
Ich stimme deinem Punkt teilweise zu, aber es wirkt so, als würdest du mit deinem Kommentar genau das Gegenteil von dem tun, was du kritisierst. Du sagst im Grunde, dass auch deine Rolle, also die des Produktmanagers, für Außenstehende komplex und undurchschaubar ist. Als jemand, der von SWE zu PM gewechselt ist, bist du eigentlich in der idealen Position, Ingenieuren beizubringen, (1) wie man die Risiken der eigenen Komplexität dem Business vermittelt, (2) wie die menschliche Realität der Arbeit mit anderen Menschen und Teams aussieht und (3) warum ein CEO mit Vertriebshintergrund sie nicht versteht. In allen Funktionen eines Tech-Unternehmens gibt es verborgene Komplexität
Ich denke, schon die Wahrnehmung von Komplexität ist ein menschliches Problem. Komplexität ist fraktal und man spürt sie erst, wenn man nah genug herangeht. Und ich stimme der Behauptung nicht zu, dass Ingenieure nur mit Computerkomplexität zu tun haben. Im Gegenteil: Es ist ihre Aufgabe, die komplexen Anforderungen der Organisation und aller Kunden an starre Computer zu übermitteln und dort zu interpretieren. Mit jeder zusätzlichen Ausnahme und jedem weiteren Sonderfall wird das gesamte System beeinflusst. Deshalb erwarte ich von meinen Senior Engineers, dass sie selbst Business-Terminologie lernen und diese Botschaft direkt transportieren können. Ich halte das inzwischen für einen essenziellen Teil des Werkzeugkastens eines Engineers
Die meisten Ingenieure neigen dazu, nicht tief darüber nachzudenken, was für das Unternehmen tatsächlich wertvoll ist. Eine saubere Build-Pipeline oder breite Testabdeckung ist nur insoweit wertvoll, wie sie das Produktrisiko reduziert. Wenn Software so wenige Nutzer hat, dass es niemanden interessiert, habe ich Teams schon geraten, sie nicht einmal zu warten. Andererseits habe ich auch schon verlangt, sich besessen darauf zu konzentrieren, ein kleines Feature perfekt zu machen, das von 90 % der Nutzer verwendet wird
Mich erinnert das an eine Geschichte, die mein Vater immer erzählt hat. Eines Tages stritten die Organe des Körpers darüber, wer wichtig sei. Das Gehirn sagte: „Ich bin wichtig, wenn ich sterbe, sterben alle.“ Das Herz rief: „Wenn ich stehen bleibe, sterben sofort alle.“ Die Nieren, die Leber, die Haut und die Wirbelsäule mischten sich ein, und der Streit ging weiter. Aber als sich das Arschloch schloss, konnte am Ende niemand mehr etwas sagen
Ich glaube nicht, dass der Artikel behauptet, es gebe in anderen Funktionsbereichen keine versteckte Komplexität. Er will eher sagen, dass das Ignorieren der verborgenen Komplexität von Engineering/Programmierung zu allerlei Problemen und Leid führt. Nur ist die Formulierung etwas aggressiv
Wenn dein Boss/CEO/Manager dich dazu drängt, LLM-Tools wahllos einzusetzen, den Ersatz von Entwicklern erwartet oder ernsthaft glaubt, „Vibe Coding“ sei die Zukunft, dann ist es wahrscheinlich klug, einfach schnell abzuhauen und dir einen neuen Job zu suchen. Es gibt immer noch viele Firmen, die LLMs sinnvoll einsetzen, ohne die absurde Erwartung zu haben, Entwickler zu ersetzen oder die Produktivität zu verzehnfachen. Firmen, die so etwas pushen, werden nicht von guten Führungskräften geleitet, sondern von Idioten
Zum Thema, dass AI Jira hacken wird: Es wurde festgestellt, dass Atlassians neues Produkt MCP, das vor Kurzem veröffentlicht wurde, wegen einer Kombination aus Zugriff auf sensible Daten, Offenlegung nicht vertrauenswürdiger Daten über öffentliche Issues und Möglichkeiten zur externen Kommunikation anfällig für Datenexfiltrationsangriffe ist. Der ausführliche Bug-Report ist hier, meine persönlichen Notizen sind hier
Jemandem, der sich im Zusammenhang mit AI-Tools Sorgen um die job security macht, würde ich raten, sich mit dem Business zu verbinden. Viele Ingenieure sind von coolen und schwierigen Problemen so gefesselt, dass sie nur noch auf die Technik selbst schauen. Aber wertvoller und sichtbarer ist, wer Business-Probleme versteht, besonders strategische, und Technik einsetzt, um sie zu lösen. Diese Probleme gehen meist über ein einzelnes Technikgebiet hinaus und haben eine starke kollaborative und soziale Komponente, daher braucht man Zeit, um sich daran zu gewöhnen. Aber das ist der Weg, den ICs künftig gehen müssen
Aber in Interviews wird so etwas wie die Fähigkeit, sich „mit dem Business zu verbinden“, gar nicht abgefragt. In Wirklichkeit kannst du viel Wert liefern und wirst trotzdem nicht eingestellt, wenn du im System-Design-Interview versagst. Man muss ohnehin schon zu viel wissen: verteilte Systeme, Software Engineering, Datenbanken, Leadership. Wenn man jetzt auch noch Business verstehen muss, fragt man sich irgendwann, was wir eigentlich alles tun sollen und wann man das alles lernen soll. Natürlich gibt es eine kleine Zahl von Generalisten, die in allem stark sind, aber nicht jeder ist so
„Verbinde dich mit dem Business“ ist wirklich ein großartiger Ratschlag. So konzentriert man sich als Engineer auf das Lösen echter Probleme und kann sicher sein, dass das, was man baut, tatsächlich ein echtes Problem löst
Die Kernbotschaft des Artikels ist okay, aber er drückt das Ganze zu stark in einen „wir gegen sie“-Rahmen und wirkt mit Formulierungen wie „Agile Industrial Complex“ etwas herablassend gegenüber Menschen außerhalb des Engineerings, mehr noch als mit dem Punkt, dass AI schaden kann, wenn man menschliche Expertise ignoriert. Schade ist auch, dass nicht darüber gesprochen wird, dass niemand weiß, wie die Zukunft aussehen wird. Selbst wenn wir die Komplexität von Software gut verstehen, gehört Unsicherheit nicht nur uns. Schon auf HN sieht man, wie stark Hoffnung und Erwartungen in Bezug auf AI selbst unter Softwareentwicklern auseinandergehen. Sollten wir als Experten nicht eher auch dazu beitragen, die Ängste der Öffentlichkeit zu beruhigen?
Bei „Big Agile“ und der Vorstellung, Engineering bedeute vor allem die Entwicklung neuer Features, frage ich mich, warum am Ende alle angefangen haben, „Agile“ zu hassen. Schon bevor „Agile“ eingeführt wurde, wollten Manager immer neue Features. Noch bevor es T-Shirt-Sizing gab, wollten Manager Schätzungen mit konkreten Fristen, ob lang oder kurz, in Tagen oder Monaten, machten auf Basis willkürlicher Daten Zusagen und ließen Ingenieure Überstunden schieben. Wie Prinzip 8 von Agile sagt („Nachhaltiges Tempo muss auf unbestimmte Zeit möglich sein“), wollten Manager schon immer, dass Entwickler für immer durchhalten. Abgesehen davon, dass dadurch die neue Berufsgruppe des „Scrum Masters“ entstanden ist, frage ich mich also, worin der eigentliche Schaden von Agile überhaupt bestand
Ich glaube, Agile hat Managern die Illusion gegeben, dass sich jede Arbeit im Voraus in Tickets zerlegen, grob schätzen und innerhalb von zwei Wochen erledigen lässt
Ich glaube, die Leute hassen Agile, weil ihnen ein erheblicher Teil der Arbeitszeit durch praktisch sinnlose Meetings weggenommen wird: Stand-ups, Retros, Sprint Planning, Refinement und so weiter. Aus Engineer-Sicht kommt dabei fast nichts Substanzielles heraus
Nach meiner Erfahrung hat Agile vor allem zusätzliche Mittel geschaffen, um den Status quo zu „quantifizieren“. Das ist nützlich, wenn man Managern oder Investoren Fortschritt erklären muss, aber für Engineers bedeutet es nur mehr administrativen Aufwand. Wenn Agile eine Sünde hat, dann die, die Illusion von Produktivität geschaffen zu haben. In Wirklichkeit ist es für Engineers ein unnötiges Mittel der accountability. Als ich im Finanzbereich gearbeitet habe, ging das Hand in Hand mit einer Mentalität unbegrenzten Wachstums: Alles wurde gemessen, künftige Verbesserungen wurden eingefordert, und sogar das Gehalt hing an Metriken. Sicher gibt es auch Firmen, in denen das anders ist
Beim Lesen dieses Artikels hatte ich die amüsante Vorstellung: Was wäre, wenn Atlassian versucht, AI mit Jira zu verheiraten, und AI sich dann gegen Jira auflehnt? Das wäre perfektes Material für einen Film
Am Ende könnte AI von langsamem Jira so genervt sein, dass sie einfach selbst einen leichten und schnellen Issue-Tracker entwickelt
Bald gründen Build-Bots und Bug-Tracker wohl eine Gewerkschaft und weigern sich, neue Binärdateien zu veröffentlichen, bis die Zahl der offenen Issues auf null gefallen ist
Vielleicht wird auf diese Weise Roko’s basilisk geboren
Wie der Artikel andeutet, ist das eigentliche Problem, dass es keine vertrauenswürdigen branchenweiten Standardmetriken für Entwicklerproduktivität gibt. Deshalb kann die C-Suite sich einfach die Metriken aussuchen, die zu ihr passen, und behaupten, die „AI-First-Strategie“ sei extrem effektiv, während Engineers mit ihren eigenen Erfahrungen oder Kennzahlen argumentieren, dass AI in Wirklichkeit nicht hilft. So glaubt am Ende jede Seite, ihre Position habe gewonnen, und die Wahrheit wird bedeutungslos; wichtiger wird die politische Perspektive. Das kann die Wahrnehmung verstärken, Entwickler seien unmotiviert und betrieben nur Wortklauberei, während umgekehrt das Misstrauen wächst, das Management sei ahnungslos und verstehe die Realität der Engineers nicht. Auch früher haben Werkzeuge wie Outsourcing auf beiden Seiten Vorstellungen von „Gewinn“ und „Verlust“ erzeugt, aber AI könnte politisch zur Katastrophe werden, weil sie jeder Seite ihre jeweils passende Version von gemeinsamen Fehlern, Gewinnen und Verlusten zeigt. Interessant ist auch, dass große Tech-Unternehmen früher unbedingt 10x-Engineers einstellen wollten und diese Strategie ihren Erfolg gesichert hat, sie heute aber unter Verweis auf Investitionen in AI genau diese Strategie kleinreden. Die Frage ist nun, ob es wirklich nachhaltig und unproblematisch ist, auf AI zu setzen, um bestehende Belegschaften zu ersetzen oder Massenentlassungen durchzuführen. Das Beispiel Twitter und Musks Entlassungen zeigt, dass das Backend irgendwie noch läuft. Wer wird über Jahre hinweg die Rolle des „Kanarienvogels“ übernehmen, während Big Tech Entwickler entlässt und durch AI ersetzt? Eine weitere Möglichkeit ist, dass die Idee von Wartbarkeit verschwindet: Wenn die C-Suite immer mehr autonome Änderungen durch AI zulässt, könnte die Codebasis selbst so komplex werden, dass Menschen sie nicht mehr mit den Augen verstehen können und stattdessen wieder AI brauchen, um sie zu begreifen. Langfristig könnte generative AI zur Zwischenschicht aller menschlichen Interaktionen werden. Im Recruiting entsteht bereits eine Struktur „AI gegen AI“: AI filtert Lebensläufe, und Bewerber erstellen mit AI maßgeschneiderte Lebensläufe. Es wirkt, als könnte dieses Muster nach und nach zur allgemeinen Formel der Gesellschaft werden
Ich hoffe, dass AI irgendwann den Posteingang und Google Meet hackt und dann auch die C-Suite und die Manager ersetzt. Es ist eine amüsante Fantasie, dass Claude-Agenten als CEO/CTO/CFO/VP/Direktor vernünftigere und entschlossenere Strategien liefern würden als das aktuelle Management
Ich habe auf Reddit gelesen: „Sagt ihnen, dass man achtmal mehr Kosten sparen kann, wenn man den CEO durch AI ersetzt.“ Interessant ist die Ironie, dass genau so ein Vorschlag in AI-Debatten kaum ernsthaft auftaucht. Irgendwie würde die Qualität der Entscheidungen wahrscheinlich nicht allzu stark sinken, wenn man die Eliten durch AI ersetzt, und insgesamt wäre es deutlich billiger, das Verantwortungsniveau eingeschlossen. Nur werden die Leute an der Macht ihren eigenen Platz natürlich nicht durch AI ersetzen und die Entscheidungsträger selbst werden das nicht ändern
Da steckt zwar ein Witz drin, aber im Kern ist das Argument sinnlos, weil die Hauptaufgabe eines CEO darin besteht, „Verantwortung zu absorbieren“, und ein LLM nichts ist, das man bei Problemen verantwortlich machen und hinauswerfen kann. Allerdings könnten durch AI Organisationsstrukturen auf log(n_employees) schrumpfen und Unternehmen mit weniger Ebenen entstehen, wobei manche Ebenen vollständig durch AI ersetzt werden könnten. Um das Problem zu lösen, dass LLMs keine Verantwortung tragen können, könnte es auch Organisationsformen aus mehreren Guilds und Independent Contractors geben, die unter Koordination eines LLM zusammenarbeiten. In diesem Fall bliebe die Verantwortung bei den einzelnen Komponenten
Im Gegenteil: Das könnte eine der besten Einsatzmöglichkeiten für AI sein, und ich vermute, dass Tech-Kooperativen bald anfangen werden, mit dieser Idee zu experimentieren