Was passiert hier gerade?

• In der Softwarebranche verschärft sich der Burnout unter Engineers, insbesondere weil Junior Engineers AI-Tools missbräuchlich nutzen und dadurch Probleme bei Codequalität und Zusammenarbeit verursachen
• Feedback von Senior Engineers wird nicht als Lernchance genutzt, sondern als neuer Prompt an die AI weitergereicht, und von „AI geschriebener Code“ verbraucht die Review-Kapazität des gesamten Teams
• In manchen Organisationen wird von AI erzeugter, unvollständiger Code wie ein „Erfolg“ inszeniert und präsentiert, wodurch eine Atmosphäre entsteht, die AI-Abhängigkeit fördert
• Der Autor berichtet aus eigener Erfahrung, dass er beim Erhalt von AI-generierten Code-Antworten Unbehagen und Befremden empfand, und kritisiert, dass AI vielmehr die Lern- und Mentoring-Kultur beschädigt
• Auch das Ökosystem der AI-Startups ist letztlich wegen Unwirtschaftlichkeit, Stromverbrauch und Umweltproblemen nicht nachhaltig, und die aktuelle Lage sei kaum etwas anderes als der Betrug vom „nackten Kaiser“

---

Einleitung: Eine verunsichernde Engineering-Umgebung

• Unter Engineers hat sich zuletzt das Burnout-Phänomen verschärft
• In Organisationen wird von Senior Engineers faktisch erwartet, „Vibe-/Meme-basierte Features“ zu prüfen und dazu beizutragen, obwohl sie nicht wirklich funktionieren
• Meiner Erfahrung nach wollen die besten Engineers neuen Teammitgliedern stets mit großem Engagement helfen, sich weiterzuentwickeln

• Doch statt dieses Feedback als Wachstumschance zu nutzen, verwenden Junior Developers es nur als den nächsten Prompt für generative AI
• Tatsächlich habe ich viele Fälle direkt beobachtet, in denen Junior Engineers LLM-Tools (Large Language Models) in einem Ausmaß nutzen, das an Missbrauch grenzt

Reale Fälle in Organisationen: Die Schäden des AI-Missbrauchs

• Kürzlich sah ich bei einem firmenweiten Town Hall zu, wie Junior Engineers neue Arbeitsergebnisse präsentierten
• Sie schienen weder den Zweck noch die Funktionsweise der Features richtig zu verstehen
• Doch in großen Organisationen konzentriert man sich oft darauf, „Erfolg“ zu inszenieren – unabhängig vom tatsächlichen Ergebnis
• Als ein Senior Manager ihre AI-Nutzung offenlegte, erklärte er selbstbewusst: „Das sind 4.000 Zeilen Code, die Claude geschrieben hat“, und erhielt Applaus

• Auch ich sollte eine kleine Verbesserung an einer bestehenden Funktion prüfen und bat den Junior Engineer, der den letzten Change gemacht hatte, um Kontext
• Ich schickte die GitHub-Commit-URL und stellte Fragen, doch vermutlich wurde der Inhalt in ein LLM eingegeben und anschließend die zurückgegebene Antwort einfach kopiert und an mich gesendet
• Dabei stellte sich bei mir ein eigenartiges Gefühl von Befremden und Unbehagen ein

Die AI-Rutschbahn und die Grenzen von Code Reviews

• Anhand des Falls eines Freundes wurde deutlich, dass tatsächlich einen Monat lang mehrere Engineers Zeit damit verschwendeten, von einem LLM automatisch erzeugten Code (vibe-coded PRs) zu reviewen und zu mergen
• Ein anderer Freund schilderte, wie ihn das wiederholte Review von „schlampigem Code“ aus AI-Erzeugung zermürbt hat
• Dank AI verbessern sich weder Codequalität noch Lernen, stattdessen nimmt nur die monotone Wiederholungsarbeit zu

Der wahre Wert von Entwicklungskultur und menschlichem Wachstum

