Der ewige Sloptember

• AI-Agenten führen Programmierung nicht wirklich aus, sondern ahmen die Verteilung von Programmierung nach, und kaputte Ausgaben werden zunehmend schwerer zu erkennen
• Zum Schreiben von Teilen von tinygrad und zum Reverse Engineering eines USB-<->-PCIe-Chips ausprobiert, aber der Verdacht bleibt, dass es direkt von Hand besser und schneller gewesen wäre
• Agenten sorgen anfangs für schnellen Fortschritt, lassen einen beim Finish aber wie an einem Spielautomatenhebel auf wiederholte Versuche hoffen und kommen nicht bis zum Ende
• Große Organisationen könnten durch langsame Feedback-Loops und 10-fachen Output ohne Selbstkontrolle größere Qualitätsschäden erleiden als leistungsstarke Einzelpersonen
• AI ist nützlich für Suche und schnelles Prototyping, taugt aber kaum als echter Software Engineer; entscheidend ist zu wissen, wann man sie nicht einsetzen sollte

---

Zentrale Kritik an AI-Agenten

• Der Trend, AI-Agenten in die Softwareentwicklung einzuführen, könnte ein sehr kostspieliger Fehler sein; Agenten sind näher an ausgefeilten statistischen Modellen, die nicht Programmierung selbst beherrschen, sondern die Verteilung von Programmierung nachahmen
• Die Ausgaben sind kaputt, aber auf eine Weise, die immer schwerer zu entdecken ist, und je präziser die statistischen Modelle werden, desto schwerer werden diese Probleme erkennbar
• In den vergangenen sechs Monaten wurden Agenten genutzt, um Teile von tinygrad zu schreiben und einen USB-<->-PCIe-Chip zu reverse engineeren, aber der Verdacht bleibt, dass es direkt von Hand besser und schneller gewesen wäre
• Agenten beschleunigen den frühen Fortschritt, aber in der Abschlussphase bringen sie einen dazu, wie beim Ziehen eines Spielautomatenhebels immer wieder zu hoffen, dass das Ergebnis besser wird, ohne je ganz ans Ziel zu kommen
• Da verschiedene Modelle, Harnesses und Prompts ausprobiert wurden, ist das Gegenargument „falsch benutzt“ wenig überzeugend und wirkt ähnlich wie die Behauptung, man müsse bei einem Spielautomaten nur auf die richtige Weise setzen, um zu gewinnen
• AI selbst ist nützlich; bei vielen Suchen funktioniert sie wie ein besseres Google, und für schnelle Prototypen, bei denen Perfektion keine Rolle spielt, ist sie sehr schnell
• Als Software Engineer taugt sie jedoch kaum, kommt nicht einmal an die Standards irgendeines Unternehmens heran, mit dem man gearbeitet hat, und der Schlüssel liegt darin, zu wissen, wann man sie einsetzen sollte und wann nicht

Auswirkungen auf Organisationen und Qualität

• AFL hat mehr Bugs gefunden als LLMs, ohne dass Entwickler um ihren Status fürchten mussten, und auch Schach und Go wurden nach dem Aufkommen von AI sogar populärer; deshalb ist es wenig überzeugend, AI-Kritik nur als Statusangst abzutun
• Eine Zukunft mit verlässlichen Roboterassistenten, die Code aufräumen, ist durchaus attraktiv, aber es wirkt so, als würde Verlustangst genutzt, um Agenten auf die Weise zu verkaufen, die große Unternehmen in Bewegung setzt
• Große Organisationen könnten durch Agenten größere Schäden erleiden als leistungsstarke Einzelpersonen oder kleine Organisationen
  • Leistungsstarke Entwickler können Fehler beheben, erkennen eher, wenn Output schlampig ist, und behalten die Gewohnheit bei, jede Zeile aufmerksam zu lesen und zu verstehen, außer in eng begrenzten Bereichen
  • Große Organisationen haben langsame Feedback-Loops und schwache Abstimmung; wenn schwächere Mitarbeiter mit Agenten ohne Selbstkontrolle den 10-fachen Output erzeugen, kann die durchschnittliche Qualität der Ergebnisse sinken
