AI macht Open-Source-Entwickler langsamer. Peter Naur könnte erklären, warum

• Laut einer aktuellen Studie brauchen Open-Source-Entwickler 19 % mehr Zeit, wenn sie AI-Tools in einer Codebasis einsetzen, die sie gut kennen
• Entwickler glauben zwar, dass AI sie schneller macht, tatsächlich gibt es jedoch eine Lücke zwischen Wahrnehmung und Realität, und sie werden langsamer
• Der Hauptgrund liegt in den Grenzen des Wissenstransfers zwischen dem fein ausgearbeiteten mentalen Modell (Verständnisstruktur) der Entwickler und der AI
• Nach Peter Naurs Theorie ist das Wichtigste beim Programmieren das „mentale Modell“ im Kopf des Entwicklers
  • Dänischer Pionier der Informatik und Turing-Award-Preisträger von 2005. Er trug zur Backus-Naur-Form (BNF) bei, die zur Beschreibung der Syntax von Programmiersprachen verwendet wird
• Aus einer langfristigen Perspektive ist es wichtig, ein mentales Modell durch eigenes Schreiben von Code aufzubauen, um ein Projekt tiefgreifend zu verstehen

---

Warum AI Open-Source-Entwickler langsamer macht

• Laut einer Studie von Metr führte der Einsatz von AI-Tools dazu, dass die Problemlösung 19 % langsamer wurde
• Vor der Arbeit erwarteten die Entwickler, dass AI ihnen um 24 % schneller helfen würde, und selbst nach der Arbeit glaubten sie noch, 20 % schneller gewesen zu sein, als sie es tatsächlich waren
• Die Studie wurde mit erfahrenen Entwicklern durchgeführt, die Open-Source-Projekte selbst verwalten und tiefgehend verstehen
• Die Ergebnisse lassen sich nicht auf alle Entwickler verallgemeinern, zeigen aber, dass AI-Tools in dieser Gruppe einen negativen Effekt auf die Produktivität hatten
• In Unternehmensumgebungen oder für allgemeine Entwickler, die sich in eine neue Codebasis einarbeiten müssen, könnten AI-Tools eine positivere Rolle bei der Produktivitätssteigerung spielen

Warum AI erfahrene Open-Source-Entwickler ausbremst

• Laut Peter Naurs Aufsatz „Programming as Theory Building“ ist das eigentliche Ergebnis des Programmierens nicht der Code, sondern das ‚mentale Modell des Entwicklers über das Projekt‘
• Dieses mentale Modell ist zentral für das Verständnis des Systems, die Diagnose von Problemen und wirksame Verbesserungen
• LLM-basierte AI kann nicht direkt auf das mentale Modell des Entwicklers zugreifen; selbst wenn ein Teil der Informationen übermittelt wird, entsteht im Wissenstransfer ein grundlegender Verlust
  • Ein Beispiel: Wenn man jemandem aufträgt, ein Baby schlafen zu legen, handelt diese Person trotz klarer Erklärung in der Praxis oft anders als beabsichtigt
• Die Übertragung eines mentalen Modells ist extrem komplex, und es ist für AI nahezu unmöglich, dieses allein aus Text vollständig aufzunehmen
• Deshalb senkt das Delegieren von Arbeit an AI in Projekten, die man tief versteht, eher die Produktivität
• Der reiche Kontext und das intuitive Verständnis eines Entwicklers lassen sich von AI nicht leicht ersetzen

Sollte man AI-Tools im Arbeitsalltag verbieten?

• Nicht unbedingt. Das gilt nur für Menschen, die an Projekten arbeiten, die sie selbst gut kennen und tief verstehen
• Viele Unternehmensentwickler warten Code von bereits ausgeschiedenen Senior-Entwicklern oder arbeiten, ohne die Gesamtarchitektur eines Systems tief zu verstehen
• In solchen Umgebungen kann AI dazu beitragen, eine Codebasis schnell zu erfassen und Änderungen automatisch zu erzeugen, was kurzfristig die Produktivität steigern kann
• Wenn es vor allem um kurzfristigen Business Value und unmittelbare Effizienz geht, können AI-Tools eine positive Rolle für die Produktivität spielen

Aufbau mentaler Modelle und AI

