- Ein Beitrag, der angesichts der euphorischen Aufnahme von LLM-Codegenerierungstools in der Branche die Bedeutung des Denkens in der Softwareentwicklung betont
- Automatisch generierter Code ist nichtdeterministisch (non-deterministic) und seine innere Funktionsweise ist intransparent; damit unterscheidet er sich grundlegend von Mechanisierung, die jedes Mal dasselbe Ergebnis garantiert
- LLMs lernen aus bereits existierendem, minderwertigem Code, wiederholen dieselben Fehler und trainieren diese erneut an — das Problem der „Human-Centipede-Erkenntnistheorie (human centipede epistemology)”
- Wenn Codegenerierung an Agenten delegiert wird, werden bei PR-Reviews gemeinsamer Kontext und Verantwortlichkeit geschwächt, was sich negativ auf die Softwarequalität auswirkt
- LLMs sind für begrenzte Einsatzzwecke wie Prototyping nützlich, aber es ist riskant, als Entwickler das Denken selbst auszulagern; ohne Verständnis ist Wartung nicht möglich
Das Unbehagen gegenüber LLM-Codegenerierung
- Obwohl die Autorin seit Langem Branchentrends verfolgt und neue CSS- und JS-Funktionen mit Kolleginnen und Kollegen teilt, hat die rasche Verbreitung LLM-basierter Codegenerierung bei ihr die Angst ausgelöst, zurückzufallen
- Sie hat Copilot und Claude als „spicy autocomplete” und als Debugging-Hilfe genutzt, doch sobald die Aufgaben auch nur etwas komplexer werden, ist das Ergebnis chaotisch
- Man muss genügend Kontext liefern, aber zu viel überlastet das Modell, und man gerät in die Situation, lange Prompts zu schreiben, die das Ego des LLMs besänftigen, etwa mit Sätzen wie „Sie sind Expertin für verteilte Systeme“
- Oft ist es schneller, den Code direkt selbst zu schreiben, als Zeit mit dem Feilen an Prompts zu verbringen
- Es wird infrage gestellt, warum Ingenieurinnen und Ingenieure die angenehme Arbeit des Codierens aufgeben und nur die langweilige Arbeit des Reviewens übriglassen wollen
Gegenargument zur Behauptung einer „Wiederholung der industriellen Revolution“
- So wie die industrielle Revolution zum Klimawandel beigetragen hat, zeigt sich ein ähnliches Muster im enormen Energieverbrauch von KI-Rechenzentren
- Nicht jeder Strom stammt aus fossilen Brennstoffen, aber für Dinge wie die Erzeugung von Bildern wie „Shrimp Jesus“ werden enorme Ressourcen verschwendet
- Mechanisierung machte Waren billig und weit verbreitet, führte aber auch zu Qualitätsverlust, was in einer Realität mündet, in der man bei SHEIN Hosen für weniger als den Preis einer Tasse Kaffee kaufen kann
- Verschärft wurde dies durch den Niedergang qualifizierter Arbeit, die Verlagerung von Fabriken in Niedriglohnländer und die Ausbeutung von Arbeitskräften
- Generierter Code ähnelt Fast Fashion: Oberflächlich sieht er gut aus, doch mit der Zeit ist er voller Löcher, übernimmt oft Code anderer ohne Erlaubnis und schadet auch der Umwelt
- Der entscheidende Unterschied: Mechanisierung produziert jedes Mal dasselbe Ergebnis, und bei Problemen konnte man ins Innere schauen; LLM-Ausgaben hingegen sind nichtdeterministisch und ihre innere Funktionsweise ist intransparent
- Ein mechanisierter Prozess, der jedes Mal ein anderes Ergebnis liefert und mit Halluzinationen (hallucinations) durchsetzt ist, ist nicht nützlich
Gegenargument zur Behauptung einer „neuen Abstraktionsebene“
- Es stimmt, dass man mit Java oder Go nicht mehr Assembler lernen muss und Laufzeiten sich um Garbage Collection oder Speicherzuweisung kümmern
- Aber Systemarchitektur, die Auswirkungen auf den kritischen Pfad, Trade-offs zwischen Wartbarkeit und Bereitstellungsgeschwindigkeit, Browser-Kompatibilität sowie Barrierefreiheit, Sicherheit und Performance sind weiterhin Bereiche, über die Entwicklerinnen und Entwickler selbst nachdenken müssen
- Den größten Schaden richten LLMs dort an, wo Ingenieurinnen und Ingenieure das für Softwareentwicklung nötige Denken selbst auslagern
- Da LLMs nicht schlussfolgern können, entsteht, wenn Entwickler nicht denken und das LLM auch nicht denkt, ein Zustand, in dem niemand denkt
- Der Fall des Horizon-Skandals: Aufgrund von Bugs in der Post-Office-Software wurden unschuldige Beschäftigte inhaftiert, und 13 Menschen begingen Suizid
- Verantwortlichkeit (accountability) für Software ist wichtiger denn je
Minderwertiger Code ist das Grundproblem
- Auch menschliche Entwickler schreiben Code, der schlecht zugänglich, leistungsschwach und übermäßig von JavaScript abhängig ist
- LLMs werden mit genau diesem minderwertigen Code als Trainingsdaten (ohne ausdrückliche Zustimmung) trainiert und geben dieselben Fehler erneut aus
- Dazu kommt ein Kreislauf, in dem von LLMs erzeugter minderwertiger Code wiederum von anderen LLMs gelernt wird — die sogenannte „Human-Centipede-Erkenntnistheorie (human centipede epistemology)”
- Wenn man Nutzerinnen und Nutzer von Hilfstechnologien, Menschen mit schlechter Internetanbindung oder Betroffene rassistischer Gesichtserkennungssoftware berücksichtigt, ist die aktuelle Softwarequalität nicht ausreichend
- Statt als Menschen zu lernen und uns zu verbessern, haben wir Fehler an gedankenlose Algorithmen ausgelagert
PR-Reviews und die Schwächung des gemeinsamen Kontexts
- Die Kernaussage des Vortrags von Jessica Rose und Eda Eren auf der FFConf: „Code, den man nicht selbst geschrieben hat, ist Code, den man nicht versteht, und Code, den man nicht versteht, kann man nicht warten“
- In einem PR, den Kolleginnen oder Kollegen geschrieben haben, steckt ein gewisses Maß an Vertrauen und Denkprozess, bei einem LLM-generierten PR gibt es diese Garantie nicht
- Open-Source-Maintainer erleben derzeit eine Explosion minderwertiger, LLM-generierter PRs
- Einige Unternehmen nutzen in Slack den Ansatz, Claude per Chat um Codeänderungen zu bitten und den automatisch erzeugten PR anschließend von derselben Person genehmigen zu lassen
- In diesem Fall konzentriert sich die Verantwortung auf nur eine prüfende Person, und eines von zwei Augenpaaren geht verloren
- Auch der gemeinsame Kontext (shared context) im Team nimmt ab
- PR-Reviews dienen nicht nur der Fehlersuche, sondern sind auch ein Prozess zum gemeinsamen Verständnis von Code und Änderungen
Nicht gegen Fortschritt, sondern gegen den Hype
- Der Beitrag richtet sich nicht gegen LLMs an sich, sondern gegen das Branding als „künstliche Intelligenz”
- LLMs sind nicht intelligent, sondern eine Form des Machine Learning
- „Generative KI“ ist eine sehr gut gebaute Markov-Kette, in die Menschen überzogene Erwartungen setzen
- Für den schnellen Bau von Prototypen, Wireframes oder interaktiven Demos ist das sinnvoll
- Das Problem beginnt dort, wo man glaubt, mit „Vibe Coding” produktionsreife Software bauen zu können, oder den Denkprozess des Codierens selbst delegiert
- Die Ansicht von Mikayla Maki im Zed-Blog: Agenten sollten wie nicht vertrauenswürdige externe Beitragende behandelt und nur für Aufgaben verwendet werden, deren Ausführung man bereits kennt; Code zu verstehen ist zwingend erforderlich
- „Spicy autocomplete” wird sie weiter nutzen, aber das Denken nicht auslagern — und sie will sich daran erinnern, warum sie diese Arbeit ursprünglich mochte
Noch keine Kommentare.