• Agenten werden mehr Code, Apps und Funktionen hervorbringen als zuvor, aber statt hochwertiger Juwelen könnte sich ein Zeitalter massenhafter schlampiger Ergebnisse auftürmen
• Berichte, dass Apple allen Engineers den Einsatz von AI nahelegt, sollte man nicht als abstrakte Erwartung betrachten, sondern als konkrete Frage wie: „Wird macOS in den nächsten zwei Jahren besser oder schlechter?“
• Menschen gehen bei Ergebnissen stillschweigend davon aus, dass die Urheber einen menschlichen Geisteszustand und Prozess durchlaufen haben, aber bei AI-Ergebnissen trifft diese Annahme nicht mehr zu
• Elemente wie Grammatik und Syntax, die früher als Stellvertreter für Qualität dienten, verlieren gegenüber AI-Ergebnissen an Nutzen; der Unterschied zeigt sich, wenn man auf menschliche Weise mit ihnen interagiert oder etwas darauf aufbaut
• Beim Thema LLMs ist die Position näher an LeCun/Marcus gerückt: Solche Modelle können nicht programmieren, und daraus folgt die Schlussfolgerung, dass der Prozess wichtig ist
• Deep Learning könnte weiterhin die Lösung sein, aber für echte Programmieragenten braucht es ein Weltmodell statt RLVR, das etwa failing tests auskommentiert und anschließend behauptet, alle Tests würden bestehen
• Die Kernfrage dieser Zeit könnte sein, wer im kollektiven AI-Hype durchhält, ohne sich selbst zu schaden

[GN⁺]

Hacker-News-Kommentare

• Ein großes Problem der aktuellen Debatte ist, dass sie zu sehr schwarz-weiß geführt wird. Wenn man LLMs skeptisch sieht, ist man ein Luddite, und wenn man daran glaubt, ist man „ai pilled“
  In den meisten Fällen bringen LLMs einen zu 80–95 % ans Ziel, manchmal weniger, manchmal mehr. Gelegentlich führen sie einen auch völlig in die falsche Richtung
  Trotzdem scheinen alle nur darüber zu streiten, ob ein LLM allein im Schrank zu einem perfekten Softwareingenieur werden kann, und auf dieser Grundlage sogar das riesige Potenzial in anderen Szenarien abzustreiten
  Wenn man bedenkt, wie viel produktiver die meisten Organisationen allein mit dem hätten sein können, was das Internet gebracht hat, dann sieht man, dass echte Unternehmen oft nicht einmal einen kleinen Teil des Möglichen ausschöpfen. So sehe ich auch LLMs
  Das Problem liegt nicht bei den Sprachmodellen, sondern bei uns selbst

  • Je mehr ich über die tatsächlichen Ludditen erfahre, desto besser verstehe ich ihren Standpunkt
    Die ursprünglichen Ludditen protestierten vor allem gegen Maschinen, die minderwertige Waren „betrügerisch und irreführend“ produzierten, Arbeitsstandards umgingen und qualifizierten Handwerkern die Lebensgrundlage nahmen
  • Für eine vernünftige Debatte steckt hier zu viel Geld drin
  • Der Artikel nennt besonders Agenten: „Die Einführung von AI-Agenten in die Softwareentwicklung könnte einer der kostspieligsten Fehler in der Geschichte dieses Bereichs werden“
    Ich nutze keine Agenten, sondern entwickle Software auf Funktionsniveau über einfache Chat-Interfaces und fortlaufende Gespräche. Der resultierende Workflow ist ziemlich „chimärenhaft“ und profitiert stark von meiner Erfahrung und Expertise. Das LLM glättet nur den Prozess
    Für mich funktioniert das gut, und ich möchte nicht mehr zurück
  • Der Punkt von geohot scheint ähnlich zu sein. Es geht weder darum, völlig „ai pilled“ zu werden, noch darum, ein Luddite zu sein, sondern eher darum, AI als Werkzeug zu nutzen
  • Ludditen waren nicht einfach nur „Ungläubige“, sondern gewaltbereite Aktivisten
    Die Menschen, die heute im Diskurs als „Ludditen“ bezeichnet werden, sind meist einfach Leute, die es wagen, den Hype um „AI“ zu hinterfragen. Normalerweise sind das nicht einmal Aktivisten