• Wenn man noch kein mentales Modell eines Projekts hat, kann ein LLM helfen, die Produktivität zu steigern
• Wenn das Wesen der Softwareentwicklung jedoch im Aufbau mentaler Modelle liegt, kann zu starke Abhängigkeit von AI diese Fähigkeit schwächen
• Wer ein Projekt langfristig tief verstehen und aktiv weiterentwickeln möchte, braucht die Erfahrung, selbst Code zu schreiben
• Umgekehrt kann der Einsatz von AI effizient sein, wenn es nur darum geht, etwas „einfach zum Laufen zu bringen“

Weitere Diskussion und Fazit

• Mit AI-Tools auf dem aktuellen Stand ist es schwierig, die Produktivität von Entwicklern mit einem ausreichend ausgeprägten mentalen Modell zu steigern
• Wie AI mentale Modelle besser unterstützen oder die Produktivität erfahrener Entwickler grundlegend erhöhen kann, erfordert noch weitere Forschung und Entwicklung
• Künftige Modelle könnten so weit fortschreiten, dass menschliche Entwickler vielleicht kein eigenes mentales Modell mehr brauchen; auf dem aktuellen Stand sind direktes Verständnis und eigenes Lernen jedoch unverzichtbar
• Letztlich kann AI in Umgebungen, in denen man tief versteht, was man tut, eher stören, während sie in Umgebungen, in denen schnelle Ergebnisse wichtig sind, ein Produktivitätstool sein kann

[paruaa]

Entwickler glauben, dass AI sie schneller macht.
Da die Recherche mit AI schneller wird, kann man die Qualität steigern; kommt dann nicht selbst bei derselben Aufgabe eine etwas höhere Qualität heraus? Vielleicht denken Entwickler, dass es schneller ist, mit Hilfe von AI das Qualitätsniveau des Ergebnisses zu erreichen, als allein dorthin zu gelangen.
Wenn sie AI von Anfang an nicht genutzt hätten, hätten sie vielleicht nur mit dem Wissen implementiert, das sie selbst bereits haben – das könnte ein Grund dafür sein, denke ich.

[tested]

> Umgekehrt kann der Einsatz von KI effizient sein, wenn es sich um Aufgaben handelt, bei denen es nur darum geht, „es einfach irgendwie zum Laufen zu bringen“.

Das gilt nicht nur für Entwickler, aber es gibt nun einmal Menschen mit sehr unterschiedlichen Neigungen. Deshalb habe ich den Eindruck, dass gerade diejenigen, die eher zufällig in der Softwareentwicklung gelandet sind und das Schreiben oder Lesen von Code nicht mögen oder sogar davor zurückschrecken, und die strukturierte Architektur oder Wartbarkeit weniger wichtig finden als die bloße Tatsache, dass es irgendwie läuft, besonders stark dazu neigen, sich auf KI zu verlassen oder ihr blind zu vertrauen. Vielleicht liege ich auch falsch.

[xguru]

Messen des „AI-Impacts“ auf die Produktivität erfahrener Open-Source-Entwickler

[GN⁺]

Hacker-News-Meinungen

