Die Illusion hinter den Behauptungen zum AI Coding: Warum es keine Explosion von Shovelware gibt

• Jüngste Datenprüfungen zu Behauptungen über Produktivitätssteigerungen durch AI-Coding-Tools zeigen, dass weder Geschwindigkeit noch Output tatsächlich spürbar zunehmen
• Laut einer METR-Studie glaubten Entwickler, dass AI-Coding-Tools ihre Produktivität um 20 % steigern würden, tatsächlich sank sie jedoch um 19 %
• Zahlreiche Werbeaussagen sowie überzogene Behauptungen von Unternehmen und Entwicklern über eine 10-fache Produktivität spiegeln sich weder in der Marktrealität noch bei neuen Software-Releases wider
• Phänomene wie ein starker Anstieg von Shovelware (in Massen produzierte Apps, minderwertige Software) sind nicht zu beobachten; sichtbare Veränderungen bleiben aus
• Übertreibungen bei der Produktivität durch Unternehmen wie GitHub, Copilot, Cursor, Google und OpenAI sowie durch einige Entwickler werden für Investitionen, Umstrukturierungen und Gehaltsfestsetzungen missbraucht
• Zentrales Fazit: „Solange nicht tatsächlich mehr Software entsteht, ist die Behauptung, AI Coding mache Entwickler 10-mal produktiver, eine Fiktion“. Entwickler sollten sich daher nicht unter Druck setzen lassen, sondern mit Daten argumentieren

---

Einleitung: Softwareentwickler sind wütend auf AI Coding

• Als langjähriger Softwareentwickler verbindet der Autor mit dem Programmieren Stolz und Identität
• Bei der frühen Einführung von AI-basierten Coding-Tools war die Erwartungshaltung hoch, doch neuere Forschungsergebnisse (METR) haben Skepsis geweckt
  • Der Autor selbst dachte, AI Coding mache ihn etwa 25 % schneller, doch die METR-Studie kam stattdessen auf 19 % Verlangsamung
• Die Studie zeigt, dass die von Entwicklern subjektiv empfundene Effizienz von AI-Tools dem gemessenen Ergebnis genau entgegengesetzt ist
• Auch eigene Experimente vermittelten den Eindruck, dass der Einsatz von AI keinen positiven Einfluss auf die tatsächliche Programmierzeit hat

Eigene Überprüfung: Zufallsvergleich mit und ohne AI

• Es wurde eine Methode genutzt, bei der pro Arbeitseinheit die Zeitdifferenz (Delta) zwischen Aufgaben mit und ohne AI-Einsatz gemessen wurde
• Die in einem sechswöchigen Experiment gewonnenen Daten zeigten keinen statistisch signifikanten Unterschied
• Trotz kleiner Stichprobe zeigte sich sogar die Tendenz, dass der Einsatz von AI tatsächlich 21 % langsamer machte (derselbe Wert wie in der METR-Studie)
• Gäbe es wirklich einen 2-fachen oder 10-fachen Effekt, hätte sich das in den Daten klar zeigen müssen
• Der aktuelle Traum vom AI Coding erfüllt sich nicht; in der Praxis ist keine Veränderung zu sehen

Erwartung und Realität: Warum es keine Shovelware-Explosion gibt

• Wenn die Produktivitätsrevolution durch AI Coding real wäre, müssten Apps, Services und Spiele aller Art explosionsartig zunehmen
• Die Marketingbotschaften zahlreicher AI-Coding-Tools (etwa „Built to make you extraordinarily productive“) sind allgegenwärtig
• Auch Google, OpenAI und GitHub Copilot behaupten 25 % mehr Geschwindigkeit oder eine 10-fache Produktivität für Entwickler
• Doch in den realen Daten zu neuen Software-Releases (GH Archive, BigQuery usw.) gibt es weder steiles Wachstum noch explosionsartige Zunahmen
• Trotz der breiten Verfügbarkeit von AI Coding seit 2022 zeigen die weltweiten Zahlen zu neuen Releases und Projekten keine großen Veränderungen

