Der Ingenieur, der einfach Nein sagt, war ein ZIRP-Phänomen

• Der Ingenieur, der einfach Nein sagt, ist ein Senior-Archetyp, der Codeänderungen grundsätzlich bremst, komplexe Features verzögert und darauf hinwirkt, dass möglichst wenig Code geschrieben wird
• In der ZIRP-Phase waren Produktivitätsverluste dank niedriger Zinsen und ausgeweiteter Einstellungen weniger wichtig, und die Rolle, aggressive Technikvorschläge zu blockieren, war für Unternehmen nützlich
• Nach dem Zinsanstieg entließen Tech-Unternehmen 5–20 % ihrer Ingenieure, legten mehr Wert auf Umsatz als auf den Aktienkurs, und der Schutzschirm, der stellvertretend „Nein“ sagte, wurde kleiner
• LLMs erhöhten den Druck mit KI-generierten PRs und hinreichend brauchbarem Code, aber die entscheidende Veränderung ist nicht KI, sondern der durch das Ende von ZIRP veränderte wirtschaftliche Anreiz
• Diese Rolle verschwindet nicht, passt aber besser in den Bereich des reinen Engineerings und muss im Vergleich zu den 2010ern einen engeren Umfang und geringere Sichtbarkeit akzeptieren

---

Die Rolle des „Ingenieurs, der einfach Nein sagt“

• Der Ingenieur, der einfach Nein sagt, ist ein Archetyp irgendwo zwischen Senior- und Staff-Engineer und kommt einer Rolle nahe, die Feature-Entwicklung verlangsamt, Änderungen verhindert, die die Komplexität erhöhen, und dafür sorgt, dass möglichst wenig Code geschrieben wird
• Auf der Gegenseite steht der Ingenieur, der einfach Ja sagt: Er priorisiert schnelles Vorankommen, genehmigt Codeänderungen standardmäßig, misst MTTR mehr Bedeutung bei als MTBF und neigt dazu, viel Code auszurollen
• Die meisten Ingenieure liegen zwischen diesen beiden Polen, aber hier liegt der Fokus auf denen, die ihre Identität stark mit der Rolle des „Nein-Sagens“ verbinden
• Im KI-Zeitalter müssen nicht nur PRs von Junior-Ingenieuren, sondern auch große Mengen KI-generierten Codes abgelehnt werden; manchmal stammt der Code sogar von Managern oder VPs, was eine Ablehnung politisch erschwert
• Zum ersten Mal in ihrer Karriere stehen sie stark unter Druck, die Maßstäbe zu senken und „Ja“ zu sagen, doch die Kernursache ist weniger KI selbst als vielmehr das Ende von ZIRP

Das von ZIRP geschaffene Umfeld

• ZIRP steht für „Zero Interest Rate Policy“ und bezeichnet die Ära der Softwareentwicklung zwischen 2008 und 2022, in der Banken Unternehmen Geld zu nahezu null Prozent liehen
• Investoren steckten dieses geliehene Geld in fast alles, und Tech-Unternehmen hatten starke Anreize, weiter Ingenieure für Projekte einzustellen, bei denen sie niedrige Risiken und hohe Belohnungen erwarteten
• Erfolgreiche Unternehmen vergrößerten ihre Engineering-Teams von einigen Dutzend auf Tausende und setzten sie für randständige Open-Source-Projekte, endlose technische Migrationen oder Neuschreibungen in anderen Sprachen ein
• Für Softwareingenieure war es eine Zeit großer Verhandlungsmacht, in der man für fast jede Art von Arbeit sehr gut bezahlt wurde
• Führungskräfte konnten bei so schnell wachsenden Teams kaum auf Details achten, und weil schon die wachsende Zahl von Ingenieuren dem Aktienkurs half, wurden viele Aktivitäten nicht als großes Problem gesehen
• Wenn sich zu viele Ingenieure frei bewegten, konnten Systeme unbeherrschbar werden, und genau hier wurde der „Ingenieur, der einfach Nein sagt“, für Unternehmen nützlich

Warum „Nein“ in der ZIRP-Zeit wertvoll war