• Hallo HN, ich bin der Autor der Studie.
  Ich denke, der Blogbeitrag greift auf interessante Weise einen konkreten Faktor auf, der dazu beitragen kann, dass AI die Entwicklungsgeschwindigkeit verlangsamt.
  In der Studie gibt es auch Entwicklerzitate, siehe Abschnitt C.1.5.
  Viele lesen die Studie und entdecken einen Faktor, der ihnen plausibel erscheint, und ziehen dann leicht den Schluss: „Dieser eine Punkt ist der Grund für die Verlangsamung.“
  Tatsächlich sind es aber mehrere Faktoren (mindestens 5 sind wahrscheinlich, bis zu 9 können nicht ausgeschlossen werden; siehe die Faktortabelle auf S. 11).
  Statt anzunehmen, dass nur ein einzelner Punkt die Ursache ist, ist eine mehrdimensionale Ursachenanalyse angemessener.
  Wer selbst ein Experiment dazu plant, den würde ich sehr bitten, die Ergebnisse an die in der Studie angegebene E-Mail-Adresse zu schicken.
  Und zum Artikeltitel „AI slows down open source developers. Peter Naur can teach us why“ denke ich, dass etwas wie „Anfang 2025 verlangsamt AI erfahrene Open-Source-Entwickler. Peter Naur liefert zusätzlichen Kontext zu einem bestimmten Faktor.“ präziser wäre.
  Das klingt vielleicht weniger provokant, aber Genauigkeit ist wichtig.
  Nochmals vielen Dank für den großartigen Artikel, und ich lese die Kommentare weiterhin
  Frühere verwandte Diskussion
  Vollständige Studie
  • Ich hätte eine persönliche Frage: Wie wurde in der Studie verlässlich gemessen, wie stark sich die tatsächliche benötigte Zeit vor und nach der Nutzung von AI verändert hat? Haben die Entwickler vielleicht zuerst geschätzt, wie viel Zeit sie durch AI einsparen würden, und dann wurde die tatsächliche Zeit gemessen, um die Differenz zu sehen? Und wie hat das Forschungsteam kontrolliert, wenn der Schwierigkeitsgrad eines Issues oder die zur Lösung benötigte Zeit schwer einzuschätzen war? Ich kann gut nachvollziehen, wie komplex solche Messungen sind
  • Ich stimme den Ergebnissen zu und danke für die Antwort. Den Titel werde ich nicht ändern, weil mir der radikalere Stil gefällt, aber ich werde im Artikel klar korrigieren, dass die Formulierung ungenau ist. In meinem Text werde ich deutlich machen, dass die wesentlichen beitragenden Faktoren der Studie – „hohe Vertrautheit des Entwicklers mit dem Repository“, „große und komplexe Repositories“, „impliziter Repository-Kontext“ usw. – mit meiner Darstellung übereinstimmen. Ich würde so ein Experiment auch gern selbst durchführen, aber es erscheint mir sehr schwierig, neben den Anforderungen des Arbeitsalltags eine kontrollierte Umgebung zu schaffen. Außerdem fehlt es an einer Liste klarer Aufgaben, die sich in kurzer Zeit abschließen lassen
  • Wenn man in einem Projekt, das man gut kennt, einen optimierten Workflow verändert, würde ich erwarten, dass man zunächst langsamer wird. Wichtig ist, wie es bei diesen Entwicklern in 6 Monaten oder in 1 Jahr aussieht. Diese Studie zeigt keine Langzeitentwicklung, daher hoffe ich, dass künftige Forschung zeigen kann, wie sich die Leistung derselben Entwickler verändert, nachdem sie sich daran gewöhnt haben. Ich habe selbst erlebt, dass ich mit AI viele Aufgaben skripten konnte, die sich zuvor nur schwer automatisieren ließen. Man sollte sich immer fragen: „Ist das den Zeitaufwand wert?“
    xkcd-Zeitmanagement-Comic
  • Es wurde auch angemerkt, dass selbst „Anfang 2025 verlangsamt AI erfahrene Open-Source-Entwickler“ noch zu stark verallgemeinert ist. Es gibt bestimmte Aufgaben, bei denen AI Zeit sparen kann, daher hängt der Effekt von der jeweiligen Aufgabe ab
  • Langsamer zu werden ist nicht zwangsläufig schlecht; langsames Programmieren (Literate Programming / im Stil von Knuth) kann der Theoriebildung sogar eher helfen. Man könnte also argumentieren, dass langsame Entwicklung mit ausreichend Nachdenken und Abstraktion wichtiger ist als Fast-Food-Programmierung