Marktauswirkungen und die Realität der Entwickler

• Es zeigen sich bereits gesellschaftliche Folgen innerhalb der Branche, etwa AI-First-Strategien, FOMO, Massenentlassungen und sinkende Entwicklergehälter
• In der realen Entwicklungsarbeit liefern AI-Tools keine Produktivitätsrevolution
• Auch Lernkurven oder größere Tool-Erfahrung erklären keinen absoluten Produktivitätsunterschied

Fazit: Nüchterne, datenbasierte Urteile sind nötig

• Entscheidend ist, dass sich bislang keine Veränderung bei der Menge neu ausgelieferter Software in den Daten erkennen lässt
• Für die Behauptung, AI mache aus Entwicklern 10x-Coder, gibt es keine Belege
• Entwickler sollten dem Druck nicht nachgeben und ihre Tool-Auswahl auf Basis selbst überprüfter Daten treffen

Erwiderungen auf häufige Gegenargumente

1. „Wenn man Prompting richtig beherrscht, wird man zum 10x-Entwickler“

   • Wenn tatsächlich Menschen eine 10-fache Produktivität erreicht hätten, müsste sich die weltweite Produktion neuer Software mehr als verdoppelt haben
   • Wichtiger als Behauptungen sind objektive Ergebnisse (Apps, Projekte usw.) als Beleg

2. „Es ist noch früh, das braucht Zeit“

   • Es wurden bereits Milliarden investiert, und die Tools sind in der Praxis längst im Einsatz
   • Die heutigen Entscheidungen beeinflussen das Leben realer Menschen direkt

3. „Wer jetzt nicht einsteigt, fällt zurück“

   • Selbst in GitHub-Copilot-Daten ist der tatsächliche Produktivitätszuwachs durch steigende Routine äußerst gering (29 % → 34 % Akzeptanzrate)

4. „Die Qualität ist besser geworden, nur die Menge bleibt gleich“

   • Die Gesamtqualität in der Branche ist eher zurückgegangen, und es wird auch weniger getestet
   • Wäre es wirklich ein Tool für 10x-Coder, müsste eine Flut von Shovelware längst Realität sein

5. „Alles dreht sich um Websites, und Domainnamen interessieren heute kaum noch. Subdomains bei Anbietern wie Vercel sind alles“

   • Es gibt weiterhin viele Nutzer, die eigene Domains bevorzugen

6. „Der Boom bei .ai-Domains (47 % in diesem Jahr) zeigt doch reales Wachstum“

   • Der Anstieg neuer Domains ist nur auf Pivots von AI-Startups zurückzuführen, nicht auf eine Explosion der Gesamtzahl neuer Domains
   • Die Gesamtzahl aller Domains zeigt das nicht

7. „Die Essenz von Entwicklung liegt in Arbeit jenseits des Codes“

   • In Umgebungen von Einzelentwicklern oder kleinen Teams statt großer Konzerne steht Code tatsächlich im Mittelpunkt
   • Trotzdem gibt es weiterhin keinen auffälligen Anstieg neuer Projekte, die kleinere Coding-Bedürfnisse befriedigen

Schluss

• Entwickler veröffentlichen in der Praxis nicht mehr als zuvor
• Die Behauptung, AI Coding liefere eine 10-fache Produktivität, lässt sich mit Daten widerlegen
• Statt sich von FOMO und Marketing-Narrativen der Branche treiben zu lassen, sollte man anhand realer Ergebnisse bewerten
• Botschaft des Autors: „Wenn du Druck spürst, zeig Daten und Diagramme. Verlange Belege für Behauptungen über 10-fache Produktivität.“

[ahwjdekf]

Für einen 10x-Entwickler ist mit Hilfe von AI vielleicht ein Sprung auf etwa 12x möglich.

[overthetop]

KI ist eine Illusion. Nicht vertrauenswürdig und qualitativ minderwertig. Die Behauptung, man könne mit KI entwickeln, ist eine übertriebene Lüge. Unmöglich. Und KI zu verwenden ist ein unverantwortliches Verhalten, bei dem Entwickler ihre Ethik aufgeben.

