502 - Carborator 39

פרק מספר 502 של רברס עם פלטפורמה - קרבורטור מספר 39, שהוקלט ב-19 באוגוסט 2025. אורי ורן מארחים את נתי שלום לשיחה על מיתוסים, מציאות והדרך ל-AGI. 🎗️

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

(אורי) רק על זה . . . .

01:00 על AI, יעילות ומכבסות מילים

(רן) אז יאללה - בואו נדבר על AI. נתי - כמה מילים ו-Let's go.

• (נתי) אני חושב שמה שרצינו לדבר עליו היום זה מיתוס לעומת מציאות, סביב הנושא של Productivity, של Development, של Code.

(רן) מיתוס זה מיוונית? דרך אגב, המילה? מאיפה זה מגיע?

(אורי) זו בירה יוונית . . . 

(רן) מאיפה המילה?

(אורי) מיתולוגיה . . . [ד”ש ל-Stephen Fry] 

• (נתי) אז באמת יש הרבה Hype סביב זה, ויש כל מיני ציפיות - ואני, בתור חברה שמדברת על זה לא מעט - אתה שומע את הדרג הניהולי
• אז המנהלים מצפים שאפשר יהיה לחתוך בכוח אדם, בגלל שעכשיו צריך פחות מפתחים.
• ואנחנו גם שומעים על הצהרות של חברות ציבוריות כמו Microsoft, מן הסתם עם Copilot, ו-McKinsey וכל מיני דברים כאלה.
• זורקים הרבה מספרים לאוויר, שמראים שבאמצעות AI הולכים באמת לשפר את הפרודקטיביות.
• כשבדרך כלל המילה . . . הצד השני של “Productivity” זה “פחות אנשים” . . . 

(אורי)  . . . לא בהכרח . . . 

• (נתי)  . . . . בדרך כלל, בטח בגלים הראשונים של הטרנד, זו בדרך כלל הציפייה . . . .
• הציפייה היא “Efficiency” = “פחות אנשים”.

(רן) כן, אפילו Satya Nadella הצהיר שניתק הקשר בין כמות כוח האדם לבין ה-Revenue או ההצלחה העסקית - ויום לאחר מכן . . .  אולי לא היום, אבל מייד לאחר פרסום דוחות מאוד מאוד מוצלחים של החברה, אלפי עובדים פוטרו בחברה . . . .

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

(רן) יחד עם זאת, ציניות בצד - יש דברים בגו.

• (נתי) כן . . .  כן ולא, אני חושב שזו התשובה הנכונה. אני חושב שהצד ש... 

(אורי) . . . כשאומרים “כן ולא”, זה אומר...

• (נתי) הכן יותר חשוב מהלא . . . 

(אורי) . . . . לא - מתכוונים להגיד “לא, אבל...”

• (נתי) אז זהו, אז אני אגיד שאני, ממרום גילי, מסתכל על זה טיפה אחרת.
• ואני מנסה גם לראות ב-Retrospect מה קרה בעולם ה-DevOps, למשל, כשאמרו דברים מאוד דומים.
• זה  “ייתר את כל אנשי ה-IT”, והיתה כתבה, אני חושב, אז, בזמנו, מאוד מפורסמת - “The End of IT”, כשהתחיל ה-Cloud.
• זאת אומרת, בוא נגיד - גדלנו ועברנו גלים כאלה שבהם ההבטחה לכאורה נראית כאילו היא מייתרת משהו אחר, אבל בעצם היא ייצרה הרבה יותר מקומות עבודה והרבה יותר הזדמנויות.
• ואני אתחיל מהנימה האישית, זאת אומרת - בהחלט החיים שלי בעולם ה-AI הם נראים אחרת - אני מדבר על חיי היום-יום, אני לא מדבר אפילו על העבודה - הם שונים לגמרי מ-Pre-AI בכמעט כל דבר שאני עושה.
• בין אם זה בכתיבת תוכניות, בין אם זה כתיבת בלוגים, בין אם זה ביצירת תוכן, בעבודה עם אנשים . . .
• כמעט כל דבר השתנה - בכל חזית.
• ומהבחינה הזאת, אני חושב שה-AI מייעל הרבה מאוד דברים - אבל הוא גם מאפשר לך לעשות דברים שלא עשית בעבר.
• והיום אני יכול להגיד לבן שלי, שהוא בכלל לא מתכנת והוא למד כלכלה ושמאות, לכתוב Agent-ים, ולהתחיל לחשוב על סוכנים ולהתחיל לחשוב על איך זה . . .
• ואותו דבר הבת שלי, שבכלל למדה אמנות, והיא עכשיו כותבים סוכנים בשביל לעשות לימוד.
• אני מלווה סטארטאפ אחר שמתעסק בעולם הלימוד - ומדבר על איך אנחנו בעצם פותרים בעיה של Knowledge Transfer.
• שזה מקומות שבהם באמת נהיות טריטוריות חדשות שנוצרות . . .  של לעשות Training, למשל, שזה Overhead יחסית גדול וזה Overkill ל-Knowledge Transfer, 
• אז הרבה פעמים Knowledge Transfer היה מין תחום אפור כזה שאף אחד לא התעסק איתו
• אבל ברגע שאתה יכול לשים Agent, שיכול לקחת חומרים כאלה ולעשות מזה משהו שהוא נראה כמו Training, אבל עם Effort הרבה יותר קטן, אז זה פותר את כל אלה שצריכים את ה Knowledge Transfer אבל לא היה שווה להם להשקיע ב-Training.
• זה קהל הרבה יותר גדול.
• עכשיו, תחשוב על כמעט כל גזרה בתעשייה שתלך אליה - אתה תמצא את ה-Traditional, שזה כאילו “בוא ניקח את ה-Business הקיים ונעשה לו אוטומציה באמצעות AI ואז אני אשפר פרודקטיביות”.
• לצידו, אתה תמצא הרבה מאוד מקומות שעצם הורדת החסמי-כניסה, פותח שווקים שבכלל לא היו.
• וזה נכון לנדל״ן, וזה נכון לכלכלה, וזה נכון לכמעט כל תחום בחיים. 
• אז לכן אני חושב שכשאמרתי “כן ולא” - מי שלא יתאים את עצמו לעולם הזה, אז כן, הוא ימצא את עצמו מתייתר.
• ומי שכן יתאים את עצמו, ימצא הרבה יותר הזדמנויות פה.
• ויהיו הרבה יותר הזדמנויות - חד משמעית.

