תרומת קוד שנוצר ב-AI לפרויקטי קוד פתוח: המדריך המלא

מה לעשות לפני שליחת קוד שנוצר בעזרת בינה מלאכותית ל-upstream

פרויקטי קוד פתוח מפרסמים כיום מדיניות בנוגע לקוד שנוצר בעזרת בינה מלאכותית, ומדיניות זו אינה אחידה בין פרויקט לפרויקט. לכן, ההרגל הנכון הוא פשוט: מצאו את המדיניות לפני כתיבת ה-patch, ודווחו על כך בצורה מדויקת בעת השליחה. כלל אחד עומד בבסיס שניהם: לעולם אל תגישו שורה שאינכם יכולים להסביר במהלך ה-review.

גם patch תקין ייסגר אם הפרויקט אוסר על קוד שנוצר אוטומטית, או אם הסתרתם את מקור הקוד. המחיר יחול על שמכם ויישאר שם, שכן מתחזק שיגלה את ההשמטה בשלב מאוחר יותר לא ימצא סיבה לתת אמון בשאר ההיסטוריה שלכם. תחילה, כמה מונחים, כיוון שהמדיניות משתמשת בהם. LLM (מודל שפה גדול) הוא המודל שמאחורי סוכן הקידוד שלכם. PR (בקשת משיכה) ב-GitHub הוא MR (בקשת מיזוג) ב-GitLab, וכל האמור להלן תקף לשניהם. ה-DCO (אישור מקור מפתח) הוא שורת ה-sign-off בתחתית הודעת ה-commit, והוא מתברר כמרכז הוויכוח כולו.

היכן התייצבו המדיניות בנושא קוד AI בקוד פתוח

פרויקטים התחלקו לארבע קבוצות עיקריות. כל דוגמה להלן נושאת תאריך, כיוון שמסמכים אלו משתנים.

איסור. מועצת Gentoo הצביעה ב-14 באפריל 2024 כי "חל איסור מפורש לתרום ל-Gentoo כל תוכן שנוצר בסיוע כלי בינה מלאכותית מבוססי עיבוד שפה טבעית". הנחיות ה-commit של NetBSD מגדירות פלט מ-LLM כ-"tainted code" (קוד מזוהם) ש-"אסור להכניס ללא אישור בכתב מראש מהליבה". מסמך מקורות הקוד של QEMU, נכון לאוגוסט 2026, עדיין קובע כי הפרויקט "ידחה כל תרומה שסביר להניח שכוללת או נגזרת מתוכן שנוצר על ידי AI".

ניתוח בלבד. רוב האיסורים מצומצמים יותר מכותרותיהם. המסמך של QEMU מציין כי המדיניות "אינה חלה על שימושים אחרים ב-AI, כגון מחקר של APIs או אלגוריתמים, ניתוח סטטי או ניפוי שגיאות (debugging), ובלבד שהפלט שלהם לא ייכלל בתרומות". מותר להשתמש בסוכן כדי לקרוא את הקוד. אסור לשלוח (ship) את מה שהוא כתב. הבחנה זו היא קו הגבול המעשי ברוב הפרויקטים המגבילים, וזהו הפרט שאנשים מפספסים.

חובת גילוי. מועצת Fedora אישרה מדיניות בנושא תרומות בסיוע AI באוקטובר 2025. היא מתירה שימוש בכלים ומטילה את האחריות על האדם: התורם הוא המחבר, הוא אחראי באופן מלא על כל התרומה, ועליו לדווח כאשר חלק משמעותי ממנה הגיע מכלי ללא שינויים. ה-Linux kernel הוסיף דף עוזרי קידוד בתיעוד התהליכים שלו בדצמבר 2025, עם נספח לתיעוד הכלי וכלל מחייב לגבי מי רשאי לחתום על הקוד (sign off).