• Jeder Engineer wächst Schritt für Schritt dank Kolleginnen, Kollegen und Mentoren
• Direkt zu lehren und Menschen wachsen zu lassen, ist das Wesen der Software-Engineering-Kultur
• Doch angesichts einer Realität, in der solche Investitionen sofort als Trainingsdaten für das „neueste Modell“ kopiert werden, stellt sich Ernüchterung ein
• Daraus ergibt sich die grundsätzliche Frage, ob man dann nicht gleich lieber das Modell statt Junior Engineers trainieren sollte

• Eine solche Welt ist eine äußerst düstere Vision.

Ein Experiment ohne AI und ein Fazit

• Ganz konkret wird das Experiment vorgeschlagen: „Hör auf, AI zu benutzen.“
• Der Autor selbst hat beim jüngsten Zurücksetzen seines Computers sein Claude-Pro-Abonnement gekündigt
• Einige Suchen, Stack Overflow und das Lesen offizieller Dokumentation führten vielmehr zu deutlich verlässlicheren Schlussfolgerungen
• Ich kam zu der Überzeugung, dass mein eigenes Urteilsvermögen der Ausgabe eines LLM in Genauigkeit und Verlässlichkeit überlegen ist.

Der wirtschaftliche Wert generativer AI-Tools und ihre grundsätzlichen Grenzen

• Es wird die Frage gestellt: „Ist AI überhaupt wirklich nützlich?“
• Objektiv betrachtet gibt es erhebliche Zweifel an ihrem Wert
• Der typische Ablauf bei AI-Startups sieht so aus:
  • „AI“ wird auf einen bestehenden Bereich angewendet, und unter dem Vorwand von Effizienz entsteht ein neues Startup
  • Das AI-Startup wirbt erfolgreich Venture-Capital-Investitionen ein
  • Es zahlt Nutzungsgebühren an AI-Dienstleister (wie OpenAI)
  • Das AI-Startup selbst erzielt keinen Gewinn
• Für sich genommen unterscheidet sich dieser Ablauf nicht stark vom bisherigen VC-Ökosystem, doch der entscheidende Unterschied ist, dass selbst die Dienstleister (wie OpenAI) bislang keinen Gewinn erzielen
• Die Technologie selbst ist inhärent ineffizient und strukturell ungeeignet für massive Skalierung
• Auch der übermäßige Stromverbrauch und die ökologischen Nebenwirkungen sind ein ernstes Problem

Schlusswort: Die Notwendigkeit, die Realität anzuerkennen

• Man kann hoffen, dass Moores Gesetz zurückkehrt oder alle reich werden, bevor das Universum auskühlt
• Doch wenn man der Realität ins Auge sieht, ist das Geschäft mit generativer AI eine Art Illusion und ein Fall vom „nackten Kaiser“

[ahwjdekf]

Die Sorge, dass die Menschheit nach einem Weltkrieg mit Atomwaffen, dem technologischen Höhepunkt, wieder in die Steinzeit zurückfallen würde, ist im Bereich der Softwareentwicklung derzeit bereits Realität.

[dicebattle]

Es scheint, als müsste man nur mit dem übertriebenen Vibe-Coding aufhören. Als Assistent und beim Schreiben mancher detaillierter, aber einfacher Algorithmen ist das kaum zu übertreffen.

[GN⁺]

Hacker-News-Meinungen