(אורי) אז בואו נשאל, שנייה - איפה זה פוגש את המפתחים?

• (נתי) אז המפתחים זו הדוגמה הקלאסית, כי התחלנו את התחום הזה של Copilot וכל הדברים, אבל בזה שזה באמת עושה הרבה מאוד מהעבודה של המפתחים.
• אני חושב שיותר ויותר מבינים שזה הופך את העבודה של המפתחים ליותר מעניינת ויותר יעילה, אני חושב שזה באזורים מסוימים.
• ויש אזורים שגם זה לא נמצא שם.
• אני אתחיל ממשהו, משפט ששמעתי מאחד האנשים שאנחנו עובדים איתו, Lee Twito מ-LangTalks - שבסופו של דבר צריך להבין שאנחנו עובדים מול מודל שפה, וזה מה שהוא נועד לעשות, הוא נועד לעבוד על שפה . . .
• ובגלל שהוא נועד לעבוד על שפה, הוא יודע לעשות Prediction למילה הבאה, וזה ה-Core Technology מאחורי הדבר הזה, זה לא השתנה.
• השימוש בשפה השתנה - ובעצם תוכנה היא שפה.
• והאפליקציה שלקחו מהדבר הזה זה בעצם להגיד, אוקיי, אם יש לי שפה גם מובנית - בשונה מאנגלית או כאלה דברים, שהיא פחות Structured, ויש לה הרבה מאוד Exceptions to the rule, מה שנקרא
• בתוכנה אני יכול להריץ קומפילציה (Compile), אני יכול לבדוק את זה - לכן אני יכול להשתמש במודל שפה לייצר קוד.
• עכשיו, מה זה קוד? זה בעצם אוטומציה . . . אני יכול לקחת ולייצר דרך זה קוד שעושה גם אוטומציה.
• ואז האפליקציה שיכלנו לקחת . . . וההקשר הזה פתאום נראה מאוד מפוצץ.
• אבל כמו שפה, הוא טוב כמו ה-Data שאתה מכניס אליו, “Garbage-In-Garbage-Out“, מה שנקרא.
• ולכן צריך גם להבין את המגבלות של הדבר הזה - זה לא שאתה יכול לזרוק לו Prompt-ים ופתאום ייצא לך UI ואפליקציות וכאלה דברים . . .
• ואז אתה מוצא את עצמך לומד בעצם לפתח שפה אחרת - שהיא לא בדיוק אנגלית, היא גם לא בדיוק קוד.
• יש לי שפת ביניים כזאת, שהיא בעצם מאוד מאוד Structured
• אתה צריך להיות מאוד Detailed, אתה צריך להגדיר את זה בצורה מאוד מדויקת.
• לוקח לא מעט זמן למצוא את הניואנסים האלה ואת השפה הזאת, ואיך נכון לעשות את זה לכל מיני אזורים.
• ולוקח לא מעט זמן לדייק אותה.
• אז א', לוקח לא מעט זמן להביא את עצמך למצב שזה פרודקטיבי ובאמת מייצר לך את התוצרים הנכונים.
• זה יותר קל במקומות שהם חוזרים על עצמם, שהם Repetitive Code או Boilerplate, כמו שזה נקרא.
• ב-Enterprise Software זה כמעט אפילו הייתי אומר מייצר “ערך שלילי” בהרבה מאוד מקומות
•  בגלל שיש הרבה מאוד היבטים של אינטגרציה, בגלל שזה פחות Repetitive, בגלל שיש הרבה Legacy.
• אז כשמבינים את זה ומתאימים את הציפיות לזה, אז אפשר למצוא את המקומות שבהם זה כן פרודקטיבי, ואפשר למצוא את המקומות שזה לא פרודקטיבי.
• ואפשר להבין שזה לא קסם, שיש פה באמת איזה מנוע אינטליגנציה שאתה יכול לזרוק עליו מה שאתה רוצה והוא יעביר לך מה שאתה רוצה.

09:13 הדבר הכי פרודקטיבי בקוד זה למחוק / המחקר של METR

(רן) רגע, אבל נתי - אתה הגעת למסקנה בלי שעשינו את הדרך . . .  בוא רגע נעשה את הדרך, כי הדרך חשובה והיא מלמדת. 

• (נתי) כן, בהחלט.

(רן) אז לפני חודש-חודשיים, משהו כזה, מכון מחקר שנקרא METR פרסם מחקר שאני חושב שתפס את העיניים של הרבה.  אני קראתי אותו, אתה קראת אותו. גם כתבת עליו בלוג פוסט [The AI Paradox: Why “Efficiency” Won’t Just Mean Less Headcount — And What It Means For Your Tech Career], אני גם קצת דיברתי עליו בפרק הקודם של הפודקאסט שבקרוב יתפרסם [אה,  זה כבר קרה - 501 Bumpers 87].

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

• (נתי) כן, אז קודם כל, METR זה ארגון - זה Model Evaluation and Threat Research, אם אני זוכר נכון - שזה בעצם התחיל מהשאלה של מה זה פרודקטיביות? איך מודדים פרודקטיביות?
• ואני חושב שזה החלק הכי מעניין ב-Research הזה, אני חושב שהם הגיעו לאיזושהי נוסחה הרבה יותר מדויקת.
• כי הרבה פעמים, כשאמרתי את המספרים ש-Copilot זרקו ו -Microsoft זרקו וכאלה דברים - מבחינתם פרודקטיביות היא “כמה קוד ייצרתי” - שורות קוד שייצרתי באמצעות AI.

