AI Code at Open Source Policy: Ano ang Dapat Gawin

Ano ang dapat gawin bago magpadala ng AI-assisted code upstream

May mga policy na ngayon ang mga open source project tungkol sa AI-assisted code, at hindi magkakatugma ang mga policy na ito. Kaya simple ang dapat na gawin: hanapin ang policy bago mo isulat ang patch, at magbigay ng tumpak na disclosure kapag ipinadala mo ito. May isang rule na pinagbabatayan ng dalawang hakbang. Huwag magsumite ng kahit isang linya na hindi mo kayang ipaliwanag sa review.

Maaari pa ring isara ang isang tamang patch kung ipinagbabawal ng project ang generated code, o kung itinago mo kung saan nagmula ang code. Ang epekto nito ay maiuugnay sa iyong pangalan at mananatili roon, dahil kapag natuklasan ng maintainer ang pagkukulang kalaunan, wala na siyang dahilan para pagkatiwalaan ang iba mo pang history. Unahin muna ang ilang termino dahil ginagamit ang mga ito sa mga policy. Ang LLM (large language model) ang model sa likod ng iyong coding agent. Ang PR (pull request) sa GitHub ay MR (merge request) sa GitLab, at nalalapat ang lahat ng nasa ibaba sa parehong uri. Ang DCO (developer certificate of origin) ay ang sign-off line sa ibaba ng commit message, at ito pala ang sentro ng buong usapin.

Kung Saan Nauwi ang Mga Patakaran ng Open Source sa AI-Generated Code

Nauwi ang mga project sa apat na kategorya. May petsa ang bawat halimbawa sa ibaba dahil patuloy na nagbabago ang mga tekstong ito.

Ipinagbabawal. Bumoto ang council ng Gentoo noong 14 April 2024 na “hayagang ipinagbabawal ang pag-contribute sa Gentoo ng anumang content na nilikha sa tulong ng mga tool na gumagamit ng Natural Language Processing artificial intelligence”. Tinatawag ng commit guidelines ng NetBSD na “tainted code” ang output mula sa LLM, at sinasabing “hindi ito dapat i-commit nang walang paunang nakasulat na approval mula sa core”. Ang code provenance document ng QEMU, noong August 2026, ay nagsasabi pa rin na “TATANGGIHAN nito ang anumang contribution na pinaniniwalaang may kasamang o nagmula sa AI-generated content”.

Para sa analysis lamang. Mas makitid ang karamihan sa mga ban kaysa sa ipinahihiwatig ng headline. Sinasabi ng document ng QEMU na “hindi saklaw ng policy ang iba pang paggamit ng AI, gaya ng pagsasaliksik sa mga API o algorithm, static analysis, o debugging, basta hindi kasama ang output ng mga ito sa mga contribution”. Maaari mong gamitin ang agent para basahin ang code. Hindi mo maaaring i-release ang isinulat nito. Ito ang praktikal na hangganan sa loob ng karamihan sa mga restrictive project, at ito ang madalas hindi napapansin ng mga tao.

Kinakailangan ang disclosure. Inaprubahan ng council ng Fedora ang policy sa AI-assisted contributions noong October 2025. Pinapayagan nito ang mga tool at inilalagay ang pananagutan sa contributor: ang contributor ang author, ganap na responsable sa buong contribution, at dapat mag-disclose kapag malaking bahagi nito ay nagmula sa isang tool nang walang pagbabago. Nagkaroon ang Linux kernel ng coding assistants page sa process documentation nito noong December 2025, kasama ang trailer para itala ang tool at mahigpit na panuntunan kung sino ang maaaring mag-sign off.

Walang nakasulat na patakaran. Ito pa rin ang karaniwang sitwasyon. Sa isang preprint mula May 2026, sinuri ang 1,000 sikat na GitHub repository at natuklasang 118 lamang ang may anumang nakasulat na AI policy. Ang pananahimik ay hindi pahintulot. Magtanong sa issue tracker sa isang pangungusap bago mo isulat ang patch, upang maging public record ang sagot na maaari mong ituro sa hinaharap.

Bakit isinulat ng mga maintainer ang mga patakarang ito