• Weil Produktivitätsverluste kein großes Problem waren, konnten Unternehmen es verkraften, wenn die Hälfte ihrer Ingenieure in einer Schleife aus Vorschlägen und Ablehnungen festhing
• Diese Arbeitsweise hatte auch den Effekt, dass Ingenieure geschäftskritische Systeme nicht berührten
• Sie half außerdem dabei, die 5 % der Ingenieure zu kontrollieren, die im Rausch technischer Freiheit radikale Vorschläge machten, etwa auf eine handgebaute Datenbank zu migrieren
• Der Ruf, ein Unternehmen mit sehr hohen technischen Standards zu sein, war positiv fürs Recruiting, und in der ZIRP-Zeit stellte praktisch jedes Tech-Unternehmen permanent ein
• Der Spruch „Junioren produzieren viel Code, Seniors etwas weniger, Staff-Engineers entfernen Code“ wirkt attraktiv, weil er suggeriert, Experten müssten sich kaum bewegen, trifft aber nicht zu, denn auch Staff-Engineers müssen bei Bedarf sehr schnell viel funktionierenden Code liefern können

Veränderungen nach dem Ende von ZIRP

• Als die Banken die Zinsen anhoben, entließ fast jedes Tech-Unternehmen sofort 5–20 % seiner Ingenieure
• Überdimensionierte Engineering-Organisationen nur zur Stützung des Aktienkurses aufrechtzuerhalten, war nicht länger profitabel, und Unternehmen mussten tatsächlich Geld verdienen
• Mit „Geld verdienen“ ist hier nicht zwingend gemeint, Gewinn zu machen, sondern zumindest Umsatz zu generieren
• Öffentlich einzuräumen, dass man Hunderten Ingenieuren unprofitable Arbeit gegeben hatte, war keine gute Erklärung für Entlassungen
• Weil das Ende von ZIRP zeitlich ungefähr mit dem Aufstieg von ChatGPT zusammenfiel, konnten Unternehmen ihre Entlassungen mit der Macht der KI begründen
• Die Botschaft „Dank dieser transformativen neuen Technologie können wir mit der Hälfte der Ingenieure den 10-fachen Wert liefern“ klingt kraftvoll, aber wenn das wirklich stimmt, stellt sich die Frage, warum man die Ingenieure nicht behält, um den 20-fachen Wert zu liefern

Fokussiertere Unternehmen und ein geschrumpfter Schutzschirm

• Tech-Unternehmen sind heute fokussierter als jemals in den vergangenen 20 Jahren und jagen nicht mehr wahllos vielen Dingen hinterher, sondern verzweifelt neuen Fähigkeiten und Features, mit denen sich Geld verdienen lässt
• Dieses neue Umfeld ist für den Ingenieur, der einfach Nein sagt, aktiv nachteilig
• Früher hatte dieser Ingenieur die implizite Unterstützung des Managements, und selbst wenn sich jemand beschwerte, konnte man das mit einem „Wir wissen, was dieser Ingenieur tut; wenn er Nein sagt, vertrauen wir ihm“ abräumen
• Diese Unterstützung ist jetzt verschwunden, und dasselbe Verhalten wird vom Management kritisiert oder aktiv überstimmt
• Es heißt dann, man solle teamfähiger sein, Wege finden, Ja zu sagen, oder wird bei wichtigen Entscheidungen gar nicht mehr konsultiert
• Verhalten, das vor 2022 noch belohnt wurde, führt inzwischen zu schlechten Bewertungen; oft folgt der kulturelle Wandel dem veränderten wirtschaftlichen Anreiz mit einigen Jahren Verzögerung
• Diese Veränderung hängt nicht von KI ab: Selbst wenn LLMs in diesem Jahrzehnt nicht aufgekommen wären, hätten Unternehmen Ingenieure entlassen, und die für das „Nein“ zuständigen Ingenieure wären genauso verwirrt gewesen, warum ihr Verhalten plötzlich bestraft wird

Der zusätzliche Schock durch KI