[nemorize]

Wenn man einfache Routinearbeiten vollständig der KI überlassen und sich ganz auf wichtigere Aufgaben konzentrieren könnte, dann könnte man wohl sagen, dass KI die Produktivität beim Schreiben von Code deutlich steigert.

Wenn man einmal einen Befehl absetzt, kommt die Ausgabe erst nach einigen Dutzend Sekunden Wartezeit; diese Zeit kann man auch nicht sinnvoll nutzen, und es ist ja auch nicht so, dass nach diesen paar Dutzend Sekunden immer ein perfektes Ergebnis herauskommt.

Letztlich muss ich also weiter aufmerksam bleiben, bis selbst diese einfache Aufgabe vollständig erledigt ist, und kann auch nicht zu einer anderen Aufgabe wechseln ... daher war es für mich schwer, eine wirklich spürbare Verbesserung zu erwarten.

[nemorize]

Für die Produktivitätssteigerung schien es mir eher hilfreicher zu sein, über Karrot jemanden für einfache Arbeiten für ein paar Stunden zu engagieren und 10.000 Won Stundenlohn zu zahlen.
Schon mit Ausgaben von rund 100.000 Won pro Woche war ich persönlich ziemlich zufrieden.

Ich habe vor allem auch mit einigen Frauen gearbeitet, die früher in der Buchhaltung tätig waren, dann mit der Arbeit aufgehört haben und nun Vollzeit-Hausfrauen sind; selbst Leute, die vom Programmieren überhaupt nichts verstehen, liefern nach ein paar Feedback-Runden sehr sauber gemachte Ergebnisse, haha.
Boilerplate-Code erstellen sie mit Excel per AutoFill, Formeln und Ähnlichem teilweise in Windeseile...

[zxcv123]

Hm … mein ehrlicher Eindruck ist, dass auch AI letztlich nur ein Werkzeug ist und man sie gut einsetzen können muss.
Bei jedem Werkzeug gibt es mehr Menschen, die es nur so halbherzig oder gar nicht richtig nutzen, als solche, die wirklich gut damit umgehen.
Wenn man AI so einrichtet, dass sie qualitativ hochwertige Ergebnisse liefert, zeigt sie absolut überzeugende Performance.
Vielleicht sind es eher die Leute, die nicht wissen, wie man mit AI hochwertige Resultate erzielt, die einfach nur dumme Prompts raushauen und dann behaupten, die Produktivität sei gesunken. Dass man die Produktivität von AI grundsätzlich bestreitet, kann ich wirklich überhaupt nicht nachvollziehen.

[kirrie]

Aber wenn Sie das so sagen, scheint das genauso wenig irgendetwas zu beweisen wie die Aussage: „Jemand, der echte Informatik tiefgehend versteht und ausreichend Erfahrung gesammelt hat, ist produktiver als jede KI.“

[ndrgrd]

Ich habe mir die erwähnte METR-Studie vor Kurzem angesehen, und die Ergebnisse erklären ziemlich gut das, was ich selbst empfunden und hinterfragt hatte.

Selbst wenn man ihr die in den Hacker-News-Kommentaren erwähnten „wiederholenden Aufgaben“ gibt, ist in der Praxis meist dennoch manuelle Prüfung und Korrektur nötig.
Es ist nicht nur ein- oder zweimal vorgekommen, dass ich beim chaotischen Gedankengang eines von der AI erzeugten „einfachen“ Ergebnisses dachte: Ich hätte es besser gleich selbst gemacht.

Wirklich einfache Arbeiten auf dem Niveau von Copy & Paste erledigt sie wahrscheinlich gut.
Aber dafür sind schlicht Copy & Paste und Snippets effizienter. Man muss nicht ins Internet gehen, seine Daten auf fremde Server hochladen und dann jedes Mal mehrere Dutzend Sekunden warten.

[GN⁺]

Hacker-News-Kommentare