• Es wird betont, dass die Einführung von AI in Organisationen nicht einfach ein technisches Problem ist, sondern ein Thema des Change Managements. Erst wenn ein fähiges Team auf Basis von Vertrauen und Transparenz Prozesse schafft, die menschliche Expertise und die Stärken von LLMs ausgewogen verbinden, entsteht ein echter Effekt. Es gibt auch Fälle, in denen kleine Teams mit AI große Ergebnisse erzielen. Doch die meisten Organisationen, insbesondere Großunternehmen, verfügen nicht über eine gesunde Organisationskultur, sodass AI diese Toxizität eher noch verstärkt. Unter Führungskräften gibt es auch Fälle, in denen „Story Points“ schlicht als Zeiteinheit missverstanden werden und AI nur als Werkzeug gesehen wird, das alles halbieren soll. Grundsätzlich ist das von dem eigentlichen Prozess, wartbare Software zu bauen, abgekoppelt, und AI wird nur als Abkürzung zu mehr Gewinn verstanden. Auch das Forschungsergebnis, dass 95 % der jüngsten AI-Pilotprojekte keinen ROI erreicht haben, zeigt als Beispiel die Unfähigkeit des modernen Managements

  • Es wird darauf hingewiesen, dass AI vielleicht einfach überbewertet ist. Es wird gefragt, von welchen konkreten Teams eigentlich die Rede ist, wenn behauptet wird, „kleine Teams erzielen mit AI große Ergebnisse“
  • Es wird Müdigkeit gegenüber der Haltung geäußert, den Problemen von AI mit „das waren doch nur schon vorher bestehende Probleme“ einen Freispruch zu geben. Auch die durch AI verursachte Verschlechterung der psychischen Gesundheit oder Probleme der Organisationskultur seien dem Werkzeug selbst mit anzulasten. Entgegen der Vorstellung, Werkzeuge und Systeme seien verantwortungslos, wird angenommen, dass auch Werkzeuge und Umgebungen Einfluss ausüben
  • Es wird bedauert, dass zur Behauptung „kleine Teams schaffen große Dinge“ nur Erfolgsgeschichten ohne konkrete Beispiele erzählt werden
  • Die Einführung von AI in eine ohnehin schon kaputte Management-Organisation wird damit verglichen, einer Wikingerhorde Sturmgewehre in die Hand zu drücken. Das beschleunige nur den Zeitpunkt des Zusammenbruchs der Organisation. Es wird betont, dass nicht die Technologie der Kern des Problems ist, sondern das soziale und ethische Versagen vieler Beteiligter (oder einiger weniger zentraler Manager)
  • Es wird erwähnt, dass viele Führungskräfte „Story Points“ als Zeit missverstehen, und dass man diesen Fehler bisher in allen Rollen erlebt habe, denen man begegnet sei (Entwicklung, QA, PM, Führungsebene)

• Es wird über das Aufkommen von „Prompstitudes“ gesprochen, also Angestellten, die sich nur auf Prompts verlassen. Ein Kollege habe einmal nur eine ChatGPT-Antwort weitergereicht, die angeblich die eigene Meinung erraten habe, und das habe sich wie das im Artikel beschriebene „Gefühl des Übergriffs“ angefühlt. Diese Leute wirkten nicht unbedingt unfähig, sondern eher zu abhängig von LLMs, wie alte Menschen in einem Casino, die nur immer weiter am Spielautomaten ziehen