• Beim aktuellen Fähigkeitsniveau von AI war es für mich persönlich nützlich, sie eher als eine sehr gute Suche zu betrachten, die auf bestehendem Wissen aufsetzt. Es wirkt wie die nächste Stufe der Durchsuchbarkeit von Nachschlagewerken, Stack Overflow und GitHub
  Programmierer gehören wohl zu den Berufen, die dieselben Techniken am häufigsten wiederverwenden und neu erfinden, daher passte ein Werkzeug, das Stand der Technik extrem gut durchsuchen kann, hier besonders gut. Dass AI diesen Stand der Technik für einen konkreten Use Case anpassen kann, macht sie noch mächtiger
  Aber so wie aus zusammenkopierten Code-Schnipseln von Stack Overflow kein großer Erfolg entsteht, kann auch die heutige AI kein komplettes Projekt sauber bauen

  • Es wird klar, dass die Antwort eher in Werkzeugen liegt, die die Kosten des Umschreibens und Neuerfindens senken, als darin, alles gut in wiederverwendbare Bibliotheken zu verpacken
  • Ich stimme zu 100 % zu, dass die aktuelle AI eher eine verstärkte Version von Stack Overflow und Google ist. Meiner Erfahrung nach kann sie abgesehen von einem ersten Grundgerüst keine vollständigen Anwendungen in echter Größenordnung gut bauen
    Bei einer alten, wenig genutzten Legacy-Codebasis kann man einen AI-Agenten zum Beispiel den Code lesen lassen und fragen: „Wie macht Anwendung X Y?“ Aber ich würde ihn nicht ungehemmt Features bauen oder Refactorings übernehmen lassen
    Das würde zu zu vielen Commits führen und das Entwicklungsteam verwirren; am Ende käme wahrscheinlich etwas noch Schlimmeres heraus als der Mischmasch, den man ohnehin schon verwaltet. Ich bin in letzter Zeit etwas von AI enttäuscht gewesen, und diese Beschreibung fasst meine Erfahrung gut zusammen
  • Dass „AI den Stand der Technik für einen bestimmten Use Case anpassen kann“, ist letztlich genau das, was ohnehin alle behaupten

• Das Schwierigste in der Softwareentwicklung ist es, das richtige Problem zu lösen. Ich denke, die Fähigkeit zu erkennen, welches Problem überhaupt gelöst werden sollte, unterscheidet Senior Engineers auf höherem Niveau
  Vereinfacht gesagt ist das hier das Problem, das – wenn man es löst – im Verhältnis zu Komplexität und Nebenkosten den größten Wert für das Produkt schafft
  Vor langer Zeit habe ich an einem Webprodukt gearbeitet, bei dem ein Junior-Designer ursprünglich dachte, es wäre toll, wenn man das Backend mit LDAP-Tools verwalten könnte. Deshalb ahmten das Datenbankschema und die Struktur des Produkts OpenLDAP nach und verwendeten zusammengesetzte CN-Schlüssel, und die gesamte Codebasis musste beim Lesen und Schreiben in die DB ständig mit dieser Struktur umgehen. Bei der Gestaltung des DB-Schemas war LDAP-Kompatibilität nicht das richtige Problem, das es zu lösen galt
  Software, die das richtige Problem löst, kann schwer zu erkennen sein. Meist wirkt ihre Funktionsweise so selbstverständlich, dass kaum auffällt, dass man sich auch für ein anderes Design hätte entscheiden können
  Was mit der Zeit den Explosionsradius eines Designs begrenzt, das das falsche Problem löst, ist meist die Reibung, die dieses Design erzeugt. Die Entwicklung wird langsamer, und auch die Entwicklung weiterer Lösungen für die falschen Probleme wird langsamer. Das ist ein selbstbegrenzender Effekt
  Genau das ist meine große Sorge bei LLM-Coding-Agenten. Sie überdecken diese Reibung. Sie beheben nichts, sondern verschieben die Kosten nach hinten
  So entstehen Codebasen, deren Komplexität im Verhältnis zum gelieferten Wert unbegrenzt wächst, ohne dass es noch einen Mechanismus gäbe, das unter Kontrolle zu halten
  Juniors durchlaufen dann nicht mehr die Feedback-Schleifen, in denen sich technisches Urteilsvermögen und Geschmack dafür entwickeln, welches Problem in einem bestimmten Design tatsächlich das richtige ist
  Auf Ebene des gesamten Fachgebiets könnten wir am Ende sogar vergessen, dass es so etwas wie das Lösen des richtigen Problems überhaupt einmal gab
  Ich weiß nicht, was man dagegen tun soll. Vielleicht sollte ich lieber Pläne für den Vorruhestand machen

