- KI-Tools Anfang 2025 wurden in einer randomisierten kontrollierten Studie darauf untersucht, wie sie die tatsächliche Produktivität von Open-Source-Entwicklern beeinflussen
- Das Ergebnis der Studie: Mit KI-Tools dauerte die Erledigung von Aufgaben im Durchschnitt 19 % länger
- Entwickler erwarteten, dass KI sie um 24 % schneller machen würde, doch entgegen der eigenen Wahrnehmung trat eine Verlangsamung ein
- Die Diskrepanz zwischen Benchmarks und Alltagserfahrung einerseits und den tatsächlichen Effekten andererseits fällt sehr deutlich aus
- Die Studie betont, wie wichtig ein genaues Verständnis der Produktivitätseffekte von KI und vielfältige Bewertungsmethoden ist
Überblick
- Diese Studie führte eine randomisierte kontrollierte Studie (RCT) durch, um zu prüfen, wie sich KI-Tools Anfang 2025 (Early-2025) auf die Produktivität erfahrener Open-Source-Entwickler auswirken
- Entgegen den Erwartungen zeigte sich, dass Entwickler mit KI-Tools 19 % länger brauchten
- Das Ergebnis kann als ein Beispiel dafür verstanden werden, wie sich die Automatisierung von KI-Forschung real auf die Softwareentwicklung auswirkt
- Auf Basis dieser Methodik will man die realistischen Effekte der Beschleunigung von KI-F&E fortlaufend abschätzen
Motivation der Studie
- Bestehende Coding-/Agent-Benchmarks bilden reale Arbeitssituationen nur unzureichend ab
- Durch selbstständige Tests, einmalige Aufgaben ohne Kontext und automatische Bewertung kann die Fähigkeit von KI überschätzt werden
- Umgekehrt ist auch eine Unterschätzung der tatsächlichen Modellleistung möglich, wenn adaptive menschliche Eingriffe fehlen
- Um diese Grenzen auszugleichen, wurde der Einfluss auf die tatsächliche Produktivität von Open-Source-Entwicklern experimentell gemessen, um die reale Wirkung von KI zu erfassen
Versuchsaufbau
- Es wurden 16 erfahrene Open-Source-Entwickler rekrutiert, die 246 reale Issues in großen Repositories auswählten, an denen sie seit Jahren arbeiten (durchschnittlich 22.000+ Stars, 1.000.000+ Codezeilen)
- Für jedes Issue erfolgte eine zufällige Zuteilung zu einer Gruppe, in der KI-Nutzung erlaubt oder verboten war
- Wenn KI erlaubt war, konnten die Entwickler Cursor Pro sowie aktuelle Modelle wie Claude 3.5/3.7 Sonnet frei nutzen; wenn nicht, arbeiteten sie ohne generative KI-Unterstützung
- Die Teilnehmenden zeichneten den Lösungsprozess für jedes Issue (durchschnittlich 2 Stunden) auf und meldeten den Zeitaufwand selbst
- Die Teilnehmenden erhielten eine Vergütung von 150 US-Dollar pro Stunde
Zentrale Ergebnisse
- Bei der Nutzung von KI-Tools verlängerte sich die Lösungszeit pro Issue im Durchschnitt um 19 %
- Die Entwickler erwarteten, dass KI ihre Produktivität tatsächlich um 24 % steigern würde, und gaben selbst nach dem Experiment noch an, eine Beschleunigung von 20 % zu spüren
- Damit zeigt sich eine große Lücke zwischen Wahrnehmung und realer Leistung
- Um Missverständnisse zu vermeiden, liefert diese Studie keine Belege für die folgenden Aussagen:
- Dass KI für alle Entwickler oder die gesamte Softwareentwicklung generell zu Verlangsamung führt
- Wie der Effekt von KI in anderen Bereichen oder Settings ausfällt
- Dass dasselbe Ergebnis auch in naher Zukunft bestehen bleibt
- Dass eine Optimierung bestehender LLM- und Prompting-Techniken unmöglich ist
Analyse der Einflussfaktoren
- Es wurden 20 Faktoren analysiert, die die Verzögerung erklären könnten; bei 5 davon wurde ein tatsächlicher Einfluss angenommen
- Es zeigte sich, dass zentrale Variablen wie Versuchsbedingungen, Modell, Schwierigkeit des Issues und PR-Qualität das Ergebnis nicht signifikant beeinflussten
- Das Verzögerungsphänomen wurde auch in verschiedenen Daten-Teilgruppen und mit unterschiedlichen Schätzmethoden konsistent beobachtet
- Detaillierte Analysen finden sich im Originalpapier
Interpretation und Diskussion der Ergebnisse
Widersprüchliche Evidenz und Ursachen
- Die Unterschiede zwischen KI-Benchmark-Scores, Fallberichten und realen Experimenten treten deutlich zutage
- Benchmarks messen KI-Fähigkeiten vor allem anhand enger Problemstellungen, die sich automatisch bewerten lassen
- SWE-Bench: testbasierte Open-Source-PRs, RE-Bench: Probleme mit algorithmisch bewertbaren Ergebnissen
- In der realen RCT wurden Menschen bei komplexen, realitätsnahen Aufgaben mit einer Dauer von 20 Minuten bis 4 Stunden hingegen langsamer
- Gleichzeitig gibt es in Industrie und Community viele qualitative Berichte, wonach KI bei längeren Arbeitsabläufen sehr nützlich sei
Interpretationsrahmen
- Jede Herangehensweise hat die Eigenschaft, „reale Fähigkeit“ auf unterschiedliche Weise zu messen
- Fallbezogene Betrachtung:
- Mögliches Unterbewertungsproblem der RCT: Es könnte sich um eine Besonderheit nur unseres experimentellen Settings handeln
- Mögliches Überschätzen durch Benchmarks/Fallberichte: Abweichung von realen Lösungswegen, unzureichende Verlässlichkeit selbstberichteter Grundlagen
- Alle drei Ansätze könnten nur auf bestimmte Teilprobleme der Realität gut passen
- Die Diskrepanz zwischen verschiedenen Quellen und tatsächlicher Leistungsfähigkeit kann als Ergebnis von Messfehlern/-verzerrungen (rot) und Unterschieden im Messbereich (blau) interpretiert werden
Weitere Implikationen des Experiments
- Die RCT-Ergebnisse gelten möglicherweise nicht für Umgebungen, in denen KI-Ergebnisse hunderte oder tausende Male gesampelt werden
- Es ist möglich, dass Effizienzgewinne erst nach dem Einsatz von KI-Tools wie Cursor über Dutzende bis Hunderte Stunden auftreten
- In Umgebungen mit hohem Anspruch an Codequalität und vielen impliziten Anforderungen (Dokumentation, Testing, Formatting usw.) könnte die Fähigkeit von KI begrenzt sein
- Benchmarks haben einen engen Problemzuschnitt und spiegeln die Schwierigkeit realer Arbeit nicht angemessen wider
- Qualitative Berichte über subjektiv empfundene Vorteile können durch Überschätzung und Selbsttäuschungseffekte an Verlässlichkeit verlieren
- Keine einzelne Bewertungsmethode ist perfekt; deshalb sollten sie sich gegenseitig ergänzen
Ausblick
- Diese Methodik soll fortlaufend verbessert werden, um quantitativ nachzuverfolgen, wie stark KI-Tools die Produktivität von Entwicklern tatsächlich verändern
- Falls KI-Tools die Effizienz von Entwicklern in der Praxis stark steigern, könnten zugleich Risiken wie eine abrupte Beschleunigung der KI-F&E insgesamt, Überwachungsversagen oder Machtkonzentration entstehen
- Die Entwicklung eines Bewertungsrahmens, der für reale Umgebungen geeignet ist, ist für die künftige KI-Entwicklung und die gesamte Branche von großer Bedeutung
2 Kommentare
150 Dollar pro Stunde? Schon damit ist die Variablenkontrolle lolololol
Hacker-News-Kommentare
Kommentar von Simon Willison:
Die vollständige Studie enthält viele Details, die in der Zusammenfassung fehlen Link zur Studie
Meiner persönlichen Einschätzung nach gibt es bei LLM-basierten AI-Tools eine deutlich steilere Lernkurve, als die meisten erwarten, wenn man damit echte Produktivitätsgewinne erzielen will
An der Studie nahmen 16 Personen mit unterschiedlicher Erfahrung im Einsatz von AI-Tools teil, 56 % nutzten Cursor zum ersten Mal, und die Untersuchung bezog sich hauptsächlich auf Cursor
Jede teilnehmende Person bearbeitete insgesamt etwa 15 Issues, wobei pro Issue zufällig festgelegt wurde, ob AI verwendet werden durfte oder nicht
Das heißt, dieselbe Entwicklerin oder derselbe Entwickler bearbeitete einen Mix aus Aufgaben mit und ohne erlaubte AI-Nutzung
Nur bei einem Viertel der Teilnehmenden verbesserte sich die Leistung, bei drei Vierteln verschlechterte sie sich
Zu den stärksten AI-Nutzern gehörten Personen mit mehr als 50 Stunden Cursor-Erfahrung
Auch die Forschenden räumen ein, dass Entwickler mit ausreichender Cursor-Erfahrung Leistungsgewinne hatten
Mein Bauchgefühl ist, dass die Studie zeigt, dass die Lernkurve für kollaborative Entwicklung mit AI hoch ist und die Leistung in der Praxis sogar sinkt, wenn man sie einfach direkt in bestehende Workflows mischt
Bei LLMs kommt oft die Reaktion „Du kannst es einfach nicht richtig benutzen“, aber das wirkt wie eine Ausrede, die die Verantwortung zu sehr den Nutzern zuschiebt
Bei den meisten Technologieprodukten würde ich sagen: Wenn Nutzer den Wert nicht spüren, ist das Produktdesign selbst fehlerhaft. Ich frage mich, warum diese Logik bei AI nicht genauso angewendet wird
Danke an Simon, und danke, dass du die Studie so gründlich gelesen hast – ich bin Fan von OS-Projekten und möchte auf einige wichtige Punkte hinweisen
1) Einige frühere Studien zeigen Produktivitätsgewinne auch bei geringer Tool-Erfahrung, die Theorie der „steilen Lernkurve“ erklärt das Ergebnis hier also nicht vollständig
2) Vor der Studie hatten über 90 % der Teilnehmenden Erfahrung mit LLM-Prompting, und Prompting galt als wichtigste Fähigkeit. Die gängige Annahme war, dass man Cursor leicht nutzen kann, wenn man mit VSCode vertraut ist
3) Wenn alle bereits an AI gewöhnt waren, könnten sie ohne AI sogar schlechter arbeiten (zumindest erscheint mir das plausibel). Dann würde ein solcher Effekt eher dazu führen, dass AI besser aussieht, also den gemessenen Rückgang abschwächen
4) Die Erfahrungsdaten wurden vorab mit Prognoseexpertinnen und -experten geteilt, und dennoch lagen deren Erwartungen an Produktivitätsgewinne viel zu hoch
5) Es kann durchaus echte Long-Tail-Skills geben, die erst nach Hunderten Nutzungsstunden entstehen; dazu kann diese Studie wenig sagen
Weil die Studie zu einem überraschenden Ergebnis kommt, ist es für Leser leicht, einen einzelnen Faktor herauszugreifen und zu sagen: „Daran liegt es!“
In Wirklichkeit kann es ein Zusammenspiel mehrerer Ursachen sein (mindestens 5, vielleicht bis zu 9, siehe Tabelle auf Seite 11)
Eine sehr wichtige Implikation: Die selbstberichtete Zufriedenheit der Entwickler wich stark von der Realität ab, und das unabhängig vom verwendeten Tooltyp
Für Produktivitätsmessungen braucht es unbedingt reale Felddaten (siehe Abschnitt C.2.7 der Studie: „Below-Average AI Tool Usage“)
Man kann das so lesen, dass 75 % der Teilnehmenden trotz LLM-Erfahrung mit AI langsamer wurden. Eine Interpretation ist, dass die Lernkurve von LLMs sehr steil ist, eine andere, dass die tatsächliche Effizienz aktueller LLMs als Programmierhilfe überschätzt wird. Menschen verschätzen sich bei Leistungsprognosen konsistent
Selbst wenn man gut mit LLMs umgehen kann, kann das Verständnis für den eigenen Code darunter leiden
Entwickler werden mit der Zeit immer vertrauter mit ihrem Code, ein LLM kann dagegen mit der Zeit sogar schlechter werden
Mit LLMs kann man schnell Code erzeugen, aber wenn man nicht bewusst darauf achtet, baut man selbst keine tiefere Vertrautheit mit dem Code auf
Anfangs wirkt die Entwicklung angenehm schnell, aber im Hintergrund fehlt dann das Verständnis, und auch das LLM liefert irgendwann keine echten Verbesserungen mehr – am Ende entsteht Code-Chaos, das weder das LLM noch der Nutzer noch gut beherrschen
Ich glaube, man muss der Versuchung widerstehen, hartnäckig darauf hinwirken, dass das LLM saubereren Code erzeugt, und den Code selbst wirklich studieren. Eigenes Verstehen ist notwendig
Man sieht, dass einige mit AI produktiver werden und andere nicht
Ich vermute, dass Menschen, die lange Texte oder Code sehr schnell lesen können, einen erheblichen Vorteil haben
Die Fähigkeit, unbrauchbare Vorschläge schnell zu erkennen und so lange zu iterieren, bis gute Antworten kommen, ist sehr wichtig
Schnelles Scannen korreliert zwar mit Erfahrung, aber es gibt überraschenderweise auch Junior-Leute, die darin stark sind
Wer gut recherchieren kann, könnte auch beim Einsatz von LLMs im Vorteil sein, ähnlich wie beim Googeln
Das erinnert mich wieder an die 80/20-Regel – 80 % der Arbeit werden in 20 % der Zeit erledigt, und für die restlichen 20 % gehen dann 80 % der Zeit drauf
Es fühlt sich immer so an, als sei man „fast fertig“, weshalb man leicht in die Sunk-Cost-Fallacy gerät
Ein Ansatz, den ich zuletzt ausprobiert habe, war, AI nicht als „Problemlöser“, sondern als „Reibungsreduzierer“ zu nutzen
Ich programmiere selbst und frage die AI nur nach kleinen Dingen wie vergessener Syntax, um schneller voranzukommen
Direkte Komplettvorschläge für Code schaue ich mir fast nie an. Ich schreibe immer mit eigenem Nachdenken, damit Verständnis und Fähigkeiten nicht nachlassen
Früher war es eher ein umgekehrtes Pareto-Muster: 80 % Aufwand für 80 % der Arbeit, und für die restlichen 20 % dann noch einmal 80 % Aufwand
Ich stimme der Nutzung von AI für „kleine Hürden“ zu
Gestern hatte ich wieder Ärger mit einer
ConcurrentOperationsException, als ich mit der Java Stream API eineListverarbeiteteIch schrieb die Methode erst selbst, kam aber nicht weiter, also bat ich die AI um eine „thread-sichere Listen-Transformationsmethode“, und sie sagte mir, dass es für diese API bereits eine eingebaute Methode gibt
Für solche Kleinkram-Probleme ist AI hervorragend – wenn es komplex, aber klar definiert ist
Besonders nützlich ist es als eine stärkere Version von Stack Overflow: wenn ich grob weiß, was ich tun muss, aber nicht genau, wie in meiner konkreten Umgebung, und auch beim Debugging oder als Rubber Duck hilft es
„Für die letzten 20 % gehen 80 % der Zeit drauf“ war auch schon vor AI meine Erfahrung. Wenn nur die Anfangsphase beschleunigt wird, ist das schon hilfreich. Die beste Einschätzung zu AI, die ich von jemandem mit Erfahrung gehört habe, war: „90 % meiner Skills sind wertlos geworden, und die restlichen 10 % sind tausendmal wichtiger geworden.“ Das ist übertrieben, aber der Kern gefällt mir
Die Illusion, „fast fertig“ zu sein, führt eher zu Zeitverschwendung. AI ist darauf spezialisiert, nützlich auszusehen, deshalb braucht man ein hohes Maß an kritischem Denken, um zu beurteilen, ob die Produktivität wirklich steigt
Besonders nützlich ist es beim Hinzufügen von Features zu bestehenden Codebases, etwa bei Aufgaben wie „füge
foozusätzlich zu den bestehenden Suchparametern hinzu“ oder „entferne den Code rund um x“An die HN-Nutzer: Ich bin Autor der Studie – ich bin schon lange auf HN und versuche heute, möglichst viele Fragen und Rückmeldungen in den Kommentaren zu beantworten. Wer keine Zeit für die ganze Studie hat, dem empfehle ich statt dessen den einführenden Blogpost oder den Vorstellungsthread auf x.com
Die Methodik der Studie und die Art, wie Sie hier kommunizieren, sind sehr professionell und beeindruckend, gute Arbeit
Ich halte diese Studie für eine der besten, weil sie die Ergebnisse ehrlich und ohne Clickbait präsentiert und zudem sehr gut lesbar aufbereitet ist
Haben Sie berücksichtigt, ob die Tickets, die mit AI bearbeitet wurden, wirklich gut für AI geeignet waren? „Versuch mal dieses Ticket mit AI zu lösen“ ist zwar realistisch, kann aber ineffizient sein. Wenn man AI passend einsetzt, bringt sie wirklich etwas, in anderen Fällen wirkt sie eher kontraproduktiv. Wenn die Teilnehmenden genug AI-Erfahrung hatten, hätten sie diese Unterscheidung wohl treffen können, aber beim Lesen der Studie wurde mir nicht klar, ob das der Fall war
Ich frage mich, ob Sie den anonymisierten Rohdatensatz veröffentlichen könnten oder zumindest absolute Bearbeitungszeiten pro Entwickler in die Studie aufnehmen würden. Mich würde interessieren, ob Teilnehmende mit viel Cursor-Erfahrung tatsächlich schneller waren als andere oder ob sie ursprünglich langsamer waren und deshalb mit AI einen größeren relativen Effekt hatten. Es ist erfreulich, eine wirklich gute experimentelle Evaluation zu sehen, die sogar den Hawthorne-Effekt berücksichtigt
(Ich habe die Studie nicht gelesen, nur den Post gesehen.) Wurde subjektive Ermüdung als Kennzahl erfasst, um zu erklären, warum AI fälschlich als schneller wahrgenommen wird? Seit meinem Wechsel von der Entwickler- in die Managerrolle finde ich AI in geistig erschöpftem Zustand angenehmer und daher attraktiver
Dieses Ergebnis der Studie, insbesondere der Teil „Entwickler erwarteten durch AI ein Plus von 24 % an Geschwindigkeit, glaubten aber selbst nach der Erfahrung noch an 20 % mehr Tempo, obwohl sie tatsächlich langsamer waren“, ist äußerst interessant. Warum ist die Lücke zwischen Wahrnehmung und Realität so dramatisch groß? Ich frage mich, ob das Gehirn „mentale Anstrengung“ vielleicht mit dem Zeiterleben verwechselt
Ich habe keine Belege dafür, aber einen beunruhigenden Gedanken: Vielleicht stimuliert die Interaktion mit AI beim Programmieren das Gehirn ähnlich wie ein Social-Media-Dopamin-Loop, auch wenn natürlich in anderer Intensität. AI liefert wiederholt Antworten, wodurch sich das Gehirn anfühlen könnte, als bekäme es positives Feedback, und deshalb bewerten Entwickler AI positiver, als es objektiv gerechtfertigt wäre. Falls das sogar süchtig machende Effekte hat, könnte man dadurch den realen Produktivitätseffekt systematisch überschätzen
Dieses Phänomen könnte auch Ergebnis einer großen Kampagne sein, durch die viele Menschen am Markt AI-Tools für besser halten, als sie tatsächlich sind. Gruppen von Ökonomen und ML-Experten überschneiden sich mit Interessen von AI-Unternehmen, Führungskräfte übernehmen diese Einschätzungen unkritisch und versprechen große Effekte. Das hebt die Basiserwartungen insgesamt an und beeinflusst selbst erfahrene Entwickler. Das lässt sich empirisch schwer belegen, könnte aber erklären, warum sich kollektive Fehlwahrnehmungen zur AI-Produktivität so weit verbreitet haben
Ich frage mich, ob viele AI-Enthusiasten in den HN-Kommentaren ebenfalls in dieses Muster fallen. Solange man die eigene Leistung nicht tatsächlich misst, bleibt fraglich, ob AI die persönliche Produktivität wirklich erhöht
Manchmal erlebt man auch das genaue Gegenteil. Ich habe heute versucht, mit Claude Code den Code für eine Demo-App zu erzeugen, und beim Zuschauen wirkte es cool und fast schon science-fiction-artig, aber nach 15 Minuten war ich geistig abgestumpft und gelangweilt
Wenn man liest, „Entwickler erwarteten, dass AI sie um 24 % schneller macht, glaubten aber trotz realer Verlangsamung immer noch, sie seien 20 % schneller gewesen“, dann scheint es mir, als gäbe es hier zwei Probleme
Zum einen ist es für dieselbe Person im gleichen Kontext schwer, die Zeit mit und ohne AI sauber zu vergleichen
Zum anderen wird AI-Effizienz leicht über oberflächliche Metriken wie die Zeit bis zum Öffnen oder Mergen eines PR gemessen, obwohl mit AI oft mehr Zeit in Refactoring, Tests, Bugfixes und andere Nacharbeiten fließt
Man sieht dann nur „der PR wurde schnell geöffnet“ und glaubt, AI sei schneller, übersieht aber leicht die zusätzliche Arbeit später
Den Einfluss einer bestimmten Technologie oder Praxis auf Produktivität zu messen, ist wirklich schwierig. Es ist gefährlich, allein auf Selbstberichte und Anekdoten zu vertrauen, denn jeder kann leicht Selbsttäuschungen aufsitzen. Auch die Studie selbst erkennt ihre Grenzen an, daher sollte man bei Produktivitätsdiskussionen immer eine große Fehlerspanne mitdenken. AI ist die seltsamste Technologie, die ich je erlebt habe; aus Einzelfällen oder fragwürdigen Benchmarks Kausalität abzuleiten, wirkt fast wie Kaffeesatzlesen
In der Studie wurde kein Qualitätsabfall der PRs zwischen AI-erlaubten und AI-verbotenen Bedingungen beobachtet. Die meisten Teilnehmenden kannten die Standards des jeweiligen Repositories gut und arbeiteten nicht nach dem Muster „einfach irgendwas einreichen, damit ein PR offen ist“. Die mediane Review-Zeit der PRs innerhalb der Studie lag bei etwa einer Minute. Wie Sie sagen, verändert sich die Zeitverwendung allerdings stark. Auf Seite 10 der Studie ist die Zeitverteilung mit und ohne AI dargestellt: Mit AI sinkt die reine Coding-Zeit, dafür steigt die Zeit für die Interaktion mit der AI
Zu dem Einwand, dass man „die genaue Zeitdifferenz derselben Person im selben Kontext mit und ohne AI“ nicht kennen könne: Das Experiment trennt durch Random Assignment den Effekt der AI-Gruppe vom Effekt der Nicht-AI-Gruppe. Unterschiede zwischen Personen, Situationen und Umgebungen werden durch die Zufallszuweisung ausgeglichen. Bei ausreichend großer Stichprobe und Effektgröße lassen sich so statistisch sinnvolle Unterschiede herausarbeiten
Figure 21 zeigt, dass bereits die anfängliche Implementierung selbst (Zeit bis zum PR) länger dauerte, und auch wenn nach dem PR-Review zusätzliche Zeit anfiel, scheint das insgesamt keinen großen zusätzlichen Einfluss gehabt zu haben. Wie Figure 18 zeigt, sank zwar die eigentliche Coding-Zeit, aber dieser Gewinn wurde durch Prompt-Schreiben, Warten auf Ergebnisse und Prüfen des Outputs wieder aufgehoben. Bei sehr einfachen Aufgaben unter fünf Minuten wäre es möglicherweise sogar besser gewesen, gar kein LLM zu verwenden
Ich würde gern die PR-Inhalte der einzelnen Workflows vergleichen. Copilot schlägt bei mir oft mehr Code vor, als ich selbst schreiben würde, häufig mit unnötigen Checks, Wiederholungen und ohne gute Abstraktion, sodass insgesamt mehr Code entsteht. Meine persönliche Hypothese ist, dass der Eindruck, wie viel Code ein LLM ausspuckt, das Gefühl dafür verzerrt, wie lange die Problemlösung tatsächlich dauert
Die wirklich schwierige Seite beim Arbeiten mit LLMs in großen Codebases ist, die eigentliche Aufgabe präzise zu beschreiben. Allein das Erklären eines Problems inmitten vieler Code-Interaktionen dauert oft länger, als es direkt per Hand zu lösen. Dagegen scheinen LLMs bei Boilerplate-Code in neuen Projekten am besten zu passen
Allein für die Rekrutierung der teilnehmenden Entwickler wurden 300 x 246 = rund 73K ausgegeben, und die Studie ist weder in einem Journal erschienen noch peer-reviewed. Die Arbeit wirkt äußerlich ordentlich und nicht AI-generiert, aber ich frage mich, wie eine solche Finanzierung möglich war
Die größte Förderung kam vom The Audacious Project, das lässt sich in der offiziellen Ankündigung nachlesen. Außerdem steht in einer Fußnote auf der Website, dass bis April 2025 keine Vergütung von AI-Unternehmen für Evaluierungen angenommen wurde
Unternehmen veröffentlichen oft solche Arten von „Whitepapers“ – eine Mischform aus technischem Bericht, Policy-Vorschlag und Werbematerial
Es ist aus meiner Sicht nicht besonders sinnvoll, nur darauf zu schauen, ob etwas in einem Journal erschienen oder peer-reviewed ist. In der Wissenschaft sind Reproduzierbarkeit und wiederholbare Ergebnisse entscheidend, nicht wer etwas publiziert. Die Replikationskrise in der Psychologie zeigt, dass Journal-Veröffentlichungen für sich genommen keine Verlässlichkeit garantieren
In den meisten Ländern gibt es öffentliche Fördermittel für Forschung; die USA haben früher mehr davon bereitgestellt, in jüngerer Zeit aber stark gekürzt
Laut der Seite über die Stiftung kommt die Finanzierung wohl aus verschiedenen Quellen, darunter AI-Unternehmen und Regierungen
In Hobby-OSS-Projekten ist AI für mich eher ein Hindernis. Code-Generierung oder Scaffolding ist nicht einmal mein Hauptproblem; wichtiger sind Code-Review und Community-Management. Was AI-Tools dort leisten können, ist klar begrenzt. Trotzdem hat jemand bei einem meiner offenen PRs ein AI-Code-Review-Tool eingesetzt, das selbst für einen 30-Zeilen-PR zwei Seiten Zusammenfassung mit Emojis und sauber formatierten Bulletpoints ausgespuckt hat. Das ist nur unnötiges Rauschen, und inzwischen verliere ich echte Maintainer-Zeit damit, solche Kommentare zu löschen oder zu verbergen
Wenn man nur die Lernkurve überwindet, wird man vielleicht schneller – oder, wie jemand sagte, „bis man vergessen hat, wie man ohne AI arbeitet“. Aber was man eigentlich messen müsste, ist etwas anderes: Wenn um 3 Uhr morgens der PagerDuty-Alarm losgeht, wie lange dauert dann wirklich das Debuggen dieses Codes? Und wie sieht die langfristige Qualität dieses Codes aus? Ich habe über lange Zeit die Struktur meines Codes verbessert, Geschäftslogik in gemeinsame Ordner gezogen, Aufrufketten weiter nach oben verlegt, APIs dadurch sauberer gemacht, Logik/API/Anzeige getrennt, Kapselung verbessert und durch Dependency Injection die Kopplung reduziert. Wird AI-generierter Code langfristig bessere Qualität, Portabilität und Erweiterbarkeit haben? Oder häuft sich am Ende immer mehr minderwertiger Code an, bis alles zu einer verworrenen Müllhalde wird und man schließlich die Hälfte der Zeit in Bugfixes steckt?