(רן) עכשיו, אנחנו יודעים שהדבר הכי פרודקטיבי בקוד זה למחוק . . .

• (נתי) בדיוק . . .  
• אז אני חושב שכל מי שקצת התנסה בזה יודע שזה די בולשיט, סליחה על המילה . . . 
• והם באו ובעצם ייצרו מתודולוגיה הרבה יותר מדויקת -
• הם לקחו 16 מפתחים מנוסים בעולמות של Open Source
• הם נתנו להם משימות רנדומליות - זאת אומרת חלק עם AI, חלק בלי AI, הם השתמשו ב-Cursor, בכלים שהם לכאורה נחשבים ל-Benchmark של התעשייה ב-Code Generation.
• וצילמו אותם במשך יום שלם - והראו באמת את הניסיון של כל אחד מהם כשהם נתנו להם את המשימות הרנדומליות האלה ולראות מה כל אחד מסוגל לייצר.
• ושאלו אותם בסוף “מה הרגשתם? כמה זה עזר לכם כשהייתם עם AI?” . . . .
• (רן)  . . . שאלו אותם לפני “בכמה זמן אתם מעריכים את המשימה?” ואחר כך, בסוף המשימה, “האם עבדתם יותר מהר או פחות מהר?” -  כשהשתמשתם ב-Cursor לצורך העניין.
• (נתי) כן. אז קודם כל זה היה 246, בערך, משימות שהם קיבלו שם, שכמו שאמרתי הם חילקו אותן רנדומלית.
• וה-Perception לצורך העניין היה שהם הרגישו שהם שיפרו את היעילות שלהם ב-20% - והתוצאה הראתה כמעט את התמונה ההפוכה, שזה דווקא האט אותם.

(רן) כלומר, הם הרגישו - הם אמרו, הם דיווחו - “עשיתי את המשימה שלי 20% יותר מהר”, כשלמעשה, כשמדדו את הזמן, ראו שהם עשו אותה ב-19% יותר לאט. 

• (נתי) יותר לאט מהמשימות ללא AI, כן. 

(רן) . . .  זאת אומרת, את המשימות חילקו חצי-חצי - חצי עם AI, חצי בלי - והסתכלו . . . . כמובן, חלוקה אקראית.

• (נתי) בדיוק - ואני מוסיף לזה שאם עכשיו אתה תבדוק, למשל, שזה עוד טיפה יותר מורכב אפילו מלבדוק פרודקטיביות, למעשה, מדידה אבסולוטית של Velocity, למשל, הייתה לראות באמת כמה קוד מיוצר על ידי AI, ואיך זה השפיע על ה-Production.
• זאת אומרת, בסוף כמה Feature-ים יצאו, והאם ה-Quality הלך והידרדר.
• האם היה Regression, לצורך העניין, או לא היה Regression?
• האם נוצרו כתוצאה מזה בעיית Security?
• כמה מהקוד שכתבת נזרק, לעומת כמה מזה באמת השתמשת בו.
• אני חושב שחסרים עדיין היכולת באמת למדוד את זה בצורה אפקטיבית, כדי באמת לענות על השאלה הזאת, אגב, בלי קשר ל-AI . . . 

(אורי) דרך Failure של Test-ים . . . . אם יש לך  כיסוי טוב . . . 

• (נתי) לא רק, זה לא רק זה . . .  גם Failure של Test-ים.
• אז יש DORA Metrics, שכאילו לכאורה מייצרים איזה מדד מסוים של איך מודדים פרודקטיביות בעולמות האלה.
• אבל באמת היכולת זה מה שאמרתי. זאת אומרת, אם הייתה אפשרות היום למדוד -איזה רעיון לסטארטאפ  -פרודקטיביות, אז ככה הייתי מודד פרודקטיביות. 
• הייתי מודד בסוף איך זה משפיע על השורה התחתונה.

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

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

(אורי) למה אתה אומר “לכאורה”?

• (נתי) לא יודע, סתם . . . . אני משאיר את הספק למי שלא רואה אותנו בפודקאסט הזה

(רן) “מרחב הכחשה” . . . 

• (נתי) . . . “מרחב הכחשה”, כן - אנחנו עדיין צעירים בנפשנו . . . .
• אז אני חושב שהפער שאני רואה זה באמת דווקא בצד של המנהלים.
• זאת אומרת, הם הרבה פעמים נשענים על מתווכים.
• והמתווכים - א': יודעים שהם נמדדים על פרודקטיביות, אז האינטרס שלהם זה להגיד “באמת השגנו עכשיו הרבה מאוד פרודקטיביות!”.
• ואיפשהו אתה, בתור מי שנמצא בתוך הפעילות הזאת, אומר “רגע, אבל המחוג כמעט ולא זז” . . . .
• כאילו, לא הרגשתי שכמות הFeature-ים שאנחנו מייצרים, או ה-Quality, השתפר כזה משמעותית. 
• הוא בסדר - הוא זז ימינה, שמאלה - אבל לא ראיתי קפיצה כזאת משמעותית עדיין.
• וזה, אני חושב, הפער שאותי לפחות הקפיץ וגם לכתוב את זה.
• זאת אומרת, המון רעש, המון Use Cases, המון האקאתונים, המון זה . . . 
• מראים המון המון רעש - ואתה אומר, רגע, אבל בסוף ה-Release יוצא כמעט באותו קצב, והFeature-ים יוצאים כמעט באותו קצב, אז משהו פה לא הסתדר . . .  

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

כלומר, גם עם DORA ועם אחרים, עדיין קשה מאוד למדוד Business Value.

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

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

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

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

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

16:23 ה-Bottleneck-ים ילכו לשני הצדדים

(אורי) אתה מסתכל על זה - תסלחו לי, אתם מסתכלים על זה בעיניים של מהנדסים יותר מדי . . . ואני מנסה להסתכל פה על התמונה הרחבה יותר.

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

עכשיו פה, בסוף, אני תמיד אומר ש-Execution - זה ש-95% מה-Execution זה קבלת החלטות. לעשות את העבודה, זה כמו שרן אמר - זה כלום.

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

