Das Aufräumen hinter den AI-Rockstar-Entwicklern

• Das frühere Problem schwer verständlicher Codebasen, die von „Rockstar-Entwicklern“ hinterlassen wurden, wird durch die Verbreitung von LLM-generiertem Code zu einer Wartungslast für das gesamte Team
• Rockstar-Entwickler führten neue Technologien, neue Paradigmen und neue Architekturen schnell ein und erledigten schwierige Aufgaben zügig, hatten aber wenig Interesse daran, Code zu schreiben, den andere verstehen und gemeinsam bearbeiten können
• LLM-Agenten erzeugen in kurzer Zeit Zehntausende Zeilen Code, ohne sich an frühere Arbeit zu erinnern, und kümmern sich nicht darum, ob dieser zum Gesamtsystem passt oder besser verständlich wird
• Je mehr generierter Code entsteht, desto stärker wächst die Komplexität des Systems, und es kann ein Kreislauf entstehen, in dem man erneut auf LLMs angewiesen ist, um ihn zu verstehen
• Für langlebige Software ist es nötig, LLMs auf die Erzeugung kleiner Codefragmente zu begrenzen, Menschen die Architektur vorgeben zu lassen und diese an die Komplexität des Problems angepasst einfach zu halten

---

Die Struktur, die Rockstar-Entwickler hinterlassen

• Rockstar-Entwickler stoßen zum Team und bringen starke Vorstellungen zu neuen Technologien, neuen Paradigmen und neuen Architekturen mit
• Sie schreiben große Teile der Kernarchitektur des Unternehmens neu und führen neue Build-Prozesse, Tools und Sprachen ein
• Sie lehnen viele Pull Requests ab und heben damit die Maßstäbe für Teammitglieder an, während andere nicht offenlegen können, ob sie den Code überhaupt verstehen
• Die schwierigsten Aufgaben werden dem Rockstar-Entwickler zugewiesen, und er erledigt sie schneller als alle anderen
• Die übrigen Teammitglieder bewegen sich langsamer, weil sie neue Bibliotheken lernen und sich an die Arbeitsweise des Rockstar-Entwicklers anpassen müssen
• Einige Jahre später verlässt der Rockstar-Entwickler das Team, weil er ein schwierigeres Projekt in einem größeren Unternehmen will

Mit den Folgen umgehen

• Die verbleibenden Teammitglieder übernehmen die Projekte des Rockstar-Entwicklers und fühlen sich vom Code überwältigt
• Der Datenfluss ist kaum nachzuvollziehen und wirkt fast so, als wolle jemand einen Mord vertuschen
• Man beginnt mit einfachen Bugfixes, braucht aber schon eine Woche, um den Code überhaupt auf dem Laptop auszuführen
• Die Hälfte des Codes ist in einer Sprache geschrieben, die man nicht versteht, die andere Hälfte mit Bibliotheken, von denen man nie gehört hat
• Man sagt dem Vorgesetzten, dass der Code neu geschrieben werden muss, doch das wird mit dem Hinweis abgelehnt, dass er vom Rockstar-Entwickler stammt
• Während man sich durch chaotischen Code kämpft, schaut man Stellenanzeigen an und stellt sich vor, selbst zu gehen

Hinter den Rockstars aufräumen

• Viele Teams und Agenturen müssen die Codebasen aufräumen, die solche Rockstar-Entwickler hinterlassen haben
• Der Prozess, eine komplexe Codebasis zu verstehen und zu retten, lässt sich damit vergleichen, eine verknotete Lichterkette so zu entwirren, dass man sie wieder benutzen kann
• Rockstar-Entwickler lieben das Coden, das Lernen und die Nutzung neuer Paradigmen und treiben ihre Fähigkeiten bis ans Limit
• Sie versuchen, möglichst cleveren Code zu schreiben, und konzentrieren sich darauf, sich so schnell wie möglich zu bewegen
• Code zu schreiben, mit dem andere gemeinsam arbeiten können, hat für Rockstar-Entwickler die niedrigste Priorität

Der Auftritt der künstlichen Intelligenz

