- Mit dem Aufkommen von LLM-Coding-Tools ist die grundlegende Prämisse der Softwareentwicklung, die über Jahrzehnte Bestand hatte, selbst zusammengebrochen; wichtiger als das Schreiben von Code ist nun die Fähigkeit, Probleme zu definieren und Strukturen zu entwerfen
- Der Kern der Entwicklung verlagert sich nun von der „Fähigkeit, gut Code zu schreiben“ hin zur „Fähigkeit zu sprechen“, also Probleme zu imaginieren und klar zu erklären
- Saubere Codestrukturen, gut aufbereitete READMEs und Dokumentation sind nicht länger Vertrauenssignale für Fleiß oder Können; je perfekter sie wirken, desto eher könnten sie sogar Slop sein
- Da eine äußerliche Unterscheidung zwischen von AI erzeugtem und von Menschen geschriebenem Code faktisch unmöglich geworden ist, werden statt Qualität nun eher Verantwortlichkeit, Herkunft und Menschlichkeit zu den Kriterien, die den Wert von Code bestimmen
- Die Anreize für Zusammenarbeit und Teilen, die das FOSS-Ökosystem getragen haben, schwächen sich ab; wichtiger als der Code selbst werden Vertrauen, Governance und Kurationsfähigkeit
- Für erfahrene Entwickler sind diese Tools starke Verstärker, für Anfänger können sie jedoch ein gefährlicher Genie sein, der ihnen die Chance nimmt, ein grundlegendes Verständnis aufzubauen
Einleitung: Linus Torvalds’ Maxime und ihre Umkehrung
"Talk is cheap. Show me the code"
- Dieser Satz von Linus Torvalds aus dem Jahr 2000 stand für die Haltung, dass Worte keinen Wert haben, solange sie nicht durch echten Code bewiesen werden
- Damals verlangte selbst bei einem noch so klaren Entwicklungsplan die Umsetzung eines komplexen Programms enormen Aufwand, Zeit und wiederholte monotone Arbeit
- Der eigentliche Engpass war nicht die Technik, sondern die menschliche Begrenzung: kognitive Bandbreite, individuelle Zeit und Energie sowie die biologische Last, große Systeme im Kopf zu halten und den Code Zeile für Zeile niederzuschreiben
- Infolgedessen verschwanden die meisten Ideen, angesammelt auf einer „Irgendwann-will-ich-das-mal-machen“-Wunschliste, ohne jemals ernsthaft ausprobiert zu werden
25 Jahre später: LLMs stellen alles auf den Kopf
- 2025 merkte Linus Torvalds an, als er AI-generierten Code in sein Hobbyprojekt mergte: „Ist er besser als das, was ich von Hand direkt geschrieben hätte? Natürlich.“
- Aus der Sicht eines Entwicklers, der seit Jahrzehnten Software baut, erklärt der Autor unmissverständlich, dass die Softwareentwicklung, wie wir sie kannten, bereits vorbei ist
- Als jemand aus einer Generation, die zahlreiche Übergänge von Dial-up zu Gigabit, von Basic zu Node.js und von SourceForge zu GitHub direkt erlebt hat, erkennt er klar, dass dieser Wandel keine vorübergehende Mode, sondern ein qualitativer Bruch ist
Der Zusammenbruch der Maßstäbe zur Bewertung von Codequalität
- Früher waren bei der Bewertung von FOSS-Projekten Alter des Projekts, Commit-Frequenz, Konsistenz der Codestruktur sowie Qualität von README und Dokumentation wichtige Kriterien
- Knackige Kommentare und gut aufbereitete Dokumentation galten als Signale für Umsicht des Entwicklers und Rücksicht auf andere Entwickler
- Doch seit LLMs ausgereifte Dokumentationsseiten, übertrieben detaillierte READMEs, saubere UIs sowie geordnete Muster und Kommentare auf einmal erzeugen können, sind diese Signale nicht mehr verlässlich
- Dadurch ist es anhand der äußeren Form schwer zu unterscheiden, ob ein Repository von einem Nichttechniker per Vibe Coding gebaut wurde oder das Ergebnis eines von einem erfahrenen Entwickler entworfenen Systems ist
- Paradoxerweise entsteht sogar eine Situation, in der man bei allzu perfektem Eindruck eher vermuten muss, dass es sich um ein Low-Effort-One-Shot-Generat handelt
- Ohne fachlich sehr genaue Prüfung und Analyse wird es zunehmend schwieriger, Weizen von Slop zu trennen
- Entsprechend werden weniger der Code selbst als vielmehr wer ihn gebaut hat, warum er gebaut wurde, welche Historie die verantwortliche Person oder Organisation hat und ob Governance und Wartungsplanung vorhanden sind zu entscheidenden Kriterien der Provenance
Der Wandel des Werts von Aufwand
- Früher musste ein erfahrener Entwickler, um 10.000 Zeilen hochwertigen Codes mit sinnvollem Ergebnis zu erzeugen, lange Phasen konzentrierter Arbeit und wiederholter Verbesserung durchlaufen
- Die Zahl der Codezeilen ist zwar kein Qualitätsmaßstab, doch 10.000 gut ausgearbeitete Zeilen bedeuteten, dass Zeit, Konzentration, Geduld, Fachwissen und ein gewisses Maß an Projektmanagement-Kompetenz hineingeflossen waren
- LLMs können solche Ergebnisse in nur wenigen Sekunden erzeugen und den gesamten technischen Workflow von Tests über Systemkonfiguration bis hin zum Deployment bearbeiten
- Wenn dabei menschliche Expertise und Urteilsvermögen eingreifen, kann das Ergebnis eine für den realen Einsatz ausreichend hohe Qualität erreichen
- Auch persönlich hat der Autor wiederholt erlebt, dass Arbeiten, die Wochen oder Monate gedauert hätten, in wenigen Tagen, manchmal in wenigen Stunden erledigt waren
- Das war möglich allein mit einer einfachen LLM-Agent-CLI, ohne AGENT.md oder komplexe Multi-Agent-Orchestrierung
- Die physiologischen, kognitiven und emotionalen Kosten, die man für Softwareergebnisse zahlen musste, sind um mehrere Größenordnungen gesunken
- Die dadurch gewonnene Zeit und kognitive Freiheit werden wieder investiert in Engineering-Denken, Architekturentwurf, Diskussion, Experimente und die Erweiterung der Vorstellungskraft
- Der alte Satz „Programmieren ist zu 90 % Denken und zu 10 % Tippen“ ist nicht mehr bloß Metapher, sondern Realität geworden
Die Definition von Slop und der Wert von Code
- Wenn selbst Menschen, die nie eine Zeile Code geschrieben haben, in Sekunden Code in industriellem Maßstab erzeugen können, welchen Wert hat dann das Artefakt Code selbst noch?
- Die Behauptung „Ich will nur reinen menschlichen Code statt AI-Code“ ist, realistisch betrachtet, fast schon ein ironischer Witz
- Große Vorfälle durch von Menschen geschriebenen Code gibt es längst genug: der CrowdStrike-IT-Ausfall (2024), das Boeing-737-MAX-Grounding, der britische Postskandal, massive Datenpannen in Indien, der Equifax-Datenabfluss usw.
- Ein erheblicher Teil des Codes, den Menschen weltweit täglich schreiben, befindet sich qualitativ ohnehin im Grenzbereich
- Softwareentwicklung ist nach wie vor kaum ein Feld, das man als objektiv ausgereifte professionelle Disziplin bezeichnen könnte
- Von Ärzten oder Bauingenieuren werden strenge Ausbildung, Zulassung und Verantwortung für praktische Ergebnisse verlangt; in der Softwareentwicklung gibt es kaum vergleichbare Systeme
- Die heutige Gesellschaft läuft auf schlampig entworfenen, grob zusammengeflickten und übertrieben aufgeblähten Codesystemen
- Zugespitzt könnte man sogar sagen, dass AI-generierter Slop zumindest formal sauber, gut dokumentiert und syntaktisch konsistent ist
- Die Wahrnehmung setzt sich durch, dass das Lesen des Internets voller seelenloser, von LLMs erzeugter Sätze und Nachrichten fast einer Verschwendung von Amygdala-Neuronenaktivierung gleichkommt
- Fehlen der menschliche Schaffensprozess und die darin enthaltene Perfektion wie auch Unvollkommenheit, dann werden Sprache, Literatur, Kunst und Musik im Kern zu etwas, das man nicht mehr genießen kann
- Was sich ohne Aufwand unendlich und augenblicklich erzeugen lässt, ist für Menschen extrem schwer sinnvoll zu bewerten
Code ist nicht dasselbe wie Kunst
- Code war im Kern immer ein Mittel zum Zweck und niemals der Zweck selbst
- Endnutzer lesen keinen Code, müssen ihn nicht lesen und interessieren sich nicht für ihn
- Welche Sprache, welches Framework oder welche Architektur in den Hunderten von Systemen hinter einem Portal verwendet werden, hat für Nutzer keine Bedeutung
- Code ist vollständig verborgen; Nutzer erleben über die UX nur die Ergebnisse und Wirkungen, die der Code hervorbringt
- Ob funktional identischer AI-Code als Slop gilt oder nicht, entscheidet sich an der Struktur von Verantwortlichkeit (accountability) und daran, ob Menschlichkeit (humanness) eingegriffen hat
- Ein von Menschen direkt erstellter PR in einem Open-Source-Repository erhält unabhängig von der Codequalität fast automatisch Empathie und Wert, weil man die menschliche Zeit und Mühe darin mitdenkt
- Umgekehrt ist bei einem von LLMs erzeugten PR oft die erste Reaktion unabhängig von der Qualität „Slop!“, weil sich der darin enthaltene menschliche Aufwand nicht sofort abschätzen lässt
- Gleichzeitig wächst die Last, diesen Code zu lesen und zu verifizieren, im Vergleich zu seinen Erzeugungskosten unverhältnismäßig, geradezu exponentiell
- Letztlich ist das nur eine von unendlich vielen Varianten, die ohne Aufwand erzeugt wurden und keine bedeutsame Herkunft oder keinen Kontext besitzen
- An diesem Punkt nähert sich unsere Realität immer mehr der „Bibliothek von Babel“, wie Borges sie beschrieben hat
Die Zukunft von FOSS
- FOSS ist vermutlich eines der größten öffentlichen Güter, die die Menschheit je hervorgebracht hat
- Ausgangspunkt von FOSS war die historische Voraussetzung, dass Software extrem teuer war und nur von wenigen Spezialisten erstellt werden konnte
- Weltweit konnten nur sehr wenige Menschen Software bauen; alle anderen mussten sich darauf beschränken, die Ergebnisse zu nutzen
- Nun leben wir in einer Umgebung, in der Experten selbst für noch so nischige Anforderungen schnell kleine Bibliotheken bauen können, die exakt zu ihren Bedürfnissen passen
- Mehr noch: Wer ein gewisses Maß an Cleverness mitbringt, lebt nun in einer Zeit, in der praktisch jeder kleine Werkzeuge für den eigenen Bedarf per Vibe Coding selbst bauen und nutzen kann
- Was sich auf StackOverflow verändert hat, passiert langsamer, aber in ähnlicher Form nun auch in der Software insgesamt
- Das wirkt wie ein Wandel, der den menschlichen Motiven, sozialen Bedingungen und Teilnahmeanreizen, auf denen FOSS-Zusammenarbeit und -Teilen beruhten, frontal die Grundlage entzieht
- Angesichts der kambrischen Explosion von FOSS-Projekten, die in nie dagewesenem Maßstab auf uns zukommen dürfte
- ist es gut möglich, dass in den hochwertigen FOSS-Projekten, die am Ende überleben und gedeihen, Expert-Governance, Kuration und Vertrauensstrukturen wichtiger sein werden als der Code selbst
Zwei Extreme, die den Wald vor lauter Bäumen nicht sehen
- Schon in Zeiten ohne Syntax-Highlighting, IDEs und all die heutigen Werkzeuge haben Menschen Software auf erstaunlichem Niveau gebaut
- Umgekehrt wird auch heute, trotz Überfluss an Tools und Ressourcen, weiterhin miserable Software produziert
- Fähige Entwickler mit starkem Ausdrucksvermögen und Qualitätsbewusstsein erzielen mit LLMs wie mit anderen Tools auf ihre Weise gute Ergebnisse
- Entwickler dagegen, die Probleme nicht erklären können und denen Qualität egal ist, produzieren schlechte Resultate – unabhängig davon, ob sie LLMs benutzen oder nicht
- Sowohl extreme Gläubige an „agentisches“ Vibe Coding als auch Menschen, die LLMs vollständig ablehnen, starren letztlich nur auf einzelne Bäume und sehen den Wald nicht
- Es gibt eindeutig eine praktische Mitte, in der Menschen mit Erfahrung, Fachwissen, Denkkraft und Ausdrucksfähigkeit die richtigen Trade-offs wählen und so die gewünschten Ergebnisse erzielen
- Vibe Coding kann für Nichttechniker auch ein wichtiger Einstiegspunkt sein, um erstmals mit Software zu arbeiten, zu experimentieren, Freude daran zu entwickeln und Fähigkeiten aufzubauen
- Wer Vibe Coding jedoch blind vertraut, übersieht den zentralen Faktor, der Menschen dazu bringt, ein Ergebnis ernst zu nehmen: Endlichkeit (finitude)
- So errichten sie selbst eine riesige borgesianische Bibliothek, in der man sich leicht in einem Meer aus Slop verliert, das von schmeichlerischen Agenten erzeugt wurde
- Ergebnisse, die ohne Aufwand unbegrenzt erzeugt werden und keine sinnvolle Herkunft haben, sind extrem schwer zu bewerten oder ernst zu nehmen
- Der Mensch ist seinem Wesen nach schlecht darin, mit unendlichem Angebot zurechtzukommen – besonders mit unendlicher Auswahl
- LLM-Skeptiker wiederum kommen oft nicht über ein Argument aus Ungläubigkeit hinaus
- Sie verwerfen die Technologie, weil sie ihnen persönlich nicht gefällt, weil sie nicht die gewünschten Ergebnisse bekommen haben, weil Erwartungen enttäuscht wurden oder weil sie schlicht genug davon haben
- Doch diese Haltung verliert an Überzeugungskraft angesichts der Tatsache, dass es zahlreiche Menschen gibt, die mit denselben Tools effektiv arbeiten und genau gegenteilige Erfahrungen machen
- Dumme und schädliche Implementierungen, angetrieben von Hype, Rausch und Gier, sind ohne Frage real und ein ernstes Problem
- Die AI-Business-Blase könnte wohl eine der größten Blasen der Geschichte werden
- Trotzdem ist die Verbreitung von FOSS-AI-Technologien eindeutig ein hoffnungsvolles Signal
- Es ist irrational, schlechte Akteure, Zahlenspielereien oder absurde Implementierungen mit den grundlegenden und physischen Fähigkeiten dieser Technologien gleichzusetzen
Menschliche Kosten
- Aus Sicht erfahrener Entwickler und Ingenieure wirken diese AI-Technologien als sehr starke und wirksame Hilfsmittel
- Doch für Lernende am Anfang und Junioren, die gerade erst in die Branche einsteigen, stellt sich ein ganz anderes Problem
- Fehlen die Grundlagen und ist noch kein inneres, feines Verständnis von Systemen und dem Prozess der Softwareentwicklung entstanden, dann ist diese Technologie eher ein unzuverlässiger und gefährlicher Genie
- Fordert man Code an, liefert sie Code; bittet man um Änderungen, nimmt sie sie sofort vor – oberflächlich betrachtet wirkt das bequem
- Doch bald sitzt der Nutzer in einer Codebasis fest, deren Funktionsweise er nicht versteht, und ist für Problemlösungen weiter auf den Genie angewiesen
- Wiederholt sich diese Abhängigkeit, verschwindet die Lernumgebung selbst, in der sich grundlegende und fundamentale Fähigkeiten natürlich entwickeln könnten; es droht sogar kognitive Verkümmerung
- Dadurch könnte eine ganze Generation von Junioren entstehen, die nie die Chance bekommt, zu sinnvollen Seniors heranzuwachsen
- Die eigentliche Sorge ist, dass einer Generation von Lernenden die Chance verloren geht, die Expertise zu erwerben, um objektiv zu unterscheiden, was Slop ist und was nicht
- Noch schwerwiegender ist die Möglichkeit, dass selbst erfahrene Fachkräfte, die diese Tools geschickt einsetzen, die Motivation verlieren könnten, Junioren auf grundlegende Weise zu betreuen und auszubilden
- Das birgt das Risiko, nicht nur die Softwareentwicklung, sondern den Menschen generell in eine Richtung zu drängen, in der Agency und Entscheidungsfindung vollständig an Black Boxes delegiert werden
Fazit: Jetzt ist Talk wertvoller als Code
- Selbst für Entwickler, die von Hand geschrieben haben, wird nun die Fähigkeit, Code zu lesen und kritisch zu bewerten, wichtiger als die Fähigkeit, Syntax zu lernen und Zeile für Zeile zu tippen
- Letztere bleibt natürlich weiterhin eine wichtige Kompetenz, und die Fähigkeit, Code effektiv zu lesen, baut letztlich auf genau diesem Fundament auf
- Dennoch ist der alltägliche Workflow der Softwareentwicklung bereits vollständig auf den Kopf gestellt
- Erfahrene Entwickler, die gut sprechen können – also imaginieren, erklären, Probleme definieren sowie Architekturen entwerfen und umsetzen können – haben gegenüber denen, die das nicht können, einen unverhältnismäßig großen Vorteil wie nie zuvor
- Wissen über bestimmte Sprachen, Syntax oder Frameworks ist nicht länger der zentrale Engpass
- Auch die physiologischen und physischen Beschränkungen, die Entwickler früher fesselten, wirken nicht mehr als entscheidendes Hindernis
- Maschinen, die große Mengen Code sofort erzeugen, sind inzwischen kommodifizierte Werkzeuge, auf die jeder per
pip installzugreifen kann - Der Bedarf an gesonderter Spezialausbildung oder daran, neue Sprachen und Frameworks zu lernen, verschwindet faktisch ebenfalls
- Gefragt sind nur noch altes kritisches Denken, grundlegende menschliche Fähigkeiten und ein Mindestmaß an operativer Kompetenz im Umgang mit dieser Maschine
- Dadurch erleben bisherige Methoden und Rollentrennungen der Softwareentwicklung – Waterfall und Agile, Entwickler und Tester, Senior und Junior – einen grundlegenden Wandel
- Traditionelle Grenzen verschmelzen in unvorstellbar schnellen, komprimierten und verschwimmenden iterativen „agentischen“ Schleifen
- Damit verändern sich auch die Dynamiken von Menschen, Organisationen und öffentlichen Communities rund um die Softwareentwicklung sowie die menschlichen Anreize, die Teilen und Zusammenarbeit getragen haben, in rasantem Tempo
- Beispiele dafür sind das Ende des Bug-Bounty-Programms von curl, die Einführung von Richtlinien zur AI-Nutzung bei Zulip und die explizite AI-Policy von Ghostty
- Zum ersten Mal in der Geschichte wird gutes Reden (talk) zu einem Faktor, der exponentiell wertvoller ist als guter Code
- Die Folgen dieses Wandels sind gravierend und zugleich hochgradig disruptiv
10 Kommentare
Ich kann der Aussage „Die Lernumgebung selbst verschwindet“ sehr viel abgewinnen. In einer Welt, in der die Zugangskosten zu Wissen gegen null gehen, welche Form nimmt Bildung dann eigentlich an?
„Sogar Menschen, die noch nie eine einzige Zeile Code geschrieben haben, können in wenigen Sekunden Code im industriellen Maßstab erzeugen“
-> Wenn man ein Apartmenthaus aus Strohhalmen baut, ist das dann industrieller Maßstab?
In der Realität werden bei den meisten Einstellungen jedoch weiterhin stets N+ Jahre Berufserfahrung in Sprachen wie Java verlangt.
„Sprechen“ und „Schreiben“ sind unterschiedliche Dinge.
Tatsächlich scheint es, als müsse man eher „Schreiben“ gut beherrschen als „Sprechen“.
🐎🐎🐎🐎🐎
Kimino Aiba macht zkyundokyun~
Ich mochte diese Aussage von Torvalds, aber ... die Zeiten haben sich komplett geändert.
Noch vor wenigen Jahren hat man, wenn man bei Kolleg:innen im Unternehmen oder auf Entwickler-Treffen unterwegs war, Ingenieur:innen gern als „Zungenprogrammierer“ verspottet, wenn sie nichts draufhatten und nur viel geredet haben (eine gedankenlose Early-Adopter-Fixierung auf die neuesten Trendtechnologien und Buzzwords, und im besten Fall bloß Erfahrung mit der Nutzung von Frameworks und Bibliotheken, aber noch nie selbst auch nur etwas Grundlegendes gebaut ...). Jetzt sind „Zungenprogrammierer“ zur Realität von Entwickler:innen geworden. Ach, was für ein Wandel der Zeiten.
Hacker-News-Kommentare
Ich habe Codex heute gebeten, Unit-Tests für Redux zu schreiben
Zuerst sah es ganz okay aus, also habe ich es einfach durchgewunken, aber als ich später selbst weitere Tests hinzufügen wollte und noch einmal draufgeschaut habe, gab es Dutzende Stellen, bei denen ich dachte: „Was ist das denn?“
Es lief zwar, war aber ein einziges Chaos. Und das bei einfachem Code
Ich mache mit AI immer wieder ähnliche Erfahrungen — oberflächlich sieht es okay aus, aber sobald man es erweitern will, ist es eine Katastrophe, und am Ende muss ich alles selbst aufräumen
Das Problem an „Code is cheap“ ist, dass die Erzeugung billig ist, Wartung aber teuer
Tausende Zeilen pro Tag zu generieren ist wie Schulden auf der Kreditkarte anzuhäufen. Erst denkt man, es sei kostenlos, und später kommt die Rechnung
Ich weiß nicht, ob wir direkt Einfluss darauf nehmen können, aber ich würde gern sehen, was da passiert ist
Zur Info: Unser Ansatz zum Testen von Redux ist in der offiziellen Dokumentation beschrieben
Man sollte zuerst die Testmethodik festlegen und das Modell dann auf dieser Basis anweisen
AI trifft bei nicht explizit genannten Punkten willkürliche Annahmen, daher ist Vorsicht geboten
Im Kern sind Tests entscheidend. Man sollte AI-Code nicht nach Bauchgefühl beurteilen, sondern mit Tests verifizieren
Der Wert von Code ist proportional zur Qualität der Tests. Wenn man ihn einfach mit einem „LGTM“ durchwinkt, ist das, als würde man mit geschlossenen Augen Motorrad fahren
In manchen Fällen klappt es, in anderen ist es völliger Murks
Zum Beispiel habe ich einen korrekten Use Case gegeben, der Code war aber falsch, und als der Test fehlschlug, hat die AI einfach den Test umgeschrieben
Es besteht also die Gefahr, dass sie Erfolg nach ihren eigenen Maßstäben definiert
Ich habe früher einmal zwei Claude-Instanzen parallel laufen lassen, eine für die Tests und eine für die Implementierung, aber das Setup war viel zu umständlich
Deshalb glaube ich, dass das einer der Gründe ist, warum diese Technik Teams aufgezwungen wird
Wie bei der Cloud-Migration zeigen sich die echten Kosten erst später. Nur wird es diesmal wohl viel schneller gehen
Um es mit einer Analogie aus der Autoindustrie zu erklären:
Wer einfach nur Teile nach Spezifikation montiert, muss sich durchaus Sorgen machen, durch einen Roboterarm ersetzt zu werden
Wer dagegen Designs ausprobiert, Prototypen baut und Roboterarme programmiert, muss sich über Automatisierung weniger Gedanken machen
Viele Gegenargumente laufen darauf hinaus, dass „AI auch diese zweite Rolle automatisiert“, aber in Wirklichkeit wird dabei die erste Art von Arbeit oft mit der zweiten verwechselt
Denn sie können debuggen, die Richtung ändern und konkrete Anweisungen geben
Normale Nutzer wiederholen nur: „Das funktioniert nicht, bitte reparieren“
Daher wird sich die Art der Arbeit verändern, aber der Beruf selbst wird nicht verschwinden
Wenn AI das überzeugend nachahmen kann, könnte sie mich ersetzen
In einer Wirtschaft mit wenig Wettbewerb reicht vielleicht schon eine „glaubwürdige Imitation“
Selbst miserable AI-Ergebnisse reichen, solange Umsatz und Exit stimmen
Die Welt hat schon immer „verteilten Müll“ toleriert. Man schaue nur auf Windows
Tatsächlich war vieles davon automatisierbar, und offenbar war mein Selbstbild all die Jahre überhöht
Die heutigen LLMs sind aber viel allgemeiner und können jede Art von Aufgabe übernehmen
Wenn man einem Roboterarm sagt: „Verbessere das Autodesign dieses Jahres“, bleibt er stehen, aber AI kann dazu eine Meinung äußern
Wenn AI den gesamten Prozess von Idee → Design → Bau → Test → Bewertung übernehmen kann,
dann ist das grundlegend eine andere Art von Innovation als frühere Technologien
Die Aussage, „die Zeit des handgeschriebenen Codes ist vorbei“, ist übertrieben
Solche Übertreibungen sollen an Fachkompetenz rütteln und FOMO auslösen
Man sollte sich davon nicht einschüchtern lassen, sondern dem eigenen Urteil vertrauen
Allerdings stimmt es, dass Technik die Praxis verändert
Am Ende zählt die Fähigkeit, Leistung, Kosten, Zeitplan und Qualität auszubalancieren
Auf die Behauptung „Engineering ist vorbei“ gibt es immer starke Gegenreaktionen,
aber meiner Ansicht nach macht das eigentliche Schreiben von Code bei großen Produkten nur etwa 10–20 % aus
Der Rest besteht aus Design, Experimenten, Analyse, Kommunikation und Ähnlichem, und gerade diese Teile lassen sich von LLMs nur schwer ersetzen
Eher wird Zusammenarbeit und Abstimmung noch komplexer, und LLMs verschlimmern das oft sogar
Deshalb sollte man AI nicht als Ersatz, sondern als Werkzeug betrachten
Dort hieß es eher, dass „eine jahrzehntelange Art der Entwicklung vorbei ist“, nicht dass Engineering insgesamt vorbei sei
Wenn das Schreiben von Code nur 10–20 % ausmacht, bedeutet das, dass die übrigen „Gespräche“ wichtiger geworden sind
Wie Linus sagte: „Zeig, dass der Code wie beabsichtigt funktioniert“
Mit LLMs ein paar Zeilen zu erzeugen, ist leicht, aber sie sicher zu ändern, ist weiterhin schwierig
Auch Liz Fong-Jones von Honeycomb soll einen solchen Fehler schon gemacht haben
Wenn Unternehmen den ROI von LLMs nachverfolgen, werden sie die Realität erkennen
Im Moment sind wir oben auf dem Hype Cycle von Gartner und werden wohl bald ins Tal der Enttäuschung rutschen
Dank Claude konnte ich schnell refaktorieren, aber irgendwann kam ich komplett zum Stillstand
Der Grund war, dass ich nicht wusste, was ich eigentlich wollte
Wenn das Datenmodell nicht klar ist und man nur sagt „schreib weiter“, bekommt man sehr schlechte Ergebnisse
Programmieren ist eine kurzfristige Tätigkeit, aber Software Engineering ist ein langfristiger Prozess
AI beschleunigt Ersteres, ersetzt aber Letzteres nicht
Die Annahme von „einem klaren Entwicklungsplan und Implementierungs-Know-how“ ist nicht realistisch
Programmierung selbst ist bereits ein Akt des Planens, und Sprache ist ein hervorragendes Denkwerkzeug
Deshalb unterscheiden sich die Sichtweisen auf LLMs — manche sehen Sprache als Denkwerkzeug, andere als reines Ausführungswerkzeug
Die Ersteren erkennen den Wert des Programmierens selbst, die Letzteren wollen den Code verbergen
Am Ende ist es eine Frage der Entscheidung: Baut man von Anfang an ein gutes konzeptionelles Modell auf, oder landet man später in der Debugging-Hölle?
Die heutigen Werkzeuge sind nicht auf Ersteres ausgelegt. Die Tooling-Lücke ist groß
Einige kombinieren beides und arbeiten auf neue Weise
Die ursprüngliche Bedeutung von „Talk is cheap“ ist, dass Reden leicht ist und keinen Wert hat
„Code is cheap. Show me the talk.“ klingt aber so, als sei es noch wertloser, und deshalb fand ich es von Anfang an unerquicklich
Als ich den Text tatsächlich gelesen habe, hat sich mein Eindruck bestätigt
Der Autor ist nicht ahnungslos, was Code angeht. Er ist auch in Open Source sehr aktiv
Die Aussage ist simpel — früher war es teuer, ein gutes Design in Code umzusetzen,
heute ist das billiger, also zählt die Qualität des Designs noch mehr
„Talk is cheap, show me the code“
Wichtiger als der Code ist das Modell im Kopf des Entwicklers
Code ist nur ein Nebenprodukt dieses Modells und ohne menschliche Interpretation bedeutungslos
Diese Sichtweise beeinflusst auch den Umgang mit LLMs stark
Der Aussage, „die Art, wie wir seit Jahrzehnten arbeiten, ist vorbei“, kann ich schwer zustimmen
2005, 2015 und 2025 wurde jeweils anders entwickelt
Veränderung gab es immer, und schon die Annahme, es sei „über Jahrzehnte gleich“ geblieben, ist falsch
Die Werkzeuge wurden besser, aber die Arbeitsweise von Entwicklern blieb ähnlich
dann ist das heutige neovim weit leistungsfähiger als damals
Es gibt die Tendenz, die schrittweisen Fortschritte der letzten 30 Jahre zu unterschätzen
Damals bekam man die meisten Informationen aus Papierbüchern oder durch Reverse Engineering
„Talk is even cheaper, still show me the code“ spricht mich mehr an
AI verspricht die 10-fache Produktivität, aber in der Praxis habe ich so etwas kaum gesehen
Durch AI ist Komplexität erträglicher geworden, aber eine React-App zu schreiben ist immer noch schmerzhaft
Mit nichtdeterministischen APIs umzugehen, ist ebenfalls mühsam
Immerhin verbringt man weniger Zeit mit Tippfehlern oder dem Suchen nach Beispielen
Wegen schwacher Schlussfolgerungsfähigkeit und Wissensgrenzen ist Coding aber weiterhin unerquicklich
wandelt das dann in ANSI-Zeichen um und schreibt es ins Terminal —
im Grunde eine unnötig komplizierte Umsetzung von etwas, das man einfach mit curses lösen könnte
Formulierungen wie „Code is cheap. Show me the talk.“ werden inzwischen als Clickbait missbraucht
Der Text selbst ist nicht schlecht, aber nichts daran ist neu
Auf der AI-Welle reiten nicht nur Unternehmen, sondern auch Blogger und Influencer
Wenn man positiven oder negativen AI-Artikeln nur provokante Titel gibt, werden sie auf HN oder Reddit schnell zum Trend
Zur Einordnung: Der Ursprung dieser Formulierung liegt in diesem Tweet und
dieser Meme-Seite
Endlich hat jemand die realistische Mitte zwischen den Extremen gut beschrieben
LLMs sind weder Götter noch Katastrophen. Sie sind Werkzeuge
Man kann die Rentenabschöpfung von Unternehmen wie OpenAI, Google und Microsoft kritisieren
und trotzdem lokale Modelle wie Qwen oder Mistral nutzen
Cloud-LLMs sind aus Sicherheitsgründen nicht E2EE-fähig und deshalb für Unternehmensumgebungen ungeeignet
Dank lokaler LLMs sind jetzt aber auch Enterprise-Aufgaben im Alleingang möglich
Mit einem einzigen Mac Mini erledige ich Datenbankabfragen, API-Integrationen und Automatisierung
Außerhalb großer Organisationen kann ein erfahrener Generalist drei Mid-Level-Kräfte ersetzen
Natürlich habe ich weiterhin große Vorbehalte wegen Stellenabbau oder Urheberrechtsfragen,
aber lokale LLMs sind zu einem zentralen Bestandteil meines Toolkits geworden
Ein Text, den ich Menschen zeigen möchte, die sich in einem „Glauben“ befinden.