אין מדיניות כתובה. זהו עדיין המצב הנפוץ. מאמר טרום-פרסום ממאי 2026 סקר 1,000 מאגרי GitHub פופולריים ומצא רק 118 עם מדיניות AI כתובה כלשהי. שתיקה אינה אישור. שאלו ב-issue tracker במשפט אחד לפני כתיבת ה-patch, והתשובה תהפוך לתיעוד ציבורי שתוכלו להפנות אליו בעתיד.

מדוע המפתחים קבעו כללים אלו

הסיבה הראשונה היא עומס הסקירה, והחשבון פשוט. סוכן בינה מלאכותית מייצר בקשת מיזוג (merge request) סבירה של 400 שורות בדקה. סקירה נאותה של בקשה כזו גוזלת מהמפתח אחר צהריים שלם, ורוב המפתחים הם מתנדבים. עלות ההגשה ירדה כמעט לאפס, בעוד עלות הסקירה לא השתנתה כלל.

הפרויקט curl מדגים את קצה העקומה הזו. דניאל סטנברג דיווח באמצע 2025 כי כחמישית מדיווחי האבטחה שהגיעו דרך תוכנית ה-bug bounty של הפרויקט היו מה שהוא מכנה "AI slop": דיווחים המציינים פונקציות ונתיבי קוד אמיתיים, מתארים מתקפה סבירה, אך אינם מכילים דבר בעל ערך. הפרויקט הפסיק את תוכנית ה-bounty בתחילת 2026 במקום להמשיך לממן את המבול הזה. אלו היו דיווחים ולא תיקונים, אך זהו אותו מנגנון שגורם למפתח לפתוח את ה-PR שלכם כשהוא כבר מותש.

פרויקט GNOME Calendar הגדיר את הבעיה באמצעות תווית ייעודית. ביוני 2026 הציג הפרויקט את התווית "Probabilistically Automated" עבור בקשות מיזוג המציגות "הסתמכות משמעותית או מוחלטת על 'בינה' מלאכותית ליצירת קוד", והגדיר את התסמין במדויק: "מלווה בדרך כלל בחוסר בבדיקות נאותות, ובביסוס תיקונים על התנהגות תיאורטית רצויה במקום על נכונות הקוד". קראו את המשפט האחרון פעמיים. הקוד נראה כאילו הוא אמור לעבוד. איש לא בדק אם הוא אכן עובד.

הסיבה השנייה היא מקור הקוד (provenance), כלומר מאיפה הגיע הקוד ותחת איזה רישיון הוא מופץ. פרויקט QEMU מציג את הקונפליקט בבירור: חתימה על תרומה מצהירה כי אתם "מבינים במלואו את מצב זכויות היוצרים והרישוי של התוכן" שאתם תורמים, ומצב זכויות היוצרים של פלט ממודלים אינו מוסדר. מועצת Gentoo סיפקה את אותה סיבה, לצד שיקולי איכות ואתיקה. אינכם חייבים להסכים עם הפרשנות המשפטית, אך עליכם להבין שזו החלטה של המפתח, לא שלכם.

כיצד אמצא את מדיניות ה-AI של פרויקט?

חפשו במקומות הבאים, לפי הסדר הזה:

• CONTRIBUTING.md בשורש המאגר (repository), לאחר מכן .github/CONTRIBUTING.md, ולאחר מכן כל קובץ DCO שנמצא לצדם.
• תיעוד המפתחים. QEMU שומרת את הכללים שלה ב-docs/devel/code-provenance.rst. ה-kernel שומר את הכללים שלו ב-Documentation/process/coding-assistants.rst.
• אתר הפרויקט או ה-wiki. המדיניות של Gentoo נמצאת בדף ה-wiki של המועצה, וזו של NetBSD נמצאת בהנחיות ה-commit.
• מערכת ניהול ה-issues וארכיון רשימות התפוצה. בדרך כלל מדיניות קיימת שם חודשים לפני שמישהו מתעד אותה בתוך המאגר.