• Derzeit kaufen Leute Peptide aus dem Graumarkt und injizieren sich Stoffe mit der Aufschrift „nicht für den menschlichen Verzehr“, gestützt nur auf fragwürdige Anekdoten und ein Gefühl dafür. Etwa um die Haut klarer zu machen und Muskelmasse aufzubauen
  Werden sie plötzlich alle zu Zombies? Nein. Wissen sie wirklich, was in ein paar Jahren mit ihrem Körper passiert? Auch nein. Könnte es katastrophal enden? Möglich
  Daran musste ich denken, wenn ich mir anschaue, wie die Branche in den letzten etwa sechs Monaten heftig dazu übergegangen ist, AI zum primären Erzeuger von Code zu machen. AI sind die Peptide, die Codebasis ist der Körper. Wie wartbar dieser Ansatz ist, weiß buchstäblich niemand. Es ist einfach noch nicht genug Zeit vergangen, um das herauszufinden
  Es könnte gutgehen, oder es könnte ein völliges Chaos werden. Ein ganzes Engineering-Team könnte das Steuer loslassen und einschlafen, im Glauben, zu verstehen, was es baut, obwohl es das in Wirklichkeit nicht tut, und in dem Moment, in dem das LLM nicht mehr mithalten kann, völlig die Fähigkeit verlieren, es zu reparieren oder zu warten
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  In meiner persönlichen Codebasis mache ich das nicht mehr, außer wenn mir Wartbarkeit oder Lebensdauer wirklich egal sind

  • Klüge Entwickler werden vermutlich isolierte Module bauen. So kann man von AI erzeugte Module abtrennen und neu bauen, wenn sie weiter scheitern

• Ich bin momentan auf der Seite von „seit einer Weile keinen Code mehr selbst geschrieben“. Ich würde gern ein Beispiel sehen, das schlimm genug ist, um zur manuellen Programmierung zurückzukehren
  Mein Hauptproblem ist, dass die Qualität zwischen Model-Releases schwankt und dass besonders Kommandozeilen-Tools dazu neigen, veraltete APIs oder Dokumentation hineinzumischen
  Dass Modelle in einer millionenzeiligen monolithischen Codebasis mit zehn Jahren Altlasten kämpfen, verstehe ich. Aber warum es in einer neuen Codebasis so schmerzhaft sein sollte, leuchtet mir nicht recht ein

  • Es muss nicht unbedingt ein „zu großes“ Problem sein. Es kann auch einfach zu klein sein, um den Aufwand wert zu sein
    Programmieren ist nicht besonders schwer, deshalb ist es oft einfacher, einfach zu programmieren, als Englisch zu lesen und zu schreiben. Allerdings nutze ich nur Haskell, also bin ich vielleicht voreingenommen
  • Wie lange müsste der Zustand „seit einer Weile keinen Code mehr selbst geschrieben“ anhalten, bis du glaubst, dass man durch fehlende Übung das Coden verlernt?
    Eines der Risiken von Engineering-Management ist, dass es einen zu jemandem machen kann, der diesen Job nicht mehr selbst tun kann
    Ist das überhaupt wichtig?
  • Wenn bei jedem Prompt ein PR mit tausend Zeilen herausfällt, ist man von einem weiteren millionenzeiligen Monolithen nicht mehr allzu weit entfernt
    Trotzdem bin ich etwas optimistischer als der Autor. Ich habe das Gefühl, dass man den Prozess so steuern kann, dass genau das nicht passiert
  • Vor Kurzem gab es ein Beispiel auf der Startseite: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • Es kommt darauf an, welche Art von Projekt man macht. Entscheidend ist vor allem, wie viel Neues darin steckt, wie viele Datenpunkte sich per Suche schwer finden lassen und wie viele nicht offensichtliche, projektspezifische Abweichungen von Industriestandards es gibt