Ang unang dahilan ay review load, at iisa ang direksiyon ng arithmetic. Kayang gumawa ng agent ng mukhang kapani-paniwalang 400-line merge request sa loob ng isang minuto. Ang maayos na pag-review sa request na iyon ay maaaring umabot ng isang hapon para sa maintainer, at karamihan sa mga maintainer ay volunteers. Halos naging zero ang cost ng pagsusumite. Hindi naman nagbago ang cost ng pag-review.

Ipinapakita ng curl ang kabilang dulo ng curve na iyon. Iniulat ni Daniel Stenberg noong kalagitnaan ng 2025 na humigit-kumulang isang-kalima ng security report na dumarating sa bug bounty ng proyekto ay tinatawag niyang AI slop: mga report na tumutukoy sa totoong function at totoong code path, naglalarawan ng mukhang kapani-paniwalang attack, pero walang laman. Tinapos ng proyekto ang bounty noong unang bahagi ng 2026 sa halip na patuloy na tustusan ang bugso ng mga report. Mga report ang mga iyon, hindi patch, pero pareho ang mekanismong nagiging dahilan kung bakit binubuksan ng maintainer ang PR mo nang pagod na agad.

Isinulat ng GNOME Calendar ang problema bilang isang label. Noong June 2026, ipinakilala ng proyekto ang "Probabilistically Automated" para sa mga merge request na nagpapakita ng "major or total reliance on artificial 'intelligence' to generate code", at tinukoy nang eksakto ang sintomas: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code". Basahin nang dalawang beses ang huling parirala. Mukhang dapat gumana ang code. Walang nagsuri kung gumagana nga ito.

Ang ikalawang dahilan ay provenance, ibig sabihin, kung saan nagmula ang code at sa ilalim ng anong license ito. Malinaw na ipinahayag ng QEMU ang conflict: ang pag-sign off ay nangangahulugang "fully understand the copyright and license status of content" na inaambag mo, at hindi pa tiyak ang copyright status ng model output. Pareho ang dahilang ibinigay ng council ng Gentoo, kasama ang quality at ethics. Hindi mo kailangang sumang-ayon sa legal na pagbasa. Kailangan mong tandaan na desisyon iyon ng maintainer, hindi sa iyo.

Paano ko mahahanap ang AI policy ng isang proyekto?

Hanapin ito sa mga sumusunod na lugar, ayon sa pagkakasunod-sunod.

• CONTRIBUTING.md sa root ng repository, pagkatapos ay .github/CONTRIBUTING.md, at kasunod nito ang anumang DCO file na nasa tabi nito.
• Ang developer docs. Inilalagay ng QEMU ang patakaran nito sa docs/devel/code-provenance.rst. Inilalagay naman ng kernel ang patakaran nito sa Documentation/process/coding-assistants.rst.
• Ang website o wiki ng proyekto. Nasa wiki page ng council ang policy ng Gentoo, at nasa commit guidelines naman ang policy ng NetBSD.
• Ang issue tracker at archive ng mailing list. Karaniwang naroon na ang policy nang ilang buwan bago ito ilagay ng sinuman sa repository.

Mula sa loob ng checkout, sapat na ang isang grep para masuri ang karamihan dito:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Pagkatapos, basahin ang sariling history ng proyekto, dahil mas mahalaga ang convention na naka-commit kaysa sa anumang buod nito:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Ipinapakita ng bilang sa tabi ng trailer value kung anong format ang aktuwal na ginagamit ng proyekto. Kapag walang resulta, nangangahulugan itong wala pang nag-disclose gamit ang format na iyon dito, at mahalaga rin ang impormasyong iyon. Kung nasa GitHub ang proyekto at bago sa iyo ang workflow mismo, ipinapaliwanag ng kung paano gumagana ang pull request at fork sa GitHub ang mechanics na ipinapalagay ng seksyong ito.

Ilagay ang disclosure sa commit trailer, hindi sa comment

Ang trailer ay isang Key: value line sa huling paragraph ng commit message. Ginagamit na ng Git ang format na ito para sa Signed-off-by: at Co-authored-by:, at binabasa ito ng mga tool, kaya ito ang disclosure na kasama ng code hanggang sa tree.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Idinodokumento ng kernel ang format na ito bilang Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], at malinaw nitong itinatakda ang limitasyon ng line: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." Ilagay ang pangalan ng agent sa Assisted-by. Ilagay ang pangalan mo sa Signed-off-by. Huwag kailanman hayaang isulat ng tool ang ikalawa, at huwag itong hayaang mag-imbento ng Co-authored-by address na walang may-ari.

