Identitätskrise der Programmierer

• Die Identität von Programmierern wird durch das jüngste Aufkommen von KI- und LLM-Tools bedroht
• Die Programmierkultur begann mit der Hacker-Ethik am MIT in den 1950er Jahren und betrachtete das Schreiben von Code an sich als tiefgehendes Handwerk, dessen Kernwerte präzise Logik und die vertiefte Hingabe an Problemlösung waren
• Doch die heutige KI-Industrie und LLM-Tools versuchen, Entwickler zu bloßen Spezifikationsschreibern oder Operatoren zu machen, und drängen ihnen eine Form des "vibe-coding" auf, bei der sie statt selbst Code zu schreiben nur noch Anweisungen in natürlicher Sprache geben
• Von LLMs erzeugter Code ist nicht deterministisch und ungenau und beseitigt das tiefe Verständnis und den Flow, die Entwickler beim eigenen Lesen und Schreiben von Code gewinnen, wodurch die Verbindung zur Codebasis abbricht
• Unternehmen erzwingen die Nutzung solcher Tools unter dem Vorwand höherer Produktivität und ersetzen Teamarbeit und Mentoring-Kultur durch Interaktion mit KI, was die menschliche Verbindung zwischen Entwicklern schwächt
• Der wesentliche Wert von Programmierung als Prozess des Denkens und Verstehens statt bloß als Output geht verloren, und Entwickler müssen sich diesem Wandel widersetzen, um ihr Können, ihre Freude und ihre berufliche Identität zu bewahren

---

Wesen und Tradition des Programmierers

• Code zu schreiben ist nicht bloß eine Aufgabe, sondern die Identität des Entwicklers selbst; der Editor ist Werkstatt und Heiligtum zugleich, ein Ort zum Verfeinern des Könnens und zum Eintreten in den Flow-Zustand

  • Mit Werkzeugen wie Vim arbeitet man ohne Barriere zwischen Gedanken und Code und erschafft eine immaterielle Welt, die Auswirkungen auf die reale Welt hat
  • Der Prozess des Rätsellösens ist wichtiger als das fertige Bild, und im Fluss des Könnens von den Fingern in den Buffer verschwindet die Zeit

• Am MIT entstand Ende der 1950er Jahre eine neue Programmierkultur, als experimentelle, gegenkulturell geprägte Hacker mit dem Flexowriter und dem TX-0-Computer arbeiteten und nach perfekten Programmen strebten

  • Im Zentrum stand das Konzept von "The Right Thing", also das Ziel, eleganten und knappen Code zu schreiben
  • Mitglieder des Tech Model Railroad Club vertieften sich in Maschinensprache, lernten digitale Magie und etablierten eine Kultur des Teilens entdeckten Wissens mit anderen Studierenden

• Im Schmelztiegel des Computings in Building 26 wurde das Handwerk des Codens geschmiedet, und diese vor rund 70 Jahren entstandene Kultur lebt bis heute fort und existiert weiterhin in den Köpfen der Entwickler und in den Maschinen

  • Das Erbe der frühen Hacker besteht als tiefes, beinahe körperliches Können fort, auf dem eine leidenschaftliche Industrie aufgebaut wurde
  • Entwickler werden noch immer von demselben Staunen, demselben Gefühl der Leistung und derselben Eleganz des Rätsellösens angetrieben

• Doch diese Kernwerte, aus denen sich die Identität des Programmierers zusammensetzt, sind bedroht, und die einst helle und klare Zukunft der Programmierung wird nun von düsterer Finsternis, Betrug und Unsicherheit überschattet

Die KI-Industrie erzwingt eine neue Identität

• Die milliardenschwere KI-Industrie, die Hacker-News-Community und LLM-Befürworter auf LinkedIn behaupten, die Zukunft der Softwareentwicklung sehe dem Programmieren kaum noch ähnlich, und aus dem, was vor einem Jahr wie ein Meme wirkte, ist nun Mainstream geworden: "vibe-coding"

  • Entwickler sollen statt Code Spezifikationen in Markdown schreiben, während die tiefe Vertiefung und das handwerkliche Können verschwinden, die einst daraus entstanden, jede Ecke einer Codebasis zu erkunden, Rätsel zu lösen und Geheimnisse zu entdecken
  • Stattdessen soll man zerstreute Kognition und ständige Kontextwechsel akzeptieren, während Agenten für den Entwickler denken; kreative Problemlösung wird den Maschinen überlassen und der Entwickler wird zum bloßen Operator

• Manche Entwickler begrüßen diesen Wandel und die neue Identität namens "Specification Engineering" und sind begeistert davon, als Operator wie Steve Jobs "das Orchester zu dirigieren"

  • Es wirkt fragwürdig, warum sie überhaupt Programmierer geworden sind, wenn sie sich offenbar nicht fürs Codieren interessieren; vielleicht haben sie Woz und Jobs verwechselt
  • Prompt, Context und Specification "Engineering" scheinen Programmierern keine helle und prosperierende Zukunft zu versprechen

