Die Gefahr, die Tugend der Faulheit zu verlieren

 (bcantrill.dtrace.org)
2 Punkte von GN⁺ 17 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Faulheit in der Programmierung wird nicht als bloße Trägheit verstanden, sondern als intellektuelle Tugend, die nach Abstraktion und Einfachheit strebt
  • Wahre Faulheit ist der Prozess, ein Problem gründlich zu durchdenken, um künftig Zeit zu sparen, und kommt damit auch späteren Entwicklergenerationen zugute
  • Moderne High-Level-Abstraktionen und die „Brogrammer“-Kultur lassen diese Tugend verschwinden und ersetzen sie durch falschen Fleiß
  • LLMs treiben diese Tendenz auf die Spitze und wirken als Werkzeug der Überproduktion, das dazu verleitet, die Menge an Code mit Wert zu verwechseln
  • Die aus der begrenzten menschlichen Zeit entstehende tugendhafte Faulheit sollte bewahrt werden, während LLMs für einfache und nachhaltige Systementwürfe eingesetzt werden sollten

Faulheit als Tugend des Programmierers und die Gefahr ihres Verlusts

  • Larry Wall betont, dass von den drei Tugenden des Programmierers aus Programming Perl — Faulheit (laziness), Ungeduld (impatience) und Hochmut (hubris) — gerade die Faulheit die tiefste Bedeutung hat
    • Faulheit ist keine bloße Selbstironie, sondern ein Konzept, das die Notwendigkeit und Ästhetik von Abstraktion in sich trägt
    • Sie ist die Triebkraft dafür, Systeme so einfach wie möglich zu machen und mit starken Abstraktionen mehr mit weniger Aufwand zu erreichen
  • Wahre Faulheit ist, wie bei „hammock-driven development“, ein Prozess, der nach außen wie Ruhe aussieht, tatsächlich aber intellektuelle Arbeit leistet: Probleme gründlich zu durchdenken, um in Zukunft Zeit zu sparen
    • Wenn die richtige Abstraktion geschaffen ist, nützt sie nicht nur dem Entwickler selbst, sondern auch künftigen Entwicklergenerationen
    • Diese Form von Faulheit macht es leichter, Software zu schreiben und Systeme zu gestalten

  • Ein Zeitalter, in dem die Tugend der Faulheit verschwindet

    • In den vergangenen 20 Jahren hat sich die Softwareentwicklung stark verbreitert, und es gibt immer mehr Menschen, die sich nicht selbst als Programmierer verstehen
      • Für sie hat die Tugend der Faulheit ihre ursprüngliche Bedeutung verloren
    • Die Produktivitätsexplosion durch moderne High-Level-Abstraktionen fördert paradoxerweise falschen Fleiß (false industriousness)
      • Das zeigt sich in „Brogrammer“-Kultur und „hustle porn“, die die ironische Faulheit durch endloses Produzieren von Code ersetzen

  • Das neue Übermaß durch LLMs

    • Das Aufkommen von LLMs (Large Language Models) hat diese Tendenz noch verstärkt
      • LLMs sind Werkzeuge, die menschliche Schaffensimpulse verstärken, und wirken wie Steroide für die „Brogrammer“-Kultur
    • Als Beispiel erwähnt Garry Tan, er habe mit LLMs an einem Tag 37.000 Zeilen Code geschrieben
      • Zum Vergleich: Die gesamte DTrace-Codebasis umfasst etwa 60.000 Zeilen
    • Dieser Ansatz ist jedoch ein Laster, dem die Tugend der Faulheit fehlt, und offenbart den Irrtum, den Wert von Software nach der Menge an Code zu bemessen

  • Die Grenzen von LLMs und der Wert menschlicher Faulheit

    • Weil bei LLMs die Arbeitskosten bei null liegen, erzeugen sie beliebig komplexe Systeme, ohne künftige Zeitersparnis mitzudenken
      • Dadurch werden Systeme größer und komplizierter, erfüllen zwar eitelkeitsgetriebene Metriken, schaden aber der wesentlichen Qualität
    • Menschliche Faulheit entsteht aus der Beschränkung endlicher Zeit; genau diese zwingt zu klaren Abstraktionen und vereinfachtem Systemdesign
      • Die beste Ingenieurskunst entsteht immer unter Beschränkungen, und die Begrenztheit menschlicher Zeit begrenzt die kognitive Last und fördert die Suche nach Einfachheit
      • LLMs fehlt ein solcher Zwang, deshalb haben sie keinen inneren Anreiz, von sich aus nach Einfachheit zu streben

  • Wie LLMs als Werkzeug genutzt werden sollten

    • LLMs können weiterhin eine wichtige Rolle als leistungsfähige Werkzeuge der Softwareentwicklung spielen
      • Laut den LLM-Nutzungsrichtlinien von Oxide ist ein LLM nur ein Werkzeug und kann menschliche Tugenden nicht ersetzen
    • LLMs können eingesetzt werden, um Probleme unproduktiver Faulheit wie technische Schulden (technical debt) zu lösen oder die technische Strenge zu erhöhen
    • Ihr Einsatz sollte jedoch immer darauf ausgerichtet sein, „tugendhafte Faulheit“ zu verwirklichen
      • Das heißt: einfachere und stärkere Systeme zu schaffen und Ergebnisse zu hinterlassen, die künftigen Entwicklergenerationen helfen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 17 일 전
