AI: Beschleunigte Inkompetenz
(slater.dev)- Eine übermäßige Abhängigkeit von LLMs im Software Engineering kann zwar kurzfristig die Geschwindigkeit erhöhen, zugleich aber kritisches Denken und Problemlösungsfähigkeit schwächen
- Gefährlicher als fehlerhafte Ausgaben ist, dass mangelhafte Prompts ungeprüft übernommen werden und sich dadurch technische Schulden sowie ein Abbau der Nutzerkompetenz schnell ansammeln
- Da LLMs über ihr aktuelles Kontextfenster hinaus keine Programmtheorie erinnern oder verinnerlichen können, bleiben die für Entwurf und Wartung nötigen gemeinsamen mentalen Modelle Aufgabe menschlicher Engineers
- Komplexität nimmt im Wartungsprozess fortlaufend zu, und LLMs als Token-Prädiktoren auf Textebene können durch unnötige oder seltsame Änderungen die Programmentropie erhöhen
- AI kann als Werkzeug genutzt werden, sollte aber nicht als Krücke dienen; in die grundlegenden Engineering-Fähigkeiten und das tiefe Denken, die schon 2019 wertvoll waren, muss weiter investiert werden
Engineering-Risiken durch LLM-Abhängigkeit
- Die Haltung, LLMs als „Freund“ zu bezeichnen, ist weniger Ausdruck echter Partnerschaft als ein Euphemismus dafür, dass sie dem Nutzer Vorteile bringen
- Engineers mit dieser Sicht priorisieren meist Geschwindigkeit oder stehen unter dem Druck, Geschwindigkeit zu priorisieren
- LLMs können schnell viel Code erzeugen, aber ihre Nutzung bringt einen langen Schweif an Risiken mit sich
Fünf Risiken, die sich bei der Code-Generierung zeigen
-
Ausgaberisiko
- LLMs können offensichtlich falsche Ergebnisse liefern, etwa Code, der nicht kompiliert
- Noch gefährlicher sind subtile und schwer erkennbare Fehler wie Logik-Bugs
- Das Risiko steigt, wenn die Person, die den Prompt schreibt, nicht qualifiziert ist, das Ergebnis zu bewerten
- Als Beispiel wird die Situation genannt, in der ein Projektmanager nach Source Code fragt
-
Eingaberisiko
- LLMs widersprechen Prompts mit suggestiven Fragen, falschen Annahmen oder unvollständigem Kontext nicht
- Beispielsweise kann auf die Anfrage „Stelle in C# eine thread-sichere Liste bereit“ plausibel wirkender Code mit 200 Zeilen ausgegeben werden, obwohl die eigentliche Frage lauten könnte: „Wie mache ich diesen Code thread-sicher?“
- In diesem Fall könnte die Antwort eine einzige Zeile Code sein, die
System.Collections.Concurrentverwendet - Da es nicht explizit verlangt wurde, erkennt das LLM den Fall eines XY Problem nicht
-
Zukünftiger Geschwindigkeitsverlust
- LLMs können die Qualität einer Codebasis sehr schnell verschlechtern
- Ohne starke Guardrails kann von LLMs erzeugter Code nach außen hin ordentlich aussehen, intern aber zu einem unhygienischen und dysfunktionalen Raum werden
- Das wird als dringlicheres Problem betrachtet als die übliche Diskussion über technische Schulden
-
Infantilisierung der Nutzer
- In Personen und Organisationen, die Denken und Problemlösen an LLMs abgeben, kann Talent verloren gehen
- Senior Engineers können Problemlösungsfähigkeit und kritisches Denken einbüßen, weil ihnen die Gelegenheit fehlt, durch produktives Ringen zu lernen
- Junior Engineers entwickeln diese Fähigkeiten womöglich gar nicht erst und haben später Schwierigkeiten, zukünftige Juniors zu coachen
- ThoughtWorks Technology Radar Volume 32 behandelt Fälle, in denen AI-gestütztes Selbstvertrauen auf Kosten kritischen Denkens geht
- Coding as Craft: Going Back to the Old Gym betont eine bewusste Zusammenarbeit mit AI, um Coding als Handwerk zu bewahren
- Thoughts on Thinking vertritt die Ansicht, dass LLMs zwar fertige Gedanken liefern können, aber kein intellektuelles Wachstum, das man selbst entwickelt
-
Verlust von Freude
- Viele Entwickler berichten, dass der Einsatz von AI ihnen den Flow-Zustand und die Freude am Schaffen nimmt
- Von AI erzeugter Code kann zu Code werden, den zu lesen und zu verändern unerquicklich ist
- Als verwandter Beitrag wird The Hidden Cost of AI Coding verlinkt
Zwei Fähigkeiten, die LLMs nicht ersetzen können
- Auf die Sorge, erfahrene Engineers könnten durch AI überflüssig werden, wird geantwortet, dass sich zwei Programmierfähigkeiten benennen lassen, die LLMs nicht liefern können
- Diese Fähigkeiten sind Programmtheorie und Programmentropie
Programmtheorie: Code ist nicht das Programm selbst
- Peter Naurs Programming as Theory Building versteht Programmierung als Tätigkeit, bei der Einsicht oder eine Theorie über ein Problem gebildet wird
- Aus Naurs Sicht ist ein Programm nicht der Source Code, sondern ein geteiltes mentales Konstrukt, also eine Theorie oder ein Entwurf
- Der Code wird aus diesem Entwurf abgeleitet, doch das wertvolle Ergebnis liegt eher im Entwurf als im Code
-
Gedankenexperiment mit zwei Teams
- Zwei Teams A und B mit gleichen Fähigkeiten befinden sich in getrennten Räumen ohne Kommunikation
- Team A schreibt ein Programm wie ein terminalbasiertes Schachspiel, während Team B wartet oder tatsächlich Schach spielt
- Nachdem Team A fertig ist, wird der Source Code an Team B übergeben, und beide Teams sollen Funktionen wie einen virtuellen Schachspieler ergänzen
- Das Team mit der besseren Lösung wird Team A sein
- Team A verfügt über ein frisches mentales Modell des gerade erstellten Programms
- Team B besitzt ein solches Modell nicht
- Da Programme nach ihrer initialen Erstellung fortlaufend geändert werden, sind Änderungen teuer, wenn zwar der Source Code vorliegt, aber kein verinnerlichtes Verständnis des Entwurfs
- Das wird mit der Erfahrung verknüpft, dass die Produktivität beim Einstieg in eine große bestehende Codebasis zunächst fast bei null liegt und dann steigt, während man die Programmtheorie im Kopf aufbaut
-
LLMs und Programmtheorie
- Heutige LLMs können sich über ihr Kontextfenster hinaus nichts merken und daher keine Theorie, keinen Entwurf und keine mentalen Konstrukte meistern
- Wesen, die Programmtheorie erwerben und aufrechterhalten können, sind Menschen
Programmentropie: Die Fähigkeit, Komplexität zu verringern oder ihr zu widerstehen
- Komplexität ist eine grundlegende Gegenkraft in der Programmierung und hängt mit Entropie zusammen
- Fred Brooks’ The Mythical Man-Month betrachtet den Aufbau von Programmen als einen Prozess der Entropiereduktion und Wartung als einen Prozess der Entropiezunahme
- Aus Brooks’ Sicht führen Änderungen an Programmen nach der initialen Erstellung zwangsläufig zu größerer Komplexität im Source Code
- Änderungen, die mit dem Entwurf im Einklang stehen, können die Zunahme der Komplexität jedoch verlangsamen
-
LLMs und Programmentropie
- LLMs sind Token-Prädiktoren und arbeiten nur auf Textebene
- LLMs können nicht auf der Konzeptebene mit Ideen, Diagrammen oder Anforderungsspezifikationen schlussfolgern
- Wer große Codeblöcke in ein LLM eingegeben hat, wird die Tendenz bemerken, dass unnötige und seltsame Änderungen vorgenommen werden
- Je länger das Gespräch dauert, desto stärker können die Ergebnisse abdriften
- Die Fähigkeit, die Komplexität von Code zu verringern oder sich ihr zu widersetzen, liegt beim Menschen
Wie AI im Engineering eingesetzt werden sollte
- Wer erwartet hat, dass AI die eigene Engineering-Karriere auf die nächste Stufe hebt, könnte feststellen, dass sie das Gegenteil bewirkt
- LLMs können Inkompetenz beschleunigen, menschliches Engineering aber nicht ersetzen
- Der geschäftliche Reiz von AI liegt darin, Engineering zu kommodifizieren und Kosten zu senken
- Doch wie schon der Einsatz von Engineering-Talenten im Ausland gemischte Ergebnisse brachte, so bringen auch LLMs Grenzen und Risiken mit sich
- Der AI-Hype-Zyklus könnte irgendwann seinen Höhepunkt erreichen
- Unternehmen, die AI heute übermäßig einsetzen, werden die langfristigen Kosten tragen und womöglich den Kurs ändern oder verschwinden
- Das langfristige Wertversprechen des Menschen im Engineering bleibt unverändert
- Die Welt braucht weiterhin technisches Können und tiefes Denken
- Für solche Fähigkeiten wird weiterhin bezahlt werden
- AI wird bleiben, sollte aber als Werkzeug genutzt werden und nicht als Krücke, auf die man sich stützt
- In die grundlegenden Engineering-Fähigkeiten, die bereits 2019 als wertvoll galten, sollte weiter investiert werden
1 Kommentare
Meinungen auf Hacker News
Manchmal fühlt es sich so an, als spiegele die Debatte über AI-Coding den Unterschied zwischen Software Engineers und Data Scientists/Machine-Learning-Engineers wider
Beide haben mit unklaren Anforderungen und schwer zu fassenden Bugs zu tun, aber im Allgemeinen bauen Software Engineers Software, die sich immer auf eine bestimmte Weise verhalten soll; Reproduzierbarkeit, Tests und ausgereifte Werkzeuge sind wichtig
Machine-Learning-Engineers dagegen arbeiten mit Modellen, die ihrem Wesen nach probabilistisch sind, und auch Tests drehen sich eher um Bewertungsmetriken wie „in 90 % der Fälle die richtige Ausgabe“ als darum, ob eine bestimmte Ausgabe erzeugt wird
Deshalb ist die Denkweise, mit einer AI umzugehen, der man nie vollständig vertrauen kann, im Machine-Learning-Bereich natürlicher, und man bewertet Coding-Assistenten eher nach dem Muster: „80 % sind richtig und sparen mir Arbeit, die restlichen 20 % fange ich selbst ab“
Als ich bei Amazon arbeitete, passten Machine-Learning-basierte Lösungen oft gut zu echten Problemen, für die es keinen klassischen Ansatz gab. Zum Beispiel waren Bewegungsvorhersage auf Basis von Rasterkarten oder Bild-/Rasterkartenklassifikation nützlich, weil sie sich gut in bestehende Schätz- und Steuerungs-Pipelines integrieren ließen
Umgekehrt wurde ich bei einem Startup von einem unteren Manager immer wieder gerügt, weil ich einen lernbasierten Ansatz für das Problem anzweifelte, die Ausrichtung einer stationären Ebene über die Zeit zu schätzen. Weil das Team die Grundlagen von Mapping oder Filtering nicht kannte und annahm, „mehr Daten reinzugeben“ werde das Problem lösen, bekam die gesamte Fahrzeugsteuerungs-Pipeline flackernde und springende, willkürliche Rotationsschätzungen eingespeist
Diese Kluft ist wirklich groß, und ich wünschte, es gäbe bessere Wege, sie in Interviews herauszufiltern
Früher hörte ich einmal, wie sich der Senior Architect unseres Unternehmens nach einem Meeting beschwerte: Bei unserem Produkt seien Genauigkeit und Korrektheit immer ein wichtiges Verkaufsargument gewesen, aber das Machine-Learning-Team in einem anderen Büro verstand das nicht und hielt 80–90 % Genauigkeit für ausreichend für Kunden
Das erinnert an die Debatte, ob eine Sterblichkeitsrate von 1 % bei einer Pandemiekrankheit klein oder groß ist. 1 ist die kleinste ganze Zahl, aber 1 % von 300 Millionen Menschen sind 3 Millionen Menschen
Aber ich glaube nicht, dass dieser Artikel nur davon handelt. Er behandelt die Meta-Bedenken von Menschen, die Software Engineering betreiben, und wie AI dazu passt; wenn er von „Programmentropie“ spricht, trifft er den Kern
Ein großer Teil der Arbeit beim Bau von Softwareprodukten besteht darin, Entropie zu managen. Man muss Code und Menschen vermehren und trotzdem ein angemessenes Vorankommen aufrechterhalten, und alle müssen verstehen, wie die Teile ineinandergreifen und wie neue Teile hinzugefügt werden. Vielleicht wird AI das eines Tages einfacher machen, aber im Moment verschlimmert sie die Entropie oft eher
Das wäre kein großes Problem, wenn Leute mit Eigeninteressen nicht versuchen würden, uns einzureden: „Doch, AI kann sofort für alles eingesetzt werden“
Diese Annahme ist so absurd, dass sie sich kaum noch logisch widerlegen lässt, und bisher war sie als glaubensbasierte Erzählung, die enorme Investitionen anzieht und auf Profit ausgerichtete Personaloptimierung verpackt, äußerst erfolgreich
Ich stimme der Prämisse des Artikels und den meisten konkreten Argumenten stark zu, sehe aber im Alltag bei der Nutzung von LLMs auch positive Seiten. Zur Einordnung: Ich arbeite seit ungefähr 30 Jahren in der Softwarebranche
Beim Umgang mit AI-generiertem Code liest man Code. Entwicklung wird eher zu einer Reihe von Code Reviews als zu einer Reise der Schöpfung von Grund auf, und für Solo-Entwickler hat das den Vorteil, dass sie Verantwortung nachahmen und einüben können, die man sonst leichter nur im Team lernt
Außerdem zeigt sich bei der Arbeit mit LLMs schnell, dass Entwickler das Problem als klar und gut strukturierte Schichten verstehen müssen. Wenn man etwas Großes auf einmal beauftragt, schießt man sich in der Regel selbst ins Knie; daher hilft ein Ansatz aus Designperspektive, mit detaillierten Spezifikationen und Umsetzung Teil für Teil, dabei, die Grenzen und Interfaces konzeptioneller Blöcke festzulegen
Man kann LLMs als starken Beschleuniger sehen, der Junior-Entwicklern hilft, in eine Senior-Rolle hineinzuwachsen. Mit angemessener Anleitung machen sie den Lernfortschritt sichtbar, den erfahrenere Leute sich über längere Zeit erarbeitet haben. Ich sehe nicht alles düster, glaube auch nicht, dass AI Entwickler ersetzen wird, und denke, dass sie zwar derzeit sehr disruptiv ist, am Ende aber irgendwo zwischen den anderen Werkzeugen ihren Platz finden wird
Wenn man Code reviewt, den ein LLM mit erstellt hat, könnte man sagen, dass man dadurch faderen Code liest, aber ich denke trotzdem, dass man lernt. Ich habe viel LLM-generierten Code gelesen und lerne oft Idiome kennen, mit denen ich nicht vertraut war, oder Library-Aufrufe, die ich nicht kannte
Für Senior-Entwickler ist ein LLM ein noch stärkerer Beschleuniger. Weil sie wissen, was existiert und was man gar nicht erst ausprobieren muss, können sie besser prompten
Schon ein Blick auf die jüngsten Nachrichten zeigt, dass die Entlassungen bei Big Tech, mittelgroßen Tech-Unternehmen und kleinen Tech-Unternehmen weitergehen
Erinnerst du dich noch an die Zeit, als es hieß, 3D-Druck werde die gesamte Fertigung ersetzen?
KI liegt näher an dieser Stimmung als an einer Singularität.
Man könnte sagen, dass LLMs nichts verbessert, sondern nur systemische Schwächen offengelegt haben; die Wirkung selbst ist aber eindeutig. Dutzende Vorlesungsabläufe, die vor zwei Jahren noch Standard waren, funktionieren nicht mehr.
Das gilt insbesondere für die gesamte Online- und Fernlehre, und ironischerweise kam ChatGPT genau zu dem Zeitpunkt heraus, als viele Universitäten nach Covid begannen, darin zu investieren. Das ist eine Auswirkung in der Größenordnung der gesamten Hochschul- und Sekundarbildung weltweit.
Die Luft- und Raumfahrt ist ein gutes Beispiel. Vieles von dem, was SpaceX und junge Startups in diesem Bereich tun, wäre ohne 3D-gedruckte Teile nicht möglich gewesen. Teile wie Düsen, Brennkammern und Turbopumpen werden häufig gedruckt.
Trotzdem erscheint mir der Vergleich nicht fair. Als ich Maschinenbau machte, hat 3D-Druck meine Engineering-Fähigkeiten eher verbessert, weil er schnellere und günstigere Prototypen und Fehler ermöglichte.
Er hat nicht die gesamte Fertigung ersetzt, spielt aber eine wichtige Rolle im Design und hat die Fähigkeiten der Nutzer nicht verkümmern lassen.
LLMs sind erstaunlich darin, Code zu schreiben, aber miserabel darin, diesen Code zu besitzen und zu warten.
Jede Zeile, die man übernimmt, ohne sie zu verstehen, ist geliehenes Verständnis, das man bei der Wartung mit hohen Zinsen zurückzahlt. Es fühlt sich wie kostenlose Geschwindigkeit an, ist in Wirklichkeit aber eher technische Schuld mit vielleicht 40 % Zinsen pro Jahr.
Als Branche müssen wir herausfinden, wie wir mit KI das Tippen automatisieren, aber nicht das Denken automatisieren.
Das tut es aber nicht, und aufgrund seiner Funktionsweise kann es das auch nicht.
Daher ist jede LLM-Zeile, die man ohne Verständnis übernimmt, in Wahrheit Verständnis, das gar nicht existiert. Es ist nur eine Codezeile, die ein probabilistisches Modell ausgespuckt hat, und sie bleibt unverstanden, bis ein Wesen sie gesehen hat, das den Kontext der Codebase, das System und das Design tatsächlich verstehen kann. Derzeit sind als solche Wesen nur Menschen bekannt.
In der traditionellen Entwicklung mag ich beides nicht besonders, aber aktuelle LLMs machen beides einfacher und nützlicher.
Und die „Dreierregel“ hört zwischen Komponenten praktisch auf zu gelten. Codeänderungen müssen entweder lokal begrenzt sein oder Teil einer sehr robusten Basisbibliothek. Zwischenfälle lassen die Refactoring-Komplexität explodieren.
Dass „LLMs suggestiven Prompts nicht widersprechen“, war bisher das größte Eingaberisiko und der größte Schmerzpunkt.
Noch frustrierender ist, dass ich möglicherweise nicht einmal merke, dass ich in eine bestimmte Richtung lenke. Wenn man bedenkt, wie LLMs funktionieren, ergibt das zwar Sinn, aber schon ein einziges vage formuliertes Wort kann das Ergebnis in eine schlechte Richtung kippen lassen, es ins Gegenteil dessen treiben, was ich wollte, und in den falschen Kaninchenbau führen.
Wenn man es merkt, steckt man mitten in einem irgendwie gerade so funktionierenden, zusammengeflickten Code-Sumpf. Menschliche Sprache ist extrem mehrdeutig und unspezifisch; das ist fast genau der Grund, warum wir überhaupt regelbasierte formale Sprachen erfunden haben, die Präzision ermöglichen.
Persönlich hatte ich auch das Gefühl, dass meine Fähigkeiten durch AI-Tools schnell verkümmern. Eine Zeit lang griff ich aus Bequemlichkeit für jede Kleinigkeit zu AI, aber als ich einen Schritt zurücktrat, merkte ich, dass ich kaum Zeit sparte und stattdessen viel schneller erschöpfte, weil ich Dutzende oder Hunderte Zeilen Code lesen, überlegen musste, wie die AI falschlag, und es dann korrigieren musste.
Gemessen habe ich es nicht, aber insgesamt habe ich vermutlich deutlich mehr Zeit mit AI-Tools verschwendet als eingespart.
Das eigentliche Problem ist, dass AI für viele Aufgaben tatsächlich nützlich ist, die Nutzer aber in zwei Gruppen fallen. Die einen setzen sie für komplexe Aufgaben ein, bei denen sich kleine Fehler schnell aufsummieren; die anderen sind meist Manager-Typen, die sehen, wie sie 200 Zeilen Code ausspuckt, den sie nicht verstehen, eine gerade so funktionierende TODO-App für ein „MVP“ halten und denken: „Wenn ich das bauen kann, kann ich deinen Job auch leicht machen.“
Wer mit der üblichen Antwort kommen will, ich hätte es falsch benutzt oder das Modell sei eben falsch gewesen, sollte als Kontext zu meinen Erfahrungen mit diesen Tools bitte zuerst meinen früheren Kommentar lesen: https://news.ycombinator.com/item?id=44055448
Mit anderen Worten: AI ist mein Assistent, aber die Verantwortung für ein qualitativ gutes und wartbares Ergebnis liegt bei mir.
Aus Sicht der breiten Öffentlichkeit kann man allerdings an den einfachen Taschenrechner denken. Taschenrechner haben die Kopfrechenfähigkeiten der Menschen ruiniert. AI wird dasselbe mit Schreib- und Kommunikationsfähigkeiten, Problemlösungskompetenz usw. tun.
Es scheint, als klammerten sich die Modelle an bestimmte Keywords irgendwo im Prompt-Verlauf, ließen klassische Logik fallen und drängten einen auf einen engeren Pfad, der das ursprüngliche Problem nicht einmal richtig löst. Am Ende wachsen nur Frust und Unglück auf menschlicher Seite.
Um den Verfall meiner Fähigkeiten zu verhindern, versuche ich, AI nur für kleine, klar abgegrenzte Aufgaben zu nutzen, die ich früher mit einer StackOverflow-Suche gelöst hätte. Statt nach „Wie mache ich X?“ zu suchen, stelle ich dem Modell dieselbe Frage und verwende die Antwort nicht als Wahrheit, sondern als Orientierung zur Problemlösung.
Trotzdem gibt es heute Dinge, die AI einfacher macht. Wenn man zum Beispiel ein Beispiel hat wie „Mach es wie diese Seite, aber nutze x-Daten statt y“, ist das oft schneller, als die Dokumentation zu suchen. Mit dem Vorbehalt, dass sie halluzinieren kann, aber es ist auch gut möglich, dass das mit der Zeit besser wird.
Was ich mir als Verbesserung wünsche, ist neben insgesamt höherer Genauigkeit, dass sie ohne jedes Mal ausdrückliche Aufforderung nach der einfachsten Lösung sucht. Der größte Nachteil, wenn man ChatGPT, Claude usw. loslässt, ist, dass sie sehr schnell jede Menge Müll erzeugen und nicht innehalten mit „Das wird später viel zu komplex, um damit umzugehen“. Der Originaltext argumentiert, dass nur ein Mensch, der das Gesamtdesign versteht, der Entropie widerstehen kann; ob sich dieser Punkt nie verbessern wird, weiß ich nicht, aber im Moment fühlt es sich wie das größte Problem an.
In der ersten Runde werden meist die wichtigsten Annahmen sichtbar, die das Modell trifft, und von dort aus kann man eingrenzen und präzisieren.
Nachdem ich den früheren Kommentar gelesen habe, in dem von vielen Versuchen die Rede war, scheint deine LLM-Erfahrung deutlich breiter zu sein als meine. Diese Technik habe ich dort aber nicht gesehen, daher lasse ich sie hier stehen, falls sie jemandem hilft.
Aussagen wie „Es kann Ideen, Diagramme und Anforderungsspezifikationen nicht erschließen“ oder „Nur Menschen können Komplexität reduzieren“ wirken wie Fälle, in denen hinter einem interessanten Konzept offensichtlich falsche Detailbehauptungen stehen.
Das lässt sich sehr leicht tun: Man bittet einfach um einfacheren Code. Ich nutze das oft, um eine zweite Meinung zu bekommen, und erhalte gute Ergebnisse.
Wenn man das Modell nicht fragt, bekommt man weder komplexe noch einfache Antworten. Die Standardoption abzufragen ist auch eine Entscheidung und nichts, was dem Konzept eines LLM inhärent wäre.
Ich nutze es auch erfolgreich, um Code und Ideen/Diagramme ineinander zu überführen. Ich verstehe nicht, warum Leute so starke Behauptungen aufstellen, die in der Praxis jeden Tag widerlegt werden.
Der Text wiederholt auch seltsame Argumentationslinien, die oberflächlich richtig wirken, bei genauerem Hinsehen aber nicht standhalten. Die Sache mit Naur ist inzwischen selbst ein Meme geworden und wird in der Praxis wie eine Einsicht wiederholt, vergisst aber eine weitere grundlegende und praktische Regel der Softwareentwicklung: Jedes nichttriviale Programm übersteigt sehr bald die Fähigkeit einer einzelnen Person, die gesamte Theorie im Kopf zu behalten.
Wir arbeiten fast nie mit einer wirklich vollständigen Theorie des Programms. Programmiersprachen, Techniken, Methoden und Tools haben sich alle in eine Richtung entwickelt, die es Menschen ermöglicht, besser zu arbeiten, ohne den größten Teil des Codes zu verstehen.
In dieser Hinsicht teilen Menschen dieselben Grenzen wie LLMs; wir kommen nur besser damit zurecht, weil wir nicht warten müssen, bis uns eine weitere Inferenzschleife erlaubt wird, um eine andere Perspektive zu bekommen.
Ich denke, eine ähnliche Logik lässt sich auch auf Kartentechnologien wie Google Maps oder Apple Maps anwenden. Das Argument lautet, dass solche Tools die Fähigkeit, sich in der physischen Welt zurechtzufinden, sowie den Orientierungs- und Geografiesinn verkümmern lassen.
Ganz falsch ist das tatsächlich nicht. Viele Menschen tun sich heute schwer damit, ohne Krücken wie Google Maps den Weg zu finden, und auch ihr Verhältnis zur physischen Welt hat sich in vielerlei Hinsicht verändert.
Aber auch früher waren viele Menschen nicht besonders gut darin, Wege zu finden. Vor allem die durchschnittliche Fähigkeit, in einer unbekannten Gegend sicher und zuverlässig von Punkt A nach Punkt B zu gelangen, ist eindeutig stark gestiegen.
Und bei der kleinen Minderheit von Menschen mit natürlichem Talent für Geografie und Orientierung wurden ihre Fähigkeiten durch Tools wie Google Maps nicht ersetzt, sondern ergänzt.
Ich vermute, dass es mit AI in größerem Maßstab ähnlich ausgehen wird. Es gibt ganz klar Trade-offs, und manche Skills und Fähigkeiten werden abnehmen, aber sehr viel mehr Menschen werden Dinge tun können, die sie früher nicht konnten, und eine Minderheit wird in dem, was sie tut, besser werden.
Natürlich nicht immer. Die ganze Welt zu kartieren ist eine extrem komplexe Aufgabe mit zahllosen Ausnahmen und Grenzfällen. Aber im Vergleich zu LLM-Ausgaben ist der Unterschied groß. Selbst wenn man die Temperatur auf 0 setzt und denselben Prompt mehrfach neu generieren lässt, unterscheiden sich die Ausgaben deutlich.
Außerdem decken LLMs einen viel breiteren konzeptuellen Bereich ab, sodass Menschen sie in vielen Situationen anstelle ihres eigenen Kopfes verwenden werden, in denen sie das wirklich nicht tun sollten. Schon bei Karten gibt es Leute, die in einen See fahren, weil Google Maps sagt, dort sei eine Straße. Ich will mir gar nicht ausmalen, was passiert, wenn Menschen LLM-Ausgaben blind vertrauen und ihr eigenes Denken dadurch ersetzen.
Wo ich lebe, ist Google Maps in 90 % der Fälle besser als Taxifahrer.
AI ist nicht einmal besser als jemand, der die Aufgabe seit ein paar Tagen macht.
Realistisch betrachtet erledigen 70 % der Mitarbeiter ihre Arbeit so nachlässig, dass AI sie oft genauso gut oder besser macht.
Die eigentliche Schwierigkeit ist, dass diejenigen, die vorher schlampig gearbeitet haben, auch mit AI weiterhin nutzlos sind, während die übrigen mit AI lernen und wachsen.
Bei Full Self-Driving ist es ähnlich. FSD ist besser als ein mieser, betrunkener oder textender menschlicher Fahrer, und davon gibt es auf den Straßen viele.
Ich frage mich, woher der Autor das Gefühl nimmt, dass „[AI] nicht auf konzeptueller Ebene arbeiten kann“.
Was neuere LLMs immer wieder gezeigt haben, ist, dass sie sehr wohl auf konzeptueller Ebene arbeiten können, etwa indem sie je nach Kontext Konzepte einer Sprache korrekt in eine andere übersetzen.
Dass sie Konzepte nicht wie Menschen „verstehen“, ist eine andere Aussage. Sie haben keinen Schmerz erlebt und können Schmerz daher wohl nicht „verstehen“, aber Menschen sprechen ständig über Dinge, die sie nicht selbst erlebt haben. Ob das in Ordnung ist, ist ein anderes Thema.
Das ist ein schwaches Modell einiger Eigenschaften von Konzepten, etwa von Assoziationen. Zum Beispiel ist „dog“ mit „cat“ assoziiert. Dinge wie Kompositionalität, Intension oder die Rolle, die ein Begriff in kontrafaktischen Konditionalsätzen spielt, modelliert es aber nicht.
Wenn die Frage den Trainingsdaten ähnelt, kann man scheinbare konzeptuelle Fähigkeiten allerdings mit brachialer Gewalt erreichen. Wenn jemand eine Frage wie „Wären Hunde glücklich, wenn sie auf dem Mars spielten?“ gestellt hat, oder eine hinreichend ähnliche Gruppe von Fragen, kann „dog“ in die Nähe des Clusters „wörtliche Fakten“ und des Clusters einiger bereits bekannter kontrafaktischer Fälle gesetzt werden.
Um den Unterschied zu echten geistigen Fähigkeiten zu sehen, muss man sich klarmachen, dass konzeptuelle Kombinationen beliebiger Tiefe unendlich sind und aus unendlich vielen kontrafaktischen Fällen bestehen können. Ein Kind, das nur die Grundbausteine und Vorstellungskraft hat, kann diese unendliche Vielfalt bewerten.
Deshalb werden LLMs am meisten in engen Bereichen genutzt, in denen die erforderliche „Konzeptarbeit“ sehr gut dokumentiert und hinreichend stabil ist, insbesondere in der Softwareentwicklung.
Ich neige immer stärker dazu, 90s.dev in eine AI-freie Community zu verwandeln. Sie sollte sich auf die alte Kunst konzentrieren, gute Software zu schreiben, und alle willkommen heißen, die diese Kunst kultiviert haben.
Was bräuchte man zum Start? Ein Forum? Eine Mailingliste? Einen Ansatz wie hackernoon, der Blogs mehrerer Autoren bündelt?
Eine vorläufige Mailingliste für Interessierte habe ich unter https://github.com/sdegutis/90s.dev/issues/2 eingerichtet; wer E-Mails zu diesem Thema erhalten möchte, kann sie abonnieren oder dort kommentieren.
Foren sind wegen LLMs und Bots kaputt, daher fällt diese Option weg. Damit so etwas funktioniert, müsste es nur auf Einladung sein, und jede empfehlende Person müsste für ihren Einladungsbaum verantwortlich sein.
Die Community muss gut genug sein, dass der mögliche Verlust des Zugangs gutes Verhalten fördert. In bestimmten Online-Communitys funktioniert das sehr gut.