AI-Coding legt die Trauer und Spaltung von Entwickler:innen offen

• Die Verbreitung von AI-Coding-Tools bringt die unter Entwickler:innen schon immer vorhandenen, aber unsichtbaren Unterschiede in der Motivation an die Oberfläche
• Die Trauer über den Verlust der handwerklichen Befriedigung des eigentlichen Codierens und die Trauer über Veränderungen im Ökosystem und im Karriereumfeld sind zwei unterschiedliche Arten von Verlust
• Aus der Perspektive eines Entwicklers, der seit den 1980er Jahren programmiert, ist AI-Coding die natürliche Fortsetzung von Abstraktionsstufen – von C64 BASIC über Assembler bis hin von Funktionen zur Systemarchitektur
• Die Erfahrung aus jahrzehntelangem Lesen und Reviewen von Code bleibt weiterhin als Gespür und Urteilsvermögen zur Beurteilung von AI-generiertem Code gültig
• Entscheidend ist, zu erkennen, welche Art von Trauer man empfindet; handwerklicher Verlust und kontextueller Verlust erfordern jeweils unterschiedliche Umgangsweisen

---

Der Beginn der Trauer

• James Randall begann bereits mit 7 Jahren in den 1980ern zu programmieren und beschreibt, dass die Erfahrung von Entdeckung und beharrlichem Herausfinden von Dingen „komprimiert“ worden sei
  • Sie ist nicht völlig verschwunden, aber im Komprimierungsprozess ist etwas verloren gegangen
• Nolan Lawson drückt dieses Verlustgefühl in seinem Text "We Mourn Our Craft" noch direkter aus
  • Man werde das Gefühl vermissen, Code mit der Hand zu formen, um 2 Uhr morgens mit dem Debugger einen Bug zu jagen und stolz sagen zu können: „Das habe ich gebaut“
• Diese Gefühle sind echte Emotionen über einen realen Verlust, aber beim Lesen blieb fortlaufend der Eindruck, dass hier unterschiedliche Dinge betrauert werden

Das Wesen der Spaltung

• AI-Coding macht eine unter Entwickler:innen schon immer vorhandene, aber weniger sichtbare Spaltung deutlich
• Vor AI arbeiteten beide Lager auf dieselbe Weise: mit demselben Editor, denselben Sprachen und demselben Pull-Request-Workflow
  • Handwerksorientierte Entwickler:innen und ergebnisorientierte Entwickler:innen saßen nebeneinander, veröffentlichten dieselben Produkte und waren kaum zu unterscheiden
  • Die Motivation hinter der Arbeit blieb unsichtbar, weil der Prozess identisch war
• Jetzt gibt es eine Weggabelung: den Code der Maschine überlassen und nur noch steuern, was gebaut werden soll, oder den Code weiter selbst von Hand schreiben
  • In diesem Moment der Entscheidung wird erstmals sichtbar, warum man überhaupt mit dem Programmieren angefangen hat
• Schon im Mathematik- und Informatikstudium gab es dieselbe Spaltung: Menschen, die Beweise und Theoreme an sich liebten, und solche, die erst dann Interesse hatten, wenn sie auf Anwendungen übertragen wurden

Meine Trauer war anders

• In den letzten 18 bis 24 Monaten gab es tatsächlich eine Phase von Trauer und Anpassung
• Ich hatte Angst, die neuen Werkzeuge nicht verstehen zu können, stellte aber fest, dass ich sie durchaus verstehen kann
• Ich fürchtete, die Fähigkeit zu verlieren, die Qualität von AI-generiertem Code zu beurteilen, doch die Erfahrung aus jahrzehntelangem Lesen und Reviewen von Code ist nicht verdampft
  • Wenn etwas falsch ist, merke ich es immer noch, und mein Urteilsvermögen ist geblieben
• Ich hatte Angst, dass das Lösen von Rätseln vorbei sein könnte, aber in Wirklichkeit bin ich nur eine Stufe höher gestiegen
  • Vom Platzieren von Bytes auf dem C64 → über das Schreiben von Funktionen → bis hin zur Systemarchitektur: dasselbe Muster wie bei allen Übergängen meiner Laufbahn
  • Das Rätsel hat sich jetzt in den Bereich von Architektur, Komposition und der Steuerung von Assistenten verlagert
• Die meisten Ängste hielten der Realität nicht stand, aber ein Teil der Trauer bleibt