• Das bedeutet einen Wertverlust von Technik, Können und Arbeit; die einzigartige Fähigkeit des Entwicklers zu abstraktem Denken wandert in einen Bereich ab, in dem sie nicht mehr gebraucht wird, hinein in einen Raum, den Produktmanager und Designer bereits besetzt haben

Veränderte Machtverhältnisse im Unternehmen

• Während diese neue Identität in Unternehmen erzwungen wird, verschieben sich die Machtverhältnisse; in einem fanatischen Versuch, Produktivität an der falschen Stelle zu steigern, werden Entwickler zunehmend gezwungen, LLMs auf immer konkretere Weise einzusetzen

  • Wer sich nicht anpasst, wird verdrängt und muss entweder ein Produkt nutzen, das die eigene Überflüssigkeit signalisiert, oder kündigen
  • Früher gaben Führungskräfte nur selten derart konkrete Vorgaben für die Werkzeuge von Entwicklern

• Entwickler waren immer stolz darauf, ihre Werkzeuge zu kuratieren und zu verfeinern, ähnlich wie Köche oder Tischler; über sorgfältige Editor-Konfigurationen, Anpassungen an Dotfiles und die Einrichtung ihrer Entwicklungsumgebung personalisierten sie ihre Tools nach ihrer Denkweise

  • Sie haben sich der Personalisierung ihres Werkzeugsets als Teil ihres Könnens verschrieben, doch wenn eine Führungsebene, die mit der täglichen Arbeit kaum verbunden ist, dies anordnet, fühlt es sich wie ein Eingriff an
  • Für Programmierer, die über Jahrzehnte im Unternehmen bevorzugt behandelt wurden, liefert dieses Narrativ dem Management eine neue Möglichkeit, das Gleichgewicht wieder zu seinen Gunsten zu verschieben

Der grundlegende Unterschied zwischen LLMs und Programmiersprachen

• Manche vergleichen die Wirkung von LLMs mit dem Übergang von Low-Level- zu High-Level-Sprachen wie von Assembly zu Fortran, doch dieser Vergleich ist in vieler Hinsicht falsch

  • Fortran war im Programmieren verwurzelt, versuchte das Können nicht zu beseitigen, sondern baute darauf auf, und erweiterte die Präzision und Ausdruckskraft des Programmierens, statt sie zu entfernen
  • Fortran erzeugte für Eingaben zuverlässig stets korrekte Ergebnisse, doch in der Welt der LLMs gilt nichts davon

• Computer und Programmierung können äußerst frustrierend sein, aber zumindest auf Präzision konnte man sich immer verlassen; durch Programmierung tun sie exakt das, was man ihnen vorgibt

  • Gerade wegen dieser Abhängigkeit von der Präzision des Computers ist es leicht, einem Chatbot zu glauben, wenn er einen glauben machen will, er habe die angeforderte Aufgabe ausgeführt

• LLMs und ihre Arbeitsweise sind von Natur aus unpräzise; sowohl die Eigenschaften großer Sprachmodelle als auch die Art, ihnen Anweisungen in natürlicher Sprache zu geben, lassen viel Raum für Missverständnisse

  • Es ist bemerkenswert, dass ausgerechnet Programmierer, die Nichtdeterminismus hassen und Vorhersagbarkeit, Komponierbarkeit, Idempotenz und stabile Integrationstests bevorzugen, sich für diesen Ansatz entschieden haben
  • LLM-Code steht für das Gegenteil: inkonsistentes Chaos

• Dijkstra wies in "On the foolishness of natural language programming" darauf hin, dass die Annahme hinterfragt werden müsse, natürliche Sprache werde Aufgaben vereinfachen; der Vorteil formaler Texte bestehe darin, dass sie nur wenige einfache Regeln erfüllen müssen, um gültig zu sein

Verlust von tiefem Verständnis und Flow

• Es gibt Versuche, KI-gestützte Entwicklung durch Strenge und Bürokratie vom vibe-coding abzugrenzen, doch das ignoriert das Grundproblem

  • Von LLMs erzeugten Code liest man nicht so genau, wie man eigenen Code oder einen PR-Review lesen würde; im LLM-Coding steckt etwas, das den Blick abstumpfen lässt
  • Man überfliegt ihn nur, fühlt sich überfordert und gelangweilt und akzeptiert gefährliche Fallstricke blind, solange CI grün ist und das Programm kompiliert
  • Man prüft nicht, ob Tests überhaupt so eingerichtet wurden, dass sie laufen, ob nicht existierende Bibliotheken importiert wurden oder ob die gesamte Bibliothek kurzerhand selbst nachgebaut wurde