• Ich kann mich mit dem Phänomen identifizieren, dass „Entwickler nicht erkennen, ob ein Tool sie tatsächlich schneller oder langsamer gemacht hat“. Als Beispiel wurde ein Boot genannt, das durch Wind und Strömung vom Ziel abgetrieben wird: Man erkennt Fortschritt nur anhand der aktuellen Bewegung in der unmittelbaren Umgebung, aber nicht intuitiv daran, ob man dem Ziel näherkommt. Deshalb neigt man zu Strategien, die einem ein „Gefühl von Fortschritt“ geben, und wählt dadurch manchmal ineffiziente oder tatsächlich langsamere Wege (z. B. beim Autofahren häufiges Rechtsabbiegen)
  • Als ich AI-Tools zum ersten Mal benutzte, gefiel mir das Gefühl, dass die Arbeit ohne Blockaden einfach weiterlief. In Wirklichkeit wäre es aber oft schneller gewesen, selbst eine einzelne Zeile zu ändern, und trotzdem geriet ich in die Gewohnheit, reflexhaft AI aufzurufen. Ähnlich wie bei der Fahrmetapher ist es leicht, immer wieder dorthin zurückzukehren, so wie ein GPS bei einer Sperrung später doch wieder die ursprüngliche Route empfiehlt
  • Es ist ähnlich wie bei Navi-Apps wie Waze, die einen tatsächlich über längere Routen schicken, die sich wegen vieler verschachtelter Umwege aber so anfühlen, als sei man „in Bewegung“ und daher schneller unterwegs. Bei AI-Tools hat man ebenfalls das Gefühl, dass Programmieren leichter wird, obwohl die tatsächliche Produktivität sinken kann. Menschen erinnern sich leicht nur an die kurzfristige Erfahrung eines schmerzfreien Vorankommens und glauben dann, sie hätten Fortschritt gemacht, weil es sich nicht schwierig anfühlte
  • Letztlich bevorzugen Menschen instinktiv einen Greedy-Algorithmus
  • Linux-/Unix-Nutzer halten Tastatursteuerung und CLI-Tools oft für maximal effizient, aber es gibt Forschungsergebnisse, wonach bei den meisten Aufgaben die Maus schneller ist. Dass sich Tastatureingaben schneller anfühlen, liegt daran, dass die Anzahl der Aktionen pro Sekunde höher ist
  • AI-generierter Code wird fast nie gründlich geprüft, und viele Entwickler finden Code-Review an sich schon anstrengend und weigern sich zu lesen. Deshalb sind neue Frameworks und Code-Rewrites so beliebt
    Joel on Software: Things you should never do, part I
    Viel AI-generierter Code wird einfach produziert, durchläuft ein paar einfache Tests und damit hat es sich. Es gibt sogar immer mehr Code, dessen vollständigen Kontext oder Begründung nicht einmal der Autor selbst wirklich versteht
• Der Kern dieser Studie lässt sich so zusammenfassen: „AI erzeugt die Illusion, dass der Produktivitätsgewinn größer ist, als er tatsächlich ist.“ Nur bei einigen Teilnehmern gab es einen kleinen Produktivitätszuwachs, bei den meisten ging sie vielmehr deutlich zurück. Es gibt viele Menschen, die behaupten, dass AI ihre Produktivität explosionsartig gesteigert habe, aber die Einsicht der Studie, dass dieser Effekt selbst eine Illusion sein kann, wird ignoriert. AI ist ein Produkt, das darauf optimiert ist, den Nutzer glauben zu lassen, er sollte es verwenden und es sei nützlich. Der persönliche Wert ist als wahrgenommene Realität unbestreitbar, aber wer sich stark auf AI verlässt, sollte bei verzerrter Selbsteinschätzung, falschem Erfolgsgefühl und Tool-Abhängigkeit wirklich vorsichtig sein. AI antwortet zwar manchmal mit einem optimierten Tokenstrom, aber man sollte sich zumindest einmal fragen, worauf eigentlich wirklich optimiert wird
  • LLMs sind zwar hilfreich, wenn man etwas lernt, aber dieses Verständnis fühlt sich sehr abstrakt und irgendwie „LLM-artig“ an. Beim Lernen ist es meiner Meinung nach besser, verschiedene Methoden zu kombinieren
  • AI-Tools vermitteln Entwicklern weniger das Gefühl, „schnell“ zu sein, als vielmehr das Gefühl, „im Moment reaktionsschnell“ zu sein. Das hat etwas von der Illusion geringerer kognitiver Belastung; in anderen Feedback-Loops verändert sich das Empfinden selbst und auch der Mechanismus der Gedächtnisbildung, was zu einer interessanten Täuschung führt
