Dev & Cloud

COSMIC interzice conținutul generat de AI în pull request-uri: de ce proiectele open-source trag frâna

Inteligența artificială a făcut mai ușor ca oricând să generezi cod, rapoarte de bug-uri și descrieri pentru pull request-uri. Dar viteza cu care pot fi produse aceste materiale nu înseamnă automat progres pentru proiectele open-source. COSMIC, mediul desktop dezvoltat de System76 pentru Pop!_OS, a adoptat o regulă clară: contribuțiile trimise prin pull request nu pot conține material generat de LLM-uri, fie că vorbim despre cod, comentarii sau descrierea schimbărilor. Decizia nu este un gest simbolic anti-AI și nici o declarație că orice cod asistat de un model este inutil. Este, înainte de toate, o măsură de protejare a timpului limitat al maintainerilor. Pentru comunitățile open-source, problema reală nu este doar calitatea variabilă a codului generat, ci costul uman al verificării lui.

Ce a decis COSMIC și care este, de fapt, aria interdicției

Schimbarea a fost integrată în proiectul cosmic-epoch la 30 septembrie 2026, printr-un nou șablon obligatoriu pentru pull request-uri. Orice contributor trebuie să confirme că nu a inclus conținut generat de LLM — explicit: cod, comentarii și descrieri ale pull request-ului. În plus, acesta trebuie să declare că înțelege în totalitate modificările, poate răspunde observațiilor primite la review și și-a testat contribuția. (github.com)

Nu este o nuanță minoră: COSMIC nu spune doar „nu trimite cod generat de AI fără să-l verifici”. Regula exclude conținutul generat de AI din pull request, inclusiv textul care îl explică. Este o poziție mai strictă decât simpla obligație de a divulga utilizarea unui asistent AI.

Totuși, titlul „COSMIC interzice toate contribuțiile AI” are nevoie de puțin context. Politica confirmată public vizează pull request-urile, nu stabilește automat același mecanism pentru orice tip de interacțiune din ecosistemul proiectului: discuții, documentație externă, conversații pe forum sau utilizarea personală a unor unelte de productivitate. În open source, această delimitare contează. O regulă aplicabilă într-un flux GitHub poate fi verificată printr-un checklist; o interdicție absolută asupra oricărei utilizări de AI în viața unui dezvoltator ar fi aproape imposibil de demonstrat și administrat.

De ce codul „care pare bun” poate costa mult la review

Un model lingvistic poate produce repede o funcție, un patch aparent coerent sau un raport de eroare foarte lung. Problema este că review-ul nu se face după aspect. Un maintainer trebuie să înțeleagă intenția schimbării, impactul asupra componentelor existente, cazurile-limită, riscul de regresii, licențierea și mentenabilitatea peste câteva luni sau câțiva ani.

Într-un exemplu anterior din trackerul COSMIC, un raport de bug redactat cu ajutorul Claude a fost închis, iar un membru al proiectului a explicat direct că echipa nu are timp să verifice issue-uri generate de LLM-uri și nu poate avea încredere în speculațiile dintr-un astfel de text. (github.com) Nu înseamnă că problema raportată era neapărat imaginară. Înseamnă că autorul nu putea explica suficient de bine ce a testat și de ce concluziile din raport ar trebui tratate ca date tehnice fiabile.

Aici apare diferența dintre „un cod care compilează” și „o contribuție utilă”. Un patch poate trece testele de bază și totuși să introducă o dependență inutilă, să dubleze logică existentă, să ignore convențiile proiectului sau să trateze greșit situații rare. Dacă persoana care trimite contribuția nu poate justifica fiecare decizie, maintainerul devine, practic, operatorul de control al unui cod pe care nimeni nu și-l asumă pe deplin.

Aceeași problemă se vede și în alte domenii din research-ul disponibil. Designerii descriu materialele vizuale generate automat ca fiind deseori aglomerate, fără ierarhie clară și fără atenție reală pentru informația importantă. În zona editorială și academică, apar preocupări similare legate de conținut generat automat, credibilitate și costul verificării. Aceste exemple nu demonstrează direct cazul COSMIC, dar ilustrează aceeași dinamică: când producția devine aproape gratuită, filtrarea devine partea scumpă. (linuxiac.com)