• Eine Rezension oder Zusammenfassung eines Buches kann die Erfahrung des eigenen Lesens nicht ersetzen; es braucht den Prozess, über Hunderte Seiten hinweg jeden Satz sorgfältig aufzunehmen und über die Ideen nachzudenken

  • Ebenso nimmt das Überfliegen einer Zusammenfassung von von KI erledigter Arbeit einem das tiefe Verständnis von Domäne, Problem und möglichen Lösungen und kappt die Verbindung zur Codebasis
  • Sich in den Abgrund des Nichtwissens zu stürzen, ein Thema und seine Implikationen offenzulegen, zu lernen und zu verstehen, ist befriedigend und essenziell für gute Software
  • Eigentümerschaft, Handlungsfähigkeit und tief befriedigende Arbeit werden durch zerstreute Aufmerksamkeit zwischen Agent-Tabs ersetzt

• Joan Didion sagte: "Ich schreibe, um herauszufinden, was ich denke, was ich ansehe, was ich sehe und was es bedeutet", und Peter Naur untersucht denselben Gedanken in "Programming as Theory Building"

  • Naurs "Theory" verkörpert das Verständnis einer Codebasis, einschließlich ihrer Funktionsweise, ihres Formalismus und ihrer Abbildung der realen Welt
  • Dieser Kontext und diese Einsicht entstehen nur durch Vertiefung; Naur beschreibt die "Theory" als das wichtigste Ergebnis des Programmierens und als das eigentliche Produkt, wichtiger noch als die Software selbst
  • Nur mit einer gut entwickelten "Theory" lassen sich Erweiterungen und Bugfixes wirksam auf eine Codebasis anwenden

• Gutes Design entsteht aus Vertiefung und zeigt sich in der Hin-und-her-Arbeit im Textbuffer und oft auch fern der Tastatur

  • Weil man die gesamte Codebasis nicht im Kopf halten kann, muss man in Module, Klassen und Funktionen eintauchen, um ein unscharfes mentales Modell zu schärfen
  • Man muss Code lesen und schreiben, um die eigene Kognition zu erweitern und Vertrautheit sowie Verständnis für die Problem-Domäne zurückzugewinnen

• Ist erst einmal ein Teil des Kontexts aufgebaut, kann man durch viele unzureichende Versuche schließlich zu einer Lösung finden, und man muss die Dissonanz schlechten Designs spüren

  • Erst wenn man abscheulichen, repetitiven Code geschrieben hat, erkennt man, dass es einen besseren, knapperen, eleganteren, besser komponierbaren und wiederverwendbaren Weg gibt
  • Das bringt einen dazu, innezuhalten, tief über das Problem nachzudenken, einen Schritt zurückzutreten und noch einmal von vorn zu beginnen
  • Im Gegensatz dazu ist die Arbeit mit KI-Agenten reibungslos, sodass alternative Lösungen eher vermieden werden; man weiß nicht, ob das Akzeptierte perfekt, mittelmäßig, furchtbar oder sogar schädlich ist

Zerfall von Teamarbeit und menschlicher Verbindung

• Die kognitive Schuld von LLM-zentriertem Coden geht über den Verlust von Können hinaus; slop-jockeys mit kurzer Aufmerksamkeitsspanne werfen ihre Ergebnisse in Pull Requests und Design-Dokumente und behindern so die Zusammenarbeit und das Team

  • Kolleginnen und Kollegen im Code-Review verlieren fast den Verstand angesichts der schockierenden Erkenntnis, dass sie nun nicht mehr die letzte, sondern die erste Qualitätssicherungsschicht sind
  • Sie müssen auf neu hinzugefügte, aber nie aufgerufene Funktionen, halluzinierte Bibliotheken und offensichtliche Laufzeit- oder Compiler-Fehler hinweisen
  • Der Autor, der den eigenen Code offenkundig nur grob überflogen hat, übernimmt keine Verantwortung und sagt: "Claude hat das so geschrieben. Dumme KI, haha."

• Mikromanagende Vorgesetzte und auf Kostensenkung bedachte Führungskräfte drängen Teams dazu, menschliche Interaktion zu reduzieren, vermutlich in der Hoffnung, vielleicht auch unbewusst

  • In Isolation und von Verbindung abgeschnitten, wird man nun ermächtigt und ermutigt, Mauern um die eigene Arbeitserfahrung zu ziehen
  • Wenn man Pair-Programming braucht, Hilfe beim Diskutieren und Austauschen von Lösungen, beim Prototyping, beim Skizzieren von Architektur oder bei Expertenfragen zu obskuren Teilen der Codebasis, verlässt man sich statt auf Menschen auf LLMs
  • Man braucht keinen Onboarding-Buddy, Mentor oder Kollegen mehr; stattdessen kann man mit einer Maschine sprechen
  • Es ist mit LLMs zu leicht geworden, menschlichen Kontakt zu vermeiden, und genau das könnte zum Standard werden