• Während die Studie diskutiert wurde, dass „erfahrene Open-Source-Entwickler langsamer werden, wenn sie bei der Arbeit an ihrem eigenen Projekt AI verwenden“, arbeitete ich gerade mit einer völlig fremden, erst drei Monate alten Codebasis und einem mir unvertrauten Framework. Mit Claude Code konnte ich jedoch in nur wenigen Stunden Dinge wie Datensynchronisierung fertigstellen, für die ich in früheren Projekten einen oder zwei Tage oder im Extremfall bis zu zwei Wochen gebraucht hätte, und das war ein enormer Jumpstart. Bei steigender Komplexität wird es wohl nach und nach langsamer werden, aber es war erstaunlich, wie schnell der Einstieg mit Hilfe des Tools gelang
  • Ich habe ähnliche Erfahrungen gemacht, aber worum es in dieser Studie geht, ist nicht unsere Ramp-up-Phase, sondern der Fall, dass bereits sehr vertraute Open-Source-Entwickler mit AI Aufgaben bearbeiten. LLMs beschleunigen die Einarbeitung in neue Codebasen definitiv, aber wenn man erst einmal vertraut damit ist, habe ich eher erlebt, dass sie stören
  • Bei der Behauptung „ein PR in ein paar Stunden, der sonst zwei Wochen gedauert hätte“ folgt immer sofort die Geschichte vom Produktivitätsgewinn. Meiner Ansicht nach wird aber selten überprüft, wie genau wir überhaupt bei Entwicklungszeitschätzungen sind. Außerdem muss man fragen, ob die Qualität eines so hastig eingereichten PRs wirklich der ursprünglich erwarteten entspricht oder ob beim Versuch, schnell zu sein, wichtiger Systemkontext ausgelassen wurde und dadurch die Fehlerwahrscheinlichkeit steigt. Auch ohne AI wird man schneller, wenn man Qualität opfert
  • Ich frage mich auch, ob die durchschnittliche Vertrautheit mit der Codebasis und dem System durch AI tatsächlich auf natürliche Weise zunimmt. Der Lerneffekt bei der Nutzung von LLMs fühlt sich an, als könne man eine neue Sprache lesen, aber nicht von Grund auf selbst sprechen. Um C++ als Beispiel zu nehmen: Man kann lesen und Bestehendes ändern, aber es ist schwer, selbst bei null anzufangen
  • Ich wollte nur sagen, dass ich dank AI-Tools einen enormen Jumpstart hatte; das war nicht als Kritik an der Studie, dem Artikel oder dem Paper gemeint, sondern als Hinweis darauf, dass AI in bestimmten Kontexten wirklich hilft. Es geht nicht nur ums Schreiben von Code: Claude Code versucht zum Beispiel direkt aus einem internen Container des Projekts Verbindungen zu AWS-Clustern herzustellen und hat mir sehr geholfen, die gesamte Infrastruktur und Struktur zu verstehen. Nach meiner Erfahrung haben in 80–90 % der Fälle „Business Value“ und nicht Codequalität Priorität. Ich weiß nicht, wie nützlich das bei Arbeiten ist, bei denen Codequalität wirklich wichtig ist oder spezielle Algorithmen und Datenstrukturen gebraucht werden. Aber ich habe auch erlebt, dass ziemlich brauchbarer Code entsteht, wenn man gute Beispiele und klaren Kontext vorgibt. Die Tools werden jede Woche oder jeden Monat in hohem Tempo besser. Letztlich ist AI keine Magie, sondern ein Tool, und die Verantwortung für Produkt und Ergebnis liegt am Ende bei einem selbst
  • Man sollte im Kopf behalten, dass das Paper (TFA) einen Fall in einem sehr vertrauten Projekt behandelt. Mein eigenes Beispiel ist genau das Gegenteil: Dort spielt AI vor allem in unvertrauten Situationen ihre Stärken aus
• Unter Berufung auf die Metapher „Agentische AI-Tools (Claude Code, Amp, Gemini CLI usw.) sind für die Programmierung das, was die Tischkreissäge für die Holzbearbeitung ist“ wurde argumentiert: Wenn man den Umgang damit beherrscht, kann man manche Arbeiten schneller und besser erledigen; wenn man aber nicht damit vertraut ist, kann man sich eher die Finger verletzen. Ich selbst wage mich dank agentischer AI an etwas ambitioniertere Projekte, und weil ich ungern gemachte oder repetitive Arbeit der AI überlasse, bleibt mehr geistiger Spielraum. Gleichzeitig warne ich davor, einfach alles von AI erledigen zu lassen und dann ohne Verständnis nur noch zu committen. Wie bei jedem Werkzeug muss man sich bemühen, bessere Nutzungsweisen zu erlernen
  • Ich halte die Tischkreissägen-Metapher für unpassend. Eine Tischkreissäge ist im Vergleich zu Handwerkzeugen ein präzises Werkzeug, agentische AI ist von Präzision aber weit entfernt
  • Die Logik „Du benutzt AI nur falsch“ ist für Entwickler, die ihren gesamten Open-Source-Stack schon vor dem Auftauchen von AI aufgebaut haben, beleidigend. Außerdem gibt es bislang keinen Nachweis, dass mithilfe von AI wertvolle Software entstanden ist
