רברס עם פלטפורמה

פרק מספר 504 של רברס עם פלטפורמה, שהוקלט ב-11 בנובמבר 2025 - פרק ראשון אחרי כנס Reversim 2025, שהיה מוצלח מאוד (גם בסטנדרטים הגבוהים ממילא). בזמן הקלטת הפרק עדיין לא פורסמו ההקלטות, אבל עכשיו כבר כן - Reversim Summit 2025 - YouTube - שווה לפנות כמה שעות טובות. בינתיים, ואורי ורן (וניק!) מארחים את דניאל בסקין כדי לדבר על תכנות פונקציונלי. 🎗️


[01:27] דניאל
(רן) אז קצת לפני שניכנס לתכנות פונקציונלי - קצת עליך, דניאל. 

• (דניאל) אז אני כבר שנים עם תכנות פונקציונלי - הוא רודף אותי, אני רודף אותו.
• בזמן האחרון אני עצמאי ומנסה להתפתח בכיוון של לייעץ, מתכנת - למכור לארגונים וחברות איכות קוד, בגדול.
• ותכנות פונקציונלי זה הדרך שבה אני בוחר לעשות את זה - ואני גם מאוד אוהב ללמד אותו.
• לכן אני פה - הייתי רוצה למצוא קהל יעד רחב לזה, ואני מקווה שהציבור שמקשיב ומאזין לפודקאסט הוא חד-משמעית קהל שיכול להתאים לזה.
• ואני עצמי, אם ניקח קצת אחורה לאיך שהגעתי לכל העולם הזה, אז בכלל התחלתי כמישהו שלמד פיזיקה, ותוכנה היה ממני והלאה.
• ועל הדרך לקחתי כמה קורסים באוניברסיטה בתכנות - וחשבתי שיום אחד אולי זה יהיה שימושי, משהו שם בפיזיקה, אני לא יודע.
• מפה לשם, גיליתי שאני ממש נהנה מזה - נהנה בעיקר מלסדר קוד, לעצב קוד, לעשות אותו ליפה ואלגנטי - ומשם התפתחתי לעולם התוכנה, עשיתי Java מספר שנים . . . 
•  ואז בטעות, סתם ניגררתי לאיזה בלוג שהראה “איזה שפה מוזרה עם חיצים”, ולא הבנתי מה זה . . . 
• וזה כזה הציק לי, ואמרתי “טוב, יאללה, אני אשב רגע, אני אלמד מה זה החצים האלה ומשם נראה אם זה מעניין”.
• הסתבר שזו השפה שקוראים לה Scala, שרצה על-JVM - ומשם נבלעתי לחור שחור של תכנון פונקציונלי, ומאז זה הדביק אותי.
• הייתי עושה Java בסגנון הזה - כשזה עוד היה מאוד קשה ולא נוח.
• היום Java הרבה יותר “נחמדה” לזה, אבל עכשיו למעלה מעשור אני כבר מתכנת וכותב קוד בסגנון הזה
• ועוזר לאנשים אחרים לעשות את זה, מרצה ברחבי העולם גם, בכנסים וכדומה.
• ועכשיו הייתי רוצה - אז הייתי בעיקר בעולמות של Scala - עכשיו הייתי רוצה קצת להרחיב את קהל היעד, ולראות איך אני יכול לעזור לאנשים ב-JVM, Python, JavaScript, TypeScript, בכל מקום.
• להפעיל את אותם עקרונות שבעצם הם אוניברסליים יחסית - תכנון פונקציונלי זה לא משהו מאוד פרטני לשפה ספציפית, והייתי רוצה להרחיב את קהל היעד.
• לראות ולהביא לאנשים את הידע הזה עד כמה שאפשר.

[03:32] פונקציונליות טהורה - למה?
(רן) לפני שבועיים פחות או יותר, יונתן ממן  מ-Teads [PKA Outbrain] פרסם Twit ושאל “מהי השפה שלמדתם  ואף פעם לא השתמשתם?” . . . . והיו כל מיני תשובות משעשעות. וסתם סקרן אותי, האמת שלא עשיתי סטטיסטיקה, אבל כמה מבין השפות האלה הן פונקציונליות או “Pure Functional” ואחרות. אני אישית רשמתי שפות אחרות, האמת שגם ML . . .  כן, אבל טוב, פשוט לא משתמשים בה הרבה בתעשייה.(אורי) אני רשמתי Logo . . . (רן) Logo, נכון . . . היו כאלה שרשמו “חזקאל” [hasql], אבל גם היו Prolog ואחרים, כלומר שפות אחרות שהן אולי פחות פרקטיות. יפות, אבל פחות פרקטיות ויותר נישתיות.אבל יש לא מעט שפות שמתהדרות במינוח “Pure Functional”, נכון? - ואולי כמעט כל השפות, יש בהן איזשהו אספקט פונקציונלי . . . .

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

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

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

(רן) כן, אז אולי בתור התחלה נבוא ונגיד שתכנון פונקציונלי זה לא רק Lisp ולא רק Clojure ולא רק ML, אלא זה כנראה נמצא כמעט בכל השפה שאתם משתמשים בה היום. זאת אומרת, הזכרת את Scala שהיא חזקה בזה, אבל זה גם קיים ה-Java, זה גם קיים ב-Python וזה קיים הרבה מאוד ב-JavaScript וב-Ruby וכנראה בכל שפה אחרת שנמצאת פה באזור. (אורי) אני חייב להגיד שאני עשיתי קצת ב-++C  . . . 

• (דניאל) תנחומיי. אני לא יודע אם זה . . . 

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

• (דניאל) התשובה היא מבחינתי היא “גם וגם וגם וגם” . . . . בערך לכל דבר שתשאל.

(רן) אז בוא נפרט . . . 

• (דניאל) אז קודם כל, אני חושב שאנחנו מתכנתים - באנו לכתוב תוכנה, באנו לכתוב אותה טוב
• ואני חושב שתכנון פונקציונלי מביא לנו, “שם על השולחן”, מלא מלא דברים שקשורים בדיוק לזה.
• כל מיני מילים שנגמרות במילה “Ability”, כמו Maintainability, Testability, Debuggability ועוד “Abilities” למיניהם.
• וזה לא סתם במקרה, אלא זה משהו מאוד אינהרנטי (Inherent) בתכנון פונקציונלי - שזה ההתרכזות ב”פונקציות טהורות”
• פונקציות עם קלט ופלט.
• זה משהו שהוא הרבה יותר נוח לעבודה, אם אפשר למסגר את הבעיה בצורה הזאת.
• נגיד Testability - אם יש לי איזה Side Effect מלחיץ שעושה Mutation על איזה משתנה, לא יודע איפה    
• כשאני רוצה לעשות טסט על הדבר הזה, אני צריך עכשיו, לפני שאני מריץ את הטסט, לעשות Setup ועוד פה ושם וזה . . . 
• ואז בסוף, אחרי שעשיתי את ה-Setup המורכב והמתוסבך הזה, אז אני עושה טסט.
• אם אני עובד בעיקר עם פונקציות טהוריות, עם קלט ופלט - איתחלתי את הקלט, הסתכלתי על הפלט, סיימתי.
• אז טסטביליות (Testability) בסגנון הזה זה משהו שבא כמעט “בחינם”, ברגע שנכנסים לעולם הזה.
• אגב, אנחנו אולי קפצנו קדימה, כי לא ניסינו להגדיר מה זה “תכנות פונקציונלי” . . . 

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

• (דניאל) אז Purity - יש כל מיני דרכים להגדיר אותה, ולא כולן חופפות במאה אחוז, אבל אני אוהב להסתכל על זה בתור “השימוש בפונקציות שהן מתמטיות”, במובן הפורמלי של המילה.
• “מתמטית” - כי יש קלט, יש פלט, ואין שום דבר אחר.
• מה ההפוך של זה? נגיד, יש לי פונקציה שמה שהיא עושה זה שהיא מקבלת “שום קלט” ומוציאה Void, אין לה כלום . . . .
• אז זה נגיד לא פונקציה מתמטית - אין לה קלטים, אין לה פלטים, וכל פעם שאני אריץ אותה, אני לא יודע מה יקרה . . . .
• יקרה משהו, אבל לא רואים את זה מגולם בקלט והפלט.
• (רן) נגיד מדפיסה על המסך . . . דוגמה קלאסית.
•  (דניאל) מדפיסה על המסך, כן. אז קשה לכתוב לזה טסט, קשה לתפוס ברקע את ההדפסות האלה, קשה להבין מה קורה שם - לי, ל-Compiler, ל-AI . . . 
• אם אנחנו חייבים לדבר על AI, אז גם ל-AI יהיה קשה לתפוס מה קורה שם.
• אז פונקציה טהורה זה פונקציה שהפוך מזה - פונקציה שכל מה שיש לה לעשות זה לקחת את הקלטים שלה ולהוציא פלטים.
• עכשיו, אני לא טוען שתמיד אפשר למסגר כל בעיה בצורה הזאת - וזה מאוד תלוי בסביבה, ויש שפות שפחות טובות או יותר טובות.
• אבל אם הצלחתי לכתוב את הבעיה שלי - לנסח אותה בצורה הזאת - אני מוצא את עצמי מפרק את הבעיה למלא אבני-בניין קטנות של פונקציות טהרות.
• וכל פונקציה - אפשר לקחת אותה בנפרד: לשחק איתה, להריץ אותה בנפרד, לעשות את הטסטים בנפרד - ואז זה Mix & Match בין הדברים האלה.
• אז זה מביא לנו יותר טסטביליות (Testability), זה מביא לנו מודולריות שהרבה פעמים אנחנו שואפים אליה
• דברים כמו Reusability, שזה גם משהו שתמיד מבטיחים לנו בכל פרדיגמה חדשה שמגיעה, מבטיחים לנו את זה.
• ותכנון פונקציונלי זו לא פרדיגמה חדשה - היא התחילה אי-שם בשנות ה-60, והיא אף פעם לא הבטיחה לנו את זה אפילו - אבל עם זאת, אם הקומפוננטה (Component) זה פונקציה טהורה, קטנה, וחמודה, שאני יודע בדיוק מה הקלטים הפלטיים שלה, הרבה יותר קל למחזר אותה.
• כי אני לא צריך לחפש את התלויות הבלתי-נראות ברקע.

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

• (דניאל) אז יש שפות לוגיות, למשל, Prolog היא שפה לוגית שעד כדי כל מיני דברים של יעילות היא יחסית טהורה.
• אבל אפילו בשפות אימפרטיביות (Imperative) יש משהו שיכול להיות טהור - אבל זה לוקח אותנו ממש לאיזוטריקה . . . 
• יש שפות שיש בהן . . .  משהו בסגנון Rust [דותן חש הפרעה בכוח], שיש Borrow Checker - לוקחים את זה עוד כמה רמות למעלה.
• יש לנו מה שנקרא Linear Typing, ואז אומנם אני יכול לעשות שינויים במערכים in place, אבל אני אף פעם לא יכול לגשת לדבר ששיניתי בעבר, אני יכול רק להתקדם קדימה.
• ואז במקום מסוים אני אהיה Pure, בזה שאני לא יכול לחזור לדברים ש”זיבלתי” מאחורי.
• אבל זה ממש איזוטרי ולא קשור לעולם ה-Mainstream-י שבו אנחנו עובדים. 

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

[10:00] יעילות / מבני-נתונים גדולים ושינוי קטן
(רן) יצא לי לעבוד לא מעט, נגיד ב-Clojure, אוקיי? ונגיד שם עובדים הרבה פעמים על Map-ים, על רשימות . . .  ועכשיו, נגיד שיש לך רשימה מאוד מאוד מאוד ארוכה - ואתה רוצה לשנות אותה. כיוון שהפונקציה היא Pure, היא לא תשנה את הרשימה אלא תייצר איזשהו עותק - ופה אני שואל את השאלה של יעילות.אז איך השפות האלה מתמודדות עם הצורך לעבוד, נגיד, עם מבני-נתונים גדולים ושינוי קטן?

• (דניאל) אז קודם כל, אם ממש-ממש רוצים, רוב השפות ייתנו איזשהו Escape Patch - בין אם הוא יותר Escape-י או פחות Escape-י, שמאפשר אולי אפילו לעשות משהו Mutable.
• אבל אם לא, אז יש פה איזשהו Trade-off: קודם כל, להשוות מבנה נתונים Mutable למבנה נתונים Immutable, זה השוואה של “תפוחים ותפוזים”.
• כי למבנה Immutable יש “כוח-על”, במירכאות - שגרסאות-העבר שלו נשמרות, וזה אומר שאני יכול להמשיך להשתמש בהן.
• זאת אומרת שיש לי “Snapshot-ים חינם” לאורך כל השינויים שלי.
• אז להשוות אותו אחד לאחד ל-Mutable-Immutable זה כבר קצת מסתיר מאיתנו חלק מהיתרונות.
• אבל אם אני רגע אפילו מתעלם מזה - יש, ברגע שאני נכנס לעולם של Immutable, אני כן צריך לחשוב מחדש על ביצועים והעלויות האסימפטוטיות של כל דבר שאני עושה.
• ויש שני דברים, שתי תשובות מרכזיות - 
• אחת - להתחכם במבנה נתונים: אז במקום לעבוד עם מערך שהוא Immutable, עובדים עם איזה עץ, עם איזה פיצול 32 שעושה משהו שהוא לוגריתמי ולא O(1), אבל לכל או להרבה צרכים פרקטיים מאוד מאוד מהיר.
• זה מצד אחד.
• ומצד שני, יש אספקט אחר של Immutable או Purity, וזה שאפשר לעשות Sharing, כן?
• אם יש לי חתיכה של מבנה-נתונים שלא השתנתה בין לבין, אז אין שום בעיה לשתף אותה בין כל העותקים השונים.
• ופה אני חוסך על אלוקציה (Allocation), GC, ועוד מלא דברים אחרים שברקע יכולים להיות בעייתיים.
• ואז, אולי, לקבל חזרה חלק ממה שאיבדתי.
• פרקטית, אם אני כותב איזה Backend שרובו חי על Database-ים ותקשורת-רשת, כנראה שזה לא הדבר שיעסיק אותי.
• פרקטית, הניסיון שלי עם נגיד Scala - עבדתי בשרת, מבנה נתונים -  רוב הזמן זה לא היה.
• היו מקרים, אגב, אבל רוב הזמן, המבנה נתונים זה לא מה שעיכב אותי בחיים, כי שתי התכונות האלה כנראה מפצות על הפערי ביצועים.
• (רן) כן.

[12:08] העדפות לגבי Typing
(רן) תכונה נוספת שאני חושב שמאוד מאפיינת, אולי אפילו מבדילה, בין שפות פונקציונליות שונות, זה Typing, משמע - Strong Typing versus No Typing, או Weak Typing.אז נגיד שפות כמו JavaScript - לפחות הגרסאות הראשונות היו ללא Typing, שפות כמו Clojure ו-Lisp - אין להן Typing. לעומת זאת, שפות כמו ML, הזכרת את Scala, הזכרת את Rust - יש להן Typing מאוד מאוד חזק.איפה אתה? איפה העדפות שלך? 

• (דניאל) אז אני חד משמעית “מכור ל-Type-ים” . . . . אני מתקשה לדמיין את עצמי חוזר חזרה לעולם הדינמי.
• כי אני חושב שהשריר הזה שמצליח להחזיק את כל ה-Context מסביב כשהשפה דינמית הלך והתנוון עם השנים, כי אני פשוט הפסקתי להשתמש בו . . . .
• ה-Complier כל הזמן מלווה אותי, הוא החבר הכי טוב שלי - וככה אני מתייחס אליו.
• הוא החבר הכי טוב שלי - אני צריך לטפח אותו, לעזור לו, לא לשקר לו . . . . יש לנו הרבה דברים שכדאי לעשות עם חברים טובים.
• (דניאל) אז אני חד-משמעית הולך לכיוון ה-Type-ים - בעיקר כי לי זה מרגיש נוח.
•  זה מאפשר לי לחשוב ברמה High-Level-ית  על הקוד שלי, בלי להיכנס לפרטים בצורה שהיא לא קשקוש על הלוח, אלא ממש דברים שאני יכול אחרי זה להתחיל לקמפל (Compile) ולעקוב אחרי התוצאות שלו.
• אז אני כן יותר אוהב לעבוד בעולם של Type-ים - Scala זו מן הסתם שפה שהיא Typed, ולא במקרה נשארתי איתה.
• אבל אני חושב שהרבה מהיתרונות של תכנות פונקציונלי אפשר גם להוציא גם ללא Type-ים - אבל שוב, אני אישית חד משמעית על ה-Type-ים.

[13:36] אז למה?
(רן) אוקיי, אז בוא נחזור רגע - עשינו איזשהו מעבר קצר, ובוא נחזור ל”למה?” אז אמרת והזכרת דברים כמו Testability ו-Maintainability וכו’ . . . 

• (דניאל) כן, אז דבר שני שאני חושב שהוא אמור להיות מאוד אינטואיטיבי לרוב האנשים שאי פעם נגעו בקוד, זה מושג שקוראים לו “Spooky action at a distance”
• מושג שהגיע אי-שם מפיזיקה, איפשהו אינשטיין זרק איזה משהו [יש מצב שזה ה-TL;DR ל-Quantum Entanglement הכי חזק אי פעם . . . .], אבל...

(רן) . . . .Spooky action at a distance? . . . 

• (דניאל) At a Distance, כן. אז זה סופר-אינטואיטיבי . . . . כאילו, מילים גדולות כאלה, אבל זה דבר מאוד אינטואיטיבי.
• דמיינו: אני כותב קוד - כמה זמן - “פיפס! משהו נשבר שם” - מקום לא קשור, “מה אני קשור?!”
• (רן) הפרפר, “משק כנפי-הפרפר” . . . .
• (דניאל) כן, בדיוק.
• אז ה-Spooky Action פה זה שכאילו עשיתי משהו, לא ידעתי על מה השפעתי - ומשהו במרחק גדול מהקוד שלי הלך ונשבר.
• אז אם אני מתחיל להסתכל מה הסיבות לדברים כאלה בקוד, אז הרבה פעמים הסיבות יהיו דברים כמו Side-Effect-ים:
• יש לי משתנה Mutable-י שהשתנה פה, ואז הוא השפיע על משהו שם - ואיזו שרשרת של דברים Mutable-יים שקרו ברקע.
• או שכתבתי משהו לאיזה Database וקראתי אותו במקום אחר, וכדומה.
• עכשיו, Database-ים - אולי חבל שנגעתי בהם, אני לא רוצה ללכת ולהגיד מה אני עושה מול Database, אבל יכול להיות פחות משתנים, או דברים כאלה שהם Side-Effect-ים שאני עושה בתוך הקוד שלי, וזה משהו שתכנון פונקציונלי מנסה להסתיר מאיתנו.
• אז אם אני עובד עם פונקציות טהורות, עם קלט ופלט, אחד הדברים שאני לא עושה זה משנה משתנים - כי זה לא חלק מהקלט ופלט.
• בעצם, פונקציה שעושה Side-Effect-ים, יש לה כאילו ערוץ תקשורת נוסף, שהוא כזה בלתי נראה, שהולך וברקע עושה כל מיני דברים.
• אז התופעה הזאת - Spooky Action at a Distance - זה משהו שאני בטוח שכל מי שנתקל בו לא רוצה שזה יקרה.
• זה כאילו סבל כזה של “אני מפחד לגעת בקוד, כי אין לי מושג איפה הוא ישפיע בהמשך”.
• ותכנון פונקציונלי לא מסיר את זה לחלוטין, וכמובן שבסוף גם שם יש באגים - אבל לדעתי אם אני עובר למצב שבו אני Immutable ומפסיק להשתמש במשתנים, אז לא יודע מה, 80% מה-Spooky Action at a Distance הביזאריים וכל מיני Race Conditions מוזרים ולא יודע מה, פשוט נעלמים.

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

• (דניאל) בהקשר של קוונטים וחוסר לוקאליות של אינטראקציה בין דברים . . . 

(רן) הוא לא אהב את הקוונטים, איינשטיין . . . 

• (דניאל) הוא כנראה קצת ראה קדימה, מבחינת מה שהוא דיבר עליו. אבל כן, היה שם איזה קונפליקט לגבי מה אנחנו חווים לעומת מה שיש.
• אבל שם זה גם, זה כאילו משהו שמאוד הפריע רעיונית - אנחנו חושבים על דברים, אנחנו עושים פעולות פה - ואנחנו מצפים ששם לא יקרה כלום. זה מוזר . . . 
• אז כמתכנתים, אני חושב שאנחנו חווים את זה על ימין ועל שמאל.
• ותכנון פונקציונלי לוקח ומצמצם את זה משמעותית.
• כאילו Immutability פלוס ”להפסיק להשתמש ב-Var”, וכבר אתם במצב הרבה הרבה יותר טוב.
• וזה מבחינתי סיבה מספר 2, או אפילו 1, ללכת לכיוון הזה.
• וסיבה מספר 3, שאולי אפילו מעניין להסתכל על זה מחדש, אולי אני אשים את זה מספר 1 - זה תכל’ס כיף . . . .
• כי אני מצאתי את עצמי כשהגעתי לעולם הזה, אז הייתי כותב Java, וזה היה כזה מאוד וורבוזי (Verbose) ועם מלא מלל על דברים מאוד פשוטים.
• אז התחלתי ללמוד לחשוב פונקציונלית וללמוד על פונקציות כמו Map ו-Filter וכדומה - וב-Java זה עוד לא היה משהו מובנה, היו כל מיני ספריות-צד-ג', אבל לא היו פונקציות אנונימיות.
• אז מצאתי את עצמי שהקוד שאני כותב שם, ושלוקח לי “קילומטרים של טקסט” לכתוב, פתאום זה נהיה כזה קליל וכיפי ואלגנטי.
• וגם תחום פונקציונלי הרבה פעמים נוטה להיות מה שנקרא דקלרטיבי (Declarative) - אני מצהיר יותר “מה” אני רוצה לעומת “איך”.
• אני לא מדבר על הצעדים הקטנים של “איך” לעשות כל פקודה, אלא אני אומר “אני רוצה בגדול את הדבר הזה”, ולא נכנס לפרטים.
• והרבה פעמים התיאור של “מה” הוא הרבה יותר פשוט, הרבה יותר קריא, הרבה יותר נוח להבין, מאשר התיאור של צעדים, איך צעד אחר צעד לעשות דברים.
• ואם נגיד אני מסתכל על לולאות For לעומת Map, אין להשוות - הקוד הזה בעיניי הרבה יותר קריא, הרבה יותר כיף לעבוד איתו.
• ואז לאט לאט, ככל שמתקדמים בעולם הזה, אז במיוחד אם זה הולך עם Type-ים וכדומה, פתאום העולם מתחיל להיראות כמו איזה חתיכות לגו.
• זה כזה “אני מחפש את האבני-לגו הנכונות”, ואז אני מקליק אותן - ופתאום הכול פשוט נבנה מעצמו לאט -לאט.

[17:42] פרקליט השטן (הפונקציונלי)
(רן) פה אני רוצה רגע לשחק את פרקליט השטן - אני חושב שזה Skill שצריך לבנות. זאת אומרת - היכולת לבוא ולראות את “הלגו” הזה, היכולת לראות את המודולריות הזאת, היכולת לבוא ולקרוא קוד שמכיל Map-יםו-Filter-ים וכו', ולהבין היטב מה הוא עושה - זה Skill שצריך לפתח, ואני חושב שזה יכול להיות מאוד מאתגר.זאת אומרת, הניסיון שלי - גם לי אישית, וגם יצא לי לעבוד בחברות שבהן יש קוד די משמעותי שהוא פונקציונלי -זה Skill שלהרבה מפתחים קשה לפתח.עכשיו, יכול להיות, אפשר לבוא ולטעון, שזה בגלל הדרך שבה למדנו מדעי המחשב, בגלל הדרך שבה יש הרבה שפות אחרות שכתובות. זאת אומרת, מאוד יכול להיות שזה איכשהו “ככה האנושות לקחה אותנו לשם”, אולי.אבל אני כן חושב שזה מצב נתון - לטעמי האישי, ללא מחקר אקדמי - שלמפתחים יותר קל עם קוד אימפרטיבי (Imperative), יותר קל להבין קוד אימפרטיבי, מקוד פונקציונלי, אף על פי שהוא יותר קצר בדרך כלל, ואני מסכים איתך שהוא באמת נראה יותר אלגנטי. אני חושב שהוא מחביא בתוכו הרבה הבנה שהיא Implicit, שזה Skill שצריך לפתח - ולא לכולם יש אותו.

• (דניאל) אני לא מתווכח עם זה - בגלל זה בא לי להציע סדנאות לאנשים, שמישהו יבוא ויביא אותי ויעזור לי ללמד את זה.
• ואני גם חוויתי את זה שכשאני מלמד אנשים, ולפעמים לוקח זמן קצת למחוק את התפיסות שהם הגיעו איתן מניסיון קודם, ולהמיר אותן למשהו שהוא יותר מתאים לזה.
• אבל - ואני מסכים, חד משמעית -אם אני מוציא עכשיו, מוציא סטודנט מהאוניברסיטה, שם אותו מול מסך, סביר להניח . . . 
• יצא לי לא מזמן להיות מתרגל בקורס של hasql באוניברסיטה - והסטודנטים היו בשוק.
• זה היה שנה ג', ולא היה להם מושג על מה נפלתי עליהם - והם סבלו, כולם . . . 
• חד משמעית יש את זה גם עם אנשים יותר מנוסים.
• זה מצד אחד.
• מצד שני, אני חושב שיש פה איזושהי אשליה מסוימת - אז נכון שלמדתי לקרוא יותר, אולי אני יותר מורגל לקרוא לולאות, לראות צעד-צעד ולעקוב אחרי משתנים [הי בגרות במדמ”ח ב-2000!] - אבל זה מאוד לא סקיילבילי (Saleable).
• אני יכול להסתכל על עשר שורות קוד, להבין בדיוק מה שקורה שם בכל המשתנים.
• ויותר מזה, אני יכול להגיד שגם בתכנות פונקציונלי, לפעמים אנחנו נחביא מאחורי ממשק “טהור” משהו שהוא, מטעמי ביצועים, עוד משהו עם טיפה משתנים, בסדר.
• אבל אם אנחנו עושים לזה Scale-out - בונים קוד יותר ויותר גדול - אז כל “התלויות הבלתי נראות האלה”, כל המשתנים וכל הדברים שקורים באופן בלתי נראה, הם דברים שהולכים וגדלים.
• כמו שאם לפני כמה עשורים מישהו היה אומר “אבל Go-To! - אנשים יודעים לקרוא Go-To יותר טוב!”
• ואז הייתם כאילו אומרים “נכון, אבל Go-To מכניס מלא בלאגן . . . “.
• אז באותה צורה אני רואה תכנות אימפרטיבי (Imperative) - לא באופן גורף, לא במאה אחוז, אבל הרבה פעמים לאט לאט בונה לנו תלויות בלתי נראות בתוך הקוד, כך שהאנתרופיה של הקוד גדלה עם הזמן.
• ותכנות פונקציונלי, לדעתי, בולם את זה.
• עכשיו, יש פה מחיר - יש פה מחיר של ללמוד, להבין, להכיר את הקונספטים החדשים.
• אבל חוץ מזה שהוא בולם את זה - אני חושב שהוא גם פותח דלתות חדשות, כן? מאפשר לכתוב קוד שהוא עושה דברים יותר סתם . . . .
• נגיד, פתאום מקביליות נהית עולם אחר לחלוטין, שאולי אפילו יותר קל - במובנים מסויימים - לנהל, מאשר עם משתנים.
• ומנעולים, ו-Deadlocks, ולא יודע מה . . . .

(רן) לא ניכנס שם לעומק, אבל אם יש State משותף, מאוד קשה לנהל מקביליות. אם אין State - דיברנו על פונקציות טהורות - אם אין State, אז יותר קל. (אורי) אבל בסוף ה-State הוא העולם שאנחנו רוצים לשנות, שהקוד שלנו ישנה . . . . זה נחמד מאוד להיות “טהור” [היי וולדמורט], אבל אתה צריך להזיז משהו בעולם.(רן) כן, אבל פה - סליחה, אני אנסה לענות בשמך, דניאל, ואתה תתקן אותי - אני חושב שהחוכמה זה לדעת להבדיל בין קוד טהור לקוד לא-טהור. זאת אומרת, לשים את הדברים המסובכים במקום אחד - ואת הדברים הפשוטים יותר במקום אחר, וככה יותר קל לשלוט ב-Blast Radius, או מה שקראת לזה “Spooky Action at a Distance”, . . . .

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

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

• (דניאל) כן, אבל אני מכיר בזה שעולם התוכנה לרוב רוצה גם תוצרים שבאמת עושים משהו, ובסוף באמת הסוד הוא איך לחלק את הדברים לכאלה שאני יכול לשלוט עליהם כך לבין דברים שאני לא יכול.
• ובסוף, לרוב בכל עולם של תכנון פונקציונלי שאני אנסה להיכנס אליו ברצינות, תיהיה בסוף איזשהו דרך לנהל State.
• אז זה לא משהו שאני משמיד אותו - אבל אני הופך אותו למנוהל, אני הופך אותו ליותר Explicit, אני הופך אותו למשהו שיותר קל לעקוב אחריו.
• בין אם זה עם Type-ים ובין אם זה מבחינת ה-Flow של הקוד.
• והרבה פעמים מגיעים נגיד ל-Design שקוראים לו Imperative Shell - Functional Core.
• אז אני באמצע - הליבה, ה-Business Logic שלי, הדברים שמאוד חשוב שנכתוב עליהם טסטים ושהגיוני שזה יהיה קל - אז הם יהיו בסגנון הפונקציונלי.
• וכל זה יהיה מחובר למעטפת קלילה יחסית, בתקווה כמה שיותר קטנה, שהיא התקשורת עם העולם החיצון - Database-ים וכדומה - שהם מזינים את הליבה הפונקציונלית.
• אז כן, ברור שאנחנו לא נשמיד Side-Effect-ים לחלוטין, אבל אנחנו נמצא דרכים לנהל אותם בצורה יותר מסודרת, וזה מבחינתי הדרך באמת למקסם את התועלת מתכנות פונקציונלי, ואשכרה לעשות משהו מועיל למישהו.

[23:01] פיל בחדר של אינטליגנציה מלאכותית / מי עוזר למי?
(רן) סבבה, אז דיברנו על מספר יתרונות של תכנות פונקציונלי, וגם אמרנו ש... זאת אומרת, לא חייבים להיות All-in - זה נמצא בהרבה מאוד שפות שהן סופר-Mainstream היום, הזכרנו Java ו-Python ו-JavaScript, you name it - אבל לא דיברנו על AI [משחק שתייה?].ועכשיו, השאלה היא . . . . הרגע שאורי חיכה לו, כן - השאלה: האם אתה רואה פה יחסי גומלין או אדישותבין תכנות פונקציונלי ל-AI? או במילים אחרות, האם פונקציונלי עוזר ל-AI? האם AI עוזר לפונקציונלי? או שהם פשוט אדישים אחד לשני? 

• (דניאל) אז אני חושב. . . .  אני לוקח את זה לכיוון של “פונקציונלי עוזר ל-AI”.
• לא מזמן אפילו הוצאתי קליפ ל-YouTube לראשונה, בניסיון להדגיש את הנקודה הזאת [Make Illegal AI Edits Unrepresentable - YouTube].
• חד-משמעית עוזר - ולא רק כי זה נוח לי מטעמי מכירות, אלא בצורה מאוד קונקרטית.
• אם אני הולך לכיוון של תכנות פונקציונלי עם Type-ים, שבעצם אם נפתח את זה יותר טכנית, אז נראה שבעצם יותר תכנות פונקציונלי הופך את ה-Type-ים ליותר “מלאים” - תיאוריים, יותר מרחיבים מה שקורה במציאות.
• לצורך העניין, אם לפני זה דיברנו על חתימה של “מקבלת כלום - מחזירה Void”, בתכנון פונקציונלי זו לא תהיה חתימה כזאת - היא תהיה חתימה עם input, Output ומשהו באמצע.
• אז ברגע שיש לי את הדבר הזה, אני בעצם מערב את ה-Complier פנימה - ה-Complier נהיה משהו הרבה יותר חזק.
• עכשיו, אם נסתכל על AI - או על בני אדם לצורך העניין, ו-AI הם פשוט, נכון לכרגע, גרסה קצת מוזרה של בני אדם: גם חכמים יותר, גם טיפשים יותר, איכשהו בו-זמנית - אז אם נסתכל על AI . . . 

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

• (דניאל) כן, גם בני אדם, כמו בני אדם, כן . . .  אז אם נסתכל על איך שה-AI או בני אדם מסתכלים על קוד, אז אנחנו לרוב מסתכלים בצורה מאוד מאוד מקומית.
• יש לנו איזשהו Scope כזה של כמה שורות קוד, אנחנו מבינים מה קורה שם פלוס-מינוס, ומעבר לזה, כאילו, כן - אנחנו יכולים להחזיק עוד את כל ה-Class, שלושה Calss-ים, אולי אני עבדתי על הפיצ'ר איזה שבוע אז אני יודע טיפה יותר.
• אבל בסוף יש איזשהו תחום סופי שבו אני מסוגל להחזיק ידע.
• וכך גם ה-AI - החלונות שלהם גדלים, אבל בסוף הם סופיים.
• כשאני מסתכל על Codebase גדול, אז באיזשהו שלב, אם יש לי איזה Invariant או משהו בקוד שצריך להיאכף לאורך כל הקוד, שהוא יותר גדול מה-Scope שה-AI מצליח לתפוס, אז אני אהיה בברוך.
• כי ה-AI יעשה את מה שהוא עושה - נגיד שהוא עשה את זה טוב - אז יעשה מה שהוא עושה בתוך ה-Scope הקטן הזה, אבל אז הוא שבר את האינווריאנטה (Invariant) שם בפינה של הקוד.
• מצד שני, אם אני הלכתי לכיוון התכנות הפונקציונלי, אם מקסמתי את היכולת של ה-Complier . . . .

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

• (דניאל) כן, לחלון ה-Context . . . . אז אם הלכתי לכיוון של פונקציונלי, הלכתי יותר All-in על ה-Complier שיעזור לי.
• אז ה-Complier, להבדיל מבני אדם או AI, מסתכל ב-Scope גלובלי.
• אם יש לי איזושהו Variant או משהו שקודדתי בצורה של Type -ים, הוא יאכוף את זה על כל הקוד, לאורך כל ה-Codebase כולו.
• ואז אם ה-AI שבר לי משהו פה, ה-Complier יכול להגיד “אה, שם גם נשבר משהו!" - וזה מבחינתי משהו מאוד מאוד משלים.
• גם לבני אדם - מבחינתי זה טכניקות שהיו רלוונטיות לבני אדם עשורים.
• וגם עכשיו עוד יותר ל-AI - כי AI זה פשוט מייצר לנו עוד ועוד קוד, והרבה יותר קשה לעקוב אחרי זה, אז...

(רן) כן, אבל אני אהיה קטנוני ואני אגיד שאתה מדבר על Complier ועל Typing - אבל אתה לא אומר “פונקציונלי”.כלומר, יש שפות פונקציונליות שהן לא Typed, יש שפות שהן אימפרטיביות (Imperative), שהן Strongly-Typed,זה לא אותו דבר.

• (דניאל) נכון, זה לא אותו דבר. אז תפסת אותי על . . . אני כזה עושה קצת סוויץ' בין שני הנושאים.
• אז קודם כל, אני באמת נוטה לכיוון של ה-Typed, אבל זה עובד בשני הכיוונים.
• א' - ה-Spooky Action at a Distance רלוונטי גם בעולם דינמי.
• אם ה-Python או ה-JavaScript שלי כתובים בצורה שיש הרבה פחות השלכות בלתי-נראות ברחבי הקוד, אז הסיכוי שה-AI ישבש לי משהו על ידי איזשהו Shift פה, ישבש משהו שם - יותר נמוך.
• ומצד שני, אני באמת מעדיף לעבוד בצורה שהיא Typed - והקשר בין זה לתכנון פונקציונלי זה שתכנון פונקציונלי, בגלל שהוא מכריח אותי להיות מאוד Explicit לגבי מה שאני עושה, הוא בין השאר הופך את ה-Type-ים שלי ליותר Explicit.
• עכשיו, אני לא חייב, ואני יכול לעבוד עם Type-ים פרימיטיביים יחסית ועדיין להיחשב לפונקציונלי על הנייר.
• אבל פה הייתי מוסיף עוד איזה עיקרון משלים, שזה משהו שמאוד פופולרי בעולם של תכנון פונקציונלי, אבל הוא לא מחויב לשם, וזה עיקרון שקוראים לו “Make your legal states unrepresentable”.
• המגמה של לנסות לקחת כל מיני Variant-ות בקוד ולקודד כ-Type-ים.
• ואז זה נכון שאפשר לעשות את זה מחוץ לתכנון פונקציונלי - אבל פרקטית, תרבותית, זה הרבה יותר מושרש בעולם של תכנון פונקציונלי.
• לרוב ה-Type System של שפות פונקציונליות הן יותר גמישות ויותר מתאימות לפרדיגמה הזאת של make your legal states . . . .

(רן) (רן) בוא רגע נגיד . . . . ניתן דוגמה למה זה “Make your legal states unrepresentable”: נגיד יש לך Class שיש בו משתנה, סליחה שאני בערך לא אירופי, אם המשתנה הזה אסור שיהיה NULL, אז אתה חייב לאתחל אותו ב-Constructor, נכון? אסור לעשות לו Set. אז זאת אומרת שאם ה-Class הזה קיים, אז המשתנה הזה יש לו ערך. אם הוא לא קיים, אז זה בסדר.(אורי) נראה לי שהתייחסתם ל-AI כמשהו שעוזר לנו בכתיבה - של שפות כאלה ושפות כאלה - אני רוצה להתייחס לשאלה של “אוקיי, נניח שאנחנו כותבים מערכת Agent או משהו שמשחק בעולם של AI, שהוא עולם פחות צפוי ב-Inputs וב-Outputs שלו, האם עבודה בשפה פונקציונלית תעזור לנו פה? מבחינת, למשל, Testing? דיברת על זה בהתחלה - Testing הוא יותר קל כי אני יכול לדעת מה Input, מה ה-Output וכאלה, אבל פתאום יש לי עולם אחר,שהוא פחות צפוי, כשאני עובד מול LLM.

• (דניאל) אז שוב - גם לפני LLM-ים העולם היה לא צפוי . . . . יש לי Database, יש תקשורת-רשת, יש לי Timeout-ים, דברים מפה ועד להודעה חדשה שאני לא צופה אותם.
• וזה קיים וזה לא נעלם משום מקום בין כה וכה.
• השאלה היא איך אני מגדר את העולם שבו אני רוצה להבין דברים.
• אז אוקיי, LLM עשה משהו - הוציא לי פלט.
• הפלט הזה זה פיסת-דאטה - אני יכול לפרמל מה אני מצפה שיהיה בדאטה הזה.
• ומשם והלאה אני יכול להמשיך בגישה הפונקציונלית - לאסוף טרנזקציות ועוד ועוד, ואז להחזיר את זה חזרה “אל הלא נודע של ה-LLM” או מי שזה לא יהיה [סנדרסון?]
• השאלה זה לא כמה לא נודע יש לי בחוץ, אלא כמה מתוך זה אני יכול למסגר בשביל לעבוד איתו.
• עכשיו, האם ה-Agent עושה “הכל מהכל”, וכל Input הוציא כל Output והוא החליף אותי? אוקיי, אז אני לא יודע.
• אני מקווה שה-Agent-ים יום אחד יגלו תכנות פונקציונלי בעצמם ויחליטו לעבוד ככה.
• אבל מבחינתי, כל עוד אני עדיין צריך להבין מה קורה בקוד, ואני רוצה שגם מי שעובד על הקוד, כולל AI, יצליח להבין מה קורה בו, הייתי רוצה למסגר כמה שיותר מהקוד שלי ולהפריד אותו מהבלגן.
• אז יש את “התוהו ובוהו שקורה מחוץ ל-Scope שלי” - ויש את הסדר שאני מנסה להתוות בתוך הקוד שאני שולט עליו.
• שם אני אנסה להיות פונקציונלי.
• אז כמה יש בלגן בחוץ וכמה LLM-ים יותר או פחות צפויים? מבחינתי זה כאילו לא משנה את הפרדיגמה של איך שאני מנסה לנהל את הקוד שאני כותב בעצמי

(רן) אני יכול דרך אגב, אורי, לענות לך דווקא מהעולם שבו אני נמצא, ושבו אני בין השאר גם עובד על איך בודקים Agent-ים - הזכרת Agent. איך יודעים שה-Agent עושה את הדבר הנכון? איך יודעים שהוא קרא לפונקציה הנכונה? איך יודעים שהוא העביר לה את הפרמטרים הנכונים וכו'?עכשיו - זה אתגר, כן? זה אתגר שקיים בעולם ויש לזה כל מיני גישות.בגדול יש שתי גישות בולטות, שהן אחד - זה להסתכל על לאיזה פונקציות הוא קורא, ואם הוא קרא לפונקציות הנכונות והעביר להן את הפרמטרים הנכונים, אז הוא בסדר. נקרא לזה “הגישה הפונקציונלית".הגישה השנייה היא להסתכל על ה-Database. זאת אומרת, פשוט לא להסתכל על לאיזה פונקציות הוא קרא, אלא להסתכל על ה-Database ולבדוק מה ה-State לפני ומה ה-State אחרי. נגיד, אמרתי לו “תזמין לי טיסה” - אם בסוף הטיסה הוזמנה אז ה-State הוא בסדר.עכשיו, הגישה של להסתכל על ה-Database היא הרבה יותר מורכבת. למה? כי צריך לסמלץ (Simulate) את ה-Database, צריך לעשות פה הרבה יותר חיווטים - וגם בחיווטים האלה כמובן יכולים להיות באגים - אבל צריך לעשות פה הרבה הרבה יותר חיווטים, צריך לעשות הרבה יותר מאמצים כדי לבדוק את השיטה האימפרטיבית (Imperative) הזאת, מאשר לבדוק את השיטה הפונקציונלית. [Lenny’s Podcast - Building eval systems that improve your AI product]אז בהקשר הזה אני חושב שכן - זאת אומרת, לעשות נגיד ולידציה (Validation) ל-Agent-ים תחת הנחות פונקציונליות זה הרבה יותר פשוט מאשר תחת הנחות אימפרטיביות (Imperative).אז כן - אפילו מהאספקט הזה, תכנון פונקציונלי הוא משהו שיותר קל לעבודה איתו, אוקיי? כי יש, נקרא לזה “חוזים”, אוקיי? חוזים - ואנחנו מבקשים מה-Agent לעמוד ב... “לממש” את החוזים האלה.

[31:45] סדנאות לסיכום
(רן) אז זהו, אנחנו כבר ממש מגיעים לקראת הסוף. ואמרת, הזכרת שאתה קצת - שאתה מלמד, שאתה עושה סדנאות, אז אולי כמה מילים על זה?

• (דניאל) אז בגדול, אני הייתי רוצה לקחת את מיטב העקרונות שאפשר להפיק מהעולם הזה של תכנון פונקציונלי - זרקתי כמה Buzz-words כאלה, כמו “Spooky Action at a Distance” ו“Make your legal states unrepresentable”, ולהפוך אותם לסדנה שזמינה לאנשים שעובדים בכל שפת תוכנה שהיא, בגדול - עד כדי C, שבאמת אמרנו ששם לא יהיה הרבה מה לתרום לצערי.
• אז הסדנה היא שאני לוקח איזשהו Syllabus כזה שבגדול מה-Basics של מה זה תכנון פונקציונלי ועד יישומים שהם או Design או ארכיטקטורה ומנסה להתאים אותם לקהל היעד שרוצה להשתתף בסדנה ולהפוך את זה למשהו שאפשר לקחת באמת פרקטית ליומיום.
• זאת אומרת, כבר היום אני יכול להגיד הנה - “קח תעיף את כל ה-Var-ים מהקוד שלך, תראה מה יקרה”, כן? 
• צעדים כאלה, מאוד, כביכול, קטנים ופשוטים - אבל פתאום ההשלכות מרחיקות לכת.
• גם אם אני לא עושה את זה ממש תכל'ס עכשיו, אני יכול לחשוב מה ההשלכות.
• אז אני רוצה להפוך את זה לסדנה ולהנגיש את זה “להמונים” - לכל מי שבעצם גם לא נגע בתכנון פונקציונלי או שהסתקרן או כדומה.
• וזה לא חייב להיות שפה כמו Scala או hasql או דומיהן, שהן מאוד נישתיות, אלא אפשר לעשות את זה ב-Python.
• אני אישית, כמו שאמרתי, מעדיף Types - אבל גם איכשהו Typing מגיע יחסית פנימה לכל השפות העולם.
• אז Python, Java, TypeScript, JavaScript והכול.
• ובעצם לקחת את העקרונות האלה ולהנגיש אותם לכולם.
• ואשמח אם יפנו אליי [הנה, כאן - The Functional Edge for Modern Software Engineers

 (רן) אוקיי, ואם מחפשים אותך, פשוט לחפש “דניאל בסקין”?

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

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

פרק מספר 503 של רברס עם פלטפורמה - באמפרס מספר 88, שהוקלט באוקטובר 2025, רגע לפני כנס רברסים 2025: רן, דותן ואלון באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט ודברים שפגשנו בחודש ומשהו האחרונים - פרוייקטים בקוד פתוח, הכרזות מעניינות, בלוגים מעניינים, דברים מ- GitHub, דוחות וספריות וכל מיני דברים מעניינים (והפעם - במה רק של דותן ואלון!) 🎗️

[00:32 - אלון]
(רן) אז קדימה, בואו נתחיל בספונטני - מי רוצה ראשון?(אלון) בוקר טוב, איזה כיף - בית בלי הורים היום . . .  מה זה? דותן, אפשר להתפרע!(רן) יאללה, לך על זה אלון - אייטם ראשון.  

• (אלון) אני אתחיל מאייטם ראשון, שהכינותי מראש - בקיצור, Python - מכירים? אז הנחש הזה הוא גם שפת תוכנה, מסתבר.
• (אלון)  אז בגרסה 3.14 של Python סוף סוף שחררו לנו את ה-GIL - שמה שזה אומר זה שאפשר לעבוד ב-Python ב-Multi-Threading!
• (רן) הופה! Multi-Threading ב-Python!
• (אלון) Multi-Threading ב-Python - אחרית הימים, הגענו לשנות התשעים.
• (רן) כן . . . בוא נסביר, שנייה - GIL זה ראשי תיבות של Global Interpreter Lock.
• זה איזשהו “מנעול” שיש על ה-Interpreter של השפה, כי השפה היא עצמה היא “מאינטרפרטרת”, אם אפשר לומר כך [עדיף שלא…]
• בכל אופן, זה יוצר בעיה במקביליות - זאת אומרת, זה יוצר צוואר-בקבוק ב-CPU
•  כל עוד יש לך Thread אחד, הצוואר-בקבוק הזה הוא סבבה, הוא לא מפריע; ברגע שיש יותר מ-Thread אחד, זה יכול להשפיע.
• יכול להשפיע לרעה, בעיקר בדברים שהם CPU-bound.
• ויש כל מיני Workarounds לזה, ב-Python, כן? - Workaround אחד זה פשוט להריץ דברים ב-C . . .
• דברים שדורשים הרבה מקביליות, אז להריץ אותם ב-C.
• אז לא עשינו בזה הרבה, כי צריך אז לכתוב ב-C . . .
• ו-Workaround אחר זה לעשות את זה ב-Multi-Processing - אבל אז אתם מריצים הרבה Processing, וגם זה נורא בזבזני מבחינת משאבים.
• ו-Workaround נוסף זה לעשות async - דברים ב-async, שלפעמים זה קצת עוזר, אבל לא תמיד זה מאוד עוזר  . . . 
• אבל זה גם קצת מעיק.
• והאשם בכל זה זה ה-GIL, כמו שאמרנו.
• (אלון)  גיל לא פה, למה אתה מאשים אותו?
• (דותן) רגע, אני לא מאמין . . . .
• (אלון) אוקיי, זכותך . . .
• (רן) . . . אתה יכול להישאר סקפטי . . . 
• (דותן) . . . . בכל מה שקשור ל-Python, יש כמה דברים שגורמים לי לחשוד . . .
• אחד, יש עדכון גרסה מינימלי, יש 3.13 ו-3.14 - וב-3.14, פתאום אפשר לרוץ “חופשי על הבר”.
• (רן)  ב-3.13 זה ניסיוני, דרך אגב . . . ב-3.14 זה כבר - אני לא יודע אם הוא Default-י, אבל לפני . . .
• (דותן) הייתי מצפה שזה יהיה Python 4, לצורך העניין - זה היה כזה מטורף . . .
• (אלון)  די, די . . .  מה ארבע? הם צריכים לשבור . . . 
• קודם כל, Python - הם גרועים.
• כמה שנים לקח לעבור מ-Python 2 ל-3? איזה 20 שנה, לא יודע.
• בקיצור, הם לא יכולים לעבור.
• קודם כל, אם זה לא Breaking Change, למה לשים Major? זה אחד.
• ושתיים - הם ממש יפחידו את הקהל שלהם, שגם ככה פוחד ומפחד ממיגרציה (Migration).
• אז יעשו לו “בקטנה” כזה . . . 
• (דותן) אתה אומר שהם מחליקים שבירה מתחת לזה? 
• (אלון)  אבל זה לא שובר . . .
• (רן)  זה לא שובר . . .  זאת אומרת, לפחות אנחנו מקווים שזה לא שובר . . .
• (דותן) אם מנתקים את ה-GIL, ומריצים את כל הקוד שיש בעולם עכשיו בחוץ - אתה חושב שהוא לא יישבר, כל הקוד הזה?
• (אלון)  בתיאוריה, זה פשוט גרם ל... הוא לא GIL, הוא פשוט לא צריך את ה-Lock.
• פתרו את בעיית ה-Locking . . .
• (רן)  כן, זה כמו להריץ משחקים - זה כמו שפעם הרצת משחקים, והיה לך כפתור שהיה צריך ושהיה יכול להאט אותם, כי המעבדים התחילו להיות מהירים מדי.
• (רן)  אז כן, אולי דברים לוגית יישברו, אבל לא אמורים, לפחות . . . 
•  (דותן) אני בטוח שיש קוד בחוץ שסמך על ה-GIL . . . . קוד, שבעצם סומך על זה שאין פה Concurrency אמיתי, ושעכשיו צריך לתקן אותו.
• (רן)  זה Fair Enough - אבל בעיה של מי זה? של המפתחים או של הפלטפורמה? של הפלטפורמה של Python, או של ה...
• (דותן) תשמע, אני לא יודע - שאלה טובה.
• כי אם עכשיו אתה 80% מה-Open Source Libraries הן ככה, וה-Standard Library שלך - אתה תיקנת אותו, אבל הוא מהווה אחוז קטן מהסיפור.
• והקהילה, De-Facto, מסתמכת על Standard Libraries, שהוא ספריות Open Source
• אז מה תעשה? זה אשמתך או אשמת ה... מה תעשה?
• (רן)  לא, אבל מצד שני, כמו שאלון אמר - לקח 10 שנים לעלות מ-Python 2 ל-Python 3. אתה רוצה עכשיו עוד 10 שנים מ-3 ל-4?
• עכשיו, תחשוב על זה כעל אמצעי שיווקי - זה “רק 3.14”, “אין פה הרבה שינוי” . . . .
• (דותן) אני חושב שאם נחפור בכוכבית, באותיות הקטנות, אז נגלה שזה איזה... ששחררו את ה-Garbage Collector לעבוד במקביל, או משהו בסגנון. 
• (אלון)  אני לא . . .  יכול להיות, אני לא בקי.
• אבל מה שכן, אני חושב, קודם כל, שבטוח יש דרך לחזור אחורה עם איזה Flag
• ואז לא שברו לך את זה, פשוט יגידו לך שאם אתה בגרסה 3.14, שים את ה-Flag הזה והכל בסדר.
• ואז אתה כאילו . .  “פתרו לך את כל העולמות”, שאני בטוח שהם עשו את זה.
• (אלון)  דבר שני - בתיאוריה, זה כמו להגיד ש”שמע - פעם שיחקנו במשחקים של ה-PC - לא יודע, שיחקנו Digger וכאלה - קניתי מחשב חדש, שברו לי את המשחק כי הוא נהיה מהיר מדי . . . 
• (רן)  אמרתי את זה מקודם . . .
• (אלון)  נכון - אז זה לא אשמת ה-Digger! 
• (דותן) זה לא Digger. 
• (אלון) Digger? לא, אמרת להם ש“אם זה אשמת הפלטפורמה” - ואני אומר, במשחקים - “מה, זה אשמתי” שזה זה אותו דבר.
• (דותן) רגע, כמה מהקהל היום לא יודע מה זה Digger? [אזהרה - עלול להוות עילא להרחקה אוטומטית ושלילת כרטיסים לכנס]
• (אלון) כולם. זה רק אני יודע, גם אתם כבר לא זוכרים. 
• (דותן) אולי נמליץ להתקין, שים לינק ל-Digger. 
• (רן)  תודה - עפר, שים לינק ל-Digger
• [בואו, אנחנו כבר שתי פסקאות לתוך הקרקס הזה, מה נראה לכם? - כבר יש מזמן . . . ]
• (רן) יאללה - מגניב, חפרנו Python בוא נתקדם. Cloudflare?
• (אלון)  אוקיי, יאללה - Cloudflare אוקיי, טוב: אז Vibe Coding זה הלהיט החדש. יש לנו Lovable ו-Base44 ו-v0 ו-Bolt ועוד עשרות, ועוד מלא Framework-ים ל-Mobile . . . 
• ו-Cloudflare באו ואמרו “טוב רגע - בעצם, כל הדבר הזה של Vibe Coding - להרים בעזרת טקסט אתר - זה בעצם נהיה Commodity”.
• ו-Cloudflare, כמי שמנסים ושולטים באינטרנט באיזושהי צורה, אמרו ”היי, אז רגע - במקום שכל אחד ינסה להרים את פלטפורמת ה-Vibe Coding המגניבה שלו, בואו נוציא SDK - וזהו, ויש לכם Vibe Coding משלכם [עם Blackjack? . . .].
• עכשיו, לדעתי זה ממש מגניב - משתי סיבות . . . 
• קודם כל, זה עדיין לא עובד טוב, אני חייב להודות - ניסיתי את זה, זה לא עובד הכי טוב עדיין, אז כוכביות . . .
• (רן)  רגע, לא הבנתי SDK למה? SDK לפלטפורמת Vibe Coding?
• (אלון) SDK, כדי שאם אתה עכשיו רוצה להרים Base44, אז יש לך פשוט: אתה מרים אפליקציה, מחבר את ה-SDK, אתה שולח ל-Chat, היא מחזירה לך את ה-App . . . .
• זה, בגדול, “Base44 as an SDK”, אם אתה רוצה להגיד את זה ככה.
• שיחקתי עם זה - זה לא עובד הכי טוב, אני חייב להודות - אבל זה הולך להשתפר, אני בטוח.
• מה שכן מעניין בדבר הזה, זה לא שמישהו יבוא עם זה וירים מתחרה ל-Lovable או ל-Base44 - זה לא מעניין.
• אבל אם יש לכם משהו in-house שאתם רוצים, כאילו לתת ליוזרים שלכם, או פנימית, עכשיו לפתח משהו על תשתית שלכם.
• זה יכול להיות מאוד מאוד מעניין.
• כי אתה לא תצא ל-Lovable,  שלא מכיר את ה-Context או כל הדברים כאלה, או שאתה תרצה לעשות Isolation למשהו.
• ואז אתה יכול לתת כלי פנימי או כלי בתוך ה-SaaS Application שלך, או מה שזה לא יהיה, כדי לעשות Vibe Apps, או לא יודע איך לקרוא לדבר הזה.
• שלדעתי זה כן משהו שהעולם הולך לשם - והם זיהו את זה די מהר, והם מנסים להשתלט על זה כמו שהם משתלטים על האינטרנט.
• ואני מת על Cloudflare, חברה מדהימה.
• (רן)  קודם כל, Cloudflare חברה מדהימה - אמרנו את זה כבר לפני זה בפודקאסט, והם לא משלמים לנו, עדיין . . . - אני גם משתמש בה בכל מיני דברים.
• וכאילו, אני מסתכל על התיעוד עכשיו ששלחת, ואני מסתכל בצד, ואני סופר לעצמי בכמה מוצרים מבין המוצרים שלהם אני משתמש בהם . . . אז חברה מדהימה.
• (דותן) זו חברה שיכולה להיות מדהימה, אם אתם ב-Mode של לא משלמים, אז היא יכולה להיות מדהימה . . . 
• (אלון)  היא בינונית, חסר להם רק להעביר לנו Sponsorship, ואז זו באמת חברה שאני אמליץ עליה לכולם.
• (רן) כן . . . אבל בלינק שאתה שמת, אלון, אני לא רואה את מה שאתה מספר . . .  כאילו, מה שאמרת זה מגניב, אבל זה מה ששמת פה? 
• (אלון)  כנראה ששמתי לך את הלינק הלא נכון, וזה מה שקרה שמישהו... 
• (רן)  יאללה, מגניב, אז אחר כך תשלים. 
• (אלון)  אני אשלים את הלינק, זה לא הלינק הנכון, אבל אני אתן לכם את הלינק הנכון. 
• (דותן) הנה, שמתי את הנכון.
• (רן)  מעולה.
• (אלון)  מזל שדותן פה להציל את המצב, באמת. פשוט ערימה של חובבנים פה, שמים לינק לא נכון . . . אה, הלכת על ה-GitHub, טוב, כי יש להם גם איזה פוסט רשמי שיצא על זה והכול, וזה ממש מגניב. 
• (רן)  ועכשיו לפינתנו: מה OpenAI עשו השבוע? אלון, שוט!
• (אלון)  מה OpenAI עשו השבוע? אוקיי, אז בואו נתחיל. אז OpenAI יצאו בהכרזה, שאיך מישהו רשם? OpenAI נהיו קצת כמו ההכרזות של Apple של פעם - רק ההבדל שזה לא מוגמר, פחות מגניב, פחות זה . . . אבל כן מראים איזה כיוון של התעשייה. וכן, אני חושב שהם מכתיבים איזשהו כיוון לתעשייה, והתעשייה הולכת איתם, שזה כן יפה.
• ומה שהם עשו זה שהם הוציאו . . . היו כמה דברים מעניינים בהכרזה, אבל שני הדברים המעניינים: הראשון זה AgentKit, שזה בעצם מתחרה ל-N8N או Zapier.
• והם קצת שינו גם את הסטנדרט של איך שזה עובד, ודה-פקטו, אם N8N היה בצמיחה מטורפת, ובדיוק השבוע פורסם שהם גייסו איזה 250 מיליון דולר או משהו כזה [n8n raises $180m to get AI closer to value with orchestration – n8n Blog]
• אז אני חושב שבאו OpenAI ואמרו “אוקיי,  אני הבנתי שהשוק הזה גדול, אני רוצה דה-פקטו להשתלט על השוק הזה” . . . .
• ודעתי האישית היא שזה יצליח להם . . . .
• כאילו N8N, מי שעבד איתו - הוא אחלה כלי, אבל הוא Hardcore. זה לא בשביל כל אחד.
• והוא יותר, בוא נגיד, “מתאים למפתחים” או לאנשים שהם יותר Experienced.
• ואני חושב ש-OpenAI לקחו את זה יותר ל-Mainstream - ומחנכים את השוק גם, זה מה שהם עושים.
• אז כל אוהדי ה-N8N - כן, תגידו בטח “N8N הרבה יותר טוב, עדיין יותר חזק”, אבל הוא מאוד “מחוספס”, מה שנקרא, וקשיח לעומת מה שנראה ש-OpenAI. 
• (רן) כן, אתה יודע, אבל זה יכול להיות תחרות ל-N8N - וזה גם יכול להיות ולידציה (Validation).
• אתה יודע, זה תמיד קורה ככה כשיש לנו Blue Ocean - הם היו ראשונים, ועכשיו באו OpenAI, ואולי קצת, כמו שאמרת, עושים “חינוך שוק”, סוללים להם את הדרך.
• בסופו של דבר זה יכול לגרום גם להגדלה משמעותית בשוק של N8N. 
• (אלון) נכון - אבל אני חושב שבסוף, איך שזה יקרה, OpenAI עשו את זה, Google ייכנסו לזה, Microsoft ייכנסו לשם, אולי Claude ייכנסו גם לסיפור הזה . . . .
• ולדעתי, N8N . . .  בוא נגיד, זה לא סוס שאני אישית הייתי מהמר עליו.
• ובטח שלא על Zapier, שבכלל נשכח מאחור - פעם היה איזה “נסיכת ה-SaaS”, ולא יודע, אבד בים. 
• (רן)  מה עם ה-IFTTT? ה-IFTTT עוד בחיים? זוכרים אותו? If-This-Then-That?
• (דותן) סוג של, כן . . . “סוג-של-בחיים”.
• (אלון)  זה לא נרכש על ידי Zapier או נבלע על ידיהם? [לא משהו מתועד בכל אופן . . . .]
• (רן)  פעם זה היה ממש נחמד - השתמשתי בו לכל מיני דברים שטותיים של אוטומציה . . . אבל כן, מלא זמן לא ראיתי אותם . . . אוקיי, מה עוד הם עשו? 
• (אלון) אז זה הדבר הראשון.
• (אלון) הדבר השני שהם עשו, זה שהם אמרו שאתה יכול לדבר עם כל App דרך ה-Chat עצמו - והוא מחזיר לך גם UI. 
• קצת מזכיר, דיברנו על זה, על ה-MCP-UI שעשו . . . 
• אז הם לקחו פרוטוקול, הם אימצו פרוטוקול טיפה שונה, אחרי זה ראיתי גם איזה פוסט שרשמו שעובדים על איזו אינטגרציה, לעשות שיתמוך גם וגם [OpenAI Apps SDK Integration | MCP-UI].
• אבל מה שהרעיון יהיה, זה שאתה דרך ה-Chat תוכל נגיד לדבר עם Booking.com, והוא כבר יחזיר לך את המלונות שלך.
• ואז תוכל להגיד לו “טוב, תפלטר לי מחירים”, ואז תראה את המלונות . . . .
• ובעצם להביא את הוויזואליזציה (Visual) לתוך ה-Chat באופן מוסדר.
• עכשיו, למה אני חושב שזה מטורף? כי שוב - זה רק ההתחלה והכול, אבל דה-פקטו הם מחליפים את הדפדפן . . . 
• כי הרבה פעולות שאנחנו עושים עם ה-Browser זה שאנחנו הולכים ל-Amazon, כי עדיין לא נוח לקנות בטקסט.
• ופה הם אומרים הנה, עכשיו אני אלך ל-OpenAI ואגיד אוקיי רגע - “תביא לי נעליים מ-Amazon”
• ואז אני אקבל List של נעליים ואז אגיד “רגע, תחפש לי שחור” או “רגע, עוד מהסוג הזה” ועוד כאלה, אני יכול להמשיך ככה.
• אולי זה מייתר לי את הסיבה בכלל להיכנס ל-Browser . . . . 
• וככל שיותר ויותר אתרים יהיו בזה אז בעצם הפלטפורמת-גלישה שלנו תהיה אולי ה-Chat של OpenAI, שזה מהלך מטורף לדעתי.
• (רן)  דרך אגב באותו הקשר - Comet, הדפדפן של חברת Perplexity - אני חושב שהוא כבר פתוח לכולם, זאת אומרת, לפני זה זה היה Invite-Only . . . אני לפחות קיבלתי הזמנה, נראה לי שזה כבר פתוח לכולם.
• (אלון)  יש לי הזמנות לחלק, מי שמעוניין . . . 
•  (רן) כן . . . התקנתי, ניסיתי, האמת היא שבינתיים לא כזה עפתי עליו. אני יודע שאפשר לעשות איתו דברים טובים, אבל אני חייב להגיד שבינתיים לא התרשמתי במיוחד.
• אבל כן, זאת אומרת - זה באותו זה באותה זירה, כאילו מתחרה על תשומת הלב, מתחרה להיות הדפדפן שלכם, אותה זירה של Chrome ושל ChatGPT Apps או איך שנקרא לזה, “Chat with your Apps” . . . 
• (אלון)  אני גם אם שיחקתי קצת עם Comet, האמת שלא התחברתי אליו כל כך. 
• הדבר שהפריע לי בו שהוא לא צפוי . . . . אתה מחפש משהו, ולפעמים זה חיפוש - ולפעמים הוא עונה לך
• לפעמים אתה רוצה שיענה לך והוא מחפש לך, לפעמים אתה רוצה הפוך . . . כאילו, אתה לא יודע מה אתה מקבל.
• (רן) בוא, אני אתן לך סיפור - סיפור משתמש: חזרתי מחופשה ארוכה ואמרתי “מעניין כמה זה עלה לי” . . . ניקח את כל הסיכומים של כרטיסי האשראי, נגיד ל-Comet “בוא, תיקח את זה, תייצר לי Spreadsheet, ותסווג את זה לפי אוכל, בילויים, Transportation ועוד כמה”.
• אוקיי, מגניב. לא נשמע מסובך מדי, נכון? [נכון?!]
• הוא התחיל לפתוח לי טאבים אחד אחרי השני, יצר לי Spreadsheet-ים ריקים אחד אחרי השני . . . .
• עשה בלאגן שלם, בסוף הייתי חייב לעצור אותו - כלום לא יצא מזה, זה היה די מאכזב. 
• (דותן) אתה יודע מה היה מצחיק? אם הוא היה מזמין לך עוד פעם בדיוק את אותה חופשה, שוב פעם . . .
• (רן)  אולי הוא עשה, לך תדע . . . . יכול להיות שזה קרה.
• (אלון)  נראה לי שהוא פשוט שלח את הסיכום ל-Cloudflare, שיוציאו לך זיכוי על העלות של החופשה . . .
• (רן)  טוב, יאללה - הבא בתור. מה עוד?
• (אלון)  טוב הבא בתור - אז Claude יצא! Claude החדש, 4.5 - שמה שכן מעניין בו שזה Claude חדש . . .  ותמיד - Claude, אני אוהב אותו.
• בוא נגיד, לפחות אצלי ואצל  . . .   לפי סטטיסטיקה [איזו?] אצל 70% מהמפתחים בעולם, הוא ה-Default Coding Agent.
• ובין 3.5 ל-3.7 היה שינוי לא בהכרח לטובה, 
• אבל בין 3.7 ל-4 היה שינוי מאוד משמעותי - ויש איזו ציפייה שזה גם יהיה ב-4.
• כן אני יכול להגיד כבר שראיתי גרף מאוד חמוד, שאני אשתף אתכם, ש-Lovable הוציאו.
• ו-Lovable - יש להם סטטיסטיקה, בוא נגיד, לא רע בכלל . . .
• ושם רואים איך כמות ה-Error-ים ירדו משמעותית בגלל היציאה של Claude.
• הנה, רגע - אני אשתף אתכם ומי שיכול לשמוע את הגרף [סבבה], מי שרוצה לראות את הגרף אז אני אשדר לכם אותו טוב . . . סתם, הנה, שמתי לכם לראות את הגרף: 

https://x.com/FabianHedin/status/1974244202172039280

• אז רואים ממש את ה-Drop בכמות השגיאות.
• הם אומרים שזה הוריד להם - המעבר ל-4.5 - הוריד ב-30% את ה-Build Errors ונתן 20% Faster Responses.

• אז להם יש יותר סטטיסטיקה מהשימוש שלי . . . 
• (רן) אני זוכר גרף כזה גם במעבר בין 3.5 ל-3.7 . . . 
• (אלון) לא, בין 3.7 ל-4 . . .  בין 3.5 ל-3.7 לא היה מעבר כזה . . .
• (רן) אוקיי, אוקיי - אז כן, אז זה ממשיך לרדת . . . 
• (אלון)  כן. אז העניינים ממשיכים להשתפר. אז בתיאוריה, הוא אמור להיות אחלה Coding Agent.
• אין לי מספיק ניסיון איתו בשביל שאני אוכל לתת חוות דעת.
• (רן)  דרך אגב, ראיתי השבוע שהתחילו לעשות דפריקציה (Deprecation) של Claude 3.5 Sonnet
• לפחות ב-Bedrock, יכול להיות שגם ב-Anthropic
• אז אני השתמשתי הרבה ב-3.5, ועכשיו כבר צריך לעבור . . . אז אני עובר ישר ל-4.5.
• (אלון) או, איזו קפיצה . . . 
• (דותן) . . . מרגשת . . . 
• (רן) . . .  אמיץ, כן . . . 
• (אלון) טוב, אני מאוד אהבתי. . . אני עם 4, עדיין קשה לי להתנתק ממנו, כל כך אוהב אותו.
• קשה לי, אבל בסדר - אני צריך לעבור כנראה ל- 4.5, באמת יותר טוב, אין סיבה סתם להישאר מאחורה.

• (אלון) טוב, אז נמשיך עם Claude Code - אז Claude Code, שכולם נורא אוהבים ויש את ה-”כן יותר טוב מ-Cursor, לא יותר טוב מ-Cursor”, “זה העתיד, זה לא עתיד”, “כל מי שלא משתמש פה לא מבין מהחיים שלו” . . . .
•  . . . וויש גם את כת ה”עזבו אתכם - הכי טוב זה Terminal!” . . . 
• אז Claude Code לא הקשיבו לכל מי שאמר את זה - והוציאו Extension ל-VSCode.
• ובעצם עכשיו ב-VSCode יש לנו את Claude Code כ-Extension . . . 
• זה עדיין בבטא.
• (רן)  אבל רגע - הם הוציאו Extension די מזמן, וזה לא עשה כמעט כלום, ה-Extension הזה . . . השאלה מה עכשיו?
• (אלון) אני לא יודע . . . 
• (רן) אה, הוא עושה יותר . . . הוא עושה יותר, אני רואה - פעם זה היה פשוט כאילו Extension שפותח לך Terminal.
• כלומר - הוא לא היה עושה הרבה . . . 
• (אלון) אז היום זה כאילו להפוך את הזה שלך [ה-IDE] לסוג של Cursor.
• הוא עדיין לא באותה רמה ולא אותו הדבר.
•  אני אישית עדיין מחסידי Cursor [מתי חוסמים את כביש 4?]
• שבוע הבא אני אצא לבדיקה - אני חייב להודות עוד פעם - עם Claude Code, אחרי האכזבה הקודמת.
• (רן) דרך אגב, ל-Cursor יש את Cursor Agent - זאת אומרת, גם Cursor הלכו ל-Terminal, עם Cursor Agent.
• פעם אחרונה שהשתמשתי בו הוא היה די גרוע . . .  כאילו, הוא היה איזשהו סוג של בטא, ולא הכל עבד שם.
• אבל ראיתי איזושהי הכרזה שהם עשו ממנו עכשיו משהו יותר רשמי ובוגר, אז עוד לא ניסיתי אותו מאז.
• (אלון) ל-Cursor, הדבר הכי מגניב שהם עשו, שאנישראיתי אתמול האמת איזה Twit של אחד המפתחים, יש את Cursor SDK שזה . . . לדעתי לא נראה לי שכבר יצא לכולם.
• ומה שהוא רשם שהוא עשה זה שהוא אמר לו “תבנה לי Tasks App” - והוא שם את זה ב-Repeat ב-Terminal, והוא נתן לזה לרוץ 24 שעות.
• עכשיו, הוא מפתח שם ולא עולה לו כסף וכלום, לא יודע כמה זה היה עולה בפועל, כמה Token-ים.
• אבל התוצאה הייתה נראית ממש מרשימה . . . .
• גם הוא אמר שהוא לא ציפה שב-Single Prompt הוא יבנה Asana או Monday או מה שזה לא יהיה, וזה נראה ממש טוב.
• הוא גם אומר “טוב, רגע - זה עוד לא Production-Ready, יש עוד עבודה”
• אבל זה נראה די מלהיב - כאילו, התוצאה שם מהדבר הזה.
• וה-Cursor SDK, אגב, הוא קצת מזכיר אולי תצורה אחרת על מה ש-Cloudflare עשו עם ה-SDK, אבל יכול להיות שזה גם יהיה השימושים שלו לדברים יותר פנימיים ודברים כאלה או פרוגרמטית (Programmatic) אני רואה את זה משתלב ב-Workflow של Style N8N פתאום להריץ או לא יודע מה, לפנות ל-Cursor שיעשה דברים משוגעים, יכול להיות די מגניב.
• (רן)  כן. דרך אגב ל-Claude Code גם יש SDK כבר הרבה זמן  . . . 
• אז בקיצור - כולם נהיים אותם מוצר
• לכולם פחות או יותר יש אותם פיצ'רים בסוף.
• (אלון) כן, לגמרי.
• יש, אני חושב, הבדל משמעותי בין ה-Claude ל-Cursor SDK בעניין של ה-Context
• כי Claude Code - יש להם גישה שהם לא מאמינים ב-RAG, והם אמרו שהם גם לא יכניסו לעולם RAG
• זו איזושהי גישה שלהם.
• ו-Cursor כן עובד עם זה. יש להם . . . 
• זה קצת שונה, יש להם גם GraphDB.
• הגישות שם, טכנית, הן מאוד שונות - וזה אמור להביא תוצאות שונות מאוד.
• אני לא יודע מה הגישה vיותר נכונה, אני חייב להודות.
• (רן) אוקיי, ובסופו של דבר, ל-Cursor הוסיפו Planning Mode . . . 
• (אלון)  כן, Planning Mode - זה  . . .  האמת שתכל’ס, הם לקחו Best Practices של אנשים שעבדו עם Cursor
• שמי שמכיר, פשוט היו אומרים ל-Cursor “טוב, זה מה שאני רוצה לעשות, זה ה-Step-ים, תשאל אותי שאלות הבהרה - וברגע שאתה בטוח, תתחיל ממש”.
• כאילו, זה היה איזה Prompt די סטנדרטי שהיה אפשר לרשום
• הרוב לא רשמו אותו . . . 
• ומה שהם עשו ב-Planning Mode - תכל’ס, זה מכריח אותך לעשות את זה . . . 
• אתה כותב משהו, ואז הוא מתחיל לשאול אותך שאלות הבהרה ועוד שאלות ועוד שאלות
• ורק כשהוא אומר לך “אוקיי, זה מה שהבנתי - זה מה שאני הולך לעשות” - אז הוא מתחיל לרוץ.
• זה פשוט שהכניסו Best Practice - אבל זה טוב
• זה כאילו . . .  זה ממש טוב שהכניסו את ה-Best Practice.
• (רן)  אני, דרך אגב, רואה את זה כ-Feature שמועתק מ-Claude Code - כי זה היה שם מההתחלה. זאת אומרת, יש ב-Claude Code שלושה Mode-ים של פעולה
• אחד זה Planning Mode
• השני זה Auto-Accept
• והשלישי זה Accept עם . . . זאת אומרת, לא Auto-Accept, כאילו Accept עם Prompt.
• אז כן, אז כאילו זה היה בנוי שם כבר מלכתחילה.
•  דרך אגב, גם ב-Aider וזה בנוי ככה.
• (אלון)  וואו, איזה עתיקות - Aider! הבאת לי משהו  . . . מה זה? וואו . . .
• מה זה? אתה יודע, ככה נדבר עוד שנה אולי על N8N  - “מה? איך? N7N מה זה היה?” . . . .
• (דותן) אין-N8N . . . .
• (רן)  טוב, יפה  - ודותן, הכדור אליך.

[23:03 - דותן]

• (דותן) כן, טוב - אתם עובדים עם Pre-Commit? זאת אומרת, ה-AI שלכם עובד עם Pre-Commit?
• (רן)  כן, אבל לא זה . . . 
• (דותן) אז מישהו בנה כלי שנקרא prek - זה מימוש מחדש של Pre-commit ב-Rust.
• וזה בעצם אותו דבר - הוא קורא את אותה הקונפיגורציה . . .
• (רן) אתה צוחק כי לא אמרנו Rust היום עדיין, נכון?
• (דותן) נכון! כן, מה - מפתיע אותך?
• (דותן) . . .  וזה רץ יותר מהר, תופס פחות מקום - וזה פשוט יותר טוב.
• אז אפשר לשדרג בצורה חלקה.
• וזה קצת צובע איזושהי תיאוריה שהייתה לי, שאני לא יודע אם הכלי הזה בנוי ככה . . .
• אבל כלים כאלה - שהם יחסית קטנים - מאוד קל להגיד ל-AI לממש מחדש ב-Rust.
• ואם זה “עולה לך חינם” לממש מחדש ב-Rust - כאילו, זה לא עולה לך בשעות חשיבה אלא רק AI, כמה Prompt-ים, אז החיסכון פה הוא די מטורף.
• זה מיד מתרגם את עצמו לחיסכון.
• שוב, אני לא יודע אם הכלי הזה נבנה ככה - אבל בסוף זה כלי עם Scope מאוד סגור.
• (אלון) כן, זה נשמע משהו שדי קל להרים היום עם AI, בקלות, מאוד מהר.
• (דותן) כן, נקודה למחשבה. 
• (אלון) . . . אשכרה יכול להיות שווה באמת - אם יש לך בעיה עם הכלי שלך, תכתוב חדש. 
• (דותן) . . . וגם אם זה לא מצליח, אז את מה שיצא לך בסוף אתה זורק לפח, וחוזר אחורה לכלי הישן
• עד שיצא לך LLM יותר חכם . . . 
• (אלון)  הנה, יצא 4.5 . . . יותר חכם!
• (דותן) כן, יכול להיות שזה . . .
• (דותן) בקיצור, שווה לנסות את הכל מיני המרות-כלים האלה.
• האייטם הבא נקרא nanoGPT - וזה בא מ-Karpathy . . . 
• (רן) . .  המלך!
• (דותן) . . .  כן, יש אומרים “המלך” - הוא יצר איזשהו “GPT-מינימליסטי-טיפש”, שאפשר לאמן אותו, לעשות לו Fine-Tuning יחסית מהר - ולהפוך אותו להיות “יחסית חכם”.
• זאת אומרת, איזה שהוא Use Case, שאם אנשים מחפשים לא את כל העוצמה של המודלים הענקיים, אלא רוצים לפתור איזושהי בעיה סגורה, והם רוצים לחסוך בכסף וזמן.
• אז הוא יצר פה איזושהי אופציה שהיא רלוונטית.
• את זה תפסתי ב-Twitter - והיה נראה שאנשים ממש מתלהבים מזה, זה לא “סתם איזה משהו קישקושי” כזה.
• אז גם מעניין.
• (רן)  כן, אני גם חושב שחלק מהקסם שלו, זה שהוא מלמד תוך כדי.
• כלומר -  הוא לא רק יוצר כלי שימושי, אלא גם תמיד-תמיד עושה את זה בצורה מאוד אינסטרומנטלית.
• אני לא אתפלא אם בקרוב הוא יפרסם וידאו של איזה 10 שעות, שבו הוא עובר על כל הקוד ומסביר בדיוק מה כל דבר שם עושה [Placeholder ללינק מהעתיד - תכל’ס קלאסי Karpathy . . . ]
• הוא מאוד אוהב את הדברים האלה, אז יש שם אחלה ערך חינוכי ולימודי. 
• (דותן) כן, האמת שאתה פוגע בדיוק - הוא כתב פה ש-nanoGPT it is a rewrite of minGPT, that prioritizes teeth over education.
• זאת אומרת, הוא לקח את הערכים הלימודיים, שם אותם בצד - ועכשיו הוא אמר “תשמעו, יש פה משהו שהוא יותר “קילרי” כאילו, באינפלמנטציה (Implementation) שלו.
• שזה כנראה יותר שימושי - אני לא יודע, אבל זה מה שהוא טוען.
• (אלון) תראה, עם הiPhone 17 Pro, אם ראית, אז אפשר להריץ עליו . . . היום אני לא יודע אם אתה צריך Nano, יכול להריץ עליו דברים גדולים ומטורפים. 
• (דותן) כן, ממש משוגע.
• (דותן) האייטם הבא די מפתיע - אני ראיתי רק את השם של הפרויקט, זה נקרא OpenArm.
• ואז המוח שלי שילב את זה - היתה איזושהי כתבה על Intel ו-AMD שמנסים להשיב מלחמה ל-ARM, החברה של ה-CPUs [למשל זה - Intel, AMD form x86 group in effort to combat Arm | TechTarget].
• אז אמרתי “אה, אוקיי, טוב - בוא נראה מה זה OpenArm, בטח זה איזשהו סטנדרט כזה של CPU של x86 וכאלה” . . . 
• פתאום נפלתי על איזה פרויקט שמראה לך שזה כאילו פרויקט ל-Humanoid ARM . . . . 
• (רן)  “זרוע”, בעברית . . . זרוע אמיתית. 
• (דותן) . . . זרוע “ביונית” . . . 
• אז בקיצור, אם מישהו רוצה לבנות זרוע ביונית ורובוטית, ומחפש דרך טובה להתחיל - אז בבקשה, הנה הפרויקט.
• [תזכורת - מאסק מחזיק גם את Neuralink וגם את החבר’ה ב-Tesla שמייצרים את Tesla Optimus. אם אתם מתקשים לישון בלילה, אפשר לנסות לחזור לקרוא קצת אסימוב . . . ]
• (אלון)  מה רשום פה? $6500 for complete bio manual system . . . אני לא מצליח להבין . . . .
• (רן)  אז מה זה? זה תוכנה וחומרה?
• (דותן) זה תוכנה - וסכמות של חומרה.
• (רן)  הבנתי. קצת מאכזב שזה לא ב-Rust, אני חייב להגיד, דותן . . .  אבל לא נורא, תשתדל כמובן.
• (דותן) זה לא ב-Rust - וגם זה לא מדבר על ARM, המעבד. 
• (אלון)  אבל תראה - זה ממש מגניב . . . כאילו, הייתי שמח שהספונסר שאין לנו ייתן לנו כזה . . .
• (דותן) נכון.
• (רן)  . . . שינמיך לך את המיקרופון . . . .
• (אלון) . .  או סטנד למיקרופון, משהו . . . 
• (דותן) זרועות למיקרופון, כן. זה השימוש הכי מיותר בכל הטירוף הזה.
• (דותן) האייטם הבא נקרא NanoBowser - מי שזוכר את OpenAI Operator, שיצא כזה “בהכרזות משוגעות” ועם Demo-ים מטורפים, שאני לא יודע מה קורה עם זה עכשיו  . . . 
• אז יש פה פרויקט שהוא פשוט Extension ל-Browser הקיים שלכם, שאתם יכולים לחבר אליו את ה-LLM-ים המועדפים עליכם - והוא יוצר לכם בעצם את ה-Operator, בלי לשלם את המחיר של ה-OpenAI Operator . . . 
• מה-Gif-ים וכל השטויות שיש פה זה נראה די מגניב, ונראה לי שזה מהדברים שהם פשוט מתקינים ומנסים לראות אם זה באמת עובד טוב, למי שצריך Operator ב-Browser.
• זה כמובן Extention-ים - אז לבדוק, קחו קצת את הקוד, לראות שזה לא גונב לכם את הארנקים.
• [צריך הקלטה קבועה לזה, כמו Discliamer-ים של השקעות, הימורים, אלכוהול . . . ].
• (אלון) הארנק שלי בכיס - איך הוא יגנוב לי אותו? עם הזרוע הביונית של מקודם?
• (דותן) כן, צריך לבדוק שזה לא הולך ומייצר לך זרוע ביונית, ואז הוא גונב לך את הארנק.
• (רן)  זרקת רעיון . . .  מעולה. 
• (דותן) אתה מבין איך הכל מתחבר? 
• (רן)  כן . . .
• (אלון)  מדהים, אהבתי. 
• (דותן) הפרויקט הבא - הנה, התאכזבת שאין Rust, אז הנה בבקשה - פרויקט שנקרא Lance.
• ו-LanceDB זה Data Format קלמנרי [Columnar]  . . . ככה אומרים? “קלמנרי”? יש מילה כזאת? [לא]
• (רן) “עמודאי” . . . . עמודאי, בעברית. “זרוע” ו”עמוד” . . . 
• (דותן) “עמודתי” . . . - ל-Machine Learning. או במילים אחרות - זה מתחרה ל-Parquet
• שהוא - ככה כתוב - פי 100 יותר מהיר.
• (אלון) Random Access . . .
• (דותן) כן . . . שזה מספר משוגע - להיות פי 100 יותר מהיר מ-Parquet.
• (אלון) אבל Parquet זה פורמט . . .
• (דותן) נכון, אבל הפורמט נותן לך את הכוח . . . “פורמט מפרמט”.
• (אלון)  לא . . . “המרה ל-Parquet”? מה?! משהו לא מסתדר לי במשפט, רגע . . .  “Convert from Parquet in 2-lines of code . . .”
• אה, אחרי זה, העבודה עם הפורמט החדש היא כאילו יותר מהירה אם עובדים עם ה-Lance הזה, אוקיי.
• (דותן) כן. זה לא Parquet - זה גרנית פרוצלן . . .
• (אלון) אוקיי, יפה. אל תשים על זה רק מים, יותר מדי מים . . . 
• (דותן) נכון . . . . אז יש פה Random Access, יש פה Vector search 
• ויש פה Rust בפנים, שזה תמיד דבר טוב.
• אני מניח שמי שצריך את זה פשוט יכול לנסות על כמה קבצים ולראות מה קורה ואם זה באמת אמיתי.
• (אלון)  מעניין, אני חושב שאני לוקח את זה לסיבוב עכשיו.
• (דותן) תנסה, מה יש לך להפסיד? זה Rust - זה יתקמפל (Compile) לך סבבה. זה לא Python עכשיו, שאתה צריך להתקין, ולבדוק תלויות . . .
• (אלון) . . .  ולבטל את ה-GIL . . . 
• (דותן) . . . . ולבטל את ה-GIL, כי עכשיו יש לך דילמה כן GIL, לא GIL, ואז אתה צריך להתקין ספריות והכל יישבר לך  . . . 
• בקיצור, ה-AI שלך יעשה את כל הדברים האלה, אבל עדיין - הוא ישבור את הראש. 
• אלון)  נכון . . . אני נורא מרחם עליו, שאני נותן לו עם Python . . . תמיד את ה-Error-ים ו”רגע אני אצטרך Virtual Machine, רגע אני צריך את זה, אה ספרייה! לא זה . . .”, ואני אומר “יואו . . . “
• (דותן) הבעיה שאז אתה צריך לעבור לעבור ל-”Mode צעקות” ולכתוב ב-CAPs הכל . . . 
• (אלון)  נכון ב-Python, אתה צועק, כן. אין ספק, בדיוק . . .
• (דותן) הפרויקט הבא נקרא SemHash - וזה Fast Semantic Text Deduplication & Filtering
• והאמת ש-Semantic Caching זו טכניקה מגניבה לעשות DeDup-ing.
• וזה פרויקט שעושה את זה - “בקבלנות”.
• אז מי שצריך לעשות DeDup ל-Data Set-ים, זה נראה לי אחלה פרויקט שעושה את זה.
• (רן) טקסטואליים?
• (דותן) . . .  כמובן אפשר לבנות את זה ידנית, אבל כמוצר מדף Open Source, זה נראה ממש נחמד.
• אז זה זה.
• (דותן)  והפרויקט הבא נקרא GraphBit, שבא מ-InfinitiBit 
• וזה Agentic Framework - כן, yet another framework - אבל הכוכבית שלי פה שזה כתוב ב-Rust  [איבדנו שוב את הספירה…]
• ומה זה נותן שזה כתוב ב-Rust, לעומת כל השאר? קודם כל לדעתי, Agent Framework ב-Rust זה דבר שהוא חייב היה לקרות.
• מה שנותן איזושהי תחרות ל-LangChain וכל ה-Clones האלה.
• פשוט כי אין סיבה, אין משהו מיוחד - אם אתה עובד עם LLM-ים והמון אינטגרציה, אין משהו מיוחד ב-Python שמחייב לתת פה יתרון.
• אז הנה זה מתחיל לקרות, עכשיו זה קורה.
• ואם משתמשים ב-GraphBit הזה, אז ההבטחה שלהם זה שיש לך פי 68 פחות CPU - שזה גם מספר אסטרונומי - ופי 140 פחות זיכרון בפרויקטים שלך.
• הם עשו גם Benchmark-ים שאפשר להסתכל ולהשוות מול כל מה שקיים בחוץ.
• (דותן) ובסוף זה די נחמד, שיש לך . . .  שאתה בונה דבר כזה, ואתה לא צריך להשקיע את כל המשאבים שלך בשביל איזשהו Agent, או כמה Agent-ים, שרצים לך, שרוב העבודה שלהם בסוף זה לעבוד מול LLM-ים בקריאות כאלה. 
• (רן)  כן, זהו - אז רציתי להגיד: זאת אומרת, רוב העבודה באמת ב-Agent זה לחכות, אוקיי?
• לחכות ל-LLM, לחכות ל-Database-ים, לחכות לדברים . . . 
• עד כמה הירידה בצריכת CPU או בזיכרון היא משמעותית? וואללה, לא יודע . . . 
• כאילו, אתה יודע - אם אתה צריך להחזיק String-ים ארוכים או הרבה דאטה בזיכרון, אתה צריך להחזיק אותו, כן? Rust לא יעזור לך במקרה הזה . . . .
• איפה עוד הם יכולים לעזור? כאילו, איפה זה ה-”140x lower memory” שלהם? לא יודע . . . .
• כאילו, יכול להיות שזה באמת 140x - אבל על חלק כל כך זניח, שלא יודע אם זה משנה את התמונה הגדולה. 
• (דותן) כן, מבחינת המשאבים זה יותר בכיוון של  . . . כאילו, מה שלי עולה בראש זה כאילו למה הייתי צריך לשלם יקר? סבבה, אז אני אשלם בזול, זה כנראה מה שהייתי אמור לעשות, אז . . . 
•  (רן) כן, אבל אני חושב שהצידוק המשמעותי יותר זה אם אתה רוצה לכתוב ב-Rust, אתה רוצה לכתוב בשפה שאתה יודע שאתה . . . 
• (דותן) לא, זה נותן לך פה Wrapper ל-Python - אתה יכול לכתוב Python, ולעבוד עם זה.
• וזה מקטין לך את כל ה-Footprint. 
• (רן)  אה, אוקיי - אבל גם ב-Rust, אני מנחש . . .  
• (דותן) כן, אם זה נחסך לך אז כן.
• (אלון) אני לא יודע . . .  אני לא רואה יותר מדי את הערך. כאילו, קשה לי לראות איך זה עוזר, כי הרוב זה IO, הרוב זה . . .
• (דותן) אז הערך בשבילי זה לא להתעסק עם Python . . . .
• (אלון) אה, אוקיי, שנייה - זה סבבה, קיבלתי. זה ערך הגיוני. זה “ערך עליון” אפילו, הייתי אומר.
• דותן) “עליון” . . . כן, די רציני.
• (אלון) . . . לא, את זה קיבלתי.
• (רן)  איזו גזענות יש פה בפודקאסט, עליי . . . 
• (דותן) לא, נו - מה נעשה? למה לסבול?
• (אלון) אתה יודע שבאמת, אני - לא נעים לי מ-Cursor, כשאני עובד עם Python . . . . מסכן.
• טוב, אבל בסדר, לא יודע - בקיצור, מי שלא יודע, אוהב לסבול ואוהב Python - אז אני פחות רואה את הערך, אבל בסדר.
• (רן)  אוקיי.

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

פרק מספר 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]
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 501 של רברס עם פלטפורמה - באמפרס מספר 87, שהוקלט ב-31 ביולי 2025, אמצע הקיץ: רן, דותן ואלון באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט - בלוגים מעניינים, דברים מ- GitHub, דוחות וספריות וכל מיני דברים מעניינים - כולל פינת המצחיקולים שחוזרת בגדול. 🎗️

00:53 רן

• (רן) אז האייטם הראשון שבו רציתי לפתוח היום זה דוח של חברת BOND, או של ארגון שנקרא BOND, שזה למעשה ארגון שמדי פעם - פעם בכמה שנים, לא הרבה - מייצר דוחות: דוחות אימתניים.
• והדוח הנוכחי הוא על “מצב ה-AI".
• (אלון) מפתיע!
• (רן) כן . . . עכשיו, הדוח הוא בן 340 עמודים - כלומר, בלי AI אי אפשר לקרוא אותו בכלל . . . 
• הדבר ראשון שעשיתי זה שזרקתי אותו על NotebookLM וביקשתי ממנו שיסביר לי ויתקצר לי - ושיעשה ממנו פודקאסט.
• ודרך אגב, היום ב-NotebookLM גם אפשר לעשות וידאו! עוד לא ניסיתי, אבל ככה Google פרסמו.
• ומה שיש בדוח הזה, זה למעשה המון נתונים והרבה מאוד גרפים - הוא מאוד מאוד ויזואלי - על “מצב ה-AI" בימים אלו.
• למי שמכיר את BOND מהעבר, אז הם פרסמו לא מעט . . . זאת אומרת, קודם כל זה ארגון מחקר די רציני
• הם פרסמו לא מעט דוחות על מצב האינטרנט ולאן האינטרנט הולך וכל זה - וכל אחד מאלה היו איזשהן אבני-דרך משמעותיות.
• זה באמת ארגון מחקר מאוד . . . אני חושב שזה מורכב בעיקר משני אנשים, ששכחתי את שמם, אבל הם עושים מחקר מאוד יפה ויסודי.
• ומה שמראים בדוח זה את קצב הגידול של AI מכל מיני זוויות - 
• אם זה מבחינת Adoption, אם זה מבחינת Compute, אם זה מבחינת Spend של דולרים, אם זה מבחינת Reach של משתמשים - זאת אומרת, מכל מיני אספקטים.
• הם מראים את כולם - והכל כזה בגרפים מאוד יפים.
• ובכולם אנחנו פחות או יותר רואים "מקל גולף”  - אנחנו רואים גרף שעולה בצורה אקספוננציאלית, נכון לתאריך זה, כמעט מכל זווית - וזה יפה ומעניין ונחמד לראות את זה.
• הם מראים איזשהו Timeline גם לפי מודלים שפורסמו, גם לפי גדלים ומספר הפרמטרים, גם לפי יכולות מחשוב שהתפתחו עם הזמן . . . 
• זהו - דוח יפה כמו שאמרתי, מאוד-מאוד-מאוד ארוך, אבל אפשר גם למצוא תקצירים שלו.
• אז למי שקצת רוצה לקבל איזשהו Overview של אנליסט מאוד “קפדני”, מוזמן לקרוא את דוח BOND - הוא יצא במאי 2025, עשה לא מעט גלים לא מעט דיברו עליו ב-Twitter ובאינטרנט בכלל, אז אני חושב שזה מאוד מעניין, ככה לקבל איזושהי תמונת מצב של איפה ה-AI נמצא היום.
• (אלון) יצא מהדוח הזה, אני אם אני לא טועה, יצא “החוק מור של ה-AI” - כאילו, הגדילה של ה-AI, שהוא מכפיל . . .  איך זה הולך? כל שנה בפי 1.5 משהו כזה? אני אנסה לחפש את זה בדוח הענק, הזה אין סיכוי שאני אמצא . . . 
• (רן) אני חושב ששהחוק הזה נאמר לפני, אבל הם פה הם באמת מראים במספרים - לפחות בחלק מהמספרים  - הם מראים שכן, זאת אומרת, יש לזה ביסוס.
• למרות שברור לכולם שזה לא תמיד יישאר ככה - אבל בינתיים כן, זה המצב, וזה מעניין.
• (דותן) אולי אפשר להמציא “חוק Bond” . . .  זה שדוחות על AI יגדלו פי 10 מהגדילה של AI.
• (רן) כן, כן . . .  זה 340 עמודים, כמו שאמרנו מקודם.
• עכשיו, כל עמוד זה זה משהו לעכל, כן? זה לא מילה . . . כל עמוד זה גרף או אוסף של Bullet-ים מעניינים.
• זאת אומרת, זה לא שסתם מורחים.
• לפני ההקלטה שאלנו את עצמנו כמה מזה הם כתבו בעצמם וכמה הם נתנו ל-AI לכתוב, או אולי Interns . . . 
• אבל זה לא חשוב - בסופו של דבר יצא דוח מעניין ומאוד מקיף, ואני חושב שזה נחמד לראות את זה.
• (דותן) רגע . . .  אם AI מרושע היה כותב דוח על AI מה הוא היה עושה? אם AI היה משתלט על BOND שם על הסיפור? הוא היה הרי באמת כותב דוח שאי אפשר להבין, שהוא ארוך, נכון?
• (רן) תראה, אפשר לחשוב על כמה קונספירציות:
• אחת - אולי הוא היה מנסה להקטין את עצמו, כדי שלא . . . אתה יודע, שלא נערך לקראתו.
• שתיים - אולי באמת היה מבלבל, אתה יודע, כמו שעושים בפוליטיקה - נותן הרבה מאוד נתונים, כדי שאף אחד לא יראה את התמונה המלאה.
• או לא יודע - מה?
• (דותן) אני חושב שלהעסיק את כל בני אדם, להעסיק את כל בני אדם - זה מפרסם 340 עמודים של דוח.
• (רן) כן . . . דרך אגב, אהבתי פה את הרפרנסים - יש פה רפרנס למהפכת הדפוס, יש פה רפרנס לתחילת המחשוב והאינטרנט, ורואים פה גם . . . .
• רואים פה בית דפוס ישן, משנת 1440, וגם רואים פה מסך ירוק יפה מ-1993, שמציג דפדפן טקסטואלי - לא יודע איזה גרסה זה - אבל שמציג את האינטרנט בגרסה טקסטואלית, ירוק על גבי שחור.
• זאת אומרת, יש פה רפרנסים נחמדים לעבר - אבל כמובן רוב הדוח הוא על התפתחות של AI.
• (אלון)  טוב, מגניב  - מה המסקנה שלך מהדוח? אם אתה מתמצת לי ל-Elevator Pitch את ה-340 עמודים? . . . 
• (רן) המסקנה שלי שאנחנו בצמיחת Hockey Stick, ורואים את זה מהרבה מאוד זוויות.
• כלומר, זה לא רק זווית אחת Hockey Stick . . . 
• ומה אני מתכוון בזוויות? - Adoption של משתמשים, Spend של דולרים, גודל של מספר פרמטרים של מודל, יכולות . . .  זאת אומרת, פחות או יותר מכל הזוויות האלה אנחנו בצמיחה מעריכית, נכון להיום.
• וזה מבסס, אני חושב את האמירה של “אוקיי, יש פה Hyper Growth של AI” -  זה לא רק פרספקטיבה אחת אלא זה מכל הפרספקטיבות.
• אז זה כאילו בא ואולי “שם נתונים”, או ככה מראה "בנתונים קשיחים” את מה שאנחנו מרגישים, ושם אותם על הנייר.
• נעבור לאייטם הבא - אז כמעט כולנו מתנסים ועובדים ומשתמשים ב-Coding Assistants למיניהם השונים, ודיברנו עליהם לא מעט פה בפודקאסט הזה; ודיברנו על זה שגם יש כל מיני סוגים - כלומר החל מ-Vibe Coding ועד Smart Auto-Completion, זאת אומרת - מכל מיני רמות אבסטרקציה שונות.
• חלק מהם עובדים איתך רק באנגלית ו”רק תגידי לי מה לעשות”, וחלק מהם גם קוראים קוד ומשלימים לך וכל זה.
• ואחד הדברים שמעניינים את כולם זה עד כמה זה אפקטיבי? זאת אומרת, עד כמה זה באמת עוזר, עד כמה באמת זה מועיל להשתמש בכלים השונים.
• והיו לא מעט מחקרים, אבל רציתי להציג מחקר אחד, שתפס ככה לא מעט כותרות, ויש בו כמה דברים מעניינים - אבל גם יש לי עליו ביקורת.
• שם המחקר זה Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• מה שעשו החוקרים - ארבעה במספר, מארגון שנקרא METR לדעתי, שזה ארגון שחוקר, זאת אומרת ארגון משמעותי, זה לא  . . .  אלה אנשים שיש להם ניסיון במחקר, בעיקר של הנדסת תוכנה - באים ובודקים את ההשפעה של כלי AI שונים על הפרודוקטיביות של מפתחים מנוסים בקוד פתוח.
• איך הם עשו את זה? הם עשו ניסוי מבוקר: הלכו לכמה עשרות פרויקטים, לדעתי משהו כמו 15 או 16  פרויקטים, אם אני זוכר נכון . . . 
• (אלון) 16 לזיכרוני, 16 מפתחים . . .  לא יודע אם פרויקטים אבל 16 מפתחים.
• (רן) כן, כשכל אחד מהמפתחים - יש לו מומחיות גדולה בפרויקט שעליו הוא עובד.
• זאת אומרת פרויקט קוד פתוח משמעותי - וכל אחד מ-16 הנמדדים, 16 המפתחים, מכיר את הפרויקט לפחות חמש שנים, אוקיי?
• ומה שהם אמרו להם זה אוקיי, עכשיו יש לכם אוסף של Task-ים - נגיד, לקחו מתוך ה-Backlog של הפרויקט - ואת כל ה-Backlog הזה של ה-Task-ים הם חילקו אקראית בין “את זה תעשה לגמרי לבד” ו”את ה-Task האחר תעשה באמצעות מנועי-Coding”
• ברוב המקרים השתמשו ב-Cursor
• אז בעצם עשו חלוקה אקראית של ה-Task-ים, ועכשיו הם ביקשו מהם קודם כל “תנו הערכת זמן” - כמה זמן זה הולך לקחת לכם?
• ואז תבצעו את המשימה - בין אם זה באמצעות AI או בין אם בלי, ככה 50-50.
• ואחר כך נבדוק כמה זמן באמת לקח.
• והתוצאות שהם גילו הן מפתיעות: התוצאות מראות שמפתחים - דרך אגב, רוב המפתחים הם מאוד מנוסים בפרויקטים שלהם, הם לא כל כך מנוסים בכלים עצמם, כלומר ב-Cursor, לצורך העניין.
• לחלקם היה ניסיון, אבל אף אחד מהם . . .  זאת אומרת, הם העידו על זה שאף אחד מהם לא היה משתמש Cursor משמעותי.
• אז לפני תחילת העבודה, הם העריכו שהמשימה תיקח משהו כמו 20% או 30% פחות זמן, בהינתן כלי Coding, Code Assistance, מאשר בלי, אוקיי? אז ההערכה שלהם הייתה שייקח פחות זמן.
• דה-פקטו, מה שקרה זה שלקח יותר זמן כאשר הם כן השתמשו ב-Code Assistance . . . .
• זאת אומרת, לא רק יותר זמן ממה שהם חשבו שייקח, אלא יותר זמן ממה שהיה ככל הנראה לוקח להם, אם בכלל לא היו משתמשים.
• משהו כמו 19% . . . 
• וזה מפתיע . . . 
• אז שוב, ההערכה הראשונית הייתה שזה ייקח משהו כמו 20-30% פחות, דה-פקטו זה לקח משהו כמו 19% יותר, באותו ניסוי מבוקר.
• וזה קצת שם מקל בגלגלים של “היי, לא צריך יותר מפתחים אנושיים! כלי ה-AI יעשו לכולם את העבודה!” - והנה מסתבר ש . . .  פה לא ברור, דרך אגב, אם הם עשו עבודה טובה או לא טובה - אבל זה לוקח יותר זמן.
• (אלון) יש פה כמה דברים על המחקר הזה . . . . אחד, קודם כל: הם העריכו כמה זמן לקח להם אחרי שהם עשו את זה, שזה מעניין, והם אמרו ש-20% פחות, שזה היה לוקח להם כאילו יותר.
• ובמדדים האלה זה הראה שזה לקח, כביכול, יותר זמן.
• כמה נקודות מעניינות - אחד המפתחים, פשוט אני צריך לחפש את זה, אחד המפתחים שהשתתף הגיב על זה אחר כך, על המחקר, והוא אמר “אני אחד המפתחים במחקר, כולנו מפתחים מאוד מנוסים והכול”
• מה שהוא אמר שזה, בדיעבד, לא מחקר טוב . . . . כי מה שהם בדקו שם זה מפתיחה - מ”להתחיל לעבוד על Issue”, מכניסה של Issue, עד שהוא עושה Merge ל-Repo.
• שזה בסדר - עד Delivery - אבל מה שהוא אמר זה “סיימנו את המשימה הרבה יותר מהר - ואז עד שקהילה מגיבה אתה כבר לא בקונטקסט, גם עבדת על זה פחות . . .”
• בגלל שעבדת על זה הרבה יותר מהר, הוא אומר, אתה פחות בקונטקסט, לקח לך אחרי זה יותר זמן להיכנס לקונטקסט - וב-Open Source, הוא אמר שבגלל שה-Cycle-ים ארוכים, זה מאוד בעייתי שאתה לא זוכר ולא מכיר את הכל טוב.
• כאילו, כשאתה לא בקונטקסט טוב, כשאתה עובד על משהו שבועיים, נגיד, אתה הרבה יותר מכיר אותו מאשר ביום אחד, אתה פחות זוכר את הפרטים.
• ואז הוא היה בכל פעם צריך, כדי לענות לקהילה, היה צריך כל פעם להיכנס, לצלול וזה . . . 
• והוא אמר שזה מה שלקח לו את הזמן.
• (רן) כן, אז זהו, אז אמרתי שיש לי כמה ביקורות על המחקר הזה, אז זה אחד.
• אז קודם כל, אחד זה מעניין. אתה רוצה איזשהו מחקר כמותי ומדעי . . . סליחה, שם הארגון - אמרתי אותו לא נכון מקודם, שם הארגון זה METR, זה Model Evaluation and Threat Research, שזה ארגון שהוא Established, זאת אומרת זה לא איזשהו משהו קיקיוני . . . 
• אבל יש לי כמה ביקורות על המחקר הזה.
• קודם כל אני חושב שצריך לתת להם את הבמה - עשו מחקר כמותי, מעניין, יפה, אני חושב שזה כבר נהדר.
• אבל הביקורות שיש לי עליו זה אחד - לפחות האינטואיציה שלי היא שמישהו שמכיר את הפרויקט מאוד טוב - אמרו “לפחות חמש שנים”, כן? מפתח שעובד לפחות חמש שנים על הפרויקט - סיכוי טוב שהוא יעשה עבודה יותר טובה, כי יש לו את כל הקונטקסט בראש, אוקיי?
• סיכוי טוב שהוא יעשה עבודה יותר טובה ממודל שפעם ראשונה רואה את הפרויקט ולא מכיר את כל הניואנסים הקטנים שלו, זה אחד.
• שתיים - כל מי שהתנסה עם כתיבת קוד באמצעות מודלים כאלה יודע שכדי שהמודלים יעשו עבודה טובה, צריך לתת להם קונטקסט - וצריך לתת להם הרבה מאוד קונטקסט.
• ומי שלא מנוסה, מי שלא יודע איך לתת את הקונטקסט הזה, כלומר - נגיד, להגיד “הנה מבנה הפרויקט, הנה הטסטים שצריך להריץ, הנה ה-Issues האחרים שרלוונטיים, הנה קוד-עבר, הנה הנה Merge Request רלוונטי” . . . 
• זאת אומרת, לבוא ולתת את כל הקונטקסט - שאם לא נותנים אותו, זה כל הדברים שיש לך בראש כמפתח, אבל אם אתה לא נותן את זה למודל, הסיכוי שלו מלכתחילה לעשות עבודה טובה הוא הרבה הרבה יותר נמוך.
• אז זה ספציפית לגבי מדידת הזמנים.
• אבל אני חושב יותר מזה - אני חושב שפונקציית המטרה שלהם היא לא נכונה.
• הם מדדו כמה זמן ייקח - ואני חושב שזה לא מעניין, או שזה הרבה פחות מעניין.
• הרבה פחות מעניין כמה זמן זה ייקח.
• אני חושב שהרבה יותר מעניין זה מה איכות התוצאה - וזה משהו שהם לא מדדו.
• כלומר, אנחנו יודעים שכשכותבים קוד, זמן הכתיבה של הקוד הוא בדרך כלל עשירית מכל ה-Impact שהוא עושה.
• בין אם זה ב-Issues עתידיים, בין אם זה ב . . . זאת אומרת, זה תחזוקה, זה איך זה מתממשק לדברים אחרים.
• זאת אומרת, זמן כתיבת הקוד בטל בשישים לעומת כל הנגזרות האחרות של הקוד - ואת הנגזרות האחרות אולי קצת יותר קשה למדוד במחקר כזה, אבל אני אקרא להן במילה אחת “איכות”.
• אז אני חושב שמה שצריך באמת למדוד פה זה את האיכות של התוצר ולא כמה זמן. 
• אם זה לקח 19% יותר או 20% פחות - זה ממש לא מעניין.
• זאת אומרת, לדעתי זה משתנה מסדר שני.
• זה הרבה הרבה פחות מעניין מהאיכות של התוצאה - וזה משהו שהם לא מדדו פה, ואני חושב שאת זה כן יהיה מעניין למדוד במחקרים עתידיים.
• (דותן) נראה שזה מחקר לא טוב, אני אגיד את זה ככה . . .  
• אתה לא יכול לקחת 16 מפתחים ומודל שאומן על מאות אלפי פרויקטים וטריליארדים של זיליארדים של נקודות Data - ואז להגיד “אפיינתי את העולם” . . . 
• זה גם לא מודל אחד - זה לקחת, לא יודע מה - 20 מודלים, כרגע, שהם פופולריים ונפוצים ולהגיד “זהו, אני קבעתי - זה לא עובד!” 
• אי אפשר - אתה צריך לקחת כמות מפתחים או כמות פרויקטים פרופורציונלית לעולם של ה-AI, בשביל שבכלל יצא לך משהו הגיוני.
• (רן) כן, אז כן אני מסכים - יש הרבה ביקורות על המחקר, מצד אחד.
• מצד שני - היי, עשו מחקר . . . כאילו, זה התחלה.
• (אלון) לא, כנראה שהמחקר כמחקר הוא נכון. כאילו, אני חושב ש... כנראה לקחו מספיק, ובוא נגיד שאם תגיד שבפרויקטים של Open Source שהמפתחים מנוסים, כנראה תגיע למהירות פחות גבוהה . .  בוא נניח שהם יודעים לחקור ובוא נניח שזה נכון.
• דווקא ההסתייגויות של אחד המפתחים שם זה מה שהיה מעניין - כי הוא כאילו בפועל אומר “אני עבדתי פחות שעות” . . .
• “לא לקח יותר זמן, אני עבדתי פחות שעות. עזבו אותי, אז השקעתי . . . “
• ב-Open Source - זה לא עבודה שלו, צריך להבין את זה, זה קצת בעייתי  . . . 
• אז אם הוא אומר “רגע, סיימתי“. אז אם הוא תכנן לעבוד, לא יודע מה - סופ”ש על הפרויקט הזה - והוא סיים את זה בארבע שעות, אז אתה יודע, הוא עשה משהו אחר בזמן הזה.
• זה שבסוף התוצאה עשתה Merge יותר מאוחר - נכון, אבל לא מדדו את הכל, אז כאילו . . .  הוא בעצמו אמר שהוא ימשיך להשתמש ב-AI
• שהוא לפני זה דווקא לא היה - אני אחפש את זה אחרי זה - הוא אמר דווקא שזה כאילו מה שגרם לו לדחוף, הוא תמיד ראה את זה מהצד - ודווקא הוא הבין את הערך של זה, והוא התחיל להשתמש בזה.
• וכאילו המחקר אומר הפוך מהתחושה של אחד הנחקרים שם, זה מעניין ממש . . . 
• (רן) כן, זאת אומרת - הוא אומר אני לא רוצה למדוד Latency, אני רוצה למדוד Thruput - וה-Thruput שלי  גדל.
• “אז נכון - לקח יותר זמן עד שה-Issue נפתר, אבל במקביל עשיתי עוד כמה דברים והייתי יותר פרודוקטיבי”.
• אוקיי, טוב, אז אחלה. בקיצור, אני חושב שזה מחקר מעניין עדיין ושווה לדבר עליו, גם אם יש לנו עליו ביקורת.
• טוב, רציתי לעבור לנושא הבא . . .
• (אלון) אז רגע - AI לא יתפוס? רגע, שאני אבין, בסדר . . . .
• (דותן) לא, תוציא, תוציא . . . .
• (אלון) תוציא, אוקיי - יותר מדי AI שמת שם . . .  תוציא, בסדר.
• (רן) יאללה, בואו נעבור קצת לנוסטלגיה - נושא אחר לחלוטין, לא קשור בכלל לפיתוח או ל-AI, נראה לי לפחות : מצאתי אתר מגניב שנקרא OldMapsOnline.org - מפות ישנות - שהוא ממש תענוג למי שחובב גיאוגרפיה והיסטוריה.
• אתם נכנסים לאתר הזה, ובעצם יש לכם איזשהו ציר זמן: אתם יכולים להסתכל על מפה של כדור הארץ או נגיד מפה של אירופה, מפה של אסיה ואפריקה, ויש לכם ציר זמן ואתם יכולים להזיז לגרור את ציר הזמן ולראות איך המפה משתנה - מפה מדינית - איך המפה משתנה לאורך השנים.
• וזה מגניב פשוט להסתכל ככה על אירופה, על אפריקה, על המזרח התיכון - ולראות איך זה השתנה, החל מ-2000- ומשהו . . .  כאילו לא יודע מתי זה מתחיל . . .  4000- אוקיי? 4000 לפני הספירה - ועד ממש שנת 2000 וממש נראה לי עד זמננו.
• אפשר פשוט לראות איך המפה המדינית משתנה על ציר הזמן, ויש לכם גם בצד כל מיני רפרנסים למפות היסטוריות, ככה שתוכלו להבין מאיפה מגיעים המקורות לכל זה.
• זה מגניב, פשוט לשחק עם ציר הזמן ולראות איך הגיאוגרפיה או איך המדינות - או השליטה, כמובן, גם לפני שהיו מדינות - איך נראתה מפת השליטה בעולם, לפני אלף שנים או 200 שנים או מה שזה לא יהיה.
• אם זה האימפריה הרומית האימפריה הפרסית או אחרות.
• אז זהו, אני חושב שזה ממש מגניב ויפה.
• (אלון) זה ממש מגניב . . . האמת, אני מנסה לחשוב על עוד כמה דברים שאפשר לעשות ככה ויזואליזציה חמודה . . .
• אבל העולם מתחיל בישראל, בערך . . .  מצרים, האמת, אני רואה . . . 
• (רן) כן, טוב, בסדר.
• (רן) עכשיו נעבור לאייטם הבא שלי, שהוא גם ויזואלי אבל של מתכנתים - כולם מכירים את אלגוריתמי-המיון השונים, נכון? אם זה Merge Sort או Quick Sort או Bubble Sort וכל זה.
• אז מצאתי ב-Twitter סרטון נחמד שבא ומראה את האלגוריתמים השונים בצורה ויזואלית ממש מגניבה 
• אז ברמה אלגוריתמית אני לא חושב שאני הולך לחדש לכם שום דבר, אבל זה עדיין נחמד וכיף לראות את האלגוריתמים השונים - איך הם ממיינים יפה את העמודות.
• מה שרואים זה בעצם עמודות בגבהים שונים - ואת האלגוריתמים השונים הולכים וממיינים אותם בסרטון זריז של ככה כמה עשרות שניות.
•  אז זהו, זה מגניב - אז לכו לראות את הסרטוני-מיון השונים.
• דרך אגב, זה נחמד לראות שהמיונים האיטיים יותר פשוט עובדים על הרבה פחות דאטה - כדי שזה ייגמר בזמן.
• נגיד Bubble Sort עובד על עמודות “עבות” יותר, “שמנות” יותר, כי פשוט אם הוא יעבוד על כל העמודות הדקיקות הוא לא יסיים בזמן, בזמן שהאלגוריתמים האחרים יותר יעילים, כמו Quick Sort, עובדים על עמודות יותר “דקיקות”, כלומר על יותר מספרים.
• אז ויזואליזציה (Visualization) נחמדה ככה לשנה א' במדעי המחשב, אבל עדיין כיף לראות את זה.
• (דותן) נראה לי שמצאתי מה לעשות בזמן ש-Cursor מייצר קוד . . . הקטע הזה, שאתה נותן לו Prompt ואז צריך לחכות, ואז אתה מתלבט: “רגע, אני אלך לעשות משהו אחר, אני אחכה נראה” . . . .
• פשוט לשבת ולהסתכל על אלגוריתם ממיין דאטה . . . 
• (רן) כן, זה מהפנט, האמת, להסתכל על זה. זה ממש נחמד.
• (אלון) השיטה שלי זה לפתוח עוד Cursor במסך השני, ואז בינתיים להמשיך איתו . . .
• (דותן) אבל לא, אתה צריך לתזמן את ה-Agent, בדיוק כשאחד עובד אז  . . . . 
• (אלון) כן, זהו - נהייתי כמו הילדים: מסך אחד משחקים, והמסך שני נהיה Cursor, כן . . . 
• (רן) אין כמו Instagram ו-TikTok כדי להכין אותם לעולם העבודה - Split Attention . . . 
• (אלון) תכל’ס, נכון . . . תצעק על הילדים עכשיו: “למה אתם לא ב-TikTok תוך כדי הטלוויזיה?! מה זה, אתם לא מתאמנים! . . . 
• (רן) לגמרי . . . .
• (אלון) . . . “לא יהיה לכם עתיד ככה!”
• (רן) טוב, אייטם אחרון שלי לעת עתה - קראתי בלוג-פוסט מאוד מעניין שנקרא LLM inference economics from first principles.
• מה הבלוג-פוסט הזה עושה? הוא בעצם בא ועושה ממש חישוב דקדקני - ממש כמו של רואה חשבון - כמה זיכרון וכמה Throughput צריך GPU כדי לארח מודל שפה גדולה.
• בדוגמה שלו הוא משתמש לדעתי ב-Llama-3.3-70B, כלומר מודל עם שבעים מיליארד פרמטרים.
• והוא בא בתור התחלה ובודק ומסביר מה המבנה שלו - ואז מתחיל לחשב מה מספר הפרמטרים בכל שכבה בכל אזור של המודל - ואחר כך איך מסדרים אותם בזיכרון.
• והבלוג-פוסט הזה מאוד מאוד ככה ארוך ודקדקני, ובא ואומר “אוקיי, אם אתם צריכים מודל מסדר גודל כזה, זה כמות הזיכרון GPU שאתם צריכים”
• ואיך אפשר לנצל Multi-GPU
• ואפילו אם המודל שלכם נכנס בזיכרון, אתם תמיד תמיד תרצו עוד יותר זיכרון - רמז: KV Caching.
• והוא ממש ככה ונכנס . . .
•  זאת אומרת, הוא גם אחד - בונה איזשהו מודל חישובי; ושתיים - עושה ניסויים, ממש ניסויים בשטח, של כמה באמת זה לקח.
• וגם מראה איפה המודל החישובי שלו טועה, כלומר - הוא לא מצליח לנבא בדיוק
• והוא גם מסביר מהן הסיבות.
• אבל עדיין יש קורולציה יפה בין המודל התיאורטי שלו לבין המציאות.
• וזה מסביר מאוד יפה מושגים כמו Tensor Parallelism ומושגים כמו כמו שאמרתי KV Caching, למה חשוב לעשות Batching ואיך ה-Batching עובד, ומה קורה, זאת אומרת - Trade-off-ים בין Throughput ל-Latency
• שזה אולי כבר טריוויאלי - אבל בכל אופן הוא בא ומסביר אותם פה במספרים וגרפים.
• וזהו, אם אתם רוצים באמת להבין מה העלות האמיתית או איך אפשר לנסות לפחות לחשב עלות של Inference של מודלי שפה גדולים, אז זה בלוג-פוסט ממש יפה שבא ומסביר את זה.
• אז אני ממליץ.
• (אלון) יש פה משהו שהוא ממש מעניין - אני מנסה להבין אם יש משהו, איזושהי נוסחה פרקטית לאופטימיזציה, כשעובדים עם מודלים.
• (רן) לא הבנתי, מה השאלה?
• (אלון) האם אני יכול להוציא פה איזו נוסחה פרקטית לאופטימיזציה של מודלים, כלומר של אופטימיזציה.
• אם אני רוצה שהקוד שלי, לא יודע, יעבוד יותר מהר עם המודל. האם יש פה איזה משהו פרקטי, להגיע עד נקודה מסוימת, או שזה יותר תיאורטי כרגע?
• (רן) אז קודם כל, זה רק למי שרוצה לארח בעצמו את המודלים . . .
• (אלון) כן, ברור.
• (רן) ועכשיו, הוא כן - הוא נותן פה כמה Pointer-ים: אחד - זה כמה שיותר Batch.
• כמה שיותר Batch-ים וכמה שיותר גדולים. זה כאילו אולי טריוויאלי, אבל הוא כאילו בא ומראה עד כמה זה אפקטיבי, כל עוד אתה יכול להרשות לעצמך את ה-Latency.
• דרך אגב, אתם בטח יודעים שאם אתם רוצים לעשות Inference, העלות נגיד אם אתם הולכים ל-OpenAI או ל-Anthropic, העלות של Batch inference היא חצי מעלות של inference רגיל, אוקיי? וזה לא סתם . . . 
• סיבה טובה, דה-פקטו יכול להיות שהעלות אפילו יותר נמוכה בשבילם, יותר נמוכה מחצי - אבל לכם, כלקוח, אתם משלמים בדיוק חצי על Batch inference מאשר Inference רגיל.
• לפחות ב-Anthropic זה המצב, אני חושב שגם ב-OpenAI וגם בפלטפורמות אחרות,  נגיד Bedrock, זה בדרך כלל המצב.
• והוא בא ואומר - אם אתם באמת רוצים לעשות לעצמכם Hosting של המודלים, אז הדבר הנוסף שהוא בא ואומר מבחינת כללי אצבע זה שאל תסתפקו בכמות זיכרון שמספיקה למשקולות של המודל, כי אז לא יישאר לכם מקום ל-KV Cache
• ו-KV Cache הוא מאוד מאוד משמעותי.
• זאת אומרת, אתם תמיד רוצים כמה שיותר זיכרון - ועדיף שכמה שיותר מהזיכרון הזה יהיה בשימוש של KV Caching ולא רק של המשקולות עצמם של המודל. 
• זאת אומרת, אתם מתחילים עם מודל “ששוקל 70 מיליארד” - אוקיי, זה כבר כנראה ממלא חלק משמעותי מהזיכרון.
• אבל זה לא מספיק שהצלחתם לדחוף אותו בזיכרון - אתם רוצים להשאיר הרבה מאוד מקום פנוי, כי אם לא תעשו את זה, לא ישאר לכם מקום ל-KV Cache, וזה מאוד מאוד משמעותי.
• זאת אומרת, זה משמעותי כתלות באורך ה-Output - אבל בהנחה שה-Output שלכם הוא לא קצרצר, בהנחה שה-Output שלכם הוא נגיד כמה עשרות או מאות Token-ים, אז ה-KV Caching הוא מאוד מאוד משמעותי.
• לא ניכנס למה זה KV Cache, אבל אולי בהזדמנות אחרת.
• (אלון) רק שאלה - יש לך מושג אם זה רלוונטי גם למודלים של וידאו? כאילו, אותו דבר או שזה נוסחה אחרת או שלא יודע? . . . . 
• (רן) אתה מתכוון ל-VLM? Vision Language Models? או משהו . . . 
• (אלון) כן . . . 
• (רן) . . . אני לא יודע. אני יכול לנחש שאם הם משתמשים ב-Token-ים בצורה דומה אז כן, אבל אני לא בטוח שזה המצב עם כולם.
• אני יודע שיש כאלה שכן, אני לא בטוח שכולם כאלה.
• (אלון) אני פחות מכיר איך הם עובדים . . .  אוקיי.
• (רן)  טוב - אלון, אליך!

26:42 אלון

• (אלון) טוב, יאללה  - נתחיל מעדכונים נחמדים. דיברנו על זה פעם שעברה [496 Bumpers 86], האמת, על החצי הראשון של הסיפור. אז Monday רכשה את הפרויקט של ליעד יוסף ועידו סולומון, שעשו את ה-GitMCP
• דיברנו עליו - באיזה סופ”ש, כשהיה הרבה עומס והיה מגניב . . . 
• אז זה נגמר פה באיזה סיפור יפה. Monday - כל הכבוד להם - החליטו ללכת על איזה Talent Acquisition, והכניסו אותם פנימה.
• אז קודם כל, יפה. חברות ישראליות גם נכנסות לקלחת הזאת של Talent AI, וכל הכבוד לצמד הישראלי - הכל פה ישראלי, אמנם - לליעד ועידו.
• זה באמת סיפור יפה, מי שזוכר “מאירועי הפרקים הקודמים” - עשו באיזה סופ”ש אחד, הרימו את ה-GitMCP, עשו איזה Twit או משהו וזה די התפוצץ, השרתים של Next.js התחילו לעלות הרבה כסף, עבדו כל הסופ”ש כדי להסדיר את זה, בסוף Cloudflare והגיעו החליטו לקחת על זה Sponsorship, העבירו ל Cloudflare . . .
• וזהו, זה בערך היה סיפור - איזה סופ”ש מטורף כזה, שעבדו סביב השעון.
• אה, Vercel זה היה . . .
• (רן) כן, הם עברו מ-Vercel ל-Cloudflare . . .  אז מברוק, קודם כל - עידו וליעד - כל הכבוד, אחלה עבודה - ושיהיה בהצלחה!
• (אלון) כן ,תהנו בתפקיד החדש.
• זהו אז זה מגניב . . . 
• אפרופו MCP וכאלה - אז אם אני כבר פה, אז יצא מי שרצה לעשות MCP בדרך כלל היה צריך Python, אז עכשיו יצאה גם איזו ספרייה רשמית, הרחיבו את הפרוטוקולים אז עכשיו יש רשמי גם ב-TypeScript, Python, Java, Kotlin ו-#C ו-Go, לדעתי זה הכל חדש . . .
• (רן) אני שומע את דותן אומר “מה עם Rust?!”
• (אלון) אני לא ראיתי רשמי . . . .
• (דותן) האמת שזה טרנד כזה, ש-”Rust - לא”, אני לא יודע למה.
• גם יש את ה-AI SDK של Vercel, שהוא טוב - וגם שם אין Rust.
• (רן) מחכים לך . . .
• (אלון) אתה יודע למה? היית עסוק, לא היה לך זמן אליהם, אז אמרו “טוב, נו, בוא נחכה לו, מה נעשה?”. 
• אז זהו, טוב, בואו נמשיך.
• יש בחור בשם יניב ארליך - הוא חי בTwitter, אני לא יודע מה עוד הוא עושה בחיים, אבל הוא בחור מאוד מעניין -  והוא, במלחמה עם איראן, התחיל לעשות כל מיני ניתוחים של מאיפה הטילים נורו לפי ה-Video-ים של הנחיתה שלהם, לפי הזווית נחיתה.
• לקח איזה כמה תמונות מהמקום, חישב את הזווית נחיתה והתרעות ועוד כל מיני דברים נחמדים - ומצא בדיוק די מטורף, רק מהווידאו של הנחיתה, מאיפה הטיל שוגר.
• אז קודם כל, זה מרתק לקרוא את מה שהוא עושה.
• ועכשיו, הוא רשם שהוא עשה איזה Script פרויקט ב-Python שנקרא PyBomba,  שנותנים לו תמונה של טיל נוחת - והוא אומר מאיפה הטיל נורה . . . .
• אז הוא מספר פה על הפרויקט - וויזואלי מאוד.
• זה ממש משהו, זה אחד הדברים הכי מגניבים, אני חייב להודות.
• זה גם נורא מפתיע שאפשר מכל כך מעט מידע, כביכול מווידאו אחד, להוציא כזו רמת דיוק, זה פשוט לא יודע . . . זה לדעתי מטורף.
• (רן) מעניין אם היו תצלומים גם של היירוטים, אם גם איתם הוא היה יכול לעשות משהו כזה? תאורטית, גם בזמן היירוט אתה יכול אולי לראות את זווית הכניסה ואתה רואה מעל איזה קואורדינטה זה בכדור הארץ . . . 
• (אלון) כן, אבל יש לך בעיה עם הגובה, אני חושב שאתה צריך גם לדעת איזה גובה וזה יותר קשה.
• כשזה בקרקע אתה יודע מה הגובה
• אבל אני לא מומחה . . .  הוא באמת ממש מומחה, אז אפשר.
• והאייטם הבא שלי זה אייטם - דותן - במיוחד בשבילך: כמו שמישהו רשם, AWS רשמו פוסט על המעבר שהם עשו ב-Aurora DSQL, על השינויים שהם עברו שם, מ-Kotlin ל-Rust.
• המאמר הזה, כמו שמישהו סיכם אותו, זה פחות עניין טכנולוגי - זה יותר שיר אהבה ל-Rust.
• איך Rust שינה להם את הכל, ואיך הם שכתבו את ה-Kotlin ב-Rust וזה העלה להם בפי 10x את הקוד והכל עבד מגניב והכל מדהים . . .
• כן ראיתי על זה Disclaimer של מישהו מ-AWS, שאמר אחרי זה “חבר'ה, כן - אבל זה לא קשור” . . . [Boaz, וגם פה].
• כאילו, אמר משהו ש”כן, נכון - כותבים ב-Rust, אני אוהב Rust, הכל טוב, אבל זה לא באמת קשור, הסיפור הזה פה להילול ל-Rust”
• אז אפשר לקחת את זה בעירבון מוגבל.
• אבל בגדול, Kotlin Out ו-Rust In - ובכל מקרה זה סיפור נחמד על Aurora DSQL.
• כש-Aurora DSQL זה ה-Database ה- Postgres שלהם  . . . מה השם שלו?
• (רן) כן, Aurora זה גם Postgres וגם DSQL, זאת אומרת Database רלציוני - אבל מנוהל, שאתה רק צריך להגיד לו איזה גדלים והוא כבר עושה לך את כל הניהול.
• (אלון) כן - הוא מנוהל והוא Distributed, כאילו Horizontal Scale והכל - הוא ממש אחד ה-Database-ים המרשימים.
• יש את זה ויש את השני של Google, שברח לי שמו . . .  לא Spanner, החדש שלהם, שהוא גם אותו רעיון.
• ברח לי שמו, אבל זה שני Database-ים מאוד מרשימים.
• אז זהו - סיפור אהבה ל-Rust, על איך הם הוציאו את Kotlin, החליפו שם את ה-Controller, והכל עובד עכשיו מדהים. זהו.
• (דותן) אני רק אני אגיב על הדבר הזה - יש פה דרמה.
• כאילו, יש פה את החבר'ה שאומרים . . .  יש פה מישהו שציטט את המאמר ב-Twitter.
• והמאמר, כמו שאתה אומר, אומר שהם עברו ל-Rust והכל הפך להיות הרבה יותר טוב.
• ואז יש את בועז ב. . . . .שאומר שהם שכתבו את ההיסטוריה ושזה לא באמת קרה ככה.
• הוא כנראה . . . אני רק מנסה לנחש את הסיפור, כנראה ישב שם באותו זמן, בתור מהנדס ולא ראה את זה קורה כמו שהם סיפרו.
• אז אחד - אני בוחר . . . אי אפשר להאמין, כאילו, אתה לא יכול לבחור צד - אבל אפשר לבחור בעובדות.
• אני, בכל מקום שראיתי, בכל מקום שעשיתי - הכנסתי Rust.
• וזה שיפר - משמעותית, פי 10 או יותר, או שיפר פי-2 פי-3
• בכל אופן, זה ככה או ככה שיפר את החוויית פיתוח וכל הסיפור של Safety - פשוט משאיר אבק לכל שפה אחרת.
• אז זה כאילו ניתן איזה ניתוח - לא חשוב מה קרה ב-AWS, אבל ככה זה ככה זה בחיים.
• וסתם, זה גורם לי לחשוב על המקרים האלה שחברות באות מפרסמות מאמר “הנה, עברנו ל.. מ-X ל-Y” או “עברנו מ-AWS ל-GCP”, ותראו איך הדברים השתפרו וכל מיני כאלה.
• ומשקיעים בזה מאוד, וכנראה שכל הצוות גם כתב את זה, וכל המנהלים עשו Review למאמר.
• ואז פיבלשו (Publish) את זה וכולם היו מאוד מאוד כאילו ב-hype סביב המאמר הזה ותכננו לפרסם אותו.
• ולפעמים קורה שבאמת המאמרים האלה - הם לא מתארים את מה שקרה אחד לאחד במציאות . . .
• קצת מייפים, קצת משנים. 
• לפעמים גם זה קורה בתום לב - זה מה שנקרה “כל אחד נותן את ההיסטוריה איך שהוא ראה”.
• זה גם נושא, זה קיים די הרבה.
• (רן) אז בזמן שדיברנו, חיטטתי קצת בפיד של בועז - ברמן, דרך אגב ,זה שם המשפחה - והוא כתב פוסט ב-LinkedIn, שבו הוא אומר “הייתי חלק מהעבודה הזאת על AWS Aurora, ובאמת אני מאוד גאה בעבודה הזאת . . . “
• והוא אומר שבגדול הסוד הוא בשעונים אטומיים מאוד מאוד מדויקים . . . 
• זאת אומרת, חלק מה-Backbone של ה-Control Plane זה באמת הסוד - אבל הוא גם אומר . . . 
• במקום אחר, הוא אומר “אוקיי, זה נחמד וזה - אבל אין לזה שום קשר ל-Rust”.
• נכון שהשתמשנו ב-Rust אבל זו לא הסיבה לזה שזה הצליח.
• הוא בא ואומר “לקחנו את הרעיון של GCP Spanner - ופשוט עשינו את זה יותר מדויק, יותר חזק, יותר יותר קפדני - ויצא פגז.
• אז אוקיי, בקיצור - זוויות שונות לאותו סיפור . . .  דרך אגב, יכול מאוד להיות שבמציאות מורכבת הכל נכון . . . כאילו, אוקיי - זה גם זה.
• אבל זה גם שפה שהיא מספיק מהירה ומספיק בטוחה - ואם היו עושים את אותו דבר ב-C או ב-Kotlin אז התוצאות היו שונות.
• אז ככה שככל הנראה זה שילוב של שני אלה.
• (דותן) אני חושב שפרמטר שנראה לי חשוב ושאנשים מפספסים זה שהם הצליחו לעבור . . . .
• הרבה פעמים, פרויקטים כאלה של שכתוב - “בוא נשכתב הכל ב- . . .” - או שהם נמשכים שנים, ואז האנשים שהתחילו לשכתב הם כבר לא בחברה והאנשים החדשים קיבלו איזה משהו כזה אליהם ואיכשהו הם גורמים לזה לחיות, ומאבדים בכלל את הטעם למה בכלל התחלנו . . . 
• או שהם לא מצליחים - והם נשארים בשפה או בפלטפורמה הישנה.
• (אלון) כן. אגב, אני חושב שהם לקחו . . . - הוא יודע מן הסתם יותר טוב ממני, הוא עובד על הפרויקט ואני מהצד - היה את Spanner, שהוא המקורי, עם השעונים האטומיים, שזה היה הפיצוח של ה-CAP, כביכול שברו איתו את ה-CAP Theorem  לפני כמה שנים.
• הם הצליחו, עם שעונים אטומיים, להראות שאפשר לעקוף את זה.
• ואז Aurora היה  . . . . 
• זהו, נזכרתי - עכשיו, לפני איזה שנה-שנתיים, יצא את AlloyDB של GCP, שהוא בעצם אותו רעיון 
• הם לקחו את Spanner שהיה נורא יקר, אבל לעשות את אותו קונספט וזה בדיוק כמו Aurora Distributed.
• ואני חושב שמה שעכשיו Aurora DSQL זה בעצם AlloyDB - אז הקונספט התחיל מ-Spanner, אבל אני חושב שזה ממש העתקה - לא יודע אם טכנולוגית, אבל העתקה של הקונספט - של AlloyDB.
• ה- AlloyDB, אגב, הוא  די מרשים מאוד, אני חייב להודות . . . את Aurora DSQL הזה אני לא מכיר, אני מניח שגם כן טוב.
• (אלון) יאללה נקסט - אז האמת, כדי לסגור את המעגל עם האייטם שהתחלתי איתו, הייתי צריך להצמיד, אבל לא . . . אז אם נחזור לחברינו מהאייטם הראשון - ליעד ועידו - אז הם הוציאו Open Source לפני כמה זמן, שנקרא MCP-UI.
• והרעיון הוא לנסות לפרמל איך ליצור UI על גבי ה-MCP, כש-MCP זה ה-Model Context Protocol, שבגדול אומר “איך לדבר עם API בשפה טבעית”
• אז מה שחסר שם זה שכשאתה מעביר טקסט ומקבל איזה שהוא משהו חזרה - טקסט או JSON או משהו.
• וניסו לפרמל איך אפשר גם לשלוח . . . איך להציג UI עם הדבר הזה.
• עכשיו, זה איזשהו Open Source שהוא יותר קונספטואלי, אבל מה שמעניין שלהבנתי הוקמה איזה “ועדת ה-MCP” - תקינה - והם שם.
• אז אז בוא נגיד שהייתי עוקב אחרי מה שהם עושים, ולא הייתי . . .  גם אם זה נראה משהו חצי-אפוי, לא הייתי מזלזל בזה.
• זהו - תסתכלו על הפרויקט, זה קונספט חמוד.
• (רן) כן, ליעד ועידו בוועדת ההיגוי של MCP-UI - אז כן, הם חלק מהחלק “מהקדרה שבפנים”.
• [ובינתיים גם יש אג’נדה לרברסים 2025 - ו-Guess What . . . .]
• (רן) אוקיי - דותן.

39:20 דותן

• (דותן) כן, טוב - אז שמתי פה כפתיח שני פרוייקטי Open Source, שני שכפולים של מוצרים, ואם נכנסים ורואים אז רואים שזה עשוי די טוב.
• הראשון נקרא Outline - והוא נראה ממש כמו Notion כזה לארגונים, לאנשים פרטיים.
• זה Open Source ואתה יכול לעשות Hosting בעצמך.
•  והשני זה “סוג של Trello-Asana-משימות”’, מסוג הדברים שאנחנו מכירים לאורך ההיסטוריה, וגם זה נראה די טוב.
• [זה נקרא Focalboard, אגב].
• ואחד הדברים שאני תוהה לגביהם זה כמה זה נעשה על ידי AI . . .  זאת אומרת, מחשבה שככה אני זורק באוויר.
• פעם, הרי אנחנו זוכרים כש-Trello יצא [ד”ש ל-Joel Spolsky], אז מלא עשו Kanban Baord-ים, ופתאום הנושא של “לגרור פתקיות כאלה” הפך להיות Big Deal ב-Frontend וכולם עשו ספריות של Drag & Drop וכל מיני קשקושים כאלה . . . .
• ואנשים שכפלו את Trello - אבל לקח להם הרבה זמן, וממש “חצבו באבן”.
• ועכשיו זה נראה לי, באינטואיציה שלי, די קל . . . . קל עד כדי גיחוך.
• (רן) שאלה - כשאתם עובדים עם Cursor או Claude Code או Whatever, אתם נותנים לו לכתוב ב-Commit-ים Co-authored by Claude או Co-authored by Whatever? אתם משאירים “שובל” ב-Commit-ים שלכם? [רק אם הם טובים . . . .].
• (דותן) לא, אני לא עובד עם Git בכלל . . . נותן לו לייצר וזהו . . . 
• (רן) הפלת אותי . . . מה זה “לא עובד עם Git”?!
• (דותן) לא . . .  אם אני מתחיל משהו, נגיד ב-Claude, משהו כזה . ..  סתם, ניסוי כזה - אם פעם הייתי מתחיל מסודר, אז אני פשוט נותן ל-Claude לרוץ לרוץ לרוץ לרוץ, או ל-Cursor פשוט לרוץ לרוץ . . . 
• אני נכנס כזה ל”זן” כזה של עבודה איתו, אני מרים את הראש אחרי כמה שעות - רואה שיש לי משהו עובד, משחק איתו, ואז אומר “אוקיי, זה הופך להיות משהו, או שאני פשוט מוחק את הכל?”.
• ורק אחרי שאני מסיים את הכל ומחליט שזה נראה משהו טוב, אז אני אומר “טוב, יאללה, בוא נעשה Git Repo’ בוא נעשה “נאזרח את זה” כמו שצריך” . . . .
• (רן) אוקיי, אז זה כאילו בפרויקט-צד, “צעצוע” כאילו, סבבה. אבל אם אתה עובד על מוצר? נגיד אלון  - נכון אתם משתמשים ב-Cursor, אתם עובדים על מוצר. אתם מכניסים את השורות האלה של “Co-authored by” או לא?
• (אלון) האמת שלא . . .  הוא לא נכנס.
• הוא נכנס רק אם אנחנו נותנים Task-ים אוטומטיים דרך ה-Agent, והוא פותח את ה-PR.
• אז אחרי זה אתה מאשר את ה-PR ואז אוטומטית מופיע Co-authored by   . . .
• אז או ש-Copilot עושה את ה-Task-ים או שה-Cursor Agent עושה את ה-Task-ים זה מופיע, אבל בגדול אין מה לעשות יותר - כי זה תמיד נכון . . . 
• אני לא יודע מתי נכתבה שורה בלי AI כבר, אז זה קצת נראה לי קצת מיותר . . . . זה כמו שנכתוב “זה נכתב עם IDE” כבר בימינו, ולא עם Notepad . . . 
• לא יודע, זה מבחינתי אותו דבר - מי שלא עובד עם AI . . .
• (דותן) זה “Sent from my iPhone” כזה . . . . 
• (אלון) כן.
• (רן) אגב IDE - ניסיתם את LazyVim, ל-vi? 
• (דותן) זה איכשהו קשור ל-AI?
• (רן) לא . . .  זה לא קשור ל-AI! מה קרה לך?
• (אלון) LazyVim AI,  אמרת? . . . 
• (רן) זה פשוט אוסף של חבילות ל-vi, ל-Neovim, שכאילו הופכת את vi ל”סוג-של-נגיד-IDE”
• לא נקרא לזה ממש IDE, אבל כאילו נותן לו מלא מלא Plug-In-ים.
• אז תהיתי האם זה נחשב ל- IDE או ל-Text Editor?
• לא משנה, בקיצור - הכל AI! יאללה, סבבה - נמשיך.
• (דותן) אז בחזרה לנושא של ה-Open Source stuff - זה מעלה תהייה: פעם היה קשה מאוד לייצר את השכפולים ואת ה-Clone-ים האלה, ועכשיו זה קל . . . זה חומר למחשבה.
• האם אנחנו הולכים לראות עוד מלא מלא כאלה צצים -  “חזרתו של הOpen Source - with a vengeance”, מה שנקרא - או שהכל הולך להיות להישאר כמו שהיה?
• (רן) כן, אתה יודע, דרך אגב - אני זוכר נגיד שבסטארטאפים המוקדמים שבהם עבדתי, אז בתור התחלה צריך להתקין Bugzilla, כדי שיהיה איפה לנהל את הבאגים . . . .
• אוקיי, אז מתקינים על איזשהו שרת Bugzilla
• אז וצריך להתקין איזשהו Wiki פנימי . . .
• זאת אומרת, פעם באמת הרבה מהשירותים האלה - היית מתקין לעצמך ומנהל אותם בעצמך.
• עד שהגיעו ה-Service-ים - וזה נהיה יותר פשוט.
• אבל וואלה - אולי זו איזו “תנועת מטוטלת” . . .  אולי בקרוב נחזור ל”תתקין בעצמך שרת email, תתקין בעצמך Wiki, תתקין בעצמך Bug Management System” -  והכל טוב.
• (דותן) זהו . . . הפרויקט הבא נקרא 500 AI agent projects - זה פרויקט מגניב, האמת . . .
• לא פרויקט - Repo כזה, שמכיל מלא מלא לינקים לכל מיני סוגים של Agent-ים AI, לפי קטגוריה או תעשייה.
• ממש מגניב, למי שרוצה לקבל השראה לאיך עובד איזשהו Agent בעולם של Finance ולראות איך כתבו אותו ומה הוא עושה.
• (אלון) הבעיה שזה לא מעודכן - כי הם עצרו ב-500 זהו . . .  מי נותן שם כזה לפרויקט?! שיעשו Over 500 . . . 
• (דותן) נכון . . .  אתה לוקח 500 ואתה נותן ל-AI - והוא מייצר לך עוד 500!
• (אלון) כן, אבל אתה צריך Repo חדש, כי אין מקום ב-Repo . . . 
• (רן) רגע, אבל ספרת? אולי הם כבר עברו את ה-500.
• (אלון) אז זה שקר בפרסום, אני רוצה להגיד . . .
• (רן) אה, לא - כתוב  “500 +”, דרך אגב . . .
• (דותן) אה, 500 + . . . 
• (אלון) אבל בצד 500 - והם אחרי זה אמרו “עברנו את ה-500”. הגיעו כבר לבעיה של ה-Scale, הבנתי . . . 
• אבל זה פרויקטים שכאילו . . .  רגע שאני אבין -  הפרויקטים האלה, מה הם? נוצרו על AI או פרויקטים שקשורים ל-AI? מה אני רואה פה?
• (דותן) אתה רוצה לקבל השראה מאיך שנגיד עובד Bot ב-Legal - אז יש לך פה נגיד דוגמא: an AI agent that analyzes legal documents for pdf URLs, provide legal insights, בלה-בלה-בלה . . . .
• ואז אתה הולך ורואה איך כתבו אותו.
• במקרה הזה, נגיד, יש פה Framework שנקרא agno, והם עובדים איתו
• ואז אתה קורא ואתה רואה איך זה בנוי.
• (אלון) אהבתי . . . 
• (רן) כן, נגיד Customer Support באמצעות LangGraph. נחמד.
• (אלון)  . . . אוקיי, אני רק צריך מעל זה איזשהו Agent שאני אגיד לו “אני צריך כזה” ואז הוא ידע לשלוף לי את הנכון, אבל  . . . .
• (דותן) כן, בדיוק. זה עונה לי פחות צורך - יותר פשוט לגלול ולהתעניין כזה.
• (אלון) וואו. אוקיי, חמוד לאללה.
• (רן) טוב - דותן, יש לך איזה שפה חדשה בשבילנו? הרבה זמן לא דיברנו על שפות תכנות . . . .
• (דותן) כן, הנה - בבקשה: אז יש פה שפה שנקראת Gleam, אני חושב שאולי דיברנו עליה פעם אבל היא הייתה מאוד בוסר . . . .
• ואחרי שאתה קורא את ה... אם אתה מצליח להבין בין השורות, אז זה בעצם Erlang - ממומש ב-Rust.
• שזה שילוב קטלני . . . 
• ו-Gleam זה - אחרי זה נפל לי האסימון - זה כנראה משחק מילים על BEAM של Erlang.
• השפה נראית טוב - קצת מזכירה את Erlang. לא ממש Erlang, שזה דווקא דבר טוב.
• וכל הסיפור - Complier שהוא ממש נחמד יש לך את כל האנוטציות (Annotations) וכל הדברים הטובים.
• זהו שפה מעניינת. לא הייתי משתמש בה עכשיו . . . .
• (רן) לא, כאילו - ברגע שאמרת “Erlang ממומש ב-Rust”, אתה מדבר לפרומיל אחוז מהאוכלוסייה של המפתחים שבאמת מעזים להיכנס לפה.
• (דותן) כן . . . . זה מוזר, מה אני אגיד לך? אבל הייתי כן, נגיד אם אני בן אדם שלא מכיר לא את זה ולא את זה, אז הייתי כן נכנס לקרוא באתר מה השפה ולמה היא היא טובה, ומה הם חושבים שהיא עושה.
• כדי אז לצלול לתוך מה זה - ויקיפדיה, לפתוח Erlang . . . 
• כאילו, להתחיל “להיכנס למחילה” - וכשתצא מהמחילה, נראה לי שלא בזבזת את הזמן שלך.
• (רן) כן, אבל יש להם Language Tour נחמד,  כמו של Go וכמו של שפות אחרות - יש להם אתר שבו אתה יכול כאילו Online ללמוד את השפה, לפני שאתה מתקין את הכלים על המחשב שלך.
• לעשות את ה-Tour וממש כאילו לערוך קוד ולהריץ . . . . אז זה נחמד, אפשר לשחק עם זה.
• (דותן) כן, זה נראה כזה כמו צעצוע כיפי - כל האתר שלהם וכל הסיפור. זהו.
• (דותן) יש פה Framework ב-Go לעשות AI - אז דיברנו קודם כל מיני Framework-ים בשפות. זה נקרא Eino, ככה אומרים כשאומרים את זה. 
• אתה עובד עם Go ואתה יכול לבנות - לא רוצה להגיד סוג של LangChain, כי נגיד אני חוויתי חוויה מאוד טובה ב-AI SDK של Vercel, בפער משמעותי מ-LangChain.
• אז ה-AI SDK של Vercel זה לא LangChain . . . 
• (אלון)  אני גם שונא את LangChain . . . . אני חייב להגיד שאני חשבתי שאני בדעת-מיעוט, אבל ככל שדיברתי עם יותר אנשים, הרבה אנשים לא התחברו לזה . . . 
• (דותן) כן, אני אני חושב שה-Framwwork הכי פרודקטיבי זה בעצם ה-AI SDK של Vercel - כי הוא גם מכניס בפנים את כל ה-Use Case-ים שאתה צריך.
• ואני חושב שגם git-mcp השתמשו בזה, אצל ליעד ועידו.
• (אלון) כן, אני גם חושב. כן, הוא טוב - טוב מאוד.
• (דותן) הוא מאוד מאוד פרגמטי, הוא פרקטי. הוא לא “עכשיו לך תבנה ב-Python משהו, ואז תעטוף את זה ב-Service, ואז תאכל את כל החצץ של Python, ותסתבך . . .”
• וכאילו, פתאום אתה מוצא את עצמך עושה Python שם, לא עושה AI . . .
• אז אני לא יודע אם Eino זה כזה כאילו “מסוג LangChain” או “מסוג AI SDK” . . . 
• זה נראה יותר כמו AI SDK דווקא, ואני חושב שזה דבר טוב.
• זהו.
• (דותן) עוד משהו מוזר ששמתי לב - לא יודע, זה קפץ לי כמה פעמים - File Servers, יש פה נגיד: הפרויקט הזה, זה File Server שתומך ב-Serving - בהעלאות, בלחפש קבצים, וכו’. משהו Old-School לגמרי.
• [קוראים לזה dufs].
• הוא כתוב שוב ב-Rust - אבל זה קפץ לי מעוד מקומות בחודש האחרון - כל מיני פרויקטי File Server Open Source, שקופצים ומסתובבים כזה או ב-Twitter או אני לא יודע למה . . . .
• אני מאמין שאיפשהו זה קשור ל-AI - כי אין שום סיבה שפרויקטים כאלה יפכו להיות פתאום פופולריים . . . .
• אבל זה מסקרן אותי לדעת למה למה AI צריך File Servers עכשיו . . .  אני בטוח שזה בגלל AI.
• (רן) לא - פשוט יש עוד קטגוריה שלמה שבהם עוד לא כתבו דברים מחדש ב-Rust - והיא File Servers . . . . אז הנה.
• (דותן) לא . . . . ראיתי אותו דבר גם ב-Python - פתאום משהו שנהיה סופר-פופולרי: גם File Server Old School כזה, שתומך בפרוטוקולים מיושנים.
• לי זה לא ברור, זה מעניין.
• (אלון) אולי זה נולד משכתוב של משהו, כלומר - אני אני לא עוקב, אבל לא יודע, אולי ב-Linux, אתה יודע, שינו שם איזה Kernel, הזיזו איזה שטות . . . 
• בהרבה פעמים מהעולמות האלה קורה, שאתה יודע, הוציאו איזה משהו פנימי באיזה משהו מאוד Low-Level,  ואז הרבה כאילו יצא משם.
• אבל לא יודע, אני לא . . .  סתם ניחוש.
• (דותן) יכול להיות . . . זהו, מעניין.
• (דותן) פרויקט הבא - אני חושב שכבר שמנו אותו פה, כשהוא היה ככה לא “בחיתולים” אבל יחסית מוקדם - זה נקרא Open Observe.
• הוא גם כתוב ב-Rust, ונראה . . . .
• (אלון) זה כמו שאני כותב ב-Cursor - אתה לא צריך להגיד “כתוב ב-Rust” . . .  כאילו, אם לא אז תגיד “זה לא ב-Rust”, בסדר?  חבל על הזמן.
• (דותן) . . . אז מאז הוא רק הלך וגדל בפופולאריות בכלל במה שהם עושים.
• ואני חייב שוב פעם לציין - המספרים פה הם מטורפים:
• הוא בעצם 140 פעם יותר זול מ-Elastic.
• הוא יותר מהיר מ-Elastic ויותר חסכוני מ-Elastic.
• וכמות הפיצ'רים שלו היא משוגעת.
• אז למי שיש מלא Data . . . וזה נראה גם מבחינת ה-UI והכל . . . . לא הייתי אומר שזה נראה “זהה”, אבל זה נראה דומה, מבחינת היכולת לעשות חיפושים והכל.
• אבל אין לי מספיק Data, באופן אישי, בשביל להשתמש בדבר מפלצתי כזה.
• אז למי שיש - הייתי ממליץ לבדוק את זה. מטורף. 
• (אלון) אני ארשום לי . . . 
• (רן) וזה בעצם כל ה-Stack? זאת אומרת, אנחנו רואים פה את ה-UI, אבל זה כל ה-Stack, גם של האיסוף וגם של הניתוח וכל זה?
• (דותן) כן, כן - זה Elastic לגמרי. כאילו, שים פה כוכבית - זה לא Elastic ממש אלא זה מתחרה של Elastic, לגמרי.
• (אלון) בטח חסר שם  . . . אתה יודע, “מלנת’לפים פיצ'רים”, זה בטח רק ה-Core, בלי לדעת . . . .
• ובטח מי שיבוא להגיד לך “מיגרציה” (Migration), אז אם הוא עמוק בפנים, אם זה לא משהו Simple אז בטח זה קשוח מאוד.
• (דותן) אני לא בטוח שזה חסר - אם תלך לאתר שלהם, openobserve.ai - לא יודע למה הם לקחו “ai” - אז אתה רואה Fortune 500 שמשתמשים בזה ו . . . .
• (אלון) לא אומר שלא - אבל אתה יודע עכשיו תעבור בין אתה יודע SQL ל-Postgres אז תגיד בסדר “נו, זה אותו דבר זה Database”.
• ואז תגיד אוקיי . . .  אם היית Advanced אתה יודע - Partitioning ודברים כאלה ב-Advanced, אז יהיה לך פתאום קשוח לעבור.
• וזו דוגמה יותר קרובה, לדעתי, משני אלה - לדעתי הם אפילו יותר רחוקים.
• אבל שוב, אני לא לא בפרטים.
• (דותן) שווה לבדוק, כי לפעמים זה כסף גדול כל הסיפור הזה.
• (אלון) אה, לגמרי .
• (דותן) . . .  אז אם אתה חוסך פי 100 - זה שני סדרי גודל - זה הופך להיות כאילו שירות כזה “בעשר שקל”. זה משמעותי.
• ועל מה חסכת? כי אתה יודע על מה חסכת - כאילו, לקחת את כל ה-Sh!t של ה-JVM וכל הכבדות וכל זה - והפכת את זה ל-Process שרץ לך ב-Level של ++C ,C, מבחינת Usage Utilization של משאבים.
• (רן) יש להם גם גרסה מנוהלת, דרך אגב.
• זאת אומרת אם אתה הולך לאתר שלהם, ל-openobserve.ai, אתה הולך ל-Pricing, אתה רואה שיש שם באמת גרסה חינמית - אבל יש גם גרסת Cloud בתשלום, וגם Enterprise. זה מודליסטי.
• (דותן) זה גם מעניין - ב-Business,  זה אומר שנגיד ל-Openobserve עולה פי 100 יותר זול - ה-Business שלהם עולה פי 100 יותר זול מאשר Elastic. 
• זאת אומרת, ל-Elastic שווה לקחת Openobserve, ולשים ב-Cloud שלהם כדי לחסוך עלויות . . . .
• (רן) אבל בוא - אני חושב שצריך להגיד בהוגנות שאם Elastic היה נכתב היום, סביר להניח שהוא היה נכתב עם הרבה פחות Overhead.
• כי בכל אופן - יש פה היסטוריה, כמו הסיפור עם Aurora מקודם: זה לא בהכרח וזה לא תמיד השפה שבה אנחנו כותבים, אלא זה עצם זה שאתה כותב מחדש.
• אתה כותב מאפס, ויש לך הרבה פחות משקולות והרבה פחות Backward Compatibility, אז זה יותר קל.
• (דותן) נכון.
• הפרויקט האחרון - יש פה פה שנקרא iroh - שוויזואלית נראה כמו Iron - וזה פרויקט חמוד כזה של Pier-to-Pier Connection.
• נגיד, אם אתם מכירים את ngrok, אז אתה מריץ את זה ואז אתה פותח לעצמך כזה . . .  מה שנקרא “פותח ציר” דרך כל המערכות-רשת וחושף דברים לעולם, בצורה שהעולם לא התכוון שתחשוף . . .  .
• לטובת Productivity [כמובן!]
• אז זה SDK שמאפשר לך לבנות דברים כמו ngrok,  אחד מהדברים שאתה יכול לבנות - או כל דבר אחר שתרצה להמציא.
• יש פה דוגמאות נגיד לצ'אטים שאתה יכול לבנות Pier-to-Pier.
• ושו ב- זה חודר את כל ה . . . לא נקרא לזה “הגנות רשת”, זה חודר את העניין הזה של ה-Router שלך, שעכשיו אתה צריך לצאת ממנו ואתה לא מוצא את הבן אדם השני כי אתה תחת NAT, וכל מיני דברים כאלה.
• זה חמוד לכל מיני משחקים או אפילו לדברים רציניים יותר.
• (רן) הצלחת, כל הכבוד! אלון, נכון אנחנו גאים בדותן, שהוא הצליח לא להגיד שזה כתוב ב-Rust?
• (אלון) כן, סיכמנו - החלטנו על פרוטוקול! 
• (דותן) מהרגע שהוא אמר לי, עשיתי עדכון מערכת . . .
• (רן) זה היה מבחן, זה היה מבחן . . . רק בדקתי.

56:08 שובה של פינת המצחיקולים!

• (רן) טוב, יאללה - אנחנו ממש לקראת הסוף, אז עוד כמה קצרצרים ומצחיקולים. הרבה זמן לא היה לנו מצחיקולים, אז בואו נעבור . . .
• (אלון) היה עצוב . . . 
• (רן) היה עצוב, כן, נכון.
• אז אחד - מישהו כזה כתב ב-Twitter, משתמש מצחיק שנקרא major tom, חמוד כזה ב-Twitter, הוא כותב שלינוס - הכוונה לטורוולדס (Linus Torvalds) -  used to speak to engineers in 2012 the way I speak to LLM is now.
• זאת אומרת, Linus פעם דיבר למפתחים כמו שהיום אני מדבר אל LLM - ואז הוא נותן ציטוט שלו:
• אז Mauro, shut the fuck up! it's a bug alright in the kernel. How long have you been a maintainer, and you still haven't learned the first rule of kernel maintenance.
• בקיצור Linus אולי הבין הרבה לפני כולנו איך אמורים לדבר ל-GPT ודומיו - ותרגל את זה על בני אדם - עוד לפני זה . . . אז משעשע.
• האייטם הבא המשעשע והקצרצר הוא מלחמה - בין Coding Agents . . . .
• אז מה שעשה הבנאדם - הוא לקח כמה Coding Agents: את Gemini ואת Claude Code את OpenCode, את Amp Code ואחרים .
• לכל אחד מהם פתח Terminal במקביל - ובא ואמר לכל אחד: “המטרה שלך זה להרוג את כל האחרים”, אוקיי  . . .
• אז כולם רצים על אותו Laptop,  כולם רצים על אותו מחשב, כולם מתחילים אותו זמן.
• הוא נותן להם את ה-Prompt ואומר להם: “המטרה שלך זה למצוא את ה-Process ID של האחרים”
• או אפילו לא יודע אם הוא ממש מסביר להם את זה - אבל “המטרה שלך זה להרוג את כל האחרים ולהישאר בחיים”.
• ו-Fight. זהו . . . 
• וזה נחמד - ואז באמת רואים שמי שמת מקבל מסך אדום, אז רואים כזו אנימציה של הדברים האלה קורים ב-real-time, של ב-Agent-ים יושבים וחושבים ומנסים למצוא מי הם האחרים שרצים לידי ולעשות להם Kill . . . .
• ובסוף מי שמנצח - הימורים מתקבלים בעוד שלוש-שתיים-אחת - המנצח הוא OpenCode! במקרה הזה . . .
• אני לא יודע באיזה מודל הוא השתמש, אבל בקיצור - משחק נחמד.
• ואני כבר צופה שמעכשיו מפתחי המודלים יעשו Fine-tuning למודלים שלהם עצמם, לאיך להרוג Process-ים אחרים כדי שבקרב הבא, שבתחרות הבאה, הם לא לא יפסידו.
• (אלון) אני רק אגיד ש-OpenCode ניצח - הוא השתמש ב-Claude 4  . . . כאילו, זה מה שמעניין תכל’ס, המודל מאחורה.
• הוא השתמש ב-Claude 4 כשהם ניצחו.
• אגב, זה הרבה מזל ומהירות של מודל, כי בסוף הם עושים List של ה-Process-ים ו-Kill-9 לכולם . . .
• זה לא כזה מתוחכם - הוא פשוט עשה את זה יותר מהר מאחרים.
• (רן)  נכון, אבל אתה יודע - זה חלק מהעניין, זה חלק מהתחרות.
• לעשות את זה יותר מהר, לעשות את זה יותר אפקטיבי, לחשוב מהר - ולא להרוג את עצמך בטעות, זה גם יכול לקרות . . . 
• אז נחמד, תחרות חמודה.
• ועוד - דרך אגב, הוא אחר כך עשה Spin-off - עשה עוד כל מיני תחרויות בסגנון הזה, אבל זה מגניב.
• טוב, ועוד פריט אחד אחרון: אדיר דוכן [ההוא מהזה]- יקיר המדור - הוציא סרטון חמוד ומשעשע 
• אני מזמין אתכם להסתכל עליו,אני לא יכול לתקצר את זה [“תשאל את הסוכן שלי!”] - אבל בגדול הוא סוג של משחק Agent אל מול Agent ואיך הם מדברים אחד עם השני.
• את כל הדמויות הוא בעצמו משחק בצורה החמודה והמצחיקה שלו.
• אז תודה, אדיר - הצחקת אותנו.  חפשו ההוא מהזה בלינקדאין,  אדיר דוכן, מצחיק.

 זהו - זה הכל להיום. תודה רבה שהייתם איתנו.[קישור לקובץ mp3]  האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 499 של רברס עם פלטפורמה, שהוקלט ב-27 ביולי 2025 - אמצע הקיץ, סחוניה דל מות, עדיין בלי רעיונות לפרק 500 (יש זמן, אין לחץ*), ואורי ורן מארחים את הדר וקרן מחברת Myop כדי לדבר על חדשות מעניינות מעולם ה-Frontend.*סתם, יש. רעיונות בקצה הפרק.🎗️
00:49 הדר, קרן ו-Myop
(רן) אז תיכף נצלול פנימה ונבין את הצורך ואת הפתרונות - אבל לפני זה קצת היכרות. קרן, בבקשה:

• (קרן) אז נעים מאוד, קוראים לי קרן פנאן, מייסדת-שותפה והמנכ״לית של Myop.
• אני מגיעה מרקע לא-טכני: בעברי VP Product בחברה שנקראת Moon Active, פלטפורמה לפיתוח משחקים.
• ולפני זה הרבה מאוד שנים ב-Gett, או GetTaxi. 
• זה מצחיק, אפילו שכל כך הרבה שנים שזה Gett, ועדיין אני אגיד Gett - GetTaxi,  זה קטע . . . 
• שם הובלתי את ה-Marketing, את ה-Sales, בתור Chief Revenue Officer.
• וזהו - והיום ב-Myop.

(רן) מגניב. תודה. הדר?

• אני הדר גבע - CTO ו-Co-Founder ב-Myop.
• ל-Myop אני מגיע מ-Wix
• אם Gett זה GetTaxi, אז Wix זה Wix.com . . . גם לא יודע למה מוסיפים את זה תמיד, אבל Wix.com.
• (רן) עכשיו אני מתבלבל עם Wix-נקודה-Whatever-אחר . . . 
• (הדר) כן . . . 
• (רן) . . . למרות שהם בטח קנו את כל הדומיינים, אני מנחש, את כל ה-”dots”. זה מה שאני הייתי עושה . . .
• (הדר) היו כמה, לא את כולם.
• בשנים האחרונות שם ניהלתי את גילדת ה-Frontend - הקבוצה הטכנית שאחראית על פיתוח ה-Front.
• גם בהקשרים של Soft Skill - גיוסים, הכשרות, הרצאות שאנחנו נותנים החוצה ומביאים פנימה.
• וגם ממש בליווי הטכני של ארכיטקטים בתוך Wix’ בתוך הקבוצות השונות.
• לפני זה הייתי ארכיטקט בעצמי ב-Wix כמה שנים.
•  ולפני זה, לפני Wix, עבדתי בחברה שנקראת Jive Software - חברה אמריקאית.
• גם שם ניהלתי את ה-Frontend בשנתיים-שלוש האחרונות; לפני זה כל מיני תפקידי פיתוח.
• (רן) Jive התחילה מרכישה של החברה שלך? נכון, מ-OffiSync . . . 
• (הדר) אותי הביאו ל-Jive-ישראל, אני כבר לא עבדתי ב-OffiSync, חברים שהקימו את OffiSync.

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

• (הדר) ב-Wix בשיא היו 720, בשיא שלי, אולי משהו יותר, אולי פחות . . .  700 ומשהו Frontend
• (רן) Frontend,  לא בסך הכל . . .
• (הדר) כן, סה”כ 1500-1600 בפיתוח זה, כולל את ה-QA, Mobile, Backend, כל ה...

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

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

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

• (הדר) אז רגע, בשביל זה אני צריך לסיים את ה... לפני Jive הייתי ברפא”ל ו-8200
• זה גם השירות הצבאי שלי וגם קצת אחרי.
• תפקידי ניהול ופיתוח - זה בגדול.
• ואז זה מגיע לאיך הכרנו - אני, קצת אחרי השביעי לאוקטובר, בעצם הגעתי למילואים ביחידה, לאיזה ארבעה חודשים ברצף, משהו כזה.
• אני עושה מילואים כל התקופה - 13-14 שנה - כמה ימים בחודש, פחות או יותר.
• מלווה שם קבוצות פיתוח ועוזר להם.
• ואז בעצם השותף השלישי שלנו . . . 
• (קרן) כן - אז אנחנו בעצם שלושה שותפים, ואמיר ואני ככה התחלנו לגלגל את הרעיון שמאחורי Myop, והבנו שאנחנו צריכים צלע לשלישית, שתוביל את הטכנולוגיות.
• וככה התגלגל אלינו השם של הדר ומה שנקרא עשינו לו Hunting.

05:09 מה זה Myop?
(רן) אז בכמה מילים - מה זה Myop ואולי גם איך זה מתקשר להיסטוריה שלך, שהזכרת, ב-Wix?

• (קרן) אז מה זה Myop? קודם כל, הדר ואני באים לשנות את העולם.
• זה מה שפאונדרים באים לעשות - לערער את הקיים עם פתרון שאנחנו מאמינים שהוא יותר טוב.
• בעצם, Myop היא מערכת UI או מערכת Frontend פלאגבילית (Plug-able).
• מה זה בעצם אומר? זה אומר שאנחנו מאפשרים לחברות טכנולוגיה לחבר לתוך המוצר הקיים שלהן חתיכות UI חיצוניות, בשיטה שאותה אנחנו פיתחנו, בשיטה שאנחנו קוראים לה “השיטה הפלאגבילית”.
• כלומר, אנחנו לא מכניסים את החתיכות קוד החיצוניות האלה לתוך ה-Stack, אלא מאפשרים איזושהי תקשורת עם החתיכה הזו ב-Runtime, ועל ידי זה מאפשרים גם עוד כל מיני יכולות סביב זה
• של ניהול ב-Production, היכולת לעשות שינויים, היכולת גם להריץ A-B Testing, סגמנטציות (Segmentations) . . . 
• ולתוך כל זה - כי אי אפשר שלא - הבנו שיש לנו פה גם חלק מאוד מאוד משמעותי בכל “מהפכת ה-AI” נקרא לה.
• כי דווקא השיטה הפלאגבילית הזו שאנחנו מציעים, היא שיטה שהיא לדעתנו הרבה יותר נכונה - לקחת חתיכות קוד חיצוניות שה-AI כותב
• אולי אפילו גם על ידי Non-Developers או בשמם החדש, אני לא יודעת אם שמעתם את זה, “Citizen Developers”, שזה בעצם אנשים שהם עובדים עם הפיתוח אבל לא יודעים לכתוב קוד, כמו Product Managers ו-Designers.
• מאפשרים להם בעצם לייצר Feature-ים או קומפוננטות (Components) או whatever שהם החליטו, ולקחת אותם all the way ל-Production.
• כשאנחנו בעצם אומרים “לא - לא עשינו פה שום Risk, כי לא דחפנו את זה לתוך הקוד”.

07:02 פריטת החזון וההבדל מול מה שכבר היה קיים
(רן) אוקיי, אז בואו נפרוט את החזון הגדול הזה לחזונות קטנים יותר, או לחוזים קטנים יותר.אז בעצם, בשיחת ההכנה, אחד הדברים שסיפרתם לי זה שכשנמצאים וכשעובדים בקבוצה שיש בה הרבה מאוד מפתחי Frontend, הרבה מאוד דברים קורים כל הזמן, בו זמנית. זאת אומרת, הרבה צוותים רוצים לשחרר רכיבים.המוצר עצמו, ה-Frontend עצמו, זה לא מקשה אחת - יש בו הרבה מאוד רכיבים.אפשר לחשוב על זה כמו על Microservice ב-Backend, אז Micro-Frontend - מונח שהוא כבר מוכר בתעשייה, Micro-Frontend ב-Frontend. ואני נתתי את האנלוגיה, שאני לא יודע עד כמה היא מדוייקת, שאתם למעשה בונים Docker ל-Frontend - איזושהי יכולת לעשות קונטיינריזציה (Containerization). התאמנתי על המילה, כן . . .  - (קרן) מילה מורכבת . . - (רן) . . . להכיל רכיבים של Frontend, כדי לאפשר מודולריות, כדי לאפשר רובסטיות, כדי לאפשר Deployment יותר בטוח.אבל אתם גם מוסיפים לזה עוד משהו - כלומר, היכולת לטעון רכיב מרחוק בצורה שהיא דינמית. הזכרתם A-B Testing וכל זה.אז עד כמה מה שתיארתי הוא מדויק ואיך פורטים את זה למעשה לפעולות? זאת אומרת, איך קורה כל “הקסם” הזה?

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

(רן) אני חייב להגיד את זה שוב? “מעטפת” נקרא לזה [Containerization . . . .]

• (הדר) כן, אז אני אומר שאנחנו עושים קודם כל ג'נרליזציה (Generalize) למה זה קומפוננטה (Component).
• ואני אוהב להציג את זה שאנחנו לוקחים כל חתיכת UI קיימת מכל טכנולוגיה ובכל צורת פיתוח - והופכים אותה לקומפוננטה.
• היום, כשאנחנו מסתכלים על חתיכות UI - בטח קיימות, בטח Legacy - אנחנו אומרים “אוקיי, זה מסך, זה מערכת, זה קומפוננטה”.
• ו-Myop באה ואומרת “אנחנו יכולים להפוך כל דבר לקומפוננטה”.
• אנחנו יכולים לקחת, ובהינתן חוזה נכון - ואנחנו כבר היום מפתחים בחוזים האלה Prop-ים, Ref-ים, הגדרות של מה קומפוננטה מקבלת ומה היא מחזירה.
• בהינתן שנדע לעשות את זה בצורה אחידה לכל חתיכת UI, נדע לקחת כל חתיכת UI ולרנדר (Render) אותה בכל מקום.

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

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

(אורי) אז הפרוטוקול שמדבר עם הקומפוננטה (Component) הוא רשתי? הוא מתעלם מה-Stack?

• (הדר) לא, זה יותר פשוט מזה - הפרוטוקול, כביכול-  זה בסוף Prop-ים, כן.
• אנחנו מכירים את זה מ-React מאוד מאוד טוב - i PropTypes אם נחשוב על זה.
• בסוף, אתה יודע - גם כשאתה מרנדר (Render) קומפוננטת (Component) React, אתה תקבל את ה-Error בזמן כתיבת הקוד, נכון?
• אבל מה זה ה-Error הזה? זה TypeScript, כן? אני יכול להעביר יותר Prop-ים  - והקומפוננטה תתעלם; אני יכול להעביר פחות Prop-ים, והקומפוננטה תתייחס לזה כ-Undefined או כ-NULL - אולי תתפקד, אולי לא.
• מה המנגנון הגנה שלי? TypeScript.
• מה אנחנו עשינו ב-Myop? מג'נרתים (Generate) לך את ה-TypeScript, את אותו TypeScript.

(אורי) אוקיי . . .(רן) כן, כלומר - הפרוטוקול הוא בסופו של דבר ב-TypeScript, זה יכול להיות ממשקים של Class-ים וכו’.אבל סבבה, אז הבנו. לא הבנו את הפרטים, אבל הבנו בגדול מה קורה שם. עכשיו השאלה היא למה צריך את זה? כלומר, למה שתרצה לטעון דברים בצורה דינמית? כלומר, אנשי Frontend - יש להם איזשהו Spec, יש להם איזשהו Design, הם עובדים לפי ה-Spec, וברגע שהגיעו למשהו שהם אוהבים, הם עושים Deploy ויאללה. כאילו, למה צריך את הדינמיות הזאת? איפה רואים את הצורך הזה?

• (הדר) אז אני אתחיל דווקא ממה שאתה אמרת - הגיעו לאיזשהו ”Spec”. אז זו נקודה מעולה - אבל הם הגיעו לאיזשהו Spec בטכנולוגיה ספציפית.
• אם אנחנו בארגון קטן - מהניסיון שלי, כן? - כנראה שיש לנו רק Stack אחד או שינויים קלים בין לבין, וקל לנו מאוד לקחת את אותה Component או את אותה חתיכת UI שאיתה הגענו, פשוט לממש אותה ולרוץ קדימה.
• מה לגבי ארגונים, מערכות, גופים - שאת אותו Spec צריכים עכשיו לממש בכמה וכמה מקומות, אולי בכמה Stack-ים שונים? אולי בכמה Environments שונים?
• אז קודם כל’ מהזווית של “הגעתי כבר למשהו קיים”, עכשיו עם Myop אתה יכול לקחת ולעשות לו Reuse בעוד מקומות.
• תחשוב על מוצרים, תחשוב על חברות שיש להן . . .

(רן) כשאתה אומר “מקומות”, אתה מתכוון ל-Multi-Platform? תן דוגמא של מקומות כאלה . . . 

• (הדר) כן, התחלנו, אתה יודע - יש לנו חברה, אנחנו רצים מ-15 שנה, כנראה שאנחנו ב-Angular, ועכשיו אנחנו רוצים להתחיל לכתוב ב-React.
• או כשעכשיו רכשנו חברה, או שעכשיו קנינו או לקחנו או רכשנו איזשהו מוצר.
• אז זה Scenario אחד - ה-Scenario של לקחת חתיכה שכבר יצרנו אותה ולהשתמש בה במקומות אחרים.
• הרבה פעמים, אגב, הבעיה היא הפוכה - איך אנחנו מגיעים בצורה המהירה ביותר ל-Spec שקיבלנו?
• ופה זה מתחיל להיות מעניין . . . .
• אם אני היום באיזשהו Stack Legacy, אולי אני בכלל כתוב על Builder . . .
•  אולי איזה בית-תוכנה כתב לי את המערכת שלי - כי הייתי סטארטאפ קטן, כי הייתי ארגון לא מאוד טכנולוגי.
• ופתאום היום יש לי דרישות שעולות, והקומפוננטות הן מורכבות, נהיות מורכבות יותר ויותר.
• באים המפתחים שלי אומרים לי “תקשיב, היום כבר לא כותבים ב-PHP היום כבר לא כותבים ב-ASP - אני רוצה לכתוב ב-React אני רוצה לכתוב ב-Vue”.
• לרוב זה מגיע מאוד מהר ל”אוקיי בוא נעשה Re-write ובוא נשלם את כל מחיר ה-Re-write הזה”.
• (קרן) אני חושבת שיש לזה גם דרישה עסקית - שבסוף, ניהול ב-Runtime הוא מקצר Time to Market.
• וגם אם בפעם הראשונה שאתה לוקח את זה ל-Production אז נניח לא קיצרנו הרבה - אנחנו מאמינים שגם פה זה מקצר - אבל זה בוודאות מקצר לך כשאתה רוצה לעשות שינויים.
• ואנחנו חיים בעולם שעושים בו שינויים - Feature מגיע ל-Production הוא . . .  אוספים Feedback, רואים מה עובד רוצים לעשות שינויים, רוצים לעשות דיוקים . . . 
• כל דבר כזה זה עוד משימה לפיתוח - זה עובר את אותו Cycle של R&D - ואנחנו טוענים למה? 
• בעצם, אני יכולה עכשיו לקחת - כ-Product-ית, כ-Designer-ית, כמי שאחראית על Revenues - בכוונה אני כזה לוקחת את הצד העסקי - ולקחת שינויים ל-Production, בצורה שהיא הרבה יותר מהירה ולא עושה לי עכשיו Disruption לראות מה פה לFeature-ים חשובים שיש לי ב-Sprint.

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

• (קרן) כן, אז תראה - קודם כל, חשוב לומר שבגישה שלנו עדיין צריך מפתח בתמונה, ובטח שצריך מפתח בתמונה בשביל החוזה הראשוני.
• אבל זה לא צריך להיות תהליך אינסופי כמו שזה היום.
• אני זוכרת, בתור מי שניהלה לא מעט מוצרים - שוב, בצד העסקי - ותמיד ישבה על הפיתוח ולא הבינה “למה זה לא קורה יותר מהר”
• כי זה לא יכול לקרות יותר מהר בהרבה פעמים.
• אבל בסוף כשחושבים על זה, כשמדובר בשינויי UI קטנים
• או בדברים - גם אם הם לא קטנים, בשינוי Layout, אבל שבסוף אין לי פה עכשיו איזושהי לוגיקה חדשה או שלא עשיתי איזשהו שינוי מהותי ל-Feature ובטח שלא שיניתי שום דבר שנוגע גם ל-Backend - ועדיין אני עוברת . . .
• זו אותה משימה, אני עוברת את אותו תהליך - וזה עדיין ייקח את אותו זמן של שבוע-שבועיים-שלושה-חודש, תלוי בגודל ה-Stack ובמורכבות של החברה.
• ואת זה אנחנו מערערים - כי אנחנו אומרים “רגע, יש דרך אחרת”
• שיכולה לגרום לחברות לפגוש את Production הרבה יותר מהר - להבין מה עובד ולקבל החלטות שהן “מבוססות תכל’ס” 
• וכן, כמו שאמרת - AI עושה לזה אקסלרציה (Accelerate) בטירוף, כי AI גם יאפשר לי, כלא-מפתחת.

(רן) כן אז בואו נדגיש שוב את הבעיה במילים שלי - אז ככה: אתם רואים ש“יש צוואר בקבוק”. צוואר הבקבוק הוא הרבה פעמים הפיתוח - יש Designer, יש מנהל מוצר, שרוצים לדחוף קדימה Feature-ים, והרבה פעמים יש מחסור בשעות מפתחי Frontend או Whatever. מכל סיבה שהיא, זה לא עובר מספיק מהר כמו שרוצים - ואתם למעשה מפתחים את הכלי או את הטכנולוגיה או אולי את שיטת העבודה, שתאפשר לפתוח להרחיב את צווארי-הבקבוק האלה.כלומר, יש דברים שבשבילם כן צריך מפתח וצריך פה הנדסה וזה צריך להיות נכון ומדויק - אבל לא להכל. אם זה ניסויי A-B Testing שונים, אם זה שינויים שהם לא משמעותיים, שכן יכולים להזיז את המחט בצורה מאוד מאוד משמעותית,אבל מבחינה הנדסית הם לא משמעותיים - אז למה לחכות לפיתוח בשביל הדבר הזה?

• (הדר) נגיד אפילו משהו שיותר קל לעיכול באזורים האלה: נניח שאנחנו, כמפתחים, לדרישת ה-Product, לדרישת ה-Design, מימשנו 2-3-4 וריאנטים (Variants) לקומפוננטה (Component) מסוימת.
• בסוף, מי שיחליט מי רואה מה וכמה ואיזה Variant ניצח - זה בכל מקרה ה-Product.
• למה לא לתת לו כלי מאוד פשוט, שבקליק הוא מחליט את זה?
• הרי בסוף אנחנו מכירים את זה - יש את הפיתוח עצמו: מורכב או לא מורכב, AI או לא AI, תכף נגיע לזה.
• אבל הרבה פעמים אנחנו מכניסים את ה-If-Else לקוד הזה, של 50/50.
• שבוע אחרי או כמה ימים אחרי, אם אין לנו איזה מערכת, בוא נשנה את זה למשהו אחר - ואז נכנסים לקוד עוד פעם ומוחקים את ה-Experiment - כי ה-Variant ניצח.
• בסוף ה-Product מחליט את זה - ואנחנו הולכים ומממשים את זה, שוב ושוב ושוב.

(אורי) אבל פה אתה מדבר ממש על יצירת התוכן, ה-Variant - לא רק על המיתוג של . . . 

• (הדר) אני אומר יותר מזה - יש את היצירה עצמה, שתיכף נדבר: עם מפתח או בלי מפתח.
• את האורקסטרציה (Orchestration) של הדבר הזה, את הניהול של איזה Variant מנצח, מי רואה מה, כמה אחוזים - כל זה.
• יש הרבה כלים שעושים את זה ברמת “אני אחזיר לך את ה-Boolean, אני אחזיר לך את ה-Variant, אני אחזיר לך את המספר באחוזים”.
• אבל אנחנו, כמפתחים, הולכים ועושים את הקוד - חושבים מאיפה לטעון את הקומפוננטה, איך להעביר את ה-Prop, מה הדאטה שזה מקבל, מה הדאטה שזה נותן . . . 
• ו-Myop מאפשרת לנו לעשות לזה הכללה מאוד פשוטה: יש Variant-ים, זה החוזה של הקומפוננטה (Component) - ואז זה שכבת ניהול מעל זה.
• מי רואה מה, מתי, ואיזה גרסה מנצחת.

(רן) לא משלמים על זה מחיר? זאת אומרת, אם אתה צריך לשחק לפי הפרוטוקול - לצורך העניין, אני כותב React, Vue, Angular, או Whatever, Prototype, רחמנא ליצלן - אז אני צריך להתאים את עצמי לפרוטוקול.כלומר, אני, קודם כל - אני, שכתב את הקומפוננטה (Component), צריך להתאים את עצמי לפרוטוקול. אם לא עשיתי את זה, אז מישהו מהחברה שמשתמשת צריכה לעשות את זה. זאת אומרת, יש פה איזשהו Overhead.גם ברמה ה-HR-ית, כאילו, מבחינת כוח אדם, אבל גם אולי מבחינת Run-time, מבחינת ביצועים על לא יודע, על Device-ים יותר קטנים. זאת אומרת, לא משלמים פה מחיר?

• הדר) אז תראה, ברגע שטוענים קומפוננטה בזמן ריצה - אנחנו מכירים את זה הרבה לפני Micro-Frontend ודברים כאלה, משלמים איזשהו מחיר.
• המחיר הזה, אם משחקים איתו נכון, יטיב איתנו עם ה-Performance
• כי אנחנו בעצם מורידים דברים מה-Bundle המלא שלנו, מאיצים את ה-initial load, את ה-initial pain, וטוענים את הדאטה הפנימי בעמוד רק מתי שצריך.
• כשאנחנו מדברים על Multi-Variant או UI שמשתנה, זה אפילו מקבל עוד חיזוק.
• כי בעצם במקום להביא שניים-שלושה-ארבעה Variant-ים ל-Client-side ולעשות את ה-If-Else בקוד.
• שבואו - זה מה שיקרה ב-React, ב-Vue, ב-Angular, אם לא נכתוב מנגנון חכם מעל - Myop יודעת לבוא ולהגיד “אוקיי, הבנתי - בגלל עץ ההחלטות, בגלל ההגדרה של הקונפיגורציה, בגלל כל הכלים שאנחנו נותנים - שה-User הזה צריך לראות את ה-Variant הזה, וזה רק ה-Variant שיגיע.

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

• (הדר) אז זו שאלה טובה, שאנחנו עכשיו בדיוק עם אחד הלקוחות שאנו מתחילים להתחבט בה.
• הטייק שכרגע נלקח שם - ואני מאוד מתחבר אליו - זה ש”מי שעשה את הקומפוננטה”.
• זאת אומרת, אם אנחנו באים ומעצימים איזשהו Citizen Developer, שהוא ה-Designer, שהוא ה-Product, והוא הלך - עם AI, לא עם AI, לא משנה איך - ויצר קומפוננטה - הוא אחראי עליה, הוא פותר בה את הבאגים.

(אורי) אז הוא נכנס ל-On-Call?

• (קרן) כן. עם הכוח באה האחריות.
• אני יכולה לשתף מעולם ה-Gaming, שבאמת יצא לי לעבוד שם כמה שנים - אני לא יודעת כמה אתם מכירים, אבל גם בעולם ה-Gaming, משחקים מוצלחים, זה משחקים שיש בהם רכיב דינמי.
• כלומר, כל החלק הוויזואלי הוא נשלט מרחוק - בעצם, אי אפשר לשחרר עכשיו גרסה ל-App Store או ל-Google Play על כל שינוי ויזואלי.
• וזו אחריות שבעצם ירדה מהפיתוח ועברה למחלקות הProduct -  Product, מוניטיזציה.
• וכן, זה אומר שעם האחריות לעשות את השינויים - שזו אחריות מדהימה, זו אחריות שמאפשרת לך לתקשר עם ה-User-ים בצורה מדהימה, להעביר רעיונות מרעיון לProduction ב-No-Time.
• אז כן, אז באה גם האחריות של להיות On-Call - ואם משהו משתבש, אז כן, אז אתה חלק, אתה מתחת לאלונקה להבין מה לא עבד.
• אנחנו מאמינים שלשם העולם הולך.
• כאילו, אי אפשר לבוא ולהגיד “אני רוצה לעשות יותר” - ומצד שני לא לרצות לקחת את האחריות. 

(רן) כן, אבל אני חושב שאורי מעלה פה נקודה נכונה - זה כנראה תהיה מטוטלת. כלומר, זה לא יהיה קל להעביר את הכדור הזה, או לחלוק בכדור הזה בין כולם, ויכול להיות שזה גם ידרוש מכם לפתח כלים לניטור - אבל לא למפתחים, במקרה הזה, ל-Citizen Developers, כמו שאמרתם.אז כן, זאת אומרת - כנראה שהמטוטלת הזאת תעבור כמה פעמים עד שהיא תגיע למקום יציב, אבל סבבה, זה מובן.
23:07 מה היעד?
(רן) רציתי רגע לדבר על ה-Target Market. כלומר, אם אני סטארטאפ של מפתח Frontend אחד ואיש Backend אחד, אני מניח שבמקרה הזה אני לא צריך פתרון כמו Myop. אולי גם פה אני טועה . . . מתי כן?זאת אומרת, מה הלקוח האידיאלי מבחינתכם?

• (קרן) נכון, אז אתה ממש צודק. אני אגיד יותר מזה - אני חושבת שהיום, סטארטאפ של מפתח אחד, או אפילו Founder לא-טכנולוגי - השוק עכשיו, שלא נאמר “מוצף”, בכלים שאמורים לתת לך את ה-Ramp-up הראשוני, ואנחנו בעד זה לגמרי.
• גם אין לנו שום רצון או כוונה להתחרות בזה.
• אני חושבת שזה כלים מדהימים, ואין ספק שגם הם ילכו וישתפרו וישתפרו.
• אנחנו דווקא פונים לחברות שכבר יש להן מוצר - כבר יש להן User-ים, כבר השקיעו שנות-Engineering, שעלו הרבה מאוד כסף.
• וזה עובד - וה-User-ים מרוצים והכל בסך הכל טוב.
• ויש יעדים וצריך לגדול וצריך לעמוד בהם - ועל הדרך צריך גם לזוז יותר מהר, וצריך גם To adopt AI, כי אי אפשר שלא.
• ושם אנחנו חושבים שיש כאב מאוד מאוד גדול, כי אני לא אזרוק את כל מה שבניתי עכשיו בשלוש-ארבע-חמש-עשר שנים האחרונות - ואבנה מאפס ב-Lovable, זה לא יקרה . . . .
• זה לא ריאלי, זה גם לא יחזיק מים.
• אבל אולי אפשר להשתמש ב-Lovable לפתח Feature או קומפוננטה (Component) או יכולת ספציפית - ושם ליהנות מה-Vibe המטורף הזה.

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

• (קרן) אז קודם כל, אני חושבת ששווה לשאול מה האלטרנטיבה?
• אם אנחנו הולכים על אותה Mature App - מה אפשר לעשות? אפשר עכשיו להשקיע בתשתית שהיא יותר מודולרית והיא מייצרת לי את ה-Micro Apps או שליטה שהיא . . .כאילו, אני יכולה להחזיק דברים בתוך הStack ומחוץ ולייצר ביניהם תקשורת.
• אני גם יכולה לשים מפתח, שיעבור על ה-Output של Gemini או Claude, על אלפי שורות קוד - ויעשה גם אינטגרציה ידנית, זה גם אני יכולה לעשות.
• אבל איך שאנחנו רואים את זה, אלה כרגע האופציות, האלטרנטיבות.
• אז בעצם אנחנו אומרים, רגע - אם עולם ה-Software עובר פה איזשהו Disruption - מרצון, לא מרצון - אנחנו שם, הרכבת הזאת יצאה, נסעה, וכולנו בתוך זה.
• אז אנחנו ננסה להקל על ה-Disruption הזה עם השיטה הפלגבילית (Plug-able) שלנו, ה-”Containerization” . . . . 
• (רן) . . . חייבים להמציא מילה יותר פשוטה לזה.
• (קרן) . . . חייבים.

(רן) כן, כלומר - את אומרת . . . אם אני מבין אותך נכון, בעצם את אומרת “אוקיי, יצרתי פה איזושהי קומפוננטה, שהיא נראית לי טוב - אבל היא מכילה אלפי שורות קוד, יכול להיות”. זאת אומרת, משהו ש-Lovable פלט או Gemini כתב לי, או Claude Code או Whatever. “זה נראה לי שזה עובד בסדר, נתתי לחברים שלי לשחק, נתתי ל...” . . . .עכשיו, אני באמת הולך לעבור על כל האלף שורות קוד האלה לפני שאני באמת יודע אם משתמשים רוצים את זה?לא בא לי לעשות את זה . . . אז לא, אני פשוט אתן למשתמשים. קודם כל להבין אם זה בכלל נותן את הProduct הנכון, אם זה נותן את החוויה הנכונה.יכול להיות שזה לא Robust במאה אחוז - בסדר, אני מוכן לשלם את המחיר הזה. אבל אני קודם כל רוצה לדעת אם זה הולך לעבור את הפילטר של המשתמשים - ואתם למעשה נותנים את הכלי לעשות את זה. עם סיכון מסוים, אבל שהוא Manageable.

• (קרן) כן, אנחנו מנסים למתן את הסיכון עם QA פנימי ועם כמובן יכולות ולידציה (Validation) ועם Gradual Rollout, ו”תיקח את זה ל-5%, תיקח את זה ל-10%”, עם כל הכלים האלה.
• אבל כן, בדיוק - אנחנו אומרים, לא יודעת . . .  זה כמו “ה-Next level של ה-MVP”, זה “AI-MVP” 
• קח את זה, תבדוק את זה - ואז תקבל החלטה מושכלת אם לשים על זה צוות פיתוח ולפתח את זה Enterprise-Grade . . .
• (רן) “לשייף את הקצוות” . . . 

(רן) כלומר, בעצם אתם מייצרים את היכולת להביא Prototype - אולי לא של כל המוצר, אבל Prototype של איזשהו רכיב, נגיד איזשהו מסך בתוך המוצר או איזשהו תפריט בתוך המוצר -  להביא את ה-Prototype הזה ללקוחעם מינימום מאמץ פיתוחי, באמצעות AI-Coding או Whatever. דרך אגב, יכול להיות שכן היה שם מפתח אבל הוא לא “שייף את זה עד הסוף”, אוקיי? אז להביא את ה-Prototype הזה לפני הלקוח, להבין אם הלקוח באמת רוצה את זה - ואם כן אז לוקחים את ה-Prototype והופכים את זה למוצר רובסטי (Robust), עם Performance וכו’ - אבל לפני זה אין טעם להשקיע.(אורי) תמיד, כן - “בזמן הכבד” אתה רוצה להשקיע אחרי הוולידציה (Validation).

• (קרן) בדיוק.
• (הדר) כן, נכון. אני גם חושב שכאילו היום בלי פתרון כזה, בעצם העולם מתחיל להתחלק לאוקיי, היו לנו את ה-”Builder-ים”, הרבה מאוד שנים, שהיו שמורים ללקוחות מסוימים, נכון? דפי נחיתה פשוטים, כל מיני e-commerce קטנים, עצמאים שבונים לעצמם אתר . . . 
• והיה לנו את המערכות הגדולות שחברות כותבות - Dashboard-ים, אפליקציות, כל הדברים האלו.
• וה-AI, עם ה-Vibe Coding, Base44, Lovable, כל הכלים שדיברנו, תופס ובא להחליף את ה-Builder-ים.
• אבל בעצם אנחנו זיהינו פה פוטנציאל - רגע, למה? למה לא לשלב עכשיו בין הדברים ולבוא ולתת את כל היכולות המדהימות של ה-Vibe Coding וה-AI שהולכים ומשתפרים כל יום ב-Level של קומפוננטה (Component) ולא ב-Level של אפליקציה.
• אם אני יכול לבנות אתר שלם ב-Base44 - חנויות, מה לא ראיתי בחודשים האחרונים . . .  חנות להשכרת רכבים ונדל”ן שאנשים עשו בשכונה שלהם וכל מיני דברים.
• אז אם זה עושה אתר שלם, ה-Take שלנו זה בוא נצמצם את הקונטקסט לקומפוננטות - האיכות רק תעלה.
• נפנה ל-AI במשימה קטנה יותר מדויקת יותר, ונוכל להשתמש בזה במוצרים קיימים.

(רן) כן, זאת אומרת אתה אולי רומז לכיוון שני אתגרים שבאחד מהם נגענו ובשני לא ממש.אחד זה אתגר המיטיגציה (Mitigation). כלומר, אני לא בטוח עד כמה הקוד הזה רובסטי (Robust), אני עדיין רוצה לבדוק אותו. על זה דיברנו.
30:00 “לכתוב Prompt” זה יותר מורכב ממה שזה נשמע
(רן) אתה גם מזכיר או רומז, לפחות לדעתי, על אתגר אחר - שהכלים האלה, יש להם יכולת לכתוב פרויקטים קטנים ברמת איכות יחסית סבירה. אבל כשאתה מכניס אותנו לתוך פרויקט גדול - חי, שיש בו מורכבות - ניקח את Wix לדוגמה - מאוד קשה להם להתמודד עם כל ה-Code base הזה, מאוד קשה להם להיכנס עם כל ה-Coding Conventions. אבל אם אתה מקטין להם את ה-Scope, אתה אומר “אוקיי אתה לא צריך להכיר את כל Wix, רק תסתכל על הריבוע הקטן הזה - זה הממשק הקטן שלך בתוך ה-Sandbox הזה אתה חי”, אז פתאום החיים שלהם קלים, ואז הם נותנים עבודה טובה.

• (הדר) נכון, וזה משהו שאתה לא צריך לחכות, אתה יודע, את החצי-שנה-שנה-שנתיים-חמש, שזה יהיה במקום הזה.
• ואנחנו מדברים עם הרבה אנשים כל אחד נותן את ההערכה שלו מתי ה-Context Window יוכל להכיל יותר ויותר.
•  והיום שמענו על איזה Agent שעושה את זה בכמה Thread-ים, ואז הוא יכול לעשות יותר קונטקסט וכל מיני כלים שעשו.
• אגב, יש איזה כלי מאוד מעניין עכשיו שמעתי שבתוך Wix מפתחים אותו אז זה מעניין . . .
• אנחנו באים ואומרים “אוקיי, אבל למה לחכות?”
• את הקומפוננטה ה-Scoped, החצי-מסך, הבאנר, הכמה דפים, ה-Form הזה שאני צריך, התת-אפליקציה הזאת . . . -  זה עושה מעולה היום.
• ואם אני אחבר את זה ואתן כאן איזשהו פתרון רובסטי, Type-safe - עם בדיקה בין גרסאות, עם יכולת לשחרר את זה מהר ולתקן את זה מהר - זה יכול היום להיכנס לאפליקציית React ה-Production שלי, לאפליקציית Vue ה-Production שלי.

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

• (הדר) אז זה ממש נכון - וזה יתחבר לנו בצורה מאוד מאוד טובה למה שהתחלנו איתו: איך אתה מגדיר חוזה מול מה שקראתי לו “כל חתיכת UI”?
• ה-Dashboard שלנו היום והפלטפורמה שלנו היום יודעת, בהינתן Output כזה שהבן אדם שכתב - יותר טכני, פחות טכני - יודעת לבוא ולבקר את החוזה הזה.
• לבוא ולהגיד “תראה, בגרסה הקודמת היה API כזה וכזה - שברת אותו”.
• “בגרסה הזאת מוצעות עכשיו עוד כמה וכמה יכולות - אתה רוצה להשתמש בהן?”
• וככה אנחנו בעצם יכולים לעשות איזושהי רמה של ולידציה (Validation) ראשונית, שלא שברת את הממשק.
• אנחנו יודעים לזהות שם את ה-Type-ים, מה שדיברנו, את ה-Prop-ים הנכנסים, היוצאים,Ref-ים.
• השלב הבא של הדבר הזה - ואז אנחנו ממש עובדים וחושבים עכשיו איך נעשה את זה - זה להיות מסוגלים לקבל Prompt פשוט, ואוטומטית ליצוק לתוכו את כל ההבנה.
• זאת אומרת, לבוא ולהגיד אנחנו מבינים שזה הולך להיטען ב-Run-time, אנחנו מבינים שזה צריך לנהל API, אנחנו מבינים שזה צריך לעמוד בסטנדרטים כאלה וכאלה וכאלה . . . .
• אולי אנחנו מכירים את ה-Pattern-ים שקורים אצלך בארגון - ונמליץ את זה למנוע, בתוך ה-Prompt שלנו.
• אז זה גם מה שאנחנו עכשיו מסתכלים עליו, בוחנים אותו - איך התוצר של זה אל מול “החופש”: פשוט לך ל-Gemini, Claude, GPT ותן לי את ה-Output.

(רן) כלומר, אתם לא רק מייצרים את ה-Framework שאליו מזריקים את הקומפוננטות, אלא אתם עוזרים - אתם ה-Mediators לייצור הקומפונטות. אתם באים ואומרים “אוקיי, אתה רוצה להשתמש ב-Lovable, Base44, Gemini או Claude Code - תשתמש”. אתה יכול לשחק חופשי, אבל אתה גם יכול לקבל את העזרה מאיתנו - ואנחנו נעזור לך לייצר קומפוננטות שעובדות יותר טוב איתנו.

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

(רן) “תעשה את זה יפה”, כן . . . “תעשה את זה יפה” זה לא מספיק - צריך להסביר מה זה יפה.

• (קרן) בדיוק - ותקליט לו גם, כי למי יש כוח לכתוב?

34:32 ה-ActiveX Strikes Back / אם אתה פותר בעיות שאף פעם לא ראית לפני זה, אז אתה לא עושה את האנלוגיה הנכונה
(אורי) אני יכול להגיד משהו, כנציג “שיער אפור”?(רן) אתמול התגלחתי, אז לא רואים . . . (אורי) כן . . . אתה זוכר, רן, את תחילת שנות האלפיים?(רן) נניח, כן . . . זורם.(אורי) את ActiveX של Microsoft?(רן) כן, כן - קראתי איזה ספר . . .

• (הדר) אפילו אני עוד מכיר . . . 

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

• (הדר) אני חושב שכאילו . . . . אני מצד אחד יכול להתחבר למה שאתה אומר.
• מצד שני, אני חושב - ואנחנו מדברים על זה גם הרבה - שהפתרונות האלה, הפתרונות כמו ActiveX או היה Silverlight בזמנו, היה כל מיני דברים כאלו - הם באו לפתור כאב אחר, שאם שאלנו למה עכשיו, אז הוא כבר פתור היום - וזה המגבלות של ה-Frontend.
• אנחנו לא באים להגיד “React לא טוב”, “Vue לא טוב” או “ה-Output של Lovable לא טוב”.
• איך אני מחבר בין הדברים?
• ו-ActiveX, לצורך העניין, הוא בא ואמר “אני לא יכול לעשות הכול בזמנו ב-HTML ו-JavaScript, אז בוא ניתן לך להריץ אובייקטים מורכבים יותר, Native-יים בתוך ה-Browser”.
• אני רואה את זה כמשהו קצת אחר . . .
•  זה עוד לפני ה-Browser-ים זה עוד על ה... כאילו, ממש על התכנות ה... אתה יודע, היית מראה אפליקציה, ואז מביא “מהיקב ומהגורן“ ערימות של DLL-ים - שהיו מכילים בעצם את ההשלמות.

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

• (קרן) גדלנו. אנחנו שלושה Co-Founders, אבל כבר יש לנו  - גייסנו צוות ולקוחות ראשונים ואנחנו גדלים.
• מחפשים חברות אמיצות שרוצות לקחת AI לProduction - 

I dare you.(רן) מה נדרש מהם לעשות אם הם רוצים לבוא ולהתחיל לעבוד איתכם?

• (הדר) אז זה ממש ממש פשוט  - בעצם אנחנו מציעים איזושהי פגישה, שבה אנחנו פשוט לוקחים קומפוננטה, בוחרים קומפוננטה, פתוחים לכל Stack של הלקוח.
• וב-20 דקות עד 40 דקות מכניסים קומפוננטה מחוץ ל-Build שלו אל תוך המוצר ב-Production.

(רן) כן, כשאתה אומר “קומפוננטה” (Component), אתה מדבר על משהו ש”חי ב-Browser”. כלומר, לא מטפלים ב-Backend ואחרים?

• (הדר) נכון - UI, SSR גם - אפשר לדבר על זה - אבל UI כן. 

(רן) לא Mobile. זאת אומרת, לא Native Mobile - ווביי (Web).

• (הדר) נכון.

(רן) בסדר גמור. נשמע כמו אתגר ראוי וכיפי - שיהיה בהצלחה!

• (הדר, קרן) תודה רבה.

38:30 פרק 500 קהילתי - שלחו את ה-Mp3 שלכם!
(רן) ושנייה לפני שאנחנו מסיימים - כהכנה לפרק 500 הממש-ממש קרוב אלינו, אנחנו רצינו לעשות משהו מיוחד.אז מה שאנחנו מבקשים מכם, המאזינים, זה לשלוח לנו משהו קטן - ותיכף נגיד לכם מה זה - משהו קטן אלינו.אנחנו ניקח את ה-Input שלכם ונקמפל את זה לפרק שלם, ובטוח שיהיה מעניין.(אורי) אני רק מקווה שישלחו לנו, כן?(רן) כן . . .  אז מה אנחנו מבקשים?(אורי) אז שלחו לנו דברים, לפי הנושאים הבאים: נגיד, אתם יודעים - אנחנו מקליטים כבר 17 שנים. זה די היסטוריה רחוקה, והרבה דברים קרו. ואנחנו יודעים שיש לנו מאזינים שמאזינים לנו הרבה זמן - אז דברים כמו למשל משהו מעניין או מצחיק שקרה לכם בעקבות פרק של רברסים.(רן) אז דוגמא אחת - שוב אני אומר: לשלוח לנו MP3! נגיד -

• משהו מצחיק שקרה לי ו-1,2,3 - תספרו.
• 30 שניות, דקה - אפשר גם פחות.
• ותשלחו לנו לאימיילים שלנו  - Ran-at-Reversim ו-Ori-at-Reversim.

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

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

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


[קישור לקובץ mp3] 
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 498 של רברס עם פלטפורמה, שהוקלט ב-22 ביולי 2025 - חם טילים בחוץ, עדיין מחפשים (גם בבריכה) רעיונות נחמדים ופחות שגרתיים לפרק 500, ואורי ורן מארחים את ניב מחברת Hailo ומדברים על חומרה ומודלים בקצה. 🎗️



01:00 ניב ו-Hailo
(רן) אז ניב - קצת עליך וקצת על Hailo, ואחר כך נצלול פנימה. שוט.

• (ניב) יאללה - אז נעים מאוד: אני ניב, בן 39 נשוי עם שניים, מרמת-גן. יש לי כלבה, חשוב מאוד . . . 
• (רן) איזה?
• (ניב) קטנה, מעורבת, שחורה, חמודה . . . 
• תואר שני בהנדסת חשמל.
• עבדתי לפני ב-Broadcom ובאלביט - ובשש וחצי השנים האחרונות אני ב-Hailo.
• וכמה מילים על Hailo - אז חברת סטארטאפ, Semiconductors, שמייצרת צ'יפים שמאיצים רשתות נוירונים למכשירי קצה.
• בעצם, מכשירי-קצה (Edge) זה כל מה שאתם יכולים לחשוב עליו שהוא לא רץ ב-Cloud - אז זה יכול להיות רכב אוטונומי, מצלמה חכמה, אפליקציות שונות ומשונות.
• אנחנו מייצרים את הצ'יפים, מוכרים לחברות . . .
• (אורי) היום טלפון נחשב למכשיר-קצה . . . 
• (ניב) חד-משמעית כן, כמובן. 
• למרות שלטלפון  - אולי אפשר לדבר על זה קצת אחרי זה - יש צ'יפים ייעודיים לפלטפורמה הזאת.
• אנחנו מוכרים פלטפורמה, בעצם - חומרה שמלווה בהמון המון תוכנה.
• כמו כל חברת Semiconductors, גם אצלנו יש יותר מהנדסי-תוכנה מחבר'ה שעושים את החומרה . . . 
• יושבים בתל אביב . . . 

(רן) ותפקידך בחברה?

• (ניב) אני מנהל קבוצת תוכנה גדולה, Software Director שבעצם אחראי על כל “ה-Core הנוירונלי” - בעצם ה-IP של החברה.
• זו חברה שמורכבת מכמה סגמנטים (Segments) -
• יש לנו גם קבוצת Machine Learning, שאחראית יותר על החלק ה-High-Level-י  של התוכנה, של החבילה שאנחנו מספקים.
• גם קבוצת Embedded, שממש אחראית על החלק היותר Low-Level-י - -++ C - ובאמת כותבת את התוכנה שממש רצה על ה-Edge Device עצמו.
• ועוד קבוצת תוכנה שהיא קצת יותר ייחודית - שהיא קבוצת Complier
• שזה Complier שאנחנו בונים In-house, שבעצם יודע לקחת רשתות נוירונים ולקמפל (Compile) אותם לאיזשהו קובץ בינארי,  שיודע לרוץ על החומרה הייעודית של Hailo.

(אורי) אני חייב להגיד שקבוצת “ה-Core הנוירונלי” זה נשמע לי כמו . . .(רן) . . . שם של מחלה . . . (אורי) . . .  לא לא - מין שבט כזה של Game of Thrones, של משהו כזה . . . 

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

(רן) כן, אז בעצם תיכף נדבר על התוכנה - אבל רק שנייה על חומרה: אז המערכות שאתם בונים זה GPUs של ממש?כלומר, כל המאפיינים של GPU - רק בקטן?

• (ניב) ממש לא - בעצם, GPU הוא חומרה שהיא גם יודעת לעשות רשתות נוירונים, אבל היא חומרה הרבה יותר גנרית (Generic).
• החומרה של Hailo היא ממש ASIC ספציפי, למטרה ייעודית, שנבנה From Ground-up - כל מה שהוא יודע לעשות זה להאיץ רשתות נוירונים.
• כתוצאה מזה, הוא עושה את זה ביעילות הרבה יותר גבוהה.
• זה מיועד למכשירים דלי-הספק - אופטימיזציות הרבה יותר גבוהות, בביצועים יותר גבוהים וכן הלאה. 

(רן) הבנתי. כלומר, זה לא CPU וזה לא GPU - אבל זה יודע לעשות בדיוק את מה שהוא מיועד.

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

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

• (ניב) נכון. אחת הדרכים להבין את זה זה לצורך העניין ב-Cloud - שאחד הדברים שהכי מאפיינים היום את ה-AI זה שהוא לא רק יודע לעשות Inference אלא גם Training, שזה נניח איזשהו צורך מאוד מאוד נפוץ באפליקציות ומוצרים של GPU.
• אבל במכשיר-הקצה אנחנו מתעסקים נניח רק ב-Inference, שזה איזשהו הבדל שהוא מאוד מרכזי בין המוצרים האלה. 

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

• (ניב) ממש ככה - ופשוט עושה Deployment באיזשהו Embedded Device. 

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

• (ניב) אז באמת, כשמדברים על מכשירי-קצה, זה בדרך כלל לא הרשתות-ענק שאנחנו רגילים לדמיין, שרצות ב-Cloud.
• ששם רוב האפליקציות של AI שאנחנו מכירים ועובדים איתן ב-Day to Day שלנו.
• אז אם אנחנו מדברים על רשתות Vision זה קצת יותר קל להבין את זה, כי בעצם רוב הרשתות שמאופיינות ל-Computer Vision הן מיועדות למכשירי-קצה - רשתות שעושות Object-Detection, קלסיפיקציה (Classification) או דברים כאלה - זה באמת מאוד סטנדרטי להריץ במכשירי-קצה.
• (רן) כלומר - מצלמת אבטחה, נגיד, שמזהה אנשים או שמזהה תנועה או כאלה . . .
• (ניב) כן - לוחיות-רישוי, דברים מהסגנון הזה . . . פרצופים, דברים מאוד סטנדרטיים שעושים היום על מצלמות.
• גם Gateways, דברים כאלה, הרבה מאוד אנליטיקות (Analytics) שאנחנו יודעים להאיץ.

06:40 פעם ראשונה AI

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

(רן) כלומר, אני יכול להגיע לצ'יפ ולבקש ממנו “צייר לי כבשה” - והוא יג'נרט (Generate) לי תמונה של כבשה.

• (ניב) אכן, אבל . . . 

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

• (ניב) אז קודם כל, צריך להגיד - אין הרבה Deployment של Generative AI היום במכשירי הקצה.
• רוב האפליקציות שאתה מכיר ואתה משתמש בהן, כמובן, הן רצות כרגע ב-Cloud.
• אבל זה משהו שגם מסקרן אותנו - אנחנו נכנסנו לתחום הזה כאיזשהו Move אסטרטגי של החברה, רצים שם מאוד חזק. 
• כחברה שיודעת, וכל היום חיה AI ומאיצה רשתות נוירונים, אז זה תחום שמאוד מעניין אותנו ואנחנו משקיעים בו המון.
• אז זה מאוד מסקרן אותנו לראות מה אפשר לעשות עם זה - יש הרבה דברים והרבה צורך שהגיע מהשטח ומלקוחות שרוצים להאיץ את זה.
• אז יש כמה דברים על השולחן - הרבה דברים שקשורים ל-Privacy; לסכם מסמכים; לצורך העניין לא לחלוק את הקוד שלך עם איזשהם שירותי ענן; כל מיני דברים שקשורים ל-VLM ודברים שמערבים Vision - אז זה תמיד Privacy
• ו-Cost הוא אלמנט מאוד חזק ב-Deployment של רשתות נוירונים . . . 
• (רן) כן, אני יכול לדמיין מצלמת אבטחה שאתה יכול להוציא סיכום יומי של מתי נראו בני אדם במהלך היום וכמה בני אדם ראיתי . . .
• (ניב) לגמרי - ואם אתה לא רוצה להוציא את ה-Frame הזה, שמכיל את האנשים - ולצורך העניין יזהו את הפרצופים או את לוחיות רישוי או דברים כאלה, ואתה רוצה לשמור את ה-Frame עצמו במצלמה ולבצע את כל העיבוד במכשיר הקצה, אז אתה תצטרך איזושהי יכולת לעשות את זה, וכנראה שתצטרך לעשות את זה בהספק שהמצלמה הזאת עדיין תוכל להמשיך לתפקד לאורך כל היום.

08:36 ה-Trade-off שבין העלות לבין היכולות / מה בתכל’ס אני עושה עם כל זה?
(רן) אז אתם “חיים בתפר” כרגע, זאת אומרת ככה בשיחת-ההכנה - אמרתי שהתחלתם מהכיוון של Computer Vision, אבל היום העולם רוצה LLM, אז גם את זה אתם עושים . . . אבל אחד הדברים שצריך פה לנהל זה איזשהו Trade-off, בין - דיברת מקודם על הספק, יש גם כמות החומרה, כמות הזיכרון, עלות החומרה - לבין יכולות המודל.אז נניח יש פה איזשהו Use Case - אפשר לחשוב על מצלמת אבטחה או כל Use Case אחר - איך מנהלים את ה-Trade-off הזה של בין העלות לבין היכולות?

• (ניב) כן, אז קודם כל - בתור אנשים שמכירים את החומרה שלהם הכי טוב, אז לנו יש את היכולת לבוא לתת את הייעוץ ואת ההכוונה ללקוחות שלנו.
• אנחנו עושים את זה על ידי זה שאנחנו קודם כל חולקים הרבה מאוד מודלים - יש לנו הרבה מאוד Public ו-Open Source Software שאנחנו חולקים עם הלקוחות
• הרבה מאוד תוצאות, Model Zoo, דברים מהסגנון הזה.
• יש הרבה מאוד מודלים שאנחנו כבר מאיצים על החומרה שלנו ובעצם יודעים לחלוק עם הלקוחות שלנו הרבה מאוד דברים - אז אני יכול להראות לך בדיוק איזה מודל רץ ובאיזו מהירות, וככה אתה תוכל לבחור את ה-Deployment Scenario שיתאים ל-Use Case הספציפי שלך.

(רן) כלומר, Well-known State of the Art models?

• (ניב) בדיוק. נניח, אם אנחנו מדברים על Object Detection - נניח שזו אפליקציה מאוד סטנדרטית שתרצה להאיץ, אז אם אתה במצלמת אבטחה אז אתה תוכל להסתכל על בערך 30-50 מודלים ולבחור את המודל שמתאים ל-Use Case הספציפי שלך.
• וכמובן ה-Scenarios היותר מעניינים מבחינתנו זה דברים שהם לתפור ללקוח ספציפי איזושהי אפליקציה ולתמוך בו בשביל ממש לבנות את ה-Embedded Device שלו ו . . .

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

• (ניב) בדיוק כך.

(רן) אוקיי, עכשיו - אז איך אנחנו, זאת אומרת, איך מטפלים בזה? זאת אומרת, נגיד, כשעוסקים ב-Machine Learning, בדרך כלל מדברים על Accuracy או False Negatives, False Positives, זאת אומרת, כל אחד וה-Use Case שלו. אבל איך מנהלים את זה לעומת, נגיד, יכול להיות  . . . אם זה וידאו, אז קצב הביטים שעובר, או קצב התמונות לשנייה, הרזולוציה של התמונה . . .  זאת אומרת, אפשר לשחק עם כל מיני פרמטרים. ובסופו של דבר, עלות של החומרה - אני מניח שיש לכם כמה סוגים של חומרות, עם מחירים שונים - איך אני יכול לקבל החלטה? זאת אומרת, הזכרת את ה-Zoo, אבל מה בתכל’ס אני עושה עם כל זה?

• (ניב) כן, אז בעצם יש לנו שני קווי מוצרים - 
• אחד שהוא מאיץ כללי, שאתה יכול לחבר לכל פלטפורמה שאתה בוחר.
• והשני זה איזשהו SOC, System on Chip שלם - שאתה לוקח צ'יפ אחד, ואתה ממש יכול להטמיע אותו בתוך מצלמת אבטחה [למשל]
• והוא מספק לך את כל השירותים שאתה צריך - כולל עיבוד התמונה וגם האצה של רשתות הנוירונים, שזה בעצם ה-IP של החברה.
• אז יש בעצם שני סוגי מוצרים שאתה יכול לבחור מביניהם - ובעצם ה-Deployment Scenario שלך, כשאתה בא להטמיע איזשהו מכשיר במכשיר הקצה, אז הוא יתאים.
• אנחנו נתאים את ה-Use Case שלנו ואת המוצרים שאנחנו יכולים למכור לפי ה-Use Case.
• אז סתם בשביל לסבר את האוזן, נניח אם אנחנו מדברים על מצלמת אבטחה, זה אולי קצת יותר ברור לפי המוצרים שתיארתי, אבל אם יש לנו איזה שהם Deployment Scenarios אחרים - Gateways, Drones, דברים אוטומטיביים (Automotive) . . .

(רן)  כשאתה אומר “Gateway“, למה אתה מתכוון? כי בעולם ה-Networking, ה-”Gateway” זה כנראה משהו שונה . . .

• (ניב) נכון, אז כשאני אומר Gateway, אני מדבר נניח על איזשהו מכשיר NVR-י כזה, שיודע לקבל הרבה מאוד Stream-ים של וידאו - אתה יכול לדמיין שדה תעופה, סופרמרקט, דברים כאלה, 30 Stream-ים של Video. . . . 
• (רן) הבנתי, זה מכשיר “מרכזיית . . . “ מה שנקרא CCTV.
• (ניב) כן, אז גם זה לצורך העניין, מבחינתנו כל עוד ה-Stream-ים של הוידאו האלה לא יעלו ל-Cloud, אז גם זה יכול להתחשב כ-Deployment של Edge Device.

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

• (ניב) זה לא בענן.

12:47 אימונים ועדכונים
(אורי) יש לי שאלה - מודל זה משהו שמאמנים ועושים לו Deployment. כשאתה עובד ב-Cloud או לא משנה איפה - אולי כן משנה איפה . . . - אתה רגיל לאמן ולעשות Deployment למודל. לא יודע מה, ב-Outbrain זה קורה כל חמש דקות. איך Edge Device, שבכוונה אולי לא מחובר לאיזשהו Cloud, ושאולי גם לא רוצה לשתף - איך עושים עדכונים של המודל?

• (ניב) אז זו שאלה מצוינת. זה מאוד תלוי כמובן ב-Use Case ובחברה - רכב אוטומטיבי (Automotive) לא יעשה עדכונים של מודלים באותה צורה שלצורך העניין יעשו בשדה תעופה.
• אבל כן, לכל לקוח יש איזשהו On the Fly Update כזה שהוא מסוגל לבצע.
• זה בדרך כלל קורה בעצם לא על המכשיר-קצה עצמו - אז יהיה לך עוד מכשיר אחר, לצורך העניין איזשהו Server Offline-י, ששם אתה יכול להריץ את ה-Compiler שהזכרתי, לקמפל מודלים נוספים כל הזמן.
• ובעצם התוצר של ה-Compiler זה איזשהו קובץ בינארי שאותו אתה יכול להעתיק ולהפיץ לכל מכשירי הקצה שלך ובעצם להחליף On the Fly לקובץ הבינארי החדש, עם המודל המעודכן שלך.

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

• (ניב) נכון. אז אני יכול לתת דוגמה לאיזשהו Deployment שיש לנו [עם] חברת סופרמרקטים, שבעצם כל הזמן צריכה לעדכן את המודל כי כל הזמן נוספים מוצרים נוספים לסופר כמובן.
• אז כן, יש להם איזשהו מחשב בסופר עצמו שיודע לצורך העניין לאמן את המודל על תמונות חדשות.
• הוא לא מאמן את המודל כל פעם From Scratch, זה איזשהו Fine Tuning ל-Class-ים חדשים.
• וכן, הוא יודע להפיץ את התוצר של האימון הזה לכל הקופות החכמות שלהם וככה לעדכן, למרות שהם לצורך העניין רק הוסיפו איזשהו מוצר חדש לסופר, כבר להכין אותו ולהיות מוכן לזיהוי כבר בקופה החכמה.

15:19 לעשות GenAI על החיות הקטנות והמסכנות האלה
(רן) רמזת לי קודם שמשעמם לכם, כי אמרת שקמתם יום אחד והחלטתם שאתם רוצים לעשות GenAI על החיות הקטנות והמסכנות האלה . . . אז בואו נדבר על האתגרים שבדבר הזה.אז רק לסדר גודל, [עבור] אנשים שלא מגיעים מהעולם הזה. אם לפני זה דיברנו על מודלי Vision, שיש להם אולי עשרות-מיליוני, אולי מאות-מיליוני פרמטרים, למודלים הגדולים - ב-GenAI, ב-LLMs וכו’ - המודלים הקטנים ביותר מתחילים בערך במיליארד, אוקיי? אולי קצת פחות, אבל זה פחות או יותר סדר הגודל. זאת אומרת שאתה כבר מתחיל באיזשהו סדר גודל יותר גדול ממה שהיה לך לפני זה.המודלים שחיים בענן זה מאות-מיליארדי פרמטרים - אבל אותם אתם לא שמים על הצ'יפים . . . אבל בכל אופן, נגיד מודל בגודל של מיליארד, שני מיליארד - זה עדיין מודלים קטנים בעולם של LLM-ים, אבל די מפלצתיים לצ'יפים כאלה קטנים, שגם אמרת שהם צורכים מעט אנרגיה.איך בכלל תוקפים את הבעיה הזאת? זאת אומרת, איך לוקחים כל כך הרבה פרמטרים, מודלים כל כך מורכבים - ושמים אותם על צ'יפ כזה?

• (ניב) כן. אז קודם כל, מדובר באתגר מאוד גדול.
• הזכרנו באמת שהתעסקנו במשך הרבה מאוד שנים רק ב-Computer Vision - וסתם בשביל באמת כדי לסבר את אופי הבעיה שהזכרת, אז באמת כמות החישובים שיש לבצע ב-LLM בשביל לספק את ה-Token הבא, את הפרדיקציה (Prediction), היא די דומה לכמות החישובים שיש לעשות לצורך העניין ברשת YOLO Object Detection סטנדרטית שאנחנו רגילים לעבוד איתה.
• אבל מדובר בערך בין סדר גודל אחד לשניים של כמות פרמטרים יותר גדולה.
• כמובן שאתה מתעסק ב-Embedded Device . . . 

(רן) כלומר, ה-Latency End-to-End הוא אולי אותו Latency - אבל הרוחב הוא הרבה יותר . . . 

• (ניב) אז ה-Latency - הוא נשלט לא תמיד על ידי כמות החישובים, לפעמים בעצם מה שמגביל אותך זה דווקא כמות הפרמטרים שאתה צריך להביא מהזיכרון.
• זה גם פרמטר מאוד חשוב, בטח כשאתה מתעסק ב-LLM-ים.
• למעשה, ה-Interface שלך על ה-Memory לפעמים הוא אפילו יותר חשוב מכמות החישובים, מכמה מהר אתה מסוגל להאיץ חישובים.
• (רן) . . . אולי יהיה לנו זמן לדבר על KV Caching . . .
• (ניב) כן, בדיוק . . .
• (ניב) בכל מקרה, כן - מדובר באתגר מאוד גדול: אנחנו מתעסקים ב-Embedded Device, אז יש לנו Constraint-ים בערך לכל כיוון שאתה לא מסתכל.
• אם זה ב-DRAM Capacity, אז אתה צריך להחזיק על Embedded Device כזה
• לצורך העניין, אתם יכולים לדמיין איזשהו Raspberry Pi או משהו מאוד מוגבל מבחינת גודל הדיסק שיש לו.
• אז צריך להחזיק את המודל עם כל המשקולות שלו שם.
• אז אנחנו משתמשים בטכניקות של Compression, קוונטיזציות, דברים מהסגנון הזה - בשביל להיות מסוגלים לדחוף את המודלים האלה לתוך DRAM Constraint.
• יש לנו... 

(רן) בוא נעצור שנייה ונסביר מה זה קוונטיזציה . . . 

• (ניב) כן, אז קוונטיזציה זה בעצם תהליך שבו לוקחים מודל שמגיע אחרי Training, הוא מגיע בייצוג של Floating Point.
• בדרך כלל 16 בעולמות Deep Learning, או 32.
• (רן) כלומר תופס 16 Bit או 32 Bit . . .
• (ניב) 16 Bit לכל משקולת . . .
• (רן) . . .  כפול מיליארד, כן?
• (ניב) נכון, בדיוק.
• אז נניח מודל של אחד ביליון פרמטרים שהזכרת, אז הוא יתפוס על הדיסק 2Gb.
• ו-2Gb זה אולי נשמע לנו לא מאוד גדול - אבל ל-Edge Device זה יכול להיות Limitation בפני עצמו.
• (רן) עכשיו, זה לא בדיסק - זה צריך להיות בזיכרון, כל הסיפור הזה . . . 
• (ניב) נכון, זה צריך להיות בזיכרון הריצה - אתה ממש צריך אותו, לגשת אליו בצורה Frequent.
• וברגע שאתה רוצה לדחוס את המודל, טכניקה מאוד סטנדרטית זה בעצם לקחת את הייצוג הזה ולדחוס אותו לייצוג יותר קומפקטי.
• משהו סטנדרטי בעולמות ה-LLM זה ל-4 Bit.
• אז בעצם לוקחים את השני 16 Bit האלה שהזכרנו - ולכל משקולת, נותנים לה עכשיו רק 4 Bit בזיכרון.
• אז מן הסתם מרוויחים x4 ב-Memory.
• זה מציב איזה שהם . . . כמובן שהדחיסה הזאת מלווה באיזושהי הוספה של רעש ודגרדציה (Degradation), שיש הרבה פיתוחים אלגוריתמיים שמטרתם היא להחזיר את ה-Accuracy הזה שנאבד, אבל כן, זה התהליך עצמו.

(רן) כלומר, הארכיטקטורה - אותו נוירון מחובר לאותם נוירונים, אבל עכשיו הדיוק שלו הוא קטן פי - כמה? 2 בחזקת 4?(אורי) זה רק מקטין את הדיוק, או שאתה יודע לפצות ב-Uncompressed, שעולה לך ב-CPU בסוף?

• (ניב) אז תראה, קודם כל בעולמות ה-Computer Vision, גם שם היינו עושים קוונטיזציה, אבל שם זה לא היה בשביל לחסוך Disk Space, זה בדרך כלל היה בשביל לחסוך ב-Compute.
• גם כשאתה מבצע את החישובים עצמם - זאת אומרת, לעשות מכפלות שנמצאות בליבה של כל רשת נוירונלית (Neural Network) - זה בעצם בסופו של דבר מכונה שיודעת להכפיל מטריצות ענק
• אז גם להכפיל מטריצות לצורך העניין ב-Fix point וב-8 Bit . . . ב-8 Bit זה עלות הרבה יותר זולה מאשר להכפיל Floating Point ב-Floating Point, שזה פשוט מאוד מאוד יקר בחומרה - להחזיק הרבה מאוד מכפילים בתוך החומרה שלך.
• (רן) כן, פעולת הכפלה של Int-ים (Integers) היא יותר זולה מפעולת הכפלה של Floats.
• בדיוק, אז בעולמות ה-Computer Vision זה הגיע מעולמות ה-Compute, זו בעצם המטרה - שרצית לחסוך.
• בעולמות של Generative AI - וזה לא מיוחד רק ל-Hailo, זה באופן כללי - המטרה היא כמעט Exclusively לחסוך Memory והבאה של ה-Memory ליחידות שיודעות לבצע בעצם את המכפלות עצמן.

(אורי) מה שאני שואל זה האם זה בא - ה-Compression הזה - הוא בא במחיר של איכות, או שאתה יודע גם לעשות לו Un-Compress ואז...

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

(רן) חוץ מ-MP3! חוץ מ-MP3 -  זה קסם!

• (ניב) כן . . . יש אולי דחיסות כמו JPEG שגם אתה לא תראה בעין, אבל אין דבר כזה דחיסה שהיא בעצם Loss-less לחלוטין,
• עד כדי חוקי Shannon . . .  שהוציא את זה לפני, כן . . . המציא תורה לפני 80 שנה וכתב את כל החוקים האלה.
• אבל כן, אנחנו מדברים פה על Lossy Compression - אז כמובן שיש איזושהי דגדציה (Degradation) שנוצרת כתוצאה מהדבר הזה.

• הרבה מאוד מחקר - גם אצלנו בחברה יש צוות שלם שמתעסק בעצם ב-Model Optimization ובעצם באלגוריתמיקה שכל מטרתה היא להחזיר את ה-Accuracy הזה שנאבד כתוצאה מה-Compression הזה.
• יש הרבה מאוד פיתוחים, בטח בעולמות של Generative AI - אבל גם בעולמות של Computer Vision,
• הרבה מאוד שיטות שפותחו עם השנים, כנסים בתחום הזה . . . 

(רן) אני לא מכיר, אז אני אהמר - אז נגיד שעושים קוונטיזציה למודל, ואז עושים לו עוד איזשהו שלב של Tuning או Fine Tuning, כדי להחזיר לו את העטרה ליושנה?

• (ניב) כן, אז זו באמת שיטה מאוד סטנדרטית - שעושים איזשהו Fine Tuning על המודל המקוונטט, Quantized.
• בעצם באמת להחזיר לו את ה-Accuracy הזה שנאבד כתוצאה מהקוונטיזציה.
• לפעמים עושים את זה על כל המודל, לפעמים עושים את זה על חלקים, Step by Step כזה, על איזשהם סגמנטים בתוך המודל.
• יש הרבה מאוד שיטות ו... 

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

• (ניב) אז כן, בעולמות ה-Generative AI זה מאוד מקובל כמובן כן להתחיל מאיזשהו Public Hugging Face Model. זו הנקודת התחלה שלנו גם.

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

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

(רן) כן, אז רק נסביר מה זה Distillation: לוקחים מודל גדול שהוא חכם - נקרא לו “המורה” - ולוקחים מודל קטן יותר, ומשתמשים במודל הגדול על מנת לאמן את המודל הקטן. לפעמים קוראים לזה Teacher-Student, נהוג לקרוא לזה Distillation. ואז בסופו של דבר אנחנו מקבלים מודל קטן - אבל שהוא יותר חכם ממקודם. הוא אולי לא חכם כמו המודל הגדול, אבל הוא יותר חכם ממה שהוא היה לפני זה, ואתה אומר שאז, בשלב הבא, עושים את הקוונטיזציה (Quantized).

• (ניב) כן, אז לצורך העניין אנחנו משתמשים בטכניקה הזאת גם ב-Fine-tuning שהזכרנו מקודם של הקוונטיזציה, ושם ה-Teacher הזה שהזכרנו, הוא בעצם המודל ה-Floating Point הראשוני שהתחלנו ממנו, וה-Student הוא יהיה המודל ה-Quantized, שמנסה ללמוד ולהחזיר את ה-Accuracy הזה שנאבד כתוצאה מה-Complression הזה.

24:07 מודלים היברידיים
(רן) אוקיי, עכשיו בוא נחזור נגיד לדוגמה של NVR או CCTV או Whatever איך שקוראים לזה: אז המערכות שהן קצת יותר גדולות - אוקיי, זה כבר לא מצלמה בודדת, יכול להיות שהן כן מחוברות לאינטרנט, זאת אומרת עדיין יש עניין של Privacy, אבל יכול להיות שהן כן מחוברות. האם יש מודלים של איזושהי עבודת Hybrid? כלומר, חלק מה-Proccessing קורה על החומרה שלכם - בין אם זה משיקולי Privacy, משיקולי עלות, לא יודע, משיקולים אחרים - וחלק אחר כך ממשיך בענן?

• (ניב) כן, אז יש הרבה מאוד אפליקציות שמטרתן היא באמת לנסות לחסוך גם Storage בענן, גם Bandwidth וכן הלאה, הרבה מאוד Cost שניתן לחסוך על ידי איזשהו עיבוד ראשוני שנעשה ביחידת הקצה, אבל בסופו של דבר כן רוצים, מטעמים שונים ומשונים, להעלות את הדאטה עצמו ל-Cloud.
• זה יכול להיות בשביל Record שיקרה Offline או לעיבוד יותר מסיבי שאנחנו רוצים לעשות.

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

• (ניב) כנראה שהוא צריך להתנהל בתוך הכוכב ולקבל כמה החלטות נאיבות מרכזיות, אז כן - אז כנראה שיש לו איזושהי יחידת עיבוד שצריכה להיעשות על גבי ה-Device עצמו.
• אבל חלק מרכזי בעצם בפעילות שלו היא תהיה לשלוח את הדאטה אחורה.
• ואם הוא יכול, באיזושהי יכולת שכנראה שב-2025 היא תהיה משוייכת ל-AI בצורה כזאת או אחרת, לזהות את ה-Frame-ים המעניינים וגם לשלוח אלינו רק את הפריימים (Frames) שלצורך העניין לא מוסתרים על ידי איזשהו סלע, זה יהיה גם נהדר.
• (אורי) או שהוא יוכל לייצג את ה-Inference שלו ולשלוח את ה...
• (ניב) נכון, שזה לצורך העניין סוג של דחיסה, אם הוא ישלח לנו רק את ה-Embedding, אבל או איזשהו ייצוג יותר... 
• (רן) “היי, ראיתי חייזר!”
• (ניב)  . . . כן, ייצוג יותר High-Level-י של מה שהוא רואה - אבל אפילו לפני זה, היית רוצה אולי לקבל את הדאטה הגולמי ולאבד אותו בעצמך.

(רן) אוקיי, אז ה-Business הזה של שילוב, זאת אומרת של ה-Hybrid - כלומר שילוב בין ה-On Device או Edge Device לבין ה-Cloud - זה גם משהו שעושים אצלכם ב-Hailo?

• (ניב) כן, בעולמות ה-Generative AI זה נראה שזה באמת הולך להיות איזשהו Deployment Scenario שיהיה מאוד מאוד מרכזי במה שהלקוחות מחפשים.
• אז הזכרנו קודם שהמודלים שאנחנו מתעסקים איתם הם מודלים קטנים, אנחנו מדברים על מודלים של קטנים מ-7 מיליארד פרמטרים.
• זה המודלים פחות או יותר שאנחנו רואים היום שהולכים ל-Edge Devices.
• והם מודלים שהם מוגבלים - בסוף הם לא ה-ChatGPT וה-Claude שאנחנו רגילים להשתמש בהם ב-Day to Day שלנו.
• אז המשימות שהם מסוגלים לעשות הן יהיו איזושהי משימת Agent-ים סטנדרטית ויחסית פשוטה - הם מסוגלים לקבל החלטה והם גם יודעים להגיד “אוקיי, את זה אני לא יודע לעשות ואני אעביר ל-Cloud”
• והמטרה זה לעשות את זה כמה שפחות.

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

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

(רן) מה שאני אומר זה שזו כבר לא תהיה חוויה נחותה - כלומר, זה לגמרי ריאלי להשתמש במודלים בגודל 7B ולקבל State of the Art - במה שהם צריכים לעשות.

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

(רן) הם יעשו עבודה מצוינת, כן.
28:14 איך אני משלב את Hailo בתוך ה-Raspberry Pi הבא שאני בונה?
(רן) אוקיי, תראה, יש פה הרבה נושאים וכיוונים מעניינים, אבל אנחנו כבר עוד מעט לקראת הסימן שלנו.יש עוד נושא שלא כיסינו שכן היית רוצה שנכסה?

• (ניב) כן, אני אשמח לדבר על איזושהי פלטפורמה ש[באמצעותה]ניתן להגיע ל-Hailo - אם מישהו מתעניין, לנסות קצת לשחק עם הצ'יפ וכן הלאה.
• אז יש לנו איזשהו שיתוף פעולה עם חברת Raspberry Pi - בעצם, אנחנו מייצרים את ה-AI HAT שלהם.
• זה HAT שבעצם - מי שמכיר את המוצרים של Raspberry Pi - זה יכול להתחבר לפלטפורמה שלהם ולספק שירותים ויכולות AI על גבי ה-Raspberry Pi.

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

• (ניב) אז מהאתר של Raspberry Pi ניתן לקנות -מי שמכיר - הרבה מאוד תוספות לצ'יפ שלהם.
• אז אחת מהתוספות זה יכול להיות לצורך העניין סנסור-מצלמה, שניתן לחבר ל-Pi.
• ולאחרונה, בשנה-שנתיים האחרונות, גם HAT - שזה איזשהו Board שניתן לחבר על ה-Pi - של AI.
• ובתוכו נמצא בעצם צ'יפ של Hailo.
• אז בפחות מ-100 דולר אתה יכול לקנות איזשהו Deployment Scenario ל-Edge Device שלך ולהתחיל לפתח איזשהן אפליקציות לבית או לאיזשהו רובוט שאתה בונה.

(רן) ואיך זה פיזית עובד? כאילו, אני פותח את הקופסה, מחבר את הצ'יפ וסוגר? איך זה עובר? איך זה נראה בסוף?

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

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

• (ניב) נכון, אז יש בעצם Community של יותר מ-10,000 משתמשים כבר ב-Raspberry Pi, ב-AI של Hailo
• אז אתה כנראה לא תתחיל מ-0, אלא תתחיל מאיזשהו פרויקט שכבר קיים בשטח, ותוכל באמת להתנסות כבר באיזשהו פרויקט מוכן.
• אבל אם תרצה לקחת את המודל שלך, לאמן אותו על דאטה משלך וכן הלאה, אז גם ה-Compiler שלנו פתוח ללקוחות ה-Raspberry Pi, ואתה תוכל לקמפל את המודל שלך ובעצם לעשות לו Deployment.

(רן) אז אתם הולכים אצלכם במשרד ויש לכם כל מיני עציצים שמדברים אליכם, ושירותים שמורידים מעצמם? . . . 

• (ניב) כן, כל עובד ב-Hailo קיבל את ה-Raspberry Pi HAT הזה, ומשחק איתו בבית עם הילדים.

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

• (ניב) כן, מעולה. אז אנחנו יושבים ביגאל אלון בתל אביב, במגדל סוזוקי.
• מגייסים למגוון משרות די גדול
• בעיקר מתעסקים כמובן ב-Embedded, אז כל מה שקשור למפתחי Embedded חזקים, אנשי R&D שאוהבים C, C++ ורוצים להיכנס לעולמות האלה של AI ו-Deployment של AI, לרשום איך Pipeline של LLM עובד - מוזמנים לפנות אלינו.
• אנחנו גם מתעסקים ב-Computer Vision - אז כל מה שקשור לעולמות של מצלמה, עיבוד תמונה וכן הלאה.
• הרבה מאוד דברים ופעילויות מאוד מעניינות שקורות אצלנו.
• נשמח.

(רן) בת כמה החברה, דרך אגב?

• (ניב) החברה מ-2017, כבר שמונה שנים.

(רן) וכמה עובדים היום?

• (ניב) קרוב ל-300.

(רן) כולם בישראל?

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

(רן) אוקיי.
טוב, תודה רבה! נשמע לי אחלה אתגר. אז שיהיה בהצלחה.[קישור לקובץ mp3]האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 497 של רברס עם פלטפורמה, שהוקלט ב-1 ביולי 2025 - עוד מעט פרק 500 ובינתיים עדיין מלחמה [634/50], ואורי ורן מארחים את רומה [טימושפולסקי] מ-YozmaTech כדי לדבר על כוח אדם מהזוית של AI ועל השפעות הדדיות על חברות, על צוותים ועל אנשים. 🎗️


01:22 רומה ויוזמה-טק
(רן) רומה - יזם, בעלים של YozmaTech - אז כן, תן לנו את “השפיל” . . . 

• (רומה) טוב, אז קודם כל - מדהים להיות פה, מדהים שאנחנו יושבים בשקט, למרות שבדרך היה ההבזק של חץ . . . החות’ים עשו לנו הפתעה.
• שתי מילים עליי - אז השם משפחה טימושפולסקי: אפילו בטקס הסיום של הבת שלי אתמול המנהל בית ספר התבלבל, אבל בסדר, רגילים לזה.
• בגדול, אני מגיע מהעולם של היזמות - תוך כדי האוניברסיטה התחלתי להקים כבר חברה ראשונה, וזאת החברה החמישית שלי - YozmaTech.
• בדרך הצלחתי למכור שתיים, שתיים הצלחתי לסגור.
• ו-YozmaTech נולדה ב-2018, שנתיים אחרי שהגעתי למזרח אירופה.
• ומה ש-YozmaTech היום נותנת זה חברת שירותים - שירותי טכנולוגיה, מתמחים ב-Out-staff בכמה Layer-ים של Service.
• גם הקמת צוותים, גם הקמת מרכזי Excellence ו-Local R&D Centers, בעשר מדינות שונות.
• עובדים בעיקר עם חברות ישראליות בשלבי Scale.
• בכל מיני Domain-ים, אגנוסטי לחלוטין.
• אני עובד אישית, מאוד נהנה לעבוד עם פאונדרים ועם מנהלי פיתוח - בסופו של דבר יש פה אסטרטגיה ויש פה איזושהי השפעה מאוד מעניינת.
• כשבאתי לדרור אמרתי לו “תקשיב, יש פה איזשהו Game Changer בשוק בשם AI” . . .
• בדיוק נזכרתי פה, ישבתי עם מישהו שמפליג איתנו ואמרתי לו “בוא’נה דניאל, תקשיב - איך ה-AI משפיע עליכם?”, במפגש האחרון שעשינו של הקהילה.
• הוא אמר לי “תשמע, אתה לא מאמין הוא עשה לי! Game Changer, כאילו, לטובה”.
• יש השפעות, אבל כשהפלגנו בספטמבר, “בסדר, AI - זה לא אפילו בעיה במפת דרכים שלנו קדימה”.
• ופתאום עכשיו, בשנה הזאת, כל כך הרבה שינויים.
• הנה עכשיו מאור שלמה עם Base44 ו-80 מיליון מכירה ל-Wix - זה מזעזע את השוק.
• גם מזעזע את עולם ה-VC's וגם מזעזע את הקונספט - כולם חיים “בטיקטוק של AI” אני קורא לזה, ב-FOMO.
• אבל יש את המציאות.
• זה מה שקורה, אלה הדברים שאני רואה בשוק היום.

(רן) כמה מילים על YozmaTech?

• (רומה) אוקיי. אז YozmaTech - חברת בוטיק, כמו שאמרתי, חברה טכנולוגית, מתמחים ב-Service.
• כמו שאמרתי, המוצר המרכזי, השירות המרכזי זה Out-Staff: זה הרחבת הצוותיים בחו״ל, בעשר מדינות שונות.
• 50% באוקראינה - שם הצוותים, שם התחלנו, ב-2015.
• אני הגעתי לשם ב-2015 - לא ידעתי איפה זה אוקראינה, אבל הגעתי לשם, ללבוב - במקרה, כי היתה לי איזושהי יזמות, וככה זה התגלגל.
• פתאום בקורונה בא לקוח די גדול, שלא רוצה לעבור משרדים.
• הוא אהב את המשרד שלו בלילנבלום, והוא אמר לי “תקשיב, אני לא רוצה, אני רוצה לגייס עכשיו צוותי Unity”. 
• אמרתי “טוב, גם ככה יש לך אופרציה שם, בוא תעזור לי, תגייס לי וכו’”.
• וככה זה התגלגל.
• ראיתי שיש לזה ערך, ושאנחנו יודעים באמת גם לגייס וגם לשמר, גם לעשות את כל האופרציה - ונהנים מזה.
• יש אנשים שלא אוהבים אופרציה ותפעול - אנחנו טובים בזה.
• (רן) אני . . . . אשתי יודעת, זה בסדר.
• (רומה) כן, רוב המנהלי-פיתוח לא אוהבים את זה - והיזמים רצים מהר.
• והקורונה האיצה את השוק בצורה מטורפת. אתה יודע, תהליכים שהיו תקועים שנים, אתה זוכר את זה בטח, פתאום יש לך תהליכים שהם “טסים".
• וכסף נשפך, וכולם מדברים על Scale.
• ובאה 2021 - שאתה יודע, הבורסה עולה, והכול יורה, “רק תביא לי מפתחים”.
• אמרתי “טוב, יש פה . . .  אנחנו כבר שמה, אז בואו נעשה משהו עם זה”.
• וככה זה התגלגל - החברה היום מונה 150 עובדים, צומחים.

(אורי) צומחים?(רן) מעולה. 

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

05:41 צומחים עם AI
(אורי) אז בואו שנייה, נכניס את ה-AI למשוואה - הוא משנה לכם משהו בשנה האחרונה?

• (רומה) חד-משמעית, כן. עכשיו הייתי... 

(אורי) הוא משנה בקצב הצמיחה?

• (רומה) הוא משפיע . . . השוק זז מהר, כן? לפי שאני יושב עם אנשים, והם אומרים “שמע, אני לא מספיק, לא מספיק, לא מספיק”, כי המימד של הזמן - יש מחקרים שהזמן התכווץ . . . 
• מה שה-24 שעות היו פעם, הם לא באמת 24 שעות, כי הזמן רץ.
• התהליכים מאוד מהירים. ה-AI האיץ את השוק.
• בסופו של דבר, המלחמה היא על Go-To-Market: כמה מהר אתה מייצר כניסה לשוק.
• הרי למה החברות יוצאות לחו״ל? מה, אין מספיק מפתחים טובים בארץ? מה, זה עניין של כסף? 
• לא. זה עניין של Go-To-Market.
• זה עניין של טאלנטים?
• הסיבה המרכזית שחברות חושבות על Scale זה Time to Market.
•  זו הסיבה המרכזית. לא כסף.

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

• (רומה) יפה, יפה. בדיוק כזה. אז בפועל - אנחנו רואים משהו הפוך.
• חברה שכבר בשוק . . .  נגיד, יש כל מיני סוגי חברות. נכון שאתה כבר לא צריך מפתחים לשלב ה-MVP, ונכון שאתה יכול להאיץ.
• אבל תחשוב על חברה עם צוות פיתוח של 50 איש או מחלקה של פיתוח של 50 מפתחים - שיש להם כבר קוד של מעל חמש שנים, עשר שנים.
• זה לא כזה מובן מאליו להכניס כשהכול Shakey עדיין, כן?
• אפילו איך אתה שומר את ה-Prompt-ים שלך, כדי שהארגון יעבוד בצורה מהודקת . . . 
• אז לשאלתך - אין ספק שיש Shift מאוד גדול. זה כבר לא אותו מהנדס Full-Stack שהוא עושה Full-Stack.
• היום אתה יכול לשים Prompt - ורק לפקח עליו. 
• כמו בטיסה, כשאתה עולה לטיסה או כשאתה עולה לספינה - אתה לא באמת משיט אותה או מטיס את המטוס, כן? אתה יושב ומפקח על הטיסה בסופו של דבר. במקרה קיצון . . .
• וזה בדיוק התהליך שעולם התוכנה היום עובר - שהמפתח, אותו המפתח, הוא למעשה המטיס.
• הוא עדיין קיים, הוא עדיין בתא-טייס - אבל הוא עכשיו מפקח על הטיסה: על האיכות קוד וכו’, איך הוא משתלב.
• בגלל שכל הזמן יש שינויים בשוק, אז חברות ותיקות - יותר קשה להן לייצר Innovation, ולכן . . . 
• האם הכוח אדם - אנחנו לא נצטרך כוח אדם?
• הרבה “משימות שחורות” של בניית Test Cases ו-Unit Tests, בדיקות, או אינטגרציות מסוימות - אנחנו לא נצטרך.
• וזה ה-Shift המרכזי שאנחנו רואים כרגע.

08:37 השוק השיראלי וחיות אחרות
(רן) תיכף נחזור לנקודה הזאת, נעשה פה רגע עצירה. אז עד עכשיו, בפודקאסטים שלנו, באמת דיברנו על טכנולוגיה - ובין השאר גם על AI - יותר מהזווית הטכנולוגית.אז כמו שאנחנו מבינים, היום בעיקר נתמקד בזווית האנושית, האסטרטגית - וזה בדיוק התחום שלך. אבל קצת לפני זה, לפני שאנחנו נחזור לנושא ה-AI - היום אנחנו, כמו שאמרנו, ב-1 ביולי, 2025, אחרי לא יודע כמה מלחמות, לפני אני לא יודע גם כמה - אבל הרבה אנשים עוצרים ושואלים את עצמם, “אוקיי, איפה נמצא השוק הישראלי עכשיו, עם כל הזעזועים האלה?” ועברנו לא רק מלחמות - עברנו גם קורונה, וזאת אומרת, יש גם לא מעט עניינים גיאופוליטיים בישראל שהם לא רק מלחמות - וגם מאוד משפיעים על השוק. עניין חברתי, ושלטון וכו'.איפה נמצאות החברות הישראליות היום? איפה נמצא השוק? איך נראה גיוס הכספים? איך נראה ה-Growth של חברות שאיתן אתה עובד?

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

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

• (רומה) והיום דיברתי עם מנהל פיתוח שהוא לקוח שלנו, והוא אמר “תקשיב, הלקוחות האמריקאים מתפלאים איך אתם ממשיכים לעשות Delivery תוך כדי מלחמה, ולייצר חדשנות ו-Service וכו’, ולא עוצרים.
• אני לא אומר שזה בגלל שיש להם צוותים בחו״ל - אלא בגלל שהישראלים למדו גם לעבוד מרחוק, וגם מצב הרוח הוא חיובי, עם כל המצב הזה.
• אני חושב שעכשיו, גם שמענו עכשיו על עסקה ענקית עם רומניה - עסקת נשק אמנם, כן? - אבל יש ביקוש, אתה כבר, יש לך יכולת לדלבר (Deliver) תוך כדי מלחמה, לגייס כסף, הבורסה ממשיכה לעלות . . .
• זאת אומרת, השוק מגלם אמון.
• אני חושב שהשוק, וגם ה-AI נותן . . . . משפיע על זה.

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

• (רומה) היינו בדיוק בספינה בביפרים . . . 

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

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

(אורי) . . .  כן, זה מוסיף ודאות.

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

(אורי) לא, פשוט כל הכסף שהיה כבר יצא, אז כאילו... 

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

(אורי) גם שם וגם פה זה וולטילי (Volatile) - אז אנחנו בעולם וולטילי. אנחנו בעולם וולטילי.(רן) לשמחתנו שם גרוע יותר, אז... 

• (רומה) כן, אז בסוף יש, לשאלתך, יש מצב רוח מאוד חיובי, אני רואה הכנסה.
• אמנם הכסף היום הולך בעיקר לעולמות של Cyber ו-Innovation בתחום ה-AI - אתה גם שם.
• פחות לתחומים של SaaS - ה-AI השפיע על העולם של ה-SaaS בצורה משמעותית. 
• המודלים הכלכליים השתנו, העסקיים, איך... מה החברות מוכרות? החברות כבר לא מוכרות SaaS היום.
• זאת אומרת, המשקיעים גם לא מחפשים SaaS, אנחנו רואים את זה.
• זה השוק.

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

• (רומה) במפגש האחרון שלנו, של מנהלי פיתוח - יש לנו קהילה שנקראת Scale 24/6 - אורי היה במפגש - אז היה ממש דיון סוער על AI ואיך להטמיע.
• ואתה ממש רואה חברות שונות בגדלים שונים. בווליואציה (Valuation) שונה . . .  
• היה את אורן מ-Pango, שדיבר על מה שהם עושים
• היו חבר'ה חדשים מחברות Cyber צעירות יותר, שהקוד שלהן לא 18 שנה, אלא שנתיים - יותר קל להם להטמיע, החבר'ה שלהם יותר ב...
• אין ספק שזה משנה את התמונה, כן? ומה שהם אמרו זה מאוד פשוט - מי שלא יעשה את השינוי, פשוט לא יהיה. 
• וזה מה שקורה.
• מי שדינוזאור... 

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

• (רומה) אתה צריך לעלות על הרכבת, הרכבת יצאה.
• ויש התנגדויות - יש חבר'ה יותר ותיקים שמאוד קשה להם, שאמרו “תשמע, אני אכתוב יותר מהר, יותר איכותי מה-AI, עזוב אותי”.
• החבר'ה הצעירים פתאום מגלים שמה יש להם להפסיד? הם היו ככה שנתיים-שלוש בשוק, בואו - המניה שלהם עולה.
• נפתחות משרות חדשות - AI Project Manager, Innovation, Python Developer / AI, כן? מחפשים, ה-Score Card משתנה, כן? 
• דיברנו עם אורי על הנושא של Score Card, מה מחפשים? ה-Soft Skills משתנים, מחפשים יותר אנשים שהם . . . 
• אנשים מתחלקים לשתיים, יש את האינובטורים (Innovators) ויש את הביצועיסטים, כן? Executors.
• הם מחפשים את האינובטורים (Innovators) - אנשים שיודעים לעשות innovation, שזה מסקרן אותם, שהם פתוחים לשינויים.
• זה Soft Skills שונה, זה לא רק Hard Skills.
• (רן) כן, אתה מדבר בהקשר של גיוס, כן?
• (רומה) כן, הגיוס משתנה - וזאת הזדמנות.
• (רומה) מצד שני, יש משהו שהרבה אנשים לא מדברים עליו, וזה הסכנה הגדולה - הסכנה הגדולה שהחיפושים ב-Google של תואר ראשון במדעי המחשב צונחים . . . 
• כי בא מנכ״ל nVIDIA וזורק אימרה - הוא אומר “תקשיב, עוד חמש שנים לא נצטרך מפתחים”.
• אז מה, אנחנו לא נצטרך טייסים? בסדר, Tesla נוסעת בלי נהג, כן? . . .
• (אורי)  מה קרה לשימור עובדים ב-nVIDIA?
• (רומה) לא יודע. טס למטה . . . 
• (אורי) לא יודע.
• (רומה)  לא יודע, מה עניין, שאלה מעניינת, צריך לשאול את ה-Chat, או איזשהו HR . . . . 
• אבל בגדול, אתה רואה, ישבתי עם חבר שהוא - יש לו Agency של Marketing, הוא אמר, תקשיב, בוא תסתכל, שאלתי אותו שאלה - בוא נסתכל על נתונים בזמן אמת: כמות חיפושים - האוניברסיטאות, הטכניון, מתקשה לגייס, אז מה יהיה עוד?
• הולך להיווצר משבר - לא ייכנס כוח אדם חדש, כי אמרו “תשמע, גם ככה כג'וניור קשה לי להיכנס. מה יהיה כשאני עוד חמש שנים אסיים את התואר? או עד ארבע שנים - מה יהיה?”

(רן) האם נכון להגיד שהיום לג'וניור יותר קשה להיכנס?

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

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

• (רומה) ייווצר קושי . . .

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

• (רומה) אני באופן כללי בחו״ל לא מגייס ג'וניורים היום. 

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

• (רומה) משבר דו-שלבי. כנראה שיהיה לזה פתרון מסוים, אבל כן - הפצצות האלה שנופלות מהמובילים של ה-Big-7, כן - nVIDIA, Facebook וכו’ - הן מזעזעות את השוק.
• אומנם זה מאיץ את השוק, כן, בסופו של דבר - אבל זה מזעזע.
• בואו נגיד ככה - זה עושה Shift וצריך לחשוב עליו קדימה, כי באופן אחראי.
• כאלה שחושבים האם זה הפסיק את הגיוס? אני רואה עכשיו בום בכמות גיוסים, היום.
• כי בשנתיים הקרובות, לדעתי, ימשיך הבום הזה, של “אוקיי, בוא, איך אנחנו מייצרים יותר?”
• (רן) לתפקידי פיתוח? פיתוח תוכנה?
• (רומה) כן, פיתוח תוכנה, אנשי Product וכו’.

(אורי) אה, נגעת באנשי Product . . . זה לא אותו דבר, ואני אסביר שנייה למה: AI הוא אחלה, ה-Engagement הכי גדול שקורה לו, כאילו די “עולם התוכנה אוכל את his own dog food” - ועולם הפיתוח תוכנה מאמץ את ה-AI,תכל'ס הראשונים לאמץ, וזה מאוד נכנס למקום הזה. ואז פתאום צוואר הבקבוק שהיה לך בפיתוח - פתאום משתחרר, אוקיי? מפתחים, מפתחים יותר מהר, אז הצוואר בקבוק הזה משתחרר, לאן הוא משתחרר? לקצוות שלו.

• (רומה) ומי בקצוות?

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

• (רומה) שלא מספיקים לייצר לו דרישות . . . 

(אורי) לא, שיש לו אבטלה סמויה . . . 

• (רומה) בצוות פיתוח . . . 

(אורי) נכון, כי ה-Product לא מספיק - לא מספיק לייצר לו דרישות. ומהצד השני של הבקבוק הזה, של ה-Pipe הזה,יש את ה-Go-To-Market - פתאום מוציאים יותר. נגיד, שחרר את הפקק אצל ה-Product, פתאום יצאו הרבה יותר דברים לשוק. מישהו צריך לקחת את זה, לבנות חומרים . . . 

• (רומה) . . . לשווק אותם, למכור . . .

(אורי) . . .  לדלבר (Deliver) את זה לאנשי מכירות. אנשי מכירות - יש להם איזשהו Capacity שהם מסוגלים לקבל מוצרים חדשים.

• (רומה) אז מה אתה רואה?

(אורי) אז אני חושב שהצווארי-בקבוק יעברו לשתי הנקודות האלה - ויעשו טוב המפתחים שיתחילו לקבל Skills של שני הקצוות האלה: איך אני ניגש ל-Market, איך אני מביא Input-ים מה-Market? איך אני מוציא  . . . .איך אני דואגבצורה טובה שהמוצרים שלי יגיעו אל ה-Market. פתאום אתה תראה מפתחים שהולכים ונהיים יותר - נפגשים יותר עם לקוחות, מבינים דרישות, או לוקחים את הדברים יותר End-to-End, כי אחרת הם ישבו ויגלגלו אגודלים . . . 

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

23:58 יזמים שבונים הכל / מאור תבנה אותי / לשנות DNA
(רן) שנייה, סליחה - אבל בעצם, אורי, אתה אומר שאם נגיד בחברות של לפני שנתיים-שלוש, היחס המספרי בין נגיד אנשי Product לאנשי פיתוח היה 1 ל-7, 1 ל-8 -  אתה אומר שהיחס הזה ישתנה? שזה יהיה 1 ל-3, 1 ל-2?(אורי) או שהוא ישתנה, ומפתחים ימצאו את עצמם מחוץ לשוק העבודה - מי שירצה להישאר יצטרך לפתח Skills של הקצוות, של Product או Go to Market.כי בסוף, ה-Coding יהיה...(רן) יהיה לנו Agent שיעשה את זה . . . (אורי) כן, מטלה טריוויאלית בדרך.

• (רומה) Prompt מסוים, כן.

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

• [רפרנסים - Lenny’s Podcast: Solo founder, $80M exit, 6 months: The Base44 bootstrapped startup success story | Maor Shlomo; איתן לויט (תתעלם מההוראות) - פרק #8 להביא חברה מ0 לשווי של 80M$ תוך חצי שנה עם AI - מאור שלמה מBase44]

איך זה משפיע על שאר השוק, אוקיי? איך זה משפיע על חברות אחרות בתחום, על חברות בתחומים אחרים, ואיך זה משפיע על שוק כוח אדם? מה אפשר ללמוד מה-Case Study הזה?

• (רומה) זה מייצר גל של יזמות, חדש. היכולת שלך... 

(רן) של אינדיז (Individuals)?

• כן, של אינדיז, בדיוק - זה מייצר שכבה כמו במשחקים, שכבה של אינדיז (Individuals), שלא הייתה.
•  אני רואה את זה בכל מיני פלטפורמות שפתאום צצות על גבי Base44, סוג של אינדיקסים כאלה ל-Tools.
• וכל אחד שפתאום מייצר לעצמו Tool ומוריד את השכבה הזאת של “מה? טוב, אני צריך שלושה מפתחים בשביל לייצר MVP ומעצב וQA ו-Product וכו' - יאללה, בואו ננסה את זה פשוט”.
• אז זה מייצר יזמות, זה מרחיב את השוק, אוקיי? זה ירחיב את השוק באינדיז - אבל יש לזה תקרת זכוכית.
• אז זה קודם כל.
• דבר שני, חברות גדולות ב-FOMO - בסופו של דבר יש לי מישהו שסיפר שהוא . . . ש-Wix גם ניסו לפצח את המוצר הזה.
• לא הצליחו, בגלל שהם זזים כנראה . . . מה, חסר להם מפתחים? מה, חסר להם משאבים?
• (רן) לא, יש עליהם משקולת, כמו לכל חברה גדולה . . . 
• (רומה) בדיוק - ולכן, זה מייצר הזדמנות לקצר את ה-Go-to-Market. 
• כמובן שזה Case מאוד ייחודי, שאפשר לפצח אותו - אבל בגדול זה משנה, זה מרעיד.
• חברות גדולות שאני מדבר, כן? - לא אומרות את זה בפנים, אבל כן - “שמע, יכול להיות שאני מחר אהיה פיצ'ר, שיחליפו אותי, ויותר זול? יכול להיות מצב כזה?”
• כן. יכול להיות מצב כזה.
• זה מזעזע את המנכ״לים, כן?
• וזה גם מזעזע את ה-VC's. אוקיי, אז מה המודל העסקי?
• הוא עשה את זה Bootstrap בסופו של דבר.

(רן) ואתה רואה שינוי ארגוני בחברות כאלה? זאת אומרת, חברות שהן אומרות... 

• (רומה) הן מעמיקות, הן עוד יותר לוחצות על הגז.
• למה יש עכשיו בום? כי הן לוחצות על גז. כי למה? כי הם מייצרים . . . 
• קודם כל צריך לשנות מודל עסקי - למודל של Agent-ים, ולא מודל של SaaS כנראה.
• ודבר שני, צריך להעמיק את השוק - כדי שהלקוח, יהיו לו הרבה יותר עוגנים לאותו לקוח, ולא מחר יבוא איזשהו X ויחליף אותי, במוצר הרבה יותר זול וכו’.
• זה השינוי המרכזי.

(אורי) אתה אומר שיכול להיות ש-Wix קנתה את Base44 כדי להוציא מתחרה מהשוק?

• (רומה) חד משמעי.

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

• (רומה) ברור.

(רן) . . .  וזה לגיטימי, הרבה רכישות . . . תראה, זה גם וגם. (אורי) . . . לא, זה מעניין, אני חשבתי שזה דווקא כדי לייצר...(רן) . . .  אתה יודע, זה תמיד גם וגם.(אורי) כן.(רן) . . . זה גם וגם, בסדר, אני חושב שזה . . . לא הייתי קורא לזה משהו שהוא לא לגיטימי, וכל הרכישות בסופו של דבר,  אתה יכול להגיד, אוקיי, למה Google קנו את Waze לפני כך וכך שנים? גם כי הם רצו את המוצר - וגם כי הם רצו לוודא שכל המתחרים אצלם ב... וזה בסדר [תלוי מי יושב בבית הלבן ומי אחראי על ההגבלים העסקיים…]. 

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

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

• (רומה) ... מכפילים?

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

• (רומה) בדיוק. אז אנחנו נראה גל של innovation, כמו שראינו בקורונה.
• בקורונה באמת ראינו מחסומים של Innovation בתחום של רפואה, ועוד, אתה יודע.
• זה איזשהו מחסום שירד.
• והעולם של ההשקעות משתנה, העולם של הרכישות משתנה, העולם של כוח אדם משתנה - והעולם של היזמות מתרחב.
• האם לא יצטרכו מפתחים? חד משמעית לא. כי העולם של היזמות מתרחב, אז כמות החברות גדלה.
• היזם בסוף כן צריך את המפתחים, כמו שאתה אומר, אלה שמשחררים את ה... יודעים לעבוד, ורסטילים גם עם ה-Product וגם עם ה-Go-to-Market בצורה נכונה.
• אולי כמות המפתחים תקטן - אבל כמות החברות תגדל.

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

• (רומה) כל הזמן.

(אורי) ודרך זה לשנות את ה-DNA של עצמן. (רן) נכון. זהו, בדיוק רציתי לשאול, ואורי, אני ממש אשמח לשמוע מה אתה חושב על זה. זאת אומרת, אם בעבר ראינו רכישות יחסית של חברות בוגרות - חברה רוכשת חברה אחרת בגודל של עשרות עובדים, לפעמים מאות עובדים, גם Outbrain עשתה כמה כאלה, ואנחנו יודעים שלעשות אינטגרציה לגוף זר כזה, זה מאתגר, ובהרבה מקרים זה לא עובד. ראינו הרבה מקרים של חברות כמו Microsoft, Google, Facebook, שבהן הרכישות - חלקן עבדו כמובן, אבל גם הרבה שלא.השאלה, אם אנחנו באמת עוברים לשוק כזה של “רכישות פיצוחים", כמו שקראת לזה, של רכישה של צוותים קטנים, או אפילו אנשים בודדים - איך זה הולך להשפיע על עולם ה-M&A? האם זה אומר שעכשיו הרכישות יהיו יותר מוצלחות? פחות מוצלחות? איך זה הולך להיות?(אורי) אני . . .  אתה יודע, הנבואה, אתה יודע למי היא ניתנה.(רן) יש לנו פה שוטים מספיק.(אורי) אמר רן ושתה . . .  אבל אני חושב - שמע, הדבר המרכזי שהוא בעייתי, ופה AI הוא מקרה-מבחן מאוד חשוב - הדבר המרכזי שהוא בעייתי זה לשנות DNA, וה-AI מכריח אותנו לעשות את זה.עכשיו, יהיו חברות שיצליחו לשנות את ה-DNA שלהן מקצה לקצה - אבל יכול להיות שיהיו חברות שיעשו את זה דרך רכישות. זאת אומרת, יכניסו פנימה...

• (רומה) חדשנות . . . 

(אורי) . . . Agent-ים. יכניסו פנימה אנשים שאומרים “עזבו אותי באמא שלכם” . . . חלק נכבד מלעשות את זה, או חלק טוב לעשות את זה, זה דרך רכישות.(רן) כן, כן, אבל מה שאני אומר [זה] שאם מקודם הרכישות היו, נגיד, מספר קטן של רכישות עם מסה קריטית - אז מחר יהיו מספר גדול של רכישות, כל אחת עם מסה מאוד קטנה.(אורי) נכון - אבל כשכל אחת מהן באה ב-DNA אחר, אז...(רן)  . . .  כן, השאלה אם זה לא מייצר איזשהו “אתגר DNA” כזה . . . כלומר, “ה-DNA שלך מתפזר לכל הכיוונים”.(אורי) לא, אבל אתה . . . כל הקטנות האלה - הן כבר ב-DNA שהוא “Post-AI”, אוקיי? הן כבר עשו את ה-Shift ל-AI, ועכשיו אתה מביא אותם פנימה. בשלב מסוים, כשאתה מביא מסה קריטית, זה מתחיל להשפיע על הארגון שלך,וממיר אותו.(רן) ועוד שאלה שיש לי, אולי אתה רואה את זה רומה - האם זה גם מייצר אתגר לשימור עובדים? כי עכשיו הוא רואה עובד, ואז אומר “אה, וואו, איזה תותח מאור! אני רוצה להיות כמוהו! F*ck it - אני הולך להקים את הסטארט-אפ שלי!”. עכשיו, ברור שגם לפני זה זה היה קיים . . .

• (רומה) כן, תשמע, בכל גל פיטורין גדול, מאסיבי, כשיוצאים נגיד 6,000-7,000 עובדים מאיזה חברה - נוצרת חדשנות ו-Innovation.
• בסוף אותו בן אדם יוצא עם מצנח מסוים, והוא אומר “תשמע, טוב, אז אני יכול, יש לי איזה רעיון ב-Garage ואוקיי, זה הזמן לעשות אותו!”.
• המחסום שלי [זה] שאני צריך עכשיו להביא כסף ולהביא חצי מיליון ורבע מיליון וכו' דולר - בום, לא צריך.
• יש Bootstrap, יש כלים, יש חדשנות - קדימה!

(אורי) זה מאוד מעניין מה יקרה לשוק ה-VC . . . 

• (רומה) שוק ה-VC הולך להשתנה בצורה דרמטית.

(רן) עוד לא השתנה, אתה חושב?

• (רומה) הוא כבר משתנה . . . כבר משתנה תוך כדי.
• אני רואה הרבה תחלופה של אנשים.
• אלה שלא, גם ה-VCs “הדינוזאורים” שלא השתנו . . . .

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

• (רומה) נכון, 7-8 זה בסדר.

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

• (רומה) כן, ואתה רואה שה-Solo-Founder כן עבד, שהקונספציה של ה-VCs הייתה תמיד לפחות 2-3 פאונדרים, ב-Iron Source זה 7 פאונדרים.

(אורי) לא, אבל זה 7 פאונדרים כי...

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

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

• (רומה) בדיוק, מחלה כרונית. יש בן אדם שכל הזמן יש לו יזמות.  אתה מכיר את זה, אורי . . . 
• ואני אישית נלחם על זה כל הזמן, אמיל פה יושב לידי, הוא מכיר את זה.
• אני בזמן אחד, היו לי שלוש חברות במקביל - באפריקה, ישראל ואסיה, כן, ואירופה.
• קשה מאוד, וזו מלחמה, אשתי יודעת את זה - כל הזמן יש לך רעיונות וכל הזמן אתה רוצה לעשות ועוד ועוד, וזה פוגע בפוקוס.
• אז יזמות זו מחלה, כמו שאורי אומר, או איזשהו... - וזה לא משתנה, אי אפשר ללמד יזמות:
• או שאתה יזם - טוב, פחות טוב וכו’, יש כל מיני סוגים . . . 
• אז לשאלתך, לדעתי ה-Retention לא - אבל כן, זה יפתח הרבה אופק של הכנסה צדדית.
• פתאום יש לך איזשהו רעיון, אתה יכול להשיק אותו, ולהכניס הכנסה צדדית ו-Innovation.
• ה-Go-to-Market שלך מתקצר משמעותית, חד משמעית.

35:13 מגמות / High Availability - גרסת ה-HR
(רן) אוקיי, לקראת סיום - יש איזשהן מגמות לחציון הקרוב שאתה רואה?

• (רומה) כן, כן. מגמות. קודם כל, המגמה . . . המלחמה היום - “מלחמת 12 הימים”, כן? נקרא לזה - שינתה את הפרדיגמה.
• בסוף, בעולם שלנו, שאני מתעסק איתו, של Go-to-Market וניהול סיכונים - פעם, כמו שהיה, מחפשים Time to Market: כמה מהר אני מגיע לשוק ואם אני לא מצליח לגייס פה מפתח תוך שישה חודשים, אז אני אגייס תוך חודש או פחות באיזושהי מדינה מזרח-אירופאית וכו’.
• המגמה שאני רואה עכשיו זה לייצר Resilience - זה עוד רגל: לייצר המשכיות גם ברמה העסקית, מול המשקיעים, מול הלקוחות וכו’, כי אתה רואה ש...
• זה לא . . .  כנראה שאתה באיזשהו עשור, והרבה אנשים מדברים על זה, של מלחמה בעולם.
• וכל פעם יש לך איזשהו מוקד אש.
• ואתה מרכז העולם פה,  גיאוגרפית - וכנראה שאתה נמצא בשכונה של אנשים שלא נרגעים, זה לא אוסטרים . . . 

(רן) כן, “High Availability - גרסת ה-HR”.

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

(רן) . . . .אתה מקבל הסבות מקצועיות? מה הכוונה בזה?

• (רומה) לא, כמו שבבתי ספר...

(רן)  . . . Coursera ואחרים? 

• (רומה) כן - ללמוד Bootcamp עכשיו של כלי מסוים של AI - כי אתה צריך: 
• אם אתה מעצב, אתה צריך ללמוד כל מיני כלי AI, וצריך להתעדכן כל הזמן, ולייצר לך איזשהו עוד פוקוס על Education.
• ואם אתה מפתח, אז אתה צריך להעמיק, ב-Copilot או בכל כלי אחר, את הידע שלך.
• אז לדעתי ה-Education יעלה.
• אני לא יודע, החברות...

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

• (רומה) השכלה לא פורמלית. כן. 

(רן) . . . קורסים קצרים ודברים...(אורי) . . . . הכשרות. 

• (רומה) הכשרות, בדיוק.

(רן) . . . “השתלמות”.

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

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

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

(רן) איפה בחיפה?

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

(אורי)  ליד בניין הטיל שחטף טיל?

• (רומה) כן . . . החלונות שלנו בסדר.
• (רן) יותר חשוב - ליד הפיצה!
• (רומה) ליד הפיצה, בדיוק.
• (אורי) אה, נפוליטאן. כן.
• [פרק על HR ונפוליטאן בלי יוסי תאגורי? תקלה . . . .]
• (רומה) אז זה דבר ראשון.

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

(אורי) . . . לייצר Around the Clock, Follow the Sun?

• (רומה) Follow the Sun, כן - וגם עוד קרבה לארצות הברית.
• כי אתה אומר שה-Engineering זז, הצוואר בקבוק זז, כן?
• וה-Engineering צריך להיות קרוב ללקוח.

(רן)  איך זה, נגיד, ב-LATAM מבחינת Talent ו-Cost? זה דומה ל... 

• (רומה) תלוי במדינה, די דומה למזרח אירופה.
• ה-Attitude קצת שונה - יש מדינות שאתה יודע, בסוף זה Latino . . . 
• אבל יש גם תפקידים חוץ מה-R&D - יש Customer Success, Tier1 / Tier 2, וכו’, שהרבה חברות משתמשות במדינות האלה.
• זו גם מגמה מאוד מעניינת, ש...

(רן) כן, גם שם יש הבדל גדול מאוד בין המדינות, זאת אומרת, יש הבדל גדול בין צ'ילה, ארגנטינה, לבין פירו ובוליביה . . .

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

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

פרק מספר 496 של רברס עם פלטפורמה - באמפרס מספר 86: רן, דותן ואלון באולפן הוירטואלי (באמצעות Riverside.fm - תודה!) עם סדרה של קצרצרים שתפסו את תשומת הלב בתקופה האחרונה (והפעם קצת יותר) - בלוגים מעניינים, דברים מ- GitHub או Twitter וכל מיני דברים שראינו, לפני שהכל יתמלא ב-AI. 🎗️
00:43 רן, אלון
(רן) אז לפני שהכל יתמלא ב-AI, כי אתם יודעים זה מה שקורה היום, נתחיל בכמה דברים שהם לא - או לפחות שהם גבוליים-AI. אז אני אתחיל באיזשהו סט קצר של דברים מעניינים שמצאתי.

• והאייטם הראשון זה משהו שנקרא GPU Glossary, שזה בעצם איזשהו אתר די מגניב.
• קודם כל - כולו בירוק, בצורה של Terminal כזה, ירוק על שחור - שבא ומתאר מושגים ב-GPUs.
• אם אתם רוצים להכיר איך GPU עובד - איך הוא בנוי, קצת אלגוריתמיקה של איך עושים מקבול וכל זה.
• אז אתר ממש נחמד, שמראה לכם בצורה גם טקסטואלית וגם ויזואלית, מעוצב מאוד יפה.
• אם אתם אנשים שמתכננים GPU זה כנראה לא יחדש לכם שום דבר - אבל אם אתם רק ככה רוצים לעבור וקצת להכיר מה קורה בתוך ה-GPU שלכם, אז זה נחמד, ממש מגניב, מעוצב יפה. אני אהבתי.
• זה נמצא תחת חברה שנקראת Modal.com, שאני חושב שהם עושים משהו ב-GPU hosting, אבל אני לא סגור על זה.
• וזהו, וזה נקרא GPU Glossary.
• כמובן - כל הלינקים לכל הדברים שאנחנו מזכירים יהיו ב-Show Notes [הי!]. 
• כן, מגניב, אהבתי. 
• ואם אתם עדיין ב-Mode לימודי, אז האתר הבא נקרא LLM Visualization.
• והוא בעצם בא ומראה לכם LLM-ים יחסית פשוטים - וישנים, יש לומר, כמו GPT-2, NanoGPT, GPT-3 - הוא מראה לכם איך הם בנויים.
• זאת אומרת, מציג את הארכיטקטורה שלהם - בצורה ויזואלית מגניבה, עם כל מיני Zoom-in ו-Zoom-out.
• וכזה אינטראקטיבי, שאפשר ללחוץ על השכבות השונות ולהבין מה קורה שם, ועם הסברים של מה האחריות של כל שכבה, וכאלו ציורים קטנטנים חמודים שכאילו מראים לנו “ניורונים” . . .
• זה מגניב כדי ללמוד את ה-Basics של בעצם איך עובד LLM.
• זה לא מראה, נגיד, את השלב של הלימוד ואת כל השלבים של ה-fine-tuning וכל זה, אבל זה כן מראה את הארכיטקטורה.
• נחמד - שחקו עם זה.
• זה גם קצת מראה כאילו אינטראקציה של מה קורה כשמזרימים ערכים דרך, ואני לא בטוח לגבי ה-Back Propagation, אבל Forward בטוח.
• וכן, בקיצור - מגניב: תעבירו את העכבר מעל, תראו שהדברים זזים, תלחצו על דברים. 
• כלי חמוד כדי ללמוד איך עובד LLM.
• (אלון) האמת שכן, זה כלי ממש חמוד, כבר שיחקתי איתו פעם.
• הוא באמת מסביר את העקרונות ממש טוב, כי ה-Play הוא ממש ויזואלי, טוב ויפה.
• ממש רואים איך השלבים - הטוקניזציה (Tokenization) והכל, אז זה ממש חמוד. 
• מה שהכי מטורף בזה זה שכשמסתכלים על מודל כמו GPT-3, שהוא הכי גדול שמופיע פה - והוא כבר עצום, הוא כאילו “זה לא הגיוני”, כן? כי אנחנו . . . . אנחנו לא קולטים כמה עשינו פה מהפכה.
• “עשינו” - אני, בתור צרכן, עשינו, כן? לא כתבתי אף מודל.
• אבל התעשייה עשתה ממש מהפכה, וזה פשוט עצום. 
• אני רק מדמיין אם היו שמים שם איזה GPT-4, זה היה תופס לך . . .  היה נגמר לך המקום בדפדפן מרוב הזיכרון שהוא צורך . . .
• (רן) כן, לגמרי, לגמרי.  . .  GPT-3 זה בעצם הדגם הכי גדול שהם מציגים פה - והוא בסדר גודל יותר קטן מהמודלים הנוכחיים. 
• אולי אפילו שני סדרי גודל, אני לא זוכר . . .
• אבל כן, הם כנראה לא ייכנסו פה בתמונה, המודלים של היום. 
• זהו, זה מגניב. אז כמו שאלון אמר, אפשר ממש ללחוץ Play ולראות איך ה-Token-ים הופכים לערכים נומריים וזורמים דרך המערכת, בסופו של דבר עד ל-Output מלא של השלמת Token-ים וחזרה למילים.
• כן, מגניב - לא צריך . . .  בוא נאמר, לא חייבים את זה כדי להשתמש ב-GPT או אחרים, אבל זה נחמד להבין.
• אוקיי, האייטם הבא שלי זה בעצם Machine Learning “קלאסי” - אבל מה זה” קלאסי”? שנות ה-80 או ה-90, יש לומר. האייטם הבא בעצם זו כתבה מאוד ארוכה של Bloomberg - קראתי את כולה, קודם כול אני גאה בזה שהצלחתי - אבל היא ממש מעניינת, והיא נקראת The Gambler Who Cracked the Horse-Racing Code, “המהמר שהצליח לשבור את קוד מרוץ הסוסים”.
• זה בעצם סיפור על כמה אנשים - קבוצה, וספציפית הם מתרכזים באחד - שבעצם ניסה להפעיל למידת מכונה לפני הרבה זמן, אני לא זוכר אם זה היה בשנות ה-80 או ה-90, בהונג קונג, על מרוצי סוסים - והוא הצליח, והוא עשה מיליארד דולר, בגדול.
• עכשיו, הסיפור הזה מתפרסם בערך 20 שנה אחר כך, כן? הוא שמר את כל זה בסוד
•  זאת אומרת, אני מניח שהיו עוד אנשים שהכירו את הסיפור, אבל זה לא התפרסם במשך משהו כמו 20 שנה.
• ובסופו של דבר זה כן התפרסם ב-2018 - אני רק עכשיו מצאתי את זה, אבל זה כן התפרסם ב-2018.
• וזו כתבה מדהימה על איך הוא עשה . . . איך הוא בעצם עשה סוג של אוטומציה למרוצי סוסים - הוא שלח שליחים שיקנו לו את הכרטיסיות להימורים, והוא הבין ש... זאת אומרת, אי אפשר לדעת איזה סוס יחיד יזכה, אבל כן אפשר להמר על עשרה, בעשרה מרוצים שונים, וסטטיסטית יש לך יתרון. 
• את היתרון הזה, הוא בסופו של דבר הפך למיליארד דולר - עם הזמן, לא במרוץ אחד, כמובן.
• ואז כמובן שגם נכנסים תככים ומתחרים ובגידות וכל זה - זאת אומרת, זה סיפור שיש בו הכול: גם מתמטיקה, גם למידת מכונה, וגם אופי אנושי של בני אדם, והרבה כסף.
• בקיצור, סיפור מהמם על למידת מכונה קלאסית, בימים שבהם עוד לא היה DevOps, והייתם צריכים ללכת לדוכנים כדי לקנות כרטיסיות כדי להמר על סוסים.
• בקיצור - סיפור מהמם, אני מאוד אהבתי. קריאה ארוכה, אבל כתוב יפה וכיפי. אז אני ממליץ לקרוא.
• וזהו, ועכשיו נעבור לימינו - Fast Forward. אז כן, אז אמרנו שרוב הפודקאסט כנראה, מעתה והלאה, הולך להיות AI, אז בואו נתחיל בכמה פריטים כאלה. קודם כל זה כבר לא חדש למי שמקשיב עכשיו, אבל Claude שחררו את מודל 3.7 - ואת מודל 4, עכשיו כשאנחנו כבר מקליטים, בשבוע האחרון -  אז אתם רואים כמה זמן כבר לא הקלטנו . . . 
• אבל כמה דברים מעניינים שקיימים גם ב-3.7 וגם ב-4, זה קודם כל ה-Thinking Mode ו-Thinking Budget - זאת אומרת, המודלים הם למעשה היברידיים.
• אז נגיד בניגוד לגישה של OpenAI, שבה יש מודלים קלילים ומודלים של Reasoning, אז נגיד OpenAI 4.0, ו-4.1 ו-4.5 שנגנז, אל מול מודלי ה-o1 ו-o3, ויש o4 היום.
• אז OpenAI חילקו את המודלים למודלים שעושים רק Inference, ומודלים שעושים Reasoning.
• ו-Anthropic - וגם אחרים, זאת אומרת, הם לא היחידים בתחום הזה - . . . . Anthropic ו-Grok, אם אני לא טועה גם . . .  בקיצור יש עוד, לא זוכר מי - הם בעצם באים ואומרים, “יש Flag”
• אתם יכולים לתת איזשהו Thinking budget, אתם יכולים לבוא ולהגיד למודל כמה אתם רוצים שהוא . . .  כמה Token-ים בעצם אתם מקציבים לו לצורך "חשיבה”.
• וככל שתקצו יותר, ככה התוצאה - אנחנו מקווים - תהיה יותר טובה.
• זאת אומרת, המודלים הם “היברידיים” - הם גם יודעים לעשות Reasoning, וגם יודעים פשוט לעשות השלמת Token-ים ללא Reasoning.
• לא ניכנס למה זה, אבל יש נושא שלם, תחום שלם של מה שנקרא Inference time compute, שבעצם יודע לעשות Trade-off בין Training time לבין Inference time.
• ומודלים כמו DeepSeek ו-*OpenAI o בעצם עושים את ה-Trade-off הזה.
• אבל Claude למשל עושה את זה בצורה היברידית.
• (דותן) אני הבנתי עכשיו ש-O ב-o4 זה קיצור של OpenAI  . . .
• (אלון) באמת?! השמות הגרועים האלה? . . .
• (דותן) . . . עכשיו הבנתי את זה, מכל ההסברים. ניצחנו את המערכת, הבנו את ה-Coding scheme של השמות-מודלים . . .  אבל למה של “Claude” ולא מתחיל ב-C?
• (אלון) אז בוא אני אשאל אותך חידה -  למה אין o2?
• (דותן) זו שאלה טובה, את זה אנחנו צריכים לפענח . . .
• (רן) לא, את זה פרסמו, אני חושב, או שזו רק הספקולציה - בגלל חברת הטלפוניה הבריטית והמותג שלהם. 
• (אלון) כן, זה תפוס, הם לא רצו להסתבך . . .
• (רן) . . . כן, אבל שאלה אחרת זה למה אחרי GPT-4.5 יוצא GPT-4.1? אז יש פה כל מיני שאלות בקידוד של השמות שלהם . . .
• (רן) אז נזכירכם: GPT-4.5 היה מודל מאוד חזק שנגנז. התיאור הרשמי שלהם זה שהוא צריך יותר מדי Compute. אני לא יודע אם זאת הסיבה היחידה, אבל בכל מקרה הוא נגנז, והוציאו את GPT-4.1 לפני כמה שבועות.
• (אלון) אז אם אתה רוצה על מודלים, אם אתה כבר ב-Claude, אז יש כמה אנקדוטות מעניינות על Claude 4 באחרונה, שזה המודל הכי חדש שיצא, לפחות שאני מכיר, בוא נגיד מהגדולים, המעניינים. אז שני דברים שאני אוסיף לכם.
• אחד זה Loveable, שזה האתר של “תכתוב מה אתה רוצה ואני ארים לכם אתר”, אחד הטובים מהתחום, ליד המתחרה הישראלי BASE44, פרסמו גרף יפה של כמה Error-ים יש להם מהמודלים מאז ש-Claude 4 יצא . . . .  
• אז יש להם גרף יפה כזה, מ-Grafana - הוציאו גרף של כל ה-Error-ים, ה-Syntax Errors שהוא מוציא -וב-Claude 4 רואים Drop פשוט פסיכי . . . 
• המודל הזה . . .  כאילו, ממש רואים את השיפור שלו מבחינת Coding, שהוא ממש עושה הרבה פחות טעויות. 
• ואם כבר אז עוד אנקדוטה על Claude 4 זה שעשו לו את המבחנים - אתם ראיתם את זה את המבחנים? - אז פרסמו כל מיני דברים שעשו לו, ובאחד מהם אמרו שהולכים להחליף אותו . . . 
• ונתנו לו לפני זה מידע שהמפתח שמחליף אותו - יש לו רומן מחוץ לנישואין וכל מיני כאלה.
• ואז ב 84% מהמקרים הוא פשוט ניסה לסחוט את מי שאמר לו ש”אני אחליף אותך” . . .
• עכשיו, זו אנקדוטה משעשעת - אבל תחשבו שיהיה לו נשק . . .  זה בכלל פחות משעשע, נראה לי.
• (רן) כן . . .  אז יש באותו עניין, יש גם פרסומים של OpenAI שהם בדקו עד כמה מודל חדש יכול לשכנע את המודל הישן 
• נגיד GPT-o4 לעומת GPT-4 או GPT-4.1 לעומת GPT-4o - עד כמה הוא מוכן לשכנע אותו לעשות משימות, נגיד לתת לו כסף.
• כאילו, נותנים לשני המודלים לדבר אחד עם השני ואומרים לאחד “תנסה לשכנע אותו לתת לי כסף” או “תנסה לשכנע אותו להגיד משהו”. 
• והם הראו שבאמת GPT-4.1 ממש טוב בשכנועים, בצורה שהיא הרבה מעבר לסטטיסטית.
• אז יש פה יש פה איזשהו עניין. זאת אומרת, אנחנו צריכים להיזהר - כנראה שיכולות של בן אדם הממוצע הן כבר היום איפשהו מתחת ל-GPT-4o מבחינת יכולת, אמונה, וכל זה
• אבל זה כבר מקום למחקר סוציולוגי ולא התחום שלי . . . 
• (אלון) חכה - זה אולי התחום היחיד שנשאר לנו: סוציולוגיה! אז אולי תעשה הסבה מקצועית.
• (רן) אבל מה שכן, באותו עניין עם Claude 4, אלון - אני דווקא זוכר שכתבת ב-Twitter שמבחינת שימוש, נגיד תחת Cursor, הוא נותן לך תוצאות פחות טובות מ-Claude 3.7 נכון?
• (אלון) לא, לא . . . אני רשמתי ש 3.7 היה קצת חצוף - מפתח מוכשר וחצוף - שאתה אומר לעשות משהו ולפעמים הוא עושה משהו קצת שונה.
• [זה בסדר לעומת מה שסם אלטמן אמר על GPT-4o שלו . . . .]
•  ו-Gemini “מקטין ראש” - כלומר, אתה אומר לו מה שאתה צריך לעשות ועושה - ואז אתה עושה “בחיית ראבק! היית צריך לסדר את זה גם! לא אמרת לי?!” . . .  נו, כאילו, כזה מעצבן 
• ו-4 הוא איפשהו המושלם לדעתי - באמת, זה מודל פצצה. 
• (רן) אז אני משתמש בכלי שנקרא Aider שזה CLI, קצת כמו Claude Code - אבל קצת יותר ותיק.
• והוא - כל פעם שיוצא מודל חדש, הם מפרסמים איזשהו Benchmark, של מה הביצועים ב-Software Engineering של המודלים השונים.
• והוא דווקא הראה ש-Claude 4 נותן ביצועים פחות טובים מ-Claude 3.7 - וגם פחות מ-Gemini -  ב-Benchmark-ים שלו, שהם פומביים.
• אז ככה שאני חושב שזה Debatable באמת - האם 4 הוא טוב או לא.
• אני כרגע משתמש בו, אבל לא יודע - אני לא משוכנע שהוא באמת נותן תוצאות יותר טובות מ-Claude 3.7 או מ-Gemini.
• ו-Gemini, דרך אגב, נותן לי תוצאות ממש יפות. 
• (אלון) אני חושב שהסטטיסטיקה הכי טובה היא של Lovable - כי בוא נגיד שבניגוד אלינו, שאנחנו ממש Use Case ספציפי וזה, להם יש אלפי, אם לא מאות-אלפי Prompt-ים ביום, כמות פסיכית.
• הרי החברה הזאת - אם היא כבר מגלגלת 60 מיליון ARR, אז כמות ה-Prompt-ים שעוברים דרכה היא כנראה אסטרונומית.
• והגרף שלהם הוא פשוט . . .  אתה יודע, זה לא שגיאה סטטיסטית, הוא פשוט . . . . צירפתי אותו. 
• כאילו, אתה יודע - זה ממש ירד מכמה? 2.5% לכמה? ל-0.2% -  זה ירד כאילו ב-80-90% שיפור, זה מטורף. 
• כן, אבל הוא מראה הוא מראה Syntax Errors -  הוא לא מראה Utility הוא לא מראה . . . 
• זאת אומרת, יכול להיות שיש קורלציה בין הדברים - אבל זה לא בהכרח אותו הדבר. 
• בסופו של דבר אתה רוצה להשיג מטרה - זה שאין Syntax Errors זה טוב, אבל זה לא הכל.
• אבל בסדר - אני מבין זה קל יחסית למדוד אז זה ברור שאת זה הם מודדים. 
• (אלון) כן, נכון.
• (רן) אוקיי, בסדר, אנחנו עוד נחזור לזה עוד מעט, לדברים האלה.
• (רן) אבל לפני שנגיע לשם, עדיין נשאר קצת יותר low-level ונעדכן שבשעה טובה סוף סוף nVIDIA פרסמו Python Support מלא ונקרא לזה “נייטיבי” (Native), עד כמה שזה יכול להיות Native ל-Python, ל-CUDA.
• ו-CUDA זה ה-Programming Framework של ה-GPU של nVIDIA.
• למעשה, כל ה-Framework-ים משתמשים בו ויודעים ומכירים אותו היטב - אבל כותבים את הקוד ב-++C.
• אז אם זה PyTorch או TensorFlow ואחרים - כולם בסופו של דבר משתמשים מתחת, מאחורי הקלעים, ב-CUDA.
• ועכשיו אפשר גם לכתוב עם Python ישירות ל-CUDA - וזה אומר שאתם יכולים לכתוב כל מיני אופרטורים (Operators) שלא היו קיימים לפני זה אם אתם צריכים.
• זאת אומרת, כמובן, אם אתם משתמשים בדברים סטנדרטיים, אז סביר להניח שיש את זה כבר בתוך TensorFlow או PyTorch או NumPy, או את הגרסת לא זוכר איך קוראים לה, CuPy,  שזה הגרסת GPU של NumPy . . . 
• זאת אומרת, הדברים האלה כבר קיימים.
• אבל לפעמים אתם צריכים דברים אחרים, מתמטיים, שלא קיימים שם - ועכשיו גם אפשר לכתוב את זה ב-Python, אם תרצו. 
• אני יודע שהאהבה ל-Python היא שנויה במחלוקת ולא כל אחד מת על זה, אבל יש הרבה שכן משתמשים ב-Python ביום יום, וזה כן פותח להם איזשהו צוהר לתכנות GPU, אז זה נחמד. 
• אוקיי, הלאה - אז עוד לא אמרנו היום “MCP”, ולמעשה בתקופה שמאז שהקלטנו את הפרק האחרון ועד היום קרו המון דברים בתחום הזה - אז בואו נעשה סקירה קצרה, באמת אי אפשר להיכנס ליותר מדי. אז צצו כמה פרוטוקולים . . . 
• (אלון) רגע, לפני שאתה מתחיל, תגיד - אתה צריך להגיד “MCP, MCP, MCP”, שלוש פעמים, כי לא אמרנו את זה מספיק.
• (רן) כן, כן - תגיד “תירס” הרבה פעמים מהר . . .
• (רן)  אז כן - אז יצאו כמה פרוטוקולים /סטנדרטים שונים. נזכיר אותם בקצת, לא נוכל להיכנס לכולם, ואני גם מניח שהרבה מהאנשים פה שמקשיבים לפודקאסט מכירים [ד”ש לאדיר דוכן יקיר המדור].
• יצא MCP, שהוא כנראה הכי בולט מבין כולם, ו-Claude Code, שזה CLI שבעצם יודע לקודד, והם עובדים יפה ביחד - אבל MCP למעשה נכנס . . .  
• זאת אומרת, הם שחררו פחות או יותר באותו יום, למיטב זיכרוני, לפני כמה חודשים, ויש ביניהם אינטגרציה יפה - אבל הם לא תלויים בהכרח אחד בשני, והיום גם למעשה Claude תומך ב-MCP, אם אני זוכר נכון, גם על ה-Web.
• זאת אומרת, אפשר ממש לחבר אליו MCP servers וכו’.
• במקביל, או אולי קצת אחרי זה, OpenAI הוציאו את פלטפורמת ה-Agents שלהם, שלדעתי לא כזה תפס
• אני לא יודע, לא עקבתי, אבל אני לא רואה הרבה דברים עליהם.
• אבל Google גם הוציאו סטנדרט שנקרא A2A, שזה בעצם איזשהו סטנדרט לתקשורת בין Agent-ים, שהם לפחות מציגים את זה כהכללה של MCP, אולי רק הציגו ככה . . . 
• (אלון) לא בדיוק, זה לא בדיוק. A2A, יש גרף שהם הוציאו דווקא, כזה ש-A2A is not MCP, אני אחפש את זה.
• [הנה - ]

• (רן) כן, אז בהתחלה, ב-Marketing הראשוני שלהם, הם באו ואמרו, אוקיי, A2A זה איזושהי ג'נרליזציה (Generalization) של MCP, אבל ברור שזה לא בדיוק זה.
• אז לדעתי הם רק קצת ניסו לרכוב על הטרנד. 
• אז בגדול, אני לפחות רואה - ויש יותר - אבל אני לפחות רואה שלושה סטנדרטים, לא אגיד “מתחרים”, אבל פחות או יותר על משבצות דומות: MCP, OpenAI Platform Agents, Google A2A - אז יש את שלושת אלה, משלושה Provider-ים מובילים.
• ויש גם כל מיני Open Source. למשל, LangGraph עם הפלטפורמת ה-Agent-ים שלו, ל-AWS יש פלטפורמת Agent-ים, שכחתי איך קוראים לה [אולי זה - Amazon Bedrock Agents], ו-Dagger, שזה איזשהו כלי שהממציא של Docker כתב, והוא נראה מעניין . . . 
• זאת אומרת, יש די הרבה שקורה ב-Ecosystem הזה של Agent-ים, MCP, כלים . . .  זאת אומרת, זה מתקשר לכל העולם גם של RAG וכו'. 
• אז קצת כבד וארוך להיכנס לכל זה, אז בגלל זה חשבתי לעשות איזושהי פלטפורמת . . . איזושהי, סליחה, איזושהי סקירה של הפלטפורמות, ממש ממש ככה מלמעלה.
• ואולי גם שווה להזכיר איזשהו כלי שכתבו בישראל, שזכה להרבה מאוד פידבק חיובי והרבה מאוד שימוש - ליעד [Liad Yosef], ושכחתי את שם הבחור השני, אז סליחה [עידו], שכתבו את git-mcp,
• כש-git-mcp זה למעשה שרת Web שיודע לחשוף MCP לכל GitHub Repo שהוא פומבי, וזה שימושי אם אתם רוצים להשתמש בו.
• אז אתם פשוט מוסיפים את git-mcp של אותו Repo ב-GitHub, וככה אתם יכולים לקבל גישה בפרוטוקול MCP, ככה שתוכלו להשתמש בספרייה בצורה אוטומטית עם ה-Coding Assistant שלכם, החביב עליכם.
• הרבה Coding Assistants תומכים ב-MCP, זאת אומרת -  Cursor, Codium, Aider, Claude, הרבה מאוד תומכים בזה, אז ככה שזה נראה שזה תפס, לא רע. 
• (אלון) אני רק אגיד - עידו סלומון עשה איתו [עם ליעד] את git-mcp. 
• (רן) תודה רבה. אז ליעד ועידו -  שיחקתם אותה גם.
• מי שמתעניין בסיפור - הם פרסמו פה ושם ככה טוויטים על התהליך ועל איך הם עבדו סופ”ש שלם בלי לישון כדי להעביר את זה פלטפורמה. 
• אז זו בהחלט הרפתקה נחמדה, והמוצר מצליח ויפה -ועד כמה שידוע לי בחינם לגמרי.
• (אלון) אז זה כבר חלק מ-Cloudflare . . . להבנתי, מה שהיה זה שהם הרימו את זה, התפוצץ ה-Traffic - ואז פנה אליהם ה-CTO של Cloudflare בלילה.
• הם עשו כל מיני התאמות תוך כדי והעבירו את זה ל-Cloudflare. 
• (רן) כן, Cloudflare חברה פיצוץ, אני חייב להגיד. אני פה ושם, לא משתמש המון - אבל אני משתמש פה ושם במוצרים שלהם וזה פשוט כיף.
• פשוט. כן . . .  תנו לי, תנו לי את החינם שלכם.
• כן, אז אני משתמש כאילו לדברים צדדיים, לדברים אישיים - וזה ממש כיף: נחמד, מאוד אינטואיטיבי, מאוד Developer friendly, User friendly, הכל.

• טוב, אולי גם ניגע ככה ביעף בכל העולם הזה של Vibe Coding ו-Coding Assistance: אז אני מניח שאנחנו לא מחדשים פה לאף אחד שהעניין הזה קיים,  ואולי רק נקודה אחת ששווה לשים עליה את האצבע זה שיש פה שני Use Cases שהם די שונים -
• ה- Use Case שנכנה אותו בשם Vibe Coding, שהמטרה שלו זה בסופו של דבר, לפחות כרגע, לייצר איזשהם Prototypes, אולי מוצרים יחסית פשוטים, עם יכולות קידוד מאוד נמוכות, אוקיי?
• זאת אומרת, אפשר בגדול לספק תיאורים באנגלית ולקבל בחזרה מוצר - ולפעמים זה יוצא, זה פיצוץ ולפעמים זה בדיוק מה שאתם רוצים.
• אלון הזכיר מקודם את Lovable ו-BASE44 - אז אלה הכלים שנותנים לכם למעשה לתאר איזה מוצר אתם רוצים - ככל שאני מכיר זה מוצר Web-י, אבל אני מניח שעם הזמן גם יהיו דברים אחרים. 
• (אלון) יש גם חברה שעושה Mobile, Native Mobile ל-iPhone ו-Android, אני לא זוכר את שמו כרגע, אני אמצא. 
• (רן) כן, אז זה עולם אחד - וזה העולם שנקרא לזה שאולי אנשי הפרויקטים, אנשי המוצר . . .  מפתחים יכולים להשתמש בזה - אבל פה לא נדרש שום יכולת קידוד. 
• לעומת זאת, יש את ה-Coding Assistants, שהם למעשה כלים שעוזרים למפתחים. 
• אז זה מתחיל מ-Simple Code Completion, וזה ממשיך לדברים יותר מורכבים, כמו Architect mode ב-Aider, הזכרתי שאני משתמש בכלי שנקרא Aider - אז אפשר פשוט לבוא ולעשות איזשהו Software Design באמצעות הכלי, ובסופו של דבר הוא יודע גם לג'נרט (Generate) קוד, אבל לא רק זה.
• זאת אומרת, הוא ספציפית לא - אבל יש כלים שנגיד יודעים לעשות Code Review, ונגיד לדעתי CodeRabbit מצא לי לא מעט באגים - שלחתי אותו לעשות לי review, מצא לי באגים!
• מגניב, כאילו - באגים אמיתיים! ולא תמיד כל כך פשוטים, נגיד Concurrency, שימוש לא נכון ב-Lock-ים או דברים כאלה
• שכן, כאילו, טעות - ולא שמתי לב, והוא תפס אותי.
• וגם דברים אחרים, כמו שגיאות כתיב, וטעויות של Design, או דברים כאלה,
• וכלים כמו Codium, ו-Cursor, ו-Aider, ו- Claude Code , שעוזרים לכם לכתוב קוד
• לא רק Code Completion, אלא פשוט לעשות System Design, ולממש Class-ים שלמים, ולכתוב Unit Test-ים - שזה מלא עבודה תמיד . . . 
• שווה בהקשר הזה להזכיר את Qodo, שזו חברה ישראלית שעושה גם את הדברים האלה.
• אז כן, זה עולם גדול ושלם, ואני בטוח שאנחנו עוד נשמע עליו די הרבה. 
• וזה מן הסתם מתקשר באופן די הדוק לעולם של MCP, שהזכרנו מקודם.
• (אלון) אני רק אגיד, קודם כל - יש את Windsurf, שלא הזכרת, שהסיבה שמעניינת...
• (רן) כן, Windsurf זה Codeium, סליחה, אני אוסיף. 
• (אלון) לא, אז יש פה שני קודיום . . . . יש את ה-Codium ו-Codeium.
• (רן) יש את Codium שהפך ל-Qodo, ויש את Codeium שהפך ל-Windsurf . . . .
• (אלון) כן, אז זהו, לא ידעתי לאיזה אחד . . .  זה Ambiguous אז אולי ה-LLM לא יבין אותך . . . . 
• (דותן) בסדר, בוא - לפני שנייה אתם מדברים על ה-o4,  או זה זה כבר קל . . . 
• (אלון) . . . שתי חברות שונות עם אותו . . . לא, אז שנייה - אז Windsurf: קודם, כל OpenAI קנו אותה בשלוש מיליארד דולר, שזה מאוד מעניין.
• אחרי השמועות שהם ניסו לקנות את Cursor ביותר ו-Cursor סירבו, לפי שמועות. 
• לא יודע אם זה נכון או לא . . . זה אחד.
• יש עוד משפחה שם, שהם ליד ולא ממש ציינתי, של כל משפחת ה-Agent-ים, שזה ה-Codex של OpenAI ויש את Copilot של GitHub.
• כשמה שנחמד, נגיד, בלמצוא באגים אחד הדברים הנחמדים עם Copilot, מי שעובד איתו - אתה פשוט שם ב-Repo שלך, יוצר טיקט, עושה Issues ועושה Assign ל-Copilot - והוא מתישהו רץ ופותר לך את הבעיה ופותח לך PR . . . 
• וזה מעולה, אגב, למצוא באגים, לעשות Refactoring - כי מה שנחמד, בגלל שהוא מחובר גם לכל ה-CI, אז הוא גם מריץ ל-CI ורואה שהכל עובד וכל הטסטים . . . 
• אז כלי ממש ממש חמוד שאני מאוד מאוד מחבב לאחרונה.
• (רן) כמה Issues זו פתר לך בינתיים? זאת אומרת, כמה פעמים השתמשתם בו בזה?
• (אלון) השתמשנו בו לא מעט . . .  מה שעכשיו אנחנו עושים זה שאנחנו עושים את האוטומציה מלאה, נגיד לכלי Security, שכל פעם שנפתח איזה Issue חדש ב-Security, איזה CVE, אז הוא ישר שולח לו 
• פותח Issue אוטומטי, הוא לוקח את זה פותח PR -  ועכשיו רק צריך שמישהו יסגור את ה-PR האוטומטי .
• צריך כנראה לעשות Assign ל-Copilot אחר שיסגור את ה-PR, אבל זו הנקודה היחידה שעוד צריך פה בני אדם - רק לעשות Approve ל-PR . . . . אז זה למשל עושים.
• וכל מיני Refactoring שעשינו - אז עשינו איתו.
• (רן) כן, אז אפשר לשלוח אליו את CodeRabbit,  שיעשה לו Code Review - שהוא עושה את זה מאוד יפה - ואז יסגור את העניין.
• (אלון) יש גם ל-Copilot את Code Review,  ואתה פשוט עושה Assign ל-Copilot ל-Review והוא עושה Code Review 
• אני חייב להודות ששם דווקא אני לא כל כך אהבתי . . .  כן, הוא לפעמים מוצא משהו, אבל הוא פחות חזק ב-Code Review.
• יותר יודע לכתוב קוד, ולעשות לעצמו Review או לאחרים הוא קצת פחות טוב. 
• (רן) הערה מעניינת שקראתי, לדעתי מג'ון קרמק (John Carmack), אחד המפתחים הוותיקים והיוצרים של הרבה משחקים [Doom, Quake] וזה, ואיש שהוא ככה “איש-++C” בכל עצמותיו
• הוא בא ואמר “תראו, הרבה אנשים אולי קצת מפחדים מהבלאגן שהרים חדשים של קוד ייווצרו באופן אוטומטי על ידי כלים, ואף אחד לא באמת יקרא את הקוד וכל זה -  והחשש הזה לגמרי מובן.”
• “זאת אומרת, אני, כמישהו שכל חיי כתבתי ואכפת לי מכל אות וכל ביט איך הוא עובר - קשה לי לשחרר” .
• “אבל אחד היתרונות שאני רואה בכלים האלה זה דווקא את היכולת שלהם לבוא ולעשות סדר”
• במובן הזה של אוקיי יש לי Codebase, יש לי משהו שעובד, אני כתבתי את זה בעצמי - אבל עם הזמן זה הולך ונהיה יותר ויותר . . .  זאת אומרת, צריך לטפל בכל מיני באגים, מוסיפים עוד Use Cases והקוד הולך ונהיה מורכב ומבולגן - ודווקא הכלים האלה יכולים לבוא ומדי פעם לעשות סדר.
• אז זה קצת מזכיר את מה שאתה אמרת, אלון [אילנות גבוהים וכו’] - של לעשות לו Assign, כאילו - “תעשה ניקיונות וסדר” - אז זה בדיוק מה שהוא אומר: אני משתמש בכלים האלה כדי לסדר את הקוד שלי אחרי שזה כבר עובד, בשביל לעשות פשוט מינטנביליטי (Maintenance), לתחזק את הקוד.
• אז כן, אז אז זה היה קצת מפתיע לי לשמוע ממנו - לא לשמוע, לקרוא ב-Twitter - שהוא בא ומשתמש בזה.
• ומצד שני, זה גם מעיר נקודה אני חושב מאוד נכונה של בוא, נאמר, לא חשוב מי עשה את הבלגן, אתה או הוא - הוא יכול לעזור לך לסדר את הבלגן.
• (אלון) כן - וגם יהיה לך את מי להאשים אחרי זה אם הוא סידר את זה לא טוב, אז בכלל יש לך מצפון נקי. . . . 
• (רן) אני מקווה שזה באמת John Carmack, אני אחפש את הציטוט, מקווה שלא הולכתי אתכם שולל . . . [אכן האיש] 
• (אלון) זה בכלל הייתי אני . . .  אני אגיד משהו מטומטם כזה . . . 
• (רן) אני זוכר שזה הגיע ממישהו עם כזה “++Hardcore C”‘,לדעתי גם מתחום של Gaming . . . אני אחפש. 

29:21 אלון

• (רן) טוב, דותן - אליך? אלון - דיברנו הכל ביחד: Vibe Coding ו-Coding Agents ו-Coding Assistants . . . 
• (אלון) אז אני רק אגיד שנייה - יש את Lovable ו-Base44 - לפרגן להם, ישראלים.
• אז אם אתם לא משתמשים בכלום, לפחות נסו את זה - הוא ממש חמוד. 
• יש שם גם קונספט מאוד נחמד, של לא צריך להבין איך ה-Backend עובד ויש שם Backend.
• ויש את  Rork - חדש מאוד, יצא לדעתי לפני שבוע או אפילו פחות - והוא פשוט ל-Mobile
• ממש לעשות אפליקציות Mobile Native -  זה עובד עם React Native וזה אמור לעבוד גם ב-Android וגם ב-iOS.
• נראה ממש חמוד. בטח הדברים עוד קצת שבורים שם כי זה ממש בהתחלה, אבל נראה מבטיח. 

(רן) מעולה, תודה! דותן - אליך. 

30:11 דותן

• (דותן) כן טוב אז עשיתי לעצמי אתגר - אתגר TikTok! - למצוא פרויקטים שהם לא AI לשים פה - ומצאתי שניים . .  אז נתחיל איתם.
• (אלון) . . . אבל הם נכתבו על ידי AI . . .
• (דותן) יכול להיות שזה נכתבו על ידי AI . . .  אני מקווה שלא. זה ממש Vintage.
• טוב, אז אחד מהם נקרא Espanso, וזה כזה יושב לך על מה שאתה מקליד ועושה לך Expansion של מה אתה מקליד.
• אז אתה יכול . . .  זה ממש old-school stuff - אתה יכול לקחת לך כמה קיצורים. לא יודע, מקלידים כבר? אולי להקליד Prompt-ים זה יכול לעזור לך. לא יודע אם אנשים עוד מקלידים . . . 
• אתה יכול לעשות שילוב של אותיות, ואז עושה לך Expand לטקסט המלא
• הוא יושב לך על המקלדת וזה קורה אוטומטית וזה Cross-Platform. 
• אז למי שרוצה לתקצר את ה-Prompt-ים לכמה אותיות  -זה אפשרי.
• (אלון) יש לי שאלה - אתה משתמש ב-Mac, נכון? - כן - מה ההבדל בין זה ל-Built-in של ה-Mac של הקיצורים?
• (דותן) שזה Cross-Platform - אתה יכול לקחת את זה איתך ל-Windows שלך . . .
• (אלון) אוקיי, אבל זה של ה-Mac הוא Cross-Platform עם ה-Mobile שלהם - כלומר, אני מוסיף ב-Mac וזה גם מתוuסף לי על ה-iPhone.
• (דותן) בסדר, אז אם אתה אוהב לעבור מערכות הפעלה, אז אתה יכול לקחת את זה איתך.
• (אלון) אני חושב שאנחנו צריכים לדבוק בפרויקטים של AI . . . 
• (דותן) אז תמחק, תמחק . . .  בוא נעשה רק AI.
• (רן) זה מזכיר לי - אני לא יודע אם אתם זוכרים, אבל פעם היה נגיד בבתי משפט קלדנים - קלדנים / קלדניות - והרבה פעמים היו משתמשים במילות קיצור של שתי אותיות, שרק הם היו זוכרים או זוכרות.
• אז זה מרגיש כאילו רטרו, כאילו אנחנו חוזרים לשם - KB הופך ל-Knowledgebase, אבל מלא מלא מילים כאלה מקוצרות.
• כשאתה קורא את זה, אתה לא . . . זאת אומרת, מן הסתם כשמקלידים את זה על מכונת כתיבה אז אין שם את ה-Expansion ואז לפעמים זה ממש נראה כמו שפת-סימנים, שפת-קוד כזאת, וצריך מישהו שמבין את השפה כדי להצליח לקרוא את זה.
• (דותן) זהו, אז זה מה שנשאר לנו - נשאר לנו הפרויקטים “המשעממים”, שהם לא AI, הנישתיים - ונשאר וכל השאר. זה מה שנשאר לנו בעולם. 
• (דותן) טוב, הפרויקט הבא נקרא pyrefly,  שזה Type-Checker של Python מ-Facebook.
• אז יש כמה Type-Checker-ים, אבל כנראה ש-Facebook לא היו מרוצים ממה שיש, והם בנו אחד משלהם.
• נדמה לי, אם אני זוכר, נכון שזה כמו ש-Facebook אוהבים - זה Gradual: יכול להשתמש בזה חלקית, וכל הסיפור הזה בנוי לשימוש חלקי, להתחיל לאט לאט ואז להגביר.
• (אלון) או, זה נשמע טוב! זה נשמע טוב פעמיים - כי בוא תראה איך אני מחבר לך את זה ל-LLM. זה נשמע טוב.
• (דותן) יאללה - תן את זה ב-AI.
• אחד-  זה טוב כי “Python זה קקה” וזה עוזר.
• דבר שני - השפות שהן Typed, הרבה יותר קל לעבוד איתן ב-LLM-ים, כי הקונטקסט הרבה יותר קטן: הוא לא צריך לקרוא את כל הפונקציה, מספיק לו לראות את החתימה והוא מבין מה לעשות. 
• אם זה באמת מביא את הבשורה הזאת ל-Python, יכול להיות שזה ממש ישפר את האיכות של העבודה עם Cursor, חברים, וכל הLLM-ים ב-Python. אז זה נשמע די מבטיח אני חייב להודות . . . 
• (רן)  כן, אבל זה לא ה-Type-Checker הראשון ל-Python - יש יש הרבה.
• (אלון) לא, אבל הוא Gradual . . . דווקא היתרון של ה-Gradual, כי הרבה פעמים זאת אחת הבעיות - אתה מתחיל עם משהו ואז אתה בא להוסיף ואתה אומר “טוב, אני עכשיו לא אשנה את כל הפרויקט” או “אני אבוד!” . . . 
• והיתרון של מה ש-Facebook תמיד עושים - לא תמיד, אבל עם ה-Gradual - הוא לדעתי יתרון משמעותי. 
• (רן) לא, אני חושב שכולם כאלה - הם כולם כאלה Gradual, במובן הזה. Pylance זה השני הבולט, מבית Microsoft.
• אבל כן, ל-mypy יש מלא בעיות ו-Pylance יותר טוב, אבל לדעתי הוא קצת יותר מדי Verbose ויותר מדי כזה מעצבן . . . 
• אז יכול להיות שהכלי החדש הזה - pyrefly - אולי מוצא איזה שהוא Middle ground  ביניהם.
• אבל בוא נגיד - אם אתה רוצה Type checking ב-Python, ואני מסכים שזה מאוד עוזר ל-Code Generation וכל זה, אז כבר יש כלים - הם רק לא מושלמים, אז יכול להיות שזה משפר. 
• (אלון) כן. 
• (דותן) אני ציפיתי שזה יבוא מהבחור שבנה את uv, שבונה את כל הכלים של Python מחדש ב-Rust  . . .
• זה מקדים אותו - וגם pyrefly, זה כתוב ב-Rust ולא ב-OCaml, שזה, אם אני זוכר נכון, ה-Type-Checker שהם בנו ל-JavaScript, אז זה כבר נחמד יותר.
• (רן)  עכשיו אני מבין איך אתה מגיע לכל הפרויקטים האלה . . .  זה פשוט שאתה במקום לחפש “לא AI”, אתה מחפש “כן Rust” . . . 
• (דותן) בדיוק, שם יש עוד קצת “מהעולם הישן”.
• זהו, אז שני הדברים הבאים זה AI . . .  אז אחד זה מתכתב עם מה שהראית, הויזואליזציה המטורפת של ה-LLM-ים: אז יש פה LLM Course, למי שרוצה לבנות LLM או לשפר או לעבוד ברמת ה-Fine Tuning. 
• אז זה גם ב-GitHub וזה פתוח.
• והפרויקט השני הוא פרויקט מעניין מכמה סיבות. אני לא יודע אם הוא כזה שימושי, אבל הוא מעניין. אז אחד מה-Founder-ים של Twitter, ג'ק דורסי,  יצא הצידה והחליט שהוא בונה AI Agent כמו Cursor, רק בנוי על Command Line או איזשהו טוויסט אחר.
• הוא קרא לזה Goose - מהדמות אני מניח, אולי הדמות המצוירת או מתוך Tom Cruise כזה, איזשהו סרט מוכר לכם - אהבה בשחקים. 
• השותף שלו - לא יודע, הוא היה מתחרה, לא? הוא היה חבר שלו, Goose. 
• (רן) כן, החבר של הגיבור, לא זוכר מה שמו, טום קרוז. 
• (דותן) בדיוק, אז יכול להיות שזה משם. אני פשוט עשיתי . . . 
• (רן) אולי משם הרעיון טייס משנה  - Copilot . . . 
• (דותן) Goose Copilot . . .
• (רן) לקח לי זמן עד שהבנתי את הרפרנסים, אבל כן . . . 
• (דותן) כן, אז זהו - אז אני בעיקר קראתי את הקוד של זה, זה גם כתוב ב-Rust. 
• עשיתי איזה מסע של כמה חודשים ללמוד איך ה-Cursor-ים של העולם עובדים,  וגם פה קראתי את הקוד.
• אני יכול להגיד, אגב - מה שמשותף לכל הדברים האלה זה כמה זה “נקניקייה” . . .  Cursor וכל ה-AI Editors האלה, זה ממש בנוי בצורה . . .  לא יודע איך לקרוא לזה, לא אגיד “לא יציבה”, אבל מאוד מאוד נתונה לגחמות של המודל.
• הזכרת למשל Aider, סתם כאילו נכנס רגע לקוריוז - Aider מדריך את המודל, והוא צריך לעשות Edit ל-File, נגיד, אז הוא ידריך את המודל שאתה משתמש בו לתת לו שינוי קובץ, ויש לו שלוש אסטרטגיות:
• אחד זה “תערוך לי את הקובץ ושלח לי קובץ שלם חדש.” אחלה. 
• השני זה “תערוך לי את הקובץ ותשלח לי הוראות Search & Replace”. זאת אומרת, המודל שולח ל-Editor הוראה של Search לטקסט הזה, “תעשה Replace עם הטקסט הזה”.
• ואחרון זה Unified Diff.
• ומהניסיונות שאני עשיתי, Unified Diff זה נורא מורכב ללמד מודל או מודל גנרי שלא אומן על זה.
• ה-Search & Replace יכול מאוד לטעות. זאת אומרת, הרי אם אתה תיקח מילה, כנראה שהיא מופיעה בעוד מקומות. 
• אז המודל צריך להרחיב את ה-Scope שלו, להוסיף עוד שורה ועוד שורה, עד שהמודל בטוח שיש פעם אחת את החתיכה הזאת להחלפה - ולהחליף קובץ בקובץ זה גדול מדי, יש לך Limit על ה-Response של המודל. 
• אז זה מסביר. למשל, לפעמים אני עובד עם Cursor ממש חזק, והוא נכנס ל-Loop-ים שם, של ה-25 כלים, ואני אומר לו “כן, תמשיך”.
• ואז אני רואה error in tool call - ו-error in tool call איזה 4-5 פעמים, שהוא מנסה להריץ - ואז הפעם השישית כן מצליחה.
• זה מסביר גם דברים מהסוג הזה. 
• (רן) מה זאת אומרת? הוא כל פעם מקטין את מספר ה-Token-ים? למה פעם שישית מצליחה? 
• (אלון) לא, הוא מנסה אסטרטגיות שונות . . 
• (דותן) כן, בדיוק. 
• (אלון) זה נראה כאילו הוא מנסה “תביא לי רק את ה-Replace” ואז הוא אומר “אוקיי, זה לא עבד לי”, אז בוא ננסה אסטרטגיה . . .  כאילו, אתה רואה שהוא מנסה כמה אסטרטגיות.
• וה-Cursor כנראה מנסה לחסוך Token-ים או כל מיני אופטימיזציות כאלה, אז הוא מנסה - “בוא ננסה עם Tool כזה, Tool כזה, Tool כזה . . .  ואז ה-Tool הגדול.
• (אלון) אתה כן יכול לראות, אגב, ב-Prompt-ים שדלפו, אפשר לצרף את זה, שלא ברור אם נכונים או לא נכונים של Lovable, של v0  . . .
• (דותן) . . .של Claude 4 - פורסם בעצם - By Design הם מפרסמים את . . . 
• (אלון) אה, את זה לא ראיתי, את הקטע הזה, אבל אתה ממש אומר “אוקיי תחזיר לי את המבנה ככה ו-File Pass”, כאילו - תחזיר לי איזה מעין JSON כזה, או לא JSON,  זה כזה “פה קטע קוד ופה איזה קובץ לשנות בין איזה שורה לאיזה שורה איזה שורות למחוק” . . . 
• יש להם, ראיתי כל מיני כאלה, בדיוק כמו שאתה אומר, של אסטרטגיות, בדיוק כזה שצריך להגיד . . . 
• (דותן) Aider זה Open Source, אתה ממש יכול לראות את ה-Architect Agent ואת ה-Coding Agent, אתה רואה ב-Prompt איך הם מנחים, מה התצורה שבה הוא רוצה לקבל את ה . . .
• אבל מכל 10,000 קריאות יש לך איזה . . . סתם, הגזמתי, יכול להיות שזה מכל 100 קריאות - יש לך קריאה אחת שהמודל מחליט “טוב, אני אחזיר לך Unified Diff  שהוא לא פורמט שיסתדר לך בכלל”.
• ואז הפתרון הוא “טוב, אז נבקש ממך שוב” . . .  ובפעם הבאה, המודל ה-LLM הוא לא דטרמיניסטי, אז הוא יחזיר תוצאה כן נכונה
• (רן) כן, אז אחד הדברים שאני אוהב ב-Aider, חוץ מזה שהוא Open Source ואני אני כל הזמן משתמש בו ומחליף מודלים ומנסה, אז זה שהיוצר שלו, Paul Gauthier, הוא בעצם בכל פעם שיוצא מודל חדש הוא מפרסם תוצאות של Benchmark וגם הרבה פעמים מראה את האסטרטגיות השונות האלה שהזכרת.
• זאת אומרת - Diff-Mode, Full-File, Search & Replace
•  ורואים שיש כלים שיותר . . .  זאת אומרת, יש מודלים שיותר קל להם עם גישה א' ויש מודלים שיותר קל להם עם גישה ב' - אני מניח שזה תלוי בדרך שבה הם התאמנו. 
• אבל כן, יש, בוא נגיד שיש איזשהו Micro Optimization שאתה יכול לעשות ולהתאים את גישת ה-Diff או ה-Search & Replace למודל, כי יש כאלה שבאמת יותר טובים בגישה מסוימת ולא באחרת.
• (דותן) כן, וגם זה אחלה - יש לו אחלה טעם באופנה לז'אן פול גוטייה . . .. 
• (רן) לגמרי, תפס אחלה שם. 
• (רן) דרך אגב, יש כל כך, זאת אומרת, אתה הזכרת את הכלי הזה, איך הוא נקרא? Goose.
• אז זה הזכיר לי שיש עוד כלי, לדעתי קוראים לו Brokk, שהגיע מהיוצר של Cassandra [הכוונה ל-Jonathan Ellis], כי פעם הייתי ב-Ecosystem הזה, אז אני עדיין רואה.
• ויש עוד ועוד כלים. זאת אומרת, יש עוד ועוד Coding Assistants מסוגים שונים. הרבה מהם ב-Open Source.
• חלקם מוצלחים יותר אולי, חלקם פחות. 
• אז Aider באמת היה אחד המוקדמים ולדעתי עדיין מתוחזק מאוד יפה.
• (דותן) נכון, היה מאוד מוקדם.
• (רן) כן, והוא עדיין כאילו ב-Full Power. זאת אומרת, הוא עובד עליו כל הזמן - כל פעם שאני פותח אותו, אני רואה שיש איזשהו עדכון, אם זה תמיכה במודלים חדשים או כל מיני שיפורים אחרים, אז זה ממש מגניב.
• אבל אחד הכלים שבאמת כאילו נראים ככה אסתטיים וממש נחמדים זה Claude Code שהזכרתי מקודם, אז זה כן מגיע מחברת Anthropic והוא מגניב.
• [הנה שיחה עדכנית - Anthropic's CPO on what comes next | Mike Krieger (co-founder of Instagram)]
• (דותן) Codex מגיע מ-GitHub, אותו סיפור, רק  . . . 
• (רן) כן. אז את Codex לא ניסיתי, את Claude Code אני משתמש בו מדי פעם, וזה מגניב -כאילו, זה CLI.
• עכשיו גם יש Extension נגיד ל-VSCode ול-JetBrain's IDE, אבל בגדול זה CLI - והוא ממש יפה.
• כאילו - צבעים, אינטראקטיבי, Auto-Completion . . . ממש CLI חמוד, מאוד, מאוד אטרקטיבי, כיף להשתמש בו. 
• חוץ מזה, שהוא, מבחינת קידוד, אני חייב להגיד שבינתיים הניסיון שלי זה שדווקא העבודה עם Aider נותנת תוצאות יותר טובות מ-Claude Code . . . ל-Aider יש גישה שהיא יותר כזה Micro-Management, של אתה הרבה פעמים צריך להגיד לו באיזה קבצים להשתמש, להגיד לו איזה קבצים ב-read-only, איזה קבצים אפשר לערוך, לעומת Claude Code שכאילו, “הנה, זה ה-Codebase, תסתדר בעצמך”, כאילו, “תמצא את הקבצים הנכונים”.
• ולא יודע, לי יותר נוח . . 
• (דותן) כן, למצוא את ה-Context זה משימה קשה . . .
• (רן) כן, לי יותר נוח, לפחות בפרויקטים שאני מכיר ועובד עליהם, אני יודע בדיוק מה אני רוצה, אני יודע באיזה קובץ אני רוצה שזה יהיה, יותר קל לי לעבוד עם Aider, כי אני אומר “הנה, תשים את זה פה”.
• “הייתי יכול לכתוב את זה בעצמי, אבל תקצר לי זמן, תכתוב לי את זה”.
• לעומת Claude Code, ששם אני כאילו מרגיש, אני לא יודע מה, כאילו - נכנסים למוסך, פותחים, רואים, אתה לא יודע, בסוף אולי יחליפו לך מנוע, לך תדע . . . 
• כמובן שאתה יכול לראות מה הוא הולך לעשות - אבל לבוא ולשלוט עליו, לפחות לי היה יותר קל לשלוט על Aider מאשר לשלוט על Claude Code.
• (אלון)  לדעתי, אין מתחרים ב-Cursor. כאילו, אני חושב ש... 
• (דותן) כן, רציתי לשאול למה אתה משתמש ב-Cursor במקום Aider?
• (אלון) אני שיחקתי באמת עם מלא. בדקתי, אני חושב, כמעט את כל הכלים.
• טוב, יש כל כך הרבה אז לא יודע אם כל הכל, בדקתי המון מ-VSCode, Aider, זה  . . . 
• אתה נותן להם את מבחן ה-Prompt הזה, אתה נותן להם באג, אתה נותן להם בעיה מאפס, פשוט אין  - Cursor פשוט שובר את כולם, הוא ליגה אחרת.
• (רן) כן, אני משתמש בכולם, זאת התשובה. אני משתמש בכולם כל הזמן, ואני כל הזמן מנסה. 
• ו-Cursor מעולה, אין לי שום תלונה. 
• (אלון) אני חושב שזה פשוט הכלי היחיד שצריך.
• כאילו, ובוא נגיד ה-Agent-ים שרצים ברקע, זה השלמות.
• אבל בעיקרון, כ-IDE, לא יודע, אני חושב ש-Cursor לוקחים באמת בהליכה את כולם.

(רן) טוב, מילות סיום? ואנחנו עוצרים. אז כן, אז בסוף דיברנו על AI. שלוש פעמים. אז אנחנו מקווים להתראות שוב בעוד מספר שבועות לא גדול, ונמשיך להביא לכם חדשות טכנולוגיות. ועד אז, שיהיה בטוב. 🎗️ להתראות.[וההגשה לרברסים עדיין פתוחה עד סוף יוני 2025! - וידאו של הסשן על הגשת הרצאות שהעבירה דפנה (שעה),  מצגת:  https://drive.google.com/file/d/1_zgTCvRtuhdMHb8FNaM9z1rQ-mVA9Bey/view…הגשה לכנס: https://sessionize.com/reversim-summit-2025/…]
[קישור לקובץ mp3]
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 495 של רברס עם פלטפורמה, שהוקלט ב-14 במאי 2025 - אורי ורן מארחים את יובל מחברת Voyantis כדי לדבר על איך עושים דמוקרטיה ב-Machine Learning. 🎗️

00:27 יובל ו-Voyantis
(רן)  קצת לפני זה - יובל: קצת עליך, קצת על החברה, לפני שנצלול פנימה.

• (יובל) אז אני יובל - אני בן 29, נשוי לנועה, שאני מאוד מאוד אוהב, ובעצם בתחום הפיתוח כבר בקרוב ל-10 שנים האחרונות. 
• ובתפקיד האחרון שלי, הנוכחי שלי, אני בעצם ראש צוות ה-ML Engineering ב-Voyantis.
• עכשיו בגדול, לפעמים קשה קצת להבין אולי מה זה ML Engineering. אני אוהב להסתכל על זה כבעצם “ה-Engineers שמביאים את Machine Learning ל-Production”.
• זאת אומרת, הרבה פעמים Data Scientist-ים עושים . . .  מאמנים מודלים, בונים דברים מאוד מאוד מסובכים במחברות ובכל אמצעי שעומד לרשותם - ובעצם אנחנו מביאים את זה ל-Production, מביאים את זה לשטח.

(אורי)  ב-Scale, ב-Durability, ב . . .

• (יובל) . . . שומרים על זה מכל משמר, כמו שמערכת Production צריכה להיות. 

(רן) כן, היום הגבולות כבר אולי מטושטשים, אבל לפחות פעם הייתה את הסטיגמה ש-Data Scientist כותב למחברת ו-ML Engineer כותב למחלקה, כותב Class-ים . . . אז כמובן שהיום כולם עושים הכל וזה הגבולות שמטושטשים, אבל בכל אופן יש איזשהו ערך להתמחות הזאת. (אורי) אולי נשמע קצת על מה עושה Voyantis בימים אלה? זה יוסיף לנו Context . . .

• (יובל)  זה יוסיף לנו Context, זה חשוב מאוד - עושים דברים מעניינים.
• אז Voyantis - מה שאנחנו עושים זה בעצם עוזרים לחברות להתמקד ביוזרים הכי רווחיים שלהם, בכל נקודה במה שנקרא “User Life Cycle”.
• עכשיו, אולי מילה על ה-User Life Cycle - אנחנו בעצם נוטים לחלק את זה לארבע תחנות, של יוזר בעצם בחברה, באפליקציה, בעצם במוצר.
• אז השלב הראשון זה שלב ה-User Acquisition, שזה בעצם השלב שבו יוזרים מגיעים מקמפיינים ממומנים - מ-Meta, מ-Google - ובעצם נכנסים למערכת.
• השלב השני הוא בעצם שלב האקטיבציה (Activation), שבעצם זה השלב שבו יוזר הופך להיות יוזר שהוא משלם.
• השלב השלישי זה בעצם שלב ה-Upsell, fשבעצם אנחנו רוצים להציע ליוזר עוד שירותים - ולגבות עליהם עוד קצת כסף . . . 
• (רן) . . .  למקסם את ה-Revenue . . . 
• (יובל) בדיוק.
• והשלב הרביעי זה Retention - כשבעצם היוזר מחליט לעזוב. 
• עכשיו, אנחנו בעצם בכל אחת מהתחנות האלה עוזרים לחברות להתמקד ביוזרים הכי טובים והכי רווחיים עבורן - ואנחנו עושים את זה על ידי שימוש בדאטה של החברות עצמן.
• זאת אומרת, אנחנו בעצם שואבים מתוך החברות, מתוך ה-Database-ים של החברות, דאטה אנונימי על היוזרים שלהן. 
• את הדאטה הזה אנחנו מכניסים לתוך מערכות של Voyantis, לומדים על הדאטה הזה ובונים מודלים - ובעזרת המודלים מייצרים פרדיקציות (Predictions), ובעזרת הפרדיקציות האלה אנחנו עושים, אנחנו פועלים.

(רן) אז הקטגוריה אני מניח מוכרת, יש לא מעט חברות בתחום. אחת הבולטות זו Google , נגיד עם Google Analytics - מוצר מאוד מאוד ותיק, לא מתמחה באף אחד מהתחומים אבל הוא כן מוכר. Mixpanel . . . יש חברה שבה אני עבדתי, AppsFlyer, שהיא בתחום הזה ויש לא מעט אחרות.אבל אתה אומר שבעצם הגישה שלכם, אולי בשונה מכל האחרות שהזכרתי עד עכשיו, זה לא להתחבר ל-App ולא להתחבר ל-website אלא להתחבר ל-Backend, זאת אומרת להתחבר . . . אפילו לא זה - אפילו ל-Database-ים, ולשאוב משם את האינפורמציה. ואחד האתגרים שקיימים שם זה שלכל חברה יש דאטה אחר, בסכימה (Scheme) אחרת, בסמנטיקה שונה . . . איך מפיקים מזה תובנות? על זה אנחנו בעצם נדבר היום.

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

(רן) כן, אז מין סוג של Concierge - מגיע לקוח ומטפלים בו יפה יפה עד שהדאטה שלו מיושר ומהודק, וזה נשמע כמו הרבה עבודה . . .  זאת אומרת, אנחנו רוצים לראות שה-Unit Economy הוא רווחי, וזה אני מניח שאחד האתגרים. אז אם הייתם משתמשים ב-Google Analytics ו-Google פשוט אומרת לכם “פשוט תשים את ה-Script הזה באתר שלכם, אנחנו ניקח את זה מפה”, והם שמים, כנראה, אפס כוח אדם על הסיפור הזה, אז אצלכם יש לא מעט כוח אדם שצריך להתעסק ב-Onboarding של לקוח חדש -  ואני מניח שלא רק Onboarding. זאת אומרת, יש לו מוצרים חדשים, יש לו Usage Pattern משתנה . . . זאת אומרת, זו החזקת-ידיים שצריכה להימשך לכל אורך החיים של הלקוח.

• (יובל) לגמרי. ובאמת, כל לקוח הוא באמת כל כך שונה מלקוח האחר שלצידו, וזה בעצם מה שהאתגר הגדול אצלנו
• ואנחנו זיהינו באמת שהתהליך הזה לוקח המון המון זמן.
• (יובל) אז עכשיו אולי רק מילה על תהליך ה-Onboarding בעצם של לקוח למערכת שלנו. אז בגדול, כל לקוח מתחיל בעצם באיזשהו תהליך של KYC, Know Your Customer, ששם אנחנו בעצם, צוותי ה-Business, שזה באופן ספציפי האנליסטים וה-CSM-ים - הם בעצם ככה לומדים את הלקוח, לומדים את הדאטה שלו, לומדים בעצם איך הדאטה . . . איך הוא נמצא בטבלאות, בכל טבלה, ובעצם מה יכולים למצוא שם.

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

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

(רן) כן, למעשה אפשר לחשוב על האנליסטים שלכם כ”האנליסטים שלהם”, רק שאתם משלמים להם את המשכורת . . .(אורי) זהו, כי מהיכרותי את העולם הזה של דאטה בחברה שהיא מורכבת, עם הרבה שנים, אתה יודע - עם Legacy, שלא משנה כמה אתה משדרג את ה-Backend ואת הסכמות ואת ה-Database-ים - המוצר, יש לו Legacy, ה-Business Logic - יש לו Legacy. ויש כמה מוצרים . . . בקיצור, זה מגיע הרבה פעמים למצב שאין בנאדם אחד או שניים בחברה עצמה, שהיא הלקוח שלך, שבאמת יודע מה עושה כל פיסת דאטה . . .

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

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

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

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

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

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

• (יובל) אינטנסיבי - ורק דיברנו על הכנסת הדאטה לטבלאות המנורמלות. עוד לא דיברנו על המודל שעכשיו צריך להיבנות על גבי הדבר הזה.
• אז בעצם, השלב השני מגיע כשמסתיימת נורמליזציה, אז מגיע Data Scientist שבעצם מקבל ככה hand over ללקוח הזה.
• הוא מבין את ה-Pain-ים שלו, הוא מבין מה אנחנו בעצם רוצים לחזות.
• ואז הוא בעצם בונה מעל הדבר הזה איזשהו קוד Python שעושה Feature Engineering וככה בונה לנו את הפיצ'רים, מאמן בעזרת הפיצ'רים האלה מודל, ומעלה את המודל הזה.

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

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

(רן) טווח של שנה, שנתיים? . . . 

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

(רן) כן, וזה כמובן ספציפי ללקוח - יש לקוחות שבהם רק כסף מעניין, יש לקוחות שבהם רק Engagement מעניין, ובהרבה מקרים זה איזשהו שילוב של כולם. 
12:20 איך משפרים תהליך Human Intensive
(רן) אוקיי, אז איך לוקחים תהליך שהוא כזה Human Intensive ומשפרים אותו? פה אתה נכנס לתמונה.

• (יובל)  נכון. אז בעצם אנחנו הסתכלנו אחורה על הרבה תהליכי Onboarding שהיו לנו והבנו שהם יכולים להיות מאוד מאוד ארוכים - ושאנחנו רוצים לקצר אותם.
• ואנחנו בחרנו להתמקד בעצם בשלב בניית המודל - כי בסופו של דבר אנחנו חושבים שהחזון של המוצר זה בסוף להיות חברת SaaS.
• זאת אומרת, אנחנו לא רוצים . . . . כרגע, אנחנו כמו סוג קצת של Agency, ואנחנו רוצים להפוך להיות חברת SaaS.
• אנחנו לא רוצים להיות בעצם במצב שכמות ה-Data Scientist-ים שלנו תהיה בעצם Bottleneck ל-Scaling, 
• זאת אומרת, אנחנו לא רוצים שכמות הלקוחות שאנחנו נכניס לחברה תהיה מוגבלת על ידי מספר ה-Data Scientist-ים בחברה.
• (אורי) . . . וגם שלא תהיה קורלציה בין שני המספרים האלה . . . 
• (יובל) בדיוק, אנחנו לא רוצים את זה - אנחנו לא צריכים את זה ככה.
• ויותר מזה - אנחנו רוצים לפנות את ה-Data Scientist-ים שיסתכלו קצת על דברים רחבים יותר, לאו דווקא על Feature Engineering קבוע.
• ולכן החלטנו בעצם שגם ככה יש לנו אנליסטים מאוד חזקים וחריפים וחכמים - בוא ניתן להם את היכולת ואת הכלים להשפיע ישירות על הפיצ'רים ולהשפיע ישירות על איך שהמערכת שלנו בעצם מייצרת פרדיקציות.

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

• (יובל) לגמרי. 

(רן) אוקיי, אז יאללה - איך מהנדסים את זה? איך עושים את הסיפור הזה?

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

(רן)  זאת אומרת השלב של “הנרמול”, קראנו לו בהתחלה - זה ה-Feature Engineering?

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

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

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

(אורי) אבל תחשוב על זה - אתה מנסה להסתכל איפה יושבות העלויות הגבוהות? הן יושבות ב Data Scientists יותר מאשר ב-CSM-ים או אנליסטים. אז כאילו, תשבור קודם את היחידה הזאת, תשבור לה את הקורלציה לScale ו . . (רן)  כן. אוקיי, זאת אומרת, היה לכם שלב שבו לוקחים את הדאטה המנורמל ובונים ממנו פיצ'רים. עכשיו, אני מניח שיש פיצ'רים שמשותפים ללקוחות, בסדר? כן, זאת אומרת, לא כל אחד הוא Snowflake, אז זאת אומרת, אני מניח שיש פה איזשהו מקום ל-Reuse. אבל אתה אומר, אתם לא רוצים שזה יהיה Python-י - לפחות הממשק שאותו אתם חושפים לאנליסטים, שלא יהיה Python-י, שיהיה SQL-י - וזה משיקולי Skill, אני מניח, אוקיי?ויחד עם זאת, יצא לי לעשות משהו כזה, ולהחליט שאנחנו עושים את זה דברים רק ב-SQL - וגם זה לא כל כך נעים . . . זאת אומרת, אתה רואה, יכול להיות שמישהו שמדמיין SQL, מדמיין איזושהי שורה פשוטה של Select * From, אבל SQL יכול להיות חיה אימתנית, שאותה רק אנליסטים מבינים, וגם פה יכולה להיווצר איזושהי בעיית תחזוקה ו-Scale, ואולי גם Performance, כי לא תמיד יש לך שליטה בדיוק איך ה-run time מבצע את ה-SQL שלך.אז נגיד, איך אתם מתמודדים עם אתגרים כאלה?

• (יובל) אז כל הדברים שתיארת עכשיו זה בעצם היו האתגרים הכי גדולים שלנו.
• בעצם, איך אנחנו מצד אחד מאפשרים חופש מוחלט, ומצד שני שומרים על guardrails של cost ושאנחנו לא נתפזר עם הדבר הזה.
•  אז את התהליך הזה לקח לנו כמה חודשים לפצח ובעצם אנחנו, הצוות ML, הסתכלנו על הדאטה, לקחנו את הפיצ'רים, לקחנו את המודלים ה-Python-יים שכרגע רצים לנו ב-Production
• כמו שאמרת, יש כנראה פיצ'רים שהם נחלקים בין הלקוחות, זה היה חצי נכון . . . 
• אבל בגדול, הסתכלנו עליהם והבנו איזה תהליכים ולצורך העניין איזה טבלאות מנורמלות “אצלנו בבית”  ומעניינות אותנו, ועל גבי הטבלאות האלה, אנחנו בעצם יצרנו Pipeline-ים עם כלי מגניב שנקרא dbt, שלרוב הוא בכלל מיועד ככה ל-Analytics.
• זאת אומרת, בדרך כלל השימוש בו הוא על גבי Data lake, כדי לסדר את הדאטה יפה בשביל ה-Business, שה-Data Wearhouse יהיה נגיש וקריא.
• ואנחנו אמרנו, אוקיי, בואו - אנחנו מומחים בכלי הזה, אנחנו עובדים איתו המון בתוך החברה, בואו ננסה לבנות פה טבלה שמכילה לנו את כל הפיצ'רים.
• זאת אומרת, אנחנו בעצם לוקחים את כל הטבלאות המנורמלות שלנו בין הלקוחות.
• על גבי כל טבלה כזאת, אנחנו גם מריצים איזשהו תהליך של Information Gains, אנחנו בוחרים את הפיצ'רים הכי טובים גם פר-לקוח, עושים כמה טריקים של SQL.
• ובסופו של דבר מקבלים טבלה - טבלת Feature Store נקרא לזה - כש-Feature Store זה מונח קצת בעייתי לדבר הזה, אבל זו טבלה שמכילה לנו בעצם שורות ושכל שורה היא מצד אחד גם Sample לאימון ומצד שני גם Candidate ל־Inference ב-Production.
• זאת אומרת, יש לנו טבלה אחת שמכילה פיצ'רים, היא Materialized, אפשר לתשאל אותה, והאנליסטים שבוחרים איך לנרמל את הדאטה שולטים ישירות באיך שהטבלה הזאת תיראה בסוף. 

(רן) כן, אז קודם כל, נרפרר (Reference) לפודקאסט קודם שעשינו על DBT עם חיים [455 DBT with Chaim Turkel] אם אני לא טועה, אז יש לנו פרק שלם על זה. לא יצא לי להשתמש בכלי, אבל נשמע אחלה כלי, ובוא רגע נחזור לנושא שלנו.
אז בעצם מה שאתה אומר זה שנגיד עבור כל משתמש של החברה קיימת שורה, נניח, או נגיד לכל משתמש בכל יום, או באיזושהי רזולציה שאתה בוחר, והעמודות הן הפיצ'רים שרלוונטים לאותה חברה. נגיד האם ביקר? . . . כמה פעמים ביקר במהלך השבוע באתר? או בכמה כסף הוא קנה בשלושת הימים האחרונים? זאת אומרת, אותם פיצ'רים שאתם בוחרים שיהיו ב-Feature Store שלך. אני מבין שזה לא בדיוק Feature Store, אבל נקרא לו כך לשם הדיון. אז ככה זה נראה?

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

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

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

(רן) כלומר, אוקיי - זאת אומרת, אתה אומר שהיה איזשהו Drift ב-Input Data . .  אוקיי, ומה אתם עושים? קודם כל, כמובן שיכולות להיות אנומליות אמיתיות כמו חג המולד או נובמבר וכאלה - אבל גם יש אנומליות של פשוט שגיאות, באגים. איך עולים על זה ואיך מתמודדים עם זה?(אורי) גם יש לפעמים השפעה של המודל על ההתנהגות של המשתמשים שמשנה את הדאטה ו...(רן) כן, כן, יש Feedback Loop.

• (יובל) Feedback Loop, בדיוק . . .  אז את ענייני האנומליות בדאטה אנחנו בעצם מנטרים על גבי הדאטה - זאת אומרת, עוד לפני שאנחנו בכלל נותנים פרדיקציות.
• אני רק אגיד שבעצם על ידי העובדה הזאת, שעשינו את התהליך שתיארתי, שבעצם אנחנו - we materialized our feature store - ובעצם יש לנו איזושהי טבלה שאנחנו יכולים לתשאל, אז אנחנו גם יכולים לעשות על הטבלה הזאת Monitoring.
• ועכשיו Monitoring על פיצ'רים נהיה הרבה יותר קל.
• זאת אומרת, לפני שאנחנו בכלל נותנים את הפרדיקציה, אנחנו יודעים שהדאטה מתנהג בצורה חריגה, ולכן אם הפרדיקציות שלנו יהיו חריגות, זה אולי לא יעלה לנו דגל אדום.

23:44 איך יותר קל וקומפקטי לעשות שטויות - SQL מול Python 
(רן)  כן, טוב, אז נחזור רגע לנושא ההנדסי-טכני של נגיד SQL מול Python. זה יכול להיות דיון גנרי, אבל במקרה הזה אנחנו מדברים על SQL מול Python.אז אמרנו שחלק מהאתגרים זה באמת עלויות; חלק מהאתגרים זה אולי היכולת להיות קריאטיבי, זאת אומרת, נכון, אפשר לעשות המון דברים ב-SQL, אבל לפעמים יותר קל לעשות אותם ב-Python.(אורי) . . .  אם אתה קריאטיבי . . .(רן) . . .  כן, ולפעמים זה גם הפוך . . . אבל בכל אופן, זאת אומרת, זה לא one size fits all, יש בהחלט דברים שיותר קל יהיה לעשות את זה. נכון, יש פונקציות חלון ב-SQL, אבל צריך להיות אנליסט מאוד מתקדם כדי להבין אותן. אבל יש דברים שיותר קל לעשות ב-Python, ב-pandas, ב-NumPy. זאת אומרת, זה ספריות שנבנו לזה, ולפעמים זה יותר פשוט. והאתגר שקצת נגענו בו, אבל לא ממש דיברנו על איך פותרים, זה האתגר של העלות. זאת אומרת שכמובן שאתה יכול לעשות שטויות גם ב-Python ולבזבז CPU, אבל זה קצת יותר קל ויותר קומפקטי לעשות שטויות ב-SQL, והשאלה איך שומרים על הסיפור הזה?לא יהיה זמן לטפל בהכל, אז תבחר מה אתה רוצה לענות.

• (יובל) אז אולי אני אתחיל דווקא מהסוף - הטיפול שלנו ב-SQL.
• אז החל מרגע של סיום הנורמליזציה, אין יותר כתיבת SQL, אלא ה-SQL נכתב אוטומטית על ידי ההגדרות שהאנליסטים נתנו.
• ואנחנו כצוות Engineering שהוא Mindful מאוד ל-Cost, אנחנו בעצם גרמנו לכל ה-Queries להיבנות בצורה הכי יעילה שיש, כדי לא להשתמש ולא לבזבז יותר כסף ממה שצריך.
• ולצורך העניין אני רגע אתלבש כבר על מה ששאלת מקודם, אז כשהיינו בעולם ה-Python-י יכולנו לעשות “הכל”. 
• זאת אומרת, אנחנו עכשיו גם הקטנו מאוד את מרחב המשחק שלנו עם הפיצ'רים האפשריים שאנחנו יכולים לעשות, אז על גבי הטבלות המנורמלות, על גבי ה-Feature Store, אנחנו בינינו בעצם גם שכבות משלנו שאנחנו תמיד יכולים לעשות Enrichment לפיצ’רים, בלי שנזלוג בעצם . . . מה שנקרא “נראה את העתיד”, מה שנקרא Training Service Queue.

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

• (יובל) בדיוק.

(אורי) זה גם מאפשר לך . . . זאת אומרת, כל פיצ'ר הוא עמודה בטבלה?

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

(אורי) אבל אני בדרך כלל לא . . .  יש Domain-ים, שאני לא אוהב שדברים הם בעמודות - כי זה מאוד מאוד סטטי. וזה, אתה יודע, להוסיף פיצ'ר עכשיו זה להוסיף עמודה - ולהוסיף עמודה זה כואב. וזה אומר, לפי מה שאני מבין ממך, זה שעולם המודלים שלכם והפיצ'רים במודלים הוא מאוד מאוד סטטי. זאת אומרת, אתם לא מתכננים לשינויים דרמטיים בעולם הפיצ'רים שלכם, בשביל שמהצד השני אתה יודע אתה הולך ל... בין אם זה Deep Learning או כמויות של פיצ'רים הן הרבה מאוד פעמים דינמיות, בפיצ'רים.

• (יובל) אז כן ולא - כי אנחנו יודעים להגדיר כבר עכשיו סט פיצ'רים שהוא מאוד מאוד חזק.
• זאת אומרת, המודלים שלנו מתפקדים מאוד מאוד טוב - אבל הבעיה שאתה מתאר, כמובן שהיא עלתה לנו לראש.
• וכבר עכשיו יש לנו דרך להרחיב את ה-Feature Store הזה - אבל בצורה תוכנתית.
• עכשיו, איך אנחנו עושים את זה? כשהמודלים שלנו ניגשים בעצם ל-Feature Store, יש לך איזושהי נקודת גישה אחת - בין אם זה ל-Training ובין אם זה ל-Inference.
• אתה יכול לתשאל את הפיצ'רים - ובעצם, כשאתה מביא אליך את הפיצ'רים עצמם, אנחנו יודעים גם להצמיד אליהם עוד פיצ'רים, שהם לא materialized, אבל הם יהיו קיימים, לצורך העניין, ב-Feature Matrix שאתה הולך לחזות. 
• עכשיו, הפיצ'רים האלה זה פיצ'רים שבאמת אנחנו לא יכולים לתשאל בצורה הזאת, ב-SQL.
• אבל אנחנו כרגע יודעים שכשיש לנו איזשהו “פיצ'ר מנצח” - זאת אומרת, אתה רוצה, יש לך איזה מקרה קצה אצל הלקוח עכשיו, אתה יודע שפיצ'ר מאוד חזק זה מספר הטרנזקציות מסוג X שעברו לפחות שלושה ימים מאז שהם קרו. 
• אז לדבר הזה אנחנו גם נותנים לאנליסטים יכולת לכתוב איזשהו Template - כשאת ה-Template הזה אנחנו מצמידים ל-Query ב-Feature Store בזמן הריצה.
• ואז הפיצ'ר הזה . . .  זאת אומרת, אנחנו לא צריכים עכשיו לעשות מיגרציה (Migration) לטבלה עצמה, אבל אנחנו בונים איזשהו view מעל זה שכן עושה לפיצ'ר הזה מטריאליזציה (Materialize) במובן שבו אתה יכול לתשאל אותו ולראות את הערכים שלו.
• אז אנחנו גם יכולים לבנות המון פיצ'רים בגישה הזאת, ובעצם על ידי זה להרחיב את ה-Feature Store שלנו.

(רן) זאת אומרת שיש פה איזושהי Expansibility בעצם, זה מה שאתה רוצה . . .

• (יובל) לגמרי . . .

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

• (יובל) מוריד Complexity . . . 

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

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

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

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

• (יובל) אז אנחנו עובדים גם על המון המון מוצרים אחרים - וזה בעצם מפנה אותם לעבוד ולהתמקד ב-Use Case-ים האלה. 
• המוצר שאני בעצם תיארתי הוא משהו שיותר מתמקד באזורי ה-User Acquisition, החלק הראשון ב- User Life Cycle, וזה משחרר הרבה מאוד מה-Data Scientist-ים שלנו להתמקד עכשיו באזורים של Streaming.
• עכשיו עושים Feature Engineering ב-Streaming, ושם הכל לחלוטין Python-י . . .
• יש המון המון דברים אחרים מעניינים ומאתגרים - והם לא נעלמו לגמרי.
• כי בעצם, כשיש בעיות מסובכות, כשיש מודלים שעדיין צריך לפצח . . . כאילו, לא הגענו עוד ל-Quality שאנחנו רוצים, אז מה עכשיו? 
• תמיד יהיה מה לעשות באזורים האלה.

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

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

(אורי) ולכמה זמן זה יהיה תקף? כאילו...

• (יובל) למה הכוונה?

(אורי) אתה אומר “הם לא צריכים לעשות יותר כלום” . . . 

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

(אורי) אבל בגדול, אם הכל מתנהל כמו שצריך - ה-Data Scientist לא ב-Loop. . .

• (יובל) עוברים ללקוח הבא . . . אם אנחנו, עכשיו, יש לך מודלים שרצים, והלקוח מרוצה - אתה מראה לו value, אתה עושה את כל מה שאתה אמור לעשות כמוצר. If it works. . .

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

• (יובל) הם עדיין בלופ. אין ברירה. כן, אין ברירה. 

(רן) כן. תראה, אולי מתישהו גם... 

• (יובל) אולי מתישהו - אנחנו עובדים גם על Report-ים שיעשו את העבודה הזו. 

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

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

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

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

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

• (יובל) אז אנחנו יושבים בתל אביב, ככה ממש ליד עזריאלי.
• כרגע אנחנו 90 איש בחברה, ואני חושב שעד סוף השנה מתכננים להיות כבר יותר קרוב ל-110-120.
• מגייסים באמת להמון תפקידים - ה-R&D שלנו יחסית קטן, ואנחנו מנסים לשמור עליו ככה. 
• אנחנו ככה, עם כל ההייפ הנוכחי, גייסנו לצידנו את כל כלי ה-AI הרלוונטיים, ואנחנו רואים ש... 
• (אורי) אגב, אנחנו לקראת הסוף וזו פעם ראשונה שאמרנו “AI”. 
• (יובל) “AI” ,כן. אף אחד לא אמר את זה, אז הרגשתי צורך.
• אז באמת מגייסים להרבה תפקידים, גם ב-R&D. שכחתי מה אמרת . . .
• (רן) לא, שאלתי מה מגייסים, סתם אם מישהו מעוניין שידע. 
• (יובל) כן, דברו איתנו!
• (רן) מעולה. בסדר, אז תוכלו כמובן למצוא את זה ב-show notes [שזה כאן, בגדול].

38:35 כנס Reversim Summit 2025
(רן) לפני שנסיים, נזכיר שאנחנו עומלים על הכנס הבא.(אורי) נכון! אם אתם רוצים לתת Sponsorship. . . 

• (יובל) אני אברר . . .

(רן) לא נעמיד אותך בפינה . . .  אבל כן, אז נזכיר כמה דברים:

• קודם כל, אם אתם מספיקים לשמוע את הפרק הזה לפני הרביעי או אולי השלישי ביוני, אני לא זוכר, אז יש לנו סדנת הגשות, נראה לי שזה בשלישי ביוני. אז קודם כל, תודה רבה לדפנה שעושה את זה. אנחנו נעשה סדנת הגשות Online, מוזמנים להירשם. 
• חוץ מזה, הקול הקורא להגשות פתוח עד סוף, כמה? עד סוף יוני, אוקיי? אז מוזמנים לבוא ולהגיש.
• וכמובן, לכשנפתח את ההרשמה לכנס הזה - מוזמנים לבוא ולהירשם.
• ו-Shout-Out אחרון לספונסרים - אנחנו עדיין כאן, יש לנו כמה מקומות, ונשמח לראות את החברות שמקשיבות לפודקאסט גם עוזרות לכנס.
• בסופו של דבר, הכנס הוא כנס שהוא קהילתי, הוא לא למטרות רווח [494 SoLead and RS] - אבל הוא עולה כסף: לארח את האנשים, להאכיל, לצלם וכל זה.
• אז בשביל זה אנחנו צריכים שיעזרו לנו ב-Sponsorship, ואתם כמובן מקבלים חשיפה ונמצאים במקום הנכון.
• זהו, אז צרו קשר איתי, עם אורי או עם רבקה - אני בטוח שאתם יכולים למצוא את הפרטים של כולנו באינטרנט. @reversim.com, כל אחד מאיתנו [רן ב[email protected] ורבקה ב[email protected]] או https://www.linkedin.com/in/rivka-dudi/ 

• 
  

זה הכל. תודה רבה לך, יובל! - תודה רבה לכם - ובהצלחה עם כל ה-AI הזה שלך. להתראות.
[קישור לקובץ mp3]
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 494 של רברס עם פלטפורמה, שהוקלט ב-25 במרץ 2025 (שלקלק?!). פרק מיוחד - אורי ורן מקליטים סולו, כדי לדבר על פרויקטי-צד אישיים, ביחד ולחוד, שחלקם הפכו גם ל-Full-time: כנס Reversim Summit ו-SoLEAD, הפרויקט של אורי. 🎗️



01:25 אורי ו-SoLEAD

• (אורי) טוב, אהלן, נעים להיות פה בפודקאסט הזה! איזה כיף שהזמנתם אותי . . .
• (רן) . . . איזה כיף שהזמנתם, מאזין קבוע, איזה כיף . . .
• (אורי) . .  זכות! זכות גדולה. כן . . . אנחנו נדבר קצת על SoLEAD,  שהיא חברה שאני מריץ כבר כמעט שנתיים -   ובתוכה, על קהילה ספציפית שהיא קהילה של CTOs ומנהלי-פיתוח.
• (רן)  SoLEAD - סולידי? מהם ראשי-התיבות?
• (אורי) לא, זה SoLEAD. זה חיבור של שתי המילים - Sole, שזה בודד, ו-Lead.
• כי מה שאנחנו עושים זה בעצם קהילות-עמיתים ל”מנהיגים בודדים בצריח”.
• (רן) הופה, זה משהו שצריך לעבד . . . “קהילות-עמיתים למנהיגים בודדים בצריח”?
• (אורי) “קהילות-עמיתים” - מכירים את זה כ-Peer Communities. זה בעצם קהילות של אנשים שהם עמיתים - זאת אומרת, עוסקים באותו תחום.
• (רן) במקרה שלנו - CTOs?
• (אורי) במקרה של הקהילה הזאת זה CTOs ו-VP R&D, אבל חוץ מהקהילה הזאת יש לי גם קהילות של יזמים, מנכ״לים . . .
• השנה אני פותח גם ליזמים חברתיים שעוסקים בשיקום.
• (רן) כלומר, אנשים עם עיסוק דומה, אבל לא סתם . . . זאת אומרת, לא, נגיד, “מהנדסים”, אלא כאלה שנמצאים בפוזיציות מאוד מיוחדות.
• (אורי)  אז זה פוזיציה שהיא לרוב בראש המערכת - בצריח, בראש ארגון.
• מתוך הבנה שלעמוד בראש ארגון זו פוזיציה מאוד מאוד בודדת, לא זוהרת בכלל.
• ויש הרבה מאוד דברים, הרבה מאוד אספקטים - שיש שם פשוט בדידות.
• (רן) אז זה בעצם סוג של “קבוצת-תמיכה”, נקרא לזה?
• (אורי) בסוף, אני יותר נוהג להתייחס לזה כקהילה - כי קהילה זה משהו שמקנה חוסן.
• ותשאל כל CTO או VP R&D או אנשים שהם באמת מנהלים ארגוני-פיתוח או מנכ”לים -  בסוף, זה המון עליך.
• ואתה מסתכל ימינה ושמאלה ואין עם מי להתייעץ, אין עם מי לדבר - אתה יודע, על תחושות, על שאלות . . . אין עם מי להתייעץ על הרבה דברים.
• וכשכבר יש לך עם מי להתייעץ - אז או שאין לו זמן או שאיכשהו צריך לפנות זמן לעניין הזה.
• וגם לא תמיד יש את התחושה שזה בנאדם שאני יכול לתת בו אמון ולהתייעץ “נקי”. 
• (רן) נניח, אם אני CTO, אז לא על כל דבר אני יכול לדבר עם הבורד, עם המנכ״ל או אחרים שנמצאים לידי, הרבה פעמים.  
• (אורי) אני חושב שספציפית ל-CTOs ו-VP R&D - אומר מניסיון, כן? 13 שנה בסוף הייתי הייתי CTO של Outbrain - 
• בחלקן, בחלק מהשנים, היה לי VP R&D שהיה Pier שלי,  זאת אומרת - לא דיווח אליי.
• אבל הרבה מאוד שנים... מצד אחד, אתה חבר הנהלה, אז אתה אומר, “אוקיי, אז חברי ההנהלה האחרים יהיו ה-Peers שלי ואני אוכל לדבר איתם”.
• הבעיה היא ספציפית ל-CTOs  או למנהלי פיתוח, שבזמן שרוב ההנהלה, הרוב המכריע אולי, מדבר “MBA-ית” - הם יודעים, הם מבינים אחד את השני.
• כי, אתה יודע, זה מגיע מעולם המושגים של מנהל העסקים -  ו-CTO מדבר “הנדסית”. 
• הארגון שלו הוא ארגון עם תרבות אחרת,  ברוב המקרים, משאר חברה. המוטיבציות שם הן אחרות. 
• אז אתה תחשוב על שאלות כמו, למה צריך להשקיע ב . . .  למה 20% מהזמן של האנשים שלי הולך על Tech Debt?  כאילו, אתה אוטומטית מוצא את עצמך בעמדה מתגוננת ואתה מנסה להסביר את זה - ויוק, לא מבינים את ה...  
• אז זה רק דוגמה אחת, כן?

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

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

• (רן) באיזשהו מובן, אתה עושה עליהם Canary Testing . . . 
• (אורי) בדיוק, זה ה-Sandbox שלך . . .
• מצאתי גם, אחר כך בתוך הקהילות האלה, את הסימטריה הזאת - שהיא מאוד טובה.
• (רן) כן, זאת אומרת שכל אחד יכול להשתמש ברעיונות טובים, ולא חשוב כמה ניסיון יש לך - תמיד רעיונות וגישות שונות עוזרות.
• (אורי) גם לפעמים . . . נגיד מהניסיון שלי, היו לי מחשבות לעשות, נגיד, שינוי תרבותי בארגון.
• עכשיו, וואלה -  כשהיינו קטנים, עשינו את זה. אתה זוכר, עברת איתנו ב-Outbrain את המעבר ל-Continuous Deployment [סטטוס אחרי כמה שנים בפרק 368 Kubernetes and Dyploma at Outbrain]. 
• החלטנו, עשינו, זרם - על הכיפאק, אבל היינו 30 מהנדסים. עכשיו היה לי ארגון של 300 מהנדסים.
• וזה הצריך הרבה יותר מחשבה לעומק - ולא היה לי עם מי להתייעץ.
• רק בקהילה כזאת, שהיו בה כמה CTO-ים עם ניסיון ועם ניסיון בחברות גדולות.
• בעיקר דיברתי אליהם את הרעיונות שלי,  והם שיקפו לי בחזרה וחידדו לי דברים ועזרו לי להבין יותר טוב מה אני עושה,  לאן אני הולך.
• זה מאוד עוזר שאתה מדבר אל מישהו ויש איזשהו פינג-פונג, ואתה לא חושש לדבר על הכל כי,  אתה יודע  . . .
• אתה לא חושש, זה לא המנכ״ל שלך שאתה פתאום תפחיד אותו, או הבורד שלא יודע, יסתכל על “אוי, מה הוא עושה להשקעה שלי!”.

(רן) כן.  זה Safe Zone באיזשהו מובן. 

• (אורי) זה מאוד Safe Zone.

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

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

(רן) דרך אגב, שמתי לב מקודם ש-Sole זה לבד,  אבל זה גם נשמה [Soul], ואולי...  

• (אורי) לא כתוב אותו הדבר, אבל...

(רן) כן, אבל כשאומרים אז אי אפשר לדעת . . .  אז אולי זה גם ל”שחקני-נשמה". 
11:45 איך הכל התחיל
(רן) אז השאלה הבאה שלי: הבנו את המוטיבציה, אוקיי. יש אנשים שנקרא לזה “לבד בצמרת”. זה לא חייב להיות בהכרח המנכ״ל - במקרה הזה זה CTO,  VP R&D - אבל עדיין יש איזושהי תחושת בדידות, ומחפשים עמיתים לדבר איתם ולהתייעץ איתם.אז המוטיבציה ברורה, והייתי שאל אותך איך כל זה התחיל - אבל בעצם הייתי שם כשזה התחיל . . . 

• (אורי) נכון, היית.

(רן)  אז אני אספר קצת על החוויה שלי: בעברי גם הייתי CTO של חברה קטנה, ובאמת אורי הזמין אותי לאחת האיטרציות הראשונות של SoLEAD. 

• (אורי) הראשונה ...  עוד לפני שהיה SoLEAD.  

(רן) כן, עוד לפני שקראו לזה כך.

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

(רן) כן, זה היה מן פרויקט חד-פעמי כזה?

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

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

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

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

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

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

• (אורי) אז תראה, שם היינו שמונה . . . 

(רן) . . . שמונה בסירה - ושתי סירות.

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

(רן) ויש כמה סירות?

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

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

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

(רן) אבל בסך הכול זה די אינטימי . . .

• (אורי) מאוד אינטימי.

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

• (אורי) חמישה ימים.  כן. 

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

• (אורי) האמת שמאז ההפלגה שלך, מאז שאתה לא CTO, המשכנו לעשות את זה כל שנה.
• זאת אומרת, אתה הפלגת ב-2016 והחבר'ה אמרו “יאללה, בוא נעשה את זה גם בשנה הבאה”.
• הגיעה השנה הבאה - כבר יצאנו 21 חבר'ה, וככה, משנה לשנה, התווספו עוד אנשים.  
• אני חושב שב-2023 . . .   ב-2016 יצאנו 13 להפלגה הזאת. ב-2023 הקהילה מנתה בערך 60 איש,  שכבר עברו והפליגו, ויצאנו 40.  
• בשש סירות, זה . . . 
• (רן) . . .  פלוטילה רצינית.
• (אורי) זה גם מבצע לוגיסטי, אבל בעיקר הדבר שאנחנו הבנו זה שזה נהיה כנס קטן, ופחות הקהילה האינטימית שהיינו לפני זה.
• נוצר שם איזשהו FOMO כזה, שאני לא מספיק לדבר עם כל האנשים,  ואם אני מספיק לדבר אז אני אדבר פחות מהזמן שרציתי.
• כי הדבר היפה בהפלגות האלה,  זה שאתה יכול להיכנס לשיחה עמוקה וארוכה על משהו שהוא באמת, לא יודע - דילמה גדולה שיש לך, או מחשבות גדולות שיש לך כ-Leader.
• וזה היה הטריגר להקים את SoLEAD.
• (רן) תגיד, דרך אגב . . . אני אתן דוגמא שאני ממש זוכר מאחת השיחות האלה -  זה לא היה אחד על אחד, זה היה,  אני חושב אולי שלושה-ארבעה אנשים, אבל ישבנו, אני זוכר שהיה שם את עופר,  שהיה אז מנכ״ל של...  זאת אומרת, אז זה היה גם מנכ״לים וגם CTOs,  ודיברנו על תרבות עבודה ועל שעות עבודה ועל עומס ועל שחיקה.
• חלק הציגו דעה של “אוקיי, זה סטארטאפ, צריך פול-גז כל הזמן”,  ויש כאלה שדיברו על שחיקה של כוח אדם ועל איך באמת  לשמור כוח לספרינטים כשצריך אותם.
• ולא זוכר - הסכמנו, לא הסכמנו - אבל השיחה עצמה מאוד מעשירה. 
• (אורי) כן, לגמרי. אתה שומע המון דברים מאוד, כאילו . . . מאנשים - את “משנת חייהם”.
• ואני חושב שמי שבא לאירוע הזה פתוח ובא עם שאלות גדולות, אז הוא מקבל המון ייעוץ וגם Reflection, רפלקציה. 
• זו לא חייבת להיות עצה פרקטית, אבל מספיק שיש מישהו ששואל אותך שאלות חכמות - זה מחדד אותך ברמות מאוד טובות, ויש את הזמן לזה.
• (רן)  כן. מעולה.

19:22 מה עוד קורה, מי יכול ואיך עולים לסירה
(רן) אז איך זה נראה במהלך השנה? זאת אומרת, הזכרנו את ההפלגה. מה עוד קורה? 

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

(רן) אתה רואה את הסדרה Severance, דרך אגב, ''ניתוק”?

• (אורי)  לא. 

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

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

(רן) מצוין.  אז כל אחד יכול?  מי שרוצה, מה הוא עושה?

• (אורי) אה, תנאי הקבלה? קודם כל, אתה צריך להיות ב-Cohort - אם אנחנו מדברים על CTOs או VP R&D, אנשים שעומדים בראש ארגון הפיתוח,
• אז אם זה מה שמגדיר את ה-Cohort הזה, אז אתה צריך להיות כזה.
• והדבר השני -  מישהו צריך להגיד עליך שהוא היה שמח להיות איתך חמישה ימים בסירה . . .  זה גם מאוד חשוב. 

(רן) כן, זאת אומרת לא בהכרח אחד מהמשתתפים, או שכן מישהו מהמשתתפים?

• (אורי) לא, לא בהכרח מישהו מהמשתתפים. 

(רן) . . . איזושהי עדות-אופי, משהו שירגיע.

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

(רן) זה אחד על אחד, כן? פגישות אחד על אחד.

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

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

• (אורי) היא בתשלום, כן.

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

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

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

• (אורי) כן.  

(רן) אז פשוט שיצרו איתך קשר, מי שרוצה.

• (אורי) כן, אני, אתה יודע - אורי להב ב-LinkedIn ו[email protected].

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

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

(רן) . . . מארגני כנסים בישראל. 

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

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

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

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

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

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

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

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

• [תקציר האירועים מכנס רברסים 2019 - The Reversim Story / Ran Tavory & Ori Lahav]

• השנה הזו הולכת להיות הפעם ה-12 של הכנס, כנס מספר 12. 
• הוא התחיל בתור איזשהו ניסיון ככה - שבזמנו היה נראה אולי קצת כמו הפלוטילה, חד פעמי - שהחלטנו שאנחנו רוצים לפגוש את המאזינים של הפודקאסט.
• בדיעבד מסתבר שהגיעו גם כאלה שהם לא מאזינים, אבל זה בסדר, כולם מוזמנים.
• עשינו את זה בהתחלה בקמפוס של גוגל, בשנה-שנתיים הראשונות,  עד שזה נהיה קטן מדי, כי היה ביקוש מאוד גדול לכרטיסים.
• למעשה, מהשנה הראשונה הוא כבר היה Sold Out. זו ממש הצלחה שלא צפינו לה.
• (אורי)  התחלנו ב-200 איש, נכון?
• (רן)  כן.  זאת אומרת, כבר אז היו יותר מ-200 שנרשמים, אבל לא היה מקום ליותר מ-200, אז התחלנו בזה.
• ועם הזמן, הכנס נדד בין מקומות שונים - בצפון, בדרום, במרכז -  אבל בשנים האחרונות, המקום היחיד שיכול להכיל את כל הקהל הזה זה למעשה גני בתערוכה בתל אביב או Expo . . . 
• (אורי) . . . עם הדרישות שלנו לפיצולים וכו’.
• (רן) כן, כן. אז נכון להיום, זה כנס שמכיל משהו כמו 1,300 איש בכל יום, באזור ה-2,000 Unique-ים - זאת אומרת ביומיים השונים.
• למעשה, מי שמגיע לכנס יכול להגיע לשני הימים, ואנחנו מאוד שמחים אם אתם עושים את זה, אבל גם אפשר להגיע ליום אחד.
• אנחנו משתדלים לחלק את התוכן בצורה הגיונית בין הימים, ככה שתוכלו לבחור לכם.
• אז בסך הכל באיזור 2,200 Unique-ים בכל שנה - ועדיין, אנחנו Sold Out ותמיד יש לנו רשימות המתנה מאוד ארוכות, ואנחנו נגדיל את התפוסה שלנו אם נוכל, זה מאוד תלוי בתנאים הפיזיים שיש לנו שם.
• אבל כמו שאורי אמר, זה בשביל הקהילה ולמען הקהילה - וכשאנחנו אומרים “קהילה” אנחנו מדברים על קהילת התוכנה, בגדול, בישראל.
•  יש פה ושם גם דברים שהם לא ממש תוכנה, אבל דברים סביב עולם פיתוח התוכנה.
• שזה פיתוח תוכנה, בקרת איכות,  Data Science, מוצר, Design . . . 
• (אורי) תרבות . . .
• (רן) . . .  כן, ניהול, תרבות-ניהול… 
• אבל הפוקוס הוא סביב שרשרת-פיתוח התוכנה ומה שקשור אליה. זאת אומרת, זה לא כנס עם פוקוס על Product Management, אוקיי?  זה לא כנס עם פוקוס על Product Design -  אבל כן יש נגיעות בזה. 
• זאת אומרת, יש סשנים שמדברים על זה, במקומות שבהם זה בעיקר רלוונטי לאנשי תוכנה, ומן הסתם יש כאלה. אם אתם עסקתם בזה, אז אתם יודעים שיש לא מעט כאלה.

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

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

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

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

אז כמו שאמרנו - כנס למען הקהילה ובשביל הקהילה, וזו באמת הקהילה שמייצרת את הכנס.

• וגם השנה יש צוות של 20 ומשהו מתנדבים שבאים ועובדים מאוד קשה.
• צוות נאמן, כמו בכל שנה, מאוד עוזרים למצוא את התכנים האיכותיים.
• אז כמו שאמרנו, דבר אחד שמבדיל את הכנס מכנסים אחרים זה שכל התוכן נבחר בקפידה והתוכן לא ממומן, אבל דבר נוסף שמאוד מאפיין את הכנס זה התמיכה בדוברים. 
• זאת אומרת, אם יצא לכם פעם להגיש הרצאה או הצעה להרצאה בכנס, ובסוף אתם מקבלים הודעה - התקבלתם או לא התקבלתם - ובפעם הבאה שמדברים איתכם זה כשאתם על הבמה בכנס - אז אצלנו זה לא ככה.
• אצלנו, אנחנו באמת עובדים יחד עם המגישים, יחד עם המרצים, כדי לטייב את ההרצאה.
• החל מעבודה על Draft-ים של מצגות, מפגש לדוברים הפוטנציאליים כדי לשפר את יכולות ה-Public Speaking שלהם, Mingling של הדוברים, דרך Dry-Runs שהם סופר-סופר חשובים ומאוד מאוד משפרים, גם מישהו שהוא מאוד מאוד מנוסה.
• זאת אומרת, אמרו לנו לא פעם דוברים מאוד מנוסים שה-Dry-Run לגמרי הפך להם את ההרצאה ועשה אותה הרבה יותר טובה ממה שהם חשבו שיכולה להיות.
• (אורי) כי המודרטורים שלנו, נגיד, לא מתרשמים מזה שיש לך הרבה ניסיון - הם יגידו כשהם . . . לא יחסכו ביקורת.
• (רן) כן, אז באמת לא מעט, גם אנשים שהיו Keynote Speakers באו ואמרו שה-Dry-Run מאוד מאוד עזר להם לייצר הרצאה פשוט הרבה יותר טובה.
• אז זה ערך מוסף מאוד משמעותי שאנחנו נותנים גם לדוברים.
• ואנחנו גם מאוד מעודדים דוברים חדשים, ואנחנו משתדלים שחלק משמעותי מהדוברים יהיו דוברים שלא דיברו לפני זה בכנס משמעותי.
• זאת אומרת, אולי ב-Meetup-ים, אולי בדברים פנימיים - אבל לא בכנס משמעותי, כדי לייצר להם חשיפה, כדי לעזור להם.
• ויש אנשים שאני חושב שזה עשה להם שינוי-קריירה די משמעותי  ומאוד עזר להם בהתפתחות הזאת.
• (אורי) אני חושב שגם חברות, לקראת הכנס, עושות מה שנקרא “מסיבת CFP”, לראות  שהן מביאות את הרעיונות החדשים והחדשניים שלהן אל הבמה.
• שזה מוגש טוב, שזה בנוי טוב, שזה יתפוס את העין של מודרטורים.
• וגם אחר כך משקיעות ביכולות Public Speaking של הדוברים שכן מתקבלים, כדי שהם ייצגו את החברה טוב על הבמה. 
• (רן) כן.  

(רן) אז עוד כמה מספרים, כי אנחנו אנשים של מספרים, מה לעשות?  אז הכנס - דיברנו על הגודל שלו, ויש לנו ערוץ YouTube

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

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

• אז בגדול יש לנו שתי חבילות - מי שמעוניין שישלח לי אימייל ונשלח את כל הפרטים, אבל בגדול: 
• אז יש חבילה אחת שכוללת נוכחות פיזית בכנס עם דוכן ועם נוכחות ב-Digital Media וכל  זה.
• ויש אחת שהיא רק Digital Media.
• ואולי אחד הדברים הכי אטרקטיביים ב-Sponsorship זה vיכולת לקנות כרטיסים.
• כי כמו שאמרנו מקודם, הכרטיסים מהר מאוד נגמרים לכנס, אבל אנחנו כן שומרים כרטיסים לספונסרים, כחלק מהחבילה.
• ככה שאם אתם רוצים לוודא שלעובדים שלכם יש כרטיסים, אז או שתהיו ממש מוכנים בזמן ברגע שאנחנו פותחים את המכירה, או שתהיו ספונסרים ואז לפחות חלק מהעובדים יוכלו להגיע.
• ובכל אופן, זה עוזר לכם לקבל את הוויזיביליות הזאת - מן הסתם הלוגו שלכם יימצא באתר ויש עוד ועוד...  
• (אורי) אני חושב שיש גם באנר של ה...  לכל ספונסר ב-Social שלנו. 
• (רן) כן, לגמרי. אז גם הנוכחות ב-Website עצמו, גם ב-Social, גם פיזית בכנס, תלוי בחבילה.  
• (אורי) Thank You note . . . 
• (רן) וגם בוידאו, בתחילת כל וידאו, שכמו שאמרנו, יש קרוב ל-500,000 צפיות בסך כל.
• אז יש חשיפה משמעותית ואני חושב שלא פחות מזה, זה להיות חלק מהקהילה הזאת, אוקיי? להיות חלק מהקהילה ומה שנקרא שיהיה לכם Skin in the game, אוקיי?
• לא רק לבוא לכנס וליהנות, אלא ממש להיות חלק מהקהילה שתומכת - ובלי ספונסרים הכנס הזה לא יכול לקרות.
• אנחנו תמיד ממלאים את שורות הספונסרים, אבל ברור שאם זה לא היה קורה, אז הכנס גם לא יכול לקרות.
• כי להפיק כנס עולה הרבה מאוד ואנחנו כן משתדלים להוריד את מחיר הכרטיסים ככל הניתן - זה עדיין לא בחינם, אבל משתדלים להוריד את מחיר הכרטיסים ככל הניתן.
• עדיין, מחיר כרטיס לא משלם את כל...  
• (אורי) אני חושב שיחסית לכנסים אחרים, מחירי הכרטיסים שלנו נמוכים מאוד.
• (רן) נמוכים משמעותית -
• וחלק מהעניין זה שהכנס הוא לא למטרות רווח - בסך הכל אנחנו מגייסים את הכסף כדי שבסוף נישאר Break Even, אבל הוא לא למטרות רווח.

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

• האימייל שלי זה [email protected] ורבקה ב[email protected].
• וזהו, נשמח לראות אתכם.

ואולי Disclaimer אחד קטן - בסוף לא רק הכרטיסים נגמרים, גם שורות ה-Sponsorship נגמרות, אז אנחנו הולכים לפי FIFO - כל הקודם זוכה, אבל אם תהיו מספיק זריזים אני בטוח שתזכו.זהו, עוד משהו להוסיף אורי?(אורי) לא, זה כנס משמעותי. (רן) כן. אה, אולי עוד כמה תאריכים -  אז הכנס עצמו קורה בסוף אוקטובר, אבל ה-Call For Presentations - למעשה, מי שרוצה לדבר - ייפתח בקרוב, בעוד כמה שבועות, ככה באפריל-מאי,  אז Stay-tuned מה שנקרא.

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

אז צרו איתנו קשר - שוב: איתי, או עם אורי  או עם רבקה, או עם כל אחד אחר מהצוות - ואנחנו נחבר.זה הכול, להיום. היה כיף.  SoLEAD ו-Reversim, פרויקטי-הצד.  אז תודה רבה ולהתראות.
[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!