- Django-Tickets mit LLMs zu bearbeiten, ist nicht hilfreich; sinnvoller ist es, diese Ressourcen direkt an die Django Software Foundation zu spenden
- Django ist ein Projekt mit sehr hohen Qualitätsstandards und Fokus auf langfristige Stabilität, das ein tieferes Verständnis als bloße Code-Generierung erfordert
- Wenn ein LLM anstelle des Autors Code erstellt und auch PR-Beschreibungen sowie Antworten auf Reviews übernimmt, entsteht das Problem, dass sich kaum beurteilen lässt, ob der Beitragende die Sache wirklich versteht
- Im Mittelpunkt von Open-Source-Beiträgen stehen menschliche Kommunikation und Zusammenarbeit in der Community; wenn ein LLM das verdeckt, schwächt das das Vertrauen zu den Reviewern
- Wer zu Django beitragen will, muss durch eigenes Lernen und Experimentieren Verständnis aufbauen; genau das fördert auch das Wachstum als Entwickler
Die Grenzen von Django-Beiträgen über LLMs
- Django-Tickets mit Hilfe von LLMs zu lösen, ist für die Community kein wirklicher Gewinn
- Wenn PRs mit von LLMs erzeugtem Code eingereicht und Feedback ebenfalls darüber bearbeitet wird, ist schwer zu erkennen, wie tief das Verständnis des Autors tatsächlich reicht
- Aus Sicht der Reviewer fühlt es sich dann an, als würden sie nicht mit einem Menschen, sondern mit einer „Fassade vorgetäuschten Verständnisses“ sprechen
- Django hat eine große Nutzerbasis, langsame Veränderungszyklen und Qualitätsanforderungen als Projekt, das über 20 Jahre bestehen soll
- Deshalb sind tiefes Verständnis und verantwortungsvolle Beiträge wichtiger als bloß automatisierte Code-Erzeugung
Der richtige Einsatz von LLMs
- LLMs sollten als Hilfsmittel zum besseren Verständnis eingesetzt werden
- Sinnvoll ist, zunächst eine Erklärung in eigenen Worten zu formulieren und sie dann mit Hilfe eines LLM sprachlich zu überarbeiten
- Wenn Kommunikation schwerfällt, kann ein LLM aktiv genutzt werden, die Nutzung sollte dann aber offengelegt werden
- Wer zu Django beiträgt, sollte Problem, Lösung und Review-Feedback selbst verstehen
- Ohne echtes Verständnis erzeugter Code kann die Qualität des gesamten Projekts beeinträchtigen
Menschenzentrierte Open-Source-Zusammenarbeit
- Beiträge zu Django sind eine gemeinschaftliche Erfahrung und schließen menschliche Transparenz und Verletzlichkeit mit ein
- Wenn ein LLM diese Menschlichkeit verdeckt, wird Zusammenarbeit schwieriger
- Reviewer sind motivierter, wenn die Kommunikation auf „echtem menschlichem Verständnis“ beruht
- LLMs sollten nur als unterstützendes Mittel verwendet werden und nicht die eigentliche Rolle des Beitragenden ersetzen
Das Wesen und der Wert von Django-Beiträgen
- Django ist ein Projekt mit 20 Jahren Geschichte und langfristiger Vision; jeder hinzugefügte Code sollte gründlich verstanden werden
- Für dieses Verständnis sind Zeit, Experimente und Lernen unverzichtbar
- Zu Django beizutragen ist mehr als nur eine Namensnennung; es ist eine Erfahrung, die Wachstum als Entwickler ermöglicht
- Das Lernen im Beitragsprozess ist weit wertvoller, als nur auf einer Liste zu erscheinen
Ein Vorschlag an die Community
- Nutzt LLMs nicht übermäßig, um euch selbst und euer Verständnis zu verbergen
- Die Django-Community möchte mit echten Menschen zusammenarbeiten
- Wenn ihr Django unterstützen wollt, ist es am effektivsten, Zeit und Geld zu investieren oder an die Django Software Foundation zu spenden
1 Kommentare
Hacker-News-Kommentare
Ich denke, dass LLMs in jeder Codebasis mit menschlichen Reviewer:innen Probleme verursachen können
Wenn man LLMs nutzt, ohne Tickets, Lösungen oder PR-Feedback zu verstehen, schadet das dem gesamten Projekt
Open-Source-Beiträge sind ein gemeinschaftlicher Akt, aber LLMs verdecken die Transparenz und Verletzlichkeit von Menschen
Aus Sicht der Reviewer fühlt es sich an, als würde man mit der „Maske“ eines Menschen sprechen, und das ist eine demotivierende Erfahrung
Deshalb sollten LLMs nur unterstützend als Werkzeug eingesetzt werden und nicht als Ersatz dienen
In Teams sieht man inzwischen stark zunehmende Zahlen von AI-verfassten PRs, und sogar Claude oder Codex übernehmen das Review-Feedback
Wenn sich so eine Kultur etabliert, dürfte das branchenweit zum Zusammenbruch von Vertrauen und zu sinkender Motivation führen
Statt echter Produktivitätssteigerung bleibt nur das „Gefühl, irgendwie schneller zu sein“
Weil Organisationen Produktivität in der Praxis nicht sauber messen, kennt niemand den Nettoeffekt solcher Funktionen
Der breite Einsatz von AI untergräbt Vertrauen
Es sieht oberflächlich besser aus, aber die Authentizität geht verloren
Am Ende kommt der Code also durch, daher frage ich mich auch, ob die Leute vielleicht gar nicht unzufrieden sind
Die besten Kolleg:innen, mit denen ich gearbeitet habe, haben es Reviewer:innen immer leicht gemacht zu kritisieren
Sie haben Annahmen, Unklarheiten und Fehlversuche klar dokumentiert und so erklärt, dass Reviewer sie leicht widerlegen konnten
Wenn ein PR solche Demut und Selbstreflexion zeigt, macht es mir nichts aus, wenn ein LLM beteiligt war
Das Problem ist eher, dass Leute, die früher schon Code eingereicht haben, der nicht einmal sauber baut, jetzt mit LLMs noch mehr miserable PRs produzieren
Deshalb stimme ich der Aussage „Solange der Code läuft, ist es egal, wer ihn geschrieben hat“ nicht zu
Die Lage ist inzwischen außer Kontrolle
Vor allem weil GitHub-Aktivität im Bewerbungsprozess als Bewertungskriterium zählt, versuchen Leute mit LLMs, ihre Beitragshistorie zu manipulieren
In der Praxis reicht es dann, wenn ein PR durchgeht, ohne dass die Person das Projekt wirklich versteht
Wenn gute Entwickler:innen LLMs verwenden, ist das kein Problem
Das Problem ist, dass Menschen, die ohnehin wenig konnten, dank LLMs jetzt noch mehr Code von niedriger Qualität einreichen
Schon früher haben Leute Code ohne Verständnis aus StackOverflow kopiert und eingefügt
AI hat das nur verstärkt
Wenn jemand in vielen Repositories ähnliche PRs verstreut und die meisten abgelehnt werden, ist das ein klares Signal
Am Ende müssen wir wieder zu einer qualitätsorientierten Beitragskultur zurückkehren
Das Problem zu erkennen ist einfach, aber Konsens und praktikable Lösungen zu schaffen ist schwierig, und gerade darin sind Techniker:innen oft nicht stark
Mir gefällt die Idee, Geld zu spenden
Die Kernbeitragenden von Django können Mittel wahrscheinlich besser nutzen als Tokens
Andere Projekte ergreifen Maßnahmen wie die Offenlegung von AI-Nutzung, einen vorübergehenden Stopp externer Beiträge oder Beschränkungen beim Erstellen von Issues
PRs niedriger Qualität lassen sich zu leicht erzeugen und greifen die Zeit und Konzentration der Community an
Deshalb könnte es nötig sein, zu geschlosseneren Kollaborationsmodellen überzugehen
Auch Debians Entscheidung, dieses Problem vorsichtig anzugehen, fand ich beeindruckend
Statt Tokens zu kaufen, sollte man meiner Meinung nach einfach den Kernbeitragenden Geld spenden und sie selbst entscheiden lassen, wie sie es verwenden
Mit der Aussage „Für Reviewer ist es mental erschöpfend, mit der Maske eines Menschen zu sprechen“ kann ich mich sehr identifizieren
Eine der Belohnungen von Open Source ist der Austausch mit Menschen, und wenn der verschwindet, fühlt es sich nur noch nach Arbeit an
Am Ende haben alle weniger Geduld, und die Freude an Zusammenarbeit geht verloren
So wie man sich mit der Stammmetzgerei unterhält, wollen sie Beziehungen aufbauen
Das Schreiben von Aufsätzen ist mit LLMs einfacher geworden, aber Validierung und Review sind weiterhin schwierig und zeitaufwendig
Deshalb braucht es Möglichkeiten, AI-Nutzung offenzulegen oder PRs mit AI-Erkennungsalgorithmen zu markieren
Letztlich würde das dazu führen, dass Menschen LLM-Antworten in ihre eigene Sprache übersetzen müssen
Realistisch betrachtet gibt es aber immer Menschen, die Regeln ignorieren
Innovation wirkt heute insgesamt in Richtung kurzfristiger Belohnungen
Die Anreizstruktur unterstützt keine Menschen mit langfristiger Perspektive
Wenn man sich einmal mit Spieltheorie beschäftigt, ist es schwer zu bestreiten, dass die Welt genau so gestaltet ist
Deshalb stößt sie bei der Bewertung langfristiger Strategien an Grenzen
Gute Botschaft, aber die Leute, die alles mit LLMs machen, werden solche Texte vermutlich gar nicht lesen
Auch für mich als Open-Source-Maintainer ist es schwer zu erkennen, ob Code von AI geschrieben wurde
Solche professionellen Entwickler:innen gibt es in Wirklichkeit kaum
Ich frage mich eher, ob man nicht ein eigenes Open-Source-Projekt nur für LLMs schaffen sollte
Also eines, das nur von LLMs erzeugten Code sammelt und ein klar definiertes Beitragsprotokoll hat
Allerdings dürften viele LLM-Beiträge schlicht für das Portfolio gedacht sein
Es hat Tausende Beitragende und Zehntausende Commits
AI steigert die Produktivität oft nicht, sondern wälzt nur die Last der Verifikation auf andere ab
Am Ende müssen Maintainer mehr Arbeit übernehmen, während Beitragende nur die Lorbeeren einstreichen
Ich selbst habe bei Projekten wie Django schon mit LLMs Patches erstellt
Ohne LLM hätte ich es wahrscheinlich gar nicht erst versucht
Das Ergebnis habe ich aber selbst geprüft und auch Tests geschrieben
Heute übernehmen LLMs oft Code, PR-Beschreibung und sogar die Antworten im Review komplett
Aus Sicht der Reviewer denkt man dann fast: „Dann kann ich den Review auch gleich mit einem LLM machen lassen“
Deshalb sollten LLMs als Hilfswerkzeug genutzt werden und nicht als Ersatzmittel