אחד זה איך אני מקבל את הדרישות מה-Market, מעבד אותן לכדי Spec או דרישות שאני יכול להעביר אותן ל-Prompt. מהצד השני, איך אני עושה Go To Market, כי לא נוצר Business Value עד שלא לקחת את ה-Feature ל-Market.

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

• (נתי) אני אקח את זה לקיצון, את מה שאתה אומר. אני חושב שאתה אומר משהו מאוד נכון.
• נניח שאנחנו שמים את המספר “0” על זמן כתיבת קוד, ואנחנו מנתחים עכשיו כמה זמן לוקח לנו להוציא Release, למשל, של מוצר, כשזמן כתיבת קוד הוא לצורך העניין “0”.
• אנחנו נראה שהזמן של הוצאת Release לא יהיה 0, הוא יהיה אפילו קרוב יחסית לזמן שלוקח לנו להוציא Release
• כי הרבה מה-Thread-ים זה בכלל מה צריך להיות ב-Release.
• אחרי זה יש את כל ה-Debugging ואת כל הטסטים שצריכים לעשות וכל ה-Retrospect והדברים האלה, וגם...

(אורי) מ-Debugging וכו’ אני לא מוטרד - כי פעם שמערכת מכוסה טוב, עם Test-ים ועם Pipeline טוב, מערכת AI טובה, תדע ללמוד מה המערכת הזאת מצפה ממנה.

• (נתי) זה בהנחה שלא תצטרך לעשות הרבה Reject-ים ותיקונים, כן.
• זאת אומרת, נוצר לך הרבה קוד - עכשיו השאלה האם כל הקוד הזה נכנס אוטומטית ל-Production, או שעכשיו הוא נכנס ל-Production.

(אורי) לא  . . .  הוא נכנס ל-Pipeline, נכון?

• (נתי) . . .  נכנס ל-Pipeline - ואז יש לך Reject-ים. עכשיו אתה מבין שצריך לתקן את ה-Reject-ים.

(אורי) . . . מה-Reject-ים האלה המערכת לומדת . . . אמורה ללמוד . . . 

• (נתי) כן . . . עד גבול מסוים.
• אז אני חושב ששוב פעם, כשאמרתי את מה שאמרתי לגבי ה-Perception, ונניח כל פעם הייתי שומע “שיפרנו את הפרודקטיביות ב-30%!”, 
• והייתי מסתכל בסוף, הייתי אומר, אוקיי - אם יצא ה-Release שלוש פעמים, עכשיו צריך לרוץ לצורך העניין שליש פחות, וכמות ה-Feature-ים שיצאה צריכה להיות שליש יותר. 
• וזה לא . . . 

(אורי) כשאתה אומר “כמות ה-Feature-ים צריכה להיות שליש יותר” - בום, ה-Bottleneck נדחף לצדדים. כי,

לא יודע מה, לצורך העניין, אנשי ה-Product היו צריכים להכניס פי שלושה Feature-ים, כי עכשיו יש מפתחים ש...

• (נתי) כן, אז הייתי אומר שזה צריך להיות יותר Feature-ים, באותו זמן. משהו צריך להיות . . . .ה- 30% צריך להיות מתורגם בסוף, בשורה התחתונה, לקצב.
• או קצב Release יותר מהיר, או יותר Feature-ים בפחות זמן, או משהו מהדבר הזה.
• ואתה רואה שבשורה התחתונה, המספר הזה לא זז כמעט באזורים האלה.

(אורי) נתי, ניהלת ארגוני פיתוח. קרו לך פעם שני הדברים האלה? שמפתחים אומרים . . . כאילו, יושבים Idle ואומרים “אין מה לעשות, אנחנו עושים תחזוקה כל הזמן, כי לא מגיעים Feature-ים”. “אנחנו מטפלים בתשתיות, כי . . . “. זה מצד אחד. מצד שני, האם קרה לך פעם - לי קרה - שבא Business ואומר “רגע, רגע, רגע, תעצרו. אנחנו לא יכולים ללכת ל-Market עם כמות הFeature-ים שאתם מוציאים עליהם” . . . 

שני הדברים האלה, יצא לי שהם קרו, אוקיי? לא תמיד הפיתוח הוא ה-Bottleneck. עכשיו, זה היה קורה לפעמים . . . 

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

(אורי) נכון.

22:09 לא נהיו פחות כאלה - הם פשוט השתנו

(רן) הרשו לי לעשות אובזרבציה (Observation) - קודם כל, אנחנו פה ספציפית מדברים על מחקר שמדבר על קידוד,

אבל אנחנו יודעים שה-AI נכנס בכל צווארי-הבקבוק, לא רק בקידוד, אוקיי? זאת אומרת, זה נכון, צוואר הבקבוק אולי עובר, אבל יש AI גם ב-Product, גם ב-Market Research, גם בהרבה מקומות אחרים. יכול להיות שברמות בגרות שונות, אבל ברור לכולם שכן, זאת אומרת, צוואר הבקבוק יזוז - וגם שם אנחנו ננסה לפתוח אותו בכלים כאלה ואחרים, זה אחד. אבל אני חושב שדבר נוסף מעניין שיש פה במחקר . . . 

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

(רן) . . .  הוא יצטרך להיות Product . . .

(אורי) . . . הוא יצטרך להיות כנראה יותר Product, או כנראה יותר מה שנקרא Product Marketing. 

(רן) כן, אני חושב שגם דיברנו על זה באחד הפרקים [פה - 499 FE Containerization with Myops], על היחס בין מספר אנשי המוצר למספר מפתחים בחברה, שאולי פעם זה היה נגיד אחד לעשר או אחד לחמש, וזה כנראה הולך להשתנות. יהיו יותר אנשי Product - או יותר מפתחים שהם גם אנשי Product.

(אורי) ואני חושב שזה קצת מה שקרה לאנשי ה-IT במהפכת ה-DevOps, כן?

(אורי) . . .  לא נהיו פחות כאלה - הם פשוט השתנו.