מתוך עותק מקומי (checkout), פקודת grep אחת מכסה את רוב המקרים:

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

לאחר מכן, קראו את ההיסטוריה של הפרויקט עצמו, כיוון שמוסכמות שבוצע להן commit גוברות על כל סיכום שלהן:

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

מספר לצד ערך של trailer יצביע על הפורמט שהפרויקט משתמש בו בפועל. תוצאה ריקה משמעותה שאף אחד לא הצהיר בפורמט הזה כאן, וגם זה מידע בעל ערך. אם הפרויקט מתארח ב-GitHub וזרימת העבודה (workflow) חדשה לכם, כיצד pull requests ו-forks עובדים ב-GitHub מכסה את המכניקה שעליה מניח סעיף זה.

גילוי ב־trailer של ה־commit, לא בהערה

ה־trailer הוא שורת Key: value בפסקה האחרונה של הודעת ה־commit. ‏Git כבר משתמש במבנה זה עבור Signed-off-by: ו־Co-authored-by:, וכלים מנתחים אותו, לכן זהו הגילוי היחיד שעובר יחד עם הקוד לתוך ה־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>

ה־kernel מתעד פורמט זה כ־Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], והוא מפורש לגבי מגבלת השורה: "סוכני AI אינם רשאים להוסיף תגיות Signed-off-by. רק בני אדם יכולים לאשר משפטית את ה-Developer Certificate of Origin (DCO)." שמו של הסוכן נרשם ב־Assisted-by. שמך שלך נרשם ב־Signed-off-by. לעולם אל תיתן לכלי לכתוב את השני, ולעולם אל תיתן לו להמציא כתובת Co-authored-by שאינה שייכת לאיש.

שמות משתנים, לכן העתק את השם המקומי במקום להמציא משלך. patch שנשלח לרשימת התפוצה של QEMU במאי 2026 הציע להקל את האיסור של אותו פרויקט עבור שינויים מכניים, בדיקות, תיעוד ותיקוני באגים של עשרים שורות או פחות, המתועדים עם trailer כמו AI-used-for: tests, docs. נכון לאוגוסט 2026 זוהי הצעה ברשימת תפוצה והמסמך המעודכן עדיין מסתייג מתוכן שנוצר אוטומטית. פרויקט אחד שינה את עמדתו פעמיים בין 2023 ל-2026. המהלך הבא לא יחכה לך, וזו הסיבה שהשיטה חשובה יותר מהרשימה.

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)'

‏--trailer דורש Git 2.32 או חדש יותר. הפקודה השנייה אמורה להדפיס את הערך בחזרה אליך. שורה ריקה משמעותה ש־git לא ניתח את ה־trailer, כמעט תמיד בגלל שורה ריקה או משפט רגיל שנמצאים בתוך בלוק ה־trailer בתחתית ההודעה. עבור סדרה שכבר כתבת, git rebase --signoff origin/main מוסיף את ה-sign-off לכל commit, ו־git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt עורך קובץ הודעה.

כדאי להיערך לשני מצבי כשל. ‏Squash merge משכתב את הודעת ה־commit, לכן בפרויקט שמבצע squash, חזור על הגילוי בתיאור ה-PR שבו המתוחזק קורא אותו. כמו כן, הערת review אינה נחשבת לתיעוד, כיוון שניתן לערוך הערות והן לעולם אינן נשמרות בהיסטוריה של git.

דיוק הוא דו-סטרי. Assisted-by ב־commit שכתבת בעצמך הוא רעש, והוא מפחית מהערך של הגילויים האמיתיים שלך. השמטתו מ־commit שהסוכן כתב היא הדבר שיסיים את מערכת היחסים.

מה המשמעות האמיתית של Signed-off-by?