Verteidigung der Identität des Programmierers

• Es ist erschreckend, wie bereitwillig wir uns dem KI-Hype-Narrativ unterwerfen, aktiv an der geplanten Auslöschung von Können teilnehmen und unsere Mittel zum Denken freiwillig aufgeben

  • Wir gehörten zu den Glücklichen, die ihren Lebensunterhalt mit einem Hobby verdienen konnten; selbst wenn wir strenge und sorgfältige Prozesse schaffen, um auf Slop zu reagieren, lagern wir dennoch die interessanten Teile der Arbeit aus und ersetzen sie durch anweisungsgetriebene Schinderei

• LLMs wirken wie eine Lösung aus dem Orbit mit einer Atombombe für die Komplexität von Software: Statt echte Probleme zu lösen, greift man zu etwas noch Komplexerem und Undurchsichtigem, um lediglich Symptome zu behandeln

  • Es ist in Ordnung, sed durch Claude zu ersetzen oder Antworten über eine Bibliothek oder ein Framework einzuholen, in dessen Dokumentation man selbst nach stundenlanger Suche keine Klarheit gefunden hat
  • Aber man will nicht bloß zum Operator oder Code-Reviewer werden und bei der spaßigen und interessanten Arbeit nur noch auf der Rückbank sitzen

• Man bevorzugt Werkzeuge, die bei repetitiver Arbeit helfen, die Codebasis verständlicher machen und beim Schreiben korrekter Programme unterstützen, und empfindet Abscheu gegenüber Produkten, die dafür gebaut sind, für einen zu denken

  • Man lehnt Produkte ab, die die eigene Handlungsfähigkeit beim Verständnis der produzierten Software entfernen und die Verbindung zu Kolleginnen und Kollegen kappen
  • Selbst wenn LLMs dem Hype gerecht würden, würden wir all das und unser Können trotzdem verlieren
  • Menschen sind wichtiger als Maschinen und die Unternehmen, die sie unterstützen; während der Rest von uns dem neuen amerikanischen Traum hinterherjagt, den sie verkaufen, verdienen sie daran
  • Im Gegenzug geben wir womöglich kritisches Denkvermögen, Spaß, Können, Privatsphäre und vielleicht sogar den Planeten auf

[command2alt]

Stimme ich im Großen und Ganzen zu
Vor allem Context Switching? Man stellt einen Prompt und während der Wartezeit geht der Fokus verloren, was die Produktivität senkt. Wenn LLMs schneller werden und sofort reagieren, könnte sich das vielleicht lösen.

[serithemage]

Der Text selbst wirkt stark so, als sei das Fazit schon vorher festgelegt worden. Das Problem, dass Entwickler:innen ihre Ownership verlieren, liest sich unabhängig von LLMs eher als eine Geschichte von der „Ära des Handwerksgeists vs. der Ära der Industrialisierung“.

[GN⁺]

Hacker-News-Kommentare

