12 המובילים שמעצבים מחדש את פיתוח התוכנה בעידן ה-AI

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

אלון טרון, מייסד שותף ו-CTO ב-Noma Security

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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

עילם מילנר, מייסד שותף ו-CTO ב-Echo

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

כן. מפעל התוכנה האוטונומי של Echo תיקן עד היום מעל 1.5 מיליון פגיעויות קוד ידועות (CVEs), היקף שאינו אפשרי בעבודה אנושית ידנית. התוצאות העסקיות ניכרות גם באימוץ: Echo נבחרה כשכבת האבטחה של חברות אנטרפרייז מובילות כמו Cerebras, Webflow, Varonis ו-UiPath, שבונות כיום את התוכנה שלהן על תשתיות מוקשחות של Echo.

רומן לבונסקי, מייסד שותף ו-CTO ב-Copperhelm

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

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

מה השתנה בעקבות היוזמה?

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

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

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

המעבר מעבודה מול קבצים בעורך הקוד למצב שבו Claude Code רץ על משימה שלמה האיץ אותנו פי עשרה, בשילוב תהליכי המשוב והבקרה שבנינו.

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

סימון רפופורט, CTO ב-Verbit

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

בהנדסה פיתחנו והטמענו מתודולוגיית פיתוח מבוססת סוכנים: Agentic SDLC (Software Development Life Cycle). כל מפתחי החברה עובדים היום עם AI באופן אחיד ומובנה, כך שאנחנו יכולים לשפר את התהליכים בצורה מרוכזת ולצבור ניסיון ארגוני מהר יותר. כל תובנה של מפתח אחד הופכת מהר לנכס של כולם. המפתחים עובדים מהר יותר, עם AI כשותף אמיתי, בלי לאבד את ההבנה העמוקה של המערכת.

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

כן, ומהר מהצפוי. המוצר החדש בתחום ה-legal הושק תוך שלושה חודשים בלבד מרגע ההחלטה, קצב שהיה בלתי אפשרי במבנה ובתהליכים הישנים. בתוך שישה חודשים רכשו אותו כ-20 ממשרדי עורכי הדין הגדולים בארה"ב, כולם מרשימת AmLaw 200, וגם בתי ספר למשפטים אימצו אותו ככלי הכשרה. והנתון שאולי מרשים מכולם: השימוש במוצר גדל בממוצע ב-170% מדי חודש. הלקוחות לא רק קונים, הם משתמשים יותר ויותר.

מיכאל (מישה) פיינשטיין, CTO ב-Bria

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

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

מה השתנה בעקבות היוזמה?

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

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

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

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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

רואים את זה גם במספרים: יכולות חדשות קפצו מפחות מאלף קריאות בשבוע ליותר מ-15 אלף, לקוחות שהתחילו כפיילוט מריצים היום volume מסחרי אמיתי, והערוץ שנשען על היכולת הזאת צמח פי 7.7 מתחילת 2026. אצל לקוח אחר, גרסה חדשה של מודל הסרת הרקע לווידאו שסיפקנו בפחות מחודש השיגה בבנצ'מרק שלו שיפור של 108 אחוז. השורה התחתונה היא שמהירות ההנדסה הפכה אצלנו לטיעון מכירתי. לפני שנה זה פשוט לא היה נכון.

איקו אזולאי, EVP Technology ב-Salt Security

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

התפקיד של המהנדסים השתנה בצורה ניכרת. בתחילת הדרך הייתה התנגדות אמיתית, ואף אחד לא רצה להפוך ל"מהנדס פרומפטים". היום המהנדסים מפקחים על צוות של סוכני AI, בודקים את התוצרים ומחליטים היכן צריך להתערב. גם הגיוס השתנה: בעבר שימוש ב-AI במשימת בית היה דגל אדום, והיום אנחנו דווקא רוצים לראות עד כמה מועמד יודע להשתמש בו היטב כדי לפתור משימה. במקביל, גם העבודה בין מוצר לפיתוח התקצרה: תהליך שדרש בעבר mockups ב-Figma והלוך ושוב בין המוצר ל-front-end יכול לעבור כיום מהאפיון של מנהל המוצר ישירות ל-PR.