Nagkakaiba ang mga pangalan, kaya kopyahin ang lokal na ginagamit sa halip na mag-imbento ng sarili. Noong May 2026, may patch na ipinaskil sa QEMU list na nagmungkahi na luwagan ang pagbabawal ng proyekto para sa mechanical changes, tests, docs, at bug fixes na dalawampung lines o mas kaunti, na itatala gamit ang trailer na gaya ng AI-used-for: tests, docs. Noong August 2026, proposal pa lamang ito sa isang mailing list, at patuloy pa ring hindi tinatanggap ng committed document ang generated content. Dalawang beses nagbago ng posisyon ang isang proyekto sa pagitan ng 2023 at 2026. Hindi maghihintay sa iyo ang susunod na pagbabago, kaya mas mahalaga ang method kaysa sa listahan.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

Kailangan ng --trailer ang Git 2.32 o mas bago. Dapat direktang i-print pabalik sa iyo ng ikalawang command ang value. Kapag walang laman ang line, hindi na-parse ng git ang trailer. Halos palaging sanhi ito ng blank line o ordinaryong sentence na nasa loob ng trailer block sa pinakailalim ng message. Para sa seryeng naisulat mo na, idinaragdag ng git rebase --signoff origin/main ang sign-off sa bawat commit, at ine-edit ng git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt ang message file.

Mahalagang paghandaan ang dalawang failure mode. Binabago ng squash merge ang commit message, kaya sa proyektong gumagamit ng squash ay ulitin ang disclosure sa PR description kung saan ito mababasa ng maintainer. Hindi record ang review comment, dahil maaaring i-edit ang comments at hindi kailanman mapunta sa git history.

Parehong mahalaga ang accuracy sa dalawang direksiyon. Ang Assisted-by sa commit na ikaw mismo ang nag-type ay ingay lamang, at binabawasan nito ang halaga ng tunay mong disclosures. Ang pag-iwan nito sa commit na isinulat ng agent ang sisira sa relasyon.

Ano ang aktuwal na pinatutunayan ng Signed-off-by?

Ang DCO ay isang maikling text, bersyon 1.1, na inilathala sa developercertificate.org at ginagamit ng kernel, QEMU, at marami pang iba. Kapag idinagdag mo ang Signed-off-by: Your Name <you@example.com>, sinasabi mong pinatutunayan mo ito. Basahin kung ano ang pinatutunayan mo, dahil nilalagdaan ito ng karamihan nang hindi ito binabasa.

Sinasabi sa clause (a) na ang contribution ay “ginawa nang buo o bahagi ng akin at may karapatan akong isumite ito sa ilalim ng open source license na nakasaad sa file.” Saklaw ng clause (b) ang gawaing batay sa naunang open source code na may karapatan kang ipasa kasama ang iyong mga pagbabago. Saklaw ng clause (c) ang code na ibinigay sa iyo ng isang taong nagpatunay ng parehong bagay. Sinasabi sa clause (d) na nauunawaan mong magiging pampubliko at pananatilihing walang takdang panahon ang contribution at ang personal information sa iyong sign-off.

Pansinin kung ano ang wala rito. Hindi sinasabi ng DCO na ikaw ang nag-type ng bawat character. Sinasabi nitong may karapatan kang isumite ang code sa ilalim ng license na ito. Kaya hindi madaling ikategorya rito ang generated code: ang tanong ay hindi kung sino ang author, kundi kung matutukoy mo ang pinagmulan nito. Karamihan sa mga project na nangangailangan ng sign-off ay nangangailangan din ng totoong pangalan, kaya hindi papasa sa check ang pseudonym. Idagdag ang line gamit ang git commit -s, na nagbabasa ng user.name at user.email mula sa iyong git config. Kapag nag-fail ang DCO bot sa iyong PR at tinukoy ang commit na walang line, git rebase --signoff origin/main at force push sa iyong branch ang mag-aayos nito.

Ang pag-sign ng commit ay hindi kapareho ng pag-sign-off