Die verbleibende Trauer

• Es geht nicht um die Trauer darüber, HTML nicht mehr von Hand zu schreiben, sondern um das offene Web-Ökosystem selbst
  • Das Training von AI auf Gemeingütern und die zusätzliche Zentralisierung der Kräfte, die die Internet-Erfahrung der Menschen formen, sind reale Verluste
  • Das sind Probleme, die unabhängig von persönlicher Produktivitätssteigerung nicht verschwinden
• Trauer über die Veränderung der Karrierelandschaft
  • Webentwicklung, die ich seit über 30 Jahren mache, ist nicht mehr das heißeste Feld
  • Mobile Apps haben einen Teil übernommen, und AI Engineering nimmt derzeit die führende Position ein
  • Ich glaube zwar, den Übergang zu schaffen, aber die Unsicherheit ist real und noch nicht vorbei
• Der Kern dieser Trauer: Es ist nicht die Sehnsucht nach dem Akt des Codierens selbst
  • Es ist Trauer darüber, dass sich die Welt rund um den Code verändert
  • Die Trauer von Randall und Lawson gilt dem Handwerk selbst, die Trauer dieses Textes dagegen dem Kontext und den Gründen

Keine Seite liegt falsch

• Kevin Lawver argumentiert in seiner Antwort auf Lawson, man solle die handwerkliche Haltung und Leidenschaft neu ausrichten, statt an der Vergangenheit festzuhalten
• Über die einfache Gegenüberstellung von Nostalgie und Pragmatismus hinaus ist es praktisch hilfreich, die Art der eigenen Trauer zu erkennen
• Wer einen handwerklichen Verlust betrauert, dem hilft ein „Pass dich einfach an“ nicht weiter
  • Man muss diese Befriedigung vielleicht an anderer Stelle finden oder akzeptieren, dass sich das Gefühl der Arbeit verändert
  • Dass handwerkliches Arbeiten überhaupt den Lebensunterhalt getragen hat, war bis hierhin bereits ein Glücksfall
• Wer einen kontextuellen Verlust betrauert, hat eher umsetzbare Reaktionsmöglichkeiten
  • Man kann neue Werkzeuge lernen, sich für das Web einsetzen, das man möchte – selbst wenn es nur ein kleines Web ist – und zugleich traurig sein und sich trotzdem anpassen
• Zitat von Nolan Lawson: „Ich feiere diese neue Welt nicht, und ich leiste ihr auch keinen Widerstand. Die Sonne geht auf und unter, und ich kreise machtlos in ihrer Umlaufbahn, und mein Protest kann sie nicht anhalten.“
  • Trotzdem ist es ein ehrliches Eingeständnis, dass sich inmitten von Trauer und Angst auch ein wenig Aufregung findet

Dem Computer Arbeit geben

• Seit ich in den 1980ern mit dem Programmieren begonnen habe, war jede Sprache, die ich gelernt habe, ein Mittel zum Zweck
  • Eine neue Art, den Computer dazu zu bringen, das zu tun, was ich will
• AI-Coding ist die neueste Stufe in genau dieser Entwicklung, nicht ein Bruch, sondern die nächste Sprosse auf der Leiter
• Nur verändert sich diese Leiter selbst, und auch das Gebäude, an das sie gelehnt ist, verändert sich, sodass man nicht genau weiß, wohin es geht
• Sicher ist nur eines: Die Befriedigung in dem Moment, in dem etwas tatsächlich funktioniert, das man sich ausgedacht hat, hat sich seit über 40 Jahren nicht verändert
  • Der Weg, auf dem der Code dorthin gelangt, mag anders geworden sein, aber dieser Moment des Funktionierens ist derselbe

[github88]

Es wird viel zu viel Aufhebens darum gemacht.

[ahwjdekf]

Ich halte es für eine sehr gute Sache, dass KI so etwas wie Webprogrammierung übernimmt.

[brilliant08]

Andere Programmierung scheint also irgendeinen erhabenen Wert zu haben.

[onetoday]

Ich habe manchmal auch das Gefühl, dass das Durchschnittsalter auf HN ziemlich hoch ist und es wie Menschen wirkt, die irgendwie den Anschluss verlieren.
Deshalb überspringe ich solche negativen Beiträge lieber, statt sie zu lesen (nicht kritische, sondern wirklich negative).