• Am meisten Eindruck hat auf mich gemacht, wie Code-Reviewer zunehmend mental ausbrennen, weil sie erkannt haben, dass sie nicht mehr die letzte Stufe der Qualitätssicherung sind, sondern die erste Verteidigungslinie. Man bekommt eine Review-Anfrage und muss jetzt einzeln neu hinzugefügte, nicht aufgerufene Funktionen, plötzlich eingebaute Libraries sowie offensichtliche Runtime- oder Compile-Fehler herausfischen. Die Verfasser des Codes entziehen sich der Verantwortung und winken mit einem „Das hat Claude geschrieben, die AI hat wohl einen Fehler gemacht, haha“ ab. Seit der Einführung von LLMs fühlt sich Brandolinis Gesetz ganz real an: Die Energie, die nötig ist, um Unsinn zu widerlegen, ist viel größer als die, die nötig ist, ihn zu produzieren. Wenn unerfahrene oder technisch schwächere Entwickler in ein paar Minuten Tausende Zeilen Code ausspucken, wird die Verantwortung, die Systemgesundheit tatsächlich sicherzustellen, nun auf die Code-Reviewer abgewälzt. Wenn man sich das added/removed-LoC-Delta in PRs anschaut, dann bestehen von LLMs geschriebene PRs fast nur aus immer mehr hinzugefügtem Code, während erfahrene Senior Engineers oft genauso viel bestehenden Code löschen wie neuen Code hinzufügen

  • Meiner Meinung nach ist das kein technisches, sondern ein menschliches Problem. Wenn so etwas einmal passiert, sollte man streng warnen, und wenn es ein zweites Mal vorkommt, sollte man es an den Manager eskalieren und ablehnen. Egal, wer den PR geschrieben hat: Am Ende steht dein Name auf dem Ergebnis. Wenn der Code also Müll ist, trägst du auch die Verantwortung dafür

  • Ich mache zwar schon länger keine Code-Reviews mehr in großen Teams, aber wenn ich in so einer Situation wäre, würde ich so ein Abschieben von Verantwortung vielleicht einmal durchgehen lassen. Wenn es sich wiederholt, würde ich versuchen, die Person loszuwerden. Wenn das nicht möglich wäre, würde ich selbst kündigen. So schlimm ist dieses Umfeld

  • Ich glaube, dass auch mein Gefühl sinkender Produktivität damit zusammenhängt. Da ist einerseits der Druck, mehr Code schneller zu produzieren, und andererseits die Tatsache, dass ich bei agentenartigen Tools den Gesamtkontext des von mir geschriebenen Codes nicht mehr wirklich im Blick habe. Qualität kann ich nur in dem Bereich garantieren, den ich Zeile für Zeile gründlich reviewen kann, und genau da liegt die Grenze. Deshalb nutze ich AI inzwischen langsamer und vorsichtiger und schreibe wieder mehr selbst von Hand. Bei klaren Typdefinitionen oder wenn Spezifikationen wiederholt auf mehrere Eigenschaften angewendet werden müssen, hilft AI ein wenig, aber selbst dann ist das Ergebnis nicht immer zuverlässig

  • Je erfahrener ein Senior Engineer ist, desto häufiger schrumpft er bestehenden Code ungefähr in dem Maß, in dem er neuen hinzufügt. Der Text Negative 2,000 Lines Of Code ist dazu ebenfalls lesenswert

  • Sobald LLMs im Spiel sind, zeigt sich darin meiner Meinung nach ein breiteres gesellschaftliches Problem: wem wir Verantwortung zuschieben. Wenn das Ergebnis gut ist, reklamieren Menschen es für sich selbst; wenn es schlecht ist, schieben sie bequem der AI die Schuld zu. Ich glaube, schon ein paar passende Gerichtsverfahren würden diese Kultur stark verändern

• Ich habe schon lange das Gefühl, dass viele Leute, die in die Branche kommen, Code nicht als Handwerk sehen, sondern als Mittel, leicht Geld zu verdienen. Seit ich Texte darüber gesehen habe, dass Open-Source-Infrastrukturentwickler kaum ihren Lebensunterhalt bestreiten können, dann diese Entwickler im Café, Bootcamps und die Bewegung „du musst nur coden lernen“, Leetcode-Grinder und Entwickler in San Francisco, die wegen der Mieten im Auto wohnen – und jetzt ist das Thema, sich mit AI selbst zu automatisieren und dadurch den Job zu verlieren. Das Problem ist die Wahrnehmung, dass Entwickler keine echten Professionals sind. Die Standards sind locker, es gibt keinen Ethikkodex, kein konsistentes Skillset und keine echte Repräsentation. Die Branche ist nicht einmal handlungsfähig genug, um ihre eigenen Interessen zu vertreten, eher im Gegenteil. Anwälte haben Anwaltskammern, Ärzte haben Ärztekammern, aber Entwickler haben nur ontologische Unsicherheit. Inzwischen droht der Chef mit Sätzen wie: „Ich automatisiere deinen Job mit AI weg.“ Andere freie Berufe sind ihren eigenen Interessen nicht so feindlich gesinnt, und ich frage mich selbst, warum das ausgerechnet in dieser Branche so ist

  • Ich denke, zwischen „Coder“ und Software Engineer gibt es einen Unterschied. Nur weil jemand ein Bootcamp absolviert hat und mit Python ein kleines Programm schreiben kann, ist er noch kein Software Engineer. Wenn ich sage, dass ich einen Abschluss habe, wird mir Elitarismus vorgeworfen, und ich höre dann, was man in Informatik lerne, sei für die Praxis nutzlos. Gleichzeitig gibt es natürlich Menschen ohne Abschluss, die sich aus eigener Kraft zu hervorragenden Engineers entwickelt haben. Trotzdem stimme ich zu, dass es in irgendeiner Form Standards braucht. Wenn ein Bootcamp-Absolvent bei einem angesagten Buzzword-Unicorn-Startup anfängt, kann man ihm einfach gratulieren, aber sensible Systeme wie Therac-25 sollten meiner Meinung nach besser von formal ausgebildeten Leuten betreut werden

  • Der Chef sagt: „Wenn du nicht automatisierst, verschwindet dein Job“? Genau das ist doch unsere Arbeit. Arbeit zu automatisieren ist der Kern unseres Berufs, und wir sind die Berufsgruppe mit der größten Chance und dem größten Verständnis dafür, den eigenen Arbeitsplatz selbst zu automatisieren

  • Ich glaube, der Lehrberuf hat gewisse Ähnlichkeiten mit der Entwicklerrolle. Es gibt großartige Lehrer, schlechte Lehrer und alles dazwischen. Nur weil man ein Fach gut kennt, heißt das nicht, dass man es gut vermitteln kann. Vielleicht sind Entwickler Lehrer für Maschinen. Manche bringen buchstaben- und gedankenweise einem Merchandise-Charakter etwas bei, andere eher über den allgemeinen Vibe

