Hören Sie auf zu generieren, fangen Sie an zu denken
(localghost.dev)- 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
2 Kommentare
Das sind wirklich die wichtigsten Worte überhaupt..
Auch bei GeekNews gibt es Leute, die Vergleiche mit Taschenrechnern oder Kameras ziehen. Wenn sogar Entwickler so denken, wirkt es ernsthaft problematisch, wie dann erst die allgemeine Öffentlichkeit darüber denkt.
Hacker-News-Kommentare
Solange AI nicht als „Fahrrad für den Geist“, sondern nur als Produkt zur Gewinnmaximierung großer Konzerne wahrgenommen wird, ist der aktuelle Zustand von AI kaum zu rechtfertigen.
Eine Struktur, die Daten ohne echten Lernprozess zusammenkratzt, verarbeitet und zurückliefert, ist dem geistigen Wachstum des Menschen eher abträglich.
Am Ende ist ein tragfähiges Geschäftsmodell entscheidend, sonst lassen sich hochwertige LLMs nicht aufrechterhalten.
Ich mache inzwischen fast keine manuelle Bearbeitung mehr. Wenn ich Claude Code nur die Ticket-URL zuwerfe, wird das meiste direkt im ersten Anlauf gelöst.
Ich glaube, Teams, die in diese Arbeitsweise investieren, werden deutlich produktiver sein als Teams, die das nicht tun.
LLMs sind eine Technologie, die für jede Person völlig andere Erfahrungen liefert, und die Freiheitsgrade beim Prompting sind enorm.
Wenn man ein bestimmtes Design umsetzen will, ist es oft schneller, es einfach selbst zu schreiben.
Der Satz „Code, den ich nicht selbst geschrieben habe, kann ich nicht verstehen“ ist nicht realistisch.
Der Zweck von Code-Reviews ist nicht die Identität des Autors, sondern die Sicherstellung systemischer Zuverlässigkeit.
Ob ein Mensch, eine AI oder sogar ein Golden Retriever ihn getippt hat, ist egal.
Aber statt Zeit darauf zu verwenden, einen von AI erzeugten PR extra verstehen zu müssen, fühlt es sich sinnvoller an, lieber selbst den Prompt abzuschicken und das Ergebnis zu bekommen.
Wenn man sich auf LLMs verlässt, verliert man als Entwickler die Gelegenheit, die Projektstruktur zu lernen, und behandelt das System am Ende wie eine Blackbox.
Diese Entwicklung verwandelt Entwickler in „Prompt Kiddies“.
Mit der Aussage „Bevor ich Zeit damit verschwende, Prompts zu verfeinern, schreibe ich den Code lieber selbst“ kann ich mich identifizieren.
Das Problem ist nicht die „Generierung“, sondern unstrukturierte Generierung.
Statt improvisierter Prompts sollte man mit klaren Kompositionen auf Skill-Ebene arbeiten.
Dass man einer AI sagen müsse „Du bist ein Experte für verteilte Systeme“, ist eine Geschichte aus der GPT-3-Ära.
Heute sind solche rollenbasierten Prompts dank Fine-Tuning und Nachbearbeitungsverfahren nicht mehr nötig.
Als ich den Boom bei der LLM-Codegenerierung sah, hatte ich Angst, den Anschluss zu verlieren.
Ich habe Copilot und Claude bisher nur als Autocomplete-Helfer genutzt, und bei komplexem Code war das Ergebnis immer noch chaotisch.
Inzwischen durchsuchen jedoch agentenbasierte Tools die Codebasis, suchen im Web nach Informationen und passen ihren Kontext selbstständig an.
Letztlich ist das ein Problem von Leuten, die sich beschweren, ohne die Technik richtig zu verstehen.
In Wirklichkeit liegt es wahrscheinlich eher an mangelnder Prompt-Kompetenz.
Dass die umgebenden Tools Suche und Ausführung automatisieren, lässt es nur so wirken, als würden sie „denken“.
Am Ende ist das Automatisierung, keine Intelligenz.
Viele Beiträge und Kommentare auf HN wirken in letzter Zeit, als wären sie von LLMs geschrieben.
Es fehlt an Neuem, und meist werden nur oberflächliche Verallgemeinerungen wiederholt.
Wenn man sich die jüngsten Nachrichten ansieht, ist AI noch nicht ausreichend ausgereift.
Beispiele: Microsoft senkt Copilot-Umsatzziel und der Fall der Sicherheitsprobleme bei Moltbook.
Letztlich vertrauen die meisten Menschen AI nicht.
Für das Erkunden von Ideen oder das Schreiben von Boilerplate ist AI nützlich, aber am Ende bleibt Denkfähigkeit der Kern.
AI ist die größte Versuchung, menschliches Denken zu ersetzen, birgt aber langfristig das Risiko, den Denkmuskel zu schwächen.
Wenn man nach einer gewissen Nutzungszeit wieder mit der Hand codiert, wird man merken, dass die Flüssigkeit nachgelassen hat.
Vielleicht ist Claude einfach besser als Copilot, und vielleicht sind die Sicherheitsprobleme bei Moltbook nur das Schicksal eines frühen Dienstes.
Am Ende wird sich das Ergebnis an der Überlebensrate von Unternehmen mit und ohne AI-Einsatz zeigen.
Früher dachte ich auch, „AI ist eine dumme Blackbox“, aber in den letzten sechs Monaten hat sich meine Sichtweise komplett verändert.
Wenn man es richtig lernt, kann man erstaunliche Ergebnisse erzielen.
Jetzt sehe ich AI als Verstärker und nutze sie als Werkzeug, das meine Fähigkeiten erweitert.