Nebenbei bemerkt kommt mir gelegentlich schon noch in den Sinn, wie viel Spaß es macht, selbst direkt zu coden.
Da ich im Webbereich arbeite, ist das vielleicht eher möglich, denke ich,
aber ich tippe inzwischen seit über drei Monaten keinen Code mehr.

Vor allem macht es so entwickelt aber einfach unglaublich viel Spaß, sodass ich wie in jungen Jahren oft ganz freiwillig Überstunden mache.

[snisper]

Wenn AI einem so viele Sorgen macht, kann man es doch einfach nicht benutzen, oder?

[savvykang]

Ich frage mich, wie die Leute damals reagiert haben, als RAD-Tools aufkamen.

[GN⁺]

Hacker-News-Kommentare

• Ich finde, der Text missversteht das Thema völlig. Auch „Craft“-Entwickler sind ergebnisorientiert, aber sie streben Ergebnisse an, die lange Bestand haben und skalierbar sind
  Das Ziel guter Programmierer ist es, sich selbst überflüssig zu machen. Früher zählte man in Assembler Taktzyklen und packte Bits von Hand, aber irgendwann wurde es selbstverständlich, Compiler zu verwenden. Es gab auch eine Zeit, in der man CRUD-Apps direkt selbst gebaut hat, doch heute übernehmen Frameworks das. Speicherverwaltung, Typsysteme, Hochsprachen, No-Code-/Low-Code-Systeme – all das ist Teil des Fortschritts. Letztlich besteht der Zweck des Programmierens darin, Computer dafür zu nutzen, dass wir Dinge nicht mehr selbst tun müssen
  Die eigentliche Spaltung liegt, glaube ich, in der Denkweise: zwischen denen, die Software als etwas sehen, das man verbessern und verstehen kann, und denen, die sie als unverständliches Hindernis betrachten, das andere gebaut haben
  • Diese Sichtweise gefällt mir. Wenn man lange mit einem System arbeitet, fühlt sich jedes Detail bedeutsam an. Man bekommt ein Gespür dafür, welche Auswirkungen eine Änderung auf das Ganze hat. Aber ich sorge mich, dass im Zeitalter von AI-Software ein solches Verständnis unmöglich werden könnte. Es wird wohl so viel Code automatisch erzeugt, dass man das Gesamtbild kaum noch erfassen kann. Wenn Änderungen am Ende zu schwierig werden, ist es womöglich vernünftiger, mit AI einfach neu anzufangen. Deshalb wird Modularität vermutlich noch wichtiger
  • Ich stimme fast allem zu, außer dem letzten Satz. Das ist weniger eine Frage der Intelligenz; ich denke vielmehr, dass die Leute in der zweiten Gruppe in der Praxis oft einfach weniger kompetent sind
  • Ich frage mich, ob diese Unterscheidung der von Pirsig: „klassisch vs. romantisch“ ähnelt. Die erste Gruppe versucht, Struktur und Prinzipien zu verstehen; die zweite legt mehr Wert auf äußere Form, Gefühl und Nutzen
  • Den Satz „Gute Programmierer machen sich selbst überflüssig“ hat man früher oft gehört, heute scheint er fast verschwunden zu sein
• Die eigentliche Spaltung besteht zwischen Menschen, die glauben, technologischer Fortschritt sei grundsätzlich gut, und Menschen, die wissen, dass Produktivitätssteigerungen historisch nicht zu kürzeren Arbeitszeiten geführt haben
  Der Achtstundentag war nicht das Ergebnis von Technologie, sondern von politischem Kampf
  • Die wahre Spaltung verläuft zwischen Kapitalbesitzern und Arbeitern. Kapitalisten leben von einem Teil dessen, was Arbeiter produzieren, abgesichert durch geerbte Papierfetzen
  • Interessant, dass man solche Diskussionen auf Hacker News inzwischen öfter sieht. Wenn AI Entwickler ersetzt, könnten intelligente und motivierte Menschen politisch aufwachen. Historisch wurden Unternehmen, wenn sie zu groß wurden, am Ende wie Staaten behandelt
  • Es gibt hier zu viele extreme Behauptungen. Die eigentliche Spaltung besteht letztlich zwischen Menschen, die Wissenschaft und Technologie unterstützen, und solchen, die sie ablehnen
