Was die Uhrenindustrie Softwareentwickler über das KI-Zeitalter lehrt

Dieser Beitrag basiert auf dem Video „What the Watch Industry Can Teach Software Developers” von The Monday Morning Review. Das vollständige Video findest du hier:

Die Parallele klingt zunächst absurd: Was hat die Schweizer Uhrenindustrie mit Softwareentwicklung zu tun? Auf den zweiten Blick zeigt sich ein Muster, das für jeden Softwareentwickler relevant ist. Wenn die Kernfunktion einer Branche plötzlich billig wird, überleben nicht die, die besser auf dem alten Spielfeld konkurrieren. Sondern die, die das Spielfeld wechseln.

TL;DR / Key Takeaways

• Kernverschiebung: Wenn eine Kernfunktion billig wird (Zeitmessung bei Uhren, Code-Produktion bei Software), verschiebt sich der Wert in angrenzende Fähigkeiten.
• Qualität als Baseline: Technische Kompetenz verkauft nicht mehr allein, aber schlechte Qualität zerstört weiterhin das Produkt. GitClear-Daten belegen: Copy-Paste-Code hat Refactoring erstmals überholt.
• Vom Spezialisten zum Generalisten: Der Wert verschiebt sich zu Problemverständnis, Geschäftslogik, Systemdesign und der Fähigkeit, die richtigen Fragen zu stellen.
• Fragen schlagen Antworten: Wenn Antworten billig werden, steigt der Wert der richtigen Frage. KI generiert bereitwillig Code für sinnlose Features, kaputte Geschäftsprozesse und falsche Datenmodelle.

Die Quarzkrise: Wenn die Kernfunktion billig wird

In den 1960ern waren Schweizer Uhren Präzisionsmaschinen. Eine mechanische Uhr enthält über hundert bewegliche Teile: winzige Federn, Zahnräder, Juwelen, Schrauben, Hebel und ein Hemmungswerk. Jedes Teil wird über Wochen oder Monate mit extremer Präzision gefertigt und assembliert. Wer eine teure mechanische Uhr kaufte, kaufte eines der besten kompakten Zeitmessgeräte, die Menschen herstellen konnten.

Dann kam Quarz. Eine Quartzuhr nutzt eine Batterie und einen kleinen Quarzkristall, der mit stabiler Frequenz vibriert. Ein billiger elektronischer Schaltkreis statt einer komplexen Maschine. Das entscheidende Problem: Eine billige Quartzuhr konnte die Hauptaufgabe des Zeitmessens deutlich besser erfüllen als das feinste mechanische Uhrwerk. Dazu war sie dünner und einfacher herzustellen.

Als die Kernfunktion billig wurde, kollabierte die gesamte Basis der alten Industrie.

Die Parallele zur Softwareentwicklung

Die Übertragung ist direkt. Code schreiben wurde lange als einer der teuersten Teile des Aufbaus eines Softwareunternehmens wahrgenommen. Code ist sichtbar und quantifizierbar. Man kann leicht berechnen, was er kostet. Aber die tatsächlich teuren Teile waren immer unsichtbar: Product-Market-Fit finden, Kundenbedürfnisse verstehen, ein profitables Geschäft aufbauen. Die eigentlichen Kosten stecken in allem, was vor und nach dem Codeschreiben passiert.

Jetzt ist Code-Generierung billig genug, dass der Wert eines Entwicklers nicht mehr auf „Mensch, der Syntax in einen Texteditor tippt” reduziert werden kann. Paul Graham beschreibt diese Verschiebung in einem seiner aktuellen Artikel und nutzt exakt dieselbe Uhren-Analogie.

Wer auf dem alten Spielfeld blieb, verlor

Die Schweizer Hersteller, die versuchten, direkt mit Quarzuhren zu konkurrieren, verloren. Omega ist das beste Beispiel. Ihre Reaktion war die typische Ingenieur-Antwort: bessere und präzisere mechanische Uhrwerke bauen. Sie versuchten sogar, im Quarzsegment mitzuspielen. Beides war das falsche Schlachtfeld. Sobald Zeitmessung billig geworden war, führte der Wettbewerb um Zeitmessung in eine Abwärtsspirale. Omega wurde insolvent.