Ang git commit -s ay nagdaragdag ng isang linya ng text. Ang git commit -S ay gumagawa ng cryptographic signature sa commit object gamit ang iyong GPG o SSH key. Magkaiba ang sinasagot nilang tanong. Pinatutunayan ng signature na ang commit na ito ay nagmula sa may hawak ng key na iyon at hindi ito binago mula noon. Wala itong sinasabi tungkol sa pinagmulan ng code sa loob nito. Kaya ang isang signed commit na naglalaman ng hindi isiniwalat na generated code ay signed pa rin ngunit paglabag pa rin sa policy. Ang sign-off ay pahayag tungkol sa pinagmulan. Ang signature ay pahayag tungkol sa identity. Ang mga project na nangangailangan ng pareho ay hihingi ng pareho.

Huwag magsumite ng code na hindi mo maipaliwanag sa review

Narito ang pagsubok, at hindi talaga ito tungkol sa pagiging tapat. Para sa bawat linya: para saan ito, at ano ang masisira kapag wala ito? Kung kulang ang alinman sa dalawang sagot, hindi pa handa ang patch, dahil darating ang komento sa review at magiging panibagong round ng generation ang sagot mo. Napapansin ito ng mga reviewer. Sa puntong iyon, nagiging dagdag na gastos sa proyekto ang contributor. Itanong din ang parehong bagay tungkol sa mga edge case, empty input, failure path, at second caller.

Patakbuhin ang code. I-build ito, patakbuhin ang test suite ng proyekto, at gumawa ng reproducer para sa bug na sinasabi mong inaayos. Malinaw ang fallback sa kernel documentation: "Kung hindi na-build o na-test ang fix, o walang nagawang reproducer, sabihin ito nang tahasan: masyadong maraming oras ang nasasayang ng mga maintainer sa pagsusuri ng mga report na hindi na-verify at mga fix na hindi na-test." Walang mawawala sa iyo kapag isinulat mong "Hindi ko ito na-test sa aktuwal na hardware." Kapag ipinahiwatig mong ginawa mo ito kahit hindi naman, isinasapanganib mo ang proyekto.

Ikaw mismo ang sumagot sa mga komento sa review, gamit ang sarili mong mga salita at sa sarili mong oras. Ang reply na lumabas tatlumpung segundo matapos ang komento at inulit ito sa limang talata ay malinaw na nagsasabi sa maintainer kung ano ang nangyari. Panatilihing maliit ang diff. Mas mahalaga sa proyekto ang 40 linya na lubos mong nauunawaan kaysa sa 400-line refactor na pinangasiwaan mo lamang. Kung patuloy na mas marami sa hinihingi mo ang ibinabalik ng iyong agent, isang skill na naglilimita rito sa pinakamaliit na gumaganang pagbabago ang isang paraan upang manatiling sapat na maliit ang patch para maipagtanggol mo pa rin ang bawat linya.

Panatilihin sa repository ang mga instruction para sa agent

Bahagi ng toolchain mo ang mga instruction na ibinibigay mo sa agent, kaya ituring ang mga ito na parang code. Ang file sa root ng repository, karaniwang AGENTS.md, ang naglalaman ng build command, test command, format ng commit message, requirement para sa sign-off, at mga style rule na dokumentado na ng project. Naka-version at nasusuri ang file na iyon, at pareho ito bukas at ngayon. Kapag mula sa memory ang tina-type mong mga instruction sa bawat session, magkakaroon ng magkakaibang patch sa bawat session, at hindi mo malalaman kung aling session ang gumawa ng patch na na-reject. Sinasaklaw ng Pagsulat ng AGENTS.md na mababasa ng agent at ng tao ang mismong file.

Isang pag-iingat tungkol sa repository ng ibang tao. Huwag gawing unang contribution mo ang isang PR na nagdaragdag ng agent instruction file sa project na hindi mo mina-maintain. Magmumukha itong pagtatangkang magtakda ng tooling policy ng project mula sa labas, at mabilis nitong maiuugnay ang account mo sa bagay na sawa nang harapin ng mga maintainer. Panatilihin ang file sa fork mo hanggang may humiling nito.

Mahalaga rin kung saan mo pinapatakbo ang agent sa parehong dahilan. Kapag kayang i-build ng agent ang project at patakbuhin ang tests nito sa loob ng sandbox na kontrolado mo, magkakaroon ka ng patch na aktuwal mong na-verify. Ito ang pagkakaiba ng pagsisiwalat na may assistance at pagsisiwalat ng hula. Sinasaklaw ng Pagpapatakbo ng coding agent sa sarili mong VPS ang setup na iyon, at ng mga praktikal na pagkakaiba ng Claude Code, Cursor, Codex at Copilot ang pagkakaiba ng mga tool sa pang-araw-araw na paggamit.

