Pop!_OS verbannt KI-generierten Code aus weiten Teilen seiner Codebasis

Völlig performativ.

Du baust dein OS auf Tausenden von Open-Source-Paketen auf, von denen viele KI-generierten Code enthalten. Willst du sie einzeln prüfen und die beanstandeten Pakete entfernen? Was ist mit denen, die du nicht entfernen wirst, weil das OS irreparabel kaputt wäre?

Ich hatte einen PR in der Pipeline, der deswegen geschlossen wurde. Ich hatte ein Problem mit Passwörtern im Netzwerk-Applet für das VPN und hatte Claude genutzt, um es zu identifizieren und dann einen Fix zu finden. Ich habe viel Zeit damit verbracht, es von Hand zu machen und sicherzustellen, dass die Qualität gut ist, aber ich respektiere ihre Entscheidung und bin nicht nachtragend, aber als jemand, der Schwierigkeiten hatte, Zeit und Gelegenheit zu finden, zu Open Source beizutragen, war es ein kleiner Rückschlag.

Hier läuft gerade ein Thread zu einem ähnlichen Thema von einem AWS-Experten (ehemaliger AWS-CTO)

"Anscheinend führt KI nicht in allen Softwareentwicklungsteams zu positiven Ergebnissen. Kunden fragen mich, ob sie die Einführung von KI in ihren Teams verlangsamen sollten.

Wie antwortet man darauf?

Ja? Nein?"

https://www.linkedin.com/feed/update/urn:li:activity:7510679...

Es fühlt sich an, als wäre ein Teil davon eine Lerngewohnheit, die Beherrschung der Tools (KI-Agenten) selbst und ein besserer Workflow darum herum, aber bleibt KI nicht noch unvollkommen?

Ich sehe nicht, wie das die Angreifer-Verteidiger-Lücke überleben soll, da ls immer besser in Cybersicherheit werden und 0-Days finden ... aber vielleicht ist es obskur genug, dass es keine Rolle spielt?

Ich frage mich, ob das Problem hauptsächlich der Code ist oder die von KI geschriebenen PRs und Leute, die KI benutzen, um mit den Maintainern zu reden. Ich persönlich banne jeden, der Letzteres tut, ich will nicht mehr mit Opus reden als ich es ohnehin schon tue lol

Ok, das mag kontrovers sein, aber LLM-Code-Token sind nicht kostenlos, und ich verbrauche mein wöchentliches Kontingent ziemlich regelmäßig schon mit einigermaßen aufwendigen Projekten, also verstehe ich nicht, warum jemand jemals sein eigenes Geld ausgeben würde, um absichtlich schlechte PRs zu machen, und ich nehme bei Menschen gerne gute Absichten an, solange das Gegenteil nicht bewiesen ist, was bedeutet, dass ein fast pauschales Verbot von LLM-verfasstem Code für diese großen Open-Source-Projekte mir etwas extrem erschien, wo das Kernproblem doch zu sein schien, dass sich Review-Prozess/Richtlinie mit der Zeit ändern sollten.

Zum Beispiel habe ich Anfang des Jahres an einer Open-Source-Game-Engine mitgeholfen, die einen seit etwa 2021 bestehenden Text-Rendering-Bug hatte, der verhindert, dass die Engine produktionsreif ist, und für den die Community und ich umfangreiche Workarounds entwickelt haben. Eines Tages habe ich schließlich genug gehabt und Claude dazu gebracht, ihn zu debuggen. Claude brauchte 10 Minuten, um den Bug zu finden, es waren 3 Zeilen Codeänderung im Renderer (ja, drei).

Also schrieb ich die Regressionstests, dokumentierte den Bug und öffnete einen PR für den Fix, in der Annahme, dass er in weniger als einer Woche gemerged wird und wir alle weitermachen können. Die Maintainer nahmen ihn im PR recht gut auf, aber der PR lag fast 6 Monate ungemerged herum, bis er schließlich wegen eines schlechten Squash upstream geschlossen wurde. Ich bin mir ziemlich sicher, dass der Bug auch noch da ist.

Und nebenbei bemerkt, wäre ich überglücklich, wenn jemand mit seiner KI zu meinen Github-Projekten beitragen möchte.

"... viele der KI-Beiträge waren nicht geplant und zeigten wenig Verständnis für die Softwarearchitektur. Also möchte das Team 'die Arbeit an Beiträgen unseres eigenen Teams und regelmäßiger Beitragender priorisieren.'"

Klingt vernünftig, selbst für begeisterte LLM-Nutzer, nehme ich an. Man muss eine Grenze ziehen. Diese Grenze ist zu simpel, aber sie wird erstmal funktionieren.