• In den letzten Jahren haben viele Teams erlebt, wie sie von einer ganzen Armee von Rockstar-Entwicklern überwältigt werden
• Jedes Mal, wenn jemand einen neuen Chat startet, besteht das Risiko, dem Team einen weiteren Rockstar-Entwickler hinzuzufügen
• Agenten erinnern sich nicht daran, was sie gestern getan haben, und erzeugen in wenigen Minuten Zehntausende Zeilen Code
• Agenten treiben den Abschluss von Aufgaben mit einer Geschwindigkeit voran, die für Menschen unmöglich wäre
• Sie kümmern sich nicht darum, ob der erzeugte Code zum restlichen System passt oder ob das System dadurch leichter verständlich wird
• AI verfügt über einen Werkzeugkasten mit Best Practices, die im jeweiligen Kontext unpassend sein können
• Selbst wenn die Komplexität den Nutzen übersteigt, beharrt AI auf übertriebenen Sicherheitsmaßnahmen nach dem Prinzip „doppelt hält besser“
• Bittet man um ein Code Review, erzeugt sie eine lange Liste von Verbesserungen, denen man oft nur schwer zustimmen kann
• Viele haben das Gefühl, für immer zurückzufallen, wenn sie keine LLMs verwenden
• Die Vorstellung, LLMs den gesamten Code schreiben zu lassen, führt am Ende jedoch gerade dazu, zurückzufallen

Hinter Hunderten von AI-Rockstars aufräumen

• Einen chaotischen Haufen generierten Codes aufzuräumen, macht noch weniger Freude, als den Code eines einzelnen Rockstar-Entwicklers zu bereinigen
• Bei Rockstar-Entwicklern gab es zumindest irgendeine Entwurfsabsicht und den Versuch, das Beste zu erreichen
• Ein chaotischer Codehaufen aus Vibe Coding stammt nicht von einem einzigen künstlichen Entwickler
• Stattdessen entsteht eine Codebasis, in der in vielen Chats und Kontexten jeweils nur einzelne Features oder Bugfixes generiert wurden
• Das ähnelt einer Codebasis, die von Hunderten unterschiedlicher Rockstar-Entwickler geschrieben wurde
• In manchen Fällen wird die technische Schuld so groß, dass sie niemals mehr abgetragen werden kann

Langlebige Software bauen

• Es gibt verschiedene Wege, LLMs so einzusetzen, dass sie sich nicht wie Rockstar-Entwickler verhalten
• Menschen können das Engineering führen und LLMs dazu anleiten, jeweils nur kleine Codefragmente zu erzeugen
• Man muss sicherstellen, dass Software so geschrieben wird, dass alle Teammitglieder sie leicht verstehen und bearbeiten können
• Wenn das LLM sich verirrt hat, ohne zu verstehen, was es tut und warum, sollte man das Tempo drosseln
• Es ist in Ordnung, langsamer vorzugehen, um die Qualität der entstehenden Software sicherzustellen
• Es ist in Ordnung, Overengineering zu vermeiden und die Architektur weiter zu vereinfachen, bis sie zur Komplexität des Problems passt
• Manchmal ist es auch in Ordnung, das LLM im Werkzeugkasten zu lassen und den Code direkt selbst zu schreiben
• Handwerkskunst bleibt immer in menschlicher Hand und ist ein Bereich, der sich nicht an Maschinen auslagern lässt

[GN⁺]

Meinungen auf Hacker News