• Es wird von einer jüngsten Erfahrung berichtet, bei einem Gespräch mit einem Kollegen ein ungutes Gefühl gehabt zu haben, offenbar weil klar war, dass das Ergebnis direkt von ChatGPT zurückkam. Man hätte es fast besser gefunden, ignoriert zu werden. Besonders problematisch sei gewesen, dass das LLM mit großem Selbstvertrauen Falsches behauptete. Schon kleine Details, etwa leicht unterschiedliche Namen in Konfiguration und Implementierung, könnten ein LLM völlig verwirren. Anders als Menschen lerne oder bemerke ein LLM seine Fehler nicht, sodass es dauerhaft in eine falsche Richtung weiterdrifte. Emotional sei es fast angenehmer, sich mit schlechtem menschlichem Code herumzuschlagen

  • Man habe früher mit einem PM gearbeitet, der PRDs mit AI schrieb. Wenn man nach dem Inhalt fragte, habe er geantwortet: „Ich weiß es nicht, die AI hat es geschrieben.“ Am Ende habe der PM die eigentliche Vermittlung von Ideen aufgegeben und nur noch Dokumentations-Performance betrieben. Das Verstehen und Interpretieren der Anforderungen sei komplett zur eigenen Aufgabe geworden, weshalb man das Team verlassen habe
  • Es wird Zustimmung zu der Aussage geäußert, dass „LLMs mit Selbstvertrauen falsch liegen“. Wie charismatische Kollegen, die so tun, als wüssten sie Bescheid, sagten LLMs oft plausibel klingende, aber falsche Dinge
  • Diese Woche habe man eine sehr seltsame Erfahrung gemacht. Man ließ Claude einen internen Vorschlag zu einer Fachspezifikation prüfen, die man selbst auch nicht gut kannte, und es zeigte viele Fehler auf. Als man das der zuständigen internen Person für diese Spezifikation mit dem Hinweis weitergab, „das stammt von einem LLM und könnte Unsinn sein“, habe diese Person wiederum die eigene Nachricht in ein LLM eingegeben, dessen Antwort zurückgeschickt und nachgefragt. Am Ende habe man das Gefühl gehabt, dass wir alle nur noch als Assistenten der AI arbeiten. Wenn das die Zukunft der Softwareentwicklung sei, sei das nicht attraktiv
  • Schlechter menschlicher Code sei viel besser als schlechter LLM-Code. Bei menschlichem Code könne man zumindest den Kontext erschließen, also was versucht wurde. Dagegen sei von LLM erzeugter Code manchmal von Anfang bis Ende kaputt und erfinde sogar Funktionen oder Konzepte, die gar nicht existieren. Menschen schrieben normalerweise keinen so weit von der Realität entfernten Code. Um LLM-Code zu verstehen, müsse man fast die gesamte Codebasis neu lernen
  • Zur Formulierung, ein LLM „glaube, dass es keine Fehler macht“, wird angemerkt, dass ein LLM von vornherein nichts glauben, denken oder fühlen könne. Es reiht nur statistisch die wahrscheinlichsten Sprach-Token aneinander und fügt etwas Zufall hinzu, um Kreativität zu imitieren

• Zur Frage „Sind AI-Tools wirklich nützlich?“ wird gesagt, dass sie aus eigener Sicht helfen, weil man sie anders nutzt als andere. Man entwickle seit 1983 und sei heute im Ruhestand, arbeite also oft allein. Es seien viele Tools ausprobiert worden, inzwischen nutze man aber nur noch ChatGPT und Perplexity. Man lasse sie nicht direkt den Code schreiben, sondern verwende den vom LLM vorgeschlagenen Code als Referenz und Ausgangspunkt. Manchmal werde er ganz übernommen, meistens folgten jedoch Anpassungen und Umschreibungen. Wenn das LLM zunehmend schlechtere Ergebnisse liefere, breche man einfach ab und probiere einen neuen Ansatz. Bei dem Gedanken, dass ein unerfahrener Engineer einfach nur LLM-Code übernehme, bekomme man Angst. Der größte Wert sei das Gefühl eines „StackOverflow, das sofort antwortet“. Man könne jede noch so dumme Frage ohne Scham stellen und schnell eine brauchbare Antwort bekommen. Kürzlich habe man beim Lernen der PassKey-Implementierung unter iOS direkt mit Beispielcode von ChatGPT als Ausgangspunkt begonnen und ihn Zeile für Zeile verstanden. Der zuerst geschriebene Code und die heutige fertige Version seien völlig unterschiedlich, und durch diesen Prozess sei das technische Verständnis tiefer geworden

  • Man nutze AI genauso. Ein persönliches Projekt, von dem man anfangs gar nichts verstand, sei fast abgeschlossen, und inzwischen verstehe man die Codebasis gut genug
  • Man gehe bei kleinen Aufgaben oder privaten Projekten ähnlich vor. Das LLM schreibe zunächst den „Wegwerf-Code“, und durch das Erkunden seiner Grenzen verstehe man die Problemdomäne besser. Am Ende könne man mit mehr Selbstvertrauen selbst implementieren

