סוכני קוד בארגון: 66% כבר משתמשים, 20% נותנים להם לגעת בפרודקשן. תוכנית 90 יום למנהלי פיתוח ומוצר

סקר המפתחים של Stack Overflow לשנת 2026 שם מספר אחד על השולחן של כל VP R&D: ‏66% מהמשיבים כבר עובדים עם עוזרי קוד או סוכני קוד, אבל רק 20% נותנים ל-AI לגעת בפריסה, בתפעול או בתחקור של מערכות פרודקשן. הסקר פורסם ב-6 באוקטובר, עם יותר מ-30 אלף משיבים מ-169 מדינות, והפער הזה הוא בדיוק המקום שבו ארגונים מרוויחים או נתקעים.

בואו ניקח דוגמה אחת וניצמד אליה עד הסוף. דנה (דמות לדוגמה, לא אדם אמיתי) היא VP R&D בחברת פינטק בניו יורק, עם 120 מהנדסים ושלוש מנהלות מוצר. חצי מהצוות שלה כבר משתמש בסוכני קוד "מתחת לרדאר", ההנהלה שואלת איפה ה-ROI, ו-CISO שואל מי מאשר מה. במאמר הזה נבנה איתה תוכנית פריסה של 90 יום, שאפשר להעתיק ולהתחיל ממחר בבוקר.

מה זה בכלל סוכן קוד, ולמה זה שונה מהשלמה אוטומטית

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

והבחירה של המפתחים ברורה. לפי הבלוג הרשמי של Stack Overflow, בקרב מי שעובד עם סוכנים, הכלים המובילים הם Claude Code עם 66% ו-GitHub Copilot עם 59%. ועוד נתון שחשוב להבין: 73% ממי שמשתמש בעוזרי קוד או בסוכנים עושה את זה כל יום. כלומר, זה כבר לא ניסוי של כמה חובבים, זה כלי עבודה יומיומי.

מה הדאטה באמת אומר: שימוש גבוה, אמון נמוך

בואו נפרק את המספרים, כי הם מספרים סיפור הרבה יותר מעניין מ"כולם משתמשים ב-AI":

מסתבר שהמפתחים משתמשים ב-AI בעיקר לכתיבת קוד בתחום שהם כבר מכירים (67%) ולדיבאג (61%), כלומר במקומות שבהם הם יכולים לבדוק את התוצאה בעצמם. ברגע שמגיעים לפרודקשן, לפריסה ולתחקור תקלות חיות, השימוש צונח ל-20%. ובהודעה לעיתונות של Stack Overflow מופיע הנתון החד מכולם: רק 6.6% מוכנים לסמוך על AI כשמדובר בהחלטות חשובות.

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

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

המכשול: עמק ה-J והמס על הבדיקה

כאן נכנס דוח של DORA, צוות המחקר של Google Cloud שמודד ביצועים של צוותי פיתוח כבר יותר מעשור. במאי 2026 הם פרסמו את הדוח "ROI of AI-assisted Software Development", ובו מודל של ארגון עם 500 מהנדסים.

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

ובכל זאת, המספרים בסוף חיוביים: בתרחיש שלהם התשואה בשנה הראשונה היא 39%, עם החזר השקעה תוך כשמונה חודשים. אבל יש מחיר מובנה: שיעור הכשל בשינויים (Change Failure Rate, האחוז מהפריסות שגורמות לתקלה) עולה במודל מ-5% ל-6%. זה נשמע קטן, אבל אצל דנה, עם עשרות פריסות בשבוע, זה בדיוק ההבדל בין שבוע שקט לבין לילה בלי שינה.

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

גם McKinsey מגיעים לאותה מסקנה מכיוון אחר. לפי הסיקור של דוח "The state of AI in 2026" (סקר של 1,719 משיבים ב-97 מדינות), רק 37% מהמשיבים מייחסים ל-AI השפעה כלשהי על הרווח התפעולי (EBIT), ורק כ-6% נחשבים "high performers". הקטע המדליק הוא שכמעט שלושה רבעים מהם בונים מחדש את תהליכי העבודה סביב AI, לעומת כרבע מכל השאר. כלומר, ההבדל הוא לא כמה AI קנינו, אלא כמה שינינו את הדרך שבה אנחנו עובדים.

תוכנית 30/60/90: איך דנה מגלגלת את זה

אז מה עושים בפועל? הנה התוכנית שהייתי בונה עם דנה, שלב אחרי שלב:

בימים 1 עד 30 בוחרים צוות פיילוט אחד, קובעים קו בסיס (baseline, מדידה של המצב לפני השינוי) של ארבעה מדדים, וכותבים מדיניות שימוש ברורה. במקביל מגדירים הרשאות לסוכן ברמת הריפו, כדי שהכללים יהיו קוד ולא מסמך שאף אחד לא קורא. ככה זה נראה בקובץ ההגדרות המשותף של Claude Code, שנשמר בריפו ומשותף לכל הצוות:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

הקובץ הזה מאפשר לסוכן להריץ לינט ובדיקות בלי לשאול, מחייב אישור אנושי לפני כל git push, ואוסר עליו לקרוא קבצי סודות כמו .env. וחשוב לדעת: לפי התיעוד הרשמי, חוקי deny ו-ask נכנסים לתוקף מיד, עוד לפני שמישהו בצוות אישר את התיקייה. בארגון גדול אפשר להעלות את אותם חוקים לרמת managed settings, שגוברת על כל הגדרה אחרת.

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

בימים 31 עד 60 מרחיבים לשלושה צוותים ובונים את מה ש-DORA ממליצים עליו: בדיקות אוטומטיות, אינטגרציה רציפה (CI, הרצה אוטומטית של בדיקות על כל שינוי) ועבודה בשינויים קטנים. בשלב הזה גם ממנים "אלוף סוכנים" בכל צוות, מישהו שאוסף פרומפטים, הוראות פרויקט ודפוסים שעובדים.

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

מה מודדים: ארבעה מספרים, לא עשרים

הטעות הנפוצה היא למדוד "כמה שורות קוד ה-AI כתב". זה כמו למדוד מסעדה לפי כמות המלח שנכנסה למטבח. מה שמעניין אותנו הוא מה שיוצא לצלחת:

שיעור הכשל בשינויים הוא המדד הראשון שדנה צריכה לבדוק כל שבוע, כי הוא האות המוקדם לכך שהמהירות באה על חשבון היציבות. לצידו נמדוד את עומס הריוויו (כמה זמן ממתין PR לסקירה, וכמה גדולים ה-PRs), את זמן המחזור (Cycle Time, הזמן מהקומיט הראשון ועד שהקוד בפרודקשן), ואת חוויית המפתחים בסקר דופק קצר. אם זמן המחזור יורד אבל עומס הריוויו מזנק, אנחנו בדיוק בעמק ה-J ש-DORA תיארו: הקוד נכתב מהר יותר, והבקבוק עבר לסוקרים.

ומה עם מנהלי ומנהלות המוצר?

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

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

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

בעיניי: הכלי הוא החלק הקל

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

וחשוב להיות הוגנים לגבי המגבלות. סקר Stack Overflow מבוסס על מי שבחר לענות, ולא על מדגם מייצג של כל המפתחים. תרחיש ה-ROI של DORA הוא מודל עם הנחות (למשל עלות מועסק של 176 אלף דולר בשנה), לא מדידה של ארגון אמיתי, ואת המספרים של McKinsey ציטטתי מסיקור הדוח. כל ארגון צריך למדוד את עצמו, וזו בדיוק הסיבה שקו הבסיס בחודש הראשון הוא לא המלצה אלא חובה.

אז אם 66% כבר עובדים עם סוכנים ורק 20% נותנים להם להתקרב לפרודקשן, השאלה האמיתית לכל VP R&D היא: איזה מדד אחד אנחנו מתחילים למדוד כבר השבוע, כדי שבעוד 90 יום נוכל להראות להנהלה מספר ולא תחושה?

רוצים ללכת עם זה רחוק יותר?

את כל מה שתיארתי כאן, מהגדרות ההרשאות ועד העבודה היומיומית עם סוכנים על ריפו אמיתי, אני מפרק לעומק בקורס Claude Code Mastery (באנגלית).

למנהלות ומנהלי מוצר שרוצים להתחיל לעבוד עם Claude בעצמם, עם MCP, Skills, סוכנים ואוטומציות, יש את Practical AI with Claude בעברית. ולמי שצריך קודם בסיס בלי רקע טכני, יש את AI Fundamentals.

דמואים, תוכניות פריסה ופירוקים כאלה אני מעלה כל שבוע ל-YouTube ול-LinkedIn, וגם ב-X, Instagram, TikTok ו-GitHub.