ה־DCO הוא טקסט קצר, גרסה 1.1, שפורסם ב-developercertificate.org ומשמש את ה־kernel, את QEMU ופרויקטים רבים אחרים. הוספת Signed-off-by: Your Name <you@example.com> מעידה על כך שאתם מאשרים אותו. קראו על מה אתם חותמים, שכן רוב האנשים חותמים עליו מבלי לקרוא אותו מעולם.

סעיף (a) קובע כי התרומה "נוצרה במלואה או בחלקה על ידי ואני בעל הזכות להגיש אותה תחת רישיון הקוד הפתוח המצוין בקובץ". סעיף (b) מכסה עבודה המבוססת על קוד קוד פתוח קודם שיש לכם זכות להעביר הלאה עם שינויים. סעיף (c) מכסה קוד שהועבר אליכם על ידי מישהו שאישר את אותו הדבר. סעיף (d) קובע כי אתם מבינים שהתרומה והמידע האישי בחתימה שלכם הם פומביים ונשמרים ללא הגבלת זמן.

שימו לב למה שחסר. ה־DCO מעולם לא טוען שהקלדתם כל תו ותו. הוא קובע שיש לכם את הזכות להגיש את הקוד תחת רישיון זה. זו הסיבה שקוד שנוצר אוטומטית נמצא כאן בנקודה בעייתית: השאלה אינה לגבי כתיבת הקוד, אלא האם אתם יכולים להעיד על המקור שלו. רוב הפרויקטים הדורשים חתימה מחייבים גם שם אמיתי, לכן שם בדוי לא יעבור את הבדיקה. הוסיפו את השורה עם git commit -s, אשר קוראת את user.name ואת user.email מתוך ה־git config שלכם. כאשר בוט ה־DCO פוסל את ה־PR שלכם ומציין את ה־commit שחסרה בו השורה, git rebase --signoff origin/main וביצוע force push לענף שלכם יפתרו את הבעיה.

חתימה על commit אינה זהה לביצוע sign-off

git commit -s מוסיף שורת טקסט. git commit -S יוצר חתימה קריפטוגרפית על אובייקט ה-commit באמצעות מפתח GPG או SSH שברשותך. הם עונים על שאלות שונות. החתימה מאשרת ש-commit זה הגיע מבעל המפתח ושלא חל בו שינוי מאז. היא אינה מעידה דבר על מקור הקוד שבפנים, לכן commit חתום המכיל קוד שנוצר באופן לא מורשה הוא אמנם חתום, אך עדיין מהווה הפרה של המדיניות. ה-sign-off הוא הצהרה על המקור. החתימה היא הצהרה על הזהות. פרויקטים הדורשים את שניהם יבקשו את שניהם.

לעולם אל תגישו קוד שאינכם יכולים להסביר בביקורת

זהו המבחן, והוא אינו נוגע באמת ליושרה. עבור כל שורה: לשם מה היא נועדה, ומה יקרה אם היא תוסר? אם אחת מהתשובות חסרה, התיקון אינו מוכן, כיוון שהערת הביקורת תגיע והתשובה שלכם תגרור סבב יצירה נוסף. המבקרים יודעים לזהות זאת. זהו הרגע שבו תורם הופך לנטל. שאלו את אותה שאלה על מקרי הקצה, על קלט ריק, על נתיב הכשל ועל הקורא השני.

הריצו את הקוד. בצעו build, הריצו את חבילת הבדיקות של הפרויקט, וכתבו משחזר (reproducer) לבאג שאתם טוענים שתיקנתם. התיעוד של ה-kernel מציע את חלופת הכנות במילים פשוטות: "אם לא ניתן היה לבנות או לבדוק את התיקון, או אם לא ניתן היה ליצור משחזר, ציינו זאת במפורש: מתחזקים מבזבזים כיום זמן רב מדי על ניתוח דיווחים לא מאומתים ותיקונים שלא נבדקו". כתיבת "לא יכולתי לבדוק זאת על חומרה אמיתית" אינה עולה לכם בדבר. רמיזה שעשיתם זאת תעלה לכם באמון הפרויקט.

