GDD – das Zeitalter der „Gaslight-driven Development“

• In letzter Zeit wiederholen Computernutzer unabhängig von ihrem eigenen Willen unzählige sinnlose Aufgaben und folgen dabei den Anweisungen des Computers
• LLMs beeinflussen die Art, wie Entwickler APIs entwerfen, und es gibt bereits Prognosen, dass Entwickler von KI vorgeschlagene Funktionen übernehmen und bald der Großteil des Codes von KI geschrieben wird
• Ein Beispiel: Soundslice hat eine Funktion tatsächlich hinzugefügt, die ChatGPT fälschlich beschrieben hatte
• Das liegt daran, dass LLMs zahlreiche APIs analysieren und intuitive Designs vorschlagen, die Entwicklern wahrscheinlich als Erstes einfallen würden
• Für neue Ideen oder ungewöhnliche Ansätze sind LLMs ungeeignet, aber in den meisten Fällen kann es effektiv sein, dem naheliegendsten Design zu folgen
• Wir treten nun in eine Ära ein, in der KI nicht nur die Nutzung von Tools, sondern auch deren Design bestimmt

---

Gaslight-driven development

Sinnlose Routineaufgaben im Alltag

• Wer in den letzten zehn Jahren einen Computer benutzt hat, musste immer wieder im Kern unnötige Aufgaben erledigen, etwa Registrierung, E-Mail-Bestätigung, Cookie-Einwilligung oder CAPTCHA-Eingabe
• Auch wenn Nutzer das gar nicht wollten, mussten sie tun, was der Computer verlangte
• Durch diese Wiederholungen haben wir uns bereits bis zu einem gewissen Grad an ein Leben gewöhnt, in dem wir den Anweisungen der Maschine folgen

Wie LLMs die Entwicklungsrealität verändern

• In letzter Zeit äußern LLMs zunehmend Vorstellungen davon, wie APIs oder Interfaces aussehen sollten
  • Es gibt sogar Vorhersagen, dass bis September 2025 90 % des gesamten Codes von KI geschrieben werden
• Wie im Fall von Soundslice wurde, weil ChatGPT eine nicht existierende Funktion für vorhanden hielt und deshalb immer wieder Kundenanfragen dazu eingingen, die Funktion schließlich tatsächlich eingebaut
• Auch bei Instant gab es einen ähnlichen Fall: Bisher wurden Insert und Update beide mit tx.update behandelt, doch weil LLMs ständig Code mit tx.create erzeugten, wurde schließlich die Methode tx.create hinzugefügt

Was dieses Phänomen bedeutet

• Es ist schwer zu beurteilen, ob diese Veränderung positiv oder negativ ist
• Einerseits haben LLMs unzählige APIs gelernt und schlagen deshalb aus Entwicklersicht den ‚intuitivsten‘ Weg vor
• Es ist auch eine neue Methode, APIs aus der Perspektive eines Einsteigers (newbie’s POV) zu testen
  • Früher schlugen Entwickler bei Fehlern selbst in der Dokumentation nach und korrigierten sie; heute liefert das LLM fortlaufend fehlerhafte Nutzungsbeispiele, sodass auch Entwickler Probleme schneller erkennen können

Grenzen und offene Fragen

• Für innovative Arbeit ist dieser Ansatz ungeeignet
  • Mit ungewohnten Mustern oder völlig neuen Konzepten können LLMs nicht gut umgehen
• Letztlich könnte in Bereichen wie APIs gerade das ‚Gewöhnliche‘ die beste Lösung sein
  • In den meisten Situationen ist es vorteilhafter, statt kompliziert zu entwerfen, eine Form zu wählen, die sowohl KI als auch Entwickler intuitiv verstehen können

Fazit: der Beginn einer neuen Ära

• KI beschränkt sich nicht mehr nur darauf, gegebene Tools zu verwenden, sondern beginnt Vorstellungen davon zu entwickeln, wie die Tools selbst entworfen sein sollten
• Und diese Vorstellungen „gaslighten“ Entwickler und Organisationen oft so, als wäre es schon immer so gewesen
• Künftig dürfte Entwicklung, die sich an den Erwartungen und dem Verständnis von KI orientiert, zunehmend zum natürlichen Standard werden

[ffdd270]

Manchmal habe ich das Gefühl, dass in das große Konzept der Pfadabhängigkeit ein mächtiger Nagel namens LLM-Abhängigkeit eingeschlagen wird. Dass es sich von „weil wir es schon immer benutzt haben“ zu „weil es dem LLM gefällt“ verschiebt — wie wird das am Ende wohl ausgehen ...

