- Erfolgsgeschichten über LLM-Tools lassen oft Vergleichsmaßstäbe wie Projektbedingungen, Expertise der Nutzer oder den Umfang der Nacharbeit aus, wodurch ihr tatsächlicher Nutzen schwer zu beurteilen ist
- Die Haltung, Kritiker in Debatten über MCP, Tool-Nutzung und Agents als „Leute, die nicht genau genug hingeschaut haben“ abzutun, erinnert an frühere Crypto-Debatten
- LLMs und Agents sind nichtdeterministisch, daher lässt sich schwer annehmen, dass ein Ansatz, der bei demselben Problem jetzt funktioniert, auch eine Minute später noch genauso funktioniert
- Auch die bekannte Aussage, Claude Code „kümmere sich um Legacy-Bugs“, erhielt 1,8 Tsd. Likes und 204 Reposts, obwohl Angaben zur Größe der Codebasis, zur Art der Bugs und zur Art der Betreuung fehlten
- Auch aus der Perspektive von jemandem, der mehrere Tools tatsächlich genutzt hat, sind LLMs eher nichtdeterministische statistische Maschinen; wenn sie funktionieren, können sie sich magisch anfühlen, doch sie eindeutig als Magie oder Engineering einzuordnen, ist schwierig
Warum sich Erfahrungsberichte zu LLMs schwer vergleichen lassen
- Positive und negative Erfahrungen mit LLM-Tools werden meist als isolierte Fragmente geteilt, sodass schwer zu prüfen ist, ob alle über dieselben Bedingungen sprechen
- Oft fehlt die Einordnung von Projekt und Codebasis
- Es bleibt unklar, ob es sich um ein Greenfield-Projekt, eine ausgereifte Codebasis oder eine proprietäre Codebasis handelt
- Auch die Expertise der Nutzer lässt sich nicht einfach vergleichen
- Es ist nicht ersichtlich, ob die Expertise auf dieselbe Domäne, dieselbe Codebasis oder dieselbe Sprache angewendet wurde
- Auch der Umfang der zusätzlichen Arbeit wie Review, Korrekturen, Deployment und Abschluss hat großen Einfluss auf die Bewertung
- Selbst wenn eine Person all diese Informationen liefert, bleibt der Vergleich zwischen Erfahrungen begrenzt, solange die Bedingungen anderer unbekannt sind
- Hinzu kommt die Nichtdeterministik von LLM-Systemen und Agents
- Selbst beim selben Problem kann man nicht davon ausgehen, dass ein Ansatz, der jetzt funktioniert, auch eine Minute später noch funktioniert
- Die Erfahrung eines Senior Engineers in einem React-Greenfield-Projekt und die Erfahrung eines nicht entwickelnden Designers mit einer proprietären OCaml-Codebasis werden noch schwerer vergleichbar, wenn sich Modell und Agent unterscheiden
- Selbst bei demselben Modell und Agent können die Ergebnisse von Ausführung zu Ausführung variieren, was einfache Vergleiche erschwert
Die Kluft zwischen überhitztem Diskurs und tatsächlicher Tool-Nutzung
- Reaktionen, die LLM-Kritiker als Menschen behandeln, die „MCP und Tools nicht ausreichend betrachtet haben“, zeigen die Überhitzung der AI-Debatte
- Als Beispiel eines „industry leaders“ wird eine Aussage von Steve Yegge zu Claude Code angeführt
- Es geht darum, dass Claude Code mehrere Tage lang intensiv Legacy-Bugs in einer alten Codebasis bearbeitet habe
- Enthalten ist auch die Formulierung, Claude Code mache weiter, ohne dass man den Kontext selbst auswählen müsse
- Ebenfalls enthalten ist die Aussage, dass Bugfixes bis zum Production-Deployment weiterlaufen und Nutzer-Logs geprüft werden, solange man nur weiter Bankfreigaben erteilt
- Auch in diesem Beispiel fehlen Informationen, die für eine Bewertung nötig wären
- Die Größe der Codebasis ist nicht bekannt
- Es ist nicht klar, um welche Bugs es ging
- Es bleibt unklar, ob zusätzliche Betreuung nötig war
- Auch Programmiersprache und Framework werden nicht genannt
- Dennoch erhielt die Aussage 1,8 Tsd. Likes und 204 Reposts
- Skeptiker und Kritiker nutzen die Tools ebenfalls
- Es gibt ein Side Project, das vollständig mit Vercels v0 entworfen wurde
- Ohne Swift-Kenntnisse wurde mit Claude Code eine SwiftUI-Monitoring-App gebaut
- Mit Midjourney wurden Event-Poster erstellt
- Ein MCP server wurde in Elixir vibe-gecodet, aber phoenix.new wurde nicht verwendet
- Die praktische Nutzungserfahrung lässt sich etwa mit „funktioniert in 50 % der Zeit nur zu 50 %“ zusammenfassen
- LLMs sind nichtdeterministische statistische Maschinen; wenn sie funktionieren, können sie sich magisch anfühlen, sind aber weder Magie noch Engineering an sich
- Der Diskurs über LLMs neigt dazu, sie ausschließlich als entweder Magie oder Engineering zu behandeln
1 Kommentare
Meinungen auf Hacker News
Es ist frustrierend, dass die Geschäftsführung bei uns Dinge wie 10-fache Produktivitätssteigerung hört. Einige dieser Behauptungen kommen sogar von internen Early Adopters.
Aber die Erwartungen sind viel zu hoch geschraubt. Einer der Gründe ist Amdahls Gesetz: In der Praxis verbringt man nämlich viel mehr Zeit mit Nachdenken und mit der Kommunikation mit anderen Menschen, die die Kunden meines Codes sind, als mit dem eigentlichen Coden. Selbst wenn das Coden 10-mal schneller würde – was meist nicht der Fall ist –, verbessert sich die Gesamtproduktivität eher um etwa 10–15 %. Das ist nicht vernachlässigbar, aber eben nicht 10-fach.
Mit einem LLM Denkaufgaben zu erledigen fühlt sich ähnlich an wie damals vor gut 20 Jahren, als ich Websuche gelernt habe. Suchmaschinen ermöglichten den Zugriff auf Informationen, wenn man wusste, wonach man sucht. Jetzt helfen LLMs dabei, überhaupt herauszufinden, wonach man suchen sollte, und übernehmen sogar die Suche. Aufgaben, die man früher wegen des Aufwands und der Unsicherheit als schwierig eingestuft hätte, werden trivial.
Inzwischen erledige ich etwa ein Drittel meiner Websuchen mit ChatGPT o3, und darauf möchte ich nur noch schwer verzichten.
Dazu kommt der psychologische Effekt, dass es unausgereifte Gedanken ordnet und als Rubber Duck fungiert. Viele Aufgaben fühlen sich dadurch deutlich weniger belastend an, und das allein macht schon einen großen Unterschied.
Wenn man einem Senior einen gut abgestimmten LLM-Workflow gibt, wäre es nicht überraschend, wenn er so produktiv wäre wie 10 Junior-Entwickler aus der Zeit vor LLMs. Schlechte Entwickler können einem Senior sogar Zeit stehlen und die Produktivität negativ machen; in diesem Fall nähert sich der Faktor unendlich.
Auch ordentliche Juniors sind meist an repetitive Low-Level-Arbeit gebunden, und LLMs können solche Aufgaben bereits besser erledigen.
Deshalb kann ich nachvollziehen, dass Jobs tatsächlich verschwinden könnten.
Die aktuelle AI-Welle erinnert mich an die Bewegung Anfang der 2000er, Software Engineering in großem Stil ins Ausland auszulagern. In den Führungsetagen gab es enorme Erwartungen, und auf dem Papier klang es plausibel, aber das meiste endete in großen Fehlschlägen, und fast alle Jobs kamen wieder in die USA zurück.
Viele ignorieren, dass Software Engineers unzählige kleine Dinge erledigen, die das Ganze zusammenhalten. AI fehlt vieles davon. Das heißt nicht, dass Ausländer das nicht hätten, aber durch Sprachbarrieren, Zeitzonenunterschiede, kulturelle Unterschiede usw. entstanden ähnliche Probleme. Codequalität und Wartbarkeit stürzten ab, und viele Ergebnisse von Outsourcing-Firmen mussten weggeworfen werden.
Auch in den Codebases, mit denen ich arbeite, sammelt sich bereits AI-Schlacke an. Es ist sehr schwer, solche Dinge, die durch Code Reviews kommen, zu erkennen, weil sie im Diff vernünftig aussehen. Das Problem sind unsichtbarer duplizierter Code und seltsame Abstraktionen, die auf höherer Ebene überhaupt keinen Sinn ergeben.
Ich gehöre genau zu der Gruppe, über die sich der Autor beschwert. Seit der Zeit, als es nur ChatGPT gab und die Leistung auch nicht besonders war, habe ich nicht triviale Greenfield-Produkte veröffentlicht. Anfangs habe ich Claude genutzt und zwischen Webchat und XCode hin- und herkopiert; später habe ich Cursor entdeckt.
Cursor hinterließ viele lästige Build-Fehler, aber die Produktivität lag trotzdem mindestens beim Dreifachen. Jetzt, wo die Agents besser geworden sind und Claude 4 erschienen ist, schreibe ich kaum noch selbst Code, und das stört mich auch nicht. Ich bin stärker in eine Architekten-/Managerrolle gerückt und leite die Agents bei Bedarf mit Fachwissen an.
Ich bin seit ein paar Monaten bei einem anspruchsvollen Startup, habe aber noch keine einzige Zeile Code von Hand geschrieben. Bevor ich PRs erstelle, prüfe ich alles selbst und teste es gründlich, aber Cursor + Sonnet ist in dieser Codebase wirklich absurd leistungsfähig. Nicht gemessen an sinnlosen Kennzahlen wie Codezeilen, sondern daran, dass selbst wenn Experten dieser Codebase mit ungewöhnlichen Bugs kommen, ich als jemand, der neu in dieser Domäne ist, sie innerhalb von 5 bis 30 Minuten eingrenzen kann. Deshalb bin ich überzeugt, der produktivste Mitarbeiter zu sein.
Dank Claude musste ich mich sogar aus Frontend-Entwicklerarbeit wieder herausziehen, die ich meine ganze Karriere lang eigentlich gemieden hatte, nachdem ich angefangen hatte, kleine sichtbare Probleme zu beheben. Das ist kein Vibe Coding, sondern ein Prozess aus Recherche, Planung und vorsichtigem Erkunden, bei dem man den Agent so aufsetzt, dass er erfolgreich sein kann. Domänenwissen braucht man ebenfalls. Aber ich bin wirklich erstaunt, dass es Leute gibt, die nicht denselben Nutzen daraus ziehen können, und gefühlt erscheinen jede Woche zwei solche Texte.
Du erzählst etwas kaum Glaubwürdiges, teilst aber keinerlei Belege. Du hast sogar einen Wegwerfaccount erstellt, damit Identitätsprüfung und Überprüfung der Behauptungen unmöglich sind.
Deshalb fühlt es sich wie ein Witz an.
Das heißt aber nicht, dass die Anforderungen an Kuratierung verschwinden. Das bleibt weiterhin meine Aufgabe und ist auch Teil dessen, was eine Promotion vermitteln sollte. Präzise und reflektiert damit umzugehen, warum man X tut, was man mit Y zeigen will, und jeden Schritt aufzuschlüsseln und anderen zu erklären, ist ein enormes Soft Skill. Weil Agents kein dauerhaftes Weltmodell haben und selbst mit cleverer Kompression das Ziel einer Interaktion schnell vergessen, ist das heute noch wichtiger.
Wenn ich präzise kommuniziere, kann ich Claude Code nutzen, um Rechenarbeiten auf eine Weise zu organisieren, die früher unmöglich war.
Wenn einem Qualität wichtig ist, ist das nicht leichter als Programmieren, sondern anders und verlangt andere Idiome.
Wirklich nützlich sind Agents bei groß angelegten, mechanischen Refactorings. Statt über das perfekte vim-Makro oder ein AST-Rewrite-Skript nachzudenken, überlasse ich es dem Agent.
Wie lang sind deine Prompts im Durchschnitt, und schreibt das LLM auch die Unit-Tests?
Persönlich finde ich, dass du die Erfahrung viel zu schönfärbst.
Persönlich kann ich das nicht so recht nachvollziehen.
Ein enormer Teil der Arbeit in der weltweiten Dienstleistungsbranche besteht faktisch darin, Daten manuell zu verschieben: von einer Excel-Tabelle in eine andere oder aus CRM/E-Mail nach Excel. In fast jedem Großunternehmen gibt es Hunderte bis Tausende Festangestellte, die das täglich machen, ein großer Teil davon ist ausgelagert. Ich würde sagen, auf einen Software Engineer kommen 100 Personen, die solche manuellen Daten-Pipeline-Aufgaben erledigen.
Daher muss ein LLM nicht besonders gut in OCaml sein, um enormen Wert zu schaffen. Es muss in Excel nur ein bisschen besser sein als ein Mensch. Der Punkt, an dem MCP wirklich hilft, ist, dass sich solche Systeme leicht verbinden lassen. Viele Fehler bei diesen Aufgaben entstehen, wenn man versucht, die gesamte Aufgabe auf einmal in den Kontext zu packen. Wenn man per MCP E-Mails abrufen und Daten extrahieren und sie dann wieder per MCP zeilenweise ins CRM eintragen kann, ist die Halluzinationsrate meiner Erfahrung nach sehr niedrig. Mindestens erreicht sie das Niveau eines überarbeiteten Junior-Mitarbeiters.
Vielleicht war das auch die Kernaussage des Artikels, aber bei solchen Use Cases ist Nichtdeterminismus kein Problem. Denn die beteiligten Menschen sind ebenfalls nicht deterministisch. Man kann Systeme und Prozesse bauen, die die Qualität nichtdeterministischer Systeme, etwa menschlicher Systeme, erzwingen.
Schließlich habe ich sowohl Kryptowährungen als auch LLMs aus der Nähe verfolgt, und in Bezug auf Nutzen und Adoption wirken sie für mich nicht ähnlich. Am ehesten vergleichbar ist die Smartphone-Adoption. Als das iPhone erstmals herauskam, sagten viele meiner nichttechnischen Freunde, sie bräuchten kein Smartphone, aber innerhalb weniger Jahre hatten alle eines. Bei LLMs ist es ähnlich. Inzwischen nutzen fast alle meine nichttechnischen Freunde sie für sehr unterschiedliche Zwecke.
Die gesellschaftliche Reaktion ist allerdings Teil einer Welle von Technologieverehrung, und viele Engineers, die das schon lange miterlebt haben, dürften davon ermüdet sein. Unrealistische Behauptungen lassen sich leicht finden, und die schlimmsten kommen von CEOs von AI-Unternehmen.
Gleichzeitig sind wirklich viele Menschen faktisch computer-analphabetisch. Man kann sich vorstellen, wie aufregend das für Leute wirken muss, die selbst grundlegende Automatisierung kaum erlebt haben. Der „sprechende Computer“, den wir aus der Science-Fiction kennen, wird fast Realität.
Vor ein paar Jahren habe ich vor der AI-Welle mit Machine Learning und Natural Language Processing gearbeitet, und das Auffälligste ist, dass es viel stärker im Mainstream angekommen ist als alles, was in diesem Bereich zuvor passiert ist. Entsprechend gibt es nun auch viele Menschen, denen Erfahrung damit fehlt, auf Basis statistischer Inferenz zu designen. Für eine Weile wird es in jeder Hinsicht ein Wilder Westen sein: bei Meinungen, erfolgreichen Implementierungen und realistischen Projektideen.
Man kann es so sehen: Wenn jetzt ein Freund mit einer App-Idee wie aus einem Roman ankommt, kann man ihm sagen, er solle sie selbst bauen. Das ist zumindest ein Gewinn für alle.
Dazu kann auch ein emotionales Investment in das Unternehmen gehören: der Überlebensinstinkt, nicht entlassen zu werden, der Ehrgeiz, es besser zu machen, sowie Ethik und Urteilsvermögen, um seltsame Vorgesetzte über andere Wege zu melden.
Ein LLM ruft nicht aus Gründen außerhalb des Kontexts bei einem anderen Knoten in der Organisation an, um zu prüfen, ob ein Wert seltsam ist. Zum Beispiel in einer Situation, in der der Wert 0 sein müsste, weil gestern ein einmaliger Bankfeiertag war. Sicherzustellen, dass diese Zahlen korrekt sind, kann ein volles Jahresgehalt wert sein. Und es hat ebenfalls Wert, jemanden zu haben, dem man die Schuld geben, den man entlassen oder ins Gefängnis schicken kann, wenn sie nicht korrekt sind.
Was wirklich automatisierbar ist, wurde bereits automatisiert. Ich glaube zwar, dass AI große Verwerfungen auslösen wird, bin aber sehr skeptisch gegenüber der Sichtweise, die meisten White-Collar-Berufe seien „E-Mail-Jobs“ oder Dateneingabe. Das passt nicht zu meiner Erfahrung, und ich habe auch in großen bürokratischen Unternehmen gearbeitet, über die man hier sagen würde, die Leute dort steckten in der Vergangenheit fest.
Ich bin ein pensionierter Programmierer. Es fällt mir schwer, mir vorzustellen, probabilistisch erzeugtem Code in missionskritischen Systemen zu vertrauen. Wenn er fast stimmt und nur kleine Korrekturen braucht, kann ich das nachvollziehen, aber eigene Erfahrung habe ich damit nicht.
Mein Hauptpunkt ist: LLMs sind in Bereichen außerhalb des Codings erstaunlich, etwa beim Brainstorming, beim freien Entwickeln von Ideen, beim Ausfüllen von Recherchedetails oder dabei, mir Fragen zu stellen, die mich zum Nachdenken über mich selbst bringen. Ich behandle ein LLM wie einen Denkpartner. Es macht Fehler, aber die lassen sich leicht finden, wenn man sie mit anderen Quellen abgleicht oder ein anderes LLM die Schlussfolgerungen prüfen lässt.
In weniger als 24 Stunden habe ich etwas gebaut, bei dem ich allein für den Einstieg Monate gebraucht hätte, und bis zu einer so ausgefeilten Version wie jetzt wäre es noch länger gewesen. Am beeindruckendsten ist, dass es Dinge, die ich selbst tun kann, schneller erledigt. Noch beeindruckender ist, dass es auch Dinge erledigt, die ich überhaupt nicht könnte und für die ich jemanden einstellen oder beauftragen müsste – für viel weniger Geld und Zeit und mit schnelleren Iterationen, als es in der Kommunikation mit einer anderen Person möglich wäre.
Es ist nicht perfekt und manchmal unglaublich frustrierend. Es hardcodiert Werte, obwohl ich ausdrücklich gesagt habe, dass es das nicht tun soll, oder behauptet, eine bestimmte Änderung vorgenommen zu haben, während es in Wirklichkeit etwas völlig anderes und Unzusammenhängendes geändert hat. Trotzdem ist es meiner Meinung nach ein Game Changer.
Besonders wenn man sich in einem neuen Gebiet Wissen erschließen will, ist es leicht und gefährlich, von einem LLM in die Irre geführt zu werden. Bei einer normalen Suchmaschine kann man sich die Quellseiten ansehen und ihre Vertrauenswürdigkeit beurteilen; bei einem LLM gibt es das nicht. Die Ausgabe kann im Grunde alles Mögliche sein, und ich stimme nicht zu, dass man Fehler zwangsläufig leicht findet.
Natürlich prüfe ich den geschriebenen Code, aber ich bin fast täglich von Intelligenz und Genauigkeit überrascht. Das ist etwas völlig anderes als Kryptowährungen.
Wenn man LLM-Ausgaben unkritisch verwendet, verwendet man sie falsch; aber wenn man menschliche Ausgaben unkritisch verwendet, ist das ebenfalls falsch.
Allerdings sind LLMs keine Magie, und ich mache mir Sorgen, dass Menschen mit Copilot- oder Agentenmodellen schlechte Engineering-Praktiken kaschieren und langfristig mehr Boilerplate anhäufen, statt sich um wichtige Effizienz, Sicherheit und Redesign zu kümmern.
Das Problem ist, dass man dem LLM Kontext darüber geben muss, was man tut; in ChatGPT-artigen Chats gibt man diesen Kontext nicht oder es ist zu mühsam. Hier ändert Claude Code das Spiel.
Angenommen, man hat eine PCAP-Datei, in der jedes UDP-Paket mehrere Nachrichten enthält. Wie filtert man nach IP, Port, Protokoll und Zeit? Man nutzt ein LLM und prüft die Ausgabe. Wie findet man die Anzahl der Pakete mit Mustern wie A, AB, AAB, ABB usw.? Man nutzt ein LLM und prüft die Ausgabe. Wie erstellt man für Tests ein PCAP, das nur solche Pakete enthält? Man nutzt ein LLM und prüft die Ausgabe.
Da es auch Code lesen kann, kann es, ehrlich gesagt, viel besser erschließen, was man tun will, weil die eigene Arbeit nichts Besonderes ist. Allein die Tatsache, dass man sagen kann: „Schreib Unit-Tests für alle obigen Funktionen“, hilft einem jedenfalls, selbst zu validieren.
Es gibt die Aussage: „Wie die meisten Skeptiker und Kritiker nutze auch ich diese Tools täglich. Und in 50 % der Fälle funktionieren sie zu etwa 50 %.“ Ich nutze LLMs seit ungefähr einem Jahr fast täglich bei der Arbeit, und sie lösen etwa 90 % meiner Probleme.
Es ist sehr schwer zu beurteilen, ob man solche Beschwerden über AI/LLMs ernst nehmen sollte oder ob sie eher als irrationale Nutzungsmuster mancher Anwender zu sehen sind. Ich zum Beispiel habe nie eine Codebase in ein LLM geworfen und erwartet, dass es magisch funktioniert. Ich stelle direkte, konkrete Fragen innerhalb der Grenzen meines eigenen Verständnisses und wende Lösungen absichtlich so an, dass sie testbar sind.
Wenn jemand anders herangeht und sich dann über LLMs beschwert, neige ich dazu zu sagen: Er benutzt sie falsch. Und er verpasst dabei die kleine, nützliche und ziemlich konsistente echte Magie.
Ich nutze GPT und Claude über Cursor ebenfalls täglich. gpt o3 ist für allgemeine Wissenssuche ziemlich brauchbar. Claude bricht oft zusammen, aber ich habe auch oft gesehen, dass es, während es Tokens mit Selbstdarstellung verschwendet, Punkte trifft, die tatsächlich mit dem Problem zu tun haben.
Die Modelle sind dumm, eher einfach nur dumm als geniale Idioten. Trotzdem treffen sie gelegentlich relevante Punkte. Wenn man selbst grob weiß, was passieren sollte, und ein LLM wie einen Ratten jagenden Terrier auf einem Bauernhof behandelt, kann man es sinnvoll einsetzen.
Die Zahl 90 % wirkt ebenfalls etwas verdächtig.
Dieser Beitrag liest sich, als wäre der Autor über die Ungenauigkeit des Diskurses verärgert; diese Ungenauigkeit ist ehrlich gesagt auf der Seite der Gegner weiter verbreitet als auf der der Befürworter. Befürworter müssen sich nämlich meist täglich mit Fehlern und Grenzen auseinandersetzen.
Der Schluss, dass alles rund um LLMs magisches Denken sei, wirkt ziemlich arrogant. Denn in den letzten fünf Jahren wurden Probleme wie Übersetzung, Transkription und Codegenerierung bis zu einer gewissen Größenordnung, die früher kaum handhabbar waren, vollständig oder nahezu gelöst.
Google Translate, Whisper und Codegeneratoren gab es auch ohne LLMs schon seit ziemlich langer Zeit.
Zur Aussage „Krypto ist wieder da“: Kryptowährungen sind für mich eine Lebensader. Denn in dem Land, in dem ich lebe, kann ich aus Gründen, die ich weder kontrollieren noch beheben kann, kein Bankkonto eröffnen.
Wenn Kryptowährungen für dich nutzlos sind, dann sei froh. Für mich und Millionen Menschen wie mich sind sie eine Frage von Leben und Tod.
Bei LLMs ist es ähnlich: Für manche sind sie Magie, für andere ein verlässliches deterministisches Werkzeug, und zugleich auch Magie. Ich habe gerade Hunderte von Rechnungen klassifiziert und sortiert. Ja, das ist Magie.
Deshalb ist es so schwer, in der legalen Wirtschaft nützliche Dinge zu finden, die man mit Kryptowährungen tun kann. Sie wurden dafür entwickelt, Transaktionen zu ermöglichen, die Regierungen nicht wollen oder nicht fördern können. In manchen Fällen gibt es humanitäre Anwendungen, und es gibt auch viele illegale Anwendungen.
„Man musste dabei gewesen sein, um es glauben zu können“ https://x.com/0xbags/status/1940774543553146956
Der AI-Hype durchläuft gerade eine ähnliche Phase. Jede Kritik wird als Gerede eines ahnungslosen Idioten abgetan.
Wenn du sie als Währung nutzt, sind die Leute, die Coins pumpen und dumpen und sie als Mittel zum Geldverdienen benutzen wollen, deine Gegner. Je stabiler sie sind, statt eine Achterbahnfahrt aus Explosionen und Crashs zu sein, desto besser für dich.
Im Kryptobereich gibt es meiner Ansicht nach mehr absichtliche Lügen und weniger lohnenden Wert, aber in beiden Fällen kehren Menschen, die tatsächlich profitieren könnten, wegen Unehrlichkeit und Verzerrung schon vor der Schwelle wieder um. Und in beiden Fällen gibt es heute Beispiele für realen Nutzen.
Etwas verwandt: Mich nervt, wie heutzutage der Begriff AGI, manchmal sogar der Begriff AI, verwendet wird. Gerade in wissenschaftlichen Papers würde ich erwarten, dass alles sauber definiert ist, zumindest so, wie es innerhalb dieses Papers verwendet wird.
Warum kann man keine Definition dafür erstellen, was AGI ist? Dann könnte man auch logisch beweisen, ob eine bestimmte AI dieser Definition entspricht. Selbst wenn das praktisch nicht besonders nützlich erscheint, wäre es theoretisch viel hilfreicher, als Begriffe bedeutungslos zu verwenden.
Im Moment fühlt es sich wie eine Art Ausweichklausel an. Wikipedia sagt: „eine Art von AI, die menschliche Fähigkeiten bei fast allen kognitiven Aufgaben erreicht oder übertrifft“. Wie misst man das? Wozu ist es gut, wenn man nicht beweisen kann, dass ein System diese Eigenschaft besitzt?
Ein bisschen Gemecker, aber ich hoffe, es ist trotzdem einigermaßen nachvollziehbar.
Ähnlich wie „crypto“ für mich weiterhin Kryptografie bedeutet und nicht Kryptowährung. Manchmal hat der Mainstream einfach eine andere Meinung.
„AI ist das, was noch nicht gelungen ist“[1]
Wir haben vor Kurzem im Unternehmen begonnen, LLMs einzusetzen, und die erste Aufgabe war, 20.000 Kundentelefonate zu transkribieren und anschließend folgende Informationen zu extrahieren:
Eine Recherche, die früher Wochen gedauert hätte, war in ein paar Stunden erledigt. Sie half dabei, eine neue Strategie zu entwickeln, und schuf echten Business Value.
Ich sehe LLMs einfach als Engine für Natural Language Processing, und für diesen Zweck sind sie großartig. Ja, manche übertreiben, aber das ändert nichts daran, dass sie in unserem Fall wirklich nützlich waren. Ich weiß nicht, warum es so viele „LLM schlecht“-Artikel gibt. Wenn es für einen selbst nicht passt, kann man einfach weitergehen. Warum muss irgendwer irgendwem etwas beweisen? Es ist einfach ein Werkzeug.
Solche Artikel sind wichtig, um Erwartungen abzukühlen. Wenn Leute LLMs verkaufen, reden sie normalerweise nicht über Zusammenfassungen von Kundensupport-Anrufen, sondern versuchen die Vorstellung zu verkaufen, dass man Support-Mitarbeiter entlassen kann.
Jahrelang hatten die meisten Übersetzungen im Web keinen Kontext. Jetzt können sie Kontext haben.
Vertrauenswürdige und vernünftige Tech-Persönlichkeiten, die für vorsichtige Einschätzungen bekannt sind, haben berichtet, dass sie durch verschiedene Formen generativer AI bei Programmieraufgaben erhebliche Verbesserungen erzielen.
Was heißt hier erheblich? Irgendwo zwischen 5 % und 100 %, also nicht zu vernachlässigen.
Mindestens kann man sicher sagen, dass generative AI für eine beträchtliche Zahl von Menschen ein ziemlich nützliches Werkzeug ist oder sein kann.
Damit diese Einschätzung vernünftig ist, muss man nicht alle Details wie CPU-Anzahl, Codezeilen oder verarbeitete Bytes offenlegen.