HaraldvonBlauzahn, haraldvonblauzahn@feddit.org

You have to imagine Alice, Bob, and Carlos 25 years later, working on production code that was created like this.

XKCD on this: https://m.xkcd.com/2730/

By the way, I am currently working on a 20 year old code base that was in production use all the years and was continuously adapted. At least the people who wrote this were (more or less) knowing what they were doing. I guess I should ask for a pay rise…

The thing is… to test such code, you often need to modify it first.

You see the problem?

Ich glaube nicht, dass das von Musk ist. Die Idee ist älter als Musk selber.

Auch die Kritik an überbordender Konplexität in Software ist nicht neu. Z.B. hat Niklaus Wirth nicht nur schon diese Kritik geäußert, sondern mit dem Projekt Oberon schon seit 1985 gezeigt, dass man Software wie ein ganzes Betriebssystem mit weniger Komplexität schreiben kann und auch schneller fertig wird. Ähnliche Gedanken hat un jüngerer Zeit Rich Hickey entwickelt , von dem es eine Reihe Brillante Youtube-Videos gibt, und der die extrem elegante Sprache Clojure entwickelt hat.

Das ist ja mal wieder Bullshit. Es gab neue Technologien wie Eisenbahn, elektrisches Licht, Telefon und Waschmaschine, die klar erkennbare und auch messbare Vorteile hatten und sich schnell durchsetzten. Dann gab es erfolglose Technologien.

Und dann gab es Hype und Bullshit, die wirklichen Schaden angerichtet haben, wie der Gebrauch von Radium in Dingen wie Zahnpasta nach der Entdeckung der Radioaktivität durch Marie Curie.

GenAI gehört nicht zu den Techniken mit klar erkennbaren Vorteilen. Und trotzdem werden da Geldmengen rein gesteckt, die für die Stabilität der Ökonomie bedrohlich sind.

Deine persönliche Anekdote ist keine Evidenz, weil die Nutzung von KI/GenAI es offensichtlich auch erschwert, den dadurch entstandenen Zeitaufwand realistisch einzuschätzen.

Da gibt es die METR Studie mit erfahrenen Open Source Entwicklern:

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower.

Der Knackpunkt ist, dass die Leute an ihnen gut bekannten Projekten gearbeitet haben unf auch Erfahrung mit KI Nutzung hatten.

Die hatten definierte Tasks und wurden vor dem Beginn der Arbeit gefragt, wie sie denn Zeitaufwand schätzen. Dann wurde zufällig festgelegt, ob sie für diese Task KI nutzen oder nicht. Nach Beendigung der Task wurden sie noch mal gefragt, ob sie glauben dass KI ihnen geholfen hat.

Ergebnis war, dass die Leute geglaubt haben, dass es mit KI schneller geht, dass sie aber objektiv in der Statistik deutlich(!) länger gebraucht haben, als sie geschätzt haben, dass die Aufgaben ohne KI statistisch schneller gingen, und dass sie trotzdem hinterher immer noch glaubten, dass es mit KI schneller sei.

So eine Wahrnehnungsverzerrung macht subjektive Anekdoten wertlos.

Und aus genau solchen Gründen arbeitet man in der Medizin oft mit Doppelblindversuchen und so weiter.

Ich beschreibe hier lediglich meine eigenen Erfahrungen - ich halte nicht viel davon Dinge blind zu hassen ohne sich das naeher angeschaut zu haben.

Da gibt es bei mir zwei Aspekte:

1. Ich halte meinerseits ganz sachlich nichts davon, so quasi das Wohlergehen der gesamten Wirtschaft auf eine angebliche Wundertechnologie zu wetten, bei der nicht ansatzweise belegt werden kann, dass die hält, was das Marketing verspricht. Extraordinary claims require extraordinary evidence.

Beim Ausgangspost ging es darum, dass ein genaues Verständnis des Codes in der Softwareentwicklung wesentlich ist, und dass der Zeitanteil für die Codeeingabe so gering ist, dass selbst eine völlig automatisierte Eingabe Softwareentwicklung gar nicht nennenswert beschleuniglen kann. Gibt es irgendwelche Evidenz, dass das nicht so ist?

1. Ich hasse es allerdings in der Tat, ständig Bullshit erzählt zu bekommen und damit regelrecht vollgespammt zu werden. Da finde ich es auch angemessen, mal deutlich zu werden.