• Der letzte Satz, dass Handwerkskunst immer in menschlicher Hand bleiben und niemals an Maschinen ausgelagert werden könne, macht mir etwas Sorgen
  Auch in anderen Branchen ist Handwerkskunst nicht ausgestorben, wurde aber von viel billigeren und leichter verfügbaren Alternativen verdrängt. Man kann immer noch handgefertigte Lederschuhe kaufen, aber nur wenige wollen dafür mehr als 1000 Dollar zahlen, und man kann auch Gemälde kaufen, in die Wochen an Arbeit geflossen sind, doch die meisten kaufen Wanddeko und Haushaltswaren bei HomeGoods
  Der entscheidende Unterschied ist die Annahme der Wegwerfware, und leider wird auch Software zunehmend wie andere Produkte zu etwas „Wegwerfbarem“. Eine einfache Countdown-App kann man wegwerfen, aber Software, die lang laufende Geschäftsprozesse trägt, sollte man nicht so behandeln
  Wenn man sich auf Software-Handwerkskunst fokussiert, kann das Problem wie „etwas, das ich für meinen Zweck brauche“ gegenüber „boutiqueartig, teuer und unnötig“ erscheinen. Tatsächlich sollte es aber um „wartbar und zuverlässig“ gegenüber „wegwerfbar“ gehen
  Unabhängig davon, ob dieser Trend großen Modellanbietern wie OpenAI oder Anthropic nützt, ist das nicht der Punkt, den ich hier machen will

  • Handwerkskunst in anderen Branchen stirbt nicht auf die Weise aus, wie man es bei Software beschreibt
    Mein billiger Schreibtisch, der in einem flachen Karton kam und den ich selbst mit dem Schraubendreher zusammengebaut habe, wurde zwar im Werk massenproduziert, aber in sein Design könnte weit mehr fachliche Handwerkskunst eingeflossen sein als in ein maßgefertigtes Einzelstück. Das Modell ist: hohe anfängliche Designkosten, danach Massenproduktion bei niedrigen Grenzkosten
    Software war im Grunde von Anfang an so. Wenn ich Firefox herunterlade, baut kein Handwerker nur für mich einen Webbrowser; ein CDN-Server in irgendeinem Rechenzentrum kopiert Bytes aus einem Cache
    Was AI bedroht, ist der Ersatz von vorab investierter Handwerkskunst, etwas, das in anderen Branchen nie in großem Maßstab passiert ist. Erfolgreicher ersetzt AI bisher günstige „handwerklich“ erzeugte Software, ein Bereich, der faktisch kaum existierte, weil er wirtschaftlich bisher zu unattraktiv war
  • Physische Branchen und Software sind sehr verschieden. Lederschuhe werden für jeden Kunden Paar für Paar mehrfach hergestellt, Code hingegen wird einmal geschrieben und dann nutzen alle Kunden dasselbe Produkt
    Deshalb hat Investition in Qualität einen viel größeren Hebel
    Ich finde es auch schwer, Software im gleichen Sinn als Wegwerfware zu sehen. Bei einem vorübergehenden Problem kann man den Code wegwerfen und beim nächsten Problem neuen schreiben. Aber bei einem dauerhaften Problem bleibt der Code bestehen
  • Aus Sicht der mechanischen Fertigung ist das ein interessanter Blickwinkel
    Schrauben waren einst wertvolle, kundenspezifisch gefertigte Güter, und es brauchte enorm viel Zeit und Mühe, auch nur eine gute Schraube herzustellen. Selbst das, was wir heute Maschinenschrauben nennen, konnte nur von sehr geübten Menschen unter extremem Aufwand gefertigt werden
    Aber Maschinen können Handwerkskunst übertragen. Wenn man eine wirklich gute Schraube herstellt, überträgt die Maschine deren Qualität auf viele neue Schrauben
    Heute sind Schrauben jeder Art und Qualität fast gleichermaßen Verbrauchsgüter, und Schrauben, die früher Tage oder Wochen per Hand herausgearbeitet worden wären, werden heute milliardenfach hergestellt
    Ich sehe AI auch wie eine Drehbank ohne Leitspindel. Zuerst muss ich die Schrauben noch selbst von Hand machen, und danach kann ich die Qualität, die ich liefern kann, auf beliebig viele neue Schrauben übertragen. Wenn ich bessere Schrauben herstellen kann, setze ich sie in die Drehbank ein und fertige mehr und bessere Schrauben. Aber grundsätzlich bleibe ich durch die Qualität der Schrauben begrenzt, die ich selbst herstellen kann. Wenn ich nur krumme, unebene, chaotische Stücke hinbekomme, kommt aus der Maschine auch nicht mehr heraus
  • Das ist eine völlig falsche Sichtweise. Das, was in Software der „Handwerkskunst“ entspricht, ähnelt nicht der Herstellung von Schuhen, sondern eher dem Entwurf von Schuhen
    Softwareentwickler schaffen einzigartiges geistiges Eigentum, sie fertigen keine Software-Einheiten. Das ist eher mit Buchautoren oder Musikern vergleichbar
    In Software gibt es kein Äquivalent zur Stückfertigung. Man kopiert einfach Bits
    Deshalb bedeutet „Handwerkskunst“ im Softwarekontext, wie viel Sorgfalt man in den Entwurf guter Dinge steckt. Sie wird nicht verschwinden, solange uns die Qualität der Software, die wir benutzen, nicht egal wird, und es gibt derzeit keine Anzeichen dafür, dass wir uns in diese Richtung bewegen
  • Die Analogie mit handgemachten Schuhen passt nicht, außer man meint Software, die nur von einer einzigen Person genutzt wird
    Ein passenderer Vergleich wären vielleicht Ingenieure, die die Fertigungsanlagen einer Schuhfabrik bauen und warten. Sie sind vom Endverbraucher eine Ebene entfernt, aber auch dort steckt eindeutig Handwerkskunst drin