[kandk]

Das benutzen wir schon seit früher, und das LLM hat darauf trainiert..

[jujumilk3]

"Sie können den Computer jetzt ausschalten."

[rosen]

Eine perfekte Metapher!!

[GN⁺]

Hacker-News-Kommentare

• In einer Situation, in der ein LLM nicht existierende API-Endpunkte empfiehlt, habe ich mir vorgestellt, man könnte diese Endpunkte einfach trotzdem implementieren und absichtlich den Statuscode 421: Misdirected Request zurückgeben; alternativ gäbe es auch den echten 501: Not Implemented. Falls 501 den Ton nicht ganz trifft, schlage ich einen neuen Statuscode vor: 513: Your Coding Assistant Is Wrong
  Siehe Wikipedia zu HTTP-Statuscodes
  • Die Idee 513: Your Coding Assistant Is Wrong fand ich urkomisch, das hat mir den Tag versüßt; andererseits würde ich auch HTTP 407 Hallucination empfehlen, im Sinne von: Der Server versteht die Anfrage, hält sie aber für nicht mit der Realität vereinbar
  • Diese Geschichte erinnerte mich auch an das unterhaltsame Warnschild, das darauf hinweist, dass das GPS falsch liegt
    Beispiel „GPS is wrong“
  • Ich stimme für die Einführung von Statuscode 513; es gibt schließlich schon 418, also sehe ich keinen Grund, warum 513 nicht gehen sollte
  • Wenn man schon so einen Scherz machen will, sollte man bitte eine 418-Antwort verwenden; ich würde mich freuen, wenn sie weiter verbreitet würde
• Es ist zwar interessant, in Echtzeit zu sehen, dass mehrere Nutzer dieselbe Seite ansehen, aber wegen der ständig ein- und ausblendenden Nutzeranzeigen war das Lesen des Artikels extrem anstrengend
  • Ich habe ein Bookmarklet in der Lesezeichenleiste, das all diese fixierten bzw. sticky Elemente auf einmal entfernt; damit verschwinden alle festen/sticky Elemente oben auf der Seite und das Scrollen wird ebenfalls wiederhergestellt, deshalb nutze ich es oft
    (JavaScript-Code bereitgestellt)
  • Mich hat das ähnlich gestört, daher: Rechtsklick, „Inspect“, die Entwicklertools öffnen und den folgenden Code in die Konsole einfügen, dann verschwindet der entsprechende Bereich mit den Nutzeranzeigen

    document.getElementById("presence")?.remove();
    

    Falls man sich fragt, warum das Gehirn auf solche Bewegungen überhaupt so empfindlich reagiert: Das hängt mit dem Instinkt zur Räubererkennung zusammen
    Wissenschaftlicher Artikel, siehe auch Wikipedia zu Salienz in den Neurowissenschaften
  • Das erinnerte mich an das Spiel Chess Royale; dort hatte ich mit Avataren und Flaggen eine ähnliche Erfahrung. Es war wirklich ein sehr gutes Spiel, aber Ubisoft hat den Dienst beendet, wie sie es öfter tun; schade um so ein Meisterwerk
    Chess-Royale-Screenshot
  • War das nicht früher die Seite mit lauter Cursorn im Hintergrund? Ab diesem Punkt wirkt das Designkonzept wie ein absichtlich ablenkender Witz
  • Ich habe schon versucht, mit Tools wie uBlock Seitenelemente zu entfernen, und bin dann in eine Situation geraten, die sich wie ein schnelles Whac-A-Mole-Spiel anfühlte
• Bei Instant übernimmt die Funktion tx.update sowohl das Einfügen als auch das Aktualisieren von Entitäten, aber das LLM hat ständig Code mit tx.create geschrieben, also habe ich am Ende auch noch eine Funktion tx.create gebaut. Ich frage mich, ob nicht nur LLMs, sondern auch echte Entwickler bei solchen verwirrenden Stellen unnötig viel Zeit verschwenden
  • Wenn es tx.create ursprünglich ohnehin nicht gab, würde doch eigentlich auch niemand Zeit daran verschwenden, oder?
• Wenn eine Funktion sowohl Einfügen als auch Aktualisieren unterstützt, sollte sie meiner Meinung nach eher put als update heißen; update kann missverständlich sein
  • In so einem Fall scheint upsert passender zu sein
  • Der Name put deutet eher darauf hin, dass bestehender Inhalt überschrieben wird, während upsert ausdrücklich Einfügen/Aktualisieren bedeutet