• Wenn ZIRP nicht geendet hätte, hätten LLMs dem „Ingenieur, der einfach Nein sagt“, eine starke neue Rechtfertigung liefern können
• Unternehmen, die KI-gestütztes Coden weder öffentlich noch intern leicht infrage stellen können, hätten sich stark auf diese Ingenieure gestützt, um eine Flut von KI-Code vom Unternehmen fernzuhalten
• In der Realität fügen LLMs einer bestehenden Wunde eher noch zusätzliche Kränkung hinzu
• Man muss dabei zusehen, wie früher blockierte KI-generierte PRs gemergt werden, und wird zugleich aufgefordert, solche Werkzeuge selbst zu nutzen
• Noch schlimmer ist, dass KI-Tools im Großen und Ganzen funktionieren
• Sie haben bisher keine bestimmte Art von Katastrophe ausgelöst, und auch wenn der Code etwas unordentlicher und das Verständnis etwas geringer ist, ist er gut genug, um eingesetzt zu werden
• Gerade in Umgebungen, in denen Unternehmen viele neue Dinge ausprobieren und Gescheitertes wieder verwerfen, funktioniert „gut genug“ geschriebener Code
• Selbst wenn man meint, dass es zuletzt mehr Zwischenfälle gab, kann man sich täuschen, oder andere Folgen des ZIRP-Endes wie höheres Tempo und Entlassungen sind die wichtigeren Ursachen
• Der „Ingenieur, der einfach Nein sagt“, sieht nicht nur seinen Lebensunterhalt, sondern auch seine Identität bedroht
• Er muss entweder akzeptieren, dass seine technische Rolle von einer sehr speziellen wirtschaftlichen Lage der Tech-Industrie abhing, oder weiter behaupten, das Ende stehe unmittelbar bevor

Reines und unreines Engineering

• Der „Ingenieur, der einfach Nein sagt“, verschwindet nicht, passt aber nicht mehr zu jedem Tech-Unternehmen
• In Pure and impure software engineering wird reines Engineering als Arbeit mit klar definiertem Umfang und überwiegend technischen Zielen beschrieben, etwa Compiler oder Sprach-Runtimes
• Unreines Engineering bezeichnet dagegen Arbeit mit unklarem Umfang und kundengesteuerten Zielen, etwa der Versuch neuer Features, deren Erfolg sich nicht sicher vorhersagen lässt
• In der ZIRP-Zeit leisteten Tech-Unternehmen viel mehr reine Arbeit wie React) und neigten dazu, sogar unreine Arbeit so zu behandeln, als wäre sie rein
• Der „Ingenieur, der einfach Nein sagt“, passt sehr gut zu reiner Arbeit
• Der Grund ist, dass reine Codebasen deutlich höhere Qualitätsstandards brauchen und langsamere Entwicklungszyklen verkraften können
• Die meisten Tech-Unternehmen haben weiterhin Bereiche wie Kerninfrastruktur, in denen irgendeine Form reiner Arbeit stattfindet
• Diese Arbeit ist essenziell, erfordert aber keine riesigen Engineering-Teams und steht selten im Rampenlicht
• Wer ein „Ingenieur, der einfach Nein sagt“ bleiben will, sollte in solche Rollen wechseln, muss aber einen engeren Aufgabenbereich akzeptieren als noch in den 2010ern

Debatte und ergänzte Perspektiven

• Auf lobste.rs und Reddit wurde kritisiert, dass sich die Auswirkungen von KI-Code erst mit der Zeit zeigen und es daher zu früh sei, zu behaupten, er „funktioniere im Großen und Ganzen“
• Dieser Einwand, es sei „noch zu früh, das zu sagen“, ist schwer zu widerlegen, aber dass KI-Code nicht sofort katastrophal ist, scheint klar
• Es gab auch den Einwand, dass der Archetyp des „Ingenieurs, der einfach Nein sagt“ schon in den Jahrzehnten vor ZIRP existierte; als Beispiel wurde Linus Torvalds genannt
• Nicht der Archetyp selbst wurde also von ZIRP geschaffen, sondern ZIRP hat die Nische für diese Rolle künstlich verbreitert, und nun ist sie wieder geschrumpft
• Ein weiterer Einwand lautete, dass die Nutzung dynamischer Sprachen sowie unreife Observability- und Feature-Flag-Tools diese Nische geschaffen hätten
• Auf Hacker News meinten mehrere Stimmen, diese Theorie brauche belastbarere Belege
• Diese Sichtweise basiert auf dem kleinen Fenster persönlicher Erfahrung, und Verallgemeinerungen darüber, wie die Branche vor und nach ZIRP aussah, können von Person zu Person unterschiedlich ausfallen
• Um das zu überprüfen, könnte man 2010 und 2026 jeweils Hunderte Senior- oder erfahrenere Ingenieure befragen, wie oft sie pro Woche „Nein“ gesagt haben und wie häufig diese Ablehnungen überstimmt wurden
• Sowohl vor als auch nach ZIRP bleibt es unverzichtbar, „Nein“ zu sagen; der Unterschied nach ZIRP besteht darin, dass das Management diese Fähigkeit schnell selbst aufgebaut hat und daher weniger Bedarf an einer Ingenieurgruppe hat, die stellvertretend Nein sagt

