Ich glaube, dass viele Unternehmen gerade in einen kollektiven AI-Wahn verfallen sind
(twitter.com/mitchellh)- Mitchell Hashimoto: "Viele Unternehmen stecken gerade in einem schweren kollektiven AI-Wahn, und es ist unmöglich, mit ihnen ein vernünftiges Gespräch zu führen"
- Die MTBF-vs.-MTTR-Debatte aus der Zeit der Cloud-Infrastruktur-Automatisierung breitet sich nun auf die gesamte Softwareentwicklungsbranche aus, und blinder Glaube an AI-Agenten erzeugt eine neue Form kollektiven Wahns
- Ein MTTR-Absolutismus nach dem Motto "Agenten werden Bugs schnell beheben, also ist es okay, Bugs auszuliefern" greift um sich; dabei ist diese Denkweise bereits im Infrastrukturzeitalter als gescheitert entlarvt worden
- Systeme können in lokalen Metriken gesund erscheinen und sich dennoch insgesamt in einen unverständlichen Zustand verwandeln; weniger Bug-Reports und höhere Test-Coverage garantieren keine echte Sicherheit
- Spricht man das Problem direkt an, wird das Gespräch mit sofortigen Gegenargumenten wie "Wir haben 100 % Test-Coverage" oder "Die Bug-Reports gehen zurück" blockiert, ohne das Gesamtbild zu sehen
- Das Tempo des Wandels ist so hoch, dass niemand die Erosion der zugrunde liegenden Architektur bemerkt, während automatisierte "resiliente Katastrophenmaschinen" gebaut werden
Kernthese: kollektiver AI-Wahn (AI Psychosis)
- Viele Unternehmen befinden sich derzeit in einem Zustand schweren kollektiven AI-Wahns, und ein vernünftiges Gespräch mit ihnen ist praktisch unmöglich
- Konkrete Personen nennt er nicht, weil darunter Freunde sind, die er persönlich sehr respektiert
- Er äußert tiefe Sorge darüber, wie sich diese Situation weiterentwickeln wird
Lehren aus dem Infrastrukturzeitalter: MTBF vs. MTTR
- Die Debatte MTBF (Mean Time Between Failures) vs. MTTR (Mean Time To Recovery) aus der Zeit der Cloud-Migration und Cloud-Automatisierung taucht erneut auf
- Damals war sie auf den Infrastrukturbereich begrenzt, heute betrifft sie die gesamte Softwareentwicklungsbranche (und darüber hinaus die ganze Welt)
- AI-Evangelisten handeln nahezu mit einer absoluten Denkweise nach dem Muster "MTTR reicht aus"
- Die Logik lautet: "Agenten beheben Bugs in einer Geschwindigkeit und Größenordnung, die Menschen nicht erreichen können, also ist es okay, Bugs auszuliefern."
- Die Lehre aus dem Infrastrukturzeitalter: MTTR ist großartig, aber man kann resiliente Systeme nicht einfach vollständig aufgeben
Gesprächsabbruch und Muster der Gegenwehr
- Wenn er dieses Thema bei Menschen anspricht, die er persönlich kennt, folgt oft sofortige Abwehr
- Etwa Reaktionen wie "Nein, die Test-Coverage ist perfekt" oder "Die Bug-Reports gehen zurück"
- Solche Gegenargumente zeigen nicht das Gesamtbild
- Er habe seine Bedenken persönlich direkt geäußert, sei aber nicht gehört worden; deshalb halte er es für wichtig, das Thema breiter zu teilen
Automatisierte Katastrophenmaschinen
- Eine Lektion, die man in der Infrastruktur bereits einmal gelernt hat: Durch Automatisierung kann man eine "hochresiliente Katastrophenmaschine" bauen
- Systeme können in lokalen Metriken gesund aussehen, während sie insgesamt unverständlich werden
- Bug-Reports gehen zurück, aber latente Risiken explodieren
- Test-Coverage steigt, aber das semantische Verständnis nimmt ab
- Veränderungen geschehen so schnell, dass niemand die Erosion der zugrunde liegenden Architektur bemerkt
Wichtige Punkte aus den Antworten
- @adamhjk: "Was reines Vibe Coding zuerst zerstört, ist die Architektur selbst"; überhaupt müsse erst einmal eine Architektur existieren, damit man ihre Erosion erkennen kann
- Zusätzliche Erläuterung von Mitchell Hashimoto: In der Infrastruktur kann man Online-Systeme aktualisieren und MTTR in angemessener Zeit auf alle Nutzer anwenden, aber bei Software wie Bibliotheken, Desktop-Software und Mobile Apps, die von anderen integriert oder direkt ausgeführt wird, funktioniert dieser Ansatz nicht
- @tinygrad: Wir seien in ein Zeitalter eingetreten, in dem es nicht 10 Sekunden, sondern 20 Minuten dauert, festzustellen, ob das, was die AI gesagt hat, völlig falsch ist; Organisationen müssten den Kontakt zur Realität bewahren
- @beyang: Die heutige Agent-UX macht "LGTM (Looks Good To Me)" zum Weg des geringsten Widerstands, und die Geschwindigkeit, mit der Agenten plausibel wirkenden Code erzeugen, erhebt das Verifikationsproblem im Code-Review zu einer unmittelbaren Bedrohung
- @beh_zod: Die Reward-Funktion fürs Ausliefern ist kurzfristig, und die Zeit, die nötig ist, damit Menschen die angehäuften Schulden erkennen, liegt meist außerhalb ihrer Aufmerksamkeitsspanne
- @shipwithjay: Ein Symptom ist, wenn Engineering-Leadership auf kontrafaktische Fragen (Was müsste wahr sein, damit wir damit aufhören?) nicht antworten kann und schweigt
- @chadfowler: Er schreibt an einem Buch zu diesem Thema; der Kern sei, Strenge (Rigor) in Architektur und Evaluierungssysteme zurückzuverlagern; jetzt sei die Chance, Best Practices umzusetzen, die man bisher aus Zeit- und Kostengründen nicht praktiziert habe
Mitchell Hashimotos Antworten auf Fragen und Meinungen
- F: "Was sollte man stattdessen tun?"
- A: "Denken (nutzt AI, aber denkt nach)"
- F: Er halte es für wahrscheinlicher, dass die Ansicht "AI ist überbewertet" eher das psychotischere Symptom sei
- A: Jeder weltliche Trend ist überbewertet, aber das ist kein Grund, ihn pauschal zu ignorieren
- F: "Wenn ich wählen müsste zwischen dem Schutz dessen, was ich jetzt habe, und dem Sprung ins Risiko, würde ich Letzteres wählen"
- A: Das ist kein binärer Schalter
1 Kommentare
Hacker-News-Kommentare
AI-Architekturberatung scheint eine große Form von hochpreisiger Beratung zu werden, ähnlich wie Reaktion auf Sicherheitsvorfälle oder Datenwiederherstellungsexperten
Rein von AI geschriebene Systeme könnten auf eine Komplexität anwachsen, die Menschen nicht mehr verstehen, während die Quote erfolgreicher Fehlerbehebungen sinkt und zugleich der Token-Verbrauch pro Fehler steigt; am Ende könnten AI-Änderungen mehr Fehler erzeugen, als sie beheben, sodass das Ganze instabil wird
Dann wird es wohl ein spezielles Verfahren brauchen, um dieses Chaos wie in einem Reinraum aufzuräumen, die zentralen Entwurfsprinzipien herauszuarbeiten und es vermutlich weiterhin mit AI neu aufzubauen
Die Softwaretechnik der Zukunft wird sich wohl um Prinzipien drehen, mit denen sich so etwas von vornherein vermeiden lässt, aber wie schon die bisherige Softwaretechnik überraschend lange brauchte, um zu stabilen Designprinzipien zu kommen, dürfte es wohl 20 Jahre dauern, bis wir das gelernt haben
Das Krankenhaus hat ihm sogar Zugriff auf Server der IT-Abteilung gegeben, aber weil er Claude dort nicht anbinden konnte, wusste er nicht, wie er das deployen sollte, geriet völlig ins Schleudern und meldete sich bei mir; außerdem scheint die App interessante Daten-/Statusprobleme zu haben
Das erinnert mich an jemanden, dem Amazon unbegrenzt gratis Waren nach Hause liefert: theoretisch ein Leben im Überfluss, praktisch aber eher ein Zustand, in dem man unter etwas begraben wird statt zu gedeihen
Wir wissen ja alle, wie das ausgegangen ist
In Tausenden Zeilen Github Actions hatten sie Kubernetes halb nachgebaut, und es war unmöglich zu verstehen
Ich hasse das AI-Marketing, aber als Werkzeug, mit dem erfahrene Leute sich schneller bewegen können, finde ich es nützlich
Nur scheint AI bei Nicht-Experten für alles, was sie tun wollen, komplexe Lösungen zu erzeugen
Er scheint weniger die Nutzung von AI an sich zu meinen als das Auslagern von Entscheidungen und Denken an AI durch Firmen und Menschen
Mit AI Code zu schreiben ist weder AI-Psychose noch per se schlecht, aber einfach einen Prompt einzugeben und dann zu glauben, was AI sagt, kommt AI-Psychose schon nahe
Auf Twitter sehe ich oft Leute aus dem Finanzbereich und VCs, die Themen, über die sie nur ein wenig selbst nachdenken müssten, stattdessen durch ChatGPT-Screenshots als Ersatz für Denken und Schlussfolgern behandeln
Diese Tools taugen für Ideen, Denken und Beratung wenig und liefern nur Muster, die wie Pattern Matching aussehen; wenn man mit ihnen Ideen bespricht, kommt meist nur die allgemeinste Form von Unsinn heraus
Dagegen sind sie bei Aufgaben wie dem Schreiben von Code, wo Pattern Matching tatsächlich hilft, ziemlich nützlich, aber man sollte ihnen nicht das Denken und Entscheiden überlassen
Insgesamt ist die Obergrenze höher und die Untergrenze tiefer geworden, und die Beschreibung oben trifft es sehr gut
Dazu habe ich Folgendes geschrieben: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
Der letzte Text beschreibt eine komplexe Änderung, die ich dank AI gemacht habe, und zeigt auch, wie ich dabei vernünftig vorgehe
Sie erzeugt fast immer Text, der logisch korrekt wirkt, aber darin stecken manchmal falsche implizite Annahmen und Entscheidungen, die für den konkreten Anwendungsfall ungeeignet sind
Um eine wirklich richtige Lösung zu bauen, muss die Problemdefinition stimmen, und das kann schwieriger sein als die eigentliche Lösung zu bauen
Oder wenn sie es irgendwelchen Beratern überlassen
Ist „AI hat gesagt, das sei eine gute Idee“ wirklich schlimmer als „wir sind dem Branchentrend gefolgt“?
Wenn es Einzelpersonen betrifft, setzen Freunde und Familie dem oft noch Grenzen, indem sie seltsames Verhalten oder seltsame Aussagen ansprechen
Aber wenn ein Arbeitgeber auf Führungsebene damit anfängt, ist schwer vorstellbar, wie schlimm das werden kann
Dann steht man unter Druck mitzumachen oder hat Angst vor einer Entlassung, und die einzigen, die das Denken noch korrigieren könnten, sind widersprechende Kollegen, die dann vermutlich gehen oder gefeuert werden
Um den Job zu behalten, muss man sich anpassen
Weil der Agent die Entscheidungen trifft, bewegt sich die Arbeit mit Agentengeschwindigkeit, und oft trifft er Entscheidungen stillschweigend und liefert nur noch die Endausgabe mit „Das ist der Plan“
Um das wirklich zu prüfen, muss man das Problem tief verstehen, also wieder auf menschliche Geschwindigkeit zurückschalten; am Ende überfliegt man es dann nur und gibt es frei
Der Kern ist, bewusst und sorgfältig zu entscheiden, welche Entscheidungen man auslagert
Dafür muss man langsamer werden, und dann schrumpfen die übertriebenen 10x-Vorteile des Vibe Coding, aber dafür ist man stärker eingebunden und häuft weniger kognitive Schulden an
Langweilige Entscheidungen wie die Frage, wie man durch ein Array iteriert oder wie die Ausgabe eines Calls an die Eingabe des nächsten angepasst wird, kann man dem Agenten überlassen
Die echten Entscheidungen muss man vorher treffen und in die Spezifikation schreiben: Grenzen, APIs, zentrale Datenstrukturen, Systeme und Verantwortlichkeiten, Fehlerbehandlung sowie harte Vorgaben zu Sicherheit und Datenschutz müssen definiert sein
Bei Unklarheiten sollte man dem Agenten sagen, dass er stoppen soll, und ein guter Engineer kann so 2- bis 3-fache Geschwindigkeitsgewinne ohne Nebenwirkungen erzielen
Vielleicht macht genau das aus Softwaretechnik endlich eine echte Ingenieurdisziplin
Im Moment bauen Prompt-Schreiber komplette Firmeninfrastrukturen auf
Ich kenne persönlich jemanden, der die Datenbank seiner Firma auf eine neuere Postgres-Version migriert hat; am Ende hat es funktioniert, aber beim Zuhören, wie er den Vorgang erklärte, habe ich mit den Zähnen geknirscht
Es klang wie: „Ich habe Benzin über den Server gegossen und dabei geraucht, aber keine Sorge, ich habe im Keller einen Feuerlöscher gefunden. Das Manometer zeigt leer an, aber wenn man ihn schüttelt, hört man noch Flüssigkeit darin.“
Wenn er die Firma verlässt, wird man einen noch selbstbewussteren Prompt-Schreiber brauchen, um diese DB-Infrastruktur am Laufen zu halten
Dieser Beitrag weist darauf hin, dass man mit Leuten nicht diskutieren kann, die sagen: „Es ist okay, Bugs auszurollen, der Agent kann sie mit einer Geschwindigkeit und in einem Maßstab beheben, die Menschen nicht schaffen“
Und der Top-Kommentar ist dann direkt ein Beispiel für genau die Haltung: „Aber Agenten sind wahnsinnig schnell“
Vielleicht geht man davon aus, dass der Vorteil eines verdoppelten Codebestands und doppelter Features größer ist als der Schaden durch doppelt so viele Bugs
Zumindest für den Investor-Newsletter dieses Quartals sieht das gut aus
Vielleicht deployt man einfach immer mehr Müll, und die Feedback-Schleife sind dann die Kunden?
Die Antwort war: „Das ist Spieltheorie. Irgendwer wird es tun, also musst du es auch tun. So schlimm kann es nicht sein.“
Logik kann nützlich sein, aber das Ignorieren von Risiken ist etwas anderes
Davon auszugehen, dass am Ende etwas Gutes herauskommt, wenn man extrem schnell vorgeht und dabei alles kaputtschlägt, ist gefährlich
Dieser AI-Trend läuft nicht gut, und ich mag ihn nicht
Ich bin nicht sicher, dass die Seite mit der Psychose unbedingt „unsere Seite“ ist
Ich arbeite bei einem sehr großen Unternehmen, und bei uns war Modernisierung und Einführung neuer Technik schon immer eisig langsam
Aber seltsamerweise könnte genau das jetzt ein Wettbewerbsvorteil sein
Das Leben ahmt die Kunst nach
Früher habe ich darüber gescherzt, dass hier immer noch Faxgeräte existieren, aber ich hätte nie gedacht, dass ich einmal so dankbar dafür sein würde, in einer Kultur ohne diesen Hype zu arbeiten
Wenn ich HN lese, fühlt es sich an, als würde ich in Alice's Wonderland der Token-Maximalisten und AI-Psychotiker eintreten
Hier kenne ich buchstäblich niemanden, der gezwungen wird, auf diese Weise zu arbeiten
Wenn euch dieses Gefühl gefällt, könnte euch das neue CLI-Tool Burn, Baby, Burn (those tokens) gefallen: https://github.com/dtnewman/burn-baby-burn/tree/main
Show HN dazu: https://news.ycombinator.com/item?id=48151287
Das erinnert mich an Rich Hickeys Simple Made Easy und seinen Ansatz beim Bau von Clojure
Schon bevor LLMs ganze Programme erzeugten, ermöglichten komplexe Frameworks Entwicklern, sehr schnell erste Versionen ihrer Programme zu bauen, allerdings zum Preis, dass sie schwer zu verstehen und deshalb auch schwer zu debuggen und zu verändern waren
Manche setzen darauf, dass AI, egal wie verworren und komplex die Programme sind, immer klug genug sein wird, sie zu debuggen, zu warten und zu verändern
Ich bin da nicht so sicher
AI-Psychose ist keine Position gegen die Nutzung von AI
Ich benutze AI-Coding-Tools jeden Tag, aber AI-Tools haben kein Konzept von Zukunft
Für stabile Systeme waren wir immer auf das eigennützige Denken von Engineers angewiesen, die sich sagen: „Wenn das in Produktion kaputtgeht, kann ich es nicht reparieren, und dann werde ich um 3 Uhr morgens angerufen“
Dazu kam die ganz normale Faulheit, auf CPAN die perfekte Bibliothek zu finden, um die Arbeit nicht selbst machen zu müssen, und manchmal dauerte die Suche nach einer Bibliothek länger, als sie selbst zu schreiben
Ich habe mit AI-Tools Tausende Zeilen Code geschrieben und in Produktion gebracht, und das fühlte sich meist natürlich an, weil ich Menschen seit 2017 sage, sie sollen Code schreiben statt jede Zeile selbst zu tippen, und weil ich Fallen in Tests einbaue, die schlechten Code abfangen
Aber eine Sache tut AI nicht: weniger Code schreiben: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Bug-Reports nehmen auch ab, wenn Menschen den Glauben verlieren, dass sie behoben werden
Denn einen Bug zu melden ist oft mit einem erheblichen Zeitaufwand verbunden
Das passiert ziemlich häufig, wenn das Vertrauen in eine Gruppe oder ein Unternehmen zusammenbricht
Dadurch werden sie eher falsch gemeldet, und Teile des Inhalts könnten unzutreffend sein
Man wird also aus mehreren Richtungen angegriffen
Von wirklich feindseligen Taktiken sprechen wir noch gar nicht
Wenn man keine Moral hätte, was wäre effektiver, als mit Agenten einen Konkurrenten mit gefälschten Bug-Reports zu fluten?
Problem gelöst
Vieles von dem, was Mitchell beobachtet hat, vielleicht sogar alles davon, kann auch ohne AI problemlos passieren
Ich habe das Gefühl, in einer wirklich seltsamen Lage zu sein
Ich mag die Veränderungen, die AI in Erfahrung und Praxis des Programmierens bringt, so wenig, dass ich am liebsten alles andere tun würde, nur nicht am Computer arbeiten, und gleichzeitig denke ich auch, dass diese Tools sehr mächtig sind und immer besser werden
Mitchells Punkt ist berechtigt. Solche Tools können morsche Fundamente einziehen, die man erst bemerkt, wenn die ganze Struktur zusammenbricht
Ich möchte nicht in einer Position der Verantwortung sitzen und dann feststellen, dass ich die Codebasis nicht mehr so tief verstehe wie früher
Andererseits bauen Menschen schon lange subtile, aber fatale Bugs in Code ein
Daher fühlt sich vieles noch wie eine offene empirische Frage an
Werden wir viele Systeme sehen, die auf neue Weise katastrophal scheitern? Teilweise vielleicht
Gleichzeitig lernen wir vielleicht, dass wir uns stärker in Richtung Spezifikation und Verifikation bewegen müssen? Ich weiß es nicht
Wie auch immer: Diese Art, Systeme zu bauen, wirkt unvermeidlich, selbst wenn es unterwegs Zusammenstöße gibt
Auch im Anti-AI-Lager scheint es eine eigene reaktionäre Psychose zu geben
Ich will mit AI eigentlich nichts zu tun haben, aber meine Erfahrungen mit diesen Tools kann ich auch nicht leugnen
Ich wünschte, es gäbe mehr Raum für solche nüchternen, aber negativen Diskussionen über AI
Das ist auch ein Grund, warum Mitchell ein guter Entwickler ist