Nu este o declarație de război împotriva AI

Decizia COSMIC trebuie citită mai degrabă ca o regulă de guvernanță a proiectului decât ca un verdict universal asupra AI-ului pentru programare. Pentru un dezvoltator individual, un LLM poate fi util pentru a explica un mesaj de eroare, a sugera un test, a rezuma documentația sau a accelera prototiparea. Pentru un proiect matur, cu o echipă mică și mii de utilizatori, standardul trebuie să fie mai ridicat: contribuția trebuie să fie înțeleasă, testată și asumată de omul care o trimite.

Este relevant și faptul că noul template COSMIC cere confirmarea respectării Developer Certificate of Origin, un mecanism prin care contributorul certifică dreptul de a trimite acel cod. (github.com) În cazul conținutului generat de modele antrenate pe volume foarte mari de date, întrebările despre proveniență, licențe și similaritatea cu cod public sau proprietar nu dispar doar pentru că rezultatul final pare original.

Din această perspectivă, regula reduce trei riscuri simultan:

  • riscul tehnic, când un patch ascunde defecte sau regresii;
  • riscul de mentenanță, când nimeni nu poate explica de ce există o anumită soluție;
  • riscul juridic și de atribuire, când originea exactă a unor fragmente de cod rămâne neclară.

Ce merită ignorat este ideea că o asemenea politică va „opri AI-ul” din dezvoltarea software. Nu va face asta și nici nu își propune. Va muta responsabilitatea acolo unde trebuie să fie: la persoana care trimite schimbarea și la proiectul care decide ce acceptă în codul său.

Ce înseamnă pentru dezvoltatorii și comunitățile din România

Pentru programatorii români care contribuie la proiecte open-source, lecția nu este „nu mai folosiți niciodată ChatGPT, Copilot sau Claude”. Lecția este mai practică: nu tratați rezultatul unui model ca pe o contribuție gata de expediat.

Dacă folosești AI pentru a te orienta într-un cod complex, rezultatul final trebuie rescris, verificat și înțeles de tine. Dacă un proiect are o politică explicită precum COSMIC, respectarea ei trebuie să fie literală: nu trimite cod, comentarii sau texte de PR produse de LLM. Chiar și acolo unde politica permite utilizarea de AI, un PR bun are nevoie de o descriere clară, scrisă de autor, cu problema rezolvată, deciziile luate, testele rulate și limitările cunoscute.

Pentru startup-uri, agenții și echipe mici din România, cazul COSMIC este un avertisment util înainte ca „vibe coding” să devină proces implicit. AI poate reduce timpul de scriere, dar nu reduce automat timpul de validare. În produse cu utilizatori reali, costul se mută către code review, QA, securitate și suport. Dacă fiecare dezvoltator poate genera de zece ori mai multe schimbări, echipa nu devine de zece ori mai capabilă decât dacă își poate verifica și întreține acele schimbări.

Lucruri practice de urmărit:

  • Citește regulile de contribuție înainte de a deschide un issue sau un pull request.
  • Nu trimite cod pe care nu îl poți explica linie cu linie la review.
  • Rulează testele relevante și descrie concret rezultatele, nu doar „testat local”.
  • Separă prototipul generat rapid de codul pregătit pentru producție.
  • Pentru proiecte proprii, stabilește intern ce utilizări AI sunt acceptate și cine își asumă review-ul final.

Concluzie

COSMIC nu blochează inovația, ci încearcă să apere un element rar în open source: atenția oamenilor care întrețin proiectul. Într-o perioadă în care AI poate produce cantități foarte mari de cod și text plauzibil, filtrul valoros nu mai este capacitatea de a genera, ci capacitatea de a înțelege, testa și răspunde pentru ce ajunge în produs. Pentru comunitățile tehnice, inclusiv cele din România, acesta poate fi standardul sănătos: folosește unelte rapide, dar nu externaliza responsabilitatea.