Für Softwareentwickler existiert dieselbe Falle. Wer versucht, KI im reinen Code-Output zu schlagen, konkurriert auf einem Spielfeld, das bereits verloren ist. Die kognitive Belastung durch KI-Tools steigt, aber die Lösung liegt nicht darin, schneller zu tippen als ein Sprachmodell.

Wer das Spielfeld wechselte, überlebte

Patek Philippe und Audemars Piguet wählten einen anderen Weg. Sie erkannten, dass sie nicht mehr auf reiner Performance gewinnen konnten und veränderten, was ihre Kunden eigentlich kauften.

Vor der Quarzkrise sahen viele hochpreisige mechanische Uhren ähnlich aus: klein, dünn, elegant, dezent. Der Markenname stand subtil auf dem Zifferblatt. Das funktionierte, weil der Wert im Inneren der Uhr lag. Sobald der Wert nach außen wanderte, musste die Marke sichtbar werden.

Audemars Piguet brachte 1972 die Royal Oak. Patek Philippe folgte 1976 mit der Nautilus. Beides sind bis heute Ikonen. Die Werbung änderte sich. Die Designs wurden unverwechselbarer. Die Marken setzten auf Tradition, Handfinish, limitierte Produktion und Exklusivität. Einige der begehrtesten Modelle wurden unmöglich zu kaufen, selbst wenn man das Geld hatte. Wartelisten, Beziehungen zu Händlern, Pflichtkäufe weniger beliebter Modelle.

Das Ergebnis: 50 Jahre nach dem beinahe-Kollaps springen Menschen durch Reifen, um eine 20.000-Dollar-Uhr zu kaufen, die schlechter die Zeit misst als eine 20-Dollar-Swatch. Das zeigt, wie vollständig sich das Geschäft verändert hat. In den 1960ern war eine teure Uhr teuer, weil sie eines der besten kompakten Zeitmessgeräte war. Heute ist sie teuer, weil sie Marke, Knappheit, Geschichte, Status und eine Handwerkserzählung transportiert.

Qualität wird zur Grunderwartung

Eine entscheidende Nuance der Uhren-Analogie: Eine Luxus-Uhr muss immer noch gut genug sein. Sie muss immer noch hinreichend genau die Zeit anzeigen. Aber sie muss Quarz nicht mehr auf Genauigkeit schlagen, weil Genauigkeit nicht mehr das ist, was die Uhr verkauft.

Übertragen auf Software: Code-Qualität wird zur Grunderwartung. Sie verkauft nicht mehr allein das Produkt, aber schlechte Qualität zerstört es weiterhin. Die GitClear-Analyse von über 150 Millionen Zeilen kommerziellem Code zeigt, was passiert, wenn Code als billige Commodity behandelt wird. Zum ersten Mal in der Geschichte der Softwareentwicklung hat kopierter und duplizierter Code refaktorierten Code vollständig überholt. Refactoring ist von 25 Prozent aller Code-Änderungen auf unter 10 Prozent gefallen.

Statt Logik zu konsolidieren und wiederverwendbare Module zu bauen, drücken Entwickler Tab und lassen KI redundante, parallele Code-Pfade generieren. Das sieht nach Produktivitätsexplosion aus. In Wirklichkeit ist es eine tickende Zeitbombe technischer Schulden.

Architektur, Datenbanken, Security, Performance, Wartbarkeit, Testing, Deployment: alles weiterhin notwendig. Alles weiterhin schwer. Aber jetzt ist es die Baseline, nicht der Differenzierungsfaktor.

Wenn Antworten billig werden, werden Fragen wertvoll

Der höherwertige Beitrag verschiebt sich: verstehen, was gebaut werden soll. Verstehen, warum es gebaut werden soll. Verstehen, wie es ins Geschäft passt, wie es Nutzer betrifft, wie es gewartet wird und welche Trade-offs akzeptabel sind.