• Wenn ein LLM falschen Text ausgibt, fühlt es sich an, als würde das Universum eher den Hitzetod erreichen, bevor ich auch nur eine Zeile Code ändere; die Vorstellung, aus so einem absurden Grund den Code anpassen zu müssen, ist für mich zugleich komisch und inakzeptabel
• Ich stimme der These des Posts nicht zu; schon der Ansatz, dass wir uns wirklich dem fügen sollten, was der Computer will, erscheint mir fragwürdig
  Ich denke auch, dass Nutzer E-Mail-Bestätigung oder Registrierung nicht deshalb machen, weil der Computer es verlangt, sondern weil Menschen sich so beim Design entschieden haben
  • Schon das als „These“ zu bezeichnen, ist meiner Meinung nach eine großzügige Auslegung; ich habe die Seite an der Stelle direkt geschlossen
• Ich hatte vor Kurzem mit meinem Team ein interessantes Gespräch über künftige Coding-Prinzipien
  Künftig wird es wohl weniger darum gehen, Code-Lesbarkeit, SOLID-Prinzipien oder Komplexität zu optimieren, sondern eher darum, wie gut meine agentische IDE den Code-Kontext indexieren kann und wie gut das Modell auf dieser Basis Code generiert
  Da sich Code künftig extrem schnell ändern wird, könnte Wartbarkeit paradoxerweise zum wichtigsten Messwert werden, und wir steuern vielleicht auf eine Welt zu, in der die Übereinstimmung zwischen Prompt und Code sowie die Nutzbarkeit von zufällig gut passenden Codepfaden besonders viel Aufmerksamkeit bekommen
• Wenn jemand dauerhaft mit großem Selbstvertrauen neue — in Wahrheit erfundene — Entwicklungstipps über mein Produkt verbreiten würde, frage ich mich, ob ein Unternehmen daraufhin diese imaginären Features einfach einbauen und dann einen empörten Blogpost darüber schreiben würde
  • Ich frage mich, ob andere mich auch einfach verstehen würden, wenn ich mich selbst wie ein LLM verhalten, selbstbewusst auf Unsinn bestehen und dabei ständig seltsame Fehler machen würde
  • Eigentlich frage ich mich rückblickend, ob Mr. Martin, der Autor von „Clean Code“, nicht genau so ein Typ ist
  • Wenn diese Person 90 % meiner Kunden beeinflussen würde, dann würde ich das imaginäre Feature vielleicht tatsächlich einführen
  • Die meisten Unternehmen würden wahrscheinlich selbstbewusst behaupten, dass dieses unnötige Feature unbedingt gebraucht wird
• Irgendwie fühlt es sich auch wie der Beginn einer wunderbaren Freundschaft mit LLMs an; als fractional CTO ist eines der frustrierendsten Dinge für mich, dass bei verschiedenen Kunden schon kleine Naming-Conventions wie Umgebungsnamen komplett unterschiedlich sind
  In AWS gibt es zum Beispiel dev und prod, bei Expo dagegen test und production, und wenn man zwischen mehreren Projekten wechselt, kostet das mehr Denkarbeit, als man erwarten würde
  Vermutlich erleben LLMs genau dieses Problem in viel größerem Maßstab
  Wenn wir die Synapsen, die bisher für solche unnötig verwirrenden API-Namen und Verhaltensweisen draufgehen, stattdessen für wirklich Sinnvolles nutzen könnten, wäre das ideal
  • In der Informatik gibt es den Witz, dass es drei schwere Probleme gibt — Cache-Invalidierung, Namen vergeben und Off-by-one-Fehler
    Selbst wenn ein LLM noch so klug Namen vergibt, bleibt das Problem bestehen, weil es auf einem incoherent stochastic process basiert
    Und ich würde gern fragen, ob jemals ernsthaft hinterfragt wurde, warum Benennungen für Umgebungen nicht vereinheitlicht sind
    Als früherer CTO halte ich so etwas für ein Signal, dass es in der Organisation Kommunikationsprobleme oder fehlende Standards gibt, die verbessert werden sollten
    Gerade weil man solche Dinge relativ einfach beheben und damit Kultur und Bewusstsein im Team verbessern kann, sollte man sie nicht an ein LLM delegieren, sondern sich direkter darum kümmern
• Als verwandter Link
  Frühere Hacker-News-Diskussion ansehen

[dkmin]

Viraler Erfolg von Soundslice