• Lassen wir LLMs kurz beiseite: Es gibt manchmal Code, den ich so gut geschrieben habe, dass ich wirklich stolz darauf bin. Vom Aufbau bis zu jeder einzelnen Zeile gibt es dann keine unbegründete Entscheidung mehr; bei diesem Code bin ich der Experte und habe alles vollständig im Kopf. Aber den Großteil meines Codes schreibe ich nicht so perfekt. Meistens nach dem Motto: „Hauptsache, die Aufgabe ist erledigt“, und ich erlaube mir selbst einen etwas niedrigeren Standard. Trotzdem sind die Momente, in denen ich wirklich tief eintauche und etwas sehr Ausgereiftes baue, enorm befriedigend und gehören zu meinen besten Code-Erfahrungen überhaupt. Wenn man LLMs mitdenkt, ist hochwertiges Coden einerseits leichter geworden, andererseits aber auch schwieriger. Psychologisch kann man, wenn man tief fokussiert ist, LLMs gut einsetzen, um schneller und auf höherem Niveau zu Ergebnissen zu kommen. Ich kann deutlich besseren Code schreiben als ein LLM, aber mit Hilfe eines LLM kann ich auch noch besseren Code schreiben. Das Problem ist nur, dass es immer schwerer wird, diesen Fokuszustand zu halten. Man überfliegt den vom LLM erzeugten Code nur grob, optisch sieht er ordentlich aus und funktionieren tut er auch, also lässt man ihn einfach durch. Aber so ein nur oberflächlich abgenommener Code wird nach und nach immer schlechter, und wenn man ihn lange genug in diesem abgestumpften Zustand durchwinkt, ist es irgendwann zu spät. Am Ende wird man nicht selbst zum Experten für diesen Code, sondern häuft nur schlampigen Code an

  • In den letzten zwei Monaten habe ich mehr mit AI gearbeitet und dabei ungefähr folgenden Prozess durchlaufen:
    1. Ich habe AI erst nur für kleine Aufgaben eingesetzt und war beeindruckt, wie gut das funktionierte
    2. Dann habe ich ihr nach und nach größere Aufgaben gegeben und versucht herauszufinden, wie man sie effizient nutzt
    3. Irgendwann arbeitete die AI fast wie ein Agent, erledigte praktisch alles selbst, und ich habe am Ende nur noch den Code reviewt
    4. Dann wurde mir klar: „Am Ende muss ich doch den gesamten Code selbst gründlich prüfen, und AI ist nicht die Abkürzung, die ich mir erhofft hatte“ (z. B. ist es unmöglich, nur grob die Richtung vorzugeben und dafür einen plausiblen finalen Code zu bekommen)
    5. Also bin ich wieder dazu zurückgekehrt, AI nur für kleinere Aufgaben einzusetzen AI ist meiner Meinung nach nützlich für Recherche, Prototypen, POCs oder allgemein Wegwerfcode, also Code, der zwar irgendwie läuft, aber in Produktion niemals einsetzbar wäre. Fundamentales Design und Architektur mache ich lieber selbst, während AI bei kleinen Aufgaben wie der Implementierung von Funktionen oder dem Ausfüllen von Detaillogik ziemlich hilfreich sein kann

• Dieser Essay hat genau meine Gedanken getroffen, und ich habe ihn mit Freude gelesen. Wir haben in der Firma versucht, AI einzusetzen, aber in den meisten Fällen war das Ergebnis so mäßig, dass ich am Ende fast alles selbst neu geschrieben habe. Ich bin überzeugt, dass es für meine Karriere die schlechteste Entscheidung wäre, unnötige Denkzeit oder Problemlösung an AI abzugeben. AI ist letztlich nur ein Textgenerator von mittlerer Qualität

  • Was mich am meisten frustriert: Ich könnte LLM-basiertes Coding eigentlich wirklich gut. Meine Kollegen sind völlig in dieser neuen Welt aufgegangen, produzieren ständig nur AI-Slop-Code und brauchen für alles ewig. Im Gegensatz dazu habe ich ein gutes Gespür für Softwarearchitektur und weiß auch besser, wie man einem LLM wichtige Corner Cases vorgibt, also wie man AI richtig anweist. Außerdem kann ich Kontext gut managen, und wegen meiner neurodivergenten Eigenschaften habe ich lange darin trainiert, mit Wesen zu kommunizieren, die anders funktionieren als ich selbst – dadurch kann ich mich auf mechanischere Weise in LLMs einfühlen. Meine Kollegen sind frustrierter, weil LLMs ihre Gedanken nicht erraten. Aber LLMs werden immer besser, also wird mein Vorsprung nicht ewig halten. Und je mehr AI-Slop sich anhäuft, desto mehr LLMs muss man einsetzen, um ihn überhaupt noch zu bewältigen – ein Teufelskreis. Am Ende versteht niemand mehr, was der Code eigentlich macht, und ich bete vielleicht nur noch zum Maschinengott

