מחקר חדש שפורסם ב-arXiv בסוף מרץ מתאר במונחים חדים את אחת התחושות המתפשטות כיום בקהילת הפיתוח: ההצפה של "AI slop" תוכן שנוצר בסיוע מודלי שפה ונראה במבט ראשון סביר, אך בפועל הוא שטחי, שגוי, לא בדוק או פשוט מעביר את עבודת הבקרה לאדם אחר. החוקרים Sebastian Baltes, Marc Cheong ו-Christoph Treude ניתחו 1,154 פוסטים מ-15 דיונים ב-Reddit וב-Hacker News, ומצאו שלצד יתרונות נקודתיים של כלי AI, רבים מהמפתחים רואים בתופעה בעיית תשתית של ממש. לפי המחקר, הבעיה אינה רק קוד חלש, אלא גם Pull Requests מיותרים, תיעוד באיכות ירודה ודיווחי אבטחה ובאגים שמעמיסים על מי שאמור לבדוק, לנפות ולתקן.
מה בדיוק בדק המחקר החדש
החידוש המרכזי במחקר הוא לא מדידה כמותית של שורות קוד או מהירות פיתוח, אלא ניסיון להבין איך מפתחים עצמם מתארים את הבעיה. החוקרים בנו מסגרת ניתוח שכללה 15 קודים בשלושה אשכולות עיקריים: חיכוך בביקורת, ירידת איכות, וכוחות מערכתיים והשלכות רחבות. בתוך המסגרת הזאת עלו שוב ושוב אותם דפוסים: קוד שנוצר מהר יותר מאשר ניתן לבדוק אותו, שחיקה של אמון בין תורמים למתחזקים, פגיעה במאגרי ידע ציבוריים, ותחושה שהמערכת מתגמלת כמות על חשבון הבנה. במילים אחרות, הדיון כבר אינו רק אם המודל כתב פונקציה טובה או לא, אלא אם תהליך הפיתוח כולו מתחיל להשתנות כך שעלות האיכות נדחפת אל השוליים אל בודקי הקוד, צוותי האבטחה ומתחזקי הקוד הפתוח.
- המחקר ניתח 1,154 פוסטים מתוך 15 דיונים ב-Reddit וב-Hacker News.
- הממצאים אורגנו סביב שלושה צירים: חיכוך בביקורת, ירידת איכות, וכוחות מערכתיים.
- המסקנה המרכזית: רווחי פרודוקטיביות אישיים עלולים לייצר עלות קולקטיבית לקהילה.
למה החוקרים מדברים על "טרגדיית נחלת הכלל"
המסגור של התופעה כ"טרגדיית נחלת הכלל" הוא אולי החלק החשוב ביותר בסיפור. לפי החוקרים, כל מפתח בודד, או כל ארגון בודד, יכול ליהנות מתועלת מיידית: כתיבה מהירה יותר, פתיחה מהירה יותר של Pull Request, האצה ביצירת תיעוד או בדיקת רעיונות. אבל כאשר כולם פועלים כך, המשאב המשותף זמן הקשב, הסקירה והתחזוקה של הקהילה נשחק. אם לוקח שניות לייצר קוד בעזרת AI, אבל הרבה יותר זמן לבן אדם לוודא שהקוד בטוח, קריא, תואם ארכיטקטורה ואינו משחזר שגיאות ישנות, הרווח הפרטי הופך לעלות ציבורית. זה נכון במיוחד בקוד פתוח, שבו חלק גדול מהעבודה הקריטית נעשה בהתנדבות או תחת אילוצי זמן קשים, אך ההיגיון הזה זולג גם לצוותי פיתוח מסחריים, שבהם המפתחים הבכירים הופכים לשכבת סינון עבור נפח הולך וגדל של פלט מכונה.
המסגור הזה חשוב גם משום שהוא מרחיב את הדיון מעבר לשאלה אם AI "טוב" או "רע" למתכנתים. בפועל, אותם כלים יכולים להיות מועילים מאוד בכתיבה ראשונית, באוטומציה ובבדיקות, ובו בזמן להזיק כאשר התמריץ הארגוני הוא להגדיל תפוקה נראית לעין בלי למדוד את עלות הסקירה. לכן חלק מן המפתחים בדיונים שנבדקו לא התנגדו לעצם השימוש ב-AI, אלא לדרך שבה ארגונים וקהילות סופגים את התוצר: בלי רף מינימלי של בדיקה, בלי אחריות אישית ברורה, ובלי מנגנונים שמבדילים בין סיוע לגיטימי לבין הצפה באשפה משכנעת.
הבעיה כבר נראית בשטח: קוד, דיווחי אבטחה ותחזוקת קוד פתוח
המחקר מגיע על רקע רצף עדויות מהשטח. אחד המקרים הבולטים הוא curl, מפרויקט הקוד הפתוח החשובים בעולם התשתיות. לפי דיווחים מהחודשים האחרונים, Daniel Stenberg, המתחזק הראשי של הפרויקט, סגר את תוכנית ה-bug bounty של curl דרך HackerOne לאחר גל של דיווחי חולשות באיכות נמוכה, שחלקם נשאו סימנים ברורים של תוכן שנוצר באמצעות מודלי שפה. בדיווח שפורסם בינואר צוין כי תוך 16 שעות נרשמו שבע הגשות, ו-20 הגשות נספרו מתחילת השנה, אך אף אחת מהן לא תיארה פגיעות קונקרטית. חלק מהדיווחים הצביעו על באגים אמיתיים, אבל לא על חולשות אבטחה, ולכן דרשו זמן אנושי יקר בלי לייצר ערך אבטחתי ממשי.
Stenberg התריע כבר בינואר 2024 על תופעה דומה: דיווחים שנראים רציניים, כוללים ניסוחים מלוטשים ולעיתים משלבים מונחים אמינים, אבל בנויים על ערבוב של עובדות ישנות, פרטים מומצאים והזיות מודל. הוא הדגיש נקודה מאוזנת שראויה לתשומת לב גם כיום: עצם העובדה שטקסט נוסח בעזרת AI אינה אומרת אוטומטית שהדיווח שגוי. יש מי שמשתמשים בכלים כאלה כדי לנסח טוב יותר או להתגבר על מחסומי שפה. הבעיה, לדבריו, היא שדווקא דיווח "עשוי היטב" אך שגוי דורש יותר זמן להפריך. כלומר, לא הרעש הגולמי הוא הבעיה היחידה, אלא הרעש המתוחכם זה שנראה לגיטימי מספיק כדי לחייב בדיקה מעמיקה.
- דיווחי אבטחה שנראים אמינים במבט ראשון אך מבוססים על הזיות או על אי-הבנה.
- Pull Requests שנוצרים במהירות, אך מעבירים את מלאכת ההוכחה והבדיקה למתחזק.
- תיעוד, תשובות בפורומים ופתרונות העתקה שמגדילים את נפח המידע אך לא את איכותו.
גם Seth Larson, העוסק במיון דיווחי אבטחה בכמה פרויקטי קוד פתוח, תיאר בשנה שעברה עלייה בדיווחים "נמוכי איכות, ספאמיים ומלאי הזיות LLM". הוא הזהיר שהמחיר האמיתי אינו רק זמן, אלא שחיקה, בלבול ובידוד במיוחד משום שעבודת אבטחה נעשית לעיתים קרובות בערוצים סגורים. מבחינתו, גם כאשר הכוונה של המדווח אינה זדונית, התוצאה יכולה להיות דומה: עומס מצטבר שמרחיק מתחזקים מעבודה מועילה ופוגע בנכונות שלהם לטפל בדיווחים אמיתיים. זו המחשה ישירה לטענה של המחקר החדש: העלות המצטברת אינה בהכרח נופלת על מי שייצר את התוכן, אלא על מי שנדרש לנפות אותו.
הסתירה הגדולה: תחושת מהירות מול האטה בפועל
אחת הסיבות לכך שהדיון סביב AI בפיתוח כל כך טעון היא שהחוויה הסובייקטיבית של מפתחים לא תמיד תואמת את המדידה בפועל. כאן נכנס לתמונה מחקר נוסף של METR, שפורסם ב-2025 ובחן 16 מפתחי קוד פתוח מנוסים על פני 246 משימות אמיתיות במאגרים שהם מכירים היטב. התוצאה הייתה נגד האינטואיציה: כאשר הותר להם להשתמש בכלי AI של תחילת 2025, הם השלימו משימות ב-19% יותר זמן. מעניין לא פחות, אחרי הניסוי אותם מפתחים עדיין העריכו בממוצע שהם היו מהירים יותר בכ-20%. המשמעות אינה שכלי AI מאטים תמיד, אלא שקיים פער ממשי בין תחושת הזרימה שמספקת השלמה אוטומטית, ניסוח מהיר והפקת קוד מיידית, לבין עלות הזמן שמושקעת אחר כך בבדיקה, תיקון, המתנה, ניסוח מחדש ושחזור הקשר ארכיטקטוני.
בפברואר 2026 עדכנו חוקרי METR שהמדידה כבר נעשתה קשה יותר, משום שמפתחים רבים לא רצו להשתתף בניסוי אם ייאלצו לעבוד ללא AI בחלק מהזמן, וחלקם נמנעו מלהגיש למשימה דווקא עבודות שבהן ציפו לערך גבוה מהכלים החדשים יותר. החוקרים אף ציינו שסביר שבתחילת 2026 האפקט המהיר של הכלים כבר חיובי יותר מאשר בתחילת 2025, אך שהטיית הבחירה מקשה לאמוד את גודלו. זו נקודה חשובה מאוד לדיון: גם אם הכלים משתפרים, הבעיה המתוארת במחקר על AI slop אינה נעלמת. להפך, ככל שהפקת התוכן נעשית קלה ומהירה יותר, כך נדרש מנגנון חזק יותר של בקרה, הקשר ואחריות אנושית.
מה המשמעות עבור ארגוני פיתוח
מנקודת מבט ניהולית, הסיפור הזה נוגע ישירות למדדים שארגונים בוחרים להבליט. אם הנהלה מודדת בעיקר מספר משימות שנסגרו, כמות Pull Requests, או קצב ייצור תיעוד, היא עלולה לקבל תמונה ורודה מדי. AI מאפשר לייצר יותר פלט, אבל פלט אינו בהכרח תפוקה אמיתית. כאשר מפתח זוטר או אפילו מנוסה מייצר קוד מהר יותר, מישהו אחר צריך לשלם את חשבון הבדיקה. בארגונים גדולים זה מתבטא לעיתים בהתרחבות לא רשמית של תפקידם של מפתחים בכירים, ארכיטקטים וצוותי AppSec, שהופכים למסננת. במילים אחרות, צוואר הבקבוק זז: פחות זמן נדרש לכתיבה ראשונית, יותר זמן נדרש להבנה, בקרה, אינטגרציה ותיקון. אם הארגון לא מודד גם זמן סקירה, שיעור Rollback, באגים בפרודקשן ואיכות התיעוד, הוא עלול לחשוב שהוא מאיץ, בזמן שבפועל הוא רק מחלק מחדש את העומס.
- למדוד לא רק מהירות כתיבה, אלא גם זמן סקירה, תיקונים חוזרים ותקלות לאחר פריסה.
- לדרוש אחריות ברורה של המגיש: מי בדק, מה נבדק, ואילו הנחות אומתו ידנית.
- להבחין בין שימוש ב-AI ככלי עזר לבין הגשה אוטומטית של תוצרים שלא הובנו לעומק.
המחקר גם מתחבר לחשש ישן יותר בתעשייה: אובדן ידע. כאשר מפתחים נשענים על AI לא רק להאצה, אלא גם להבנה בסיסית של קוד, ספריות ותהליכים, קיים סיכון שהיכולת לתחזק מערכות לאורך זמן תיחלש. זה חשוב במיוחד במערכות ליבה, במוצרים עתירי רגולציה ובצוותים שעובדים על קוד ותיק. קוד אפשר לייצר מהר; הבנה ארוכת טווח קשה הרבה יותר לייצר בדיעבד. לכן, בעיני רבים מהמבקרים, הבעיה של AI slop אינה רק איכות ירודה של תוצרים בודדים, אלא הזזה איטית של תרבות ההנדסה ממלאכה של הבנה, נימוק ותחזוקה למלאכה של הפקה, סינון ותגובה.
הזווית הישראלית: יעילות, מחסור בכוח אדם והצורך במשמעת הנדסית
מנקודת מבט ישראלית, הדיון הזה רלוונטי במיוחד. חברות תוכנה מקומיות, סטארט-אפים וצוותי מוצר פועלים לרוב תחת לחץ זמן, מחסור יחסי במפתחים מנוסים וציפייה מתמדת "לעשות יותר עם פחות". בתנאים כאלה, ההבטחה של AI מפתה במיוחד: לקצר מחזורי פיתוח, לסגור פערי כוח אדם ולתת לצוותים קטנים תפוקה של צוותים גדולים יותר. אבל בדיוק באותם תנאים קל גם להכניס לארגון תהליכים שמגדילים חוב הבנה מבלי לשים לב. בישראל, שבה צוותים נוטים להיות רזים יחסית והפער בין מהירות קבלת החלטות לבין משמעת תהליכית עלול להיות גדול, הסיכון הוא שמפתחים בכירים יהפכו לבולמי זעזועים תמידיים של תוצרים שנכתבו מהר מדי ונבדקו מעט מדי.
המשמעות המעשית עבור השוק המקומי היא לא להירתע מכלי AI, אלא להקשיח את הכללים סביבם. בארגונים שפועלים בתחומי סייבר, פינטק, בריאות דיגיטלית ותשתיות ארגוניות, המחיר של קוד לא מובן או תיעוד מטעה עלול להיות כבד במיוחד. לכן סביר שנראה יותר חברות שמבחינות בין שימוש פרטי ב-AI בתוך סביבת פיתוח לבין קבלה פורמלית של קוד לפרודקשן. ייתכן גם שנראה יותר דגש על תבניות Pull Request, חובת בדיקות, תיעוד של מקורות ההמלצה של המודל, וכלי review אוטומטיים שמסייעים לסנן רעש לפני שהוא מגיע למפתח האנושי. במובן הזה, הדיון על AI slop אינו אנטי-AI; הוא בעד משילות הנדסית.
לאן הדיון הזה הולך מכאן
סביר להניח שהמונח AI slop לא ייעלם, משום שהוא מתאר בעיה מבנית ולא אופנה חולפת. ככל שמודלים נהיים זמינים יותר, מהירים יותר ומשולבים עמוק יותר ב-IDE, במערכות ניהול קוד ובפלטפורמות תיעוד, כך קל יותר לייצר תוצרים "מספיק טובים" כדי לעבור לשלב הבא אבל לא מספיק טובים כדי לחסוך עבודה אנושית. השאלה הגדולה עבור התעשייה אינה אם AI ישתלב בפיתוח; זה כבר קורה. השאלה היא מי יישא בעלויות האיכות, ואילו מנגנונים יבטיחו שהרווח מהאצה לא יבוא על חשבון הקהילה, המתחזקים והמשתמשים. המחקר החדש מספק שפה בהירה לדיון הזה, ומזכיר שתוכנה אינה רק מוצר של יצירה מהירה, אלא גם של אחריות, תחזוקה ואמון.
לכן, אם יש לקח אחד שעולה מהצטלבות המחקר עם הדיווחים מהשטח, הוא הצורך להפריד בין יצירה אוטומטית לבין קבלה אוטומטית. AI יכול להיות שכבת סיוע חזקה מאוד, אבל כאשר ארגונים וקהילות מוותרים על גבולות ברורים בדיקה אנושית, יכולת שחזור, אחריות של המגיש והבנה של ההקשר הם מסתכנים בהפיכת סביבת הפיתוח למרחב שבו קל לייצר יותר, אך קשה יותר לבנות נכון. עבור קהילת הפיתוח, ובוודאי עבור הקוד הפתוח שעליו נשענת התעשייה כולה, זה כבר אינו דיון תיאורטי. זהו ויכוח על הכלכלה של תשומת הלב ההנדסית, ועל השאלה אם עידן ה-AI יחזק את התשתית שעליה נבנית התוכנה המודרנית או ישחק אותה מבפנים.