• Ich mag es, AI- oder ausgelagerten Code zu reparieren. Letzte Woche habe ich erfahren, dass ein Kunde versucht hatte, ein Tool für seine Abteilung per Vibe Coding zu bauen; das Ergebnis war ein gigantischer Next.js-Müll, der 10 GB RAM zum Kompilieren brauchte, Tausende von Lint-Fehlern hatte und sogar laute Entwicklungslogs im Git-Repository enthielt
  Jetzt müssen wir das reparieren, also sind solche Fälle immer wieder kostenlose Leads im Wert von 10.000 bis 50.000 Euro. Wenn man weiß, was man tut, ist es sehr leicht, und wenn nicht, ist es unmöglich. Immer her damit

  • In gewisser Weise hat der Kunde damit Spezifikation und UI-Mockups für die Umsetzung geliefert
  • Ich stimme dem 1000-fach zu
    Ich arbeite im Bereich Incident Response für KMU, und in den letzten Jahren ist die Menge an Arbeit so stark gestiegen, dass ich kaum hinterherkomme, und mein Bankkonto fühlt sich an wie der Goldhaufen eines Drachen
    Ich bin völlig dafür, dass Security immer integriert und geplant sein sollte, und ich will damit keinesfalls sagen, dass ich Sicherheitsvorfälle sehen möchte
    Aber dass Leute mit vager Fachkompetenz jetzt in einer Stunde Apps herauspumpen können, war für Menschen wie mich ein riesiger Glücksfall
  • Agenturen, die sich auf so etwas spezialisieren, werden viel Geld verdienen. Ich habe schon einige solcher Fälle bekommen, und solange die Leute glauben, sie könnten ihr Produkt einfach vibe coden, wird das weiter reinkommen. Wie gesagt: leicht verdientes Geld
  • Viele Leute setzen große Summen auf AI. Ein Teil davon ist vielversprechend, aber nicht jede Wette wird aufgehen
    Diese Denkweise kann man so sehen, als würden Menschen Geld in menschliche Spielautomaten schieben
  • Mich würde interessieren, ob du — ohne deine eigene Identität oder die der Kunden preiszugeben — mehr darüber erzählen kannst, wie sich solche Fälle tatsächlich entwickeln
    Wenn Kunden zu dir kommen, wollten sie dann von Anfang an Hilfe beim Gang in die Produktion, oder ist das eher der letzte Ausweg, nachdem der ganze AI-Ansatz gescheitert ist?
    Ich frage mich auch, ob es typische Arten gibt, wie solche Projekte scheitern, oder ob das Scheitern meist eher subtil verläuft

• Ich habe im Leben ein paar Menschen getroffen, die man wirklich außergewöhnlich nennen kann. Solche, bei denen man sich fragt: „Wie kann jemand nur so klug sein?“
  Bei wirklich klugen Menschen beobachtet man zwei Dinge, die meist einander ausschließen. Das eine ist, dass sie gar nicht merken, wie klug sie sind. Für sie ist etwas einfach, oder es ist eben ein Thema, das sie kennen, also nehmen sie an, jede Person mit einem Informatikabschluss wisse, erinnere und verstehe das ebenfalls. Wenn ich Freunde sehe, die mühelos kryptografische Mathematik herunterbeten, denke ich manchmal: „Ich habe den Kurs zwar bestanden, aber ich kann nicht behaupten, das Thema, über das du gerade gesprochen hast, wirklich zu beherrschen.“
  Das andere sind Menschen, die sich schmerzhaft ständig bewusst sind, dass sie klüger sind als die meisten um sie herum. Manche werden dadurch gemein, andere sind einfach erschöpft davon, von relativ „dummen“ Menschen umgeben zu sein. Mit Letzteren habe ich ein gewisses Mitgefühl. Man muss sich nur vorstellen, wie es wäre, ein Leben zu führen, in dem alles klar, offensichtlich und leicht zu lösen ist, und dann zusehen zu müssen, wie die Menschheit immer wieder törichte Entscheidungen trifft, obwohl die Antwort längst bekannt ist

  • Es gibt noch ein drittes Problem. Weit mehr als die Hälfte der Menschen glaubt, dass sie in diese letzte Beschreibung fallen
  • Ich würde von mir nicht behaupten, besonders viel gelesen zu haben oder einen hohen IQ zu besitzen, aber bei kleinen Dingen, die sich wie gesunder Menschenverstand anfühlen, empfinde ich es ähnlich
    Wenn Menschen planlos herumirren oder X tun, obwohl dadurch offensichtlich das schlechte Ergebnis -Y entsteht, macht mich das fast wahnsinnig. Die meisten lernen einfach, es nicht laut auszusprechen
    Besonders in engen Familienbeziehungen ist das ungesund. Ich sehe so viel davon, dass ich manchmal das Gefühl habe, ich könnte die anderen mit meinem Genörgel umbringen
  • Ich habe solche Leute gekannt und getroffen
    Aber keiner von ihnen war ein 10x-Entwickler, der einen riesigen Scherbenhaufen hinterlassen hat, den mein Team und ich dann monatelang aufräumen mussten
  • Als Mensch an einem Singularitätspunkt in irgendeiner grundlegenden Eigenschaft zu leben, ist einsam
    So sehr man sich auch bemüht, es ist schwer, zu den meisten Menschen eine Beziehung aufzubauen, und für sie ist es besonders schwer, mich zu verstehen. Die Unterschiede in den Lebenserfahrungen sind sehr groß und oft schwer zu überbrücken
  • Viele Entwickler entscheiden sich einfach dafür, nur Alltagsaufgaben zu erledigen oder Cargo Cults zu folgen
    Nicht alle Entwickler können die gleiche Produktivität erreichen, aber wenn man sich entscheidet, weiterzudenken und über den kulturellen Durchschnitt hinauszugehen, kann jeder auf seine eigene Weise klüger werden
    Die meisten merken nicht, dass sie dazu in der Lage sind