[GN⁺]

Hacker-News-Kommentare

• Code ist technische Schuld. Wenn Ingenieure „Nein“ sagen, dann nicht, weil sie subjektiv von Codequalität besessen sind, sondern weil sie Komplexität reduzieren wollen
  Das Management missversteht das Wort „Qualität“ heute oft. Qualität bedeutet den angemessenen Umfang an Aufwand, um ein Produkt so schnell und kostengünstig wie möglich zu bauen, wobei auch berücksichtigt wird, dass das Engineering-Team Code leicht hinzufügen und ändern können muss
  Eine bessere Erklärung gibt es hier: https://www.nair.sh/guides-and-opinions/communicating-your-e...

  • „Qualität“ lässt sich nur schwer einfach definieren. Es ist ein Bereich wie Zen in der Systemwartung, und qualitativ hochwertiger Code ist eher etwas, das erfahrene und weise Programmierer schreiben
    Jeder Versuch, das, was diese Person warum getan hat, in starre Regeln zu gießen, muss scheitern
  • In einer Welt mit agentischer KI kann diese Schuld kleiner oder größer werden. Teams, die KI-Risiken gut abmildern, können enorme Mengen an nachhaltigem Code hervorbringen

• Das Problem mit solcher Sessel-Ekonomik ist, dass man damit Argumente in beide Richtungen konstruieren kann
  Man könnte auch sagen: „Das Ende der Nullzinsära und der Aufstieg des Just-say-no-Ingenieurs.“ Weil Kapital teurer geworden ist, müssen Unternehmen dieses Geld klüger einsetzen, und man braucht das Urteilsvermögen von Ingenieuren, die Nein sagen, um es nicht für Unnötiges zu vergeuden

  • Ergänzend dazu: Entweder ist man ein Ingenieur, dem das Management vertraut und dessen Urteil es schätzt, oder eben nicht. Wenn nicht, ist man ohnehin in einer schlechten Position
  • Bei solchen Artikeln ist die HN-Community und der Kommentarverlauf wirklich großartig
    Je mehr ich den Artikel las, desto mehr dachte ich: „Er hat alle plausibel klingenden Begriffe, spricht von der ZIRP-Ära und von Just-say-no-Ingenieuren und wirkt dadurch einsichtsvoll, aber wenn man tiefer hineingeht, passt das überhaupt nicht zu meinen Erfahrungen aus der Softwareentwicklung jener Zeit und diagnostiziert auch die gewaltigen Veränderungen durch KI heute nicht richtig.“ Mit anderen Worten: Es klang für mich wie Buzzword-Unsinn, und da es für den Artikel selbst keinen Downvote-Button gibt, war ich froh, dass die Community das herausarbeitet
  • Sehe ich ähnlich. Jedes Unternehmen hat eine andere Zeitpräferenz zwischen kurzfristigem Erfolg und langfristigem Erfolg
  • Sean mag ein guter Ingenieur sein, aber Ökonomik scheint außerhalb seines Fachgebiets zu liegen
  • Hohe Zinsen bedeuten mehr Dringlichkeit und verweisen auf kurzfristige Investitionen, die sich schnell auszahlen. Wenn dazu noch LLMs kommen, die genau auf diese Dringlichkeit gut anspringen, entsteht Massenproduktion von KI-Müll
    Selbst wenn ein KI-Projekt scheitert, ist das egal, solange es schnell genug scheitert und man danach etwas anderes macht. Es ist nur bei langfristigen Projekten mit hoher Anfangsinvestition wichtig, es von Anfang an richtig zu machen