• Auf die Frage „Warum haben diese Leute überhaupt beschlossen, Programmierer zu werden? Sie scheinen sich doch gar nicht für Code selbst zu interessieren“ würde ich betonen: Das Ziel ist Problemlösung. Coden ist ein Mittel, nicht das Ziel selbst. „Editor-Konfiguration, Dotfiles, an der Entwicklungsumgebung herumschrauben“ kann Spaß machen, aber ich halte das für unnötige Komplexität und würde es gern delegieren

  • Editor, Dotfiles und Entwicklungsumgebung selbst einzurichten bedeutet letztlich, Vertrautheit mit der eigenen Arbeitsumgebung aufzubauen, Werkzeugkompetenz zu entwickeln und ein produktiveres Setup zu schaffen. Dass man bei Build-Skripten zu der Person wird, die „man ruft“, liegt genau an dieser Art von Pflege. Es gibt erschreckend viele Leute, die seit zehn oder zwanzig Jahren Git benutzen und trotzdem Merge-Konflikte oder die Grundlagen nicht verstehen. Am Ende landet dann jede lästige Aufgabe bei den Leuten, die die Tools wirklich beherrschen

  • Die Behauptung „Das hat keinen Wert“ kann, wenn man sie logisch bis zum Ende treibt, schnell bei „Welchen Wert hat Existenz überhaupt?“ landen

  • Bei fast allen Berufen auf der Welt geht es darum, Probleme zu lösen, also frage ich mich: Warum hat man sich ausgerechnet für Software entschieden?

  • Der Aussage „Problemlösung ist das Ziel, Coden nur das Mittel“ stimme ich zu 100 % zu. Wenn Menschen traurig sind, weil AI das Coden übernimmt, dann sind das eher „Code-Künstler“, die stärker an der Form dessen hängen, was sie machen. Ich selbst konzentriere mich auf das Problem, daher stört es mich überhaupt nicht, wenn AI das Coden übernimmt

  • Sowohl die Aussage „Coden ist nicht das Ziel, sondern nur ein Mittel“ als auch „Am Editor herumzuschrauben macht zwar Spaß, ist aber wertlos“ sind durch und durch subjektiv. Es gibt Menschen, die reines Coden an sich lieben würden, selbst wenn keine Problemlösung mehr nötig wäre, und viele würden auch dann noch gern coden, wenn es auf der Welt überhaupt keine Probleme mehr gäbe

• Ich fand diesen Text wirklich sehr interessant. Er deckt sich fast vollständig mit dem, was ich beim LLM-Programmieren empfinde. Ich war einfach jemand, der das Coden mochte, und ich hatte auch beruflich Freude daran. Aber inzwischen kann ich bei der Arbeit das Hobby, das ich geliebt habe, nicht mehr ausleben. Es ist zu einer völlig anderen Tätigkeit geworden