• (נתי) נכון, זה בדיוק מה שאני אומר.
• אני אומר שא' - לגבי השאלה של האם זה ייתר מפתחים? חד משמעית לא.
• אני חושב שזה אפילו, בעיניי, יגדיל אפילו את הצורך.
• הם פשוט יעשו דברים אחרים - הם יעשו Agent-ים, הם יפתחו הרבה מאוד כלים שהם כבר נותנים הרבה יותר Business Value.
• מפתח יוכל לעשות הרבה יותר, עבודה גם מעניינת.
• אני חושב שזה בהחלט גם מייצר הרבה מאוד עבודה לכאלה שהם לא מפתחים.
• כמו שהתחלתי לתאר, בהכנסה של אנשים שהם באים דווקא מעולם ה-Business.
• הייתי באיזשהו כנס שדיבר על זה באמת בקמפוס של Google, והם קראו לזה Founder Market Fit.
• זאת אומרת שבעצם בהינתן זה שהטכנולוגיה הופכת להיות יותר Commodity, הערך הופך להיות ההבנה של ה-Business והבנה של המשתמש הסופי ודברים מהסוג הזה.
• ולכן אתה רואה היום יזמים גם בסטארטאפים שבאים מרקע בנדל”ן, מרקע בפיננסים, מרקע בכל מיני תחומים עסקיים, שלא דווקא באו מרקע פיתוחי.
• והם בעצם הופכים להיות היזמים בעולמות האלה. 
• ולכן אני חושב שזה באמת מייצר שינוי מאוד דרמטי - למה אנחנו קוראים “פיתוח”, לאיך נראה פיתוח, למה המתודולוגיות - כמעט הכל משתנה.
• אבל אני חושב שבשורה התחתונה זה בסופו של דבר ייצר יותר הזדמנויות ויותר מקומות, ולא יקטין אותם.
• גם בגלל שזה פותח כל כך הרבה הזדמנויות וכל כך הרבה שווקים וכל כך הרבה אפליקציות אפשריות שלא היו יכולים לדמיין קודם, פשוט רשימה כמעט אינסופית של הזדמנויות שנפתחות, כמו שתיארתי עכשיו ב Knowledge Transfer, שלא היו קיימות קודם, בגלל חסמי-כניסה מאוד גבוהים.

(אורי) נראה לי שדיברנו על זה בפרק עם רומה על עולם התעסוקה [497 AI-HR], ובאמת הוא אומר “לא יודע,

אני רק מקבל הרבה יותר Openings של משרות” . . .

25:15 ביקורת  / מדברים “מהנדסית” / צריך לדעת לנווט?

(רן) בוא תרשה לי רגע לחזור לדבר “מהנדסית”, אורי, ונחזור רגע למחקר הזה [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity]. אני חושב שקודם כל אפשר . . . . דרך אגב, יש לי הרבה מאוד מחלוקות עם איך שהם עשו את המחקר ומה שהם עשו שם, גם מבחינת בחירת... 

• (נתי) אנחנו נדבר על זה, נפתח . . . . 

(רן) כן, לא ניכנס להכל. קצת דיברתי על זה בפרק הקודם, שהקלטתי עם דותן ועם אלון [501 Bumpers 87], אבל בגדול, אחד זה אופן בחירת הפרויקטים, אופן בחירת המפתחים עצמם - שיש להם המון ניסיון בפרויקט, וזה לא תמיד המצב. זאת אומרת, זה מפתחים עם למעלה מ-5 שנות ניסיון עם ה-Codebase, ובהרבה מקרים זה פשוט לא המצב, זה לא Fair Play. מפתחים עם מעט מאוד ניסיון ב-AI . . .  זאת אומרת, יש לדעתי לא מעט באגים במחקר עצמו.

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

ואחד הדברים המעניינים זה “אלמנט ההפתעה”, שהוא בעצם ה-Highlight. זאת אומרת, שהם באים ואומרים “אני חשבתי שזה יותר מהר, לא ידעתי שזה יותר לאט”.

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

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

ויכול להיות שאם היית חוזר - עם אותם 16 מפתחים - על אותו מחקר חודשיים אחרי זה, התוצאות היו אחרות.

• (נתי) כן, זו נקודה באמת חשובה. אמרתי קודם שבעצם מ”כתיבת קוד" זה הופך להיות ל”כתיבת שפה”.
• יש כאלה שיקראו לזה “Prompting” - אני לא אוהב את המילה “Prompt”, כי אני חושב שזה לא באמת... 
• (רן) . . . Markdown Engineering  . . .
• (נתי) כן, זה סוג של שפה שאתה צריך, Context Engineering.
• שזה בעצם שאתה כותב באנגלית - אבל בצורה שבה ה-Agent שלך, או מה שזה לא יהיה, יבין בדיוק מה אתה רוצה.

(רן) . . .  היום עניתי לירוסלב איך אני עשיתי איזשהו Command ל-Claude Code, והראיתי למישהו שעובד איתי איך כתבתי את זה. אז ככה: זה מתחיל ב-Markdown ואז אני כותב פונקציה ב-Python - בסדר, קוד, אבל ב-Python . . . - ואז המשיך ב-Markdown . . .  והוא אומר לי “מה זה הקשקוש הזה?”, “למה אתה מערבב פה אנגלית ו-Python?“, ובכלל אין לך מימוש לפונקציות - אתה רק קורא להן בשם . . .

• (נתי) אז עכשיו הגענו למצב שכל מפתח מפתח שפה . . . 

(רן) . . . כן. אז אני אמרתי לו “אבל באמת, זה עובד . . . “ - אני לא צריך לממש את הפונקציה. אני קראתי לפונקציה בשם get version - והוא יודע איך לעשות את זה, אני לא צריך לממש את הפונקציה . . . 

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

(רן) אז לוקח זמן גם “לאלף את החיה”, אבל גם אנחנו עצמנו צריכים ללמוד להתרגל אליה ולעבוד איתה. 

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

(אורי) . . . אתה כבר לא צריך ניווט.