• Für mich ist AI wie eine Glockenkurve, und ich denke, für viele andere ist es ähnlich. Entscheidend ist, nach welchem Maßstab man den Output bewertet. Es sollte nicht um die „Anzahl der Codezeilen“ gehen, sondern um die „Anzahl guter, qualitativ hochwertiger, wartbarer, skalierbarer und leicht aktualisierbarer Codezeilen“. Nach diesem Maßstab ist das Ergebnis von Anfragen wie „ein ganzes Repo erzeugen“ bedeutungsloser Müll, aber wenn AI so etwas wie getUser(... automatisch vervollständigt, ist das eine Produktivitätssteigerung. Ob das nun 0,1 %, 1 % oder 10 % sind, kann ich nicht sicher sagen

• Aus meiner Sicht ist das gravierendste Problem, dass die Probleme, mit denen ich mich in der Firma derzeit beschäftige, sorgfältige Planung und Ausführung erfordern, und AI dabei überhaupt nicht hilft. Trotzdem hat unser Manager gesagt, er habe die Projektlaufzeit auf 20 % der ursprünglichen Schätzung reduziert, weil „wir ein AI-first-Unternehmen sind“. Unter SVPs und PMs breitet sich so ein kollektiver Wahnsinn massiv aus, und so etwas habe ich noch nie erlebt

  • Du sagst, der Manager habe die Projektlaufzeit auf 20 % der ursprünglichen Schätzung gekürzt, und ich finde das wirklich absurd. Irgendwer setzt einfach so eine völlig unrealistische Zahl fest und macht sie zur Realität. Wenn es am Ende nicht klappt, wird man die Verantwortung mir zuschieben, und weiter oben wird man dann den Manager verantwortlich machen. Wenn AI die Produktivität wirklich erhöht, kann man überflüssige Entwickler abbauen, aber das ist etwas für den Zeitpunkt, wenn sich LLMs erfolgreich im Entwicklungsprozess etabliert haben. Ich überlege inzwischen sogar, ob ich wegen der AI-Blase Investitionen aus dem S&P 500 abziehen sollte
  • Wenn man sogar das Incident-Handling LLMs überlassen kann, soll der CEO eben bekommen, was er will, und auch den entsprechenden Reputationsschaden in Kauf nehmen. Wenn es scheitert, könnte man einfach git auf den Stand vor dem von LLM geschriebenen Code zurücksetzen. Halb Scherz, halb ernst
  • Das aktuelle Niveau von AI reicht nicht aus, um Entwickler zu ersetzen, aber ich denke, sie ist inzwischen gut genug, um viele Office-Aufgaben oder Manager-Rollen zu automatisieren, die sich früher nur schwer automatisieren ließen. Google hat wegen AI tatsächlich viel Middle Management abgebaut und offenbar Entwickler nicht in gleichem Maß reduziert
  • AI wird als Vorwand benutzt, mit dem Manager ohne technisches Leadership Druck auf Entwickler ausüben

• Mehrere Dinge können gleichzeitig wahr sein. LLMs machen Entwickler bei zufällig ausgewählten, allgemeinen Aufgaben nicht 10-mal produktiver. Gleichzeitig steigern LLMs die Produktivität in bestimmten Aufgabenbereichen dramatisch. Man kann sie auch nutzen, um lästige Routinearbeit zu automatisieren; selbst wenn sie in Echtzeit länger brauchen als ein Mensch, ist das kein Problem, weil die Arbeit im Hintergrund läuft. Beim Erlernen neuer APIs oder Bibliotheken beschleunigen LLMs vieles deutlich, und wenn man kleinen Glue Code in einer unbekannten Sprache schreiben muss, spart man Zeit und muss sich unnötiges Lernen nicht antun — das ist eine enorme Hilfe. Bei der Wartung großer bestehender Codebases spüre ich dagegen kaum Produktivitätsgewinn. Das Scaffolding für eine neue Website setzen LLMs erstaunlich gut auf. Auch Mock-Klassen erstellen sie blitzschnell, ebenso komplexe Aufgaben, bei denen sie den Umgang mit Mock-Bibliotheken gut verstehen und die ich selbst ein- oder zweimal mache und dann wieder vergesse. Beim Verständnis der Struktur einer neuen Codebase liefern sie mir zu etwa 70 % zufriedenstellende Ergebnisse. Auch in komplex designten Projekten ist es praktisch, wenn ich frage: „Hey Claude, wo sind die auth-bezogenen Funktionen?“ — etwa um HTTP-Routen oder Dependency-Injection-Funktionen zu finden. Man muss einfach das richtige Tool für die richtige Aufgabe einsetzen

  • Ich stimme zu, dass man durch LLMs neue APIs oder Bibliotheken viel schneller kennenlernt, aber wenn man sich die Antworten dann genauer ansieht und die Dokumentation selbst liest, ist es beunruhigend, dass sie oft Konventionen nicht einhalten, nur einfache Beispiele zusammendrücken oder falsche Features verwenden, sodass der funktionierende Weg seltsam oder unnötig kompliziert wird. Es fühlt sich wie Magie an, aber wenn man ihnen zu sehr vertraut, verfällt man leicht der Illusion, etwas wirklich verstanden zu haben, obwohl das gar nicht stimmt
  • Mich würde interessieren, was mit „LLMs automatisieren lästige Routinearbeit im Hintergrund“ konkret gemeint ist. Ich finde, AI-Befürworter sollten klar und konkret darlegen, bei welchen Aufgaben das tatsächlich erfolgreich funktioniert. Diese Vagheit ermüdet mich zunehmend
  • Damit die Formulierung „LLMs helfen, neue APIs und Bibliotheken schnell zu lernen“ präziser ist, sollte man sie wohl eher in „wenn man zum ersten Mal mit bereits länger existierenden Bibliotheken oder APIs zu tun hat“ ändern. Bei wirklich neuen Bibliotheken oder Tools helfen LLMs oft kaum

• In Videos sieht man Code auf den Bildschirm strömen, und meistens steckt dahinter nicht mehr als die Behauptung „Junior-Entwickler sind erledigt“. Ich denke, der Grund ist ein Klima voller Übertreibung und Angst, weil die Wirtschaft instabil ist und man hofft, AI werde zum Retter. Tatsächlich erzielt man mit AI manchmal beeindruckende Ergebnisse, aber grundsätzlich ist das bedeutungslos, wenn man nicht selbst ein gewisses Kompetenzniveau mitbringt. Menschen auf Anfänger- bis mittlerem Niveau posten in Social Media nur aufgeblasene Erfolgsgeschichten. Es entsteht eine Stimmung, in der jeder psychologisch und ganz praktisch versucht, seine „AI-Superkräfte“ zu verteidigen. Am Ende bleibt nur, darauf zu warten, dass der Hype-Zyklus irgendwann seinen Gleichgewichtspunkt findet und wieder einige Milliarden Dollar verbrannt werden

  • Nach meiner Erfahrung entfalten AI-Tools ihr Können wirklich bei komplett leeren Projekten, auf einer Blank Canvas. Wenn ich zum Beispiel ein neues React-Projekt anlege, richten die Tools es schneller ein als ich. In echten Arbeits-Repositories sind sie dagegen fast nutzlos. Deshalb machen AI-Tools in Demos und im Marketing einen gewaltigen Eindruck, lassen in der Realität aber vor allem Enttäuschung zurück
  • Ich frage mich, ob man jemand sein muss, der genug Erfahrung hat, um es auch selbst von Hand machen zu können, oder ob man einfach mit AI-Tools und ihren Grenzen vertraut sein muss — oder ob man beides braucht
  • Die überzogenen Geschichten über AI klingen für mich meist wie populärwissenschaftliche Medienartikel, die nur oberflächliche Paper-Abstracts lesen und dann behaupten, das werde bald Realität

• Meiner Erfahrung nach war AI bei einigen kleinen Aufgaben nützlich, etwa bei kleineren Refactorings oder der Automatisierung von Typdefinitionen, aber bei komplexeren Aufgaben darüber hinaus hat sie vieles übersehen und Nacharbeit verursacht. Vielleicht werde ich meine Aussage in Zukunft noch einmal überdenken, aber in letzter Zeit sehe ich immer häufiger, dass weniger erfahrene Engineers die Ergebnisse, die AI zur Implementierung größerer Features ausspuckt, unkritisch als „guten Code“ akzeptieren. Diese Codes halten sich dann aber nicht an unsere Styleguides und Patterns oder implementieren Logik von Grund auf neu, statt vorhandene Bibliotheken zu nutzen, wodurch am Ende mehr Code entsteht, den wir selbst warten müssen. Später tauchen dann auch riesige PRs auf, die alles auf einmal erledigen wollen

  • Wenn es um rein neuen Code geht, halte ich es oft für besser, etwas selbst zu bauen, statt für vielleicht 50 Zeilen Code eine große Bibliothek hereinzuziehen. Das ist ein positiver Aspekt
  • Die „Entdeckung“ dieser Codes und Bibliotheken bleibt allerdings als Aufgabe bestehen, und wir untersuchen auch Ansätze, bei denen Teammitglieder sich für das selbstständige Auffinden und Nutzen internen Codes auf Dokumentation oder Suche per LLM stützen. Dass Wissen über interne Bibliotheken ungleich verteilt ist, bleibt ein Problem
  • In der frühen Einstiegsphase der Entwicklung sieht die Lage anders aus. Zu Projektbeginn gibt es noch keinen Coding-Stil und keine Standards, daher unterscheiden sich die Ergebnisse eines LLM nicht stark von dem, was Teammitglieder selbst vorschlagen würden. Schon Code bis zum Demo-Status zu erzeugen, hat Wert. Mehrere Projekte schnell bis zur Demo-Phase zu bringen, ist ein großer Boost

• Ich stimme der Argumentation hier zu. Selbst mit AI habe ich keinen revolutionären Produktivitätssprung gesehen. Wenn Software Engineers nicht kontinuierlich Problemlösung, Urteilsvermögen und das Umsetzen in Code üben, könnte ihr neuronales Wissen schwächer werden. Das Versprechen, AI werde in Zukunft eine 2x- oder 10x-Produktivitätstechnologie sein, hat keine echte Substanz, und selbst wenn es in einzelnen Codebases leichte Produktivitätssteigerungen gab, hat der Markt dadurch nicht tatsächlich mehr bessere Produkte hervorgebracht. In der Beratung sehe ich oft, dass Founder oder CTOs AI aggressiv pushen und dadurch eher den Code nicht mehr ordentlich verwalten können und noch mehr Chaos verursachen. In letzter Zeit übernehme ich deshalb oft eher eine Advisor-Rolle, um Engineering Best Practices zu etablieren

  • Wie bei den meisten Technologien stumpft das Gefühl dafür ab, wenn Praxis und Übung ausbleiben. So wie der Körper beim Fahrradfahren nach langer Pause einrostet, schwächen sich auch Coding-Fähigkeiten ganz real ab. Ich glaube, das gilt auch für IT-Engineering. Das ist tatsächlich ein Warnsignal

• CEOs sagen, dass AI die Produktivität bestehender Entwickler um das Zehnfache steigert, aber wenn das wirklich stimmt, müsste man dann nicht vielmehr viel mehr Entwickler einstellen? Wenn bei gleicher Investition die Produktivität um das Zehnfache steigt, wäre es doch nur rational, noch mehr Geld in diesen „Motor“ zu stecken. Stattdessen sieht es vor Ort eher so aus, als bliebe die Produktivität gleich und nur die Personalkosten würden sinken

  • Wenn die Gewinnmargen fallen, muss man am Ende Wert aus den Personalkosten pressen. 99 % des Reizes von AI ist Kostensenkung bei Personal, und Neueinstellungen laufen dem entgegen. Ich stimme den Behauptungen über Produktivitätssteigerung durch AI zwar auch nicht zu, wollte aber auf diesen Motivationsfaktor hinweisen
  • Viele C-Levels scheinen zu erwarten, dass auch die verbleibenden Mitarbeiter noch durch AI ersetzt werden. Sie folgen dem Narrativ „AGI kommt bald“. Ich glaube das nicht, aber wenn man diese Haltung hat, kann ich die Logik nachvollziehen, warum man nicht noch mehr Entwickler einstellt
  • Heute lerne ich vielleicht, was das „Gesetz des abnehmenden Grenznutzens“ bedeutet. Es gibt Grenzen dafür, wie viele Menschen und Ressourcen eine Organisation aufnehmen kann. Mehr als nötig hineinzustecken bringt nichts. Der Grund für mehr Entlassungen ist, dass AI die Effizienz erhöht hat; wenn AI die Arbeitsmenge übernehmen kann, die früher ein Mensch geschafft hat, sinkt entsprechend die Beschäftigung. Es ist nicht ein Mensch = ein AI, sondern eine Struktur, in der Arbeitsvolumen an AI übergeht und dadurch Menschen wegfallen. Der vollständige Ersatz von Menschen ist noch nicht abgeschlossen, aber wie viele Menschen benötigt werden, wird zum neuen Maßstab von Angebot und Nachfrage. Kreative Talente wird man immer stärker brauchen, aber daran mangelt es. Unter Software Engineers, die 100.000 bis 200.000 Dollar Gehalt wollen, gibt es viele, die nicht einmal wissen, wie viel sie einem Unternehmen einsparen können. Ich habe auch das Gefühl, dass das Bildungssystem Kreativität zerstört hat. Das Problem ist nicht fehlende Fähigkeit, sondern die mangelnde Kraft, die eigene Richtung selbst zu steuern oder Ideen hervorzubringen

• Beeindruckend ist die Analyse, die die Zahl neuer Produktveröffentlichungen aus einem frischen Blickwinkel betrachtet. Statt schnellem Wachstum hatte ich eher das Gefühl, dass weniger große Veränderungen eingetreten sind als erwartet. Eine Gegenhypothese wäre, dass das Schreiben von Code in Wahrheit gar nicht der Flaschenhals für Produkt-Releases war und dass schon das Erkunden dessen, was man bauen soll, sowie das tatsächliche Deployment auf echte Plattformen viel Zeit und Aufwand kostet. Andererseits stimme ich auch zu, dass man AI-Tools viel zu leicht falsch einsetzt. Manchmal denkt man: „Jetzt habe ich es endlich verstanden!“, und am nächsten Tag merkt man: „Ah, ich habe es schon wieder auf eine andere Weise falsch benutzt.“ Warum Softwareentwicklung so schwer ist und warum sich Produktivität so schwer beschleunigen lässt, ist mir selbst nach mehr als 20 Jahren Entwicklung noch nicht wirklich klar

  • Die Erkenntnis „Code schreiben war nicht der Flaschenhals“ trifft es wirklich. Der eigentliche Wert in Software entsteht beim Lösen „schwieriger Probleme“, während einfache Probleme bereits wie Templates überall herumliegen. LLMs erledigen einfache Probleme schnell, aber der echte Flaschenhals liegt weiterhin bei den „harten“ Problemen. Diese schwierigen Probleme lassen sich aus technischen, geschäftlichen oder kundenseitigen Gründen nicht wirklich sauber mit LLMs lösen, und genau dort liegt der wahre Gewinn. Dagegen erhöhen LLMs bei template-artigen, einfachen Problemen tatsächlich die Produktivität
  • Beim Ausliefern von Software war Coding selbst nie der Flaschenhals. AI dient nur als Vorwand für Personalabbau oder als Argument, um Investitionen einzusammeln
  • In der Produktentwicklung gibt es zeitintensive Prozesse wie wiederholtes Nutzerfeedback und das Beheben von Sonderfällen, die sich auch mit AI kaum verkürzen lassen. Das knüpft auch an den Artikel auf joelonsoftware.com an, wonach gute Software zehn Jahre braucht

• Wir bauen diese Zukunft gerade jetzt. Bei mir kam die Beschleunigung tatsächlich erst ab April/Mai, als agentic AI gut genug geworden war. Allein heute habe ich ein CLI-Tool gebaut, das iMessage-Archive als Website exportiert, und etwas, das früher Wochen gedauert hätte, könnte ich jetzt wohl in ein oder zwei Tagen sogar mit einer homebrew formula bauen. Auch bei einer iOS-App komme ich viel schneller voran als beim Handschreiben des Codes, gehe aber absichtlich langsam vor. Zur Einordnung: Die Daten des betreffenden Beitrags enden im März/April, und ich finde, genau ab diesem Zeitpunkt wurde generative AI für Coding praktisch wirklich hilfreich. (Ich nutze Copilot übrigens seit November 2022)

  • Ich finde es erstaunlich, dass bei jeder dieser Debatten wieder die Reaktion kommt: „Du hast die neueste AI eben noch nicht ausprobiert, diesmal funktioniert es wirklich.“
  • Meine Erfahrung ist fast identisch. Ich bin spät auf den AI-Hype aufgesprungen, aber nachdem ich die neuen Modelle und Tool-Kombinationen der letzten Zeit ausprobiert habe, habe ich meine Meinung geändert. In meinem Umfeld erlauben große Unternehmen solche Tools erst jetzt, daher erwarte ich, dass es bei echten Produktivitätsdaten einen erheblichen Zeitversatz gibt und sich die Auswirkungen erst später zeigen. Ich habe auch gewisse Vorbehalte gegenüber der METR-Forschung und hoffe, dass mehr Meta-Studien zu dieser Produktivität erscheinen
  • Stimme zu. Agentic AI ist ein völlig anderes Tool als „traditionelle“ AI. Ich bin sehr gespannt, wie die Daten und Experimente des Autors in einem Jahr aussehen werden
  • Der Moment, in dem man sagt „AI ist endlich schneller geworden“, liegt gerade einmal fünf Monate zurück. Beim Tempo von AI fühlen sich fünf Monate wie sechs Jahre Veränderung an

• Ich war früher Fulltime-Entwickler und habe später als Manager und CTO gearbeitet, wodurch ich mich immer weiter von der praktischen Entwicklungsarbeit entfernt habe. Als ich wieder programmieren wollte, merkte ich, dass ich Frameworks, APIs, Sprachen und kleine Tricks neu lernen müsste — früher fand ich das spannend, heute nervt es mich. Aber dank Tools wie Claude Code und meiner Erfahrung im Softwaredesign ist es mir wieder möglich geworden, große Systeme zu entwickeln wie früher. Meine Produktivität ist weder um 20 % gestiegen noch um das Zehnfache. Stattdessen hat es mich dazu gebracht, Dinge wieder zu tun, die ich sonst gar nicht angefangen hätte — also würde ich es eher als unendliche Produktivitätssteigerung bezeichnen. Wenn ich ein sehr fähiger Entwickler wäre, der Entwicklung liebt, würden mich diese Tools wahrscheinlich nur nerven, aber für jemanden, der normalerweise nicht entwickelt, ist es genau umgekehrt

  • Wow, du hast große Systeme nicht nur einmal, sondern mehrfach neu entwickelt — ich würde gern konkrete Beispiele mit mehr Details hören
  • Meine große Theorie zu AI-Coding-Tools ist, dass sie nicht wirklich viel Zeit sparen, sondern den Frust massiv reduzieren. Sie nehmen unnötigen Ärger mit Syntax, Compiler und Routinearbeit weg, sodass man seine Aufmerksamkeit auf die wirklich wichtigen Dinge richten kann. Dadurch macht man Dinge, die man früher aus lauter Genervtheit nicht gemacht hätte, und bleibt vor Feierabend vielleicht noch ein paar Stunden länger am Schreibtisch, statt spazieren zu gehen