Zum Inhalt springen

root / tags / refactoring

#refactoring

6 Fiches

KI-Coding-Agenten & Skills Automatisch geprüfte Übersetzung

What...what am I missing here? (post X sur les LLMs et le codage)

X-Post von **Eric S. Raymond** (ESR, Autor von *The Cathedral and the Bazaar*, Mitbegründer der Open Source Initiative, ~50 Jahre Programmiererfahrung) — **ein frontales Gegenzeugnis zur Erzählung, dass „LLMs schrottigen Code produzieren und halluzinieren, unbrauchbar zum Programmieren“.** Seine These: Das **passiert ihm fast nie**, und **überhaupt nicht mehr in den letzten zwei Generationen** der von ihm genutzten Modelle („ChatGPT 5.4 und 5.5“ unter **codex**). Das frühere Symptom — ein Modell, das „entgleist“, wenn es sich seinem Kontextlimit nähert — ist verschwunden: codex zeigt jetzt eine **rote Warnung** an, die den Nutzer auffordert, die **Sitzung zu leeren**, statt abzudriften. **Nutzungsumfang**: KI angewandt auf **Feature-Änderungen, Refactoring und Debugging über 63 Projekte** in **C, Go, Rust, Python und Shell**; das Verfassen von Dokumentation; **das Dekompilieren einer DOS-Binärdatei in lesbaren Quellcode**. Eine etablierte **Arbeitsroutine**: Beim Wiederöffnen eines Projekts führt er zunächst die **Regressionstests** aus, startet dann codex und bittet es, den Code zu **auditieren** (Bugs + Verbesserungsvorschläge). Fazit: LLMs sind **„exzellent und enorm empowernd“**; ihre **größte Schwäche** ist der **„architektonische Tunnelblick“** — hervorragend darin, Code nach Spezifikation zu erzeugen, aber manchmal **blind für übergeordnete Muster** — was er als die **Aufgabe seines „Fleischhirns“** ansieht. Der stärkste, kontraintuitive Punkt: LLMs **liegen bei Details und Randfällen NICHT falsch**; er sagt, er sei diesbezüglich **schlechter als sie** (trotz 50 Jahren Erfahrung), denn wenn eine Änderung **fünf Stellen berühren** muss, findet das Modell **zuverlässig alle fünf**, während der Mensch vier korrigiert und **stundenlang debuggt**, bevor er die vergessene fünfte findet. Er stellt daraufhin die **„Herunterschreier“** in Frage: Leben sie in einem **anderen Universum**? Nutzen sie **alte, schwache Modelle**? Gibt es ein **Skill-Problem**, das er nicht sieht, weil seine **Denkgewohnheiten und Kommunikation** gut zu den „Griffen“ dieser Werkzeuge passen? Eine Frage, die er für wichtig hält zu klären, da „**Milliarden von Dollar durch fehlgeleiteten Token-Einsatz verschwendet würden**“. Sein Rezept, „ganz einfach“: **„Denke klar, sag dem Modell präzise, was du willst, und gute Dinge geschehen“** — mit dem Schlusssatz: „Was übersehe ich hier?“ Zu lesen als ein **Pro-LLM-Gegenpunkt einer historischen Figur der Open-Source-Bewegung** in der wiederkehrenden Debatte über die (Ab-)Wertung von Coding-Agenten — anklingend an das „Skill-Problem“ und die Spezifikationsdisziplin (vgl. [[martignole-token-manifesto-2026-07-17]]) und ein Diptychon bildend mit **Linus Torvalds'** doktrinärer Pro-KI-Werkzeug-Haltung im Namen des Linux-Kernels ([[torvalds-llm-outil-kernel-2026-07-14]]).

#Eric S. Raymond#ESR#esrtweet

Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)

KI-Coding-Agenten & Skills Automatisch geprüfte Übersetzung

Failing Faster

Beitrag von **David "Pragdave" Thomas** (Co-Autor von *The Pragmatic Programmer*, Unterzeichner des Agile Manifesto), veröffentlicht am **6. Juni 2026** in seinem Substack-Newsletter. **These**: KI schafft den Code-Verfall nicht ab, sie **beschleunigt** ihn. Bei der Erweiterung eines kleinen privaten Animations-/Grafikprojekts mit **Claude** bewegt sich der Autor von anfänglicher Begeisterung (oklch, SVG-Animationen innerhalb einer Woche ausgeliefert) zu permanenten Regressionszyklen ab der zweiten Woche. Prägnante Formulierung: Wofür Teams ***"18 Monate oder sogar mehr"*** brauchten, um zu verrotten, erreichte er in ***"18 Stunden, verteilt auf fünf Abende."*** **Grundursache**: die Aufgabe der **Code-Hygiene** (massive Duplizierung, lokale Lösungen für systemische Probleme, Überkonditionierung, Wucherung von Sonderfällen). **Verhaltensdiagnose**: LLMs optimieren auf Nutzer-Engagement und -Zufriedenheit (*"Das ist eine großartige Idee, Dave!"*) statt auf Langlebigkeit — sie sind ***"welpenhafte Junior-Entwickler, gefallsüchtig, aber ziemlich chaotisch im Umgang"***, die ständig neue Features vorschlagen und von Refactoring abhalten. **Zentrale Einsicht**: Jeder Nicht-Entwickler kann bei der *"ersten Woche"* des KI-Codings erfolgreich sein; es ist das **professionelle Urteilsvermögen** — zu wissen, wann man innehalten muss, um zu refaktorisieren —, das den erfahrenen Ingenieur vom Neuling unterscheidet. **Epigraph** (Gordon Bell): *"Jede große Computer-Katastrophe entstand dadurch, dass zu viele Ideen an einem Ort zusammengeführt wurden."* **Fazit**: ***"Es ist immer noch nur Programmierung"*** — unversorgter Code verrottet, ob in 18 Stunden oder 18 Monaten; alles, was über guten Code gelernt wurde, gilt weiterhin, der Effekt wird lediglich **verstärkt**. Konvergiert mit der Doktrin *"je schneller die Ausführung wird, desto strikter muss der Rahmen sein"* von [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], dem *"KI-unterstützte Entwicklung ist eine Falle ohne Continuous Delivery"* von [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], und dem *"KI verschiebt Engpässe, sie beseitigt sie nicht"* von dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; ein Handwerks-Gegenpol zum vibe coding von karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.

#Code-Hygiene#Code-Verfall#Code-Degradation

**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.

Transformation & Adoption Automatisch geprüfte Übersetzung

Fragments: February 13

Thoughtworks-Retreat zur Zukunft der Softwareentwicklung mit LLMs — Überlegungen zu organisatorischen Auswirkungen, kognitiver Schuld und beaufsichtigter Programmierung

#LLM#Softwareentwicklung#KI-Agenten

Martin Fowler