• (נתי) אז אני חושב שבשלבים האלה שאנחנו נמצאים כרגע, זה עוד איפשהו באמצע.
• בגלל זה אני חושב שזה עוד לא מוחלט.
• אם אתה עושה Vibe Coding - זאת אומרת, אם אתה כותב אפליקציה בודדת למשתמש בודד שכותב עכשיו זה יכול להיות שכן.
• כי אני חושב ששם בהחלט כבר אפשר לראות את הטרנד הזה, שאתה יכול לכתוב Prompt-ים, לראות אפליקציה וכאלה דברים.
• אפליקציה ל-Scale, שצריכה להתמודד עם רגולציות וכאלה דברים - שם זה חד משמעית “לא שם” כרגע.

(רן) אבל אני חושב שהשאלה שאורי העלה זו שאלה חשובה, והיא עולה בהרבה מאוד פורומים - האם אתה צריך לדעת שפת מכונה, עכשיו כשיש ++C? האם אתה צריך לדעת ++C כשיש Vibe Coding?

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

(אורי) אני לא מוטרד מהבשלות. ה-Vibe Coding ב... לא יודע, הוא נמצא איתנו שנה-וחצי? שנתיים? הוא עשה דרך ש-Java לא עשתה ב-15 שנה. 

• (נתי) . . . ועדיין - אם אני עכשיו אגיד לך שיש לך מערכת ניווט, שב-90% תביא אותך למקום, אבל יש לך נתיב אחד שיכול להיות שהיא תפספס בכל נסיעה שיהיה לך . . . . כמה אתה חושב אתה תוכל לסמוך על הכלי הזה?

(אורי) מה שתיארת עכשיו זה כאילו דינמיקה של זוג נשוי נוסע באוטו, נכון? . . . .

• (נתי) אני מנסה להסביר שיש דברים - בטח מי שבא מעולמות של אוטומציה מכיר את זה - זאת אומרת, נניח שיש לי אוטומציה ל-90% מהכלים, אבל יש Man in the Loop, איך שזה נקרא, בנקודה אחת.
• ולקבל אישור עכשיו - אנחנו יודעים כמה זמן זה לוקח . . . אתה צריך למצוא אותו והוא לא זמין.
• זה יכול לקחת יום, זה יכול לקחת שעה, זה יכול לקחת שבוע לפעמים
• תלוי באיזה ארגון אתה נמצא ואיפה אתה נמצא, כי תלוי באיזה מחלקה הבן אדם הזה נמצא . . . 
• אז 90% הגעתי לאוטומציה - אבל אני צריך את האישור הזה בשביל להעביר את הקוד הזה עכשיו, לצורך העניין, מ-Staging ל-Production. כמה זמן ייקח לי לעשות את זה?
• דקות? שעות? ימים?
• ברור שאני חזק כמו החוליה הכי חלשה, ולכן גם אם יש לי 90% - זה עדיין לא מספיק. 
• אני חושב שכדי להגיע למקום שבו אני יכול לעשות Autonomous Driving באמת, אני צריך להגיע למצב שזה באמת 100%
• וזה ממש - המספר “100%” הוא מוחלט.
• בשנייה שאני צריך להחזיק את ההגה ולהסתכל ולוודא ולהיות ער ולהסתכל עליו - אני לא אגיע ל-Productivity המצופה לצורך העניין.
• זה לא באמת יהיה 90% Productivity ו-10% התערבות.

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

• (נתי) האמת שזה משפט שאמרו לי בבה”ד 1 - וזה היה כשהייתי שבוז ברמות-על והייתי עם מיואש שאני הולך לעוף מהקורס. אמרו לי “תסתכל על זה שלידך - ורק תהיה צעד אחד לפניו”. זהו. ואז הצלחתי לעבור את זה.

(אורי)  . . . . אבל אני גם רוצה להגיד על ה-Autonomous Driving - הייתי עכשיו בקליפורניה, וזה שם . . .  זה שם. 

• (נתי) אבל למה? - כי הם צמצמו את זה לערים מסוימות, הם שמו, לצורך העניין, מספיק מערכות בתוך הדבר הזה. 
• אבל אני אומר שאם זה היה מגיע למצב שזה 90% מדויק - לא 100% מדויק - זה לא היה שם.
• עכשיו, לקח לזה שנים להגיע ל... שנים הם היו ב-90% . . .

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

• (נתי) אנחנו נהיה טיפה חלוקים פה, ואני אסביר למה.
• אני אומר, זה הכל תלוי מה. נכון, באמת היה לי Asist ל-Driving והוא עזר מאוד לנהגים והוא עוזר לי בנהיגה כשאני נוהג . . .

(אורי) . . . אבל זה Mission Criticality . . . 

• (נתי) נכון, אבל אני אומר שהערך - הקפיצה בערך - היא לא פרופורציונלית.
• זה לא קפיצה מ-90% ל-100% - זו קפיצה כמעט מ-10% ל-100%, גם אם שיפרתי רק ב-10%.
• זאת אומרת, אם היה לי 90% אוטומציה ועדיין ב-10% מהפעמים הייתי צריך לבקר את המערכת, לעומת משהו שנותן לי באמת 100% ואני יודע לסמוך עליו ב-100%, שאני יכול אפילו לא לשים נהג באוטו - זה לא 10% שיפור, זה הרבה יותר.

(רן) כן, ברור. היום, אם אני מריץ Claude או Cursor שכותב לי את הקוד, אני חייב-חייב- חייב לקרוא כל דבר שהוא כותב בביקורתיות - ולפעמים לפספס באגים. עכשיו, אם אני אדע שכל מה שהוא עושה זה “זהב”, זה 100%, ברור שזה משחרר אותי לחלוטין “ללכת לים ולהשתזף”, כן? אבל זה לא המצב.