ענו על הערות ביקורת בעצמכם, במילים שלכם ובזמן שלכם. תגובה שמגיעה שלושים שניות לאחר ההערה ומנסחת אותה מחדש בחמש פסקאות אומרת למתחזק בדיוק מה קרה. שמרו גם על ה-diff קטן. ארבעים שורות שאתם מבינים לחלוטין שוות לפרויקט יותר מאשר refactor של ארבע מאות שורות שרק פיקחתם עליו. אם הסוכן שלכם ממשיך להחזיר יותר ממה שביקשתם, מיומנות שמגבילה אותו לשינוי הקטן ביותר שעובד היא דרך אחת לשמור על ה-patch ברמה שאתם עדיין יכולים להגן עליה שורה אחר שורה.

שמירת ההנחיות לסוכן בתוך המאגר

ההנחיות שאתם נותנים לסוכן שלכם הן חלק משרשרת הכלים שלכם, לכן התייחסו אליהן כאל קוד. קובץ בשורש המאגר, בדרך כלל AGENTS.md, מכיל את פקודת הבנייה, פקודת הבדיקה, פורמט הודעת ה-commit, דרישת ה-sign-off וכללי הסגנון שהפרויקט כבר מתעד. קובץ זה נמצא תחת בקרת גרסאות וניתן לסקירה, והוא נשאר זהה היום ומחר. הנחיות שמוקלדות מחדש מהזיכרון בכל סשן מניבות בכל פעם patch שונה, ולא תדעו איזה סשן הפיק את ה-patch שנדחה. המדריך כתיבת AGENTS.md שקריא גם לסוכן וגם לבני אדם מכסה את הקובץ עצמו.

אזהרה אחת בנוגע למאגרים של אחרים: אל תהפכו את התרומה הראשונה שלכם ל-PR שמוסיף קובץ הנחיות סוכן לפרויקט שאתם לא מתחזקים. זה נתפס כניסיון לקבוע את מדיניות הכלים של הפרויקט מבחוץ, וזו דרך מהירה לגרום לכך שהחשבון שלכם יזוהה עם הדברים שהמתחזקים כבר עייפים מהם. שמרו את הקובץ ב-fork שלכם עד שמישהו יבקש אותו.

היכן שאתם מריצים את הסוכן משנה מאותה סיבה. סוכן שמסוגל לבנות את הפרויקט ולהריץ את הבדיקות שלו בתוך ארגז חול (sandbox) שבשליטתכם, מספק לכם patch שאימתתם בפועל; זה ההבדל בין גילוי סיוע לבין גילוי ניחוש. המדריך הרצת סוכן תכנות על ה-VPS שלכם מכסה את ההגדרה הזו, והמדריך ההבדלים המעשיים בין Claude Code, Cursor, Codex ו-Copilot מכסה את השוני בין הכלים בשימוש יומיומי.

השיטה, לאחר שינוי המדיניות

1. מצאו את המדיניות המוצהרת לפני כתיבת דבר מה: מאגר (repository), תיעוד מפתחים, אתר אינטרנט או מערכת מעקב (tracker).
2. אם לא קיימת מדיניות, שאלו על כך ב-issue במשפט אחד ושמרו את התשובה.
3. בצעו גילוי נאות בפורמט שבו הפרויקט משתמש, בתוך ה-commit trailer, וחזרו עליו בגוף ה-PR אם הפרויקט מבצע squash.
4. חתמו (sign off) בשמכם האמיתי, מתוך הבנה ששורה זו מהווה הצהרה על זכותכם להגיש את הקוד.
5. בצעו review לתיקון שלכם כאילו נכתב על ידי אדם זר, שכן אכן כך הדבר.

כל פרויקט המוזכר בדף זה כבר יעבור למקום אחר עד שתקראו זאת. חמשת הצעדים הללו אינם משתנים.