• Diese beiden Sätze haben mich angesprochen
  „Es war so schwer, dem Datenfluss zu folgen, dass es wirkte, als wolle jemand einen Mord vertuschen“
  „Allein den Code auf dem Laptop zum Laufen zu bringen, hat eine Woche gedauert“
  Ich dachte immer, ich sei der Einzige, der Schwierigkeiten damit hat, Datenflüsse zu verstehen oder eine vernünftige Entwicklungsumgebung aufzusetzen. Impostor-Syndrom und manchmal auch ein toxisches Umfeld, das auf „Geschwindigkeit“ drängt, helfen dabei natürlich nicht
  Es war gut zu erfahren, dass ich nicht der Einzige bin

  • Der Teil „Allein den Code auf dem Laptop zum Laufen zu bringen, hat eine Woche gedauert“ hat mich überrascht
    Claude Code in der CLI hat es viel einfacher gemacht als früher, eine App hochzufahren und beliebige Abhängigkeiten oder Docker-bezogene Probleme zu debuggen. Früher musste ich gleichzeitig die Architektur lernen und auch noch herausfinden, warum es auf meiner Maschine nicht lief
  • Du bist nicht allein. Mir ging es genauso, und dieses Wissen steckt meist in den Köpfen der Leute oder in irgendwelchen zufälligen Slack-Threads
    Bei AI-Code ist es noch schlimmer. Denn der wurde einfach als etwas erzeugt, das in dem Moment plausibel aussah

• Ich beneide die Leute ein wenig, die hinterher aufräumen müssen. Wenigstens fühlt es sich an, als würde man ein Rätsel lösen
  Meine aktuelle Arbeit ist wirklich langweilig. Es sind Aufgaben, die so einfach sind, dass selbst ein Junior sie erledigen könnte, und trotzdem heißt es, man brauche dafür einen Mid-Level-Entwickler. Ich will damit nicht sagen, dass ich für diese Arbeit zu gut bin oder dass Mid-Level-Leute so etwas nicht machen. Ich kann mich nur einfach nicht dazu zwingen, mich für den Code zu interessieren, den diese Firma produziert. Er ist alt, verstaubt und wird nicht einmal von wichtigen Leuten genutzt. Die Kunden haben das Tool irgendwann einmal gekauft und benutzen es nur weiter, weil es so langweilig ist, dass es ihnen nicht wichtig genug ist, es auszutauschen
  Mir wurde versprochen, dass bald etwas kommt, das besser zu meiner Erfahrung passt, aber ich kann mir nicht vorstellen, dass in so einer stagnierenden Firma solche Kunden auftauchen
  Es überrascht mich nicht, dass diese Firma Kunden und Mitarbeiter verliert. Aber ich muss eine Hypothek abbezahlen. Heute wurde angedeutet, dass mein Vertrag vielleicht nicht verlängert wird, und faktisch war das eine Drohung, für das gleiche Gehalt mehr Verantwortung und mehr Arbeit zu übernehmen
  Leider muss ich wohl durchhalten, bis ich eine wirklich interessante neue Stelle finde. Ich brauche nicht einmal besonders viel Geld und an „Wachstum“ bin ich überhaupt nicht interessiert. Ich brauche einfach nur genug, um zu überleben
  Dieser Kommentar ist vielleicht ziemlich off-topic, entschuldigt. Ich habe keinen anderen Ort, um das loszuwerden

  • Du bist nicht allein. Bei Microsoft war es bei mir genau dasselbe, und ich habe am Ende gekündigt
    Ich war L63, aber die Arbeit, die ich machte, hätten auch Leute auf L60~L61 erledigen können, und ich hatte oft das Gefühl, in einem von David Graeber beschriebenen Bullshit Jobs zu stecken. Die Bezahlung war großzügig, aber als die Aktien aus meinem Sign-on-Bonus ausliefen, wurde mir klar, dass ich nur noch wegen der Sicherheit dortblieb
    Ich kam mir vor wie einer dieser Ingenieure, die auf der Terrasse eines Hooli-Büros in der Sonne liegen und auf das Vesting ihrer Aktien warten. Nach neun Berufsjahren schien mir das nicht das Beste für meine Karriere zu sein
    Ich hatte allerdings keine großen finanziellen Verpflichtungen, deshalb war die Entscheidung für mich viel leichter
  • Zuerst dachte ich, „medior“ sei einfach ein seltsamer Tippfehler von „senior“, aber als es zweimal vorkam, habe ich es nachgeschlagen. Offenbar wird es in einigen Teilen Europas für mittlere Stufe verwendet
  • Mit „Ich kann mich nicht dazu zwingen, mich für den Code zu interessieren, den diese Firma produziert“ kann ich mich sehr identifizieren
    Schrottprodukte von Schrottfirmen leben von der Trägheit und Geschmacklosigkeit der meisten Menschen, und Marketer schlagen daraus Profit
    Jetzt wird das Ganze noch schlimmer, weil der gesamte Bereich LLM-isiert wird und sich alles um das Hundertfache verstärkt. Es macht Code unwartbar und, schlimmer noch, uns alle dümmer
    Ich wünschte wirklich, wir hätten das nie entdeckt
  • Wenn du dir die Codebasis, an der du gerade arbeitest, genau ansiehst, findest du vermutlich ziemlich viele Gelegenheiten zum Aufräumen, egal ob es Hinterlassenschaften anderer oder deine eigenen sind
  • Der Teil mit der „Drohung, für das gleiche Gehalt mehr Verantwortung und mehr Arbeit zu übernehmen“ macht mich ein wenig neugierig
    Ich frage mich, ob einfach mehr Überstunden und sinnlose Aufgaben gemeint sind, ob es tatsächlich mehr Möglichkeiten zum Coden gibt oder ob plötzlich erwartet wird, dass du beweist, mehr wert zu sein
    Ich will nicht kleinreden, was du erlebt hast. Falls Letzteres gemeint ist, frage ich mich, ob man daraus tatsächlich etwas machen könnte