• (נתי) בדיוק . . .  אני חושב שאנחנו מתקרבים לשם, אני חושב שהכלים מתקרבים בקצב מאוד גבוה לשם.
• אני אומר את זה בעיקר לא כדי להגיד עכשיו “אין פרודקטיביות עם AI”, חס וחלילה.
• כל החיים שלי השתנו בטווח מאוד קצר, וכל הצורת העבודה שלי השתנתה.
• חד משמעית זה נכנס לכל התחומים, זה משפר פרודקטיביות.
• אני אומר את זה בעיקר כדי שנדע איך לנהל ציפיות - גם מול המנהלים שלנו, גם מול עצמנו, גם מול אחרים - איפה זה כן נותן, איפה זה לא נותן.
• ויש פער ציפיות די גדול, כי כשרואים אפילו בסטארטאפ עם Base44, אז אומרים “הנה - בנאדם אחד הצליח להרים סטארטאפ!”, אז כולם מנסים עכשיו להרים סטארטאפ כבנאדם אחד.
• זה היה מקרה מאוד מיוחד - אני לא בטוח כמה אפשר יהיה לשכפל אותו.
• אז יש הרבה פעמים את הנטייה לשמוע על המקרים המאוד מאוד מוצלחים האלה - ולא שומעים על כל המקרים הפחות מוצלחים.
• ואז יש הרבה תסכול, ויש הרבה ארגונים שאומרים “מה אנחנו לא עושים בסדר?! איפה אנחנו לא טובים?!”
• ואני חושב שניהול הציפיות הזה הוא סופר חשוב.

(אורי) אני חייב להגיד - יש לי קהילה של CTOs ו-VP R&D [הזכרנו כאן 494 SoLead and RS], והשיח הזה כל הזמן קיים שם. אחד הדברים שהם מקבלים מזה, זה שתמיד יש להם רפרנס: הם יודעים . . .השיח הזה גורם להם להבין מה עבד, מה לא עבד. “מה, אני אני האידיוט היחידי, או אני... ?”

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

(רן) זה כמו התמונות האלה, של “Instagram vs. Reality” . . . .

• (נתי) לגמרי . . . . ומן הסתם, כמו בכל Hype, בהתחלה שומעים רק על המקרים - אני זוכר את זה גם מ-Terraform בזמנו - שומעים רק על הדברים החיוביים.
• וכולם מספרים כמה הם עשו “אוטומציה מפה להודעה חדשה”
• ובסוף הם מגלה שאוקיי, זה לא הקטע - הם חווים בעיות של חיים אמיתיים, ולא כולם כאלה.

36:19 לא רק Coding / הדרך ל-AGI

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

אז סיבה אחת יכולה להיות כי זו שפה - והם טובים בשפה והנה אפליקציה פרקטית של שפה, אוקיי? 

(אורי) אבל אני חושב שלהבדיל משפה, קוד היא [שפה] מאוד מוגדרת - כי אחרת זה לא יתקמפל (Compile).

• (נתי) בדיוק, אני אומר “יש Complier”, זו תכונה סופר-משמעותית.

(רן) אז סיבה אחת “כי זה קל". הסיבה השנייה: יש פה Business Value, נכון? כאילו - פרודוקטיביות. אולי זה עדיין Questionable, אולי עדיין לא מוכח במאה אחוז שיש פה Business Value - אבל התחושה היא שיהיה פה . . .

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

(רן) כן, אבל רגע, אני רוצה לגעת בנקודה קצת יותר עמוקה. זאת אומרת, סבבה, אני חושב שיש פה Business Value, אני יודע שיש כאלה שלא [חושבים ככה]. אני חושב שעם הזמן אני מקווה שאני אוכיח [שאני] צודק, וגם אתה, נתי. זאת אומרת,

אנחנו חושבים שלשם זה הולך.

אבל אני חושב שיש פה עוד משהו. כלומר, אחת הסיבות שבאמת מודלי-שפה יודעים לקודד יותר טוב, וגם ידעו לקודד יותר טוב, היא שזאת הדרך ל-AGI. כלומר, בסופו של דבר, “ה-Grand Plan”, כמו שאני מבין אותה, של מפתחי ה-Artificial General Intelligence, זה לייצר מכונות שיודעות לכתוב בעצמן את הקוד שלהן, כדי שנגיע ל-Inflection Point - כדי שנגיע לנקודה שבה אנחנו יכולים לתת זינוק לכיוון ה-AGI.

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

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

• (נתי) לא, אני חושב שזה אפילו יותר מובנה מזה. אנחנו אומרים, AI בעצם נועד . . .  זה Large Language Model - זה מודל שפה. 
• שפת-תוכנה זה שפה - רק שהיתרונות שלה שהיא הרבה יותר מובנית, כמו שאמרנו, ולכן אני חושב שהמודלים האלה באמת נבנו כמעט אפילו לצורך הזה.
• והקפיצה הגדולה שאנחנו רואים זה בגלל שבאמת כשחיברנו שפה - שבסוף יכולה להפעיל טוסטרים ומכוניות ודברים כאלה - למודלי שפה, אז פתאום זה התחבר לעולם האמיתי, וזו הקפיצה הגדולה.
• ופתאום אנחנו יכולים “לגעת”, היות וכל העולם הוא היום Software-Driven, אנחנו יכולים “לנהל את העולם,” - וזה מתקרב לעולמות של ה-AGI.
• אני חושב שהקפיצה הבאה הגדולה - הייתי אומר שה-AGI הוא טיפה יותר רחוק - אם נגיע למקום שבו אנחנו עושים את הקפיצה מ-90 ל-100, אנחנו נראה פתאום אסימפטוטה הרבה יותר . . . קפיצה הרבה יותר גדולה, כמו שנתתי בדוגמאות של האוטומציה.
• ולשם אני חושב שזה ה-Milestone הבא שאפשר לשאוף אליו ולהסתכל עליו - וזה אני חושב שיקרה יותר מהר.
• וכמו שאמרתי - הקפיצה לא תהיה ב-10%. ברגע שנגיע לנקודה הזאת, זה יהיה לעבור מ-Assisted Driving ל-Autonomous Driving, זה יהיה ממש חוויה כזאת.