• Es geht inzwischen nicht mehr einfach nur um Leute, die gern auf mechanischen Tastaturen tippen. Der wirkliche Unterschied ist: Menschen, die gern Systeme verstehen und neue bauen, versus Menschen, die das anderen überlassen und nur das Ergebnis mitnehmen wollen
  Wenn diese „anderen“ allerdings Menschen sind, kann man sich das Verdienst durch Mentoring oder das Schaffen guter Rahmenbedingungen teilen
  • Es ist lustig, wie die „eigentliche Spaltung“ immer wieder auf das Muster hinausläuft: ‚ich, intellektuell oder moralisch überlegen‘ gegen ‚die minderwertigen anderen‘
  • Ich verstehe gern Systeme und baue gern neue, und trotzdem delegiere ich Routinearbeit an AI. Soll ich deshalb nicht existieren dürfen? Sehe ich nicht so
  • Es gibt zwei Arten von Entwicklern. Typ A kümmert sich sorgfältig um Sicherheit, Tests und CI, kann aus Nutzersicht aber frustrierend sein. Typ B ist schwächer bei Tests oder Deployments, legt dafür mehr Wert auf die User Experience. Beide werden gebraucht. Allerdings wird AI wohl zuerst den Bereich von Typ A ersetzen
  • Es fühlt sich an wie: „Claude, heb das hier mal für mich an“
  • Menschen empfinden an unterschiedlichen Punkten Freude. Ich mag den Prozess des Rätsellösens. Spontane Lösungen machen mir mehr Spaß als Planung
• Vor AI haben beide Gruppen dieselbe Arbeit gemacht – mit demselben Editor, denselben Sprachen, demselben PR-Workflow. Der Unterschied lag in der Motivation. Deshalb mögen manche es, wenn AI den Code für sie schreibt, während andere bedauern, dass gerade der Teil verschwindet, der ihnen Freude gemacht hat
  Kellans Text „Code has always been the easy part“ geht in dieselbe Richtung. Unsere Generation ist in die Tech-Welt eingestiegen, weil sie süchtig nach dem Gefühl von Handlungsfähigkeit war, das das Web vermittelt hat
  • Der eigentliche Unterschied sind die Qualitätsmaßstäbe. Manche verbringen Stunden mit einem einzigen Variablennamen, andere denken: „Wenn es läuft, reicht das.“ Beides hat seinen Wert. Aber wegen der schnellen Entwicklung der Modelle sollte man nicht nach dem Stand des letzten Jahres urteilen. Die Standardausgabe ist durchschnittlich, aber wenn man gut damit umgeht, kann man deutlich höhere Qualität erzielen
  • Perl-Programmierung soll ästhetisch keinen Spaß gemacht haben? Ich war stolz darauf, mit Perl zu arbeiten. Es hatte etwas Befriedigendes, eine schwer lesbare Sprache vollständig zu beherrschen
  • Perl hatte definitiv seinen Reiz. Syntax wie unless half dabei, den Fluss natürlich auszudrücken. Aber weil die Weiterentwicklung ins Stocken geraten ist, haben alle es auf ihre eigene Weise erweitert, und so entstanden fragile Codebasen
  • Ich genieße das Coden selbst nicht besonders, aber die Zufriedenheit, ein Problem gelöst zu haben, ist groß. Ich habe das Gefühl, dass diese Art des Denkens mein Gehirn flexibel hält
  • Das ist keine Dichotomie. Ich bin eine Mischung aus beiden Typen. Weil AI das Coding in der Arbeit übernimmt, habe ich zu Hause wieder Muße, traditionell zu coden