• Ich bin schon etwas älter. Um 1995 herum habe ich in einer völlig anderen Welt programmiert als heute. Damals kannten Engineers ihre Zielkunden, den Tech-Stack und die Branchentrends, und sie hatten wirklich die Kontrolle. Der eigene Code war der eigene Spielplatz; man konnte ihn nach Belieben umbauen und entschied selbst über Einrückung oder Klammerstil (und reparierte es auch selbst, wenn etwas kaputtging). Unit-Tests gab es praktisch nicht – höchstens Parameterprüfungen –, und formale Code-Reviews waren selten; stattdessen unterhielt man sich mit Kollegen im Büro und stand am Whiteboard. Wenn es Bugs gab, wurden sie einfach direkt behoben. Letztlich hat das Management gewonnen, und ich glaube nicht, dass diese Ära des „Cowboy Coding“ zurückkommt. Man kann Apple der 90er vermissen, aber zurück dorthin geht es nicht mehr. Es hat damals wirklich Spaß gemacht

  • Ich habe in einer ähnlichen Zeit angefangen, und bei uns gab es wegen ISO 9001 regelmäßige Code-Reviews. Die Artefakte wurden ausgedruckt, drei Leute saßen in einem Raum, gingen jede Zeile durch und mussten unterschreiben. Das haben wir bei einem industriellen Steuerungs-RTOS so betrieben. Das Projektmanagement lief über ein ausgedrucktes 40-Fuß-Gantt-Diagramm an der Wand. Reine Waterfall-Zeit

  • Ich habe Ende der 2000er angefangen, und damals waren Karrierepfade und Fachgrenzen viel klarer. Systemadministratoren und Entwickler waren eindeutig getrennt, während heute von mir zusätzlich noch erwartet wird, Aufgaben eines System Operators zu übernehmen, wodurch mein Arbeitsbereich eher gewachsen ist. Meine System-Skills habe ich nur als Hobby ausgebaut, und wenn ich solche Aufgaben real übernehmen musste, waren Vendor-Dokumentation und Trainings in der Praxis oft so schlecht, dass man am liebsten sofort wieder davon weg wollte

  • Ich glaube nicht, dass die gesamte Branche wieder zu Cowboy Coding zurückkehrt, aber in manchen Umgebungen lebt dieser Stil sicher noch weiter. Bei WhatsApp war es zwischen 2011 und 2019 wohl recht frei. Je nach Umfeld hängt es davon ab, was es kostet, Fehler vorher zu finden oder erst in Produktion zu beheben. Ich persönlich bevorzuge einen Ansatz, der die Kosten für Fehlerbehebungen niedrig hält. Natürlich versuche ich trotzdem, keine peinlichen Fehler zu machen, und teste das, was wirklich nötig ist

  • Inzwischen sind einfach zu viele Business-Leute, Vibe Coder und Script Kiddies hereingekommen, und dadurch ist alles schlechter geworden

  • Das Problem mit Cowboy Coding ist, dass ein einziges unzuverlässiges Teammitglied das ganze Team ruinieren kann. Je größer eine Organisation wird, desto unvermeidlicher werden solche schlechten Mitglieder, und um zu verhindern, dass Probleme explodieren, braucht man immer größere Kontrollmechanismen. In kleinen, hochvertrauensbasierten Elite-Teams ist Cowboy Coding extrem effizient, aber weil es so schwer ist, bei Einstellungen die tatsächlichen Fähigkeiten von Kandidaten sicher zu beurteilen, passt es überhaupt nicht zu großen Organisationen. Vielleicht kann diese Arbeitsweise künftig noch in kleinen Firmen oder kleinen Teams innerhalb großer Unternehmen überleben

• Ich kann der Aussage des Autors schwer zustimmen, dass "<i>LLMs so etwas wie die letzte nukleare Lösung gegen die Komplexität von Software sind. Statt das eigentliche Problem zu lösen, bringen sie noch größere Komplexität hinein und lindern nur die Symptome</i>". Das eigentliche Ziel der AI-Einführung ist, „kreative und teure hochqualifizierte Talente“ bei einer winzigen Zahl von Firmen zu zentralisieren, die AI entwerfen, und in allen übrigen Firmen kreative Wissensarbeiter zu entlassen und nur noch einfache Arbeitskräfte zu behalten. Mit anderen Worten: Ziel ist es, die Komplexität aller Geschäftsprozesse mithilfe von AI zu vereinfachen. Um das mit „Der Zauberer von Oz“ zu sagen: Niemand will hinter den Vorhang schauen, alle wollen nur, dass ihre Arbeit einfacher wird. Langfristige Risiken werden ignoriert, solange sich kurzfristige Vorteile mitnehmen lassen

  • Solche Zentralisierung sieht man bereits in vielen Branchen. Im Bankensektor etwa trafen früher Banker vor Ort Entscheidungen auf Basis lokaler Gegebenheiten, heute entscheidet das zentrale HQ über alles. Die lokalen Banker werden in eine Welt „unterhalb der API“ gedrängt, während die Elite im HQ den gesamten Wohlstand abschöpft. Konzepte wie „Legibility“ und „Seeing Like a State“ sind hier als Referenz interessant

• Dieser Text hat mir sehr gefallen. Ich stimme auch manchen Stimmen zu, dass Problemlösung wichtiger ist als Code. Aber meiner Meinung nach kann die Fähigkeit zu tiefer Problemlösung mit der Zeit verkümmern, wenn man anfängt, selbst Probleme, die tiefes Denken erfordern, an AI auszulagern. Einfach nur anzuweisen: „Mach irgendetwas“, ist keine echte Problemlösung

  • Ich glaube, man kann sowohl Problemlösung als auch Handwerkskunst genießen. Logisch betrachtet hat Problemlösung den größeren Wert, aber für manche war der eigentliche Spaß eben das direkte Schreiben, Anfassen und Selbermachen, und deshalb empfinden sie den Verlust dieser Freude als schmerzhaft. Menschen, die sich – wie in diesem Text – als „Programmierer“ definieren, haben in der Regel wirklich Freude an Problemlösung, am Bauen, am Selbermachen und am Tüfteln