• Die ersten paar Abschnitte haben mich angesprochen. Früher war ich wohl selbst so etwas wie ein Rockstar-Entwickler, aber mir wurde klar, dass das nichts Gutes ist
  Vielleicht konnte ich Aufgaben 10-mal schneller erledigen als meine Kollegen. Aber irgendwann wurde mir klar, dass das nicht daran lag, dass ich 10-mal produktiver als normale Menschen war, sondern daran, dass meine Arbeitsweise die normalen Menschen um mich herum auf 1/10 ihrer Produktivität gedrückt hat
  Danach habe ich bewusst einen Gang heruntergeschaltet, und für mein gesamtes Leben war das eine positive Veränderung. Ein Teamplayer zu sein bringt in dieser verrückten Branche zwar nicht dieselbe Aufstiegsmobilität, ist aber erstaunlich gut für die psychische Gesundheit

  • Auch ich habe mir früher definitiv schon selbst ins Knie geschossen, indem ich im Rockstar-Stil implementiert habe
    Bei mir lief es meist darauf hinaus, Dinge übermäßig zu abstrahieren oder etwas für Anwendungsfälle zu bauen, die in Wirklichkeit nie eintreten. Deshalb versuche ich, mich immer an YAGNI und KISS zu erinnern, sobald meine Gedanken in Richtung Überabstraktion abdriften

• Dieser Beitrag hat einen viel zu geringen Wert
  Ich bin mir nicht einmal sicher, was er eigentlich sagen will, und er wirkt einfach wie selbstgefälliges Schulterklopfen

  • Schlechten Code gibt es definitiv. Aber dieser Artikel scheint „schlechter Code“ mit „kompliziertem, großem Code, in den man sich erst mit der Zeit einarbeiten muss“ zu vermischen
    Ein erheblicher Teil dessen, was als die riesigen Mengen an schlechtem Code bezeichnet wird, die ein „Rockstar-Entwickler“ hinterlassen habe, ist in Wirklichkeit das Ergebnis von Komplexität, die sich langsam und über lange Zeit als Reaktion auf geänderte Anforderungen aufgebaut hat
    Außerdem glauben Leute oft, sie würden „für die Lesbarkeit refaktorieren“, während in Wirklichkeit häufig eher gilt: „Sie schreiben den Code neu und verstehen ihn dabei erst richtig“
  • Zusammengefasst lautet die Aussage: „Wenn du LLMs benutzt, geh langsamer vor und denk darüber nach, was du tust.“ Das hat mir 5 Minuten gespart
    Ich hatte auf mehr Inhalt oder konkrete Beispiele gehofft. 90 % des Artikels bestehen daraus, dass der Autor jammert und das Problem definiert, und im vorletzten Absatz kommt dann eine vage, hingeworfene Lösung. An tatsächlicher Relevanz oder Nützlichkeit ist da fast nichts

