GitHub 18 éve tette alapértelmezetten nyitottá a pull requesteket (PR-eket), de néhány, kifejezetten mesterséges intelligenciára épülő nyílt forráskódú projekt mostanra a külső PR-ek automatikus lezárása mellett döntött. A döntést azzal indokolják, hogy jobb munkafolyamatot találtak: a karbantartók saját ügynökeiket (agents) használják a PR-ek létrehozására és kezelésére, illetve egész „software factory” rendszereket építenek a közösségi hozzájárulások kezelésére.
A software factory ötlete és Vercel esete
Vercel egy bejegyzésben írt arról, hogy hogyan épített „software factory”-t az AI SDK nyílt forrású projektjéhez. Az AI SDK hetente több mint 20 millió npm-letöltést kap. A projekt június végi állapot szerint „több mint 1 000 nyitott issue-dal és közel 800 pull requesttel” küszködött a backlogban, ezért ügynököket vetettek be a backlog kezelésére.
A rendszerben többféle ügynök dolgozik: van, amelyik egy hibát reprodukál, van, amelyik javítást alkalmaz, és van, amelyik átnézi a javítást. Lars Grammel, a Vercel mérnöke egy YouTube-videóban beszélt arról, hogy a csapat a saját, finomhangolt promptokkal működő ügynökeiben nagyobb bizalmat lát, mint a közösség által futtatott modellekben. Grammel szerint egy jól optimalizált agentkonfiguráció története alapján megbízhatóan javíthat bizonyos hibakategóriákat, és ez csökkentheti a review-hoz szükséges időt.
Grammel bemutatta a rendszertalkalmazás architektúráját is: egy felhasználói felület, egy webalkalmazás, háttér-API, végrehajtási tér és sandboxok, amelyek GitHubbal szinkronizálva automatikus lépéseket indítanak el. Vercel szerint a software factory bevezetését követő négy héten belül az automatizmusok „a beolvasztott PR-ek 25–35%-át szerzik meg” és „a problémák 70–80%-át zárják le”.
Astro: auto-triage és belső változás
Az Astro webkeretrendszer, amelynek 62 000 csillag van GitHubon, Fred Schott vezetése alatt szintén a software factory elvét alkalmazza. Schott elmondta a Latent Space-nek, hogy öt évig az issue-k gyorsabban érkeztek, mint ahogy a csapat kezelni tudta őket; az utóbbi hat hónapban viszont az ügynökök által végzett triage jelentősen visszaszorította a backlogot.
Az automatikus triage folyamata reprodukálja a hibákat, javaslatot tesz javításra, és a felhasználót megkéri, hogy ellenőrizze a bot által javasolt javítást, még mielőtt egy ember foglalkozna vele. Schott szerint a gyakorlat „teljesen átalakította” azt, hogyan viszonyulnak a csapattal érkező kérésekhez: az issue-k heti prioritási tételekké váltak a folyamatos hátizsák helyett. Az Astro auto-triage fejlesztése közvetlenül vezetett egy új ügynökkeret, a Flue létrehozásához.
Flue és tldraw: automatikus lezárás, viták és issue-k helyett
A Flue projekt hozzájárulói útmutatója nyíltan jelez: a projekt megpróbálja újragondolni a hozzájárulás folyamatát, részben azért, hogy megakadályozza az úgynevezett „Drive-by AI slop PR”-eket. Flue kezelése szerint minden külső PR automatikusan lezárásra kerül, és inkább issue-vá vagy discussionné alakul át: hibajelentések és javítási javaslatok issue-ként, funkciókérések beszélgetésként folytatódnak. Ezt követően a csapat saját szakértelmére és „a legjobb elérhető SOTA LLM-ekre” támaszkodva döntik el, mit érdemes tovább vinni; amikor döntés születik, ügynököket vetnek be a kutatásra, tervezésre, implementálásra és az elsődleges review-ra.
Hasonló megközelítést alkalmaz a tldraw (50 000 csillag), amely januárban jelentette be, hogy automatikusan lezárja a külső PR-eket; a projekt alapítója, Steve Ruiz később, öt hónappal később megerősítette ezt a szabályt. Ruiz szerint a döntés a kódolási munkamódok változására, a közösségi hozzájárulás gyakorlatára és a kódbiztonsági környezet alakulására adott válasz.
Mitchell Hashimoto, a HashiCorp társalapítója és a Ghostty megalkotója, aki ma a Superlogical társalapítója, ennél is távolabbi jövőképet vázolt: szerinte a nagy nyílt forráskódú projektek a hozzájárulások teljes lezárására is sor kerülhetnek a jövőben.
Közösség és megtanulási lehetőségek: mi történik a hozzájárulókkal?
A hagyományos open source gyakorlatban a PR-ek feldolgozása nem csupán a kód ellenőrzését szolgálta, hanem lehetőséget adott a hozzájárulók tanítására és megismerésére mint jövőbeli karbantartókra. Az, hogy egyre több projekt saját ügynököket használ a kód review-hoz és implementációhoz, kérdéseket vet fel arról, hova kerülnek azok a közösségi tagok, akik aktívabb szerepre törekednek.
Fred Schott ismeri ezt a kockázatot, és elismeri, hogy van egy „nyitott lyuk”: ha a projekt egyre zárkózottabbá válik, mi történik, ha a jelenlegi karbantartók hosszabb időre eltűnnek. Egy lehetséges megoldás a projektek által alkalmazott gyakorlatban rejlik: Flue és tldraw ugyan lezárják a külső PR-eket, de új issue-kat és beszélgetéseket fogadnak. Így a közösség tagjai több párbeszédbe lépnek egymással, ismeretségre és bizalomra tesznek szert, és ez alkalmat adhat arra, hogy egy tag bizonyítsa alkalmasságát karbantartónak.
Steve Ruiz összefoglaló gondolata szerint, ha a karbantartóknak könnyebb saját AI-ügynököket használniuk, mint külső kódot elfogadniuk, akkor a közösségi hozzájárulások szerepe elsősorban olyan területekre korlátozódhat, ahol még fontos: hibajelentés, beszélgetés, nézőpont és gondoskodás.
Következtetések
Néhány AI-vezérelt nyílt forráskódú projekt szemléletváltást hajt végre: a külső PR-ek automatikus lezárása és a saját automatizált ügynökök használata lerövidíti a review-ciklust és csökkenti a backlogot, miközben változtatja a közösségi részvétel hagyományos modelljét. A gyakorlat előnye a hatékonyság és a gyorsabb hibakezelés, a hátránya pedig a közösségi részvétel és a tanulási csatornák korlátozása lehet — ezért a projektek jelenleg a beszélgetésre és issue-okra helyezik a hangsúlyt, hogy megőrizhessék a közösségi szűrőt a jövő karbantartói számára.