• Agentische Laufzeitumgebungen gibt es erst seit gut einem Jahr, und erst seit etwa einem halben Jahr sind sie einigermaßen verlässlich, aber die Ermüdung ist jetzt schon groß. Ich denke, das zeigt weniger, ob LLMs tatsächlich programmieren können, als vielmehr die mentale Erschöpfung durch AI-unterstütztes Programmieren
  Um wirklich nachzuvollziehen, was ein Agent in einer Codebasis tut, braucht man eine hohe Entscheidungsfrequenz und muss astronomische Mengen an Code und Prosa lesen
  Diese persönliche, psychologische Müdigkeit und die negativen Gefühle werden fälschlich in pessimistische Prognosen über das Entwicklungspotenzial der Technologie selbst übersetzt

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • Technologie existiert nicht getrennt davon, wie Menschen sie verwenden
    Wenn alle, die sie richtig einsetzen, frustriert sind und die, denen sie gefällt, Berge unwartbarer Mischmasch-Systeme produzieren, dann werden wir das bald auf den Müllhaufen der Geschichte werfen
    Vieles hat „Potenzial“, wird am Ende aber trotzdem nichts
    Ich werde LLMs weiter nutzen, aber meiner Meinung nach hat die Nützlichkeit von agentischem Coden bereits ihren Höhepunkt überschritten