• Es wird empfunden, dass LLMs sehr gut darin sind, technische Fragen zu beantworten oder neue Ansätze vorzuschlagen. Auch Anfänger könnten frei fragen, ohne wie bei Stack Overflow bewertet zu werden oder an Wände zu stoßen. Copilot sei stark bei der Autovervollständigung und erhöhe die Schreibgeschwindigkeit von Code, Dokumentationskommentaren oder Codezeilen. Solche kleinen Hilfen ließen sich leicht überprüfen. Wenn man einem LLM jedoch komplexen Code komplett überlasse, entstehe Chaos, und man lande eher beim endlosen Debugging. Wenn Anfänger sich zu stark auf LLMs verlassen, werde es schwer, echte Entwicklungsfähigkeiten aufzubauen

• Persönlich nutze man Zed für Hobbyentwicklung, weil AI dort nicht übertrieben auf schlau macht. AI-Funktionen ließen sich bei Bedarf sanft aufrufen, und ansonsten programmiere man einfach selbst. Bei der Arbeit störe VSCode AI dagegen viel zu oft. Es gebe zwei Probleme: Erstens sei die Interaktion zu fragil (Klicks auf Pop-ups, versehentlich eingefügte riesige Autovervollständigungen), zweitens werde der Flow unterbrochen. AI-Autovervollständigung sei manchmal nützlich (ungefähr in einem Drittel der Fälle), aber in der restlichen Zeit werde der eigene Gedankengang gestört und die Konzentration leide, weil man das AI-Ergebnis prüfen müsse. Mit Zed gebe es dieses Problem nicht, weshalb man das Vergnügen am Programmieren wiedergefunden habe. Letztlich liege das Problem weniger in der AI-Funktion selbst als in ihrer Umsetzung

  • Auch hier gibt es starke Zustimmung zu Zed. Nach Spielereien mit JupyterLab oder Kate habe sich das geändert, seit man Zed benutze. Bei Zed stünden IDE bzw. Editor im Mittelpunkt, während Zusatzfunktionen wie AI oder Jupyter-Kernel nur bei Bedarf leise unterstützten. Diese Extras störten das eigentliche Editieren und Codieren nicht. Das Zed-Team habe hier eine gute Balance gefunden

• AI sei sehr nützlich, um UX-Prototypen zu erstellen. In kurzer Zeit könne man sofort klickbare Ergebnisse bauen, mehrfach iterieren, die Richtung festlegen und den Code später verwerfen und neu entwickeln. Das helfe, nicht früh viel Zeit in eine falsche Richtung zu investieren. Allerdings sei es noch weit davon entfernt, mit AI eine ganze sinnvolle App am Stück zu bauen

  • In Bereichen, mit denen man sonst wenig zu tun habe, etwa PowerShell-Skripte, sei AI sehr hilfreich. Früher habe man einmal ein Skript für einen Bericht über Registry-Einstellungen gebraucht, und Claude habe es perfekt geschrieben, wodurch eine Stunde gespart wurde
  • Auch hier empfindet man AI als hervorragend darin, Fehler zu erklären. Sie helfe oft, eine genaue Lösung zu finden oder auf neue Ideen zu kommen
  • Es wird betont, dass „den Prototyp wegwerfen und neu entwickeln“ wichtig sei, doch in der Realität vergäßen PMs diesen Teil oft, sodass Prototypen in den echten Produktivbetrieb gelangten. Trotzdem sei es gut, wenn jemand eine funktionierende eigene Nutzungsweise gefunden habe
  • Es wird nach mehr Details zu diesem Use Case, dem Prozess und den Tools gefragt, weil das auch der eigenen Person und dem Team praktisch helfen könnte

• AI sei für die eigene Person nur ein Werkzeug. Man sei kein High-Level-Entwickler, nutze AI aber in privaten Projekten, um sich bei Blockaden Ideen und Feedback zu holen. Wichtig sei, dass man das Schreiben des Codes nicht der AI überlasse, abgesehen von sehr einfachem Boilerplate. Der Grund, selbst zu coden, sei die Freude am Problemlösen, am Schaffen und am Lernen

  • Ein jüngstes Projekt hätte man ohne von AI direkt geschriebenen Code nicht fertigstellen können. Von der Einrichtung des gesamten Repositorys bis zum PoC sei es damit trotz holpriger Qualität überhaupt erst machbar geworden. Ohne Erfahrung mit Django, JS und Webentwicklung habe man dank AI zunächst zwar nichts Sauberes, aber ein funktionierendes Ergebnis erhalten und verbessere es nun schrittweise, während das Verständnis wächst