• Es war wirklich dumm von mir, zwei Production Engineers massiv unter Druck zu setzen, damit sie die Infrastruktur rund um zwei profitable Projekte bauen, die ich entwickelt habe
  Ich hätte viel mehr Geld verdienen können, wenn ich alles wie ein 10x-Boss als Spaghetti-Code hingeklatscht und dann zu Anthropic gewechselt wäre, um dort ein Vergütungspaket im neunstelligen Bereich zu kassieren. Wie dumm und noch dümmer ich doch war
  Zumindest ist das die Schlussfolgerung, die ich hieraus mitnehme

• Geschriebener Code muss in der Regel von jemand anderem als dem Autor gewartet werden. Wenn man also Code schreibt, den niemand versteht, führt das am Ende zu Wartungsversagen
  Was man optimiert, kann unterschiedlich sein: für vom Team leicht verständlichen Code, für Geschwindigkeit, für technische Exzellenz usw.
  Aber selbst wenn man auf technische Exzellenz optimiert hat, ist es trotzdem ein Scheitern, wenn sonst niemand im Team den Code verstehen kann
  Ich habe schon überengineerten Code gesehen

[GN⁺]

Lobste.rs-Meinungen

• Dieser Artikel enthält kaum wirklich brauchbare Ratschläge

  • Es wirkt, als hätte jemand zwei Buzzwords um eine persönliche Beschwerde gewickelt, damit sie überzeugender aussieht.
    Der Ausdruck „Rockstar-Entwickler“ ist immer verdächtig, aber hervorragende Entwickler gibt es tatsächlich. Nur verhalten sie sich nicht so, wie es im Artikel beschrieben wird: Sie arbeiten so gut wie möglich innerhalb der bestehenden Umgebung, verbessern die Codebasis, führen keine ungetesteten neuen Dinge wie Spielzeug ein und hinterlassen beim Weggehen durch Tests, skriptgesteuerte Deployments, Linting usw. einen stabileren Zustand.
    AI wirkt hier wie ein Zusatz in der Art, dass dieses Verhalten noch schlimmer werde; das kann sein, aber es scheint noch nicht ausreichend belegt zu sein. Ich habe jahrzehntelang als Berater chaotische Codebasen aufgeräumt, und manchmal lag die Ursache bei Leuten, die es übertrieben haben, viel häufiger aber bei Teams, die keinen besseren Weg kannten. In keinem der Fälle dachte ich je: „Das muss ein Rockstar-/Ninja-/Buzzword-Entwickler gewesen sein“

• Offenbar müssen wir jetzt nicht nur den Müll wegräumen, den Chatbots über unsere Köpfe kippen, sondern auch noch hinter Menschen herräumen, denen das egal ist.
  Ich warte nur darauf, dass die Blase platzt

  • Eigentlich war es schon immer so, und AI verstärkt das Problem nur. Andererseits kann man auch sagen, dass das Aufräumen leichter geworden ist

• Wenn man 2026 zu einer Firma stößt und feststellt, dass dort noch create-react-app verwendet wird, frage ich mich, was dann tatsächlich das empfohlene Verhalten ist. Soll man einfach gar nichts sagen?

  • Bei einem neuen Projekt kann man einfach sagen, dass es inzwischen deprecated ist und nicht mehr empfohlen wird.
    Bei einem älteren Projekt hat man eben technische Schulden entdeckt. Die hat jeder. Der beste Weg, Leute davon zu überzeugen, so etwas zu beheben, ist eine geschäftlich nachvollziehbare Begründung. Ist es wirklich ein Risiko, wenn es funktioniert? Welche Priorität hat es im Vergleich zu anderen technischen Schulden? Welche impliziten Risiken nimmt man in Kauf, wenn man nicht upgraded? Wie viel Aufwand erfordert das Upgrade?
    Wenn der Aufwand gering ist und die Kollegen es auch wollen, kann man es manchmal einfach tun, ohne vorher um Erlaubnis zu bitten. Am besten funktioniert das allerdings, wenn man die Unterstützung der Betroffenen hat und es die eigene Arbeit nicht behindert. In der ersten Woche im neuen Job ist es vielleicht nicht das Richtige.
    Im Allgemeinen ist es fast immer besser, zu fragen und herauszufinden, warum die Dinge aktuell so sind, statt zu sagen, „wie es sein sollte“. Jede Codebasis mit Geschichte ist das Ergebnis von tausenden Entscheidungen, die man noch nicht kennt. Man sollte sich mit Wissen und Empathie wappnen
  • Wenn ich neu dazustoße, beobachte ich lieber erst einmal, bevor ich alles aufzähle, was anders gemacht werden sollte. Es gibt ein Gleichgewicht zwischen allem, was ein neues Teammitglied ändern will, und dem Fokus auf Dinge, die tatsächlich Wirkung haben. Direkt nach dem Einstieg weiß man noch nicht, was diese Wirkung hat
  • Das hängt davon ab, welchen Kampf man sich aussucht. Ich persönlich halte es nicht für lohnend, aber ich bin nicht du. Legacy-Code gibt es überall, und die Kosten, ein Framework wie create-react-app hinter sich zu lassen und neu zu schreiben, sind viel höher als die Kosten, dabei zu bleiben, womit die Leute bereits vertraut sind
  • Ich bin kein Webentwickler, daher: Was genau bedeutet diese Frage? Dass create-react-app veraltet ist, oder dass React veraltet ist?
  • Ich wollte nur mitteilen, dass ich mich extrem bestätigt fühle, dass die Leute CRA jetzt hassen.
    Ich habe es schon gehasst, als es 2020 noch cool wirkte