• Die Aussage „Es war völlig in Ordnung, wenn die Hälfte der Firmeningenieure in einer endlosen Schleife aus Änderungsvorschlägen und Ablehnungen festhing. Sie mussten ohnehin nicht produktiv sein, und auf diese Weise hatten sie keinen Einfluss auf geschäftskritische Systeme“ ist nun ja eine Sichtweise. Ziemlich zynisch

  • Aus jener Zeit gibt es viele Erzählungen darüber, dass FAANG Leute eingestellt hat, damit sie nicht zur Konkurrenz gehen. Aber was lässt man diese Leute dann tun? Und wie verhindert man, dass sie Probleme verursachen?
    Rückblickend klingt das zynisch, aber damals hat man dieselben Tatsachenbündel anders erklärt, auf eine Weise, die die Gefühle der Leute weniger verletzte
  • Genau. Und ZIRP mit dem „No-man“-Phänomen zu verknüpfen, ist falsch und vielleicht die seltsamste Korrelation überhaupt. Ich mag unerwartete Zusammenhänge, aber dieses Phänomen hat nichts mit ZIRP zu tun und existierte schon vorher
  • Vieles in diesem Artikel ist von vornherein nicht überprüfbar
    Ob jemand bei Facebook am Metaverse ein wichtiger Mitarbeiter ist, der ein neues Geschäftsmodell prototypisch umsetzt, oder nur so tut, als sei er beschäftigt, wird erst später klar

• Das ist eine ziemlich extreme Auslegung. Wenn nach dem Ende von ZIRP der Fokus zugenommen hat, wäre die naheliegende Schlussfolgerung dann nicht, dass man mehr statt weniger ablehnen sollte?
  Um zu behaupten, ZIRP habe allerlei Fake-Arbeit erzeugt und sogar Ebenen geschaffen, die diese Fake-Arbeit kontrollieren, muss man sich schon ziemlich verrenken

  • Dieser Zeitraum war nicht einmal ein gutes Beispiel für nahezu Nullzinsen. Zumindest dann nicht, wenn man die Inflation berücksichtigt; es gab andere Zeiten mit niedrigen oder sogar negativen Realzinsen

• Mir gefällt die Unterscheidung zwischen „Just-say-yes-Ingenieuren“ und „Just-say-no-Ingenieuren“ sowie die Perspektive, MTTR vor MTBF zu priorisieren
  Ich bin eindeutig eher auf der „Just-say-yes“-Seite, aber es gibt den Vorbehalt, dass schlechte Architekturentscheidungen später sehr schmerzhaft zu beheben sein können und Funktionen viel schwerer zu korrigieren sind, sobald es Nutzer gibt, als vor dem Launch. Deshalb bin ich auch ein wenig „Just say no“, oder zumindest eher bei „Lass uns erst kurz nachdenken“
  Das Gleichgewicht zwischen „Just say yes“ und „Just say no“ hängt stark vom Projekt ab. Im Finanz- oder Gesundheitsbereich ist als Standard vielleicht „Nein“ besser, aber bei einer verrückten Startup-Idee gilt YOLO

  • So eine „Just say yes“-Haltung führt am Ende zwangsläufig zur Katastrophe. Denn die Zeit, das Produkt zu reparieren, kommt nie
    Zeit zum Aufräumen einzufordern ist faktisch dasselbe wie Nein zu sagen. Ein Entwicklungsleiter sollte die Befugnis dazu haben und sie auch tatsächlich nutzen. Wenn er sie nie nutzt, hat er sie de facto nicht