KI hilft beim Generieren von Code. Sie wird auch bereitwillig das gesamte Budget verbrennen, obwohl das Feature sinnlos ist, der Geschäftsprozess kaputt ist, der Nutzer sich nicht dafür interessiert, das Datenmodell falsch ist oder das Team das Symptom statt der Ursache behandelt.

Das bestätigt ein Muster, das sich durch die gesamte aktuelle Diskussion zieht. Ben Edgars von OpenAI zeigt, dass die Arbeit verschoben wird, aber nicht verschwindet. Tom Yeh argumentiert, dass Fundamente jeden Hype überdauern. Beides Facetten derselben Verschiebung: Der Wert liegt nicht mehr im Produzieren, sondern im Entscheiden.

Vom Spezialisten zum Generalisten

Die Bewegung vom Spezialisten zum Generalisten ist in der Softwareindustrie nicht neu. Es gab spezialisierte React-Frontend-Entwickler und DBAs. Aber die wertvollsten Mitarbeiter eines Tech-Unternehmens waren diejenigen, die den gesamten Stack beherrschten: UI-Komponenten implementieren, REST APIs bauen und Deployments verwalten.

Diese Erwartung erweitert sich jetzt. Ein wertvoller Entwickler versteht Produkt, Geschäftsmodell, Design, Distribution, Operations, Security, Performance, Compliance, Support und Kosten. Nicht als Tiefenspezialist in all diesen Feldern. Aber genug, um die Punkte zu verbinden.

Robert A. Heinlein formulierte es in „Time Enough for Love”: „Spezialisierung ist für Insekten.” Wenn die Implementierung billiger wird, wird enge Implementierungskompetenz allein weniger verteidigbar. Der Wert verschiebt sich zu Menschen, die über Grenzen hinweg operieren können.

Nintendos Game Boy: Die Gegenlektion

Die Falle, eine strukturelle Verschiebung mit besserem Engineering beantworten zu wollen, hat ein interessantes Gegenbeispiel. In den späten 1980ern jagten Atari und Sega nach besserer Handheld-Hardware: Farbbildschirme, stärkere Prozessoren, beeindruckendere Spezifikationen.

Nintendo veröffentlichte als Antwort einen grauen Klotz mit Monochrom-Display, ohne Hintergrundbeleuchtung und mit bescheidener Hardware. Nintendos Designer Gunpei Yokoi hatte eine Philosophie namens „laterales Denken mit veralteter Technologie”: alte, billige, bewährte Technologie verwenden, aber auf clevere Weise.

Der Game Boy sah schlechter aus als seine Konkurrenten. Aber er war günstiger, robuster und hatte bessere Akkulaufzeit. Das reichte, um zur Ikone zu werden. Ein besserer Stack bedeutet nicht automatisch ein besseres Produkt. Mehr Features bedeuten nicht automatisch mehr Wert. Manchmal ist die klügste technische Entscheidung, langweilige Technologie einzusetzen und das eigentliche Problem zu lösen.

Umsetzungs-Checkliste

1. Eigene Commodity identifizieren: Welcher Teil der täglichen Arbeit ist durch KI bereits zur Commodity geworden? Reines Code-Tippen, Boilerplate-Generierung, Standard-CRUD-Operationen. Das ist das Zeitmessen. Dort nicht mehr differenzieren.
2. Angrenzende Kompetenz aufbauen: Produkt, Geschäftsmodell, Nutzerverständnis, Systemdesign, Kostenanalyse. Das sind die neuen Differenzierungsfaktoren. Wähle einen davon und baue systematisch Wissen auf.
3. Qualität als Baseline halten: Architektur, Testing, Security und Performance weiterhin beherrschen. Nicht weil es differenziert, sondern weil schlechte Qualität alles andere zerstört. Refactoring-Quote im eigenen Code überwachen.
4. Die richtigen Fragen stellen: Vor jeder Implementierung fragen: Löst das ein echtes Problem? Ist der Geschäftsprozess korrekt? Ist das Datenmodell richtig? Adressieren wir die Ursache oder das Symptom? KI wird diese Fragen nicht stellen.