• Dass „ein Agent sich an nichts erinnert, was er gestern getan hat“, ist ein lösbares Problem. Man kann etwa Memory-Ansätze verwenden. Das ist nicht universell gut, wird aber allmählich besser.
  Dass „es dem System egal ist, ob dieser Code gut zum restlichen Code passt“, deckt sich nicht mit meiner Erfahrung. LLM-generierter Code neigt meist dazu, dem ähnlichen Code im relevanten Bereich ziemlich stark zu ähneln. Der Code, den es zur Orientierung gelesen hat, spiegelt sich oft fast direkt wider.
  Auch „es kümmert sich nicht darum, ob das System dadurch leichter oder schwerer verständlich wird“ ist lösbar. Man kann das von einem LLM bewerten lassen und den Wert schrittweise senken. Was leicht verständlich ist, ist oft eine nichtdeterministische Eigenschaft eines Systems, weshalb ein LLM paradoxerweise leichter zu messen sein kann als andere Werkzeuge. Man kann etwa in einer neuen Session fragen: „Wie viel des Systems muss man verstehen, um diesen neu hinzugefügten Code zu verstehen?“, und dann darauf optimieren, diesen Umfang zu verkleinern.
  Der Teil „AI hat einen Werkzeugkasten mit Best Practices, die hier vielleicht nicht passen“ erinnert mich daran, dass die Arbeit mit AI oft dem Anlernen eines Junior-Entwicklers ähnelt, der mit denselben Idealvorstellungen in ein neues Projekt kommt. Einem Junior erklärt man Dinge verbal und hofft, dass er dieses Wissen behält und anwendet; bei AI dokumentiert man es in Dateien wie AGENTS.md / CLAUDE.md, und dieses Wissen bleibt erhalten.
  Dass „man bei einer Code-Review-Anfrage jede Menge Verbesserungsvorschläge bekommt, denen man nicht zustimmt“, ist bei Codex so abgestimmt, dass die Liste klein, prägnant und wertvoll bleibt. Andere Modelle können anders sein, aber letztlich ist auch das ein Problem auf Instruktionsebene. Dinge, die einem wichtig sind, lohnen sich oft zu dokumentieren, und mit AI wird das notwendig

• Die Hälfte des Problems im Umgang mit Rockstars ist zwar das Ego, aber selbst ein Rockstar, der von Menschen geschriebenen Code hinterlässt, hatte noch Reflexion und Absicht dahinter.
  Dagegen haben „Rockstars“, die nur eine menschliche Hülle über AI ziehen, denselben oder noch größeren Bluff, wissen aber oft nicht einmal über die Hälfte der Probleme wirklich Bescheid, die sie angeblich lösen

• Wenn man den funktionalen Programmieransatz so weit wie möglich anwendet und kontextunabhängige Komponenten baut, die sich auf unterschiedliche Weise zusammensetzen lassen, gewinnt man erheblichen Hebel.
  Wenn man einzelne Bausteine, die Implementierungsdetails abstrahieren, von Aufgaben trennt, die vom konkreten Kontext abhängen, kann man diese Bausteine leicht neu anordnen, wenn sich Anforderungen ändern oder man einen anderen Ansatz wählt. Außerdem kann man über jedes Teil unabhängig nachdenken, ohne den gesamten Bereitstellungskontext zu kennen, und aus der Art, wie die Teile zusammengesetzt sind, die Logik auf höherer Ebene verstehen.
  Funktionale Sprachen bieten eine gute Grundlage für die Arbeit mit LLMs, weil sie einen auf natürliche Weise dazu bringen, Code so zu schreiben, dass der Kontext begrenzt wird. Das hilft sowohl dem Modell als auch menschlichen Nutzern, weil es den Umfang reduziert, der zum Verständnis einer bestimmten Programmfunktion nötig ist