Echtes TTD, so wie ich es gelernt habe, erfordert, dass du immer nur die kleinstmögliche Änderung an den Unit-Tests machst. Der erste Test prüft z.B. nur, ob es eine Funktion gibt. Dann schreibst du den Code, der genau diese Anforderung umsetzt, also eine Methode, die nichts macht.

Das ist genauso, wie Robert “Bob” Martin das beschreibt, und worauf sich die Kritik von John Ousterhout ganz explizit bezieht.

Es gibt dann noch eine Beschreibung von Martin Fowler, dass in einem dritten Schritt im Anschluss daran, dass man den Test mit dem neuen Feature zum funktionieren gebracht hat, man Refactoring macht, bei dem man die Struktur des Codes wieder verbessert und etwas aufräumt.

Das ist natürlich besser als nichts! Aber Ousterhout argumentiert, dass sowohl die initiale Struktur des Codes, als auch spätere Änderungen des Codes vorab geplant und bedacht werden müssen, damit die Codebasis langfristig ihre Konsistenz behält. Viele ungerichtete, nicht geplante Änderungen an einer Codebasis führen halt früher oder später zu einem unrettbaren Durcheinander. Genauso wie es bei einer Bibliothek nicht fubktioniert, wenn man Bücher die zurück gegeben werden, einfach irgendwo in ein Regal stellt wo grad Platz ist - sie sind dann nicht mehr zu finden.

Und genau das, die Struktur des Code und seine Invarianten verstehen und diesen so ändern, dass diese implizite Struktur erhalten bleibt, kann die KI halt nicht, auch nicht bei einer mittelkleinen Codebasis. Die Struktur geht dann verloren, auch wenn die Tests vielleicht noch funktionieren.

Und das Problem ist gerade, dass funktionierende Tests eben nicht eine konsistente interne Struktur des Codes sicherstellen. Das können sie halt gar nicht.

Ousterhouts Buch ist wirklich super empfehlenswert, es ist nicht so dick!

Eine Konsequenz der Tatsache, dass man den Zusammenhang und die Bedeutung der Namen in einer größeren Codebasis regelrecht erlernen muss, ist dass es wegen der Menge an Details nur durch häufige Wiederholung geht. (Ins Kurzzeitgedächtnis passen bekanntlich nur ca. sieben Dinge rein ).

Und dass es bei Legacy Code extrem hilfreich ist, sich auf Geschriebenes zu stützen, denn das vereinfacht die Wiederholung .

I learned programming on Apple II and the fast keyboard reaction felt really good. I hate it when keys lag.

50 ms is clearly noticeable. Dan Luu mentions 2ms in the original post.

Try in a terminal

read a; sleep 0.02; echo $a

and vary the number.

Actually, the time resolution for visual sensations is at least 5ms and for sound it is even smaller - a drummer in s band needs to practice a lot to get the right beat.

Übrigens fällt dieser Beitrag (und einige weitere hier im Faden) exakt in das Muster, das ich erst heute morgen in meinem Kommentar auf c/programning@programning.dev als eine weitere Marketing-Strategie unter einem Arsenal von Strategien beschrieben habe, mit der versucht wird GenAI unter Softwareentwicklern an den Mann, bzw an die Frau zu bringen:

• da wird erstens eingeräumt, dass GenAI unter bestimmten Bedingungen (Entwickleunerfahren / zu erfahren / Problem zu komplex / keine genaue Spezifikation / Lösungsstrategie schon klar usw.) keinen Vorteil bringt
• und dann wird behauptet, dass es aber unter anderen Bedingungen (Entwickler erfahrener / weniger erfahren / genaue Spezifikationen vorhanden / Problem nicht definiert / Problem einfach / “Boilerplate") dann doch angeblich einen Vorteil hat.

Belege für diese angeblichen Vorteile gibt es nie.

Eindeutige Untersuchungen, die z.B. Vorteile für erfahrene Entwickler belegen, gibt es nicht.

Offizielle Angaben, wozu KI nun gut geeignet sein soll und wozu nicht, gibt es keine.

Das ist letztlich eine Variante von “moving the goal posts”.

What I love about his approach is that he first thinks about what are his own requirements, before choosing his solution.

Oh, and you should absolutely try Common Lisp. In the 80ies, when I learned programming, Lisp had a reputation of being expensive to get licenses for, extremely resource-hungry and unusable on microcomputers. Today, it is a language that is more powerful than Python and open source implementations like SBCL compile Lisp to native code with roughly about the speed of Java.