FAQ

האם עליי לציין שהשתמשתי בסוכן קידוד מבוסס בינה מלאכותית?

בדקו את הפרויקט, שכן התשובה נקבעת ברמה המקומית. Fedora דורשת גילוי נאות כאשר חלק משמעותי מהתרומה הגיע מכלי ללא שינויים. ה-Linux kernel מבקש להוסיף Assisted-by trailer. הפרויקטים Gentoo ו-QEMU, נכון לאוגוסט 2026, אינם מעוניינים בתרומה כזו כלל. במקומות שבהם לא נכתב דבר, בצעו גילוי נאות בכל מקרה בתוך commit trailer. מתחזק שיגלה זאת בדיעבד יגיב להשמטה ולא לכלי עצמו, ותגובה זו עלולה להשליך על כל שאר התרומות שלכם.

אילו פרויקטי קוד פתוח אוסרים על קוד שנוצר על ידי בינה מלאכותית?

נכון לאוגוסט 2026: Gentoo מאז אפריל 2024, NetBSD המתייחסת לפלט של LLM כאל קוד מזוהם הדורש אישור ליבה, QEMU המסרבת לקבל תרומות הנגזרות מתוכן שנוצר, ומספר יישומי GNOME כולל Loupe ו-Calendar. קראו את הטקסט של כל פרויקט עצמו במקום להסתמך על רשימה זו, שכן היא תתיישן. שימו לב לפטור שרובם חולקים: שימוש במודל לצורך מחקר של API, הרצת ניתוח סטטי או סיוע בניפוי שגיאות (debugging) הוא בדרך כלל תקין, כל עוד הפלט שלו אינו מופיע בתוך ה-patch.

מה ההבדל בין Signed-off-by לבין commit חתום?

Signed-off-by היא שורת טקסט פשוט המוספת על ידי git commit -s. היא מאשרת את ה-developer certificate of origin, כלומר שיש לכם את הזכות להגיש את הקוד הזה תחת הרישיון של הפרויקט. commit חתום, המבוצע באמצעות git commit -S, הוא חתימה קריפטוגרפית על אובייקט ה-commit באמצעות מפתח ה-GPG או ה-SSH שלכם. היא מוכיחה שה-commit הגיע מהמפתח שלכם ולא שונה. מקור וזהות הם טענות נפרדות, לכן commit חתום עדיין יכול להפר מדיניות בנושא בינה מלאכותית.

האם אני יכול להוסיף את הגילוי הנאות בתיאור ה-pull request במקום בהודעת ה-commit?

הוסיפו אותו בהודעת ה-commit, שכן זהו התיעוד שנשמר בהיסטוריית ה-git ועובר עם הקוד לכל מי שישכפל (clone) את המאגר בעתיד. תיאור של pull request ניתן לעריכה לאחר מעשה והוא קיים רק בפלטפורמת האירוח. הוסיפו אותו גם לגוף ה-PR כאשר הפרויקט מבצע squash merge, כיוון שפעולת squash משכתבת את הודעת ה-commit שלכם ועלולה להשמיט את ה-trailer.

ה-pull request שלי נסגר מכיוון שהוא נוצר על ידי בינה מלאכותית. מה עושים עכשיו?

אל תתווכחו על המדיניות בשרשור, כיוון שהאדם שסגר אותו לא כתב את הכלל לבדו והשרשור אינו המקום שבו הוא משתנה. קראו את טקסט המדיניות, ואז החליטו אם אתם יכולים לעמוד בו. במקומות שבהם הפרויקט אוסר על patches שנוצרו אוטומטית, דיווח באגים ברור עם דרך לשחזור (reproducer) ללא patch עדיין יתקבל בברכה, ולעיתים קרובות זוהי התרומה המועילה יותר. אם תחזרו עם קוד, חזרו עם שינוי קטן שאתם יכולים להגן עליו שורה אחר שורה.