האם נמדדו תוצאות עסקיות או טכנולוגיות?

כן. בהשוואה ללפני כשנה, מספר הפיצ'רים ששוחררו לכל מהנדס עלה בערך פי חמישה. במקביל, מספר הבאגים ב-production ירד בכ-30%, אף שהתפוקה הכוללת הוכפלה בתקופה הזאת. לפי החישוב שלנו, כדי להגיע לאותה קפיצה בתפוקה בדרך המסורתית היה צריך להגדיל בערך פי חמישה את מספר המהנדסים. העלות הנוספת של השימוש ב-AI, בעיקר בטוקנים, הייתה שקולה בערך לעלות של שני מהנדסים. ההשפעה ניכרת גם מול לקוחות: תהליך הוכחת יכולת (POV) ירד בממוצע מכ-160 ימים לכ-40 ימים, מה שמקצר משמעותית גם את מחזור המכירות.

עופר שמש, VP R&D ב-Milestone

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

הפכנו את ארגון הפיתוח שלנו ללקוח הראשון של המוצר שלנו. כשהתחלנו להריץ סוכנים על הקוד גילינו שהחסם העיקרי לא היה המודל, אלא הארגון עצמו. הקוד היה מפוזר בין כמה מאגרים, והידע היה בראש של אנשים. איחדנו את הקוד למאגר אחד ובנינו בתוכו שכבת הקשר מסודרת עם 337 מסמכים, 136 עמודי wiki ו-36 מסמכי עיצוב. במסמך העיצוב כתבנו לעצמנו: "כל פיסת ידע ארגוני שהיית מספר לעובד חדש צריכה להיכתב, כי הסוכן הוא עובד חדש נצחי." גם תחזוקת המסמכים עצמה הפכה לתהליך אוטומטי שעליו רץ סוכן מדי יום.

מה השתנה בעקבות היוזמה?

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

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

תפקיד המהנדס השתנה. מה שאני מודד אצל מפתח הוא כבר לא כמה קוד הוא כותב, אלא כמה חזיתות הוא מסוגל להחזיק, לשפוט ולהכריע בהן במקביל. יותר מהעבודה עוברת לניסוח המשימה, לארכיטקטורה ולסקירה. גם הידע נפתח מעבר לפיתוח: אנשי Product ו-Customer Success יכולים לשאול שאלות ישירות על הקוד והנתונים במקום לפתוח כרטיס ולחכות למהנדס. תהליכים שפעם דרשו מהנדס הפכו ל-self-service: הקמת טננט חדש, למשל, עברה מצ'ק-ליסט ידני של ימים ללחיצת כפתור במוצר פנימי. אצל הלקוחות, המערכת מתחילה לטפל בתקלות באיסוף הנתונים עוד לפני שמישהו פתח כרטיס, וזמן חקירה של בעיה התקצר מימים לדקות. אני עצמי עדיין שולח קוד לאורך כל הסטאק. מבחינתי זו לא נוסטלגיה: אני לא יכול להוביל שינוי בדרך שבה אנחנו בונים בלי לבנות.

האם נמדדו תוצאות עסקיות או טכנולוגיות?

כן. אנחנו מודדים את ארגון הפיתוח שלנו בתוך המוצר של Milestone, כך שאנחנו לא מסתכלים רק על adoption או על היקף השימוש בכלי AI, אלא על הקשר בין השימוש ב-AI לבין התפוקה ההנדסית בפועל. שיעור הקומיטים שנכתבו בסיוע AI עלה מ-75.4% ל-99.5%. מספר ה-PRים שהגיעו לפרודקשן בחודש עלה מ-275 ל-605, עלייה של 120%, ומספר ה-PRים למפתח בחודש עלה מ-26.5 ל-48.4, עלייה של 83%. זמן הסקירה החציוני ירד מ-7 דקות ל-5 דקות. כל זה קרה עם אותו צוות, בלי גיוס נוסף.