Ang Paraan Kapag Nagbago ang Policy

1. Hanapin muna ang itinakdang policy bago ka magsulat ng anuman: repository, developer docs, website, o tracker.
2. Kung walang policy, magtanong sa issue gamit ang isang pangungusap, at panatilihin ang sagot.
3. I-disclose ito sa format na ginagamit ng project, sa commit trailer, at ulitin sa PR body kung nagsi-squash ang project.
4. Mag-sign off gamit ang tunay mong pangalan, dahil ang linyang ito ay pahayag na may karapatan kang isumite ang code.
5. I-review ang sarili mong patch na para bang ibang tao ang sumulat nito, dahil may ibang taong talagang susuri rito.

Lahat ng project na binanggit sa page na ito ay maaaring nagbago na pagsapit ng pagbasa mo rito. Hindi nagbabago ang limang hakbang.

FAQ

Kailangan ko bang sabihin na gumamit ako ng AI coding agent?

Suriin ang project dahil lokal na itinatakda ang sagot. Nangangailangan ang Fedora ng disclosure kapag malaking bahagi ng contribution ay nagmula sa isang tool at walang ginawang pagbabago. Hinihingi ng Linux kernel ang Assisted-by trailer. Hindi tinatanggap ng Gentoo at QEMU, noong August 2026, ang contribution mismo. Kung walang nakasulat na patakaran, mag-disclose pa rin sa isang commit trailer. Kapag nalaman ito ng maintainer kalaunan, ang magiging reaksiyon niya ay karaniwang sa hindi pagsasabi, hindi sa tool. Maaapektuhan nito ang lahat ng iba mo pang naipadala.

Aling open source projects ang nagbabawal ng AI-generated code?

Batay sa sitwasyon noong August 2026: ipinagbawal ito ng Gentoo mula April 2024; itinuturing ng NetBSD ang LLM output bilang tainted code na nangangailangan ng core approval; tinatanggihan ng QEMU ang contributions na nagmula sa generated content; at may ilang GNOME application, kabilang ang Loupe at Calendar, na may ganitong patakaran. Basahin ang sariling policy ng bawat project sa halip na umasa sa listahang ito dahil maaari itong magbago. Tandaan ang exemption na karaniwan sa mga ito: karaniwang pinapayagan ang paggamit ng model para magsaliksik ng API, magpatakbo ng static analysis, o tumulong sa debugging, basta’t wala ang output nito sa patch.

Ano ang pagkakaiba ng Signed-off-by at signed commit?

Ang Signed-off-by ay plain text line na idinaragdag ng git commit -s. Pinatutunayan nito ang developer certificate of origin, ibig sabihin, may karapatan kang isumite ang code sa ilalim ng license ng project. Ang signed commit, na ginagawa gamit ang git commit -S, ay isang cryptographic signature sa commit object gamit ang iyong GPG o SSH key. Pinatutunayan nitong nagmula ang commit sa iyong key at hindi ito binago. Magkaibang claim ang origin at identity, kaya maaari pa ring lumabag sa AI policy ang isang signed commit.

Maaari ko bang ilagay ang disclosure sa pull request description sa halip na sa commit message?

Ilagay ito sa commit message dahil iyon ang record na napupunta sa git history at kasama ng code para sa sinumang mag-clone ng repository sa hinaharap. Maaaring baguhin pagkatapos ang pull request description, at nasa hosting platform lamang ito. Idagdag din ito sa PR body kapag gumagamit ang project ng squash merge, dahil nire-rewrite ng squash ang iyong commit message at maaaring mawala ang trailer.

Isinara ang pull request ko dahil AI-generated ito. Ano ang dapat kong gawin?

Huwag makipagtalo tungkol sa policy sa thread dahil hindi lang ang taong nagsara nito ang gumawa ng rule, at hindi sa thread binabago ang policy. Basahin ang policy text, pagkatapos ay magpasya kung kaya mong sundin ito. Kung ipinagbabawal ng project ang generated patches, malugod pa ring tatanggapin ang malinaw na bug report na may reproducer at walang patch, at madalas itong mas kapaki-pakinabang na contribution. Kung babalik ka na may code, magdala ng maliit na pagbabago na maipagtatanggol mo sa bawat linya.