• In dieser Studie gab es nur einen einzigen Entwickler mit mehr als 50 Stunden Cursor-Erfahrung (einschließlich der im Rahmen der Studie verbrachten Zeit), und dieser Entwickler erlebte eine Beschleunigung von 25 %. Alle anderen waren Anfänger, und wenn Anfänger ein neues Tool benutzen, werden sie natürlich langsamer. Nur aus dieser Studie lässt sich meiner Meinung nach schwer ein allgemeines Produktivitätsfazit über AI ableiten
  • Wenn man sich die Details des Papers ansieht, haben frühere Studien mit Teilnehmern mit ähnlicher (oder sogar geringerer) Tool-Erfahrung eher Geschwindigkeitszuwächse berichtet. Die meisten hatten zudem ausreichend Erfahrung mit LLM-Prompts, und insbesondere ähnelt Cursor VSCode, sodass die zusätzliche Lernkurve nicht besonders groß ist. Wenn sich alle Entwickler extrem an AI-Tools gewöhnen, könnte es sogar sein, dass ihre Fähigkeiten ohne AI sinken und dadurch die Arbeit mit AI nur deshalb schneller wirkt, weil der Vergleichsmaßstab schlechter geworden ist. Entscheidend ist nicht, welches Tool verwendet wurde, sondern die wichtige Einsicht, dass die Selbsteinschätzung der Produktivität im Vergleich zur Realität übermäßig optimistisch war. Um den tatsächlichen Effekt zu beurteilen, braucht man konkrete Messwerte
    (wird in Abschnitt C.2.7 des Papers „Unterdurchschnittliche Nutzung von AI-Tools“ ausführlicher behandelt)
  • Wenn ein Entwickler seine eigene IDE (Vim/Neovim usw.) schon lange verwendet, kann die Produktivität beim Wechsel auf ein neues Tool (etwa Cursor) für Monate deutlich sinken
  • Ich sehe das genauso. Entwickler, die mit einem Tool nicht vertraut sind, werden zwangsläufig langsamer. Für AI gilt keine Ausnahme
• Ich bin derzeit regelmäßiger Code-Reviewer bei Burn, dem Rust-basierten Deep-Learning-Framework. Kürzlich habe ich einen Bugfix-PR geschlossen, der so aussah, als sei er vollständig von einem AI-Agenten geschrieben worden. Dieser PR löste die Ursache des Problems nicht, sondern ignorierte den Fehler einfach, fügte unnötig weitschweifigen, rechtfertigenden Code hinzu und enthielt sogar Tests dafür, Fehler zu ignorieren. Es wirkte wie ein Beitrag nur für den Commit-Record. Ich finde es besorgniserregend, dass sich eine solche Form des AI-Missbrauchs ausbreitet
  • Es ist bemerkenswert, wie LLMs, wenn sie die richtige Antwort nicht kennen, etwas Falsches ausgeben und bei einem Hinweis darauf dann mit etwas wie „Stimmt, ich korrigiere das“ reagieren. Ich habe Angst davor, dass unerfahrene Leute die Probleme nicht unterscheiden können oder sich nach und nach gar nicht mehr um den Code kümmern. Es gibt auch die Sorge, dass bald ernsthafte Schwachstellen und Missbrauchsfälle in großer Zahl auftauchen werden
  • Beim Review eines MRs eines Kollegen fand ich Testfälle, die eindeutig nach AI aussahen (thing1, thing2 usw.; nur die Variablennamen unterschieden sich, der Inhalt war immer gleichförmig). Ich schlug als Feedback unterscheidbarere Namen vor, und daraufhin vergab die AI nun extrem weitschweifige Variablennamen, als wolle sie alle Eigenschaften jedes Falls vollständig aufzählen, sodass der Code letztlich noch schwerer auf einen Blick zu erfassen war. Der Autor hatte vermutlich das Gefühl, seine Schreibgeschwindigkeit stark erhöht zu haben, aber tatsächlich ging der Produktivitätsgewinn vollständig in Feedback, Review und Überarbeitung verloren
  • Es gab auch eine scherzhafte Bemerkung im Sinne von: „Ein Deep-Learning-Framework in Rust – ein Teufelskreis mit AI“
  • Tatsächlich ist die Nutzung von AI mit dem Ziel, einfach Commits zu erzeugen, schon seit längerem verbreitet. AI macht auch die Produktion schlichten Spams leichter
    Siehe auch: altes Thema zu AI-Spam
  • Es wurde darauf hingewiesen, dass LLMs try:catch-Blöcke zu breit einsetzen und es dadurch schwerer machen, die Problemquelle nachzuverfolgen. Ich persönlich möchte lieber, dass Probleme schnell und deutlich sichtbar werden (= fail fast), damit ich sie sofort beheben kann