• Bei einer kürzlichen Code-Review eines Kollegen habe man eine komplexe Funktion namens prepareData gesehen, die mehrdimensionale Arrays mischte und filterte. Auf die Frage an den Kollegen, welche Aufgabe das erfülle, habe dieser geantwortet, man solle zur Zeitersparnis einfach ein LLM fragen, was einen fassungslos gemacht habe. Man sei enttäuscht gewesen über eine Haltung, die nicht einmal die grundlegendsten Fragen für eine Code-Review beantworte

  • Es wird halb scherzhaft vorgeschlagen, die Antwort einfach vom LLM zu holen und dem Kollegen zurückzuschicken, und nach 20 Runden Feedback könne man ihm, wenn er es dann immer noch nicht verstehe, ebenfalls sagen, er solle doch ein LLM fragen

• Es wird die Sorge geäußert, dass Berufsanfänger in zehn Jahren Senior-Entwickler werden wollen, ohne je selbst Code geschrieben zu haben

  • Tatsächlich habe dieses Phänomen schon vor AI begonnen. Ohne mehr als zehn Jahre Erfahrung sei eine Anstellung oft kaum möglich gewesen, und die Branche habe beim Up-Skilling der jüngeren Generation versagt. Selbst wenn Unternehmen konsequent Berufsanfänger ausbilden wollten, würden in Krisen zuerst sie entlassen und danach in Eile wieder nur Seniors eingestellt, wodurch sich ein Teufelskreis wiederhole
  • Mit einem scherzhaften Ton wird erwähnt, dass man inzwischen schon mit drei Jahren Erfahrung Senior sein könne und in nur drei statt zehn Jahren schnell Staff Developer werde
  • Das Konzept des „Vibe Coding“ sei vor neun Monaten aufgekommen, und es wird die Aussicht geäußert, dass Menschen in weniger als zwei Jahren womöglich keinen Code mehr selbst schreiben oder warten werden
  • Trotzdem werde es immer Software geben, die von Entwicklern mit echter Expertise geschrieben wurde, und solange LLM-Code nicht perfekt sei, werde die Nachfrage nach hochwertigem Code bestehen bleiben
  • Es gebe zu viele Junior-Entwickler und nicht genug lohnende Probleme, an denen sie echte Erfahrung sammeln könnten, weshalb der Aufstieg in die nächste Stufe schwer sei. Früher konnte man ihnen zumindest günstig PoCs oder Skriptarbeit geben, aber da AI solche Rollen nun passabel ausfülle, würden die Chancen kleiner. Ergänzend wird gesagt, dass es auch damals schon viele Juniors und zu wenige Stellen gegeben habe

[happyiminjay]

In der frühen Entwicklungsphase sind KI-Tools beim Einrichten der Umgebung und bei der Entwicklung von Modulen in kleinen Function-Einheiten sehr effektiv, aber abseits davon ist Vibe Coding, bei dem man einfach Code und Prompts hineinhaut, aus Sicht der Wartbarkeit eine Katastrophe. Die ersten paar Male mag es noch funktionieren, doch letztlich muss man jedes Mal, wenn ein Problem auftritt, N-mal versuchen, bis die KI ihr eigenes Problem löst, und die Angst bleibt bestehen, nicht zu wissen, welche anderen Bugs diese Lösung möglicherweise auslöst.

[ulsoft]

Je nach Fähigkeit des Entwicklers
Wenn jemand mit solidem Fundament damit arbeitet, kann er mithilfe von AI hochwertige Entwicklung leisten,
fehlt dieses Fundament, gerät alles aus dem Ruder.
So wie der Unterschied bei einem Koch mit und ohne Grundkenntnisse.