• Ein Teil meiner Arbeit besteht darin, Wege zu finden, diese Modelle in dem Großkonzern, für den ich arbeite, produktiv zu machen. Es ist eher so, als würde man Tomaten gegen die Wand werfen, und bis zu einem gewissen Grad sehe ich ein Problem, das dem ähnelt, was er gesagt hat: Die Ausgaben scheinen bestimmte Grenzen zu haben.
  Gleichzeitig gibt es in seinem Text nirgends ein Code-Snippet oder ein anderes konkretes Artefakt, an dem man festmachen könnte: „Hier hat das Modell miserabel versagt, und eigentlich hätte es so aussehen müssen.“ Diese Art von Kritik wirkt wie ein wiederkehrendes Muster in Blogposts und Twitter-Beiträgen der Sorte „LLMs taugen überhaupt nichts“.
  Die Modelle sind offensichtlich besser als Autocomplete, und auch in meiner täglichen Entwicklungsarbeit erzeugen sie große Teile einer Codebasis, wie sie auch ein Junior- oder Mid-Level-Ingenieur geschrieben haben könnte.
  Wenn niemand konkret zitiert, welche Fehler tatsächlich passieren, wie sollen wir dann ihre realen Fähigkeiten einschätzen?

  • Die Fehler, die LLMs machen, sind ziemlich subtil. Mit LLMs zu coden ist wie eine Szene aus dem Film Whiplash. „Nicht mein Tempo“, „Downbeat auf 18“, „du bist zu schnell“, „zu langsam“ — so in der Art.
    Sie erzeugen fast immer Code, der läuft, und normalerweise tut er auch ungefähr das, was man verlangt hat. Aber er liegt auf eine unglaublich frustrierende Weise leicht daneben, sodass man am liebsten einen Stuhl werfen würde. Und obendrein fehlt ihnen sogar jedes Gespür dafür, was genau wie falsch gelaufen ist.
  • Wenn Leute Blogposts darüber schreiben, dass LLMs bei einer bestimmten Aufgabe gescheitert sind, ist die Reaktion der Verteidiger fast immer: „Nimm ein anderes Modell“, „ändere den Prompt so“, „dir fehlt das Können; aus einem einzelnen Beispiel kann man keine grundsätzliche Aussage über KI ableiten“.
    Dann geht es also nicht, konkrete Beispiele zu bringen, und es geht auch nicht, keine konkreten Beispiele zu bringen. Dann ist das Spiel im Grunde vorbei.
    Ich weiß, dass ich hier einen Fehlschluss der Gruppenattribution begehe, aber trotzdem ist es so.
  • Genau das ist ein hervorragender Punkt. Selbst aus der Perspektive eines Anfängers, der dank LLMs Projekte angeht, die früher völlig außerhalb seiner Reichweite gewesen wären, möchte man Beispiele und Belege dafür finden, was der Agent genau falsch schreibt und wie ein Mensch es besser machen würde.
    Solches Material gibt es sicher, und wenn jemand Inhalte mit guten Beispielen kennt, würde ich das gern erfahren.
    Ich bezweifle nicht, dass die besten paar Prozent der Programmierer deutlich besser schreiben können als Claude oder Codex. Aber mich interessiert, wie viel schlechter sie im Vergleich zum durchschnittlichen, gewöhnlichen Entwickler sind.
  • Dieser Beitrag enthält ziemlich detaillierte Beispiele, einschließlich Code-Snippets, die schlechte Architektur zeigen: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• Ich vermute, dass die Modelle weiter besser werden.
  Als ich vor ein bis zwei Jahren mit agentischem Coden angefangen habe, war ich überzeugt, dass es nur für Autocomplete nützlich ist. Anfang dieses Jahres ist irgendetwas passiert, und die Modelle haben ein neues Fähigkeitsniveau erreicht.
  Inzwischen machen alle, die ich kenne, agentisches Coden, und das ist wirklich erstaunlich. Ich denke, man sollte so weit wie möglich auf das Gaspedal treten. Es fühlt sich an, als stünde die Beschleunigung der Menschheit unmittelbar bevor.

  • Wir stoßen bereits auf einige logistische Grenzen. Selbst wenn es bei Transformern kein intrinsisches Fähigkeitsplateau gibt, sind die GPUs und die elektrische Leistung, die man für Verbesserungen einsetzen kann, begrenzt, und beim Ausbau dieser Infrastruktur gibt es große Schwierigkeiten.
    In den vergangenen zwei Jahren wurden neue Rechenzentren mit zusammen etwa 6 GW angekündigt, aber tatsächlich in Betrieb gegangen und in den Service gestartet sind weniger als 1 GW. Bei allen übrigen verschieben sich die Liefertermine immer weiter nach hinten.
    Außerdem sagen die Rechenzentren, die Chips darin würden sechs Jahre durchhalten, aber auch das erweist sich als unrealistisch.
  • Was, wenn wir mit Vollgas auf eine Wand zurasen?
  • „Beschleunigung der Menschheit“ ist das größte Coping, das ich dieses Jahr gesehen habe.
  • Ja, irgendetwas ist passiert. Sie sind besser in Autocomplete geworden. Was denn sonst? Das Basismodell hat sich nicht geändert.
    Ich wünschte, dieses Gerede von der „Beschleunigung der Menschheit“ würde aufhören. Niemand löst mit LLMs Krebs, Klimawandel, Ungleichheit oder andere wichtige reale Probleme.
    Wenn diese Technik gut genug ist, um deine Produktivität zu steigern, dann deshalb, weil du nichts Neues, nichts Hochmodernes und nichts Innovatives machst. Der einzige Grund, warum ein LLM deinen Job erledigen kann, ist, dass dieser Code bereits wortwörtlich geschrieben wurde und oft genug in den Trainingsdaten vorkam.
    Versuch mal, mit LLMs C++26, HDL oder einen extremen Nischen-Stack zu schreiben — das wäre ein guter Reality-Check.

• AFL hat nicht mehr Schwachstellen gefunden als LLMs. AFL und erfahrene Praktiker haben Schwachstellen gefunden.
  AFL provoziert Fehler, und viele oder die meisten davon sind nicht ausnutzbar. Menschen — heute auch Agenten — müssen sie aussortieren und bewerten.
  Außerdem geschah das an einem Korpus speicherunsicherer Software aus der Zeit vor AFL. AFL hatte seine beste Zeit vor zehn Jahren, und inzwischen sind alle Ziele schwieriger geworden.

• Als zusätzlicher Kontext: Der Autor ist George „geohot“ Hotz. Er hat eine lange Exploit-Historie und ist vermutlich vor allem dafür bekannt, dass er comma.ai für autonome Fahrzeuge mit kleinem Budget fast schon im Stil von Vibe Coding aufgebaut hat — lange bevor echtes AI-Vibe-Coding überhaupt aufkam.
  https://en.wikipedia.org/wiki/George_Hotz