• Man sollte kein Ingenieur werden, der ohne Alternativen nur „Nein“ sagt. Das ist kein guter Ingenieur, sondern jemand, der faul ist und dabei gut aussehen will
  Ingenieure schlagen wegen Legacy-Systemen oft Lösungen vor, die nicht ideal, aber notwendig sind. Und nein, man kann nicht einfach das gesamte System neu schreiben und es „richtig“ machen. Nur „Nein“ zu sagen oder darauf hinzuweisen, dass eine Lösung nicht ideal ist, macht einen noch nicht zu einem superintelligenten Genie

  • Ich erinnere mich an genau so einen Software-Development-Manager. Jemand, der das System gut kannte, wurde Manager und fing an, gegenüber mehreren Produktmanagern und anderen Entwicklern ständig Nein zu sagen
    In Meetings mit den Business-Leuten trat er einschüchternd auf, weil er programmieren konnte, und das Schlimmste war, dass er überhaupt keine Alternativen vorschlug, wenn er einem Vorschlag nicht zustimmte. Es war schwer, mit ihm zusammenzuarbeiten
    Ich frage mich, ob diese ZIRP-Person aus dem Artikel genau so jemand ist

• Wenn es bei LLMs und Agenten Mängel gibt, scheint es einen Trend zu geben, nicht auf Verbesserungen zu warten, sondern die Maßstäbe zu senken. So nach dem Motto: „Konzentriert euch auf MTTR“
  Ist der Code schlecht? Dann lest ihn nicht, prüft ihn nicht und nehmt die Person als Flaschenhals aus der Schleife. Solche Narrative verbreiten sich überall
  Die Technologie ist ziemlich nützlich, deshalb würde ich mir wünschen, dass man sich statt nur um die Symptome darum bemüht, besser mit den Tools zu arbeiten und die dazu passenden Prozesse zu verbessern

  • Macht man nicht ohnehin beides? AI-Labore werden auf ihrer Seite Verbesserungen vorantreiben, und es gibt auch Leute, die bessere Agenten bauen. Einzelne können ihre Fähigkeiten ausbauen oder AGENTS.md anpassen
    Es gibt unendlich viel, was man tun könnte, aber die eigentliche Frage ist, wie man die Zeit zwischen der Arbeit am realen Projekt und solchen Verbesserungen aufteilt

• Es heißt: „Je mehr Engineers, desto besser für den Aktienkurs … als die Banken die Zinsen anhoben … war es nicht länger profitabel, aufgeblähte Engineering-Organisationen zu halten, nur um den Aktienkurs zu stützen“ — aber gibt es einen bekannten Mechanismus, der die Zahl der Software-Engineers und den Aktienkurs verbindet? Oder ist das einfach nur eine empirisch beobachtete Erscheinung?

• „Früher musste man zu handgeschriebenen PRs von Junior-Engineers nur Nein sagen, heute wird man mit AI-generiertem Code überschwemmt, und ein Teil davon stammt von Managern und VPs, deren Beiträge sich politisch nur schwer ablehnen lassen“ — meine Güte
  Ich habe zwar bei großen Tech-Unternehmen gearbeitet, die Branche aber vor InstructGPT und Ähnlichem verlassen, daher habe ich LLM-Codegenerierung intern nie erlebt. Passiert so etwas wirklich? Schlagen obere Führungskräfte und VPs tatsächlich per LLM erzeugte Code-Änderungen vor? Ich glaube, ich würde das nicht aushalten

  • Ja, das passiert tatsächlich. Ein Freund erzählte mir, dass er sich mit einem 25.000-Zeilen-PR herumschlagen musste, den ein Produktmanager eingereicht hatte
    Der politische Druck ist auch real. Man kann nicht einfach „Nein“ sagen, aber einen 25.000-Zeilen-PR sinnvoll zu reviewen, den jemand eingereicht hat, der kaum versteht, was er da tut, und Fragen dazu nicht beantworten kann, ist ziemlich schwierig
  • Der CEO von Shopify eröffnet PRs in öffentlichen Repositories: https://github.com/Shopify/liquid/pull/2056
    Fairerweise muss man sagen, dass er in den Anfangstagen des Unternehmens liquid und große Teile von Shopify selbst gebaut hat, also ist er kein Unerfahrener, aber trotzdem schon bemerkenswert

• Das wirkt wie eine schwer überprüfbare Hypothese. Wenn ein Unternehmen tatsächlich versucht, etwas zu erreichen, ist es dann nicht ganz selbstverständlich sinnvoll, jemanden zu haben, der bei der Priorisierung hilft, indem er aufzeigt, bei welchen Entscheidungen langfristige Kosten entstehen?