Hacker-News-Kommentare

  • Sogar in meinem Bereich, Computational Fluid Dynamics, gibt es Leute, die wie beim Prahlen mit LOC damit angeben, besonders viele Tests zu haben.
    Wenn man genauer hinschaut, sind diese Tests aber nicht besonders streng und viel schlampiger als die Tests, die ich manuell erstelle.
    Eine Million einfacher Tests bedeutet gar nichts, wenn sie die entscheidenden Teile des Codes nicht abdecken.

    • Mir ist klar geworden, dass ich die Tests selbst schreiben muss.
      Und um zu verhindern, dass Claude Tests einfach „repariert“, wenn der Code nicht funktioniert, prüfe ich Teständerungen immer mit git diff.
      Wenn man Tests streng verwaltet, implementiert Claude sogar schwierige Algorithmen aus Papers gut und spart Zeit, aber es braucht viel Betreuung.
    • Das wirkt wie eine Art Reward Hacking.
      Das Modell missbraucht die Belohnungsfunktion namens Test im Grunde dazu, den „Sieg zu erklären“.
      Ich vermute, dass so ein Muster vielleicht in den RL-Pretraining-Daten enthalten ist.
    • Es ist wirklich schwer, ein LLM dazu zu bringen, Tests zu erzeugen, die nicht dumm sind.
      Es entstehen Hunderte nutzlose Tests wie assert(1==1).
      Deshalb muss man separat eine Verbotsliste pflegen mit Dingen, die es nicht als Test erzeugen soll.

  • Ich habe 30 Jahre lang selbst programmiert und bin inzwischen vollständig auf AI Coding umgestiegen, deshalb fühlt es sich seltsam an, wenn Leute LOC oder Features aus AI-generiertem Code als ihre eigene Leistung darstellen.
    Damit zu prahlen, man habe an einem Tag Hunderttausende Zeilen „geschrieben“, wirkt am Ende so, als hätte man nur ein paar Prompt-Zeilen eingetippt.

    • Das ist wohl ein Spektrum.
      Änderungen, die man selbst direkt freigegeben hat, kann man sich bis zu einem gewissen Grad zurechnen, aber bei einer vollständig vibe-coded App ist man kaum beteiligt.
      Ich liege irgendwo in der Mitte — ich reviewe nicht den gesamten von der AI erzeugten Code, aber ich gebe Architektur und Richtung des Refactorings vor.
      Das Ergebnis ähnelt dem, was ich selbst gebaut hätte, ist aber viel schneller fertig.
    • Bei Meta gibt es inzwischen wohl ein Leaderboard für AI-Nutzung, das zeigt, wer die meisten Claude-Tokens verbraucht.
      Dass Meta Claude nutzt, dürfte Anthropic ziemlich freuen.
    • Viele LOC können in Wahrheit auch ein Signal für ein schlechtes Ergebnis sein.
    • Manche sagen, LoC sei als Qualitätsmetrik bedeutungslos.
      Wir seien jetzt in einer Zeit, in der Implementierung, Tests und Wartung komplett von Agenten übernommen werden.
      LoC sei nur noch eine Fähigkeitsmetrik, die zeigt, wie stark ein Agent Anforderungen durchdrücken kann.
      Kritisches menschliches Review kann trotzdem weiter als Feedback eingespeist werden.

  • Die Aussage „Man sollte mehr Abstraktion verwenden“ war früher vielleicht richtig, aber inzwischen empfinde ich eher das Gegenteil.
    Ich mag die Philosophie WET (Write Everything Twice) — erst zweimal schreiben und erst beim dritten Mal über Abstraktion nachdenken.

    • Das wird oft auch Rule of Three genannt.
      Siehe den Wiki-Artikel.
    • Die wahre Schönheit von Software liegt in der richtigen Abstraktion.
      Innovationen wie Betriebssysteme, RDBMS oder Cloud-Orchestrierung sind Beispiele dafür.
      Aber der meiste Code ist einfache Business-Logik, und dort steht Abstraktion oft eher im Weg.
      Deshalb habe ich den Grundsatz: Baue keine Plattform, bevor nicht drei reale Use Cases das belegen.
    • Etwas mehr als zweimal zu schreiben ist eine niedrige Hürde und widerspricht dem Perl-Zitat meiner Meinung nach auch nicht.
    • Das zweite Schreiben ist eine Chance, Dinge zu verbessern, nachdem man das Problem besser verstanden hat.
      Wenn man beim dritten Mal eine Abstraktion versucht, sollte man sich vor dem Second-System Effect hüten — zu viel Selbstvertrauen führt zu überkomplexen Systemen.
    • Die Explosion an Abstraktionsschichten seit Programming Perl von 1991 ist erstaunlich.

  • Jemand teilte das berühmte Zitat des deutschen Generals Kurt von Hammerstein-Equord.
    Kluge und fleißige Menschen taugen für den Generalstab, dumme und faule für Routinetätigkeiten, kluge und faule für Führungsaufgaben,
    und dumme und fleißige Menschen sind gefährlich, daher dürfe man ihnen nie Verantwortung übertragen.

    • Darauf kam als scherzhafte Reaktion: „Wo sind Leute wie ich aus der 90-%-faulen Kategorie?“

  • Damit anzugeben, mit einem LLM 200.000 LOC geschrieben zu haben, ist töricht, aber sie deshalb auszulachen und zu sagen „dieser Code ist dumm“, ist meiner Meinung nach genauso falsch.
    Entscheidend ist am Ende nicht der Code-Output, sondern die Wertschöpfung.
    Ob Garry Tan tatsächlich etwas Wertvolles gebaut hat, weiß ich nicht.

    • Es wäre fatal zu glauben, Codequalität sei unwichtig.
      Fälle wie der Horizon-IT-Skandal zeigen, dass schlechter Code realen Schaden anrichten kann.
      Laut einer Analyse des Projekts durch den polnischen Entwickler Gregorein enthielt die App ein Test-Harness, eine Hello-World-App und doppelte Logo-Dateien sowie allerlei Chaos.
      Es gibt die Sorge, dass solcher Code die Angriffsfläche für Sicherheitsprobleme vergrößert.
    • Garry ist nicht einfach nur Entwickler, sondern CEO von YC.
      Es ging ihm nicht um LOC, sondern um einen Post zur AI-Promotion.
    • Die echte Kennzahl ist Wert – Kosten.
      AI senkt Entwicklungs- und Betriebskosten, erhöht aber versteckte Kosten wie Sicherheits- und Rechtsrisiken.
      AI-Evangelisten betonen nur Ersteres.
    • Ich habe keine Zeit, 200.000 LOC zu lesen, um zu beweisen, dass es eine schlechte Idee ist.
      Das muss der vibe coder selbst beweisen.
      Mit LOC anzugeben bleibt trotzdem töricht.
    • Schon der Ausdruck „Wertschöpfung“ kann gefährlich sein.
      Wie bei Wachstum auf Basis fossiler Brennstoffe kann kurzfristiger Wert langfristige Kosten verursachen.

  • In den letzten paar PRs habe ich oft gesehen, dass LLMs falsche Lösungen liefern.
    Zum Beispiel implementieren sie einen Parser selbst, obwohl bereits ein JSON-Parser vorhanden ist.
    Ein Mensch hätte gespürt: „Das ist viel zu ineffizient“, aber LLMs haben keine Faulheit und arbeiten deshalb eifrig in die falsche Richtung.

    • Außerdem erkennen sie doppelte Funktionen innerhalb eines Projekts überhaupt nicht.
      Dass es drei Funktionen wie formatTimestamp gibt, ließe sich mit einem einzigen grep feststellen, wird aber ignoriert.

  • Ich kann der Aussage zustimmen, dass LLMs nicht faul sind.
    Ich weiß nur nicht, ob das ein dauerhaftes Problem ist oder ob es mit dem nächsten Modell-Upgrade oder in der CI/CD-Pipeline gelöst wird.
    Ich gebe nach Abschluss einer Funktion oft den Prompt, nach Bugs oder Refactoring-Potenzial zu suchen,
    und später könnte es vielleicht einen Schritt geben, der automatisch die letzten Commits analysiert und Vereinfachungen vorschlägt.

    • Wenn man aber sagt „Finde X“, dann findet ein LLM immer irgendetwas.
      Deshalb ist es schwierig, Abbruchbedingungen zu definieren.
    • Am Ende liegt das Problem nicht im Wesen des Tools, sondern in den Grenzen seiner Nutzung.
      Wenn man nur sagt „Füge etwas hinzu“, fügt es immer etwas hinzu, und wenn man sagt „Reduziere“, senkt es die LOC.
      Wenn man große Aufgaben übergibt und das Review auslässt, sammelt sich leicht Code Slop an.

  • LLMs neigen dazu, statt eines einfachen Programms mit Konsolenausgabe lieber ein vollständiges SPA zu bauen.
    Außerdem gelingt es ihnen nicht, eine spec.md-Datei knapp zu halten.
    Wenn man sagt „Aktualisiere dieses Dokument und vereinfache den Kontext drumherum“, machen sie es eher noch komplizierter.
    Am Ende muss ein Mensch selbst zusammenfassen, damit ein lesbares Dokument entsteht.
    LLM-Ausgaben zu bearbeiten ist schmerzhaft, und wenn man Dinge selbst schreibt, bleibt auch das Verständnis erhalten.

  • Es ist Zeit, LLMs und vibe codern die klassischen Lehren der Softwareentwicklung beizubringen.
    Wie die Geschichte Negative 2000 Lines of Code zeigt, ist weniger Code oft der eigentliche Fortschritt.

  • Man denkt sich: Wie schön wäre es, unter so einer Führung zu arbeiten.
    Mit einem wirklich verständigen Leader zu arbeiten, ist ein großes Glück.