KI schreibt Code doppelt so schnell. Und jeder vierte Pull Request ist Müll. Beides steht in derselben Studie. Linux Foundation Research hat gerade untersucht, wie generative KI die Arbeit in Open Source Projekten verändert. Das Ergebnis ist ein ehrliches Bild: KI Coding bringt echtes Tempo, aber ohne Guardrails entsteht AI Slop. Und auf diesen Slop können sich Maintainer nicht verlassen.
Wir arbeiten jeden Tag mit OpenCode und Open Weight Modellen. Wir wollen nicht mehr zurück. Gerade deshalb lohnt der Blick auf die Zahlen. Sie zeigen, wo KI heute steht und warum Regeln, Tests und Review keine Bremse sind. Sie sind die Voraussetzung, damit KI im Team überhaupt funktioniert.
KI Coding ohne Slop: Eure Developer lernen, Coding Agents mit Tests, Regeldateien und Quality Gates sicher einzusetzen. Zum NCA KI Workshop für Developer
Was die Linux Foundation Studie zu KI in Open Source zeigt
Die Studie heißt Navigating Open Source Software Development in the Generative AI Era. Sie kommt von LF Research, gesponsert von Red Hat, mit Unterstützung von Futurewei, OpenSSF und LF AI und Data. Vorgestellt wurde sie auf der All Things Open in Raleigh. Die wichtigsten Zahlen aus der Pressemitteilung der Linux Foundation:
- 52 Prozent weniger Zeit beim Code schreiben, so schätzen es die Befragten im Schnitt.
- 59 Prozent der Maintainer bekommen seit dem KI Boom mehr Beiträge, bei großen Projekten sind es 69 Prozent.
- 25 Prozent der eingehenden Pull Requests gelten als minderwertiger AI Slop, bei großen Projekten 31 Prozent.
- 21 Prozent brauchen bei komplexen Aufgaben mit KI sogar länger.
- 53 Prozent der Maintainer widersprechen der Aussage, dass KI das Vertrauen in der Community verbessert hat.
Das Tempo ist also real. Die Qualität ist es nicht automatisch. Genau diese Lücke ist das Thema.
Warum jeder vierte Pull Request AI Slop ist
KI senkt die Hürde. 71 Prozent der Maintainer sagen, dass Einsteiger mit KI leichter zu Open Source finden. Das ist erst mal gut. Nur kostet ein Pull Request mit KI fast nichts mehr. Das Review kostet weiter genauso viel Zeit wie vorher. Die Last landet bei den Menschen, die prüfen müssen.
Was AI Slop im Alltag bedeutet, kennt jeder Maintainer:
- Code, der plausibel aussieht und am eigentlichen Problem vorbeigeht.
- Tests, die grün sind, weil sie nichts Wichtiges prüfen.
- Änderungen, die der Einreicher selbst nicht erklären kann.
- Große Diffs, die keiner bestellt hat.
Die Studie zeigt auch, wo es hakt. Nur 61 Prozent der Contributors machen vor dem Einreichen ein gründliches Review und volle Funktionstests ihres KI Codes. Ob KI im Spiel war, legen viele nicht offen. Adrianne Marcum, Chief of Staff der OpenSSF, bringt es in der Mitteilung auf den Punkt:
… contributors still need to understand and test what they submit.
Adrianne Marcum, Chief of Staff, OpenSSF
Verstehen und testen. Das ist der Kern. Wer KI Code einreicht, den er nicht versteht, verschiebt Arbeit auf andere. Warum das bei Tests besonders gefährlich ist, zeigen wir im Beitrag Gute Tests zementieren keinen Slop.
KI Coding bei komplexen Aufgaben
Die Studie hat sechs Tätigkeiten gemessen. Überall sparen die Befragten im Schnitt Zeit, beim Code schreiben am meisten, bei Diskussionen über Vorschläge rund 19 Prozent. Bei komplexen Aufgaben dreht sich das Bild für einen Teil der Leute. Jeder Fünfte braucht mit KI dort länger.
Das passt zu dem, was wir täglich sehen. Bei klaren, kleinen Aufgaben ist KI brillant. Bei Architektur, verteiltem Zustand oder fachlich kniffliger Logik produziert sie mit der gleichen Überzeugung Fehler. Die Grenze dazwischen ist unsichtbar. Wir haben das ausführlich in Rote Linie für KI im Coding beschrieben. Dazu passt die Geschichte von 800.000 Zeilen gelöschten Tests, die zeigt, was ein Agent ohne Leitplanken anrichten kann.
Kann man sich beim Programmieren auf KI verlassen
Die kurze Antwort: Blind auf keinen Fall. KI ist ein starkes Werkzeug. Sie ist kein Kollege, der Verantwortung übernimmt. Jedes Ergebnis braucht eine Prüfung, die sich nicht von einer gut klingenden Begründung überreden lässt. Ein grüner Test ist ein Beweis. Ein langer Text im Chat ist keiner.
Die Linux Foundation sieht es ähnlich. Hilary Carter, SVP of Research, fordert klare Erwartungen an KI, Verantwortung für Tests und Offenlegung bei den Contributors und bessere Werkzeuge für Maintainer. Die Studie empfiehlt, Governance, Verifikation und Vertrauen als Kerninfrastruktur zu behandeln. Das ist genau unser Ansatz.
KI Richtlinien fehlen in den meisten Projekten
Hier liegt das größte Problem der Studie. Nur 35 Prozent der Projekte haben eine formale Policy, die KI erlaubt und regelt. 32 Prozent haben gar keine und planen auch keine. Die Tools sind also längst im Einsatz, die Regeln fehlen.
In Firmen sieht es oft nicht besser aus. Jeder nutzt sein eigenes Tool, mit eigenen Prompts und ohne gemeinsame Regeln. So entsteht AI Slop auch intern, nur ohne öffentliche Maintainer, die ihn aussortieren. Die Tabelle zeigt, welche Guardrail zu welchem Befund passt:
| Befund der Studie | Was im Team passiert | Guardrail |
|---|---|---|
| 25 Prozent AI Slop | Review frisst die gesparte Zeit | Pipeline Gate vor jedem Merge Request |
| Mehr Zeit bei komplexen Aufgaben | Agent dreht sich im Kreis | Aufgaben klein schneiden, Architektur bleibt beim Menschen |
| Nur 61 Prozent testen gründlich | Ungeprüfter Code landet im Branch | Tests first mit PHPUnit, pytest und Cypress |
| Offenlegung uneinheitlich | Keiner weiß, was die KI gemacht hat | Kennzeichnung im Merge Request |
| Keine KI Policy | Jeder arbeitet anders | Gemeinsame Regeldateien wie AGENTS.md |
| Mehr Bedarf an Mentoring | Junioren übernehmen KI Code ungeprüft | Review Pflicht und Pairing |
Welche Guardrails gegen AI Slop helfen
Gegen Slop hilft kein besseres Modell allein. Warum Guardrails mit jedem stärkeren Modell sogar wichtiger werden, steht in Warum KI Guardrails mit jedem besseren Modell wertvoller werden. In der Praxis setzen wir auf eine feste Kette:
- Tests first: Erst steht der Test, dann schreibt der Agent Code. Unit Tests für die Logik, Cypress E2E Tests für echte Nutzerwege. Welche Ebenen mit Agents wichtiger werden, zeigt die Testpyramide für KI Agents.
- Statische Analyse: PHPStan, Psalm und Rector bei PHP, Ruff und mypy bei Python. Der Agent lässt sie lokal laufen, bevor er pusht.
- Regeldateien: Architektur, Namenskonventionen und Verbote stehen schriftlich für den Agent. Vorlagen dafür sind die NCA PHP AI Coding Guidelines.
- Pipeline als Gate: GitHub Actions oder GitLab CI prüfen jeden Merge Request. Was rot ist, kommt nicht rein.
- Mensch beim Merge: Kein Agent merged selbst. Review bleibt Pflicht, gerade bei komplexen Änderungen.
Wie das als Gesamtsystem aussieht, beschreiben wir bei den NCA Agentic AI Coding Guardrails. Typische Fallen ohne diese Kette sammeln wir unter Vibe Coding Risiken. Wer schon AI Slop im Projekt hat, findet den Weg raus im Beitrag AI Slop Refactoring.
Was wir aus der Studie mitnehmen
Die gesparte Zeit fließt bei vielen zurück ins Projekt. 66 Prozent bauen damit technische Schulden ab, 63 Prozent entwickeln neue Features, 58 Prozent lernen Neues. Das ist der schöne Teil. Er funktioniert nur, wenn die Qualität stimmt. Sonst geht die gesparte Zeit im Review und im Bugfixing wieder verloren.
Und noch etwas fällt auf: 46 Prozent der Maintainer sagen, dass KI mehr Mentoring nötig macht. Nur 32 Prozent sehen weniger Bedarf. KI ersetzt also keine Erfahrung. Sie macht Erfahrung wichtiger, weil jemand erkennen muss, wann das Ergebnis falsch ist.
Fazit
KI ist schnell, aber noch lange nicht verlässlich. Die Linux Foundation Studie belegt beides mit Zahlen: halbe Zeit beim Code schreiben, ein Viertel AI Slop, mehr Aufwand bei komplexen Aufgaben und kaum Regeln in den Projekten. Wer KI Coding ernsthaft nutzen will, braucht Tests first, statische Analyse, Regeldateien, ein Pipeline Gate und einen Menschen beim Merge. Dann wird aus Tempo auch Qualität.
Schluss mit AI Slop im eigenen Code
Wir richten mit euch Coding Agents, Regeldateien und Quality Gates ein, damit KI schnell ist und der Code trotzdem in Production taugt. Im kostenlosen Kennenlernen schätzen wir den Aufwand, abgerechnet wird transparent auf die Minute.