אריק צעדי, מנהל קבוצת פיתוח (R&D Director) ב-Port

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

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

מה השתנה בעקבות היוזמה?

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

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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

במחקר שכלל כ-12,000 שאילתות, הנגשת הקשר הנדסי מובנה לסוכנים דרך Port, במקום ממקורות מפוזרים, הוזילה את עלות השאילתה בכ-80%.

יותר ממחצית עובדי Port, כ-140 מתוך 265, ולא רק בפיתוח, משתמשים מדי חודש בכלי AI כמו Claude Code ו-Cursor. סוכנים פנימיים מאתרים ומתקנים בדיקות תוכנה לא יציבות ומייצרים טיוטות לתחקירי תקלות.

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

שירה נבות, Principal AI Researcher ב-UVeye

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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

שלומי קושצ'י, Chief Architect ב-Sweet Security

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

מה השתנה בעקבות היוזמה?

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

מערכת הוולידציה שלנו פועלת בשלוש שכבות. הראשונה היא ריצה לאחור על dataset מתויג, ובסוכנים מסוימים ראינו שיפור של עד 32% בדיוק. השכבה השנייה היא מערכת evaluations על ריצות של משתמשים, עם LLM בלופ, שמאפשרת לזהות אי-דיוקים והזיות. היא קיצרה ב-70% את זמן התגובה לזיהוי ותיקון תקלות, וכיום שיעור ההזיות שואף לאפס. השכבה השלישית מאפשרת להריץ גרסאות חדשות side by side ולבצע A/B testing לפני שחרור ל-GA.

רותם בן חמו, Director of Engineering, Core & GPU ב-ScaleOps

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

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

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

מה השתנה בעקבות היוזמה?

לפני שנה הגדרנו את עצמנו כארגון AI-First. השנה זה הפסיק להיות הצהרה והפך לדרך שבה R&D עובד. ברגע שהפסקנו לתחזק כלי פנימי, ההשקעה עברה למה שבאמת מבדל אותנו: חיבור הסוכנים לידע ולמערכות של הארגון. הסוכנים עובדים 24/7, במקביל, ולעיתים בסביבה נפרדת לחלוטין מסביבת הפיתוח. חלק גדול מהמשימות נסגר אוטומטית ומגיע לאדם רק לאישור.

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

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

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

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

מבחינת הלקוחות, זה כנראה היתרון הגדול ביותר. ScaleOps מבצעת אורקסטרציה אוטונומית של תשתיות ה-AI של לקוחותיה: המחשוב שמתחת לכל סוכן, מודל ואפליקציה שהם מריצים בפרודקשן. כשהרצנו בעצמנו סוכנים ומודלים בסביבה self-hosted על Kubernetes, נתקלנו מוקדם בבעיות שהלקוחות שלנו עומדים להיתקל בהן: עומסים אייג'נטיים שמתפרצים ונעלמים, GPU שלא מנוצל, ועלויות שקשה לחזות. ההבנה שעדיף להריץ ולנהל היטב את הכלים והמודלים הפתוחים הטובים בשוק היא בדיוק מה שאנחנו רואים אצל הלקוחות. היא זו שהובילה אותנו לפתח יכולות אורקסטרציה אוטונומית לסוכנים ולמודלים self-hosted בפרודקשן.

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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

ליאל כהן, Principal Software Engineer ב-Novee Security

אילו אתגרים פיצחתם כדי להזניק את הארגון קדימה בעידן ה-AI?

אנחנו בונים ב-Novee סוכני AI שמטרתם להפוך את הידע של חוקרי האבטחה שלנו לתהליכי Penetration Testing מלאים ואוטומטיים.

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

מה השתנה בעקבות היוזמה?

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

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

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

האם נמדדו תוצאות עסקיות או טכנולוגיות?

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