• Ich bin ergebnisorientiert. Mir ist die Qualität des Ergebnisses wichtig. Nicht der Coding-Prozess, sondern wie ausgereift das fertige Produkt ist. Aber heutige Apps sind langsamer und fehleranfälliger als vor 15 Jahren. Sogar in der Claude-App tauchen manchmal Buttons auf, die sich nicht klicken lassen
  AI-Coding steigert die Produktivität vielleicht um 10 %. Der echte Flaschenhals ist der Prozess des Verstehens und Überzeugens, was überhaupt gebaut werden soll. Coding ist nur ein Mittel, um dieses Verständnis zu gewinnen
  • Ich nutze AI ebenfalls häufiger für Informationsbeschaffung und Verifikation als fürs Schreiben von Code. Ich setze mehrere LLMs als Reviewer ein und lasse sie sich gegenseitig kritisieren. Das hilft enorm bei komplexer Business-Logik. AI ist auch nützlich bei der Suche nach Edge Cases
  • Ich stimme zu, dass Coding nicht der Flaschenhals ist. Dass AI eine 10-fache Produktivität bringen soll, ist Unsinn. Ich war schon immer schnell beim Coden, daher hilft mir AI nicht besonders. Im Gegenteil, ich gerate dadurch eher in eine Situation, in der Geschwindigkeit über Qualität gestellt wird. Teammitglieder lassen mit AI tausende Zeilen erzeugen, und die Codequalität stürzt ab
  • Du scheinst Codequalität und Produktreife zu verwechseln. Die meisten Probleme entstehen durch Business-Entscheidungen
  • Wenn „nur das Ergebnis zählt“, könnte man auch fragen: Warum macht man es dann nicht einfach selbst per Outsourcing?
• Ich vermisse das „Web, in dem man HTML noch von Hand geschrieben hat“. Es macht mich traurig, dass ein DIY-Web-Ökosystem, das Menschen selbst gebaut haben, durch AI-Tools im Besitz von Unternehmen ersetzt wird. Im Moment befinden wir uns noch in einer Zwischenphase, aber der Niedergang des offenen Webs beschleunigt sich bereits
• Auch generative AI lässt sich als Verlängerung von Handwerkskunst nutzen. Man kann Open-Source-Code laden und fragen: „Warum funktioniert das hier so?“ – also verständnisbasiert entwickeln
  • Der Spaß am Rätsellösen ist nicht verschwunden, sondern eine Ebene nach oben gewandert. Jetzt liegt das Handwerk darin, Struktur und Gründe des Gesamtsystems zu entwerfen
  • Natürlich sollte man die Ergebnisse dann upstream beitragen
  • Eigentlich war so etwas auch früher schon mit Suchmaschinen möglich
• Alle drei Szenarien sind schlecht. ① Schwache AI → Große Depression 2.0, ② AI auf erwartetem Niveau → Monopol einiger weniger Superreicher, ③ extrem starke AI → Auslöschung der Menschheit. Die ideale Menge an AI ist 0
  Trotzdem sollte man Widerstand leisten
  • Ich habe früher auch so gedacht, aber wenn ich mir heute die realen Grenzen nach dem AI-Boom anschaue, wirkt es auf mich so, als würde sich der Markt bald korrigieren. Im Moment sind wir eher noch in einer AOL-Ära
  • Echte Intelligenz bedeutet nicht einfach, Text in Tool-Aufrufe umzuwandeln, sondern umfasst auch Planung, Kritik und kreative Problemlösung
  • Eigentlich profitieren in Szenario 1 und 2 dieselben Leute. Szenario 3 ist eine Illusion, die nur dazu dient, die Aufmerksamkeit der Öffentlichkeit abzulenken
• Nachdem ich lange in Startups gearbeitet habe, habe ich die Idee von „Handwerkskunst“ aufgegeben. Stattdessen habe ich ein Gespür dafür entwickelt, wie gefährlich fehlende AI-Code-Reviews oder zu große PRs sind. Das ist keine Frage von Handwerkskunst, sondern von Genauigkeit und dem Management technischer Schulden
  • Das Problem sind nicht „ergebnisorientierte Leute“, sondern Menschen, die Lorbeeren einstreichen und Arbeit meiden. Wenn ihr Code auseinanderfällt, sind sie längst beim nächsten Projekt
  • Meiner Erfahrung nach ist nicht der Gegensatz „Handwerkskunst vs. Ergebnis“ entscheidend, sondern eher das Gespür dafür, das ganze Gebäude gut zu bauen. Es ist okay, wenn AI wie ein Subunternehmer einzelne Teile übernimmt, aber momentan sind wir an dem Punkt, an dem das Ganze ausgelagert wird – und das Ergebnis ist chaotisch
• Es gibt zwei Arten von Entwicklern: solche, die das Coden so sehr lieben, dass sie keine Manager werden, und solche, die bei der ersten Gelegenheit ins Management wechseln. Von AI profitiert eher die zweite Gruppe
  • Menschen, die gut mit anderen umgehen können, sollten Manager werden. Und es gibt auch eine dritte Gruppe: Menschen, die Systemdesign lieben und die Implementierung anderen überlassen