• Mein persönlicher Eindruck ist, dass AI-gestütztes Programmieren den Konzentrationsfluss immer wieder unterbricht und schneller ermüdet. Dass man den ganzen Tag durchgehend codet, ist ein Mythos; üblich sind 1 bis 3 Stunden konzentrierte Arbeit mit Pausen dazwischen. Selbst beim Lesen von Code oder Änderungen von Kollegen wird diese Zeit zwar als Arbeitsfortschritt mitgezählt, tatsächlich kommt man aber oft kaum voran. Agentische AI kann bei kleinen Refactorings nützlich sein, aber ein großer Produktivitätssprung ist aus meiner Sicht selten. Code-Autovervollständigung (z. B. frühes Copilot) ist dagegen oft eher unnötiges Rauschen
  • Wenn man tatsächlich einen ganzen Arbeitstag aufzeichnen würde, wäre das Ergebnis vermutlich ziemlich deprimierend. Gerade bei einer reifen Codebasis ist vielleicht sogar eine Stunde fokussierte Arbeit schon übertrieben
• Wenn man in einer unbekannten Codebasis einen kniffligen Bug wie eine Race Condition debuggt, sind zusätzliches Logging, der Austausch von Bibliotheksfunktionen und strukturelle Verbesserungen unverzichtbar. Wenn AI dann nur die kurzfristig schnelle Lösung liefert – „Hier ist die Race Condition und so behebst du sie“ –, kann das dem Verständnis von Code-Struktur und Logik eher schaden. Wenn AI-gesteuerte Code-Edits langfristig weiter zunehmen, könnte sich der Code irgendwann so verschlechtern, dass selbst AI nicht mehr angemessen darauf reagieren kann
  • Immer wenn ich höre: „Ich habe mit AI zu einer Sprache oder Codebasis beigetragen, die ich gar nicht kannte“, frage ich mich: Kurzfristig mag das okay sein, aber was wurde dabei wirklich gelernt? Für kleine Arbeiten mögen solche Beiträge brauchbar sein, aber Berichte über langfristige Wartungserfahrung höre ich kaum
• In einer Rückschau auf mein erstes Projekt, bei dem ich AI-Tools aktiv eingesetzt habe, war mein Fazit: 1) Es ging nicht schneller, 2) vielleicht war es sogar langsamer, 3) die Qualität des Ergebnisses war besser. Die Verlangsamung und die Qualitätssteigerung hängen zusammen, weil ich AI vor allem als Hilfsmittel zur Überprüfung von Ideen oder zur Erkundung von Alternativen genutzt habe. Dank AI war die Lernerfahrung in unbekannten Bereichen gut, und in meinem Kerngebiet konnte ich meine eigenen Ideen oder die der AI verfeinern, was die Qualität letztlich erhöht hat. Geschwindigkeit ist nicht alles; auch wenn sich Qualität schwer quantifizieren lässt, fühlt es sich dennoch wertvoll an
  • Gerade weil AI zur Qualitätssteigerung beitragen kann, bevorzuge ich inzwischen AIs, die widersprechen und nicht einfach blind zustimmen. Wenn ich AI um Ideen bitte und sie bitte, Schwachstellen anzugreifen oder mit mir zusammen Lücken in meinen Ideen zu suchen, ist das produktiv. Vielleicht setze ich es am Ende nicht um, aber es hilft mir, verschiedene Blickwinkel zu sehen, an die ich zuvor nicht gedacht hätte. Es ähnelt praktisch einem Gespräch mit einem Kollegen, der zum Themengebiet eine vernünftige Meinung beitragen kann

[eususu]

Ich hatte einen ähnlichen Gedanken, aber es war schwer, ihn in Worte zu fassen.
Mentales Modell ist wirklich eine passende Bezeichnung. Ich werde sie gelegentlich verwenden.