(רן) אז תראה, אני לא יודע עד כמה התחזיות האלה מודויקות, אבל כן קראתי תחזיות על “יולי 2027”. כלומר, זה לא כל כך רחוק . . .  עכשיו, אני חושב שכן יש פה הרבה מאוד מקום לביקורת על Variance בתחזית הזו, אבל אני לא משוכנע שזה כל כך רחוק.

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

• (נתי) כן, אני חושב שאגב . . . טוב, זה נוגע בדבר אחר שאני מתעסק איתו שאמור להוביל לשם - זה הצורך גם בחשיבה אחרת, כשמתקרבים למקומות האלה. 
• למשל, בעולמות של Autonomous SRE זה נקרא, כל הנושא של ניהול Datacenters וכאלה דברים.
• כשאני אומר “חשיבה אחרת” - אנחנו היום בבעיה שאנחנו מוצפים במידע.
• יש איזו סטטיסטיקה שאומרת שלכל ארגון יש בממוצע איזה 5-7 כלי Observability, וכל אחד עושה טיפה משהו אחר, ואנחנו מוצפים במידע.
• ואחת הבעיות זה עודף מידע, ומאוד קשה . . . זה Garbage In, Garbage Out.
• ואז זה דורש חשיבה אחרת, של איך אני בעצם מצמצם מידע, לא מגדיל מידע. 
• אז זה הרבה פעמים נתפס - בטח למי שבא מעולמות של BI וכאלה דברים - זה נתפס כמעט כאנומליה.
• ואני חושב שהאתגר הרבה פעמים זה לזקק את המעט מידע שהוא באמת חשוב.
• כי AI עובד מאוד טוב, כמו שאמרנו, כשהמידע הוא דווקא הרבה יותר מדויק ומצומצם.
• וזו תפיסה שהיא, שוב פעם, למי שבא מעולמות BI למשל, זו תפיסה שאני רואה שמאוד קשה לעשות.

(רן) כן. דרך אגב זה נכון גם מהפן של ה-Inference. כלומר, לזה קוראים Context Engineering. כלומר, תן לו את מה שהוא צריך, תן לו את כל מה שהוא צריך - אבל לא יותר מדי, כי אחרת זה Needle in the Haystack, אבל זה גם נכון ל-Training. כלומר, זה לא עוזר להגדיל את ה-Data Set של ה-Training אם זה זבל, אוקיי? זה מפריע.

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

• (נתי) ההוכחה הכי טובה זה המודלים הקטנים - אנחנו רואים היום במודלים קטנים שאפשר להגיע לדיוק יחסית גבוה, כשאתה יודע בדיוק לאיזה Use Case אתה מכוון אותם.
• והיום, אגב, גם GPT הוציאו מודל קטן Open Source שאתה יכול להתקין, וגם Google עכשיו יצאו עם משהו כזה, שאתה ממש יכול לעשות לו Fine-Tuning ולהגיע לתוצאות טובות כמו למודל גדול.
• שוב פעם - באזורים תחומים: אם אתה תוחם אותו לאזור מסוים, אתה יכול להגיע לדיוק מאוד גדול.

(אורי) תכל'ס, זה מחכה אותנו - את האנשים - נכון? פעם שיש לך מומחה - לא נדבר על רן, כן, שהוא מומחה בהכל - אבל פעם שיש לך מומחה במשהו, אז הוא מומחה ב-Domain מסוים, והוא Trained ל-Domain הזה.

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

• (נתי) כן, אבל אני עכשיו אחבר את זה ל-AGI: החזון ב-AGI זה ש-AI ידבר עם AI, לא ידבר עם בן אדם.
• זאת אומרת שהם בכלל, נניח ה-Product Manager יהיה Agent, והמפתח יהיה Agent וה-Tester יהיה Agent, והם ידברו אחד עם השני, ואז...

(אורי) כמו שעושים אנשים . . . . בסדר.

• (נתי) כן, נכון - רק בלי אנשים.
• שזה - לך תדע מה יקרה מאחורי כזה דבר, עוד מעט . . . זה כן יכול להיות עולם מפחיד. 

(רן) אני עכשיו כבר לא בטוח שאתה אמרת את זה . . . 

(אורי) בוא נאמר, נתי - העולם מפחיד גם ככה.

• (נתי) כן, אני מקווה שזה לא יקרה בימיי, בוא נגיד ככה. 

(רן) העולם מפחיד אז פוחדים, 

(אורי) . . . בתור נציג החות'ים פה . . . . 

• (נתי) אנחנו עכשיו במקום שבו אנחנו מרגישים גם ככה שהעולם הוא בטרללת אינסופית, שאף אחד לא יודע מי נגד מי כבר.
• אבל אני חושב שלפני שנגיע למקום הזה, יש הרבה דברים, לדעתי, כיפיים ומעניינים שאפשר לייצר בדבר הזה.
• לפחות זו החוויה האישית שלי, זה המסר שאני מעביר גם לילדים שלי.
• שתחשבו על Agent-ים, זה נותן לכם עכשיו כמעט בכל תחום, בין אם זה אמנות ובין אם זה כלכלה ובין אם זה [משהו אחר], להיכנס ולהמציא דברים שבעבר היו שמורים רק לאנשים שהם יוצאי-8200 או “אנשים אחרים”.
• אז זה יכול גם לייצר סוג של דמוקרטיזציה חיובית. 
• זאת אומרת, יש היום הרבה היבטים חיוביים - לצד, כמו כל דבר, הרבה דברים שיכולים להיות שליליים ומפחידים.
• אני מעדיף להסתכל תמיד על - לא סתם קוראים לי נתי שלום - אני מעדיף להסתכל על הצד החיובי ולא על הצד השלילי.
• את זה יש לנו מספיק, בלי עין הרע.
• ואני חושב שבנימה הזאת אולי אפשר ככה לחתום את השיחה. 

(רן) אמן.

(אורי) שיהיה יותר Downwind עם ה-AI . . . 

• (נתי) לגמרי.

תודה רבה על שיחה קלילה על-AI ו-AGI וחברים. להתראות.

[קישור לקובץ mp3]

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!