- LLMs als KI-gestützte Programmier-Tools nehmen in der Softwareentwicklung bereits eine unverzichtbare Rolle ein
- Viele Bekannte glauben, KI sei nur ein vorübergehender Hype, doch der Autor betont, dass man im Entwicklungsbereich seine Sichtweise bereits ändern sollte
- Coding-Agenten automatisieren repetitive und langweilige Aufgaben, sodass sich Entwickler auf sinnvollere Arbeit konzentrieren können
- Es gibt zwar Debatten über Qualität, Eigentum und Tool-Unterstützung von KI-generiertem Code, doch meist wiederholen diese nur Probleme, die es in bestehenden Entwicklungsumgebungen ohnehin schon gibt
- Eine zögerliche Haltung gegenüber der Einführung von LLMs ist nicht angemessen; vielmehr deutet sich an, dass noch wichtigere technologische Veränderungen bevorstehen
Einleitung: KI, Programmierung und Skepsis
- In letzter Zeit neigen Führungskräfte in Tech-Unternehmen dazu, die Einführung von LLM-Tools zu erzwingen, doch das ist laut Autor die falsche Strategie
- Einige der klugen Entwickler im Umfeld des Autors halten KI für einen vorübergehenden Hype wie NFTs und nehmen sie nicht ernst
- Tatsächlich hat die Einführung von LLMs jedoch bereits große Veränderungen in der Entwicklung ausgelöst
- Der Text konzentriert sich auf die Bedeutung von LLMs in der Softwareentwicklung und behandelt keine anderen Bereiche wie Kunst, Musik oder Schreiben
LLM-Agenten und moderne Nutzungsweisen
Das Niveau richtig einordnen: frühere LLMs vs. heutige Agenten
- Im Unterschied zur simplen Nutzung von ChatGPT oder Copilot vor 6 Monaten bis 2 Jahren verbreitet sich heute eine weiterentwickelte Umgebung für LLM-Agenten
- Entwickler lassen Agenten heute frei im Codebestand navigieren und Änderungen vornehmen; dadurch werden Dateierstellung, Kompilierung, Tests und iterative Abläufe automatisiert
- Unterstützt werden unter anderem die Bereitstellung von Code aus dem Verzeichnisbaum und externen Quellen, informationsgewinnende Unix-Tools, Git-Interaktionen sowie die Ausführung verschiedenster Entwicklungstools
- Die eigentliche Logik zur Codebearbeitung ist vergleichsweise einfacher Systemcode
- Wer wie früher nur Code aus ChatGPT kopiert und einfügt, erlebt die eigentliche Veränderung nicht
Positive Effekte von LLMs
- Einfacher, repetitiver Code, der in den meisten Projekten anfällt, lässt sich von LLMs leicht erzeugen
- LLMs sind gut darin, Informationen ohne Suche oder Dokumentationslektüre bereitzuhalten, und sie leiden nicht unter Ineffizienz durch Ermüdung
- Wenn der Einstieg in die Entwicklung gewünschter Funktionen bisher an Hürden neuer Sprachen oder Umgebungen scheiterte, kann ein LLM diese Hürden stark senken
- Wartungsorientiertes Refactoring von Testcode, Abhängigkeitsbehandlung und andere lästige Entwicklungsaufgaben kann das LLM übernehmen
- Entwickler können mehr Energie in wichtige und kreative Bereiche investieren
Gegenargument zur Behauptung „Man versteht den von LLMs erzeugten Code nicht“
- Es ist selbstverständlich, den Code, der im Team zusammengeführt wird, selbst zu lesen und stilistisch anzupassen
- Der von LLMs erzeugte Code ist „algorithmisch“ vorhersagbar, und man kann das Ergebnis verstehen und prüfen
- Wer schon bei repetitiven Code-Reviews Schwierigkeiten hat, wird vermutlich auch mit chaotischem Code menschlicher Entwickler Probleme haben
Sicht auf das „Halluzinationsproblem“ von KI
- LLM-Agenten führen Linting, Kompilierung und Tests durch, korrigieren dadurch falsche Informationen und erhöhen die Zuverlässigkeit
- Das Halluzinationsproblem ist in den meisten Umgebungen bereits zu einem gewissen Grad gelöst
- Für eine effektive Nutzung braucht es weniger mikroskopische Überwachung als vielmehr Vertrauen in den Automatisierungsprozess
Kritik: „KI-Code ist von geringer Qualität“
- Die Kosten von LLM-Diensten liegen unter dem Gehalt eines Praktikanten (z. B. Cursor.ai für 20 US-Dollar im Monat)
- Senior-Entwickler erhöhen die Produktivität sowohl von weniger fähigen Praktikanten als auch von LLM-Code
- Der kompetente Einsatz von Coding-Agenten, Tooling und Prompt-Design ist ebenfalls ein neuer Bereich technischer Fertigkeiten
- Es gibt Verwirrung darüber, wer welche Aufgaben übernimmt; grundsätzlich tragen Entwickler jedoch die Verantwortung für Richtung, Validierung und Urteilsvermögen
Debatte: „In Rust ist die KI-Leistung schwach“
- Begrenzte Kompatibilität mit bestimmten Sprachen oder Tools ist eine Aufgabe des jeweiligen Ökosystems
- In LLM-freundlichen Sprachen wie Go ist die KI-Nutzung sehr hoch
- Probleme in der Zusammenarbeit mit Rust sind keine allgemeine Grenze von LLMs; es braucht sprachspezifische Strategien
Handwerk (Craft) und praktische Programmierarbeit
- Softwareentwicklung dient der praktischen Problemlösung
- Eine unnötige Fixierung auf Codequalität ist „yak-shaving“ und wirkt in der realen Arbeit ineffizient
- Repetitive und lästige Aufgaben sollten an LLMs delegiert werden, damit Entwickler ihre Fähigkeiten auf wertschöpfende Bereiche konzentrieren können
Die Mittelmäßigkeit („mediocrity“) von KI-Code akzeptieren
- Dass der Großteil des Codes nicht außergewöhnlich ist, stellt in der Praxis meist kein Problem dar
- Wichtige Teile sollten qualitativ verbessert werden; bei weniger wichtigen Teilen sollte man Kostensenkung durch LLMs bewusst als Vorteil nutzen
- LLM-Code ist in repetitiven Bereichen sicherer und kann im algorithmischen Bereich breitere Ansätze liefern als Menschen
Meinung zur Sichtweise „Bis AGI ist es noch weit“
- Der Autor interessiert sich nicht für die AGI-Debatte; entscheidend ist nur, ob es tatsächlich funktioniert
- Maßgeblich sind die reale Leistung und der unmittelbare Produktivitätsgewinn
Debatte über den Ersatz von Arbeitsplätzen
- Wie die Einführung von Open Source ist auch das LLM eine Technologie, die Berufsbilder verändert oder verschwinden lässt
- Auch Softwareentwickler müssen sich bewusst machen, dass sie wie andere Branchen Ziel von Automatisierung sind
- Ob diese Veränderung am Ende nützlich oder schädlich sein wird, ist ungewiss, aber die Veränderung selbst ist unvermeidlich
Plagiats-/Urheberrechtsfragen
- KI wird zu einer großen Bedrohung für die visuelle Kunstwelt
- Tatsächlich können LLMs in großem Umfang Ergebnisse erzeugen, die industriellen Qualitätsstandards genügen
- Für Softwareentwickler ist es schwierig, Plagiate als zentrales Problem anzuprangern
- Entwickler waren schon bisher gegenüber Urheberrechten wenig sensibel und bevorzugten eher Teilen und Reproduktion als strikten Schutz geistigen Eigentums
- Die Debatte über die Wiederverwendung einzelner Codebestandteile ist letztlich nur eine spezielle Ausrede
Aktuelle LLM-Nutzung und Geschwindigkeit des Wandels
- Der Einsatz asynchroner Agenten auf LLM-Basis und paralleler Arbeit steigert die Produktivität deutlich
- Selbst hervorragende Entwickler nutzen LLMs für Code-Review und Verbesserungen und erleben den praktischen Nutzen in einem dynamischen Umfeld
- In Bereichen mit Vertrauensfragen, etwa beim Zugriff auf wichtige Infrastruktur, ist weiterhin Vorsicht geboten
Fazit: technologischer Wandel und das Überwinden von Skepsis
- Anders als klassische KI-Skeptiker hält der Autor zwar an einer konservativen Perspektive fest, spürt aber dennoch den tatsächlichen Wandel
- Für Softwareentwickler ist der Zeitpunkt gekommen, sich von überholten Gegenargumenten zu lösen und die reale Veränderung anzunehmen
- LLMs und KI-gestützte Programmierung werden voraussichtlich – wie einst Smartphones und das Internet – die grundlegende Struktur der Branche verändern
4 Kommentare
Beim Schreiben einfacher Skripte zum einmaligen Gebrauch ist es definitiv nützlich. Das spart sehr viel Zeit.
Auch in Fällen, in denen ein Problem gelöst werden muss, man aber nicht viel Zeit investieren kann, ist es nützlich. Allerdings ist es derzeit zwar im Großen und Ganzen hilfreich, ersetzt Menschen aber noch nicht vollständig. Wie weit es sich künftig noch entwickeln wird, weiß ich nicht, aber im Moment ist es als Assistent ganz brauchbar.
Ob gläubiger AI-Anhänger oder Skeptiker – wenn es extrem wird, möchte ich lieber Abstand halten.
Jedes Mal, wenn sie wieder „Die Singularität kommt“ herausschreien, ist das wirklich ermüdend.
Hacker-News-Meinungen
Wenn du vor 6 Monaten versucht hast, mit einem LLM Code zu schreiben, und gescheitert bist, dann bedeutet das ernsthaft nur, dass du es anders gemacht hast als die meisten Entwickler, die LLMs ernsthaft einsetzen. Ich selbst war aber immer skeptisch gegenüber den Stimmen, die diese Technologie als revolutionär bezeichnen. Schon vor 6 Monaten hieß es, wer nicht die neuesten LLMs benutze, sei veraltet oder nutze sie nicht richtig, aber inzwischen scheint man sich einig zu sein, dass die damaligen LLMs eben nicht besonders gut waren. Das wirkt wie ein sich ständig wiederholendes „Der-AI-Junge-rief-Wolf“-Phänomen. Auch diesmal heißt es wieder, die Produktivität steige bei der Arbeit dramatisch, aber ich frage mich, auf welcher Grundlage ich glauben soll, dass die heutigen Behauptungen diesmal wirklich stimmen. Ich erwarte, dass man in weiteren 6 Monaten wieder sagen wird, die bisher verwendeten LLM-Produkte seien doch nicht gut gewesen.
Ein exponentieller Graph sieht zu jedem Zeitpunkt nach einer ähnlichen Kurve aus. Computer haben sich über lange Zeit jedes Jahr enorm verbessert, nicht weil der neu gekaufte Computer Müll gewesen wäre, sondern weil sich die Technologie tatsächlich sehr schnell weiterentwickelt hat. Hier wird die Sichtweise vertreten, dass genau dieses ermüdende Gefühl des ständigen Besserwerdens selbst das Ergebnis wirklich revolutionären Fortschritts ist.
Wenn man einen Menschen von der Geburt bis zum 30. Lebensjahr alle 6 Monate um Hilfe bitten würde, ab wann wäre man beeindruckt? Je nach Person und Aufgabe kann der Zeitpunkt unterschiedlich sein, aber mit der Zeit wären immer mehr Menschen von diesen Fähigkeiten beeindruckt. Die Entwicklung von LLMs sei ähnlich schnell, als würde man einem Kind beim Aufwachsen zusehen. Ich selbst habe LLMs früher nicht genutzt, setze sie aber seit o3 und Gemini 2.5 Pro ständig ein. Wenn du die neuesten Modelle selbst ausprobiert hast und noch immer nicht beeindruckt bist, dann wirst du es innerhalb von 3 Jahren sicher sein.
tptacek hat so etwas vor 6 Monaten noch nicht behauptet. LLMs werden mit der Zeit immer besser, und gelegentlich schaffen sie sogar den Durchbruch bei Dingen, die vorher nicht funktioniert haben. Die letzten 6 Monate markieren den Punkt, an dem „agentenbasiertes Coding“ tatsächlich angefangen hat zu funktionieren. Mit der Haltung „Es wird ja alle 6 Monate gesagt, dass es besser geworden ist, also nehme ich es nicht ernst“ riskiert man, die Fähigkeit zu verlieren, Technologien richtig zu bewerten.
Der Kern des Problems liege beim „Wendepunkt“. Manche kopieren einfach Code in ChatGPT und sind unzufrieden, andere erzielen mit Agenten, die den gesamten Code-Kontext sehen können, deutlich bessere Ergebnisse. Am Ende ist nicht nur das jeweilige LLM wichtig, sondern auch der Workflow.
Ich mag Thomas’ Argument, aber ich glaube, es enthält auch einen grundlegenden Fehler, den andere oft machen. Gute Programmierer müssen viel Erfahrung sammeln, um LLMs gut nutzen zu können, und Thomas hat sich diese Expertise ebenfalls über die Zeit aufgebaut. Vielleicht ist er aber auch die letzte Generation, die ohne LLM-Unterstützung gewachsen ist. Ich frage mich, wie Einsteiger direkt nach der Schule vom bloßen „vibe coding“ wegkommen und echte Fähigkeiten entwickeln sollen. Früher ist man gewachsen, indem man Dinge selbst mit der Hand gebaut hat, jetzt droht die Gefahr, dass man das gesamte Design und die Montage einfach einem Roboter überlässt und nie lernt, wie Werkzeuge oder Materialien tatsächlich funktionieren. Dann versteht man am Ende nicht einmal die Traglast eines Dachs anders als nur „nach Gefühl“.
Die Vorteile von AI-Agenten zeigen sich klar, wenn Experten den von LLMs erzeugten Code lesen, verstehen und in eine Codebasis integrieren können. Aber wenn irgendwann alle mit AI coden, wie bildet man dann noch echte „Editoren“ aus, die immer komplexeren Code lesen, Risiken erkennen, wissen, wo und wie getestet werden muss, und die gesamte Struktur einer Codebasis im Kopf halten können? Diese Fähigkeiten, die ein Editor heute braucht, erwirbt man nur, indem man über lange Zeit selbst Code schreibt. Wenn Einsteiger das Denken auslagern, bekommen sie keine Gelegenheit, diese Fähigkeiten aufzubauen. Es entsteht auch die Sorge, woher künftig noch erfahrene Leute kommen sollen. Als Professor stimmt mich traurig, dass Hausaufgaben und Aufgabenstellungen inzwischen schon gedankenlos mit LLMs bestanden werden. Wahrscheinlich braucht es neue Wege zur Kompetenzentwicklung, aber mir fällt bisher keiner ein, und ich frage mich, wie Einsteiger in so einer Welt zu Experten werden sollen.
Als Gegenargument kommt die Frage: Wenn alle nur noch Taschenrechner benutzen, wie lernt man dann Mathematik? Man müsse Schüler erst ausreichend von Hand üben lassen und ihnen das Wesentliche beibringen, bevor man LLMs wie einen Taschenrechner einführt.
Jemand teilt die Erinnerung an Isaac Asimovs Kurzgeschichte „Profession“. Dort bekommen die meisten Menschen ihre Fähigkeiten und Berufe direkt vom Computer, können ihre Arbeit deshalb zwar gut erledigen, entwickeln aber weder Innovation noch Kreativität. Stattdessen lernen nur einige wenige, die mit dieser Technologie nicht kompatibel sind, wirklich selbst und werden zur einzigen Gruppe, die die Kunstwelt weiterentwickeln kann.
Nach meiner Erfahrung sind LLMs eher wie Pair Programmer und für Einsteiger fast wie Senior Engineers. Sie helfen nicht nur beim Code, sondern funktionieren auch hervorragend als Tutor, der Prinzipien und Abläufe gut erklärt. Für Seniors bieten sie viele Vorteile, etwa bei Code Review, Brainstorming und Boilerplate. Aus Expertensicht kann man sich auf die 10 % schwierigen Aufgaben konzentrieren und den Rest der Routine dem LLM überlassen, was Zeit spart. Wenn Einsteiger ohne Interesse oder Neugier einfach nur Code abschreiben, ist das ihr Problem; für Leute, die aktiv lernen wollen, sind LLMs eine Lernressource auf höchstem Niveau. In diesem Sinn ist die Gegenwart für Einsteiger die beste Zeit überhaupt.
Der ganze Thread wirkt, als zeige er die klassischen psychologischen Phasen: „Das Problem existiert nicht – doch, aber es ist nicht so schlimm – oh, es existiert wirklich, dann passen wir uns eben an.“ Es fühlt sich so an, als sei hier eines der wirklichen Kernprobleme berührt worden.
Ich teile ebenfalls die Ansicht, dass Einsteiger sich nur schwer weiterentwickeln, wenn sie ihr Denken vollständig an LLMs auslagern. Gleichzeitig lerne ich durch LLMs ständig Neues. Ich lasse sie mir Aufgaben zu APIs geben, die ich nur vage kenne, lese die Ergebnisse und lerne so die Konzepte, und meistens ändere und refaktoriere ich den Code anschließend selbst. Vor ein paar Tagen wollte ich zum Beispiel verstehen, wie Signals intern funktionieren, und das LLM hat Beispiele geliefert, die wir dann gemeinsam analysiert haben. Mit genügend Neugier kann es ein unglaublicher Tutor sein. Juniors sollten nicht einfach nur „vibe coden“, sondern aktiv lernen wollen. Wenn nicht, ist das ihre Verantwortung, und in einer Realität, die ohnehin nicht mehr umkehrbar ist, gibt es mit genügend Neugier immer noch genug Wege zum Wachstum.
Ich habe kürzlich tatsächlich Dinge wie Claude 4 Agent in ganz unterschiedlichen Fällen ausprobiert: große C-Codebasen (neue Features, Bugfixes), kleine Rust-Projekte, kleine Frontends, neue Frontends mit grundlegender API-Dokumentation und mehr. In allen Fällen war es ein kompletter Fehlschlag. Es kamen falsche Diffs zurück, Tools bekamen falsche Argumente, sogar grundlegende Funktionen scheiterten, hunderte Zeilen wurden sinnlos refaktoriert, und unvollständige Refactorings blieben liegen und haben die Codebasis verwüstet. Auch bei JS-Frameworks mit vielen Daten wie Svelte oder solidJS war das Ergebnis schlecht. Ich verstehe nicht, worin die wirklichen Stärken der Agenten liegen sollen, die von manchen so gelobt werden; es wirkt eher wie Marketing-Übertreibung.
Jemand fragt nach der Art des Promptings. Meist funktioniert es deutlich besser, wenn man ein einzelnes Feature in kleinere, feinere Aufgaben zerlegt und diese dem LLM gibt. Einzelne Aufgaben im Bereich von 10 bis 200 Zeilen klappen gut, darüber hinaus folgen oft nur weitere Aufgaben und Enttäuschung. Das heutige Niveau sei intelligente, aber berufserfahrungslose Praktikanten-Autonomie. Schwieriges Gesamtdesign und Planung müssten weiterhin Menschen übernehmen.
Hypothese: Auch die Leute, die Agenten bewerben, produzieren in Wahrheit nur Spaghetti-Code und kümmern sich nicht darum, weil ihre Produktivität angeblich gestiegen ist. Konkrete Erfolgsberichte, die auch die eingesetzten Tools und Methoden offenlegen, gebe es kaum, obwohl AI das Dokumentieren ja ebenfalls übernehmen könnte.
Viele Beiträge über Agenten wirken wie Werbetexte. Es fließt zu viel Geld in den AI-Markt, und wenn man an frühere Marketingfälle denkt, sinkt das Vertrauen weiter. Ich habe selbst viele Agenten-Produkte ausprobiert, aber die praktischen Verbesserungen waren gering. Auf HN gibt es eher viele AI-pessimistische Leute, deshalb entsteht bei vielen Debatten schnell die Stimmung, das Problem liege dann wohl am Nutzer. Ein User meinte sogar, man müsse „wirklich 1000 Dollar für AI ausgeben, um es richtig zu erleben“, was stark nach Werbung riecht.
Wenn man LLM-Änderungen auf kleinen Code, einzelne Dateien oder Einheiten unter 50 Zeilen begrenzt, lässt sich das besser kontrollieren.
Als jemand, der seit den 90ern programmieren lernt, finde ich allein schon erstaunlich, dass man heute dem Computer vage und mehrdeutige Eingaben geben und trotzdem sinnvolle Ergebnisse bekommen kann. Dass man mit menschlichem Maß an Unschärfe brauchbare, klare Ausgaben erhält, fühlt sich wie Science-Fiction an.
Andererseits interpretiert der Computer selbst sehr klare Eingaben oft wieder vage um in Probleme, die für ihn leichter zu lösen sind.
Ich finde gerade diese Mehrdeutigkeit von LLMs für dokumentorientierte Gespräche attraktiv. Man muss Suchanfragen nicht ständig umformulieren, um die gewünschte Information zu finden, und spart dadurch insgesamt viel Zeit.
Erstaunen darüber, dass wir wirklich in einer unglaublichen Zeit leben, verbunden mit dem Gefühl, ein- bis zweimal pro Woche von der Realität überwältigt zu sein.
Jemand erinnert sich daran, Fan von Star Trek: The Next Generation gewesen zu sein und über den Unterschied zwischen dem Computer der Enterprise und Data nachgedacht zu haben. Der Enterprise-Computer konnte, ähnlich wie heutige AI, Wissen ordnen, zusammenfassen und Aufgaben ausführen, während Data als Roboter mit persönlichen Fähigkeiten angelegt war. Dass Data Grenzen bei Humor, Kunst und anderen menschlich-emotionalen Bereichen hatte, erinnere stark an heutige AI-Art. Auch subtile frühe Setups und Entwicklungen der Serie kommen in Erinnerung.
Ich bin in diese Branche gegangen, weil ich einer Maschine klare Anweisungen geben und exakt das bekommen wollte, was ich haben möchte. Dijkstra hat schon früher die Mehrdeutigkeit menschlicher Sprache betont und die Bedeutung „formaler Sprachen“, die genau deshalb entstanden sind. Am Ende sind wir 2025 also in einer Zeit von „Prompt Engineering“ und „vibe coding“ gelandet, in der man mit Computern diskutiert und ihre Formulierungen korrigiert. EWD667: The Humble Programmer sei lesenswert.
Ich frage mich, ob die Leute, die von den unbegrenzten Fähigkeiten generativer AI sprechen, dafür echte Belege zeigen können. Wenn GAI oder Agenten wirklich so mächtig wären, müsste man das daran sehen, dass jemand nur mit AI ein Unternehmen gründet und in kurzer Zeit massenhaft hochqualitativen Code produziert. Dafür gibt es aber keine Anzeichen. Bisher sind die nützlichsten Einsatzzwecke eher die Erzeugung von Texten und Bildern, die Menschen fälschlich für sinnvoll halten könnten. Aus Erfahrungen von Startups im realen Einsatz war es höchstens gelegentlich bei API-Erkundung oder beim bequemen Finden von Informationen hilfreich. Insgesamt überwog der Zeitverlust. Statt immer nur zu behaupten, AI sei „gut“, sei jetzt der Zeitpunkt gekommen, tatsächlich direkt von AI erzeugte Ergebnisse zu zeigen.
Hier prallen wohl unterschiedliche Perspektiven aufeinander. Es gab schon immer eine Schwelle zwischen Änderungen, die umsetzbar sind, also genug Nutzen im Verhältnis zum Aufwand bringen, und Dingen, die im Backlog liegen bleiben. AI-Tools senken diese Kostenschwelle, wodurch mehr Aufgaben überhaupt versucht werden. Deshalb betont die Seite, die von „5x Produktivität“ spricht, dass tatsächlich mehr Code verarbeitet wird, während Skeptiker eher meinen, am geschäftlichen Kernwert habe sich nicht viel geändert. Empfehlenswert dazu: Das Produktivitätsparadox der AI.
Nachfrage, welche konkreten Belege denn gewünscht seien. Gehe es um unbegrenzte Fähigkeiten oder einfach um den Nachweis realistischer Nützlichkeit? Praktisch niemand behaupte, dass diese Systeme völlig allmächtig seien; nützlich würden sie für Menschen, die ihre Grenzen und Stärken richtig verstehen. Als Beispiel wird sogar eine Commit-Historie wie cloudflare/workers-oauth-provider genannt, verbunden mit der Frage, ob man nicht wenigstens anerkennen könne, dass es ein Stück weit nützlich ist.
Alle nutzen bereits in gewissem Maß intern von LLMs erzeugten Code. Es wird berichtet, dass PRs mit LLM-Unterstützung seit Monaten in echte Produktion gehen. Wenn du den Nutzen bisher nicht gefunden hast, kann es auch sein, dass du einfach noch nicht gelernt hast, wie man sie richtig einsetzt.
Wenn ich Leute sehe, die LLMs als wenig effektiv bewerben, fühlt es sich an, als sehe ich Marketing in Aktion. Firmen, denen ich früher vertraut habe, sind in letzter Zeit leider ebenfalls stark auf AI-Werbung fokussiert. Wenn es echte Vorteile gibt, soll man es eben selbst ausprobieren, so die Stimmung.
Der Vergleich mit „Händlern, die während des Goldrauschs Schaufeln verkaufen“. Statt die Wirksamkeit des Werkzeugs selbst zu beweisen, besteht die Marketingstruktur darin, die Leute nur davon zu überzeugen, dass es irgendwo eine Goldmine gibt.
Kritik an der Haltung, die Github-Code-Lizenzproblematik zu ignorieren. Manche Entwickler sagen, man solle sich nicht um Copyright kümmern, aber die Annahme, alle Programmierer seien ständig urheberrechtsverletzende Kriminelle, ist eine falsche Verallgemeinerung. Viele Entwickler, mich eingeschlossen, haben mit groß angelegter Piraterie nichts zu tun und versuchen vielmehr, Copyleft und den Open-Source-Geist zu bewahren. Man kann SciHub als öffentliches Gut betrachten und zugleich das von einzelnen Entwicklern gewollte Copyleft respektieren. Beim Copyright geht es nicht um ein simples Dafür oder Dagegen. Diese Vielfalt und den Kontext zu ignorieren und stattdessen pauschal zu schimpfen oder das Ignorieren von Lizenzen zu rechtfertigen, ist intellektuelle Faulheit.
Programmierer verstehen Recht oft nicht besonders gut, vor allem nicht das amerikanische Common Law. Rechtstraditionen sind über lange Zeit unter der Annahme formuliert worden, dass Menschen sie vernünftig auslegen, und selbst wenn AI-Tools so gestaltet sind, dass sie Verantwortung verteilen oder umgehen, wird das Recht am Ende trotzdem jemanden finden, der zur Verantwortung gezogen und bestraft werden kann. Die Realität nach dem AI-Boom dürfte so aussehen: 1) Unternehmen und Staaten versuchen, Verantwortung zu zerstreuen, 2) es kommt zu Schadensfällen wie Autounfällen, diskriminierenden Algorithmen oder Datenlecks, 3) Gerichte geben die Verantwortung an Menschen zurück und verhängen Geldstrafen oder andere Strafen, 4) andere Unternehmen bekommen Angst vor dem Risiko und beschränken AI. In einem solchen Verlauf werden AI-Tools nur innerhalb menschlicher Verantwortlichkeit überleben können.
Ich bin seit über 25 Jahren als Free-Software-Entwickler aktiv und mag viele unterschiedliche Lizenzen. Mein Ehepartner ist Regisseur und bildender Künstler, aber ich fasse AI-bezogene Inhalte nicht an und halte sie für Müll. Diese Position wird sehr klar ausgedrückt.
Eine Challenge wie der Konwinski Prize ist interessant: 1 Million Dollar für ein Open-Source-LLM, wenn es mehr als 90 % neuartiger Github-Issues löst. Siehe Konwinski Prize Wettbewerb. Selbst die besten Modelle liegen aber derzeit nicht bei 0,9, sondern nur bei 0,09, also noch sehr weit von realer Praxistauglichkeit entfernt. Auch wenn Open Source etwas schwächer sein mag als kommerzielle Modelle, ist eigenständiges Code-Schreiben durch LLMs weiterhin nahezu unmöglich. Sie produzieren zwar oft viel Müll, sind aber trotzdem nützlich, schon allein wegen Bewertung und Verwaltung.
Selbst wenn AI die repetitive Boilerplate-Codierung übernimmt, wiederholt sich nun stattdessen das langweilige Review von AI-Code, was noch weniger Spaß macht, ähnlich viel Zeit kostet und das Verständnis eher verschlechtert.
Diejenigen, die AI-Entwicklung verteidigen, scheinen am Ende Code Review mehr zu mögen als das eigentliche Coding. Das mag persönlicher Geschmack sein, wirkt für manche aber einfach qualvoll.
Genauer gesagt kostet Review großer Code-Mengen normalerweise weniger Zeit, als sie selbst zu schreiben. Besonders wenn der Code die Tests besteht; außerdem kann LLM auch Testcode erzeugen, was die Belastung weiter senkt.
Claude, Gemini und ähnliche Systeme sind viel schneller als ich selbst beim Programmieren, und selbst wenn ich alles zweimal prüfen muss, ist es immer noch weniger Zeit als beim Selberschreiben.
Früher schrieb man Code für lästige „Yak-Shaving“-Arbeiten, heute reviewt man schlampige „Yaks“, die jemand hastig rasiert hat.
Insgesamt führt das zwangsläufig zu höherem Energie- und CO2-Ausstoß.
Diskussion über maschinelle Übersetzung und Spracherkennung. Aus der Perspektive von jemandem, der fast hörbehindert ist, wird diese Technologie den ganzen Tag genutzt. Früher konnte man Serien aus den 80ern nicht ohne Untertitel genießen, aber mit einem LLM wie Whisper lassen sich aus Videos Untertitel erzeugen, und das fühlt sich wie ein Wunder an, weil etwas Realität geworden ist, das früher nur vorstellbar war.
Bei modernster Spracherkennung und Übersetzung liegen spezialisierte Einzelaufgabenmodelle beim SOTA zwar noch vorn, aber der Abstand schrumpft schnell, und LLMs können dafür viel vielfältigere Aufgaben übernehmen. Als Beispiel wird das Spracherkennungs-Leaderboard genannt; LLMs eröffnen breite Möglichkeiten.
Über viele Jahre hinweg waren verschiedene Spracherkennungsversuche wie Dragon zwar beeindruckend, im praktischen Einsatz aber unbequem. Die Kombination aus Whisper und LLM sei der erste Moment gewesen, in dem wirklicher Nutzen entstanden ist. Perfekt ist es noch nicht, aber der manuelle Nachbearbeitungsaufwand hat sich auf ein Zehntel reduziert, sodass es für persönliche Notizen inzwischen bequem genug ist, um nicht einmal mehr alles zu verifizieren.
Für wirklich risikoreiche Aufgaben, etwa Arbeitsverträge mit ausländischen Staaten oder Aussagen bei der Polizei, würde man sich aber noch nicht allein auf LLM-Übersetzung verlassen. Sprach-zu-Text gab es zwar schon früher, und der Fortschritt ist spürbar, aber bisher bleibt es eher bei alltäglichen und risikoarmen Anwendungen; bis zu Science-Fiction-Szenarien wie interstellaren Verhandlungen ist es noch sehr weit.
Auch ich habe das Gefühl, dass die jüngsten technologischen Fortschritte tatsächlich Versprechen aus dem Science-Fiction-Genre meiner Kindheit einlösen. Vor ein paar Tagen habe ich in einer fremden Stadt die Speisekarte eines Restaurants fotografiert, handgeschriebenes Chinesisch extrahieren lassen, es direkt ins Englische übersetzen lassen und mir sogar die Aussprache des gewünschten Gerichts beibringen lassen, um es zu bestellen. Ich bin sicher, dass das vor 2 Jahren noch nicht möglich gewesen wäre.
Gerade Übersetzung scheint ein perfekter Einsatzbereich für LLMs zu sein. LLMs können soziale Konzepte, kulturelle Kontexte, Popkultur und seltene Referenzen berücksichtigen und sogar mehrere Übersetzungsvarianten passend zu verschiedenen Sprachen und Kulturräumen liefern. Es besteht die Überzeugung, dass sie traditionelle Übersetzung darin bereits weit überholt haben.