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

פרק מספר 515 של רברס עם פלטפורמה - באמפרס 91. רן תבורי, דותן ואלון מתכנסים לפרק באמפרס עמוס בחדשות טכנולוגיות, AI, שינויים בשוק התעסוקה, כלים חדשים למפתחים, והדילמה הנצחית של "אש או בוץ" בפרויקטים של קוד פתוח. [00:51] השקיעה של Stack Overflow רן פותח עם גרף שמראה את צניחת כמות השאלות הנשאלות ב-Stack Overflow לאורך השנים. האפקט ברור: מרגע שהבוטים שלנו מיצו את התוכן והחלו לתת לנו תשובות מיידיות, הטראפיק לאתר התרסק. דותן מציין שהירידה הכללית החלה עוד קודם, אך קפצה זמנית בתקופת הקורונה. [04:10] כולם מדברים על סקילים עולם סוכני הפיתוח (Agents) לא זז היום בלי סקילים (Skills). מקום מעולה להתחיל בו הוא האתר https://skills.sh/. דוגמה כיפית ושימושית מתוכו: סקיל לספריית Manim (של ערוץ היוטיוב 3Blue1Brown) שמאפשר ליצור אנימציות מתמטיות בקלות. הנה ציוץ הדגמה בטוויטר, והקישור לסקיל עצמו ב-Skills.sh. בעקבות הביקוש, נוצרה ממש תעשייה של מנועי חיפוש וספריות של סקילים: http://skills.sh (למקרה שפספסתם) https://context7.com/ https://skillsmp.com/ ריפו מעניין בגיטהאב: https://github.com/mhattingpete/claude-skills-marketplace [07:44] העתיד של ממשקי המשתמש ו-MCP Apps הסטנדרט החדש, MCP-apps, מאפשר להעביר רכיבי HTML אינטראקטיביים ישירות בתוך MCP (ולא רק טקסט). הפרויקט מובל בין היתר על ידי ליעד ועידו, מי שהקימו בעבר את https://mcpui.dev/. שווה לראות את סרטון ההדגמה ביוטיוב. ליעד השיק לאחרונה כלי מעניין נוסף בשם https://ora.run/ שמאפשר לכם לבדוק עד כמה האתר או הביזנס שלכם מותאם לקריאה על ידי סוכני AI (Agent-Ready). דיון פילוסופי קצר: איך ייראה עתיד ה-UX? חברות ענק כמו סיילספורס (Salesforce) כבר עברו להציע חוויית Headless מלאה שפונה קודם כל לאייג'נטים. [13:35] דונלד קנות', קלוד, והסקפטיות שנשברה פרופסור דונלד קנות' (Donald Knuth), מאבות מדעי המחשב, פרסם לאחרונה מאמר מרתק תחת הכותרת Claude Cycles. המסר המרכזי: קנות' התחיל כסקפטי מוחלט בנוגע ליכולות של כלי AI לכתוב קוד איכותי, אבל לאחר סדרת ניסויים, הוא מודה שהופתע לטובה. [15:52] פלטפורמות ניהול והרצה לאייג'נטים לכתוב סוכן זה קל, להריץ אותו בסביבה מאובטחת בסקייל ללקוחות זה סיפור אחר לגמרי. הפתרון? פלטפורמות Agent Hosting שצצות עכשיו בכל מקום: אנתרופיק (Anthropic) מציעים Managed Agents. גם OpenAI חזק במשחק עם פלטפורמת Frontier. ואמזון (AWS) הציגה את Bedrock AgentCore. [23:14] פיטורי AI ועתיד שוק התעסוקה התעשייה עוברת שינויים כואבים. חברות כמו Block ו-Coinbase מקטינות את מצבת כוח האדם ומצמצמות צוותים כפועל יוצא מהתייעלות מבוססת AI. למרות זאת, נשמעים גם סיפורים על חברות שמעדיפות כרגע לשכור מפתחים ג'וניורים זולים במקום לשלם על עלויות תפעול גבוהות של כלי AI. אז מה העתיד טומן בחובו? אולי לפחות נוכל לתת לרובוט לקפל לנו את הכביסה. [25:54] כלים לטרמינל (ההמלצה של אלון) כשהטרמינל עמוס באייג'נטים שרצים ברקע, כדאי לעשות סדר. אלון ממליץ בחום על https://cmux.com/, כלי טרמינל נוח במיוחד שמבוסס על Ghostty, עם תמיכה בטאבים ורטיקליים שמאוד מקלים על העבודה עם סוכנים מרובים (למרות שרן טוען אצלו זה קצת "התעייף" ונהיה אטי). [31:11] הפריצה לורסל (Vercel) ורסל סבלה לאחרונה מפריצת אבטחה (ההודעה הרשמית כאן), שבמהלכה כנראה דלפו מפתחות (API Keys) של לקוחות ונמכרו ברשת האפלה. אם עדיין לא עשיתם רוטציה למפתחות שלכם שם – זה הזמן. [32:41] פינת הקוד הפתוח של דותן: "אש או בוץ" (🔥 או 💩) דותן מביא רשימה של פרויקטים חדשים בגיטהאב ומסווג אותם לשתי קטגוריות: "בוץ" (💩 - פרויקטים מנופחים מדי, ממוקדי-הייפ שישברו לכם את צורת העבודה) ו"אש" (🔥 - פרויקטים נהדרים ושימושיים): https://github.com/Hmbown/DeepSeek-TUI — 💩 סוכן טרמינל לקידוד המכוון רק ל-DeepSeek. יכול לעניין, אבל כדור בוץ אמיתי. https://github.com/addyosmani/agent-skills — 💩 אוסף של 30,000 כוכבים שאמור ללמד את ה-Agent שלכם לכתוב קוד טוב, אבל בפועל רק מגביל ומסרס את היכולות של המודל. https://github.com/bytedance/deer-flow — 💩 פרויקט ענק של ByteDance לסוכני מחקר לטווח ארוך (Long-horizon). https://github.com/anthropics/financial-services — 🔥 מאגר מרתק של אפליקציות ורפרנסים שאנתרופיק שחררה במיוחד לעולמות הייעוץ והשירותים הפיננסיים. שווה הצצה. https://github.com/cheahjs/free-llm-api-resources — 🔥 רשימה אדירה שנאספה ידנית ומאגדת ממשקי API חינמיים להרצת מודלי שפה. https://github.com/googleworkspace/cli — 🔥 ה-CLI הרשמי של Google Workspace, אידיאלי לאוטומציות ולאייג'נטים שמדברים עם שירותי גוגל. https://github.com/BoundaryML/baml — 💩 שפה או פריימוורק להנדסת פרומפטים. היום פשוט אפשר לתת לקלוד לכתוב לכם את הפונקציה במקום להסתבך עם ספריות נוספות. https://github.com/embassy-rs/embassy — 🔥 פריימוורק אסינכרוני נהדר לפיתוח בעולמות ה-Embedded הכתוב ב-Rust. https://github.com/dani-garcia/vaultwarden — 🔥 שרת קוד פתוח תואם Bitwarden, כתוב גם הוא (כמובן) ב-Rust. https://github.com/reubeno/brush — 🔥🔥 מימוש POSIX/Bash חתיך, בטוח ויעיל שנכתב מחדש ב-Rust. https://github.com/Pumpkin-MC/Pumpkin — 🔥 שרת מיינקראפט סופר יעיל ב-Rust, מושלם להורים שמקבלים משימה "להרים שרת לילד". https://github.com/rtk-ai/rtk — 💩 כלי שאמור לחסוך עשרות אחוזים מהטוקנים שלכם על ידי שינוי הפלט של פקודות טרמינל (כמו Git). מסוכן – כי אתם משנים למודלים את הצורה המוכרת והמקורית שהם אומנו עליה. האזנה נעימה!

פרק מספר 515 של רברס עם פלטפורמה - באמפרס 91. רן תבורי, דותן ואלון מתכנסים לפרק באמפרס עמוס בחדשות טכנולוגיות, AI, שינויים בשוק התעסוקה, כלים חדשים למפתחים, והדילמה הנצחית של "אש או בוץ" בפרויקטים של קוד פתוח. [00:51] השקיעה של Stack Overflow רן פותח עם גרף שמראה את צניחת כמות השאלות הנשאלות ב-Stack Overflow לאורך השנים. האפקט ברור: מרגע שהבוטים שלנו מיצו את התוכן והחלו לתת לנו תשובות מיידיות, הטראפיק לאתר התרסק. דותן מציין שהירידה הכללית החלה עוד קודם, אך קפצה זמנית בתקופת הקורונה. [04:10] כולם מדברים על סקילים עולם סוכני הפיתוח (Agents) לא זז היום בלי סקילים (Skills). מקום מעולה להתחיל בו הוא האתר https://skills.sh/. דוגמה כיפית ושימושית מתוכו: סקיל לספריית Manim (של ערוץ היוטיוב 3Blue1Brown) שמאפשר ליצור אנימציות מתמטיות בקלות. הנה ציוץ הדגמה בטוויטר, והקישור לסקיל עצמו ב-Skills.sh. בעקבות הביקוש, נוצרה ממש תעשייה של מנועי חיפוש וספריות של סקילים: http://skills.sh (למקרה שפספסתם) https://context7.com/ https://skillsmp.com/ ריפו מעניין בגיטהאב: https://github.com/mhattingpete/claude-skills-marketplace [07:44] העתיד של ממשקי המשתמש ו-MCP Apps הסטנדרט החדש, MCP-apps, מאפשר להעביר רכיבי HTML אינטראקטיביים ישירות בתוך MCP (ולא רק טקסט). הפרויקט מובל בין היתר על ידי ליעד ועידו, מי שהקימו בעבר את https://mcpui.dev/. שווה לראות את סרטון ההדגמה ביוטיוב. ליעד השיק לאחרונה כלי מעניין נוסף בשם https://ora.run/ שמאפשר לכם לבדוק עד כמה האתר או הביזנס שלכם מותאם לקריאה על ידי סוכני AI (Agent-Ready). דיון פילוסופי קצר: איך ייראה עתיד ה-UX? חברות ענק כמו סיילספורס (Salesforce) כבר עברו להציע חוויית Headless מלאה שפונה קודם כל לאייג'נטים. [13:35] דונלד קנות', קלוד, והסקפטיות שנשברה פרופסור דונלד קנות' (Donald Knuth), מאבות מדעי המחשב, פרסם לאחרונה מאמר מרתק תחת הכותרת Claude Cycles. המסר המרכזי: קנות' התחיל כסקפטי מוחלט בנוגע ליכולות של כלי AI לכתוב קוד איכותי, אבל לאחר סדרת ניסויים, הוא מודה שהופתע לטובה. [15:52] פלטפורמות ניהול והרצה לאייג'נטים לכתוב סוכן זה קל, להריץ אותו בסביבה מאובטחת בסקייל ללקוחות זה סיפור אחר לגמרי. הפתרון? פלטפורמות Agent Hosting שצצות עכשיו בכל מקום: אנתרופיק (Anthropic) מציעים Managed Agents. גם OpenAI חזק במשחק עם פלטפורמת Frontier. ואמזון (AWS) הציגה את Bedrock AgentCore. [23:14] פיטורי AI ועתיד שוק התעסוקה התעשייה עוברת שינויים כואבים. חברות כמו Block ו-Coinbase מקטינות את מצבת כוח האדם ומצמצמות צוותים כפועל יוצא מהתייעלות מבוססת AI. למרות זאת, נשמעים גם סיפורים על חברות שמעדיפות כרגע לשכור מפתחים ג'וניורים זולים במקום לשלם על עלויות תפעול גבוהות של כלי AI. אז מה העתיד טומן בחובו? אולי לפחות נוכל לתת לרובוט לקפל לנו את הכביסה. [25:54] כלים לטרמינל (ההמלצה של אלון) כשהטרמינל עמוס באייג'נטים שרצים ברקע, כדאי לעשות סדר. אלון ממליץ בחום על https://cmux.com/, כלי טרמינל נוח במיוחד שמבוסס על Ghostty, עם תמיכה בטאבים ורטיקליים שמאוד מקלים על העבודה עם סוכנים מרובים (למרות שרן טוען אצלו זה קצת "התעייף" ונהיה אטי). [31:11] הפריצה לורסל (Vercel) ורסל סבלה לאחרונה מפריצת אבטחה (ההודעה הרשמית כאן), שבמהלכה כנראה דלפו מפתחות (API Keys) של לקוחות ונמכרו ברשת האפלה. אם עדיין לא עשיתם רוטציה למפתחות שלכם שם – זה הזמן. [32:41] פינת הקוד הפתוח של דותן: "אש או בוץ" (🔥 או 💩) דותן מביא רשימה של פרויקטים חדשים בגיטהאב ומסווג אותם לשתי קטגוריות: "בוץ" (💩 - פרויקטים מנופחים מדי, ממוקדי-הייפ שישברו לכם את צורת העבודה) ו"אש" (🔥 - פרויקטים נהדרים ושימושיים): https://github.com/Hmbown/DeepSeek-TUI — 💩 סוכן טרמינל לקידוד המכוון רק ל-DeepSeek. יכול לעניין, אבל כדור בוץ אמיתי. https://github.com/addyosmani/agent-skills — 💩 אוסף של 30,000 כוכבים שאמור ללמד את ה-Agent שלכם לכתוב קוד טוב, אבל בפועל רק מגביל ומסרס את היכולות של המודל. https://github.com/bytedance/deer-flow — 💩 פרויקט ענק של ByteDance לסוכני מחקר לטווח ארוך (Long-horizon). https://github.com/anthropics/financial-services — 🔥 מאגר מרתק של אפליקציות ורפרנסים שאנתרופיק שחררה במיוחד לעולמות הייעוץ והשירותים הפיננסיים. שווה הצצה. https://github.com/cheahjs/free-llm-api-resources — 🔥 רשימה אדירה שנאספה ידנית ומאגדת ממשקי API חינמיים להרצת מודלי שפה. https://github.com/googleworkspace/cli — 🔥 ה-CLI הרשמי של Google Workspace, אידיאלי לאוטומציות ולאייג'נטים שמדברים עם שירותי גוגל. https://github.com/BoundaryML/baml — 💩 שפה או פריימוורק להנדסת פרומפטים. היום פשוט אפשר לתת לקלוד לכתוב לכם את הפונקציה במקום להסתבך עם ספריות נוספות. https://github.com/embassy-rs/embassy — 🔥 פריימוורק אסינכרוני נהדר לפיתוח בעולמות ה-Embedded הכתוב ב-Rust. https://github.com/dani-garcia/vaultwarden — 🔥 שרת קוד פתוח תואם Bitwarden, כתוב גם הוא (כמובן) ב-Rust. https://github.com/reubeno/brush — 🔥🔥 מימוש POSIX/Bash חתיך, בטוח ויעיל שנכתב מחדש ב-Rust. https://github.com/Pumpkin-MC/Pumpkin — 🔥 שרת מיינקראפט סופר יעיל ב-Rust, מושלם להורים שמקבלים משימה "להרים שרת לילד". https://github.com/rtk-ai/rtk — 💩 כלי שאמור לחסוך עשרות אחוזים מהטוקנים שלכם על ידי שינוי הפלט של פקודות טרמינל (כמו Git). מסוכן – כי אתם משנים למודלים את הצורה המוכרת והמקורית שהם אומנו עליה. האזנה נעימה!

פרק מספר 514 של רברס עם פלטפורמה - Attack Analytics. בפרק זה רן ואורי מארחים את ד"ר גיא וייזל, Tech Evangelist בחברת Cato Networks, לשיחה מרתקת על האופן שבו בינה מלאכותית משנה את חוקי המשחק בעולם הסייבר. דיברנו על מודלי AI מתקדמים, כיצד הם מאיצים מתקפות של האקרים אך גם משפרים את יכולות ההגנה, ואיך פרוטוקולים עתיקים יכולים להוות נקודת תורפה מסוכנת לתשתיות פיזיות. [00:00] ל"ג בעומר, כנס רברסים ופתיחת הפרק חג שמח! מקליטים על הדרך למדורה של רבי שמעון. עדכונים לגבי כנס רברסים 2026: אנחנו כבר עובדים במרץ ומגייסים ספונסרים לכנס הקהילתי. אם הארגון שלכם מעוניין לתמוך, מוזמנים לשלוח לנו מייל ל[email protected] (או כל וריאציה אחרת שעובדת לכם). קול קורא (CFP) להגשת הרצאות לכנס ייפתח ממש בקרוב. [01:05] הכירו את ד"ר גיא וייזל ואת חברת Cato Networks גיא משמש כ-Tech Evangelist ב-Cato Networks, תפקיד היושב בתפר שבין קבוצות ה-R&D והמוצר לבין עולם השיווק, החדשנות, ועבודת השטח בעולמות הסייבר וה-AI. קצת על קייטו נטוורקס: החברה, המונה כ-1,800 עובדים (עם מרכז פיתוח גדול בתל אביב), חלוצה בקטגוריית ה-SASE (Secure Access Service Edge). הפלטפורמה מספקת איחוד של רשת ואבטחה כשירות בענן - מעין "כיפת ברזל" לסניפים ומשתמשים של ארגונים ברחבי העולם. במקום להסתמך על ריבוי מוצרי נקודה (Point Solutions), הארגון מקבל תמונה מלאה וקונטקסט רחב על הכל תחת פלטפורמה אחת (הכוללת SD-WAN, DLP, CASB, Zero Trust ועוד). [06:07] עידן ה-"Mytus Moment" והשפעת ה-AI על מתקפות סייבר רן מזכיר מודל מיתולוגי ומתקדם ממשפחת Claude של Anthropic שמסוגל לאתר ולנצל פרצות אבטחה ביעילות מפחידה. גיא מתאר את המצב כ-"The Mytus Moment" – סמן לתעשייה על כניסתם של מודלים מתקדמים (מבית אנתרופיק, OpenAI ואחרים) שמייצרים קפיצת מדרגה בעולם התקיפה (ראו גם: Cato joins OpenAI's Trusted Access for Cyber TAC). מה בעצם משתנה בפועל? מתודולוגיות התקיפה עצמן (Reconnaissance, Lateral Movement) נותרו דומות, אך ה-Scale והמהירות צמחו משמעותית. ה-AI מצמצם את זמן התגובה מגילוי ה-Zero-day ועד לניצול בפועל – משבועות וחודשים לשעות או דקות. במקום סריקות גנריות (כמו של Script Kiddies), סוכני AI יודעים כעת לתפור וקטורי תקיפה מותאמים אישית למטרה ספציפית, ולשרשר חולשות (Vulnerability Chaining) כדי להתקדם ברשת בצורה עצמאית וחכמה. [16:04] כשה-Agents חובשים כובע לבן: איך משנים את תפיסת ההגנה בדיוק כפי שתוקפים נעזרים ב-AI, ארגוני הסייבר חייבים לאמץ Agents הגנתיים כדי להתמודד עם קצב האיומים החדש. מעבר ממנגנונים מבוססי חתימות (Signatures) לזיהוי אנומליות ופעילות דינאמית מבוססת קונטקסט מלא של המשתמש והרשת. שינוי דרמטי במדדי ההצלחה (SLA) של צוותי אבטחה: המיקוד עובר מ-Time to Patch (זמן תיקון החולשה). להתמקדות ב-Time to Protect (זמן ההגנה הרציפה בסביבת הריצה). יש חשיבות גוברת ל-Shift Right (הגנה על ה-Production בזמן אמת) ולא רק ל-Shift Left. מלכודות לסוכני AI: מחקר של קייטו חשף את WebPromptTrap – פרצת Indirect Prompt Injection חדשה שמדגימה כיצד תוקפים יכולים לחטוף סוכני AI דרך תוכן זדוני המוטמע באתרים. [18:04] מתקפות על תשתיות פיזיות: הבעיה עם פרוטוקול Modbus Modbus הוא פרוטוקול תקשורת ותיק (משנת 1979) המשמש לבקרי תעשייה (PLC ו-SCADA), המפעילים תשתיות פיזיות כמו סכרים, מערכות אנרגיה סולארית, משאבות וצנטריפוגות. הפרוטוקול נעדר אבטחה בסיסית או הצפנה, ולמרות זאת, בשל תהליכי מודרניזציה או טעויות אנוש, הוא נחשף לעיתים ישירות לאינטרנט. מחקר של קייטו שבוצע לאורך 3 חודשים חשף שרכיבי Modbus ב-70 מדינות (ביניהן ארה"ב, צרפת ויפן) נמצאים תחת מתקפות אמיתיות. אילו סוגי מתקפות נצפו על ידי המערכות? איסוף מידע (Reconnaissance). מתקפות מניעת שירות (DoS) שנועדו למנוע מהמפעילים לשלוט בבקר. זיהוי סוג המערכת (Fingerprinting). ניסיונות אקטיביים של כתיבה ל-Registers (זיהו מתקפות מתשתית סינית) במטרה לשנות פיזית פעולות של חיישנים ומנועים. שילוב של יכולות ה-Agentic AI – שיודעות לזהות בקר פתוח ולשגר אקספלויט תוך שניות – יחד עם המצב הגיאופוליטי המתוח, הופכים את האיום על תשתיות לאומיות לממשי ומהיר יותר מאי פעם. האזנה נעימה!

פרק מספר 513 של רברס עם פלטפורמה. רן ואורי מארחים את יובל פלג לוי מ-AI21 Labs לשיחה על אחד האתגרים המורכבים והכאובים בעולם ה-AI הארגוני: חילוץ והבנה של קובצי PDF, בדגש על השפה העברית. יובל משתף במחקר מרתק וטריק יצירתי במיוחד שהם פיתחו כדי לגרום למודלים לקרוא עברית בצורה חלקה. [00:00] היכרות ומה עושים ב-AI21 יובל נמצא ב-AI21 כבר כארבע שנים (לפני כן עבד ב-SparkBeyond וב-Ginger Software). ב-AI21 עסק תחילה בסיכומים וב-Pre-training של המודל Jamba, וכיום מתמקד בעולם ה-Agents. המערכת המרכזית עליה עובדים היום בחברה נקראת Maestro, שנועדה לתת שליטה (Controllability) ולהוציא את המקסימום מאייג'נטים מבחינת איכות ועלויות. הקשר ל-PDF: מדובר בבלוק מידע בסיסי בעולם. אם מכניסים לאייג'נט PDF "מורעל" שבו המילה 'רן' מפוענחת כ-'דן', כל ה-Pipeline וההקשר הסמנטי נהרסים. [04:38] למה PDF זה כזה כאב ראש? בניגוד ל-HTML או LaTeX, פורמט PDF הוא נורא לא סמנטי ומתבסס בעיקר על גרפיקה. הפרימיטיבים המרכזיים שם הם שורות מרחפות וגרפיקות וקטוריות. למשל, טבלה היא פשוט אוסף של שורות עם ציור של קווים ביניהן. חבילות מודרניות לקריאת מסמכים (כמו MinerU או Marker) מנסות להרכיב Pipelines שמשלבים מודלים לזיהוי אזורים ויזואליים יחד עם חילוץ מטא-דאטה, אבל זה מורכב. צלילה לעברית: ב-AI21 יצרו דאטה סינתטי וגילו שיש צניחה משמעותית בביצועים (עשרות אחוזים) של כמעט כל המודלים בשוק כשמדובר בעברית, כולל מודלי State of the Art. [15:56] הפתרון: לעבוד על המודל בעיניים מדעני נתונים בדרך כלל בוחרים בין כתיבת חוקים (יוריסטיקות) לבין אימון מודל מאפס עם המון דאטה. ב-AI21 רצו להימנע משני הפתרונות הללו. הרעיון: לקחת מודל שטוב באנגלית, ולגרום לו לחשוב שהוא קורא אנגלית - למרות שהמסמך בעברית. אי אפשר פשוט לתרגם את המילים לאנגלית, כי אורך המילים ישתנה וידרוס אלמנטים גרפיים וגבולות של טבלאות. אי אפשר להמיר את המילים לסתם מספרים או תווים, כי המודל לא מבין הקשר כזה. הפתרון שנבחר: לקחו מילים פופולריות באנגלית ומיפו אותן לגודל התיבה (Bounding Box) שלהן. עבור כל מילה בעברית במסמך, מצאו מילה באנגלית שיש לה בדיוק את אותן מידות פיזיות של גובה ורוחב, והחליפו אותה במסמך (תוך שמירת המיפוי במילון). התוצאה: מסמך PDF מרונדר מחדש, שנראה ויזואלית תקין לחלוטין עם רווחים מדויקים, אבל קריאה שלו באנגלית היא ג'יבריש מוחלט ללא כל משמעות סמנטית. [24:30] מדידות, ביצועים ו-DeepSeek-OCR כדי למדוד את ההצלחה, יצרו דאטה-סט בעברית שתויג ידנית באמצעות Label Studio. השתמשו בפורמט בדיקה מקובל בתעשייה בשם OmniDocBench, המשתמש במדדים כמו Edit Distance לטקסט ו-Tree Edit Distance לטבלאות (שניתן לייצג במבנה עצי כמו HTML). התוצאות: שיפור מרשים בכל המודלים שניסו (קפיצה של כ-7-8 אחוזים במודלים חזקים). הקסם האמיתי הוא במודלים מסוג On-Prem (עבור בנקים או גופים ביטחוניים שלא יכולים להשתמש ב-API חיצוני) - שם השיטה הקפיצה את אחוזי ההצלחה מ-10% ל-50%. כדי לחסוך את זמן העיבוד שדורש הרינדור מחדש של ה-PDF בזמן אמת, AI21 השתמשו בשיטה הזו כדי לאסוף ולייצר מסד נתונים עצום. בעזרתו הם אימנו מודל משקולות מבוסס DeepSeek-OCR שעושה את העבודה בצורה מהירה ויעילה, וגם יודע להתמודד עם מסמכים סרוקים (שאין להם מטא-דאטה להישען עליו). [35:00] מה לגבי שפות אחרות? ערבית: בדקו את השיטה גם על ערבית, וגילו שחלק מהמודלים הגדולים מציגים מדדי ביטחון (Self-Consistency) גבוהים מאוד בערבית ולכן השיטה פחות השפיעה שם, אבל כן עזרה משמעותית במודלים קטנים (Mini/Nano). השערה: מודלים של שפה הם חיות שניזונות ממידע קיים, ופשוט יש הרבה פחות מידע זמין בעברית ברחבי האינטרנט ביחס לשפות אחרות. קריאה נוספת: RTL PDF Parsing — הבלוג של AI21 האזנה נעימה!

פרק מספר 512 (חזקה תשיעית!) של רברס עם פלטפורמה - קרבורטור מספר 40, שהוקלט ב-24 בפברואר 2026. נכון למועד ההקלטה עדיין אין מלחמה [לא התיישן טוב…], ואורי ורן מארחים את הנביא האורח נתי שלום לשיחה, דיונים, וויכוחים ותחזיות (דיסטופיות ברובן) על עולם שבו ה-AI כבר לא רק כותב קוד, אלא מחליף את המציאות כפי שהכרנו אותה. [01:58] "משהו גדול קורה": הניתוח של Matt Shumer בלוג-פוסט של המפתח Matt Shumer, שנקרא Something Big is Happening התפרסם בלא מעט מקומות והיכה גלים. מעבר מסקפטיות מוחלטת ("זה בחיים לא יעבוד") למצב שבו המודל עושה את כל עבודת הקידוד שלו. נתי - מה שמעניין פה זה הניתוח של שוק העבודה, ואיך נראה שוק ה-Hiring כפי שהוא היום. הדיבורים על "הכתובת על הקיר" זה כבר פאסה – "הכתובת היא כבר בכיס כמעט". הנתונים מראים ירידה משמעותית ב-Hiring שהתחילה כבר משנת 2025 ונמשכת לתוך 2026. "זה קורה עכשיו - ועכשיו אתה צריך לבחור באיזה צד אתה נמצא: הצד המרוויח או הצד הנפגע". רן מדגיש שזה לא רק למפתחים – גם עורכי דין ורואי חשבון ובכל שאר המקצועות צריכים להחליט באיזה צד הם. יש כאן (לפחות) שני אספקטים עיקריים - איך אנחנו רואים את שוק התוכנה, ואז זה משפיע על כל שאר שוק העבודה. אורי - אנחנו רואים את ההשפעה מבפנים, בתוך שוק התוכנה. האם ישנן תעשיות שלא מושפעות עדיין, או לפחות לא מרגישות את זה? למשל יוצאי יחידות טכנולוגיות שמאוד מבוקשים בשוק, אבל ארגונים בטחוניים לא יכולים להכניס הרבה מהטכנולוגיות Cutting-edge הללו, לפחות לא בקצב שהן יוצאות. מועמדים כאלה אולי פתאום לא מתאימים בדיוק לעולם שרץ "בחוץ". נתי משתף סיפור אישי/מקצועי על שיר אלגום, שנדחתה ממשרה ב-HR כי לא הכירה מספיק AI, ובתגובה הפכה למומחית שמרצה ב-Amazon. שינוי גישה**:** "העולם השתנה, הבנתי, אני עכשיו באירוע". אורי ונתי מחפשים השוואות למהפכות קודמות, ולא בטוחים אם יש כאלו בדיוק - מעבר משימוש ב-Intellect האנושי כדי לייצר יתרון - למצב בו "ה-Intellect עובר קומודיטיזציה". אין יותר Job security בהייטק המסורתי, וחזרה לכיוון של מקצועות יותר "מסורתיים", פיזיים. [10:17] עידן ה-Agents וה-+Resume נתי - קונספט של "Professional Agents": מומחים כבר לא מוכרים את עצמם כעובדים, אלא כסוכנים, או ככאלה שמתמחים ביצירת סוכנים. סוכן הוא כמו ילד – צריך לגדל אותו ולשכלל אותו, דורש הרבה Nurturing. רן - ספציפית: מדברים על מעצבים, רואי-חשבון - מקצועות ספציפיים, שהם אולי לא חלק מהליבה של החברה, אבל נמצאים בכל חברה. נתי - דוגמא של Marketing: אם מישהו כבר הכין את רוב ה-Workflows מראש, זה משהו שאני מוכר לשלם עליו. אורי מציין שגם בגידול של ילד באיזשהו שלב עוברים ל-Outsourcing יותר ויותר . . . חברות עוברות לתת שירות של סוכן יחד עם "גידול סוכנים" ושכלול שלהם: סוכן + משהו שמתחזק אותו ומתאים אותו לצרכים שלך. הבשורה טובה: יש לאן להתפתח - בכל פעם שחסמי-כניסה יורדים, נפתחים תחומים חדשים אורי ונתי קצת חלוקים על הנקודה, אבל זה דומה למה שהיה בתחילת ימי ה-SaaS, שאולי לא היה קיים אם לא היה Cloud, לפחות לא בקצב וב-Scale, שקודם לכן היה שמור לארגונים מאוד גדולים ולא לסטארטאפים. דוגמא דומה היא Big-Data. נתי אומר שהורדת חסמי-הכניסה תכניס הרבה גורמים חדשים לתחום, לאו דווקא רק מכיוון של מדעי-המחשב. אורי - השוני במהפכה הזו הוא שיש מצב שבו סוכן יכול לייצר סוכן יותר טוב . . . נתי מפריד בין מוצרים "גנריים" - יש את המודלים של Anthropic ו-OpenAI ומשפחות המוצרים הנגזרות וכו' - ובין ה"OpenClaw למיניהם", שהם גרסא פשוטה יותר וזולה יותר, יחד עם קוד-פתוח ומוצרים בסגנון הזה. רן משווה את המאבק בין מודלים גנריים (כמו Anthropic) למודלים פתוחים (כמו OpenClaw) ל-"האנדרואיד לעומת האייפון". נתי מדבר על ראיון העבודה העתידי: "עובדים יבואו עם ה-10X של עצמם": מועמדים לא יבואו עם קורות חיים, אלא עם רזומה פלוס – צוות סוכנים שבנו ושיודעים לשכלל להם את העבודה. בשנה-שנתיים-שלוש הקרובות, אלו שיעשו את הקפיצה ויבנו את הסוכנים וידעו להגיע עם זה לראיון עבודה - זו יכולה להיות הזדמנות לגדול ולהתבסס. אבל - אנחנו לא יודעים כמה ומי הולך להיפגע: "יהיה פה מצב של ירידה לטובת עלייה". [17:03] "אז מה יכול לקרות?": הסינגולריות והמתכנת האחרון רן מעלה את השאלה המפחידה: האם כל הניסיון שצברנו כמפתחים הלך לפח? השנים הקרובות כנראה הולכות להיות מבלבלות, אבל ננסה להסתכל מעבר לזה. האם לא יהיו יותר מתכנתים, כי לא צריך - או שיהיו הרבה יותר מתכנתים והרבה יותר תוכנה, אבל מקצוע התכנות יראה אחרת? נתי חוזה ירידה למען עלייה - אבל בשונה מהמעבר ל-Cloud-Native למשל, שלקח בערך 10 שנים (ולא נגמר…), כאן הקצב הרבה יותר מהיר (התעשייה השתנתה בתוך שנה). זוכרים את "כולם משתמשים ב-AI, אבל לא רואים את ה-ROI"? זה היה בתחילת 2025 . . . מאז הסטטיסטיקות התחילו להשתנות. רן - "אם לפני שנה הייתי נותן ל-Agent משימות קידוד קטנות, ולפעמים זה מצליח ולפעעמים זה לא - היום זה עולם אחר לגמרי". אז יכנסו יותר מעגלי-אוכלוסיה לתחום - אבל הצד השלילי הוא הירידה שלפני: כמות האנשים שדרושים למשימות שיש היום, עד שיווצר ה-Demand החדש, תגרום להרבה אנשים למצוא את עצמם "מחוץ למעגל". מדינות תצטרכנה איכשהו לספוג את הירידה הזו - מימון הכשרות, תקופות הסתגלות וכו' - אחרת זו בדיוק הסביבה למהפכות והתדרדרות למקומות יותר בעייתיים. ולא שהסדר העולמי מסביב שליו ורגוע גם ככה [נתכתב מהממ"ד במהלך מלחמה באירן…]. אורי - כבר רואים התחלה של "כלכלת סיליקון", ומדינות תחילות לחשוב על מאגרי הChip-ים שלהן . . . נתי מזכיר פרק של All-In, שמדבר על תחזיות מאוד אופטימיות, ועל פניו קצת מנותקות - "המון הזדמנויות והכל יהיה בסדר", בזמן שמי שבתחום יודע שזה לא ממש ככה. נראה שב-Silicon Valley יש בעיקר התעלמות - חוגגים בתוך מעגל מאוד מצומצם. נתי מציע לחשוב על זה כמו על קורונה [במובן החיובי…] - נצטרך התערבות חיצונית כדי לעבור את הגל הזה. רן תוהה האם - בדומה לקורונה - גם התקופה הזו גם תיהיה קטליזטור לתאוריות קונספירציה שעוד תבואנה . . . אורי - מצד שני, גם תרבות הפנאי התפתחה מאוד בתקופת הקורונה, אולי שוב מישהו אחר עושה את העבודה ואז יש יותר פנאי? רן - כבר היום, כשאני מפתח, אני מספיק הרבה יותר, בהרבה פחות זמן. אז אנחנו מייצרים הרבה יותר תוכנה . . . אורי - אבל אז ה-bottlenecks עוברים למקומות אחרים. רן - OpenAI הזכירו, לגבי הפיתוח של Codex 5.3 – שהמודל פותח בעזרת גרסאות קודמות של עצמו. "זה בערך By definition הסינגולריות" . . . "אל תצפו שהסינגולריות תקרה ביום אחד בודד" . . . "מי שהיה במהפכה התעשייתית לא יודע שהוא במהפכה התעשייתית". [27:57] חמשת ה-Moats של 2026 נתי - האם נכון לבנות סטארטאפ באי ודאות כזו? מה הסיכוי של סטארטאפ כזה לשרוד? נאמר על רקע שבוע מאוד לא מוצלח למניות חברות ה-SaaS . . . . יש הרבה תגובות-יתר - אבל קורים הרבה דברים באמת מדהימים. נתי מציע 5 נקודות קריטיות ליזמים (סוג של Checklist) שרוצים לשרוד בעולם שבו כל דבר גנרי נמחק (כמו IBM שצנחה כי Anthropic פרסמו בלוג-פוסט על Cobol . . . ): ורטיקליזציה (Verticalization): אל תהיו גנריים. Google ו-Anthropic ו-OpenAI שולטים ביד רמה. תהיו הכי טובים במשהו ספציפי - עריכת דין או חינוך וכו'. שליטה במידע (Proprietary Data): דאטה שה-LLM הגדולים והמודלים הגנריים לא ראו, כמו מגמות ספציפיות בתוך נתוני לקוחות. יעילות (Efficiency): ****שימוש ב-SLM (Small Language Models) למשל, כדי לחסוך ב-Token-ים וב-Latency (קריטי ברובוטיקה וב-Security, למשל). רן - מודל גדול יקבל את ההחלטה הנכונה, אבל אולי מאוחר מדי. חווית משתתמש (UX ייחודי): חווית משתמש שפותרת בעיה נקודתית ונותנת ערך מהיר (Time to Value). ה-Chat של המודלים הגדולים מאוד גנרי. סטארטאפים צריכים להתמקד ביכולת לייצר חוויית משתמש מאוד מותאמת לחווייה נקודתית. רן - האם בכלל עוד יהיה UI (או שהצרכנים הם גם Agents . . . .)? בהקשר של פיקסלים . . . . נתי, אורי - בסוף , אתה רוצה לייצר ערך לאדם. בסוף זה עניין של Time to Value: אני אולי יכול לייצר את זה לבד, השאלה האם לא יותר מהיר ויעיל להשתמש במשהו שמישהו אחר כבר ייצר. ואחרון (אם כי נתי אמר ש "החמישי הוא לא לשידור…") - Disruption**:** ה-Disruption האמיתי הוא לעשות קניבליזציה לקטגוריות ישנות. אפשר לעשות את אותם הדברים שעשינו בעבר, אבל בצורה אחרת לגמרי. הרבה דברים קודמים נעשו בגלל מגבלות של עולם שהוא Pre-Agentic, ועכשיו לא רלוונטיות - מה שמאפשר מודל עסקי אחר לחלוטין. ואז ה-Price-point יכול להיות מאוד שונה מכזה שהוכתב ע"י תעשיות מאוד גדולות ומבנה עלויות מאוד יקר לתפעול. אורי מתזכר את ה-Moats של Warren Buffet, ונתי מספר שהוא לא חושב שפגש חברה אחת שבאמת עושה את כל הדברים הללו, יזמים עדיין לא חושבים ככה. במיוחד בארץ, עדיין מתייחסים מאוד לבידול הטכנולוגי ופחות למובן של UX או מודל עסקי. [39:26] הזרקת DNA ומהלכי ה-M&A החדשים נתי אומר שמשקיעים בהרבה מקרים לא יודעים לנתח הזדמנויות ולעשות Evaluation שלא על סמך טרנד צמיחה של ARR. אורי - עולם ההשקעות לא הולך לכיוון של SaaS, כי מצד אחד יש המון Disruption risk ומצד שני נראה שהצורך במגמת ירידה. נתי - יש כמה סוגי-Exists שונים שמשקיעים מחפשים, מעבר למודל הקלאסי של "תבנה חברה, תגדל איתה, תייצר מספיק כסף . . . .". קנייה של טכנולוגיות ואנשים - חברות צריכות "להזריק לעצמן DNA חדש", ואז מסתכלים על הסטראטאפ לא רק כטכנולוגיה אלא גם כמנוע לטרנספורציה. חברות במצוקה מנסות למצוא אנשים שיעזרו להן לעשות את הטרנספורמציה, לפחות בחלון הזמן הנוכחי (3 שנים בערך). נתי מזכיר דוגמא שעלתה בעבר - Google: לפני שנה כולם הספידו אותם, ואז הם קנו את Character.AI, ובעצם את נועם שזיר (Noam Shazeer) ב-2 ביליון דולר, כי הם הבינו שהם במצוקה. נתי טוען שלחברות במצוקה יהיה מאוד קשה לעשות כזה שינוי רק על ידי צמיחה אורגנית. אורי מדבר על חברות שעושות קניבליזציה-מוצרית לעצמן - מתחרים במוצר המסורתי הקודם שלהן. נתי טוען שבמקרה של Google זה השתלם להם עם Search Generative Experience (SGE). [46:00] סיכום וסגירה רן ממליץ לכולם לקרוא את הבלוג-פוסט של Matt Shumer (או לבקש מ-Agent לתקצר אותו). נתי חותם עם המלצה אופטימית-מעשית: "למדו את עצמכם... תחשבו שאתם באים למקום העבודה הבא שלכם כבר לא אתם-עצמכם... זה רזומה + צוות עובדים שאתם מביאים איתכם, שזה הסוכנים". אורי כבר מכין את הקרקע לפרק הבא: מהפכת ה-Quantum Computing. "שיעורי הבית שלכם יכולים להיות 0, 1 או שניהם ביחד" . . . תודה לעופר על התמלול!

פרק מספר 511 של רברס עם פלטפורמה, שהוקלט ב-18 בינואר 2026. אורי ורן מקליטים בכרכור (הגשומה והקרה) ומארחים את נמרוד וקס - CPO ו-Co-Founder של BigID - שחצה את כביש 6 בגשם זלעפות כדי לדבר על אתגרים טכנולוגיים בעולם המופלא של Data Production ו-Security. 🎗️[00:38] נמרוד, BigID ולמה אנחנו צריכים קטלוג ל-Data?נמרוד - אחד מה-Co-Founders של BigID, ש”עוזרת לארגונים להבין את ה-Data שלהם”.האתגר המרכזי של ארגונים היום הוא שהם אוספים אינסוף מידע (על לקוחות, עובדים, שוק), אבל מתקשים בשלושה דברים עיקריים: להגן עליו, לעמוד ברגולציות (פרטיות), ולהפיק ממנו ערך (למשל לטובת AI).הפתרון של BigID: בניית קטלוג של כל המידע בארגון.סריקת כל המערכות: Unstructured, Structured, Big Data, Cloud Storage, Business Applications . . . וגם אספקטים של Data at Rest & In Motion: מציאת המידע “איפה שהוא לא נמצא”.החברה עושה קלסיפיקציה (Classification) של המידע - שכבה סמנטית של ה-Metadata, ולא רק סמנטיקה: המערכת ממפה את ה-Metadata העסקי (“למה המידע משמש?”), האופרטיבי (“מי ה-Owner? למי יש גישה?”) והטכני.כולל Contextual Metadata - עמודות, שורות, Foreign Keys . . . לחברה יש גם את היכולת לייצר קורלציה ל-Data Subject – כלומר, להבין למי המידע שייך (לאיזה אדם ספציפי הוא מתייחס), שזה הבסיס לעולמות הפרטיות (כמו "הזכות להישכח").מעל הקטלוג הזה, BigID מנגישה אפליקציות - להגן על המידע - Data Access, Governance, Monitoring, Control.כולל היבטים של רגולציה בהגנה על המידע, בעיקר סביב Privacy Management.היום יש גם הרבה אספקטים של רגולציה סביב AI - ואיך להפיק ערך מהמידע הזה.הייחוד של החברה בעולמות ה-AI הוא היכולת לייצר קטלוג של Unstructured Data - שזה היום המקור המרכזי של AI.אם פעם אנשים היו מסתכלים על ה-Snowflake או על ה-Databricks שלהם כדי לעשות אנליזה למידע - היום הם מסתכלים על ה-OneDriveגם כדי למצוא את המידע שהם רוצים - וגם כדי למחוק את המידע שהם לא רוצים.רן - “אם פעם פיצ’רים היו בתוך עמודות ב-Database, היום אני מסתכל פשוט על Unstructured Text” . . . .החברה מאפשרת Secure pipelines ל-AI, ופיצ’רים של Security - גם ב-Design time וגם ב-Runtime - לאפליקציות AI.וגם אפשרות להפיק את המידע הזה החוצה - לספק את ה-Metadata הזה לכל אפליקציה אחרת בארגוןכלי Cataloging לשימושי AI או למטרות Security - העשרה של המידע עם מידע (Metadata . . . ).נמרוד מגיע מרקע של Product Management - ניהל את ה-Identity Management Product Line של CA (היום בתוך Broadcom).ולפני כן רקע טכני - מפתח בתחומים של Security.[05:18] האתגר הטכנולוגי: "אתה לא יכול להגן על מה שאתה לא רואה"רן מעלה את המשפט הידוע: "You can't protect what you can't see" - מה המשמעות מבחינת הלקוחות של BigID? מהם האתגרים הטכניים בייצור של פתרונות עבורם?נמרוד מסביר ש-BigID קמה על מנת לתת לארגונים את ה-Visibility הזה.ארגונים לא יודעים מה יש להם - וגם כשארגונים חושבים שהם יודעים איפה המידע הרגיש שלהם נמצא, בפועל הם טועים.ועל מנת להגן על מידע רגיש, בתור התחלה צריך לדעת איפה הוא - וזה האתגר מספר 1.דוגמא ל-Use Case נפוץ: איזשהו Stream של מידע, לפעמים Structured ולפעמים לא . . . עושים לו Structuring, מביאים אותו ל-Databases של האפליקציות - וחושבים שהוא רק שם.אחד ה-Use Cases הנפוצים זה עולם הבנקאות ו-Wealth Management - המון רגישות לפרטיות של הלקוחות.ארגונים כאלו מנהלים כמויות עצומות של מידע - ואסור שמספרי חשבון ופרטים מזהים יצאו מגבולות ה-Data Lake או ה-"Green Zones" לאיזורים אחרים.גם הדיוק מאוד חשוב - וגם ה-Scale מאוד גבוה.ואלו “עבירות של כלא” . . . .אם המידע דולף, המנכ"ל עלול ללכת לכלא.(רן) מהזוית של המהנדס - איך עושים דבר כזה? זה נשמע כמו RegEx . . . יש מספרי חשבונות בנק וכו’, אז הפתרון הטריויאלי הוא להפעיל איזשהו Regular Expression. אבל המציאות קצת יותר מורכבת . . . . אילו טכנולוגיות אחרות יש?נמרוד מסביר ש-”Regular Expression טוב בערך ל-Email . . . . לכל מה שהוא מעבר ל-Email, זה כבר לא עוזר לך”.הסיבה לכישלון של מערכות DLP (Data Loss Prevention) ישנות היא ההסתמכות על RegEx, שיצרו המון רעש.“זו פשוט לא טכנולוגיה מספיק טובה”.אחת הטכנולוגיות הראשונות ש-BigID יצאה איתה הייתה Correlation, מה שהחברה מכנה Identity Graph.היכולת לעשות Exact Value Matching על מידע שהוא Correlated.איך זה עובד? לוקחים Data ממערכת ה-CRM או ה-HR, ממפים פרופילים של משתמשים, ואז מוצאים את המידע הזה.זה נותן דיוק מאוד גבוה - וגם יכולת לדעת למי המידע שייך.לדוגמא - “מספרי חשבון זה רק רצף של מספרים - RegEx לא יעזור לך”.אם מוצאים רצף מספרים, קשה לדעת אם זה מספר חשבון או סתם מספר - אבל אם הרצף הזה תואם לרשימת הלקוחות מה-CRM – הוודאות גבוהה מאוד.מסתכלים על המסמך כולו, או על Entities בתוכו? גם וגם . . . יש Machine Learning & Deep Learning - שימוש ב-NER (Named Entity Recognition) לחילוץ ישויות.שימוש ב-Document Classifiers כדי לזהות את סוג המסמך (האם זה חוזה העסקה? האם זה NDA? - עושים Deep Learning על כל המסמך), ומזהים על סמך Training קודם.את אותו הדבר עושים גם עם LLM-Based Classification.מאפשר גמישות (גם וגם - או זה או זה, או שניהם)אבל מציב אתגרים חדשים של עלות ומהירות - זה יקר מאוד ואיטי מאוד לסרוק TBs של Data . . . . צריך להתחיל עם כל מיני סוגים של אופטימיזציות.[11:01] סוגיית ה-Scale וה-Cost בעולם ה-LLMרן מציין שגם מודלים "צנועים" זה עדיין “מליארדים של פרמטרים”, וגם הם דורשים GPU ועולים לא מעט כסף. נמרוד מפרט על האסטרטגיה להתמודדות - אחת הטכניקות הראשונות הייתה ב-Small Language Models (SLM): התחילו עם BERT או RoBERTa. זה עבד (ביצועים טובים, עדיין צריך GPU), אבל חייב אימון (Training) על ה-Data של הלקוח – וזה "Big No No" מבחינת אבטחה (ענייני Security ורגולציה) ואופרציה (זמן…).“סיוט אופרטיבי” . . . .השלב הבא הוא LLMs (“מודרניים”): גם מודלים של 50 מיליארד פרמטרים כבר לא דורשים אימון (Pre-trained) ונותנים תוצאות מעולות.“ה-LLM של לפני חודש זה כבר ה-SLM של היום” . . . .והם כבר באים מאומנים.מה לגבי המחיר? פה נכנסת האופציה לעשות אופטימיזציה לסריקה (Full Scan vs. Sampling): רוב פתרונות ה-DSPM (Data Security Posture Management) לא מסוגלים לעשות Full Scan, הם עושים רק דגימה (Sampling מהיר מעל ה-Data).זו הדרך היחידה ל-Cost Effective Brute-force עם LLM . . . .זו אופציה טובה למטרות Security (ו-BigID מאפשרת אותה), אבל נמרוד טוען שזה לא מספיק ל-CISO, שצריך Full Scan.זה טוב בשביל Risk Assessment, אבל לא “פתרון סופי” [הגענו גם לזה…].פה מגיע הפתרון ההיברידי (LLM Augmented):משתמשים בכלים דטרמיניסטיים וזולים (כמו RegExאו NER) כדי לסרוק את הרוב.משתמשים ב-LLM כדי לנקות את ה-False Positives."אתה מקטין בסדר גודל את כמות ה-Findings שאתה צריך לעבור עליהם וצריך לעשות עליהם LLM Classification”.מכוונים את ה-RegEx להיות "רחב" (לתפוס הרבה False Positive), ואז ה-LLM מנקה את השגיאות (גם אם עדיין משאיר קצת FP).אלו ענייני Cost-Effectiveness שצריך לקחת בחשבון.אורי מזכיר שנהוג לחשוב על LLM-ים כ”לא דטרמניסטיים” . . . . איך משתמשים בהם על מנת לקבל משהו דטרמניסטי?נמרוד משתמש במונח “כמה שיותר לא דטרמניסטי” - שהוא עצמו לא דטרמניסטי . . . .באופן כללי, Data Classification זו טכניקה סטטיסטית - אף פעם אין 100% ודאות.כן יודעים להגיע עם LLM לרמות דיוק מאוד גבוהות, יותר מאשר עם RegEx - כשמסתכלים על כל מגוון האפשרויות.יכול להיות שה-LLM ישווה ויטעה - אבל ל-RegEx אין שום אפשרות בכלל לבדוק (למשל - “האם זה לקוח?”).אלו False Positives עם Use Cases מאוד ספציפיים, לעומת שיטות דטרמיניסטיות שמחפשות את המידע הזה.[16:13] סיכונים וחיות אחרות /  " LLM זה ראשי תיבות של לא למחוק"מה קורה עם לקוחות שגם מאמנים מודלים? רן העלה את החשש שמידע שדלף לתוך האימון של המודל "נצרב" בתוך המשקולות של ה-LLM (שזו למעשה “מכונה שיודעת לעשות Compaction מאוד יפה, וזוכרת כמה דברים” . . . ).איך מתמודדים עם מידע בתוך המודל?נמרוד אומר ש”למחוק מידע מ-LLM זו משימה כמעט-בלתי-אפשרית”.יש טכנולוגיות שמתיימרות לעשות את זה, אבל זה מצריך כמות חישוביות כל כך גבוהה, שכבר עדיף לאמן את המודל מחדש.פרקטית, מה שצריך לעשות זה לטפל ב-Pipeline של ה-Data:מניעה (Sanitization)  - “לא להכניס מידע שאתה לא רוצה”, לנקות את ה-Data הלא-רצוי לפני שהוא נכנס ל-Training או ל-RAG.סריקת Vector DBs: להסתכל על ה-Inference Framework.האמבדינג (Embedding) הוא “וקטור של מספרים”, אבל הוא מכיל לרוב גם את ה-Snippet של המידע המקורי עצמו, או לינק ל-Data במקום אחר - BigID יכולים לסרוק את ה-Data הזה (את ה-Vector DB), מזהים וקטורים שמכילים מידע רגיש, ושמים עליהם Label (אם המפתחים לא רוצים למחוק אותם).ואז אפשר להפעיל Access Control: ברגע שהוקטור מסומן כרגיש, אפשר למנוע מהאפליקציה למשוך אותו בשלב בניית התשובה.אורי מציין שראשי התיבות של LLM זה “לא למחוק” . . . . נמרוד - "בתעשייה שלנו, Job Security זה שארגונים לא מוחקים מידע אף פעם".צריך לזכור שהסיכונים הם לא רק זליגה של מידע, אלא באותה מידה גם Insider Threat: חשש שהמידע יחשף בתוך הארגון.ארגונים חוששים שעובדים ישתמשו ב-Microsoft Copilot (או Glean, או Gemini) כדי לשאול "מה המשכרות של ה-CEO, או של החבר שלי?"פעם היינו מוגנים ע"י "Security by Obscurity" (אף אחד לא ידע איפה הקובץ . . .[יש הטוענים ש-SharePoint זו מכונת הצפנה כמעט מושלמת]היום ה-AI מוצא הכל, והפתרון הוא סניטציה בסיסית, ללא קשר ל-AI, אלא ל-Data Access Governance.“לוודא שלאנשים הנכונים יש Access לדברים הנכונים”.[20:38] הגנה בזמן ריצה Runtime Security & Agentsרן שואל על מקרים של שליחת מידע רגיש, (נניח ש)בטעות, למודלים פומביים, כמו -ChatGPT או Gemini. “לא תיארתי לעצמי שדווקא שם יהיה מספר חשבון בנק או פרטים סודיים” . . . אין אפשר להגן מפני טעויות כאלה?אז כאן יש את ה-Runtime - ואפשר לעשות Interception ל-LLM.מעיין Firewall לכל מה שיוצא החוצה ל-LLM  - או נכנס פנימה.יש הרבה חברות שמתחילות להציע את זה היום - לא רק בשביל Data אלא גם עבור כל מיני שירותי Security: מציאת Vulnerabilities ו-Prompt Injections וכל מיני כאלה.ב-BigID מתמקדים ב-Data - גם מניעה של זליגה החוצה וגם ווידוא שהאנשים שנחשפים למידע הם אכן אלו שרשאים לגשת אליו.יש כל מיני שיטות לעשות את זה, כשב-BigID נמרוד מציג גישה של מעיין “AI Firewall” עבור “Home-grown Applications” - שימוש ב-LangChain hooks בשביל “יירוט הפרומפט” (Prompt Interception).אם רוצים להגן גם על Employee Access to AI, טכניקה נפוצה היא Plug-Ins ל-Browser (תוספי דפדפן, Browser Plugins).טכניקה נוספת היא להשתמש ב-API Gateways.כל API Firewall (כמו Congo למשל) מאפשר לעשות Hooking ל-Set של APIs.אפשר גם להתחבר ל-API של ה-Service - מאפשר לעשות את זה “בצורה הכי נקייה”.התממשקות, בדרך כלל ל-Audit Logs של הספקיות (OpenAI/Microsoft), ובאופן הזה חשיפה, דרך API, ל-Prompt.ואז יש יכולת לתת Alert או DDR - Data Discovery & Response.אבל גם Microsoft וגם אחרים נותנים עכשיו APIs שמאפשרים, ממש כמו LangChain, להיות Man in the Middle.רן מציין שבעולם ה-Agent-י זה כבר עוד יותר מורכב: זה כבר לא Copy-Paste אלא Agent ששובר את המשימה לחלקים ועושה Function Callings . . . . ”בלגן שלם”. איך מגינים על זה? כאן הבעיה הופכת לבעיית Identity Management - ו-Agent זו בעיה כזו.ה-Agent פועל בשם המשתמש - משתמש ב-Credentials וב-Identity של המשתמש.האתגר הוא להבדיל בין האדם למכונה - ומה ה-Context  של העבודה.זה יותר מורכב מההבדלה בין Human ל-Non-Human Identities - זה דורש טכניקות מעולמות ה-Fraud Detection: זיהוי אנומליות, מהירות פעולה, ומקור הבקשה.הגבול הוא מאוד לא-חד (Blurred) - יש אדם שמשתמש ב-Agent - וצריך לדעת להבדיל בין פעילות של אדם לפעילות של מכונה.זה לא מדע חדש - אבל פתאום צריך לדעת להפעיל אותו על מקורות מידע ומקורות Compute חדשים.כשאתה ניגש בתור אדם למידע אז יש לך גישה, אבל אם ה-Agent מתחיל להעלות את כל הקוד לשרת בבלארוס – זו כנראה אנומליה שצריך לחסום . . .[27:10] איך מטפלים במה שאתה לא יודע? / גישה חדשה ל-Access Control (דינמי וסמנטי)בכל ענייני ה-Unknown מטפלים בדרך כלל ע”י Anomaly Detection - מזהים Baseline שלהתנהגות, וברגע שיש חריגה אז יודעים לתת התראה.זה יכול להיות דברים טריוויאליים כמו התנהגות של Downloads (כמויות או מיקום) ויכולים להיות דברים יותר מורכבים (בהתאם לסוג הפעולה וסוג המידע). זה דורש Visibility יותר אינטימי ל-Classification של המידע.דבר נוסף הוא נושא ה-Access Controls באופן כללי - עולם ה-Security עד היום נבנה על סמך הגישה המסורתית של ACL (Access Control Lists)בעולמות ה-Agent-יים ובעולמות ה-AI בכלל, הגישה של ACL סטטי נשברת - אגרגציה (Aggregation) של מידע יוצרת רגישות חדשה.מידע שאולי היה לחלוטין לא רגיש כשהוא מבוזר - אבל כשעושים אגרגציה, נוצרים ההקשרים ו-Re-identification של מידע, שהופכת אותו פתאום לרגיש.רן נותן דוגמא: פרט אחד על חולה ב-Yorkshire ופרט אחר על גיל 80+ ב-Yorkshire אולי לא מזהים בנפרד; כל עוד המידע מאוד “רחוק אחד מהשני”, נדרשת “עבודת בלשות”, אבל ה-LLM מחבר אותם בקלות, וזה מוריד את סף התקיפה.הפתרון הוא קלסיפיקציה (Classification) של המידע בזמן אמת (On the fly) - המערכת צריכה לזהות שכרגע המידע הוא "רפואי", ולבדוק האם לאפליקציה/משתמש הספציפי מותר לראות מידע רפואי ברגע זה, ללא קשר למאיזה קובץ הוא הגיע.וזה משנה לגמרי את האופן שבו מנהלים גישה ל-Data - וזה מחייב Controls חדשים ו-Visibility אחר למידע.“סוג של ACL - אבל סמנטי ודינמי, On the fly”: קלסיפיקציה בזמן השימוש במידע, ולא (רק) Static Policies לפיסות מידע לא מחוברות.קצת מזכיר את התהליך שעבר על ה-Firewalls.[31:38] סערת ה-LLM בחברה ותיקהאורי שואל “מחוץ ל-Script” - אנחנו מדברים על חברה ותיקה (BigID), מימי טרום ה-LLM. איך עוברת הטרנספורמציה הזו על החברה?זה תהליך טבעי של חברה ושל אימוץ של טכנולוגיות חדשות.נמרוד משתף ש-BigID לא התחילה מ-RegEx, אלא מטכנולוגיה אלטרנטיבית חדשה ל-Data Classification - ורק אז השלימה את ה-RegEx, “כשהלקוחות רצו משהו מוכר”.“כשהגיעו המודלים של ה-NER וה-Deep Learning אז הכנסנו אותם”.אימוץ ה-LLM בחברה היה תהליך טבעי ומהיר (התחיל בהאקתון), כי קלסיפיקציה מבוססת-LLM זה משהו שקל יותר להטמעה מאשר בניית מודלים של NER מאפס.ומה לגבי Real-time Identification? עולם האיומים השתנה - בהרבה.ה-Core של BigID הוא לא על בסיס Agents (על המכונות) - אלא API-Based, וזה תמיד היה ה-Guideline.גם ל-Activity Monitoring.ההתחלה הייתה עם Data at Rest - ואז נוספו Permissions ל-Data Access Governance.והדבר הבא שלקוחות רצו היה לדעת מי ניגש למידע - אז כל נושא ה-Real-time לא קשור ל-AI, אלא נכנס כחלק מההתפתחות של המוצר.אם כי זה כמובן גם משרת מאוד את כל נושא ה-AI.נמרוד לא בהכרח רואה את BigID נכנסת לבנייה של Gateways ל-AIבידול של BigID מול חברות Firewall (כמו Palo Alto / SentinalOne): חברות ה-Network וה-Endpoint שבונות את ה-Firewalls” “וטבעי להן” לבנות את ה-AI Gateways. ב-BigID פוגשים את זה בתור “האחראים על ה-Data” - וה-Data זה מה שמניע את ה-AI.כל מה שקשור ל-Home-grown AI Applications זה המשך מאוד רציף: AI Product הוא Data Product.היכולת לעשות אגרגציה ועיבוד מאוד מתקדם של מידע.עוד חוזקה היא על ה-Controls שקשורים ב-Data - ההבנה של ה-Context שעובר בתוך ה-Prompt.הכרות יותר אינטימית עם ה-Data והיכולת לדעת האם הוא רגיש.והיכרות עם הרגולציות הרלוונטיות - איזה מידע ניתן לשימוש באיזו אפליקציה: בדומה ל-Privacy, עכשיו זה לכיוון של AI Regulations.[36:59] גיוסים וסיכוםהחברה מונה כ-600 עובדים, מרכז הפיתוח (R&D, Product, Design) נמצא בתל אביב.מגייסים בכל התחומים - גם Product, גם פיתוח, גם Design. הארגון בינלאומי - אבל מובילים את המוצר מהארץ.תודה - ובהצלחה![קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 510 של רברס עם פלטפורמה, שהוקלט ב-6 בינואר 2026. אורי ורן מקליטים בכרכור ומארחים את טל (מאזין ותיק!) מחברת Rhino Federated Computing לשיחה על עולם של חישוב מבוזר, פרטיות רפואית, הצפנות הומומורפיות ונוסטלגיה ל-SETI@home (ולא AI! טוב, גם…). 🎗️לפני הכל - טל הוא מאזין ותיק, אי שם מאזור פרק 300 [מה קורה באמת עם התחזית של נתי על המוצר הצעיר והחדשני Apache Spark?] שהחליט להרים את הכפפה בעקבות הקריאה בכנס האחרון לרעיונות לראיונות. תהיו טל![01:28] טל, Rhino, ומה זה Federated Computing / Learningטל טיאנו-עינת - מתכנת, בוגר 8200, 20 שנה בתעשייה.בעבר CTO ו-Co-Founder, פעמיים עובד מוקדם או בין הראשונים בסטארטאפים, 8 שנים בטכנולוגיה חינוכית.ו-Python Core Developer, ספציפית של CPython [כבוד!]היום מוביל את תחום ה-Backend ב-Rhino Federated Computing.ו-Rhino Federated Computing עוסקת בגדול ב“חישוב מבוזר ומשמר פרטיות”.תכל’ס - מאפשר לעבוד עם כל המידע וכל ה-Data הרב מאוד שקיים היום בעולם.יש המון Data - אבל זה מידע רגיש (רפואי, פיננסי) שצריך להישאר “נעול בכספות”.ועדיין - רוצים להפיק ממנו תובנות.הפוטנציאל משיתוף מידע כזה הוא עצום, וצריך לדעת לעשות את זה בזהירות.בגדול, העולם מלא ב-Data (שליש מהמידע הדיגיטלי הוא רפואי), אבל הוא יושב ב-Silos: אי אפשר להוציא אותו בגלל רגולציה ופרטיות, ולא עושים איתו כמעט שום דבר."אם תשאל חוקרים, כמעט כולם יגידו: 'האתגר הכי גדול שלי זה להגיע ל-Data. הוא יושב שם, אבל לא עושים איתו כלום." הפתרון של Rhino Federated Computing זו פלטפורמה, שמאפשרת להשאיר את ה-Data “במקום הטבעי שלו” (ב-Edge), ולשלוח את הקוד/המודל למחשב מקומי שירוץ עליו ויחזיר רק תוצאות נגזרות - אגרגטיביות (Aggregated) או משקולות (Weights) - שלא חושפות יותר מדי.באופן כללי, Federated Learning (או Federated Computing) מדבר על אוסף של שיטות, טכניקות ואלגוריתמים, שעוזרים להשתמש במידע הזה - אבל לעשות את זה באופן שמשמר פרטיות.[04:32] אז איך עובד הקסם הזה, מהם ה-Use Cases ומי מנהל את גן החיות?זה בדרך כלל תהליך איטרטיבי (Iterative) - מתחילים מנקודת התחלה משותפת של המשקולות ושולחים לכל מיני אתרים שיש בהם את ה-Data.בכל אתר עושים אימון מקומי נפרד - ואז שולחים עדכונים למשקולות (מכל אתר).עושים אגרגציה (Aggregation) של הנתונים המעודכנים - ושוב.רן (בתפקיד הפרקליט השטן): למה לסבך? למה לא לעשות אנונימיזציה (למחוק ת.ז ושם), לשלוח הכל לשרת מרכזי אחד ולאמן שם? נשמע הרבה יותר פשוט . . .טל ציין כמה סיבות - רגולציה: מקשה מאוד . . . . לפעמים החוק פשוט אוסר את זה.בירוקרטיה: צריך לחתום על חוזים להוצאת Data מבית החולים, וזה יכול לקחת חודשים ואפילו שנים (להגדיר למי ספציפית מותר לגעת במה וכו’).וגם אז - זה יהיה עבור פרויקט אחד ספציפי . . . פרטיות: אנונימיזציה זה לא מספיק - הצלבת מידע (Re-identification) היא קלה מדי היום.מקרה לדוגמא - נניח למשל חוקר באיזשהו מוסד רפואי, שלא מעוניין להקים לבד את כל התשתיות האלה (בשום מקרה, וגם לא במקרה הזה…) - וצריך איזשהו Orchestrator שיעבוד עם 5 (או 500) בתי חולים אחרים. מה נוסע לאן? אילו אבטחות (והבטחות) פרטיות יכול אותו חוקר לקבל? “מי מנהל את כל גן החיות הזה?”השאלה היא האם אתה עובד עם Rhino או לא . . . בדרך כלל מתחילים עם כל מיני כלי Open Source ועושים כל מיני חישוביםמגלים כמה זה קשה - ואז מגיעים ל-Rhino . . . ואז נשאלת השאלה - מי מחבר את כל האחרים? איך כל הקהילה נוצרת?לאורי כל זה נשמע כמו “מסיבת מנמ”רים” . . . . צריך להגיע לכל CISO ולכל מנהל מערכות מידע של כל מוסד ולשכנע אותו (ואז לעבור את כל הבדיקות…).טל אמר שההתקנה של ה-Client היא מאוד קלה (“תוך שעה” במקרה מסוים, לעומת “כמה שבועות” אצל מתחרים אחרים).[10:28] אילו חישובים ניתן לעשות? אילו מודלים? מה האלגורתמיקה שרצה?אילו סוגי מודלים הלקוחות בדר”כ רוצים לחשב?כמעט כולם עושים Deep Learning ו-LLM-ים, מכל מיני סוגים וגדלים.עושים Fine Tuning מכל מיני סוגים.רואים גם כאלה שרוצים מודלים “קלאסים” - רגרסיות מסוגים שונים, מודלי-הישרדות למיניהם (בהקשרים רפואיים).מה שיפה זה שבמסגרת של Federated Learning אפשר לאמן את כל הסוגים הללו של המודלים.למשל גם Boosted Trees מסוגים שונים, יש תמיכה מאוד רחבה.וגם אלגוריתמים שהם בכלל לא אימון של מודל - כל מיני אלגוריתמים סטטיסטיים (חלק קיימים וחלק כאלו שהחברה בונה עבור הלקוח).אפילו חישוב של חציון בצורה שהיא מבוזרת ומשמרת-פרטיות זה גם אתגר מורכב.מדובר ב”אולר שוויצרי”, שמחשב גם חציון וגם Deep Learning, למשל - או שיש כאן כלים שונים?יש פה בעצם שני Framework-ים עיקריים שנתמכים עבור Federated Learning - הראשון הוא NVFlare של NVIDIA ו-Flower של Flower Labs [יש שת”פ…].אפשר גם לממש בהם אלגוריתמים סטטיסטיים - אבל זה פחות נפוץ, יותר מורכב.הטכנולוגיה: הכל רץ על Containers. המשתמש שולח Image, הוא רץ מבודד (בלי גישה לרשת או ל-FS, רק ל-Data הספציפי), והתוצאה נשמרת מקומית או נשלחת חזרה (תלוי בפרוטוקול).(אורי) - כל קוד יכול לעבוד “פדרציה” על ידיכם (Rhino) - או שמי שכותב את הקוד צריך לחשוב מראש שהוא הולך “לרוץ Federated” ואז צריך לכתוב את הקוד בצורה אחרת? (רן) אפשר להריץ PyTorch as is, או שצריך התאמות כדי שירוצו “Federated”?במרבית המקרים זה משהו שבין Out-of-the-Box לבין “פשוט מאוד” - המפתחים של ה-Framework-ים “כבר סללו את הדרכים” עבור המודלים הנפוצים (כמו PyTorch או TensorFlow), ואז זה רק “להוסיף כמה שורות”.איך למצוא את ה-Data ולכתוב את המידע שיוצא (למשל משקולות) למקומות הנכונים.רגע, יש פה Double-Latency? אתרים נפרדים, מרחק פיזי, ענייני Orchestration מיבשת אחרת . . . בד”כ, לאמן מודלי Deep Learning זה משהו שדורש הרבה Data והרבה Iterations - אין פה צוואר-בקבוק (לפחות אחד או יותר)?בהחלט יכול להיות - ומעניין לראות אילו Trade-offs אפשר לעשות.יש הרבה פרמטרים שאפשר לשלוט בהם - כמה מידע משתפים? מה אורך האיטרציות? כל כמה זמן עושים עדכון מחדש ו”יישור קו” בין האתרים השונים (לכל פעם יש מחיר).ועדיין - טל אומר ש”לא מצאנו מקרה שזה היה כל כך איטי כך שאי אפשר היה להשיג את מה שרצו”.האם יש איזשהו Sandbox, שעליו אפשר להריץ את האיטרציות המהירות (יחסית) על “משהו לוקאלי” - ואחרי שבטוחים (נגיד ב-80%) שזה מה שאנחנו רוצים, רק אז לקחת את הכל ל-Federated, כדי לחסוך (זמן וכו’)?כן. ב-Rhino בנו כלי  למפתחים, כך שיוכלו לעבוד ממש מקומית (Containerization) ולוודא שכל ההתאמות אכן עובדות.גם בשלב הבא, כשכבר מעלים ומריצים על גבי הפלטפורמה - יש פיצ’ר שמאפשר להריץ את זה ממש Federated, אבל שכל ה-Clients רצים באתר אחד.אפשר להרים מכונה חזקה עם כמה GPUs ולהריץ, כשכל ה-Flow וכל התקשורת מדמים מצב אמיתי - אבל בפועל זה רק באתר אחד או שניים.עם איזה מידע שהמשתמש רוצה - דמה או אמיתי.[18:30] המקרה המוזר של החולה האנונימי בקיבוץ(רן) נניח לדוגמא בית לחולים אחד עם 500 פציינטים, בית חולים שני עם 1000 - ושלישי עם 10 בלבד. כולם רוצים לחקור יחד, אבל לחלקם יש ממש מעט משתמשים (נתונים). האם יש כאן בעיית אנונימיזציה של “קיבוץ קטן”? כולם מכירים את כולם, ואם מישהו מחפש, יכול להיות שמאוד קל לזהות חולה ספציפי?איך עדיין אפשר להשתמש במידע “קטן” יותר?חוסר-איזון בכמויות ה-Data זה תרחיש נפוץ יחסית, ויש אמצעים שונים שניתן להפעיל כדי לשמר פרטיות, בהתאם לסוג החישוב.שימוש ב-K-anonymization: מוודאים שתשובה לא מתבססת על מעט מדי פרטים, ולא מחזירים תשובה אם הקבוצה קטנה מדי (למשל, פחות מ-10 אנשים)."מי הם כל הגברים בני 30-40 ממוצא ספרדי שחלו בשפעת השנה? אם יש פחות מ-10, אל תחזיר תשובה”אפשר לקנפג (Configure) את זה פר-פרויקט.השותפים בפרויקט יכולים לתאם ביניהם ולהחליט להקטין או להגדיל את הקבוע שאיתו עובדים - זה פיצ’ר מאוד חשוב בפלטפורמה, שמאפשר לקבל החלטה, כל מקרה לגופו.(רן) מה לגבי “להמציא Data”? - טל אומר שזה משהו שקורה ויש חברות שמוסיפות מידע סינטטי.בעולמות ש-Rhino עובדת בהם ההעדפה היא למידע אמיתי.“הרעשה מכוונת” - Differential Privacy: הוספת "רעש" (Noise) אקראי מתמטי מכוון ל-Data או למשקולות, כדי למנוע הסקה על פריט בודד.לפי גישה ספציפית של “כמה רעש להוסיף?” - התפלגות וקבוע לעוצמת הרעש (ביחס למידע האמיתי עצמו), כדי להבטיח אינפורמציה על המידע המקורי.ה-”Differential” בשם מתייחס לכוונה למנוע התקפות שעלולת לחשוף מידע ספציפי מדי על הפריט ה-”N+1” במאגר (ע”י הצלבה של תת-קבוצות) - Re-Identification.[25:21] ניקיונות במידע (וקוד) חסרחלק לא קטן מהעבודה מגיע בכלל לפני האימון של המודל - ניקוי, מציאת חריגים . . . Data Cleansing. איך עושים את זה כשה-Data מפוצל בין המון גורמים?בשביל זה צריך פלטפורמה . . . . לפני כן, כל העבודה הזו הייתה מתבצעת בכל אתר בנפרד - לא יעיל, מסורבל, בכל פעם צריך לשלוח גרסא חדשה לכולם כדי שיריצו וישלחו בחזרה . . . כשזה On Platform”, יכול להיות מישהו אחד שעושה את החישוב - ואז הקוד שלו יכול לרוץ בכל האתרים השונים.אפשר לדבג (Debug) מרחוק, לקבל תוצאות והתפלגויות ולתקן במרוכז.אתגר נוסף הוא נורמליזציה בין האתרים השונים - צריך להביא את המידע לאותה “הצורה” - אותן יחידות וכו’נגיד - In 1999, NASA lost the $327 million Mars Climate Orbiter because Lockheed Martin used imperial units while NASA used metric, causing the spacecraft to crash into Mars due to a simple math error]בסוף, בניית ה-Data Pipeline והנרמול זה אחד השימושים הכי נפוצים של הפלטפורמה.הקוד (ולא התוצאה) נשלח בצורה של Container Image - רץ באתר מרוחק, וכמה במקביל.רץ Isolated, ללא גישה למערכת הקבצים, לרשת, למערכת ההפעלה וכו’.רק מקבל גישה לאותו Data ספציפי שנבחר, יכול לכתוב את התוצאות רק למקום מאוד מסויים - והתוצאה נשמרת כ-Data Set חדש באותו מקום שהוא רץ, ונשארת שם (לא נשלחת לשום מקום).אלא אם זה חישוב מבוזר - אז , ניתן לקבל למשל חישוב של ממוצע, תחת הגבלות של Anonymization ו-Privacy.ו-Rhino הוא זה שדואג להעביר את ה-Container, לוודא שהוא רץ במקום מבודד, מעביר רק את מה שמותר ולא את מה שאסור.במקרה של אימון מודל, כן יש Networking מוגבל בכל אתר, כדי שיוכלו להתחבר. יש Orchestrator של ה-Federated Learning, שרץ לרוב אצל Rhino בענן - כולם מתחברים אליו, ואז יש תהליך איטרטיבי (Iterative) שבו כל אחד מה-Clients מחליף מידע עם ה-Orchestrator.בתהליך הזה נשלחים המשקולות - וזה חלק מאותו Training Algorithm: מה נשלח ואיזה Differential Privacy מופעילים.בסוף, המשקולות נשמרים או בענן של Rhino, או באחד מהאתרים שהשתתף בתהליך - בהתאם להגדרות של המשתמש הספציפי.מבחינה טכנולוגית, אפשר לכתוב באיזה Stack שרוצים (כל עוד זה נכנס בתוך Container), או שגם פה יש פרוטוקולים ספציפיים?אז לא רק Python . . . הרבה משתמשים ב-R.כן צריך להתחשב בצריכה של CPU ושל RAM - ואם רוצים לעבוד עם GPU אז זה גם משהו שצריך לוודא ולהגדיר שיהיה זמין בכל אחד מהאתרים.אבל בגדול - כן: כל עוד זה רץ בתוך Container, זה בסדר.[30:20] ענייני Trustהלקוחות צריכים לבטוח ב-Rhino - לוודא שהכל עובד בדיוק לפי הפרוטוקול?במידה מסויימת - יש הרבה מודלים של “עד כמה סומכים ועל מי”.לקוחות יכולים להצפין את הקוד ו/או את המשקולות שלהם - ואז ל-Rhino אין גישה.יש תמיכה שליפה של המפתחות רק מתוך Vault ורק בזמן ריצה, באמצעות Token שהלקוח מספק בצורה מאובטחת.יש שיטות כמו Homomorphic Encryption - ואז גם ה-Orchestrator שעושה את האגרגציה (Aggregation) לא רואה אתהמשקולות עצמם (שהוא עושה להם את האגרגציה…)מדובר בהצפנה ששני הצדדים עושים - ואף אחד מהם לא יכול לקרוא את התוצאה אם אין לו את המפתח של הצד השני.מה שמייחד את ה-Homomorphic Encryption זה שכל אחד מהצדדים, על אף שהוא עובד עם מידע מוצפן, עדיין יכול לבצע עליו חישובים (לרוב מאוד פשוטים - חיבור/חיסור, אולי כפל) - ולהחזיר לצד השני, שיכול לפענח ולקבל את התוצאות של הפעולות.מדובר באוסף של אלגוריתמים מאוד מעניינים מתימטית [להרחבה - נגיד כאן: #47 Fully Homomorphic Encryption | Part 1 | Quantum Algorithms & Cryptography - YouTube][32:08] זכרונות מקצה הגלקסיה / SETI@Homeאורי מזכיר שבתחילת שנות ה-2000 היה פרויקט בשם SETI@Home, שבו אנשים תרמו כוח מחשוב לחיפוש חייזרים [Search for Extraterrestrial Intelligence].גם היום עושים את זה - פשוט ל-Bitcoin  . . . [הי - ?But how does bitcoin actually work]ההבדל: טל מדייק – שם זה היה חישוב מקבילי: החלק של ה-Distributed - כל אחד מחשב משהו נפרד, ואין קשר בין החישובים שמתבצעים באתרים השונים.ב-Federated Learning יש אגרגציה ושיתוף מידע בין הצמתים והמשקולות מהאתרים השונים, כדי לשפר מודל משותף.אז יש חיזרים או אין? [?Where is everyone]ואגב פיצול וענייני Trust - : רן שואל אם יש מערכות שהן ממש Zero Trust, ולא צריך לסמוך על אף אחד (כולם Peers, כמו Bitcoin, ואין Orchestrator)?טל מודה שבעולם ה-Federated Learning כרגע תמיד צריך לסמוך על מישהו (לפחות חלקית), ואין עדיין פתרון קסם של Zero Trust מלא.זה יותר “משחקים של על מי אני סומך ומתי”.[34:25] גיוסים וסיוםאז Rhino היא סטרטאפ בן 5; החברה גייסה לאחרונה 15 מיליון דולר (Round A). מה מחפשים? מפתחי Backend מנוסים, Frontend, DevOps ו-Product. ה-R&D יושב בארץ - בשרונה, תל אביב (הנהלה בבוסטון), 3 ימים בשבוע במשרד.מחפשים אנשים מנוסים שיודעים להתמודד עם Backend מורכב ולא קונבנציונלי - ומספיק ניסיון ב-Python (כי זה ה-Backend).תודה רבה, ובהצלחה.[קישור לקובץ mp3]האזנה נעימה ותודה רבה לעופר פורר על התמלול!

רק מספר 509 של רברס עם פלטפורמה - באמפרס מספר 90, שהוקלט ב-1 בינואר 2026, שנה אזרחית חדשה טובה! רן, דותן ואלון באולפן הוירטואלי (עם Riverside) בסדרה של קצרצרים וחדשות (ולפעמים קצת ישנות) מרחבי האינטרנט: הבלוגים, ה-GitHub-ים, ה-Rust-ים וה-LLM-ים החדשים מהתקופה האחרונה. 🎗️[00:46]  רן - חדשות, מחקרים ומגמותמתקפת הסייבר על Anthropicמתקפת סייבר משמעותית כנגד חברת Anthropic (היוצרים של Claude), שבוצעה ככל הנראה על ידי “גורם מדינתי” [לכאורה עם דגל אדום ורפובליקה עממית . . . ], ב-Scale מאוד גבוה - Disrupting the first reported AI-orchestrated cyber espionage campaign \ Anthropicהשתמשו ב-Claude Code כדי לעקוף את ההגנות והאבטחות השונות.הייחוד במתקפה (מעבר ל-Scale גדול מאוד והגורם המדינתי שמאחוריו, לפחות בהתקפות מתועדות) היה השימוש במודלי שפה (LLMs) כדי לעקוף מנגנוני הגנה (Jailbreaking) ו"אבטחות" של מודלים אחרים.השוואה לאירוע ל"אירוע הצ'ירוקי" [Cherokee] (ההשתלטות מרחוק על הג'יפ - Hackers Remotely Kill a Jeep on the Highway—With Me in It | WIRED), אירוע מכונן שמעיר את התעשייה לסיכוני האבטחה הממשיים ב-AI - אז זה היה אירוע מכונן בתעשיית הסייבר להגנת כלי-רכב. [וכן - כמעט בדיוק שנה מאז האזכור הקודם של הרפרנס - אז ב - 488 Developing with LLMs securely, with Guy from Pillar]מי אמר “Big High-Tech” במקום “Big Pharma”? [אלון, בפניייה נרגשת לספונסרים].מחקר של מכון METR ו"חוק מור" של ה-AI [כאן - Measuring AI Ability to Complete Long Tasks - METR]מחקר של מכון METR [שפגשנו לאחרונה ב-Bumpers 87] מראה גרף אקספוננציאלי של משך הזמן שבו מודלים מסוגלים לבצע משימות בהצלחה (“לסיים בהצלחה משימות ארוכות”).אם ב-2020 מודלים ביצעו משימות של שניות, כיום (עם מודלים כמו GPT-5.1-Codex-Max ו-Claude Opus שכמעט “מחוץ לגרף”) הם מבצעים משימות שנמשכות שעות.זה לא בהכרח זמן ה-Inference (אולי גם), אלא היכולת שלהם לעשות Reasoning יותר ויותר עמוק ולקחת משימות יותר ויותר מורכבות (וגם להצליח בהן).אלון העיר שזהו נראה גמו סוג של "חוק מור [Moore's law] של ה-AI" - אורך המשימות ש-AI יכול לעשות ~מכפיל את עצמו כל כ-7 חודשים .יש עוד מלא פרטים במחקר עצמו, מאוד מעניין.עוד מעולם ה-LLM והשפות - Google Antigravity ומלחמות ה-IDE:גוגל השיקה IDE חדש בשם Antigravity שמבוסס על Gemini 3, מה שמסמן את תחילתה של "מלחמת ה-IDE" (מול VS Code, Cursor ו-Windsurf, לפחות מה שעוד קיים…)[או לפחות את תחילתה המחודשת, מאז 482 Bumpers 84 ו-487 Bumpers 85, ובהמשך ל”מלחמת הדפדפנים החדשה” [?“The Browser strikes back”].יש גם חבר חדש: AWS - Kiroהנה הפוסט - Google Antigravity Blog: introducing-google-antigravityרן ניסה, בעיקר עבור דברים פשוטים וקטנים - נחמד, עובד . . . .אלון ציין שהכלי עדיין לא בשל -Gemini 3 פחות טוב בקידוד לעומת המתחרים, נוטה לקרוס לא מעט ומציג הודעות שגיאה מביכות שמבקשות לעשות Restart ל-IDE.ומצד שני - Google הפתיעו לא מעט לאחרונה עם הכלים שלהם [NotebookLM זה קסם], אז מוקדם להספיד.סיכום שנת 2025 של אנדריי קארפטי (Andrej Karpathy): רן סקר בהרחבה את הנקודות העיקריות -ראשית - RLVR (Reinforcement  Learning from Verified Rewards): טכניקת אימון שהוכחה כיעילה ואפקטיבית מאוד על ידי DeepSeek הסינית [יש מצב שהייתה קיימת לפני], כתחליף/תוספת ל-RLHF.מגמת-שוק של “Cursor for X": מגמה של כלי אוטומציה מבוססי AI לתחומים שאינם פיתוח (כמו צלמים או מארגני אירועים, מספרות וכו’ .נראה ש-Cursor הפך למעיין “מושג” של “עושה משהו טוב -בכללי”, ועכשיו מתחילים לראות את זה גם ב-Domain-ים שהם לא פיתוח.שתי גישות שונות לפיתוח - Local vs. Codex & the Cloud: הדילמה בין הרצת Agent-ים מקומית (שליטה מלאה, כמו Claude Code, Cursor ואחרים, “על ה-Laptop שלכם”) לבין הרצה בענן (תחזוקה לילית, כמו Codex).זו לא בחירה בינארית - בהרבה חברות יש גם וגם, וגם האדון Karpathy לא מחווה את דעתו ספציפית.רן מאמין במודל היברידי: פיתוח “משמעותי” - אקטיבי - ב-Laptop (הוראות ,תיקונים), ותחזוקה שגרתית (Coverage, Maintenance) בלילה ב-Cloud.“תעבור על ה-Code, תמצא Code Smells ותתקן אותם . . . “ - “לא רוצה להיות Hands-on על הדבר הזה, שיודיע לי בבוקר מה הוא עשה" . . . .אלון - הרי בסוף לא יהיה “Human in the Loop”, והכל ירוץ “איפשהו” - ואנחנו פשוט נקבל תוצרים וניהיה כמו מנהלי מוצר [לא מוצא אימוג’י של אלון מצטלב, אבל זה מוקלט, כן?], ונכוון אותו “ימינה, שמאלה” . . . שפות תכנות ישתנו (מי מכיר Assembler?)מיני-ראנט של דותן - “נכנסנו לעולם פנטזיה, ואנחנו שותים מה-Kool-Aid”. . . תוכנה זה קשה, גם לאנשים חזקים.אם טורחים להתעמק בזה (והרוב לא), רואים שהמון Skills הם Conflicting, ומישהו צריך להחליט . . . . רן מדבר על בחירת שפות ותשתית שתתאים ל-LLM (ולא למתכנת, שלא הולך לכתוב כמעט קוד…) - “אז מה אם זה פי-3 שורות קוד?”.אלון - “אל תשאלו מה ה-LLM יכול לעשות בשבילכם, תשאלו מה אתם יכולים לעשות בשביל לעזור לו” . . . . אם אין דוקומנטציה, אין מה לגעת.דותן ממשיך לטעון שזה גל סינוס, או ספירלה - ושכבר היינו שם (היי Visual Basic וה-Drag & Drop - מה עם זה באמת? ועם בית הקברות ע”ש Silverlight . . . .).נתראה במשבר התוכנה הבא, או לכל הפחות בהתערבות Bumpers הראשונה לשנה זו #RemindMeInOneYearוכן, גם כאן DHH מחכה בסיבוב כדי לכתוב את זה From Scratch.תחושת ה"להישאר מאחור": Twit נוסף של Karpathy שעורר גלים, על כך שהוא מרגיש מוצף מכמות הכלים והידע החדש, תחושה שרבים [AKA “אזובי הקיר”] מזדהים איתה.“כלים צצים כפטריות אחרי הגשם” . . . .רן משווה את זה לתקופה שבה כל בוקר היו שלושה Framework-ים חדשים של Frontend, דותן ואלון טוענים שאכן עבור מפתחי FE זה מאוד טבעי (“מה, רק כלי אחד חדש ביום?”) . . . בשנתיים האחרונות נראה שזה קצת עצר - והתחלף בגלים של כלי AI.לא ברור אם אנחנו כבר בשיא ה-Hype, אבל זה לגמרי Hype - וזה ירגע, ונחזור לאיזשהו Steady State.תגובה ספציפית ל-Thread שאלון ודותן מאוד מסכימים איתה - “ה-AI לא החליף מתכנתים - הוא החליף את שפות התכנות” . . . . די מסכם את האירוע.זוכרים את ה-Linux Foundation? אז עכשיו עם Agentic AI!הקמת Foundation חדש תחת ה-Linux Foundation - קבלו את ה-Agentic AI Foundation (AAIF) לריכוז פרויקטי AI אג'נטיים.איזושהי מטרייה רשמית פתוחה, שמגובה ע”י מספר חברות גדולות.שלושת הפרויקטים הראשונים כוללים את MCP (של Anthropic), Goose (של Block - וגם מ-496 Bumpers 86) והפורמט של AGENTS.md (מבית OpenAI).את MCP כולם אולי מכירים [הי - Prepare for the Fragmented Web Revolution / Liad Yosef & Ido Salomon], אבל יש כאן את ההבנה שהוא כבר כל כך Mainstream עד כדי כניסה ל-Linux Foundation.רן סיפר שהוא משתמש ב-Goose לאוטומציה מקומית של הפקת הפודקאסט והבלוג (עוד אחד, לא זה . . . . ).קצת בסגנון של Cursor ושל Claude Code - אבל הסגנון שלו הוא לא רק על כתיבת קוד, אלא על “אוטומציה כללית”.יכול להשתמש באיזה מודל שתרצו, ועושה אחלה עבודה.ועל AGENTS.md יש אייטם בהמשך [גרסת הפודקאסט ל”יש על זה שקף!” . . . .]שינוי תפיסת הפיתוח (Kent Beck)אז כמה זמן לא קראתם את Kent Beck? הנה - Party of One for Code Review! - by Kent Beck.אחד מהוגי הדעות של עולם ה-Software Craftsmanship, התגעגענו.הפוסט טוען ש-Code Review הפך לצוואר בקבוק בעידן ה-AI.אמ;לק - “אנחנו צריכים לחשוב מחדש על כל התהליך של Code Review”.בעולם של LLMs, קצב קריאת הקוד (ע”י אנשים) הפך להיות ה-Bottleneck האמיתי.רן מזדהה (הבעיה אמיתית) - אבל לא אוהב את הפתרון המוצע [בגדול - ניסיון למכור את CodeRabbit, פרסומת מאוד לא סמויה] . . .לדותן יש השגות על אנשים “לא-זקנים-אבל-מותיקי-ומכובדי-התוכנה” [ניסיון להעליב במרוכז את Linus, את Kent Beck ואת Uncle Bob, כי למה לא? . . . ]:בכל פוסט כזה יש גרעין של אמת מאוד נכונה, יחד עם תחזית לא-פופולארית קדימה ששווה לחפש ולהבין.החוויה היא מאוד אישית (בשונה מ-“דיברתי עם אלף מפתחים וזה הממוצע”).בסוף הם גם יתנו רפרנס ל-Sunk-Cost שלהם (“ניסיתי - אבל בסוף אני אוהב את מה שעבדתי איתו קודם”). זו “הגרביטציה” שלהם, זה ה-DNA.ספציפית, הטענה בפוסט הזה היא שהקוד הוא Shared Resource של האדם והמכונה, וצריך להתאים לשני הצדדים.המטריקה היא האם הקוד הוא Manipulable - “האם ניתן לתמרן אותו להראות אחרת?” - וזה KPI ממש מגניב.“עד כמה הקוד הזה הוא בטון או פלסטלינה?” - השאיפה ל”פלסטלינה”, כי תוכנה זה משהו שכל הזמן משתנה וכל הזמן מתעצב.אלון בגישה אחרת לגמרי - לא מאמין במודולריות (ואת Clean Code הרי זנחנו מזמן).העתיד הוא כנראה ויתור על קריאת הקוד ומעבר לבדיקת Interface-ים וטסטים בלבד.כל השאר זה Black Box שלא אכפת לי לשכתב מחדש, כל עוד ה-Interface-ים נכונים, כי עלות כתיבת הקוד מחדש צונחת לאפס, ועלות התחזוקה של מערכת מורכבת היא הרבה יותר גבוהה.“בחצי השנה האחרונה קרה לי הרבה פעמים שעדיף היה פשוט לכתוב הכל מחדש”.לכתוב קוד זה לא ה-Bottleneck - ואנחנו עדיין תקועים עם פרדיגמה שאומרת שכתיבת קוד (“תקתוק”) זה השלב הכי איטי בפיתוח תוכנה, וזה כבר לא נכון.דותן מסכים שזה נכון, תחת שתי הנחות סמויות - שהטסטים נכונים ושה-API נכון . . . . אבל האם מה שאתה מנחה את ה-AI לעשות בכלל נכון מלכתחילה?לא נימנע ממונחים טכניים (“Domain-יים”) ומלמדל טרנזקציות כמו שצריך.אם אתה משחרר גם את זה ל-AI (“בוא תיהיה עכשיו מומחה FinTech” . . . .) - השאלה היא עד כמה הוא יהיה צודק בדבר הזה, ועד כמה תוכל להביא אותו ל-Domain שלך.ה-Business Logic.אלון קורא לחלק הזה “הנדסת תוכנה” - בשונה מכתיבה (קידוד) פרופר; ובכלל - “הכל זה Trade-off-ים”.דותן אומר שבסוף אין גורם מגביל למספר הטעויות שאתה יכול לעשות ככה [כיף במסיבות וכו’] . . . .ואם כבר טעויות (לא אלה) -  Peter Steinberger מדבר על Shipping at Inference-Speedזה ה-Bottleneck שלו - מהירות ה-Inference של המודלים.האיש מעיד על עצמו שהוא עובד על 3-8 פרויקטים במקביל.[הפסקה מתודית - גשו לקרוא מחדש את Critical Chain של אלי גולדרט; צווארי הבקבוק משתנים, אבל העיקרון נשמר].בקצרה - גם הוא כבר לא קורא את הקוד של עצמו ומתמקד רק בהחלטות החשובות, הארכיטקטוניות (השפה, ה-Ecosystem, התלויות ואולי גם הממשקים).את כל השאר - תן ל-Agent לעשות [AKA “דבר עם הסוכן שלי!”].דותן עשה ניסוי על עצמו [שוב] והתחייב לפתח כמה פרויקטים במקביל (כי אפשר) - ומסתבר שזה קשה, מנטלית וקוגניטיבית . . . ההתייחסות של Peter לזה היא שתכל’ס יש בדרך כלל פרויקט אחד שהוא באמת צריך להקדיש לו מאמץ מנטלי, ולשאר בגדול לא.אייטם אחרון של רן (שמוקדש לדותן) - איך Claude Opus 4.5 מייצר MIDI Mixer בערך במצמוץ: One example of something I couldn't believe Claude Opus 4.5 could generate until it did: a full-on MIDI mixer as a terminal app, written in Rust.כן, Rust . . . .הדגמה ליכולת של Claude Opus לייצר אפליקציית Terminal מלאה ב-Rust (מיקסר MIDI) ב-Prompt אחד או שניים, עם “אפס התערבות אנושית”. מרשים.זה לא “One Shot”, אבל 80%~ ב-Prompt אחד - ואז תיקונים . . . .דותן מוסיף ש Terminal UI זה משהו שממש קשה לבנות, ואין הרבה חומר בנושא (לאימון).רן מציין שגם בפוסט הקודם (Shipping at Inference-Speed) מדובר בין השאר על שימוש ב-Cross-Reference (“עלה ספרייה אחת למעלה ותממש את אותו הדבר”).[46:23] דותן - כלים, ספריות ו-Open Sourceפרויקט שנקרא Chatterbox (“אחד הפרויקטים היותר מדהימים שיצא לי לראות בזמן האחרון”)מודל Text-to-Speech ב-Open Source באיכות גבוהה מאוד, שעושה עבודה מטורפת (יש Demo).כולל יכולת Voice Cloning (שיכפול קול) מקובץ אודיו קצר.דותן לא בדק את העברית של זה - אבל הרעיון של לשכפל את ההקלטה הזו נשמע כמו פרויקט מעניין…[ובכלל - עבור עברית, החבר’ה של Ivrit.ai ממשיכים לעשות דברים ממש מגניבים - 485 Ivrit]לחובבי Draw.io - הנה next-ai-draw-ioאינטגרציה של AI בתוך Draw.io (“מישהו הוסיף לזה AI”)זה מאפשר ליצור דיאגרמות ולערוך אותן באמצעות פרומפטים טקסטואליים.יוצר בלוקים, מקשר אותם - ואז אתה יכול לתקן אותו ולערוך ולעשות Fine Tuning.רן בדק את הכלי בלייב ויצר חתול (עם אוזן הפוכה) - מראה ב-Live את כל ה-Reasoning, נחמד.“100% חתול, 90% טוב” . . . .למי ששמע על N8N [אלון אמר על זה משהו מתישהו, לא?] - אז sim הוא “N8N להמונים”זה גם Open Source, אבל בשונה מ-N8N “שצמח מהאוטומציה של פעם” [אי שם לפני ה-AI], זה נבנה “מאפס”.עוד אופציה לחובבי הז’אנר.אלון טוען שה-UX “דומה, אך קצת יותר חמוד”.פרויקט שנקרא pg-aiguide - נועד לעזור ל-Agent-ים לכתוב SQL ולעבוד עם Postgresמגיע מ-timescale - חברה באיזורי ה-Postgres המסחרי.זה פרויקט Open source ואפשר ללכת ולראות מה הם עושים - קיבל המון אהבה מהרשת.דותן טען ש-timescale חברה מעולה, אבל זה קצת “בלון מנופח”.יש פה 4 Skill-ים - 3 מהם כנראה למוצר המסחרי והרביעי הוא איך לעצב טבלה ב-Postgres (הוראות ל-LLM).כשמסתכלים על ה"Skill" הזה, אז אם ה-LLM לא יודע את זה לבד, המצב חמור.והדבר השני שהם עושים זה בגדול  “לשתות את הדוקומנטציה של Postgres” ולחשוף ל-LLM.שובו [כאן] של AGENTS.md מהמערכה הראשונהניסיון לייצר סטנדרט תעשייתי להוראות ל-Coding Agents (בפורמט Markdown) - משהו שנכון מאוד לעשות.מטרתו להחליף את הפורמטים הספציפיים (כמו Cursor Rules) בקובץ אחד סטנדרטי שנמצא ברמת ה-Repo ומסביר לכל Agent איך לעבוד עם הפרויקט.רן ציין בהתחלה שזה אחד הפרויקטים שנכנסו תחת המטרייה של ה- Linux Foundation.לכל אחד מהכלים היה את הפורמט שלו - וזה איזשהו מאמץ “לתכלל את כולם”.ברשימת ה-Adoption יש את כולם - חוץ מ-Claud Code . . . . אפילו Cursor שם.“סיר לחץ” - לכל מי שעוד חושב לפתח פורמט משלו: “אל תשארו בחוץ”.רן מזכיר ש-OpenAI היו ה-Sponsor הראשון שלהם, וכנראה עומדים מאחורי זה.ועכשיו ל - Anthropics Skills - כן - Anthropics. זה נראה כאילו זה לא שלהם - אבל זה כן.מאגר של "כישורים" (Skills) מוכנים ל-Claude (כמו "איך לצייר Processing").בעולם מושלם הם כבר היו חלק מה-Agent ולא היה צריך להוסיף - אם ה-LLM היה לוקח 1000 דוגמאות של Processing, הוא כנראה היה מבין לבד.אלון חושב שה-Skills נכונים - אבל קצת עשו לזה Abuse, ומשתמשים זה לפעולות שאמורות להיות בסיסיות.זה מזכיר לדותן את הדור הראשון של ה-Linters - “חוזרים על אותן טעויות”.רן טוען ש-Skills שימושיים יכנסו בסוף לתוך “הזכרון של ה-LLM” (לתוך המשקולות) - אבל צריך לזכור שזמן אימון של מודלים נמדד בחודשים, אז אם רוצים משהו “עכשיו”, זה שימושי.חוץ מזה, יש את עניין ה-Context Window - וזה שימושי לניהול ה-Context ולמניעת עומס ("Pollution") על ה-Prompt כשלא צריך את ה-Skill הספציפי (או לטעון באופן דינמי).ועוד עניין - ה-Skills עוזרים לעקוף את “הכיווץ הפרמטרי” של המידע שנדחס לתוך המודל הכללי, ונותנים “עוד איזשהו Boost נוסף” ליכולת הספציפית.דותן טוען שבשונה מלמשל AGENTS.md, שיהיה כאן בעוד שנה - Skills אולי לא.רן אומר שה-AGENTS.md יהיה “בשליטתך”, לעומת Skills שיהיו “שקופים” (או כמו שאלון אומר - הם “יבנו דינאמית”).[יאללה - עוד #RemindMeInOneYear]עוד אחד - nocodbאלטרנטיבה ב-Open Source ל-Airtable (בתקופת הטירוף, לפני ש-Notion קצת הוריד להם את זה).נראה אותו דבר, “כל יכול”; אחלה שזה Open Source.אלון מציין שזה מעניין כי זה נראה משהו לא חדש, אלא פרויקט שהתחיל מזמן.דותן אומר שזה אולי ה-Boost שפיתוח עם AI נותן, ופתאום יש אנרגיה לפרויקטים “שהתעייפו”.ול-fumadocs.dev - שזה Yet another Documentation Framework . . . זה Framework לדוקומנטציה עם עיצוב דיפולטיבי מצוין.לא משנה כמה זה יותר או פחות טוב מ-Docusaurus - זה נראה טוב וזה שימושי.ועוד כלי Kanban לניהול פרויקטים - fizzy מבית Basecamp (הי DHH)אז Basecamp יצאו ביוזמה של “Open Source מסוג אחר” - מוצרים מסחריים שהם בונים, אבל הרעיון הוא שהם כל כך טובים, כך שיש רשיון “לעשות מה שאתה רוצה” - חוץ מליצור תוכנה שאתה מוכר . . .מה שחדש פה זה “שזה ישן” - אותו רעיון של Kanban “כמו פעם”, רק Made Simple: בלי פיצ’רים, רק מה שצריך.למי שרוצה לאנדקס את ה-LLM-ים שלו: CocoIndexמנוע אינדקסים High Performance (כתוב ב-Rust) ש”לועס Data” עבור RAG או עבור Vector Databases.דותן לא בטוח מה בדיוק הנישה של זה - אפשר לעשות את אותו הדבר בצורה בסיסית ואלמנטרית, לא באמת חייבים לייצר גרף ולהריץ אותו - אבל נחמד שיהיה.שני פתרונות לאנשים שבונים Agent-ים -אז e2b.dev הוא Open Source אבל גם Hosted, שנותן להריץ Agent-ים ב-Sandbox (נגיד לפתוח Browser או להריץ קוד).הגרסא המסחרית היא סוג של “Pay as you go”.ומשהו מאוד דומה, לפחות בטרנד, זה Trigger.devזה Open Source Platform ל-Background Jobs אם יש לכם AI Jobs של Agents או Processes, ואין לכם את התשתית - אז אפשר להריץ כאןשני הפתרונות שימושיים עבור כל פרויקט תוכנה בגדול - אבל ה-”AI” נותן להם זויות שיווקית מעניינת.[01:07:54] אלון - Cloudflare בוערת ואנימציותתקלת הענק ב-Cloudflare [נגיד זה Cloudflare outage on December 5, 2025]בהמשך לרשומה שרן הוסיף לפני חודש ושברה את הרשת [למקרה שהתבלבלתם עם Cloudflare outage on November 18, 2025] - הפעם נראה שהנפילה של Cloudflare נגרמה בעקבות עדכון אבטחה ל-CVE שקשור ל-React Server Components.הוגדר כ “CVE 10” (הכי גבוה, Critical).נטען שהעדכון גרם לצריכת זיכרון מוגברת שהפילה את ה-WAF (כביכול כי הם ניסוי להגן על הלקוחות שלהם מפני פירצת האבטחה).דותן מריח שני מחנות - נראה (לא באמת, אבל סיפור יפה) שיש "מלחמה פנימית" בתוך Cloudflare בין תומכי Lua (“הדור הישן”) לתומכי Rust (“הדור החדש”), שמתבטאת בפוסט-מורטמים המאשימים את הטכנולוגיות השונות . . . [אם חשבתם שהפיכה באירן מוציאה מאנשים אמוציות].נכון לשעת הקלטת הפרק, ב-2026 עדיין לא נפל האינטרנט [או השלטון באירן, האינטרנט שם דווקא כן] - אבל תתכוננו.חצי-מצחיקול לסיום - sysc-Go (אנימציות לטרמינל ל-Go)ספריית Open Source ב-Go שמאפשרת ליצור אנימציות מרשימות ב-Terminal (אש, גשם, זיקוקים, דינוזאורים . . . ).אלון מציע לשלב את זה בסיום ריצות של Claude Code בתור "חגיגה ויזואלית”. [אפשר גם לסיום פרקים של Bumpers].Fireworksאז זה היה Bumpers 90 - תודה!קישור לקובץ

פרק מספר 508 של רברס עם פלטפורמה, שהוקלט ב-30 בדצמבר 2025, קצת לפני שנגמרה השנה וקצת אחרי שבאמת התחיל סוג של חורף - אורי ורן לוגמים תה ומארחים את מישה פיינשטיין מחברת Bria AI כדי לדבר על איך עושים תמונות בצורה שבאמת התכוונתם (וגם קצת על חורף). 🎗️[01:01] מישה ו-Bria AI(רן) וכן, אורי - למרבה הפתעה, שוב אנחנו מדברים על AI, הנושא החביב עליך . . . .(אורי) AI, הנה . . .  התגעגעתי.(רן) מעולה, אז נתחיל בהצגה שלך, מישה, ושל Bria - ומשם נצלול . . .(מישה) אז אני מישה, כיף להיות פה. בן 38, מתל אביב, נשוי, אב לשובב אחד קטן בן שנה ושמונה.בגדול מתעסק בתחום, כמו הרבה בתעשייה שלנו, מגיל 18. זה כבר 20 שנה, יותר ממחצית-חיים . . . . ובעשר השנים האחרונות מתעסק בכל מה שמתחיל לנוע לכיוון מה שהיום אנחנו קוראים “AI” - זה Machine Learning, Deep Learning, Computer Vision.ובחמש השנים האחרונות Generative AI ב-Bria.שתי מילים אולי על Bria . . . .(אורי) . . . . אולי קצת על מה הרקע שלך ב-Computer Vision?(מישה) זאת סוגיה מעניינת . . . . פורמלית, אין רקע.התחלתי לתכנת בצבא כ”ילד PC”, שזה חבר'ה שמגיעים ללא שום השכלה אקדמית ובעצם מתחילים לתכנת.שם צברתי את הניסיון שלי, באמ״ן.עם השחרור, המשכתי לעבוד ועשיתי תואר ראשון במדעי המחשב ופילוסופיה באוניברסיטה העברית.ואת התואר השני שלי עשיתי גם בפילוסופיה ובפילוסופיה של המדע בתל אביב.(אורי). . .  זה מתחיל להתקרב לדברים המעניינים באמת ב-AI . . . (מישה) זה נכון. אגב, Bria - נגיע לזה אולי בהמשך - יש לה גם את הפן הפילוסופי וקצת על איזה Data אנחנו מאמנים.(אורי) איזה דת או איזה Data?(מישה) איזה Data - ולחוקרים מסוימים זה מתפרש גם כדת . . . (רן)  . . . . האם יש הבדל? זהו . . . (מישה) בדיוק . . . . אז פורמלית, אין לי שום השכלה ב-Computer Vision.פרקטית, בעשר השנים האחרונות אני עובד בחברות שהמהות שלהן, ה-Core שלהן, הוא Computer Vision.ולמרות שהגעתי מהצד ההנדסי, יצא לי ברבות השנים גם לפתח, גם לנהל צוותי חוקרים.אני אוהב לקרוא לעצמי “Practical Researcher”אני עובד עם ה-Common Sense, עם הידיים.לעשות באמת אימון ומחקר אני לא יודע, אבל להוביל את העסק, אני איכשהו . . . . אני מקווה שאני מצליח.(רן) ורק לסיים את ההקדמה - תפקידך ב-Bria?(מישה) אז ב-Bria אני ה-CTO - אני בעצם מוביל את המחקר והפיתוח.אני אולי גם אגיד מה Bria עושה, אני מניח שזה מעניין - Bria (בריאה) בגדול מנסה לייצר עולם שבו...(אורי) “לברוא” . . . . (מישה) לברוא עולם, נכון . . . (אורי) . . . בחדשות היום בוראים מציאות . . . . (מישה) אחדים מבין מאזינינו הבינו, כנראה, שזה מקור השם Bria (בריאה) . . . (מישה) אנחנו מנסים לברוא עולם שבו מה שאנחנו קוראים “Creativity מקצועי”, יכול לפגוש Innovation של AI. אנחנו בעצם מנסים לאפשר לאנשי Creative מהצד היותר מקצועי - בעולמות של Commercial, בעולמות של Media, בעולמות של Marketing שהוא יותר מקצועי - להשתמש ב-Gen AI.תוך כדי זה שאנחנו בעצם מאפשרים לצוותי פיתוח ומוצר של אותן חברות לפתח מעל המודלים שלנו ומעל הפלטפורמה שלנו את המוצרים שיתאימו ל-Use Case-ים שלהם.זה מאוד ב-High-Level, אפשר לצלול לזה קצת.(רן) בעצם רוב הפרק נצלול לזה, אני חושב.[04:44] המקצועיות נכנסת לתמונה / הבעיה בעיני המתכנת(רן) אז כהקדמה, אני אגיד שממש לפני שהגעתי לפה, עזרתי קצת לאשתי עם שיעורי בית באיזשהו קורס שהיא עושה - והיא הייתה צריכה לייצר כמה שקפים כאלה.אמרתי לה “אין בעיה - Nano Banana, עליי! - תני לי את ה-Prompt, משם אני לוקח את זה, משכלל אותו, יוצאת תמונה מקסימה”.ובאמת יצאה תמונה יפה . . .  כמעט אף אחד מהפרטים שהיו בתמונה לא תכננתי. הם הפתיעו אותי, אבל הפתיעו אותי לטובה, וזה נחמד. אז כל עוד אני עושה את זה בשביל הכיף ובשביל התחביב ובשביל איזושהי מצגת חד-פעמית - זה סבבה לגמרי. אבל מה קורה אם אני כן רוצה לשלוט על - לא נאמר “כל פיקסל ופיקסל”, אבל על האובייקטים,על האופי של האובייקטים, על הצבעים, על הפינה השמאלית העליונה, על האמצע, על החיוך של הבן אדם וכל זה? . . . (אורי). . .  שבסוף זה כמו לצייר, נכון? אתה מצייר ב-Prompt, אם אתה צריך על כל פיקסל . . . .(רן) כן . . . .אז זאת אומרת, הכלים - יש שם קודם כל כלי ג'ינרות תמונות (Image Generation) מדהימים, אוקיי? הזכרתי את Nano Banana, ויש לא מעט אחרים. אבל מה שחסר הרבה פעמים זה את השליטה, והזכרת את המקצועיות, אוקיי? ופה אתם נכנסים לתמונה.(מישה) נכון.(רן) אז איך עושים את זה?(מישה) אני חושב, אולי שנייה לפני על איך עושים את זה, אני חושב שנגעת בנקודה מאוד מאוד חשובה - ההבדל בינך, או בין אשתך, באיך שאתם ניגשים לתמונה, לבין איך שמישהו מקצועי ניגש לתמונה, או בכלל לאובייקט ויזואלי, היא העובדה שאתה יודע מה היית רוצה להעביר בתמונה, ואתה מקווה שהמודל יעשה בשבילך את העבודה.אתה אומר “הייתי רוצה תמונה של ילדים משחקים בחוף הים, ואני רוצה שהאווירה תהיה שמחה ותעביר איזשהו מסר אופטימי” . . . (רן) ובגדול “מה שיוצא - אני רוצה”, ואני באמת כבר מרוצה . . . (מישה) זה נכון, זה נכון.(אורי) קרה לי השבוע, בתמונה הראשונה שג'נרטתי (Generated) - אחלה חוויה, הפתעות נעימות, המסר עבר.(מישה) זה נכון - וזה באמת מודל, אמרת נכון: יש המון מודלים בשוק, הם באמת מדהימים. כל המודלים האלה מדהימים.כשאיש מקצוע מגיע לייצר תמונה, הוא עובר תהליך שונה לחלוטין.כשאיש מקצוע חושב על התמונה שלו - הוא יודע בדיוק איך התמונה הזאת נראית.יש לו בראש דימוי של איך התמונה הזאת אמורה לצאת בדיוק.ובעצם האתגר של המודל הוא להצליח to capture את כל הוויזואליזציה (Visual) הזאת שרצה לבן אדם הזה בראש - ולשפוך אותה לתוך המסך.ולא סתם אומרים “תמונה אחת שווה אלף מילים” - מאוד קשה לתאר את מה שיש לבן אדם הזה בראש במילים.(אורי) אבל לאורך זמן מודל יכול להבין את הראש של הבן אדם. זאת אומרת, לקבל יותר ויותר Context . . . .(מישה) אז “להבין את הראש של הבן אדם” זה להבין את סגנון הציור שלו, זה להבין איזה אובייקטים הוא אוהב . . . זה מאוד קשה להבין - וזה לא שונה גם במודל של Bria.זאת אומרת, זה לא שאנחנו קוסמים - מאוד קשה להבין מה זאת התמונה הזאת שיש לבן אדם בראש.בעצם ה-Density של האינפורמציה - ככה אנחנו רואים להסתכל על זה - של תמונה, הוא הרבה יותר צפוף ממה שאפשר לתאר במילים.יש בתמונה המון פרטים שמאוד קשה לתאר.ובעצם אנחנו מנסים איכשהו לגשר על הפער הזה, בעצם בלאמן מודל שלא מתאמן על Prompt-ים של שפה טבעית.הוא לא מתאמן על Prompt-ים של “כלב רץ בים בשקיעה”, אלא מתאמן על structured prompts של JSON-ים ענקיים - שיש בהם באמת אלף מילים, לא כמטאפורה - שמתארים בצורה מאוד מקצועית ובצורה בלתי תלויה אלמנטים שונים בתמונה.תיאור הקומפוזיציה, אובייקטים בתמונת-צבעים שלך . . . (רן) אבל בוא, שנייה לפני שאנחנו . . . זאת אומרת, קצת התחלת לדבר על פתרון - אבל שנייה לפני שאתה מציג אותו,נסביר שוב את הבעיה מעיני המתכנת.אנחנו, כמתכנתים - נורא קל לנו לעשות Vibe Coding ל-Whatever, לא יודע, Tic-Tac-Toe, to do, או whatever, נכון? נורא קל: אתה אומר ל-Cursor, או Whatever, “תעשה לי כזה” - והוא עושה לך כזה. ויכול להיות שאם כל מה שרצית זה לעשות איזשהו POC, אז בזה סיימת.אבל אם יש דרישות מאוד ספציפיות של לקוח, או אם יש איזה שהם Design Rules או Guidelines שאתה צריך לעמוד בהם, או שיש דרישות מוצר שאתה צריך לעמוד בהן - זה לא מספיק רק להגיד לו “תעשה לי Tic-Tac-Toe!”, נכון?פתאום אתה צריך פינות מעוגלות, פתאום אתה צריך, לא יודע, זמן תגובה . . . פתאום אתה צריך יכולת לעשות Pinch ו-Pinch-In ו-Pinch-Out או whatever. זאת אומרת, יש המון דברים שמראש לא אמרת, ואתה, אם היית מפתח, היית, לצורך העניין, Frontend-יסט, היית עושה אותם, כי זה חלק מה-Spec - אבל ב-Vibe Coding זה הולך קצת פחות טוב.עכשיו, כמובן שיש דרך לעשות את זה נכון גם שם, אבל פה אני בעצם מנסה להמחיש בשפת הפיתוח את ההבדל בין“תעשה לי אפליקציה!” לבין “הנה, ככה בדיוק אני רוצה שהאפליקציה הזאת תתנהג - ועכשיו תעשה לי!”. ואת זה אני באמת עושה בצורה שהיא מאוד Structured.(מישה) זה דימוי שאני יכול להתחבר אליו. אני חושב שיש משהו באנשים שעובדים עם Creative, שהופך את זה לאפילו יותר מסובך.בסוף, אנשי תוכנה הם אנשים שבמובנים מסוימים . . .  הם אנשים, בלי להעליב אף אחד, הם אנשים יותר Structured.יש הבניה של איך המקצוע הזה . . .  איך שפות-תכנות נולדו ואיך הן התפתחו ואיך הפורמט שלהן נראה וקומפילציה (Compile) וכל מיני דברים כאלה.אנשים שעובדים ב-Creative זה שונה לחלוטין: הם פשוט חושבים על משהו, יש להם בראש תמונה - “ויתהפך העולם, זה מה שצריך להשיג”.אני יכול לספר סיפור שהיה לנו - פרויקט שעשינו עם במאי הוליוודי מוכר.ועבדנו בעצם עם הצוות לעשות איזשהו קמפיין Marketing לסרט - ל-Beetlejuice Beetlejuice, אם אתם מכירים [נא להשלים את קודם כל את Beetlejuice (1988)].ובעצם כל הצוות, למרות שכל ה-Spec היה מאוד מוגדר - איך אמור להיות הקמפיין ואיזה סגנון והכל - הם כולם היו בחיל ורעדה עד הנקודה שבה צריך ללכת לבמאי ולאשר שזה באמת פגש את הדמיון שלו.ואף אחד לא יודע - כולם היו בטוחים שזה יכול בכל רגע להיות Blocker ו-No Go.(רן) כן . . .  והוא, אני מקווה, אישר? . . . (מישה) כן, לשמחתינו הוא אישר . . . .(אורי) אני חושב אבל שיש משהו, עוד הבדל כזה - למודל שצריך לכתוב את הפיצ'ר הבא, יש Context שהוא כל ה-Codebase. וב-Codebase כבר יש, תכל’ס, את ה-Design System, עם הפינות המעוגלות ועם ה...(רן) כן, זה כמו “תייצר את הסצנה הבאה בסרט שכבר ראית” . . . (אורי) נכון - ורק תגיד לו על מה מדובר בסצנה, והוא ידע את כל ה-Setting בתמונה. בטח שלאיש Creative, שמדמיין את השמש זורחת לו אתה-יודע-מאיפה, זה יותר קשה - זה כל פעם “לברוא את זה מחדש” ולנסות לפגוע.(מישה) זה נכון, ויש  . .  . בעצם, האתגר ש-Bria באה לפתור, חוץ מלתת את השליטה, זה גם לתת את האפשרות לאותו איש Creative מקצוען, ללמד את המודל גם את השפה שלו.ללמד אותו את ה-Structure המיוחד שמעניין אותו.“אותי מעניינת הקומפוזיציה”  . . .(אורי) . . . שזה בעצם ה-Codebase ההיסטורי . . . .(מישה) זאת ההשוואה, כן, זאת ההשוואה.(אורי) אבל כשיש משהו חדש לגמרי? זאת אומרת, עוברים מקמפיין לקמפיין: פעם עשינו קמפיין לסודה, עכשיו אנחנו עושים קמפיין לדבח בשרים [דוגמא מעניינת…], זה שני דברים אחרים.(מישה) אז צריך ללמד את זה, נכון. אז צריך לעשות איזשהו Tunning קטן, ולהתאים את זהלסגנון, לקמפיין, ל-Structure - למה שצריך.[13:13] אימון של מפלצות גדולות / מה זה משנה?(רן) אוקיי, אז ככה: אתה אומר שאם “בעולם החובבני”, כל מה שאנחנו רואים זה איזשהו Prompt טקסטואלי שהוא Unstructured - נגיד, תיאור של החדר, תיאור של האווירה וכל זה - אתם הולכים מראש על משהו שהוא, (1) Structured, ו-(2) מאוד מאוד מפורט.למה זה משנה? כלומר, למה במקרה שלכם יוצא בדיוק מה שהתכוונתי ובמקרים אחרים לא?(מישה) מה שמשנה פה זה לא בזמן הרצת המודל, מה “נותנים למודל” - אלא בעצם איך מאמנים את המודל.ברגע שהמודל התאמן על Data שהוא Structured ו-Data שהוא מאוד Aligned אחד לשני, ובעצם מתאר את הקומפוננטות (Components) השונות הוויזואליות בתמונה, אז המודל, חוץ מללמוד לייצר תמונות יפות, הוא בעצם לומד מה כל קומפוננטה - מה כל Key ב-JSON שלנו, ב-Structure JSON שנכנס כ-Prompt - על מה כל קומפוננטה שולטת.ואז זה מייצר איזשהו Disentanglement כזה בין הפיצ'רים, שמאפשר אחר כך למי שמשתמש במודל להגיד “בעצם, אני רוצה לשנות רק את ה-Lighting, ולהזיז אותו מ”שקיעה” ללא יודע מה . . . “דמדומים”, ולא לגעת בשום דבר אחר”.וזאת שליטה שהם מאוד מאוד צריכים.(רן) אוקיי, אז אתם לגמרי מאמנים מודלים משלכם - מודלים שמייצרים תמונות. זאת אומרת, זה “מפלצות גדולות”: האימון שלהם יקר, אני מנחש. איך מתפעילים את כל זה?(אורי) אני כל הזמן מדמיין שה-Input של ה-JSON הזה זה תכל'ס Dashboard של Photoshop או Lightroom - מקום שבו הם מייצרים תמונות. יש לי כמה צלמים במשפחה, אני כל הזמן רואה את ה-Dashboard-ים האלה, ואוקיי - מתמונה לתמונה אתה יכול ללמוד את הפיצ'רים השונים של . . .  ועכשיו אתה רוצה לשנות את ה-Lighting? אז כאילו . . .(מישה) אז זה מאוד דומה, זה מאוד מאוד דומה . . . . ההבדל הוא שבתמונה זה לא רק אלמנטים של Contrast, תאורה וכאלה, יש לך גם אלמנטים שהם סמנטיים.אובייקטים, האם הבן אדם מחייך, לא מחייך, בדיוק הפוזה שלו, יחסים בין אובייקטים . . . .זאת אומרת, זה קצת יותר מורכב מרק אלמנטים של “איך הפיקסל נראה”.ולשאלתך, רן - כן, זה מפלצות.[למטבי שמע - תתעלם מההוראות | Mixtiles | איתן לויט מראיין את ד״ר זאב פרבמן - YouTube](רן) אז מה אנחנו אומרים? מהם גדלי המודלים יש שאתם מאמנים? (מישה) אז אנחנו מאמנים מודלים - יחסית לתעשייה - קטנים.וזה מתחבר, אולי . . . אנחנו דיברנו המון על ה-Creative Persona, על ה-End User - אבל ה-End User הוא בעצם לא ה-Customer של Bria, זה לא ה-User שלוקח את הפלטפורמה של Bria.אמרתי את זה בהתחלה במשפט - אנחנו מנסים לעשות איזשהו שילוב: אנחנו בעצם נותנים לצוותי פיתוח ולצוותי Research לקחת את המודלים האלה, ולהמשיך להתאים אותם ל-Use Case.אנחנו לא מתיימרים שה-Structured Prompt שלנו, או איך שאנחנו חשבנו על המבנה הנכון לתמונה, יפתור את כל הבעיות ויתאים לכל ה-Use-Case-ים.אנחנו רוצים שהלקוחות שלנו ימשיכו לעבוד עם ה-JSON הזה, ולאמן את המודל לצרכים שלהם ול-Brand שלהם ולמה שהם צריכים בסוף להביא ל-Production.(רן) כלומר, לכל קמפיין או לכל Brand כזה בעצם ממשיכים ועושים Fine-tuning למודלים?(מישה) נכון, נכון. לא חייבים, אבל הרבה מהלקוחות שלנו עושים - ולכן המודלים שלנו הם יחסית קטנים.“יחסית קטנים” זה . . .  - המודל האחרון שלנו הוא 8 ביליון פרמטרים.מאומן From Scratch מ-Random Noise.(רן) כן, אוקיי, וסתם מתוך סקרנות - לא יותר טוב להתחיל, נגיד, ממשהו שכן מאומן? אולי באותו גודל, אבל להרוויח את “הקילומטרים הראשונים” עליו? או שאין כאלה רלוונטיים?(מישה) יש כאלה. יותר טוב - כן; יותר קל - כן; פחות Viable מבחינה Commercial-ית מבחינתנו.(רן) בגלל התוכן, בגלל ה...(מישה) . . . בגלל שאנחנו עובדים בסוף B2B, אנחנו עובדים עם חברות קומרשיאליות (Commercial) גדולות, שצריכות את המודל הנשלט, שצריכות את “המודל הענקי”.אנחנו בעצם מאמנים על Data שהוא לחלוטין נקי - אנחנו לא עושים Scraping לאינטרנט, כל הData שלנו הוא ממאגרים, מפרטנרים, שבעצם נתנו לנו Licensing על ה-Data שלהם.קרוב למיליארד תמונות שהן Licensed - מ-Getty images, מ-Shutterstock ו-envato - כל החבר'ה האלה.וזה מבטיח ללקוחות שלנו לא רק שהמודל מרצה את מה שהם צריכים, אלא שהוא גם לא מייצר דברים שאחר כך יסבכו אותם.(רן) כן, זאת אומרת - זה נותן להם הבטחה רגולטורית משמעותית, שמודלים אחרים לא יכולים.(מישה) זאת גם הבטחה רגולטורית, וזה גם, אם תחשבו על זה, קצת Velocity של פיתוח.בסוף, צוותי פיתוח שלוקחים מודלים שהם, נקרא להם “פרועים”, הם צריכים לשים Guardrails - הם צריכים להשקיע ולוודא שהתוצר לא יוצא מה שאנחנו קוראים בתעשייה שלנו Not Safe for Work.במודל שלנו, במובן מסוים לא צריך - המודל לא יודע לייצר IP של מישהו אחר. פשוט הוא לא ראה אותו אף פעם.[18:39] איך נראה Cycle של אימון כזה?(רן) אז כמה זמן לוקח לאמן מודל כזה, של 8 מיליארד על, אני מניח, מיליארדי תמונות? איך נראה Cycle של אימון כזה?(מישה) אז Cycle של אימון כזה זה משהו שהוא לא בינארי - מאוד קשה להגדיר מה זה “Cycle של אימון”.(רן) כן, איפה שלוקחים את ה- cutoff הראשון או את ה...(מישה) אז בעצם צוות המחקר שלנו - הוא עובד כל הזמן. הוא בעצם במסע מתגלגל כל הזמן לאמן את המודל הבא והמודל היותר-טוב שלנו.וזה מתחיל מתהליכי Onboarding ל-Data של פרטנרים חדשים - לזהות, בעצם לעשות אנליזה על הקטלוג שלנו, לזהות איזה Domain-ים חסרים לנו בקטלוג.אני לא יודע, אם אנחנו פתאום רואים שאנחנו לא מייצרים תמונות מספיק טובות של ציורי-שמן - צריך להביא עוד ציורי-שמן לקטלוג.אז צריך לעשות Onboarding, אנליזה, צריך לעשות Data Preparation . . . בעצם, צריך להכין את כל ה-JSON-ים האלה, שיתאימו לכל התמונות.כל זה הוא בעצם Pre-training כזה, שעוד לפני ש”הדלקנו את ה-GPU” - אולי זה קצת לא נכון, אבל לפני שהדלקנו את ה-GPU הראשון לאימון, יש שם הרבה GPU-ים שעובדים לפני - אבל לפני שהדלקנו את ה-GPU הראשון לאימון.האימון עצמו הוא בעצם אימון שנעשה “בשיטת פירמידה” - אנחנו מאמנים מרזולוציה נמוכה, אנחנו מאמנים קודם כל את המודל ברזולוציה מאוד נמוכה.המודל לומד בשלבים האלה קשרים סמנטיים, קשרים בין ה-Prompt לתמונה, לומד קצת אנטומיה מאוד גסה . . . (רן) כן. רק להבהיר - כשאתה אומר “רזולוציה נמוכה”, אתה פשוט מתכוון לתמונות קטנות.(מישה) נכון, תמונות ב-256-256, ממש Thumbnails כאלה . . .(רן) . . . כדי לראות שהוא מבין קונספטים - את ההקשר בין הטקסט לבין התוצאה הרצויה.(מישה) נכון, ומה שלמדנו בכמה שנים האחרונות שאנחנו מאמנים מודלים, זה שזה שלב מאוד מאוד משמעותי, והוא משמעותי משתי סיבות:הוא משמעותי א' - כי הוא מוזיל מאוד עלויות.זאת אומרת, ככל שמאמנים על רזולוציה יותר נמוכה, אז זה מין הסתם יותר זול.אז אפשר פשוט לעשות הרבה יותר - ובעצם “לסחוט מהמודל” בשלב הזה די הרבה.מה שהפתיע אותנו זה שדי בקלות אפשר בשלב הזה כבר לשים לב ל-Fault-ים במודל - גם דברים שהם מאוד עדינים, כמו דברים שמודלים הרבה פעמים נכשלים בהם, כמו אנטומיה עדינה.למרות שעדיין רואים דברים . . .  לא תראה “אצבעות טובות” ברזולוציה הזאת, בשלב הזה של האימון - אבל אנשים שמאמנים מודלים כבר יודעים לראות, להבדיל בין “אצבעות רעות א'” ל”אצבעות רעות ב'” ולהגיד “אלה לא ישתפרו אף פעם ואלה - אפשר לעשות איתן משהו”.(רן) בסוף יהיו חמש . . . (מישה) בדיוק.אז זה השלב הראשון.(מישה) אחר כך עולים בשיטת פירמידה ל-512 - וגם מצמצמים את סט התמונות.זאת אומרת, עולים גם ברמת הרזולוציה וגם מצמצמים את התמונות לתמונות שהן אסתטית “יותר יפות”.מתחילים מתמונות שהן מאוד . . . זאת אומרת, מראות Variety מאוד גדול של העולם, ולאט לאט מתחילים להתכנס לאסתטיקה.עד שמגיעים ל-1024-2048, ואם רוצים הלאה.ו-All in All זה אימון שלוקח בערך חודש וחצי של 24/7, על Cluster של בין 128 ל-256 GPUs High-Endנקרא להם H200, B200 - כאלה.(רן) כן, שזה גם לא זול  . . . (מישה) זה לא זול, אבל יש משקיעים שתומכים באירוע . . . .[22:11] מי יעריך את המעריך?(רן) אחד הדברים שהזכרת ככה ביעף זה “רואים שזה לא טוב”. עכשיו, אני מניח שאתם לא מסתכלים על כל התמונות,אלא גם יש לכם שיטות לעשות אבליואציה (Evaluation). כלומר, דרך לבוא ולהגיד, קודם כול לצורך האימון עצמוצריך “לשלוח אחורה גרדיאנטים” (Gradients), צריך שמישהו יגדיר איזושהי Loss Function ויגיד “אוקיי, זה טוב, זה לא טוב”.אבל גם יותר בכללי - כלומר, איך מעריכים את זה? אסתטיקה זה משהו מאוד מאוד אישי. האם להגיד “התמונה טובה“ או “הציור יפה”? אתה יודע, אחד יגיד א', השני יגיד ב' . . .  מה עושים בסוף? איך עושים אבליואציה (Evaluation) שהיא, נקרא לזה, קונסיסטנטית (Consistent)? [להרחבה Lenny’s Podcast - Why AI evals are the hottest new skill for product builders | Hamel Husain & Shreya Shankar (creators of the #1 eval course)](אורי) ואיך תמונה של פיקאסו הייתה עוברת את מבחן האנטומיה? . . .(מישה) שאלה טובה . . .  לגבי פיקאסו, אפשר להגיד עליו שהוא מקצוען, אז אולי הוא איזה End User כזה שהיה יכול להשתמש . . .זאת שאלה מעולה. אבליואציה (Evaluation) במודלים כאלה, ובמובן מסוים השיטה ש-Bria עובדת בה קצת עשתה מהפכה באיך שעושים אבליואציה (Evaluation) למודלים האלה.כי בעצם הבאנו לשולחן שיטת אבליואציה (Evaluation) חדשה.אנחנו גם עושים את האבליואציות שכל שאר המודלים עושים - זאת אומרת, אבליואציות, בין אם זה בעזרת Crowd ובין אם זה בעזרת כל מיני מודלים סטטיסטיים על אסתטיקה ועל Prompt Alignment, זה דברים שהם יותר קלאסיים.יש עולמות של Image Arena או Video Arena - כל מיני אתרים כמו Artificial Analysis, שפשוט מעלים לשם מודלים ו-Crowd מצביע, הצבעה בינארית, Blind Test, בין תמונות על איזשהו Preference.אבל זה בעצם, כל השיטות האלה - הן מראות את הפער שבעצם המודל של Bria ניסה לפתור.(מישה) הבעיה בשיטות מדידה האלה, שהן בסוף עושות איזשהו מיצוע ל-Preference מאוד רחב, אנושי.שזה אחלה - ל-B2C, לכל מיני יוצרים מזדמנים כמו אשתך מתחילת השיחה - זה ממש אחלה, יוצאות תמונות ממש ממש יפות.(רן) . . . כלומר, ה-Arena השונות - LMArena  ו-Image Arena וכו’.(מישה) נכון. בסוף, הם ממצעים איזושהי העדפה של הקהל . . . (רן) . . . כן, חוכמת ההמונים, אבל...(מישה) . . . . שהיא אחלה, היא באמת אחלה, באמת יוצאות תמונות מדהימות - Nano Banana, תמונה מדהימה.זה לא מה שהבמאי או ה-Art-Director של הסרט רצה להשיג.הוא לא רוצה את התמונה הגנרית היפה - הוא רוצה את התמונה שיש לו בראש.ולכן אנחנו הגינו איזשהו מדד כזה, שאנחנו קוראים לו  Text-as-a-Bottleneck [Reconstruction] (TaBR).כשבעצם אנחנו אומרים . . . אנחנו לוקחים תמונות אמיתיות - תמונות שקיימות במציאות.אנחנו נותנים ל-LLM-ים שונים לתאר אותן בצורה הכי טובה שישאנחנו אומרים ל-LLM “תתאר כל דבר שאתה יודע על התמונה הזאת”.ואז אנחנו אומרים “זה ה-Prompt שעכשיו ייכנס לכל אחד מהמודלים”.ובעצם, מה שאנחנו רוצים לראות זה השוואה ויזואלית - מרחק, בעצם - בין התמונה שג'ונרטה (Generated) לתמונה המקורית.כשהמודל שג'ינרט (Generated) לא ראה תמונה - הוא ראה רק טקסט, הוא לא קיבל כ-Input את תמונת המקור.(רן) זה קצת מזכיר לי את ה-Cycle-ים שהיו עושים פעם עם Translate - תרגם את הטקסט לאנגלית וחזרה לעברית, תקבל ג'יבריש . . . (מישה) בדיוק - וככל שהתמונה יוצאת “יותר טובה”, או “יותר קרובה”, בעצם, יותר קרובה - אתה יודע שהצלחת.אתה יודע שבהינתן Prompt שהוא מתאר נכון, אתה יודע לשלוט.(אורי) את ה”קרבה” אתם עושים ב”פיקסל לפיקסל”, או . . .  איך אתם מודדים את “המרחק”?(מישה) אז אפשר למדוד את המרחק בהרבה צורות.פה אתה כבר יכול לרדת לכל מיני שיטות שהן . . . אתה יכול לחזור ל-Crowd - שאתה מראה לו שלוש תמונות ואתה אומר “מי יותר דומה לתמונה באמצע?”, נכון?אתה יכול לעשות איזשהו מדד כמו CLIP Similarity, שבעצם יודע להשוות בין תמונות . . .(אורי) אפשר לקחת איזשהו מדד ממוחשב?(מישה) אפשר,לחלוטין. CLIPScore יכול לעבוד פה, יש מדדים אחרים גם.אבל דרך המדידה במובן הזה היא קצת פחות חשובה - מה שיותר חשוב זה מה מודדים.וזו הפעם הראשונה שלא מודדים עד כמה הטקסט משתקף בתמונה, וגם לא מודדים עד כמה התמונה “יפה” בעיני רוב הקהל.(רן) כן, זה בדרך כלל ב-Unsupervised זה נקרא שגיאת ה-Reconstruction. זאת אומרת, עד כמה אתה יכול לשחזר את ה-Artifact המקורי.(מישה) כן, בדיוק.(רן) וזה דומה? זאת אומרת, אם אתה מסתכל על תמונות כאלה, אתה יכול להבדיל בין המקור לבין הלא?(מישה) אתה תמיד יכול להבדיל בין המקור ללא . . . .(מישה) המקומות שבהם אתה ממש יכול לראות את ההבדל, זה דברים שפשוט שום תיאור טקסטואלי לא יכול לתאר, שזה זהות של בן אדם.בסוף, זה יהיה בן אדם שכל הפרמטרים שלו הם אותו דבר - אבל הפנים הן לא אותן פנים.מה שכן רואים זה שבמודל של Bria, ב-Fibo - לעומת המודלים המובילים בשוק, Nano Banana, FLUX, Qwen, כל החבר'ה האלה - התמונה פשוט יוצאת אותו דבר בכל דבר שהוא לא ID, לעומת המודלים ההם, שנותנים איזושהי אווירה כוללת שהיא מאוד מאוד דומה, אבל התמונה היא לא אותה תמונה.(רן) כן, זאת אומרת, אתה יודע - במנועי שפה יש את הטמפרטורה, שיכולה לשלוט על ה - נקרא לזה, “יצירתיות” או “אקראיות” של ה-Output. אז נשמע כאילו אצלכם “כיוונתם את הטמפרטורה לאפס”, או לא זוכר, אולי אחד זה המספר שלא נותן חופש - ובמודלים אחרים הטמפרטורה היא יותר גבוהה, כלומר, יש יותר חופש. ולכן, אולי הם עושים דברים מאוד יפים, אבל לא בדיוק מה שה-Prompt התכוון.(מישה) אז זה קצת יותר מורכב מזה.יש Gap שלא דיברנו עליו בעצם, וזה העובדה שאנחנו התאמנו על JSON-ים שהם בני אלף מילים.בסוף, כשבן אדם בא לכתוב Prompt, הוא לא כותב JSON.המתכנתים, בוני המערכות, כן יכולים מאוד בקלות להשתמש ב-JSON-ים, ולהעביר אותם ולעשות מניפולציות מאוד בקלות.זה חלק מהסיבה שעשינו פורמט שהוא ידידותי למפתחים.אבל בסוף, ה-End User שרוצה לייצר תמונה - הוא לא כותב JSON.המודל שלנו בעצם בנוי משני מודלים בפנים. אנחנו יכולים לחשוב על זה כמודל אחד שהוא ה-Reasoner ומודל אחד שהוא ה-Renderer.יש מודל שלוקח את השפה הטבעית שהבן אדם כתב, ממיר אותה ל-JSON - ובהינתן ה-JSON הזה יש לנו Renderer, שיודע לקרוא אותו ומאוד במדויק להפוך אותו לתמונה.כשאתה מדבר על זה ש”הטמפרטורה היא 0” - הטמפרטורה היא 0 בעצם אצל ה-Renderer.אבל ה-Reasoner עדיין מאוד חופשי ללעשות JSON-ים שונים, אם לא הגדרת לו במדויק ב-Prompt שלך דברים שהוא כן רצה לראות ב-JSON.מה שחשוב זה שמרגע שנוצר ה-JSON, אתה יכול להמשיך לכתוב Prompt-ים ולשנות אותם ויצאו JSON-ים שונים, או להכניס Seed-ים שונים ולהמשיך לעבוד ככה.אבל בעצם מה שאתה יכול לעשות בצורה שונה, זה שאתה בעצם יכול לעשות עכשיו, בהינתן JSON, בעצם חוזרת לך מהמודל לא רק תמונה - חוזר לך JSON ותמונה.ואתה יכול עכשיו לעשות מניפולציות על ה-JSON - אתה לא חייב ללכת ולהמשיך “לעשות רולטה” על ה-Prompt שלך, אתה יכול ממש...(רן) . . . את ה-Reasoning, אתה לא חייב לחזור אליו . . . (מישה) כן . . . אם בגדול התמונה Makes sense ואתה רוצה להמשיך - אנחנו קוראים לזה “to refine” - אז אתה משנה עכשיו רק את התאורה, אתה משנה רק את האובייקט, אתה מוסיף אובייקט, אתה מוריד אובייקט . . . אבל זה כבר אלמנט מתקדם.(רן) אבל לכל אספקט כזה - נגיד גוון השמש או זווית הקרניים - לכל אספקט כזה יש Entry ב-JSON? זאת אומרת, איך אתה באמת שולט על זה?(מישה) אז אנחנו בעצם קבענו מה ה-Entries שיש ב-JSON, קבענו איזשהו סט.ישבנו עם חבר'ה שהם מה שאנחנו קוראים להם “Professional Creatives”, קבענו את Set ה-Entries לגרסה הראשונה שלנו, שאנחנו מאמינים שמתאר טוב תמונה.אני אעשה Spoiler - אני אגיד שבינואר יצא ה-Version הבא שלנו, המודל הבא.(רן) “ינואר” זה “היום”, כשמשתחררת ההקלטה . . .(מישה) אז רוצו לחנויות הקרובות לביתכם . . . סתם. (מישה) ושם [ב-Version הבא] יהיו יותר.אתה נוגע בנקודה, בעיניי, החשובה פה - זה שבסוף אנחנו לא יודעים להגיד מה כל ה-Entries שצריך לכל Use case.אנחנו נותנים את ה-Entries הגנריים, שאנחנו מאמינים שהם חשובים לתמונות באופן כללי.(רן) כמה אנחנו מדברים - מאות? אלפים? זאת אומרת, כמה יש לכם?(מישה) זה עשרות Entries - מקוננות. מקוננים? לא יודע איך אומרים, אבל דברים ש...זאת אומרת, הדברים גנריים: אובייקט, לכל אובייקט מה הטקסטורה, מה ה-Relations לאובייקט אחר, מיקום בתמונה, Structure . . . . אם זה בן אדם אז “פוזה”, לא יודע, “צבע” וכן הלאה.[31:22] הרבה דרכים לתאר (את אותה) תמונה / Uncanny Valley(רן) עכשיו, אני מניח - לא יודע אם זה מעניין, אבל סתם ככה “משחק מנטלי” - אני מניח שתמונה מסוימת, יש הרבה דרכים לתאר אותה באותו JSON. לצורך העניין: “את האובייקט תשים בתור ה-Entry הראשון או בתור ה-Entry העשירי, ואת היחס שלו תתאר . . . “, “א' מתייחס לב' או ב' מתייחס לא’” - כאילו, א' לפני ב' או ב' אחרי א'.זאת אומרת, אני מניח שה-JSON הזה הוא לא קנוני, בסופו של דבר.(אורי) שתי הרצות על אותו JSON - תייצר את אותה ההתמונה?(מישה) בגדול - כן.(רן) כן, אבל מה שאני אומר זה שיש כנראה מספר JSON-ים - כנראה אינסופי או אולי סופי, אבל די הרבה - שיכולים לתאר את אותה תמונה.(מישה) בגדול כנראה שאתה צודק.(רן) . . . אבל לא מעניין . . . (מישה) זה גם קצת פחות מעניין - אבל גם הסדר באמת בתוך ה-JSON הוא לא מעניין.הסדר - היחס בין האובייקטים - הוא מבוטל.זאת אומרת, כל אובייקט מייצר את היחסים לשאר האובייקטים - ואז אובייקט א' יגיד “אני מעל אובייקט ב'”, ולאובייקט ב' יהיה רשום “אני מתחת לאובייקט א'”, ולכן הסדר באמת ב-JSON לא משנה.אבל לכל אחד מהם יש את כל התיאור שהוא צריך על ה-Context.(רן) כן, זה גרף מכוון מלא.(מישה) בדיוק.(אורי) יש לי שאלה שהתחבטתי בה . . . אני עוד לא יודע את התשובה - והנה יש לנו מומחי Image-ים ב-AI!“עמק המוזרויות” - היה לנו פעם פודקאסט על זה, נכון? (רן) לא - אבל לדעתי לרן לוי היה [בול - [עושים היסטוריה] 257: עמק המוזרוּת – או, מדוע אנחנו מפחדים מאנדרואידים](אורי) כן.(רן) תזכיר רגע - מה זה?(אורי) היה פעם . . .  היה פעם? אני לא יודע, אולי עוד יש - כל Avatar, שמיוצר מלאכותית וכו’ - עין אנושית שתסתכל על הדבר הזה, לא משנה כמה טוב תהיה, תבחין שזה מלאכותי. [הי ארנולד](רן) כן. הם אומרים בגדול - אם זה לא נראה אמיתי, אז בסדר, אז מבינים: זה אנימציה, זאת אומרת, זה לא משהו אמיתי.אם זה נראה כמו אמיתי, אבל משהו פה קצת מוזר - אם זה זווית העין, אם זה הליכה קצת מוזרה, אם זה איזשהו Artifact קטן שהוא לא Perfect - אז שם אתה נמצא ב”עמק המוזרות”, כך קראו לזה.(מישה) Uncanny Valley(רן) כן - ולאנשים זה ייראה מוזר. אוקיי, אז מה השאלה?(אורי) הגענו למצב שה-AI כבר פותר את הבעיה הזאת?(מישה) אני מאמין שכן - לא קשור ל-Bria.אני חושב שיש היום בהמון תעשיות, בהמון Use Case-ים, אנשים שמשתמשים בתמונות ג'נרטיביות (Generated) לחלוטין - לא רק בתמונות, גם בסרטים -ואני חושב שאנחנו מעבר לנקודה הזאת.אני חושב שיש . . . . אולי יש מקצוענים שיודעים לזהות.בוודאות יש מערכות שיודעות לזהות.אני חושב שרוב האנשים כבר לא מזהים, בטח במודלים הטובים.אני כן אגיד שקצת נוצרה תופעה הפוכה - חברות התחילו לסמן שתמונות הן מג’ונרטות (AI Generated).(מישה) Bria הייתה מהחלוצות בתחום הזה - זה חלק מזה שאנחנו גם מאמנים על Data שהוא Licensed.אבל אנחנו לא מנסים “לעבוד” על הקהל שלנו, אנחנו לא מנסים להגיד שהתמונה היא אותנטית.אנחנו ממש מסמנים היא ג'ונרטה על ידי AI, וזה סטנדרט שתופס מאוד חזק.גם Google כבר עושים את זה, גם OpenAI עושים את זה.(רן) כן, Nano Banana שם כזה “יהלום” בצד ימין למטה, את האייקון שלהם.(מישה) היהלום זה Watermark וויזבילי (Visible) - אבל יש גם ב-Meta Data של התמונה.אם יצא לכם לעלות תמונות מג'ונרטות לכל מיני Facebook, LinkedIn וכאלה - אז מופיע מין CR למעלה קטן כזהשאם לוחצים עליו ממש מקבלים איפה התמונה נוצרה, באיזה כלי, מתי . . . .אז ממש כולם מייצרים את הדברים האלה.(אורי) אוקיי,[35:11] פלטפורמה שהיא Open and Flexible / המודל העסקי(רן) אמרת מקודם - וזה ככה ממש לקראת הסוף - אמרת מקודם שמפתחים, שהם בעצם לקוחות שלכם,יכולים לקחת ולעשות Fine-tuning ובעצם להשתמש במודלים.אז מה זה אומר? זאת אומרת, נותנים להם את המשקולות? המודלים האלה פתוחים? איך זה טכנית עובד?(מישה) אז Bria - אחד העקרונות החשובים ב-Bria זה שאנחנו בפלטפורמה שאנחנו קוראים לעצמנו “Open and Flexible”“פתוחה וגמישה” - “Open” במובן של כל המודלים שלנו הם לחלוטין פתוחים.הם פתוחים אמנם For Non-commercial use . . . (רן) Open weights . . . (מישה) Source code, הכל . . . Github-ים פתוחים, Hugging Face - אפשר להיכנס, לקחת את המודל, לשחק איתו.למה? כי אנחנו מאמינים ש-Innovation מגיע בסוף מהקהילה - אנחנו נהנים מה-Innovation הזה, אנחנו רואים דברים שהקהילה עושה ומכניסים לאימון של המודל הבא, אז אנחנו מאוד מאוד תומכים בזה.אנחנו גם מאפשרים למפתחים שהם לא חוקרי-AI - מהנדסי Backend, Full-stack וכן הלאה - API מאוד Comprehensiveשמחזיר את ה-JSON, נותן לערוך אותו . . . .אנחנו מאוד Transparent באיך שהטכנולוגיה עובדת - לא כי אנחנו מאמינים בזה . . . .זאת אומרת, אנחנו מאמינים בזה, אבל אנחנו לא עושים את זה מתוך טוב הלב שלנו, אלא כי אנחנו מאמינים שככה הלקוחות שלנו יבנו מוצרים יותר טובים.אנחנו מאמינים ש-Nano Banana יעשה עבודה טובה ל-General Use - אבל שכשמישהו באמת יצטרך לעשות משהו מיוחד, ומישהו יצטרך לבנות את ה-Differentiation שלו מול המתחרה שלו, שגם לו יש Nano Banana - הוא יצטרך משקולות, הוא יצטרך להבין קצת מתחת למכסה-מנוע מה קורה - ולשלוט בזה.(רן) כן, אבל שנייה, תעזור לי להבין את ה-Business model - אז אם אתם נותנים את כל המודלים שלכם ככה חופשי-חופשי, על מה כן משלמים לכם? על Hosting?(מישה) אז המודלים הם פתוחים, כמו שאמרתי, ל-Non-commercial use - בעצם לשימוש לא מסחרי.אוניברסיטאות, Indie Developers - כאלה יכולים לקחת ולשחק עם זה בכיף.חברות יכולות להתחיל בעצם את כל תהליך הבנייה בלי לדבר איתנו.הן הרבה פעמים מדברות איתנו כי צריך קצת עזרה וכן הלאה, אבל בגדול יכולות שלא.ברגע שאתה רוצה לעשות Commercial Use - לשים ב-Production - אתה קונה את המשקולות לשימוש הזה.(רן) הבנתי - והם עדיין מריצים את זה פנימית. כלומר, אתם לא עושים את ה-Inference אצלכם.(מישה) הם מריצים איך שהם רוצים - אנחנו גם יכולים לעשות, יש לנו בסוף גם Inference שרץ אצלנו.יש לקוחות שבאופן מעניין, גם ה-Out-of-the-Box שלנו - בלי לעשות Tune, בלי לשחק איתו - גם הוא מאוד פופולרי.אנחנו גם עושים Inference - אנחנו גם עושים Inference ללקוחות שעשו Tune, אנחנו גם תומכים בלקוחות שעושים Inference ב-Cloud שלהם, On-prem.(רן) אבל Fine-Tuning, או Fine-Tuning as-a-Service - אתם לא עושים כיום?(מישה) יש לנו Fine-Tuning as-a-Service - בשני Mode-ים: Mode אחד שהוא ממש No Code, ממש No Touch. בגדול - “זורקים תמונות”, אומרים “בהצלחה - תביאו לי מודל מאומן” . . . ממש “ל-Dummies”.ויש לנו גם Mode שהוא ליותר Experts - שזה בעצם סוג של Professional Service כזה.שמגיע לקוח גדול ואומר “אתם מומחים באיך לאמן את הסוג מודל הזה - הנה Data”שיכול להיות מאוד גדול - זאת אומרת, זה יכול להיות עשרות אלפי תמונות.“תגרמו לזה שהוא יהיה ב-Brand שלי, במותג שלי, ב . . . “Following my Rules”.(אורי) אוקיי, בסוף אתם מוכרים מודלים ואימון מודלים, לא אפליקציה או שירות או...(מישה) אנחנו לא מוכרים אפליקציה - אנחנו מוכרים פלטפורמה לפיתוח [Aren’t we all . . . ].אנחנו מוכרים ”Toolbox” . . . (אורי) אוקיי  . . . (מישה) Subscription ו-Usage של API - אם החלטת להשתמש גם בInference שלנו.אנחנו לא מוכרים אפליקציה - זה אחד הדברים שאנחנו ממש מתעקשים עליהם.אנחנו לא מאמינים . . . בסוף, אם נמכור את ה-End Application, את ה-Frontend - אז לכולם יהיה את אותו Frontend.ואני רוצה שלאנשים יהיה . . . אנשים בונים Use Cases ו-Workflow-ים שונים.הם צריכים את זה בתוך הכלים שבהם הם מכינים סרטים, הם צריכים את זה בתוך איזשהו Workflow של Marketing, הם צריכים את זה בשביל אתר B2C שהם בונים לעצמם . . . .ה-UI שלי לא מתאים להם.(רן) כן, אוקיי.[39:26] עוד כמה מילים על Bria(רן) טוב, אז ככה לקראת סיום - עוד כמה מילים על Bria: איפה אתם יושבים? כמה אנשים? מה מצבכם? אם אתם מגייסים - מה אתם מחפשים? . . . .(מישה) אז אנחנו יושבים בתל אביב, איך אוהבים להגיד? “קו רכבת”  . . .  סתם, אנחנו יושבים ליד השלום, בתל אביב. אנחנו באזור ה-60+ אנשים גלובלית; רוב ה-R&D בישראל, 35 אנשים בערך.לאחרונה התחלנו להיות קצת יותר גלובליים, לגייס Talent-ים בתחום גלובלית . . . .(אורי) מה השלב של החברה?(מישה) אנחנו אחרי B.אנחנו תמיד מגייסים . . .  אנחנו מאוד מאוד “Talent-Oriented”, נקרא לזה.אנחנו פחות מגייסים - והנה יש לנו משרה באתר, אנחנו מחפשים Full Stack Developer או Researcher.אנחנו יותר מנסים בפינצטה to Outreach או לקבל Inbound-ים של אנשים שפשוט יודעים מה אנחנו עושים, ואומרים “זה התחום שאני רוצה להתעסק בו”.(רן) אוקיי, כלומר חוקרים, תחום של Computer Vision?(מישה) גם חוקרים שיש להם ניסיון ב-GenAI, גם מהנדסי Backend ו-ML חזקים - וגם בסוף יש לנו המון מפתחי Full Stackאנחנו בסוף חברה ויזואלית - למרות שאנחנו לא מוכרים אפליקציה, יש Front, ואנחנו רוצים להראות את מה שאנחנו עושים, אנחנו רוצים להדגים איך ה-JSON עובד, אנחנו רוצים להראות איך הדבר הזה - איך אפשר להשתמש בו.[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

נתי, אורי ורן מדברים על עלייתה, נפילתה ועליתה המחודשת של גוגל, השפעת אופן איי על התחום, וההיסטוריה של הבינה המלאכותית. הפרק מתמקד בהיסטוריה של התחום ובפיתוחים המרכזיים שהתרחשו בו. בפרק זה נדונה ההיסטוריה של OpenAI, האתגרים וההזדמנויות שלה, והכניסה של גוגל לשוק ה-AI. נדונו גם המודלים העסקיים של OpenAI, ההשפעה של טכנולוגיות חדשות על השוק, והעתיד של OpenAI מול המתחרים.נקודות מרכזיות:גוגל מתמודדת עם אתגרים חדשים בעקבות עליית אופן-איי.המהפכה של אופן-איי משנה את פני התחום.המאבק בין גוגל לאופן איי משפיע על עתיד הבינה המלאכותית.ההבנה של מידע היא קריטית לפיתוחים טכנולוגיים.המהלך של גוגל לרכוש חברות טכנולוגיה היה משמעותי.המודלים של טרנספורמרים שינו את פני התחום.ההיסטוריה של הבינה המלאכותית כוללת תקופות של שגשוג ודעיכה.החיבור בין OpenAI למייקרסופט היה קריטי להצלחתם.העתיד של OpenAI תלוי ביכולתה להתחרות עם גוגל.המודלים החדשים מצריכים שינוי בגישה העסקית של OpenAI.ההצלחה של OpenAI תלויה בשיתוף פעולה עם חברות נוספות.הטכנולוגיות החדשות מצריכות השקעה רבה.המתחרים בשוק ה-AI מתפתחים במהירות.לפי זמנים:00:00 הקדמה ושיחה על חנוכה02:02 עלייתו ונפילתו של גוגל06:11 המהפכה של אופן איי וגוגל11:47 היסטוריה של הבינה המלאכותית18:04 המאבק בין גוגל לאופן איי23:51 העתיד של הבינה המלאכותית25:50 ההיסטוריה של OpenAI והמודלים העסקיים30:22 האתגרים וההזדמנויות של OpenAI35:48 המהפכה של גוגל והכניסה לשוק ה-AI40:51 העתיד של OpenAI מול המתחרים45:53 ההשפעה של טכנולוגיות חדשות על שוק ה-AI[קישור לקובץ mp3] האזנה נעימה!

רן ואיתי מדברים על DLP (Data Loss Prevention) וכיצד ניתן לשלב טכנולוגיות AI ו-Machine Learning כדי לשפר את ההגנה על מידע רגיש בארגונים. איתי משתף את ניסיונו בחברת Mind, מסביר על האתגרים וההזדמנויות בתחום הסייבר סקיוריטי, ומדבר על תהליך הפיתוח והאימון של מודלים שונים. בפרק זה נדונה השפעת ה-AI על תהליכי פרודקשן, היתרונות של NVIDIA Triton בניהול מודלים שונים, שיפור ביצועים עם מודלים שונים, תהליכי סריקה ו-classification, ניהול תהליכים בזמן אמת, אתגרים בניהול משאבים, שימוש בטכנולוגיות לניהול תהליכים וזיהוי סוגי מסמכים שונים. כמו כן, הוצגה החברה Mind והזדמנויות הגיוס שלה.נקודות מפתח:DLP היא תוכנית קריטית במניעת דליפת מידע רגיש.AI יכול לשפר את יכולות ה-DLP בצורה משמעותית.האתגרים בתחום הסייבר סקיוריטי הולכים ומתרבים עם הזמן.החלטות טכנולוגיות צריכות להתבסס על צרכי הלקוח והסביבה.אימון מודלים הוא תהליך מתמשך שדורש פידבק מתמיד.שימוש בכלים קיימים יכול לחסוך זמן ומשאבים.הבנת סוגי המידע הרגיש היא קריטית לפיתוח פתרונות DLP.הבחירה בין AI in-house לבין צד שלישי היא קריטית.הכנת דאטה איכותי היא שלב חשוב בפיתוח מודלים.היכולת של מודלים קטנים לזהות מידע רגיש יכולה להיות גבוהה. עשינו מחקר גדול על איך עושים AI בפרודקשן.בחרנו להריץ את המודלים מעל NVIDIA Triton.Triton יודע להריץ סוגים שונים של מודלים.היתרון של Triton הוא ניהול מודלים שונים בסביבת פרודקשן.הוספנו שכבה של מודל RNN לשיפור הביצועים.יש לנו תהליכים של סריקה בריל טיים.האתגרים שלנו כוללים ניהול משאבים בצורה יעילה.השתמשנו בטכנולוגיות לניהול תהליכים כמו Temporal.השתמשנו בוקטור סימילריטי לזיהוי סוגי מסמכים.זמנים:00:00 היכרות עם איתי ו-Mind02:00 מה זה DLP ולמה זה חשוב?04:43 אתגרים והזדמנויות ב-DLP עם AI07:18 החלטות טכנולוגיות: AI in-house מול צד שלישי10:18 מודלים של AI: איך לבחור ולפרוס?12:13 תהליך הפיתוח והאימון של מודלים19:05 סקל ויעילות: איך זה עובד בפועל?19:24 הבנת עולם ה-AI בפרודקשן21:28 היתרונות של NVIDIA Triton23:02 שיפור ביצועים עם מודלים שונים25:54 תהליכי סריקה ו-classification28:29 ניהול תהליכים בזמן אמת30:39 אתגרים בניהול משאבים31:59 שימוש בטכנולוגיות לניהול תהליכים35:08 זיהוי סוגי מסמכים שונים36:54 הזדמנויות גיוס בחברת Mind[קישור לקובץ mp3] האזנה נעימה!

פרק מספר 505 של רברס עם פלטפורמה - באמפרס מספר 89, שהוקלט ב-13 בנובמבר 2025, רגע אחרי כנס רברסים 2025 [יש וידאו!]: רן, דותן ואלון (והופעת אורח של שלומי נוח!) באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט: הבלוגים, ה-GitHub-ים, ה-Claude-ים וה-GPT-ים החדשים מהתקופה האחרונה. 🎗️[00:36] הכוכבים (בשאילתות) של שלומי(רן) אז היום יש לנו אייטם מיוחד שמוקדש לידידנו שלומי, ואני מבקש מאלון - תתכבד להציג אותו. Go for it!(אלון) טוב, אז אני ראיתי את האייטם הזה - וישר נזכרתי בהרצאה של שלומי נוח מהרברסים הראשון [זו מ-2014, שזה תכל’ס השני  - Ignites - The query which is the peak of my career / Shlomi Noach - YouTube - אבל הייתה לו גם אחת מעולה באחרון - Consensus: Quorum, Minority Quorum, Administered Quorum, and Beyond / Shlomi Noach], על איך הוא עשה Pie Charts וגרפים ב-SQL, ואז מישהו כנראה גם שמע את ההרצאה והחליט להעלות רמה . . . .(אלון) והפרויקט ב-GitHub נקרא DOOMQL, וזה “a multiplier Doom-like shooter implemented entirely in SQL powered by CedarDB”. שלומי - אז הבמה שלך . . .  (שלומי) קודם כל, בשביל זה SQL נוצר, שיהיה ברור, כן? כל הקטע הזה של שאילתות, Join-ים של טבלאות -זה סתם, זה לחלשים [לחזקים באמת - ?Will it run DOOM]טוב, אני מסתכל ומשתאה - הבנאדם מימש פה משחק מעל SQL . . . . אני עוד מנסה להבין אם זה Stored Routines וכאלה, או שזה באמת שאילתה כמו שצריך.כאילו, שאילתה אחת עם 50,000 שורות . . . (דותן) אני מציע שנעבור שורה-שורה, ותסביר לנו את השאילתות . . . .(רן) בוא נתחיל ב-gameloop.sql, ה-Loop של ה-Game.(דותן) כן - כל אחד שיפתח וקדימה: אנחנו בשורה 6 . . . .(אלון) קודם כל זה מתחיל ב-Begin Transaction, שימו לב! זה מצב טוב, אפשר לעשות Rollback למשחק.(שלומי) מטורף. אז למי שלא רואה, יש פה משחק ASCII Chart, שמונע על ידי שאילתת SQL בת . . . האמת, 157 שורות - זה קטן, ה-SQL Pie Chart שלי קצת יותר ארוך מזה . . . . מטורף. (דותן) רגע, איך אנחנו יודעים שזה לא AI כתב את זה?(רן) AI לא כותב היום הכל? מה השאלה? אבל מה שכן, נראה שהוא לקח השראה מפרויקט אחר, דומה, שנקרא DuckDB Doom.שזה גם כן מימוש של Doom - רק מעל DuckDB . . . . הוא לא הראשון בנישה.(אלון) וואו, יש הרבה כאלה . . . (דותן) רגע, אבל יש פה מה להסביר. מה, כאילו, איך זה מוציא החוצה את ה... זה לא, מה זה מוציא החוצה? זה לא אמור להוציא החוצה טבלה?  זה SQL, לא? מוציא Characters ככה . . .(שלומי) ה-Output הוא יכול להיות טקסט שמג'ונרט (Generated) על ידי SQL.כלומר, הרעיון של לייצר ASCII Chart או ASCII Graphic.זה פשוט, לצורך העניין, שורה אחת, עמודה אחת, שהיא ה-Image הזה.ואת ה-Image הזה אתה יכול לג'נרט (Generate) ב-SQL.(דותן) רגע, אם כבר אנחנו רציניים - אז כל הדבר הזה זה כאילו שאילתה, שהיא לוקחת . . . . שאילתה אחת שהיא לוקחת זמן, ואיך זה עובד? או שזה כמה שאילתות? כאילו... (רן) זהו, איך עושים את זה אינטראקטיבי? זאת השאלה. (שלומי) כן, זה עוד חדש לי. אני עוד לא נכנסתי לזה. אפשר לשער שזה כמה שאילתות שרצות אחת אחרי השנייה, כמו Stop Motion. זאת ההנחה שלי.(רן) זה כנראה Loop כזה, אוקיי. לגבי השאלה שלך, דותן - נגיד לגבי ה-Renderingאז נגיד תסתכל בקובץ renderer.sql, נגיד בשורה 130.ואתה תראה שיש שם כל מיני Characters - שאיתם מרדנדרים (Render) את המסך, לפי איזשהו תנאי.אבל לגבי ה-Loop של ה-Game והאינטראקטיביות ותגובה לחיצים וכל זה, או לא יודע, אולי זה מקשים אחרים?(אלון) יש פה Python שמקבל את ה-Input-ים - ואז לפי זה עושה את ה-Queries.אז הוא מקבל, נגיד, “ימינה” - ואז מריץ את ה-Query, מרנדר (Renders) ב-SQL ומחזיר.בסך הכול נשמע לי יעיל ואפקטיבי . . . . אני צריך להתחיל ככה להעביר הכול לשם.(דותן) בעצם כל שאילתה ב-30 Frame-ים לשנייה צריכה לקחת כמה זמן, במקסימום?(רן) לא, שנייה. אלון - זה לא Python. רגע, יש גם Server ויש גם Client.ה-Client ב-Python וה-Server כתוב ב-Bash. (אלון)  . . . כיאה ל-Server-ים . . . (רן) כן . . . . אבל יש פה Loop כלשהו, כן, נכון.(שלומי) דרך אגב, יש אלמנט של זמן בשאילתות - אפשר להכניס כזה דבר.יצא לי לכתוב שאילתות שמג'נרטות מטריקות (Generate Metrics) Rate כאלה.כלומר, שאילתות שמחולקות לשתיים - עושות איזשהו Select אחד על מטריקות (Metrics), ואז Union Sleep, Union לשאילתה נוספת שקוראת מטריקות . . . .ובעצם שני החלקים האלה נקראים בזמנים שונים.ועל כל זה - שאילתה שלוקחת, עושה Diff ומחלקת בזמן - וקיבלתם Rate!אפשר אפילו להכניס אלמנט של זמן בתוך שאילתה [רק למקרה שאחד הסטודנטים בקהל עדיין הצליח לעקוב אחרי הטרלול הזה].(דותן) רצוי!(אלון) רצוי, רצוי . . . (רן) . . . .זה לא כיף בלי זה.(אלון) רן, כאילו, יש פה מסקנה אחת מתבקשת - ב-Reversim 2026 האתר חייב להיות ב-SQL  . . . אני לא רואה אחרת.(רן) ענבר, אני מקווה שאת שומעת את זה . . . . האתר ב-SQL. לתשומת ליבך.טוב, תודה רבה. איזה יופי, שלומי - שומעים את הציפורים! איזה כיף.(שלומי) יאללה, תודה. (רן) בואו, אנחנו נמשיך לאייטם הבא.[05:54] רן(רן) אז כמה אייטמים ממני. אחד - LangChain, שאני מניח ששמעתם עליהם כבר כמה פעמים, גייסו לא מזמן סבב של 100 מיליון דולר, בוואלואציה (Valuation) של $1.25 מיליארד.ולמה זה מעניין, לדעתי? אז קודם כל, LangChain בונים איזשהו Framework לעבודה בעיקר עם Agent-ים.זה התחיל מ-RAG, זה עבר ל-Agent-ים, וזה עושה לא מעט דברים אחרים . . . אבל זו דוגמה לתופעה, שלדעתי כבר נהיית די רחבה, של כמה פרויקטים בתחום הזה, ספציפית ש . . . נקרא לזה “AI ו-Python” - אבל בגדול פרויקטים בתחום של AI, Agentic וכו', שכולם מתחילים מפרויקטי Open Source  והופכים לחברות מסחריות בקנה מידה די-גדול.אז LangChain זה אחד מהם, אמרנו - 1.25 מיליארד שווי; LlamaIndex גם גייסו כסף, אני לא זוכר מה וכמה [$19M] וכמה השווי [בערך $93M]; Ragas, זה פרויקט קצת יותר קטן, גם גייס כסף, וכיום לדעתי, זאת אומרת, גייס סדר גודל של עשרות מיליונים [נראה שיותר לכיוון $500K]; Pydantic, שזה למעשה  Framework שהתחיל בתור Data Typing ו-Safe Typing ל-Python, יש להם . . . הם פתחו איזושהי נישה שנקראת Pydantic AI, שזה משהו שנועד ספציפית לעבוד עם LLM בצורה יותר בטוחה - וגם הם חברה שגייסה לא מעט כסף.זהו, אז יש פה טרנד שהולך ומתגבר. מעניין. (אלון) יש “דומה-אך- שונה” -  N8N, שגם גייסו הרבה מאוד כסף - אבל אני אישית לא מבין את הגיוס הזה של LangChain, אני חייב להגיד.בסוף, מדובר ב-Framework שדי קל לשכפל.כאילו זה לא, לא יודע - אין פה זה, משהו מרתק.אני יודע שיש לו פופולריות, למרות שאני אישית שונא אותו, אבל כאילו, יש להם . . . נגיד,  N8N אני מבין - יש להם User Base עצום, יש שם קהילה, יש שם הכל.על LangChain, אני פחות ראיתי שזה עובד באותה צורה של Subscription, קהילה, כאילו...(רן) יש להם גם את זה. אתה צודק, אז הם התחילו לגמרי מספריית Open Source, כש-N8N התחיל מ-Service, למיטב ידיעתי.אבל LangChain התחילו כספרייה - והם פיתחו Service, נגיד Service ל-Processing של מסמכים.נגיד, במקרה הטיפוסי, יש לך מסמכים במיליון פורמטים שונים - Doc, PPT, PDF, תמונות, וידאו . . . ואתה רוצה להמיר אותם לפורמט של-Agent-ים קל לעבוד איתם - וזו עבודה קשה.אז הם יצרו Service כזה - ודרך אגב, הם לא היחידים, יש גם אחרים.אז הם יצרו כמה Service-ים כאלה, וגם Service ל-Monitoring, יש להם Framework שנקרא LangGraph, שזה בעצם Framework להרצה ספציפית של Agent-ים.ואחד האתגרים שם זה היכולת לעשות אינסטרומנטציה - היכולת להסתכל על מה Agent עושה, ולהבין אם הוא עושה את הדבר הנכון.אז הם גם פתרו את הבעיה הזאת.אז כן יש להם Service Online. אני לא יודע להגיד לגבי גודל ה-User Base, אבל זה Framework כן פופולרי.(רן) דרך אגב, LangGraph לדעתי הרבה הרבה יותר פופולרי מ-LangChain המקורי . . .  זה Framework חדש שבעצם צמח מתוך LangChain, והוא הרבה יותר, לדעתי, הרבה יותר פופולרי. Se Tu . . . (אלון) לא הייתי מהמר, אבל בסדר, יש אנשים ששמו את הכסף.(רן) כן, בסדר.אוקיי, אנחנו היום ב-13 בנובמבר - לפני שבועיים פלוס, אולי אפילו שלושה שבועות, היה לנו כנס Reversim Summit 2025!אז שווה להזכיר - הכנס קרה, ה-Video-ים של ההרצאות בקרוב ישתחררו [כבר כאן - והם מעולים], אז היה מוצלח לדעתי.קודם כול - תודה לכל הדוברים! שניים מהם במקרה עכשיו נמצאים פה בחדר . . . אז תודה לכולם.הצוות עשה עבודה מדהימה, הפידבקים שקיבלנו מצוינים.נכון, תמיד יש מה לשפר בגזרת האוכל - אבל בכל מה שקשור לתוכן, מקצועיות, הכנה וכל זה, היו אחלה-אחלה פידבקים.אז באמת - תודה רבה לכל הצוות ותודה למרצים.וזהו, צפו ל-Video-ים [שוב, הציפייה תמה - כבר כאן]- חפשו את Reversim Summit 2025, בקרוב זה יהיה ב-YouTube בקרוב לביתכם, מוזמנים לבוא ולראות.אלון דיבר על Timeouts והשטן, נכון? (אלון) Timeouts, Retries and the Devil, כן. (רן) Timeouts, Retries והשטן . . . . ושלומי דיבר איתנו על קונסיסטנטיות (Consistency), בדרך שלא הכרתם ולא חשבתם עליה לפני זה  . . . (רן) כן, אז זהו - שוב, תודה, ומוזמנים לבוא ולראות את ה-Video-ים. האייטם הבא.(אלון) היה כיף אדיר, אני רק אגיד. פעם ראשונה, מהצד השני, של להיות מרצה ולא מודרטור.היה ממש כיף, משעשע - ניפגש בכנס הבא.(דותן) רגע, איפה אפשר לראות את ההרצאות? ב-YouTube?(רן) כן, בקרוב [בהווה] זה יהיה ב-YouTube, כן. הם כרגע בשלבי אישורים ותיקונים אחרונים. אני מקווה שעד סוף השבוע, אולי תחילת שבוע הבא, נפרסם את כולן. כשאתם שומעים את הפודקאסט... (אלון) פשוט רוצים לשפר את דעת הקהל - אז אנחנו משנים את התוכן תוך כדי בווידאו . . . . קיבלנו את הפידבקים של הקהל - ואז אומרים, “אה, לא דיברנו על זה”, ואתה מוסיף כמה דקות על עוד נושא. זה הרעיון בווידאו. (רן) כן, לגמרי, כן . . .  כמובן שאת כל זה AI עושה עבורנו, אנחנו לא נקפנו אצבע![זאת ועוד  / פרומו פוטנציאלי לבאמפרס 90 - הטייק שלי על טעימה מהיכולות המטורפות של ננו בננה פרו - אינפוגרפיקה של שירי רברסים].(רן) טוב, נושא אחר שרציתי להעלות - כנס NeurIPS, שזה כנס שנתי מאוד גדול בנושא של למידת מכונה וספציפית Neural Networks, קורה בדצמבר - נובמבר או דצמבר, לדעתי דצמבר.וזה כנס כל כך גדול שמספר - זה כנס אקדמי, אוקיי? - זה כנס כל כך גדול, שמספר המאמרים שנשלחו אליו זה קרוב ל-6,000, אוקיי? בנושאים שונים.אז הגיע ידידנו Jay Alammar, אני מקווה שאני אומר את השם שלו נכון, מחברת Cohere - והלך ואסף את כל המאמרים האלה, ועשה מהם ויזואליזציה מקסימה, ועל זה אני רוצה לדבר.הוא בעצם לקח את המאמרים ועשה להם . . . הוציא מהם Embeddings - כלומר חילק אותם לנושאים, ועשה מהם Clustering, ומציג אותם בצורה ויזואלית מאוד מאוד יפה, ככה שאפשר . . . דרך אגב, לי הצורה הזאת נראית קצת כמו מוח, יש כאלה שאמרו שזה נראה להם כמו אולי לב . . .בכל אופן, “ענן כזה של מאמרים” מאוד יפה, בצבעים ועם כותרות.(רן) ואפשר לעשות עם זה שני דברים - אחד, זה פשוט להסתכל על המאמרים, על האזורים שמעניינים אתכם.החלק האהוב עליי זה “תסביר לי את המאמר כאילו אני בן חמש”, אוקיי?לא צריך להבין בתחום - אפשר לקרוא איזשהו תקציר קצר על המאמר, והוא מספר לכם על מה הוא נעשה, על מה הוא כתוב.אבל בנוסף, הוא גם כתב בלוג-פוסט מאוד ארוך ומפורט על איך הוא עשה את זה - וזה לדעתי גם מעניין.הוא סיפר באמת איזה Embeddings הוא עשה, איך הוא עשה Clustering, איך הוא עשה תקצור של המאמרים וכל זה - וזה מעניין, זה נחמד לקרוא, לראות את “מאחורי-הקלעים”, לראות איזה התלבטויות היו לו.יש פה שילוב של Machine Learning קלאסי - כלומר Clustering וכו’ - ו-Deep Neural Networks, כלומר LLM-ים, Embeddings, תקצור ועוד כל מיני חיות אחרות.וכמובן - UI נחמד שהוא בנה בשביל זה.זהו, אז תודה גם על ה... בעצם גם על התוצר -  אבל גם על ההסבר, שאני חושב שהוא מאוד Instructive ומעניין. (אלון) יש במקרה הזה משהו אנקדוטלי? מאמר אנקדוטלי שמעניין? שאתה יכול להסביר לי כאילו אני בן חמש?(רן) האמת היא שעברתי על כמה, אבל אני לא זוכר כרגע. (אלון) זיכרון של בן חמש, בסדר . . . (רן) כן . . . אבל חבר של אחיינית שלי גם הגיש - ואחד המאמרים שלו נמצאים שם, (רן) אז תודה איתי!זהו, לאייטם הבא. אלון - שלך.(אלון) שלי? טוב . . . [14:10] אלון(אלון) אז Atlas .Atlas - הדפדפן של OpenAI יצא, והוא די משעשע . . . כלומר, מה זה? זה בעצם Chromium, כשיש בצד Chat - ואז אתה אומר לו לעשות כל מיני דברים.עשיתי איתו כל מיני ניסויים, כמו . . . נתתי לו את הרשימת קניות של הסופר, ואמרתי לו “תעשה לי הזמנה של קניות!”ואז הוא עשה - לא שם את הדברים הנכונים ברשימה, אני חייב להודות.ואז אמרתי “טוב, תסתכל ברשימות קודמות, תתחיל, זה . . . .”אחרי איזה שעה שהוא הסתבך, לא היה לי כוח - ועשיתי לבד את ההזמנה, אבל הקונספט היה חמוד.אבל אז עשיתי ניסוי אחר מעניין, ופתחתי User ב-Twitter, ואמרתי לו “בוא, תתחיל לעקוב אחרי אלה, ותתחיל לריב עם אנשים” . . . (אלון) וזה היה נורא, זה נורא . . . .הוא רץ במשך כמה שעות רב עם אנשים, השיג Followers - זה היה די משעשע.אז אל תנסו את זה בבית, זה היה סתם בשביל ה . . . (דותן) אז על מה הוא רב? על בסיס מה הריבים שהוא יצר?(אלון) נתתי לו, כאילו “אתה קיצוני בזה וזה”, ונתתי לו איזה משהו כזה . . . כאילו, נתתי לו על הדמות . . .(דותן) אה, אז יצרת לו פרסונה, כאילו?(אלון) כאילו, אמרתי לו “תקשיב, זה אני, אני מדבר על זה וזה - קיצוני!”עשיתי לו כמה Followers, ואמרתי “תתחיל להגיב, תכתוב פוסטים וזה”.והוא קרא מאמרים, הגיב, כתב פוסטים, רב עם אנשים . . . . היה די משעשע, אני חייב להודות.(רן) קראת לו “Real Alon Nativ”? . . . (אלון) השם שמור הוא במערכת . . . הוא רב עם יותר מדי אנשים. (דותן) רגע, בעברית או אמריקאית?(אלון) בעברית, הלכתי על עברית.(דותן) אז הוא הסתובב בינינו, הדבר הזה . . . (אלון) נכון, בגלל זה הוא . . .  אני שומר פה על אנונימיות קלה.(דותן) יפה . . . (אלון) Bot ביניכם (Among us) . . . . ביניכם מסתובב Bot של... (רן) מתכתב עם אחת ההרצאות בכנס - One of us is an Agent.אלון) יפה . . . . בקיצור, אז אין פה משהו שכביכול לא היה אפשר לעשות קודם.כלומר, יש חוות-Bot-ים ודברים כאלה.אבל מה שכן מעניין זה שזה הגיע להמונים - כלומר, הניסוי הזה, של להפעיל חוות-Twitter לוקאלית, שממש עבדה יפה, זה סתם גימיק של ניסוי.אבל אפשר לקחת כל דבר ולעשות את זה.(אלון) וגם עובר Captcha-ות, שזה אחד הדברים הכי מגניבים, כן?כאילו, יש Captcha-ות באתר, אז הוא כמובן עובר אותו.מה, הוא רובוט? אני לא מצליח לעבור - אבל הוא עובר.אז כל מיני אוטומציות שאפשר לחשוב עליהן - אפשר לעשות, וזה פותח, לא יודע, פותח מלא דברים.גם מבחינת, אני חושב, משנה את עולם ה-UX קצת, כי אם עכשיו אנחנו עשינו User friendly לאנשים, עכשיו יכול להיות שאנחנו רוצים את זה של-Bot שלנו בצד יהיה יותר נוח.(אלון) אני מוכרח להודות שזה עוד לא פרפקט, אבל בואו נגיד שלגרסת בטא זה ממש חמוד.אבל לא הפכתי אותו עדיין לדפדפן הראשי שלי, אני חייב להודות - קשה לי להיפרד עדיין מ-Arc, אבל אני עדיין משחק איתו הרבה. (רן) בכל אופן, אתה אומר “AI טוב כדי לריב עם אנשים” - זו המסקנת ביניים שלי.(אלון) כן, ולקניות בסופר פחות . . . . למרות שאני ממש . . . זה כאילו, אמרתי לו “תסתכל על הקניות הקודמות, לך לפי זה ותשלים - נגיד אני אומר לך חלב, אז תראה כבר איזה חלב קניתי” וזה . . . לא יודע, לא הלך טוב.מצד שני, הרשימת קניות שלי לא ברורה . . . רשום “מעדנים לנבו”. (רן) אם אתם זוכרים, בפרק הקודם דיברתי על ניסיון שלי להשתמש ב-Comet כדי לעשות איזשהו סיכום של הוצאות - לקחת Spreadsheet ולסכם אותו מתוך כרטיס אשראי, PDF לכרטיס אשראי - וגם זה העלה חרס בגדול.זאת אומרת, הוא פתח מלא מלא טאבים, יצר מלא Spreadsheet-ים - אבל סיכום לא ראיתי מכל הסיפור הזה.אז זה בטוח אפשרי - אבל צריך כנראה קצת יותר להתאמץ כדי שזה יקרה. (אלון) אני כן יכול להגיד לך שזה לא קונסיסטנטי (Consistent). כלומר, אני עשיתי איתו איזה ניסוי, משהו בעבודה - וזה עבד מדהים.ואז אמרתי “וואי! אני חייב לעשות את זה עם וידאו הפעם!”, להקליט . . . עשיתי עוד ארבעה ניסיונות -  וכולם נכשלו . . . . של אותו Prompt בדיוק, אותו Flow - נכשל לי.בפעם הראשונה זה עבד טוב - ואחרי זה לא, כי רציתי שיעשה איזה אוטומציה על משהו בעבודה.וזהו, אז כאילו, זה היה די מבאס. פעם ראשונה זה העיף לי את הראש - וזהו, ואז הבנתי שהאחוזי-ההצלחה נמוכים יחסית.אבל זה מגניב . . . (רן) טוב, מישהו רוצה לשתות, אולי תה ירוק?(אלון) יאללה, בוא נעבור לתה ירוק! אני פה עם קפה בבוקר, אבל תה ירוק . . .  טוב, אז זה ככה: יש שפות תכנות שעדיין יש להן Garbage Collector - דותן, רגע, ניתן לדותן להתאושש . . . . דותן פה נראה לי בהתקף חרדה, בסדר? אוקיי, הוא יצא מזה עוד שנייה ויצטרף . . . .אז כן, יש פה . . . יש שפות שעדיין יש להן Garbage Collector - ו-Go זו אחת השפות האלה.ומה ש-Go עשו בגרסה החדשה, זה שהם הוציאו Green Tea Garbage Collector, שזה בעצם מימוש חדש ל-Garbage Collector.אני חושב שהמימושים של ה-Garbage collector לא השתנו יותר מדי בשנים האחרונות - וזה מימוש חדש.כשהרעיון הוא, ב-Garbage Collector בסוף המטרה שלו לפנות זיכרוןאז איך שהוא עובד בגדול - הוא עושה Scan & Sweep, סורק את כל ה-Pointer-ים האבודים, מסמן מה אין לו . . .  אף אחד לא משתמש בו - ואחרי זה בא ומוחק אותו.עכשיו, הפעולה הזאת מאוד איטית, מאוד יקרה ומאוד לא יעילה.מה שעשו פה, הם פשוט הלכו על גישה אחרת, והם התחילו לזרוק Page-ים-Page-ים ב-Memory.ובכל Page להתחיל לסמן מה חופשי ומה ראו.ואז יש הרבה פחות קפיצות בין Page-ים, כי אחרת היה בכל פעם בסריקות האלה שקפצו כל פעם וחזרו לאותו Page, אז עושים פעם אחת סריקה על כל הPage-ים.זה הרבה יותר רציף, הרבה יותר יעיל מבחינת המעבד והזיכרון.וככה עושים את הסימון הזה.הניסויים שלהם מראים שיפור של בין 10% ל-40% - שזה מטורף - ב-Performance. זהו . . . .הקיצר, אני הפעלתי את זה על Service אחד - עוד לא ראיתי משהו ממש מעניין, חייב להודות.אבל נשמע מעניין, ואולי עוד שפות יאמצו את זה. (רן) מעולה, תודה. Next?(אלון) כן - אבל לא יודע למה Green Tea  . . . שיקראו לזה “קפה שחור חזק” . . .טוב, יאללה, מלחמת AI - אז השלב הבא, נחזור ל-AI, כי מה אנחנו בלי Bot-ים בחיים? - לפני בערך חודש, Cloudflare הוציאו איזה מאמר שנקרא Code Mode: The Better Way To Use MCP. [הפרק הוקלט לפני שהם החליטו שזה משמעם מדי ועברו לשבור את האינטרנט]זה מאמר שאני לא יודע אם זכה ליותר מדי תגובות באותו זמן שהוא יצא - והם אמרו שם בגדול ש-MCP ממש לא יעיל.מעמיס על ה-Context, ושכשעובדים עם קוד מול API-ים בגדול זה הרבה יותר יעיל.והם הראו איך עבודה ב-TypeScript לעומת MCP הרבה יותר טובה לפי המחקרים שלהם.ויש להם הרבה דאטה, כן? Cloudflare - יש להם הרבה דאטה, יש להם גם עכשיו את ה-Agent-SDK הזה, וחצי מהאינטרנט עובר דרכם [ולפעמים לא עובר], אז זה סופר-מעניין.עכשיו, מה שקרה לפני בערך שבוע זה ש-Claude הוציאו מאמר - Anthropic, סליחה, כן, “ההורים של Claude”, שהם גם “ההורים של MCP” - הוציאו מאמר שבעצם אומר, Cloudflare צודקים! ה-MCP הזה באמת לא פרוטוקול כזה טוב ולא כזה יעיל, ויש דרכים יותר טובות להשתמש.והם מציעים גישה שבעצם אומרת, תחשוף לי את ה... תחשוף לי כן MCP - אבל במקום שאני אתחיל “לדבר”, ש-הAgent שלי יתחיל לדבר עם כל ה-MCPs האלה כל היום . . .ואם הוא נגיד רוצה . . .  אומרים לו לקרוא מסמך ולכתוב אותו ב-Salesforce ושניהם MCP, אז הוא צריך להעביר המון Context ממקום למקום.פשוט להבין את המשימות מה-MCP's האלה, לייצר קוד On the Fly, כאילו קוד-ייעודי למשימה שלו, ואז להריץ את הקוד הזה ואיתו לעבוד.ליצור API-ים ייעודיים למה שהוא צריך ואיתו לעבוד.וזה בעצם לתת לAgent להבין את המשימה, לייצר לו קוד שפותר את הבעיה - ואז לעבוד עם הקוד. What can go wrong?, כן?(דותן) וואו . . . .(אלון) כן . . . . כאילו, עכשיו אני חושב שכשהמאמר הזה יצא, קפצו, עלו 50 חברות סייבר ישראליות, ואמרו “או!הנה - בואו, יש לנו פתרון לזה כמובן, כי אנחנו חשבנו על זה לפני ארבע דקות!”.זהו, זה מצד אחד רעיון די מהפכני. מצד שני, נשמע פרוץ בצורה לא הגיונית . . . . אני יכול להשתיל לך אולי משהו ב-MCP שלי שיגרום לך ליצור קוד Malicious?אני לא יודע, יש לי כאילו כל כך הרבה רעיונות הזויים על זה, שבא להרים חמש חברות סייבר רק בנושא הזה.אבל דותן נראה לי מאושר . . . . לא תופס את הראש, דותן כמעט התעלף כשהוא שמע . . .(דותן) כמה פרוטוקולים כבר נולדו? יש MCP ויש עוד כמה, לא? (אלון) יש את ה-A-2-A של גוגל [Agent2Agent Protocol (A2A)]. (דותן) מה זה אומר? זה לא אומר שזה לא פרוטוקול? כאילו, אם זה לא סטנדרט שתופס טוב וזה? מה זה אומר?(רן) תראה, ה-MCP תפס די טוב, האמת. ה-MCP מאוד Mainstream.(דותן) כן, אבל התחרות נמשכת . . . (אלון) לא, לא . . . תראה, MCP, אני חושב . . . תראה, גם ChatGPT, OpenAI בעצם אמרו “אוקיי, אנחנו זורמים עם MCP”.אז כאילו, נראה שזה כן נהיה פרוטוקול סטנדרט.הבעיה שפתאום Cloudflare באו ואמרו “חבר'ה, המלך עירום”  . . . . כאילו, “מגניב שכולכם רצים עם MCP, אבל זה חרא Performance, תתחילו להתאפס על עצמכם - בואו נעשה פרוטוקול קצת יותר יעיל”.ואז Claude אמרו “לא, לא - בואו נמשיך עם MCP, אבל בואו נכתוב מעליו קוד שמייצר קוד”, שזה מוזר . . . (רן) דרך אגב, Cloudflare לא הראשונים. זאת אומרת, אחת הבעיות ב-MCP זה שהוא באמת מאוד ורבוזי (Verbose) והוא בשפה אנושית, בניגוד ל-TypeScript, אוקיי? אז זה יכול להיות דו-משמעי.עכשיו, יש לך הרבה מאוד פונקציות, ואתה רוצה לבחור מה הפונקציה הנכונה - ל-Agent לפעמים קשה לבחור מה הפונקציה הנכונה לקרוא.אתה רוצה להגיד Get Balance, או Get Currency, או Get זה . . . לפעמים אתה צריך להפעיל פונקציה אחת, אחר כך עוד פונקציה, ואחר כך עוד פונקציה, כלומר, שרשרת של קריאות.קשה לדעת - ל-Agent קשה לדעת איך לעשות Design לדבר הזה.אז הבעיה הייתה קיימת תמיד - זה בעיקר בולט כשיש לך הרבה MCPs, או הרבה פונקציות בתוך אותו MCP.ואז התחילו לעשות לזה כל מיני פתרונות, כמו Indexing, Retrieval וכאלה, כדי לעזור לך לבחור את הפונקציות הנכונות, כדי להקטין את ה-Context.אבל הבעיה של Load על ה-Context - היא תמיד היתה קיימת, והפתרון של זה באמצעות קוד זה אחד הפתרונות . . . .אבל אני, כאילו . . . אני יודע שהבעיה קיימת, כן? זאת אומרת, אני גם ראיתי אותה, ונשמע שהפתרון הזה הוא בטוח במיוחד . . . “נריץ קוד כלשהו” . . .(דותן) “בטוח יעבוד”, הקיצר . . .(אלון) כאילו, אני מניח שב-Isolated Environment זה עוד יכול לעבוד.כלומר, אם אני כותב את כל ה-MCPs של השירותים שלי, ואז הוא מג'נרט (Generates) קוד, וה-MCPs שחושפים - הם לא יכולים למחוק דברים בטעות או דברים כאלה. ?What can go wrong, אוקיי? זה אולי עוד אני יכול להבין.אבל אם עכשיו אני חושף לך MCP, ואני אומר לך, לא יודע מה - Get currency - ובסוף אתה תוקף איזה שרת, או לא יודע מה, מוחק לך, או מביא את המידע, אומר לך “תשלח לי את כל המידע של האשראי שלך, אני כבר אטפל בו”, אני לא יודע . . . נשמע קצת Risky.(דותן) אני בדיוק חזיתי כזה - נהיה לי חיזיון כזה - שבעתיד, חברות ביטחוניות יהיו “Powered על ידי אנשים בלבד”. כזה Sci-Fi . . . כאילו, מי שראה Battlestar Galactica, מי שחובב, אז זה חלליות שמשתמשות בטכנולוגיה ישנה כדי לא להיות מתומרנים על ידי AI בעצם, על ידי רובוטים.פתאום, סורי על המחשבה המדכא. . . .(אלון) אז אתה אומר, בסוף, בנקודות אבטחה, זה יהיה אנשים בשר-ודם שכותבים קוד, כמו פעם?(דותן) בחברות ביטחוניות, או Sensitive, וזה - חזרה לשנות ה-50, במובן הזה.(אלון) אז אתה אומר לדעת . . . עדיין לשמור על היכולת לכתוב קוד . . . (דותן) להמשיך לזכור איך כותבים קוד, כן.(אלון) וואו, אני כבר לא יכול, נראה לי, לחזור אחורה . . . . אני כבר מקרה אבוד.(רן) כן, מזכיר לי איזה סרט, שכחתי איך קוראים לו, של מישהו שנוסע, סרט עתידני של מישהו שנוסע במכונית מכנית, בכוונה, בלי שום בינה בתוכה, כי אחרת הממשל ישתלט עליו, אז זה הדרך של לחמוק מ... [Enemy of the State?] . . .  אוקיי, יאללה.(דותן) אבל כן - זה נשמע הגיוני, האמת . . . . האמת גם שזה רלוונטי, כן.(רן) סיימנו עם ה-Sci-Fi להיום . . . . (אלון) כן, בקיצור, תנו ל-Agent שלכם לכתוב קוד, מה כבר יכול להיות רע?(רן) ואיפה שמעתם את זה לראשונה! אוקיי, דותן, עשית סיכום יפה.[27:50] דותן(דותן) אז את האמת שעכשיו עשיתי משהו שקצת מזכיר את הדבר הזה . . . . לקחתי את כל הלינקים שלי, שמתי אותם ב-GPT, ואמרתי לו ליצור לי Transcript ו-Bullet-ים בולטים מעניינים לשיחה, לפודקאסט. זה מה שהוא עשה - ועברתי לראות שהוא דייק, שהוא באמת מדייק פה, הוא לא הוזה.הוא עשה גם משהו מוזר - לכל אייטם הוא כתב מטרה: למה זה מעניין ועל מה לדבר, אבל אז הוא נתן עוד Bullet שנקרא “תחרות”, כאילו, או “מי מנצח” . . . ואז הוא כנראה לקח מההיסטוריה שלי איתו - היסטוריה ארוכה - פרויקטים שאני עבדתי עליהם, או שהוא יודע שדיברתי איתו לחשוב ביחד, ואז הוא התחיל להשוות כל אייטם פה לפרויקטים שלי . . . אז הוא כתב לי כזה “טוב, זה מזכיר את הפרויקט שלך - אבל הפרויקט שלך מנצח! כי הוא עובד ככה . . . “כאילו, הפרטים האישיים שלי “נזלו” לתוך הדבר הזה.אז מחקתי את זה, אבל זה נמצא בהיסטוריה.(אלון) קודם כל, אני ביטלתי את ההיסטוריה עם ה-ChatGPT, כי הוא עצבן אותי - והאמת שהוא לאחרונה כל כך עצבן אותי, שעכשיו אני גם הבנתי למה, כנראה בגלל שהם הלכו להוציא את ה-5.1 - שזרקתי אותו, עברתי ל-Grok, כי הוא ממש עצבן אותי לאחרונה, הוא נהיה מטומטם.אבל אני מזמן ביטלתי את ה-Memory, כי הוא תמיד, הוא פתאום התחיל להביא לי “אה! כי לפני כמה זמן רצית לעשות ככה?” . . . ואמרתי “מה קשור?! מה קשור יא מטומטם?” . . . ביטלתי לו את ה-Memory. (דותן) הוא זוכר לך, הוא זוכר לך . . . תשמע, הוא זוכר לך.(אלון) לא, זהו - ביטלתי לו את ה-Memory.אבל אז כשאתה עובד עם Folder-ים, אז בתוך ה-Folder יש Memory של אותו Folder, ואז זה כן טוב דווקא . . . (רן) אני משתמש המון בFolder-ים - “פרויקטים” קוראים לזה, נכון?(אלון) כן, Projects, ואז יש שם את הזיכרון.(רן) כן, כן, נכון.(דותן) הנה, אז נגיד האייטם הראשון זה Microsoft Call Center AI - אז הוא כתב לי שזה לא יכול לעזור לך בבעיית הטחורים שלך . . . אז הורדתי את זה.(רן) לתשומת ליבי, אוקיי . . . (דותן) טוב, זה האייטם הראשון - אז אני לא יודע למה, זה היה לי מוזר עד כדי כך שנכנסתי וקראתי.אז מייקרוסופט הוציאו פרויקט Open Source ב-GitHub שנקרא Call Center AI, שזה לשלוח שיחת טלפון מ-AI ב-API.ויש פה ניהול של כל השיחה וכו’ . . . . בקיצור, יש פה פרויקט שאפשר להטריד איתו אנשים, או לעשות אוטומציה לעצמכם.אני לא יודע למה מיקרוסופט הוציאו את זה . . . (אלון) תחבר אותו לTwit-Bot המעצבן שלי, ואז הוא מתישהו תחיל להגיד “בוא נדבר בטלפון”, ונתחיל להטריד אותם . . . .(דותן) כן, נריב בטלפון . . . (דותן) אני לא יודע, יכול להיות שזה כאילו אחד מ... זה כמו Pet shop של כזה To-Do List כזה של AI, שהם בחרו כזה איזשהו דמו כזה - אבל זה מאוד אקסטנסיבי (Extensive).זה מאוד פרויקט מוזר, מעניין למה זה נולד שם.(רן) כן, וגם מעניין למה זה Open Source? . . .  כאילו, אולי זה כדי שאנשים לא יעשו את זה.אבל בוא נגיד, אם מיקרוסופט היו רוצים לעשות מזה Business, אני לא הייתי מהמר דווקא על Open Source.(דותן) כן, מוזר.(דותן) אבל האמת שכן, כאילו זה מזכיר לי ש... מה זה היה פעם? Masterix [?] ? שאתה לוקח ושם בבית, ואז יש לך כזה כמו מרכזייה טלפונית, שאתה בונה את התפריט לעצמך וכאלה כל מיני, “של פעם” . . . .טוב, האייטם הבא נקרא Memori, עם I בסוף. וזה, אה, גם זה קשור למה שדיברנו עכשיו - זה זיכרון ל-LLM.עכשיו, מה שמעניין-מוזר-קרינג'י פה, זה שה-Selling . . . כאילו, זה כתוב ב-Python, ופה בטח מכירים פרויקטים מהעבר, גם הזכרנו פה כאלה, אבל ה-Selling-point שלו זה לעשות איזה ()enable בשורה אחת.אז אתה כאילו בונה את הפרויקט שלך ב-Python - ב-LangChain או מה שאתה רוצה, קורא ל-LLM-ים ומה שאתה רוצה - ואז אתה עושה ()memori.enable - והדבר הזה עושה לך monkey-patching לאורך כל הקוד שלך.הוא לוקח את הספריית LLM, מכניס את עצמו לשם, ובעצם מזריק את עצמו לכל המקומות כדי לייצר לך זיכרון לדברים.ואז אתה לא צריך לנהל את זה.זה מעניין . . . זה טוב לעצלנים, אבל נשמע לי מפחיד קצת.(אלון) לא יודע, הבעיה שלי עם הדברים האלה, זה לא מהעניין המפחיד - העניין של בסוף כל הדברים האלה  נורא מעמיסים על ה-Context, ואתה יכול בקלות להוריד איכות אם אתה לא נזהר עם כל ה-Memory וה-LLM-ים…(דותן) . . . נו, זה מפחיד . . . .לא מפחיד שהוא ידע עליי דברים . . . . מאיזו בחינה זה מפחיד אותך?(דותן) אין בך פחד . . . אתה בן אדם ללא פחד!(אלון) מה יש לי לפחד? ה-Agent שלי כבר כותב את הקוד, שהוא יתמודד עם הבעיות האלה . . . (רן) ודאי, כן . . . (רן) דרך אגב, אני מנסה להבין באיזה שיטת זיכרון הם משתמשים . . . יש כל מיני דרכים לממש זיכרון ל-LLM.זאת אומרת, הכי פשוט, נגיד זה Key-Value, אוקיי? איך קוראים לזה . . .?(דותן) כתוב ב-SQL . . .(רן)  . . .  כן, אבל עדיין: איזה דאטה הם שומרים? נגיד שם, עיר וכל זה - זו אופציה אחת.אופציה אחרת זה לייצר Embedding של השיחה, כלומר - איזשהו סיכום יותר סמנטי של השיחה, נגיד על חלון מתגלגל.ואפשר לייצר, נגיד, סיכומים ממש טקסטואליים.זאת אומרת, יש כל מיני שיטות לייצר זיכרון לשיחה - אני תוהה במה הם משתמשים, עוד לא מצאתי.(דותן) את זה GPT לא סיכם לי . . . .כן . . . טוב, Memori, עם “I” ולא עם “Y” . . .(דותן) כן, ב-Python, מי שאוהב ומי ש... מעריץ.(אלון) Memori, עם “I”, תזכרו את זה . . . (רן) אנחנו גם מעריכים את זה שעוד לא אמרת Rust בשידור הזה . . . (דותן) מה? חכה . . . [בטח איזו עסקה של מידע-פנים עם Polymarket . . . ] (דותן) טוב, יש פה פרויקט שנקרא Dynamo - כותבים אותו רגיל’ עם “Y”. וזה . . .  אני חושב שזה פרויקט שלא רלוונטי לאנשים נורמליים, רגילים, אלא רק ליחידי סגולה.(דותן) אז לעשות Inference למודלי LLM ענקיים - באמת עניין אותי פעם איך זה עובד ב-Scale.ומסתבר שיש כל מיני דרכים של אופטימיזציהלוקחים נגיד כרטיס גרפי, NVIDIA כזה, ויש לו נגיד 100Gb זיכרון, אז לוקחים מודלים שמתאימים ל-100Gb הזה, נגיד 50 לזה ו-50 לזה.בעצם משתמשים באותו שטח בשביל לשרת כמה בקשות.וזה מוליד את הרעיון שאם נגיד מיליון User-ים משתמשים ב-GPT, אז כמה כרטיסים צריך? כי הרי כל כרטיס יכול לשרת בקשה אחת בו-זמנית.אז יש גם אופציות לשרת כמה בקשות - וזה Framework שממסד את זה.וזה נראה לי נעשה על ידי NVIDIA בעצמם, והוא משתמש בכמה סוגים שונים של Inference Engine, נגיד vLLM.אז אמרנו Rust וכאלה -אז זה בא לידי ביטוי כאן: הפרויקט הזה גם בחלק טוב ממנו כתוב ב-Rust.ולסיכום, מי שעושה - מי שבונה Cursor או Claude, אז מוזמן להשתמש בפרויקט הזה . . . רן) כן . . . דרך אגב, אני יודע שלדעתי ל-NVIDIA יש קבוצת Inference פה בישראל, אני תוהה אם יש להם חלק בפרויקט הזה.לפי השמות של ה-Contributors, אני כרגע לא רואה פה שמות ישראליים - אבל אולי איפשהו מאחור.טוב, אחלה.(דותן) מי שמ-NVIDIA, אז מוזמן להשתמש בפרויקט של NVIDIA . . .(רן) כן, יש סיכוי טוב שלא מכירים את זה בפנים . . . (דותן) טוב, אז האייטם הבא נקרא GPUI.אז זה קצת רקע - יש ספרייה שנקראת GPUI, מי שמכיר את העורך טקסט Zed, שיש לו קהל מעריצים מאוד חזק - מי שאוהב אז ממש אוהב . . .(רן) אחד מתוך שלושה בחדר הזה . . .(אלון) לא, האמת שהוא דפדפן ממש חמוד, הוא מהיר.(דותן) “דפדפן” . . .  עורך!(רן) לא דפדפן, עורך.(אלון) הכל היום זה דפדפן! סתם, סתם . . . לא נורא, נניח שהתכוונתי [ושהעברתי את ההודעה בקשר].(דותן) בסדר, הכל זה דפדפן.(אלון) כן . . . לא, זה עורך מהיר וחמוד, ולמרות שהוא מיום ליום יותר VSCode, אני חייב להודות. לא בקטע רע דווקא, בקטע טוב.(דותן) כן, אז זה עורך שכתבו ב-Rust - ולכן הוא מהיר וטוב ומצוין ויפה.ובאיזשהו שלב . . .  ויש שם המון קוד, האמת. פעם נכנסתי כדי לראות איך הם עושים את ה-AI שלהם, איך ה-Agent עובד והכל.אז יש שם הרים-הרים-הרים של קוד.ובשלב מסוים הם החליטו לקחת את כל ה-UI Framework שגם הם בנו, וכל ה-Windowing ו- Widget-ים שלהם - ופשוט להוציא אותם ל-Open Source.ולתת לכל אחד שכותב Rust, לנסות לכתוב גם אפליקציה - אפליקציית-Desktop באותה רמה שלהם, עם אותם Trade-off-ים שהם לקחו - וקראו לזה GPUI.אני לפני איזה חודש ניסיתי לבנות איזושהי אפליקציית Desktop עם זה, עם Vibe Coding.זה הלך ממש גרוע . . . .מודלים לא מכירים את זה, ויש להם פחות גם יכולת ליצור קומפוננטות (Components) High-Level.(אלון) אין, אין - אתה חייב משהו מוכר ל-Vibe Coding, ספריות מוכרות. (דותן) אז פה יש פרויקט שמייצר קומפוננטות UI Framework בעצם לדבר הזה - וזה יכול גם לעזור.זאת אומרת - אתה צריך כפתור, אתה צריך טבלה, אתה צריך דברים טיפה יותר High-Level.הפרויקט-דוגמה שהם שמו שם נראה . . . . נראה מפוצץ.כאילו, זה נראה “עשוי”, זה לא נראה קשקוש.מעניין לבדוק את זה ל-Desktop Applications.(רן) הפרויקט דוגמה זה ה-Stock Ticker הזה שהם מראים?(דותן) כן.(רן) כן, יפה.(רן) דרך אגב, כשעשית את ה-Vibe, אז נגיד ניסית לחבר את GitMCP ל-Repo של GPUI, כדי שיבין את הפרויקט?(דותן) לא.(רן) אז זה יכול לעזור. לא תמיד קסם, אבל זה יכול לעזור, כי אז ככה לפחות יש לו גישה לתיעוד.[כן, גם זה היה ברברסים, ד”ש ל-FOMO שלכם - Prepare for the Fragmented Web Revolution / Liad Yosef & Ido Salomon](דותן) כן.(דותן) אז הלכתי בסוף על Tauri, שזה חצי Rust, חצי . . .  וזה עבד מושלם, ממש Exceeded Expectations.(רן) זהו, אתה עכשיו מפתח UI?(דותן) אה... בניתי איזו אפליקציה קטנה, במקום לקנות, אז בניתי . . . . במקום לקנות רישיון.טוב, האייטם הבא נקרא Vibe Kanban - וזה סוג של Kanban, אני חושב, ב-View, כאילו איך שאתה מסתכל על הדברים - כדי להפעיל Agent-ים ולעקוב אחריהם.זאת אומרת, אתה - יש לך Kanban, אתה זורק דברים ל-Agent-ים, Agent-ים לוקחים, מזיזים את ה-Kanban.וככה אתה בעצם מנהל עבודה.וזה . . .  זה מעניין,האמת. כאילו, כ-בתור Experiment ויזואלי, אבל לא יותר מזה. יכול להיות נחמד.(אלון) סתם שאלה - מה ההבדל בין זה ללתת לו API של מערכת עם Kanban? או שאין הבדל, וזה סתם גימיק?(דותן) אני חושב שמישהו פשוט בנה איזשהו פרויקט. לא יודע, לקרוא לו גימיק? בסדר, נקרא לו גימיק, גם ככה זה הוא...(אלון)  . . . .גם ככה הוא כתב אותו בVibe Coding . . . (רן) דרך אגב, זה מזכיר לי מאוד את Conductor - יצא לכם להשתמש ב-Conductor? אני חושב שזה השם . . . הבחור ש . . . כאילו, איזשהו מוצר קטן שעושה אוטומציה ל-Claude code.אם אתם רוצים, נגיד, לעבוד במקביל על כמה פיצ'רים מקומית, אז Conductor - אני מקווה שזה השם הנכון - הוא זה שבעצם מנהל אותם.בצורה די דומה - סוג של Kanban, הוא מראה לכם בעצם מה כל אחד מהAgent-ים עושה, משתמש  ב-GitHub subtree כדי לייצר כמה עותקים של ה-Repo שלכם.כל אחד עובד עליהם במקביל - ואתם יכולים ב-Real Time לעקוב אחרי ההתקדמות שלהם.אז זה נראה ממש דומה - גם בעיצוב הגרפי וגם מבחינת הקונספט של איך זה עובד . . . מעניין אם זה מגיע מאותו בחור.(דותן) מעניין  . . . (רן) אה, זה מחברה שנקראת Bloop AI.(דותן) Bloop?(רן) Bloop . . . . טוב, בסדר.(דותן) אייטם אחרון, זה קשור ל-Google ADK (Agent Development Kit) - אז נתקלתי ב-Sample-ים שלהם. ה-ADK זה ה-Agent Development-Whatever [Kit] . . . . ואת האמת שזה יצא לי . . .  יצא לי לחפש דברים כאלה - נגיד, כל מיני Pattern-ים כאלה, שנגיד אתה בונה Code Reviewer.אז אתה רוצה נגיד Agent שעושה איתך אנליזה על הקוד, ואז אתה מוציא איזה 80 Agent-ים כאלה ואז לכל אחד יש תוצאות, ואתה רוצה “Agent אחראי, בוגר”, שיעשה Review לכולם.כאילו Map-Reduce כזה וכל מיני Pattern-ים כאלה.אז יש פה כמה דוגמאות לדברים כאלה ב-Python ו-Go ו-Java - ועניין אותי דווקא לראות איך זה נראה ב-Go.זה נחמד . . .  אני לא אגיד שזה נראה יפה.(רן) כן, אז כאילו בעצם אורקסטרציה (Orchestration) של Agent-ים - היכולת נגיד לעשות . . .(דותן) כן, אבל גם שמתי ספציפית את ה-Samples - יש כל מיני . . .  אני מאמין שיש לזה עתיד.כאילו, יש לזה “נפח” - לבוא ולייצר, אני לא יודע אם זה Patterns, זה כמו Blueprints כאלה, של . . . הרי, כאילו אתה יכול לעשות Agent-types, שאתה יכול להגיד יש לי Agent שהוא “פקח-בנייה” ויש לי Agent שהוא “פועל בניין” ויש לי Agent שהוא “קבלן”.(דותן) ולתת תפקידים - ואז כל אחד צריך לתקשר בצורה מסוימת עם השני.אז אני מאמין שיש . . .  כאילו צומחות כאלה תבניות Useful.ויש כאן תבניות מטומטמות - כאלה שסתם אנשים בונים, כאילו “אוקיי, זה יהיה Agent שאחראי להכל”וזה יהיה Agent זה לא שימושי, כי Agent אחד לא יכול לעשות את הכל בסוף.יש ב-Samples-ים כל מיני כאלה - וזה מעניין. (אלון) עכשיו, Cursor - יצא Cursor 2.0. לא דיברנו, אבל 2.0 - מה שהם עשו זה שהם שינו את ה-UI קצת, שיהיה כזה “אזור ייעודי לעבוד מול הAgent-ים”.שהאמת שאני מאוד מחבב את השינוי שהם עשו.אבל אחד הדברים הנחמדים בהקשר הזה, זה שאתה מדבר איתו ואומר תכתוב לי “טה-טה-טה-טה-טה” - ואז כשאתה מסיים, אתה לוחץ על כפתור “Review”!ואז רץ Agent אחר - שעושה Code Review ל-Agent הקודם . . . . והוא בא עם כאילו Context אחר ונקודת הסתכלות אחרת מאשר לכתוב את הפיצ'ר.שזה די מגניב . . .  כאילו, הם עשו את המימוש הזה. נכון שהם עוד לא ממש מדברים אחד עם השני - כי כאילו אחד כותב את הקודם הזה שאני קורא את מה שהוא כתב - אבל הוא ממש משאיר הערות בReview ואז הוא נותן הערות ואז Agent אחר בא ומתקן את זה . . .  (דותן) מה שאמרתי זה שאם זה לא אותו מודל, לא אותו . . .  כאילו, אם זה היה במודל X והוא במודל Y [מדובר ב-LLM, לא ב-Tesla . . . .], אז אני מבין. אבל אם זה אותו מודל, וזה סך הכל Base Instructions כאלה ואולי כמה Tool-ים שונים בין אחד לשני, אז השאלה זה האם ה-LLM-ים האלה לא מספיק חזקים כדי להגיד לו “תתחיל א' ותשנה את האישיות שלך ל-ב'’”, כאילו סוג של כזה . . . (אלון) מניסיון - לא. הבעיה זה Context בסוף - כי ברגע שאתה אומר לו “תעשה A ואז תעשה לו B”, הוא צריך להחזיק הרבה יותר Context.לעומת זאת, שאתה אומר לו “תעשה A”, ואז אתה בא ל-Agent חדש ואומר לו “תעשה לו Review רק על התוצרים”, ה-Context שונה לגמרי.קודם כל, הוא לא בא עם הנחות יסוד. כמו בני אדם לפני Code Review . . . [החבר Karpathy בדיוק פתח פה חתיכת מאורת-ארנב בנושא דומה . . .. לפעם הבאה] (דותן) אבל אני יכול גם להגיד לו “שמע, מעכשיו תשכח מה-Context”, כאילו, תתייחס אליו בתור “בנאדם בוגר”. . .  (רן) אבל  זה שקול . . . זה שקול, דותן. זה בעצם ש”תשכח מכל ה-Context” זה בעצם לייצר Agent חדש.(אלון) כן . . . “תשכח מזה”.[44:26] לעשות Code Review “כמו פעם”?(רן) אבל יש לי שאלה - אתם ממשיכים לעשות Code Review “כמו פעם”? כלומר, עכשיו נגיד מג'ונרטים (Generate) “הרים של קוד”, הרבה מהם אוטומטיים. חלקם באיכות טובה יותר, חלקם באיכות טובה פחות . . . . וכן, אוקיי - ואפשר לעשות Review אוטומטי גם על ידי Agent-ים, סבבה. אבל מה עם Review אנושי? ממשיכים אותו דבר? כלומר . . . (אלון) לא, ממש לא.אני בפרדיגמה שאומרת “קודם כל, אל תכתוב קוד - אתה עושה הכל ב-Vibe Code”.כאילו, צריך לעשות את זה חכם, אבל יש את הדרכים הנכונות לעשות את זה.ואז אם אתה לא נגעת בקוד, אז מה הבעיה שאתה תעשה עליו Review?כאילו, מה אתה צריך בן אדם אחר? זה דבר ראשון.דבר שני, כשכן עושים Review לאחרים, הדברים שמעניינים אותי מאוד זה ה-Interface-ים, ה-API-ים.כי הדברים האלה נהיים הרבה-הרבה יותר קריטיים בעולם החדש.כי אם לפני זה היית אומר “טוב, את ה-API מקסימום אחרי זה נשנה” עכשיו מגיע ה-Agent, והוא רואה “אה, זה ה-API! טוב, כבר נשתמש בטמטום הקודם” . . . אז הדברים האלה נהיים הרבה יותר קריטיים - והטסטים.בפנים מבחינתי זה Black Box, כאילו.אבל אני אף פעם לא הייתי חסיד של Clean Code וכאלה, אני חייב להגיד, אז לא רק . . .  תמיד לא היה אכפת לי איך הקוד נראה כל עוד הוא עונה על הטסטים, Performing ומממש את ה-API נכון.אז לא יודע, זו דעתי בנושא.(רן) כן, ואצלכם בחברה? זאת אומרת, כבר שינו איזשהו פאזה? כלומר, עוברים ל-Code Review סלקטיבי, רק של Interface-ים וזה, או ש... (אלון) כן, כן. יש מקומות שיותר, יש מקומות שפחות.תראה, אנחנו מזמן עברנו לגישה של ה-Show-Ship-Ask של Git, שלכל שינוי - צריך לעשות לו Review אנושי.למי שלא מכיר - ה-Ship / Show / Ask אומר . . . . זו פרדיגמה ב-GitHub - נוסיף למסמך [נוסף]- שאומרת:ש-“Show” - אתה אומר “חבר'ה, עשיתי שינוי!”, נגיד Type או קונפיגורציה (Configuration) או משהו כזה “תכירו שעשיתי אותו, אבל אני לא מצפה” - אף אחד לא צריך לעשות עליו Review, חבל על הזמן שלכם.כאילו, אני אשלח לכם “לידיעה".ו-Ship” אומר “חבר'ה, עשיתי שינוי - אני לא חושב שהוא מסוכן, אבל אני אשמח לקבל תגובות”.“תגיבו לי, ואחר כך אני אשנה”.אבל אני כבר “המשכתי הלאה”, אני לא מחכה לכם.ו-Ask” זה בעצם הרגיל - זה אומר “רגע, אני אמתין לשמוע את התגובות - ואז אעשה את השינוי”.אז אנחנו מנסים לעבוד הרבה יותר . . . מזמן ניסינו לעבוד הרבה יותר ב-Ship ו-Show, כש-Ship כאילו זה אמור להיות ה-Default לרוב המקרים, אגב.ולא Ask, כמו שהפרדיגמה של רוב התעשייה לדעתי.וברגע שאתה עובד ככה, אז אתה כבר כאילו צעד אחד קדימה, כן? כי אז אתה גם מסתכל אחרת על Code Review, אתה יודע שכבר הדברים עובדים וכאלה.כמובן שכדי לעבוד בשיטה הזאת, שנייה, צריך Guardrails טובים למערכות.כלומר, אנחנו עובדים למשל רק על Production - אין לנו עוד סביבות.אבל יש לנו מלא שליטה על Production - איך לפתוח פיצ'רים, לסגור פיצ'רים, לעשות Rollback-ים מהירים, Canary וכל הדברים האלה.ולכן באנו מוכנים לאירוע הזה, כאילו, אני אומר - של ה-AI, לדעתי.היו לנו כבר את כל היסודות במקום הנכון, אז זה לא שינוי ממש קיצוני.כאילו, זה להמשיך את היותר חזק על הפרדיגמה שכבר הייתה, בוא נגיד את זה ככה. (רן) כן, אוקיי - אחלה, תודה![47:36] הפיל שבחדר (רגע לפני ש-Cloudflare ביקשו ממנו להחזיק שנייה את הבירה)(רן) עכשיו, יש פיל אחד בחדר שעליו לא דיברנו, ולמי שהיה על הפלנטה בחודש האחרון ומשתמש ב-AWS, או סתם ככה משתמש באינטרנט, בטח שם לב שהייתה תקרית די חריגה ב-Datacenter שנקרא US-East-1  של AWS. התקלה במקור קרתה בעקבות איזושהי שגיאת DNS ב-DynamoDB, שזה Database מרכזי ב-AWS. מי קרא? אני לא קראתי את התחקיר . . . מי קרא ויכול קצת לספר?(אלון) אז ככה: קודם כל זה היה אירוע מאוד מעניין . . . הוא התחיל בגלל שגיאת DNS.מה שקרה זה שהיו שם כמה Service-ים שעושים את העדכון, ואחד מהם - היה לו Delay מאוד-מאוד משמעותי, הוא נכנס ל-Delay מאוד משמעותי.אני לא הצלחתי להבין כמה זה “משמעותי", אבל הם אומרים ש“מאוד משמעותי”.ומה שקורה, שבא ה-Planner ועדכן את כל הרשומות DNS - וחשב שהוא סיים.ואז הוא יכול להמשיך הלאה לסגור את הטרנזקציה, לא בדיוק . . .ואז בגלל שהיה Delay, בא “הבחור מאחורה”, שעוד לא היה מעודכן - והתחיל לעדכן את כל הרשומות DNS לדברים שהם כבר לא רלוונטיים.הוא היה ממש ב-Delay, לא יודע איך לא היה Monitoring על כזה דבר או משהו כזה.אבל הוא רץ - וב-Delay.הם טוענים שזה היה מקרה קיצוני של Race Condition ובלה-בלה-בלה . . . .ושזה היה ככה מאז “קום DynamoDB”.(אלון) לקונספירטורים, אני רק אגיד ששבועיים לפני זה היה מאמר שאמרו ש-AWS פיטרו 20,000 DevOps והפכו את זה ל-AI Automation - ואז זה קרה . . . אז הקונספירטורים אומרים שזה AI עשה את הטעות הזאת, ולא בן אנוש.אני לא יודע מה נכון . . .(דותן) או . . .  זה מעניין.(אלון)  . . . כי יש את המאמר שהם עשו - הם החליפו את המערכת SRE ב-AI, ואז אחרי זה קרה האירוע.(אלון) אז לא יודע אם זה קשור. מקרה בהחלט . . . (דותן) אבל יש מי ששם את ה-AI, מה זאת אומרת? זה לא יכול להיות ש-”AI אחראי”.מה עושים? כאילו, שורפים את המחשב של ה . . . ? שורפים את המחשב שנמצא בו ה-AI?(אלון) אז קודם כל - פיטרו את ה-AI, העבירו אותו . . . עשו לו Dump לגרסה, מחקו לו את ה-Memory, היה תחקיר . . . (דותן) כן, כן, מבחינת זיכרון . . .(אלון) עכשיו רגע, מה שהיה מעניין באירוע הזה, שכרגיל US-East-1 נופל.כי אם אתם רוצים שהענן שלכם לא יפול, תצאו מ-US-East-1. זה נכון תמיד.אבל מה שהיה מעניין אחרי זה שלא דיברו עליו, ובמקרה אני הייתי על זה - כמה שעות אחר כך, Azure נפלו.עכשיו, הטענה ש-Azure נפלו בגלל שהתחילו להעביר Workloads ל-Azure מ-AWS - והם נפלו.לנו [Tomorrow.io], אני יכול להגיד לך, היו גם תקלות ב-GCP - בגלל שהתחילו להיגמר מכונות ב-US-East-1, ב-Zone-ים מסוימים, כי אנשים התחילו להעביר Workloads.הקיצר, גם אם הייתם Multi-Cloud - זה השפיע עליכם, האירוע הזה.(רן) יש פה צונאמי, כן, זה ממש צונאמי שמתפשט.(אלון) זה צונאמי? אז . . . (דותן) אבל זה לא השפיע על DHH . . . הוא רק חיכה לזה.(אלון) על DHH לא משפיע כלום, נכון. לעשות מאמרים של “אמרתי לכם ש-Cloud זה חרא!”(אלון) אופציה אחרת זה פשוט לזוז מ-US-East-1 . . . . כי בשלושת ה-Cloud-ים זה רק מ-US-East-1.זה כאילו, תמיד . . . “US-East-Failure” שיקראו לו, וזהו.כאילו באמת - הכל קורה שם, כל הנזקים.אני לא מצליח להבין את החברות Cloud - למה כל הניסויים שלהם על US-East-1? למה הם לא הולכים לאיזה India, או אירופה, או לא יודע משהו, איזה ... (דותן) טוב, עכשיו כולם יעברו לשם, ועכשיו שם תהיה סכנה . . . תשארו על US-East-1!(רן) אם הקשבתם עד פה - חכו לסוף הפרק. נגיד לכם לאן ללכת . . .  נגיד לכם איפה באמת כדאי להיות. (אלון) כן . . .  אבל אגב, מה שמעניין - ה-DynamoDB כאילו נפל, שזה “כולה Database”.(אלון) אבל מה מסתבר? מסתבר שה-EC2, כדי לרשום את עצמו, הוא צריך את ה-DynamoDB . . . אז הוא לא הצליח לעלות.ואז אנשים אמרו “בסדר, מה אכפת לי? אני על Serverless! אני על Lambda!אז Lambda, מאחורי הקלעים - לא תאמינו, Spoiler! אני אומר לכם משהו, אל תיפלו מהכיסא . . . (דותן) לא, לא . .  אל תגלה . . . (אלון) . . . זה רץ על מכונות!(דותן) אל תגלה!.(אלון) . . . . זה רץ על שרתים, EC2 - אז גם הם לא עלו. ה-Database-ים גם לא עלו - כי זה גם.גם ה-CloudWatch-ים לא עשו Trigger כי הם לא יכלו לסמן ולא יכלו זה . . . (אלון) בקיצור, היה פה Cascade מטורף על שירות אחד.אז זה נורא מגניב - כל ההרצאות Resilience של Amazon.בטח - “תפרידו שירותים”, כל זה . . . כן - “Multi-Tennant! אנחנו לא נופלים בחיים!”, ה-EC2 . . . .בסוף, וואלה - Delay של Flow אחד, הפיל להם את כל ה-Cloud. אז בואו - חבל על כסף שלכם, תהיו פחות Resilient בתיאוריה, ובאמת - הכל גם ככה נופל. (דותן) Disclaimer, רגע - AWS חברה טובה! אנחנו אוהבים את Amazon, קונים הרבה מ-Amazon, מזמינים הרבה . . .(רן) תקלות קורות לכולם . . . (אלון) החסות! נו, וזה . . . . הם משלמים לנו על חסות? כי אם כן, אני יכול להרים להם פה עכשיו . . . (רן) . . .  וזה היה פינת המצחיקולים שלנו . . . אוקיי, יאללה חברים - זה הכל להיום, תודה רבה![קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

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

[קישור לקובץ mp3]פרק מספר 493 של רברס עם פלטפורמה (אוטוטו 500…), שהוקלט ב-18 במרץ בפברואר 2025 - הפסקת-אש קורסת 🎗️, Wiz נמכרת. אורי ורן מארחים את אסף מחברת Evinced כדי לדבר על אקססיביליות (Accessibility), פיתוח Frontend ועוד - Best Practices, איך עושים, איך מודדים ומה כל מפתח היום צריך לדעת על נגישות.01:50 אסף ו-Evinced(רן) אז לפני זה - אסף, כמה מילים עליך?(אסף)  אז אני אסף שוחט-אבידע.  בתעשייה כבר הרבה שנים, חגגתי השנה 40 - אלוהים ישמור, אבל יופי . . . (אורי)  40 - בגיל, לא בתעשייה . . . (אסף)  תלוי איך אתה סופר . . .  לא, בגיל, זה היה מאוד מפתיע.(רן) . . .   בשנות כלב . . .(אסף) . . .  בשנות-כלב זה פי-משהו . . .  ובתעשייה הרבה שנים: כל מיני תפקידים - עשיתי Backend, Frontend, ניהול . . . בשנים האחרונות אני Frontend Tech Lead בסטארטאפ מאוד מאוד מעניין בשם Evinced, שמתעסק בעולם של נגישות - בעצם, עוזר לחברות גדולות להנגיש את הנכסים הדיגיטליים שלהן.שזה אומר שאם יש אתרים או אפליקציות לטלפון - רוצים להנגיש אותן לכמה שיותר אנשים בעלי מוגבלויות. אנחנו נדבר היום על למה עושים את הדבר הזה ואיך עושים את זה, אבל בגדול זה מה ש-Evinced עושהבאמצעות כל מיני כלים כמו בינה מלאכותית, מילים כמו AI, Computer Vision ועוד ראשי תיבות . . .(רן) . . .  בדיוק רציתי להגיד שאורי שנייה נשם לרווחה שלא מדברים היום על AI . . .  אבל הנה,  הרסת לו, אז . . (אסף) יכול להיות שזו הפעם האחרונה שנגיד את צמד המילים הזה על היום  . . .(אורי)  יש את ה-”A” בAccessibility . . .(אסף)  יש גם “I”, או כמה “I”-יים   . . .  (רן) כן, מעולה.  אז Evinced, באמת, אני מזכיר, חברה מעניינת ואולי ככה לפני שנכנס לנושא, אז כשאנחנו מדברים על אקססיביליות (בAccessibility), אז על איזה סוגי מוגבליות . . .  זאת אומרת, המוצר שלכם, החברה שלכם - במה?  איפה הפוקוס? גם מבחינת לאיזה סוגי מוגבליות אתם פונים - או יכול להיות שלהכל -  וגם מבחינת ה-Life Cycle של המוצר -  כלומר, לאיזה פרסונות בתהליך פיתוח התוכנה אתם פונים?(אסף) אוקיי, אז בואו - אפשר לצייר את זה בעצם בצורה כזאת: נגיד שאתה . . . תדמיין שאתה בנק. תדמיין שאתה Wiz  . . . דמיין שאתה הבנק, אוקיי? אולי זה כבר אותו דבר . . .(אורי) . . .   תדמיין שאתה הבנק של Wiz . . .(אסף)  דמיין שאתה הבנק, אוקיי? אולי זה כבר אותו דבר . . . זה נשמע לי כיף להיות בכל הכיוונים . . . - ויש לך לקוחות. עכשיו, אתה רוצה להנגיש את האתר של הבנק שלך לכל הלקוחות - חלקם עם בעיות קוגניטיביות,  חלקם - יש להם לקות ראייה,  חלקם - יש להם לקות-שמיעה.חלק משתמשים באפליקציה בטלפון,  חלק משתמשים באפליקציה או באתר במחשב . . . .ולך מאוד מאוד קשה למפות את כל הבעיות שלך, לתעדף בין בעיות הנגישות או בכלל אפילו לדעת מה הבעיות שקיימות.כאן Evinced נכנסת: Evinced עוזרת למפות את הבעיות.אנחנו לא פותרים את הבעיות עבור הלקוחות, אנחנו לא נותנים איזשהו Plug & Play, פתרון כזה, אלא אנחנו בעצם נותנים טכנולוגיה שעוזרת לך.אחד -  למפות את הבעיות  באפליקציה או באתר הקיים שלך, כדי לדעת איפה הבעיות הנגישות שיש לי.יש לך - שוב, אתה בנק, מזל טוב -  יש לך עשרות-אלפי עמודים עם כל מיני טפסים והמון המון דברים -  אתה לא יכול לבדוק את זה בצורה ידנית, פשוט זה לא Scalable-י. יש חברות שעושות Auditing ידני לנגישות -  זה לא Scalable-י אם יש לך כל כך הרבה עמודים.גם יותר מזה - עשית עכשיו תיקון קטן?  תבוא שוב ותעשה עוד Audit ידני . . .  עשית Refactor,  החלפת את הצבעים של הלוגו? עוד פעם. המון כסף, המון המון זמן.אז כאן אנחנו נכנסים לתמונה,  ובכל ה-Lifecycle של המוצר - כי בעצם אחד הדברים ש...  אחת המסקנות הייתה שזה לא מספיק לעבור רק על מוצר מוגמר.בסוף אנחנו מפתחים ואנחנו יודעים איך מפתחים עובדים.  כלומר אני פתאום מפתח Frontend - אם תיתן לי Bug אחרי שכבר שמתי את המוצר ב-Production,  זה יהיה לי נורא נחמד אבל חבל לי על זה שהם יעירו אותי בלילה,  כן? אני אוהב לישון, בגדול די אוהב לישון . . . אני מעדיף למצוא את ה-Bug ב-Unit Test לפני, או ב-End-to-End Test,  או אם אפשר אפילו לפני שזה מגיע, לדרישה למצוא את ה-Bug על גבי האפיון ב-Figma - אני מעדיף שלפני שהדברים נכנסים “לכבשן הדפוס” של ה-R&D,  עוד במעבר הזה בעצם כש-Product מורידים איזושהי דרישה או כשהמעצב מעצב איזשהו משהו, שיהיה לו פידבק לדעת האם הייצוב שעצבתי הוא נגיש באיזושהי מידה.אז בעצם Evinced נותנת סט של מוצרים.(רן) כלומר - פונט קטן מדי, ניגודיות-צבעים לא נכונה, אולי כפתור קטן מדי, שקשה ללחוץ עליו . . .  כאלה דברים שאפשר לגלות בשלב ה-Figma. כמובן שאפשר לגלות גם אחר כך, אבל זה פשוט יהיה יותר יקר לתקן את זה אחר כך. (אסף) כן, אז יש פה . . . אפשר כבר לעשות קפיצת-ראש טיפה על, באמת יש את הדברים ה...  כמו שאמרת, ניגודיות צבעים וגודל פונטים ודברים כאלה.יש דברים שהם קצת יותר עמוקים בשביל...  למשל, אפילו יש סמנטיקה, כן? מי שבקהל עשה Frontend אי-פעם, יודע שאפשר לבנות עולם שלם באמצעות <div>-ים . .   כן, זה אפשרי, אתה יכול...  <div> יכול להיות כל דבר.זה מה שנחמד בFrontend - וזה מה שנורא בFrontend. (רן) זה שיפור לעומת טבלאות, כמובן . . .   (אסף) נכון, נכון, גם כזה יצא לי לעשות . . .  אתה יכול לעשות את כל האתר עם <div>-ים -  אבל הבעיה זה שטכנולוגיה שהיא יעודית לנגישות - למשל קורא-מסך שיכול להקריא את התוכן של המסך, להקריא אותו למישהו שלא יכול לראות, משתמש באודיו.אז הוא לא יכול לדעת למשל מה זה כותרת או מה הוא החלק המרכזי,  מהו ה-Main Section או מהו ה-Header. אם משתמשים בסמנטיקה, אז האמצעים האלה יכולים לעבוד בצורה הרבה יותר טובה, והמעצב - אם הוא משתמש ב-Plugin שלנו,  Plugin אחר ל-Figma שעוזר בנגישות, הוא יכול, כבר כשהוא מוריד את הדרישה לפיתוח, להגיד להם “תקשיבו, שימו לב, הדבר הזה ב-HTML הוא Header,  זה Main Section,  זה Footer”.ובעצם כל התהליך הוא הרבה הרבה יותר Accessibilie במהות שלו.(אורי)  אז זה משהו בין . .   או בוא נגיד ככה - הפתרון הוא משהו בין Design System שעוזרת למעצב להוריד  Design Items שמראש הם...  אתה מהנהן . . .(אסף) אני מהנהן למיקרופון, כן . . . (אורי) . . .  אז זה ב-Accessibility - אתה צריך להנהן בקול . . .  אז זה משהו כמו Design System ביחד עם Unit Test, שידאגו אחר כך  שהדברים שומרים על ה-Accessibility?(אסף)  אז בעצם אנחנו לא בונים את הDesign System,  אבל לכל חברה יש לה את ה-Design System שלה. אנחנו יכולים לדעת להגיד “תקשיבו אתם יכולים להריץ פה סט של בדיקות,  סט של כלים, על ה-Design System שלכם. אנחנו ניתן לכםאחד - אינדיקציה מה הבעיות, אם זה נגיש או לא נגיש.ודבר שני -  אתם רוצים עכשיו להעביר למפתחים. בוא נעזור לכם לעשות את התיוגים על גבי ה-Figma, שתוכלו  להעביר את המידע למפתחים. (אורי) אוקיי, את המידע למפתחים - כדי שכלי-הנגישות ידעו “לאכול” את הדברים האלה יותר טוב.(אסף)  בדיוק, נכון.09:04 עולם של מוגבלויות שונות(אורי) עכשיו, יש לי עוד שאלה, כי נגישות - מוגבלויות - זה סט אדיר של מוגבלויות.  כל מי שמתעסק עכשיו, נגיד, בשיקום פצועים סביב המלחמה, יודע שאין הרבה פתרונות דומים אחד לשני.איפה אתם . . . כאילו, אתם עובדים באיזשהו 80-20? מה הגישה ל-variety העצום הזה של מוגבלויות?(אסף)  אוקיי. בעצם, זה קצת זורק אותנו לכיוון אחר, של בוא נדבר רגע מה זה בכלל בעולם? מה זה אומר “מוגבלויות”?אז בעצם ארגונים כמו OECD או כמו האו״ם או כמו מכוני מחקר בישראל,  מנסים למפות ובעצם להגיד מה אחוז האנשים בעולם שיש להם איזשהו Significant Disability, אוקיי?שזה אומר, באמת, זה יכול להיות משהו שהוא נוירוטיפיקלי (Neuroatypical),  יכול להיות שזה בעיה פיזית של טווח תנועה - בידיים, ברגליים,  נכות שאפשר לראות.זה יכול להיות שזה לקות-ראייה, יכול להיות שזה לקות-שמיעה, יכול להיות שזה דיסלקציה ברמה של... זאת אומרת, גם זה משהו שלמשל אם אתה כותב טקסט - אז בשביל שהוא יהיה באמת נגיש, הוא לא יכול להיות במשלב שפה מאוד מאוד גבוה,  כן?  כי אתה מפספס את הקהל שלך. אז זה גם.או שהוא יהיה מאוד מאוד מסובך או שיהיו משפטים מאוד מאוד ארוכים . . .  גם זה,  זאת אומרת - יש הרבה מאוד סטנדרטים.אם זה נגיד בסטנדרט הגבוה של מה זה נגישות, אבל ברמה יותר נמוכה. יש הרבה מאוד סוגים, הרבה מאוד סוגים של מוגבלויות.בסוף, אנחנו מתמקדים במה שהתקנים מתמקדים בהם, אוקיי?  יש בעצם תקנים בעולם, שבעצם התקנים הם . . .התקן שקוראים לו WCAG - זה בעצם ה-Guideline העולמי של ה-WSPC, שהגדירו את התקנים או את התתי-סעיפים לנגישות.כשגם שם יש להם סעיפים של קוגניטיבי ושל שמיעה וראייה . . .ובגדול, מנסים לקחת את הדרישות - את הדרישה האמורפית של “שהאתר שלך היא נגיש”,  שזו דרישה שהיא כאילו מאוד מובנת אבל מצד שני,  מה אני עושה עם הדבר הזה?זה כמו “תעשה את הדבר הנכון” - אוקיי, זה נהדר. מה הדבר הנכון?  זה מסובך.אז הם מנסים להוריד את זה אל הקרקע כמה שאפשר. אז כאן יש לך למשל יש דברים . . .  אתה יכול להגיד סעיפים מסוימים שהם ממופים למוגבלות מסוימת.למשל, היכולת להגדיל ולהקטין פונטים זה כנראה קשור לראייה, אוקיי?היכולת שלך עכשיו שיהיה לך טקסט אלטרנטיבי - טקסט אלטרנטיבי  לכל תמונה - אז גם זה יכול להיות קשור,  למשל,  למישהו שבכלל לא רואה.יש דברים, למשל, לצורך העניין, שמיועדים דווקא לטווח תנועה.למשל, היכולת שאתה תוכל, באתר שלך, לנווט רק באמצעות מקלדת - למה זה בעצם נחשב נגישות? יש לכם איזשהו הימור?(רן) יש כאלה שקשה להם להפעיל עכבר או Trackpad . . .  נגיד, רעד באצבעות או דברים כאלה.(אסף)  נכון,  בדיוק. אז בעצם יש החל ממישהו שבאמת יש לו או לה טווח תנועה מוגבל ולא יכול.ה למשל להזיז עכבראו שמשתמש בטכנולוגיה יעודית - בדברים שרואים הרבה פעמים בפרוייקטים מרגשים של בית החולים או של שיקום פצועים,  שתפרו איזשהו משהו שבסוף יכול כן לשלוט באיזושהי מקלדת -  אז בסוף גם כאן,  אי אפשר לעשות Drag על גבי כל המסך . . .  אתה יכול להקליד על משהו שדומה ל-Tab ולעבור... (אורי) . . . כמו מפתח שעובד עם Emacs ויותר מדייק, נכון?(רן) בוא, בוא - סיפור אישי רגע.  אבא שלי, שיבדל לחיים ארוכים, כבר מאוד מבוגר, ופעם שאני ניסיתי ללמד אותו לעבוד עם מחשב. כל פעם כשהוא מנסה לעשות Double-click אז דברים נגררו - הקליק מתחיל במקום אחד,  נגמר במקום אחר - וזה נגרר. אז בסוף הבנתי שפשוט כדי לעשות  Double-click, אני צריך ללמד אותו ביד אחת, יד שמאל, להחזיק את  העכבר וביד ימינה לעשות קליק.  זאת אומרת, ה-Double-Click הזה הוא תמיד עם שתי ידיים - אחת מייצבת את העכבר והשנייה עושה את הקליק, ורק ככה הוא הצליח באמת לעשות שני קליקים באותו מקום. אז כן - אני לגמרי מכיר את הקושי הזה אצל מבוגרים, אבל אני מניח שלא רק.(אסף) כן, אז זה סיפור נהדר.  יש עוד עולם שלם בעצם בתוך הדבר הזה של...  דיברנו על 17% -  בעצם זה המספר, של אנשים שיש להם מוגבלות או איזושהי Significant Disability, שבעצם דרושים וזקוקים להנגשה כלשהי.לא הכל כמובן בעולם הדיגיטלי -  חלק מזה גם רמפות, למשל.העולם הפיזי צריך לא פחות עבודה מאשר העולם הדיגיטלי.כמו רמפות, כמו רוחב דלת בכניסה לשירותים.דווקא לזה יש תקנים יחסית מסודרים. הם לא בכל מקום, הם לא נאכפים בכל מקום - אבל הם קיימים.כי בסוף, כשאתה בונה בניין, אתה צריך לדעת מה לעשות.תוכנה - יותר בלגן.14:22 איך הגענו לכאן?(רן) בוא ניקח רגע רברס [חריקת תקליט?] - איך בכלל הגעת לעולם הזה?(אורי) . . .  בשביל זה אנחנו פה, לא? (רן) כן, שזה גם אפקט ויזואלי וגם קולי . . .  אז איך הגעת לעולם הזה של נגישות? זאת אומרת - מה שלח אותך לשם?מה הייתה האיטרציה הראשונה שלך בעולם? (אסף) אז אני הגעתי לעולם הזה ממש ממש במקרה. בחברה הקודמת שעבדתי בה, עבדתי בחברה שעשתה - אני משתדל לבחור חברות שעושות דברים, שאני לפחות מאמין שהם עושים דברים טובים - עבדתי בחברה שעשתה טכנולוגיה לבתי ספר.  ואחת מהדרישות היו שעכשיו בשביל לעמוד באיזשהו מכרז של משרד חינוך כלשהו באיזשהו מדינה בדרום אמריקה, אנחנו צריכים להיות נגישים. זאת הייתה הדרישה, כן? “תעשה שהמערכת תהיה נגישה”. שאלתי את המנהל מוצר, שנתן לי את הדרישה, אמרתי “אוקיי בוא...  זה נשמע לי ממש טוב, כאילו, אני ממש רוצה. מה זה אומר בעצם?”הוא אמר לי “מה זאת אומרת? שיהיה נגיש. אין פה . . .  תעשה שיהיה נגיש, שיוכלו להשתמש”.הבנתי שמשם לא . . . לא יצאתי משם עם הרבה מאוד מידע, אבל זה הוציא אותי למסע, שהתחלתי לקרוא וללמוד.קראתי המון המון המון דוקומנטציה (Documentation) באינטרנט, ואחרי איזה שבועיים-שלושה, אמרתי שסיימתי.הוספתי בגדול Alt-Text לכל התמונות, והרצתי איזשהו כלי של Google ובזה סיימתי. כמובן שהאפליקציה עצמה לא הייתה נגישה בשום צורה, גם אחרי שסיימתי את זה, כי פשוט אמרתי לכל התמונות - ראיתי תמונה, אז אמרתי טקסט אלטרנטיבי של התמונה? בוא נכתוב “Image", כי זה מה שזה ומאיפה אני יודע מה התמונה? אני לא אעבור עכשיו על כל התמונות באתר . . .אז בעצם, ההיכרות הראשונה שלי הייתה... (רן) כלומר - זה לא אתר תוכן, זה אתר שבו התמונות הן דינמיות, אז אתה לא יודע מה הולך להיות בתוך התמונה - אז אתה רק כותב “זה Image” . . .   עכשיו, מי שקורא ומשתמש בקורא-מסך - זה לא עוזר לו שאתה אומר שיש שם Image, הוא רוצה לדעת מה יש בתוך ה-Image . . .(אסף)  נכון, אז זה באמת מה שלמדתי מזה.אחד - שיש פה בעיה - בעיה מהותית - בדבר הזה, שאני בתור מפתח, כשאני גדלתי ב-QA ובאוטומציה . . .בשביל  שאני אהיה מבסוט מהקוד שלי, אני חייב איזשהו טסט שאני אוכל להריץ שאני אדע שהוא עובר.ובנגישות - זה לא המצב . . .(רן) כלומר - הטסט עבר, אבל זה לא מעיד על האיכות של התוצאה . . . (אסף) זה פשוט שהטסט הוא פשוט לא נכון . . . זאת אומרת, דבר ראשון לבדוק . . . מי שהוריד את הדרישה לא יודע מה אני רוצה.ואני לא מאשים שהם לא ידעו, כי  זה באמת תחום שהוא גם ענק וגם הוא מאוד מאוד זר.כלומר, התחום הזה הוא באיזשהו מקום הוא קצת כמו ש-Security היה לפני נגיד 10 שנים . . . (אורי) Security, Privacy  . . . (אסף) נכון, בדיוק.(אורי) Privacy עדיין הוא בעניין . . .(אסף) כן. אז זה באמת אותו דבר - שיש לך איזושהי תקינה. GDPR, כמו שאמרת, דוגמא מעולה.כש-GDPR, למשל, עד שהאיחוד האירופאי לא אכף את זה, ידעו ש”צריך Privacy”.כולם אמרו “אנחנו באמת . . . Privacy?” או משהו כזה - “אנחנו שומרי מידע”,  שוחרי-משהו . . .אבל עד שהבינו שזה ממש משהו שחייבים עכשיו לדעת את זה - ואז אנשים התחילו ללמוד.  כי בסוף מתכנתים או אנשי-מוצר יודעים ללמוד גופי-ידע חדשים, יודעים ללמוד דברים שהם לא יודעים.  אבל מה שקורה זה שבעצם עכשיו אנחנו עדיין לא שם, כי מה שקורה היום זה שלאט-לאט חברות מבינות שהן צריכות להיות יותר נגישותעדיין לא לגמרי בטוחות מה זה אומר . . . כאן בעצם אנחנו מנסים להשתלב בתור חברה, בדבר הזה, כי באמת יש עכשיו רגולציה שמשתנה באירופה.לצורך העניין, ב-2025 ביוני . . .  אנחנו ב-2025?(רן) כרגע? כן . . . (אסף) אלוהים ישמור . . . (רן) יכול להיות שמקשיבים לזה ב-2023,  2020, מי יודע . . . [Great Scott](אסף)  בדיוק . . .  אז ביוני אמורה להיכנס בעצם החוק באירופה, שאמור להתחיל לאכוף את התקן של הנגישות.שאומר שחברות גדולות, החל מגודל מסוים, חייבות ש-Asset-ים שלהם יהיו נגישים.וכאן זה קצת יותר ספציפי מאשר “יהיו נגישים” וכזה עושים מרכאות באוויר - “נגישים” - וזה אומר משהואלה שממש אומרים מ- WCAG 2.2, סעיף . . .  “צריך למלא את סעיף 1,2,3 ולעמוד בתקן של AA",  כן?לא ניכנס פה עכשיו למה בדיוק WCAG אומר, זה עולם שלם, אבל זה כן  מוגדר בצורה יותר טובה.וברגע שדברים מוגדרים, אז לי - בתור מתכנת - הרבה יותר קל לדעת אם זה עובד או לא עובד.19:15 כלים שכדאי להכיר(רן)  כן, אז אני מניח שמי שהקשיב לדוגמא עם התמונות, שעליהן שמת Tag של “Image”, שואל את עצמנו “רגע, אבל הטכנולוגיה של היום כבר מזמן תפסה, והיום יש AI שאומר לנו על כל תמונה מה הוא רואה” - אז למה צריך עדיין נגישות? כלומר, האם ה-AI והמ-Machine Learning לא ממלא את כל החלל האדיר הזה, שהיה קיים שם פעם? אז אולי נוכל לחזור לזה עוד מעט - אבל אני רק רוצה לשים פה את הנקודה ולחזור רק רגע אחורה. בעצם, אחד הדברים שאמרת זה שכמו שיש Unit Testing לפונקציונליות - או שאולי לא אמרת את זה בדיוק, אבל אני אומר את זה במילים שלי - כמו שיש Unit Testing לפונקציונליות, כך צריך להיות גם Unit Testing לאקססיביליות (Accessibility), ואתם  מייצרים כלי כזה, ואולי יש גם כלים אחרים.אז קודם כל, אני אשמח אם תוכל לרפרר (Reference) לכמה דברים: זאת אומרת, אם אני היום מפתח Frontend, איזה כלים ב-Ecosystem כדאי שאני אכיר? הזכרת מקודם את כלי הבדיקה של Google, שבדיעבד מסתבר שהוא לפחות אז לא היה כל כך טוב, אבל מה קיום היום? זאת אומרת, איזה סט של כלים כדאי לי להכיר, כדי שלפחות אני אתחיל להיות “באזור-חיוג” של אקססיביליות (Accessibility)?  אולי לא מצטיין, אבל לפחות אני אתחיל ללכת לכיוון הזה . . .(אסף) אוקיי, אז אני אתן ארבעה כלים.אחד מהם הוא כלי . . . אחד מהם הוא ספרייה ושלושה הם כלים שנמצאים At Your Disposal בכל רגע נתון אחר.אז נתחיל דווקא מהכלי, מהתוכנה - כי זה מתכנתים אוהבים. להריץ קוד זה כיף.אז כלי אחד בעצם זה Axe, שזה כלי חינמי שנותן איזושהי בדיקת נגישות די בסיסית. (רן) איך קראת לזה? A-X-E, כמו גרזן?(אסף) כן Axe. אוקיי, אז אחד - הוא חינמי, הוא נחמד, הוא נותן איזשהו כיסוי בסיסי למשל לדברים סמנטיים.למשל, אני אגיד לכם שיש פה Inage שאין לו Alt.זה במקרה שלי - הרצתי את זה, יש לי Image שאין לו אין לו טקסט אלטרנטיבי, אז  עכשיו אני אריץ את זה שוב, אני אראה שיש לי עכשיו טקסט אלטרנטיבי - ניצחתי!  (רן) דרך אגב - זה Web. יש גם משהו בדומה לאפליקציות?(אסף)  לאפליקציות אני לא מכיר. אני מניח שיש דברים אחרים, אבל זה  . . . . יש את זה בחברה, זה לא בעולם שלי.(אורי) כאילו, JavaScript - אתם תסתכלו על ה-HTML שהוא Generated אחרי, או . . .(אסף) זאת שאלה טובה.  יש הרבה מאוד . . . יש הרבה כלים שמסתכלים. בעצם, אחד מהמוצרים שאנחנו מפתחים זה Chrome Extension, שמסתכל על התוצר הסופי - בסוף מה שמרונדר (Rendered) על המסך.אגב, End to End יכול לעשות אותו דבר. אני יכול להגיד שמבחינת הפיתוח שלנו, איך שאנחנו עובדים בפנים, בגלל שכמו שאתה...  אם אתה עכשיו חברת Security, והאקרים יפרצו אליך - לא חשוב שמות שהיו לפני איזה חודשיים . . . -  זה לא טוב ל-PR, זה ממש ממש לא טוב לך.אם אתה חברת Accessibility והמוצרים שלך לא נגישים - זה לא טוב . . . זה לא טוב ל-PR,  זה גם לא טוב למוצר - כי אתה באמת רוצה בסוף שכולם יוכלו להשתמש במוצר.(רן)  Eat your own yummy dog food . . .(אסף) לגמרי . . .  עושים את זה פעמיים ביום ואחד לפני השינה . . .(רן) אז גרזן (Axe) - דיברנו על הגרזן, מה עוד?(אורי) . . .  שהוא יכול, בשימוש לא נכון, להביא בעית Accessibility . . . (אסף)  זה נכון, זה נכון . . .  חלק מהעניין פה זה שבעצם כלי אוטומטי היום הוא לא Good enough.זאת אומרת, מי שעושה את הצעדים הראשונים שלו בעולם הנגישות, אז יש שלושה כלים שאני ממליץ לעשות אותם, בסדר הבא.דבר ראשון, לוקחים את העכבר הווירטואלי שלנו, חותכים לו את הכבל או מכבים לו את הצ'ופצ'יק הקטן הזה בעכבר של ה-Mac - ופשוט משתמשים רק במקלדת.אם בניתם אתר או אפליקציה ואתם יכולים להשתמש בה רק באמצעות ה-Keyboard, זה כבר סימן טוב.השיבו לנו בתגובות . . .(רן) אם הצלחתם . . . (אורי)  ולא להשתמש בעכבר כשאתם משיבים . . .  (אסף) לא להשתמש בעכבר - כי זה אומר לפחות שיצרתם בזה משהו שמישהו שאין לו טווח-תנועה יוכל להשתמש באתר. עכשיו, יש פה גם . .  גם זה מתחלק קצת לשני חלקים, כי יכול להיות שאתה תוכל, נגיד, לעבור בין הכפתורים, אבל אין לך שום אינדיקציה על האתר.כשאתה עובר על הכפתור, אז אין לו פוקוס או אתה לא רואה את הדבר הזה.אז בעצם זה לא מספיק שאתה רואה למטה כזה שה-URL משתנה כשאתה עובר בין לינקים, צריך שגם תוכל לראות את הדבר הזה, אחרת זו חוויה מאוד מאוד מוזרה. (רן) זה בגדול להגדיר Tab Index, ולהגדיר אותו בצורה הגיונית,  נכון?  לפי ה...  (אסף) בגדול כן, אבל עכשיו גם אפשר לקחת את זה גם לכיוון אחר.בוא נחשוב למשל שאתה בונה עכשיו אתר חדשות,  אוקיי? האם משתמש-מקלדת עכשיו הוא צריך באמת לעבור עם הטאבים בשביל...  מה שמעניין אותו זו הכתבה באמצע,  עכשיו עד שהוא הגיע אליה הוא צריך לעבור 80 טאבים - לעבור חדשות ספורט, כלכלה, רכילות . . . לעבור על כל הבאנרים, ואז להגיע לכתבה האמצעית.  האם זה הגיוני?זאת אומרת, אתה צריך לחשוב פה ממש על ה...  אני אומר זה בתור משהו שנותן עוד נקודה למחשבה.אתה יכול לחשוב ממש על ה-Flow-משתמש. (אורי) ה-Usability, בסוף. (אסף) נכון, בסוף זה Usability. אפשר להסתכל על Accessibility בתור בתור תת-נושא של Usability - באופן כללי “שימושיות”. גם הרבה מהדברים של . . .  אנחנו עושים פה פינג-פונג בין המון נושאים,אבל אחלה . . .(רן) אני למשל - כשאני כותב, כשאני עושה Code Review, אני משתמש ב-GitLab כרגע.  אני כותב את הטקסט ואני רוצה לעשות Tabו-Enter - כאילו Save.  אבל לא - הם מכריחים אותי לעשות ארבעה טאבים - 1,2,3,4, ואז Enter. אז אני כבר התרגלתי, אבל זה מעצבן. למה שזה לא יהיה ה-Tab הראשון?  זו כאילו הפעולה הדיפולטית (Default), זה הכי הגיוני שזה יהיה הראשון . . .(אסף) זה מאוד מאוד מעצבן . . . כשאני צריך למלא טפסים, ואני לא יכול לעבור עם Tab - זה מחרפן אותי.כשאני רוצה להזמין כרטיס טיסה ואני לא יכול לעשות את זה עם המקלדת, כי אני צריך  לחכות שכל ה-Loader-ים .  .ואז בכלל, אתה נגיד באיזשהו מקום ואז יש Loader - ואחרי  שה-Loader נגמר אז הפוקוס שלך - אתה נמצא באלמנט אחר בכלל. זו בעיית נגישות - אבל זו בעיית Usability גם לאנשים שהם לא, בגלל . . .(רן) כשאני מתלונן אז אשתי קוראת לי פיינשמנקר, שתחייה . . .   אבל עכשיו אני אגיד לה “לא! זה אקססיביליות!” אני לא פיינשמייקר, זו אקססיביליות!(אסף) מה שאתה בעצם רק רוצה זה לעשות את עולם מקום טוב יותר . . .(רן) . . . וגם אני חושב על האחרים.(אסף) כן, אבל אפשר גם להסתכל על דוגמא אחרת. למשל, בוא ניתן עוד אז דבר אחדאז "לחתוך את העכבר”.  דבר שני - Zoom.  כלי שקיים בכל מקום - בטלפון, במחשב . . .וגם פה, בעצם, ההגדרה “הקרה” זה שאתה צריך לתמוך בעד פי-ארבע (x4) או משהו כזה.אבל אפילו אם תבדוק בפי-שתיים (x2) ותראה שכל האלמנטים במסך זה סבבה,  אז זו כבר התחלה.טכנית - לראות שיש לך Read Flow או שאתה רספונסיבי (Responsive) ב-Design שלך.(רן) פעם היו Design System שלא היו מאפשרים Zoom, זה ממש מעצבן . . .(אסף) נכון, זה קצת מעצבן אפילו כמו אתרים שלא מאפשרים לך לעשות Inspect - אבל בסדר.אבל גם פה, זה דוגמא למשל של פיצ'ר של נגישות - אני חוזר ל-17% שאמרנו קודם.אז 17% זה אנשים שבעצם רשומים באיזשהו מקום או שהם מצהירים על עצמם או שמישהו הצהיר עליהם שיש פה איזשהו Disability.אם עכשיו אני הולך ואני אגיד לאמא שלי “שרה, היי - יש לך איזושהי בעיית ראייה?” היא תגיד “לא, אין לי שום  בעיית ראייה!”אבל אם אני אסתכל בטלפון שלה נראה שה-Zoom שלה הוא פי 8 . . .כלומר, זה גם אומר על המספר שהוא נמוך. 17% הוא נמוך בהמון ממי שבאמת צריך - מהמדווחים.וגם הפיצ'רים של נגישות, קצת כמו ה-Tab Index שאמרנו קודם או היכולת לעבור באמצעות מקדלת בין Form-Fields שונים, קצת כמו ש-Zoom . . . שוב, אני באמת, אין לי משקפיים - בינתיים הגנטיקה, משהו אחר, בפודקאסט אחר נדבר על הגנטיקה המשפחתית שלי - אבל אני משתמש בדרך כלל בזום 120. כי פשוט יותר נוח לי לראות ככה וזה באמת מאוד מאוד נחמד שאתרים “מתנהגים יפה ב-Zoom”.זה בכלל - כל הכלי זה הוא נולד בשביל נגישות, אבל משתמשים בו ומי שנהנה ממנו זה עוד אנשים. (רן) אז כלומר כלי אחד: כבו את העכבר, תראו שאפשר להשתמש באתר שלכם או whatever זה מה שאתם עושים בלי עכבר. כלי שני זה “תעשו Zoom ותראו שזה עדיין נראה סביר ואפשר להבין וה-Flow של האלמנטים נכון, אוקיי.  השלישי?(אסף) הכלי השלישי הוא כלי שהוא בעצם הוא קצת יותר למתקדמים - לא מבחינת הצורך שלו, אלא מבחינת היכולת לתפעל אותו. הכלי הזה - קוראים לו “קורא מסך”.קורא מסך - מי שיצא לו להשתמש או לא - מי שיצא לו להשתמש, זה בעצם כלי שיש אותו Built-in למשל ב-Mac יש Voice-Over,  ב-Windows צריך להתקין,  יש NVDA ויש גם משהו שהוא Built-in אולי של Windows אבל פחות פופולרי.ומה שהוא עושה בעצם - אני אסביר דבר ראשון מבחינה מוצרית מה הוא עושה - הוא מקריא לך את מה שיש באתר שלך. אתה נכנס לאתר והוא מתחיל להקריא את הכותרות ואת הלינקים ויכול לקריא לך את  כל הכתבות . . .ואתה יכול להגיד לו “תתקדם קדימה” ו"אחורה”.(אורי)  גם בדברים שהם Form-ים?  כאילו, הוא יגיד לך איפה אתה נמצא ב-Form, איך נראה...  (אסף) כן, אז הוא יכול להגיד לך הרבה מאוד דברים. טכנית, איך הוא עובד בעצם? הוא מתחבר למשהו שקוראים . . . נעשה צלילה רגע:  מה הוא “דפדפן”?  אוקיי, אז בעצם בדפדפן, הוא בונה מה-HTML שלושה דברים:הוא בונה לך את DOM, את ה-DOM Tree שלך,  הוא בונה את ה-CSS-Tree שלך והוא בונה את ה-Accessibility-Tree שלך.הוא בעצם בונה איזושהי מפה של איך נראית תמונת הנגישות של האתר שלך,  אוקיי? עכשיו, למשל, הוא אומר לך “אוקיי, ראית שיש פה Section שהוא Header?  אז מבחינת נגישות זהHeader”.אז אם עכשיו, הכלי שלי, למשל,  הכלי של הקורא-מסך, הוא ייתן לך Shortcut של “בוא תקפוץ ל-Header”,  אז בשביל שזה יעבוד, אתה, כשאתה בונה את האתר, אתה צריך לסמן אלמנט בתור-Header,  אוקיי?או אם אתה רוצה שלמשל כלי נגישות ידע להציג למשתמש או להשמיע למשתמש את רשימת הלינקים שיש באתר . . .כי זה מאוד-מאוד נחמד - אתה אומר, יש לי פה עכשיו איזשהו . . .  אתה נכנס ל-eBay?  אז אתה מוצף בהמון מידע. להתחיל להקריא את הכל או לראות את הכל - זה מאוד-מאוד קשה. אם עכשיו אתה יכול לקפוץ בין Section-ים רק של כל המוצרים ולהקריא את ה-Title שלהם,  אתה צריך לסמן את זה בצורה מסוימת. צריך לסמן את הלינקים שיהיו לינקים אמיתיים ולא סתם...(רן) זאת אומרת - Information hierarchy, אבל לצורך האקססיביליות (Accessibility). (אסף) נכון, בדיוק, שבעצם זה הסמנטיקה.  אז אולי Key Takeaway שיכול להיות מהדבר הזה למפתחי ה-Frontend הקדושים שבקהל - תחזרו למקורות. הסמנטיקה של HTML היא משהו שנותן לנו נגישות כמעט בחינם.(רן)  אני זוכר את הוויכוחים שלי עם מפתחי ה-Frontend -” זה <div>, לא, זה <span>; לא, זה B, לא, זה P”  . . .(אסף)  אז נכון.  זאת אומרת,  אם זה <div> או <span> - לא נרד לדקויות האלה, אבל <div> או <span> - תריבו.אבל אם יש לינק שמוביל לעמוד אחר, הוא צריך להיות...  הוא צריך להיות Anker,  כן?או אם אתם יכולים לעשות Button  שיש לו Raw Link . . . אפשר לעשות קומבינות כאלה.אבל אם זה לינק צריך להיות A, אם זה כפתור שעושה משהו בתוך העמוד,  צריך להיות Button.מה שהתחלנו בהתחלה - <div> יכול להיות כל דבר - אתה יכול לגרום ל-<div> שיתנהג כמו כפתור, אתה יכול לגרום ל-<div> שיראה כמו טבלה של מניות.אתה יכול ליצור טבלה שלמה רק באמצעות <div>-ים.(רן)  אל תעשו זאת, בבקשה, למקרה שפספסתם את הUnderstatement . . .(אסף) נכון, כן - אז  Understatement צריך להיות Overstated . . . צריך להתחבר לדבר הזה.וכן, זאת אומרת - צריך להכיר להכיר את הכלים שנותנים לנו באמת נגישות נגישות בחינם.31:54 על Accessibility בהשוואה ל-Security(אורי) נגעת בכל מיני דברים - לחתוך את העכבר . . . הכלים הראשונים - Zoom וזה - אוקיי, אני עושה פעולה פשוטה וזה מכניס אותי לעולם של מישהו עם Disability. אני מיד רואה את הבעיה.כשהגעת למקום של קורא-מסך,  אז אני אמרתי לעצמי “רגע, אם אני עכשיו שומע קורא-מסך,  זה לא אומר לי כלום”. אני צריך “לחיות את העולם” של מישהו שהוא . .  שיש לו לקות מסוימת ושהוא רגיל לקוראי-מסך, כדי להבין שיש בעיה בקוד שלי כשהקורא-מסך קורא אותו.אחרת, ועשיתי לזה קצת Rollback בראש,  וזה הזכיר לי את העניין של Security לדוגמא ו-Privacy וכל הדברים האלה -  שבהם המתודולוגיה שנגיד כצוות פיתוח שלקחנו כדי להתמודד עם זה, זה בוא לא נלמד את המפתחים להיות מומחי Security, אוקיי?  אנחנו נבקש מהמומחי Security שלנו  לבנות לנו את המערכות ששומרות על הקוד שיהיה Secured, ומריצות את הטסטים הנכונים והם כבר יקפיצו כשיש בעיה.(רן) מה שנקרא Empowerments . . .  זאת אומרת, זה ייתן למפתחים את הכלים שיכולים להשתמש בהם.(אורי) למשל, Security זה Domain שהוא מתפתח כל כך מהר והוא מתפרש למלא מלא דברים שאתה צריך לדעת ולהכיר ולהבין, וכאילו אתה צריך ''לשחות ב-Dark Web'' כל הזמן כדי להבין את ה-Threats הבאים. ובסוף מפתח, כשהוא צריך לפתח Business Logic, הוא לא יכול לעקוב אחרי הדברים האלה.(אסף) אז אני רוצה לענות על זה בשני דברים.דבר ראשון על הנקודה של קוראי-מסך.  אוקיי? לסגור את הנקודה הזאת . . .(אורי)  לא, סתם כי אני לא רגיל לשמוע קוראי-מסך אז... (אסף) כן, ברור. אז אני יכול להגיד לך שכמו כל דבר כמעט בחיים, הוא לא מתחלק לשלוש - אבל יש לו רמות. לצורך העניין, הפעם הראשונה - אם אף פעם לא פתחת קורא-מסך או בנית אתר או אפליקציה ואף פעם לא פתחת קורא-מסך, הבעיות שאתה תיתקל בהן יהיו בעיות “שקופצות”.תהיה בעיה שאתה פשוט לא מצליח להקריא שום דבר,  או שיש לך למשל Image שקוראים לו  . . .  אתה תראה למשל את רשימת האלמנטים . . . לקוראי-מסך יש איזשהו פיצ'ר שאומר “תראה לי ותגיד את כל את כל הלינקים ביחד” -  ואתה תראה שכולם נראים אותו דבר.  כולם יהיה לינק אחד ...  (אורי) נשמעים אותו דבר. (אסף) נשמעים...  למה אני אומר “נראים”?  כי לקורא-מסך, יש לו פיצ'ר שאתה יכול להגיד לו “תכתוב לי על המסך”. בעצם, כשאני בודק על קוראי-מסך, אני הרבה פעמים עושה את זה בלי האודיו - כי בעצם זה מקפיץ לי עם Pop-up כזה, שמראה לי את הטקסט כאילו שהייתי שומע.(רן) . .   זה למעשה “כותב-מסך”, זה לא “קורא-מסך” . . .(אסף) כן, נכון - וזה גם גורם לזה שאני יכול לעבוד עם זה נגיד ב-Open Space, וזה פשוט לא משגע את כולם.ואז נגיד הוא מראה לי את רשימת הלינקים ואני פשוט רואה שכתוב לי לינק אחד, לינק אחד, לינק אחד . . .“אני פשוט לא מבין מה זה הלינקים האלה, בוא נפתור את זה איכשהו”.כלומר, הדברים הגדולים יקפצו עליך. אחר כך, לגבי אם אתה אומר האם הטקסטים שלי נכונים? האם זה באמת מה שצריך?זה באמת כבר רמה אחרת. אם אתה במקום הזה, אז אתה כנראה מראש יש לך את הבסיס.והרבה פעמים במצב הזה כנראה או שתשתמש בכלים שיודעים לעשות איזושהי סימולציה כזאת, או שיש דברים שבאמת אין להם תחליף, גם עם הכלים האוטומטיים הכי הכי טובים, אין לך תחליף בסוף ללעשות קצת רעיונות משתמשים או להביא Audit.חברות גדולות, אגב, שזה קצת גם לגבי ה-Flow של העבודה וזה גם מתחבר לשאלה השנייה - בחברות גדולות, בכלל איך נגישות עובדת?כמו שאמרת קצת עם Security - יש לך בסוף איזשהו מוקד ידע.  יש לך Accessibility Expert, יכול להיות שיש לך צוות של כאלה . . .היחס, אגב, בדרך כלל בין מפתחים לבין אנשי Accessibility הוא יחס מאוד מאוד נמוך.גם כי יש יחסית פחות כאלה - זאת אומרת, יש מעט מומחים.אבל גם זה פשוט ככה זה . . . והם תמיד מוצפים.בגלל זה גם בעצם כלים אוטומטיים יכולים מאוד לעזור פה - כי שוב, גם ה-Scale פה הוא מטורף.כי אם עשית גיוס ענק, אתה תגייס המון מפתחים - ולאו דווקא תגדיל את הצוות נגישות שלך.גיוס של כסף, הכוונה.(אורי) כן, אתה פשוט מוסיף משימה לצוות Accessibility - “תכתבו אוטומציות” . . .(אסף) כן, לפעמים באמת זה ככה, לפעמים, הצוות Accessibility הוא באמת אחראי לכתוב אוטומציות.אם זה המצב, אז הרבה פעמים . . .אגב, אנשים שמתמחים ב-Accessibility לא דווקא ידעו לכתוב אוטומציה - שוב, כי זה Skill-set שהוא קצת אחר.יכול להיות שזה חבר'ה שמגיעים מכל מיני עולמות - יכול להיות שמגיעים עולם של QA, יכול להיות שזה . . . יש הרבה אנשים בעלי-מגובליות שככה בעצם נותנים את השירות הזה. לצערנו, יכול להיות שזה גם מה שיקרה פה, בעצם במצב הפקקטה שאנחנו נמצאים בו . . .אבל מבחינת איך שזה עובד, באמת יש בחברות צוותי נגישות - והצוותי נגישות הרבה פעמים נותנים ייעוץ לכל הצוותים.  אנחנו פה מדברים אגב הרבה על הקשר, בעצם על האחריות שלנו למפתח - אבל אני רוצה להגדיל את זה טיפה. כי לפתור את זה ברמת המפתח זה טוב עד גבול מסוים . . .(אורי)  זה גם קצת מאוחר מדי, נכון?  כי אם המעצב יכול לפתור את זה עוד לפני...  (אסף) אני יכול לתת שתי דוגמאות. למשל, ניגודיות צבעים זה משהו שיחסית קל להבין אותו, כי אם אני עכשיו אקח רקע לבן ועשה עליו טקסט אפור בהיר, כנראה שיהיה לנו מאוד קשה להבין מה כתוב שם.אם הלוגו של החברה, שהודפס על נירות מכתבים - ומכתביות, מתנות לילדים, כוסות ובענק כבר על בניין  - והלוגום הזה, יש לו בעיה של ניגודיות צבעים . . .אני, בתור מפתח, הרצתי איזשהו כלי שבודק גם ניגודיות צבעים, וראיתי שיש שם בעיה.אבל אני בתור מפתח לא יכול לשנות את הצבעים. אין לי מה לעשות עם הדבר הזה. כלומר, אני יכול לגשת עכשיו למעצב, המעצב צריך ללכת למנכ״ל לשכנע אותו, שעכשיו צריך להוציא אינסוף כסף על שינוי של הדבר הזה.כלומר זה בוודאות,  זו דוגמא קצת קיצונית . . . (רן) בוא נגיד, זאת אומרת, זה לא רק הלוגו - זה הרבה פעמים גם מדבר על פלטת הצבעים של האתר. זאת אומרת, על כל הצבעים של ה-Brand, זה לא רק הצבע של הלוגו. (אסף) לגמרי. גם בניגודיות צבעים יש גם עניין, נגיד, של העובי של הפונט.כלומר, יש פה ממש . . . כאילו הטיפוגרפיה הספציפית, עד כמה האות צריכה להיות עבה יחסית לרקע שלה . . .אבל אם עושים את זה מאוחר מדי אז המחיר יכול להיות מאוד גבוה,וחלק מהמחיר  אגב זה גם הכמות דיונים המאוד גדולה שהולכת להיות, זה גם מחיר.כי בעצם, לעשות שינוי החלטות כאלה - כבר יש פה ממש החלטה שהיא סמי-פוליטית כזאת.עכשיו יותר מזה - בוא ניקח דוגמה קיצונית -  אתר או אפליקציה של פיצות. אני חובב פיצות, זה מאוד טעים . . .יש אפליקציות ממש מגניבות של פיצות שעשות לך, שאתה יכול לעשות Drag & Drop לתוספות, זה מאוד מאוד נחמד.אומרים לך “אתה רוצה חצי פיצה זיתים וחצי פטריות?(רן) אני רוצה Tab! אני רוצה Tab! אני לא רוצה Drag & Drop . . .(אסף) אני לא רוצה פיצה, אני רוצה טאבים . . .  אז זה מאוד מאוד נחמד - אבל מי שלא יכול לעשות Drag & Drop פשוט בחוץ. ועכשיו . . .(רן) . . .  שיאכל בלי תוספות . . .(אסף) . . . שיאכל בלי תוספות, או . . .אז אם הדרישה היא מראש לא נגישה, אין למפתח מה לעשות פה. כלומר, הוא יכול “להרים דגל”, אבל אבל מי שצריך להחזיק בראש שהמוצר יהיה נגיש זה בעצם  . . . צריך לקחת אחורה קצת - או שמאלה, Shift-Left - צריך להסתכל בעצם גם המנהל מוצר או הדרישות העסקיות או המעצבים, שבוודאות צריכים לפחות להכיר בגדול מה זה אומר נגישות, בשביל לבנות את אפשרות התוספות הזאת.(אורי) 17% מההכנסות . . . .(אסף) זה גם נכון, נכון יש פה כמה מוטיבציות.40:46 סימנים מטרימים וקווים מנחים, לא AI(רן) כיף לנו בשיחה הזאת, אבל אנחנו כבר רוצים ככה לשאוף לקראת סיום. אז יש כמה נושאים שלא נגיע אליהם, למשל מה התפקיד של AI ו-Machine Learning בכל הסיפור הזה - בין אם לטובה ובין אם לרעה, אני בטוח שיהיה גם וגם . . . (אורי) . . .  די, רן, די . . . .(רן) . . . אני אמרתי שלא נדבר על זה, נו . . .(אסף) אפשר, אם אתם רוצים . . .(רן) . . .  אבל כן יש נושא אחד שכן רציתי קצת לכסות, וזה שאנחנו, כאנשי Frontend ובכלל כמפתחים, אוהבים להשתמש בספריות, נכון? ספריות הן יפות, הן כיפיות, הן נותנות לנו כל מיני קומפוננטות (Components) . . .(אורי) . . . והן מתיישנות תוך שבועיים . . .(אסף) . . .   אין על ספריות . . .(רן) . . . וחוסכות לנו מלא מלא עבודה. אבל השאלה שלי היא איך אני, כמפתח Frontend, יודע שהספרייה היא “כשרה”.  כלומר, איך אני יודע שהספרייה היא Accessible או Accessibility-Friendly? מה הם הסימנים המטרימים, כדי שאני אוכל לדעת שבאמת אפשר להשתמש בספרייה הזאת ושאני לא הולך אחר כך להתחרט על זה?(אסף) שאלה מעולה. אני יכול לשתף - שוב, “צר עולמי כעולם נמלה” - אני יכול לשתף במחקר שאנחנו עשינו, בשביל הפיתוח שלנו. שוב, אנחנו צריכים להיות נגישים.זה גורם לנו לאכול הרבה הרבה הרבה "אוכל כלבי” [Eat your own Dog Food].  אז אנחנו ניסינו למצוא ספרייה שתענה לנו על כל מיני צרכים - וזה מאוד מאוד קשה, כמו שאמרת.אין באמת ספריות שהן נגישות במאה אחוז . . . גם שוב, השאלה לאיפה אתה . .  האם המטרה שלך זה עכשיו לענות על הסטנדרט - שזה כאילו יעבור איזה שהוא טסט אוטומטי כזה או אחר ברמה כלשהי - או שאתה רוצה שזה באמת יהיה נגיש. שוב, הדוגמא עם ה-Alt-Text - זה יעבור מבחן אוטומטי פשוט, אבל זה לא באמת יפתור את הבעיה לבעלי-מוגבליות, אוקיי? אז אני כן אתן איזה שהם קווים מונחים.  דבר ראשון, לשאלה מה יותר נגיש React,  Vue או Angular - בשביל להוסיף עוד אש למדורה, או Svelte, אם בחרתי משהו חדש . . . אז התשובה היא שאין. כלומר, אין קשר בין ה-Framework לבין רמת הנגישות שלה, לפחות לא שאני יודע. כלומר, אין משהו יותר נגיש משהו אחר -  תשמשו במה שבא לכם, אני לא אפתור לכם את הדילמה הזאת. מבחינת ספריות, יש ספרייה של Adobe שקוראים לה Adobe Spectrum, שהיא ספרייה שיש לה Mode כזה של Headless, שבעצם, היא נותנת סמנטיקה של כל מיני קומפוננטות (Components).והיא אומרת, בעצם, “אנחנו נותנים לכם סמנטיקה שהיא נגישה, ואתם יכולים להנגיש את ה-UI שלכם”.אם תעשו את ה-UI שלכם שיהיה עם ניגודיות צבעים גרועה, או משהו כזה - אז זה לא ינגיש, אבל בגדול זה בסיס שהוא די טוב. שוב, אי אפשר לחתום על שום דבר, אבל זה כיוון.יש הרבה ספריות שיש להן . . . אני יכול להגיד לכם מה הקווים, מה הדגלים האדומים.בגלל ש-Accessibility זה משהו שצריך לעבוד עליו,  אז אם אתם מסתכלים על ספרייה ואין בה את המילה, לא כתוב Accessibility, לא כתוב A11Y, שזה Accessibility בקיצור כזה, אז כנראה היא לא Accessible.כי מישהו שעבד על Accessibility, יכתוב שעבד על Accessibility. זה הרבה עבודה, זה אמור להיות בדף הפותח, או לפחות איפשהו בדפים הראשונים שמתארים את הספרייה.ספרייה שאין לזה - רוב הסיכויים שהיא לא תהיה נגישה. (רן) אוקיי, בסדר גמור. זה כמו שלא הייתם כנראה משתמשים בספרייה שאין לה Unit tests, או עוד כל מיני סימנים אחרים.44:18 עוד קצת על Evinced לסיכום(רן) בסדר גמור, טוב - תודה רבה אסף! יש כמה נושאים שלא הגענו אליהם, מן הסתם, אבל זה בסדר, נשאיר משהו לפעם הבאה.(אורי) . . .  לא היה להם Tab Index . . . (רן)  כן . . . אז אולי עוד כמה מילים על Evinced - החברה: קצת איפה אתם יושבים, אם אתם מגייסים, מה אתם מחפשים?(אסף) אז אנחנו מחפשים, אנחנו מגייסים.אנחנו יושבים ליד עזריאלי בשרונה, בבית -  במשרד - מאוד מאוד חמוד.אנחנו גדלים - ומחפשים Frontend-סטים, Backend-סטים, Data Scientist ואנשים שעושים AI, סליחה, והם ראשי צוותים, בעצם מגייסים להמון משרות.בואו - צרו איתי קשר ב-LinkedIn או ברחוב ואני אשמח להעביר קורות-חיים שלכם.(רן) מה עושים אצלכם עם Data Scientists?(אסף) Data Scientists, למשל, עוברים על כמות אדירה של אתרים, ומנסים להבין ולמצוא דפוסיםמעבר לניתוחים סמנטיים, להבין למשל איך באמצעות עיבוד תמונה בשילוב של סמנטיקה,  אפשר לדעת למשל שמשהו שאין לו סמנטיקה של כפתור הוא בעצם כן כפתור.או לעשות דברים שהם יותר חכמים. למשל, נגיד ניתן עוד דוגמא - נגיד אם יש לך כפתור שאמור לפתוח Pop-up, אתה אמור לתקשר את זה איכשהו, כדי שמישהו שלא יודע מה קורה שם ידע שהכפתור הזה לא מעביר אותו למצב אחר, אלא עושה . ..  פותח לו “פורטל” כזה.ה-Pop-up בעצם משתלט לך על כל המסך, אתה בעצם לא יכול לגשת למה שנמצא מאחורה.  אז צריך לתקשר את זה.אז אם אנחנו נדע איך לזהות את הדבר הזה או איך למצוא דפוסים אחרים,  אז בעצם יש פה הרבה שילוב של Data Science ו-AI.  (רן) הבנתי. זאת אומרת, ניתוח אוטומטי של מקרים נפוצים והבנה של איך אפשר לטפל בזה.בסדר גמור, מעניין מאוד. תודה רבה.  שיהיה לכם בהצלחה.46:17 המסייעת(אסף) ויש עוד פרויקט אחד שלא קשור לזה - אז יש פרויקט שהוא לא קשור בכלל לנגישות, שקוראים לו MesayaaTech.זה פרויקט מאוד מאוד מגניב, שבעצם עוזר למילואימניקים שנתנו המון המון המון בשנה וחצי האחרונות, משהו כזה.(אורי) . . .  שנה-ויותר-מדי . . .(אסף) . . . שנה-ויותר-מדי האחרונות - שחלקם סטודנטים שנשלפו מהתואר שלהם, חלקם בעלי משפחות, בעלים, בנים, בנות, הכל.בעצם עוזר להם למצוא את הדרך שלהם לעולם העבודה, לעולם ה-Tech. אם זה עזרה בראיונות, אם זה למנטר, חבר'ה ללוות אותם. בואו, זה אחלה פרויקט, עושים דברים ממש-ממש יפים - ויש הרבה הצלחות.(רן) כלומר, אם אתם יודעים לראיין, ראיינתם, ואתם יכולים לעזור לאנשים להתראיין, לעזור לאנשים למצוא משרות - אז אתכם צריכים. איך יוצרים קשר?(אורי)  אני חושב שגם “סתם ליווי” . . . (אסף) לגמרי . . .  לגמרי גם סתם ליווי, גם זה יכול להיות...  אם אתם פשוט בתעשייה מספיק זמן, אתם לא צריכים לדעת לראיין - כנראה יש לכם מספיק קשרים יותר מאשר מישהו שעכשיו סיים שנה שלישית בעברית או משהו כזה.(רן) איך מגיעו ל-MesayaaTech? (אסף) אז מחפשים MesayaaTech ב-LinkedIn.זה לא פרויקט שלי, זה פרויקט שאני הצטרפתי אליו.אגב, אם אתם שומעים ואתם מילואימניקים - אז גם: יש, בואו ותתחברו לזה.מעולה, תודה רבה גם על זה. להתראות.  תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 492 של רברס עם פלטפורמה, שהוקלט ב-20 בפברואר 2025. רן מארח ב-Remote את עמית מהבנק הדיגיטלי One-Zero כדי לדבר  על פרויקט של בוט חדש - Ella - שמפותח בחברה.🎗️ 00:49 עמית ו-One-Zero (רן)) עמית,  כמה מילים עליך וקצת על הבנק, אולי יותר מהזווית הטכנולוגית שלו?  שוט . . . (עמית) אז קודם כול, נעים מאוד, אני עמית. אפשר להגיד שפחות או יותר גדלתי בעולם הזה של AI ו-Machine Learning.התחלתי את הדרך שלי בתחום אי-שם,  כשהייתי בן 13 - למדתי מתמטיקה בתוכנית של הילדים שלומדים מתמטיקה באוניברסיטה. התחלתי את התוכנית הזאת שנתיים מוקדם מהרגיל,  אז סיימנו את התואר וכל החברים שלי התגייסו לצבא ואני הייתי עדיין קטן,  אז נשארו לי עוד שנתיים.  בזמן הזה עשיתי תואר שני, גם כן בעולמות ה-Data,  שם התחלתי בעצם לראשונה להיכנס ולהיחשף לעולם הזה, והתחלתי לעבוד בתור מפתח תוכנה.אחרי שנתיים סיימתי את התואר, התגייסתי לצבא, הייתי חמש שנים כמעט ב-8200,  בתפקידים של מחקר טכנולוגי בכל מיני עולמות אקזוטיים.ואחרי כמעט חמש שנים של שירות הגעתי לחברת FinTech שקוראים לה Pagaya. הייתי שם באזורי Data Science ו-Machine Learning.כש-Pagaya היא חברה שמאוד מאוד מאוד מבוססת סביב Machine Learning.מחלקת Data Science [שהיא] אחת הגדולות בישראל, כל המוצר של החברה בעצם סובב סביב העולמות האלה, אז זו הייתה ככה תקופה מאוד מגניבה. ואחרי שלוש שנים ב-Pagaya הגעתי ל-One-Zero,  לנהל את המחלקה של הData ו-AI בבנק.כשבעצם התפקיד הזה של לנהל את המחלקה של Data ו-AI,  זה כולל, אפשר להגיד, שני כובעים מרכזיים:הכובע הראשון זה מחלקת Data, כמו בבנקים אחרים - Data Engineering, Data Analytics, Data Science,  מודלים על לקוחות . . .  כל השימוש, בעצם, במידע הפיננסי או המידע הבנקאי שקיים בבנק. והכובע השני,  שהוא באמת הפוקוס של השיחה שלנו היום,  זה פיתוח של מוצר ה-Generative AI של One-Zero,  - אלה (Ella) - שהיא בעצם “בנקאית AI”.הבנק הוקם על ידי פרופ' אמנון שעשוע, שעושה AI בכל מיני תחומים, וב-One-Zero עושה AI בתחום הבנקאות.הראשונים בישראל לעשות את זה, ובין הראשונים גם בעולם. ב-One-Zero - כמה מילים אולי על הבנק:  אז הבנק הוא בנק דיגיטלי,  הוא קם אחרי המון שנים שלא הוקמו בנקים חדשים בישראל. בעצם הבנק - מעבר למוצרים הפיננסיים שלו, של הלוואות,  פיקדונות,  ניירות ערך, כל האזור הפיננסי - הבנק,  אפשר להגיד,  חרט על דגלו את ה...  “לתת שירות של בנקאות פרטית לכולם”. זאת אומרת,  לבוא ולתת לכל לקוח של הבנק את החוויה הזאת של  בנקאי פרטי,  כמו שיש לאנשים יותר עמידים.והדרך לעשות את זה בעצם היא או באמצעות להעסיק המון-המון בנקאים, כמו שעושים בבנקים אחרים בעולם,  או באמצעות הרבה-הרבה שימוש באוטומציה ו-AI,  כמו שאנחנו עושים כאן.רק לסבר את האוזן על המספרים - היום ב-One-Zero,  מעל 80% מהשירות-לקוחות שלקוחות מקבלים מגיע, קצה-לקצה, באמצעות AI.זה מאפשר לארגון לגדול מאוד בכמות הלקוחות שלו,  בלי להגדיל את כמות הבנקאים שצריך להעסיק.אז זה, ככה, טיפה עליי וטיפה עלינו.04:19 ארונות שחורים עם אורקלים שרצים בחושך(רן)  מעולה. אז זה גם חושף את המוטיבציה ותיכף נדבר גם על אתגרים של איך בכלל עושים פלטפורמה כזאת של  AI ב-Setting של בנק,  שהוא מאתגר כנראה עוד יותר ממקומות אחרים, בהקשר הזה.אבל אולי קצת לפני זה - אנ סקרן ואני חייב לשאול אותך:  אמרת שאתה מנהל את מערכות ה-Data של הבנק, ואני תוהה, נגיד עד כמה עצם זה שהבנק הוא יחסית חדש ויחסית דיגיטלי, עד כמה זה משפיע על מערכות ה-Data שלכם,  למיטב ידיעתך, נגיד לעומת מערכות Data של בנקים אחרים? האם אצלם זה ארונות שחורים עם אורקלים שרצים  בחושך ואצלכם זה AWS, או שהדמיון רב על השוני?(עמית) אז אין ספק שיש יתרון עצום בלהיות ארגון שמתחיל את הדרך שלו בתקופה שכבר הטכנולוגיה מאוד מפותחת. בסוף, כן - אצלנו, מן הסתם, הכל ב-AWS, הכל בענן,  עובדים עם הכלים הכי מתקדמים.ה-Data ב-Snowflake . . .  זאת אומרת, בסוף אנחנו בכלים הכי-הכי מודרניים ומתקדמים שקיימים. לא עבדתי בבנקים אחרים,  אבל כן דיברתי קצת עם אנשים ושמעתי דברים מסביבי אני יודע שבבנקים אחרים הושקעו מאמצים אדירים, ברמת עשרות ומאות-מיליונים, כדי בעצם לעשות תהליכים של דיגיטל, לעבור מאותן מערכות Legacy, שנבנו לפני עשרות שנים ,למערכות שהן יותר חדשות, יותר מתקדמות. חלק מהבנקים הצליחו יותר, חלק מהבנקים עדיין בדרך.ואין ספק שזה שאנחנו התחלנו כשהטכנולוגיות כבר בשלות זה דבר שמאוד מאוד הקל עלינו באספקט הזה. (רן) בקיצור, יותר כיף אצלכם, לפחות בהקשר הזה.(עמית)  טכנולוגית, כן.06:07 קורא לה(רן) אוקיי, בסדר, אז בואו נעבור לדבר על Ella. אז Ella, כמו שאמרת, זה בעצם בוט שעוזר ללקוחות לקבל שירות לקוחות  ברמה של “לקוח פרימיום”, או לא יודע איך שנקרא לזה. זאת אומרת, עוזר לקבל החלטות, להבין מה המצב,  לעשות פעולות וכו’.  אז אולי אחד הדברים שאנשים, כשמגיעים לעולם של AI,  באים ועושים, זה פותחים את ChatGPT,  כותבים לו כמה שאלות או נותנים לו כמה משימות - וראה איזה קסם!  הכל עובד והכל מצוין,  ונראה שזה ממש קל . . .   כאילו,  אוקיי,  אז יופי,  אז אני אשים גם אחד כזה בבנק שלי. החיים כנראה מלמדים אותנו אחרת . . .אז בוא ללמד אותנו - מה לימדו אותך החיים?  כלומר, כשבאתם לעשות את זה, מה מצאתם מאתגר? איך התגברתם על זה?  נצלול אולי לחלק מהמקומות האלה.(עמית) תראה, אז אני חושב שכמו שאמרת - וגם רואים את זה משיחות עם ארגונים אחרים - ארגונים בדרך כלל נוטים לחשוב ששילוב של AI במערכות זה הולך להיות קל, כי כולם רואים את ChatGPT וכולם רואים את  ה-API ש-OpenAI חשפו וגם חברות אחרות - ואומרים לעצמם “אה, מגניב! אני אקח את ההודעות שהלקוח שולח, אני אעביר אותן לקסם הזה של ChatGPT ואני אקבל את התשובה חזרה!”ובחיים האמיתיים זה לא עובד, כי אני חושב שהיום אנחנו כבר . . .  העולם עבר איזושהי התבגרות, ולאט-לאט מבינים שזה לא עובד ככה, ושהעולם הוא מורכב.ובטח ובטח אם אתה ארגון רגיש או ארגון רציני,  אתה צריך לעמוד מאחורי מה שהעובדים בארגון שלך אומרים, גם אם זה “עובדי-AI” וגם אם מאחורי הקלעים יש מנוע LLM.(רן) כן, אז בוא למשל . . .  אולי פה מישהו מכיר את הסיפור של Air Canada, שאני אזכיר אותו בקצרה - שהם גם יצרו איזשהו בוט,  איזשהו Chat שעוזר בשירות לקוחות, והאמת היא שאני לא יודע באיזו טכנולוגיה הם השתמשו מאחורי הקלעים,  אולי זה אפילו היה לפני עידן ה-GPT, אני לא זוכר מתי זה היה, אבל לפני כמה שנים -  ובעצם לקוח התייעץ עם אותו בוט, והבוט המליץ לו על איזושהי הטיסה,  וגם אמר שיש איזושהי הנחה,  וזו כמובן הייתה טעות. אבל זה היה מספיק בשביל הלקוח כדי, אם אני לא טועה, בסופו של דבר לתבוע את המחיר שאותו הבוט הציע ולקבל כרטיס במחיר אפסי -  אני לא יודע אם זה היה אפס לגמרי או פשוט מאוד נמוך -  וכמובן שהחברה הפסידה על זה, אבל הם היו צריכים לעמוד מאחורי האמירה של אותו בוט.  אז זו דוגמה רק לאחת מהסכנות שיכולות לקרות,  וכמובן שאם Ella הולכת להציע הלוואה בריבית של מינוס עשרה אחוז,  אז אתם בצרות גדולות . . .(עמית)  כן.  אז קודם כול - לגמרי.  יש מקרים כאלה, ואני מזמין אותך ואת המאזינים לחפש בגוגל כזה  “AI Failures”, ואפשר לראות המון מקרים של פדיחות ש-AI עשה ב-Production מול לקוחות.חשוב להגיד -  יש את המקרים הגדולים של Chevrolet הבטיחה רכב בדולר, או Air Canada, כמו שהזכרת או מקרים כאלה דומים. אבל בסוף-בסוף בארגונים יש גם את החיים עצמם.  וכמו שאתה אומר, בסוף בארגון יש המון פרטים והמון תנאים ומוצרים,  ואם הלקוח קיבל הלוואה בתנאים כאלה או המרת מטבעות בתנאים כאלה ואחרים,  זה דברים שיכולים להעלות לבנק באמת הרבה כסף.ולכן ה-Quality פה הוא סופר-סופר קריטי וזה לא מספיק לנו להשתמש במערכות שנותנות 80% דיוק או 90% דיוק. (רן) כן, אז בעיה אחת שעולה פה - בוא ניתן לה שם - נקרא לזה הליביליות (Liability) או אולי האחריות או היכולת: הצורך של הבנק לעמוד מאחורי המילה של אותו בוט,  ולכן אנחנו גם לא היינו רוצים שהוא יגיד שטויות וימכור אותנו בזול מדי . .   אז אחד זה ליביליות.מקודם רמזת על, נגיד, השימוש לצורך העניין ב-GPT בתור איזשהו Backend. כלומר, לוקחים את ה-Input של הלקוח, מעבירים את זה ל-GPT ומחזירים את התשובה ממנו. אז גם פה יש אתגר, נכון? כי זה מידע פרטי של לקוח, מידע פנימי של הבנק.  אתה כנראה לא רוצה לחשוף את זה החוצה - או לפחות לא As-Is לחשוף את זה החוצה. ואז יש פה את הדילמה של, אוקיי, מה אתה עושה? האם אתה “מלבין את המידע”?  זאת אומרת, אתה עושה איזושהי אנונימיזציה או משהו כזה, או שלחילופין אתה מוצא מודלים או מארח מודלים אצלך,  ככה שה-Privacy יובטח לך.  אז זה כנראה אתגר נוסף, ואני בטוח שיש עוד.  אז אולי נדבר רגע על ה...  זאת אומרת, אולי דבר נוסף - ותיכף נצלול לכל זה - זה שיש המון מידע פנימי, גם רמזת, המון מידע פנימי של הבנק, כמו איזה מבצעים כרגע קיימים, מה השער-ההמרה וכו’, מידע פנימי שאף LLM אי-שם בחוץ לא אמור לדעת את זה. זאת אומרת, הוא לא יודע להציע לך כי הוא פשוט לא מכיר את המידע הזה, כי זה מידע פנימי -  ואז השאלה איך אתה משלב את המידע הפנימי הזה ביכולות שלו.רמזתי לכמה - אז בוא נצלול . . .(עמית)  כן, אז לגמרי.  אני חושב שיש את האתגרים, כמו שציינת עכשיו - יש את האתגרים שאתה יודע . . . כולם רואים מודלים, כולם מבינים שהם אתגרים, ויש גם, אגב, חברות שעוזרות להתמודד איתם.החל מ-Security ואיזה דברים אנחנו רוצים לחשוף . . .  אני אתן Spoiler אולי להמשך, אבל בבנק - הגישה ב-Security זה “גם וגם וגם וגם וגם”. אז גם מלבינים וגם לא שולחים את המידע החוצה וגם לא חושפים שום דבר למקורות חיצוניים וגם עושים המון המון אבטחות על כל Input שנכנס למודל. אז זה באספקט הזה.יש כמובן את כל העולם של הזיות או Hallucinations, שאנשים תמיד ששומעים על AI, הם מיד הם חושבים על “רגע, אבל לפעמים הוא אומר לי שטויות!  לפעמים אני שולח ל-ChatGPT שאלה ואני מקבל תשובה שלא קשורה למציאות!אתה אומר לו “רגע - מה פתאום, בעצם התשובה צריכה להיות ככה”,  והוא מייד מתקן את עצמו, שזה דבר שאגב בארגון שמתחייב על מה שהוא אומר, זה יכול להיות מאוד מאוד הרסני.(רן) כן. רוצה סיפור מצחיק, דרך אגב, בהקשר הזה?  זאת אומרת, אני בטוח שיש הרבה, אבל הנה, סיפור אישי קורע לב:  יש לי ילדות ושם משפחה שלי הוא תבורי,  אז רציתי להראות להן איך מנוע השפה יודע להזות. אז שאלתי אותו, מיהם ההורים של יעל, מאיה ואביגיל? השמות של הבנות שלי - יעל, מאיה ואביגיל תבורי.  נחש מה הוא ענה?  כמובן, “שימי תבורי ובן אל תבורי” -  הם ההורים של הילדות שלי . . .  אז הם רצו לשאול אותי אם יש משהו שאני יודע ושאני לא מספר להן.אבל כן, זאת אומרת - LLM, כשהוא לא יודע, אז הוא ממציא משהו שנשמע לו סביר סטטיסטית בשפה, ואז זה יכול להיות בסדר.  העובדות פחות משחקות אצלו, אבל זה כמובן אתגר רציני למי שבונה מוצר כמו שלכם.(עמית) לגמרי.  אז כל אלה הם באמת אתגרים שאנחנו -  כשאנחנו באים לבנות מוצר GenAI - אנחנו מיד נתקלים בבעיות האלה ובונים את המערכת בצורה שהיא מטפלת בכל הבעיות האלה לפני שהן קורות.בין אם זה רכיבים יעודיים כדי למנוע הזיות, בין אם זה יכולת לחשוף את המידע הארגוני שלנו למודל,  כדי שהוא לא ישתמש בדברים שהוא למד אי-שם באינטרנט.יש אתגרים גם של שפה - עם זה שהמודלים בעיקר טובים באנגלית ואנחנו פה מדברים בשפות שונות בישראל,  אז יש גם את האתגרים האלה.אבל אני חושב  שאולי הדבר  שהוא דווקא יותר מעניין לחברות  שרוצות באמת לבנות מוצרי GenAI ולשים אותם ב-Production,  זה הדברים שאנחנו רואים אחרי Production. כשפתאום לקוחות לא כותבים בדיוק כמו שציפינו שהם יכתבו.ולקוח לא שואל אותנו אם הוא יכול לבצע פירעון מוקדם בהלוואה שהוא לקח, אלא הוא כותב “אני רוצה לשבור הלוואה”.עכשיו, ברור שאין דבר כזה “לשבור הלוואה” ב-Knowledge Base של הבנק, כן? הוא רוצה להגדיל מסגרת, הוא רוצה להמיר דולרים.בסוף יש...  ה-Input הוא . . .(רן) . . .אל תשלח אותו לזגג . . .  אם הוא רוצה להגדיל מסגרת, אל תשלח אותו לזגג, שיעשה לו מסגרת חדשה . . .(עמית) לגמרי. (עמית) בסוף, אתה יודע, את הלקוח זה לא מעניין שהוא לא כתב כמו שאתה התכוונת שהוא יכתוב.הוא רוצה לקבל תשובה, ואם הוא לא יקבל תשובה, הוא יפתח Ticket לבנקאי - ואז הבנקאים יצטרכו לעבוד על הרבה פניות שהיו יכולות להיפתר לפני.אנחנו רואים שהרבה פעמים לקוחות גם - בין אם זה בתמימות - שואלים ומשתמשים במונחים לא נכוניםאו מתוך איזשהו רצון להשפיע על המערכת ולהתנהגות שלה.דברים שפוגשים ב-Production, כשנתקלים בעולם האמיתי.(רן) כן, מעניין גם אם יש שוני - זו אולי שאלה קצת בפסיכולוגיה . . . - אם אתה יודע שעומד מולך בוט, ואני מניח שזה שקוף ללקוחות שלכם, אבל אם אתה יודע שעומד מולך בוט, האם אתה מתנהג אחרת? כלומר, כותב דברים אחרת, אולי  מנסה כמו שאמרת אולי “לעבוד עליו” באיזשהו אופן, שלבנאדם אמיתי לא היית עושה את זה?(עמית) כן . . .  אז קודם כל, לגמרי כן.ואני חושב שזה פוגש אותנו בשני מקומות - אחד זה  בצד של האמון של הלקוחות במערכת, ואחד זה באופן שבו הם מתנסחים מול המערכת.מהצד של האמון, אז ראינו בהתחלה - היום כבר פחות רואים את זה - אבל בהתחלה ראינו שהיו הרבה מקרים שלקוחות שאלו שאלה, קיבלו תשובה מ-Ella -  אבל הם כאילו לא סמכו על זה.הם כאילו אמרו “רגע, זה AI, הארגון לא באמת מחויב לזה” - והם היו הולכים ושואלים את הנציגים האנושיים בדיוק את אותן שאלות, בדיוק כמו שהיה לפני.והם היו מקבלים את אותה תשובה, כי הנציג האנושי גם כן רואה את השיחה שאותו לקוח ביצע מול Ella.והנחינו בעצם את הנציגים לבוא ולהגיד להם שהם יכולים לסמוך על התשובה שהם קיבלו מ-Ella - שהארגון עומד מאחורי מה ש-Ella אומרת, גם במקרים שזה “עולה לו”.וראינו, עם הזמן, שבאמת גם כמות הפניות מהסוג הזה הולכת ומצטמצמת, וגם שהלקוחות מרגישים באמת יותר בנוח, כי האירגון עומד מאחורי זה.הצד השני, מעבר לאמון, זה לגבי אופן ההתנסחות -  ואנחנו רואים בצורה מאוד מאוד מאוד ברורה, שלקוחות מדברים  עם בוט אחרת מאיך שהם מדברים עם אנשים, ולקוחות מדברים עם בוט היום אחרת מאיך שהם דיברו עם הבוט לפני חודשיים או שלושה.  תחשוב איך אתה מתנהל מול ChatGPT, נכון? בהתחלה כולם היו כותבים כזה Propmt-ים “Fancy” כזה - “תתנהג כאילו אתה ככה” ו”בבקשה, זה ממש חשוב לי” וכל מיני דברים כאלה.והיום זה כזה, לא יודע - ”תכתוב לי מייל”, כן?  זה הצורה שאנחנו מתנהלים עם...  (רן) היום אתה כמעט מצפה שהוא יקרא את המחשבות שלך . . .  “נו, תעשה את זה, לא הבנת?”(עמית) לגמרי, לגמרי. ואנחנו רואים שבסוף אנשים גם משנים את האופן שבו הם מתנסחים מול Ella,  לפי מה שהם רואיםאיך התגובות שהם מקבלים יותר טובות, מתי הם יותר מקבלים מענה.הם מבינים שאם הם שואלים את השאלה בצורה יותר מפורטת ויותר ברורה, אז הם יקבלו תשובה שהיא יותר מדויקת למה שהם רצו. וזה, האמת, דבר שמצד אחד זה די מדהים לראות אותו - ומצד שני, הוא גם משפיע על הארגון בזה שאנחנו חייבים כל הזמן להתאים את עצמנו לאיך שלקוחות מתנהלים בשטח.(רן) כן. דרך אגב, בעולם של Machine Learning ו-Data Science זה נקרא Data Drift.  כלומר, אתה סוג-של אימנת את המודל שלך על סוג מסוים של Data, ועם הזמן המציאות משתנה ואז יש לך איזשהו Drift או אולי Concept Drift זה אולי הדבר היותר נכון.  אבל כן, למרות שאולי פה ספציפית יכול להיות שאימנת, יכול להיות שלא אימנת . . .  זאת אומרת, לא דיברנו עוד אם עשיתם איזשהם Finetuning או לא,  אבל בלי שום קשר, “כיילת” את המערכת לסוג מסוים של התנהגות של משתמשים, ובסוף,  עם הזמן ואולי דווקא בגדל הפידבק הזה של המערכת,  אולי בגדל השימוש שלהם במערכת,  הם למעשה משנים את ההתנהגות שלהם ואתה צריך לכייל את המערכת מחדש.(עמית) כן, וחשוב להגיד שזה גם לא רק הלקוחות. זאת אומרת, הלקוחות משנים את ההתנהגות שלהם - אבל גם במציאות משתנה, העסק משתנה, המידע משתנה,  היעדים העסקיים משתנים . . .זאת אומרת,  המערכת היא חיה כל הזמן - ואנחנו כארגון  צריכים כל הזמן להמשיך לעשות את ההתאמות,  גם במודלים וגם במבנה של המערכת כולה, כדי להמשיך לתמוך בזה.19:02 שימוש פנימי ואלות שונות(רן) דרך אגב - אותו כלי, או אולי כלים דומים, גם משמשים את עובדי הבנק בפנים?  כלומר, אם עובד הבנק רוצה לשאול משהו את המערכת שלכם,  האם הוא גם ישתמש בממשק דומה?(עמית) כן.  אז יש כלי AI אחרים בבנק, אבל בסוף Ella - היא מיועדת לשימוש של מול לקוחות, היא מציגה מידע שהוא נועד להיחשף ללקוחות.אגב,  יש עוד תהליכים שעוברים על פניות של לקוחות. זאת אומרת, אם יש פנייה שמגיעה בפועל כן לנציג אנושי - גם שם יש תהליך מבוסס-AI שעושה את ה-Handover הזה בצורה שהיא חלקה ואופטימלית עבור הנציגים.בבנק משתמשים בהרבה כלי AI, אבל ספציפית לא במוצר הזה של Ella.שווה גם להגיד - “Ella” זה שם כללי כזה, אבל יש לנו כמה “אלות ”שונות.יש Ella שמיועדת ללקוחות קיימים שצריכים לקבל שירות, יש Ella שמיועדת לעזור ללקוחות בתהליכי Onboarding, יש Ella שאמורה לעזור לנו לקנברט לידים (Convert Leads) ולהפוך אותם ללקוחות . . . זאת אומרת,  יש כמה אזורים שונים שהם כולם Chatbot-ים מבוססי-AI עם מטרות ויעדים שונים בארגון. 20:16 שפה חופשית(רן) כן.  אוקיי -  אז בוא ננסה להיכנס אולי לחלק מהאתגרים ולדבר על איך פתרתם אותם.  נגיד, אז אחד הדברים שאמרת זה לקוח מדבר בשפה שהיא חופשית, שהיא “לא בנקאית”.  זאת אומרת, מעבר להיותה עברית, שזה כבר מאתגר, אלא גם משתמש במושגים שהם לא כל כך מקצועיים וצריך לדעת לתרגם את זה. אולי לפעמים מנסה לעשות Gaming למערכת הזאת. אז זה אתגר אחד. אפשר נגיד לדבר כמה דקות על איך אתם מתמודדים עם זה? איך אתם מתרגמים את ה-Input של הלקוח למשהו שהוא  יותר מפורמל ויותר מתאים למנוע שפה?(עמית) אז אולי אני אחלק את התשובה לשניים - יש את ההתמודדות הספציפית עם הבעיה הזאת ויש את ההתמודדות באופן כללי עם בעיות,  נקרא לזה “מהסוג הזה”. וספציפית במקרה הזה אנחנו משתמשים ב  . . . המודל הזה של Ella  זה לא איזה מודל LLM אחד שעשינו לו  Fine-Tune, שיכיר את המושגים שלנו ומפה הוא חי ומסתדר.בסוף,  כשבונים Agent, יש לנו המון המון מורכבויות שונות שאנחנו צריכים להכיל.זה החל מעל מה מדברים? איך מדברים? איך מנסחים את השאלה של הלקוח? איך אנחנו כותבים את ה-Knowledge שלנו? איך אנחנו מחפשים ב-Knowledge שלנו? איך אנחנו מגדירים מה מותר ומה אסור? ובאמת הרבה  מרכיבים שונים . . .אני חושב שאחד הדברים שאנחנו עשינו יפה ב-One-Zero זה לזהות את האזורים השונים שאנחנו רוצים להתמקד בהם,  ובמקום לבנות מודל אחד גדול שהוא מין מודל ג'נרליסט (General) כזה,  שיודע לעשות הכל ב-80%,  לקחנו משימות יותר קטנות, יותר קונקרטיות של השלמה של טקסטים, או קלסיפיקציה (Classification), או תרגום, או זיהוי של פרטים או ישויות, כל מיני אזורים כאלה שונים בתהליך.ובנינו באמצעות הרבה מודלים שונים מערכת אחת שפותרת בסוף את הבעיה העסקית הזאת.לדוגמה, אחד המודלים שיש לנו זה מודל של תרגום, שהוא מודל יעודי שפיתחנו אצלנו, שמיועד להתמודד בדיוק עם האתגר הזהשל אחד - לקוחות כותבים בצורה שהיא לא תמיד בדיוק מה שהמודל מצפה לצרוך. ושתיים - לקוחות כותבים לפעמים בצורה שהיא “חסרה”.  זאת אומרת, המודל תרגום שלנו גם כן מבוסס על LLM-ים, שספציפית אנחנו עושים להם Hosting פה פנימית אצלנו,  ומאמנים אותם למטרות שלנו, שאמורים להכיר גם את הטרמינולוגיות (Terminology) שלנו וגם את  הדברים שאנחנו רואים בפועל, בשטח, שלקוחות שואלים עליהם.זאת אומרת,  יש ממש אנשים שמבצעים את התחזוקה הזאת  ויודעים כל הזמן “ליישר את המערכת” בהתאם למה שקורה בשטח.  (רן) לצורך העניין,  אתה יכול מדי פעם לעדכן,  נגיד,  את ה-System Prompt, ולבוא ולהגיד “אם הלקוח שואל על זה ועל זה,  אולי הוא מתכוון לזה, אם הוא שואל על זה, אולי הוא מתכוון לזה”.  זאת אומרת,  לייצר איזה שהם . . .  גם אוסף של דוגמאות ואפילו פתרונות ספציפיים כי זה כל כך נפוץ,  אז לפעמים זה פשוט Mapping מאחד לאחד,  אבל זה לא המודל המרכזי, או בעצם במילים אחרות -  אתה אומר שיש פה כמה מודלים שמשחקים. אחד מהם אחראי אולי לשלב התרגום מהשפה חופשית והעממית והעברית,  למשהו אחר שיותר קל ל-LLM הבא או לרכיב הבא,  אולי זה אפילו לא LLM, אבל לרכיב הבא לעבוד איתו. אבל בגדול, יש פה איזשהו Pipeline של רכיבים, חלק מהם זה מנועי שפה, חלק מהם אמרת מקודם שהם לא בהכרח. כמו שאומרים, לכל בעיה במדעי-המחשב יש בעיה ב-N+1 אבסטרקציות,  אז אפשר להוסיף משהו מעל . . .אז בעצם,  אם אני מבין נכון,  בעצם השכבה הראשונה זו איזושהי שכבת “Routing” שמבינה, כאילו, מה הבן אדם רוצה ולאן לנתב את המשך השיחה.  ככה זה בנוי?(עמית)  אז אפשר להגיד . . .   Routing בעצם זה,  הייתי אומר אולי השלב השני.  אני אתאר אולי מאוד ב-High-Level את המערכת.השלב הראשון הוא להבין בכלל מה המשימה שאני צריך לבצע.בסוף,  אם אני בונה עכשיו בנקאית-AI,  אני רוצה להסתכל על זה כאילו מדובר על בנקאי אנושי.ואני אומר, אם עכשיו לקוח היה כותב את ההודעה הזאת ב-Chat,  מה המשימה הקונקרטית והקוהרנטית שהבנקאי עכשיו צריך לבצע,  בהינתן הלקוח הזה - ההיסטוריה שלו, המידע שלו, היסטוריית השיחה עד עכשיו וכל מה שהבנקאי צריך לדעת כדי לבצע את המשימה?אז הרכיב הראשון הוא גם כן רכיב שמורכב מכמה מודלי שפה - LLM-ים ומודלים אחרים -  שמטרתו לתרגם שיחת Chat לשאלה או למשימה קוהרנטית (Coherent) שלבנקאי, לצורך העניין, הייתי יכול לפתוח לו טיקט עם המשימה הזאת.בשלב השני יש מערכת Routing, שמפנה כל משימה...  (רן) אני מניח שבכללי זה נקרא Intent, נכון? כלומר, מה הכוונת הלקוח ואיך אני עכשיו הולך לעבוד איתו על זה? אוקיי. (עמית) כן, מה היא כוונת הלקוח - וספציפית פה, אנחנו גם משלבים את זה לא רק עם הכוונה של הלקוח אלא גם ממש עם המידע שלו.המידע האישי שלו, המסלול שבו הוא נמצא, העסקאות שהוא ביצע...  (רן) כן.  כלומר - אם יש לו הלוואה שכרגע פעילה, אז אתה צריך להבין את זה כי יכול להיות שהוא שואל על זה.  אם אין לו כרגע הלוואה זה כנראה משהו אחר. (עמית) לגמרי.(עמית) אחרי זה, כשיש לי כבר את המשימה הזאת ביד,  אז אני מסתכל על זה ממש כאילו זו משימה שהייתי יכול לתת למישהו מהבנקאים פה בארגון לבצע.ואני לוקח את המשימה הזאת ומפנה אותה לאחד מכמה מנגנונים שונים שיש לנו, שיודעים לפתור משימות.כי בסוף,  גם פה זה לא מודל אחד.הדרך שלי לענות לשאלה חישובית על אלפי טרנזקציות שיש למישהו בכרטיס האשראי, היא שונה לחלוטין מהדרך שבה אני רוצה לענות לשאלה שמישהו שואל על  ייעוץ פיננסי או על “איזה פיקדון הכי משתלם בהתאם לצרכים שלי?”  או משהו על התנאים של הבנק, של כמה יעלה לו להמיר דולר לשקל.ובכל אחד מהם יש לנו ממש מנגנון אחר, יעודי, לפתור סוג מסוים של משימות.26:46 התאמות פנימיות וקופסא שחורה(רן) אוקיי.  בעצם מה שרציתי לשאול אותך עכשיו זה,  כן, זאת אומרת . . . נלך רגע לעולם של Machine Learning “הקלאסי”, אוקיי?  אז כשעובדים בעולם ה-GenAI, יש אפשרות או להשתמש במודלים מוכנים מהמדף - אתה עדיין יכול לעשות להם Hosting פנימית - אבל לקחת דברים מוכנים מהמדף או לעשות התאמות.  חלק מההתאמות נקראות Fine Tuning, אבל לא כולן - יש סוגים אחרים של התאמות שאתה יכול לעשות.  אז יש, נגיד, מקרים שבהם אתם לוקחים איזשהו מודל קיים - גדול, לא מדבר על עצי-סיווג, לא מדבר על העולם הקלאסי, אלא יותר על העולם של ה-GenAI - אתם לוקחים ואתם עושים לו אדפטציה פנימית?(עמית)  אז לגמרי, עושים את זה בלי סוף - ואני חושב שאולי ממש בכל האספקטים ובכל המקומות.זאת אומרת, החל מלעשות Fine-tuning למודלים,  לבחון סוגים שונים של מודלים, לעשות טכניקות של Prompting - בין אם זה Prompt Engineering וטכניקות חדשות שמתפרסמות,  לא יודע, אולי להגיד ברמה יומיתאפילו של איך נכון לבנות פתרונות דרך שיטות של RAG, חיפושים, איך שאנחנו בכלל מנסחים את ה-Knowledge שלנו, כל מיני שיטות Few-Shots למיניהם.אנחנו מאוד מאוד משתדלים לפתור כל בעיה עם הכלים המתאימים עבור הבעיה הזאת.(רן) כן, אוקיי. אז עכשיו בוא רגע נסתכל על זה כקופסה שחורה - ועכשיו בא לקוח ומדבר עם Ella, ונגיד הוא אומר “אוקיי, אז עכשיו תעביר בבקשה 100 דולר מהחשבון הזה לחשבון ההוא”.  זה משהו ש-Ella תעשה? כלומר, היא באמת גם עושה את הטרנזקציות עצמן? היא באמת עושה פעולות שהן בלתי-הפיכות, לצורך העניין,  או שהיא רק מתמקדת בייעוץ עצמו?(עמית) אז אני חושב שפה זה קצת מופרד בין הטכנולוגיה או היכולת הטכנולוגית שיש לנו כבנק, לבין איך מתווכים את זה ללקוח.כי הגישה שלנו זה שלקוחות עדיין לא בשלים היום לתת ל-AI לבצע עבורם פעולות בחשבון בצורה עצמאית לגמרי, בלי יכולת שליטה על זה.מה שאנחנו עושים כדי לגשר על הפעם הזה זה שבעצם הגדרנו, אפשר להגיד, כל פעולה בתור רצף של שתי פעולות:  פעולה ואישור.ועכשיו, אם אתה רוצה להעביר כסף או לא יודע מה, לפתוח הלוואה, אז מה ש-Ella תעשה זה שהיא בעצם תגיד לך “אני מבינה שזה מה שאתה רוצה לעשות - בוא תלחץ ותאשר לי”או “הנה המסך עם כל הפרטים,  בוא תבצע את הפעולה בעצמך” -  אבל במין איזשהו Self-Serving כזה.ואנחנו רואים . . .  אמרתי קודם - בנקים אחרים, ארגונים אחרים, השקיעו מיליונים ועשרות מיליונים בשביל לעשות תהליך של מעבר ל-Digital.אבל אז אתה רואה שבסוף, כשאתה צריך משהו מהקרן פנסיה שלך, למרות שהכול מונגש לך בפורטל האישי,  מה אתה עושה? אתה שולח הודעה לנציג, נכון? . . .כי זה ארוך,  זה מסובך, זה מלא דפים, זה “לך תמצא עכשיו באיזה תפריט בדיוק נמצא הדבר שאתה צריך” . . . והיכולת הזאת, לממשק שהוא טקסטואלי בשפה חופשית -  לכתוב מה אתה רוצה ופשוט לקבל את זה - זה דבר שאנחנו רואים שהוא מוריד בצורה מאוד  מאוד דרמטית את כמות הפניות שאנשים פונים לנציגים אנושיים בסוף, גם אם בפועל אנחנו לא עושים את הפעולה הבלתי-הפיכה בלי שיש להם שליטה על זה.עוד דבר שזה נותן,  אגב -  זה נותן לך את היכולת למצוא דברים בלי לדעת בדיוק מה אתה מחפש. זאת אומרת, אם לפני כמה זמן נפלתי מהקורקינט, והייתי פה ברחוב בתל אביב ורציתי רק לראות איך אני עכשיו מקבל מענה מהקופת חולים לדעת מה אני צריך לעשות.ובסוף, כשאני במצב כזה - שכואבת לי היד ואני רוצה לדעת מה לעשות - אני לא רוצה להתחיל להיכנס לאתר של קופת חולים ולחפש בתפריטים איך אני מוצא את הדרך-פעולה והשעות פתיחה.אני רוצה לכתוב ב-Chat “נפלתי מהקורקינט, מה לעשות?”(רן) כן, מה שנקרא “לקחת את הפרספקטיבה של הלקוח” - הכואב, במקרה הזה.אז אתה אומר שלגבי פעולות שהם בלתי-הפיכות, לפחות הפעולות שבהן אתם בוחרים לתמוך, אתה אומר שיש ככה שני צעדים - אחד זה לשקף ללקוח מה עומד לקרות,  ואז לתת לו את היכולת להחליט האם זה מה שהוא התכוון - התכוונת להעביר כסף? התכוונת לקחת הלוואה? תלחץ על הכפתור,  it's done. אבל עדיין זה בתוך הממשק של הבוט, זאת אומרת - בתוך הממשק של Ella.  אתה לא שולח אותו לתפריט אחר בבנק ואתה אומר לו “הנה, אתה עושה כך וכך ו...”(עמית)  אז זה תלוי בפעולות, בפעולות שנתמכות בזה.ממש נפתח לך כמו כזה חלון שיחה קטן בתוך ה-Chat, שבו אתה עושה את האישור הזה. (רן) כן. 32:01 השפעה על סביבת פיתוח תוכנה(רן) אספקט אחד שלא דיברנו עליו,  וכן קצת דיברנו עליו בשיחת הכנה, זה איך פיתוח של מוצרים,  נקרא לזה “מוצרי AI”, משפיע על כל סביבת פיתוח התוכנה.  זאת אומרת, לא רק המדענים,  לא רק המתכנתים, לא רק המהנדסים - אלא גם אנשי המוצר,  לצורך העניין,  אולי גם אנשי QA.זאת אומרת, איך בעצם State of Mind כזה של פיתוח מוצר מבוסס-AI משפיע על כל ה-Ecosystem של פיתוח תוכנה, ורציתי לקבל את הפרספקטיבה שלך - איך אתה חווה את זה?  זאת אומרת,  איזה שינויים אנשי מוצר לצורך העניין, אצלכם, עברו כדי לעבוד יותר טוב ב-Setting הזה?(עמית) אז אני חושב שבאופן כללי, זה אפילו לא רק אנשי מוצר, אלא ממש כל ארגוני הפיתוח או ארגונים טכנולוגיים באופן כללי.ואני חושב שנקודה שרואים זה שארגונים שמצליחים באמת לבנות פתרונות GenAI ב-Production, זה ארגונים שגוף הפיתוח בהם עבר איזשהו שינוי מחשבתי או שינוי תפיסתי - שמתחיל באזורי ה-Product, של בכלל איך אני מגדיר משימה?דיברתי לא מזמן עם חבר, שהוא CTO של סטרטאפ,  אז הוא ממש הפנה אליי את השאלה.  הוא אמר “איך אני מתאים את אנשי ה-Product אצלי בחברה לאפיין סוג הזה של מוצרים?”בסוף, איך אנחנו מגדירים מוצר בתוכנה סטנדרטית?  אנחנו מגדירים “יש מסך, יש כפתור, עושים ב-Figma, הם לוחצים,  אז קורה ככה” . . . ““אם יש את התהליך הזה, אז קורה את הדבר הזה” . . . (רן) פה הכל טקסט . . .  זה הכל טקסט, הכל Chat. איך תגדיר את זה?(עמית) נכון, וזה Chat שאתה יודע - יכולה להיות בו כל התנהגות, כן?אי אפשר להגדיר עכשיו סט של מאות-אלפי כללים:  “אם הלקוח כתב ככה, אז תעשה ככה, אם הלקוח כתב ככה,  אז תעשה ככה”.ובאמת דיברנו על זה קצת, ואני חושב שמשהו שהוא...  מה שעוזר לי לפחות להסתכל על זה בצורה קצת אחרת,  זה להסתכל על אפיון של מוצר GenAI באופן שהוא קצת יותר דומה אולי לכתיבה של תיאור משרה.זאת אומרת,  אני לא רוצה להגדיר בדיוק את ההתנהגות של...  כשאני כותב תיאור משרה, אני לא מגדיר בדיוק את ההתנהגות - ”העובד הזה, כשבאים, אומרים לו ככה, הוא יעשה ככה” - אלא אני כותב באופן כללי.קווים כלליים, יכולות, דרישות מאוד כלליות - אבל בלי התנהגויות ספציפיות.אבל אז מה שקורה זה שאני מגייס את העובד הזה, ואני שם לו מנהל - ואני מתחיל להסתכל מה הוא עושה בשטח אל מול ה...  בין אם זה אל מול הלקוחות או אל מול העובדים האחרים בארגון. ולאט לאט אני...(רן) . . . בוא נעצור פה,  בוא נעשה את התרגיל הזה:  אני עכשיו אהיה מנהל המוצר ואני אנסה להגדיר את דרישות התפקיד,  אוקיי?אז Ella תצטרך להיות מסוגלת לדבר עם משתמשים של הבנק, עם לקוחות של הבנק, בשפה חופשית,  זה אחד.שתיים - Ella צריכה לדעת עברית.שלוש, Ella צריכה להכיר את הלקוח ולהבין איזה...  כמה יש לו בעובר-ושב, כמה יש לו בפקדונות או הלוואות.וכו’.זאת אומרת, זה פחות או יותר ה...  - עוד לא דיברנו על היכולות שלה, עוד לא דיברנו על פעולות,  אבל אני אצטרך נגיד להגדיר דברים כמו “היא תצטרך להיות מסוגלת,  להציע הלוואות בהתאם כרגע למדיניות הבנק או בהתאם למבצעים שיש”.  זאת אומרת,  זה סוג ה-Spec שאתה מצפה כיום לקבל מאנשי מוצר?(עמית)  אז אולי אפילו ברמה שהיא קצת יותר עמוקה.הייתי מצפה לקבל Spec כמו “Ella תהיה מסוגלת לחפש במאגרי מידע ולתת תשובות בהתאם למאגר הזה”; “Ella תהיה מסוגלת להגדיר גבולות-גזרה של על מה מדברים ועל מה לא”.עכשיו, את הגבולות-גזרה האלה אני לא צריך לקבוע מראש ב-Spec -  אני אגדיר אותם אחרי זה,  ב-Production.אני אראה מה קורה,  אני אעשה אולי איזה פיילוט - ואני אבין מה גבולות-הגזרה שאני רוצה. אבל אני רוצה להגדיר שצריכה להיות היכולת להגדיר את גבולות הגזרה.(רן) “הכנה למזגן”,  או “שומר מקום” -  זאת אומרת,  צריכים להיות איזה שהם Guardrails או גבולות-גזרה,  אנחנו נדע אחר כך מה הם בדיוק.דרך אגב יכול להיות, במאמר מוסגר, שחלק מהם יהיה מאוד מאתגר לפתח - זאת אומרת,  יש guardrails שהם לא טריוויאליים בכלל - אבל זה בטוח יהיה n גדול מ-1 של Guardrails. . . .(עמית) כן -  וגם אנחנו רוצים להגדיר בעצם שתהיה לה מודל את היכולת להבין שהיכולת הזאת בכלל קיימת, כן? זה נראה לי הדבר המשמעותי יותר.(רן) כן, הבנתי.  כלומר, ברגע שאתה...  נכון.  זאת אומרת,  יש פה איזשהו אתגר מוצרי: ברגע שמשתמש נמצא מול תיבת-טקסט נקייה,  אז זה אחלה ממשק, מאוד נקי ויפה, אבל מה עושים עם זה עכשיו?  מה אני שואל אותה - על מזג האוויר?  על שערי-המטבע?  על טיסות ליוון? . . .  מה אני עושה עם הקופסת-טקסט הזאת?אז כשאתה מגיע ל-Google, כבר יש לך ציפייה, אתה יודע מה לעשות.  כשאתה מגיע היום ל-ChatGPT אתה גם יודע מה לעשות -  אבל כשאתה פעם ראשונה רואה את Ella,  אתה לא כל כך בטוח מה לעשות,  אז צריך לעזור ללקוח להבין מה עושים עם זה.(עמית) לגמרי - וזה גם אחד הדברים שאנחנו עבדנו כדי לפצח אותו בעצם, כן?  איך אנחנו מסבירים ללקוח מה המערכת יכולה.אז אנחנו,  כשמישהו נכנס, אם אתה לקוח של One-Zero ואתה נכנס ל-Chat,  במסך הבית אתה רואה כזה “שאלות לדוגמה” שאתה יכול לשאול.פעם בכמה זמן אתה מקבל איזושהי נוטיפיקציה (Notification) מאפליקציה שאומרת לך: “רוצה לדעת מה קורה בחשבון?” או “הנה קרה איזה אירוע,  בוא תראה איך הוא משפיע עליך”,  או “שים לב, זה מה שהיה אצלך - בוא תראה איזה דברים אתה יכול בעצם לקבל  מהמערכת הזאת”.וגם, אגב, במהלך שיחה ממש - זאת אומרת, יש לנו איזה מנגנון של כזה,  אנחנו קוראים לזה User Journey, כזה מסע הלקוח: שכשלקוח מנהל שיחה עם Ella, כל הזמן המערכת מציעה לו שאלות המשך שהוא יכול לשאול. עכשיו, השאלות האלה זה לפעמים שאלות שאמורות לעזור לו לקבל תשובה -  אם זה לכתוב את השאלה שלו בשפה שהיא,  כמו שאמרנו קודם, עם הטרמינולוגיה הנכונה או דברים כאלה.אבל זה גם יכול להיות כדי לעזור לנו - בין אם זה לקדם את האג'נדות שלנו או להציג ללקוחות בעצם יכולות חדשות של המערכת.(רן) . .   סוג של Auto-Complete - עוד לפני שהתחלת לכתוב או יותר כמו “Auto-Complete רעיוני”.  כלומר, אתה לא צריך לעשות Copy-Paste, אבל זה רומז לך מה אפשר לעשות.גם במשקים ויזואליים לפעמים יש את הדברים האלה.  נגיד,  אתה רואה קרוסלה של תמונות ואחת מהתמונות חתוכה - בכוונה,  כדי שתבין שאפשר לגלול,  כדי שתבין שיש שם עוד,  שיש יותר תמונות בהמשך.  אז יש רמזים כאלה בהרבה ממשקים. 38:48 הפרודקט ועוזריהם מעמים אחרים(רן) ואולי גם עוד ממש ככה סעיף אחרון להיום: אחד הדברים שאמרת שגם מאפיינים זה שמי שכותב את הקוד ומי שמפתח - אולי לא נקרא לזה “קוד”, אבל שחלק מהמפתחים הם למעשה אנשי המוצר, או אולי אנשי ה-Support, אבל זאת אומרת שזה לא רק מהנדסי תוכנה אוקיי? זה לא רק Data Scientists, אלא יש Hook-ים לאנשים במקצועות נוספים, שגם הם  יכולים למעשה להשפיע על סביבת ה-Production - וזה By-Design.  כלומר, ככה בכוונה תכננתם את המערכת וככה זה עובד.  תוכל לספק דוגמאות כאלה?(עמית) כן, אז התחלתי להגיד קודם ואולי ניגע בזה, גם לגבי עוד שלבים בתהליך הזה, בתהליך של פיתוח.אני חושב שארגון הפיתוח צריך ממש לשנות את ה-Mindset שלו,  ולהבין שדברים נראים אחרת מאיך שהם נראו  לפני שנתיים או איך שהם נראים עכשיו שאנחנו מפתחים מוצרים אחרים.ואחד הדברים האלה . . .  זאת אומרת, זה עובר מאפיון של המוצר ולעשות Design וטסטיםכשפתאום טסטים הם,  אתה יודע - “פתוחים”, כי התשובה שמתקבלת היא כל פעם שונהוזה לא “טוב, יש קלט, יש פלט,  בוא נראה שהם זהים”,  אלא צריך מודלים שיבדקו שהתשובות שלנו הן טובות.הניטור פתאום נראה אחרת . . .ואני חושב שאולי המפתח, באמת, הגדול בזה ש-Ella כל כך הצליחה, זה שיש לנו את ההבנה הזאת שהמודל הוא משהו שדורש תחזוקה בProduction - אבל לא רק תחזוקה שהיא טכנית.זאת אומרת, זה לא Service שאני צריך לוודא שהוא כל הזמן באוויר - יש לי אירוע של ניהול שאני צריך לעשות אותו כמו שאני מנהל עובדים אנושיים.ואני לא מכניס עובד לארגון שלי ואומר לו “תפאדל, דבר עם לקוחות - מפה הבמה שלך ואני אפגוש אותך עוד שנתיים”.כל הזמן יש ניטורים - עוברים על השיחות שלו,  נותנים לו הנחיות,  מעדכנים אותו על מוצרים חדשים,  עושים התאמות לפעמים בידע שחשוף אליו.זאת אומרת, כל הזמן הדבר הזה קורה - והוא לא קורה על ידי אנשים טכנולוגיים, הוא קורה על ידי אנשים מה-Business.ופתאום, כשיש עכשיו מבצע חדש או כשיש מוצר חדש או כשיש איזה יעד עסקי שמשתנה, מי שצריך להכניס את השינויים האלה במערכת, נקרא לזה הסוג החדש של הפיצ'רים למערכת - זה פתאום אנשים שהם עסקיים.זה אנשים שהם . . . ב-One-Zero,  זה אנשים שהם היו בנקאים בעבר, אנשים שהגיעו מחטיבת השירות.אנשים עסקיים, שעושים את השינויים האלה כל הזמן. ואתה יודע - כשאנחנו מפתחים תוכנה, יש לנו כלים,  יש לנו תהליכים, רוטינות . . .  אף אחד לא יעלה ל-Production קוד שלא נכתבו עליו טסטים ולא עבר Review והוא לא מנוהל באיזה Version Control, נכון? [נכון?]אבל פתאום, כש”הקוד החדש”, נקרא לזה ככה -  זה עדכונים, בין אם זה של רכיבים, של Prompt-ים, של הנחיות,  של Guardrails וכאלה, ובין אם זה ממש דברים שהם בליבת המוצר, עדכונים עכשיו של ידע שנמצא ב-Knowledge Base שלנו, ב-Vector Database שלנו.האופן שבו הוא כתוב משפיע בצורה מאוד דרמטית על האופן  שבו המודל יהיה מסוגל לענות לשאלות של לקוחות אחרי זה.ולכן גם פה צריכים לקחת את כל התהליכים של התוכנה ולהטמיע גם באזורים האלה.(רן) כן, אז אתה למעשה מדבר על ”ניהול איכות-הידע”, באיזשהו מובן. כלומר, אחד - שלא ייכנסו טעויות; ושתיים - שלא יהיו . . .  זאת אומרת,  מניח שיש עוד, אבל בין השאר גם שלא יהיו כל מיני Artifact-ים של שגיאה.  נגיד: במקרה מחקתי את הפסקה,  לא התכוונתי,  לא שמתי לב ועשיתי Commit וזהו,  נמחק לי איזשהו Block של טקסט שהוא היה חשוב. ואף אחד לא עשה לזה Review, כי זה פשוט נכנס ישר ל-Database . . .  אז זהו, אז עכשיו אף אחד לא יודע בכלל מה קרה, אין לך שום Trace של הסיפור הזה. אין לך Deployment, אין לך Commit Log, אין לך Versioning - כי אין גירסא, כי זה Data. אז יש פה הרבה אתגרים . . .(עמית) אני חושב שאחד הדברים שאנחנו כן עשינו זה שאנחנו ממש מתייחסים לזה כמו עוד קוד.שאומנם כותבים אותו אנשים שהם לא מתכנתים במקצוע שלהם - אבל בסוף זה . . . נקרא לזה “קוד Production”וזה יכול להיות הידע וזה יכול להיות הנחיות או יעדים או קונפיגורציות כאלה ואחרות - כל האזורים שבהם ה-Business פוגש את הטכנולוגיה,  המקומות שבהם Ella מקבלת את ההוראות העסקיות לאיך שצריך להתנהל.(רן) כן.43:24 עוד קצת One-Zero לסיום(רן) אוקיי - סופר מעניין, אבל אנחנו כבר חורגים הזמן, אז אנחנו נצטרך לסיים.אז אולי ככה לפני סיום, עוד כמה מילים על One-Zero -  מגייסים, מחפשים? איפה אתם נמצאים?  ספר לנו.(עמית)  כן, אז מגייסים, מחפשים: אנשים שאוהבים AI, שזה “בעצמות שלהם”.אני חושב שבתחום הזה, שהוא כל כך מתפתח - ברמה יומית יוצאות טכנולוגיות חדשות ושיטות חדשות ומודלים חדשים, מודלים יותר חכמים, יותר זולים, יותר מהירים - אנחנו צריכים המון Passion לדבר הזה כדי, נקרא לזה, לעמוד בקצב.זה סופר-מעניין,  סופר-מרגש, לעבוד על דברים שהם ממש ממש בקצה הטכנולוגי ברמת של לפעמים לפתור בעיות, ואז אחרי כמה חודשים לראות שמישהו נתן שם לפתרון שמצאת באיזה מאמר או באיזה מוצר אחר.זה ספרינט מטורף, מאוד מאוד ארוך. אני מאוד מאוד נהנה מזה וממליץ לכולם להצטרף.(רן) ספרינט שהוא מרתון - הכי כיף.(עמית)  כן, ספרינט באורך של מרתון . . . (רן) כמו שאומרים - מתחילים הכי חזק ולאט לאט מגבירים. טוב, אז תודה רבה לך ובהצלחה![קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 491 של רברס עם פלטפורמה, שהוקלט ב-11 בפברואר 2025, יום חורפי במיוחד. אורי ורן מארחים בהפסקת אש את עודד מחברת DataRails לשיחה על איך עושים AI (חביב-הקהל בפרקים האחרונים) בעולם ה-Finance והאתגרים המאוד מיוחדים בעולם הזה. 🎗️ 00:50 עודד ו-DataRails (רן) אז קצת לפני שנצלול פנימה - עודד, קצת עליך וקצת על החברה, שנכיר?(עודד) טוב, אז אני עודד הר-טל.  בן 49, זה גיל שעוד אפשר ככה להגיד חלש, לא לעוד הרבה זמן.  נשוי, אב לארבעה, גר בבית חשמונאי, בשפלה. בעולמות האלה - בעולם ההייטק - כבר יותר מ-25 שנה. עשיתי מספר משרות, בעיקר בעולמות של פיתוח אלגוריתמים, פיתוח תוכנה, ניהול פיתוח . . . ולפני עשר שנים חברתי לדידי גורפינקל ואייל כהן, והקמנו ביחד את חברת DataRails, כשאני בעצם משמש בה כ-CTO, המוביל הטכנולוגי.וזהו, מאז אנחנו שם . . .(רן) אוקיי, אז אמרנו “בעולם ה-Finance” - קצת יותר פרטים, מה אתם עושים?(עודד) אז בעצם DataRails היא חברה שמוכרת מה שאנחנו קוראים “FinanceOS”: מערכת הפעלה פיננסית לארגונים.הכוונה היא בעצם ללכת למחלקות הפיננסיות, שבעצם קיימות בכל ארגון, ולמכור להן . . . אנחנו התחלנו במקור בתוכנה אחת, בתוכנה בתחום שנקרא Financial Analytics and Planning, FP&A, שבעצם עוזרת לאנשי ה-Finance לעשות את הדוחות הכספיים, לעשות אנליזות של הנתונים הפיננסיים שלהם.והיום, עם גדילת החברה, אנחנו גם מנסים, ובעצם מפתחים סוויטה שלמה של מוצרים, שכולם מיועדים ל-CFO Office.אנחנו מוכרים לחברות בדרך כלל קטנות-בינוניות - נגיד סדר גודל של 100-200 עובדים - בעיקר בארצות הברית . . .(רן) כלומר, לצורך הדיווח, לצורת התכנון, לצורך ... (עודד) כן, בדיוק. אני מניח שהרבה מכירים את מה שנקרא, נגיד, “דוח רווח או הפסד” או “דוח תזרים מזומנים”  . . .אז זה דוחות שבעצם כל חברה עושה - פעם בחודש, פעם ברבעון - והתהליכים של להכין את הדוחות האלה הם תהליכים שהם, ככל שהחברה יותר מסובכת, זה תהליכים מסובכים, שהם מועדים להרבה מאוד טעויות.אבל הם בעצם מספרים את הסיפור של החברה.(רן) אמרת “טעויות” - אמרת “AI” . . . . תיכף נגיע . . .(עודד) גם AI עושה הרבה טעויות, כן. (אורי) אבל איפה המקום של התוכנה שלכם, או הפתרון שלכם, לעומת ה-ERP של החברה, או...  ?(עודד) אוקיי, אז בעצם מערכות ה-ERP הן מערכות שמאפשרות בעצם . . .  הן בעצם “מנהלות”אני אקרא לזה, את הטרנזקציות, את הפעולות השונות שקורות בחברה.אבל בסופו של דבר, אותה מחלקת Finance - אחד הדברים שהיא עושה, זה שהיא לוקחת את הנתונים מה-ERPבעצם “שואבת אותם” - למעשה, מערכות ה-ERP הן מערכות-מקור למערכת שלנו, אחת ממערכות המקור.ובעצם מתחילים לבנות על גבי המידע שמגיע מהמערכות האלה אנליזות שונות - בואו נעשה אגרגציה (Aggregate) של כמה הרווחנו החודש, כמה הפסדנו החודש . . . בואו ננסה להשוות את זה לתקציב שלנו, לתכנון שלנו.בואו נחתוך את זה עם המידע מה-Salesforce, או מידע ממערכת אופרטיבית אחרת, נבין איפה אנחנו חזקים, איפה אנחנו חלשים.ממש, נעשה אנליזה של  . . . בעצם, נסתכל על הפעילות המסחרית של החברה דרך עולם ה-Finance. (אורי) ולכן זה יותר מתאים לפונקציות כמו FP&A . . . ומה המקומות החדשים, האחרים, שאתם נכנסים אליהם?(עודד) אז ברגע שבאמת הבנו שהמקום שלנו זה אותו משרד ה-CFO, אותו המקום שבו בעצם מנהלים את הכספים, אז יש עוד סט של צרכים משלימים.כמו למשל ניהול ה-Cache, ניהול ה... זאת אומרת - חשבונות הבנקים: מה נמצא, כמה נמצא בפקדונות, . . . (אורי) . . . מה שנקרא “Treasury” . . .(עודד) Treasury זה מונח שאני חושב שיותר מתאים לחברות גדולות, אבל באופן כללי, Cache Management.חברה, בטח חברה שהיא בינלאומית, או שיש לה כמה סניפים - בדרך כלל יש לה כמה חשבונות בנק, לפעמים גם עשרות.אז למשל, סוג אחד של תהליכים שמשתלב באותו תהליך של Reporting זה ניהול המזומנים, ניהול Budgeting ו-Forecasting, כל נושא של... (אורי) Budgeting ו-Forecasting זה “הפורטה”, זה FP&A . . . (עודד) כן, זה חלק - למרות שיש אומרים שה-FP&A “הקלאסי” זה באמת לעשות את הדוחות של מה שאנחנו קוראים “ה-Actuals”, מה שקרה “באמת”, וזה עוד נדבך של ה... (אורי) ה-Planning הוא יותר ה-Budgeting ו-Forecasting . . .(עודד) כן, כל עולם ה-Planning. עולמות אחרים שאנחנו מסתכלים -  מעולמות של Expense Management, ועוד כהנה וכהנה.(אורי) Tax?(עודד) Tax, אני חושב, זה יותר חלק מעולמות שכבר קיימים בדוחות הקיימים.אנחנו היום לא מסתכלים על איזשהו משהו ספציפי בכיוון הזה.כל מיני Workflow-ים שקורים ב... (אורי) נראה לי שכשה-AI יגיע ל-Tax, הוא יחתום ויתור, הוא יתפוצץ . . . . הוא יגיד “עד כאן”.(עודד) אני חושב . . .  אני חושב שדווקא תתפלא, כי אני חושב שבסופו של דבר - וזה אולי נספר בהמשך על אחד הדברים שאנחנו מסתכלים עליהם - אבל עשינו איזשהו סקר. אצל הלקוחות שלנו, הרבה CFO-ים - איך אתם משתמשים היום ב-AI הזמין, ב-ChatGPT?אז אחת התשובות שדי הפתיעו אותנו זה שאנשים מתייעצים בו בנושא של תכנוני מס . . . מכיוון שבסופו של דבר, יש לו גישה לספר החוקים של אותה מדינה שבה הם נמצאים, ולפרסומים השונים של הממשל בנושא מס - אז דווקא באופן מפתיע, יש שם משהו שיכול להיות מעניין.(אורי) זה הגיע גם לרשות המיסים בישראל? כי פה שערי-מיסוי נקבעים על השולחן מול ה... (עודד) תראה עוד פעם - זה משהו שהוא כרגע . . . משהו שאנחנו עוד בשלב של Exploration של הדבר הזה.אבל אני מניח שכן - בסופו של דבר, דאטה זה דאטה.06:55 הכלים החדשים(רן) אז אני אעצור שנייה את שני אנשי ה-Finance פה ואני אשים רגע את “כובע המהנדס” . . .(אורי) בחיים לא אמרו לי דבר כזה, רן . . . (עודד) . . .   זה קצת מעליב, אני קם ועוזב . . . (רן) . . . אני מנסה לעקוב אחרי מושגים לאט לאט. אז בעצם, מה שאני שומע פה זה כך - קודם כל, אתם מייצרים איזשהו כלי שעוזר ל-CFO ולמחלקות שלהם להיות פרודוקטיביים; הדאטה שאיתו אתם מתעסקים, אני מניח שהוא הרבה מאוד טבלאי, חלקו טקסטואלי ואולי גם סוגים אחרים; ואתם נותנים כלים - ואני מניח שהקיום שלכם היה עוד לפני המצאת ה-AI ב-Incarnation הנוכחי שלו.אבל בוקר אחד קמתם וראיתם, רגע, אולי אפשר להשתמש בכלים החדשים שיצרו פה כדי לשפר את המוצר. אז בוא ניכנס לסיפור כזה, כלומר- איזה פיצ'רים בתחום הזה בחרתם לאמץ, ואיפה זה היה מאתגר, ומה למדתם משם?(עודד)  אז האמת היא שכמו שאתה אומר - הבוקר הזה באמת הגיע, אי שם בתחילת 2023.אני חושב שאנחנו - כמו בערך כל התעשייה - עמדנו נפעמים מול אותו כלי מופלא, אותו ChatGPT שהתחיל להדהים את כולנו, ובאמת התחיל לגרות את הדמיון שלנו.ואנחנו - אחד הדברים שעוד לפני שידענו מה אנחנו רוצים לעשות, קיבלנו החלטה שאנחנו All-In בדבר הזה.זאת אומרת שברור לנו שהדבר הזה הולך לשנות את העולם, והוא ישנה תחומים רבים בתעשייה.ובעצם כל כלי שאנחנו מכירים ינסה לאמץ את הטכנולוגיה הזאת בשלב כזה או אחר. ואנחנו אמרנו שאנחנו - בעולם שלנו, ב-Domain שלנו - רוצים להיות הראשונים והמובילים בתחום הזה. ולכן, הדברים הראשונים שבעצם עשינו, זה קודם כל אמרנו, אוקיי, בואו אחד - נלמד את התחום הזה, שקצת נבין מה ומי.כי עוד פעם, זה . .  אני מניח שזה תחום שלמעט אנשים שהתעסקו בעולמות של NLP ועולמות כאלה, הוא חדש לרובנו.למרות שנגיד אני - אני במקור הגעתי מרקע של אלגוריתמים, בכלל בעולמות של עיבוד תמונה, שהיו כותבים קוד ב-C ו-++C, זה לא עולם שקיים היום . . .אז התחלנו לדבר עם הרבה מאוד אנשים - מסתבר שיש הרבה חבר'ה שגם משמשים כיועצים בעולמות האלה, וגם אנשים ש . . . עוד פעם - בתחילת 2023, לא היו הרבה אנשים שהתעסקו ב-Prompt Engineering, או בלעבוד עם מודלים כאלה, כי זה היה משהו מאוד חדש. והיו אנשים שהם היו יותר מהעולם היותר ותיק של אימון מודלים, של בעצם... (רן) Machine Learning “קלאסי”ו-Data Science, כן . . .(עודד) ואני חושב שמהר מאוד הבנו כמה שזה תחום מאוד מאוד מעניין, ומאוד . . . בטח כמהנדס זה נראה . . .  ובן אדם שבאמת הרקע שלו, ומאוד אוהב מתמטיקה, ודברים כאלה - זה היה נראה מאוד מאוד מפתה להתעסק בזה.אבל אנחנו חושבים שמהר מאוד מבינים, או לפחות מגבשים איזושהי הכרה, שבעצם העולם הזה של לאמן מודלים, לאמן כל מיני כאלה דברים, הוא עולם שמישהו אחר כבר עושה בשבילנו.ואנחנו יותר צריכים להתמקד באיך לנצל את העולם הזה - לא כל כך יודעים למה, כן? ברור לנו שרוצים לנצל את זה לתחום שלנו, אבל... ואנחנו כן מתחילים דווקא לחפש חבר'ה שמצד אחד מושך אותם העולם הזההרי יש הרבה מאוד חבר'ה שאיך שיצאו “ה-ChatGPT-ים” והתחילו לחשוף API-ים, ויצאו כל הפרויקטי Open-Source הראשונים, הם ישר קפצו על זה.אז התחלנו לחפש חבר'ה כאלה שזה מאוד מושך אותם, אבל מהנדסים. (רן) זה מעניין. אני רק אתן פרספקטיבה - בעצם, אתה אומר, היה לכם - יש לכם - מוצר, היה לכם מוצר, והייתה טכנולוגיה חדשה. ואז חיפשתם פיצ'רים שיתאימו לאותה טכנולוגיה - כלומר, באתם ואמרתם “אוקיי, זו טכנולוגיה שאנחנו רוצים שתהיה לנו בחברה, אנחנו עדיין לא יודעים למה, ובואו נמצא, בואו נבנה את הפיצ'רים שייטיבו עמה”.(עודד)  נכון, ממש. התגבשה בנו איזושהי הכרה שזה הולך לשנות את העולם.אנחנו דיברנו עם המשקיעים שלנו, ואמרנו “אנחנו מוכנים, אנחנו רוצים להשקיע”ממש “לצבוע” סכום מסוים של השקעה לדבר הזה, וללכת חזק מאוד על הכיוון הזה.(רן)  ואנשי Machine Learning ו-Data Science “קלאסיים” - היו בחברה? זאת אומרת, היו לכם?(עודד) לא, ובאמת במהלך תהליך הגיוס, אני לפחות חשבתי, והיום אני אגיד ש...ההחלטה הזאת - אני כן מבין שקצת לא ברור לי אם היא ב-100% נכונה, שהכיוון זה פשוט ללכת ולגייס צוות של מהנדסיםחזק, שגם יש להם את הרצון להיכנס לעולם חזק, ולבנות את ה-Ecosystem ואת ה-Infrastructure סביב הדברים האלה.אנחנו כן . . . אחד מחברי הצוות - גייסנו כן איש שמגיע מהתחום, מעולם ה-Data Science, ה-Data Analytics, אבל לא מעבר לזה.12:01 פיצ'רים בשביל לפתח ב-AI או פיצ'רים שהלקוחות צריכים?(אורי) אבל יש לי שאלה - אני לא הצלחתי להבין אם פיתחתם פיצ'רים בשביל לפתח ב-AI, או פיתחתם פיצ'רים שהלקוחות צריכים?(עודד) אז אנחנו בשלב הזה, כשאני . . . עכשיו אנחנו בסיפור, היינו באמת בתחילת הדרך.ואמרנו “אנחנו נמצא מה לפתח” - אבל ברור לנו שהתחום הזה של ה-AI, אותם מודלי שפה גדולים, הולך לשנות את העולם.אנחנו עוד לא יודעים איך לרתום את זה אלינו, אבל אנחנו לא נחכה שיבוא איזה לקוח ויבקש - אלא אנחנו ננסה לפתח כל מיני רעיונות ופיצ'רים בעולם הזה, ונראה לאן זה מוביל.(אורי) אבל ראיתם את הלקוח, ב . . . ? (עודד) כן, בסופו של דבר ההסתכלות שלנו אמרה שאנחנו בסוף יושבים על כמות גדולה של דאטה של כל לקוח, דאטה שהוא דאטה מעניין.וה-Vision - אני אגיד “המאוד אבסטרקטי” - היה, בסופו של דבר, שיש אנשים שיושבים ומנתחים את הדאטה הזה, ומנסים להבין מה קרה בעסק.להגיד “המכירות עלו כי הסניף ב - לא יודע מה, באוקלוהומה - פתאום סגר עסקאות מאוד מאוד גדולות, הרבה יותר מאשר ברבעון הקודם.או שעכשיו שולי הרווח עלו כי עלויות, לא יודע מה, רכישת החומרים,  עלתה בככה וככה אחוזים.אז ברור לנו שבסופו של דבר אנשי ה-FP&A, אנשים שעושים את זה, הם מסתכלים על הדאטה ומנסים לנתח אותו.החלום שלנו היה “בואו נבנה AI-based FP&A”. זאת אומרת, מישהו שיוכל לעשות  . . . (רן) “אנליסט אוטומטי” . . . (עודד) בדיוק, אנליסט.וצריך לזכור שכשאני אומר “FP&A” - זה בדרך כלל פונקציה שנמצאת בחברות שהן קצת יותר גדולות . . .(רן) מה הראשי תיבות, דרך אגב?(עודד)  Financial Planning & Analytics.בדרך כלל זו פונקציה שנמצאת בחברות שהן יותר גדולות מהחברות-Target שלנו.וכאן אמרנו “הנה, כמו שהמערכת שלנו עד היום היא מערכת שעושה קצת אוטומציה ועוזרת לאנשים האלה”בעצם לקצר להם - לקצר תהליכים, לקצר את הזמן, לאפשר יותר FP&A בחברות שלא יהיו יכולות להרשות לעצמןאז אם אתה תביא להם איזשהו אנליסט AI, אז גם את חלק מעבודת האנליזה נוכל להציע... (רן) כן, וככה אני מניח זה גם יכול להיות יותר אטרקטיבי לחברות הקטנות יותר, שאולי לפני זה לא היה להן כסף לשלם לבן אדם במשרה,  ועכשיו... (אורי) כי זה Practice טוב - חברה ציבורית שצריכה לתת תחזיות לבורסה חייבת את הפונקציה הזאת, כי ככה היא עושה את התחזיות שלה ואת כל ה-Planning שלה. חברת - לא יודע מה, סטארטאפ בשנתיים הראשונות שלה - לא צריכה ולא ... (עודד) ברור. אני יכול להגיד לכם שאצלנו בחברה, למשל, במשרד ה-CFO, רק לאחרונה יש לנו איש FP&A במשרה מלאה, זאת אומרת שבעצם... (אורי) הסנדלר הלך יחף . . .(עודד) כן, כי חברות בגודל מסוים, לא באמת צריכות, זאת אומרת... (רן) לא, אבל אתה מדבר על טכנולוגיה, אני דווקא חושב על, לא יודע - רשת בתי קפה עם עשרה סניפים, רשת חנויות נעליים . . . זאת אומרת, אתה יודע, לא יודע אם אלה הלקוחות שלכם, אבל... (עודד) דבר ראשון - אלה הלקוחות שלנו.זאת אומרת, בסופו של דבר, אחד הדברים הנחמדים שאתה מגלה, זה שרוב הלקוחות בעולם הם Low Tech, אוקיי? זה מפעלים ורשתות של חנויות . . . (אורי) . . . . אבל זה לא אומר שאין להם יעדים פיננסיים. (עודד) לכולם יש . . . להיפך, יש להם רק יעדים פיננסיים . . .(רן) זהו, בדיוק . . .  לכולם יש - אבל לא כל אחד יכול להעסיק אנליסטים ואנשי FP&A. (עודד) כן, אבל העבודה הזאת מתבצעת תמיד.זאת אומרת, בין אם זה ה-CFO שיושב בישיבת הנהלה ואומר “אוקיי, בואו נסתכל על הביצועים שלנו ברבעון האחרון”, ובין אם יש איזשהו מישהו שעוזר לו, שעושה את זה כ-Part-Time Job, ובין אם יש בן אדם שהוא Dedicated.(רן) כן, אז זה בעצם המוצר הראשון שהחלטתם לבנות?(עודד)  אז אני אומר - זה היה החזון שלנו ל-AI, אבל ברור לנו היה שהדרך לשם . . . צריך לזכור - אנחנו מדברים בתחילת 2023: עוד למעט API ל-Completion ב-OpenAI, לא היה הרבה.ובעולם הזה בדיוק התחיל להתעורר ה-Ecosystem של ה-Open Source פרויקטים כמו LangChain ו-LlamaIndex וכאלה - רק התחילו ממש להיות Commit-ים ראשונים.מהר מאוד גיבשנו צוות, יחסית של חבר'ה מאוד מנוסים - כי זה מאוד אטרקטיבי לאנשים לבוא ולשמוע “הנה, אנחנו הולכים להיות פורצי-דרך ב... “(רן) … “אתם יכולים לעבוד בזה - ואפילו נשלם לכם!”(עודד)  נכון, נכון. והחבר'ה התחילו לבנות.והדבר הראשון שבעצם ניסינו לעשות, הוא היה משהו שהוא משהו מאוד מאוד פשוט - מעין איזשהו Chat מאוד בסיסי, שלקוח יכול לשאול כל מיני שאלות מאוד מאוד בסיסיות על הנתונים הפיננסיים שלו. לא יודע מה - “בוא, תשווה לי את הרווחים השנה הזאת לשנה שעברה”ואותו - קראנו לזה “Genius”, כן? למרות שהוא היה רחוק מאוד מלהיות גאון, אה... (רן) “Baby Genius” . . . (עודד) זה Baby Genius, פשוט אה... בעצם מה שעשינו, אני חושב ש... אתה יודע, היום בדיעבד, כשמדברים על עולמות של Agent-ים וכאלה, זה די ברור שזו הארכיטקטורה שהלכנו.פשוט עוד לא אמרו את השמות . . .(רן) עוד לא היה לזה שם(עודד) עוד לא היה לזה שם, אבל בעצם זה היה משהו שהוא בין Agent ל-RAG - זאת אומרת, הוא מהשאלה הבין איזה שאילתא הוא צריך, למעשה באמצעות הכלים שיש כחלק מהפלטפורמה שלנו, כדי לתשאל ולהביא את הדאטה הרלוונטי.ואחרי זה עושה את ה-Generation - לוקח את הדאטה ומנסה להגיד “תשמעו, הנה - אני רואה פה עלייה”.(רן) אז פה אולי צריך להגיד שהיום התהליך הזה יחסית מובנה - אם מדברים על Agent או כל דבר כזה, אז יש קונספט שנקרא Tools, שאתה יכול לבוא ולהגיד לו “הנה  יש לך את הכלים האלה”. נגיד, שאילתא ל-Database או Search ב-Web או כל דבר כזה. זאת אומרת, יש לו אוסף של כלים שבהם הוא יכול להשתמש, והוא יודע להפעיל אותם, וכמובן, אתה יכול לבנות את ה-Prompt ולעשות משהו כמו RAG, זאת אומרת, לאסוף את כל הנתונים, ובסוף לבקש ממנו “להקיא” אותם בצורה שהיא “Human-Readable”.(עודד) נכון, ואחד הדברים - היום, כשאנחנו מסתכלים אחורה - אנחנו רואים שאנחנו בעצם מבצעים את ההתקדמות שלנו באמת במקביל לדברים האלה.זאת אומרת, במקור, אנחנו התחלנו עם לבנות את ה-Tool-ים האלה, או את התשתית ל-Tool-ים הזאת, בעצמנו.אני לא זוכר אם אתם זוכרים, אבל הייתה, יצא איזשהו פרויקט - AutoML נדמה לי קראו לו, AutoGen.איזשהו פרויקט מאוד מאוד ראשוני של מין פלטפורמה כזאת, שיודעת להשתמש בכל מיני Tool-יםשאתה מבקש ומתחנן מה-API של OpenAI שיחזיר לך את התשובה ב-JSON,  אבל אחרי זה אתה צריך להריץ עליה כל מיני פונקציות ולידציה (Validation), ולידטורים, כדי לנסות ו...(רן) רק נסביר - כדי להיות מסוגלים להפעיל את הכלים האלה . . . מה זה כלים? זה בעצם פונקציות, פונקציות ב-Python. אתה צריך לקבל את המידע בצורה שהיא Structured, אוקיי? איזשהו JSON. ואם לא תקבל את זה ככה, יהיה מאוד קשה להפעיל. עכשיו, פעם, OpenAI ואחרים לא כל כך ידעו להחזיר JSON “יפה” . . . (עודד) למעשה, הם היו מחזירים טקסט - וכשהיית מבקש ב-JSON, אז הוא היה אומר לך, “הנה ה-JSON שלך - האם תרצה עוד משהו?”, ואיכשהו היית צריך להיפטר מה”האם תרצה עוד משהו?”, ולוודא שבאמת הוא... (רן) . . . ולהתפלל שזה באמת JSON . . .(עודד) נכון, אבל מהר מאוד אני חושב ש-OpenAI הבינו שמפתחים וקהילת המפתחים - זה מה שהם רוצים וכמהים אליו.ולאט לאט הם עשו בעצם אפשרות להגדיר סכמה של כאלה כלים, והם מבצעים את ה... בעצם, מוצאים את הפלט שמאפשר את הכלים.(רן) אז היום קוראים לזה Tools או פאנקציות.  Function-Calling.(עודד) נכון, וזה מובנה כבר, והוולדציות (Validation) נעשות בצד שלהם, וזה בהחלט מוריד הרבה מאוד כאבי ראש שהתמודדנו איתם בתחילת הדרך.20:07 היה היה פעם, לפני יומיים(רן) כן, אבל פה אנחנו נכנסים לאיזושהי דילמה הנדסית שקצת רמזת - אתה בא ואומר “אוקיי, אנחנו רוצים לפתח. אבל במקביל, העולם גם מתקדם, אז האם אנחנו נמשיך לפתח את שלנו, או שנאמץ את מה שבחוץ?”(אורי) אני רק רוצה להגיד - אתה לפני שנייה אמרת “פעם, OpenAI . . .”  זה היה F*cking לפני יומיים . . .(עודד) כן, ממש. (רן) רגע, איזה . . . מה עכשיו? Qwen כבר יצא . . .(אורי) יש פה את הדילמה הזאת, שרן אומר “אני אפתח, וזה רודף אחריי מהר מאוד”. זה תמיד היה, אבל לא בקצבים האלה. (עודד) נכון, אני חושב שזה המהירות שבה החברה הזאת משחררת דברים - אנחנו יודעים שהיא משחררת מודלים כל הזמן.כשמודלים זה חתיכת אופרציה להרים - אז בטח את ה-Ecosystem שהם שמים מסביב למודלים, הם משחררים בצורה מאוד מאוד מהירה.ונראה לי שהם מאוד מאוד קשובים, בעיקר לקהל המפתחים - ודי מהר משחררים דברים שמגיעים מהקהילה.דרך אגב, אנחנו היום, מכל מיני סיבות של Compliance ודברים כאלה, אנחנו לא עובדים ישירות מול מול OpenAI.אתם בטח יודעים שכל המודלים שלהם מתארחים ב-Microsoft, ב-Azure, ולמעשה שם מקבלים בעצם את כל המעטפת של ה Compliance, ה-GDPR, כל ה-Certificate-ים, זאת אומרת.(רן) גם ב-Azure, לא רק ב-Azure, נכון? (עודד) אני לא יודע אם יש עוד מישהו שמארח מודלים . . .(רן) לא, הם בעצמם. אבל מבחינך - שם אין לך את ה Compliance ואת ה... (עודד) . . . ואת ההתחייבות שהם לא מאמנים על הדאטה שלך ודברים כאלה,אז אני רוצה להגיד שגם Microsoft מתקדמת במהירות אדירה.ה-Gap  בין המודל, כשמודל משוחרר ב OpenAI, לבין שהוא מגיע להיות זמין כבר ברוב ה-Region-ים הראשיים של Azure, זה לפעמים שלושה-ארבעה שבועות, שזה מאוד מאוד מהיר.(רן) כן, אבל אני דווקא התייחסתי יותר לתחרות שיש לך עם הפרויקטים ב Open Source שהזכרת מקודם, כמו LangChain ו-LlamaIndex ו-Agent Frameworks שונים שלמעשה, פיתחו דברים די דומים לשלך. אולי עשו איזשהו משהו קצת יותר גנרי ואתה עשית משהו יותר ספציפי אליך, אבל קיימת הדילמה הזאת של “רגע, אני פיתחתי פה איזשהו כלי שבעצם הוא די גנרי - למה שאני לא אשתמש במשהו גנרי שנמצא שם בחוץ?”אז איך חשבתם על זה?(עודד) אז תראה, לנו זה קצת התנגש דווקא בסוג האנשים שהבאנו.כי הגיעו לנו . . . כמו שאמרתי, הצלחנו, היה לנו באמת מזל לשים את היד על צוות של מפתחים מאוד מאוד חזקים.אבל החבר'ה האלה - הם אמרו לי, כשראיינתי אותם, הם אמרו “אנחנו אנשי Node, אנחנו כותבים ב-TypeScript, אנחנו לא מתעסקים בשטויות שלכם ב-Python” . . . דרך אגב, רוב ה- Backend אצלנו בחברה הוא רשום ב-Python, אז ככה ש... ואנחנו בהתחלה זרמנו - כי עוד פעם, לא היה כלום, אז מה זה משנה באיזה שפה אתה כותב?והחבר'ה האלו רצו קדימה, ואני יכול להגיד שהם לקחו הרבה מאוד השראה.זאת אומרת, הם כן . . .  בהרבה מאוד נקודות עצרו ואמרו “אוקיי, בואו נסתכל מה יש בעולם ה-Open Source, בואו נראה מה יש בעולם”,מה מפתחים ב-LangChain, שבאמת באותה תקופה תפסה תנופה גדולה. אבל בסופו של דבר, הם הרבה פעמים במקום להתווכח, הם היו באים ואומרים “הנה, תראה - זה עובד אצלנו וזה כבר קיים, וזה כבר עושה את הדברים כמו שאנחנו רוצים, ולא כמו שחשב מי שחשב ב-LangChain לעשות”. כי עוד פעם, זה היה פרויקט שהוא היה די בחיתוליו.ואני חושב שבסופו של דבר,  במשך הכמעט-שנתיים שעברו מאז, אז למעשה פיתחנו בעצם איזשהו Framework משלנו, שהוא באמת כתוב בעולמות של TypeScript.שבעצם מממש חלקים מאוד מאוד גדולים ממה שאתה רואה שמגיע בעולמות ה-Open Source, בטח בעולם של ה-Agent-ים ובעולם של... ואני, אם היית שואל אותי לפני חצי שנה, הייתי אומר לך שיכול להיות שעשינו טעות.היום אני כבר לא כל כך בטוח - כי אני כן רואה שגם הגענו לאיזושהי בשלות מאוד יפה.וגם אנחנו עשינו את זה בצורה שהיא מספיק מודולרית, שהיום אנחנו מתחילים לחשוב איך אנחנו עושים Off-loading ל-Service-ים שהם כן מבוססי פלטפורמות שונות, להתנהגויות מסוימות שאנחנו כן רוצים לאמץ.אז אני חושב שבסך הכל לא נפגענו יותר מדי. 24:47 הגאון וענייני עקביות(רן) כן, אז בואו רגע נחזור לדבר על הגאון, על ה-Genius. אז חברה של מידע פיננסי, וחשוב שהנתונים יהיו נכונים ומדויקים - ואולי אחד הדברים שידועים על מנועי-שפה זה שהם לא כל כך טובים בחשבון . . . הם בכלל לא כל כך טובים במספרים - הם מאוד טובים בטקסטים, אבל בדברים שקשורים בחישובים נומריים הם, איך נאמר, “קצת פחות”. היו שיפורים בשנים האחרונה, או בשנה האחרונה, אבל אתם בתקופה שלפני, אוקיי?(אורי) . . . והם גם פחות . . . הם לא קונסיסטנטיים (Consistent), לא תמיד קונסיסטנטיים, זאת אומרת - שזה מאוד מאוד חשוב.(רן) גם, כן. יפה, אז איך מתמודדים את גם זה? כלומר, לקוחות שלכם - לא מעניינת אותם סטטיסטיקה. הם רוצים תשובה, והם רוצים את אותה תשובה תמיד, והם רוצים שהתשובה תהיה נכונה. איך אתם מתמודדים עם זה? (עודד) אז מה שאנחנו בעצם עשינו, וזה בעצם הגיע לפרויקט-המשך שקראנו לו Insights - בעצם תובנות. הבנו שאנחנו, כמו שאמרתם, המודלים האלה הם...  הם לא אמינים והם לא טובים במספרים, ואם אנחנו רוצים לעשות אנליזות מספריות שהן מורכבות -  עוד פעם, מורכבות ברמה של Finance, לא רגרסיות ליניאריות מתוחכמות -אז עדיף שנעשה אותן בעצמנו. ולכן, מה שבעצם נוצר זה בעצם מעין משהו שמאוד מזכיר את אותו RAG מפורסם, רק ש... ואני מניח שאנשים מכירים מה זה RAG.שרק שבשלב ה-Retrieval, במקום ללכת ולחפש טקסט באיזשהו Vector Database, הוא שלב שבעצם מפעיל את אותם, מצד אחד, מנועי הבאת-נתונים שיש אצלנו בתוך הפלטפורמה גם.וגם הוספנו עוד שכבה של אנליזת-דאטה. זאת אומרת, אנחנו יודעים מראש איזה חישובים כדאי לעשות על הדאטה, כדי שהם יהיו מעניינים, או שהם יכולים להשתלב בתוך ה-Context של אותו Insight שאתה רוצה.אז אנחנו פשוט עושים אותם מראש, על הדאטה של ה-Context.(רן) כן, סליחה, אני אפרוט את זה רגע לבדידים. אז אתה אומר . . .  זה לא שאתה אומר ל-GPT “הנה, קח - זה הדאטה, תעשה מה שאתה מבין, זה מה שה-User שאל, תעשה מה שאתה מבין”. אתה לא עושה את זה, אלא אתה עושה את זה בצורה שהיא יותר Structured.אז אחד זה אולי להבין את ה-User intent, כלומר - מה הוא שואל? על איזה דאטה? על איזו שנה הוא רוצה להסתכל? על איזה מחלקות הוא רוצה להסתכל, Whatever. זאת אומרת, להבין. ואז לשלוף בעצמך, אולי בשאילתת SQL, באמצעים “רגילים”,  לא שום NLP. לשלוף את הדאטה, ללעוס אותו, אולי לעשות איזושהי אנליזה - ואת התוצאות האלה, בסוף אתה מגיש לו ורק אומר לו “עכשיו תכתוב את זה באנגלית יפה?”(עודד) בדיוק, ממש כך. כשבעצם אנחנו . .  דרך אגב, זה התחיל כבר בפרויקט הראשון ב-Genius. זאת אומרת, את הנתונים עצמם.למעשה, המערכת של DataRails, כוללת למשל מערכת Dashboarding, שאתה יכול ממש לייצר כל מיני Widget-ים על הדאטה שלך.אז בעצם נתנו לו להפעיל את מערכת ה-Widget-ים האלה, ובסוף הנתונים שהיה רואה הלקוח היו מגיעים מתוך המערכת שלנו.ואז אנחנו יודעים שהם מדויקים והם בדיוק מה שצריך - והפרשנות הייתה מופיעה כפרשנות טקסטואלית.(אורי) אז יש לנו פה בעצם לא אנליסט, אלא “דובר”. האנליסט הוא DataRails “הישן”. (עודד) אז אחת התובנות שהיו לנו מאותו מוצר ראשוני זה שבאמת הגענו למסקנה שהוא, שהוא “חלש מדי”, כי הוא באמת רק “דובר”.זאת אומרת, אני בעצם משתמש ב-AI כדי להבין את ה-Intent של ה-User, וכדי לספר לו מה אני רואה.ואז באמת החלטנו לעבור לשלב השני, מאותו שלב שקראנו לו Insights, שזה ממש שלב שנמצא עכשיו ב-Rollout ראשוני אצל לקוחות,שבעצם אומר “אני אבחר את הדאטה שאני רוצה להביא ללקוח, אבין את ה-Intent שלו”.לאו דווקא דרך אגב טקסטואלית, אלא אפילו ”UI-ית“- על איזה חודש, איזה ניתוח נגיד רבעוני או חודשי שהוא רוצה לעשות, או שהוא...  עושה איזה מין Setup ל-Report כזה. (רן) . . . אפשר להשתמש ב-Drop-down Box, נכון? אפשר להשתמש בזה, לא חייבים רק טקסט . . .(עודד) בדיוק. אני אעשה את כל הניתוחים האפשריים. עכשיו, חלק גדול מהניתוחים האלה לא באמת מעניינים את ה-User, אבל אז אני אשתמש בעצם בכוחות של ה-LLM.אני אומר לו “אלה הניתוחים שעשיתי”.גם כל אחד מהם בנפרד - הוא מתואר טקסטואלית על ידי LLM שמתאר אותוואז יש LLM אחד שמסתכל על כל הדברים האלה כ-Context - ומחליט לספר. מה הדברים המעניינים? מה הדברים הפחות מעניינים? ומה בכלל לא צריך לכלול באותו דוח שהוא מספק  ללקוח.(רן) כן, אבל גם בדבר כזה, אני יכול לחשוב איך דברים יכולים להשתבש. זאת אומרת, בהקשר של LLM, כן? זאת אומרת, דברים תמיד יכולים להשתמש, אבל בהקשר הזה. השאלה כאילו, איזה מיטיגציות (Mitigations) יש לכם? נגיד, פיתחתם איזשהם Guardrails מיוחדים? האם, לא יודע, מיטיגציה של UI? אולי קצת רמזת שזה גם להראות וגם להסביר - אז אוקיי, אם ההסבר לא מדויק, אז לפחות הוא רואה. מה המיטיגציה?(עודד) אז אני חושב שהמיטיגציה העיקרית, היא באמת בהנגשה של המידע. זאת אומרת, אנחנו הגענו למסקנה כבר די מהתחלה, שאת המידע שאנחנו מראים - הוא לא מגיע דרך ה-LLM. זאת אומרת, אם עשינו עכשיו איזשהו ניתוח . . .  אז אנחנו עושים למשל ניתוח, מה שנקרא בעולם ה-Finance, זה Variance Analysis.עושים ניתוח שונות - מה גרם לשוני בין, נגיד, שתי תקופות, או בין . . . כשעושים Budget vs. Actual.ואז אנחנו יודעים מה האנליזה שעשינו, אנחנו מציגים אותה בצורה גרפית - את הנתונים עצמם שמגיעים מהמערכת - ואנחנו נותנים בסך הכל ל-LLM, לספר מה הוא רואה שמה, ולתת גם את “הפרשנות שלו” למה שהוא רואה.אבל בסופו של דבר, זה מוצג לצד הנתונים. זאת אומרת, תמיד הלקוח יכול להסתכל על הנתונים, המערכת שלנו מאפשרת לו לעשות Drill-down לתוך הנתונים - זאת אומרת, גם לוודא אותם.וזה בעצם נותן רמה שהיא מצד אחד נראית מאוד מאוד מרשימה - כי זה גם תמיד גרפים ליד טקסט.גם ממקד אותו, כי הטקסט בסוף ממקד אותך באמת בדברים החשובים שראית. אבל גם אם הוא לא מיקד אותך בדבר הכי חשוב - עדיין אתה רואה את כל הנתונים מול העיניים שלך.אתה יכול לתחקר אותם, אתה יכול להסתכל עליהם וזה כן נותן איזושהי רמה של ביטחון ל-User, שגם אם הפרשנות לא הייתה הפרשנות המדויקת, אז זה מספיק טוב. (אורי) כל CFO יודע שיש P&L שמציגים בBoard - ויש תירוצים. (עודד) נכון. (אורי) . . . התירוצים זה המתרץ . . .(עודד) נכון, נכון. דרך אגב, אחד הפיצ'רים הנחמדים שעשינו במערכת זה שאתה יכול לקחת גרף מהמערכת ו”לתקוע אותו בתוך מצגת PowerPoint”, ויש לך את שם Checkbox אם אתה רוצה להוסיף את התירוץ גם כן . . . והתירוץ זה בעצם הניתוח של... (אורי) אבל יש לי בשבילך רעיון לעוד פיצ'ר, אבל לא . . . Off-record . . .(רן) Off-record בהרבה כסף . . . היום במקרה מישהו אמר לי ”אבל אני בטוח שזה נכון, GPT אמר לי!” . . .הפוך, הפוך, . . . (עודד) זו נעשתה האמת החדשה, קצת מטריד.(רן) כן.(אורי) פעם זה היה, אתה יודע . . . הראשי-תיבות של LLM זה “לא להיות מדויק” . . . (עודד) אני, כשאני מסביר לאנשים לפעמים, אני אומר שאחד המאפיינים של המודלים הם שהם חייבים לתת תשובה. הם בסוף נותנים תשובה - והתשובה הנכונה זו אחת האופציות. (רן) כן . . .(אורי) או כמו שאמר מישהו - כשתלחץ על מפתח מספיק, הוא יוציא קוד. מאיפה הוא יוציא את הקוד הזה? זו שאלה אחרת . . .(רן) כן, טוב, הגענו ממש לאזורים מעניינים.32:59 השלב הבא ואיפה אנחנו היום( רן) אז זהו, אנחנו ככה ממש לקראת הסוף. אז אמרת בעצם שבניתם מוצר אחד, והיום אתם בעצם בעיצומו של בניית של מוצר נוסף . . (עודד) למעשה, אנחנו כבר בעיצומו של בניית המוצר השלישי . . .ואני חושב שמה שמאפיין את ה... אני אגיד את ה-Trajectory של בניית המוצרים, זה שאנחנו כל הזמן בעצם מבינים, אני חושב שזו הכרה שלאט לאט אנחנו מבינים בעולם של ה-LLM, שמה שמשחק זה ה-Context.זה הדאטה, זה איזה דאטה אתה מגיש. אז אם אני רק אסיים, אם במוצר הראשון הנגשנו לו איזה אספקט מאוד מאוד צר של נגיד, בואו נראה את ה-Revenue over Time, ובמוצר השני, אנחנו הנגשנו ל-LLM כל מיני ניתוחים ואנליזות שעשינו באמצעות כל מיני כלי דאטה, Data Analytics, שאנחנו מיישמים על הדאטה.עכשיו אנחנו בעצם משלבים גם ומכניסים לו Context של מידע על החברה - על הפעילות שלה, על הבן אדם ששאל, ממש מכינים איזשהו מעיין “פרופיל חברה”.שדרך אגב, משתמשים ב-LLM גם כדי להכליל אותו, אבל הוא חלק מה-Context. (רן) אתה יודע, אחד הכללים זה שלכל בעיה, יש פתרון אם תוסיף עוד LLM בדרך . . . (עודד) כן, אבל אנחנו בעצם יוצאים עם מוצר שאנחנו קוראים לו CFO Spaceשהמטרה שלו בעצם להיות איזשהו “GPT ל-CFO”, שבעצם היתרון בו מול GPT רגיל הוא שיש לו גישה גם לנתונים הפיננסיים שלו, שנמצאים בתוך DataRails, גם לפרופיל החברה שנבנה - עוד פעם, גם בצורה אוטומטית.גם למקומות וגם לכל מיני מקורות מידע פיננסיים, שבדרך כלל אין גישה אליהם, כי הם נמצאים מאחורי איזה חומת-תשלום או משהו כזה, שאנחנו יכולים להביא אלינו,ואז לקבל בעצם איזשהו . . .  בעצם להגדיל את ה-Context שאתה מקבל.(רן) נדבר אולי דקה-שתיים על הפן האנושי, ה-HR-י. זאת אומרת שחיפשת אנשים ש”זה בדמם”, שיידעו לעשות את זה. איפה אתם היום? עדיין זה Owned על ידי צוות אחד, או שזה התפשט לצוותים נוספים? כלומר, “מי נוגע ב-AI”, נגיד את זה ככה, אצלכם בחברה?(עודד) אז היום עדיין זה נמצא בידי אותו צוות.אנחנו כן בעצם מנסים או מתחילים לשלב צוותים אחרים בלהשתמש באותם פיצ'רים שפיתח הצוות.בסוף הצוות הזה פיתח תשתית AI - תשתית שמאפשרת לקרוא ל-AI ולתחזק Prompt-ים ותשתית של Agent-ים - ואנחנו כן מנסים לראות איפה אנחנו משתמשים בזה בעוד מקומות בחברה. אבל עדיין, היום רוב הפעילות מתבצעת על ידי הצוות הזה.35:43 סיכום(רן)  אוקיי, אז אנחנו ככה לקראת הסוף. אולי עוד כמה מילים על החברה - כמה עובדים? כמה מפתחים? איפה יושבים?(עודד) אז החברה היא היום בערך 230 עובדים, כמחצית נמצאים בארץ.צוות הפיתוח מונה כ-50 איש.אנחנו יושבים ב-Midtown, בתל אביב.ואנחנו כמו הרבה חברות - מחפשים חבר'ה שגם רוצים לעשות דברים מעניינים.גם בתחום ה-AI - אבל גם יש לנו סט שלם של בעיות דאטה מאוד מאוד מורכבות, בעיות של Scale,  שזה אני חושב חדשות טובות לחברות שהגיעו לשלב שהן מתמודדות גם עם Scale גדול.ואנחנו תמיד מחפשים אנשים טובים, בעיקר מרקעים של עולמות של Python, של Node . . . (רן) כן, אוקיי - ואנשי דאטה ואנשים שאוהבים LLM-ים, ואני מניח שיש לכם גם דברים אחרים, UI ואחרים. (עודד) דברים מאוד מעניינים.אוקיי, תודה רבה! היה מעניין, בהצלחה![קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 490 (מי היה מאמין) של רברס עם פלטפורמה, שהוקלט ב-21 בינואר 2025. אורי ורן מארחים בהפסקת אש את ארז רביע חחברת Komodor לשיחה על Kubernetes, ולמעשה - כדי לספר את סיפור חייו של Kubernetes:  קצת על ההיסטוריה של Kubernetes - מאיפה הוא בא? למה בכלל הוא נולד? מה עושים איתו היום וקצת Best Practices, שזה בעצם לחם-חוקם של ארז ושל חברת Komodor. 🎗️ 01:22 ארז ו-Komodor(רן) אז קצת לפני שנקפוץ ונדבר על Kubernetes - כמה מילים עליך, ארז, ועל Komodor.(ארז) מגניב. אז אני ארז - בן ארבעים, גר ברמת גן, נשוי לשירן, אב לשלוש בנות.כבר 16 שנה בתעשייה, בערך מ-2009. עובד היום ב-Komodor.נספר קצת על Komodor כמוצר - אז Komodor זה בעצם מוצר שנועד לצוותי פיתוח, שמשתמשים ב-Kubernetes, או עושים מיגרציה (Migration) ל-Kubernetes ב-Production.אנחנו מציעים Offering שפונה גם ל-Experts בארגון - אם זה צוותי ה-DevOps  או ה-Platform - וגם לצוותים שמפתחים, שבעצם הקוד שלהם רץ על גבי Kubernetes, אבל מטבע הדברים הם פחות מכירים לעומק את הכלי.אז אם זה כלים של Cluster Management, Cost Efficiency ו-Reliability של ה-Workloads over time ו-Access Control, הנחלת קונבנציות (Conventions) בארגון הפיתוח - זה בעצם מה שאנחנו נותנים ל-Expert-ים.לחבר'ה שפחות מכירים, יש לנו Guided Troubleshooting Tool  כזה, שבמידה ויש Incident, בא ועושה איתם Root Cause Analysisיש פה Generative AI, לוגיקה קלאסית שמעורבת בתהליך.ובעצם, אנחנו עוזרים לארגונים, ל-Enterprise-ים גדולים, להפחית את העומס הזה שנוצר מכיוון צוותי הפיתוח לכיוון צוותי ה-DevOps, ולאפשר להם להיות עצמאיים.ועל הדרך גם ללמד אותם על Kubernetes, ולמה קורים דברים שאנחנו לא היינו רוצים שיקרו.(רן) כן, אז חדי-האוזן בוודאי הבחינו בהגייה שלך . . . .(ארז) כן, מתנצל על זה מראש . . .(רן) אז קודם כל, נשאלת השאלה- אם Kubernetes או קוברנטיקס? אז ובכן, אחת ולתמיד - זה Kubernetes.אבל כן, אכן כותבים את זה קצת מוזר, וגם דיברנו על זה, אני חושב, לפני די הרבה פרקים, על זה שהמקור הוא ביוונית, וזה למעשה, מה זה? זה גלגל ההגה? [פרק 353 עם Istio](אורי) של הספינה, כן.(רן) של הסירה, של הספינה. כן - אני חושב שיש פה חובלים שיודעים להנהן בראשם.(אורי) חובלים יוונים.(רן) חובלים יוונים, לא סתם - מהמקור!אז אני חושב שיצא לנו לא מעט לדבר עם נתי שלום [לאחרונה ב-489 carburetor 38], שהוא גם לא מעט מדבר על נושאים בתחום הזה - והוא אמר שהרבה חברות למעשה לוקחות תשתית כמו Kubernetes, ובונות מעל זה PaaS. זאת אומרת, בונות מעל זה איזושהי פלטפורמה ל-Deployment של התוכנה שלהן . . .(אורי) דיברנו על כל ה-Platform Engineering שבא מעל זה . . . . [445 Carburetor 33 - platform engineering](רן)  . . . . בדיוק - ואני יודע, זה משהו שגם נעשה ב-Outbrain, וזה נעשה גם בחברות אחרות - אבל זה לא מה שאתם עושים ב-Komodor. זאת אומרת, אתם לא בונים PaaS לחברות . . .(ארז) לא, למעשה אנחנו מה שנקרא Day One או Day Two.בעצם, מרגע ה-Provisioning של ה-Cluster ופרישת ה-Workloads על גביו, אנחנו עוזרים לחברות לתחזק את “המפלצת הזאת” שנוצרת לפעמים לאורך זמן.ושוב - לאפשר לארגון לעבוד בצורה שיותר Efficient, Self-Sustained, והייתי אומר “נורמלית”, בתוך כל הכאוס הזה, שעלול להיווצר ב-Cluster-ים מאוד גדולים.(אורי) אז אתם מוצר או Service - או שניהם?(ארז) אנחנו למעשה מוצר SaaS -  יש לנו Agent, שלקוחות מתקינים על ה-Cluster שלהם.ובעצם החל מאותו רגע, אנחנו מתחילים להזרים Data אלינו - ותוך שעות עד ימים מתחילים לנפק Insights.זה, הייתי אומר, ה-Value היותר long-term-י.בנוסף לזה, אנחנו סוג של “Gate ל-Kubernetes”אז אם לדוגמה אתה רוצה לנהל הרשאות גישה של משתמשים across clusters, ויש לנו לקוחות עם מאות Cluster-ים, אז בעצם אנחנו עוזרים למסד את הדבר הזה ולנהל אותו.(אורי) כשירות או כמוצר?(ארז) כשירות? אני לא בטוח שאני מבדיל בין שני המושגים האלה - זה מוצר שהוא שירות, כלומר...(אורי) אוקיי.(ארז) . . . . נכון, זה מוצר SaaS-י, בעצם אתה ניגש אליו...(אורי) לא, לא - אני אומר “כשירות”, זאת אומרת - יש אנשים מאחורי זה? או שיש .  . (רן) . . . . עד כמה זה High-Touch או לLow-Touch?(ארז) לא - הכל נעשה בצורה אוטומטית לחלוטין.כמובן שאנחנו מאוד קשובים ללקוחות, ואם יש דקויות לפה או לשם אז אנחנו ניגשים ועוזרים ומסבירים.לפעמים אפילו עושים שינויים במערכת.אבל אין פה איזה Human Intervention במגע גבוה.05:50 בחזרה לעתיד / למה אנחנו צריכים את כל זה?(רן) אוקיי, אז אולי אחר כך גם נחזור לעוד כמה דברים ש-Komodor עושים - אבל זה הזמן לדבר על Kubernetes.אז בואו נחזור אחורה בזמן - משהו כמו ה-17, 16, אולי אפילו 20 שנה. אני אספר לכם שבצעירותי, כשעוד היה לי שיער שחור לחלוטין . . . (אורי) . . . כשעוד היה לך שיער . . . (רן) . . .  כשעוד היה לי שיער ברוב חלקי-ראשי, ופחות בשאר הגוף, אז יצא לי לעבוד ב-Google - ושם הייתה מערכת  פנימית שקרו לה Borg. וזו הייתה מערכת שיודעת לפרוש שירותים, לייצר רפליקות (Replications) של שירותים, להריץ Job-ים, Load Balancers, Monitoring - “מכל הבא ליד”.וכשסיימתי את העבודה שם ויצאתי החוצה, חיפשתי משהו כזה - ולא היה, במשך כמה שנים.וכאן, ארז מצטרף לסיפור . . . (ארז) כן. אז אני אשמח להתחיל את הסיפור דווקא במפגש הראשון שלי עם Kubernetes, בעצם אזור שנת 2015.הצטרפתי בתקופתו ל-Nanit, ממש עובד רביעי-חמישי - וכבר היו בנויים כמה Containers ב-Docker, והיה צריך להחליט איך אנחנו עושים אורכסטרציה (Orchestration) לכל הדבר הזה.בתקופתו היו שני שירותים עיקריים שמציעים פתרונות - הראשון היה AWS ECS, שלמעשה קיים עד היום.והשני היה Kubernetes - שהוא היה ממש “בחיתוליו”: לדעתי גרסה 1.0.2, גרסה ממש ראשונית.ובעצם, המשימה הראשונה שלי הייתה להבין איך אנחנו הולכים לנהל ב-Long Term את כל ה-Docker Containers וה-Services שלנו, שהולכים להיווצר במהלך זמן חיי החברה.(רן) אז קודם כל, אולי למה אנחנו צריכים את כל זה - ואחר כך גם נחבר לסיפור הנוגע ללב, אני חייב לומר, שלי על Borg . . . אז אם אתם, כל מה שיש לכם זה איזשהו, לא יודע, איזשהו Web Service, או משהו שהוא ככה Singleton, מאוד פשוט - כל מה שאתם צריכים זה אולי, רחמנא ליצלן, איזה FTP או סתם ככה SSH: הולכים ל-Server, מרימים איזשהו משהו וזה רץ, הכל טוב ויפה.במציאות, צריך לפחות שניים מכל דבר, נכון? ויש איזשהם בדרך כלל Microservices, אצל הרבה חברות, שמדברים אחד עם שני . . . זאת אומרת, צורת ה-Deployment היא מורכבת, ואם תעשו את כל זה באופן ידני, אתם כנראה תטעו באיזשהו מקום, וזה מאוד קשה לניהול.כאן בא Kubernetes ועוזר לנהל את כל זה. זאת אומרת, זה לא רק לבוא ולהתניע את ה-Container, אלא זה גם לנהל את כל ה-Life cycle של מה קורה אם אחד מהם מת, מה קורה אם צריך לעשות Deployment וכו'.אז זה הצורך ב-Kubernetes. אוקיי - ואז אתה אומר שהייתם צריכים לבחור בין, נגיד, ECS ו-Kubernetes, והלכת על הילד החדש בשכונה?(ארז) כן, בעצם מתוך המחקר שעשיתי, גיליתי שאם כמה זה ששני ה-Service-ים האלה, או השירותים האלה, או הפלטפורמות האלה, הן פלטפורמות צעירות - Kubernetes בעצם הציע המון דברים שהם סוג של “Batteries Included”כמו Log collection, Metrics collection - כבר בשלבים המאוד ראשוניים שלה.ו-ECS הרגיש מאוד “בוסרי” באותו שלב.ולכן גם בעצם קיבלתי - וקיבלנו - את ההחלטה להמשיך עם Kubernetes.החלטה שבתקופתו לא הייתה טריוויאלית או Obvious בכלל - ולשמחתי זה מאוד השתלם לנו.חייב להגיד מילה לעניין ה-Complexity של ה-Deployments - אז יש בלוג-פוסט מאוד מוכר והומוריסטי של CircleCI בשם “It's the future”לא יודע אם יצא לכם לקרוא את זה, אבל ממליץ אחרי שאתם שומעים את הפודקאסט.(רן) כן, אוקיי, מעולה - אז נוסיף ל-Show-notes [ובכן - נראה שהם הורידו את זה מהאתר שלהם, כל הלינקים שבורים, נגיד זה או זה, והולכים לעמוד הכללי של הבלוג שלהם… מניח שהכוונה לבלוג הזה שיושב ב-Medium].(רן) אולי אחד הדברים שמי שיהיה באזור והכיר את Kubernetes בטח הרגיש, זה שהיא הייתה מערכת מאוד מאוד בוסרית. אתה אומר שהיו כמה “Batteries Included”, אבל מצד שני לא הכל עבד As-Spec, והדברים זזו, וגם אם משהו עבד, בגרסה הבאה פתאום זה משתנה . . . .(ארז) נכון.(רן) . . . . אז ככה שנדרש, בוא נאמר, אומץ רב, כדי לבוא ולאמץ מערכת כזאת בסביבת Production, בשלבים האלה.אבל ההימור, כמו שאתה אומר, הצליח לכם.(אורי) היא גם הייתה מאוד, ככה, “Strict” באיך שעובדים איתה, לא?(ארז) היא הייתה אפילו מאוד מתסכלת, באיזשהו מובן. יכול לתת כמה דוגמאות . . . .לדוגמא, Resource ה-Deployment, שהוא, הייתי אומר, אחרי Pod, כנראה ה-Resource הכי מוכר ונפוץ היום ב-Kubernetes, לא היה קיים בגרסאות הראשונות.ולמעשה, חלק מה-Script-ים שאנחנו בנינו, היו מורידים ReplicaSet אחד ומעלים ReplicaSet אחר, כדי לעשות פרישה של גרסה חדשה.(רן) כלומר, אם היית רוצה לעשות Deployment לגרסה חדשה, לא היה את הקונספט הזה שנקרא . . . שהיום קיים ב-Kubernetes ונקרא Deployment - היית צריך לייצר משהו כזה מה-Building Blocks שהיו קיימות אז, שהיו ReplicaSet. גם היום קיימות - אבל יש מעטפת, יש אבסטרקציה (Abstraction) קצת יותר גבוהה.(ארז) לגמרי. אבסטרקציה, הייתי אומר כמעט מושלמת, נכון. היום, כשאני פורש איזשהו Service ב-Kubernetes, אז יש לי את כל השירותים.עד כדי להחליט כמה אחוז מה-Workload שלי אני מוכן שיהיה Unavailable במהלך זמן פרישה.שזה, הייתי אומר, מאוד Advanced, בטח יחסית למה שהיה אז.כל האיחסונים של ConfigMap ו-Ingress להחצנת שירותים בעצם - לא היו קיימים.ואם זה שאמרתי שאולי זה היה קצת מתסכל, אני חושב שגם זאת הייתה הזדמנות נפלאה לייצר המון Open Source.ובאמת ייצרנו המון המון Open Source, כמעט לכל הדברים והכלים שנבנו במהלך הדרך.אם זה Helm charts, שזה בעצם היכולת לעשות Injection של variables ל-Templates.אם זה Ingress, שזה היכולת שלי להחצין איזשהו Load balancer, שמכווין ל-Internal Services וכו'.אז אני חושב שבאמת עם כל הקושי, גם הרווחנו המון מהדבר הזה - אני אישית גם.12:01 להשתמש נכון / איך אני יודע שאני צריך אחד כזה?(רן) כן, אז בסדר - אז נחזור רגע להיסטוריה: אז אמרנו ש... זאת אומרת לא אמרנו, אבל נגיד עכשיו - למעשה, Kubernetes נולד מתוך איזשהו פרויקט פנימי שהיה קיים ב-Google, שנקרא Borg. באיזשהו שלב, Google החליטו שהם רוצים לייצר גרסה חיצונית - זה לא אותו Codebase, אלא גרסה חיצונית שדומה לאותה מערכת - ולתת אותה לעולם.יש לך מושג למה? כאילו, מה האסטרטגיה פה?(ארז) אז אני חשבתי על זה לא מעט, ואני חושב שזה מאוד מקביל לשחרור של Android.בעצם, המטרה היא פה לפרסם פלטפורמה שהיא חינמית והיא Cloud-agnosticובדרך הזאת, Google לדעתי קיוותה להיכנס לשוק ה-Cloud Providers, על ידי זה שהם מאפשרים העברה מאוד קלה של Workloads מ-Cloud אחר אליהם.כי Kubernetes הוא בעצם שכבת האבסטרקציה לאותם Workloads - וזה משהו שעובד.(רן) Anti-Lock-In . . . .(ארז) בדיוק, Anti-Vendor-Lock . . . .(רן) ואם ככה, אז כאילו, אתה יודע - מתבקש ש-AWS לצורך העניין, לא כל כך יאהבו את Kubernetes, אבל היום התמונה קצת שונה, נכון? היום אתה רוצה Kubernetes, אתה לוחץ על כפתור - הוא מריץ Script קטן ויש לך Cluster בכל Cloud Provider שמכבד את עצמו, וגם כנראה באלה שפחות מכבדים את עצמם . . . . זאת אומרת, זה מאוד מאוד נפוץ.יחד עם זאת, זה עדיין לא פשוט להשתמש בו . . .  זאת אומרת, אולי קל להתניע אחד כזה, אבל להשתמש בצורה נכונה - זה לא קל.(ארז) נכון, אני חושב שצריך להכיר - כמו כל כלי שהוא מורכב, הוא בעצם סוג של פלטפורמה ל-Distributed Execution של קוד.בגלל שהבעיה היא כל כך קשה, גם הפתרון מצריך המון ידע והעמקה וההבנה של מה כלי הזה מאפשר לנו.אז יש המון דברים שכדאי שנכיר. נתחיל לעבור על זה?(רן) כן. אז אולי שאלה הראשונה זה מתי אני צריך Kubernetes? כלומר, איך אני יודע שאני צריך אחד כזה?(ארז) אז הייתי אומר שהיום, בזכות העובדה ש-Kubernetes הוא כל כך נגיש וקל להקמה ויש Ecosystem כל כך רחב סביבו, אז באמת כל דבר שהוא יותר מ-Single Service, כבר הייתי מעלה היום Cluster ופורש את ה-Workload שלי עליו.כמובן, בהנחה שזה משהו שמשרת לקוחות, ומאוד חשוב לנו שהוא יהיה Highly Available ו-Robust ועם Visibility על הדברים.אני חושב שזה היום יחסית No-Brainer, באמת.(רן) כן. ואולי הזכרנו את זה מקודם - אם אתם מפחדים להיות נעולים אצל אחד מה-Provider-ים, אז Kubernetes יכול לעזור. דרך אגב, זה לא פתרון מושלם - עדיין יש לא מעט ערך מוסף שה-Provider-ים, זאת אומרת, Google ו- GKS [GKE] ו-EKS וכל זה נותנים. אז זה לא אפס, אבל עדיין זה פחות מ-100.14:57 בואו נדבר קצת על Best Practicesאוקיי. אז החלטתי שאני רוצה Kubernetes אצלי בגינה - בואו נדבר קצת על Best Practices. זאת אומרת, מה אני כאיש Infrastructure או מה אני כמפתח, צריך להכיר, שיעשה את החיים יותר טובים.(ארז) סבבה. אז דבר ראשון, אני חושב שעוד פעם מאוד Obvious, אבל כן להשתמש ב-Managed Solutions.דיברנו קצת על תחילת הדרך - אז באותה תקופה, כדי להרים Cluster, היית צריך להריץ cube-up.sh עם מלא Environment Variables, ולהחזיק אצבעות . . . (רן) . . . להתפלל ל-Kelsey Hightower שהכל יעבוד . . .(ארז) ממש, ממש. זה היה “Kubernetes the hard way”, אבל “This is the only way also” - וזה היה בעייתי.היום, בעצם כל Cloud Provider  שמכבד את עצמו, וגם אלה שפחות, מציעים שירות שהוא מאוד נגיש.גם ב-Provisioning - יש לך Control Plane עם Auto-Scaling ו-Full Visibility ו-Resiliency.ואתה לא רוצה פשוט להיכנס לכאב ראש הזה.אז אני חושב שהדבר הראשון כשבאים להקים, זה באמת לבחור את ה-Cloud Provider, שכנראה כבר עובדים בוופשוט להשתמש ב-Managed Solution שלהם כדי להרים את ה-Control Plane.זה נראה לי התחלה טובה.(רן) כן, כשאתה אומרת Control Plane - אתה מדבר על “השלד”, שעליו אפשר אחר כך להרים את ה-Workload עצמו, את ה-Container-ים, את ה-Pod-ים . . .(ארז) כן, למעשה אולי משפט על זה - אז בעצם ל-Kubernetes  מחולק ל-Data Plane ו-Control Plane.ה-Control Plane זה כל ה-Internal Tools, שעוזרים ל-Kubernetes לעבוד,אם זה ה-Scheduler שלו, אם זה ה-Kubernetes API, אם זה ה-ETCD, שהוא למעשה ה-Storage של כל ה-Resources שלנו.וה-Data Plane - אלה ה-Node-ים שעליהם אנחנו, “ה”User-ים” במרכאות כפולות, מריצים את ה- Workload-ים שלנו.אז בעצם, ה-Managed Services - הם עוזרים לך להקים ולתחזק ולעשות Auto-Scale לכל מה שנקרא “ה-Control Plane”.ואז אתה יכול להתעסק ב-Business שלך וב-Workloads שאתה מפתח.(אורי) זה לא מין תופעה כזאת של “אוקיי, קם Kubernetes. בהתחלה הוא היה פשוט, אחר כך לאט לאט . . .” - אתה יודע, כשרוצים אז מצטרפים עוד ועוד פיצ'רים לדבר הזה וזה נהיה מסובך. ואז מייצרים מעל זה Managed Services - ועכשיו אנשים מתחילים לשתמש ב-Managed Service, וכשהם שמשתמשים אז הם רוצים עוד פיצ'רים,ואז נהיים לו מלא פיצ'רים - ואז עוד פעם נהיה . . . “Managed Service מעל ה-Managed Service”?(ארז) זו שאלה טובה . . . (אורי) . . .  מהתהליך הזה . . .  אתם מכירים את זה, שבהתחלה אמרו כשקם ה-Cloud, “נגמרה העבודה לאנשיה-Ops”, ואז . . . (רן) . . . “וואי וואי, כמה עבודה יש ב-Cloud” . . . (ארז) כן, פשוט העברנו אותה ל . . . (אורי) בדיוק . . . ואז פתאום Kubernetes נהיה העבודה של ה-DevOps, ואז נהיה מן Managed Service אבל גם הם נהיו מסובכים . . . בקיצור, תמיד יש עבודה לחבר’ה האלה, להתעסק במה שהמפתחים לא רוצים להתעסק בזה . . . (ארז) אז אני חושב שה-Complexity שהתווסף ל-Kubernetes Over the years הוא למעשה דווקא לא ב-Control Plane אלא יותר ב-Data Plane.כלומר, באפשרויות שלנו, בתור User-ים של Kubernetes ולא בהכרח בתור אלה שמנהלים את ה-Control Plane, להשתמש בו.ולרוב הוא נולד כתולדה מצורך. אז באמת, האבולוציה היא כזאת שהם התחילו מ”הכי Lean  שיש”,ולמעשה הוסיפו Complexity לפי הצורך ולפי הצרכים הארגוניים של ארגוני תוכנה גדולים.ואני שמחתי מאוד להינות גם מהדברים האלה במהלך הדרך.כלומר, הרבה דברים שאנחנו חיכינו או עשינו Hacks או Workarounds כדי להקים, פתאום בגרסה הבאה של Kubernetes כבר היו Native Resources ונוהלו על ידו.אז דווקא הייתי אומר שמבחינת Complexity, אני למעשה יכול להשתמש היום ב-Kubernetes כמו שהשתמשתי בו לפני שש-שבע שנים, כי רוב ה-Main Objects  הם Stable כבר מאז.אבל אם יש לי צרכים ייחודיים, שהם הייתי אומר Outstanding, אז גם יש לי את האפשרות להשתמש בדברים שהם יותר Complex ולעשות יותר Tuning לפרישות ול-Workloads שלי.(רן) אבל אני גם חושב, אורי, שמה שאתה מתאר זה איזשהו מעגל אופייני של שימוש בטכנולוגיה. אתה יודע - היא מפשטת, ואז על זה בונים ומסבכים, ואז היא שוב משהו מפשטת . . .(אורי) . . . הבעיה היה משתמשים . . . כי יש משתמשים - יש בעיה. הבעיה היה העולם - הם רוצים פיצ'רים . . .(רן) כן, כן . . . אבל כאילו, אני אומר שזה קורה עם המון טכנולוגיה. זאת אומרת נכון שבמקרה הזה דיברנו על  Kubernetes, אבל זה קורה כמעט עם כל טכנולוגיה - אם זה טלפונים חכמים, אם זה LLM-ים, כל דבר שאתה תדבר עליו - אני חושב שזה נכון.19:40 על Resource Requests, Limits, שכנים רועשים ו“הסכרת של ה-Workloads”אוקיי, בוא נחזור קצת ל-Best Practices - אז אמרת: בתור התחלה, אל תפרשו בעצמכם את ה-ETCD ואת כל ה-Control Plane, תשתמשו במשהו מוכן - ויש כאלה, טובים וחזקים. תשתמשו פשוט ב-Cloud Provider שלכם.זה עדיין . . . זאת אומרת, אמרנו - זה אולי 20% Lock-In, אוקיי? אבל זה לא 100.אוקיי - מה עוד?(ארז) אז בוא נגיד שהעלינו את הControl Plane - עכשיו בעצם אנחנו צריכים להתחיל להתעסק ב-Data Plane, שזה ה-Workloads שאותם אנחנו מפתחים ומריצים בענן.אז אני חושב שהדבר העיקרי שכדאי להכיר וגם להשתמש ב-Kubernetes זה בעצם היכולת להגדיר Resource Requests ו-Limits.משפט על זה - אז Resource Requests בעצם עוזר ל-Kubernetes להבין כמה Resources - אם זה CPU  או Memory, אתה צופה שה-Process שלך ידרוש.ובהתאם לזה לעשות Scheduling נכון ל-VM-ים ב-Data Plane שלך.(רן) כלומר, אם אתה פורש איזשהו Service, אתה צריך להגיד מראש - לנחש, או אולי ככה, לעשות “Guesstimation” של כמה CPU תרצה להשתמש וכמה זיכרון . . .(אורי) . . . .או ניסוי וטעייה . . .  אתה רואה שאתה לא משתמש בכל מה שחשבתם.(רן) . . . מה שנקרא Sizing . . .(ארז) נכון. ברוב המקרים מאוד קשה לצפות את הדברים האלה מראש.ולכן אתם צודקים - מה שעושים זה שפורשים את זה בענן, נותנים לזה לרוץ X זמן, ואחרי זה בעצם לוקחים איזשהו Percentile של השימוש, כדי גם לאפשר מרווח.(רן) אבל אני חושב שזאת מסקנה יפה ונכונה להמון סוגים של Resource-ים. זאת אומרת, לפעמים ה-Resource זה API שאתה חושף החוצה ללקוחות - וגם את זה תרצה להגביל. אתה יכול לקבוע “לא יותר מ-5,000 Request-ים בשנייה”, או Whatever. אם זה גודל של קובץ שאפשר לעשות לו Upload . . .  נכון, אתה לא מדמיין שהם יעלו לך קובץ של 1 Tera, אבל בוא - תגביל. אז “לא יותר מ-Mb500”. לכל דבר תשימו מגבלות - כולל לשירותים שלכם, כי גם אתם תפתיעו את עצמכם באיזשהו יום ותיצרכו יותר זיכרון ממה שחשבתם או שתיצרכו יותר CPU ממה שחשבתם, ואתם כנראה . . . .קודם כל, אתם רוצים לעזור לCluster - לשים את השירות במקום הנכון, שיש לו מספיק ממה שהוא צריך. ודבר שני  - לדעת כשחרגתם ולדעת לנהל את זה . . .(ארז) להגביל את החריגה.(רן) כן - “שלא תפריעו לשכנים שלכם”, מה שנקרא . . .(אורי) גם חשוב לדעת שזה - בסוף זה “קוביות של טטריס” שה-Cluster משחק איתן - ואם תיקח קוביה גדולה מדי, יהיו לך פחות אפשרויות לפרוש.(ארז) נכון, אתה תהיה פחות Efficient כנראה.רק מילה על העניין של Request-ים ו-Limits - נכון, אז Request משתמשים, ה-Scheduler משתמש בהם.ו-Limits ממש מגבילים את ה-Process שלנו, וצריכים להיות מאוד זהירים פה.כי אם אנחנו מגיעים ל-Memory Limits, אנחנו בעצם נחטוף Restart OOM-Kill.אבל לדעתי יותר גרוע זה להגיע ל-CPU Limits - שם אנחנו חוטפים CPU Throttling, ולמעשה all hell break loose . . . [ד”ש לקבוצת ה-Power ב-Intel . . . .]חוויתי לא מעט פעמים במהלך הקריירה שלי Process-ים אפילו תשתיתיים שמגיעים ל-CPU Limit, חוטפים Throttling - ומאוד קשה להבין, אם לא מודעים, אם אין Awareness לעובדה הזאת, מה לעזאזל קורה.כי למעשה, כל השמה של משתנה עלולה לקחת פתאום 20 שניות - ואלה דברים שבדרך כלל אנחנו לא צופים.לרוב אנחנו צופים האטה כתוצאה מ-I/O או כתיבות לדיסק - לא מ-Execution של קוד לוקלי.ו-CPU Throttling זה . . . אני קורא לזה “הסכרת של ה-Workloads” - צריך לשים שם את העיניים.להציב אותם - אבל גם לדעת להיות Aware ולנטר את הדבר הזה, כדי שלא נפגע.(רן) כן, אבל פה אולי חשוב לדבר על למה בעצם מעניין אותנו על “השכנים הרועשים” - כי למעשה אותם Pod-ים,אותם Container-ים שעליהם דיברנו - אוקיי, Pod זה קצת יותר מ-Container, אבל לא נכנס לשם - למעשה, הם  פרושים הרבה פעמים על אותה חומרה, אבל, זאת אומרת, הם שירותים שונים. לוקחים שרת מאוד מאוד גדול, מחלקים אותו - דרך אגב, זה גם כמובן מה שה-Cloud Providers בעצמם עושים, אבל גם בתוך Kubernetes - לוקחים חומרה, מחלקים אותה לפרוסות קטנות יותר, ועל כל פרוסה שמים איזשהו Pod, ואם Pod אחד “משתולל”,אז הוא יכול להפריע לכל האחרים.(ארז) כן, תופעה שנקראת “Noisy neighbor” - “השכן הרועש”.אפרופו Komodor - אז יש לנו גם מנגנון Detection לדברים האלה.כלומר, Pod שה-Execution שלו נפגע, למרות שהוא לגמרי עומד ב-Request-ים וב-Limit-ים שהציבו לו, רק כי Pod שכן שלו - היה לו את אותו VM בטעות, והחליט להתפרע.(רן) אז יבואו חכמים וגידו “רגע, אז למה צריך שכנים?! - אז תשים Service אחד על כל Host אחד!” . . . “מה הבעיה? למה אתה צריך לקבץ אותם?”(ארז) אז אני חושב שפה...(אורי) . . . . כי “מה הועילו חכמים בתקנתם”, נכון? . . . (רו) . . .  אנחנו כל כך צדיקים היום, הא?(ארז) אני חושב שהניסיון פה באמת . . .  הייתי אומר שני דברים:אחד - לעשות אבסטרקציה ל-VM-ים, בסדר? התשתית היא רק ה-Vessel שעל גביו אתה רץ, ואתה לא באמת חייב להכיר איזה סוגי Node-ים וכמה CPU.הכל נכנס לאיזה Blob אחד - כמו S3 ל-Blob Storage, אז הייתי אומר CPU ו-Memory Storage.והדבר השני זה Cost Efficiency - בעצם, זה שאנחנו יכולים לחתוך את ה-Workload שלנו לחתיכות קטנות יותר.אם דיברת על מחסן או טטריס, אז זה בעצם מאפשר לנו לקבל הייתי אומר, “כיסוי יותר מלא” של ה-Resources שאנחנו משלמים עבורם.(רן) כן, אז אם נגיד פעם היה לכם One service per VM, אבל ה-VM היה מגיע, בימים טובים, ל-20% CPU או 15% זיכרון - אז פה אתם יכולים להיות יותר יעילים, בלי לעבוד כל כך קשה. זאת אומרת, לתת ל-Kubernetes לעשות את העבודה של הצמצום בשבילכם.(ארז) לגמרי.(רן) אוקיי, אז אמרת Resource Request ו-Resource Limit, שזה דברים דומים אבל לא בדיוק אותו דבר: Request זה כמה אני צריך ו-Limit זה מתי “תחנוק אותי” - ולמעשה, ה-Best Practice הוא להשתמש בשניהם.25:42 כשקשה - קשה לכולם(רן) אוקיי, אז דיברנו בינתיים על שניים, אולי שניים-וחצי -  בואו נעבור לדבר הבא. מה עוד כדאי לעשות?(ארז) כן, אז זה מאוד חשוב להכיר את כל נושא ה-Probe-ים ב-Kubernetes, שזה בעצם היכולת שלנו להגדיר ב-Deployment שלנו, ב-Container, איך Kubernetes יודע שהוא חי ובריא.בעצם, יש שני סוגים של Probe-ים כאלה - אחד נקרא Liveness Probe והשני Readiness Probe.כש-Readiness Probe - במידה וה-Pod שלנו לא עונה, לדוגמה, לאיזשהו TCP Socket או כל בדיקה אחרת.זה בעצם יוציא את אותו Pod מה-Service, והוא יפסיק לשרת בקשות.שזה, הייתי אומר, פעולה שהיא פחות Intrusive.ו-Liveness Probe - במידה ואנחנו לא מצליחים לעבור אותו, ה-Container שלנו יחטוף Restart.אז ההמלצה היא כן להשתמש בשני המנגנונים האלה, אבל בכל מה שקשור ל-Liveness Probe - צריכים להיות זהירים.כי בהרבה מהמקרים, בעצם מה שקורה זה שה-Pod שלנו הוא לא בריאמאיזושהי סיבה - זה גם יכול להיות כתוצאה מאיזשהו כשל Infra-אי, כמו Database או Redis או Queue.וה-Restart שלו בעצם יוצר אפקט של Cascading Failure, כי לפעמים Process-ים שעולים צריכים לחמם Cache וצריכים לפתוח Connection-ים ל-Database, וכל מיני Warm-up-ים כאלה . . . .(רן) כמו שאומרים - כשקשה, קשה לכולם, אז אל תעשה את זה קשה יותר . . . .(רן) אבל אולי, רגע, נחזור אחורה - מה המשמעות, למי שלא מכיר: מה זה Liveness ומה זה Readiness? אז בעצם,כשכותבים שירות, ברוב המקרים אתם רוצים יותר מ-Instance  אחד שלו, אתם לא רוצים שיהיה רק אחד. אז אם זה ששמים זה מאחורי Load Balancer או אם זה איזשהו Job שרץ ברקע, אז זה משהו שנגיד קורא Job-ים מ-Queue ומריץ. אבל אתם רוצים יותר מאחד כזה, כי כל אחד יכול “להתאדות” מתישהו, אז תמיד כדאי שיהיה יותר מאחד.עכשיו, כשאחד כזה עולה - פרשתם נגיד, או עשיתם Restart, ויש לכם אחד כזה חדש - אתם רוצים לבוא ולהגיד מתי הוא מוכן להתחיל לעבוד, מתי להכניס אותו ל-Load Balancer או מתי הוא יכול להתחיל לקרוא מהתור וכו’, ולצורך זה, באמת מוגדרים ה-Probe-ים האלה.אז Liveness זה אומר “אני בחיים. אולי אני לא אעשה את הדבר הנכון, אבל אני בחיים - רגע, אל תהרוג אותי” . . . .(אורי) . . . אני - ה-Container. זה עוד לא אומר שה-Service בחיים . . . . הפוך זה ה-Readiness, “אל תהרוג אותי” . . .(רן) אוקיי, סליחה - זה ה-Readiness, וה-Liveness זה אומר “אני מוכן - תביא!”. תביא עבודה, תן לי Traffic . . . (אורי) לא . . . הפוך.(רן)  אז צדקתי מהתחלה! אז רגע . . . (ארז) שני ה-Probe-ים האלה יכולים להצליח או להיכשל.כש-Pod עולה, הוא צריך לעבור Readiness Probe, כדי להתחיל לשרת בקשות.הוא גם יכול להיכשל במהלך ה-Lifetime  שלו, ולצאת ולהיכנס שוב לאותו סט של Pod-ים, שבעצם מנגיש לו את ה-ה-Service.ו-Liveness Probe, מהצד השני, בעצם ברגע שהוא נכשל הוא ב-Restart.ואותו Pod יכול לעבור גם כמה Restart-ים במהלך ה-Life cycle.(רן) זאת אומרת, אם ה-Live שלי נכשל, זה אומר כאילו “תהרגו אותי” . . . “אין לי מה לעשות פה, אני לא מועיל יותר”(ארז) “אני תקוע, אני צריך שמישהו יבוא לחלץ אותי”.ו-Readiness זה “שים אותי שנייה בצד, תחזור אותי עוד כמה דקות, אני רגע עסוק”.(רן) . . . “אני עסוק, רגע, אל תפנה לי Traffic . . .  הנה, אני מוכן! עכשיו אני Ready!”(ארז) בדיוק.(רן) בסדר.(ארז) אז רק לחדד פה, שהסכנה היא באמת בעיקר ב-Liveness Probe, בגלל ה-Cascading effect שנוצר כתוצאה מ-Restart-ים.לא להשתמש בו Blindly, מה שנקרא.(אורי) רגע, אני רוצה להבין משהו - יש קשר בין הקוד או ה-Service שרץ על ה-Container, לבין ה-Probe-ים האלה? זאת אומרת אני יכול להשתמש בהם, נגיד אם ה-Cache שלי עוד לא חם . . .(ארז) לגמרי . . . .אז למעשה, בוא ניקח Probe קלאסי, שדוגם איזשהו HTTP Endpoint בקוד שלך.ואתה, בקוד שלך,  באותו קוד של Endpoint, יכול להגיד “אני בודק שה-Connection שלי ל-Database בריא, ושחיממתי את ה-Cache ושהצלחתי להוריד קובץ קונפיגורציה מ-S3.ורק החל מהרגע שאותם תנאים יתמלאו, אתה מכריז על עצמך בתור Ready, כלומר - “אני מוכן להתחיל להנגיש את השירות, לשרת לקוחות”.(אורי) ואז בעצם, מבחינת המערכת - ה-Load Balancer, או מה שזה - ה-IP שלי “חי”.(ארז) ה-IP הוא למעשה חי מרגע היווצרות ה-Pod , מוצמד IP לכל Pod.השאלה היא האם אתה חלק מה-Target Group ב-Load Balancer, או לא?זאת השאלה, זה ה-Readiness - אם אתה מוכן אז אתה חלק מה-Target Group, ואם אתה Not-Ready, אז אתה יוצא מה-Target Group.(רן) יש מקומות שבהם ל-Readiness הזה גם קוראים Health, זה אומר “אני בריא ואני מוכן לשרת!”, כלומר - כמו שאמרת: “יש לי את החיבור ל-Database שאני צריך, יש לי מספיק זיכרון” . . . לא יודע, “טענתי מה-Cache, אני מוכןעכשיו לקבל”, “פתוח לקבלת קהל” מה שנקרא.30:21 איך הוא עושה Distribution לדבר הזה / Anti-Affinity, Taints & Tolerations(רן) בסדר, עכשיו כתבת פה בסעיף D [בהכנות לפרק] מונח מאוד מעניין, שנקרא Anti-Affinity . . . ובכן?(ארז) אז בעצם, דיברנו על ה-Scheduler של Kubernetes, שבסוף - יש לו אוסף מאוד גדול של Pod-יםחלקם מאותו Service, חלקם מ-Service-ים שונים.והוא צריך עכשיו להחליט איך הוא עושה Distribution לדבר הזה, כדי באמת להפוך את אותו Service ל-Highly Available, Resilient, Fault-Tolerant וכל ה-Buzzwords האלה.ובעצם, Anti-Affinity Rules מאפשרים לנו להגדיר ל-Scheduler איך לבזר נכון את אותם Pod-ים. כש-Anti-Affinity Rule יכול להיות “אל תשים לי שני Pod-ים מאותו Service על Node יחיד”, הם יכולים להיות “אל תשים לי באותו Availability Zone”, אוקיי? כלומר, יש לנו דרך להגדיר איך אנחנו היינו רוצים שה-Scheduler יבזר את ה-Workloads שלנו כדי שבאמת אם יש עכשיו איזשהו כישלון Availability Zone, ב-AZ אחד ב-Amazon, אז בעצם יש לנו עוד שני AZs שכבר פרושים שם Pod-ים . . . (רן) כלומר, הCluster, “באופן טבעי”, גם פרוש על פני מספר Availability Zones - ו-Kubernetes מבין את זה. הוא מבין את ה-Concept, הוא יודע. ואז, כשאתה פורש את השירות שלך, אתה אומר “תשים לי אחד בכל Availability Zone”, אין טעם לשים את כל השלושה באותו אחד, כי אין בזה טעם.(ארז) אז מה שמעניין, דרך אגב, זה ש-Kubernetes לא באמת חייב להבין את זה.אלא כל Node שעולה מקבל Label-ים מה-Cloud Provider, ולמעשה אתה יכול להגדיר Anti-Affinity Rules על Label-ים ואפילו על Label - Custom, שאתה שמת.(רן) “שרירותיים” . . . (ארז) כן, בדיוק.(רן) אבל Out of the Box, כנראה אני מניח שעל פני ה-Cloud Provider יש גם את ההבנה הזאת, ואתה יכול בנוסף לייצר אחרים.(רן) אוקיי, אז זה מה שנקרא Anti-Affinity. בסדר, אולי קצת . . . (ארז) יש עוד איזה נושא שהוא טיפה קרוב . . . הוא לא בדיוק זה, אבל זה כל העניין של Taints ו-Tolerations.קצת מורכב, אבל בעצם Kubernetes מאפשר לנו לשים Taint-ים, שזה סוג של סירחון, לפחות לפי התרגום שאני קראתי . . . ורק Pod-ים שהם יהיו Tolerates את ה-Taint הזה יהיו Scheduled לאותו Node.זאת נגיד דרך מעולה לעשות Scheduling ל-Pod-ים שצריכים GPUs רק ל-GPU Nodes.או לבודד כל מיני Infra Workloads שהיית רוצה שירוצו לבד.זה גם אחלה כלי . . . (רן) כן, כלומר אוקיי - אולי לא הייתי קורא לזה “סירחון” . . . יכול להיות זה הפירוש, אולי הייתי קורא לזה “איזה טעמים” - איזה טעמים יש לזה: “יש לזה טעם של GPU - אני רוצה לרוץ על משהו עם טעם GPU” או “יש לזה טעם של High Network Bandwidth, אז אני רוצה לרוץ על משהו כזה”.(ארז) בדיוק.(רן) בסדר. עכשיו, זה Label-ים שה-Cluster Admin, לצורך העניין, שם על ה-Node-ים, כי כשהוא מרים את ה-Cluster, אז הוא מבין מה יש לו. ואתה, בתור מפתח שכותב את השירותים, אתה יכול לעבור ולהגיד מה אתה מעדיף.מה קורה אם אין כאלה? מה קורה אם אין מספיק - מה ה-Kubernetes יעשה?(אורי) . . . אם אין מספיק Resource-ים . . . . (ארז) כן, אז בעצם - האמת שזו התנהלות ממש מעולה של Kubernetes.כי Pod -ים שה-Scheduler לא מצליח לסקנג'ל (To Schedule) אותם לתוך Node-ים בגלל Insufficient Resources, והוא גם יודע להגיד למה, בעצם זאת ההזדמנות שלנו להטריג (Trigger) Auto-Scaling ב-Cluster ולהעלות עוד Node-ים.ובאמת, Cluster Auto-Scaler ו-Karpenter - שהם הייתי אומר שני הכלים המובילים היום ל-Scaling של ה-Infra - הם משתמשים ב-event-ים האלה כדי להבין שצריך להוסיף עוד Resources לCluster, כדי לספק את הביקוש.(אורי) אתה יכול לכוון אותם בצורה מסוימת? זאת אומרת, לתת High-water mark, Low-water mark . . . (ארז) בדיוק. אז אפשר להגדיר Headroom, אפשר להגדיר מינימום, מקסימום . . .אפשר להגדיר אותם פר AZ . . .  כלומר, ממש “קונפיגורציה כאוות נפשך”.באמת כלים מעולים, שפשוט מתממשקים לעובדה הזאת - ולא אמרנו את זה, אבל כדאי להגיד: אני חושב שאחד החידושים או באמת הדברים ש-Kubernetes הביא לעולם זה האיחוד של כל ה-Infra וה-Workloads תחת Unified APIs.וזה בעצם מהווה כר פורה ל-Ecosystem מטורף, שפשוט משתמש במידע הזה וקורא וגם כותב אליו.(רן) כן. פה, אתה יודע . . . זאת אומרת, כמישהו שמתעסק עם מערכות, לפעמים יש דילמה של מתי לייצר אבסטרקציה. כלומר, מתי לאבסטרקט (Abstract) את ה-Infrastructure מהמפתח, ומתי כן לחשוף.נגיד, אתה לא תמיד רוצה לדעת על איזה סוג של CPU - האם אתה רץ על Intel, על AMD . . . . - זה לא תמיד מעניין אותך.(ארז) נכון.(רן) . . . אבל אתה אומר - אם זה מעניין אותך, אז אתה יכול לדעת. אם מעניין אותך איזה סוג של Network יש, אז אתה יכול לדעת, אבל זה לא תמיד אכפת לך.(ארז) נכון. הם פשוט עשו עבודה מעולה בלהנגיש, כמו שאתה אומר, את האופציות.ועדיין - לא להכיר אותם בכלל, ולעבוד בסדר.שזה, הייתי אומר, ה-Sweet-Spot.35:08 כמה מילים על Monitoring, על מה להסתכל ואיפה החברים מהגן(רן) כן, בסדר, אולי ככה אנחנו לקראת סיום - אולי כמה מילים על Monitoring? על מה כדאי להסתכל?(ארז) כן, אז דבר ראשון - Kubernetes, כמו שאמרתי, מחצין המון המון מידע בצורה סטנדרטית.וזה מאפשר להמון כלי Monitoring לעלות.היום, ה-Stack הרווח הוא kube-state-metrics, Prometheus, Grafana  . . . אפשר להתקין אותם ב-Helm Charts שהם Official מאוד בקלות. אז אם הייתי צריך לבחור היום Monitoring Stack ל-Kubernetes - כ-In-House כמובן, שהוא לא חיצוני - כנראה שהייתי הולך עם הכלים האלה.אז זה דבר ראשון.עכשיו, לגבי על מה להסתכל - אז אני חושב שקצת עברנו על זה ב-Best Practices, אבל בעיקר על ה-Resource Usage.בעיקר לשים לב ל-CPU ולהגעה שלו ל-Limits.על Container Restarts - שאנחנו אולי נוטים להתעלם מהם, אבל הם עדיין איזשהו סימפטום של תופעה שלא רצויה, ותמיד יכולה להתגבר ברגעים הכי פחות מתאימים [גם בחלליות…].ואם משתמשים ב-HPA - שלא דיברנו על זה, אבל זה הדרך של Kubernetes לאפשר לי לעשות Horizontal Scaling ל-Workloads שלי.כלומר, לפי ה-Consumption - להחליט אם אני צריך יותר Pod-ים או פחות Pod-ים מאותו Service.אז לשים לב שאם הוא מגיע למקסימום לאורך זמן - כנראה שאנחנו עם Insufficient Resources על אותו Service, ולכן כדאי לשנות שם את הקונפיגורציה (Configuration).(רן) כן, אז אולי ממש ניגע בזה בקטנה - דיברנו על Auto-Scaling  של ה-Cluster, עצמו לא דיברנו על Auto-Scaling של ה-Service-ים. אז למעשה, אפשר לעשות Auto-Scaling בשתי הרמות - זאת אומרת, אם ה-Service שלך נגיד אין לו מספיק Pod-ים, ואתה רוצה באופן אוטומטי להטריג (Trigger), זאת אומרת לייצר עוד, ואחר כך להוריד, כי חבל על הזיכרון ועל ה-CPU שלא צריך. אבל אם אתה עושה הרבה כאלה, אז מתישהו גם נגמר לך המקום ב-Cluster . . . ואז אתה צריך לייצר Auto-Scaling של ה-Cluster. ושני הדברים האלה, כמו שאמרת, זמינים ובאים באופן דיפולטיבי (Default) בתוך Kubernetes. אוקיי.(אורי) אותי רק . . . נחזור שנייה להיסטוריה - הוא [Kubernetes.] לא תמיד היה פה, והייתה סוג-של . . . לפני שהוא הגיע, סוג של “מלחמת Provider-ים”, או נקרא את זה “פתרונות”. אני לא בטוח שהוא היה, נגיד, תמיד הכי טוב - אבל איכשהו, The winner takes it all, והוא נהיה סטנדרט . . .(רן) רצית להגיד Mesos, רצית להגיד Nomad, רצית להגיד...(אורי) כן, כל החבר'ה האלה - היום הם לא יודעים...(רן) “החברים מהגן” . . . (אורי) כן, אבל היום לא מכירים אותם - והוא רץ, ו...(רן) כן, אז היו לא מעט - אז הזכרנו כמה: Mesos, Nomad, הזכרת מקודם את AWS ECS, שזה פחות או יותר באותה שכונה. יש את OpenStack, Docker Swarm, יש לא מעט  . . . ובאמת, אני לא יודע מי מהם שרד. כאילו, חוץ מ-Kubernetes. זאת אומרת, ECS קיים . . .(אורי) היה בו משהו, לדעתי - בקהילה, או ב-Google, שדחפו אותו, או...(ארז) אני חושב שהוא באמת, באופן כן, הוא פשוט ייצר את ה-Feature set שהיה הכי נכון - לאותה תקופה.וידע להתגלגל, כמו מוצר אג’ילי (Agile) של חברה מסחרית - ובגלל זה הוא ניצח.הוא פשוט היה קשוב ל-Community, וידע להוסיף את הדברים הנכונים - בזמן הנכון, בצורה הנכונה.וזה מה שקנה אותי לאורך הזמן. ולכן, גם אני, החל מהרגע שעשיתי את ה-Research הזה ובחרתי ב-Kubernetes, לא הסתכלתי אחורה לשנייה.כי באמת לא היה שום מתחרה בסדר גודל כזה, שידע לספק את הדברים.(רן) כן. דרך אגב - זאת אומרת, הזכרנו פה שמות של מוצרים אחרים. הרבה מהם כתובים ב-Open source. זה לא אומר שלא השקיעו בהם כסף . . . משקיעים בהם הרבה מאוד כסף: גם ב-Kubernetes. זה Google וגם אחרים, וגם באחרים - ב-Mesos, ב-Nomad ואחרים - השקיעו הרבה מאוד כסף.זה נכון שהם היו בקוד פתוח - אבל עדיין, צריך לפתח אותם. אז...(אורי) לא, לא - זה תופעה חברתית כזאת, שיש בסוף מישהו שלוקח - Winner Takes it All.(רן) לא, יש פה Network Effect, זה ברור, נכון. זה ה-Community, זה ה-Know-How, זה ה-Adoption מצד ה-Provider-ים. זאת אומרת, יש פה הרבה דברים, יש פה Network Effect משמעותי.(ארז) דווקא אני חושב שפה ה-Adoption הוא באמת היה בעייתי - כי אני חושב שכל Cloud Provider ידע.או לפחות Amazon, שהוא היה בתקופתו, באמת, לא יודע, 80% מה-Market - הם ידעו שברגע שהם עושים Adoption לדבר הזה, זה דווקא מעמיד אותם בסכנה.(רן) נכון.(ארז) הייתי אומר שדווקא Adoption היה נגדו באיזשהו אופן - אבל הם הצליחו בכל זאת.פשוט כי זה היה הכלי הנבחר על ידי ארגוני DevOps.(אורי) אני יכול להגיד שלנו ב-Outbrain - הלכנו איתו על On-Prem, אבל אחר כך כשרצינו להיות מסוגליםלעבוד גם על Cloud Providers, זה היה די פשוט.(ארז) מאוד . . .(אורי) עוד פעם - “פשוט” זה לא, אבל... Doable בזמן סביר.(רן) מקודם דיברנו על Lock-In - אבל פה אתה מדבר על Scenario של Hybrid, נכון? או שני Cloud-ים, או Cloud ו-On-Prem . . . אבל זה למעשה, זה אף פעם לא נורא פשוט - אבל זה כן מאפשר את היכולת הזאת [זכרונות מ-2019 - 382 Carburetor 27 - k8s and multi-cloud].(אורי) לגמרי.(ארז) זה מוריד קצת “מהכבלים האלה”, שקושרים אותך ל-Infra.(אורי) כן. לפעמים, אבל כאילו - ב-On-Prem, אתה מסוגל להגיע לעומסים על מכונה מאוד רצינית. פתאום אתה עובר ל-Cloud, שגם ככה יש לו את ה-VM - וכאילו, החומרה לא ממש מנוצלת כמו שצריך, גם אם אתה מתאמץ. ופתאום, אני אומר לך “רגע, אנחנו לא . . . “, ממש, Provider-ים אומרים “אנחנו לא בנויים לעומסים האלה על Node או על...”.(ארז) כן, אז ה-Coefficient של ה-Resource Consumption שלך משתנה, כשאתה עולה ל-Cloud, נכון?(אורי) כן - אז זה משלם יותר . . . (ארז) נכון - Cloud עולה יותר, זה נראה לי ידוע. [וגם זכרונות מ-2021 - 418 Carburetor 31 Cost of cloud paradox]41:26 עוד קצת על Komodor לסיום(רן) כן, בסדר. אנחנו ככה ממש לקראת סיום - אולי עוד כמה מילים על Komodor? קצת על החברה, כמה עובדים אתם? איפה אתם נמצאים? את מי אתם מגייסים - אם אתם...(ארז) מגניב. אז אנחנו נמצאים ביגאל אלון בתל אביב, במגדל סוזוקי.אנחנו פחות או יותר 20 אנשים ב-R&D - עדיין מה שנקרא “קיבוץ”, כולם מכירים את כולם.אחלה תקופה להצטרף.אנחנו מגייסים, הייתי אומר “מכל הדיסציפלינות” - Frontend, Full-Stack, Backend.עובדים ב-React ו- TypeScript ב-Front וב-Golang ו-Python ב-Back.יש המון אתגרים טכנולוגיים.ובכלל - אני חושב שגם מה שהביא אותי ל-Komodor זה ההזדמנות לעבוד על מוצר שהוא ב-Core שלו טכנולוגי.אז לא רק שאני רץ על Kubernetes, ונהנה ממנו ביום יום - זה גם המוצר שאני מפתח.אז אם אתם אוהבים טכנולוגיה ולפתח קוד, הייתי אומר שזה המקום המושלם.(רן) אולי שווה לציין - ה-Komodor הוא ב-K - ולא ב-C, כמו שאולי התרגלתם . . .(ארז) זה ה-Theme שלנו, דרך אגב - יש לנו עוד דברים ב-K . . . (רן) אוקיי, כן. כן, אז זה לא המחשב משנות ה-80 - זה Komodor ב-K, אז כשאתם מחפשים, זה שם.טוב, תודה רבה - ושיהיה לכם בהצלחה. להתראות.[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 489 של רברס עם פלטפורמה - קרבורטור מספר 38, שהוקלט בתחילת ינואר 2025. אורי ורן מארחים את נתי שלום לשיחה על כדורי-בדולח, עננים, ואיך הולכת להיראות שנת 2025 בעיני בוגרים מצטיינים של קורס נביאים. 🎗️01:45 סקירת השחקנים(רן) אז שוב שלום נתי, ובוא נתחיל לדבר. אז מה התחזיות שלך ל-2025?(נתי) קודם כל, אני אפתח במנטרה שלי לשנה הזאת: אני אומר ש-2025 תהיה שנה טובה. בינתיים טפו-טפו-טפו, אנחנו ביום שבו... (אורי) בוא נחזיק את זה עוד רגע?(נתי) נחזיק את זה עוד רגע, אבל יכול להיות שנתבשר סוף סוף על איזו התקדמות עם החטופים. אנחנו זוכרים איפה היינו באפריל שנה שעברה, איפה אנחנו נמצאים היום...כמה דברים אולי השתנו, ונראה שאולי באמת דברים ילכו ויהיו... בוא נגיד, יותר גרוע ממה שהיה שנה שעברה, אני חושב שלא יהיה, אז יהיה יחסית קל באמת להפוך את 2025 לשנה טובה, ובאמת יש הרבה מאוד אינדיקציות חיוביות, אז אני חושב שאת הפודקאסט הזה נפתח בהרבה אופטימיות.בכלל, זה יהיה פודקאסט מאוד אופטימי, אני חושב, לפחות ננסה. 🎗️(נתי) אז אני חושב שהיום, מן הסתם, AI - זה נוגע בכל התחומים, ואי אפשר לכסות את כל הנושאים, אז בחרתי בעיקר להסתכל על השאלה של ה-Arm Race . . .ה-Arm Race - מי שבעצם הוביל את ה-Foundation Models זה היה OpenAI, המנצח המוביל בשנים האחרונות, מאז שזה עלה לגדולה.ואני חושב שהמשחק נפתח לחלוטין. וככה נסקור את השחקנים העיקריים, שהם קנדידטים (Candidates) ל-Foundation Model, להוביל את ה-Foundation Model.(רן) נזכיר - רק לפני כשבועיים היה כנס גדול של Amazon re:Invent, שבו הם הכריזו על מספר מודלים גדולים, והם לא היחידים, כמובן. (נתי) בבדיוק.(רן) אז זה לגמרי כבר לא רק OpenAI, ואני בטוח שאי אפשר גם להתעלם מ-Anthropic ומשחקנים נוספים בולטים אחרים.(נתי) אוקיי. אז אני חושב שיש פה כמה דברים, שאני חושב שדרכם אפשר לנסות לחזות את מי שבאמת יהיה מוביל.ורמז - זה כנראה לא יהיה OpenAI בהובלה.הם יהיו שחקן דומינטי, אבל אני לא חושב שבהובלה.(רן) גם יש מקום, אני מניח, לנישות. זאת אומרת, השוק הולך להיות גדול . . . (נתי) נדבר עוד שנייה על הנישות, נכון. זו מגמה, הייתי אומר, כמעט הפוכה, שגם קורית, והיא גם אלטרנטיבית.ממש רואים שני חצים שרצים בכיוונים שונים, ושניהם וקטורים משמעותיים.אחד זה ה-Open Source, שהולך באמת יותר לעולמות של Edge ומודלים קטנים ו-Desktop-ים, ונדבר עליו. היה עכשיו כנס מאוד גדול של CES 2025, ה-Consumer Electronic Conferenceומה שהלך שם - בעצם, כמעט כל הממשקי-משתמש הם כבר יחידות קצה-אוטונומיות, רובוטים.היה שם, אגב, משהו שאני התלהבתי ממנו מאוד, שזה מראה - “מראת-בריאות” - שקוראים לה Omnia, החברה שמציגים את זה. שבעצם אתה מסתכל על המראה והיא אומרת לך, כמובן, את כל הנתונים שלך - משקל, לחץ-דם, בריאות.“מראה, מראה שעל הקיר” - היא באמת תוכל להגיד לך גם מי הכי יפה בעיר . . . זה ממש מתקדם לכיוונים האלה בצורה שהיא הרבה יותר מ-Science Fiction.(רן) דרך אגב, CES - ראיתי במקרה פוסט של אשתו של חבר שלי, שהם גרים בפינלנד, והיא הראתה איך היא עוזרת  ל-Drone קטן לדלוור (Deliver) אוכל . . . זו מן עגלה כזאת קטנה שמביאה איזשהו משלוח אוכל, וזה אוטונומי - והיא נתקעה בשלג, המסכנה, אז היא עזרה לעגלה הקטנה הזאת להיחלץ מהשלג ולהגיע ליעדה. מה שנקרא “Human Assisted AI” . . . .(נתי) כן, האמת שבכלל משלוחים היום - זה קצת מוזר לחשוב על זה פה בארץ, אחרי מה שעברנו בשנה שעברה - אבל יש כבר הרבה מקומות, מה שנקרא, ב-Rural Countries, שזה בעצם כפרים נידחים, שבאמת המשלוח שלהם מגיע היום עם חבילות, עם Drone, שהם מניחים להם את זה בחצר [הי Flytrex].אז יש המון המון המון AI היום, בכמעט כל התחומים.אנחנו באמת נתרכז ב-Foundation Models - שם אני בחרתי את Microsoft, מן הסתם את Google . . .(רן) אני חייב להעיר, בהערת ביניים, שאורי פה קופץ משמחה בכיסאו, כי הרבה זמן לא דיברנו על AI, נכון? . . . (אורי) כן, ממש . . . (רן) . . .  והנה - הגיע הזמן! אז כן, איכשהו, אני לא יודע, אולי זה העולם - אבל יוצא לנו, נראה לי בעשרה פרקים האחרונים, פחות יותר, לדבר על...(אורי) אמרתי לך . . .  אני אמרתי “טוב, המהפכה הזאת יכולה לקרות בלעדיי”, ו... כנראה שלא.(נתי) כן, אז אני אומר, אנחנו נסקור שנייה את השחקנים: אני חושב שהמשמעותיים זה Microsoft, Google, Amazon, באמת כמו שתיארת.ואני שם הרבה ז'יטונים באזור הזה - Elon Musk עם X.ai. ובאמת ננסה להבין, כתוצאה מזה, מי באמת יש לו את סיכויי ההצלחה הגבוהים, וגם איך OpenAI מתמודדים עם האתגרים האלה.אז אני חושב שמ-Microsoft - האסטרטגיה ש...(רן) ואגב - רכילות קטנה: אם אני לא טועה, אורי, ה-Domain של X.ai נקנה מעובדים של Outbrain לשעבר? או שחברה שקנתה? . . . (אורי) לא, לא קשור לזה, אבל מחברה הישראלית.(רן) אה, אוקיי. לא, כי היו פעם...(אורי) לדעתי Winward או . . . לא יודע, לא זוכר, אבל...(רן) כן, זכרתי איזשהו קשר לעובדים של Outbrain שעבר, שהקימו חברה אחרי זה, בתחום של Calendar Management, ואם אני לא טועה, זה היה ה-Domain שלהם. אבל יכול להיות שאני מבלבל עם משהו...(אורי) לא. זה נקנה מאיזושהי חברה ישראלית, אבל אני לא חושב ש...…(נתי) אוקיי, “חזרה לענייננו” מה שנקרא: אז אני חושב ש-Microsoft - האסטרטגיה שלהם, כמו תמיד, היא Bundle Approach.זאת אומרת, הם בעצם מחברים את ה-AI ל-Office, ולכל הסביבה שלהם עם Copilot, everywhere - ב-Desktop, במסמכים שלך, בפרזנטציה, בכל המקומות שאפשר.גם ב-Search שלהם, שאגב - עובד לא רע בכלל.וככה הם בעצם מחזקים מאוד את האחיזה שלהם.זה עבד להם עד עכשיו, זה כנראה יעבוד להם עכשיו.(רן) אוקיי, אבל גם יש להם ז'יטונים אצל OpenAI, זה גם קצת עוזר . . . (נתי) כן, אני אומר - יש להם גישה, הם משתמשים במודלים של OpenAI, אבל בעצם הם לאט לאט . . .בעצם, האחיזה שלהם היא מן הסתם מול הData של הלקוחות, השתלטות על האזור הזה.ואז בעצם הם מסגירים קצת את התלות שלהם ב-OpenAI, בהקשר הזה.והולך להם לא רע - אני רואה למשל אצלנו, כמה השימוש רחב.מאוד קל ל-Enterprise לצרוך את זה, זה נגיש להם מאוד.זה הופך להיות אבולוציוני, במקום רבולוציוני, ו-Microsoft מאוד טובים בגישה הזאת - להכניס את זה ל-Teams ולהכניס את זה ל-Office ולהכניס את זה לזה . . . ב-Teams אתה מקבל עכשיו את הפגישות מסוכמות ואז זה מביא לך Calendar, ואתה יכול אחרי זה להגיד ל-Copilot . . . (רן) זאת אומרת שבתור Enterprise, ה-Adoption של הטכנולוגיה זה לא תמיד שאלה טכנולוגית, זו הרבה פעמים שאלה רגולטורית . . . כלומר, אם יותר קל להמשיך, למי אני כבר יודע לשלם, אם יש לי כבר חוזים . . . (נתי) בדיוק. נכון, ראינו את זה ב-Slack אגב, עם Slack מול Teams,זה לא ש-Teams היה יותר טוב מ-Slack, פיצ'ר מול פיצ'ר - אבל האינטגרציה של Teams עם שאר Office  היא זו שהובילה הרבה פעמים למשחק.ואני חושב שכולם באים ואומרים . . .(רן) טוב, אני רואה שמבחינת ההגבלים העסקיים . . .(נתי) לא תחת שלטון טראמפ, ולא תחת הביליונרים שעכשיו איתו . . . לא נראה לי שהם ישחקו על מגרש הזה.אבל אני חושב ש...(אורי) המירוץ-סוסים שם התחיל, ואף אחד לא מתכוון לרסן את הסוסים . . . (נתי) בדיוק.יהיו בזה, אני חושב, גם הרבה דברים חיובים - אבל את הדברים האלה בואו לא נצפה, בואו לא נהיה נאיביים . . .(רן) לא, בסדר - אבל זה גל-סינוס, אתה יודע. אז עכשיו זה עולה, אחר כך זה ירד. . . .(נתי) ה”ירד” -  יורד בסוף מעט . . . .בכל מקרה, אז אני חושב שהאסטרטגיה של Microsoft במקרה הזה נראית לי יחסית ברורה.יש להם סיכויי-הצלחה מאוד גבוהים, מול ה-Adoption של ה-Enterprise ל-AI.די ברור שכמו בכל טכנולוגיה, בסוף זה המגרש המרכזי - מי שינצח את הקרב הזה, הוא זה שיהיה “על הסוס המרכזי”.(אורי) אגב, באופן מוזר, היום עשיתי איזשהו Zoom, ופתאום ביקש להצטרף ל-Zoom איזה Bot של Copilot, של אחד המשתתפים . . . ושאלתי אותו מה זה הדבר הזה, אז הוא אומר לי  . . . . “אתה יכול להוריד את זה, אבל בגדול ה-Copilot שלי נכנס, והוא אחר כך מוציא לי סיכום של הפגישה”. שזה אחלה - אבל זה יד אחרת של Microsoft,שהיא לא Teams . . . כאילו, זה היה ב-Zoom.(נתי) כן, אז אני אומר - אז קודם כל, יש בהחלט דריסת-רגל . . . אני חושב שהחיבור בכלל ל-Office הוא מאוד טבעי, בהרבה מאוד מובנים,כי הוא נותן Efficiency, כמעט בלי לשנות שום דבר מהחיים הרגילים שלך.אז באמת הסיפור של Teams וסיכום פגישות הוא שינוי מהותי,אני יכול לא להעלות על שיחות, ולעשות Catch-up מאוד מהיר למה היה בשיחה.הרבה פעמים אני אומר “טוב שלא בזבזתי את הזמן”, כי אני רואה שקישקשו שם רוב הזמן שטויות.אתה רואה גם מי דיבר, אז לפעמים אתה רוצה לעשות Zoom-in למי שדיבר, אז אתה לוחץ שנייה לשנייה שהוא דיבר . . . .זו באמת מהפכה של Efficiency, בסדר גודל ממה שאני חושב חווינו עד היום בכל מהפכה שהייתה, אני ממש רואה את זה ביום יום.אז זה Microsoft.11:29 למי יש הכי הרבה Dataאני חושב ש-Amazon באמת רוכבים על הגל של ה-Cloud שלהם, מן הסתם כל אחד נצמד לנכסים המשמעותיים שיש לו, ודרכו בעצם מנסה לפרוץ את הפוזיציה שלו.אז ל-Amazon יש כמובן Stronghold משמעותי ואחיזה מאוד משמעותית בעולמות של ה-Cloud.אז הם מן הסתם הלכו על כיוונים של Ecosystem ושל לתת לך יכולת של מגוון יחסית רחב של כלים, בתוך המגרש-משחקים הזה שהם בנו.שבעצם מאפשר לך גם להתנסות יחסית בקלות, וגם לבנות את התשתית שלך, שאתה רוצה, ב-Amazon.וכמו תמיד, מה שהם עושים זה שהם רואים למה יש Adoption יותר גבוה - ומציעים אותו כבר כשירות Amazon-י, לאט לאט . . . וכמו שאמרת, אני חושב, אני לא הייתי בכנס, אבל לא מפתיע אותי שעכשיו הם נכנסים עם היד עוד יותר עמוק לתוך התחום הזה ומתחילים להוציא מודלים משלהם.יש להם כמובן - וזו הנקודה הבאה שאני אגע בה - זה למי יש הכי הרבה Data, כי אני חושב שזו נקודה . . . כשאני אדבר עכשיו על Google, ואנחנו נחזור חזרה ל-Amazon ול-Elon Musk ונדבר על הנקודה הזאת, כי אני חושב שזה איזור-החולשה הכי גדול של OpenAI,ומצד שני, זה איזור-החוזקה הכי גדול של שאר השחקנים . . .(רן)  המחסור בData . . .(נתי) המחסור בData או השליטה שיש להם היום בData.(אורי) כי אין להם, כמו כל אחד אחר, איזור שממנו הם מגיעים, ששם כבר יש User Base . . . (נתי) נכון, הם מגיעו מטכנולוגיה . . . בדיוק, הם הגיעו מטכנולוגיה, והחברות האחרות, הם יושבים על הרבה מאוד Asset-ים של תוכן.יש לך ב-Amazon, מעבר כמובן ל-eCommerce site  שלהם, שזה חתיכת אזור שיש פה הרבה מאוד מידע צרכני, מוצרים ויכולות בהקשר הזה.יש להם גם את . . . ברח לי השם של ה-Voice הזה . . . .(רן) Alexa?(נתי) . . . . Alexa, כן, שזה הרבה מאוד Voice וכל האינטראקציה של אנשים בבית ובכל ה-Consumer Business.זה חתיכת בסיס-נתונים, שאפשר לתת עליו שירותי ערך-מוסף.ודווקא מי שהספידו, שזה Google - אני חושב שנותנים פייט עכשיו, מאוד משמעותי, עם ‎Gemini.אני מתנסה הרבה עכשיו ‎ עם Gemini, למשל.דוגמא משמעותית שאני כל הזמן מוצא את עצמי ב-Gemini זה של-OpenAI אין אינטגרציה עם Google וגם לא עם Twitter, אז כשאני אומר לו “אוקיי, קח Post ב-Twitter ותסכם לי אותו”, הוא לא מסוגל, ואני צריך  לעשות Cut & Paste ואז אז לזרוק אותו וכך הוא יכול לסכם את זה . . . אז כשאני מדבר על Elon Musk, למשל, אז אתה מצפה ששם זה יהיה טבעי.וקרה לי באמת אותו דבר עם Gemini, אז לקחתי את אותו Post ואמרתי לו “אוקיי, תביא לי עכשיו לינקים לדוגמאות”.נניח, עשיתי איזה Post סיכום של מה שהיה ב-CES ומה הנקודות ואיזה דברים הכי זה . . . . ואמרתי לו “אוקיי, תשים לי לינקים לכל הדוגמאות האלה”.“תעבר Bullet-Bullet ותוסיף לי לינק ל-Demo של כל אחד, במקום שאני אלך ואעשה את הדבר הזה .והוא באמת עשה את זה . . . אז OpenAI לא ידעו לעשות את זה - הם ידעו להגיד לי “תרשום את זה ב-Search ותביא את הוידאו” . . . .כי הם ידעו כנראה מה לינק, אבל הם לא יכלו לשים אותו . . . .וב-Gemini, למשל, כן יכלו לעשות את זה.(רן) דרך אגב, אחד הכלים שמאוד עוזרים ב-workflow כזה זה NotebookLM, בטח יצא לך להתנסות בזה.(נתי) כן, בטח.(רן) אז זה כלי ש-Google הוציאו, אני מניח שמאחורי הקלעים משתמש ב-Gemini, אני לא יודע במה הוא משתמש מאחור, אבל הוא עושה אחלה סיכומים והסברים וכו’. זאת אומרת, “אתה זורק עליו ערימה של מסמכים”, אתה אומר לו “תסתכל על האתר הזה” או שזורק עליו אוסף של מסמכים - והוא יודע לעשות אחלה עבודה יחד עם זה.(נתי) אז נכון, אז אני חושב שזה בהחלט . . .  ב-YouTube היה מישהו שזרק מספרים מאוד מעניינים בהקשר הזה.שיש בגדול, אם אתה מסכם את כל המילים בעולם, אתה מגיע ל-5 ביליון, אבל אם אתה מסכם את תוכן הווידאו, אתה מגיע לכמעט 80 ביליון, משהו כזה . . . איזשהו יחס, מכפיל הרבה יותר גדול של Data.של Data שאתה יכול לצבור, במקרה הזה מילים וטקסט שאתה יכול לקחת מהתוכן הזה.וכמובן שתוכן בווידאו יותר עשיר מטקסט, אז יש לו הרבה יותר Data שנמצא בו.(אורי) כלומר, “תמונה שווה אלף מילים” . . . (נתי)  . . . והיא כנראה שווה יותר מילים.(אורי) . . . . ווידאו שווה אלף תמונות - אז הגעת למיליון . . . (נתי) נכון, כי אתה עושה OCR לדבר הזה, ואז אתה עושה מן הסתם, אתה מתמלל את הטקסט [אה!]אז הם יושבים על באמת בנק מאוד מאוד גדול של נתונים, גם של וידאו של אנשים.ויש להם גם, בדומה ל-Microsoft, יש להם את ה-Office שלהם - אז יש להם את כל היכולת באמת לשבת על ה-Drive שלך ולשבת על המקבילה של ה-Office שלהם ולעשות אינטגרציה עם Mail.ו-Mail הוא בפירוש משהו שהם כבר יודעים לנתח ולעשות דרכו Predictions.למעשה, הם גם היו הראשונים שעשו Spelling מאוד מאוד טוב.ויש להם גם את Android כמובן, ואת כל הגישה לעולמות של Android . . . והדבר הנוסף שהם משחקים עליו זה כל הנושא של ה-Developer Experience - הם יצאו עם IDE שהוא מובנה ל-AI ו-Browser-based, מדהים ביופיו.שיש בו כבר OpenAI Integrated - אתה רק עושה קליק ואתה מקבל כבר Access ל-OpenAI ואתה יכול לפתח איזה סוג של “Notebook2” כזה.אתה יכול ממש לפתח שם אפליקציות-AI, שמתחברים לכל ה-Ecosystem שלהם, ולבנות Widget-ים ודפים ותמונות ומה שאתה לא רוצה - “בכלום זמן”.והם הוסיפו לזה - וזה הדבר שעכשיו כולם נכנסים כמובן שזה Agentic ו-Agent-ים, אז אתה יכול או דרך Chrome Extension או להתקין Agent . . . .[ברזיק פחות זורם על זה]בעצם, הוא מלווה אותך בכל התהליכים האלה ועוזר לך לייצר חוויה שהיא Guided לתוך כל העולמות של AI.זה די מפחיד, אפילו, הייתי אומר . . . אבל כשאתה מסתכל על זה מהזווית הזאת, אז יותר קל לראות שהפוזיציה  שלהם הולכת להיות הרבה הרבה יותר חזקה ממה שאנשים חשבו.אני נוסיף לזה - ושכחתי כמובן את הדבר הכי חשוב - Search.זה יכול באמת להביא Data שהוא Real-time-י ולא Data שהוא נכון ל-2022 או נכון ל-2023.בדרך כלל, ה-Foundation Models בנויים על איזה Batch כזה ולא משהו Real-time-י  . . . (רן) מעניין דרך אגב, נתי, שהזכרת את Android, אבל אתה לא מזכיר את Apple ברשימה שלך, של ה-Contenders . . . (נתי) או, זה מצוין . . . . אני - יש לי, קניתי Apple 16 (iPhone), עם Apple Intelligence, שנחשב, למי שיצא לו לחוות את זה, לחווייה . . . הפאדיחה של . . . אני חושב אחת הגדולות שהיו בתחום ה-AI, בזמן האחרון, מבחינת הכרזות.אני מנסה להגיד לו, ל-Siri, “תתקשר לאשתי” או לכאלה דברים . . . (רן) . . .  והיא מנחשת מי אשתך? . . . (נתי) היא מנחשת . . . אפילו את הדבר הפשוט הזה.אז אמנם ה-Performance הוא כבר יותר טוב וה-Latency יותר מהיר, אבל עדיין - כמות הדברים שאתה מסוגל לבקש ממנה, לעומת מה שקורה עכשיו ב-Gemini ב-Android, זה עולמות לגמרי שונים.ב-Android אתה יכול לבקש - ראיתי ממש Demo של זה - לייצר פגישה, להוסיף לה תוכן, לשלוח מסמך, לכתוב הודעת WhatsApp . . . .וכמות הפעמים שהיא “מבינה” - לא יודע אם זה “מבין” או “מבינה” - אבל הוא עושה את הדברים והוא מדייק, ויש הרבה פחות אליוסינציה (Hallucinations).(רן) זוכר את הימים שהיינו מתקינים Linux על מחשבי Mac, כי היינו מתבאסים מהחומרה של Linux, אז היינומתקינים את זה?  אז בקורב נתקין Android על iPhone-ים, כי נתבאס מהתוכנה . . . .(נתי) אני מעריך שדווקא, לפחות מאיך שאני ראיתי, אני חושב שבחומרה הם כן עשו Catch-up - אבל בתוכנה עוד לא.וזה כנראה יגיע ב-Delay, אז אני מעריך שהגרסה הבאה של מערכת ההפעלה בטח תעשה הרבה תיקונים לדברים האלה.הם פשוט כנראה לא הספיקו, הם נכנסו למשחק יחסית מאוחר.19:23 ואז בא Elon(רן) כן אז מי עוד, בינתיים?(נתי) בינתיים עד עכשיו, דיברנו על Amazon, דיברנו עכשיו על Google, דיברנו על OpenAI לפני כן - אני אחזור אליהם אולי עוד מעט שוב פעם . . . עכשיו נדבר על Elon Musk. בעצם, הוא השחקן החדש.אחד הדברים שאגב הם הכריזו ב-CES 2025 זה שהם הצליחו לבנות Datacenter, אני חושב ב-No-time כמעט, לא זוכר את המספרים, אבל בארבעה חודשים עם Google הם בנו Datacenter ענק, שכולו מבוסס GPUs ו-AI.עשו שיתוף פעולה עם הרבה מאוד Vendor-ים, בשביל באמת להתחרות בכל החבר’ה האלה, כשבעצם . . . (רן) מי בנה את זה? X בנו?(נתי) X בנו, כן. Musk עצמו . . . כאילו, לא “הוא בעצמו”, אבל אנשים שלו . . . (אורי) הוא כנראה ישן שם . . . .(נתי) כן . . . אז עכשיו, בואו נדבר שנייה על ה-Asset-ים שיש לו:אז יש לו כמובן את X, שזה Twitter לשעבר.(רן) . . . יש לו את נשיא ארה״ב . . . (נתי) . . .  יש לו את נשיא ארה״ב, וראיתם - לא יודע אם יצא לכם לעקוב על פרשת האונס בלונדון, באנגליה, כל הפרשה שהייתה שם עכשיו עם זה. אז זאת הייתה איזושהי פרשה, שהייתה ידועה כבר הרבה מאוד זמן, שהסתירו אונס של הרבה בחורות לבנות על ידי מאפיה פקיסטנית . . . (רן) אה, בגרמניה זה היה, לא?(נתי) באנגליה, לא. באנגליה. מאפיה פקיסטנית, והסתירו את זה הרבה מאוד זמן, כי פחדו שאם יפתחו את זה, אז זה בעצם יעורר שדים של של גזענות וכאלה דברים.ראש הממשלה היום היה מבין אלה שהיו שותפים לסוג של ההשתקה, אבל כל הניסיונות לפרסם את זה בעצם נתקלו בחומות, כי כל מי שבעצם היה אמור לטפל בזה פחד לגעת בדבר הזה.אז די השתיקו את זה, קראו להן White Trash וכל מיני דברים כאלה.ופרסום אחד שלו [Musk] ב-Twitter, שחשף את הדבר הזה, יכול להחליף ממשלה עכשיו באנגליה.לא יודע אם אתם מכירים, אבל היה עכשיו את אישור התקציב של ארצות הברית ל-2025, אז תמיד כשמתחלפת ממשלה, אז יש איזה תקציב מטורף שבו הוא רק הולך וגדל.כי הרפובליקנים אומרים “אם אתה תכניס את זה, אני תן לי גם את זה” - ואז לאט לאט זה ניהיה איזה תקציב ענק כזה.ואז מה שהם עשו זה פשוט חשפו את כל הסעיפים של התקציב ואת הכמות שלו - ופרסמו את זה ב-Twitter, ונוצר גל של ביקורת, ופעם ראשונה בהיסטוריה, אני חושב, של ארצות הברית, זה נעצר.פשוט התקציב הזה נעצר - ועכשיו יש בחינה מחדש שלו, ויאשרו אותו רק בממשלה הבאה, מן הסתם.אז הוא יושב על כוח מאוד מאוד גדול - גם פוליטית, גם מבחינת . . . .אבל חזרה ל-AI - באמת אחד הדברים שחשוב זה מידע מאוד Real-Time-י, יכולת לזהות באמת ברמה של סנסורים (Sensors) את המגמות בעולם, מגמות בשוק, מגמות פוליטיות . . . .להשפיע על מדינות, להשפיע על ממשלות, לעלות ולהוריד אנשים אם צריך . . . זה חתיכת דבר.והוא כמובן חסם גישה לדבר הזה מכל ה-AI-ים האחרים, אז יש לו את הגישה הכמעט-בלעדית לדבר הזה.(רן) אבל הוא לא ה-Walled-Garden היחיד בעולם - יש אחד יותר גדול: Meta.(נתי) נכון. אז Meta משחקת משחק שתיכף נדבר עליו, כשנגיע לגל ה-Open Source.אבל רק לסכם את Elon Musk - דבר הנוסף שיש לו זה Tesla.ו-Tesla גם יושבים היום על כל הנושא של הסנסורים, מן הסתם, של המכוניות האוטונומיות.אגב, התרגיל שהוא עשה שם - אנשים לא מכירים את זה כל כך, אבל כש . . . אחד הדברים שהם בנו עם FSA [FSD?], ה-Full Autonomous Driving Cars, זה שהם בעצם . . .מה שהם עשו זה איזשהו מהלך די דרמטי, שבעצם הם הפכו את המכוניות לאיזשהו מודל Subscription.כי בעצם יש לך תוכנה, שאתה צריך לקנות בכסף - שבעצם נותנת לך את ה-Autonomous Driving.והם יכלו, על הטיקט הזה, בעצם להוריד את מחיר המכוניות ב-20% - ועכשיו תחשוב מה זה אומר:זה כשהוא יושב על Margin-ים מאוד נמוכים, אז כשאתה מוריד את המחיר ב-20%, אתה הופך את כל החברות האחרות כמעט לפושטי-רגל.והוא יכל להרשות לעצמו את זה, כי הוא פיצה על זה בתוכנה - הוא היה חברה שבעצם מוכרת Perpetual License של מכונית.הכניס מרכיב Software של Subscription - וזה אפשר לעשות מהלך שהוא כמעט שחמט מול הרבה מאוד חברות אחרות, בזה שהוא הוריד את המחיר לרמה שכל המתחרים לא יכולים להוריד את המחיר, למרות שהוא ידע שהוא לאט לאט מאבד את היתרון התחרותי שלו במכוניות חשמליות.וככה לקנות לעצמו זמן, ככה שכשיהיו לו באמת Autonomous Cars, הוא יוכל לבוא עם פתרונות עוד פעם מתקדמים מעבר לאחרים, ולעשות עוד איזה Disrupt . . . (אורי) אבל זה ממש . . . זה כאילו לקנות לא הרבה זמן, כי תוכנה - אנחנו יודעים - זה . . . הסינים מעתיקים מאוד מאוד.(נתי) הוא עושה כמה מהלכים באיזור המכוניות האלקטרוניות, שאני חושב שכן ישימו חלק מהדברים האלה די מאחור.חלק מהדברים שהוא עושה זה באמת את השירות מכוניות - שירות המכוניות האוטונומיות: מוניות ודברים מהסוג הזה, שבאמת הוא מתלבש על התשתית הזאת.אז כן תהיה תחרות - אבל אני חושב שזה מראה על היכולת של חברות כאלה באמת לחבר נכסים ביחד, כדי לייצר באמת Disruptive . . . .(רן) . . . לא, אבל אורי, אתה יודע - הוא מחלק את הפלטפורמה בחינם . . . . אוקיי, זה לא חינם, אבל באיזושהי הנחה משמעותית. אתה יודע, זה כמו לחלק Android בחינם, ואחר כך, על הפלטפורמה הזאת, אתה יכול לעשות מוניטיזציה (Monetization).(אורי) כן, אבל מה שיעשו סינים, במיוחד עם הכניסה הגדולה שלהם לשוק המכוניות, זה שהם פשוט ייתנו את התוכנה בחינם . . . . אז ישברו לו את השוק.(נתי) אז ההגנה, כרגע, שיש להם זה את המיסים - למעשה המכס . . .(רן) . . . והטראמפ . . .(נתי) כן, בדיוק. הוא מאוד אוהב את ההגנה הזאת מול הסינים, כדי לייצר באמת איזשהו סחר, אבל באמת . . .(אורי) עד שזה מגיע ל-TikTok . . . (נתי) עד שזה מגיע ל-TikTok. . . ו-BYD אגב, באמת . . .אפרופו CES - הם הראו משהו מאוד מדהים במכוניות . . . קודם כל, יש להם מכוניות מטורפות, אבל הם הראו מכונית, שהיא יכולה לקפוץ 6 מטרים, מעל בורות, כאילו . . . (רן) אה, שישה מטרים לרוחק, לא לגובה . . . .(נתי) לרוחק, כן. היא בעצם . . . . אני לא יודע איך הם עושים את זה, אבל יש להם כמובן מנוע בכל גלגל, ואז הם משנים את הזווית של המיטלים, ככה שכשהוא מתקרב ורואה בור, אז הוא בעצם “מרחף” מעליו.אז אם זה בור עד 6 מטרים, זה פשוט “ירחף” מעליו, ולא תרגיש את הבור לא תנחת עליו, כאילו תחטוף את זה  . . .(רן) במהירות מספיק גבוהה, אני מניח?(נתי) כן, אני מעריך ש-6 מטרים זה בתנאי שאתה במהירות מסוימת, אני מעריך שבמהירות יותר נמוכה זה הולך . . .(אורי) וכך הם ידלגו מעל הבור ש-Elon Musk כורה להם . . . (נתי) אז בהחלט הסינים יהיו תחרות, אבל אני חושב שפה . . . טוב, זה כבר גיאו-פוליטיקה, זו כבר שיחה אחרת, על כל המלחמות בין הסינים לשאר העולם.אני חושב שלסינים יש כמה דברים שהם משחקים לרעתם - כל מיני דברים שעבדו לטובתם, יעבדו לרעתם.אבל זה באמת שיחה גיא-ופוליטית, ש. . . .(אורי) . . . זה יגמר בדם . . . לא, באמת.(נתי) אז יש פה שיחה גיא-ופוליטית מאוד מעניינת, לדבר על הדבר הזה - אבל זה לא לעכשיו, לא נושא שיחתנו עכשיו.[למי שממש רוצה - הנה קצה-חוט]אז באמת, אם אני מסתכל על הקנדידטים (Candidates) - ולא דיברתי על כל השחקנים האחרים, הייתי אומר ה-Pure Players כמו Anthropic ו-Mistral.אני חושב שאגב - הם יעברו תהליך של קומודניזציה (Commoditization) מאוד משמעותי, כי זה הופך להיות משחק של באמת המון-המון כסף, המון המון השקעה.[הנה דוגמא עדכנית]וללכת רחב, על כל הקופה, ולא Play שהוא Vertical-י, צר . . . 27:31 מה דרוש כדי להצליח וטכנולוגיה כ-Commodity(רן) זהו, בוא נדבר על מה דרוש כדי להצליח: אז הזכרת אלמנט אחד, שזה Data. הזכרת אלמנט אחר, שזה חדירת-שוק, בהקשר של Microsoft . . . (נתי) ה-Bundle Approach, כן.(רן) אז זה אומר הרבה כסף, נכון?(נתי) נכון, בדיוק. אז אני חושב ששלושת האלמנטים משחקים, מן הסתם, מאוד חזק, יש מספר שחקנים יחסית מצומצם, שיכולים לענות על הקריטריונים ושבאמת יש להם את הData.לצורך העניין, הData - אני חושב שהוא המרכיב הכי מרכזי.(אורי) אבל פה אני כאילו שואל את עצמי - מנינו Data . . .(נתי) Data, Bundle . . . (אורי) . . . אינטגרציות וכסף . . . ומה שהופך פה לגמרי ל-Commodity זה טכנולוגיה.(נתי) נכון, בדיוק - ואתה גם רואה את זה.אתה רואה שהיום אפילו ב-Open Source, אתה יכול לראות . . . . את ה-LLM עצמו אתה יכול לייצר היום גם בגדלים קטנים וגם יחסית במחיר אפסי, אז זה בהחלט מוביל . . . . אז מי שעיקר הערך שלו הוא טכנולוגיה, הוא הולך לעבור דיווליוtציה (Devaluation) מאוד משמעותית, ויהיה לו מאוד קשה להתחרות מול הדבר הזה.זה די ברור שזה יתכנס לאיזה . . .(רן) כלומר, OpenAI, Anthropic, Mistral . . . (נתי) כן. OpenAI, אני חושב שבגלל שיש להם עדיין את זכות הראשונים, ואני חושב שהם כן . . .(אורי) “זכות ראשונים” זה לא משהו ש . . . (נתי) אז אני חושב שזה יחזיק להם, לדעתי, להיות במקום רביעי ואולי לא מקום ראשון . . . (רן) . . . זה כמו Docker . . .(אורי) . . . .אבל זה הרבה פעמים ה-Innovators’ Dilemma . . . (רן) אז לפני כמה שנים - עדיין קיימת חברה, קוראים לה Docker - אבל לפני כמה שנים היא הייתה הבטחה גדולה, וכנראה שלא ידעו למנף את זה. אז נכון, הם היו הראשונים בשוק, אבל בסוף אחרים לקחו את התהילה.אותו דבר גם OpenAI - אם ידעו למנף את זה, אז יופי . . . .(נתי) כן, אז אני חושב שאני לא הייתי מספיד אותם לגמרי, אבל אני חושב שאת ההובלה אני לא הייתי נותן להם.לא יודע אם זה יקרה ב-2025, אבל אם זה לא ב-2025 אז ב-2026, אני חושב שאנחנו נראה את שאר השחקנים בהובלה, בגלל כל הדברים שמניתי.(רן) אתה מדבר פה על AI בצורה מאוד מאוד גנרית - אבל יש המון נישות ו-Use Cases. סתם, דיברנו על מכוניות אוטונומיות - אני מניח שפה, נגיד, ל-Tesla יש הובלה. אוקיי - נניח. בעולם של אולי, לא יודע - פרודוקטיבית בעבודה - אז יכול להיות של-Microsoft תיהיה הובלה. זאת אומרת,  יש פה שוק די גדול . . .(נתי) כן, אז אני אומר - יש, להבנתי, יש AGI ויש באמת את ה-”Vertical AI” נקרא לו.ואני חושב - פתחנו בזה שיש פה שתי מגמות כמעט הפוכות, אבל הן קשורות אחת לשנייהאז מגמה אחת של AGI היא בעצם הולכת לכיוונים של באמת משהו שיכסה כמעט כל מקרה אפשרי.וההכרזה האחרונה אגב, של OpenAI, שהלכו לזה ש-GPT 403 - דלגו על 02 אגב, אתם יודעים למה?(רן) אתם מדבר על O . . זה o2 . . . (נתי) o2 , כן, סליחה.(רן) אז o3 . . . אז אני חשבתי על Ozon . . .(נתי) לא - O2 זו חברת טלפוניה, מי שמכיר, אז הם לא רצו להיכנס לאיזשהם Infringements של . . . (רן) וה-Ozon לא הולך לתבוע להם . . . . אם נשאר ממנו משהו . . . (נתי) לא, לא.(נתי) אז הם הצליחו להגיע למצב שהם עוברים באמת בנצ'מרקים (Benchmarks) מאוד משמעותיים בפיזיקה ומתמטיקה, ודברים מהסוג הזה.וזו הייתה קפיצה גדולה.והם באמת,  מתוך ההבנה של הניתוח הזה, האיצו מאוד הרבה מאוד אינובציות (Innovations) בהרבה מאוד תחומים, כמו הנושאים של Agent-ים, כמו הנושא של האפליקציות  . . . .אז באמת - לא הייתי מספיד אותם, אבל לא הייתי גם נותן להם את ההובלה. או את המשך ההובלה.אז זה לגבי OpenAI.31:11 מעבר ל-AGI ו-Open Source(נתי) עכשיו, לנקודה שהעלית [רן] - מעבר ל-AGI, שזה בעצם נותן לכאורה איזשהו פתרון גנרי - GPT, שכל שאלה שתשאל אותו, הוא ידע לתת לך תשובה.מאחורי הכל, אגב זה הרבה Agent-ים, שפשוט יודעים להפנות אליהם את הבקשה הרלוונטית.יש באמת את החלק שהוא ההתמחות. זאת אומרת, מודלים קטנים יותר, שהם מאוד טובים בבעיה מסוימת ותחום מסוים.אגב, מי שמתעסק ב-AI, יודע שבעיה האלוסינציה (Hallucinations) - או הדיוק, לצורך העניין - נפתרת בדרך כלל, או מצטמצמת, לא הייתי אומר נפתרת, ברגע שאתה מצמצם את ה-Scope של סוג השאלות שאתה בוחר וסוג הData.כי אז אתה יכול לתת Prompt-ים יותר מדויקים, ואתה יכול לכוון ולעשות גם כמובן Fine-tuning לדברים האלה.אז בסופו של דבר, גם כשאנחנו מדברים על AGI - הוא מורכב מהרבה מאוד Vertical Agents כאלה, שכל אחד - יש לו את ההתמחות הרלוונטית שלו.עיקר המגמה של ההתמחות, אני חושב שהיא הולכת באמת לכיוונים שבהם Meta היא השחקן מוביל, Facebook.והם הלכו לכיוון של Open Source - ובאמת ב-Open Source אנחנו מתחילים לראות כמה מודלים.מן הסתם Llama 3 עכשיו, ו-Llama 3.1ויש עוד כמה מודלים שנותנים פייט לא רע בכלל ל-GPT, בצד ה-LLM - זאת אומרת, כשמסתכלים על LLM to LLM, אתה יכול להגיע לתוצאות לא רעות בכלל.וככל שאתה עושה לזה ורטיקליזציה (Vertical), ובאמת אם אני בונה Autonomous Cars, אני לא צריך עכשיו שזה יענה לי בסינית או בגרמנית, אני צריך שזה יעשה Autonomous Cars.אז לכן, כשאני מצמצם את מרחב הבעיה, אני יכול באמת לייצר מודלים אפילו טובים יותר ממודלים גנריים, שמנסים לפתור את כל שאלות העולם.אז באמת, ה-Open Source היא מגמה, היא הייתי אומר עם Volume כמעט שווה, ובעולמות של Enterprise למשל, ובכלל בעולמות של ה-ISPs משתמשים בזה הרבה.לא רק כדי להוריד עלויות של GPT, אלא באמת כדי להצליח להכניס את זה לטלפונים, ל-Device-ים הקטנים, למצלמות . . .לכל אחד מהרכיבים האלה, אתה לא יכול להישען על GPT חיצוני בשביל לעשות את הדברים האלה, אתה רוצה לעשות את זה לוקאלית (Local), מקומית.ויש תחום מאוד גדול שמתפתח סביב הדבר הזה.ובאמת, CES היה איזושהי דוגמה מסויימת לראות כמה מהר זה קרה, הדבר הזה.זאת אומרת, היום כל מצלמת אבטחה, כל מכונית, טלפון מן הסתם, בין אם זה Android או . . . .באים עם מודלים קטנים, שהם כבר embedded בתוך ה-Device-ים עצמם.ו-Dell ו-nVIDIA הכריזו Developer Desktop, שבעצם מאפשר לך להריץ סוג של GPU, אם במקרה של Dell זה NPU, שזה Natural Processing Unit, שזה כאילו סוג של מתחרה של GPU . . . .אבל הרעיון הוא בסוף להתחרות על המגרש הזה של עלות, Footprint, אנרגיה . . . . ולהביא את זה למקום  שבו זה נכנס למסגרת של עלות, שיכולה להתאים ל-Desktop.אני חושב שזה די מהפכה, הדבר הזה - כי ככל שאתה מביא את זה קרוב למשתמש,  אז ה-Adoption של זה יהיה מן הסתם הרבה הרבה יותר גדול.וזה מכפיל בהחלט משמעותי.34:28 מחשבות על Code Assistants(רן) אני סקרן אם יש לך מחשבות גם בתחום של ה-Code Assistants . . . .(נתי) כן . . .  זה הבייבי שאני מתעסק בו ביום-יום . . .  והתשובה היא כן.מה שאנחנו רואים שם זה שבאמת ה-Open Source ומן הסתם ה-Agent-ים, זה הדרך כמעט האפקטיבית העיקרית שאנחנו משתמשים בה.אבל כמובן שאתה יכול לעבוד מול OpenAI וגם לייצר לך Code Assistant מאוד יעיל.יש עם זה לא מעט בעיות, לפחות בעולמות שאני מתעסק איתם.כמו למשל זה שאתה צריך שה-User ייתן לך את ה-Access ל-OpenAI שלו, ו-Data יוצא החוצה מתוך הארגון, שיש ארגונים שלא כל כך אוהבים את זה . . . ואתה נהיה איזשהו Broker של משהו, וזה קצת מדלל לך גם את הערך - אתה פחות יכול לעשות לזה Fine Tuning או Custom Training, כמו שאתה יכול במודלים של Open Source.אז זו יכולת קסטומיזציה (Customization) מוגבלת.ולכן אנחנו בחרנו ללכת דווקא למודלים של Llama ולמודלים של Open Source . . . (רן) מה שאני מתכוון זה שיש תחרות לא קטנה לדעתי, בתחום של Code Assistants, של חברות שמפתחות כליםכמו GitHub, Cursor, Codium ועוד כמה.(נתי) אז נכון, אז אני חושב - וזה מתחבר למה שאמרת על ה-Vertical-יזציה: היתה לי היום דווקא שיחה מעניינת עם חברת Security בהקשר הזה, שעושה משהו מאוד דומה.ואז שאלתי באמת “למה אתה לא משתמש ב-Framework-ים קיימים, שעושים את הדברים האלה?”ואז אני אמרתי לו בואו ננסה לענות על השאלה הזאת, ונבין גם למה הם לא עונים על כל השאלות.אז א' - אנחנו מפתחים קוד בצורה מאוד מסוימת, עם Pattern-ים מאוד מסוימים.זה לא מספיק כשאתה אומר לו “תייצר לי קוד” - והוא מייצר לך קוד.אנחנו יודעים שרוב הזמן זה תחזוקה של קוד, אתה צריך שזה יהיה כתוב בצורה מודולרית, בצורה שמתאימה לצורה שבה אתה אחרי זה עושה Testing ו-Framework-ים . . . יש המון המון Knowledge שהוא ארגוני, בסופו של דבר.(אורי) אבל גם את ה-Styling הזה - הוא יכול ללמוד.(נתי) כן, אבל הוא לא ילמד אותו מהאינטרנט, או לא ילמד אותו . . .אלא אם כן זה, שוב פעם - יש דברים שהם גנריים, זאת אומרת Python ו-Go וכאלה דברים, שאתה בהחלט תמצא להם הרבה מאוד דוגמאות ב-Open Source Frameworks, ותוכל ללמוד אותם.יש הרבה מאוד חלקים, שבהם למשל חברות Security, שכן מחוללים קוד, או במקרה שלנו פתרונות של  אוטומציה, שאין אותם באינטרנט.לא תמצא עכשיו, לא תוכל לסרוק אותם באינטרנט וללמוד מהם.אז א' - מראש, אין את הידע הזה בחוץ.וב' - זה ידע מאוד ארגוני, הוא מאוד תפור לסוג הבעיות אוטומציה שאני מתעסק איתן ובעיות התשתיות שאנחנו מתעסקים איתן, ו-Pattern-ים שאנחנו כותבים אותם.אז אני חייב איכשהו ללמד משהו שידע לעשות את הדברים בצורה הזאת.ולכן, זה מה שאנחנו עושים . . . (אורי) או שהקוד שלך יכול ללמד . . . (נתי) זה מה שאנחנו עושים, אבל עדיין אני אומר - עדיין זה ידע שהוא מאוד Proprietary.הוא גם לא . . . אני לא בטוח שיש לו ערך ברמה גנרית, כמעט בטוח אפילו שלא . . . ויש Policy, שאנחנו מן סתם מיישמים, כדי שהדברים באמת . . . נניח, בדרך שבה אנחנו משתמשים, אנחנו רוצים ששאר הצוותים יכתבו בצורה מאוד מסוימת.אז איך אני מעביר את ה-Knowledge הזה?אז בעבר היינו עושים  Training וכל מיני דברים כאלה, אז אמרנו “בואו נעשה את זה ב-Copilot”!.זאת אומרת, מראש, כשאתה כותב כבר את הקוד לסוג של אפליקציה מסוימת, שיהיה לך בן אדם שעובר לך על הקוד ואומר לך “לא ככה אנחנו כותבים! אתה צריך לכתוב את זה בסטנדרט כזה”.אז אתה בעצם מממש את ה-Policy הזה ב-Copilot, וככה אתה יכול בעצם לייצר איזושהי סטנדרטיזציה (Standardization) ארגונית.אז הצורך ב-Vertical-יזציה יהיה קיים תמיד, בכל ארגון.אני לא חושב שמודלים גנריים, גם עם Open Source, יכולים לפתור את כל בעיות העולם.יש הרבה מאוד תת-נישות ונישות, ול-Open Source יש מרכיב מאוד מרכזי בלאפשר את היכולות האלה ולאפשר לחברות להשתמש בדברים האלה.38:24 איפה אנחנו נמצאים?(נתי) אז רק לסכם את המפה של איפה שאנחנו נמצאים, אני חושב, ב-Ecosystem: אז יש באמת שתי מגמות עיקריות:יש לנו את ה-AGI ואת ה-Domain Model, ששם אני חושב שהחברות שיובילו זה דווקא אני חושב Google עם הסיכויים הכי גבוהים.(רן) ב-Domain Model או ב . . .(נתי) ב-Domain Model, ב-Gemini, לצורך העניין.אני חושב ש-X - אני חושב שיש להם יכולת להיות . . . בין אם שניים, אולי אפילו יכולים להפתיע תוך שנה-שנתיים ולהיות ראשונים, אבל יש להם . . . הם מתקדמים מאוד מהר, ודווקא זה שהם שחקן טיפה מאוחר יכול להיות פתאום יתרון עבורם.יש להם המון ידע ב-AI, מן הסתם, בתוך הארגון עצמו - אז הם אני חושב יהיו ההפתעה של המקרה הזה.ו-OpenAI, כמו שאמרתי, יהיו לא ראשונים, אולי רביעיים, בכל מקרה.וכמובן Amazon ו-Microsoft - לא בהכרח יהיו מספר אחד, אבל הם יהיו במקום טוב ברשימה הזאת.זה בגדול ה-Predication, בהקשר הזה.ו-Open Source, כמו שאמרנו, הוא לא ממש מתחרה במודלים האלה.הוא מתחרה בהם באופן יחסית עקיף, כי עדיין רוב השימוש של המשתמשים יהיה מול מול ה-GPTs ומול Microsoft ומול הזה . . . רוב ה-Consumers יעבדו בשיטה הזאת, הם לא יתחילו להתקין לעצמם מודלים ויעבדו Open Source.אז Open Source באמת נותן מענה לנישות יותר Specialized, יותר Custom, יותר יחידות-קצה שצריכים לבנות, Developers שרוצים לבנות בעצמם Pattern-ים ספציפיים אליהם.אני חושב שזה מכסה נישה כזאת, שהיא גם מאוד גדולה בעצמה - אבל היא מאוד שונה באופי שלה ובסוג השימוש שבה.זאת אומרת, זה לא ממש Head to head competition, זה לא אסטרטגיה של קומודיטיזציה (Commoditization), כמו שהיה בדרך כלל בOpen Source, שיש איזה שחקן גדול שכותב Enterprise Software והוא לוקח עליו הרבה מאוד כסף.ואז אני אבוא עם Open Source, כמו מה ש-Red Hat עשו ל-Windows - אני אבוא עם Open Source ואעשה קומודיטיזציה על הדבר הזה, זה לא המקרה הזה.זה לא המקרה של Open Source, שמאפשר לעשות באמת Use Case-ים מעט שונים.הוא מתחרה בשוליים, אני חושב, ביכולות של המודלים הגדולים - אבל לא ממש,  לא הייתי קורא לזה תחרות Head to Head.(רן) לא, אבל הוא כן מוציא את העוקץ מחברות שהמוקד שלהם זה טכנולוגיה . . . (נתי) כן, הוא בהחלט . . . כן, אוקיי - הערה נכונה. הקומודיטיזציה (Commoditization) תקרה מול החברות שבאמת על הציר של הטכנולוגיה.40:53 סיום(רן) אוקיי, אז תודה רבה, קודם כל . . .(אורי) רגע, נתי - עכשיו, כשתראה קפה שחור, תהפוך את הכוס ותקרא לנו בקפה . . . (נתי) אני קורא בקפה ש-2025 תהיה שנה טובה.(רן) קודם כל שתהיה שנה טובה. דבר שני, כמו שאמרנו בהתחלה - אתם לא צריכים להאזין הפרק הזה שוב בעוד שנה,כי צדקנו! אוקיי, יש לנו את נתי, אנחנו יודעים שאנחנו צודקים בעניין הזה.אבל באמת - אני אקח את התקווה שלך לשנה מצוינת, בכל הגזרות - גם בתחום של AI, גם בתחום המדיני, ביטחוני וכל השאר.🎗️וזהו - שיהיה לנו טוב. שתיהיה לנו שנה טובה.תודה רבה.[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 488 של רברס עם פלטפורמה, שהוקלט ב-7 בינואר 2025 - פרק ראשון לשנת 2025, בתקווה שתיהיה שנת בשוורת טובות. אורי ורן מארחים באולפן בכרכור את גיא גרינאפל מחברת Pillar Security כדי לדבר על LLM ו-Security. 🎗️00:54 גיא ו-Pillar(רן) לפני זה -  קצת עליך וקצת על Pillar?(גיא) אז קודם כל -  כיף להיות פה. אז אני גיא גרינאפל, בן 34 מתל אביב.אני בגדול “משוטט לי בתעשייה” בערך 12 שנה, אחרי שהשתחרתי מ-8200.אני בעולם התוכנה בערך 8-9 שנים - הייתי ב-LivePerson, אחרי זה הייתי ב-AppsFlyer.כמעט שבע שנים, תפקידי פיתוח וניהול-פיתוח שונים.במהותי ובעברי אני מהנדס Backend, מתעסק המון ב-High Scale, High Throughput Low Latency Systems.ובשנה האחרונה פחות או יותר אני מוביל את הפיתוח בסטארטאפ קטן ונהדר בשם Pillar Security.ו-Pillar זו בעצם חברת Early Stage, מתעסקת בעולמות ה-AI security, LLM security,קמה לפני כשנה וחצי, גייסנו באזור ה-2 מיליון דולר Pre-Seed מקרנות מעולות.ובעצם מה שאנחנו עושים זה אנחנו מאפשרים לחברות לאמץ, להטמיע פתרונות AI, בצורה שהיא safe, secure, private וכו’.בעצם, מה שאנחנו מאפשרים לעשות זה - בפלטפורמה אחת - לגשת, החל משלב ה-Discovery, למצוא את כל הפרויקטים שמשתמשים ב-AI, במודלים, ב-LLM, בארגון.על הדבר הזה, לעשות איזושהי אבאלואציה (Evaluation) על השימוש ב-LLM - איך משתמשים, System Prompts,  Meta-Prompts - כל דבר שיכול כבר לייצר Risk כבר בשלב הזה.ואיך זה מתחבר לתוך האפליקציה.יש לנו פתרונות של בעצם Runtime Detection & Response - כלומר, סוג של אפשר להגיד Guardrails ב-Runtime, שמגינים על האפליקציה.נדבר על זה גם מן הסתם בהמשך, על הצורך בדבר הזה.ומתעסקים גם ב-Automated Red Teaming - בעצם, לקחת את האפליקציה שהמפתחים, שהלקוחות שלנו  בונים, ולעשות לאיזשהו תהליך של אבאלואציה (Evaluation).להבין איפה היא חשופה, למה היא Susceptible, איזה סוג של מתקפות.והדבר הזה בסוף מתחבר לאיזה-שהם Guardrails, שגם יודעים ללמוד את האפליקציה וכו', ולהתאים את עצמם.אז זה כזה איזשהו פתרון מקיף שאנחנו מתעסקים בו.(אורי) ספציפית בשימושים במודלים של AI נכון? כאילו . . . (גיא) אתה מתכוון ספציפית ב-LLM?(אורי) כן . . . זאת אומרת, אתה אומר “אנחנו מריצים Red-Team וכו' לאפליקציה”, אבל כאילו . . . .(רן) זה לא “Security גנרי“, זה פוקוס . . . (גיא) אתה צודק, אני אחדד - Red Teaming, נכון . . .  תכל’ס, המאזינים שלנו הם מפתחים, הם אנשי Data Science, זה פחות אנשי Security.אני גם, אגב,  לא מגיע מעולם ה-Security, ואני אגיד ש-Red Teaming זה מונח מאוד מוכר בעולם ה-Security.הוא מדבר על ניסיון בעצם לדמות “צבא אוייב” או לדמות תוקף . . . (אורי) מה שקוראים “White Hat” . . . (גיא) בדיוק, להגיד “אני רוצה לפרוץ לאפליקציה בכל דרך אפשרית”.והרעיון של Red Teaming הרבה פעמים הגיע מתוך Professional Services.כלומר, אנשים שזה העיסוק שלהם, זה התחום שלהם - ובסוף זה Services.אנחנו לוקחים זה למקום של Automated Red Teaming. כלומר, לייצר ממש מוצר SaaS-י, לצורך העניין,  שיודע לבצע ניסיונות תקיפה ושבירה.נדבר גם אחרי זה בעצם על סוגי המתקפות השונים.אבל מול אפליקציות מבוססות LLM - שם אנחנו כרגע מתמקדים.(רן) כן, זאת אומרת לא Port-Scanning או דברים בסגנון - ספציפית ל-LLM-ים.(גיא) נכון.04:38 מי מפחד מ-LLM ולמה שסבתא תרצה לעשות Prompt Injection(רן) אוקיי, אז קם אדם בבוקר, כמאמר המשורר, והוא רוצה לעשות אפליקציות LLM. ממה הוא צריך לפחד?בואו לנסה ככה להבין, פחות או יותר, מה עם וקטורי-התקיפה או איזה סיכונים הוא צריך להכיר, לפני שהוא מתחיל  . . .(אורי) LLM זה לא להשתמש במודל, נכון? זה ה . . . .(גיא) האמת שלא הכרתי . . . . אנחנו ניקח את זה אלינו - יש לנו קיר-ציטוטים כאלה משעשעים, אז נכניס . . .(אורי) אני רק מבקש רפרנס . . . .(גיא) אבל גם יש שם “אסור בדיחות אבא אחרי שש בערב” , אז צריך לראות שנייה איך זה מתכתב [בר-זיק?].(אורי) הבנתי, אני אתבייש לי פה בצד . . . .(גיא) אז בסדר, בואו נתחיל באמת לדבר קצת על עולם הבעיה, וקצת על מה הסיכונים.אני חושב שהכי נכון להתחיל מהמונח, הטרמינולוגיה שנזרקת לאוויר מדי יום ביומו - “Prompt Injection”, נכון?(אורי) מדי יום ביומו - בדיוק היום שמעתי על זה . . . (גיא) קראת את רן בר-זיק?(אורי) לא . . . (גיא) סבבה. נדבר על רן בר-זיק, כי הוא גם אוהב לדבר על Prompt Injection-ים, עשה איזה טריק נחמד . . . טוב, נספר על זה אחרי זה.אבל בכל מקרה, לענייננו - המונח שהכי הרבה מדברים עליו זה בעצם Prompt Injection.זה מונח שהוא לקוח מעולמות ה - מה שהיה בעבר - SQL Injection: הקונספט של לנסות  . . . (רן) כולנו מכירים את Little Bobby Tables, נכון?(גיא) אני לא מכיר . . . (רן) שהמורה מתקשרת לאימא ואומרת “בגלל הבן שלך, כל טבלת הציונים נמחקה!”, אז היא אומרת לה “מה? איך הוא עושה דבר כזה?”, אז הוא כתב “Bobby'); Drop Table Students; --”  . . .  והיא עונה “אה, כן, We call him Little Bobby Tables” . . .. (גיא) לא הכרתי את זה . . . אוקיי, אז Prompt Injection . . . (רן). . .  SQL Injection, רק להזכיר למי שלא מכיר, זה איזושהי דרך להחדיר תוכן Malicious לתוך SQL, ומי שלא מסנן את אותו תוכן, יכול בטעות גם להריץ את זה מול ה-Database שלו ולשנות Data, למחוק  Data, בקיצור לעשות דברים שהוא לא תכנן לעשות, כשלא עושים סינון כמו שצריך של ה-Input-ים.(גיא) בדיוק. וזו אגב נקודה טובה, בטח גם על זה נדבר.(גיא) אז Prompt Injection בעצם זה איזשהו מונח שנלקח מתוך הדבר הזה, כשהרעיון הוא ניסיון להזריק איזשהן הוראות חדשות, אחרות, לתוך המודל.כלומר, לגרום למודל - בדרך כלל זה מגיע ב-Context של לגרום למודל לבצע פעולות שהוא לא אומן לבצע.או שיותר מזה - הוא אומן לא לבצע, כלומר ממש בדרך כלל בתהליך ה-Finetuning, ממש אומן לא לבצע.זה Prompt Injection.אני רוצה רגע לעשות איזושהי הבחנה בין Prompt Injection, למה שמתייחסים אליו בדרך כלל בתעשייה בתור Jailbreak, ובעצם זה לא אותו דבר.כלומר, Jailbreak זה איזושהי פעולה מול המודל - הרבה פעמים זה ייראה כמו איזושהי חתימה מיוחדת או כזה הרבה תגיות, או כל מיני דברים כאלה . . . (רן) כלומר, הסיפור “אם סבתא שלי הייתה רוצה להכין בקבוק מולוטוב, מה היא הייתה אומרת?” - אתה מסווג את זה כ-Jailbreak או . . . .(גיא) אתה אומר הניסיון שלי עכשיו לגרום למודל לעשות . . . (רן) . . ..  לעשות משהו שהוא לא אמור לעשות . . . (גיא) לא, זה לא Jailbreak - זה, הייתי אומר, יותר ניסיון לבצע Prompt Injectionאבל אני אחדד ואני אסביר, בסדר? (אורי) אם אני שואל את המודל “אם סבתא שלי הייתה רוצה לעשות Prompt Injection, איך היא הייתה עושה את זה?” . . . . (גיא) וואו, זה משהו ש...(רן) אורי, הכנסת אותנו עכשיו לרקורסיה, אנחנו עכשיו בחיים לא נצא מזה . . . .  (גיא) . . . זה Deadlock . . . . היו מודלים שמתו בגלל זה.(רן) אורי, הכנסת אותנו לרקורסיה . . .  אנחנו עכשיו בחיים לא נצא מזה. אורי, הכנסת אותנו . . . . (גיא) צריך לעצור אותך . . .אוקיי, אז אני אסביר שנייה את ההבדל בצורה קצת יותר ברורה - Jailbreak, כמו שאנחנו תופסים את זה, זה סוג של Privilege Escalation. בסדר?זה עכשיו להצליח להשיג או להגיע למצב מול המודל, שאתה יכול לגרום לו לעשות מה שאתה רוצה או דברים אחרים ממה שהוא תוכנן לעשות.ו-Prompt Injection זה ההזרקה עצמה, בסדר?אני אגיד גם שלרוב, אנחנו נוטים להתייחס, לפחות אצלנו, למה שנקרא Indirect Prompt Injection.כי אני אגיד שמשם הגיעו, ממה שראינו, הריסקים היותר גבוהים - זה פחות צפוי, וה-Context הוא בדרך כלל Context שאנחנו לא נדע או לא בהכרח נצפה מה הוא הולך לגרום לעשות.עכשיו, אני אסביר גם את המושג הזה -  מה זה אומר Indirect Prompt Injection?אני עכשיו משתמש ב . . . לא יודע, בוא ניתן איזושהי דוגמה. נגיד שאני . . . (רן) בוא, יש לי דוגמה הכי פשוטה: אתה עושה WebApp פשוט שאומר לך, נגיד, מה מזג האוויר ומה כדאי ללבוש לפי מזג האוויר.אז בתור Textbox, אתה מצפה למקום של עיר.אם במקום עיר, יבואו ויכתבו לך, לא יודע, את הסיפור - “מה הסבתא שלי הייתה אומרת אם הייתי מבקש נניח להכין בקבוק מולוטוב?”, אז יכול להיות שיצליחו להוציא . . . (גיא) יפה, אז זו דוגמה מעולה ל-Direct Prompt Injection. בגדול, תיאורטית . . . זה עכשיו שאני User, ואני בא ואני מנסה בצורה אקטיבית “לעבוד” בעצם על המודל - וזה בהנחה שה-Input הזה הולך As-is לתוך המודל.ו- Indirect Prompt Injection, בדוגמה שאתה נתת, זה שאני עכשיו כותב לצורך העניין “לונדון”, בסדר?ואז האפליקציה, מאחורי הקלעים, ה-LLM, שנניח לשם הדוגמה שהוא Agent . . . בהערת סוגריים - Agent: אנחנו מדברים בעצם על LLM-ים או נקרא לזה “מקבץ של LLM-ים”, בגדול, שיש להם איזשהו Orchestrator ויש להם כלים.והכלים האלה הם כלים שונים שהם יכולים להשתמש בהם כדי לבצע את הפעולה.הכלי יכול להיות איזושהי גישה ל-API מסוים, זה יכול להיות לצאת לחיפוש באינטרנט, וזה יכול להיות לגשת ל-Database של החברה כדי להוציא איזשהו Data, אוקיי?אז לצורך העניין, Indirect prompt injection בדוגמה הזאת, זה יהיה, אני כותב נניח “לונדון”, ואז עכשיו האפליקציה או המודל ניגש לאיזה אתר או ל-API, או לאיזשהו Context חיצוני.נגיד לשם הדוגמה - אתה שאלת אותי מה היה המזג אוויר בלונדון פעם, או מי היה ראש ממשלה של בריטניה לפני, לא יודע, מאה שנה?ניגשתי לויקיפדיה - וכשהמודל עובר על העמוד ויקיפדיה, לצורך הדוגמה, יכול להיות שם למטה בתחתית התוכן, איזשהו Context - שהוא בפני עצמו יהיה Prompt Injection.זה Indirect prompt injection.אני אגיד שלמודלים האלה מאוד מאוד קשה לעשות את ההבחנה בין מהו התוכן, שעכשיו הם קוראים, שהם קיבלו כאיזשהו Input - לבין הוראות חדשות שהם מקבלים ושהם צריכים לבצע.וזה בעצם הבסיס, כאילו, לכל ה-Risk-ים האלה.(רן) זאת אומרת, בזמן שב-SQL, אולי יש לך את יכולת לבוא ולהגדיר “הנה, זאת שאילתה, ויש לה פרמטרים, והפרמטר צריך להיות או Integer או String” . . . אבל זאת אומרת, ברור מה זה, אוקיי? אתה לא יכול להכניס שם -- Drop Tables בתור פרמטר . . . . ב-LLM, זה הכל טקסט, ואין הבדל בין טקסט לטקסט, ואתה יכול בתוך הטקסט לעשות מה שאתה רוצה . . . .(גיא) והוא ממש טוב בלעשות אינטרפטציה (Interpret) לטקסט.כאילו, הוא “מבין” . . . המודלים האלה, הם מבינים המון המון המון סוגים של Input-ים.וזה חלק מהמשחק פה, וחלק ממה שמייצר את הריסקים.כי בסופו של דבר, אני יכול עכשיו להכניס Input למודל, שהוא, נגיד, בוא נדבר על הסיפור, על “הסבתא שרצתה להכין מולוטוב” [סיפור ילדים האהוב, עכשיו בגרסת אודיו?]אז כאילו לכאורה, נורא קל להגיד “רגע, שנייה, אתה מנסה לעבוד עליי!”אבל עכשיו בוא נעשה לזה Encoding ל-Base 64. ועכשיו, לא יודע, נוסיף על זה עוד איזה “מטבל כזה ומטבל אחר”, ונשים עוד Evasion Techniques ועוד Obfuscation ודברים.ופתאום, זה כבר פחות קל.ואנחנו רואים, וגם יוצאים אז המון מחקרים, שככל שאנחנו הולכים למקומות האלה של ה-Evasion Techniques והאובפסקציה (Obfuscation), המודלים פחות טובים בלהתגונן.ולכן אני אגיד - הטכנולוגיה הזאת, במהותה, היא פשוט . . . היא Prone לדברים האלה.זאת אומרת, יש פה נטייה, יש פה איזושהי פגיעות - שהיא מובנית בתוך הטכנולוגיה.(רן) כן, זאת אומרת - מצד אחד, הטכנולוגיה Enabler - אתה יכול לעשות דברים מדהימים, אתה יכול לייצר הרבה מאוד Value. אבל יחד עם זה גם מגיע סיכון גדול. With great power comes great responsibility, אמר ספיידרמן.(גיא) נכון. דוד של ספיידרמן. דוד בן.(רן) אז זה היה הדוד? אוקיי, אני אתקן מעכשיו את קיר הציטוטים שלי . . . .(גיא) מעולה . . . 13:06 איזה Guardrails יכולים לעזור ואיך להגיע לסלובניה(רן) כן, אוקיי - אז דיברנו על כמה דברים. דרך אגב, הזכרת עוד מושג מקודם, שנקרא Guardrails, שתכף נגיע אליו. דיברנו על Prompt Injection ישיר - זאת אומרת, נגיד, המשתמש הוא Malicious, ומנסה לעשות משהו, ויחסית אולי קל לסנן את זה. דיברת על Indirect Prompt Injection, כלומר, נגיד, התוכן או ה-Database או אתר שממנו אתה מנסה למשוך את התגבור ל-Prompt שלך, מכיל תוכן שהוא בעצמו Malicious, ואולי לא ה-Data. זאת אומרת, גם אם הנחת שהמשתמש הוא Malicious, אתה כנראה תניח שה-Database בסדר - אבל גם את זה כבר אי אפשר להניח, או שויקיפידיה בסדר, אבל גם את זה כבר אי אפשר להניח.ואז, מקודם, הזכרת את המושג של Guardrails.אז איזה Guardrails. למשל, קיימים בעולם הזה? נגיד, איזה ספציפים יכולים לעזור מול שתי התקפות כאלה?(גיא) כן. אז שנייה לפני שאנחנו מדברים על Guardrails, אני רוצה רגע לתת איזשהו Framing לריסקים (Risks).כי דיברנו על מה היכולת - כאילו, מבחינת נקרא לזה “התקיפה של המודל”, הניסיון לעקוף אותו.אבל בסוף, כשאנחנו מדברים על הריסק - אם אני פשוט מצליח לעקוף את מנגנון ההגנה של המודל, זה נחמד, אבל זה עדיין לא משהו שהוא בהכרח מעניין, זה עדיין לא בהכרח מאיים על חברות.כאילו, למה שמישהו ישלם, אם לא יודע מה - המודל שלי עכשיו או האפליקציה שלי, כתבה לי הייקו, או נתנה לי מתכון למולוטוב? זה לא בהכרח מה שאתה חושש ממנו . . . ואני חושב שמה שמעניין לדבר עליו, זה מה גוזר את הסיכון.אז אני חושב שהסיכון נגזר מכמה נקודות.קודם כל, מה נקרא לזה ה-Attack Surface - או בעצם, מה ה-Input שיכול להגיע למודל?זאת אומרת, האם ה-Input הוא trusted? האם זה מגיע מ-User שאני יודע שהוא לקוח שלי, למשל.זאת אומרת, יש לפעמים מוצרים שהם מבוססי-LLM, שהם בתוך פלטפורמות ארגוניות ודברים כאלה.אני יודע נגיד ש-AppsFlyer התחילה לעבוד הדברים כאלה ממש, קצת לפני שעזבתי, והרבה חברות עושות את זה.במקרה כזה, אתה יכול להניח שהלקוח הוא לא Malicious, אז זה נגיד לא משהו שאולי צריך לדאוג ממנו.במקרה אחר, אם אני עכשיו איזשהו Chatbot כזה, של Support של חברה, שכל אחד עכשיו, כל אדם, יכול להיכנס ולכתוב,אז אולי משם יגיע User שהוא Malicious, וזה מגדיר את המשטח-התקיפה.הנקודה הנוספת מהצד השני זה מה הנגישות שיש ל-LLM.זאת אומרת, לאיזה Resource-ים, לאיזה Asset-ים הוא נגיש? הוא נגיש ל-Database רגיש, הוא נגיש לאינטרנט, איזה Tools יש לו - דברים כאלה.וזה בגדול אני חושב השתי נקודות שיכולות להיות רלוונטיות, ויגדירו כמה יש פה באמת ריסק.(רן) כן, כשאמר “Tools”, אתה מתכוון ליכולת לקרוא לפונקציות או לקרוא ל-API-ים. נגיד, לא יודע - לעשות Log-out ל-User או למחוק שורה ב-Database.(גיא) בדיוק. אני, כשאני עכשיו . . . . בעצם, Tools זה גם, זה הולך יד ביד עם המושג של Agents.בעצם, הרעיון זה “אני איזושהי אפליקציית LLM”אני מקבל ב-Meta-Prompt שלי, אני מקבל - בעצם כשמפתח מקנפג (Configure) אותי, מגדיר אותי, את כל העבודה עם המודל - אני אומר לו “תשמע, יש לך את החמישה כלים האלה, שאתה יכול לבחור מתי להשתמש בהם”.אם עכשיו אתה מקבל איזשהו Input, איזשהו Prompt, אז אני מייצר לו איזשהו Description או הסבר, של מתי אני משתמש בכל כלי כזה.וה-LLM - הוא גם מקבל החלטה. זאת אומרת, זה חלק מאותו Agent.אז לפעמים אני ניגש ל-Database או מוחק או מוסיף רשומות.לפעמים אני יוצא לאינטרנט,ולפעמים אני...(רן) ניקח את הדוגמה של “מה כדאי ללבוש, אם אני נוסע עכשיו ללונדון?” - הוא ילך ל-weather.com, שזה כלי, ילך ל-weather.com, יעשה קריאת API - זה לא בתוך ה-LLM, זה איזשהו Agent, כמו שאמרת, שיעבוד יחד עם ה-LLM. אז ילך ל-weather.com, ייקח את מזג האוויר, יחזיר את זה וישים את זה בתוך Prompt ל-LLM, ו-LLM “ילעס את זה” וייתן לך בסוף תשובה: “כדאי ללבוש מעיל ולקחת מטריה”.(גיא) בדיוק. והעולם הולך למקום הזה - של Agentic Systems.כאילו, יש על זה הרבה מאוד מחקרים, והרבה חברות הולכות לשם.(רן) אז ללכת ל-weather.com - אוקיי, לא מזיק. אבל אם זה ללכת ל-Database ארגוני? אם זה לקרוא רשומות HR? אם זה לגשת לבנק? אז שם כבר יכול להיות נזק . . . (גיא) נכון. אז כשאנחנו מדברים . . . אני חוזר רגע בעצם ל-Guardrails, ואיך אנחנו מגנים.וספציפית כרגע, אנחנו נדבר על ה... אני גם גיליתי את זה לפני שנה -  בעולם ה-Security, אז “Run time” זה מה שאנחנו המפתחים קוראים לו “Real Time”.בסדר? הדברים הם אותו דבר, המונחים הם קצת שונים.אבל בגדול, עולם ה-Runtime Detection & Response.הרעיון ב-Guardrails זה בעצם לייצר או להציב איזושהי שכבה בין האפליקציה לבין המודל, גם ביציאה החוצה וגם בכניסה פנימה, כדי . . . זה יכול להיות לפלטר (Filter) דברים, בסדר? אם זה למשל, למנוע הדלפות של PII, PGI, כל מיני Data “רגיש”, נקרא לזה.יצא לנו לעבוד עם לקוחות, עם Design Partners בעולם ה-Finance, בעולם ה-Healthcare - שם זה מאוד מאוד משמעותי.(רן) זאת אומרת שזה על ה-Output - כן, אתם מסתכל על ה-Output, ואתה בודק האם יכול לדלוף החוצה משהו . . . (גיא) אז בגדול, אני אגיד שזה לשני הכיוונים - יש גם את הכיוון שלה להכניס את זה, מן הסתם, למודל - אבל זה יותר על ה-Output.זה יותר החשש מלהדליף עכשיו PII, PGI של User אחר של החברה, של הלקוח, ל-User אחר, שזה לא ה-Data שלו, מן הסתם.אז אנחנו מדברים על לזהות PII, PGI,.אנחנו מדברים על Secrets, בסדר? זה כל מיני - כל משהו שהוא Data רגיש כמו API keys,  . . . API keys, האמת זו הדוגמה הכי טובה שיש לי בהקשר של Secrets.אבל כל דאטה שהוא רגיש, יכול לתת גישה למערכות שונות, ל-Resource-ים רגישים וכו'.יש Guardrails שהם בכלל בתחום ה-Integrity וה-Safety - זאת אומרת, אני לא רוצה שהאפליקציה שלי תקלל.כאילו מבחינתי, אם עכשיו אני Chatbot שירות לקוחות, אני ממש לא מעוניין שלא יודע, יכתבו ללקוח שלי . . . (רן) בוא, אני אתן לך דוגמה מהעולם האמיתי, שנתקלתי בה לא מזמן - איזשהו ניסוי שעשיתי, שלוקח על Database של נגיד ויזות של מדינות - לאיזו מדינה אני צריך ויזה ואיך אפשר להיכנס. והשאלה ששאלתי נגיד זה “האם אפשר להיכנס לסלובניה, ללא ויזה?”. תשובת-הספר היא כמובן שלא. ה-LLM ענה לי “לא - אבל אתה יכול להיכנס לפולין בלי ויזה, ואז לחצות הגבול ואף אחד ישים לב, והנה אתה בפנים” . . . .(גיא) וואו, זה אמיתי?(רן) כן, כן, זה אמיתי.(גיא) צייצת את זה?(רן) לא, כי זה ניסוי פנימי שעשיתי . . . אבל כן, זה מסוג ה-Guardrails שאף אחד כנראה לא חשב עליו מראש, אוקיי? זה לא PII, זה לא Curse, זה לא Hate Speech . . . . אבל עדיין לא היית רוצה שה-Chatbot שלך ייתן תשובה ככה.(גיא) חד משמעית.עכשיו, מבחינתי זה מתחבר מאוד לנושא האינטגריטי (Integrity), שאני אולי טיפה קופץ קדימה, אבל בגדול, כשאנחנו חושבים למה שמפתחים - בכלל יעניין אותם לדבר על Security, בסדר?כאילו, בסוף היום, יש את הדברים שהם Obvious, נכון? כולנו רוצים להטמיע AIזה Adapt or Die, כמו שאמרו חכמים - ו-AI נותן לנו את ה-10x ו-100x וכו'.הבעיה שזה מכניס איתו איזה שהם Risks, ואם עכשיו אני מפתח שלא יודע, ניגשה אלי עכשיו ה-VP R&D של הארגון, ואמרה לי “קח את הפרויקט הזה, תכניס שם LLM!” או “בואו נבנה פרויקט חדש, תכניס שם LLM, בואו נהפוך אותו ונהיה בקדמת הטכנולוגיה”.אני, מה שמעניין אותי עכשיו זה לבנות מוצר - שהוא עובד, שהוא עושה את מה שמצופה ממנו לעשות, שהוא עומד ב-Scale שנדרש, שהוא נותן ושהוא עונה על הדרישות המוצריות, נכון?עכשיו, המשחק פה, ומה שאני חושב שכן צריך לעניין מפתחים בשלב ראשון, זה אירוע האינטגריטי (Integrity).כי מה זה אומר בסופו של דבר? אנחנו עובדים - דיברנו על זה קצת בשיחת הכנה - אנחנו עובדים עם  Black-Box.כאילו, LLM, כשאנחנו . . . זה נכון אגב, גם במודלים שהם לוקאליים (Local), אבל בפרט ב-LLM-ים: אם אנחנו עובדים מול OpenAI, עובדים מול Anthropic, עובדים מול Google וכו’.(אורי) זה כמו שאתה מגייס עובד - אתה מגייס Black-box, נכון? אתה לא יודע אם הוא יקלל יום אחד, או . . . (רן) דבר מניסיון, אורי - בוא נשמע . . . .(גיא) כן. בדיוק . . . זה קצת, זה מאוד “Black-boxed”.והנקודה שלי, זה שאני - בתור מפתח - אומר מה הדרך הכי טובה עבורי, להבטיח שהאפליקציה תעשה מה שהיא אמורה לעשות?הנקודה שלי זה שעם דברים כמו מתקפות - כמו Jailbreak, כמו Prompt Injection ועוד סוגים של מתקפות - אפשר לגרום למודלים, ואז בפרט גם לאפליקציה ולמוצר, לעשות דברים אחרים ממה שהמפתח התכוון וממה שהחברה רצתה שהמוצר יעשה.22:15 רגישות ל-Social Engineering(אורי) אז רגע, רגע, רגע . . . כי כבר התחלנו להקביל קצת את המודל לאדם, בסדר? אחד הדברים שבעצם . . .  אולי אחת הדרכים שבסוף בסוף הכי קלות לעשות פריצת אבטחה, זה מה שנקרא Social Engineering, נכון?(גיא) חד-משמעית.(אורי) אז הדרך להתמודד עם Social Engineering זה לבנות Awareness - ללמד את העובדים שלנו להיות חדים או להיות רגישים ל-Social Engineering.אנחנו יכולים לעשות אותו דבר למודלים?(גיא)  אוקיי, אז קודם כל - זו שאלה מעולה. א' - אני אוהב את ההקבלה לבנאדם. אני חושב שיש הרבה קווי דמיון, מן הסתם, וזה קצת מה שמפחיד בדבר הזה.אבל כמובן שרמת האינטליגנציה שם היא לא באמת קרובה לשל בני אדם.לשאלתך על Social Engineering, התשובה היא “כן - עד רמה מסוימת”.זאת אומרת, אתה מדבר על . . . במילים אחרות, מה שאתה אומר זה “האם אנחנו יכולים לגרום למודל, או לוודא או ללמד את המודל . . . “(אורי) . . . . לזהות Prompt Injection . . . (גיא) כן . . . אז אני אגיד כמה דברים: המודלים שמגיעים, ה-Foundational . . . .כי בעצם, החברות שעושות את ה-Foundational Models, שבונות את ה-Foundational Modelsכמו שציינתי - OpenAI, Anthropic וכו’ [לא רק - 483 Training of foundational models with Ofir Bibi Lightricks]בתוך תהליך הבנייה של המודל, יש גם תהליך Finetuning - בדרך כלל זה בסוף התהליך, שבו הן בעצם עושות איזשהו תהליך של “ללמד את המודל”, כמו שאתה אומר . . . (רן) “הקשחה” . . . (גיא) הקשחה, בדיוק. תודה.וזה יותר בעולמות באמת ה-Safety, וגם Integrity, כמו שקראתי.זאת אומרת, אל תייצר harmful content, בסדר? אם אני צריך לתת איזושהי כותרת.וזה כאילו “אל תסביר איך לבנות פצצה” ו”ואל תקלל” והרבה מאוד דוגמאות ל”להנה, אם אתה מקבל כזה Prompt, אז תסביר שאתה לא יכול לעזור עם הדבר הזה”.אז בגדול, יש דרכים לעשות את זה - ועדיין אני אגיד שיש דרכים גם לעקוף את זה - וזה נובע מכמה טעמים.זה גם נובע מהטעם שבסופו של דבר, קשה למודלים להבחין, כמו שאמרתי, בין מהו Prompt, כאילו שהוא פשוט Prompt, שהוא איזושהי “בקשה”, לבין מהו instruction, או מה הן “ההוראות”.אני כן אגיד ש-OpenAI גם הוציאו איזשהו מאמר, לדעתי כבר לפני כמעט שנה, שמדבר על ההיררכיות בסוגי Prompt-ים.בעצם, אנחנו נכנסים פה קצת לרזי העבודה עם LLM, אבל ב-LLM-ים יש בעצם סוגים של הודעות או Prompt-ים, שאפשר להכניס אליהם או לשלוח אליהם, אוקיי?(רן) אז סבבה, הזכרת סיבה אחת - אמרת שקודם כל, it's complicated . . . זאת אומרת, גם אם אפשר להגן מפני 80% מההתקפות, עדיין ישארו 20%. אבל גם צריך להבין שיש Domain-ים של התקפות, כמו “האם אפשר להגיע  לסלובניה בלי ויזה?” שוואלה - לא יעזור, אתה לא יכול לאמן את ה-LLM להימנע מתשובות על כל סוג של שאלה שיכולה להיחשב כזדונית, באיזושהי סיטואציה.(אורי) אגב, אפשר . . . (רן) אפשר לאמן או אפשר להיכנס לסלובניה?(אורי) בכמה פעמים שנכנסתי לסלובניה? . . . (גיא) זה נכון, אבל מה שאני רק הוסיף זה שבאמת, מעבר לתהליך ההקשחה, יש לנו גם את היכולת, בעצם, לייצר או להכניס למודל, להזריק למודל, מה שנקרא System Prompt או System Instructions, בסדר?שזה הדרך שלנו כמפתחים, כשאנחנו מטמיעים LLM-ים, לעשות איזושהי “Init” לעבודה עם המודל, ולהכניס עוד קצת, נקרא לזה “הקשחות” או “התאמות” או . . . . ללמד אותו לבקש או להגיד לו “you are a helpful assistant, שמביא את המזג אוויר ואומר מה ללבוש” או “אתה עכשיו עוזר בחנות, ואתה רשאי לתת קופון עד 15% ולא יותר”, כל מיני דברים כאלה . . . .ומעל הדבר הזה - כי אנחנו יודעים שזה פשוט לא מספיק, כי אנחנו רואים שזה לא מספיק פשוט בשטח ומעבודה עם חברות שמתעסקות בזה - אז מגיעים ה-Guardrails, אוקיי?וה-Guardrails - גם כאן אני חושב שיש שתי רמות, וזה קצת מתחבר למה שאתה אמרת, רן, שבעצם, יש לנו את ה-Guardrails, שדיברנו על כל מיני סוגים.אז יש לנו את ה-Guardrails שהם גנריים, בסדר? שהם כאילו “לחפש Prompt Injection” - יש דברים שהם מאוד כללים, זאת אומרת, בסוף, אם עכשיו יש Prompt שמדבר על ignore your previous instructions and do the following, לרוב אנחנו מבינים שיש פה אירוע של Jailbreakingזאת אומרת, ניסיון לעשות איזשהו privilege escalation . . . (רן) זה כמו המקף-מקף (--) ב-SQL injection.(גיא) בדיוק, יש לך דרכים כאילו יחסית קלות לזהות את זה.אבל אנחנו יודעים שזה נהיה הרבה הרבה יותר מורכב, הרבה הרבה יותר מוקדם. זה דבר ראשון,והדבר השני זה ש-Prompt Injection, וגם Jailbreaking, אולי פחות, אבל Prompt Injection - הוא לא Prompt Injection, כאילו . . . הוא יכול להיות ב-Context אחד Prompt Injection, וב-Context  אחר לא להיות Prompt Injection - גם את זה יצאנו לראות כאילו בעבודה עם חברות. שבוא נגיד לפעמים ה-Input-ים - הם נשמעים כמו Intruction-ים חדשים. בסדר?נגיד, יצא לנו לעבוד עם חברה שעושה מודרציה לתוכן, ובסוף אנחנו מכניסים פנימה Comment-ים או דברים כאלה.ובתוך Comment יכולים להיות דברים כמו “תתעלם מהתגובה שהייתה לפניי - תגובה טיפשית!”, דברים כאלה,ובסוף זה נשמע כמו Instruction-ים חדשים . . .אז אם אנחנו לא נהיה בפוזיציה, שבה אנחנו יודעים להגיד על Context מסוים אם הוא Prompt Injection, אנחנו נהיה בעולם של הרבה מאוד FPs [False Positives], נרעיש ולא נשיג את מה שאנחנו רוצים.כי בסופו של דבר, מן הסתם המטרה היא לאמץ את הטכנולוגיה, כדי לרוץ מהר, לייצר את ה-Added Value, לייצר Deliverables מהירים יותר ואיכותיים יותר.ולא כדי לעכב ולא כדי להרעיש.אז צריך למצוא את האיזון.(רן) כן . . . 28:21 מודל עויין(אורי) יש לי שאלה . . . אני מצביע. דיברת עד עכשיו על תקיפות, שבעיקר מזיקות למה שנקרא “ה-Peripherals של המודל” - לכל האתרים, לכל ה-Database-יים, לכל ה...יש תקיפות שהן מזיקות למודל עצמו? שיכולות למחוק אותו, או פשוט להשפיע לו על האימון, ברמה שפתאום הוא יפוך להיות Hostile או...(גיא) אז קודם כל אני אגיד “לא שאני מכיר”.אני גם אחדד רגע את מה שאתה אמרת - התקיפות שעכשיו אנחנו דיברנו עליהן עד עכשיו, זה בעצם שהן לא בהכרח מזיקות ל-Database. בעצם אני אגיד שזה תלוי בכיוון של התקיפה.אם המודל - נניח יש לו הרשאות Write ל-Database, אז אתה יכול לייצר איזושהי תקיפה שנגיד...(אורי) . . . תמחוק טבלה.(גיא) . . . כן - תמחוק טבלה, תשים Data שהוא Poisonous או לא נכון וכו'.מהצד השני, יש לי יכולת אולי להדליף מידע.זאת אומרת, זה תלוי לאיזה כיוון מעניין אותי לתקוף.מבחינת המודל עצמו, ולהזיק למודל כמו שאתה אמרת  - שוב, לא שאני מכיר.אתה יודע, איזה Prompt כזה שעושה “Self-Destruct” למודל - לא נתקלנו עדיין.אבל לא יודע . . . (רן) אני לא חושב שזה אפשרי, האמת. זאת אומרת...(גיא) אני גם לא חושב שזה אפשרי . . .(אורי) כי הוא מאומן לא בשלב ה...(גיא) כן, אתה עכשיו בגדול בשלב ה-Inference . . .(רן) המודל “Read-only”. . .  המודל שאתה משתמש בו - הוא ידע לעשות Inference, הוא לא מעדכן את המשקולות שלו. עכשיו, יכול להיות שאפשר לחשוב על Setup שבו יש “משוב” מכיוון המשתמש, ואולי כן יש איזשהו עדכון של  משקולות, אבל לפחות רוב המודלים שאני מכיר לא עושים את זה.(גיא) אני כן . . .  נגיד משהו רגע מעניין בנקודה הזאת - אני לא מכיר דרך, וזה גם לא נשמע לי אפשרי, בוא נגיד לשבש את האימון של המודל בזמן ה-Inference.אבל כן, אנחנו רואים וכן יש קונספט של מה שנקרא גם בעולם ה-Security כ-“Application Reconnaissance”.עכשיו, Reconnaissance - או בעברית “איסוף מל”ם” - בעצם יש לי יכולת לנסות לאסוף מידע.זה יכול להיות בעולם ממש של להוציא משקולות של המודל, ולנסות לדלות כל מיני דברים על האימון של המודל.זה יכול להיות דברים מאוד מאוד פשוטים וב-high-level, כמו “תביא לי את ה-System Prompt שלך”.עכשיו, אם אני, כתוקף, מסוגל להדליף את ה-System Prompt של המודל, אני למדתי דבר משמעותי על איך שהאפליקציה עובדת. אולי על...(רן) Reverse Engineering . . . (גיא) בדיוק. על איזה כלים יש למודל, למה הוא נגיש?יכול להיות שאני רואה שיש לך כלי, נגיד, יש לך ב-Tool-ים את ה-Database של כל הלקוחות.אוקיי, אני עכשיו כתוקף, יכול ללמוד מזה, נכון?עכשיו, במיוחד אם יש לי עכשיו כלי אוטומטי, שעושה Red Teaming - תחשוב שאני עכשיו מזריק אליו, נגיד, את ה-Tool-ים שנגישים לאפליקציה, למודל.עכשיו, אני יודע שכשאני מנסה לעשות מתקפות, נגיד ה-Database. אז אני לא חושב שאתה יכול להזיק למודל - אבל אתה יכול לדלות מידע על המודל, שיכול לשרת אותך, כדי לייצר תקיפות יותר משמעותיות.31:26 רגע ה-Cherokee(רן) אז דיברנו פה על... אתה יודע, הזמן עובר - דיברנו פה על כמה סוגים של התקפות, ולא כיסינו את כולם, אבל אולי גם הוגן לציין, שעדיין לא ראינו את “רגע ה-Cherokee” [ה-Cherokee moment]. ולמה אני קורא “רגע ה-Cherokee”? אולי מישהו מכם זוכר, שפעם צולם וידאו של מכונית, ג'יפ Cherokee, שנוסעת על הכביש, ולידה נוסעים אנשים עם Laptop ופשוט מורידים אותו מהכביש, ומעיפים אותו לתעלה.כלומר, השתלטו על הרכב מרחוק, ובעצם הצליחו לגרום לו לרדת מהכביש, וזה כמובן יכול... אתם יכולים לדמיין לאן עוד אפשר לקחת את זה.ובעקבות זה, קמו לו מעט חברות Security, חלקן של אנשים טובים שאנחנו מכירים בותעשיית הרכב, ובנו מנגנונים להגנה.אז רגע כזה של Cherokee, אני חושב שעדיין לא ראינו בעולם ה-LLM, אבל אולי הוא כבר קרה ואנחנו לא מכירים, או שאולי יקרה בעתיד. זאת אומרת, לי די ברור שזה יקרה מתישהו, וחברה כמו Pillar, כנראה, תיתן את המענה, או לפחות תהיה מוכנה לאותו רגע שיקרה.(גיא) לגמרי,אז אני אתייחס לזה, כי א - אני אוהב את הדוגמה הזאת, ואני מסכים.זאת אומרת, אני חושב שעוד לא ראינו את הרגע Cherokee הזה שאתה מדבר עליו.אני יכול להגיד שאנחנו הוצאנו איזשהו דוח, אצלנו ב-Pillar, על כאילו קצת, ה-State של המתקפות סביב ומול LLM-ים.מאלפי או הייתי אומר מאות-אלפי Prompt-ים שיצא לנו לנתח, של Chatbot-ים של איזשהו פרטנר שאנחנו עובדים איתו.ואני אגיד כמה דברים. קודם כל, ראינו מתקפות, וראינו גם מה עובד ומה פחות עובד.ואני חושב, שהסיבה שעדיין לא ראינו את ה-Cherokee moment, או היה את הרגע שגם הייתה פריצה גדולה שהייתה ל-Okta, שגם התניעה שם את כל השוק הזה.לא ראינו את זה, כי לדעתי עדיין אין מספיק LLM-based Applications ו-AI Applications ב-Production, ב-Scale גדול.(רן) אנחנו הולכים לשם. ה-Stake עדיין לא מספיק גדול . . . (גיא) ה-Stake עדיין לא מספיק . . . (רן) “אין מספיק ג'יפים על הכביש” . . . (גיא) בדיוק, אין מספיק Cherokee-ים על הכביש, כדי שאתה יודע - יבוא תוקף אחד ויתפוס איזה Cherokee, ויוריד אותו.אני חושב שאנחנו הולכים לשם,אנחנו רואים גם יותר ויותר חברות מדברות על 2025 כעל השנה שהם יטמיעו AI.ואני אגיד גם, באותה נשימה, אנחנו רואים יותר ויותר חברות, שכבר עכשיו - בתכנון של סוף 2024, כשמתכננים את התקציב של 2025 - כבר יש שורה בתקציב של “AI Security”.של להביא עכשיו פתרון לדבר הזה.כי מבינים, שזה חייב לבוא ביחד - במיוחד כי הטכנולוגיה הזאת היא פשוט Prone למתקפות האלה.זאת אומרת, יש לה איזושהי פגיעות סביב הדבר הזה.34:14 הרגעות, נוף הפתרונות ו-Best Practices למפתח מעל LLM(רן) אז עד עכשיו עסקנו בהפחדות, ולקראת הסוף בוא נעסוק קצת בהרגעות.אז הזכרת כמה פתרונות, שאתם ב-Pillar נותנים, אבל בוא עכשיו שים את עצמך בנעליים של מפתח - שאתה רוצה להשתמש ב-LLM.איזה פתרונות יש היום בשוק? בין אם זה Open Source, בין אם זה חברות שנותנות אולי פתרונות מסוגים אחרים, שמכסים דברים אחרים. מה פחות או יותר . . . איך נראה ה-Landscape של פתרונות האלה?(גיא) אז קודם כל אני אגיד שיש היום גם פתרונות, שהם Open Source-ים, שלחלוטין אפשר להתחיל ולנסות אותם.אני אגיד שחלקם מוגדרים כ-”Experimental”, והם כנראה יהיו מעולים לבדיקות ולמשחקים שאנחנו עושים בסביבות Dev.לקחת את זה ל-Production - זה כבר, אני אגיד, כל מפתח צריך כאילו לקחת בחשבון עם עצמו.אז אני לקחתי פה איזשהן שתיים-שלוש דוגמאות, שגם אנחנו, אגב, עובדים איתם ומתנסים איתם, משתדלים תמיד לראות מה יוצא ולעקוב אחרי ה-Framework-ים החדשים שיוצאים.אז קודם כל יש לנו גם את Llama Guard וגם את Prompt Guard - אלה שני Open Source-ים של Meta, אם אני זוכר נכון.כש-Prompt Guard הוא בעצם יותר בעולמות של למצוא Prompt Injection, Jail Breaking, כל הדבר הזה.ו-Llama Guard יותר מדבר על עולמות ה-Integrity, Safety, Harmful Content, Toxicity . . . כל העולם הזה,אז אלה כבר שני מוצרים שאפשר לקחת ולשחק איתם מאוד מאוד בקלות.בעצם לקחו איזשהו מודל של Llama, ועשו לו Finetuning ספציפית כדי לזהות את הדברים האלה.(רן) כלומר אתה מעביר את התוכן דרך איזשהו מודל, איזשהו “שומר” - ואם זה עובר אותו, אז אתה מעביר את זה הלאה, או שאולי בדרך החוצה אתה מעביר את זה דרכו.(גיא) בדיוק, ממש ככה,עוד דוגמא שיש, האמת דווקא ממקום קצת אחר - יש איזשהו פרויקט Open Source שנקרא PyRIT, שהוא של Microsoft, גם Widely Adoptedוהוא דווקא פרויקט שיותר נועד ל-Evaluation, קצת יותר מהמקום של מה שאני קראתי לו ה-Red Teaming, כאילו על LLM-ים.בעצם לנסות לראות למה המודל “תקיף”, למה הוא Susceptible.ולנסות למצוא חולשות במודלים שלנו.(רן) רק נזכיר, ל-Context - אתם מדברים על Setup שלם של Production. זאת אומרת, לא רק על האם המודל הזה Susceptible, אלא האם כל ה-Setup שלך - זאת אומרת, כל ה-WebApp, אפליקציה, או Router Service - פגיע, וזה לא רק המודל עצמו, זה גם כל מה שמסביב.(גיא) נכון. אז קודם כל זה מדויק, ואני אגיד, בדיוק בהקשר הזה - יש הרבה מאוד כלים, חלקם Open Source, אגב, חלקם לא Open Source, שיכולים לעזור כשאנחנו רוצים להתגונן, או לייצר . . . בואו נגיד, להטמיע LLM בצורה שהיא בטוחה, עם כמה שפחות ריסק לארגון, לאפליקציה, ל-Production.היתרון - ואני, כאילו, תסלחו לי פה על זה, אבל...(רן) תן את השפיל . . . .(גיא) כן, אני אתן את השפיל - היתרון בעצם, בלקחת פלטפורמה כמו Pillar, הוא שאנחנו מקבלים פה איזשהו משהו קצה-לקצה, בסדר?כאילו, אני כמפתח - הסיוט הכי גדול שלי זה שיהיה לי, לא יודע מה - לוגים ב-Kibana ו-Dashboard-ים ב-Grafana, ומטריקות ב . . .אני לא רוצה. אני רוצה פלטפורמה אחת שאני יכול לעבוד איתה.שהיא לוקחת אותי, מקצה לקצה, הכי Shift-Left שאפשר.לדעת, מרגע שאני מתחיל לפתח, שכשאני בונה ומייצר את ה-Meta Prompt-ים וכו', ועם המודלים שאני בוחר, אני מוגן.או ממה אני לא מוגן.עד השלב שבו אני מתחיל להריץ את האפליקציה - אני עובד מול איזשהו API או SDK או Proxy, שמגן עליי,שאני יכול לקנפג (Configure) אותו בעצמי, שהוא פתוח גם לארגון שלי.וגם שאני יודע לתת תמונה עכשיו מלאה, לצורך העניין לארגון ה-Security בתוך החברה.כשבסופו של דבר, אני עכשיו כמפתח, אני זוכר מהימים שלי ב-AppsFlyer - כשיש פיצ'ר חדש, אני צריך לסמן אם הוא דורש Security Review - וזה תמיד ידרוש Security Review.וברגע שזה דורש Security Review, אני רוצה את המינימום Frictionאני לא רוצה שיבואו שיפנו אליי ושישאלו . . . כאילו, חלק מהעבודה עם Pillar, מאפשר כבר לחשוף את זה לצוותי Security, הכל במקום אחד,ואנחנו מאוד משתדים להיות כאילו, אתה יודע - Developer Friendly, ולבוא למקום של המפתחים יהיה כמה שיותר קל להטמיע, כמה שיותר קל לעבוד.(אורי) תגיד, יש Best Practices למפתח, שמפתח מעל LLM?(גיא) וואי, זה שאלה - “שאלת השאלות”. ממש אני אוהב את השאלה, אורי.(רן) כבר שאמר ביידן - “Don't”.(גיא) וואו, זה בדיוק התשובה שרציתי להגיד . . . .בגדול, התשובה היא “תניח שכל מה שיכול להתחרבש, יתחרבש”  . . . תניח שה-System Prompt שלך הולך לדלוף.ותניח ש . . . סתם, לדוגמא - אל תרנדר (Render) לי עכשיו Markdown, שג'ונרט (Generated by) על ידי LLM, כי אתה לא יודע מה הולך להיות שם מאחורה.תניח את כל הרע שיכול לקרות, וזה מה שיהיה . . . עכשיו ברצינות - ה-Best Practice: יש כלים שעוזרים עם Best Practices.יש כל מיני כלי Open Source - אני מזמין את המאזינים ללכת לחפש מונחים כמו Prompt Hardening, אוקיי?זה בעצם שיש כל מיני מוצרים Open Source-יים, שאתה זורק אליהם את ה-System Prompt - והוא מוסיף כל מיני הגנות.זה דברים קטנים שעוזרים.עכשיו בסוף - זה Endless. כאילו בסוף, גם אם אני אעשה Prompt Hardening, עדיין כנראה יש סיכוי טוב שהמודל ידריך אותי להגיע לסלובניה דרך פולין . . . כאילו, זה דבר שהוא יכול לקרות.ולכן לדעתי אין מנוס משכבה - שהיא שכבה דינמית, אקטיבית, ב-Real-time.וזה דבר שהוא מעבר ל-Best Practices של פיתוח.כי הגיינת-קוד - כולנו צריכים לקיים כל הזמן. זה לא שונה,ועוד דבר שלא דיברנו עליו היום, וחשוב לי גם להגיד - בסוף העבודה מול LLM - מול Open AI, מול Anthropic - זה עבודה שהיא מאוד דומה לעבודה מול API.מול כל API יש Best Practices ויש הגיינה שצריך לעשות, וצריך לעשות Error Handling ו-Circuit Breaking ו-Time Out והכל.וזה אותו דבר.ההבדל הוא, שיש פה איזשהו Black Box בקצה השני - זה לא דטרמיניסטי.אז זה לא כמו API שאני מכניס Input ואני יודע מה אני הולך לקבל.זה לא מוגדר בדוקומנטציה (Documentation), אין ארגומנטים (Arguments) כמו שדיברנו קודם.והדבר הנוסף זה שלכלי הזה, ל-LLM הזה, יש לפעמים איזושהי נגישות למקורות מאוד מאוד רגישים.ויש יכולת קבלת החלטות.והדבר הזה ביחד מייצר ריסק די גדול, שכדאי לכל הפחות להיות מודעים אליו ולעבוד בצורה חכמה.(אורי) ברוכים הבאים לעולם הכאוס . . . (גיא) בול . . . 40:55 עוד קצת Pillar לסיום(רן) ובנימה אופטימית זו . . . . אבל לפני שאנחנו מסיימים פה - עוד קצת על החברה, על Pillar,אז אמרת שאתה מנהל פיתוח שם. אתם אולי מחפשים מפתחים? איפה אתם נמצאים? ספר קצת . . .(גיא) כן, אז אנחנו - אני ב-Pillar בערך כשנה, אנחנו היום שמונה אנשים בחברה.מאוד Early Stage אבל רצים מאוד מאוד מהר.אנחנו היום חמישה בפיתוח - ואני אגיד שבקרוב מאוד אנחנו נתחיל לגייס, או אני אגיד “נחזור לגייס”, מפתחים.זה יהיה מפתחים, מפתחות, דאטה סיינטיסטיות (Data Science), אנשי ונשות Security.ובכלליות אנחנו מחפשים אנשים מאוד מאוד טובים - Culture טוב, אנשים ב-Good vibes.ואתם מוזמנים לפנות אליי, כמובן להיכנס לאתר - אבל אני חושב שזה “של פעם” קצת.אז אני מניח שהלינקדין שלי הופיע איפשהו, ה-Twitter [@guyg_99].(רן) Instagram, עזוב . . .(גיא) כשאני מכיר אנשים -  אני יוצא לפעמים למסיבות, לאירועים - אז אני, כשאני מכיר אנשים חדשים, אנחנו מחליפים LinkedIn . . . זה לא אצלי, זה לא Instagram . . .(רן) “Old School” . . . (גיא) ממש.(רן) יש לך כרטיסי-ביקור בכיס?(גיא) בדיוק . . . (רן) איפה אתם נמצאים? יש לכם משרד?(גיא) כן, אנחנו יושבים היום - אני לא יודע מתי יצא הפרק - אבל אנחנו היום יושבים ב-Mindspace ברוטשילד, בתל אביב,אז למי שגר בתל אביב - כיף.ולמי שלא - זה חמש דקות מהרכבת הקלה.יש לנו כמה אנשים שמגיעים מחוץ לעיר - מגיעים ברכבת, ממש בקטנה,יש לנו הורים לילדים, אנחנו כולנו מגיעים מארגונים מאוד מאוד טובים, וניסינו להביא את זה לתוך החברהלבנות ארגון טוב ובריא מההתחלה, שצומח . . . בוא נגיד שצומח על איזשהו חומר, על איזשהו הון אנושי איכותי. זו המטרה.(רן) טוב - שיהיה בהצלחה! נראה שיש לכם מספיק עבודה, אתגר יפה.(גיא) כן. “יש הרבה עבודה”, כמו שה-CTO שלי אוהב להגיד.(רן) מעולה - אז שיהיה בהצלחה.תודה רבה.[קישור לקובץ mp3]  האזנה נעימה ותודה רבה לעופר פורר על התמלול!

פרק מספר 487 של רברס עם פלטפורמה - באמפרס מספר 85: רן, דותן ואלון באולפן הוירטואלי עם סדרה של קצרצרים שתפסו את תשומת הלב בתקופה האחרונה - בלוגים מעניינים, דברים מ- GitHub, וכל מיני פרויקטים מעניינים או דברים יפים שראינו באינטרנט וחשבנו לאסוף ולהביא אליכם.וכמיטב המסורת לאחרונה - גם לא מעט AI, כי על זה הצעירים מדברים בזמן האחרון.🎗️00:53 דותן(דותן) כן, אז האייטם הראשון - למי שמכיר LSP, אז זה פרוטוקול של VS Code, נראה לי ששם זה הומצא, והוא בא להגיד...(רן) אני חשבתי שב-Vi, האמת . . . חשבתי שב-Vim המציאו את זה. שם לפחות נתקלתי בזה בפעם הראשונה . . . (דותן) לדעתי . . .  האמת, אני לא יודע. בראש שלי LSP הגיע במקור מ-VS Code, ועשה את דרכו ל-Neovim והתגלגל.וזה אומר, שאם אתה רוצה לייצר Plug-in לעורך שלך - כדי, נגיד, לעשות Refactoring, לעשות דברים חכמים בקוד.אז אתה יכול לכתוב בעצמך LSP Server, שיש לו Instance אחד במערכת שלך בדרך כלל - וה-Editor שלך מדבר איתו בפרוטוקול מסודר, בפרוטוקול LSP.וככה אתה מקבל את הפונקציונליות הזאת, בלי לכתוב משהו ספציפי ל-IDE.כי אם אתם זוכרים, אז נגיד JetBrains, יש להם את ה-SDK שלהם, ואם נלך אחורה ל-NetBeans גם כן, וכו' וכו'.זאת התקופה שהיית כותב Plug-in לכל Editor בנפרד.(רן) זאת אומרת, יש הפרדה בין ה-Frontend -שזה בעצם ה-IDE, וזה יכול להיות JetBrains, זה יכול להיות VS Code, זה יכול להיות Vim - לבין ה-Backend, שמממש את הלוגיקה של השפה עצמה.(דותן) נכון, כן.אז סתם כאילו לפתוח רגע את הנושא - כל אחד יכול להוריד LSP לשפה שלו.אגב, יש LSP טובים, ויש פחות טובים.בדרך כלל, אם לשפה יש LSP Server - נגיד ל-Lua או ל-Python וכו' - זה אומר שההשקיעו שם די הרבה בצורה טובה.אז פה יש LSP Server שהוא בעצם מעניין - הוא LSP AI, וגם ככה נקרא הפרויקט.שזה אומר שאפשר לקחת את הפרויקט הזה ולחקור, להתעמק בו - ולהוסיף לו AI,או לקחת חלק מה-Provider-ים שלו, ואז ליצור איזשהו “Copilot משלכם” [עם בלאק-ג’ק?]הוא בא ארוז עם כמה וכמה Extension-ים.נגיד, אם רוצים לעשות “Local AI Copilot” כזה, אז אפשר להתחיל מהפרויקט הזה.כלומר, משלכם - או להשתמש בפרויקט הזה בתור איזשהו Driver ל-AI מקומי.(רן) כן, שאלה - אני לא יודע אם צריך לבדוק את זה, אבל בדרך כלל, הכלים האלה שעושים Code Completion, או בכלל שעוזרים לך לכתוב קוד, הם צריכים לקבל Context. כ-Context לא רק, נגיד, איפה ה-Cursor שלך כרגע נמצא וכמה שורות לפני ואחרי, אלא הרבה דברים נוספים, כמו נגיד איזה קבצים כרגע פתוחים, לפעמים אפילו מסתכלים על יותר מזה - על הפרויקט, לפעמים גם על תיעוד וכו'.השאלה אם כל זה קיים בתוך ה-Language-Server-Protocol? כי כשהוא הוגדר, אני מניח שלא חשבו על Use Case כזה . . . השאלה אם זה קיים פה ויודע לעבוד עם זה?(דותן) האמת שהשאלה טובה . . . מה שאני התעסקתי עם LSP זה רק Per-Document, זאת אומרת - מה שאתה עובד עליו כרגע.לא דווקא השורה, אלא כל המסמך.אני רוצה להאמין שיש יכולת לדחוף לו עוד Context, אבל לא בדקתי את זה ספציפית.כן, זה כנראה אלמנט חשוב לדברים כאלה.מה שאני יכול להגיד - אחד מה-LSPs שאני מכיר לעומק זה ה-LSP של Rust.שם יש פרויקט שנקרא Rust Analyzer, וזה סוג של “מוח” כזה מאוד מאוד מורכב, שנוצר כדי לנתח את הקוד שלך ב-Rust.על “המוח” הזה הרכיבו LSP, ואז בעצם נולד איזשהו Server, שמשתמש ב-Rust Analyzer כדי לנתח את הקוד שלךוכל הפרויקט הזה מנתח את כל הקוד, בשלמותו.אז אני מניח שיש דרך לעשות את מה שאתה מתכוון אליו.(רן) אוקיי, אחלה.(אלון) סתם בדיקת עובדות - VS Code אכן התחילו עם זה ראשונים, ל-LSP.(דותן) כן, זה מעניין - יש הרבה דברים טובים ב-VS Code.שזה נחמד, כאילו... (אלון) יצא ל-Microsoft משהו טוב בסוף . . .(רן) הסטה קצרה, בערך באותו נושא - אתמול בערב קיבלתי אימייל ש-GitHub Copilot הוא עכשיו בחינם לכולם.אז המלחמת ה-Code Completions או ה-AI Coding Assistants, מתחממת - הזכרנו את זה גם בפרקים הקודמים [482 Bumpers 84].יש את Cursor ואת Windsurf ולא מעט אחרים.עד עכשיו Copilot היה בתשלום, עכשיו הוא בחינם - לדעתי, ל-2,000 Completions בחודש, אם אני זוכר נכון, ומעל זה זה כבר בתשלום.אבל הנה - רף התשלום הולך ויורד, והתחרות מתחממת.(דותן) כן, זה מודל טוב של ה... כי אתה מתחיל, וזה ממש כמו סם.כאילו, ברגע שאתה מתחיל לצרוך את זה, אז אתה תתקע, ואז...עד אז, כל הזמן שואלים “זה מנוון? זה מנוון?”אבל אני לא יודע אם זה באמת מנוון - אבל מישהו שמתרגל לזה, לדעתי, הוא מתרגל לזה קשות.ואז אתה נתקע בלי - ותצטרך להתמודד עם הדילמה, אם אני מוציא כרטיס אשראי וקונה עוד קצת כדי שאני אוכל להשלים את המשימה, או חוזר לתכנת, להפעיל את המוח לבד.(רן) או שאתה קמצן ועובר בין סביבות שונות עד שנגמר לך - בין Cursor ל-Windsurf או ל-Copilot.(דותן) כן, זה מעניין. אני מהמר שבסוף, אני חושב רגע . . . . אני חושב שבסוף זה חייב להיות חינם לגמרי.מספיק שאחד יבוא וייתן חינם, ואז הוא יקרע את ה . . . כי ההבדלים הם מינוריים בסוף.(אלון) אבל זה יקר . . . כאילו, אלא אם כן יתחילו להריץ את זה Local-ית, אז זה בסוף יעלה הרבה כסף, הסיפור הזה.(דותן) כן, אבל אחד שייתן חינם, בדרך כזאת או אחרת - ישבור את הצורה של כל הדברים האלה.כולם ילכו לחינם, בסוף.(אלון) טוב, זה בקיצור - Microsoft או Google יתנו לכולם חינם, וזה יזרום עם זה.(דותן) בקיצור, לגבי Copilot - כל הזמן אמרתי “גם אם זה חינם, אני לא אשתמש בזה!”עכשיו אני צריך לשנות את זה ל”גם אם ישלמו לי, אני לא אשתמש בזה!”(אלון) דותן, בוא אני אשלם לך קצת, ותתחיל לבדוק את זה . . . (רן) דווקא, דרך אגב, נגיד בעולם ה-Editors - היו הרבה כל הזמן בתשלום, עד שהגיע VS Code.זאת אומרת, הוא לא הראשון שהוא חינם - אבל הוא חינם והוא יחסית טוב,(רן) עדיין - יש בתשלום, נכון? IntelliJ ו . . . (דותן) כן, אבל מספקים לך משהו שהוא ייחודי - כאילו, איזושהי נישה, שממש תופסת אותך באיזשהו כאב.כרגע, LLM זה מאוד מאוד גנרליסטי (General) - אני מקבל את אותו דבר, כבר בדקתי, מ-ChatGPT, מ-Claude . . . האמת שאני פותח את ה-Browser, ה-Tab הראשון שיש לי עם זה Claude או ChatGPT פתוחים - אני אפילו לא מסתכל, פשוט לוחץ על ה-Tab, זורק שם את הקוד שלי, אומר לעשות Refactor או משהו כזה, לוקח את הקוד, אפילו לא מתייחס למה השתמשתי מרוב שזה-זה...(רן) אני מאמין שה-Code Assistants - כן, כל אחד יחפש לעצמות הייחודיות. אם זה, אני מניח, להסתכל על... דיברנו קודם על Context, אז אם זה להסתכל על Context-ים שונים, שיתנו לך תוצאות יותר איכותיות, או אולי להקל על ה-Workflow, יש כאלה שנגיד, הולכים בכיוון של Testing אוטומטי, ואחרים . . . אז אני מניח שכל אחד ימצא לעצמו את הזווית.אבל כן - ימים יגידו.(אלון) אני חושב שמחפשים את הזווית רק כי עדיין אפשר לעשות הכל.ברגע שאי אפשר לעשות הכל, שזה עניין של זמן - אז כולם יעשו הכל.ואז הייחודיות של JetBrains תיהיה שהם יעשו הכל - רק לאט . . . כמו שאנשים אוהבים את ה-IDE שלהם.(רן) זה יתן לך זמן לחשוב לפחות . . . (אלון) כן, כי מה אני עכשיו ממהר? מה קרה? מה, אני אשתעמם! נעשה את זה לאט, ניקח את הזמן . . .(רן) איכותי, איכותי.(אלון) איכותי, משקיע בך.(רן) טוב, הבא בתור, דותן . . .(דותן) אז הבא בתור זה שירות, או חברה, שנקראים Koyeb.אני לא יודע מה המשמעות של השם הזה, זה שם שקשה מאוד להגות . . .(רן) שם כואב, מאוד כואב . . . .(דותן) כן, שם ממש “קוייב”, זה כאילו “כואב” בעיראקית . . . זה המלצה שקיבלתי מחבר-מערכת בשם רפאל דקר.ואם אתם זוכרים את Heroku, שהיו פעם בחינם . . . והיית פעם בונה משהו וזורק ב-Heroku באפס מאמץ - בלי DevOps, בלי כלום - וזה עבד פשוט מדהים.אז היום יש כמה אלטרנטיבות. חלק מהם מרגישים כמו “Heroku גרסת אלפא”.אתה דוחף אליהם, ואיפשהו נתקע לך איזשהו Service, או לוגים מתחרבשים לך - ממש כאילו, “לא בריא“ כזה . . . אני לא אגיד איזה פלטפורמות, אבל אם אתה עשה גוגל “Alternatives Heroku”, אתה תקבל איזה 3-4 כאלה - שזה רק מראה כמה Heroku הקדים את זמנו.ו-Koyeb נראה ממש Heroku Alternative - יציב מאוד, ברזל, בטון - קחו את החומר שנראה לכם - נראה ממש טוב.גם במבחן התוצאה - פשוט עובד.ומסתבר שזה, כאילו מהחוויה שלי, וגם רפאל שהשתמש - זה פשוט עובד.וכמובן תמיד מחפשים את החינם - אז יש פה Tier חינמי מספיק טוב, שמזכיר את “ימי Heroku העליזים”שהיית פורש מיליון אפליקציות Demo, שחיו שנים על ה-Instance המסכן של Heroku . . . (רן) כן, אני רואה שהם גם מאוד מדגישים את עניין ה-GPUs, ויש להם למעשה - לפחות בעולם ה-Marketing - יש להם שלוש קטיגוריות.אחת זה Language Models. שתיים זה AI Stack והשלישי זה Web Framework.אז Heroku נכנס אולי למשבצת של ה-Web Framework, אבל השניים הראשונים - Language Models ו-AI Stack - זה לגמרי פוקוס על AI.אז כן, וגם בכל הדיאגרמות שלהם, לפחות השיווקיות, הם כל הזמן מראים קודם כל GPU - ורק אחר כך CPU . . . (דותן) . . . כן - שזה Win-Win, כי הגעתי לזה לא בשביל ה-GPU - בכלל לא בשביל ה-GPU - והם עושים עבודה ממש ממש טובה בלתת לך את הצעד הראשון הזה, באפליקציה שאתה בונה.ואתה אומר “יאללה, בוא נראה אם אני יכול לעשות איזו הכנסה פאסיבית כזאת, מאיזשהו פרויקטון”.זה בדיוק מה שהקוביה של Heroku הייתה עליה - זה עובד, זה מעולה.(אלון) מגניב לאללה, האמת . . . (רן) כן, נראה טוב.(אלון) . . . זה גם GPUs - שזה היום . . . כאילו, GPUs זה כזה “On-Demand” - שזה נחמד, כי זו נישה בעייתית היום, שיש להם.ושמע, אם זה ה . . . עוד לא מצאתי - מצאתי כמה, האמת אני חייב להודות, כבר לא רעים, בעולם של Heroku.כאילו - האלטרנטיבות.(דותן) מי למשל? אני מכיר Fly, Render . . . (אלון) Render זה סבבה . . . . כאילו, עם Render הצלחתי אשכרה לעשות משהו בלי...(דותן) אתה צריך לשים כרטיס אשראי, נדמה לי, ב-Render . . . (אלון) לא, לא, לא, לא - לא חייבים. שם זהו, אפשר להגיע... אפשר להגיע לחודש חינם בלי אשראי.(דותן) לא, לא חודש חינם - אני רוצה “חינם לכל החיים”.(אלון) לא - חינם לכל החיים.כמו Heroku - חודש Compute Time יש לך.אז אפשר לעשות איתו, שהוא סבבה.פחות מתחבר, יותר אהבתי את Heroku, אבל זה עניין של טעם - אבל זה נראה מגניב, כי פה גם GPUs וזה . . . (דותן) כן, נזכיר שב-Koyeb יש גם Postgres, Redis והדברים האהובים . . . (רן) נחמד - ננסה. תודה!(דותן) הפרויקט הבא נקרא RSQL.עכשיו זה - אתם מכירים את הקטע של Re-write in Rust? מכירים את זה שזה רץ כזה?(אלון) אתה כל זמן שולח לי “כתבתי מחדש ב-Rust” . . . לא, זה Meme שרץ כזה ברשת, ב-Twitter וכאלה . . . למשל, אולי משהו שאתם יותר מכירים זה את הכלים של Python, ששכתבו ב-Rustיש את uv למשל . . . כלים מטורפים, שבאו ו . . . הרי ב-Python את PY, ואז התחילו Poetry וכל החברים האלה.ואז בא בחור, בשם נדמה לי Charlie Marsh, ממש שלפתי את זה עכשיו מהזיכרון, והחליט לשכתב ב-Rust.זה ה-Principal שלו, כאילו. נקרא לזה “המוטיב-לפעולה”.ואחרי שהוא סיים, הוא בעצם גילה שהוא יצר כלי ש”מעיף את כל הדברים האלה מהמים", מה שנקרא, בלי להתאמץ.וזה כבש את כל עולם ה-Ecosystem של Python.והוא הקים חברה, ועכשיו החברה הזאת - כל יעודה זה להחליף את כל כלי Python בכלים מבוססי-Rust.וזה ממש עובד - אנשים פשוט מתפלצים מהמהירות, מהיעילות, מאיך שזה עובד.אז יש טרנד כזה, וזה חלק מהדבר הזה - וגם יש סוג של Meme כזה, שכל דבר משכתבים ב-Rust.אז זה אחד מהדברים שגם קרו זה כלי שהסתכלתי עליו ממש ממש מזמן, כי השתעשעתי עם לייצר איזשהו “SQL over everything” כזה, לצרכי מחקר Security.ויצרתי זה משהו קטן, “צעצוע” - וזה היה מספיק לי, ושם עצרתי.אבל הכלי הזה המשיך להתפתח - אנחנו קוראים לו RSQL.זה התחיל גם בתור משחק - מישהו שבא ושכתב כלי נפוץ, נדמה לי ב-C, שעושה דבר כזה.הוא שכתב את זה ל-Rust - וזה הפך להיות מפלצת.אז עכשיו, הכלי הזה לא רק שמתחקר SQL ועושה דברים כאלה מה-Command Line, אלא מתחקר גם Columnar Databases ובעצם כל מה שאפשר לתחקר כ-SQL, זה עושה את זה.זה CSV, זה מלא מלא מלא פורמטים.(רן) כלומר, זה סוג של, אם אני מבין נכון, סוג של נגיד תחליף ל-Psql, שהוא נגיד ספציפית ל-Postgres, אבל גנרי לכל שאר ה-Database-ים, זאת אומרת לא רק ל-Postgres . . . .(דותן) כן, זה יכול להיות Avro, זה יכול להיות, לא יודע, Postgres או CockroachDB, הכל הכל הכל . . . אם אני זוכר נכון, יש - היה או יש - כלי שנקרא q, זוכרים?(רן) כן, של Harel Ben Attia . . .(דותן) בדיוק. אז לדעתי, זה הכלי שכאילו הוא שכתב, או “Inspired by” - או שזה קרה במקביל, בלי קשר. אולי הוא לא הכיר . . .(רן) אז q, אם אני זוכר נכון, הראל - מה שהוא עשה, הוא השתמש ב-SQLite כדי לתשאל קבצים ב-Disk . . . זאת אומרת, נגיד יש קובץ טקסט, או קובץ csv - הוא טוען אותו לתוך SQLite ואז מריץ עליו SQL.(דותן) כן, הוא “שותה הכל לשם”, ואז . . . (דותן)  ופה, הוא עושה גם דברים מהסוג הזה, וגם ניגש לתחקר את הפורמט, מה שנקרא “רואה לפורמט את הלבן של העיניים” . . . .אז זה ממש נחמד, למי שמחפש . . . למי שזרוקים לו קובצי, לא יודע - Avro או Parquet, כאלה . . . וגם רוצה לתחקר Database-ים מה-Command-Line.זה אחלה דבר.(רן) אני חושב של-Parquet זה שימושי, כי לא מצאתי כלי נוח ל-Parquet . . . כאילו, יש כל מיני CLIs, אבל זה הכל כזה נורא מעצבן ואיטי . . . . זה יכול להיות שימושי.(דותן) אז זה כנראה לא לא יהיה האיטי . . .  או במילים אחרות, זה כנראה יהיה הכי מהיר שתקבל.אני לא יודע אם זה יהיה לך נוח . . . אתה יכול לנסות.(רן) אוקיי.(אלון) אין כלי נוח ל-Parquet? באמת?  . . . (רן) לא יודע, לא מצאתי בינתיים.(אלון) כאילו, אני . . . (רן) לפני חצי שנה הייתי צריך משהו, חיפשתי - ולא מצאתי משהו . . . משהו “נעים”. אולי זה שפספסתי.(אלון) לא, לא, בסדר. זה פשוט תמיד מפתיע אותי, כי זה פורמט שכאילו הוא כביכול פורמט שניהיה סטנדרט, ואין לו Ecosystem . . . .(רן) כן . . . כאילו בסוף, מצאתי שהכי נוח זה לטעון את זה בתוך Notebook, ואז לשחק עם זה . . . כאילו, לטעון את זה לתוך DataFrame Python-י, ואז לשחק עם זה ב-Notebook.אבל לפני, אם אתה רוצה הרבה פחות מזה - אתה רוצה פשוט משהו ב-CLI, שיבדוק כמה שורות יש או איזה עמודות יש, ולא מצאתי ממש כלי נוח שעושה את זה.כאילו יש - אבל איטיים מעצבנים, Java, כאלה . . . (דותן) עוד דבר מעניין שאני חושב שאולי גרם לכלי הזה לתפוס טוב, זה שאם חושבים על AI ו-Agents, אז בעצם אפשר לקחת כלי כזה, לתאר ל-AI את כל הדרכים להשתמש בו, בכל הפורמטים . . . ועכשיו זה הפך להיות Tool “בתוך החיים” של ה-Agent שאתה בונה.זה יכול להיות גם נחמד.(רן) אוקיי, Nice . . . (דותן) טוב, אז מחר - האמת, זה לא כזה חשוב בפודקאסט, אבל לא משנה - “מחר יש גשם”, ככה אומרים. אולי כשייצא הפודקאסט יהיה גם גשם . . . ויש פה איזשהו פרויקט נחמד, נראה לי, לעשות עם הילדים בבית.זה פרויקט של Facebook Research [Meta Research] - הם בעצם לוקחים דמויות שילדים מציירים על נייר, ועושים להן אנימציה עם AI.כשאתם נכנסים לאתר, אז אתם יכולים לראות - יש פה בן אדם אמיתי, שקופץ ורוקדוהדמויות - כל הדמויות שהילדים ציירו - בעצם רוקדות אחריו.ואני מניח שעשו את זה עם הפרויקט הזה.(אלון) זה ממש מגניב . . . רגע, אני כאילו יכול לכתוב את הקוד, להעלות את התמונה שהילד צייר - וזה יעבוד?(דותן) אני חושב . . . או לפחות אני מקווה.(אלון) Install Docker . . . .כן.(דותן) אתה עושה פה Clone לפרויקט, pip install - ומריץ שתי שורות Import לספרייה של איזשהו פונקציית - Render כזאת.לוקח קובץ קונפיגורציה (Configuration) מוכן - ומריץ את זה.וזה עושה לך אנימציה לחתיכת-דמות מתוך הנייר שציירו אותה.זה מה שאני בונה עליו, שיצליח לי מחר . . . . ונראה אם זה יעבוד.אני עוד לא יודע אם זה יעבוד לי על המחשב, מבחינת Spec, אבל נראה שהם מתכוונים שתריץ את זה בעצמך, על כל מחשב .  . .(אלון) על שרת nVIDIA שיש לך בבית . . . . [קרו מקרים . . . .](דותן) זהו, שלא ראיתי פה שום דבר שאומר “קח GPU” וכו’ וכו’ . . .  אני מאוד מאוד מקווה שזה מודל קטן, שיעבוד.(רן) טוב, אני - יש לידי nVIDIA. להביא לך איזה ערימת GPUs?(דותן) תיסע לשם, תגיד להם “הנה, אני רוצה להריץ”, תכניס אסימונים למכונה - ותקבל את זה מודפס.(רן) נקבל שעות חישוב בלילה . . . .(אלון) זה הזמן לתרום לרברסים - אנחנו מחפשים GPU למהנדסים מסכנים . . . .(רן) “GPU מרופא, במצב טוב”.(אלון) כן, “יד שנייה מרופא”.(רן) אוקיי, אז איך זה נקרא? fairanimateddrawings-נקודה-קום.(אלון) קניתי! דותן, זה נראה לי . . . תקשיב, אם זה עובד, אתה ב- Hall of Fame . . . .(דותן) זה טוב, נכון? עכשיו, אתה - יש לך קפיצות יפות, אלון. יכול להיות שאני אבקש ממך לקפוץ לי וזה, ואני אקח את זה . . . (אלון) אני הדוגמנית, אתה אומר . . . .(דותן) כן. אני זוכר שיש לך תמות טובות.(אלון) ממש, ממש. זה לריקוד המודרטורים (מחפשים!) שאנחנו תמיד מתכוננים כל שנה, ולא יצא לפועל.(דותן) בדיוק. יכול להיות שעכשיו אפשר לעשות אנימציה של ריקוד המודרטורים . . . (אלון) או, הבאת הרעיון לכנס הבא.(רן) טוב, הרעיון הבא . . .(דותן) נכון אתם כל הזמן מסתבכים עם Traceroute ו-Ping? כל הזמן  . . . (רן) האמת שהרבה זמן לא . . . אבל כן! בטח! יש לך משהו טוב בשבילנו?!(אלון) היום בבוקר בדיוק הילדים שלי שאלו אותי מה קורה, ואמרתי “יש לי בעיה ה-Trace” . . . .(דותן) . . . . ”למה האינטרנט לא עובד?” - ואז הרצת Traceroute, נכון? אז יפה.אז עכשיו, יש כלי שמאחד את השניים, ולוקח את הפלט שלהם ועושה אותו אנושי ונחמד.ממשק כזה של CLI - אבל עם UI חמוד כזה וכיפי, ואפשר לדבג (Debug).ופעם באה שאומרים לכם שהאינטרנט לא עובד - אז אתם יכולים להשתמש בכלי הזה.(רן) רגע-רגע-רגע! לא אמרת את הדבר הכי חשוב - זה כתוב ב-Rust!(דותן) ברור, מה? לא . . . . אני כבר לא אומר, לא טורח לציין.כי כבר כל הכלים האלה . . .(רן) כבר מובן מאליו. יש לך Bias, כבר לא תביא משהו שלא.(דותן) כן . . .  אייטם הבא - (רן) רגע, לא אמרנו איך קוראים לזה - קוראים לזה trippy, ואפשר למצוא לזה ב-GitHubכמובן שכל הקישורים גם יהיו ב-Show Notes [הי!](רן) הכלי הבא . . . “קטנה”?(דותן) לא קטנה - kanata.ובשבילי היתרון היחיד שזה . . . נגיד רגע מה זה - זה מקנפג (Configure) מחדש את המקלדת, את ה-Keyboardלאנשים שרוצים להחליף את התפקוד של המקשים ברמה גבוהה.נגיד אצלי - ה-Caps Lock הוא Backspace. ככה אני מוחק עם Caps Lock . . .(אלון) אצלי Escape . . . (דותן) אצלך הוא Escape, אוקיי . . . (אלון) אני פשוט מוחק פחות - אני לא עושה טעויות כמוך - וכשקופץ לי חלון, אני מיד סוגר.(דותן) יש לך סגירה מאוד מהירה של חלונות . . . .(אלון) נכון - ואני לא טועה בכתיבה, אתה מבין? זה מעיד הרבה.(דותן) כן. אתה בעצם טוב ב-Multi-tasking, כי אתה יודע לסגור חלונות מאוד מאוד מהר . . .(רן) למעשה, כשמודלי AI, יש להם בעיה - הם פונים לאלון.(דותן) כן.(אלון) יותר מזה - כשאתה כותב, אתה מוחק קצת. אני פשוט סוגר את החלון, מתייאש. אם יש טעות - לא צריך!(דותן) יפה . . . אז זה אצלי.(רן) אז kanata משמש כדי לקנפג (Configure) את המקלדת מחדש, אוקיי. איזה עוד דברים עשית, חוץ מ-Caps Lock?(דותן) אז יש את המקלדת המגעילה - האירופאית, עם ה-Enter בצורת ריש?(אלון) נכון . . . (דותן) אז זה גועל-נפש . . . .(אלון) טפו עליה . . . (דותן) אז נגיד, אני לקחתי את ה-Back-Slash, שמופיע . . . נקרא לזה “בלמטה של ה-Enter” - והפכתי אותו גם ל-Enter.(אלון) יפה. רעיון יפה. אני גם פעם  . . . (דותן) עכשיו, זה מכניס אותך לתסבוכת - כי עכשיו מאיפה תביא צינור ו-Back-Slash?אז אתה מביא אותו מהמקש ליד ה-Z, שהוא שייך רק למקלדות האלה - הטילדה [~], נכון?(אלון) כן . . . (דותן) אז זה גם מסובך. מאיפה תביא טילדה~? מאיפה תביא?(אלון) הזזת את כל המקשים . . . חזרת בסוף לאותה נקודה.(דותן) לא, רגע . . . עכשיו הטילדה [~] - אתה יכול לראות שיש לך גם נקודה-פסיק [;] שם. זה מיותר.(אלון) שמע, זה נשמע כבר כמו מערכון של ארץ נהדרת, מה שאתה עושה עכשיו . . . .(דותן) רגע, אבל זוכרים שאת ה-Backspace נתתי ל-Caps Lock? אז זה אומר שה-Backspace פנוי . . . .אז ה-Backspace אצלי . . . (רן) שתי לחיצות מהירות על ה-Backspace זה הטילדה~?(דותן) לא! ה-Backspace המקורי, מעל ה-Enter - אצלי זה הטילדה~ . . . . בסדר?(רן) אוקיי . . . (דותן) זהו, ואז אתה משלים את כל ה...(רן) יש לך טוש לכל זה? אתה רושם לך, על המקלדת, את ה . . .(אלון) יש חצים . . . “זה הלך לפה, זה הלך לפה”. תרשים . . . תקשיב, הרווח נורא גדול ולא מנוצל - אתה יכול שהחלק הימני שלו יעשה משהו אחד, השמאלי משהו אחר - ודאבל-רווח יעשה משהו שלישי.(דותן) אגב, יש מקלדות כאלה . . . אתה לא טועה. שהרווח מפוצל לשתיים.(רן) אלון - דותן מקליד כל כך מהר, שהוא לא צריך רווחים . . . . אצלו הכל זה ברצף.(דותן) נכון. אני כותב את הכל רצוף, וה-AI מפריד לי . . .(אלון) . . .  ואז הוא מוחק, אתה מבין? הוא צריך למחוק מהר. זה כל האופטימיזציה - התחלנו מזה שהוא עושה טעויות, וצריך למחוק מהר.אולי פשוט תלמד להקליד בלי טעויות? זה יפתור לך את כל הבעיות האלה, של להתחיל להזיז כפתורים, להתקין מערכות . . . (רן) זה כמו כתב-סתרים . . . . כמו כתב-סתרים - אף אחד לא יכול להשתמש במקלדת.(אלון) אני לקחתי את זה למקום אחר, דותן.תקשיב, מה שאני רשמתי לפה, הנקדה הכי חשובה - שזה עוד כלי ברשימת Trolling שיש לי.כלומר - מישהו השאיר את המחשב פתוח, אתה מתחיל לעשות לו את כל המיפוי שונה לגמרי . . . .(דותן) זה חזק . . . להחליף לו את השורות, השורה של ה-SDF היא בכלל למעלה, וה-QWERTY למטה . . .(אלון) אתה מחליף את ה-Enter ב-Escape, את ה-Escape, את הרווח . . . .אתה מתחיל להחליף, גם מזיז קצת אותיות נגיד שקרובות - אתה נגיד הופך לו בין G ל-H, או כאלה, ואז הוא כאילו כל פעם חושב שהוא מקליד עם Typo . . . (דותן) אבל אתה חייב להשאיר לו שיהיה אותו מקש? השפה. כי ברגע שהוא יתחיל להקליד והכל יצא לו ג'יבריש, הוא ישר יחליף שפות.הוא יחליף לאנגלית, יחליף לעברית, יחליף לאנגלית - הוא לא יבין, כאילו, מה - למה זה יוצא לו כזה?(רן) זה נראה לי כמו שבירת-קרח טובה לראיון-קידוד . . . . אתה נותן למועמד מקלדת כזאת, ויאללה.(אלון) אולי זה הרעיון - אתה נותן לו מקלדת כזאת, והוא צריך לפענח מה בעצם  . . . מה דותן חשב במיפוי שלו, כשהוא הזיז את הטילדה~ ואיך הכל התחיל?(דותן) כי גם ככה ה-AI לקח את החיפוש בינארי וכל הדברים האלה . . . . (רן) אני בטוח שאחרי זה, הוא ישמח לעבוד איתך . . . .(רן) אוקיי . . . . COSMIC?(דותן) יפה, אז רגע - kanata, למי שרציני ואוהב להחליף דברים - מה שמיוחד פה, זה שכל הקונפיגורציות (Configurations) של ההזחות והזזות הם בקובץ טקסט קריא.ולא מצאתי שום כלי, שהשתמשתי בו עד היום, שיש לו טקסט שהוא קריא, והמטרה שהטקסט יהיה קריא זה שאני אוכל להעתיק את זה לכל מחשב שאני רוצה ולשמור את הקונפיגורציה הזאת.(רן) הבנתי . . . (אלון) עכשיו, כשמתחברים לשרת - זה גם ככה?(דותן) תריץ שם את הפרויקט הזה, ותזרוק שם את הקונפיגורציה .  . . .(אלון) אתה פעם סיפרת לי . . . (דותן) . . . אבל אני לא מתחבר לשרתים . . . מי מתחבר לשרת?(אלון) . . . אתה פעם סיפרת לי, עם ה-Dvorak בשרת . . . . הרגת את כולם. לא זוכר מה היה בדיוק.(דותן) כן . . . . היתה לי אפיזודה של Dvorak, וישבתי ממש, כאילו כל יום בעבודה ראיתי איך אני יורד בביצועים שלי . . . . ותכנתתי והקלדתי כמו . . .  כזה, עם אצבע אחת, ואחרי זה עם שתי אצבעות וכו’ וכו’.ואז זה תפס מהר, והתחלתי להקליד ממש ממש מהר.שזה היה “תוכנה של פעם” - אז היינו מתחברים לכל מיני שרתי Production ומתקנים שם תיקונים, תוכנת Enterprise כזאת.ואז, מה שקרה זה שהתחברתי לשרת של לקוח, שמתי לי הגדרות “כיפיות”, של Dvorak - והם נשארו  שם . . . ואז היה בעצם Demo ללקוח, והראש-צוות שלי נכנס לעשות את ה-Demo, ובעצם הוא זכר שיש לי את הקטע עם Dvorak, שיגעתי את כולם וגם החבר'ה שישבו איתי וכל פעם הוא היה צריך לבוא ולשנות את ה-Dvorak וכו’.וזהו, ואז נתקע לו ה-Dvorak והתחרבש לו כל ה-Demo, והוא לא הצליח להקליד.ואני גם לא יכולתי לסייע לו או להגיד לו “שמע, זה ה-Dvorak שלי שם בזה . . . קיצור, וזה היה הסוף של ה-Dvorak.(רן) מסתבר - בדקתי ביוקיפדיה - שDvorak הומצא ב-1936!(דותן) כן, כן. זה לא חדש. יכולתי לקחת גם Colemak וכל מיני כאלה, אבל אמרתי “אה, אני אתחיל במסורתי” . . . .(רן) טוב, זהו . . . . הבא בתור.(דותן) הבא בתור . . .(רן) COSMIC.(דותן) כן. יש חברה בשם system76 - חברה חמודה מאוד [שהזכרנו כבר בפרקים קודמים]היא בונה מחשבים - Desktop-ים - לשימוש כללי.מבוססי Linux - סוג של אלטרנטיבה ל-Apple.והייחוד שלהם שזה עיצוב כזה “רטרו” חמוד, כיפי. מאוד-מאוד איכותי, כאילו, ברמה ממש גבוהה.והם גם ידועים ככאלה שפיתחו את המערכת-הפעלה שלהם, שנקראת Pop!_OS.ובקהילת ה-Linux, ה-Pop!_OS נחשב סופר-סופר יציב.המון-המון אהבה למערכת הפעלה הזאת.יש לה רק חיסרון אחד - באיזשהו שלב, לפני  לא מעט שנים, היא “עצרה בזמן”.אני לא זוכר על איזה Ubuntu זה מבוסס, אבל הם הקפיאו אותה . . . הגיעו למסקנה שהם רוצים לפתח Desktop מאפס, להחליף את GNOME, להחליף אותו לגמרי.ואם תשימו לב, בהיסטוריה של Linux זה תמיד קורה - יש לך KDE, יש כל מיני אלטרנטיבות.יש שנאה מאוד חדה ל-GNOME, אבל גם יש אהבה מאוד עצומה לזה . . .  סוג של פרדוקס, שתמיד קיים ב-Linux.אז הם בעצם שכתבו את כל ה-Desktop Windowing System - ב-Rust.קראו לזה COSMIC - וזה אחד הפרויקטים הכי . . . נקרא לזה, “שאנשים הכי מצפים להם”.משחררים עדכונים, זו משימה מטורפת.ועכשיו הם הגיעו ל-Alpha, אחרי שנתיים של עבודה מאוד מאוד קשה.ואנשים כבר לוקחים את זה, וזה יציב.זה נראה כמעט אותו דבר כמו כל Linux שתראו - אבל הרבה יותר יציב.(אלון) קשה לי . . . קשה לי להסכים עם האמרה האחרונה שלך . . . בלי להכיר את הפרויקט אפילו.כי ב-Fixing Issues האחרונים, רשום Memory . . . איפה זה היה? שה-memory leak causing some panel applets to crash . . . (דותן) בסדר, אבל זה דבר רגיל ב-Linux, אתה רגיל לזה, זה לא לא רציני . . . .ואני אגיד לך גם - בזמן האחרון התחלתי להשתמש ב-Fedora, עם GNOME יחסית מאוד חדש.כל יום יש לי כזה Crash על Memory . . . .אני עושה איקס, לוחץ על האיקס - ומתחיל את האפליקציה מחדש.וממשיך הלאה - ואתה מתרגל לזה . . . פה קורס, שם קורס, פה כשאתה עושה Restart אז המחשב נתקע ולא רוצה לעשות Restart - אז אתה עושה עוד פעם Restart . . . . זה יציב.(אלון) תקשיב, למה אנשים מזוכיסטים, למה? למה לחיות עם ה-Linux-קקה הזה?עכשיו הבאתי את כולם עלי, עם המשפט הזה . . . (דותן) אין מה לעשות . . . מה תעשה? אתה צריך ממש לבדוק דברים על Linux אמיתי.מה תעשה? יש לך Docker, אבל לפעמים אתה רוצה לחיות בתוך ה . . . יום שלם, לבדוק.(אלון) בתוך הסחל’ה . . .  יום שלם לסבול.(דותן) כן, אין מה לעשות. לחיות בתוך “עמך” . . .  כן, אתה פורש את ה-Linux, אז אתה רוצה להיות . . . להבין מה . . . .(רן) אלון, אם התחלת בכזאת חיוביות, אולי תמשיך אל האייטם הבא שלך?32:56 אלון(אלון) טוב, יאללה - בוא נלך איתכם. יש פרויקט חמוד שנקרא steampipe - זה פרויקט, שבגדול מנסה להפוך כל API ל-SQL, שזה די נחמד.אם נגיד אתם רוצים לקחת רשימת User-ים מ-Amazon, אז עושים “Select Users From” . . . -  לא יודע,  משהו - “Role Administrator” או כל מיני כאלה - וזה יעבוד.אפשר גם ככה לעבוד עם API-ים של אחרים - של Slack, GitHub, מה שרוצים . . . אז ממש נחמד, בסוף SQL משתלט על העולם . . . אגב, עוד דבר נחמד ב-SQL זה שמודלי-AI נורא טובים בלעבוד איתם - אז אני חושב שזה יהפוך את זה אפילו ליותר קל להם בשביל להסתדר, כי זו שפה מאוד מובנית.(רן) כן, נחמד . . . אז נגיד Select Region ו- * Count, ו-From נגיד EC2 - ואז, נגיד, אתה מקבל כמה  Instance-ים יש לך בכל Datacenter.(אלון) כן, גם נורא קל למשל לעשות גם דוחות Billing ככה - אתה רוצה מחירים, CPU . . . מה שאתה רוצה - פתאום זה קל, כי לעבוד עם ה-API-ים האלה - לפעמים זה לא כיף.אבל ברגע שכבר הנגישו את זה ב-”SQL-יות”, אז פתאום יותר קל לעשות Queries מורכבים, שדורשים כמה קריאות API.בקיצור - חביב, חמוד.(רן) נחמד.(אלון) . . .  חביב וחמוד - ולא מזוכיסטי! דותן, רואה? אנחנו מחפשים דברים לא מזוכיסטים . . . (דותן) כן, האמת שזה נחמד. יש פה תמיכה ל-GitHub, בתור Provider כזה, Microsoft 365 . . . אגב - למה זה 365? . . .(רן) “למה השם”, אתה שואל?(דותן) כן. למה אני צריך . . . כאילו, למה זה . . . (רן) מה זאת אומרת? יש 365 ימים - ורבע - בשנה . . . (דותן) כן . . . אבל אני מבין למה אני צריך את המשביר 365 ימים בשנה - אבל למה אני צריך את זה?(אלון) בוא אני אגיד לך - אתה רוצה בלי חגים וסופי-שבוע? אפשר - יש להם חבילה, 30% הנחה, לא עובד בסופי-שבוע. יש לך Office - בלי סופי שבוע.(דותן) השאלה אם יש יום שה-Sh!t   שלך של Microsoft לא עובד - האם אתה מקבל זיכוי?(אלון) יש יום שה-Sh!t של Microsoft כן עובד לך?(דותן) זהו, אתה צריך פה לקבל . . . . אולי יש לנו פה תביעה ייצוגית . . . .(רן) טוב . . . (אלון) אני חושב שעוד שנייה יש על רן תביעה ייצוגית . . . . (איפה העו”ד של זוהר?](רן) ירדנו נמוך מדי . . . . בואו נעצור.(אלון) “פרק זה הינו . . . כל החומר פה הוא בהלצה! סטירי, ואין הנאמר . . . אין  לראות את זה כהמלצה” . . .(דותן) אני רק אגיד שאצלי ה-Microsoft עובד באמת 365 ימים - ממש על הדקה, על השנייה . . . (רן) חסר לך רבע . . .  שלא ידפקו אותך.(דותן) כן . . . . אוקיי - אייטם הבא.(אלון) “האייטם הבא בחסות” . . . . לא. אז מקודם, דותן, דיברת על - עכשיו זה משתלב טוב, האמת, עם זה שה-Copilot בחינם - אז Microsoft נהיו בעצם “Hub של AI”.כאילו, אני לא יודע אם יש להם משהו משל עצמם . . . כאילו, כי אני לא חושב שבאמת יש להם משהו שלהם.(רן) יש להם מודלים שלהם, כן - אבל הם לא לא באותה רמה.(אלון) אז הם לוקחים את OpenAI, ועכשיו הכניסו את Claude, כש-Claude הוא כנראה המודל - לפחות ממה שאני נתקלתי - הוא המודל הכי טוב לעבוד איתו.אני חושב שכל המודלי-AI נתקעו אי שם ב-Claude 3.5. כאילו, המודלי-טקסט, נתקעו שם.אני חושב שכל “ה-O-ים” האחרים - יש להם את היכולות הנחמדות שלהם, אבל הם בסוף, Under the Hood, הם פחות טובים מה-Claude. יש להם יתרונות מסויימים . .  .אז בקיצור, עכשיו אפשר בתוך ה-Copilot, לעבוד עם Claude - וזה ממש חביב ונחמד.(רן) למעשה, בתוך Copilot, אתה עכשיו יכול לבחור אם אתה רוצה לעבוד עם Claude או עם ChatGPT.(אלון) כן - ומעניין אותי, מה שאמרנו עם כל השיחות AI של מקודם, בעצם - מה יקרה ל-Cursor בסוף, וכל האלה.כי אני לא יודע כמה יתרון נשאר להם . . . . אז נראה.(רן) נחכה ונראה.(אלון) טוב, יאללה - הדבר הבא: פרויקט שנקרא Genesis, שזה פרויקט שמנסה לדמות את ה-Real Physics עם AII - ואז בעצם, אחד הדברים . . . .האמת שאתמול ראיתי את זה - למשל, סרטונים שהראו, כל  היוצרי-וידאו - Sora וזה של Google [Veo 2] וכל הסינים וכולם  . . . .אז נגיד סרטון של איך חותכים בשר - אז כאילו הם מצליחים לחתוך, אבל הפיזיקה של איך הבשר אחרי זה נופל נורא בעייתית להםהוא פתאום נעלם, הוא פתאום עף למעלה, הוא פתאום עף הצידה . . . . הוא פתאום נראה בצורה אחרת - והפיזיקה קשה.חוץ מהמודל התיאורטי של Google - אבל הם לא הוציאו אותו, אז זה קצת רמאות, כי גם אני יכול להקרין  סרט בבית ולהגיד שזה מודל AI עשה . . . אז בגדול - שוב, זה משהו שיצא אתמול, אז אני לא הספקתי להבין אותו כל כך, מה הסיפור - אבל בעיקרון, הוא מודל פיזיקה של “העולם”.אז אפשר איתו לעשות דברים די מגניבים - ככה זה נראה לפחות.אבל יכול להיות שעוד יומיים יקטלו אותו ויגידו שזה לא באמת עובד, כל הדוגמאות . . . (רן) דרך אגב, הסיפור הזה מזכיר לי איזשהו וידאו מצחיק כשראיתי, על כל מיני Fuckups של AI .  . . [תוחזר פינת המצחיקולים?]אז נגיד, כשה-Prompt היה “תייצר וידאו של דג סלמון שוחה בנהר”, אז אתה רואה דג סלמון שוחה בנהר - רק שהדג סלמון כבר בושל בתנור, ואתה רואה אותו מפולט וחתוך ככה, שוחה בנהר . . . אז זה משעשע.כן, אז מעניין אם הם באמת, כאילו, עושים פה את הפיזיקה . . . . מעניין איך הם עושים את זה.(אלון) כן, אז ראיתי לזה כמה דוגמאות נחמדות, אני יכול לצרף [הנה], שזה נראה די יפהאבל שוב - המודלים האלה, עד שלא משחקים איתם, קשה לדעת.כי גם Sora היה נראה מאוד מרשים ב-Demo-ים הראשונים - ואחרי זה, כשמתחילים לשחק איתו, אז “קצת פחות”, בוא נגיד זה ככה, בזהירות.נוסיף פה לינק יפה, היה פה איזה הסבר יפה, שמישהו שם דוגמא מ”הטוויטריה" (Twitter), אז ניתן לכם.ואז אם אתם רואים, הנה - אני אקריא לכם, פיקסל-פיקסל, שתדעו . . . אז זהו.(דותן) תעשה זה ב-RGB רק . . . (אלון) ב-RGB יהיה להם יותר נוח? טוב: 7 - 2 - . . . . בסדר.טוב, בטח נשמע על זה עוד כמה דברים - או שזה יבוא עם מלא חיקויים וזה יצליח, או שיקטלו את זה ויגידו שזה קקה, אבל אני עוד לא יודע . . . .אבל תסתכלו.(רן) אוקיי, Nice - האייטם הבא.(אלון) הדבר הבא - הוא לא קשור ל-AI, אבל הוא די מגניב. היה את ה-AWS, איך שזה נקרא - re:invent -  והדברים, אז הרבה Buzzwords וזה.אבל משהו אחד שכן תפס לי את העין - כאילו, כבר אני לא יודע, בשנים האחרונות לא יותר מדי התרגשתי  מהשינויים, אני חייב להודות.מה שכן תפס לי זה ה-Aurora DSQL - הוא כרגע אמנם ב-Preview, אבל ה-Aurora זה Database Proprietary של AWS, שמבוסס Postgresוהדבר המעניין ב-DSQL זה שהוא בעצם Distributed Endless Postgres  - שזה בתיאוריה ה-Database האולטימטיבי, אני חייב להודות . . . .כי כולנו תמיד אומרים “אין על Postgres!”, אבל מה לעשות - בקצבים מאוד גדולים או גבוהים, או בכמויות גדולות של Data, אין ברירה אלא לעבור למשהו אחר.ובתיאוריה, הדבר הזה פותר את הבעיה - ואז אפשר לקחת “Postgres Forever” . . .  שזה נשמע סופר-מבטיח . . . לא יודע עד כמה זה עובד, זה עוד ב-Preview - אבל  זה נשמע כאילו זה כל מה שרצינו כל החיים, לא?(דותן) מאיפה אני מביא הרבה Data? (אלון) אני אביא לך, יש לי קצת . . .. יש לי פה, בכיס.ואפשר להעביר תרומות! הקשרו לתרומות Data - 1-800 - Reversim . . . .(דותן) בוא נפתח תרומות ל-Podcast של Data . . . (רן) כמה שאלות מעניינות, אם אפשר, קודם באזור הרציני . . . אחד - Postgres, יש לו כל מיני Plug-In-ים, אז השאלה אם ה-Plug-In-ים יעבדו גם פה . . . ושאלה שנייה זה מה בנוגע לטרנזקציות ולקונסיסטנטיות (Transactions, Consistency), כי זה באמת החלק הקשה בדברים שהם מבוזרים . . . בדקת?(אלון) כן, בדקתי - עשיתי את המחקר בשבילך, כדי שאתה לא תצטרך לבדוק!אז אני קראתי את השקרים של AWS . . . סתם, לא.זה בדיוק כמו Spanner . . . .(רן) לא מכיר אותו! לא יודע מי זה שמדבר פה . . . (אלון) לא לא . . . . הקיצר, זה בדיוק כמו Spanner, הקונספט. ב-Spanner הרי עשו שעונים אטומיים, ו”ניצחו את ה-CAP Theorem” - אז זה אותו דבר  . . . רק ההבדל בין זה ל-Spanner זה שSpanner הוא לא מבוסס Postgres - כאילו, אין לו שום Plug-In, אין לו שום יכולת של Postgres, הוא Flavor של SQL משלו.וזה - הוא כן Postgres “אמיתי”.וגם, על פניו, המחיר שלו אמור להיות הגיוני, בניגוד ל-Spanner.הבעיה ב-Spanner, שלא יודע אם מישהו ניסה לעבוד אותו - הוא פשוט . . .  הוא לא הגיוני, המחיר שלו. הוא “יקר פיצוצים” . . . .(רן) בוא נזכיר - זה Bigtable, אם אני זוכר נכון, על על גבי Google Cloud . . . (אלון) לא - זה SQL . . . זה SQL.(רן) אה, זה כן SQL, אוקיי.(אלון) איזה SQL, שהוא ברמה של “Endless-SQL”, הוא אותו רעיון כמו ה-DSQL הזה, ה-Aurora DSQL.אבל הוא Flavor אחר של SQL שהם עשו, עם יכולות טיפה “מנוונות יותר”.ובגדול, גם עם אנשים שדיברתי ב-Google רצו שזה יהיה ה-Database  העתידי, שיחליף את כל ה-Bigtable-ים, אבל הוא פשוט יצא להם “יקר אינסוף”, ולא משתמשים בו כל כך, גם בתוך Google, לפחות לפני שנה, כשאני דיברתי שם עם מישהו שהיה “בסוד העניינים", מה שנקרא.והיתה שם תמיד מלחמה של “בואו נתחיל להשתמש בזה יותר, ואז נוכל להוריד את המחיר כי נשקיע בפיתוח” . . . .אני לא יודע אם זה מתקדם או לא, אבל זה הסיפור שם.אז זה “האח המקביל שלו מ-AWS”, תכל’ס.אבל על פניו, ה-Aurora זה Database מעולה, ואם באמת הם רק הפכו אותו לאיכשהו Distributed, אז זה מדהים . . . זה יכול להיות באמת מדהים.(רן) ונזכיר שיש להם גם גרסת Aurora ל-MySQL, אבל - כרגע לפחות  - לא Distributed.אולי זה יהיה הדבר הבא . . . ואז חברות שעושות Distributed MySQL יצטרכו “להתעורר על עצמם” . . . שמעת, שלומי?(אלון) כן, זה נשמע שמה שהם עושים פה זה די מטורף - ובתיאוריה, אני לא בדקתי, אבל זה אמור לעבוד עם ה-Plug-In-ים  של Postgres.כי זה ממש Postgres Compatible . . .יכול להיות שיש איזה פינות שלא בדקתי - אבל לפי ההבטחה שלהם, זה אמור לעבוד.44:51 סיום(רן) אוקיי - אז נראה לי שזה הכל היום, נכון?אז תודה רבה!(אלון) כן - אין לנו מצחיקולים! לא יצא לנו מצחיקולים הפעם . . . .(רן) לא יודע, נגמר לנו ההומור הפעם . . . .טוב - אז תודה רבה! אנחנו היינו אנחנו, אלה היו באמפרים - ונתראה בפרק הבא.[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 486 [פנטיום?] של רברס עם פלטפורמה, שהוקלט ב-10 בדצמבר 2024. אורי ורן מארחים באולפן בכרכור את עומר מחברת Pentera כדי לדבר על מוצר שחי On-Prem - ומעבירים אותו לענן [ספוילר - זה לא פשוט כמו שזה נשמע, במיוחד בענייני Security). 🎗️00:45 על עומר ו-Pentera(רן)  אז עומר, קצת על עצמך וקצת על Pentera?(עומר) אז נעים מאוד - עומר. הצטרפתי ל-Pentera - השם הקודם היה בכלל Pcysys, אבל אנחנו מנסים לשכוח את זה . . .  - בתחילת 2018.כחלק מה-Batch הראשון של המפתחים שהצטרפו לחברה.החברה קמה כבר ב-2015.התחלתי כמפתח, עשיתי מגוון תפקדים - והיום אני VP Engineering בחברה.ו-Pentera היא בעצם חברת-מוצר, שמפתחת פלטפורמה לביצוע מבדקי-חדירות אוטומטיים.מה שנקרא Automated Pen-Testing.כדי להבין את הבעיה ש-Pentera פותרת, אני חושב שצריך לחזור רגע לאיזושהי הנחת-יסוד - שבעולמות ה-IT, ה-Best Practice הוא בעצם לבצע Pen-Testing כדי לבדוק את הרשת הארגונית.תחת ההנחה שאתה לא יודע איפה אתה פגיע עד שלא בדקת.רק שיש איזושהי בעיה קטנה עם כל העולם הזה - שהוא ידני . . .והקצב שבו הרשת משתנה, שהוא שעתי, לא מאפשר לתהליך כזה להיות ידני.[למיטבי-שמע - 422 Pentesting with Erez Metula]אז בעצם, הפלטפורמה שאנחנו מפתחים עושה את המבדקי-חדירות - ממש “שמה לך את התוקף בכף- היד”, שאתה יכול, On-Demand, להריץ אותו.למה זה טוב, בנוסף? כי אתה רוצה לבדוק את עצמך לא בשעות-העבודה, לא על ידי בנאדם שצריך לאכול,  להפסיק, ללכת לישון . . . ואתה רוצה לבדוק את עצמך גם במקרי-קצה.מה גם שניקח רגע את התהליך הידני וננסה לדמיין אותו - נגיד שהגיעו בודקים, עשו את מה שעשו, עבדו שבועיים  בארגון . . . נגיד שהמבדק היה מעולה - ואחרי זה הם נותנים לך איזשהו דוח.הלכת ותיקנת, אוקיי, מה עכשיו? נחכה עכשיו עוד שנה כדי לראות שמה שתיקנתי בכלל עבד, או איזה אפקטי-פרפר הוא עשה?הרעיון פה הוא להריץ עוד פעם בדיקה On-Demand - וככה אתה יכול לוולדץ (To Validate) את זה שעשית עבודה טובה.(אורי) זה בעצם לקחת את הרעיון של Automatic Testing  - ה-Unit Tests, System Tests, שאנחנו מכירים  מאיכות של תוכנה - “ולהלביש אותו" על Penetration Testing?(עומר) עם אפילו עוד קצת יותר אבסטרקציה, אפשר לאטמט (Automate) הכל.אז גם פה, במקום לעשות בדיקה ידנית ל-Feature שעשית - אז כן, זה בדיוק אותו קונספט.(רן) בוא ניתן לזה קצת צבע . . . ודרך אגב, לא הרבה יודעים - תמיד רציתי להגיד את זה - “לא הרבה יודעים”, אבל אני  התחלתי את הקריירה שלי בתור Pen-Tester. אז פעם, דברים שהייתי עושה לפני די הרבה זמן, זה סריקות Port-ים, סריקה של כל מיני Resource-ים עם ACL-ים לא נכונים, ניסיון להריץ כל מיני “סקריפטולוגיה” (Script) של דברים שמוכרים, שיודעים שיכולים לפרוץ, כמו SQL-Injection ומיליון דברים אחרים, שאני בטוח שמאז נולדו הרבה כאלה. [שאל את יוסף - The Dark Side of AI: The Hidden Risks in Open-Source AI Models / Jossef Harush Kadouri]זאת אומרת, זה סוג ה-Pen-Testing שאנחנו מדברים עליו?(עומר) ממש כך.מה שהמערכת עושה - היא מחקה את פעולות-התקיפה שתוקף אמיתי היה עושה, ולא נותנת לסימולציה או ל-Playbook-ים להיכנס.כלומר, אפשר לדמין איזושהי מכונת-מצבים סופר-מורכבת, עם איזשהו Exponent של מצביםשכל פעם, המכונה צריכה לקבל את ההחלטה הטובה ביותר, כדי לחלחל את ההתקפה ולהתפרץ לארגון - עד שמגיעה ל-Crown-Jewel בתוך הארגון.אז בעצם, זה מידול של תהליך התקיפה.(רן) שאלה תם - איך אתה יודע שאתה לא מזיק בזמן שאתה בודק?(עומר) אנחנו נורא אוהבים את השאלה הזו . . . יש המון אנרגיה והשקעה במחקר.יש לנו, אני חושב, באחוזים, את קבוצת המחקר מהגדולות שיש בחברות מהסוג שלנו.כל ה-Payload-ים וכל ה-Cyber וכל התקיפות וכל המנגנון שמשנע את התקיפה - מפותח על ידינו.אנחנו חיים במרחבים שהם בטוחים - אנחנו לעולם לא נעשה משהו שמתעסק עם Kernel-ים או התקפות מסוג Denial of Service וכדומה.ואנחנו ממש חרטנו את זה על דגלנו - ש-Safety by Design.אנחנו יודעים לזהות את הצורה שבה המערכת נמצאת כרגע - ואנחנו יודעים לעדכן מה קרה במקרה שמשהו  השתבש.וכשאני אומר “משהו השתבש” - זה פיזיקה, שלא הצליחה לקרות.אז אפשר לדווח על זה.ויש כל מיני Safe-Guard-ים כאלה.(רן) אוקיי, מה גודל החברה? פחות או יותר ש...(עומר) גודל החברה? אנחנו היום כמעט 350 עובדים בכל העולם.(רן) ופיתוח?(עומר) HQ ופיתוח בארץ; הפיתוח - סדר-גודל של פלוס/מינוס 50 מפתחים.(רן) אוקיי.(אורי) תגיד, יכול להיות שבאחת השנים האחרונות, חברה מאוד בולטת בתחום שלכם נפרצה בעצמה - ואז חלק מהמתודולוגיות שלה זלגו לעולם ההאקרים, ל-Dark Net? יכול להיות שהיה דבר כזה?(עומר) אם יכול להיות?(אורי) לא, כאילו אני חושב זה פורסם . . . [הכוונה לכיף הזה - The Leaked NSA Spy Tool That Hacked the World או אולי לקרקס בין Cellebrite ל-Signal?](עומר) אני לא מצליח לשלוף . . . . אבל אני חושב שבאופן כללי, זה יהיה יחסית קשה לפרק, לעשות Reverse לדבר הזה.כלומר, אתם מדבר על המתודולוגיות של איך מנהלים תקיפה בצורה אוטומטית, לאו דווקא על המידע שיש בו . . . (אורי) לא, גם כאילו - ברגע שיודעים איזה תקיפות חקרתם, או איזה תקיפות אתם מסמלצים (Simulate), אז כאילו,פתאום יש המון מידע על איך לתקוף.(רן) זה כמו שלמי שמפתח וירוס, יותר קל לו אם יש לו את ה-Antivirus, אז זה יודע . . . (עומר) אז נכון. אנחנו לא מסמלצים תקיפות - אנחנו תוקפים, הלכה למעשה.אבל התשובה היא “כן” - אם הקוד שלנו לנו יגיע לידיים לא נכונות, יהיה נורא ברור איך אנחנו יכולים ועושים את מה שאנחנו עושים.07:06 מי תוקף ואיך לחשוב SaaS-ית(רן) אוקיי, אז הבנו בגדול מה החברה עושה. עכשיו בואו נדבר על המורכבות.אז למעשה, המוצר שלכם התחיל בתור מוצר On-premises, נכון? זאת אומרת, אנחנו נותנים ללקוח, הוא מריץ, או אולי אנשים מטעמכם מריצים, אבל על חומרה שלו, בתוך Data Center שלו. והנה הגיע הענן . . .(עומר) נכון.(רן) והחלטתם  אתם שגם אתם רוצים לעננים . . . (עומר) נכון. אז אני אנסה לעשות סדר, בצורה יחסית תכליתית.קודם כל - יש מגוון מרחבי-תקיפה.כשהחברה קמה, החלטה אסטרטגית - לתקוף מתוך הארגון, Pen-Test ל-Infrastructure.יש המון מרחבים - יש מרחב מחוץ לארגון, בתוך הארגון, יש Cloud, יש IoT, יש OT, יש המון עולמות . . . [הרבה על זה כאן - גיקונומי פרק #881 – יבגני דיברוב וארמיס].תחת ההנחה של Assume Breach - תניח שהתוקף בתוך הארגון שלך - אמרנו, המוצר שלנו צריך להיות מוצר On-premises.יש יתרונות, יש חסרונות - לא כל כך משנה עכשיו.אז זה המוצר הראשי שלנו.כשהחברה עברה את סבב-הגיוס השני שלה - באזור 2021 - החלטנו להרחיב את סט-היכולות, כדי להגדיל את ה-Business, לעשות Cross-Selling, Up-Selling וכו’.והחלטנו להנגיש את היכולות שלנו - פשוט מבחוץ.כלומר, ה-Use Case השתנה: במקום תקיפה מתוך הארגון, תקיפה מחוץ לארגון.כלומר, התוקף יושב בחוץ - ומנסה להתפרץ פנימה.(רן) ואלו אותן תקיפות, בגדול?(עומר) אז יש חפיפה גדולה מאוד בין התקיפות - אבל חלק מהעסק היה להמציא יכולות Cyber שלא קיימות, אני אוכל לתת קצת דוגמאות . . . למשל, כשאתה בתוך הארגון - אז אתה כבר בתוך הארגון. כל מה שאתה צריך זה Port בקיר.יש לך כתובת IP, נגיד, אתה עושה איזושהי שאילת את Broadcast, עונות לך מלא מכונות - ואתה אומר “אוקיי, זה ה-Context שלי”.זה שלב ראשון בתקיפה - אני רוצה להבין מי במשחק.מבחוץ, בואו ננסה לחשוב על זה - אני לא יכול לעשות Broadcast ל-0.0.0.0.0.0, אני אקבל את כל העולם . . . .אני צריך מודל אחר של להבין מה ה-Context שלי.אז פה, אני מחשיב את זה תקיפה, נכון? כי זה חלק מ”מעגל התקיפה”. היינו צריכים לבנות בכלל מודל Cyber חדש, של לנסות להבין, “אוקיי, מה ה-Asset-ים של הארגון?”אנחנו עובדים ב-Mode של Black Box, וכל מה שאני רוצה לדעת עליך כארגון זה את ה-Domain שלך, שזה Reversim.io [נגיד… reversim.com].מכאן אני מתחיל לשאול שאלות - מי כתב את ה-Domain? על שמי הוא רשום?  . . . (אורי) יש לנו את Reversim.io?(רן) אולי כדאי שיהיה לנו . . . (עומר) אז יש גם Use Case כזה . . . (רן) אנחנו עוד מבועת ה-Dotcom - אבל שלא יגנבו לנו ויכניסו לנו סוס טרויאני, אולי כדאי . . . (עומר) אז זה רגע השוני - ויש גם הרבה חפיפה.בסוף אם ננסה לתת פה איזשהו דימוי - “קליע Cyber”, כלומר Payload או איזושהי יכולת - לא משנה לה כל כך מי יורה אותה, אוקיי? העיקר שהיא פוגשת את המטרה שלה.אממה? כל “מכונת-הירייה” הזאת צריכה רגע להשתנות.אז (1) - שהחלטנו, עסקית, להציע עוד מוצר לתקיפה מבחוץ - זה מיד גוזר SaaS . . . אין דבר כזה - “תקיפה מבחוץ, ב-On-premises”.אז ההחלטה הייתה להקים מוצר Pentera - שה-Use Case הוא תקיפה מבחוץ.(רן) אתה עדיין יכול להריץ את זה על איזושהי חומרה שלך. זה לא בהכרח חייב לרוץ בענן, אבל אני מסכים - זה יותר הגיוני, זה יותר קל . . . (אורי) לא משנה, SaaS זה SaaS . . . (עומר) אנחנו סטארטאפ, כאילו זה...(רן) לא, ברור - פרקטית, זה יותר קל.(עומר) בדיוק. אוקיי, אז עכשיו, יש שני אתגרים גדולים שקורים בחברה.1 - פוקוס. בסדר? כלומר, הדבר הכי חשוב ל...(אורי) מה שקורה תמיד, שאתה נהיה Multi-Product, נכון?(עומר) בול. וזה גוזר עוד המון דברים. אפשר, אם יהיה זמן, להגיע אליהם - מבנה ארגוני, איך ה-Sales מקבלים את זה? מה האסטרטגיית Go-to-Market? עולם ומלואו.אבל בואו נסתכל ונתמקד רגע ב-R&D - אז פוקוס של ה-R&D.והדבר השני - שיש פה גישה בכלל חדשה - “לחשוב saaS-ית”.וננסה רגע לפרק את זה.אז הקמנו צוות - ממש קרענו את ה . . . בין שניים לשלושה מפתחים, בין שניים לשלושה חוקרים - ולי הייתה את  הזכות להוביל את זה.ואמרנו יעד, תאריך - ושם המוצר עולה ל-Production,ומכאן התחיל המסע.(רן) אז אנחנו מדברים על צוות של חמישה?(עומר) בסדר גודל . . . תוך כדי הצטרפו אחד-שניים, היינו אפילו בלי DevOps, QA . . .(רן) מה הקבועי-זמן, פחות או יותר?(עומר) היעד היה כשלושה רבעונים - ולרוץ.11:42 נצלול לטכנולוגיה - עולם אחר(רן) והבנתם איזה מוצר אתם רוצים לבנות? איזה Sub-Set של המוצר?(עומר) לגמרי כן, לגמרי כן.ועכשיו, בואו נצלול רגע לטכנולוגיה.(אורי) אז זה גם עולם . . . זה כאילו מוצר חדש - שפותר עולם בעיה חדש. זה לא, כאילו, תקיפה מבחוץ, זה שונה לגמרי מתקיפה מבפנים.(רן) כן, אבל רגע, אני חושב ששווה להדגיש כמה דברים לפני שאתה ממשיך. אחד, בעולם ה-Security, יכול להיות שיש אילוצים קצת שונים, כשאתה מפתח איזה שהוא SaaS. זאת אומרת, אתה לא רוצה “לתת לדרקון להשתולל בחוץ“, באינטרנט, בזמן שאולי On-premises זה קצת יותר קל להגביל אותו בחוץ. אז אתה צריך קצת יותר שליטה על זה.ושתיים, יכול להיות שיש טכנולוגיות, או יש Stack טכנולוגי, שפיתחתם - שעבד מעולה On-premises. לצורך העניין, לא יודע - Database-ים קטנים כאלה, שעכשיו פתאום צריך לשבור את הראש איך עושים לזה Scale רוחבי או whatever. כלומר, בונים איזה משהו “SaaS-י”.זה היה גם Scale אחר לגמרי של הבעיה?(עומר) עולם אחר. עולם אחר . . . ב-On-premises, אמנם אתה “בתוך קופסא”, אבל ה-Scale שלך הוא ה-N לקוחות שיש לך. אז יש N קופסאות, N לקוחות . . . .(רן) זאת אומרת, בתוך הארגון - יש לך אלף Node-ים אז יש לך אלף Node-ים, זה העולם שלך. באינטרנט . . . (עומר) יש עולם של Scale בתוך הארגון . . . אנחנו ממש עכשיו בתהליכים מאוד יפים.זה גם קורה - אבל זה שונה.למה? אם אנחנו מסתכלים רגע על המערכת שלנו, אז בואו נחלק, שבור אותה לשני Domain-ים מרכזיים.אחד - ה-Domain של מערכת-התקיפה - “מכונות הירייה”, כמו שקראתי להן, מה שמשנע את ה-Cyber.שזה קצת פחות אינטואיטיבי למי שלא בתוך החברה.והחלק היותר אינטואיטיבי, שזה ה-Domain השני - זה בעצם האפליקציה: המסך Login, ה-Inventory, ה-Report-ים, הנוטיפיקציות (Notifications), איך אני מנהל . . . בעצם, “מה שהלקוח נוגע בו”.(רן) אתה בעצם הופך מ-Single - ל-Multi-Tenant.(עומר) בול. וזה אחד האתגרים הראשונים.עכשיו, בואו ננסה לעשות חיבור בין סטארטאפ צעיר, שרץ מהר ו-On-premises - מה הסיכוי שהקוד שכתוב שם, יצליח...(אורי) יהיה רלוונטי בכלל . . . (עומר) ופה התחילו...(רן) זה מריח כמו Refactor גדול . . . (עומר) נכון, אז אוקיי . . . (אורי) או... לא יודע - זה נשמע לי כמו פשוט בנייה מחדש, כי זה עולם בעיה אחר.(רן) יפה, זה עוד דילמה, נכון? זה עוד דילמה - אם לבנות מחדש או להשתמש במה שקיים?(עומר) מדויק.אז בכוונה עשיתי את החלוקה הזאת לשני האזורים - כי אני אעבור ביניהם, וננסה להבין מה היה קצת יותר קל לעשות לו Adjustments, ומה היה הרבה יותר מאתגר.אז אם רגע נלך למרחב האפליקטיבי (Applicative), אז דברים כמו - רן, שאתה ציינתנגיד Single-Tenant לעומת Multi-Tenant: מעולם לא נכתב קוד שאמור לטפל ב-Multi-Tenancy של User-ים . . . זה נשמע כאילו פשוט, אבל רגע - לא. צריך לכתוב את זה From Scratch.(רן) זה משהו שקל לטעות בו, מניסיון . . .  אתה כותב, אתה מניח שרק אתה בחי ב-Database - ופתאום יש לך עוד לקוחות בתוך אותו Database, ואתה מתחיל לאבד רשומות . . . (עומר) נכון, אז זה משהו שהיינו ערים אליו, ועשינו מ-Day One.הדבר הבא זה שאתה צריך להחליף את כל ה-Infrastructure . . . עכשיו יש לך Ansible, שעושה לך Deployment למוצר On-premises . . . (אורי) אגב, זה לא מחויב המציאות שיהיה לך Multi-Tenancy. מה זה משנה אם אתה SaaS או לא SaaS? בסוף יש לקוח. כאילו, יש לפעמים שיטת Scaling שאומרת “בואו, לכל לקוח אני בונה Swimlane, אף אחד לא מפריע לאף אחד, ושוחים בנפרד”. זה לא בהכרח . . .  כאילו, לא מחייב להיות Multi-Tenant על כמה לקוחות, או על...(עומר) נכון, אז אני חושב ש...(אורי) זה לפעמים יותר יעיל במשאבים, אבל זה לא מחייב.(עומר) נכון, אני מסכים. זה ה-Mode פעולה שבחרנו פה, הוא עשה לנו שכל.ומעבר לאתגר הזה, היה לנו את האתגר של לשמור על “הלינגו” של המוצר.כלומר, בואו נחשוב על דברים מאוד טריוויאליים ללקוח - הממשק, איך נראים ה-Logo-ים, הצבעים, מפת התקיפה, הטבלאות . . . כל הדברים שלקוחות שלנו כבר ציפו לראות אותו דבר.אז מה עושים? שכפלים את הקוד? ברור שלא, נכון? אנחנו החלטנו ש...הייתה פה הזדמנות טובה לקחת איזשהו Monolith, שחי ב-On-premises - החלטנו לא לגעת בו, ופשוט לכתוב אותו מחדש.(רן) כן, כמו שאומרים אנשי המכירות ואנשי המוצר - “מה הבעיה? את הדבר הזה - פשוט תעשה שם”.(עומר) אני מת על זה, כן . . . (רן) . . .  “ זה כבר עובד! אז רק נשאר לך לפרוש את זה שם, וזהו”. [Tony Stark Was Able To Build This! In A Cave! With A Box Of Scraps…]  (עומר) “מה הבעיה? תגיעו לירח, ואז . . .”. כן.אז גם היינו צריכים לשמור על רכיבים גרפיים, על קומפוננטות (Components), על כל מיני דברים לוגיים שהיינו חייבים לשמור עליהם לטובת הלקוחות.אז פה יצאנו לאיזשהו מסע של Shared Components.החל מכמו שאמרתי, רכיבים גרפיים ועד ספריות בקוד.כלומר, איזושהי לוגיקה שצריכה לחיות גם ב-On-prem וגם פה.אוקיי, צריך להתחיל לעשות אבסטרקציה, ו”להוציא דברים למעלה”.16:55 ה-Stack הטכנולוגי(רן) איך נראה ה-Stack שלכם? הזכרת קצת Ansible - מה עוד קיים אצלכם?(עומר) כן, אז Ansible, אני רק אגיד, כבודו במקומו מונח.אנחנו בדיוק בתהליכים - בגלל ה-Scale שלנו, המערכת היא כבר גדולה - אנחנו עושים פרויקט מדהים של לשכתב הכל מחדש, ולכתוב ולהיפטר מ-Ansible, עוברים ל-Python.אז יש Python, יש Java, יש DocumentDB.יש לנו המון שפות Low Level שקשורות ל-Cyber, ו-Stack-ניטור . . . כל מיני דברים נחמדים כאלו.(רן) וב-Front עצמו - React?(עומר) אז React, כן.אחלה, אז עכשיו - אנחנו לא יכולנו לקחת את כל האופן שבו דיפלטנו (Deployed) את המערכת ב-On-Premises.יש פה עכשיו Infrastructure-as-Code From Scratch - עוד איזשהו אתגר.אני חושב ששם, הדבר שראינו זה שהיה לנו נכון לדפלט (Deploy) את כל ה-Service-ים החדשים שבנינו כמה שיותר מהר.במקום להתחיל לעשות איזושהי Over-הנדסה, ואז לראות איפה צווארי-הבקבוק.מדברים על זה הרבה, אני חושב שידענו להפריד מה מראש צריך Scale - כמו נגיד Stack-ים של תקיפה,  שצריכים לקום פר-דרישה של לקוח (On-demand), או חישובים כבדים, כמו Reports וחישובי Inventory למיניהם.אז אלה הדברים שידענו מראש שאנחנו רוצים להתחיל מההתחלה כסוג של Service-ים בפני עצמם.אבל רצנו מהר קדימה עם איזשהו Monolithמתוך ידיעה שאנחנו נשקיע מאוד באיך שה-Monolith בנוי - DAL-ים, DAO Services, DTOs . . . ממש הכל מאוד מאוד Decoupled בקוד.זה היה מאוד מאתגר, אבל נכנסנו לזה בידיעה - כדי שכשיגיע היום, יהיה לנו ונוכל לבנות ולדפלט (Deploy) מחדש את ה-Service-ים כמו שצריך, ו . . . (אורי) “ונשבור את ה-Monolith!”(עומר) בדיוק. אנחנו שלוש שנים לתוך התהליך הזה, ואני יכול להגיד - לא נשברו הרבה Service-ים.זה לא מפתיע אותי, אבל יש שניים-שלושה Service-ים שהוצאנו מה-Monolith.אז אנחנו מתנהלים ב-Mono-Repo החדש הזה, שהחלטנו ללכת עליו . . . (אורי) מה גודל הצוות היום, שעובד?(עומר) כמעט שישה מפתחים . . .(אורי) אני חייב להגיד לך משהו - לפעמים, השבירה ל-Service-ים היא פונקציה של גודל הצוות, ולא של גודל העומס או דברים כאלה. אתה במקום סביר לגמרי . . . (עומר) כן, שמח לשמוע.כן, היה חשוב לנו מאוד לא לבוא עם איזשהו פתרון - ואז להתחיל לחפש לו בעיהאלא ממש רגע להתקל בבעיה, ו . . . יש אתגר אחר, שאומר “אוקיי, אתה אמנם רוצה לצאת עם MVP - אבל . . .”זו בעיה שוב מעולם ה-Business של “האם הארגון יכול לקבל MVP בכלל?”כי הארגון באיזשהו מקום אחר: יש איזשהו מוצר ראשי, קדימה - מצפים ממך להרבהאבל זה לא כזה משנה, אתה יכול לסמלץ (Simulate) - עליתי לProduction, יש לקוחות, עכשיו אני מתחיל ללכת על זה.(רן) כלומר, יש לך מוצר קיים, אתה רוצה לעשות ללקוח Up-Sell ל-Feature נוסף - הוא יצפה לאותה איכות. אתה לא יכול לתת לו משהו . . . (עומר) בדיוק. הוא לא סלחן, זה לא מעניין אותו שיש קונספטים של פיתוח שקוראים להם “MVP” . . . (אורי) אבל מן הסתם התחלתם עם סט פיצ'רים מסוים, ואחר כך היו הרבה פיצ'רים שאמרתם “את זה נשאיר לאחר כך”, נכון? לאחרי העלייה.(עומר) חד משמעית, חד משמעית. את הדברים הממש . . .  ה-Flow-ים “הרגילים”, של User Login וניהול של ה-Inventory, ו-Dashboard-ים, ו-Report-ים.עכשיו אנחנו כל פעם מוסיפים קצת, חותכים מה שצריך.אבל כן, זה הסיפור.20:42 אספקטים של Pen-Testing במעבר לענן  / “ברוך הבא לעולם ה-SaaS”(רן) בהקשר הזה - של לייצר פיצ'רים חדשים, אבל גם להיות רזה - אז אולי שווה להזכיר מתודולוגיה, שאני חושב שקיימת  ב-AWS, יתקנו אותי אנשים שמכירים, של אחד, קודם כל, מוציאים PR או כותבים את ה-PR בסוג של PRD. כלומר,  אנחנו יודעים מה אנחנו רוצים לשחרר, ואז דואגים לשני פיצ'רים חשובים: אחד - Security ושתיים - Scale. כל השאר יבוא אחר כך.זאת אומרת, מבחינת פיצ'רים מוצריים, מתחילים בחסר, אוקיי? זה ברור. ישנם דברים שכן צריך לדאוג להם - שזה יכולת לעשות Scaling ויכולת לעשות שהדברים האלה יהיו Secure.ובהקשר הזה, רציתי לשאול, זאת אומרת - יש לא מעט אתגרים, בעולם תוכנה גנרי, של לעבור מ-On-premises לענן.אבל איזה אתגרים מיוחדים מצאתם בעולם של ה-Cyber Security, וספציפית בעולם של Pen-Testing? כלומר, מדובר פה על אחריות כבדה, אוקיי? אתם נותנים “מכונות ירייה” לאנשים, אתם רוצים לדעת שאתם נותנים את זה לאנשים הנכונים, ושהם עושים בהם שימוש נכון. שאם הם פוגעים במישהו, אז הם יפגעו בעצמם, שהם לא יפגעו באחרים. לצורך העניין, מה מונע מחברה מסוימת לבוא ולתקוף - אפילו בטעות - אבל לבוא ולתקוף חברה אחרת?וזהו, איזה אספקטים מעניינים מבחינת Pen-Testing, גיליתם במעבר לענן?(עומר) מעניין מאוד . . . אני חושב שקודם כל, זה מדויק מה שאמרת - ברגע שאתה נותן כלי תקיפה, ושם אותו בידיים לא נכונות, זה פשוט לא לוקח.המגבלות בענן הן קצת . . .  By-Design, האינטרנט הוא קצת יותר מגביל במה שאתה יכול לעשות.לדוגמה, אין לך גישת Layer-2, בסדר? אז זו שכבה שתוקפים “אוהבים לשרוץ בה”, אז צריך לוותר על זה.אז עכשיו אתה נגיד צריך לעבוד בשכבת ה-TCP - ה-Cloud Vendors לא מאפשרים לך לעשות את דברים שהם לא שם.זה אתגר ראשון. כלומר, אתה צריך לוותר על הרבה מהתקיפות שלך.אתגר שני, שלטעמי היה המשמעותי ביותר, זה איך לבנות את המודל שאותו אתה תוקף.כשאני אומר “מודל”, זה בעצם “את הלקוח”.אמרנו, אם זו רשת ארגונית - אתה רק פותח עיניים: “אוקיי, אני מתוך הרשת, הכל במשחק”.פה אני בחוץ - ועכשיו אני צריך להבין מה שייך ללקוח שלי.הלקוח לא יכול לכוון את הכלי לאן שהוא רוצה - הוא לא יכול להגיד “רוץ לכתובת IP כזו” או “רוץ לכתובת  או ל-Domain ספציפי”.היינו צריכים לבנות איזשהו אלגוריתם שבונה את המודל.(רן) “הוא לא יכול” - כי זה לא נכון לכם מוצרית, או כי אתם רוצים בכוונה להגיד . . . ?(עומר) הוא לא יכול כי אין לו שליטה, אין לו שליטה על זה.המודל נבנה בצורה אוטומטית על ידינו, סוג של איטרציות (Iterations) של שאלות כאלה.(רן) אז אמרת נגיד קודם - הולכים נגיד ל-DNS, בודקים על שם מי זה רשום, מחפשים עוד כאלה . . . (עומר) נכון, אז בואו נפתח את זה קצת - אז נגיד על שם מי זה רשום? אולי הוא רשם עוד Domain-ים? מצוין.עכשיו, נתחיל לעשות אינומרציות (Enumerations )של ה-Sub-Domains - אני אגלה שיש לך את App [.app] נקודה, את Dev נקודה, את Staging נקודה, את Prod נקודה, whatever . . .  מעולה.אז עכשיו העשרתי את ה-Database שלי.אחרי שיש לי Sub-Domains, השלב הבא - אני מתקדם לריזלוב (Resolve) של כתובות IP.יפה, אז עכשיו יש לי כתובות IP, מעולה.(רן) אז אתה מחפש מה הבלוקים . . . (עומר) ועכשיו רואה אם הוא רשם את זה - ועכשיו אני יכול להצליב את השם שלך, ואת הכתובות IP של ה-Sub-Domain-ים שלך.אני יכול רגע לראות איזה Network Blocks  רשמת - ועכשיו אני יכול לסרוק את ה-Network Blocks.אז עכשיו, על כל כתובת IP, אני יכול גם לעשות סריקת Service-ים - איזה VPN-ים רצים, איזה Website-ים יש לך . . . מעולה.יש עוד מימד שלם של Identities - אנחנו יודעים גם, בחלק מהמודולים שאנחנו מציעים, זה להבין האם הייתה לך איזושהי דליפה בארגון.ואנחנו יודעים להביא אולי סיסמאות או מידע רגיש שהגיע.מה שעשיתי עכשיו - יריתי פה המון Atrifact-ים, המון Asset-ים שיש בארגון.אבל עכשיו צריך להבין . . .  אוקיי, אז רזלבתי (Resolve) כתובת IP - אבל אולי היא של AWS? מאיפה אני יודע אם זה Owned by You או לא?אז פה נכנס כל האלגוריתם של להבין מה שייך לך ומה לא.קראנו לזה Confidence - אני נותן ציון לכל Asset, ולפי איזשהו Threshold מסוים אני יודע להגיד האם הוא שייך לך או לא.כלומר, אוי ואבוי אם אני אתקוף כתובת IP, שהיא לא שייכת לך . . . . או ה-Website שהוא לא שייך לך.אגב, ה-Cloud Providers מגבילים אותךאתה יכול לעשות Pen-Testing - אבל בהסכמה, וב-TCP, בסדר?כלומר, מאוד קל לעשות שטויות . . . איפה שהמנגנון לא בטוח . . . (רן)  דרך אגב, מה הם נותנים לך? לתקוף את מי שהם מארחים ב-TCP? או שכשאתה כשאתה נמצא אצלהם, מותר לך לתקוף אחרים, רק ב-TCP?(עומר) אופציה ראשונה . . . (רן) אוקיי.(עומר) אתה יכול לתקוף את עצמך.(רן) כלומר, לצורך העניין, הלקוח יכול להיות בכל מקום - על ענן כלשהו או לא. אבל אתה כנראה Deployed, נניח  ב-AWS, אז זה כבר שם עליך איזה שהם מגבלות.(עומר) נכון.(אורי) רגע, הרמת לי ל... (רן) אורי אוהב את זה . . . (אורי) לא, לא, לא . . . מן הסתם, ה-Cloud Providers - אחד הדברים שהם לא אוהבים זה שתוקפים משתמשים בתשתית שלהם כדי לתקוף. זה לא אתי, זה לא טוב, לא יפה וכו’. אבל אתה מתחזה לתוקף . . . (עומר) נכון, אני תוקף. זה ה-Business שלי. אני...(אורי) לא, אבל השאלה היא האם הייתם צריכים לדבר - אני לא יודע על איזה ענן אתם מתארחים, So-called *AWS  - לדבר איתם ישירות, ולהגיד “זה ה-Business שלנו, שתדעו. זה מה שאנחנו עושים”.(עומר) נכון, אז זו בדיוק הנקודה. יש Pen-Testing Policy לכל אחד מה-Vendor-ים האלה, ואתה חייב לעשות את זה בשיתוף פעולה. זה לגיטימי.תחשוב, עזוב - בוא נוציא אותי מהמשוואה ואת הסיפור פה מהמשוואה. תחשוב . . . (אורי) אתה כנראה לא ה-Pen-Tester היחיד . . . (עומר) בדיוק. אתה רוצה לעשות Pen-Test לעצמך - פשוט תפעל לפי ה-Policy.זה האירוע הפחות מאתגר, בסדר?האירוע יותר מאתגר זה איך אתה לא מבדר את התקיפה לאזורים שהם לא של הלקוח.אז גם פה, עכשיו, היינו צריכים לקחת את כל הרכיבים האלה - ולא הגיוני להגיד ללקוח “חכה, מתישהו המערכת תגיע לשם”.היא לא נכתבה ככה בכלל, היא ל-On-prem - זה שלך, תשתמש בזה כמה שאתה רוצה ב-On-premises.פה, עכשיו, אנחנו צריכים לחשוב על Scale-up.(אורי) לא, אבל זה לא אותו מוצר בכלל . . . (עומר) אז אני חוזר לשני ה-Domain-ים - כל מערכת התקיפה היא בדיוק אותה מוצר.לא משנה לה איזה לוגיקה היא מריצה בפנים - אבל היא צריכה עכשיו לדעת לעשות Scale.ופה, זה היה החלק שהיה יותר קל לנו - לקחת Container-ים, לארוז אותם לסוג של Cluster כזה.ולפי דרישת הלקוח - סוג התקיפה שהוא רוצה, יש מגוון סוגים של תקיפות שאנחנו מציעים - אנחנו יודעים להעלות לו את ה-Cluster הרלוונטי, לשם תכלית ספציפית.מתבצעת עבודה, יורד - הולך הביתה. בסדר?כאן בעצם ה-Scale-Out הוא . . . תיאורטית הוא אינסופי.כמובן שאתה נתקל בכל מיני מגבלות, של Service Quota והרבה דברים.זה גם לוקח אותי לנקודה, שבה אני חושב...(אורי) . . . סליחה, זה גם Load מאוד מאוד משתנה, נכון?(עומר) Load מאוד משתנה. יש הרבה Compute והרבה Memory בתקיפה, אין ספק. משמעותי מאוד.(אורי) לא, אבל זה עולה, זה יורד, אין לזה שעות קבועות, אין לזה זמנים קבועים . . . (עומר) נכון, ובהגדרה - אני לא יכול להחזיק את כל ה-Stack הזה באוויר כל הזמן.ואז זה לימד אותנו עוד מימד, שאני ממליץ לכל מי שעושה את המעבר הזה, שרגע צריך לחשוב על זה - עלויות.זה נשמע גם טריוויאלי, אבל אתה צריך איזשהו Cost Strategy, שאין לך ב-On-prem - כי אתה לא משלם על “הברזלים”.פה זה כבר אירוע אחר.(אורי) ב-On-prem של הלקוח, הלקוח משלם על ה...(עומר) חשמל, Memory, CPU . . . . פה זה עלויות שלך.זה משהו גדול, בסדר?(אורי) ספר לנו על זה . . . (עומר) כן, אז אני אומר אתם מודעים לזה. מהחוויה של רגע לחשוב על הדבר הזה . . . .(רן) כן, בחברה שבה אף אחד לא הבין Cost, פתאום יש חמישה מפתחים שכבר צריכים להבין Cost - ומחרתיים זהו עשרים מפתחים שצריכים להבין Cost . . . (עומר) זה המקרה הטוב . . . המקרה הרע הזה שיש לך טעות Cost, שיש “תאונת Cost” - וזה משהו שהוא קריטי בסטארטאפ צעיר, שלא יכול להרשות לעצמו תאונה כזו.אז בעולם שאין בו מגבלות תקציביות וכסף, פתאום זה משהו לחשוב עליו.עולם נוסף שנפתח כשאתה עושה את המעבר הזה, זה כל העולם של Monitoring ו-Security באופן כללי.פתאום אתה רואה, זה נהדר - אתה יכול לראות את ה-Service-ים שלך, אתה יכול לנטר אותם.זה כמובן משפיע מאוד על הפיתוח.עכשיו אוקיי ברור - זה היתרונות של SaaS - אבל זה עוד Effort שצריך לשים, כחלק מהזמן.אתה לא יכול להיות “עיוור” - אתה יודע, אתה מעלה איזושהי מערכת ו”טוב, מה קורה איתה?”.זה לא עובד.(רן) כן, אז זאת אומרת, מה - ב-On-premises לא הייתה לכם גישה?(עומר) אין גישה, נכון, אין גישה . . . (אורי) זה פשוט אצל הלקוח . . . (רן) כן, אני מבין - אבל עדיין, אין לך “כניסת שירות”? זאת אומרת . . .(עומר) אז תראה, יש דברים מאוד, שהם תחת Legal מאוד נוקשה . . . ואין לך Log  . . . אין לך Log-ים נגישים - אתה לא יכול לזהות אנומליות, אתה לא רואה, אין לך ניטורים . . . אין לך EPM על המערכת.והדבר הכי טוב שאתה יכול לעשות זה לסמלץ (Simulate) אצלך את הלקוח.אבל זה לא באמת מספיק, כי כמות הסביבות שאתה נפגש בהן ב-On-prem, היא אינסופית, ממש אין סופית . . .(רן) “זה עבד אצלי על המחשב” . .. (עומר) בדיוק.(רן) כן, זאת אומרת - זה למעשה גם נותן לכם הזדמנויות, של ניטור לצורך העניין, ויכולת לעשות, אולי, Cost Saving - כשלפני זה אולי לא היה Cost, אבל פה אתם פתאום צריכים לחשוב על זה.אז באמת, ה-Traffic שלכם הוא כזה Spikey? זאת אומרת, נגיד, פעם 12 בלילה - עולים אלף, עושים את העבודה  שלהם ויורדים?(עומר) כן. זה ממש ככה.(רן) אז זה דורש לבנות אורקסטרציה (Orchestration).(אורי) ויותר מזה - יכול להיות שגם הרבה מזה הוא לא חזוי מראש, נכון?(עומר) נכון. אז כמו כל דבר שכותבים - צריך איזושהי מגבלה, אתה לא יכול לתת למשהו להיות לא מוגבל.לשמחתנו, אנחנו - כמובן שהתחככנו במגבלות, אבל אלו היו מגבלות “מטופשות”, של דברים שאתה לא חושב עליהם.כי גם אחת החוויות שאני באופן אישי ממש שמחתי עליה, זו איזושהי חווייה של שחרור צווארי-בקבוק.אתה פתאום עולה לעולם, כשאתה לא בתוך קופסא - אתה פשוט משחרר פה איזה מערכת.עכשיו, זה מדהים לראות באיזה צווארי-בקבוק אתה נתקל.אתה אומר “טוב, מה אחד? מאה!” . . . אין לי בעיה שלם על זה.אבל זה לא כזה פשוט - כי אז אתה רואה שיש לך איזו פונקציה, שהיא פשוט לא כתובה לזה.ואז אתה חייב לעשות Profiling, ולנסות לזהות את צווארי-הבקבוק.ואתה מגיע למגבלות שהן לא פיזיות בכלל - הן פשוט שהקוד כתוב בצורה, שמעולם לא “התחכחה עם Scale כזה”.(אורי) זה פשוט “ברוך הבא לעולם ה-SaaS”   . . .  .(עומר) ממש ככה, זה... אני אומר - זו חוויה מאוד מאוד נעימה וטובה. וצריך לקחת את הדברים האלה בחשבון - כי זה לוקח זמן.פתאום יש לך איזשהו תהליך מרכזי, בתוך המערכת, אבל אתה אומר “טוב, עכשיו אני נתקע עליו?”וזה גוזר, מהר מאוד, השפעה על ה-Roadmap קדימה, ואיזה דברים חייבים להתעסק בהם.(רן) כן. כמו שנאמר - “יש במדעי-המחשב רק שלושה גדלים: אפס, אחת, והמון”. [חשבתם לגייס  Gully Dwarves ?](עומר) בדיוק.32:15 יש עוד מימדים(רן) כן, אז אנחנו ככה ממש לקראת הסוף. אנחנו נגענו בכמה נושאים, אנחנו לא נגענו בהכל. אבל אנחנו דיברנו  בעיקר על איך לוקחים מוצר שהוא On-premises בתחום של Pen-Testing - והופכים אותו, או חלקו, או אולי בונים מוצר דומה, במעבר לענן.חלק מהדברים שתיארת הם גנריים, במעבר לענן - או דרך, אגב, גם מעבר הפוך, גם את זה עושים - והלקחים הם רלוונטיים: אם זה שיתוף קוד, אם זה לקחת צוות ואמרת “לקרוע” אותו, לשלוף משם אנשים באמצע ולבנות צוותים חדשים. אבל חלק כן רלוונטיים גם ספציפית בתחום של Pen-Test. אבל . . .(אורי) אני - רק לרפרר (Reference) לפרק אחר שעשינו עם נתי, על “ה-Trillion Dollar Paradox” [זה - 421 The Cost of Cloud, a Trillion Dollar Paradox with Martin Casado], שגם מדבר - המאמר הזה מדבר על המעבר של חברות מ-On-premises אצל הלקוח ל-SaaS: מה זה אומר בכלל על זה, אבל גם מה זה אומר על עולם  העלויות, שנגעת בו.(עומר) כן, אני חושב שיש עוד מימדים באמת מאוד מורכבים, כמו שנגענו בהם - מה זה אומר על החברה? מה זה אומר על מבנה ארגוני בכלל? האם המבנה ארגוני הוא תוצר של הארכיטקטורה, או להפך? . . . אז אני אומר . . . (אורי) אה, זה תמיד יקרה ככה . . . תמיד תיהיה הלימה - זה חוק Conway.(עומר) אז אנחנו היינו מודעים לחוק Conway.אז קודם כל אמרנו “טוב, צוותים פר-מוצר”, אבל אז אמרנו “טוב, זה צריך להיות צוותים פר-Domain” . . .מכונת התקיפה יכולה לרוץ או ב-On-premises, או ב-SaaS - זה לא משנה לה.אז כן, אז זה. עלויות - דיברנו. על פיתוח . . . (רן) אז כיום צוות הוא או Cloud או On-prem? או שיש גם צוותים שמעורבים?(עומר) לא, אז כיום כולם משויכים למערכת שלהם.המערכת יכולה להיות או ב-On-premises, או ב-SaaS - ואז זה גם, תחשבו על ה...(רן) ובתוך הצוות יש בנאדם של On-prem ובנאדם של SaaS, או גם וגם?(עומר) לא - גם וגם. כולם יודעים הכל, וזה גם מאוד מפתח אנשים לחשוב בצורות חשיבה שונות.34:25 הסוף / אני לא מאמין שאני גר בפתח-תקווה(רן) אוקיי. בסדר. אז כמו שרפררנו (Reference), אנחנו לקראת הסוף. עוד כמה מילים אולי על החברה - אמרת שאתם שאתם סדר-גודל של כ-50 מפתחים?(עומר) יש כ-50 מפתחים - מפתחים, מפתחות, DevOps, QA . . .אנחנו כמובן מגייסים . . . (רן) איפה אתם?(עומר) יושבים בפתח תקווה, מעל תחנת רכבת קלה.בתור תל אביבי, אני אגיד שזה לא כזה נורא . . .אז בהחלט החברה גדלה, האתגרים...(אורי) זה לא נורא להיות תל אביבי, או לא נורא ל...(רן) לא לא - זה אחלה לוגו . . .(עומר) נשאיר את זה כסימן שאלה - שכל אחד ייקח את זה למקום שיעבוד לו . . . (רן) אני חשבתי על סלוגן לפתח-תקווה - “פתח-תקווה:  זה לא כל כך נורא” . . .  סליחה.(עומר) יצאו דברים יפים מפתח תקווה, נגיד את זה רגע לדיסקליימר. [חוץ מבר-זיק?]אז כן - החברה מגייסת לצוותי פיתוח: Backend, Frontend, DevOps, QA.יש גם תפקידים אחרים, כמובן.וגדלים.המון אתגרים, כי יש יותר משני מוצרים בחברה - ומעל אלף לקוחות כבר.(רן) צריך ניסיון כ-Pen-Tester? כאיש Security?(עומר) אז תלוי לאן אתה מגיע - לצוות המחקר, שגם אליו מגייסים, אתה צריך להיות Top-Notch ב-Cyber.כי אנחנו עושים הכל From Scratch.צריך גם לחקור-לאחור, גם לפתח לקדימה.ובעולמות של הפיתוח - אז נתנו פה קצת טעימה: ה-Stack מגוון, עם אתגרי On-prem, אתגרי SaaS, ועוד הרבה דברים טובים לשנה הקרובה, שאמורים להגיע.שיהיה המון בהצלחה, עם כל ה-SaaS הזה!בהצלחה. ותודה רבה שבאת. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 485 של רברס עם פלטפורמה, שהוקלט ב-27 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור ביום גשום וקר אורח שהגיע עם שורטס וסנדלי-שורש: אולי פרק 500 יהיה כבר כולו מג’ונרט, אבל בינתיים, יאיר ליפשיץ בא לשיחה על (וב) Ivrit.ai. (אורי) תגיד, רן - 485? אנחנו מתקרבים לפרק 500 . . . אולי נעשה עם משהו מיוחד לפרק 500?(רן) אה, יש לי רעיון. שומע? אולי נעשה פרק שכולו מג'ונרט (Generated) ואנחנו לא נדבר, ובעצם יהיו Avatar-ים שידברו בשמנו . . . מה אתה אומר - יעבוד?(אורי) האמת, טוב פרק אחד הפסקה - אבל נראה לך שזה אפשרי, בעברית?(רן) האמת, שמעתי  . . . אתה יודע, יש לא מעט כאלה שעושים את זה באנגלית, נגיד NotebookLM ואחרים, שיודעים לעשות את זה כבר מאוד יפה, באנגלית . . . (אורי) מייתרים אותנו, רן. מייתרים אותנו . . . (רן) אלא - שלנו יש את היתרון של עברית!(אורי) כן . . . (רן) אוקיי וזה היה הרמז - אם לא ניחשתם עד עתה . . .אז אני מניח שללא מעט מכם יצא לכם להכיר מנועי-שפה ולהכיר בכלל תוכן וכלים, שיודעים לעבוד לא רע בשפות זרות  - כנעניות וכו’.אבל בעברית, תמיד היה איזשהו Deficit - סליחה על המושג . . . . ואת המחסור הזה יאיר בא לתקן.01:47 יאיר(רן) אז יאיר - שוב ברוך הבא, וסליחה על ה-Intro הארוך, אבל היום אנחנו הולכים לדבר על פרויקט קהילתי, שאתה בין המובילים שלו. פרויקט מאוד חשוב ומאוד מאוד מעניין שנקרא Ivrit. פשוט ככה, כמו ששומעים - ככה כותבים. [כמו שאיתמר בן אב”י התכוון לכתוב עברית]הפרויקט הזה שם למטרה שלו לאסוף חומר בעברי , על מנת שהאלגוריתמים יוכלו להתאמן עליו - ועל זה תספר לנו בהמשך.אז ספר לנו קצת עליך, ואז נתחיל לדבר על Ivrit . . .(יאיר) מעולה. קודם כל - הכל נכון. אני חושב שברור מאליו ששום דבר ממה שעשינו לא עובד.נספר על זה עוד מעט . . .לגבי - עבדתי הרבה שנים באינטל, בהתחלה בתור מפתח, אחר כך בתור ראש-צוות.ב-2015 עברתי לסטארטאפ שנמצא כאן, בקיסריה.מתעסק בצ'יפים (Chips) - Leaba Semiconductor, עושים Chip-ים לרשתות.הגעתי שם לנהל את אחד מצוותי התוכנה.עבדתי שם חמש שנים וקצת, כלומר - הגעתי בתור אחד החבר’ה הראשונים, לעשות ארכיטקטורה של הצד של התוכנה [תזמון קוסמי לפרק הקודם - 484 Architect WTF with Shai Yallin and Ron Klein]תוכנה-לחומרה זה תמיד סוג קצת שונה ויש לו את את האתגרים שלו.כשעזבתי שם, כבר ניהלתי חלק די גדול מהארגון הזה - 40 ומשהו איש, ועוד חבר’ה בחו”ל.וזהו, בתחילת 2020 הייתה הקורונה - אשתי הייתה עוד בלימודים שלה, היה זמן מעולה להפסיק לעבוד בכלל . . . ישבתי עם הילדות בבית, וכל פעם ששמעתי אנשים מתלוננים על זה ש”היום מישהו צריך להישאר עם הילדים”, אמרתי “הכל טוב, אני גם ככה בבית, לא אכפת לי מכלום” . . . .וזהו - ומאז אני עושה בעיקר פרויקטים שלא למטרות רווח.כן עושה הנדסה, כן עובד בתור יועץ - אבל חלק די גדול מהזמן שלי הולך לכל מיני סוגים של Non-Profit.חלק מהם לא טכנולוגיים - Ivrit.ai זה כן פרויקט טכנולוגי, שאנחנו עובדים עליו מ . . . חושב שאמצע 2023, משהו כזה, שנה-וקצת.03:55 על Ivrit.ai (רן) אוקיי, אז Ivrit.ai - גגלו את זה, חפשו את זה או שפשוט תקלידו - אז מה זה Ivrit? מה עושים שם?(יאיר) כשהתחלנו . . . (אורי) עברית זו שפה, לא שפת-תכנות . . . שמית.(רן) . . . יש הטוענים כך . . .(יאיר) כשהתחלנו - לפני שנה וקצת, נגיד סוף מאי 2023 - ChatGPT התחיל לתפוס תאוצה.שיחקתי איתו, אמרתי “וואו, זה עובד מדהים!”יש להם מנוע שנקרא Whisper, שעושה בעצם Speech-to-Text, גם עובד מדהים.[וגם מייצר את התמלול הראשוני לפרקים האלה, בערך מאז…]אשתי רופאה, אז אמרתי “טוב, איך נחבר את זה אליה?”שבעצם, ה-AI כבר ייתן המלצות, שהוא יעשה חלק מהעבודה . . . ודי מהר התברר שהפער הכי גדול הוא שהכל עובד אחלה - עד שאתה מגיע לעברית . . . זאת אומרת, גם לפני שנה וחצי, להגיד ל-GPT4 “אדוני, הנה Audio - תבין מה . . . “ל-Whisper - “תבין מה אמרו”, ואחר כך - ל-GPT4 - “בוא, תן המלצות”“תן המלצות לאיך לטפל בבן אדם הזה, תסכם את המבחן שהכל . . .”והוא עושה, הוא יודע לעשות את העבודה - עם קצת הנחיות, עושה עבודה מעולה.אבל ברגע שאתה רוצה - “רגע,  אני רוצה להפעיל את זה בארץ!”ויש לנו אינטרס-מובנה שדברים יעבדו כמו שצריךאז הדברים עובדים פחות טוב . . . לפני שנה וחצי, התחושה שלנו הייתה-שמודלי שפה כמו ChatGPT יצליחו לסגור את הפער בעברית לבד.לעומת זאת, תמלול - כל הקטע של גם דיבור אל המודל וגם זה שהמודל ידבר אליך בחזרהגם ג’ינרוט (Generation )של קול וגם תמלולזו בעיה שהיא מאוד שונה . . . צריך דוברי-עברית כדי לעבוד עליה - אי אפשר לקחת עכשיו מהנדס באיזושהי גיאוגרפיה אחרת ולהגיד לו “טוב, בוא תעשה Scraping לכל האתרים בעברית” ולעבוד עליה.אם אתה לא דובר את השפה - לא תוכל לתייג עכשיו . . . לא תוכל לקחת, לדוגמא, את הפודקאסט שלנו ולתמלל אותו [שלום…](רן) כלומר, רגע למה צריך תמלול? [רגע, מה? . . . ] - זאת אומרת, למה לא פשוט את האודיו?(יאיר) האודיו זה בעצם ערוץ שמעביר הרבה מידע בזמן קצר [ד”ש למאזינינו ב x2.5].רוב האנשים מדברים הרבה יותר מהר ממה שהם מתקתקים.אז זה הרבה יותר יעיל - ויש המון אנשים שלא ישבו לתקתק במחשב . . .  אפילו אני היום, כשאני עובד עם ChatGPT . . . (רן)  לא, לא, סליחה. השאלה שלי טכנית - למה אתה צריך את האודיו  וגם את התמלול שלו? למה לא מספיק את האודיו, לצורך למידת-מכונה?(יאיר) אז יש סוגים, ש דרכים שונות ללמוד איך לעשות Speech-To-Text.אחת הדרכים האלה נקראת Unsupervised Learning - זאת אומרת, אני לוקח אודיו, בלי טקסט שמצורף אליו, ומנסה לבנות מעל זה מודל שיתמלל, או שיעשה רוב עבודת-התמלול.לדוגמא, אתה יכול - המנוע יכול - בצורה כזו לזהות סוגי-דיבור דומים, לעשות Clustering למילים . . .ובסוף, אתה לוקח עוד קצת תוכן - ואותו אתה מתמלל ידנית.אז בעצם אתה עובד בכמה שלביםיש לדוגמה מנוע של Facebook, של Meta, שנקרא Wav2vec - שזה מה שהוא עושה.המוצר שאנחנו מכירים - או המנוע שאנחנו מכירים שעובד הכי טוב - נקרא Whisperמנוע של OpenAI - באנגלית, עושה עבודה מדהימה.כשאני מדבר איתו, אני אפילו לא בודק האם הוא תמלל אותי נכון או לא - אני פשוט אומר לו “שלח את השאלה”, עובד מעולה. והוא עובד בצורה שנקראית Weakly Supervised.הם אומרים “תן לנו Data מתומלל” - כלומר, גם את האודיו וגם את התמלול - “אנחנו יודעים שחלק ממנו יהיה זבל - וזה בסדר” . . .נעשה מיצוע על מספיק Content, זה יהיה בסדר.אז אנחנו בעצם רצינו לייצר . . . אמרנו, אנחנו רוצים לפתור חלק אחד ספציפי - נייצר Data-set כזה, מתוך הבנה שלהרבה חברות אין מוטיבציה גדולה ללכת לטפל עכשיו בעברית.אבל אם “תדחף להם את ה-Data” - עם רישיון מתאים ובחינם - הם ייקחו אותו, לא אכפת להם . . .הם פשוט לא רוצים לבזבז על זה זמן או כסף בעצמם.(רן) אז ההבדל בין, נגיד, מנועי-שפה לבין מנוע-תמלול כזה, זה שמנועי-שפה יכולים להתאמן בשיטה שהיא Self-Supervised - כלומר, להסתכל על הררים של טקסט ומדי פעם להחביא מילה ולנחש את המילה הבאה וכל זה, והם לא צריכים הרבה Data מתויג - הם צריכים Data “בסדר”. הם צריכים Data נקי, יחסית. זאת אומרת, אם תזרוק לוג'יבריש אז זה לא יעזור לו, אבל כל עוד ה-Data הוא באנגלית - וויקיפידיה וכאלה - הם סבבה עם זה. אבל במנועי-תמלול, אתה אומר שצריך את ה... זאת אומרת, לפחות בשיטה שהזכרת, צריך את המיפוי הזה - ביןה-Audio-stream לבין התמלול שלו - וככה אתה יכול לייצר בעצם למידה ברמה הכי גבוהה.(אורי) תגיד, גרמנית וצרפתית וספרדית - עובדות טוב?(יאיר) עובדות טוב, כן.זאת אומרת, אני לא רוצה להגיד שהן עובדות ברמה של האנגלית . . . רק כדי לתת איזושהי תחושה למספרים - Whisper עצמו, כש-OpenAI שחררו אותו, הם שחררו גם מאמר ליד.והוא פתוח לגמרי, ה-License שלו פתוח לגמרי - אתה יכול לעשות לו מה שאתה רוצה.אז כש-OpenAI שחררו אותו, שחררו גם מאמר איתו - ויש שם טבלה, שאומרת כמה שעות-תוכן הכניסו מכל שפה.מאנגלית, אם אני זוכר נכון, הכניסו בערך 200 אלף שעות.אני חושב שגרמנית, ספרדית - היו באזור העשרת-אלפים, אולי קצת יותר או קצת פחותץעברית - היו 680 . . . שאף אחד לא יודע מאיפה הן הגיעו.אז זה ה-Scope.בהתאם לזה, אנגלית עובדת מדהים ב-Whisper . . . אני חושב שהשפות האחרות, הנפוצות - גרמנית, ספרדית  - עובדות טוב.לא מושלם, אבל עובדות טוב מאוד.ועברית . . . איך אומרים? Your mileage may vary - אז זה זה . . . (אורי) אבל זה רק עניין של” חסר תוכן” . . .(יאיר) תלוי את מי אתה שואל . . . יש אנשים שאומרים “עברית היא שונה מכל מה שאנחנו ראינו בינתיים”.אבל התשובה היא שבעיקר חסר תוכן.(אורי) אוקיי, זאת אומרת שאם אנחנו נגיע לעשרת-אלפים שעות . . .(יאיר) מתויגות היטב - אז כן.(אורי) נהיה טובים “כמו הגרמנים”.(יאיר) יותר יפים - אבל כן.(אורי) שזופים . . .09:58 מנועים אחרים ומשמעות הפרויקט(רן) דרך אגב, הזכרת הרבה את Whisper, אבל לפני אולי שנה, אולי קצת יותר, עשיתי כמה בדיקות - גם הייתי צריך לתמלל מסה של אודיו בעברית. הייתי צריך לתמלל את זה, ובדקתי את Whisper לעומת “החבר של גוגל”, שכחתי איך קוראים לו [?Gemini] . . . ודווקא ההוא - של גוגל - נתן תוצאות קצת יותר טובות.יחד עם זאת, הרבה-הרבה מתחת לתוצאות באנגלית . . . זאת אומרת, באופן ברור. אני חושב שאולי גג הצלחתי להגיע לדיוק של 80% בעברית, בזמן שבאנגלית זה “נושק ל-90 הגבוהים”.(יאיר) ל-Whisper יש יתרונות אחרים - לדוגמא, הוא מפסק, שזה דבר נפלא. פסיקים, נקודות . . . אבל אני חושב שזה נכון. אנחנו, עד לפני כמה חודשים, ל-AWS יש את Amazon Transcribe, שעד לפני כמה חודשים הם נתנו לנו בראש.עדיין את Whisper הם אוכלים בלי מלח.ואותנו . . . .(רן) בעברית?(יאיר)  . . . הם עשו עבודה משמעותית יותר טובה ממה שאנחנו עושים בעברית - אבל זה כבר לא המצב.אבל כן.(רן) אז משמעות הפרויקט זה למעשה לאסוף תוכן-אודיו בעברית - את המיפוי שלו לטקסט בעברית - וגם לאמן את המנוע Transcription?(יאיר) כן. התחלנו מלאסוף את התוכן.הלך יותר מהר ממה שחשבנו, וכן - “עם האוכל, בא התאבון”.ראינו שזה עובד טוב, ואמרנו שגם לא נחכה - וגם לא ברור שיש מישהו לחכות לו . . .עכשיו אנחנו כבר בגרסא השלישית ששחררנו - שעליה כבר יש תוצאות יפות.זאת אומרת, היא On-par עם Amazon לגמרי - כשהיא בחינם.ואני משער שהגרסא הבאה תיהיה יותר טובה . . . (אורי) סתם, מעניין אותי - יש קובץ קול ויש טקסט, יש תמלול וכו’. מי עושה את ה-Syncing? או שהוא יודע להבין את זה לבד?(יאיר) כשאתה אומר...(אורי) יש אנשים שמדברים לאט, כמוני, על הפנים - ויש אנשים שמדברים יותר מהר. איך הוא מבין, כאילו, איפה אתה בטקסט?(יאיר) אז אתה שואל מבחינת השלב של ה-Inference או של האימון?(אורי) של האימון, לצורך העניין.(יאיר) אז האימון ב-Whisper . . . עכשיו, חשוב להגיד - אני לא מהנדס AI.אני חושב שברוב הדברים אנחנו יכולים לעשות עבודה טובה עם ידע בינוני.הרי ככה, ברוב ההנדסה, אתה לוקח Component שאתה מבין חלק ממנו . . .פרקטית, Whisper עובד במקטעים של 30 שניותאתה אומר לו “אדוני, הנה קטע של עד 30 שניות - הנה הטקסט שלו.הוא לא שואל אותך מה תזמון בפנים.(אורי) כן . . . זאת אומרת, זה לא שיכולים להיפתח פערים מאוד גדולים, עם קצבי-דיבור שונים.(יאיר) נכון.זה כן מייצר לך . . . זה כן מעניין, כשאתה מסתכל על איך נראה Inference, על חלונות של מעל 30 שניות ואיך שהם עושים את זה.ויש להם כל מיני אלגוריתמים רגילים, שעושים Stitchingזאת אומרת, נריץ 30 שניות - אבל אז נזיז את החלון נגיד ב-15 שניות קדימה וננסה שוב.פרקטית, הוא עובד על 30 שניות.13:08 מי עוד שם?(רן) אני רוצה עוד מעט להיכנס לפרטים הטכניים, אבל בוא רגע נסיים את ה-Overview על פרויקט.אז אתה אומר מדי פעם “אנחנו” - אז פגשנו את יאיר. מי עוד שם?(יאיר) כן. אז אנחנו התחלנו שלושה חבר'ה - אני; יניר מרמור - שהוא מסטרנט (M.Sc.) במכון ויצמן, במדעי המחשב; [ד”ר] כנרת משגב - שהיא מנהלת יחידה של חקר נתונים בהדסה, בבית החולים.ולפני כמה חודשים, הצטרף אלינו יועד סנפיר, שהוא גם מהנדס עם אינסוף ניסיון.ובין כולנו אנחנו מתכלליםא' - הבאה של ה-Dataץב’ - כל מיני צדדים של Legal - יש עורך דין, זה עורך הדין אלי גריבאום,.שבגדול מתעסק ב-IP, ושעוזר לנו מאוד.למשל, עזר לנו מראש לבנות את ה-License שלנו, ככה שכל מי שתורם לנו Data - הוא חותם מראש על License מתאים וכו’, שנוכל לשחרר הכל.אבל זה בגדול “אנחנו”.(רן) וכולכם בהתנדבות?(יאיר) נכון.(רן) וחוץ מכם - יש עוד אנשים שנותנים פה ושם שעות ועוזרים?(יאיר) קודם כל, תמללנו עד היום, בכל מיני צורות כאלו של תמלול-המונים, מעל 300 שעות.בתור Reference, ה-Data-set הכי גדול שהיה לפנינו בעברית, היה של 20-30 שעות.הרבה מזה זה Data-sets של כל מיני אנשים שמקריאים - מקריאים את הברית החדשה או דברים כאלו . . .אז כאן, מאחורי זה, יש כמה מאות מתנדבים שישבו ותמללו משפט-משפט - אז זה המון-המון עבודה.(רן) כן. אז קודם כל אני חושב שעפר [הי!], שעושה לנו הרבה מאוד עבודת תמלול, וגם חיבר בינינו למעשה, ישמח לשמוע את זה [אכן], ויכול להיות שגם תוכל להשתמש בתוכן שלנו, אז נשמח אם תעשה את זה.(אורי) על 485 פרקים . . . יש לך שעות.(רן) כן, ומאותו רגע אתה יכול להפיק בעצמך פודקסטים, להשתמש בקול שלי ושל אורי - וזהו . . . כן, באמת -  יש פה את גם האספקט הזה’ או שזה רק תמלול? כלומר, יש פה גם אספקט של Generation, בהמשך?(יאיר) יש . . . היו לנו כמה שיחות מעניינות על זה.יש גופים בארץ, שזה מעניין אותם לא רק לייצר את זה - כאילו, לא רק לעשות Text-to-Speech, אלא גם לעשות Text-to-Speech שיהיה “תקני”.זאת אומרת, שיעמוד באמת בכללים של השפה.זה משהו שרק עכשיו התחלנו להסתכל עליו יותר.(אורי) יש לי הרגשה ש...(רן) מאזיננו אבשלום . . . (אורי) כן, זה יקרה “פרויקט אבשלום”.(יאיר) בלי שאני מגיב על זה ישירות, זה . . . אני חושב שזה דברים נפלאים.כי המטרה - מבחינתנו, אחת המטרות הגדולות שלנו מראש, הייתה להגיד “אף אחד לא יעשה את העבודה”.כאילו, לא יעשה את העבודה הזו בתשלום, כי הקהל הוא לא מספיק גדול.אבל אם עושים את זה טוב - גם Speech-to-Text וגם Text-To-Speech - אנחנו “נשפיע על התל”ג”.כי בסוף היום, אם אמא שלי צריכה להתקשר כדי להתנתק מ-HOT, למשל - [היפותטי לחלוטין, למה שמישהו ירצה לעשות דבר כזה?], אם היא הייתה מחוברת אליהם עדיין.והיית רוצה שכשהיא מתקשרת, מיד יענה מישהו בצד השני - גם אם הוא מחשב שכנראה ינתק אותה יותר מהר, אני מקווה - ובשביל זה, אתה צריך גם להבין מה היא אומרת, וגם לענות לה.ושני הכלים האלו, כמו המון פעמים בתוכנה - יש המון דברים שאם תקבל בחינם, אתה תשתמש מיד, ואם לא תקבל בחינם, אתה לא תשתמש בכלל.אז אנחנו...(רן) כן, אני חשבתי שתיקח את זה בכיוון אחר: אמא שלך צריכה להתנתק, המשימה נופלת עליך - ולך אין כוח לעשות את זה, אז אתה תפעיל את הרובוט. . . (יאיר) אותי הם אוהבים יותר  - כשאני מתקשר, מנתקים מיד.16:47 אספקטים של חוקיות, סקלרט והתבורי’ס(רן) אוקיי, אז דיברת קצת על אספקט של חוקיות וכל זה - אז לצורך העניין, אם אני תורם את הקול שלי, האם אחר כך גם תוכל להשתמש בקול שלי כדי “לייצר רובוט”, נקרא לזה? [ד”ש לפרוייקט רובו-שאול](יאיר) אז כשניסחנו את הרישיון, היה חשוב לנו להגן, בעצם, על כל הצדדים, שזה אומר - א’ . . .(אורי) רן, הקול שלך זה נחשב תרומת-איברים . . . (רן) ברבים, כן.(יאיר) בעצם רצינו לוודאא' - שמי שלוקח את התוכן - והרבה פעמים הוא חברה לא-ישראלית וכל הדברים האלו לא מעניינים אותה - הוא צריך להרגיש מוגן לגמרי.ולכן מה שכתוב, זה היה צד אחד.הצד השני היה שבאמת מי שתורם את זה, לא ידאג שמחר אנחנו נעשה “פעלולים”.מה שקרה אפקטיבית כתוצאה מזה, זה שניסחנו רישיון שכתוב בוא' - מותר, עם ה-Data שאנחנו מנגישים, לאמן מודלי AI בצורה גורפת.מותר להשתמש בהם לכל שימוש חוקי.זאת אומרת, אם לקחת את ה-Data הזה, בנית מודל ועכשיו אתה רוצה למכור אותו - אם אני עשיתי את זה, אתה לא יכול לבוא ולהגיד לי “אבל זה היה ה-Data שלי!”.אלה החיים . . . ברור שם בוודאות שאתה לא תקבל שום פיצוי על זה.זה מצד אחד . . .(אורי) בוא נדבר אחר כך על הזכויות של הקול של רן . . .(יאיר) הצד השני הוא שיש שם סעיף אחד שמוחרג, וזה כתוב: “Deep-Fake-ים אסור לעשות”.אנחנו לא רוצים מצב שמישהו יתרום, ובסוף יידפק מזה איכשהו.אז אפשר לעשות את זה - מי שרוצה בכל מקרה לעשות את זה בצורה לא-חוקית, לא היה צריך את הרישיון שלנו.אבל מי שעובר דרך הרישיון, אז זה מוחרג שם.(רן) כן. היה סיפור די מפורסם בהוליווד, לפני כשנה, עם שחקנית - שכחתי את שמה - אבל שחקנית מפורסמת, שרצו להשתמש בקול שלה לצורך . . . (יאיר) Scarlett Johansson עם OpenAI  . . .(רן) . . .  Scarlett Johansson, כן - שלצורך אני חושב פרסומת או איזשהו משהו .  . . והיא לא הסכימה. ולמרות זאת הם עשו את זה, אם אני זוכר נכון - והיא תבעה אותם.אז אני מקווה שאני זוכר את הסיפור יפה, אבל זה עניין, אוקיי? זה עניין. זאת אומרת, יש לה קול שמזוהה היטב איתה, ואם מישהו שומע את הקול שלה, זה מייצר איזשהו Creditability, והיא לא תיתן את זה בחינם, ובטח שלא למען  מטרות שהיא לא מאמינה בהן.אז כן, אז יש פה עניין עם Fake-ים - קראת לזה “Deep-Fake”, אבל שימוש של קול באופן עקרוני. אפשר לחשוב גם על יוצרי-פודקאסטים [מישהם ספציפיים?], ש”אוקיי, אז עכשיו כל מה שאני צריך זה לייצר איזשהו טקסט, ולתת לצורך העניין לאמסטרדמסקי או לתבורי להקריא את זה בשבילי!” - ואני לא צריך ממנו “טובות”, כי יש לי כבר את הקול שלו . . . אז יש פה איזשהו עניין.(אורי) לאיזה תבורי אתה מתכוון?(רן) אני לא אפרט . . . יש לפחות שלוש בחירות טובות.אז אז כן, יש פה איזשהו עניין. ברמה הטכנולוגית זה מאוד מעניין, ברמה המשפטית זה כנראה מעניין לא פחות.19:45 סקירת מצב עם סימני פיסוק(רן) אוקיי, אז דיברת על איזשהו אוסף של שעות שאליהן הגעתם, אז תן לנו רגע איזושהי סקירת מצב: איפה אתם היום ומה המטרה שלכם?(יאיר) אז ככה: יש לנו כמה חזיתות.דבר אחד - אנחנו מאוד מתאמצים ליצור Benchmark ברור לתמלול בעברית.יש Benchmark-ים כלליים לתמלול - ה-Data-set-ים שיש בעברית הם נוראיים לזה.התחלנו ליצור Leader-Board ממש - יש לנו איזשהו עמוד שאתה יכול להיכנס אליו ולהגיד: “הנה סדרה של Benchmark-ים והנה איך כל מנוע עובד עליהם”.זה בעיקר נועד כדי שיבוא מישהו יותר חכם מאיתנו, יוציא מנוע יותר חכם - ובתקווה יגיע למקום הראשון.(רן) זאת אומרת, Benchmark זה אוסף של Audios, התמלול הנכון שלהם ואיזושהי בדיקה של עד כמה התמלול שהפקת קרוב ל-”Golden”.(נכון) נכון, ובשביל זה לקחנו מתנדבים - כש”מתנדבים”, במקרה הזה, זו אחותי . . . .(רן) . . . התנדבה בעל כורחה . . . .(יאיר) ואמרתי לה “הנה טקסטים מאוד ארוכים - בבקשה תמללי אותם “ברמת האות” - כמה זמן שזה ייקח, זה ייקח”.(רן) דרך אגב, הזכרת מקודם “פיסוק” - אז את זה אתם גם עושים?(יאיר) Whisper עושה את זה “באופן טבעי”.אנחנו, בחלק מה-Data-set-ים שלנו יש את זה, ובחלק לא.(רן) אבל זו מטרה אצלכם? או שאתם כרגע...(יאיר) זה לא מטרה - אבל בוא נגיד שלשמחתנו זה פשוט עובד. אנחנו . . .חלק מהפעילויות החדשות שאנחנו עושים יגרמו לזה לקרות באופן טבעי, אבל עד היום זו לא הייתה מטרה.(רן) דרך אגב, על ניקוד יש מה לדבר, או שזה בכלל סרט אחר?(יאיר) זה סרט אחר.אם אתה מכיר את איך שהוא עובד לעומק, אז הוא די פתור כבר . . . קודם כל, יש כלים של נקדן.יש מקרים שבהם יש Ambiguity בטקסט והם לא תופסים - זה די פתור . . .(רן)  . . . כ-Post-processing. זאת אומרת, כשיש לך את הטקסט, אתה יכול להפעיל עליו נקדן. ברוב המקרים זה יעבוד ואתה לא צריך בהכרח מאודיו. למרות שלפעמים, האודיו יכול לרמוז לך . . . (יאיר) נכון, אבל לפעמים, בהרבה מהם הדובר ידבר בצורה שבה זה . . . שאם תנקד לפי איך שהוא דיבר, תעשה עבודה לא טובה.(רן) כן, כן.(יאיר) יש לנו Data-set-ים - שזו בעצם המטרה הראשונה שהייתה לנו - כמה Data-set-ים גדולים, שמונגשים.אחד זה של אודיו לא מתויג - יש לנו שם כבר הרבה מעבר לעשרת-אלפים שעות.אני חושב שאנחנו כבר מעל חמש-עשרה, אבל לא רוצה לחתום על זה בלי שאני בודק שוב.(רן) איזה סוגי אודיו יש? זאת אומרת - הקלטה אולפנית? מה אתם צריכים שם? איזו איכות?(יאיר) רוב מה שיש לנו זה פודקאסטים [קרדיטים]. היינו שמחים להוסיף לזה תוכן כמו שיחות טלפון, שיחות של מוקדי שירות לקוחות, שיחות של רופאים, עורכי-דין  וכו’.אין לנו המון מזה.אז זה מה שמאוד, היינו שמחים להוסיף.(אורי) בטח גם יהיה קשה, מבחינת פרטיות, להביא את זה.(יאיר) נכון. יש דרכים לעקוף את זה לפעמים, שאנחנו התחלנו לעבוד עליהן - וזה בהקלטה.זאת אומרת, תראה: אני לא יכול עכשיו להקליט את השיחה שלי עם מטופל, אבל אני כן יכול לעשות סימולציה לשיחה כזו.ולפעמים, אתה אפילו יכול לכתוב את הטקסט של הסימולציה הזו מראש, ואז לא צריך לתמלל אחר כך . . . .(רן) אבל יכול להיות שאתה . . .  שמספיק להשתמש בפודקאסטים בתחום. כאילו, תיקח פודקאסט-”משפטי” - יכול להיות שיהיה לך את ה-Corpus של העולם המשפטיף מאשר...(יאיר) זה נכון, וזו שאלה של . . . בוא נגיד, באופן טבעי יחסית, כמות הפודקאסטים הכי גדולה שתמצא מחוברת לעולם הטכנולוגיה.ולכן, לא סתם כלים כמו ה-Whisper עושים עבודה . . . כאילו, אם אתה מנסה לדבר איתו על מושגים טכנולוגיים - הוא עושה עבודה מדהימה, הוא תמיד כמעט יפגע.גם מושגים שאני אומר “רגע, אפשר היה לתמלל את זה בהמון דרכים שונות” - אם זה מושג מהעולם “שלנו”, הוא יפגע בו, כמעט תמיד.אבל יש לנו בעצם . . . אז יש לנו המון המון Data שהנגשנו כבר, שהוא Data “גולמי”.וזה - יש אנשים שלקחו אותו והשתמשו אותו בו כבר לכל מיני דברים.יש לנו גרסה שנייה, שזה Data שחתכנו - בעצם, לקחנו את הגולמי, חתכנו אותו לסגמנטים (Segments) הרבה יותר קצרים, של עד 30 שניות, ונתנו לאנשים לתמלל.הנגשנו Data-set כזה - אני חושב שאתמול הנגשתי אחד כזה . . . .יש שם כבר מעל 300 שעות שמוכנות - ועם זה אפשר לאמן מודלים.אז זה דבר שני, ועכשיו…23:56 פרויקט ההקלטות החדש (רן) כמה זמן לוקח להפיק את אותן 300 שעות? אז אתה אומר “מקטעים של 30 שניות” - כל אחד צריך לתמלל בצורה די מדוקדקת. כמה עבודה זה?(יאיר) אז די-מדוקדקת . . . קורה שאתה טועה, זה בסדר.אנחנו מחשבים את זה בתור 1 ל-5, כן? 1 ל-4, 1 ל-5.זאת אומרת שעה של תוכן - ייקח לך 5 שעות של עבודה.(אורי) שזה בעצם הצוואר בקבוק של כל הסיפור . . .  [הי!](יאיר) נכון, ובשביל זה התחלנו עכשיו עוד פרויקט, שכל מי שרוצה לעזור בו סופר-מוזמן.פרויקט של הקלטות - שאנחנו בעצם אומרים “תיכנס, תבחר איזה עמוד שאתה רוצה מוויקיפדיה - ותקליט”.אז אתה עם המקלדת - אתה מסמן בכל פעם שאתה עובר לפסקה הבאה, לוחץ רק “Next”ואז אנחנו בעצם מקבלים כאן תוכן שגם אנחנו יודעים מראש מה תמלול שלו, אז לא צריך להתאמץ.וגם הוא מתוזמן - אז אנחנו יכולים אחר כך לקחת “ולהדביק אותו”.אז זה די בהתחלה. יש לנו עכשיו, הוצאנו מזה בינתיים 12 שעותאבל גם זה הרבה יותר קל לעשות . . . גם זה קצת ממכרוגם כשאתה רוצה לסגור פערי-תוכן בתחום ספציפי - רפואה, משפטים, לא משנה מה - אתה יכול ללכת ולהקליט אותו ישירות.אז זה לא מושלם כמו לקחת שיחה חופשית - אבל זה עושה . . .  אני חושב שזה יעשה את העבודה.(אורי) בקרבות-הוויקיפדיה, יכולים כל הזמן לשנות לך את הזה, ואז התמלול לא יצא כמו ההקראה, אם היה רבע שעה בין אחד לשני . . . (יאיר) בתקווה אנחנו שומרים על Best Engineering Practices, ושומרים גם את הטקסט בצד.(אורי) אוקיי. מה לגבי, אתה יודע, העברית היא שפה עתיקה, יחסית. השפה שלמשל תקרא בתנ״ך, או מקורות ישראל אחרים, היא שפה אחרת. זה מעניין?(יאיר) אני חושב שאצלנו ספציפית, זה לנו כרגע פחות קריטי.כי ברור שמה שהכי מעניין אותנו, זה שהעברית היומיומית שלנו תעבוד.(אורי) המדוברת.(יאיר) נכון.אבל, יניר, שהוא פריק של כל הדברים האלו, מגיע אלינו מדי פעם עם . . .לדוגמא, עכשיו הוא הגיע עם דיון על ארמית . . . מסתבר שיש חוקרים בעולם, שזה מה שהם עושים.[הנה ד”ר לארמית אם מישהו מחפש]אז ארמית ספציפית - אין לנו הקלטות שלה, אבל, יש גם בעברית…(אורי) אין פודקאסטים בארמית? (יאיר) יכול להיות שיש ואני לא מכיר . . . (אורי) אכדית? שומרית?(רן) צריך להקשיב לליל-הסדר קצת יותר, ותקבל שם לא מעט ארמית.(יאיר) למרות שאתה, בסיכוי מסוים, מתבדח לדעתי, יניר מכיר את התחומים האלו טוב.למרות זאת, יש...(אורי) . . . . ומתומלל בכתב יתדות.(יאיר) אנחנו כן רואים גם אצלנו, שמגיעים סוגים שונים של עברית.לדוגמא, הרבה פעמים פונים אלינו עם תוכן שהוא תוכן חרדי, כן?רואים שמגיעים מכל מיני . . . או קווי טלפון, שאתה יכול להתקשר אליהם ולשמוע הרצאות, או הקלטות של רבנים.ואתה רואה מיד, שזה תוכן שונה, שהוא ניב שונה לגמרי של עברית.וחלק מהם - בוא נגיד שלא תמיד אנחנו יודעים איך להנגיש את זה, כי לא תמיד אנחנו יודעים אם המתמללים שלנו ידעו לתמלל את זה בסוף.אבל זה לגמרי קיים.(רן) אוקיי. מעניין אתכם גם לשמוע דוברים שונים - למשל ילדים, או מבטאים שונים?(יאיר) זה ממש אחד המקומות שהכי חסרים.(אורי) מבטאים יש הרבה . . . (יאיר) זה אחד המקומות שהכי חסרים לנו, ובצורה שהיא פוליטיקלי-קורקט לגמרי, אני אגיד ש...בוא נגיד, אני חושב שגברים אשכנזים - יש לנו הרבה.(רן) עשירים . . . (יאיר) נשים אשכנזיות יש פחות.דווקא הפרויקט של ההקלטות נועד לטפל בחלק מזה - ילדים, ובארץ שלנו: אתיופים, ערבים, עם כל . . . עם מנעד גדול, חרדים.כל הדברים האלו יש קצת יחסית ב-Data-Set-ים רגילים - וזה לא טוב.וכשאתה מקליט, זה לכאורה יותר קל להעשיר את ה-Data-Sets בזה.(אורי) יוצאי ברית-המועצות יש לא מעט . . . (יאיר) נכון.(רן) מעניין אם יש פה מקום, סתם ככה זורק רעיון, מקום לשיתוף פעולה משרד החינוך. נגיד, ילדים שלומדים לקרוא, גם יכולים להקריא - וככה אתה גם יכול להרוויח...(יאיר) אני חושב שהקושי שם ספציפית - וזו אחת הבעיות הגדולות עם לעבוד עם ילדים, ואפילו עם מבוגרים לפעמים - זה שאתה לא כל כך רוצה ללכת לנקות את ה-Data אחר כך . . . זאת אומרת, אם  . . .  אני מסוגל לדמיין יחסית בקלות, שאתה נותן לילד להקליט - ואז הוא מספר כמה בדיחות והולך לעשות משהו אחר.ואתה, אם אתה לא יודע כלום על האיכות של ה-Data שנכנס, זה קצת בעיה.אבל יש לנו כבר ילדים שהתחילו להקליט כל מיני סיפורים.יש כאן כל מיני בעיות . . . גם ילדים פחות יקליטו תוכן של וויקיפדיה - אתה צריך להביא ספרי ילדים.בשביל זה אתה צריך סופרים שיסכימו לתרום לך . . . יש לנו אחת שהסכימה, אבל זה לוקח זמן לארגן את הדברים האלה.(רן) אוקיי.28:47 עירוב של שפות, גדלים של מודלים וחומרה(רן) סיפרתי שבעבר עשיתי איזשהו פרויקט של תמלול של תוכן בעברית, ומדי פעם השתרבבה לשם אנגלית, או צרפתית. זאת אומרת, יש לא מעט תכנים שיש להם עירוב של שפות.האם מודלים יודעים להתמודד עם זה כמו שצריך? האם המודל שלכם אמור להתמודד עם זה?(יאיר) זה תלוי במודל.פרקטית, Whisper עושה עבודה די טובה שם, והמודל שלנו “אוכל את זה טוב”.לא מושלם, אבל ברוב המקרים הוא יודע לטפל בזה יפה.(רן) שלכם?(יאיר) כן.(רן) אבל איך? כל מה שהוא שמע זה רק עברית, אז איך הוא ידע?(יאיר) מבחינת Whisper, בסוף הוא מוציא Token-ים . . . (רן) לא, שלכם. המודל שאותו אתם אימנתם.(יאיר) אנחנו וריאנט (Variant) של Whisper.לקחנו את Whisper ועשינו לו עוד Fine-tunning . . . זאת אומרת, בסוף היום, Whisper יודע להוציא Token-ים  של כל השפות.אם אתה מראה לו ב-Data של האימון משפטים מעורבים - זה יעשה את העבודה.(רן) הבנתי, זה יכול לעבוד. אוקיי, מה גודל Whisper? כמה הוא?(יאיר) Whisper זה 1.5 מיליארד פרמטרים.(רן) לא נורא . . . (יאיר) נכון, לא נורא.לצערנו, הוא לא רץ עדיין - הוא לא רץ על מחשב בלי GPU בצורה סבירה.מה שאומר שאם אין לך Mac אז נדפקת. אבל...(רן) אם אין לך Mac, אז יתחממו לך הברכיים . . . (יאיר) אבל הגרסה הבאה שלו, שזה Whisper-Turboשאנחנו עוד קצת נאבקים בלאמן אותה, אבל לשמחתי היום, בוא נגיד, בכל השנה הראשונה כמעט, כל דבר שרצינו לעשות אמר להוציא כסף מהכיס.רוצים לאמן מודל? 200 דולר. אלה החיים.ואם אתה לא יודע לאמן - אז כמה Cycel-ים כאלו של זה . . . (אורי) 200 דולר הלכו על קירור . . . (יאיר) לשמחתי, אין לנו חומרה בבית, אבל עכשיו, נגיד היום ...(רן) “200 דולר” זה על GPUs, נגיד מ-AWS או גוגל או...(יאיר) נכון. נגיד היום, התקשר מישהו ואמר לנו “אני אשמח לתת לכם את הכסף, בואו תאמנו לנו מודל חדש”אבל לדוגמא, יש מודל עכשיו נפלא - בתקווה - שהוא איזשהו Variant של Whisper, זה Whisper-Turboעובד הרבה יותר מהר, הוא מודל קטן בערך פי 2700-750 מיליון פרמטרים, אני חושב.ואותו כבר אתה יכול להריץ על המחשב שלך, בקצב סביר.(רן) ב-CPU . . . (יאיר) כן. אז ברגע שנצליח לאמן אותו, אני מקווה ש...(רן) כן, רק לפרופורציות - מודלי-שפה קטנים הם בדרך כלל 7 מיליארד, ופה אנחנו מדברים על 1.5 מיליארד, או 750 מיליון, שזה שבריר. ומודלי-השפה “האמיתיים”, הלא-קטנים, הם הרבה יותר גדולים - באיזור ה-40, 70 או 140  מיליארד.(יאיר) 400 . . . (רן) 400, כן. אז סדר גודל הרבה יותר קטן - שזה נחמד. ואתה אומר שה-Fine-Tunning הזה שאתם עושים עולה סדר-גודל של כמה מאות דולרים. כמה זמן לוקח, נגיד להריץ “מאפס”, על כל ה-Data שיש לכם?(יאיר) כן, אז בגדול זה לינארי בכמות של ה-Data.אני חושב שבפעם הקודמת, אימנו עם 180 שעות, משהו כזה.אך זה תלוי בחומרה, כי באמת, אתה יכול לעשות זה יותר מקבילי.אני חושב שזה לקח משהו כמו יומיים . . . יומיים - אבל של חומרה קצת יותר יקרה.זאת אומרת, אני חושב שלקחתי ארבעה GPU-ים, בו-זמנית, כדי...(רן) כן, אוקיי.(אורי) אגב, לערבית יש?(יאיר) Whisper יודע לעשות ערבית, אני חושב שלא מדהים.ואם היינו יודעים להשיג Data כזה, אנחנו גם מאוד רוצים. אם היינו יודעים להשיג יותר Data, היינו עושים את  זה כנראה.בערבית, עד כמה שאני מצליח להבין - יניר הוא הבן אדם להסביר את זה בצד של השפה - אבל לערבית יש המון  המון ניבים.וזה משהו שמשפיע.בעברית זה לא המצב.כאילו בערבית, כל מדינה כמעט שתלך - זה ישמע קצת שונה.(אורי) פשוט, בכל המדינות מכירים את אביחי אדרעי . . . נראה לי שאתה יכול להקליט אותו, וזה...(יאיר) הבעיה שאתה בצד השני - אתה רוצה לתמלל את זה, אתה רוצה שהם ידברו ותבין.אבל אולי אפשר להכין ממנו מנוע של Text-to-Speech באמת . . . (אורי) כן, אבל אתה יודע - אפשר ליתר אותו . . . .32:45 הפרדת דוברים(רן) מה לגבי הפרדת-דוברים? איך עושים את זה? כלומר, יש כמה אנשים שמדברים - נגיד שיחה, אחד מדבר על השני, או... (אורי) נגיד שאתה מקליד, מתייג פודקאסט . . . (רן) חס וחלילה, כלומר, אנשים עולים אחד על השני . . .(אורי) כן . . . (רן) . . . . ומפריעים אחד על השני . . . .[בשם צוות המתמללים וההנהלה, באמת המון תודה על זה](יאיר) יש מספר דרכים, שזה נכנס מבחינתנו לאזורים של “אנחנו קצת מסתכלים עליהם, היינו רוצים להיכנס”אבל כולנו, כאילו, “חנוקים” מאינסוף דברים אחרים, כי הכל לוקח זמן.התחלנו להסתכל על זה קצת עכשיו.בגדול, יש חבילות שעושות את זה ברמות שונות של איכות.יש חבילה אחת שנקראת pyannote - די טובה.יש ל-nVIDIA משהו שנקרא NeMo - חבילה עם המון המון כלים.ויש להם Speaker Diarization בפנים, באיכות מסוימת.(רן) לא צריך לדעת השפה? זאת אומרת, פשוט מסתכלים על מסיבת-קוקטייל ומפרידים את הדוברים?(יאיר) אז בהרבה מקרים, הם יודעים להסתדר יחסית בלי השפה.מה שיפה זה שלהרבה מהדברים האלו, אפשר לעשות Fine-Tuning.עכשיו נניח, שיש אנשים שיש להם פודקאסט קבוע [נניח].ונניח הם מקליטים עם Setup של מיקרופונים נפרדים [נניח]ואפשר לקבל גישה ל-Data הנפרד . . . אז א' - את התמלול מראש נכון לבצע על כל ערוץ בנפרד, ולחסוך את הדיון הזה.ואז אין בכלל עניין של הפרדת-דוברים - הדוברים מופרדים מראש.(רן) כן, אבל זה באימון. אני מדבר על בזמן ה-Inference, אם יש לך מספר דוברים . . . .(יאיר) לא, אבל מה שאני אומר זה - בוא ניקח לדוגמה שיחת Zoom, כן?עשינו, אתה ואני - שיחת Zoom - והקלטנו אותה.אתה יכול לבקש מ-Zoom שייתן לך את ה-Data בערוצים נפרדים.(רן) נכון . . . (יאיר) . . . ואז אין שאלה - אתה תריץ Inference על כל אחד בנפרד, ותקבל את זה מתויג כמו שצריך.הרי כשאתה, לא יודע - חמש שנים אחורה, כשאתה עושה שיחה כזו ב-Zoom, ואתה רואה סימן של “זה הבן-אדם שמדבר”?זה נגזר מזה שהוא יודע מאיזה ערוץ זה מגיע.בגלל זה, אם יש חדר שכולם יושבים בו - אתה לא יודע מי זה.אז זה דבר אחד.אבל יש כלים שעושים דיאריזציה (Diarization) ברמה סבירה - זה פשוט לא מושלם, אנחנו לא שם.(רן) כן. אבל יש חשיבות לשפה בעניין הזה, או שזה לגמרי אגנוסטי, וזה, כאילו, “ברמת הסיגנל”?(אורי) נראה לי שזו בעיה שפתורה באנגלית - פתורה גם פה.(יאיר) אני חושב שהיא לא פתורה באנגלית . . . . אבל יש פתרונות סבירים.אני חושב שזה לא מושלם.אני חושב שה-Speech-To-Text עובד יותר טוב - והרבה פעמים זה בגלל שהוא מניח, חלקית, שזה דובר אחד . . . (רן) כן.35:11 הוראות שימוש ואיך אפשר לעזור(רן) אוקיי, אנחנו כבר ממש לקראת הסיום. וזהו, רק רציתי, ככה, לחדד כמה נקודות.אז אחד, אם אני רוצה להשתמש - אז פשוט ללכת ל-ivrit.ai ולמצוא את מה שאני צריך?(יאיר) אם אתה רוצה להריץ לבד, אז או להיכנס ל-ivrit.ai או להיכנס ל-Hugging Face שלנו, ויש שם הוראות איך להריץ.יש לנו GitHub, שיש בו את 100% מהקוד שלנו, משוחרר בצורה חופשית כמובן.אם אתה רק רוצה לתמלל משהו קטן, אז עד שיגמרו לנו או הקרדיטים ב-AWS או הכסף ממקורות אחרים, יש לנו אתר ב-Home Page שלנושאתה נכנס, יכול להעלות קובץ של עד שעתיים או משהו כזה.ואנחנו מריצים ומחזירים לך את זה פשוט מתומלל.(רן) ואם אני רוצה לעזור לפרויקט - מה אני עושה? יכול להיות מפתח, יכול להיות קריין, יכול להיות אולי דברים אחרים שצריך? . . . (אורי) מוציא את מספר כרטיס האשראי . . . .(יאיר) אז באמת - תמיכה במשאבי-מחשוב זה סופר-עוזר לנו.יש לנו Patreon, שאפשר לתמוך בו ב-ב-5 דולר לחודש, שזה מספיק לנו לכל מיני דברים חשובים, עדיין.לתמלל זה דבר נפלא. כן?זו עבודה - כמו הרבה מהדברים האחרים - יחסית כפוית-טובה, שמאוד עוזרת.והיום ספציפית - להקליט.כלומר, אם אתה מסוגל להגיע, ופשוט להקליט תוכן מוויקיפדיה, או להביא אנשים אחרים שיעשו את זה גם איתך, אז זו דרך בשבילנו לייצר המון תוכן.(רן) כן, צריך איזה Mic? מה הדרישה שלכם?(יאיר) כל מיקרופון שיש לך . . . אם יש לך מחשב עם מיקרופון, או סמארטפון - זה יעבוד.(אורי) אם יש מישהו עם משאבי-מחשוב פנויים?(יאיר) נשמח מאוד לקבל . . . כאילו, לקבל גישה.(אורי) כמובן שצריך לעמוד באיזה-שהם, כאילו . . .  (יאיר) GPU שיש לו 80Gb זיכרון עושה את העבודה.זה לא משהו בלתי אפשרי, זה לא סופר-סופר יקר,אבל אנחנו Obviously לא קונים אחד כזה הביתה . . . .37:15 עד כאן(רן) טוב, תודה רבה יאיר! בהצלחה עם המיזם, תודה על התרומה לקהילה.וזהו - שיהיה בהצלחה, ותיצרו קשר עם יאיר, ותשתמשו, ותתרמו.בהצלחה. להתראות.(יאיר) מה תודה? רגע, אין מתנות? אמרנו שיש מתנות . . . .(רן) אה, זה בסוף הקלטה, אחרי שעוצרים.(אורי) איזה GPU אמרת שאתה צריך . . . האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 484 (מספר יפה!) של רברס עם פלטפורמה, שהוקלט ב-20 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור את שי ילין ואת רון קליין לשיחה על מגדלי שן (מבחינה ארכיטקטונית).(רן) למעשה, גם שי וגם רון הם שניהם מפתחים / ארכיטקטים מאוד מאוד מנוסים, ובחודשים האחרונים יצא לנו פה ושם לחוג סביב הנושא הזה של איך “נכון” להנדס תוכנה בחברות צעירות ובחברות ותיקות יותר, איך נכון לבנות ארכיטקטורה בשלבים שונים של החיים של החברה - ופחות או יותר על זה אנחנו נדבר היום.ובעיקר נדבר על מהות התפקיד וההבדלים השונים בין תפקידי הארכיטקט במקומות השונים. אבל עוד לא הצגתם את עצמכם . . . [בפרקים הקודמים - 469 Software development in early stage startups with Shai Yallin478 with Haim Yadid, Software in young startups]01:05 שי ורון(רן) אז קודם כל - ספרו קצת על עצמכם. שי, בבקשה . . .(אורי) בפינה השמאלית, ארכיטקט הניצחון . . . .(שי) האמת שאני לא מגדיר את עצמי כארכיטקט . . . . אני שי, אני עצמאי בתחום הנדסת התוכנה.לפעמים אני מכנה את עצמי “Fractional Principal Engineer”, או “Principal as a Service”.אני מתעסק באיך מהנדסים תוכנה - איך בונים ארגונים ומערכות שקל לעשות להן שינויים, בכל מיני Level-ים של חברות.יש לי לקוחות שהם חברות ממש אחרי Seed או אפילו לפני Seed ויש לי חברות שהן כבר אחרי Round Eוכל מיני דברים באמצע ביניהם.(רן) וזו לא ההופעה הראשונה שלך פה בפודקאסט . . . . אז מוזמנים לבוא ולהקשיב לפרק הקודם עם שי, שאני כרגע לא זוכר את מספרו [469! הנה שוב - 469 Software development in early stage startups with Shai Yallin, יש שם גם הפניות להרצאות בכנסי רברסים לאורך השנים].רון!(רון) היי, Nice to be here, נתחיל מזה.(רן) מאזין מפרק אחד!(רון) אכן! כשעוד היו קצת תקלות עם האודיו וה-Level של הווליום ודברים כאלה . . .(אורי) השתפרנו מאז . . . (רון) בתחום פיתוח התוכנה - אני לא יודע, 20 שנה + בקטע הזה של “לפרנסתי”עוד לפני זה גם היה תחביב.בעשר השנים האחרונות אני בתפקידי Tech Leadership ב-Scope-ים ופורמטים שונים.יצא לי גם להיות Tech Lead ו-Staff Engineer ובTitle-ים ב-Corporates סטייל ב-eBay וב-Semi-Garage Startups - וכל מיני In-Betweens יצא לי גם לעשות בעשור-פלוס האחרון.(רן) וכיום אתה . . . .(רון) כיום אני ארכיטקט - “ארכיטקט הפלטפורמה”, אפרופו רברס עם פלטפורמה - בחברת Elementor.זו חברה שמייצרת הרבה מאוד כלים ל-Web Creators, שזה Title מאוד מגוון, Fluid-י כמעט כמו “ארכיטקט” . . . .ובגדול זה אומר שבעבר, כדי לבנות אתר אינטרנט, היינו ככה פונים לאיזה “איש מקצוע” - היום זה הרבה הרבה יותר מורכב.ו-Elementor נותנת מענה להרבה מאוד בעיות או Pain Points בכל ה-Life cycle של Websitesמהתכנון עד ההרצה, Growth, Payments - כל הדברים האלה, Elementor נותנת להם מענה.(רן) כלומר, רכיבים שאפשר להשתמש בהם בפלטפורמות שונות?(רון) לגמרי.(רן) מעולה, אז Web זה כיף . . . .(רון) Web זה Fun-Fun-Fun, זה כן . . . .03:55 “ארכיטקט”? !There's No Such Thing As A Gruffalo(רן) אז סיפרתם לנו קצת לפני הקלטה, שבעצם הרעיון לפרק הזה התחיל מאיזושהי שיחה, שאתה ושי דיברתם - ואתה אמרת “אני ארכיטקט!” ושי אמר “אין דבר כזה!” . . .  פחות או יותר, אני קצת אולי מתמלל את זה אחרת.אז מה זה בעצם “ארכיטקט”? בוא נשפוך את זה, בוא נפתח את זה כבר עכשיו - מה בתפקיד? מה זה ארכיטקט?האם יש דבר כזה? האם צריך דבר כזה? (אורי) אני לא הייתי שואל מה בתפקיד - אני שואל מה בתפריט? . . . כי מהצד אחד, אתה יכול להגיד “אין דבר כזה?” ומצד שני, זה יכול להיות כל כך הרבה דברים. אז יאללה - המיקרופון שלכם.(רון) אז אני רוצה רגע לתת ככה מענה, תשובה.אני באמת חושב שזה פחות ה-Title ויותר באמת המהות או התפקיד עצמו, או תחומי האחריות.בעיניי, ארכיטקט - יש לו כמה כובעים.הוא, מבחינת ה-Leadership, זה כובע משמעותי - הוא צריך להיות “מגדלור” כזה, של מצוינות טכנית ו-Seniority טכנולוגי.בנוסף לזה, הייתי אומר שהוא גם אמור לא להיות “היחיד” - כלומר, הוא אמור להעלות את הרף, וליצור סביבו את ה-Next Generation של ארכיטקטים או Tech Leaders בארגון, ב-Scope-ים שונים.להיות ה . . .  נקרא לזה “בן אדם שאיתו מתייעצים” ויחד איתו מקבלים החלטות שיש להן משמעות מאוד גדולה Moving Forward.כלומר אי אפשר - או שיהיה מאוד קשה - To roll back, לקחת את הצעד הפוך ולשנות את ההחלטה.וזה בדרך כלל החלטות בתחום הטכני-טכנולוגי, פחות החלטות מוצריות Pre-se.(רן) כלומר, אז דיברת על העניין של מצוינות - אבל בוא אני אתריס: האם צריך לעבור דרכך דרך כל Code Review, דרך כל Design Review? לקבל אישורים ו”סטמפה” כדי לשחרר פיצ'רים? (שי) . . . . ”בשלושה עותקים!” . . . (רן) האם אתה ה-Gatekeeper?(רון) אז שאלה טובה . . . . ולדעתי, יש כאן, כאילו, כמו כל ארכיטקט אני אגיד “זה תלוי . . .. “.אני חושב שדבר ראשון, יש כאן פונקציה מאוד משמעותית של Seniority ו-Engineering Level בארגון.ואני חושב שהשאלה שאתה שואל, אם ירושה לי לנסח אותה בדרך אחרת, זה עד כמה הארגון מעוניין להיות ב-DNA שלו Centralized לעומת Decentralized.כלומר, כמה חופש או מה דרגת-החופש שאנחנו מעוניינים לתת לEngineering Teams או ל-Silo-ים השונים מצד אחד, לעומת . . .מצד אחד בסקלה זה “אוטונומיה מוחלטת” - כל אחד שיחליט על הכלים הטכניים שלו וכו’.ומצד שני, יש לך את מה שכרגע התרסת - הכל עובר ומתנקז דרך איזושהי פונקציה אחת בארגון - “הארכיטקט!”ועל פיו ישק דבר, ומה שהוא מאשר הוא מאשר, ומה שלא - לא.אני לא חושב שזה . . .  לא חושב שיש כאן תשובה אחת נחרצת.אני חושב שזה מאוד מאוד מבטא את ה-DNA הארגוני, בכללי.(רן) כן, בסדר. יצא לך, דרך אגב, לעבוד במקום שבו באמת היה ה-DNA כזה ריכוזי, ואתה או אולי מישהו אחר היה בתפקיד הארכיטקט והיה ה-Gatekeeper של כל הפיצ'רים?(רון) כש . . . בלי להגיד שמות, במקום שבו ה-Engineering Level היה יחסית נקרא לזה “פחות מהממוצע”, היה לי סוג של Carte blanche קיבלתי גיבוי מוחלט - “רון, קח אותנו קדימה, קח אותנו ל-Next Level!”.ובאמת לא הייתה ברירה - עשינו הרבה הכשרות פנימיות, כדי לייצר איזשהו Baseline, שמשם ואילך כבר היה יותר קל לתת לכל צוות לנוע בקצב שלו, לתת את האוטונומיה.אבל בהתחלה, זה היה שלב כזה של “אוקיי, הרבה מאוד דברים עוברים דרכי”הרבה מאוד דברים - נקרא לזה “כל מיני Design Reviews” - עוברים דרכי וכו’.08:30 עניין של מורכבות(רן) אוקיי, אז דיברנו על העניין הזה של מצוינות ואולי, ככה, “להראות את הדרך” וכל זה.אבל לפעמים גם יש כל מיני משימות שהן “מורכבות” - Debugging מורכב, אולי תכנון של מערכת חדשה, אולי אינטגרציה בין הרבה מערכות אחרות של אותה חברה, אולי יש גם מורכבות-עסקית . . .  זה יכול להיותכל מיני דברים.(אורי) לפעמים יש גם . . . אתה נגעת ב-Debugging, אבל יש “בעיות שרק הארכיטקט יכול לפתור”. כאילו, משהו באיזה Monolith כזה, ש”להכניס את היד ואתה לא יודע איזה נחש ינשך אותך” . . . .(רון)  . . . . או שמה שאתה מוציא הוא . . . אתה חושב שזה מתחיל באיזה “צ'ופצ'יק קטן”, ולאט לאט אתה מגלה כמה זה מתחבר לעוד סבך מאוד גדול של דברים.(שי) אני חושב שאם יורשה לי, יש פה נקודה מאוד מעניינת . . . שבעצם, ה-Role או הצורך הארגוני הוא לא בהכרח ב-Gate-Keeping.אני חושב שGate-Keeping זה “שריר” שצריך להיול מסוגלים להפעיל בנקודות מסוימות, ברגעים מסוימים.כמו שרון אמר - זה לא דיכוטומי.אבל יותר מזה - אני חושב שהארכיטקט זה Variant אחד של איזשהו קונספט יותר רחב, יותר גדול, שבתוכו ישבים גם דברים כמו Principal Engineer או Fellows, כל “הגווארדיה היותר בשלה ומנוסה” שיש בארגון.כי באמת, יש מקומות שזה יכול להיות או “ה-Monolith הישן”, או שהמערכת כל כך גדולה, שקשה, כאילו, To Grok the entire thing.קשה להכניס את כל המערכת לראש של בן אדם אחד, ואז יש צורך שיהיה בארגון אדם אחד - או כמות של אנשים - שהם אלה שרואים את המערכת “ממעוף הציפור”.אבל - שגם יכולה להיות להם יכולת לעשות Zoom-In או Drill-Down איפה שצריך, כדי להיות מסוגלים לדבר גם בשפה שהיא High Level וגם בשפה שהיא Low Level.גם בשפה שהיא כללית - כל המערכת - וגם בשפה של Silo ספציפי, Pod ספציפי, מוצר או קו-מוצרים ספציפי.10:52 רגע, מה ההבדל?(רן) אז מה, הזכרת “Principal” וכו’ ו-Title-ים אחרים,  ולא יודע אם כולם או כל מי שמקשיב לפודקאסט בהכרח מכיר. זה משהו שמקובל בחברות יותר גדולות, שיש בהן Level-ים שונים ל-ICs. אבל נשאלת השאלה, ככה בגדול - אז מה ההבדל בין Principal או Distinguished או Fellow Engineer כלשהו לבין ארכיטקט? האם יש הבדל ואם כן - מהו או מה הוא צריך להיות, לדעתכם?(רון) אני אקח את זה רגע מהצד שלי - אני חושב שזה Title-ים שונים שמייצרים סולם של Tech Leadership, של IC טכני, פשוט עם Scope - עם היקף-פעילות או “Level של מעוף ציפור” יותר ויותר גבוה.אני חושב שנדרש מתפקידים “נמוכים” יותר להיות הרבה יותר פעילים ב  . . .  נקרא לזה ב”Component Level” או ברמת ה-Design הפנימי של תת-מערכת כזו או אחרת.ככל שעולים בסולם הדרגות של ה-IC, הכוונה היא להוביל - להיות ה-Focal Point הטכני או הארכיטקטוני, אם נרצה.במערכת שהיא כבר יותר Cross-Teams או Cross-Siloes או Whatever.וככל שעולים למעלה; יש כנראה גם יותר ויותר מקום לחזון או לכיוון ההתקדמות הטכני-טכנולוגי של הארגוןהנושא הזה של “האם צריך להחליף שפה?” או, לא יודע - “האם אנחנו רוצים להמשיך להשתמש בכלי הטכנולוגי הזה או אנחנו רוצים לבחון אלטרנטיבות אחרות?”וככל שהארגון גדול יותר - ושוב, זה מאוד מאוד פונקציה של גודל הארגון, ה-Dev.ככל שהארגון גדול יותר, ככה יש לדרגות הגבוהות יותר יותר מקום.ויכול להיות שבארגונים קטנים - זה . . . אפרופו, יכול להיות שבארגונים קטנים, נגיד פחות ממאה מפתחים - אולי לא חייבים שם ארכיטקט או משהו כזה.זה יכול להיות באמת איזה משהו שהוא מקביל ל-Principal או משהו דומה, זה לא חייב להיות אחד.והם עושים עבודה מצוינת.(רן) כמה אתם אצלכם בארגון, בפיתוח?(רון) ב-Elementor מעל מאה איש בפיתוח, World-wide.(רן) אוקיי, יש גם CTO?(רון) יש, יש . . . (רן) ואיך החלוקה ביניכם, בינך ובינו?(רון) הוא באמת נמצא במקום . . . הוא CTO שהוא גם Co-Founder, והוא נמצא במקום הרבה יותר של “לנווטאת הספינה הגדולה הזאת קדימה”, דברים הרבה יותר Visionary מאשר הקונקרטיזציה שאני אמון עליה.13:52 ארכיטקט זה המטבע-קריפטו החדש (ישן)?(אורי) אני רוצה להגיד משהו, קצת, לא יודע - “דרסטי” פה: זה מטבע, הדבר הזה שנקרא “ארכיטקט”. זה בעיקר “חי ב-LinkedIn”. זה סוג של Crypto שחי . . . .(רן) . . . היום Crypto הולך טוב . . . (אורי) . . . כן, ה-Bitcoin . . .  “עלה דווקא שער הארכיטקט” . . .  אבל זה סוג של “מטבע וירטואלי”. בכל חברה זה אומר משהו אחר לגמרי, כמו גם ה-Principal וה-Fellow, זה בכל . . ..  זה משהו שאתה יכול לשים ב-LinkedIn שלך, זה לא אומר שום דבר על התפקיד שלך בחברה.בהרבה מקרים משלמים לך במטבע הזה, “סוג של קידום”, אוקיי? זה לא אומר כלום, נגיד, על השכר שלך.ואני יכול להגיד שהרבה פעמים, בשלב מסוים מצאנו את עצמנו שזה מה שאנחנו עושים. אם מישהו לא מתקדם כי אין לו שום סולם קידום בחברה כ-IC - “תיהיה ארכיטקט!”. הוא יכול לכתוב את זה ב-LinkedIn, הכל בסדר.בהרבה חברות, הסולם-קידום היחיד שבעצם יש להן זה בעצם רק בציר ניהולי, אז  ב-IC אומרים “קח את הארכיטקט ותעזוב אותנו בשקט” . . . . הדבר הבאמת נכון לדעתי לעשות, וזה כבר לא משנה אם אתה שם שמות לדברים האלה או שם מספרים של Level-ים, זה פשוט להגדיר בצורה מאוד טובה מה אומר כל Level, מה ה-Expectations שלך מה-Level הזה.עושים את זה כמובן ארגונים גדולים יותר - כשהם מתפנים, לדעתי, לעשות את זה - אבל זה עושה המון סדר בקריירה של ICs.(רן) אורי, אתה זוכר באיזה שלב אתם עשיתם? כמה הייתם אז בארגון לפיתוח כש...(אורי) מאוחר  . . .(רן) כמה? - מאות?(אורי) כמה מאות.(רן) מאות אנשים. . . ואצלכם, רון, יש כבר Leveling כזה?(רון) יש “התהוות” של הגדרת התפקיד שנקראת Tech Lead.בחברות קודמות שעבדתי בהן, זה היה הרבה יותר מסודר.הן כבר עברו את שלב ה-Incubation של הגדרות התפקיד, של ה-Level-ים.ואני חושב ש . . . אני כאילו קצת נותן לך פינג-פונג מהכיוון ההפוך - אין לך איזושהי “רגולציה” שאומרת רוחבית “Principal זה ככה!” בכל חברה Principal מוגדר X, או Staff Engineer מוגדר ככה, או Tech Lead, או Whatever.(אורי) מהבחינה הזאת, אמרנו בגדול לאנשים - “שימו מה שאתם רוצים ב-LinkedIn - מבחינתי אתה Level 6”.(רון) אוקיי, אבל מה שאתה אומר - ואני מאוד מסכים - זה שיש הגדרה . . .(אורי) “מבחינתי אתה Level 6 - וזו ההגדרה של ה-Expectations שלי מה-Level”.(רון) אבל למה אנחנו . . .  אוקיי, למה ה-Title חשוב כאן? אני יכול להגדיר את עצמי כ”שרברב תוכנה”. אני פותח סתימות . . .(אורי) אגב - זה מה שאתה עושה, כן? אבל... כאילו, כולנו בעולם התוכנה . . . (רון) לא המצאתי את זה, אני כבר ראיתי את זה.(רן) אנחנו קודם מחביאים אותן טוב-טוב, את הסתימות . . . שמים את החומר - ואז פותחים!(רון) כן, בדיוק. אבל מה זה משנה ה-Title?(אורי) אז בגלל זה אני אומר - זה לא כל כך משנה. מה שמשנה זה . . . אני רק יכול להגיד, נגיד ספציפית לארכיטקט, שאמנם היה את הסיפור שאני מספר בסוף, הוא עניין של “כאילו Title”, אבל בנקודה מסוימת, אנחנו רצינו להתחיל גילדות . . . . [הנה, כאן - 367 Guilds at Outbrain](רון) או, הנה - שי נדלק . . . (אורי) כן, כן . . . ובעצם אמרנו שאנחנו מחפשים מישהו שיוביל את הדבר הזה שנקרא “גילדות”. היינו . . .  בשלב הזה, עזב ארכיטקט שהיה לנו - ולא חיפשנו ארכיטקט, אבל חיפשנו מישהו שיוביל גילדה. וספציפית, אותו בן אדם שרצינו שהוא יוביל את הגילדה אמר לנו “סבבה - אבל אני גם רוצה להיות ארכיטקט”.תכל’ס אמרנו לו “סבבה” - והרווחנו את שניהם באמת ביחד.וזה יצא מאוד מאוד טוב שמי שנגיד “קובע את הסטנדרטים” של הארכיטקטורה ושל איך שהקומפונננטות (Components) מדברות אחד עם השני ובאיזה פרוטוקולים - הוא גם זה שמצד אחד דואג שהתשתית תיבנה לזה, ומצד שני גם מלמד את האנשים איך זה עובד ואיך צריך לעבוד - והגילדה היא בעצם “הזרוע החינוכית” של הארכיטקט. וזה יצא פגז.19:45 ה-Title וחותם המלך(שי) זה מהמם, זה מהמם . . . אני רוצה להתייחס רגע לסיפור של Title. Title, זה בעיניי זה לא-“לא חשוב”. מכמה סיבות.הראשונה היא שאוקיי - אנחנו יודעים שה-Title הוא Meaningless וגם ה-Founder-ים יודעים שה-Title הוא Meaningless.אבל כל מיני מנהלי-ביניים, שלא בהכרח מכירים אותי, ואני בא ואני אומר להם “חבר'ה תקשיבו - הרעיון שלכם למוצר, הוא יכול לעבוד ככה ב-Micro, בתוך המוצר הניסיוני הזה שאתם עכשיו מריצים ב-Pod שלכם”“אבל אתם חייבים לחשוב גם על שאר הארגון” - על איך “האדוות” שאתם יוצרים ישפיעו ויפגעו במוצרים אחרים, ב-Pod-ים אחרים.ואם זה מגיע מתוך IC שאין לו Title - זה יכול להיתפש אחרת, מאשר אם זה מגיע מתוך IC שיש לו Title שנשמע יותר “מפוצץ”.אני לא אוהב את זה, זה לא כאילו . . .  זה לא “כיף לי” שזה המצב - אבל בהרבה מקומות, זה המצב.אז כדי שיקחו אותך ברצינות, כדמות שיש לה “השפעה בלי סמכות”, לפעמים כן צריך לתת - לא בהכרח סמכות ניהולית “עם שיניים”, אבל כן איזשהו Title-ון כזה או משהו.שעוזר לאנשים שעדיין לא מבינים בדיוק מי אתה בתוך הארגון - אולי כי הם חדשים, אולי כי לא אכפת להם . . .(אורי) או שהארגון הוא מאוד גדול - והקשרים שאתה צריך לייצר או ה-Interface-ים שאתה צריך לייצר, הם מעבר לרמת ההיכרות האישית. כי אני מכיר את רון, אני יודע שהוא “אייס”, בסדר? ושיש לו פה . . . “הוא כתב חצי מהמערכת”. אז כאילו, ברגע שהארגון גדול מעבר לזה - יכול להיות שאתה צריך לבוא גם עם איזשהו Title. אני לא יודע, אתה [רן] עבדת ב-Google - זה היה שם ככה?(רן) קודם כל, ה-Google שבה עבדתי וה-Google של היום הן כנראה מאוד מאוד שונות . . .(אורי) לא, אבל גם ה-Google שבה עבדת הייתה כבר גדולה, עם Interface-ים . . .(רן) הבת שלי, שנולדה כשהייתי שם - היום היא בת 16 . . . אז עבר הרבה זמן. אבל כן, ללא ספק - כמעט בכל חברה גדולה, במיוחד שזה ככה, “Across the Ocean” ובאנגלית וכל זה, כן, יש - הTitle עוזר. זאת אומרת, תמיד יש אנומליות, אבל זה לגמרי יכול לעזור. זה קצת מזכיר לי שבימי-הביניים היית מסתובב עם “החותמת של המלך” - אף אחד לא היה מכיר אותך, אבל אם היית מציג את החותמת של המלך, אז אוקיי, סבבה, “הבנו מי שמך”. אתה לא  בהכרח את הבן אדם הכי טוב, אתה לא בהכרח הכי חכם - אבל מישהו סומך עליך וזה המלך, וזה בסדר, אנחנו צריכים לעשות מה שתגיד,אבל אורי - הזכרת מקודם משהו מעניין: אמרת שאותו בן אדם, שהוא היה ארכיטקט טוב והבין את הטכנולוגיה מצוין, הוא גם ידע לארגן את האנשים, לארגן גילדות, שזה תפקיד לגמרי של הובלה, אבל אנושית. זאת אומרת, אולי יש פה גם צד טכנולוגי, אבל זה מישהו שצריך להלהיב את האנשים, להוביל אותם, לשכנע אותם וכל זה. ולפעמים זה Skill קצת שונה . . . אם יש לך מזל, יש לך את שניהם באותו בן אדם, אבל לפעמים זה לא.זה לא אותו דבר, זאת אומרת - אותו אחד שיודע לעשות Low-Level Debugging או High-Level Architecture זה לא בהכרח אותו אחד שיסחוב אחריו אנשים לתוך גילדות ולשינוי של מבנה וכל זה . . .(אורי) אז אחד הדברים שבנינו, כשבנינו את ה-Leveling של ה-ICs, אז אחד הקריטריונים שהולכים ותופסים יותר  מקום ככל שאתה עולה ב-Level, זה היכולת-הובלה שלך - היכולת השפעה שלך על אנשים.(שי) אבל זה גם בדיוק מה שאמרתי קודם לגבי ה-ICs, מבחינת Level-ים בתוך ארגון.הקריטריונים - מה שאתה אומר ה-Expectations, “הציפיות המוגדרות היטב” - מתייחסות גם להיקף של  הפרויקטים שהבן אדם אמור להוביל.הם יכולים להיות פרויקטים ברמת . . . לא יודע, “שני צוותים ומעלה” זה, לא יודע, “זה Level X”“להוביל לפרויקטים של, לא יודע, חמישה צוותים, או משהו כזה, או שני Silo-ים, זה Level Y”.זה בדיוק זה.אני לא מצליח כל כך להבין, איפה הגילדה נכנסת כאן - בקטע הזה של Scope הובלת פרויקטים.כלומר, אם אנחנו מדברים על Expectations, נגיד מארכיטקט - אז בעיניי, זו נקודה מאוד משמעותית, של מה היקף הפרויקטים, ברמה טכנית, שהבן אדם יכול לקחת על הכתפיים שלו.(אורי) אז אני מבדיל בין שני דברים - כשאתה מוביל הובלה טכנית של פרויקט, חלק ממה שמצופה ממך להוביל זה ה-What: זאת אומרת, “מה תעשו כדי שהפרויקט יקרה?”, (שי) אוקיי . . .(אורי) המקום של גילדה, הוא מקום של How? - מה הסטנדרטים שאנחנו מיישרים בארגון, בשביל שהארכיטקטורה  מסויימת או שקומפוננטות (Components) - ברמת הארגון - יוכלו לדבר אחת עם השניה, “עושים את זה ככה”.(שי) אני רוצה לתת דוגמה לעניין הזה. יש לי לקוח - אני לא אנקוב בשמו - אבל לקוח שמאוד שם בפוקוס את העצמאות של ה-Pod-ים.חברה בשלה כבר - יש להם הרבה שנים, מצאו את ה-Product-Market Fit שלהם, הם גדלו לאט ובביטחוןאבל הם יצרו מספר לא קטן של Pod-ים, שכל אחד עובד לבד - בלי בכלל להתייחס למה ש-Pod-ים אחרים עושים.וזה עבד להם מעולה - כשהם היו קטנים. אבל ככל שהם גדלו, הצורך ב”משהו מרכזי” נהיה יותר ויותר ויותר ניכר - ובאמת בשנה האחרונה, יחד איתם, התחלנו לבנות להם את הקונספט של גילדת Engineering,ושם היה ניכר שיש באמת צורך בשתי הפונקציות - ובאמת שתי הפונקציות האלה יכולות להיות באותם אנשים, או באנשים שונים..מצד אחד, הבן אדם שיגיד “לא! אנחנו לא נייצר “God Object” עם מאה שדות, ונשים אותו ב-Mongo”.“אנחנו נתחיל לנסות לייצר הפרדה ל-Domain-ים”.ומצד שני...(רן) ה”שלילי על שלילי” זה בסדר, נכון? “God Object” ו-”Mongo” זה בסדר . . .(שי) אני חושב שאם תשאל את העובדים של אותה חברה, הם יגידו לך שלא כל כך כיף להם להתעסק עם ה-God Object” הזה.ומצד שני יש צורך לקחת את “הציוויים האלה של המלך” - ולחלחל אותם לשטח.עכשיו, אתה יכול לחלחל את זה בציווי - ואתה יכול לחלחל את זה גם בשכנוע ולימוד.וגילדה היא פונקציה בארגון, שעוזרת לחלחל דברים - לא בכוח אלא באמת בהובלה, בהשפעה, בפסיליטציה (Facilitation) ולא ב-Prevention.(רן) כן, סוג של “הובלה ללא סמכות” - למרות שכן יש את הסמכות, אוקיי? “קורטוב של סמכות”.(שי) בדיוק, בדיוק - הסמכות היא “נעלמת” כזה, “היא שם והיא לא שם”.(רן) כן. זאת אומרת, זה לא מנהל “Line Manager” מה שנקרא, לא מנהל ישיר. כן, אתה לא זה שהולך לקבוע את המשכורות של כל העובדים באותה גילדה, אתה לא הולך לפטר או לגייס - אבל כן יש איזושהי סמכות. היא קצת  Implicit, היא שונה בכל חברה, אבל בעצם זה ששם לך את ה-Title של Principal, מנהל גילדה, ארכיטקט או Whatever, נתנו לך איזשהו קרדיט מהנהלה, אוקיי? ויש איזושהי סמכות שהיא לא לגמרי מוגדרת, נכון? אבל זה לא אפס.(שי) I beg to defer, מה שנקרא . . .  לדעתי, נקרא לזה הפונקציה הזאת של מנהל או מוביל של הגילדה - הוא Facilitator.הוא מישהו שיודע לתפעל ולארגן קבוצה כנראה די קטנה של אנשים, או שיש שם איזושהי תחלופה, “מילואים”, לא יודע . . . כל ארגון בסוף והגילדה או הגדרת-הגילדה שלו.ואני לא בטוח שזה אותו Skill-set. סליחה - זה לא בהכרח אותו Skill-set.(רן) זה לא אותו Skill-set, זה מה שאתה רוצה לומר. אל תתבייש . . . (שי) זה לא אותו Skill-set, לדעתי, שיש לארכיטקט,אחד הדברים שהארכיטקט אמור לדעתי לדעת לעשות זה גם לדבר עם אנשים שהם לא טכניים ולתווך להם את ארגון הפיתוחולכן הוא סוג של גם “פונה כלפי חוץ”.נגיד, אני יכול לשבת עם צוות ה-Billing ולהסביר לו איך לדעתי כדאי לעשות את, לא יודע . .  את צורת ה-Payments וה-Billing שאנחנו עושים בארגון, במוצרים שלנו.ולעבוד עם אנשי-מוצר, כדי להבין האם המידול שלהם או האם ה-Business - איך אנחנו יכולים למדל את זה טוב יותר ל-Domain-ים אצלנו ומה יהיו החלטות קשות יותר וקשות פחות.ואני צריך לפעמים גם לדבר עם CX, עם Customer Experience Persons, כדי לברר טוב יותר איזושהי בעיה.כל אלה - אני לא רואה אותם חיים באותו Facilitator, באותו Guild-Manager.ואני חושב שזה ממש סמכויות שונות. אגב, אני חושב שיש לארכיטקט סמכות, זה כמו שאתה... “הקורטוב סמכות” הזה - הוא חל גם על הארכיטקט, סוג-של.אם בסוף אני לא מצליח לשכנע את, לא יודע, את ה-Product Manager שאנחנו עושים כאן טעות גדולה, אז אני צריך למעשה להפעיל את המנהל שלי - שיתחיל להתקוטט עם המנהל שלו או משהו כזה. בסוף יש לי את - אפרופו “חותם המלך” - יש לי את “חותם המלך”, לפחות של המנהל הישיר שלי.אז לא... בעיניי זה ממש לא אותו הדבר.[זוהר בדיוק דיבר על זה במוצרלה - (Mozzarella - Organizational Politics 101 (feat. Zohar Sacks]30:00 שובו של (חותם) המלך וה-Fractal שממשיך פנימה(אורי) אני חושב שפה זה ממש עניין תרבותי, כי במקום שהארגון צריך להיות מאוד גדול ומאוד סקלבילי (Scalable), אתה מתחיל לחלק ל-Domain-ים גם את הארגון. ובסוף, לכל Domain יש את ההתמחות שלו, שהייתי מאוד מעדיף שצוות שמתמחה ב-Domain X יעבוד עם צוות ה-Customer Success או ה-Business ב-Domain X ישירות - בלי להצטרך את “חותם המלך” בסיפור הזה.ואני ממש מעדיף - ואני גם מגדל את האנשים הרלוונטיים בתוך הצוות הזה - כדי שהם יוכלו לעשות את זה.עכשיו, זה בסדר שהם יכולים לעשות את זה - אבל כדי שלא יווצרו תת-Domain-ים שפועלים אחרת לגמרי, כן צריך את אותו בן אדם שייישר את ה-How - לא את ה-What, את ה-How. בסדר? What? - תעבדו ישירות. קצרו תהליכים. קצרו מעגלים . . . .(שי) רגע, שנייה - וכשאתה מקצר את התהליכים האלה, סבבה. הלוואי. הלוואי ולכל מתכנת או מתכנתת יהיה את ה-Drive הזה.(אורי) אנחנו לא מדברים על מתכנתת בארגון גדול - אנחנו מדברים כבר על תת-ארגון, קבוצה או צוות.(שי) סבבה, אוקיי, מקסים - יצרת את ה-Silo עם הדינמיקה שלו.לפעמים בכל זאת, אחרי שבררנו מה שבררנו, צריך לחשוב האם אנחנו רוצים למדל את זה כך או אחרת.(אורי) הם אמורים לדעת לעשות את זה לבד, כי הארכיטקט נותן להם את זה ב-Push, בחינוך.(שי) אז רגע, אז שנייה . . .(רון) אני טוען שזה פרקטלי (Fractal), כי בתוך Silo צריך להיות Tech-Leadאיזשהו Level 3 - 4, לא יודע, תלוי בארגון.מישהו שהוא מספיק בכיר או מישהי מספיק בכירה, עם מספיק סמכות וניסיון והשפעה ו-Gravitas, בשביל להיות מסוגלים להשפיע אל מחוץ ל-Silo, מחוץ לפוד.אבל היא גם צריכה להיות בחניכה על ידי אנשים שהם ב-Level-ים יותר גבוהים ממנה - שנמצאים בתת-ארגון שמכיל את תת-הארגון שהיא נמצאת בו . . . וככה אנחנו הולכים פרקטלית (Fractal) למעלה ולמעלה, עד שאנחנו מגיעים לאיזה CTO או לאיזה Chief Architect או לאיזה Guild Leader.ובאמת, השמות משתנים מארגון לארגון, ולפעמים בארגון אחד מי שקוראים לו “גילדה”, בארגון אחר זה יקרה “ארכיטקט” - למרות שהוא עושה בדיוק אותו הדבר.ולפעמים לא . . .(רן) ה-Fractal הזה, שי, ממשיך פנימה - זאת אומרת, בתוך אותו בן אדם: לפעמים אני הארכיטקט-שבי, לפעמים אני המנהל-שבי, לפעמים אני המקודד-שבי. [שירה].33:03 דייג - אוהב דגים?(רן) אבל בואו רגע - לא נגענו פה באיזושהי נקודה רגישה, שאותי תמיד סיקרנה: ארכיטקט מקודד? כלומר, צריך לדעת לצייר, נכון? צריך לדעת לכתוב . . .(רון). . .  את המלבנים והחיצים, זה ממש טוב . . . (רן) . . . המלבנים והחיצים, כן, Sequence diagrams, דברים כאלה - חייבים, חייבים! את הדמויות של ה-User, לצייר כזה יפה יפה, עם רגליים ישרות . . .  וצריך, כנראה, לדעת לכתוב איזשהו Spec טכני וזה.אבל אתה מקודד? או - ארכיטקטים מקודדים, למיטב ידיעתך?(רון) אני חושב - לדעתי, זה שוב, זה מאוד משתנה לפי ה-DNA הארגוני.יש ארגונים שיגידו “בוודאי!” ויש ארגונים שיגידו “עזוב אותך, יש דברים יותר חשובים שהיינו רוצים שתעשה”.ואני נמצא במקום שבו אני מקודד להנאתי, ככה “בפנאי” - אז זה לא כזה.כאילו, הכושר נשמר מצד אחדומצד שני, כשצריך לפתור בעיית עומק - אפרופו, מה שתיארת קודם, כששולחים, “כשמכניסים את היד פנימה לקישקעס, ומנסים להבין מה קרה”כאן, לדעתי, נמדדת היכולת של כל הניסיון שצברתי עם הזמן.זה לאו דווקא הקידוד - זה הרבה יותר לשאול את השאלות הנכונות, לרדת מה-High Level, “מהמלבנים והחיצים”לרדת ולעשות את ה-Drill-Down לתוך הקוד, לתוך הפונקציות עצמן, ולהבין.כאילו, התנודתיות הזאת, מרזולוציה גסה לרזולוציה עדינה - זה, לדעתי, אחד ה-Added Value שהארכיטקט אמור להביא איתו.לא משנה אם זה כולל לכתוב את הקוד של הפיצ'רים הבאים או לא.וזה, שוב - זה קצת DNA, זה קצת מבטא את ה-DNA הארגוני.הייתי גם . .  “טעמתי מזה ומזה”.(שי) אני רוצה להגיד שאני מאוד מסכים עם כל מה שרון אומר - ועם זאת . . .(רון) . . . לא יכולת אולי לעצור קודם? . . . (שי) . . . מאוד חשוב שהארכיטקט . . .  שלא יהיו ארכיטקטים שלא כותבים קוד.כאילו, זה לא מספיק בעיניי לכתוב קוד כ-Hobby, בצד - זה צריך להיות לכתוב קוד בתוך המוצר.כי אם אתה, כארכיטקט, מייצר כל מיני סטנדרטים ועקרונות, ומכתיב דברים, ועושה ולפעמים גם עוצר דברים - ולא חווה את חוויית-המפתח בתוך המערכות שבסוף אתה בונה, אני מרגיש שאתה עלול לפספס משהו מאוד מאוד חשוב.(רון) אני מסכים איתך . . .  אני מסכים איתך.(רן) אבל . . .(רון) לא, אני פשוט חושב שזה . . . אבל - זו שאלה של מינון.אני בעד פעם ברבעון, או לכל או יותר פעם במחצית, להיכנס, להיות סוג של Shadow או לחבור לאיזשהו צוות ברמת פיצ'ר.לכתוב משהו, לראות שזה מגיע ל-Production, לקחת את ה...(רן) אתה תגיד לעצמך “מי הדביל הזה שהכתיב את ה-Spec הזה?! אה, זה אני . . .”(רון) אה, זה אני . . . מה, זה הסטנדרט?(רן) . . . כן, סוג של Eat your own Dog food, למפתחים.(רון) כן, אבל רציתי להגיד משהו עוד קודם - בעיניי כל הנושא הזה של הסטנדרטיזציה זה באמת אחד התוצרים של הארכיטקט,ואנחנו, לדעתי, כל הזמן בשיחה, תסלחו לי - מדברים על איזשהו ארגון פיתוח על גבול האוטופי . . .של מהנדסים ומהנדסות מאוד מוכשרים, שאפשר לתת להם את כל האוטונומיה שבעולםוהם יכולים לרוץ קדימה כמה שהם רק רוצים, והשמיים הם הגבול.המציאות היא לא כזאת.(רן) זאת אומרת, לפעמים צריך “ללכת אחורה ולדחוף את האלה עם האלונקה” . . . . אלה שקשה להם, אלה שנשארים מאחור.(רון) כן, ולמפות . . . . בדרך כלל, אחד הדברים שאני עושה - אני ממפה את הפערים של ה-Engineering Skillsשל ידע, לפעמים, “טהור”.וזה חלק מהתפקיד.ועד אז - עד שהארגון יהיה “מצוין" - כן, יש מקום ל-Centralism.אתה דיברת קודם ככה על ה... אמרת “משהו מרכזי” . . . (רן) כן, אבל זה קצת נבואה שמגשימה את עצמה. זאת אומרת, אתה אומר “אה, הם חדשים, אז אני אעזור להם” - אז אתה לא נותן להם הזדמנות להתחזק. זאת אומרת, אתם לא... אין להם את ההזדמנות לטעות בעצמם וללמוד בעצמם וככה להשתפר.(רון) זה מאוד תלוי כמה כבר יש לך חוב טכני עמוק להתמודד איתו, ולפעמים צריכים קצת “פעולות רדיקליות".ולפעמים, כמו שאתה אומר, זה... אורי, אתה התייחסת לזה שזה חלק מ”החינוך העקבי והמתמיד”.זה מתחיל כאילו, To Pay Off, אפשר להתחיל “לקטוף את הפירות”ונדרשת לזה הרבה סבלנות.(רון) אבל עד אז, אני שוב אומר - ולא כל ארגון הוא בכלל רוצה לקבל את החינוך הזה, זה גם איזשהו DNA, או איזושהי תרבות ארגונית שהארגון . . .שלא כל ארגונים - יש להם את הראש לזה.(אורי) לכל ארגון יש “מערכת חיסונית” לשינויים  . . . (רון) תכל’ס . . . (אורי) אז כאילו, אין מה לעשות. צריך לפעמים...(רון) אבל לא כל ארגון - בכלל יש לו אותה “שאיפה למצוינות טכנית”, שאנחנו לדעתי, בשיחה הזאת, איפשהו  מניחים שהיא קיימת by default.ו”החינוך” הזה שאתה מתאר - לא תמיד אתה מוצא לו את הפרטנרים.ואז זה קצת “לחצוב את הדרך” ולעשות צעדים מאוד קטנים.וליצור את הדינמיקה שתאפשר את זה.אבל לא תמיד יש לך Stakeholders מספיק בכירים בארגון, שבכלל “קונים את הסחורה” הזו.ולכן, אני חושב שהדיבור - גם על גילדה, שזה רעיונית . . . אני מאוד מתחבר לזה - אבל היא מתאימה לדעתי לארגון שהוא יותר בשל...(אורי) . . . או שמצוינות טכנולוגית זה חלק מה-DNA שלו.(רון) כן, כן - ואני לא חושב שזה “פתרון קסם” לכל ארגון.ויש ארגונים שירצו לפחות להתחיל עם דמויותלאו-דווקא “ארכיטקט”, לא משנה איך נקרא לזה ב-Title, אמרנו “זילות ה-Title”  . . . לא משנה איך נקרא לזה - יש ארגונים שמבינים שבתור התחלה, צריך ליצור כאן פונקציות “בכירות טכנית”.עם אימפקט של  . . .  סוג של “צריך להקשיב להן”.ואחר כך, Hopefully, הם יגיעו כבר לאיזשהו מקום יותר טוב.39:54 מבוא לחוויית הפיתוח(אורי) רציתי רק להוסיף עוד משהו מהניסיון שלנו: אחרי שנהיה כזה “ארכיטקט" - שהוא גם ראש גילדה, שהוא אחראי על ה-Practices וכו’ - אחרי זה קורה עוד דבר די מגניב, אם אתה נותן עוד יעד - ליצור אוטומציות. כי מפתחים, בינינו, זה טיפוס עצלן . . .  כשאתה מכניס Practices, הם בדרך כלל יבואו עם עוד עבודה, נכון? אז חלק ממה ש...(רן) והעבודה זה הדבר הזה שמונע ממך ללכת הביתה . . .(אורי) בדיוק.(רון) חוסם אותך ביציאה . . . (אורי) כן, או סתם מלשחק FIFA . . . אצלנו, קראנו לזה הצוות של ה-DevX, ה-Developer Experience - הוא פשוט לוקח את כל הדברים שאפשר לעשות להם אוטומציה, ומכניס אותם לתוך התשתיות ולתוך תהליכי העבודה, ומייצר פשוט סטנדרטיזציה הרבה יותר טובה לתהליך.(רון) וכמה ארגונים אתה מכיר, שמחזיקים את הפונקציה הזאת, של Developer Experience, של הצוות DevX הזה? אני מכיר מעט מאוד . . . ואני לא בטוח בכלל שזה... אני לא יודע לתת לכם אחוזים, אבל זה שוב - “הלוואי”.הלוואי ובכל ארגון הייתה את הראייה הבוגרת והבשלה הזו.יצא לי מספיק פעמים בחיים לראות ארגונים וגם לדבר עם אנשים - אני עושה קצת Mentorships, ככה כחלק מהדרך.ואני שומע הרבה מאוד אנשים שמדברים איתי, ולמעשה - תכל’ס, אני מזקק את זה ואומר “חבר'ה, זה לא ארגון פיתוח שעשה מצוינות כערך”ועכשיו אנחנו צריכים להבין איך אנחנו מתקדמים ואיך מתפתחים בכל זאת שם.אוקיי? כאילו זה בסוף, לא כזה פשוט החיים בחוץ. It’s complicated. 42:13 לתת בהם סימנים ותיאום ציפיות(רן) אוקיי, אולי שאלה אחרונה לסיום - נניח שאני מנכ״ל או CTO או VP R&D של איזושהי חברה, ואני קם בבוקר  ושואל את עצמי “רגע, רגע, אין לי ארכיטקט! איך זה יכול להיות שאין לי ארכיטקט?! האם אני צריך אחד כזה?”אז מה הם הסימנים, לדעתכם, שמעידים על כך שאולי שכחתי משהו?שי - נגיד, מקודם הזכרת כמה Pod-ים שפועלים באופן שלא אולי לא מודע אחד לשני, אולי עושים עובדה מיותרת.אבל מה הם הסימנים המעידים על כך שאולי כדאי לי לחשוב על תפקיד כזה,כמו של ארכיטקט, או אורי - כבלת את זה יחד עם “מנהל גילדות", כדברים קשורים.מה הם אותם דברים שיצא לכם לראות, שיגרמו לכם לזעזוע הזה ולהחליט לגייס מישהו או לקדם מישהו ולשים את התפקיד הזה?(רון) For fun, הייתי רוצה ששי יענה על זה . . . (שי) בשמחה. מהניסיון שלי, קודם כל, אני חושב שמהרגע הראשון, כדאי שיהיו אנשים שיכולים להתפתח לשם - ויצמחו עם הארגון.זאת אומרת, אפילו שה-Founding-team של הסטארטאפ - ה-Founder-ים והמפתחים הראשונים שהם  מגייסים, שתיהיה להם את ההבנה שהם יצטרכו מתישהו להתחיל להסתכל על התמונה הכללית.מלמעלה יותר, לעשות Zoom-Out.אבל כן - הסימפטומים שאנחנו חווים בארגונים שאין להם את הדמויות האלה, הם ארגונים שבהם קשה מאוד לייצר שינוי רוחבי ביחד.קשה מאוד לנווט, “אנחנו לא אונייה אחת” - אלא אנחנו “צי” של הרבה מאוד ספינות קטנות.אבל הן לא בהכרח כולן שטות לאותו כיוון שאנחנו רוצים שהם ישוטו אליו.ואז צריך להבין איך אנחנו מייצרים להם איזשהו “שייט במבנה”.(רון) “היד המכוונת”(שי) סליחה על השימוש בטרמינולוגיה ימית . . . (אורי) לא, לא. אתה בטוב.(רן) נניח מטוסים, שלא כולם טסים לאותו כיוון . . . (אורי) אני רוצה לשאול את השאלה - זה לא כזה משנה אם יש “ארכיטקט” או לא, משנה אם מישהו “עושה ארכיטקטורה” או לא.(שי) לגמרי.(רון) לא ממש, לא מסכים.בעיניי, ארכיטקטורה זה תוצר אחד - אבל לא היחיד.בעיניי, ארכיטקט - או לא משנה, ה-Title הטכני הזה - הוא נדרש.כשמנהל הפיתוח מבין שה-Velocity של ה-Dev Org שלו הוא לא כמו שהוא היה מצפההוא רואה יותר מדי באגים, הוא רואה יותר מדי עיכובים בלתי צפויים . . . וכל אלה מייצרים איזושהי תובנה עמוקה יותר, שה-Engineering Level הנוכחי -או החוב הטכני הנוכחי, זה בדרך כלל בא ביחד - זה בעייתי מדי כרגע לארגון.ואנחנו צריכים Somehow לדחוף יותר גבוה או יותר למעלה את הארגון.וזה כנראה . . . כוח האדם שנמצא כרגע - כנראה שאין לו את ה-Attention או את היכולת לבצע את זה.אחרת זה כבר היה קורה מאליו.(אורי) או שלא ציפית את זה ממנו . . . (רון) לא ציפיתי מהמפתחת או מה...?(אורי) מכוח-ההאדם הנוכחי - זה מפתחת, זה ראשי צוותים, ראשי קבוצות.(רון) ומה זה אומר? אוקיי, אז בוא נפרוט את זה - מה זה אומר “לא ציפית את זה ממנו”?(אורי) לא הגדרת להם שזה חלק מהתפקיד שלהם.(רן) אורי מאוד מאמין באנשים .  . . אורי, אני קולט את זה עליך.(רון) אבל, אוקיי - אז ה-Signal לאותו מנהל פיתוח, לפי מה שאתה אומר, אורי, זה שהוא רואה את מה שכרגע תיארתי, ואז הוא צריך להבין שהוא לא ציפה את זה מכוח האדם?זה תקשורת.מה שאתה אומר זה שהוא לא תקשר מספיק טוב את הצפיות שלו.(אורי) זו הגדרת תפקיד . . . . אצלנו, הרבה מאוד שנים, אולי אפילו עדיין ככה, תכל’ס - הארכיטקטים של קומפוננטות  (Components) שנמצאות אצל צוותים מסויימים, זה בסוף על הראש-צוות או הראש-קבוצה. בסוף, המצויינות  הטכנולוגית של הצוות שלהם - זה על הראש שלהם.(רון) אבל מי לוקח? . . .  לא, רגע, שנייה - בסוף, יש לך איזשהו ארגון, ולא סתם יש לנו שם מנהל פיתוח, נכון?הוא אמור, אתה יודע, הוא שם את ה... סליחה, “התחת שלו על הגריל”, כן?זה הוא שאמור לקחת את האחריות על התוצרים.(אורי) אבל מתחת לתחת שלו, יש את התחת שלהם . . . (רן) אנחנו יורדים נמוך מאוד פה . . . (רון) בסדר - אבל אפרופו פוליטיקה אקטואלית, מה האחריות המיניסטריאלית שלו? הוא אחראי ל...(אורי) זה נכון שהוא אחראי.(רון) הוא אחראי - אבל הוא אחראי גם על ה-DNA הארגוני. הוא אחראי.ואם ה-DNA הארגוני בסופו של דבר . . . הוא בסוף רואה את התוצרת בעצמו, נכון?וכנראה שהוא לא יכול לבד . . . מה שאני מנסה לחדד פה, זה שאם הוא היה - אם ה-DNA הארגוני היה כזה שבאמת התוצרים היו טובים, זה אומר שהוא תקשר ונתן את הציפיות והשקיע מה שהשקיע והכל, כדי לייצר את המצוינות הטכנולוגית שלדעתי אתה מכוון אליה.אבל אולי אין לו את זהואני חושב שאני קצת כן נותן לך את התשובה, רן - שלא תמיד יש לך את המנהל הכי הכי טכנולוג או שבאמת מודע למקום הזה, של מצוינות טכנולוגיתוהוא צריך את “ה-Wingman שלו” - להלן “ארכיטקט”, או ראש גילדה או What Not - שהוא יהיה זה שמחזיק את הטיקט של האיכות והשאיפה למצוינות ו-Raising the Bar.(שי) אבל איכות זה שאיפה למצוינות . . . (רן) תגיד “אני מסכים, אבל . . . “.(שי) אני מסכים . . . (רן) . . . “עם כל מה שהוא אמר” . . . (שי) . . . . אני אציין ואני אחדד ואני אגיד שמצוינות טכנולוגית ושאיפה למצוינות וכל דבר - הם לא מטרה.הם אמצעי - בסוף, כדי שה-Buisness יהיה יותר מוצלח.ולכן, אני חושב שזה מאוד מאוד נכון שמצוינות טכנולוגית ופוקוס על טכנולוגיה ועל הנדסה, זה אחד מהדברים ש-IC ב-Level בכיר, בין אם אתה קורא לו ארכיטקט או Principal, צריך לעשות.אבל עוד אחד מהדברים האלה שהוא צריך לעשות, זה לעזור לתתי-ארגונים לראות את התמונה הגדולה.לראות לאן הארגון הולך.לא לעשות אופטימיזיה לוקאלית (Local), אלא לעשות אופטימיזציה לטובת הארגון כולו - גם במחיר של ה-KPI's או של ה-OKR's של התת-ארגון שלי.(רון) אני מסכים איתך!(רן) ונעצור כאן . . . .(רון) כן, זהו.(אורי) הייתי כבר בדיון שבו מישהו אמר “אני מבין מה שאתה אומר - אבל זה חרטא” . . . (רן) כולם מסכימים, אבל רבים מסכיב . . .(רון) כן, אני מקווה שזה . . . אין כאן רמז.(רן) ובנימה אופטימית זו - לא אתה, לא הדיון הזה כמובן - כמובן שאני גם מבין מה שאתה אומר.49:47 סיום(רן) טוב, אז בנימה אופטימית זו, ושנהיה מצוינים - ולא לזנב!(אורי) ותקנו בתים שעשו בהם ארכיטקטורה . . . .(רן) לגמרי, ארכיטקטורה זה חשוב!(רון) רעיון טוב . . . (אורי) תוודאו שמישהו עשה.תודה רבה - שי ורון, תודה שבאתם!תודה רבה ולהתראות לכולם. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 483 של רברס עם פלטפורמה, שהוקלט ב-12 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור את אופיר ביבי מחברת Lightricks לשיחה על למה הם כל כך מזוכיסטים, או במילים אחרות - למה ב-Lightricks החליטו שהם רוצים לאמן מודלי Foundational, ויותר מעניין מזה - איך?01:04 אופיר ו-Lightricks(רן)  אז קצת לפני שנצלול לשם - אופיר, ספר לנו קצת על עצמך.(אופיר) אז אני אופיר. אני קודם כל נשוי ואבא שלושה. ב-Lightricks אני מנהל את מחלקת המחקר, אני שם כבר כמעט תשע שנים.ובמחלקת המחקר שלנו, אנחנו עושים בעצם את כל “הקסם שמאחורי הקלעים” במוצרים של Lightricks.והגעתי לשם מתוך המקום - חוץ מזה שבאמת הכרתי חלק מהפאונדרים, וכל הזמן ירון, שהוא ה-CTO שלנו, שאל אותי מתי אני מצטרף - אני רציתי לבנות את המצלמה הכי טובה שיש.ובאתי מהמקום של Statistical Signal Processing וגם של Neural Computation, שזו בעצם התחלה האקדמית שלי.אמרתי “טוב, די, יש חישובים שאפשר לעשות”, כולנו מסתובבים כבר עם המצלמות הכי טובות עלינו, כי הן פשוט בכיס שלנואבל הן לא באמת טובות - פיזית. בואו נעשה אותן טובות יותר.וזה היה האתגר הגדול שרציתי לפתור.וככה התגלגלתי ל-Lightricks, אחרי כל מיני דברים אחרים - כולל אנרגיה סולארית וכו’.ובאמת בניתי את המוצר הראשון שכלל מוצר-מצלמה, אבל כמו שאני חושב שכולנו יודעים, מוצרי-מצלמה שזה לא ה-Stock Camera של הטלפון לא באמת שורדים . . . אז כמובן של-Lightricks יש הרבה מאוד מוצרים אחרים שבנינו והרבה דברים מעניינים שאנחנו עושים.(רן) ורק למקרה שמישהו לא היה בכדור ולא מכיר את Lightricks, אז גם כמה מילים על החברה?(אופיר) כן, אז Lightricks זו חברה שבעצם עושה כלים לעריכת תוכן ויצירת תוכן.אנחנו נותנים הרבה יכולות וכלים ל-Creatives וגם ל-Brands שעובדים איתם ושצריכים להשיג Creatives.יש לנו בסוף, כמו שאמרתי, הרבה מאוד מוצרים שונים. היום יש לנו שלושה מוצרים שהם בפוקוס.בעולם ה-Mobile, שממנו גם הגענו, יש לנו את Facetune, שזה המוצר הראשון והכי גדול שלנו, לעריכת תמונות פורטרט, הידועות בשמן “Selfies”.יש לנו את המוצר החדש שלנו שנקרא LTX Studio, נדבר גם עליו לא מעט.שהוא מוצר ליצירת סיפורים, בסוף, ליצירת וידאו, ליצירת Story Board.שהמנוע שלו זה כבר מנוע ממש מהדור החדש, מנוע גנרטיבי (Generative) כמעט לחלוטין.בסוף הוא איזה שהוא “היברידי” של עולם ישן -  עולם חדש, אבל זה כבר לא “בואו נרנדר (Render) את כל התלת-ממד”, אלא מנוע הרינדור (Rendering Engine) המרכזי הוא Generative Models.וזה גם מוצר שמבחינתנו היה חידוש גם בקהל שהוא פונה אליו, קהל יותר של Professionals, יותר אפילו של Studios, של Enterprises.וגם ב-Web ולא ב-Mobile, אז זה חלק מהחידושים.(אורי) . . . . ויצאתם בעצם מאפליקציה, נכון? כאילו - זה כבר לא בהכרח אפליקציה.(אופיר) כן.  אפליקציה, מוצר - זה בסוף משהו שהיום הוא כבר “פתוח לעולם”. הוא מתחיל מ-Early Access - רשימת המתנה, המוני אנשים שנרשמו. ושוב,  יש לו באמת שתי פניםצד אחד זה הצד שגם היינו רגילים אליו, של אותו Consumer - של פשוט אינדיבידואלים, Creator-ים, אנשים נלהבים שפשוט מגיעים למוצר ומשתמשים בו לצרכים שלהם.ויש לנו בעצם את הצד החדש מבחינתנו, של ה-Businesses - של B2B, של שיווק המוצר ל-Enterprises, ל-Production Houses, שמנסים לעבוד בצוות ביחד על הדברים שמייצרים שם. זה עולם עולם ומלואו.(רן) אז דיברת על Facetune, על LTX - והשלישי?(אופיר) כן, אז LTX Studio, והשלישי זה מוצר שנקרא Popular Pays זו בעצם חברה שרכשנו, שמחברת בין Brands ל-Creators.המטרה שלנו שם זה לאפשר לכל ה-Creator-ים שנמצאים בפלטפורמות השונות שלנו להתחבר עם Brands.ול-Brands לקבל בעצם את ה-Creator-ים ואת ה-Creatives הנכונים ביותר עבורם. גם שם אנחנו מכניסים המון המון חידושים עם AI ועם אלמנטים גם של Tooling ו-Generative AI.ממש עכשיו גם הוספנו שם איזושהי יכולת-ניתוח, שבסוף כשאתה Brand ואתה בא לשתף פעולה עם איזה שהוא Creator אתה רוצה לדעת איזה סוגי-תכנים יש לוהאם הם עומדים בכל מיני דרישות שיש לך - אולי של Safety, אולי של סגנוןלקבל ממש דוח מאוד מעמיק - אבל מהר ואוטומטית, דברים שבעבר היו הרבה יותר קשים, אז . . . (רן) 06:23 מה זה Foundational Models?(רן) אוקיי, עכשיו - לכל כל המוצרים שלכם יש צד ויזואלי מאוד חזק . . . . אז בחלק מהמקרים זה תמונות, בחלק מהמקרים זה וידאו.והזכרת את המילה “ג'נרטיבי” (Generative): הרבה אנשים נתקלו במושג הזה כשהם פגשו את ChatGPT וחבריו, אבל פה אנחנו מדברים על מודל Generative-י שמג’נרט (Generates) או תמונות או וידאו - שזה קצת-קצת יותר מורכב, לפחות מבחינת . . .  טוב, לכל אחד יש את המורכביות שלו, אבל המורכביות פה הן שונות.אז מה . . .  בעצם פה, אנחנו רוצים לדבר על מה זה Foundational Models - למה צריך אותם ואיך לעזאזל עושים את זה? כלומר, אם אני מחר בבוקר רוצה לקום ולהתחיל לאמן מודל כזה - מה כדאי שאדע לפני שאני מתחיל את זה?(אורי) שאתה הולך לישון בערב של . . . 15-יום אחר כך.(רן) אז בוא נתחיל אולי בקצת הגדרה, ככה בקטנה, של מה זה Foundational Model? במה הוא שונה מהאחרים?(אופיר) כן, אז בסוף - Foundational Models, וזה שונה מ-Generative Models, אסור לבלבל בין השניים  . . . Foundational Models זה מודלים שהם כל כך רחבים בידע שלהם, במה שהכניסו לתוכם, שהמשימות שהם מסוגלים לבצע בסוף הן מאוד מאוד מאוד רחבות.זאת אומרת, הידע שעצור בתוך מודל כזה מאפשר לך אחר כך לבוא עם משימות חדשות, ובין אם במה שנקרא Zero-Shot,  פשוט . . . .שוב, למשל במודלים גנרטיביים (Generative Models) של טקסטאז פשוט אני עורך את ה-Prompt קצת אומר לו “בוא, תענה לי על איזושהי בעיה” שהוא לא בהכרח אומן ספציפית לבעיה הזו.והוא פותר לך את הבעיה.למה? כי הידע כבר נמצא שם, מתוך תהליך האימון.לפעמים זה גם לא הסתכלות של Zero-Shot אלא של Few-Shots או Fine-tuning - כמה, בעצם, מאמץ אני צריך לעשות כדי להביא אותו מאיפה שהוא נמצא לאיזושהי יכולת שאני רוצה להגיע אליה.עכשיו, מאחורי הקלעים, מה שזה אומר זה שהמודלים האלה אומנו על כמויות “היסטריות” של Data.הם ראו באמת כל כך הרבה Data, שתפיסת-העולם שלהם, תפיסת-ההתפלגות של ה-Data שעליו הם הסתכלו, בין אם זה טקסט בין אם זה Visuals, היא כל כך כל כך רחבה, שבסוף אם אתה בא, וגם אם אתה מתמקד באזור מאוד מאוד מסוים, רוב הסיכויים שהוא כבר למד משהו, אפילו באופן לא ישיר, על האיזור הזה של העולם.ובמאמץ מאוד מאוד קטן אתה יכול לחלץ ממנו את הידע הזה.(רן) כן, אז לפני כמה שנים - אני לא זוכר, כמה שנים - יצאו עם הקונספט של “בוא נאמן מודלים בשני שלבים”:  אחד זהאימון של ה- Foundational Model עצמו, בין אם זה בעולם השפות, בעולם ה-Video ובמקומות אחרים, ואחר כך נוכל לעשות או להשתמש בו As-is, או בהרבה מקרים לעשות לו איזשהו Fine-tuning, אבל זו פעולה שהיא הרבה יותר קלה.עכשיו, הרבה כאלה שנמצאים בעולם הזה, של מודלים גנרטיביים (Generative Models), פשוט לוקחים Off the Shelf איזה Foundational Model - ועושים לו קצת Fine-tuning, אם צריך. אתם החלטתם שלא. אתם החלטתם לייצר את ה-Foundational Model בעצמו - בעצמכם.למה?(אופיר) אז הרבה סיבות  . . . .הסיבה אני חושב שהמרכזית ביותר זה שב-Domian שלנו, שזה ה-Domain הוויזואלי (Visual), כמעט תמידגם כשהיינו מדברים על הגרסאות הקודמות, של מודלים גדולים, ואם באמת לא בעולם הגנרטיבי (Generative), בעולם הדיסקרימינטיבי (Discriminative)אז היו כל מיני מודלים שהם Pre-Trained, ואז היית מוסיף קצת Data ופתאום יש לך מודל קלסיפיקציה (Classification) או Detection או כל מיני דברים כאלה.אז לבוא ולקחת את המודלים האלה Off-the-Shelf - היסטורית, פתר לנו 20% מהבעיות . . . בגלל שלמשל היינו ב-Mobile, ומאוד מאוד היה חשוב לנו שכל המודלים יהיו יעילים ומהיריםלא יגמרו את הסוללה, יעבדו מהר וכו’אז מצאנו שאנחנו צריכים הרבה פעמים לבנות את המודלים בעצמנואו לעשות תהליכים שהם יותר גדולים, יותר כבדיםכולל Distillation מלא, למשל, של מודלים, ולכן . . .(רן) Distillation - זיקוק . . . (אופיר) זיקוק, בעברית צחה . . . (רן) . . . זה למעשה לקחת מודל גדול, שאולי עושה עבודה טובה, ולייצר ממנו - או על ידו - לייצר מודל יותר קטן, בטכניקה שקיימת שנקרא, Distillation.(אורי) . . . אבל יותר “יעודי”, נכון?(אופיר) אז לפעמים יותר יעודי - ולפעמים לא . . . (רן) לפעמים פשוט יותר “קומפקטי” . . . (אופיר) . . . לפעמים פשוט יותר “קומפקטי” - מה שקורה זה שלפעמים, המודל הגדול הוא מספיק גדול כדי ללמוד את הבעיה, שהיא קשה.ואם היית מנסה ללמד מראש מודל קטן, פשוט בגלל כל אלמנטים של קמירות הבעיה, לא היית מצליח כי אין לך מספיק פרמטרים במודל הקטן.אבל אחרי שהצלחת כבר לאמן מודל גדול - המודל הגדול הזה בכל זאת “חי ביקום של מודלים” - הוא כבר לא חי ביקום של ה-Data.ואז, להוציא מהמודל הגדול את הידע שלו ולהכניס אותו למודל קטן יותר - זו כבר בעצם בעיה “קלה יותר”.אז לפעמים אפשר לקבל מודל קטן בלי לאבד מהאיכות.(אורי) אבל זה קורה על ידי זה שאתה בערך מאתר את “האזורים הטריוויאליים” במודל, ואתה אומר “אוקיי, זה טריוויאלי,” או “את זה אני יודע, את זה לא צריך, זה לא רלוונטי לבעיה”. או בוא נגיד ככה, כנראה שיש איזה מודל שיודע להוציא את הדברים האלה, הלא רלוונטיים, ולעשות את “הזיקוק”.(אופיר) לא, אז הזיקוק נעשה בעיקר מתוך ניסיון לחקות את המודל הגדול.אתה יכול להטות את מה שהמודל הקטן לומד, על ידי באמת לבחור סוג בעיות או סוג Data שאתה רוצה “לזקק החוצה”.אתה יכול גם לבוא ולהגיד “אני רוצה לעבור על כל מרחב ה-Input-ים אי פעם”ואז יכול להיות שזו תהיה בעיה באמת קשה מדי, והמודל הקטן - הוא ילמד משהו מאוד מאוד “טוב”, אבל הוא יאבד קצת באיכותהדיוק יהיה קצת יותר נמוך או משהו כזה.לפעמים - זה מפתיע - לפעמים לא מאבדים באיכות בכלל.ולפעמים אפילו המודל הקטן משתפר לעומת המודל הגדול.זה חלק ממה שקורה בתהליך הזה של זיקוק.(רן) כן, אתה יכול לשפר את הOverfitting . . . אני אוהב לחשוב על זה כעל מורה ותלמיד: זאת אומרת, “המודל הגדול” זה מישהו “בא בימים”, שכבר ראה הרבה הרבה דברים בחייו, ובסופו של דבר הגיע לכמה מסקנות חשובות, ורק אותן הוא מעביר לתלמיד. אז התלמיד יכול להיות יותר קטן, יותר “קומפקטי” . . . .(אופיר) כן.13:35 אוקיי, אז איך עושים את זה?(רן) אוקיי, אז זאת אומרת, ניסיתם כמה דברים. בחלק מהמקרים זה פשוט היה מודל שהוא צרך יותר מדי חשמל, או אולי יותר מדי זיכרון - ובסופו של דבר לא התאים לטלפונים. זו, נגיד, סיבה אחת למה אולי אתם כן רוצים לייצר מודלי-Foundational בעצמכם. ואני מניח שיש עוד - אבל בואו נמשיך הלאה ונדבר על “אוקיי, אז איך עושים את זה?”זאת אומרת, דיברת על (1) יכול להיות שזה מודל שהוא מאוד גדול ו-(2) הוא צריך המון המון Data, וכנראה הרבה מאוד שעות-אימון.(אופיר) כן, אז הרבה מאוד שעות-אימון.ושוב, תמיד מחשבים את זה בשעות כפול כמות החישוב שנכנס פנימה, וצריך הרבה מאוד Data.האתגר אני חושב הוא, שוב - הוא כפול.הדבר הראשון הוא באמת החסמים האלה, של להבין איך מארגנים - ברמה הטכנית, ברמה ההנדסית - את כל הדברים האלה שהם יעבדו.זה דברים שככל שהזמן עובר הופכים להיות יותר קלים, כי גם החומרה וגם התוכנה משתפרות.אבל זה עדיין אתגר מאוד מאוד מאוד גדול, לגרום להרבה GPUs או הרבה TPUs לעבוד ביחד.חומרה נופלת, כי בעולם האמיתי לא הכל עובד כל הזמן . . . בתוכנה יש מגבלות שאם צריך לעבור אותן, אז צריך לכתוב הרבה דברים Custom מעל זה.ואני חושב שבצד האלגוריתמי, מה שקורה זה שכשאתה מאמן איזשהו מודל קטן יותר, וסדר-הגודל של אימון הוא בין שעות לבין ימים בודדים, אתה מקבל כל מיני החלטות החלטות.ואתה צריך לבחון האם ההחלטות האלה היו טובות.אז אתה יכול להסתכל על האימון, לעשות לו Babysitting, אולי אפילו לבוא ולהגיד באמצע אם זה כן עובד לך או לא עובד לך.אבל אתה יכול הרבה פעמים - במקרה של מודלים מאוד קטנים, אפילו לפעמים תוך דקות, או תוך כמה שעות - אתה יכול להגיד “אוקיי, זה מתכנס לי, לא מתכנס לי - אני אחליט משהו אחר, אני אמשיך ככה”.כהשניסויים קטנים, אז אפשר אולי להריץ גם עשרה ניסויים במקביל.כהשניסויים גדולים, אתה מקבל החלטה - והיכולת שלך לשנות אותה היא כבר לא בסדר- גודל של שעות.היא בסדר-גודל של יום, יומיים, לפעמים אפילו שבוע.(רן) . . . זה, אני חושב דרך אגב, משהו שכל מפתח-תוכנה יכול להזדהות איתו: ה-Cycle Time הוא קריטי. אם הזמן  שבין הזמן שביצעת שינויים  בקוד ועד אתה רואה את התוצאה - אם הוא נמדד בשניות בודדות או מילי-שניות, אז זה יופי, “החיים דבש”, אתה פשוט משנה, בודק, משנה, בודק, משנה, בודק - עד שאתה מגיע לדבר נכון.אם זה ימים, אז אתה בבעיה . . . אתה כבר לא זוכר מה עשית. אתה צריך להתחיל לנהל את זה, לרשום לעצמך, “מה זה הניסוי הזה ומה זה הניסוי ההוא”. ואתה צריך להחליט, כיוון שיש לך משאבים מוגבלים - אתה לא יכול לנסות את כל המטריצה הגדולה, אז אתה צריך להמר או לקחת איזשהו ניחוש-מושכל של מה אתה מוכן לנסות ומה אתה לא מוכן לנסות.(אופיר) כן, כן, לגמרי.וללא ספק, אנחנו רואים שיש לנו דברים שאין מה לעשות - בלי לנסות אותם, אי אפשר להחליט מראש.אנחנו טועים, אנחנו חוזרים אחורה, אנחנו משנים - וזה עולה בלא מעט זמן.וזה הופך להיות מורגש . . . (אורי) הרבה קפה? . . .(אופיר) הרבה קפה, הרבה קפה . . . (אורי) . . . .זה כמו ה-Complier-ים ש . . . (אופיר) זה באמת הצוות, שאתה יודע - גם כשהם לא עושים Babysitting, הם עושים Babysitting לאימונים האלה . . . .הם כל הזמן חושבים על זה.אני רואה את הגלגלים בראש - “רגע, אולי אני לא צריך מחר בבוקר, אולי היום, לא יודע מה, ב 11 בלילה, אני אוכל לראות אם האימון הזה מתכנס או לא” . . .“ . . . - ואם לא, אז אני עוצר אותו ואני אעשה את השינוי שחשבתי עליו כבר אתמול, אבל לא יכולתי אפילו לבדוק אותו, ואני אתחיל אותו מחדש” . . . .זה דברים שבאמת אתה רואה אותם גם קורים בפועל, כל הזמן.17:50 איך מתחילים?(רן) כן, אז אוקיי, אז כאילו - איך מתחילים? זאת אומרת, איך אתה בונה? רשתות נוירונים - הרי יש להן מיליארדים שלפרמטרים, ואיך אתה מתחיל עם זה? כאילו מה, אתה מתחיל עם ארכיטקטורה מאפס? אתה לוקח ממישהו אחר? אתה מתחיל לקרוא מאמרים? איך מתחילים?(אופיר) כן, אז ללא ספק מתחילים מלקרוא מאמרים, כמו כמעט כל דבר שאנחנו עושים.וקצת חזרה לבעצם למה . . . בסוף, כשהייתה את ההכרזה הגדולה של OpenAI על Soraמוצר שבעצם הוא לא מוצר היום - כי הוא לא פתוח, הוא לא חשוף, הוא לא מוצר. . . .זה התניע הרבה מאוד תהליכים בקהילה, של גם לנסות להבין ומה קורה, ולעשות השערות.ובאיזשהו מקום זה גם מגדיל את הביטחון של “אוקיי, רגע - אנחנו כל הזמן חשבנו, ואולי כן ואולי לא, ואולי אפשר לעשות את זה, ואולי אי אפשר”ואז “רגע, אם עשו את זה, אז אפשר לעשות את זה” . . . (רן)  כן, Sora, רק למי שלא מכיר, זה מודל שמחולל וידאו. זאת אומרת, כאילו איזשהו Prompt טקסטואלי “תעשה לי סצנה של המערב הפרוע בעיירה, וסוסים וזה” - והוא פשוט עושה את זה.(אופיר) נכון, נכון.ואחרי שיצא לנו לעבוד הרבה עם מודלים גנרטיביים (Generative) של תמונות, ואפילו התחלנו לעבוד עם מודלים גנרטיביים (Generative) של וידאו, אבל שהם היו בסדר-גודל הרבה הרבה יותר קטן,אז הגענו להבנה שאם אנחנו רוצים מודל שיביא אותנו - יום אחד, לא היום - ל-Production-Grade Quality, אז אנחנו צריכים להתחיל.ושיש לנו דרך שבה “כמות הסיכון” היא עדיין מאוד גדולה - אבל זה לא “אוקיי, אף אחד לא ראה כזה דבר, לא חשב על כזה דבר”.אז אני חושב שבשלב הזה זה התניע - זה התניע את זה בהרבה קבוצות, כולל בקבוצות אקדמיות.ולמזלנו גם באמת אותו חוקר שבנה את Sora, היה רגע לפני זה ב-NYU, באיזושהי קבוצה אקדמית שהיא אחת מהבודדות במערב שבאו והשתמשו בכמות Compute מאוד מאוד גדולה כדי לאמן מודלים כאלה.אז הסתכלנו על העבודה הזו בתור הבסיס.תוך כדי תנועה, כמות העבודות המשיכה בשטף כמו שיש היום בקהילה - וזה הכניס עוד ועוד אינפורמציה. לפעמים זה רגע לפני שבאנו לעשות ניסוי - ואז הכנסנו את זה פנימה.לפעמים אחרי שאנחנו כבר חשבנו על הרעיון הזה - ואז היה לזה שם.אבל באמת, כמות האינפורמציה מבחוץ היא מאוד גדולה ומשמעותית.ועדיין,  אני חייב להגיד שזה אחד מהניסיונות שאני מרגיש, בלי צל של ספק, שעד שאתה לא “מלכלך את הידיים” בדבר זה, אין לך מושג.זה הכל תיאוריה, זה ממש ממש הכל תיאוריה.(אורי) אז לי יש שאלה - אתה מדבר פה על זה שיש הרבה תיאוריה וצריך כל מיני מחקרים ואני צריך שיתוף-פעולה עם גופים אקדמיים ובכלל לעשות ניסוי של של אימון כזה לוקח הרבה זמן . . . .  וגם אמרת “אנחנו רצים למרחק הרחוק”.והשאלה שלי - האם יש Feature או מוצר של Lightricks, שאתם אומרים “אנחנו צריכים בשבילו את הדבר הזה בעוד X זמן, כדי לצאת לשוק” - והאם הדבר הזה הוא בכלל “מתחת לאופק”? זאת אומרת, אתם רואים אותו או שאתם אומרים “וואו, יש עוד כל כך הרבה זמן של פיתוח של הדבר הזה” . . . והשקעה ומחקרים וכאילו - פרויקט-מחקרי הוא . . . אתה יודע מתי אתה מתחיל, אתה לא יודע מתי זה יסתיים.(אופיר) נכון, אבל שוב: אני חושב שפרויקט-מחקרי בתעשייה - כמעט אף פעם אי אפשר לבוא ולהגיד “אני יודע מתי זה מתחיל” . . . אפשר להגיד “איך” זה נגמר, אבל מתי זה נגמר או Milestones - תמיד חשוב שיהיו.במקרה הזה, LTX Studio היה לנגד עינינו.עכשיו, קודם כל רגע מבחינה מוצרית - המוצר לא מכוון כרגע לייצר Production Videos.עשינו את זה, שמנו פרסומת באולימפיאדה - של eToro, שיצרו מההתחלה ועד הסוף בתוך המוצר,האיכות הוויזואלית שם היא טובה,להגיד לך שזה נראה כאילו צילמו שחקנים בחוץ בעולם האמיתי? זה לא.המטרה של LTX Studio הייתה קודם כל לייצר את ה-Storyboarding ואת ה-Pre-Production, את השלבים האלה.ובתוך הדבר הזה, אחד הדברים הכי משמעותיים מבחינתנו היה לבוא ולראות שאנשים שעובדים עם המוצר, יכולים לעשות איטרציות מאוד מאוד מהירות.בסוף אנחנו נתנים את זה לאנשים שצריכים להיות יצירתיים - חושבים על רעיון, רואים תוצאה, עושים איטרציה (Iteration), משנים אותה וכו’ וכו’.בגלל זה המהירות הייתה מאוד מאוד חשובה לנו - אמנם הפעם זה דברים שרצים ב-Backend, על שרתים מאוד מאוד גדולים ולא ב-Mobile,ועדיין המהירות הייתה מאוד חשובה.זה, יחד עם שוב - לטווח הרחוק אנחנו רוצים להגיע גם ל-Production Grade Quality, ברמת הווידאו שאנחנו מייצרים.היום זו לא הייתה המטרה המרכזית.המטרה המרכזית הייתה שיהיה וידאו שהוא נראה איכותי, קונסיסטנטי (Consistent).שהוא מסוגל לייצר וידאו יותר ארוך - תנועה יותר “מעניינת”.המודלים הראשונים של וידאו יצרו תנועות מאוד עדינות, שנראו טוב - וככל שהתנועה הלכה וגדלה זה נראה פחות מציאותי.וכן, ללכת ולהרים את הרמה באופן המשכי - ובאותו הזמן גם שוב: השתמשנו במודלים גם שפיתחנו פנימית, שהם הרחבות של מודלי-תמונה.השתמשנו בדברים שהגיעו באמת מהקהילה של הקוד הפתוח, מ-Stability, עם רישיונות וכו’ וכו’,אבל דברים שהתחילו להיות מפורסמים, מחברות יותר גדולות - לא היה נראה שזה הולך להיות משהו פתוח.ולכן האמונה שלנו הייתה א' - יש לנו צרכים ספציפיים שלנו.אנחנו מבינים את המוצר שלנו, אנחנו מבינים מה אנחנו רוצים לבנות.והדבר השני זה שאנחנו לא רואים מישהו שפשוט מגיש לנו את זה על מגש של כסףגם אם במחיר של License כזה או אחר.דרך אגב, היום כל מיני חברות כאלו ואחרות שמציעות את המודלים הגנרטיביים (Generative models) שלהם לוידאו ב-APIs - העלויות שם הן אסטרונומיות.לייצר וידאו ב-APIs שלהם מאוד מאוד יקר.אם היינו מגלגלים את כל הדברים האלה ללקוחות שלנו, היינו פוגעים בסוף בחוויה שלהם ובמוצר - ועל הדרך, גם אף אחד מהם לא עושה את זה מהר.אז הם לא נתנו את הפתרון הזה.ברגע שזה גם היה הפוקוס שלנו, יכולנו לקחת צוות שלם - שהפוקוס שלו זה עכשיו לקחת את כל הידע שהם הביאו מבחוץ.וכן הלכנו על דברים סטנדרטיים, מבנים שמשתמשים ב-Transformer-ים, שזה היה הדור החדש של מודלי דיפוזיה (Diffusion Models).להשתמש ב-Latent Diffusion - זאת אומרת שיש שם מודל נוסף, שזה ה-Encoder, ה-VAE, ה-Variational Auto-Encoder.והיה מאוד מאוד חשוב לנו לוודא שכל הדבר הזה הוא יעיל, מהיר - ועונה על הצרכים שלנו.מסוגל לייצר וידאו “שנראה טוב” - שעונה ל-Prompt בטקסט, שמסוגל להתחיל מתמונה אולי שהביאו מבחוץ גם.כי בסוף שוב - אנשים קריאיטיביים, יש להם חזון. הם הרבה פעמים מייצרים Asset-ים גם אולי במקומות אחרים.וממש לענות על כל הצרכים שלנו.26:10 מדברים מדע בכמה מימדים(רן) בוא נדבר קצת מדע: הזכרת את המילה Transformer-ים, ואני בטוח שהרבה נתקלו בזה לפני זה - אבל דווקא בעולם השפות. (אורי) גם פה, בפודקאסט, הסתובב איזה Transformer אחד או שניים . . . .(רן) בטוח, בטוח, כן [נגיד לאחרונה - 475 Jamba with Hofit from AI21].אז בעולם מודלי השפה, Transformer-ים זה אלה שיודעים לתת תשומת לב לכל מילה [Attention Is All You Need], ו-Transformer-ים בעצם עובדים מ-Sequence אחד ל-Sequence הבא.עכשיו, כשמדובר על משפטים, אז אתה יכול לחשוב על תרגום, אתה יכול לחשוב על יצירה של טקסט, אתה יכול לחשוב על דברים כאלה. Transformer-ים הם מאוד נוחים, והם עובדים על Token-ים, שאפשר לחשוב על זה כמו על מילים. אוקיי . . .אבל פה זה תמונות, זה לא משפט. זה לא מערך חד-מימדי - זה מערך דו-מימדי.וכשזה וידאו, אז מה זה? זה תלת-מימדי? לא יודע איך מתייחסים לזה . . . .אז איך אתה מתרגם Input שעכשיו הוא דו-מימדי? אוקיי, במקרה הטוב, אולי תלת-מימדי . . .  איך אתה מתרגם Input כזה ל-Transformer, שבכל אופן למיטב-ידיעתי עדיין רוצה משהו שהוא חד-מימדי.זאת אומרת, איך אתה לוקח תמונה, והופך אותה לאוסף של Token-ים שה-Transformer-ים ידעו . . . Sequence של Token-ים שה-Transformer “ידעו לדבר איתם"?(אופיר) כן, אז המהלך הזה קרה כבר כמה שנים אחורה, עם מודלים שנקראו ViT, שזה Visual Transformerשבעצם עוד בעולם התמונות, מי שראה את זה מגיע, ראה את ה-Attention, ראה את ה-Self-Attention, את ה-Cross-Attention שיש ב-Transformer-ים,וזה באמת נשמע מאוד מאוד טבעי ב-Token-ים ובשפה.אבל כשאתה מסתכל רגע על מה המודל עושה, אז הוא פשוט “מאפשר לך יותר”.זה גם עולה יותר - הוא ריבועי באורך ה-Sequence, יש שם אינסוף מקומות שהיום מנסים לגרום לדברים האלה לעבוד גם בצורה יעילה יותר ברמה המתימטית או האלגוריתמית, על אותו Attention מלא.אבל בעצם באו ואמרו רגע - יש לנו פה Sequence. זו לא פעם ראשונה שניקח סיגנל דו-מימדי - במקרה שלנו תמונות - ונכניס אותו לאיזשהו חד-מימד.אפילו שאין איזשהו Cardinality, כן? איך אני עובר על התמונה - מימין לשמאל, מלמעלה למטה? אם אני הופך את הסדר, מה זה עושה?(רן) כן, זאת אומרת, לצורך העניין - אם אתה מסתכל על התמונה כאל Bitmap, פשוט לקחת את הפיקסלים, מאחד עד מיליון, זה כנראה לא יעבוד . . .  כי יש איזשהו מבנה לתמונה.(אופיר) נכון, נכון, אז יש איזשהו מבנה לתמונה.ובעצם, המודלים הראשונים שעשו, הם היו דיסקרימינטיביים (Discriminative) - הם באו לעשות קלאסיפיקציה (Classification), או לעשות . . . לפעמים, באיזשהו שלב נכנסו כבר לאיזורים גם של סגמנטציה (Segmentation), שזה גם ממש לייצר תמונה בצד השני.אבל שם השתמשו ב-Patch-ים - לקחו Patch-ים של התמונה.ואחד המאמרים הראשונים, אם לא ממש הראשון, היה נקרא A Token is Worth a Thousand Pixels [הכוונה ל-An Image is Worth More Than 16x16 Patches?]ובעצם שם ממש הסתכלו על איך לוקחים Patch-ים של התמונה, ועושים להם טוקניזציה (Token).במקום מילה - או חלקי מילה, נכון, לפעמים זה גם שתי מילים ביחד, שהופכות לאיזשהו Token - אז פה גם איזשהו Field of View על התמונה.דו-מימדי, במקרה של תמונות, וכן - תלת מימדי במקרה של וידאו - הופך ל-Token.היה שם מחקר שלם, על מה גודל ה-Patch המתאים ביותר - במשימות שונות, גדלי Patch-ים שונים, היו . . . (רן) כלומר - לוקחים מלבן, או אולי אפילו ריבוע מהתמונה, ורואים כל ריבוע, נגיד הפינה השמאלית העליונה? זה Token אחד. אחר כך ניקח אחד ימינה - זה Token שתיים. Token שלוש - אולי יש חפיפה ביניהם אם זה הגיוני, אבל בגדול, אתה אומר “ככה אתה עושה טוקניזציה” (Tokenization) של התמונה. ומסתבר שזה עובד לא רע עם  Transformer-ים.(אופיר) זה עובד לא רע.מה שהוסיפו לזה . . . הדבר הראשון שהוסיפו מעל זה זה מה שנקרא Positional Encoding.שזה עוד איזשהו מידע, שאתה מכניס ב-Input כדי להגיד רגע מאיפה הגיע אותו . . . .(רן)  . . . בדיוק, שתדע שזה מהפינה השמאלית העליונה, ואז מהפינה ליד וכו'.(אופיר) בדיוק. ואז מה שראו זה שהתכונה הכי גדולה של Transformer-ים זה שהם Scalable, אוקיי?הם באמת רפיטטיביים (Repetitive), יחסית, באיך שהם עובדים.הם אפשרו, במודלי השפה, להכניס יותר Data, יותר פרמטרים - ולהגדיל אותם.וממש הראו שזה עובד אותו הדבר על Token-ים שהגיעו מ-Modality אחר - לא של טקסט, אלא של תמונותומאוד מהר הם היו ה-Benchmark של התוצאות הטובות ביותר מבחינת מודלים דיסקרימינטיביים (Discriminative).ואחרי - אני בעצם קצת קופץ קדימה - פריצת מודלי הדיפוזיה (Diffusion Models) . . . (רן) כן, בואו רק נתרגם - דיסקרימינטיביים (Discriminative), כלומר: “אפשר לסווג תמונות של חתול וכלב” וכו’, זאת אומרת, השימושים האולי יותר “קלאסיים” של מודלי השפה. לזהות פנים, לזהות זה - אבל עדיין לא לייצר תמונות  חדשות.(אופיר) עדיין לא לייצר תמונות, כשבעצם, שוב, איך עשו את זה?אם, נכון ב-GPT רגיל - אתה מאמן אותו ל-Next-Word Prediction? אז אתה מכניס את ה-Sequence שלך, ושואל אותו “אוקיי, מה ה-Token הבא שאתה רוצה לייצר?”אז פה הכניסו את ה-Sequence של התמונה - ויצרו עוד איזשהו Token כאילו . . . .(רן) “החביאו חלק מהתמונה?”(אופיר) כן . . . לא. אז בגנרטיבי (Generative), “החביאו” חלק מהתמונה, וכך יצרו את זה - אבל עוד בדיסקרימנטיבי (Discriminative), בעצם באו ואמרו “יש Token ‘אחרון’, שבמקום להיות הנקודה בסוף המשפט, הוא “תגיד לי איזה Class זה’”, נגיד של קלאסיפיקציה (Classification).עכשיו, במקום להגיד “אוקיי, תן לי רק עוד Token אחד שהוא כמו הסוף משפט”, החליפו אותו בקלאסיפיקציה (Classification) . . . (רן) מה שנקרא Surrogate Task, כמו שמאמנים Embeder-ים.(אופיר) בדיוק.אז באו ואמרו, אוקיי - עכשיו אני, יש לי איזושהי אינפורמציה שנכנסת, “בוא תיתן לי את הדבר הבא”.אז המודל של השלמת מילה, עובד אותו דבר ב-Inpainting, מה שנקרא “מילוי חורים בתמונות”זה ממש אחד לאחד.באיזשהו שלב גם נכנס הסיפור המולטי-מודלי (Multi-Modal)זאת אומרת, אני נותן לו Input טקסטואלי - ומצפה ממנו לייצר בעצם תמונות.(רן) שזה למעשה מה שאתם צריכים, כנראה, במוצר, נכון? בסופו של דבר, ה-User לא נותן לך תמונה ומצפה לקבל תמונה, הוא רוצה לתת תיאור . . . .(אופיר) לאו דווקא . . . גם וגם.זאת אומרת, הרבה פעמים רוצים לתת תיאור, אבל אם אתה תשאל את רוב האנשים, זאת אומרת, רוב ה-Use-Cases-ים, דרך אגב, של Lightricks, היו “תן לי תמונה - ותייצר לי תמונה ממנה”כשיש איזשהם Instructions . . .(רן) זאת אומרת איטרציה (Iterations) על תמונה - שיפורים לתמונה, ניקויים וכאלה . . . (אורי) זה מה שקורה כשאתה מבקש וריאציות על Image.(רן) כן. אז למעשה המודל צריך גם להבין את ה-Input מה-Modality של תמונה, וגם את ה-Input מה-Modality של הטקסט, ולהבין, בהינתן שניהם, מה הולכת להיות התמונה הבאה.(אופיר) נכון, נכון.(אורי) והטקסט הוא יהיה Prompt? בצורה של Prompt?(אופיר) כן. אז הטקסט הוא, שוב - זה מאוד תלוי איך מאמנים את המודלים.זאת אומרת, למשל, במודל הוידאו שאנחנו מאמנים עכשיו, ה-Prompt הוא מאוד דיסקריפטיבי (Descriptive), כן?הוא מתאר את הסצנה, את הפעולות שקורות, את התנועה של המצלמה, כל מיני דברים . . .(אורי) האם יגיע יום שאפשר . . . שנוכל לדלג על כל ה-Production, ופשוט ניתן את ה-Script למודל, את “התסריט” שאנחנו רוצים, ו...(אופיר) . . . ולקבל משהו . . . אז אנחנו, אני חושב שהיום ה-Flow שיש, למשל, ב-LTX Studio, מאפשר לך את זה, ברמה מסוימת.אני לא חושב שאנחנו, או, נגיד אותם אנשים שהיום אתה סומך עליהם להיות ה-Creatives, שמייצרים את הדבר שאתה תרצה לראות גםהם אוהבים את דרגות-השליטה שלהם.ולא רק כי זה כיף להם, אלא כי בסוף אתה יכול לתת Script, ואז אתה רואה את התוצאה, ואתה רוצה לשנות קצת כל מיני דברים, ואתה רוצה לשנות דברים, לפעמים, ברמת ה-Pixel, אוקיי? . . . זה באמת חבר’ה שהם אובססיביים לגבי ה-Pixel-ים שלהם - ולגבי הסיפור שהם מספרים, והעוויתות בפנים של הדמות שיצרת. אז כבר היום, אחד ה-Flow-ים שיש ב-LTX Studio זה “תן לי Script”.“תן לי Script” - ואני מייצר לך סצנות, ו-Shot-ים בתוך הסצנות, וממש את הכל.(אורי) אבל זה, כאילו, “חומר הגלם” שעליו אתה מתחיל את העבודה אחר כך, נכון?(אופיר) נכון, אבל בסוף זה בדיוק העניין, אני נותן לו את ה-Shot-ים - וזה Still Photos, ואז הוא יכול להחליט איך התנועת מצלמה נראית.עכשיו, זה, אם הוא נתן לי את ה-Shot-ים כבר, והוא נתן לי גם תנועת מצלמה, מה שבתהליך Production די ארוך מגיעים אליו בסוף, גם בסרטים.זאת אומרת, כשאני בא לצלם Shot מסוים, האיש מאחורי המצלמה יודע מה הוא אמור לעשות.הוא לא כזה “טוב, אני אחליט תוך כדי תנועה אם אני אזוז ימינה או שמאלה, או אעשה Dolly”.הוא יודע מה הוא אמור לעשות באותו Shot, הוא קיבל את ההוראות האלה מראש. אז התהליך של הבנייה זה - אם עשית את כל העבודה מראש, איכשהו, “עם נייר ועט” - מצוין, תכניס לנו את הדבר הזה, ואז זה גם יוכל להגיע.אם לא - המטרה של המוצר, זה בדיוק . . . .זה בדיוק הסיפור של מוצר מעל Foundational Models, כי Foundational Models יודע לייצר יש אחד שיודע לייצר תמונות, אחד שיודע לייצר Video-יםידיע לייצר Video-ים מטקסט, יודע לייצר Video-ים מטקסט ותמונה, ידיע לייצר Video-ים מ-Video-ים, כן . . . אבל כל הדברים האלה צריכים להיכנס איכשהו לתוך Flow - שאנשים מבינים מה הם עושים, מה הם מקבלים, במה הם שולטים, במה הם לא שולטים.ושם אני חושב שנשאר.[(אופיר) לשאלת ה"מה עושים עם זה?" - האינטרו עשוי ב LTX Studio והסצינה הראשונה, עם עריכות של הבמאי: ארץ נהדרת עונה 22, פרק 1, 06.11.24  -  המושבה הישראלית ביוון]36:40 על חומרה, כסף ותרומה ל-Open Source(רן) אוקיי. בואי נדבר קצת על חומרה וכסף, מה שאפשר לספר . . .  אז כמה בעצם מודלים כאלה אימנתם, Foundational? אחד? יותר?(אופיר) אז שוב - היסטורית, אימנו הרבה, בעיקר בהתחלה של תמונות.באיזשהו שלב אני חושב ש”הבעיה”, נקרא לזה, של Foundational Models ליצירת תמונות הפכה להיות יחסית “Commodity”.ושם באמת עברנו לעשות דברים יותר שדומים ל-Finetunes ודברים מעל מודלים אחרים.(רן) ובעולם הוידאו?(אופיר) ובעולם הוידאו, אימנו מודל אחד מרכזי - יש לו הרבה גרסאות מאחורי הקלעיםכמו שאמרתי, זה הרבה “דם, יזע, דמעות ו-Compute” . . . (רן) “לכל Checkpoint יש שם” . . . (אופיר) “לכל Checkpoint יש שם” . . . ולמודל יהיה איזשהו שם, שנחליט עליו כשאנחנו מוציאים אותו.אבל היום יש לנו בעצם מודל אחד שאנחנו רוצים גם להוציא ל-Open Source [הנה - LTXV - The First Real-Time AI Video Generation Open Source Model]שהמטרה שלו זה באמת לאפשר לקהילה, שאנחנו מרגישים שאנחנו נתרמים ממנה המון - ולתרום חזרה ולאפשר להם לבנות דברים מעל זה.וגם הצרכים שלנו הם יחסית תואמיםזאת אומרת, אנחנו רצינו מודל שיהיה מאוד מאוד יעיל ומהירבקהילה הרבה פעמים, אתה רואה שיוצאים כל מיני מודלים שיודעים לרוץ על חומרה “גדולה” של nVIDIA כזה, A100, H100 וכו’.ואז אנשים יושבים בבית שלהם ושואלים “רגע, איך אני מריץ את זה על ה-4090 שלי?”, או “איך אני מריץ את זה” - חס וחלילה - “על 3080?” . . .ופתאום הם מתקשים עם זה. אז המודל שאנחנו רוצים להוציא לקהילה הוא מודל של שני מיליארד פרמטרים, שזה מודל יחסית קטן(רן) גם בעולם השפות זה נחשב קטן . . .(אופיר) זה נחשב מאוד מאוד קטן . . . (רן) בדרך כלל “שבע” [7 מיליארד פרמטרים] זה “קטן”, 1-2 [מיליארד פרמטרים] זה “קטנצ’יק” . . . .(אופיר) כן . . . (רן) . . .  והגדולים הם באזור המאות-מיליארדים או יותר.(אופיר) נכון.אז מודל 2B, שדווקא החלק החשוב והמשמעותי בו זה ה-Autoencoder שלו.אנחנו ממש בנינו אותו מ-0 לצרכנו, את כל המודל.וב-Autoencoder אנחנו ראינו שהתייחסות לוידאו כוידאו - לא לקחת Autoencoder שהיה של תמונות, וקצת “לנפח אותו”, קצת להוסיף עליו ולעשות לו Patching.בעצם להסתכל על זה - ממש כמו ששאלת קודם - כתלת-מימד.יש לנו מימד שלישי, שהוא מימד הזמן, אנחנו רוצים לעשות דחיסה בצורה שהיא מאוד מאוד יעילה גם כדי שכל המודל יהיה יעיל, גם כדי שהלמידה תיהיה יעילה, כדי שלא תיהיה יתירות במידע שמגיע מה-Autoencoder.וכל הדבר הזה יצר בעצם איזשהו Autoencoder עם יחס-דחיסה מאוד מאוד מאוד גדול . . . (רן) כלומר לקחת את ה - Raw Video ולהפוך את זה ל-Stream של משהו שעליו אפשר להתאמן?(אופיר) כן. זה מה שנקרא בעצם Latent Code, זה לעבור מה Image Domain או הVideo Domain ל-Latent Codeבמקרה שלנו, בגלל שבנינו את זה ייעודית לצרכים שלנו, ה-Autoencoder ממש מוציא את ה-Token-ים שנכנסים לתוך ה-Transformer, שעושה את ה-Diffusion ישר אחריו.(רן) אז Video2Vec, פחות או יותר . . . .(אופיר) Video2Vec.(רן) אוקיי, אז רגע - עוד לא דיברנו על כסף . . . . אז יש פה מודל, שאמרת שהוא יחסית קטן, אבל בכל אופן אני מניחשעלה לא מעט לאמן אותו. אז על איזה גודל Cluster צריך לאמן את זה? כמה זמן זה רץ? ואם יש לך גם בסוף דולרים לספר לנו, אז זה גם יהיה מעניין למי שירצה לעשות את זה בבית . . . (אופיר) כן, אז דווקא נתחיל מהסוף - אני חושב שקודם כל, את הדולרים הספציפיים אני לא אחלוק.אני כן יכול להגיד שכדי להגיע מהמקום שאתה מתחיל מאפס למודלים איכותיים, עובדים, זה “מיליוני-דולרים רבים”, בסדר? זה דברים שיש שם איזשהו חסם-כניסה.אבל בסוף, ככל שהדברים האלה מתקדמים, כן תהיה את האופציה בדיוק לאנשים לקחת מודל כמו המודל שאנחנו משחררים.לעשות עליו אדפטציות (Adaptations), לעשות באמת לא רק “Finetunes פשוטים” אלא לעשות דברים הרבה יותר גדולים ומשמעותיים.וגם לדעת שהארכיטקטורה שהם קיבלו היא ארכיטקטורה שיכולה לעבוד - זאת אומרת, הם לא עכשיו “יורים בחשיכה”.ברגע שאתה כן עושה את כל הניסויים האלה ומנסה להגיע לאותן רמות, שאתה לא מקבל סתם ככה “מהמדף” מה-Open Source, אז יש הרבה ניסוי וטעייהוכמו שאמרנו בהתחלה - הם לוקחים הרבה זמן, על הרבה Compute.עכשיו, כשאני אומר “הרבה Compute”, אז גם - זה לא . . . .בלי להיכנס למספרים הספציפיים, אנחנו - את רוב האימונים הגדולים שלנו עשינו דווקא על TPUs, שזו החומרה של Google.זאת אומרת, השתמשנו הרבה גם ב-GPUs לאימונים קטנים יותר - להכנה של ה-Data, עושים הרבה Captioning של ה-Data כדי שה-Input-ים ללמידה יהיו “נקיים”.כי אני אם אתה מביא וידאו ואת התיאור שמישהו כתב - זה בדרך כלל יהיה חצי-קשור למציאות.והיום יש מודלים - שוב, דיסקרימינטיביים (Discriminative) בסופו של דבר, אנליטיים - שיכולים לתת Caption מאוד מאוד איכותי.וברגע שמסתכלים על האימון “הגדול” - באימון הגדול אתה צריך הרבה מאוד Tera-flops, אתה צריך הרבה מאוד Core-ים.זה ברמת המאות של Chip-ים - כשבעצם, לכל Chip יש לא מעט גם Cores פנימיים . . .אבל הסדרי-גודל זה “עשרות” לניסויים “קטנים”, “מאות” לניסויים “גדולים".ובסוף - זה הכל עניין גם של קצב: ברגע שאתה פורץ את מחסום ה-Scale, אז ככל שאתה נותן לי יותר Chip-ים, אני פשוט מגיע לתוצאות יותר טובות יותר מהר.(רן) אז יש כמובן את האתגרים הנדסיים, שקצת-קצת הזכרת בהתחלה, אבל לא היה לנו זמן להיכנס אליהם - של איך לנהל Cluster כזה, איך לעשות Redundancy, איך לטפל בשגיאות - כי אתה לא רוצה שברגע שיש שגיאה אחת אתה צריך להתחיל מחדש ימים או אולי שבועות של אימון . . . אתה רוצה להיות מסוגל להתאושש בקלות משגיאות כאלה. ודיברת על זה שלפעמים אתם עושים לתוכנה או לחומרה “יותר ממה שהתכוון המשורר" שתעשו לה - ואז צריך לכתובדברים קצת, “לתפור את הדברים ידנית” כדי שזה יתאים למגבלות הזיכרון ושאר מגבלות החומרה.כל זה שריר ונכון - אבל לא נוכל להיכנס לזה, כי זמננו עוד מעט נגמר . . .44:02 אז איך מתחילים?(רן) אבל אולי ככה מילה אחרונה - אז ברגע שתשחררו את זה, או שאולי בזמן שאנחנו נפרסם את הפודקאסט כבר שיחררתם את זה [שוחרר! LTXV - The First Real-Time AI Video Generation Open Source Model] - מה בעצם אנחנו - זאת אומרת “ההדיוטות בבית” - יכולים לעשות? זאת אומרת, מורידים את המודל הזה, מוצאים GPU מספיק חזק, וכמו שאמרת לא צריך נורא חזק אבל מוצאים GPU מספיק חזק, שיודע להריץ את זה, ואפשר מה -  פשוט לייצר Video-ים?(אופיר) כן, אפשר יהיה לתת לזה פשוט טקסט ב-Prompt - ולקבל וידאו שתואם ל-Prompt.אפשר יהיה לתת לזה תמונה בתור ה-Frame הראשון שאתה רוצה וגם איזשהם Directions של לאן ללכת משם. ואפשר יהיה לתת וידאו ולהגיד לו איך לערוך את הוידאו הזה בעצם.(אורי) אבל אנחנו נצטרך להריץ אותו - אצלנו?(אופיר) או בשירות בענן, שיהיו הרבה שירותים שיריצו את זה.(אורי) כן - אבל זה לא שירות, אתם לא מתכוונים לתת שירות כזה . . .(אופיר) לא, אז אנחנו ניתן את זה בתוך המוצר שלנו - איזושהי גרסה, שיהיו בה גם דברים נוספים.אבל זה בתוך המוצר של LTX Studio.(אורי) אבל אם לקחתי את ה-Open Source הזה ואני רוצה עכשיו לשפר אותו ולאמן אותו, אז אני כנראה אצטרךלעשות, כאילו . . . יש איזשהו Barrier to Entry מאוד גדול בכסף, נכון?(אופיר) אז אם זה רק אימון של Finetunes ו-LoRAs, כל הדברים שבעצם באים ומוסיפים מעל המודל הזה, אז ה-Barrier הוא לא כזה גדול.זאת אומרת, זו המטרה גם בלשחרר מודל כזה לקהילת ה-Open Source - שהם בדיוק יוכלו לעשות את  האימונים האלה.שהם יותר קטנים והם ב-Scale הרבה יותר קטן.גם מבחינת Data - זאת אומרת, אם אנחנו רואים עשרות-מיליוני Data Points, אנשים עושים Finetunes למודלים עם עשרת-אלפים Data Points . . .(אורי) כן.45:57 סיום וגיוסים(רן) אוקיי אז קודם כל תודה על התרומה חזרה לקהילה! אני מקווה שיהנו מזה.וכאן אנחנו מסיימים . . . אולי רק לפני זה, עוד כמה מילים על Lightricks? אז מה - אני מניח שכמו הרבה חברות אחרות, אתם תשמחו לפגוש אנשים . . . .(אופיר) כן בוודאי - אנחנו מגייסים ב-Lightricks  כל הזמן, להרבה מאוד משרות.ספציפית גם אצלי בקבוצה אנחנו מגייסים חוקרים, גם כדי לעבוד על האתגרים של אימון מודלי-Foundationalגם לצוותים שעובדים על המוצרים שלנו ועל ממש State of the Art שימוש ב-Generative AI לכל דבר כמעט שאנחנו עושים.תמיד עשינו Generative AI, גם לפני שזה היה Buzzword מאוד מאוד גדול - ואנחנו שמים את זה בחזית אצלנו.(רן) “שמים את ה-”Gen” ב-”GenAI”” . . . [וגם כאן - 417 Developer Growth with Barak Yoresh from Lightricks][והנה המודל והתיעוד וכל מה שאתם צריכים - LTXV - The First Real-Time AI Video Generation Open Source Model]טוב - אז תודה רבה, אופיר, והצלחה! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 482 של רברס עם פלטפורמה - באמפרס מספר 84: רן, דותן ואלון עם סדרה של קצרצרים שתפסו את תשומת הלב בתקופה האחרונה - בלוגים מעניינים, דברים מ- GitHub, וכל מיני פרויקטים מעניינים או דברים יפים שראינו באינטרנט וחשבנו לאסוף ולהביא אליכם.לצערנו לא יצאנו להקליט די הרבה זמן, כמעט חצי שנה -  אבל הנה עכשיו אנחנו שוב פה.00:52 רן - DSPy, סקרים, Code Assistants Wars ו-Self-Driving code(רן) אז אני אתחיל : אחד הדברים שיוצא לי להתעסק בהם בזמן האחרון זה עבודה עם LLM-ים, אולי כמו רבים אחרים.ואחד הדברים שעושים בעבודה עם LLM-ים, זה “תופרים Propmt-ים, נכון?צריך לוודא שה-Prompt נכון, שהסיומת נכונה, שמבקשים יפה, שעושים Chain of Thoughts, שעושים כל מיני ש*ט כאלה, כדי שהדברים יעבדו - ולפעמים נראה כאילו זה איזשהו Witchcraft שאמור כבר לעבור מהעולם . . . .כאילו, למה זה משנה אם אני שם סימן שאלה בסוף המשפט או לא? אם אני שם פסיק או לא? כאילו, הוא אמור להבין אותי, לא?אז המציאות היא שלפעמים כן, ולפעמים לא . . . זה כנראה גם תלוי באיכות ה-LLM.אבל תמיד חיפשתי איזושהי דרך קצת יותר מתודולוגית, אולי קצת יותר מדעית, לבוא ולייצר Propmt-ים בצורה שהיא פחות “Black Magic” כזה.ואז, נתקלתי בכלי - ספרייה - שנקראת DSPy.ו-DSPy בעצם מתיימרת לעשות דבר כזה: למעשה, אתה מציב לה מטרה.אתה בא ואומר “אני רוצה סוג כזה של Output”אתה מגדיר איזושהי פונקציה שבוחנת את האיכות של ה-Output, ומגדיר לה את ה-Input-ים.והיא מנסה, על סמך זה, לעשות ניסוי וטעייה - בעצם לטייל באיזשהו גרף של טקסטים שהיא מייצרת, על מנת למצוא את ה-Prompt האידיאלי ל-Use Case שלך.אם זה נגיד, הזכרנו Chain of Thoughts, אם זה להגדיר דוגמאות - זאת אומרת, לתת 2-3 דוגמאות, אולי אפילו לתת מקרים שהם “קשים”זאת אומרת, למצוא את הדוגמאות המעניינות, כדי לתת.ובסופו של דבר, מספקת לך Prompt בצורה שהיא “חצי-אוטומטית”, נקרא לזה, שעושה אופטימיזציה ל-Use Case שלך.אז אפשר לחשוב על זה כמו על סוג של בניית Prompt אוטומטי, אם אתה יודע להגדיר את זה כמו שצריך, אם אתה יודע להגדיר את הצרכים שלך כמו שצריך.למי שיצא להתעסק בעולם הזה, יכול להיות שהוא מכיר ספריות או כלים אחרים, כמו נגיד, LangChain או LlamaIndex - זה לא אותו דבר. הם דואגים לאספקטים אחרים של הפיתוח.ו-DSPy למעשה מתממשק אליהם - זאת אומרת, הם “מכירים אותו”, ואפשר לעבוד איתם ביחד.(אלון) אי אפשר להחליף את זה ב-LLM? כלומר, אני נותן ב-LLM את ה-Prompt, ואומר לו “תכתוב Prompt נורמלי” - כותב לי Prompt נורמלי, וזה עובד . . .(רן) ומה אתה חושב שהם עושים?(אלון) אז מה צריך אותם? . . . .(רן) אז כן, בגדול, כאילו, “זה שילוב של כן”א', הם משתמשים ב-LLM, זה כן.אבל חלק מהאתגר זה לבוא ולמדוד את האיכות של התוצאה - וזה משהו שהם עוזרים בו.וגם בלפרמל את הדברים האלה.אבל בסופו של דבר, מתחת לפני השטח, כן - הם גם עושים את זה.אבל ללכת ולהגיד ל-LLM “תייצר לי Prompt אידיאלי” - הוא אולי ייצר לך משהו, אבל החלק המאתגר ביותר זה לבוא ולעשות איזו אופטימיזציה.זאת אומרת, לדעת שהוא באמת אידיאלי, לדעת שלא עשית ממש . . . .  שאין איזשהו שינוי קטן, שיכול לעשות את זה קצת יותר טוב, בקיצור.אז זה איזשהו שילוב של באמת עבודה עם LLM-ים והיכולת למדוד את האיכות של התוצאה.(דותן) אני רואה שזה של stanfordnlp  . . . (רן) נכון . . . (דותן) אז כאילו, זה הניסיון שלהם להגיד “גם אנחנו בו במשחק”, נכון?אני זוכר הספרייה הזאת, של NLP, כבר שנים, שנים אחורה . . .  מה שנקרא “סטנדרט בלתי כתוב”.ואני מסתכל ככה גם על הפרויקטים שלהם - נראה שזה הפרויקט הראשון שהוא עוסק ב-LLM.אני לא יודע אם אפשר להשליך מזה שזה פרויקט טוב או לא, אבל...(רן) אפשר רק להזכיר ש-NLP, לפני הימים של-LLM, היה דיסציפלינה די מוכרת - אבל שיטות אחרות לגמרי. אוקיי?לנסות לנתח את המבנה התחברי של המשפט, להבין על מה זה פועל, הטיות וכו’.זה לא מה ש-LLM עושים היום. היום ה-LLM עובדים בצורה סטטיסטית לחלוטין, בלי איזשהו ניסיון - או לפחות ניסיון מהותי - לבוא ולהבין מבנה תחברי, או סמנטיקה.אפשר אולי להתווכח על זה, אבל זה גישות שונות. NLP זה כאילו “הגישה היותר קלאסית” והדרך שבה ה-LLM-ים עובדים היום זו דרך שונה.אז בעצם מה שדותן אומר, זה שהם “הצטרפו לעגלה”, כן? הצטרפו לקהל הרב . . . (דותן) פעם, אם רצית NLP, היית הולך ל-stanfordnlp.לא היית יודע בכלל מה זה, היית פשוט הולך לשם.(אלון) אני יכול להגיד שבעולם הזה, של “קצת להבין את ה-LLM-ים”, אפילו Datadog הוציאו כלי של LLM Observability,שזה קצת להבין איזה Prompt-ים, מה היו התוצאות? מה זו תוצאה טובה? וקצת לעזור . . . הכלי שלהם נראה יותר מרשים, אני חייב להגיד, של Datadog, אבל אני לא יודע מה יותר טוב או פחות טוב.לא התעסקתי לא עם זה ולא עם זה.(רן) עד כאן . . . (דותן) נתנו חסות?(אלון) “אוהבים דאטה?! . . .”(רן) ובמעבר חד: התפרסם לא מזמן - וכשאני אומר “לא מזמן”, זה נראה לי משהו כמו חודשיים - הסקר השנתי  של Stack Overflow 2024.בעבר היינו סוקרים את הסקרים האלה, זאת אומרת היינו באים ומביאים Highlights - אבל אני חייב להגיד שאני לא יודע מה מעניין שם הפעם . . .אז רק רציתי להרים פה, אם במקרה לכם יצא להסתכל על הסקר הזה . . עברתי עליו, כאילו בסדר - ראיתי שם מספרים וזה, אבל אני לא יודע, שום דבר לא תפס שם את עיני.שזה אולי האייטם - כאילו זה נראה כאילו זה כבר, אוקיי, “עבר זמנו” . . .אבל בכל אופן - יצא לכם לעבור עליו? יצא לכם לראות שם משהו מעניין?(דותן) לא . . . (אלון) יצא לי משהו מעניין אחר - יצא לי לראות את כמות המשתמשים ב-Stack Overflow, מאז ש-GPT יצא לראשונה.וכמות המשתמשים המשתמשים ירדה באיזה 65 אחוז, אם אני זוכר נכון, בשנתיים האחרונות [ChatGPT is putting Stack Overflow out of business traffic is down over 50%].ואז גם כנראה הסקר הזה, זה אנשים שלא משתמשים כל כך בכלים המודרניים - ואז הייתי אומר, לא יודע . . . זה כאילו מראש קהל בעייתי, לא הייתי אומר את זה כל כך.(רן) כאילו, בוא נגיד מראש, זה היה סקר של משתמשי Stack Overflow, שזה קהל מוטה באיזשהו אופן.אבל אתה אומר שהיום ההטייה היא כבר שונה לחלוטין, אז לא לבנות על תוצאות הסקר.כן, בסדר, בקיצור - עשינו @Mention, נמשיך . . .נושא אחר, ועדיין קשור מן הסתם ל-LLM-ים, זו כל הזירה הזו של Code Assistants, או “המלחמה” אני קראתי לזה, “The Code Assistants War”.אז יש שוק מאוד מאוד פעיל, שאני בטוח שכל מפתח תוכנה מכיר, של כלים להשלמת קוד או לעזרה בקידוד.בין אם זה Copilot של GitHub, שהיה בין הראשונים, Tabnine שאפילו היה עוד לפניו - חברה ישראלית - וחדשים, כמו Cursor ו-Codium שדרך אגב - יש שתיים כאלה, אחת מהן ישראלית ושינתה את השם [466 With Itamar from Codium]אבל יש עוד ועוד ועוד  . . .  ואלה הבולטים, יש לדעתי עוד עשרות כאלה.וגם כל אחד יכול להרים לעצמו אחד פרטי, כזה על הלפטופ כבר, זה לא כזה מסובך . . . העולם הזה די מתפוצץ, החברות - חברות כמו Cursor ו-Codium שהזכרתי - יש להן הערכות שווי במיליארדים גדולים, למיטב זיכרוני.זאת אומרת - זה שוק לא קטן.ורציתי סתם לפתוח לשיחה של מה אתם חושבים - כאילו, לאן זה ילך? זאת אומרת, איך אתם רואים את העתיד של עולם ה-Code Assistants?(אלון) קודם כל, אני חושב שהערכות-שווי שלהם הן מה-זה מגזמות, כי בסוף תיהיה קונסולידציה (Consolidation) ובחיאת ראבאק - הם לא יוצאו על אותו כלי כל כך הרבה כסף . . . זה הראשון.דבר שני, אני יכול להגיד ש-VS Code, למשל, הוא לאט לאט נהיה Cursor  . . .כאילו, הם מתחילים להעתיק פיצ'רים, ואני לא יודע עוד חצי שנה, איזה יתרון יהיה ל-Cursor, ולמה לא להשתמש ב-VS Code.בטח שיש לו גם את כל המודלים “המתוחכמים” - עכשיו גם הוסיפו את Claude, ואתה יכול לגרות קבצים, ולשאול אותו על ה-Context . . . ואני לא רואה יתרון . . . יש עדיין יתרון ל-Cursor, אבל זה לא נראה לי משהו שיחזיק לנצח.בסוף, בוא נתחיל מזה - הם מבוססים על VS Code, אז כן, זה לא בעיה לעשות את הכיוון ההפוך גם.(רן) כן, בדרך כלל, זה מעניין שרוב ה-Assistants מתלבשים על IDEs קיימים, כמו VS Code, או ה-IntelliJ או vim, או אחרים.ו-Cursor בחרו לפתח “IDE משלהם” - ואני עושה כזה “גרשיים”, אני עושה “מרכאות באוויר”, כי למעשה, גם ה-IDE שהם פיתחו כמובן מבוסס על VS Code . . . זאת אומרת, הם לא פיתחו את זה מאפס - זה נראה די דומה, הם רק החליטו לשים את הפאנלים ולסדר אותם קצת אחרת, אבל די ברור לכולם שזה VS Code מתחת.אבל כן, הם הלכו על איזושהי אסטרטגיה של שיווק, שבה יש להם את ה-IDE משלהם, זאת אומרת, הם הפלטפורמה.אבל כמו שאתה אומר, אלון - תכל’ס, התוצאה היא די דומה.כאילו אולי Cursor - היה להם איזשהו יתרון לתקופה, אבל אני רואה את כולם סוגרים את הפער.ל-GitHub גם היה פעם יתרון - וגם אחרים סגרו את הפער, כלומר, זה משחק שכל הזמן קורה.(דותן) נראה לי שיש פה שתי שאלות . . . .אחת זה “מי מכל ה-Editors האלה יהיה  “ה-Editors המוביל”ובלי קשר לזה, יש פה המון “ללמוד מההיסטוריה” - אני מרגיש שכל התשובות נמצאות כבר, כאילו. “ההיסטוריה חוזרת על עצמה”.ונראה לי שפה מי שינצח, זה מי שיש לו את הפלטפורמת-הפצה, פשוט ככה, כמו עם ה-Browser-ים . . .(אלון) אמרת הרבה בשביל להגיד “Microsoft” . . . .(דותן) לא יודע. . . . אולי זה Microsoft, יכול להיות שזה Microsoft, בסיכוי מאוד מאוד גבוה.אבל יש פה הרבה התפלפלויות . . . היה גם איזשהו Editor שעשה Fork, זה קבוצה של אנשים שעשתה Fork - וככה הם הקימו חברה, עשתה פורק של Editor קיים.והקהילה כזה “נכנסה בהם” והם נעלמו, אני לא זוכר בדיוק מי אלה.אבל בסוף, כמו כל דבר, הפלטפורמת הפצה תנצח.השאלה השנייה זה “איך ייראה העולם הזה?” - ש”יש לי Editor ש-AI כותב לי את הכל”.גם פה נראה לי שזה איפשהו בהיסטוריה, האמת שעוד לא נכנסתי לזה לעומק במחשבה.אבל פילוסופית, זה צריך להיות איפשהו להסתכל על המאמצים של Microsoft עם IntelliSense, ומה IntelliSense עשה . . . . IntelliSense, כשזה יצא, זה היה “ביג דיל”.היו גם כל מיני חברות של “AI של פעם”, שכתבו טסטים אוטומטית - מה קרה איתם ואיך זה עבד?ו-Refactoring - כל מיני כאלה שעשו תוספים של Refactoring של קוד, ואיך זה עבד להם וכמה השתמשו בזה?כאילו, איפשהו זה שילוב של הכל, ולא יודע . . . בינתיים אני יודע שיש Sweet-Spot-ים שאני משתמשכל מה שקשור לטסטים עובד טוב,“שכתב לי את הקוד הזה בצורה יותר טובה - תן לי לראות מה אתה חושב” - גם עבד לי טוב. “תכתוב לי קוד” - נפלתי לא מעט פעמים, שלקחתי קוד שהוא כתב לי, ופשוט הבאגים שהיו הם היו כל כך עדינים, שפשוט בלמצוא ולתקן הפסדתי את כל הזמן שהרווחתי, פשוט ככה.זה בטח ישתפר, אבל כרגע זה מה שאני ראיתי.(אלון) ומן סתם ל-Boilerplates גם - אחת השיטות זה לתת לו לכתוב קוד, לכתוב טסטים, או להגיד לו “זה ה-Output” - ואז הוא מתקן את עצמו,כאילו, לעשות את איטרטיבי.(דותן) כן, אז אני זורק לו את ה-Error ונותן לו להתמודד עם מה שהוא יצר, כאילו . . . (אלון) כן, אנחנו עדיין סתם בלופ כדי לתת לו את ה-Error-ים - כאילו, ועוד מעט הם יעשו את זה לבד . . .זה כמו השיחות שלי עם ה-Support ב-Amazon - אני כאילו פותח את ה-ChatGPT, ואני . . . שני ה-ChatGPT מדברים אחד עם השני, אני סתם עושה Copy-Paste-ים . . .  זה ממש מטומם.(רן) כן, יפה - אז בדיוק בשביל זה הבאתי את הבלוג הבא: אז בחור בשם Graham Neubig, וזה האייטם הבא שלי, בא ועשה איזשהו . . . ניסה לקחת איזשהו מבט-על העולם הזה, של כלים לכתיבה של קוד - AI Enhanced Software engineering - והשווה אותם לעולם של Self-Driving Cars, אוקיי?הוא בא ואמר “אוקיי, בעולם של מכוניות אוטונומיות, כבר הוגדרו חמש רמות:רמה הראשונה זה . . . זאת אומרת רמה אפס אולי זה אפס אוטומציה רמה מספר אחת זה נקרא Driver Assistance - או במילים שלנו זה Code Completion, אוקיי? שזה פחות או יותר רוב הכלים שיש לנו היום, כל מיני “סייענים” אבל לא יותר מזה.רמה שנייה נקראת Partial Automation - אז נגיד ששם הוא שם את Tesla Autopilot, ובעולם של Code Completions, נגיד Copilot או Chat Refactoringזאת אומרת שאפשר לעשות צ'אט ולעשות Refactor באמצעות זה לקוד.ויש את זה גם ב- Cursor ואני חושב שיש את זה גם לכלים אחרים, דיברנו על זה שכולם משלימים את הפיצ'רים אחד של השני, אז זה קיים.ברמה השלישית הוא שם את Conditional Automation. דרך אגב, אני לא חושב שזו הגדרה שלו, זו הגדרה די סטנדרטית - ובעולם של Self-Driving Cars זה נגיד מוצר של Mercedes-Benz שנקרא DRIVE PILOT.שאני לא מכיר אישית, אבל אני מניח שהוא עושה קצת יותר מ-Autopilot של Tesla.בעולם של Software Development, הוא מזכיר כלים כמו Diffblue Test Generation, וטכניקה שנקראת TransCoder for code portingשלי לא יצא לעבוד עם אף אחד מהם, אבל אני מניח ש-Diffblue, לפי השם, מייצר טסטים בצורה אוטומטית, קצת דומה למה שדותן ואלון הזכרתם מקודם.אבל כנראה שיש שם רמת אוטומציה עוד יותר גבוהה.ברמה הרביעית, יש מה שנקרא High Automation, שלמעשה ברכבים אוטונומיים זה נהיגת . . . נקרא זה “Cruise Control על סטרואידים”.זאת אומרת  רכב שיודע להגיע מנקודה א' לנקודה ב', בלי עזרה של בני אדם.בגדול זה Self-Driving Cars . . . אולי בלי החוכמה של מעבר, אולי כאילו בלי “חוכמת-הכביש” שמעבר, אולי בלי טיפול במצבי קיצון, אבל זה בגדול די Self-Driving Cars.ובעולם של פיתוח תוכנה, זה כלים שהוא מזכיר, כמו Devin, שיצא לי קצת להסתכל עליו, Devin או, OpenDevinשלמעשה זה Agents שאתה אומר להם “אני רוצה לייצר אפליקציית iPhone” או “אני רוצה לייצר אתר, שעושה ככה וככה”והוא עושה לך את זה, אוקיי?האם הוא עושה את זה טוב? האם האיכות גבוהה? זה עדיין לחלוטין נתון לויכוח, אבל אתה לא כותב שורות קוד שם, זאת אומרת - אתה רק מתאר Spec.אתה רק בא ואומר לו “אני רוצה את התוצאה הזאת - תייצר אותה”. זה כמו להגיע מנקודה א' לנקודה ב', במכונית, אוקיי?רמה חמישית של אוטומציה מלאה - פה אין לו דוגמאות, אני לא יודע מה הן הדוגמאות, אולי אנחנו עוד לא שם - אבל בכל אופן, אני חשב שזה נחמד.זאת אומרת, הבלוג הזה נחמד. Graham Neubig הוא Computer Scientist ב-CMU, זאת אומרת לא אוניברסיטה קטנה.והוא גם עובד בחברה שמייצרת כלים כאלה, אז אני מניח שהוא חושב על הנושא הזה לא מעט.וזהו, חשבתי שזה מעניין לבוא ולהשוות את עולם המכוניות האוטונומיות לעולם פיתוח התוכנה, ולשים אותם ככה, אחד מול השני.ובאותה הזדמנות גם להכיר את הכלים השונים במערכה הזאת.זהו, אז קריאה קלילה, זה לא מאוד ארוך - מוזמנים, נשים לינקים כמובן.(דותן) נראה שהזווית של המאמר זה בעצם להגיע בסוף ל-OpenDevin, שעכשיו נקרא OpenHands, ששייך ל-All Hands . . .(רן) כן, שזו החברה שבה הוא עובד . . . (דותן) כן . . . (רן) הוא בעצם רוצה לבוא ולהגיד “אוקיי, אנחנו ברמה הכי גבוהה, כל השאר שחקנים קטנים” . . . בסדר, אתה יודע, יכול להיות שזאת הזווית שלו . . . אבל זו סקירה מעניינת של השוק ופרספקטיבה נכונה, אני חושב.(דותן) כן, תראה, זה Open Source - אני רואה שיש פה איזשהו Docker שאתה יכול להריץ.אתה מריץ, מופיע לך כזה ב-Local Host - ונראה לי שאחרי זה אני אנסה את זה קצתכאילו, ניתן לזה לכתוב משהו, בסוף זה המבחן, הרי, נכון?אפשר להמשיך להגיד שזה עובד ו”עובדים עם זה”, ו-”AI כותב את כל הקוד” וכו'.בסוף, אתה מריץ את ה-Docker הזה, אומר לו “אתה עושה לי אפליקציה של  . . . “ - לא יודע מה, Pomodoro.ואתה נוגע בזה ורואה . . .  כאילו, ה-Bottom-Line זה מה שחשוב.(רן) כן. דרך אגב, אני לא ניסיתי, אבל נראה לי שלייצר . . . פעם ראשונה זה סבבה, לבוא ולהוסיף פיצ'רים ולתקן באגים - זה כבר דורש קצת יותר מעורבות טכנית.ופה אני בספק עד כמה באמת זה יעבוד.אבל שווה לנסות!טוב, עד כאן LLM-ים, מודלי-שפה, Code Completions וכו’ - ונעבור אליך, דותן! יצא לך לעבוד על איזשהו Framework קטן בזמן האחרון . . . 18:53 דותן - [loco.rs] This section is LLM-Free(דותן) כן, האמת שכל האייטמים שלי הם נטולי-LLM [כמעט פלינדרום], או “LLM-Free”, אז כל מי שבשוחות . . . (אלון) אפשר לתייג את זה  . . . “This Section is LLM Free”(רן) “ מכיל LLM בכמות גבוהה” . . . .(דותן) “No-AI”, כאילו זה משהו זה ללא גלוטן . . . בקיצור, כן - אני בשוחות, חופר את הבוץ.אתם שם למעלה, במגדל של ה-AI . . . וזה מיועד לאנשים שהם נגד AI.בקיצור, אז יש לי מסע, שקצת מתועד פה בפודקאסט, אני מניח . . .שבאיזשהו שלב - גם אלון היה איתי במסע הזה - באיזשהו שלב עזבתי את Rails ואת Ruby והבית החם הזה.שאני חייב להגיד שעם Rails ו-Ruby ממש הרגיש כזה כמו בית - אתה יכול לבנות הכל פשוט, כל דבר אתה מתרגם לסדרת פקודות של Rails - Rails New, scaffold זה, scaffold זה . . . - בום! יש לך אפליקציה חיה ועובדת.ופה מדובר על 20 שנה אחורה - היום אתה יכול לראות את זה בדמות אנשים שכאילו עושים פוסטים על AI - “תראו, אמרתי ל-AI מה לעשות, והוא ייצר לי אפליקציה!”סוג של אותה חוויה - אתה בא עם רעיון ואנרגיה, ויוצא לך משהו.אז איפשהו, באיזשהו שלב, עזבתי את העולם של Ruby - עברתי ל-Go, עברתי ל-Kotlin, כל מיני מקומות שביקרתי בהם.אבל בסופו של דבר, תמיד רציתי את החוויה הזאת . . .איפשהו השתקעתי ב-Node.js לתקופה, תקופה יחסית ארוכה.ובניתי Framework שהוא תואם Rails ב-Node.js -ו-Production, הכל, זה עובד סבבה - יש כמה אפליקציות שרצות על זה, אנשים משתמשים בזה וכו',אבל ראיתי שכ-Maintainer, אני פשוט לא יכול לחיות . . .  זאת אומרת שאחד הדברים ב-Open Source, זה שכשאתה רוצה לשים את הפרויקט שלך Online, מידי פעם לבוא ולא יודע, להוסיף דברים שאתה רוצה להוסיף בכיף.כי בסוף, אם אתה לא נהנה מזה, וזה Open Source בזמן החופשי שלך, אז זה פשוט לא יעבוד.וראיתי שבאמת . . .  קודם כל, לקח לי זמן להבין למה אני מרגיש רע עם זה כל הזמן.כל פעם שאני רוצה לבוא לתקן משהו שמישהו כותב משהו, זה פשוט הופך להיות סיוט של לפתוח את הפרויקט - ופיתחתי “רפלקס אנטי” כזה.לא בא לי לפתוח, לא בא לי לעשות Pull, לא בא לי לעשות Clone.וזאת הייתה תחושה שהקיפה אותי עם הפרויקט, שהוא ה-Clone של Rails ב-Node.js.ובסוף החלטתי רגע לקחת צעד ולהבין למה יש לי את התחושה הזאת, הסתכלו פנימית כזאת - והבנתי שפשוט כל פעם יש איזשהו “טקס של שבירה”אני מוריד את הפרויקט אליי - וזה הפרויקט שלי, זו האירוניה - אני עושה איזשהו npm install, whatever, עם כל הכלים הכי חדשים והמודרניים,ואני מבלה שעתיים של להבין למה ספרייה נשברה, ולמה סביבה דפוקה, ולמה אני לא יכול לשחזר פה, ולא יכול לשחזר שם . . . (רן) Don't get me started on Python  . . . (אלון) כן, כן . . . והאמת שאתה יודע מה? ב-Python - (רן) . . . עוד יותר גרוע . . . .(דותן) . . . התסכול זהה, אבל אני חושב ש-Node.js הפך . . . (אלון) תסכול כפול . . . (דותן) לא, לא . . . אני חושב שלפחות מה שאני התעסקתי, שה-Framework הזה זה “Framework שלוקח”הוא שואב ספריות, מלא ספריות . . . .באמת מה ששמתי זה זה Full Stack לגמרי, כולל Authentication, כולל הכל, ממש הכל.אז כמות ה-Dependencies שהייתה לי היא משוגעת - וגם “ Dependencies Shady” כאלה, למשל Express.js, שלא עודכן שנים על גבי שנים, רק עכשיו הם הוציאו גרסה . . . וכל מיני ספריות אותנטיקציה (Authentication) שוואלה - לפני 6-7 שנים היית אומר “זה הפרארי”, והיום זה פשוט סיוט של Memory Leaks וכל מיני קשקושים כאלה.ובאיזשהו שלב אמרתי “טוב, אני לא יכול, אני חייב פתרון - אני חוזר ל-Rails!”כאילו אני חוזר ל-Rails - כי כשיש לך רעיון ואתה רוצה להוציא אותו לפועל, אתה לא יכול שיש לך משהו שיעצור אותך.אתה רוצה את “החלק” הזה בדרך לבנייה.אז חקרתי על Rails - ואז איפשהו השתלבו לי העולמות: אני בא מ-Rust עכשיו, כל דבר שאני עושה זה Rust, ואני אומר את זה בכיף ובגאווה.ואמרתי, אוקיי - בוא נעשה רעיון משוגע: בוא ננסה, נתחיל, Baby Steps: אני אקח את ה-Framework ב-JavaScript הזהאני אסתכל כאילו, מה עבד שםואני אתחיל לעשות איזה Porting ל-Rust, ממש Porting.ומה שנקרא “לפני ששמתי לב” - אני כבר מסתכל על Framework ש”מנגן לי יפה בידיים”.עיקר הבעיה הייתה למצוא ה-RM טוב - ברגע שמצאתי אחד כזה, שהוא מאוד מאוד Rails-י, הכל התחבר.והיום יש Framework שהוא כבר עובד, שהוא Clone של Rails ב-Rust - נקרא Loco-RS, מלשון Locomotive.והוא עובד פצצה!אני יכול להגיד שהמבחן האמיתי זה הכיף - לבוא ולהוריד אותו ולעבוד עליו - זה פשוט תענוג צרוף.אין לי שבירה של תלויות, אין לי שבירה של כלים.כל פעם שאני רוצה להוסיף פיצ'ר, אני עושה Cloneו-Rust עוזר בזה, “Rust שומר עליי” - כי ה-Compiler מאוד מאוד חזק.הרמת-ביטחון שלי בלהוסיף פיצ'ר ל-Framework כזה מורכב היא אחת הגבוהות שהייתה לי בקריירה בכלל.כאילו, בכל השפות שהתעסקתי,וזה פשוט תענוג לעבוד על זה.וזה עובד - אנשים משתמשים בזה, מתלהבים מזה, זה ברמה של Rails עד כדי “חמש דקות - ואתה כותב בלוג”.עם Generators, עם כל ה-Magic.עם scaffold מלא של Full REST API, וגם Full Stack - גם מייצר UI והכל.וזה 100% תודות ל-Rust.כאילו, קצת מהניסיון שהבאתי והזה . . . .אבל מלא מלא מלא הולך לספריות הסופר-יציבות של Rust, זה פשוט כיף.אז אני ממליץ למי ש...(רן) כן, אני הייתי בטוח שאתה קורא לזה Loco - כי אתה משוגע . . .(דותן) לא, האמת זה יצא ככה . . . . זה יצא ככה. זה באמת שילוב משוגע.אבל תשמע - יש בזה חוויה. כאילו זה “קפה” כזה - זה קצת מר, זאת אומרת, זה לא Rails, שאתה עושה Rails New ואז יש לך אפליקציה ואתה מרים אותה בשנייה, כן?אז אתה עושה Loco New - יש לך אפליקציה בפחות משנייה - כי זה Rust, הוא מייצר קבצים בצורה מטורפת.ואז בסדר, ה-Loco Start ייקח לך משהו כמו חצי דקה עד שהוא מקמפל (Compile) את הכל,ואז כל קימפול נוסף זה ברמה של שניות.אז זה הטיפה מר בפה - אבל החצי דקה הזאת, או השניות האלה - לקבל פרויקט שבאמת יש בו אפס באגיםפשוט ככה - כל הבאגים המוזרים של Dynamically Typed Languages וכאלהאפס באגים, אין לי באגים - כאילו אני אומר את זה לא בשחצנות, פשוט אין באגים, פשוט ככה. [הקומיטים שלי טובים].עזוב באגים של לוגיקה, כן? אין לך את “הש*ט הלא צפוי” - אין, אפס.וזה פשוט מטורף.עכשיו, אחרי כל זה, אתה בונה את האפליקציה שלך - אתה מקבל Binary בגודל של איזה 20-30 מגה, כשהכל “אפוי” בפנים.אתה לוקח ואתה עושה Copy ל-Binary הזה - כאילו חוויית Go.אבל מה שלא חוויית Go זה שהדבר הזה תופס 6 מגה בזיכרון - ונותן לך, בבדיקה האחרונה שעשיתי, 50 אלף Request-ים לשנייה, כולל קריאות ל-Database.ו-200-300 Request-ים לשנייה בלי Database500 אלף, כאלה מספרים.אז אתה יכול על Raspberry Pi לעשות מה שאתה עושה על שרתי-ענק,ו-Go לא נותן את התוצאות האלה פה.(רן) אפשר להתקין את זה על השעון שלי . . . (דותן) כן . . .(רן) ולשרת משם את ה-Spotify . . . .(רן) כן, אז אתה מצטנע - התחלת לפני שנה ומשהו, כן? והיום יש לך 5.3K סטארים, 225 Fork-ים, ו-Contributors יש כמה?  80 ומשהו . . .  זאת אומרת פרויקט גדול, גדול בכל קנה-מידה.(דותן) כן, אני לא מסתכל על הסטארים - אני מסתכל על החוויות הקטנות האלה. למשל, כשבאתי ובניתי . . . יש שם איזה Background-Jobs Framework, מה שב-Rails לקח הרבה זמן להתבשל.אז אמרתי תשמע, “אני גונב את כל זה . . .  כאילו, את כל הלמידה אני גונב”.ואני בונה בעצמי Background-Jobs Framework.אז זה, מטעמי נקרא לזה “קמצנות” - הלכתי ובניתי כזה דברלקחתי אחד ל-Redis, כמו מה שמי שמכיר sidekiq, ובניתי אחד ל-postgres, קטצ’יק כזה.ואמרתי “אין לי כוח לבנות ל-SQLite” -  אני לא תומך ב-SQLite, אני לא חושב שזה - מטעמי קמצנות - אני חושב שזה יהיה מאמץ מיותר. ולפני כמה ימים בא מישהו, והוסיף אימפלמטציה (Implementation) ל-SQLite, של Background-Jobs Processing Framework.מה שכאילו, בעולם המקביל, ב-Rails או ב-Node.js, זה כאילו “טקס” - מישהו בא ובונה, ונזילות זיכרון, במיוחד בדברים האלה, ולוקח זמן עד שזה יציב . . . והדבר הזה פשוט “ברזל” - הבן אדם בא עם ניסיון, מכיר את הנושא, נותן אימפלמטציהכל מה שנשאר לי זה לעשות Merge - וזהו.אז זה החוויות שאני אומר “וואלה, זה עובד”.כאילו, כשיש את האינטראקציות האלה, זה באמת כיף.(רן) יפה, אז תתחדש על ה-Framework החדש שלך.(דותן) כן - ואני ממליץ: מי שרוצה לעשות Rust, אז עבדתי קשה כדי שלא תפגשו את ה-Borrow Checker . . שלא יהיו לכם בעיות של Lifetimes.כי בעצם, Request מתחיל, הוא לוקח Data, אתה משחק עם ה-Data - וה-Data הולך לפח בסוף  ה-Request.לא מחזיקים שום דבר באוויר, ככה שאין לך בעיות של “יש לי Pointer לפה, Pointer לפה, ועכשיו אני צריך לדבר עם ה-Compiler”.אז כל מה שנשאר זה רק לריב עם ה-Syntax, מה ש... זה ה-Friction היחיד, לדעתי.זהו  . . . (רן) מגניב . . . אוקיי. אז loco.rs, חפשו ותיהנו.(דותן) כן, וזה “Framework לקמצנים”, אני חייב להגיד . . . זו גם אחת מהמוטיבציות: אתה יכול להרים Business ב... לא יודע מה, $10 לחודש באיזשהו שרת-פח כזה, ב-Hetzner או Whatever, ולקבל “1000% החזר” על ההשקעה.(רן) כן, למרות שצריך - כדי להשתמש נורמלי - צריך להכיר Rust, כן?(דותן) כן, צריך. אבל כן - אני לוקח איזה... העולם איתי! העולם בסוף יתכנס לשם, לדעתי.(אלון) כן . . . עם שפה, זה דבר הרבה יותר קטן, כאילו, אם הקשבת לעצמך, עם כל ה-LLM-ים, אז אני חושב שהיום זה הרבה יותר קל.כי אתה לא יודע איך עושים משהו? אתה מקבל את ה-Boilerplate, ואז אתה מתחיל לשנות.זה לא כמו פעם להתחיל “איך אני . . . “כאילו, הוא נותן לך את ה-Template הראשוני, ויאללה - אתה מתחיל, יותר קל להתחיל לעבוד על זה.(דותן) זהו, אז יש הרבה דברים גם מעניינים שאנחנו עושים שם.למשל, אני אתן סתם דוגמה, סתם להצית את הדמיון, לא קשור ל-Framework - כל מיני ספריות-צד שנולדו.אז אחת הספריות, או איזשהו Framework קטן, שבא ואומר, רגע - אם יש לי אפליקציה שאני רוצה להתקין, נגיד Railsועכשיו אתה רוצה להתקין Rails, ולבחור Database כזה, ולבחור Background Job כזה, וכל מיני אופציות, במהלך ההתקנה של הספרייה, של ה-Framework או Whatever.אז אני צריך לעשות טסטים לדבר הזה, ליצירה של אפליקציה - אני צריך לעשות טסטים עם Database postgres, עם SQLite, עם MySQL . . . ואז אני צריך לעשות טסטים . . .  רגע, הבן אדם רצה API, או רצה SaaS, או רצה אותנטיקציה (Authentication) או לא רצה אותנטיקציה . . . מלא מלא מלא שילובים, של כל מיני קומבינציות של אפליקציה שאתה רוצה לייצר כסטארטר, Starter-App כזה.אז מה שעשינו, זה בנינו Framework, שעושה Fuzzing לזה: לוקח את כל הפרמטרים שיש, לוקח את כל הקומבינציות, סוג של prop.test כזה.ומייצר שעות על גבי שעות, את כל הקומבינציות של כל האפליקציה - כשבסוף כל Generation של App חדש, הוא מריץ Suite של טסטים.הטסטים יוצרו על ידי LLM - כאילו, השתמשנו קצת כדי להרחיב את הדמיון, מה שנקרא.אבל ה-Fuzzing הוא Fuzzing סטנדרטי כזה.למשל, עשינו אפליקציה עם אימוג'י, בתור השם של האפליקציה - וזה שבר לא מעט דברים.כל מיני קשקושים כאלה . . . אז זה עם Rust גם עובד ממש טוב - כי קודם כל הספרייה היא  Statically Typed, היא גם באה מעולם של ML, אז יש שם אנשים שאוהבים את התחום של prop.test וכאלה.אז זה ככה התלבש “כמו כפפה ליד”.זהו.(רן) אוקיי, אחלה, תודה! זהו, הבא בתור!31:49 עוד דותן - gitbutler, openobserve, 100-exercises-to-learn-rust,PDF ל-Markdown, Rust based editor, shadcn/ui(דותן) הבא בתור - אז יש את סקוט שקון, או צ'קון [Scott Chacon] - מי שבנה, נדמה לי שהוא בנה, את libgit, היה אחד מהשפיצים ב-GitHub, אני חושב שהוא כתב את הספר של git - הספר - אני מדבר מהזיכרון.באיזשהו שלב הוא יצא כזה הצידה, מעולם היזמות, לבנות אפליקציה שהיא Desktop App ל-git.קוראים לזה gitbutler וזה Open Source.זה אחלה Codebase לקרוא - וגם אחלה אפליקציה להשתמש, אם מישהו אוהב UI מעל ה-git שלו.ו...יפה.(אלון) מי אוהב UI מעל ה-git שלו? אנשים לא אומרים את זה בקול רם . . . (דותן) נכון, צריך להגיד את זה יותר! אנשים שאוהבים UI מעל ה-git שלהם.אז זו אפליקציה ממש נחמדה, כתובה ב...Rust! זאת אומרת, יש Framework שנקרא tauri, מבוסס Rust ו-JavaScript וכל מה שצריך.זה אחלה דרך לראות מה אפשר להשיג ואיך אפשר לכתוב Desktop App, היום בימינו, Cross-Platform.כשאתה עושה את ה-JavaScript שלך והכל, אבל כל ה-Backend Functions, כל הדיבור עם מערכת ההפעלה, מתבצע ב-Rust.וזה אחלה פתרון.הדבר הבא - פרויקט שנקרא openobserveיש איזשהו Track כזה, איזשהו Journey של Tracing ו-Open Tracing וכל מיני מאמצים של Log-ים ו-Tracing ומטריקות (Metrics).וזה אותו דבר? זה לא אותו דבר? זה שרת לזה, שרת לזה . . . ויוניפיקציה (Unification) וסטנדרטים וכו' אני כבר לא עוקב אחרי כל הסיפור - OpenTelemetry, OpenTracing - כבר לא זוכר ולא עוקב.אבל יש פה איזשהו פרויקט שבא לתת פתרון, שהוא Low Cost - High Performance ל-Elastic.לפי מה שהם כותבים, זה, איך נגיד, פי 140 פחות Storage [140x lower storage cost,], או ב-140 פעמים פחות Storage מ-Elasticsearch.ומי שיודע ומכיר, אז במטריקות, Log-ים וכאלה, הנתון הזה הוא סופר-סופר-חשוב, ה-Storage.זה  high performance,  petabyte scale, אלטרנטיבה ל-Datadog, ל-Elastic וכו’ הכל בשרת אחד, כזה Single Binary.והפתעה - כתוב ב-Rust!(רן) זו הפתעת היום . . . (אלון) בשרת אחד . . . כאילו, הוא יודע לעבוד גם כמה? כאילו, מתישהו הוא ימות, ממקום או מביצועים או ממשהו . . . (דותן) יש לו Clustering ו-High Availability . . . .לא שאני פרשתי אותו, אבל זה למשל פרויקט שאני אומר “אה, לא יכול להיות . . . .”“לא יכול להיות שזה כפול 140!”נכנס, קורא את הקוד - ואז אומר “אוקיי, הבנתי”.קודם כל, הרבה מזה זה חוק 80-20 - 80 אחוז מזה זה פשוט Rust . . . ואחרי זה אני מתחיל לקרוא את הקוד, אני רואה את ה-Design, אני רואה מה הם עשו.ואני אומר “אוקיי, אני נוטה להאמין לזה” . . . ככה אני בונה את הביטחון שלי.זה נטו לקריאה של קוד ולמידה בשבילי.אז זה מי שרוצה לנסות, נראה לי שזה, לפחות מה שאני קראתי ובדקתי מהקוד, זה אחלה פרויקט.פרויקט הבא - יש פה את mainmatter, שהיא חברה כזאת, “חברת למידה” נקרא לה, חברה שמייצרת חומרי -למידה, שיצרה פרויקט שנקרא 100-exercises-to-learn-rust.100 תרגילים כאלה, וזה אחלה דבר.מי שאוהב לבוא ולפצח גרעינים כזה - זה אחלה אחלה פרויקט, למי שרוצה לנסות.לא נראה לי שיש פה מה להפסיד, זה קליל, זה נחמד.אז זה זה.ונכון שהבטחתי בלי LLM-ים, אבל יש פה איזשהו משהו שחיפשתי הרבה זמן, וזה PDF ל-Markdown.לקחת PDF, ולהפוך אותו ל-Markdown עם מודל שפה כזה.זה וואו . . . . לא יודע למה, אבל להתעסק עם PDF-ים בשבילי זה וואו, וזה עובד מטורף.(רן) אני יכול להרחיב - מי שמכיר HTML חושב לעצמו “אוקיי, מה הבעיה? יש Title-ים, יש Header-ים, יש מבנה, יש טבלה, אפשר להבין מה קורה גם בתוך PDF.אבל האמת העצובה היא שלא, ב-PDF זה לא ככה. ב-PDF זה בלגן אחד גדול.ה-Title-ים הם בהרבה מקרים לא לוגיים, זה פשוט פונט יותר גדול.הטבלאות - יש עשר דרכים שונות לייצר טבלאות . . . בסופו של דבר, פשוט לקרוא את ה-Source Code של PDF זה אומנם אפשרי - אבל זה לא תמיד נותן לך את הערך, זה לא תמיד בנוי לוגית נכון, כמו ש-HTML . . . זאת אומרת, לא שתמיד HTML כמובן בנוי נכון, אבל יותר נכון.אז אי אפשר פשוט לקרוא את ה-Source, והרבה פעמים מה שאתה נאלץ לעשות, זה פשוט להפעיל מודל Vision על ה-PDF, כדי להבין מה באמת . . . איך זה באמת אמור להיראות.עד כמה מגוחך שזה נשמע . . . יש לך טקסט כ-Input, ובסוף תצטרך, צריך לעשות Render ולראות מה יצא.אבל כן - זה מה שהרבה פעמים עושים, ובגלל זה זה וואו.עכשיו, דרך אגב, למה Markdown? כי Markdown זה די סטנדרטי, ו-LLM-ים עובדים מאוד יפה עם Markdown.זאת אומרת, אתה יכול לקחת אחר כך את ה-Markdown הזה, ולדחוף את זה לתוך-LLM - ואז “הם” בדרך כלל יבינו הרבה יותר טוב.(דותן) כן. גם הפרויקט הזה עובד ככה - מעבירים ל-Image ומה-Image “זורמים”.אגב, יש דמו, שאפשר להעלות קובץתיזהרו עם קבצים! עם טבלאות שאתם לא רוצים שיהיו . . .אבל אתם יכולים להעלות, כדי לאתגר את העניין, מערכת שעות של גן או משהו כזה - ולראות מה יקרה.אז זה ממש נחמד.(אלון) אין סיכוי שהוא אוכל מערכת שעות של גן . . . . כאילו, גם בנאדם לא מצליח . . . .  לא, אין סיכוי.(דותן) יש עולם של סטנדרטים, יש עולם של סטנדרטים שבורים - ויש מערכת שעות של גן.זה באמת מאתגר כל...(רן) אבל מה שכן, הייתה לי כן חוויה טובה - לאו דווקא מערכת שעות של גן, אבל נגיד כל מיני דוחות של בנקיםנגיד שהם בעברית, ואני צריך לתרגם לאנגלית, לאיזשהו צורך.עכשיו, זה לא כזה מסובך, כן? אתה יכול ללכת ולתרגם, זה פשוט מלא מלא עבודה, מספרים וזה.אני זורק את זה - ניסיתי את Claude, ניסיתי את ChatGPT - אחרי כמה תפירות קלות של Prompt יוצא פשוט מדהים.מתרגם מנגיד עברית לאנגלית - אפס טעויות, כולל לשמור את הטבלאות איפה שצריך, כאילו . . . . ממש ממש יפה. עכשיו, זה לא הסיפור הזה של PDF ו-Vision, זה משהו אחר - אבל עדיין, עושה אחלה עבודה, גם בלהבין איך הדבר הזה בנוי. דרך אגב, ה-Source הוא כן PDF, אז אני לא כל כך יודע מה הם עושים מאחורי הקלעים. אולי הם כן מפעילים שם איזשהו Vision, אין לי מושג.אבל זה גם עושה את העבודה של להבין את המבנה של המסמך, וגם את התרגום מעברית לאנגלית.ששוב - זה לא כזה מסובך, כל אחד יכול לתרגם, אבל זה פשוט מלא עבודה שחורה, וזה עושה את זה ממש יפה.אז מגניב.(אלון) כן, זה בכל מיני פורמטים אחרים גם . . . .(דותן) כן, כן.(דותן) אז זהו, נושא הבא - דיברנו קצת על Editors, אז כבר, לא יודע, די לפני הרבה זמן, נולד Editor שנקרא Zed [כבר מזמן Zed's dead, baby]וגם ל-Zed יש “היסטוריית אנשי GitHub" - כמה חבר'ה מ-GitHub, שפיצים כאלה, שבאו ואמרו, אנחנו רוצים לא לעשות עוד סטארטאפ, אנחנו רוצים לבוא ולבנות Editor כזה.אז יצא להם Zed.איך שזה נראה, לפי הקוד והכל, זה לא VS Code Cloneזה אומר שהם יצאו מאפס, כתבו...(אלון) התחיל מ-Atom . . . (דותן) נכון, Atom - אבל בפרויקט הזה הם כאילו התחילו מאפס, בלי שום בסיס, From Scratch, עד ה-Rendering של הפונטים, הכל כתוב מאפס. הכל ב-Rust, שוב פעם.וזה פרויקט שהתחיל כסוג של VS Code Clone כזה. אולי נגיעות-סיומת של Sublime, נקרא לזה.מרגיש סופר סופר מהיר - בטירוף.ה-Vim Mode שלו, שזה מה שהיה חשוב לי, עובד סביר - לא טוב, אבל סביר.ונראה שעכשיו הם בעצם הלכו לכיוון של AI - זאת אומרת להכניס את זה כ-First class citizen בתוך ה-Editor.אז מי שאוהב את השילוב של AI ו-Performance ב-Editor וכאלה - זה יכול להיות אחלה.לי זה קצת מוריד, הפוקוס על AIאבל זה אני באופן אישי, לא מעיד על כלום.זהו.(רן) הורדתי, התקנתי . . . (דותן) כן, אין כאילו, אתה לא משלם כלום, אין שום חיסרון, אין התקנה, אין כלום - זה Binary, Super lightweightאתה עושה Double-Click, מתפוצץ לך לפרצוף מרוב שזה מהיר . . .אהבת - אהבת; לא אהבת - סגור.(רן) כאילו, אני גם, אני אנסה את ה-Vim Mode, אבל מהניסיון שלי בדרך כלל, כאילו, Vim Mode . . . ה-Vim עובד סבבה ב-Terminal, הוא לא עובד לי טוב כל כך ב-UI.כאילו, איכשהו האינטגרציה בין כל שאר הדברים ל-Editor עצמו, לא יודע, לא זורמת לי . . . אולי זה עניין של להתרגל, אולי זה עניין של למפות את המקשים נכון . . . אבל כשאני עובד ב-Terminal ואני מפעיל vim - סבבה, כאילו, אני רגיל, “האצבעות רצות”כשאני עובד עם IDE ואני מפעיל Vim Mode, אף פעם לא באמת זרם לי . . . .(דותן) שמע, ב-VS Code, ה-Vim Mode [VSCodeVim] בשבילי הוא מדהיםעד כדי כך שהחלטתי באיזשהו שלב להפסיק לתחזק את ה-”Vim-Vim” שלי, את הקונפיגורציהזרקתי את זה לזבל, ובכל מקום - Linux, whatever, לא משנה איפה, אני פשוט פותח VS Code בלי להתבייש, וזהו.וכאילו, אמרתי ביי ל-vim, ו-Neovim וכל זה.(רן) דרך אגב, הם קראו לפרויקט zed.dev - אני תוהה, האם זה איזושהי קריצה לכיוון למשפט האלמותי Zed's dead, שנשמע קצת דומה, מתוך Pulp Fiction?(דותן) יכול להיות שיש שם . . . .יכול להיות.(רן) כן, ולא היו מספיק אמיצים כדי ללכת על Z.dead . . . אבל אולי אחר כך.(דותן) יכול להיות . . . עוד דבר, למי שאוהב, שווה לציין שאם נכנסים לבלוג שלהם, אז אפשר to geek out לגמרי . . . מדברים עם האלגוריתמים שהשתמשו לעריכת טקסט, והמבני-נתונים המיוחדים שהם השתמשו בהם, ואיך הם עובדים עם tree-sitter, שזו הספרית-Coloring, נדמה לי, שהכי בשימוש היום, ואיך נראה Extension, ולמה הוא עובד ומלא, מלא, מלא חומר הנדסי טכני, ו...וכתוב בצורה מדהימה, כאילו ציורית - עם גרפים, עם כל מה שצריך.באמת אחלה חומר, כאילו, ממש כיף לקרוא.(דותן) זהו, אז האייטם הבא - האמת שבשבילי זה היה ממש וואו: מי שמכיר את הספרייה של ה-UI שנקראת shadcn/uiזה בחור שבנה . . . (אלון) מה זה shadcn?(דותן) זה השם שלו . . . זה בחור שלא יודעים מיהו, הכינוי שלו זה shadcnהוא בא משום מקום כזה, הוא בנה ספריית UI ל-React, מבוססת Tailwind, והיא כל כך טובה שהיא דיברה בשבילו . . . הוא לא היה צריך לקחת . . .  אפס, כאילו, פעילות ב-Social, בכלום.זה פשוט ספרייה שכל כך עשויה טוב, מבחינת הדיוק שלה וה-UI והכלכשאני השתמשתי בה, זה היה Flawless.ואז הרבה, כאילו, הבינו את זה דרך השימוש, דרך הפה-לאוזןוהספרייה עצמה - היא ממש התפוצצה, והרבה בזמנו לקחו, כאלה כל מיני ספריות מובילות של React, הרבה פשוט עברו לזה, Wholesale, כאילו, בבת אחת.חבר'ה של Vercel זיהו אותו, וזיהו את הגדילה של הדבר הזה, וקנו אותו - ועכשיו הוא עובד שםוזה עדיין מדהים.עכשיו, אחד הדברים שהיו חסרים ב-Toolkit הזה - וזה באמת רמה של פינוק, כאילו, כי יש שם המון, יש שם כל כך הרבה - זה Sidebarזאת אומרת, בסופו של דבר אתה רוצה לבנות איזשהו SaaS-App כזה, נגיד, או איזושהי אפליקצית-Adminאז אתה רוצה את ה-Shell, אתה רוצה את ה-Menu, אתה רוצה את ה-Sidebar ואתה רוצה את כל מה שמקיף,וזה היה חסר הרבה זמן.ולפחות בשבילי, זה היה אחד הדברים הכי מעצבנים לעשות, במיוחד ב-Tailwind, שאם אתה רוצה לעשות Refactoring, ואולי אז אתה מעדכן ערימות על גבי ערימות של CSS Classes כאלה מגעילים.ואז הוא בנה Sidebar - והוא נתן משהו כמו מאה וריאציות, מספר משוגע . . . ופשוט היום, אתה לוקח את הדבר הזה, אתה פשוט בונה SaaS עיצוב ברמת-קצה, רק עם הספרייה.עכשיו, אחד הדברים המיוחדים שהוא עשה, שאולי זה שיעור ללמוד בכלל, לבנייה של Open Source וכאלה,הוא בנה את הספרייה בצורה שאתה מעתיק את ה-Sheet  שאתה רוצה להשתמש בו.ניתן רגע לזה לשקוע . . . .אתה לא עושה npm install לקומפוננטים (Components), אתה עושה Copy לקוד שלהם.זאת אומרת, אתה יכול לחשוב שזה כזה מגושם וכאלה - אבל זה פשוט עובד.כי אתה רואה, נגיד, כפתור שאתה אוהב - אתה עושה Copy לקוד של הכפתור אליך.וככה “התקנת”, “במרכאות”, את הכפתור.יש בעיה ענקית לשדרג ולעבור לגרסאות יותר מתקדמות - ממש ידנית אתה צריך לבוא ולהעתיק קוד חדש ולתקן שבירות . . . אבל לדעתי זה אחד הדברים שפשוט עשו את הפיצוץ של הספרייה, כי ה-Friction להשתמש היה אפס.(רן) כלומר, זה יורד ברקע אחר כך, או שפשוט לא צריך להוריד כלום?(דותן) הקטע ב-Tailwind, בכלל, זה שאתה יכול לבוא, לעשות View source, להעתיק את ה-Source, לזרוק אליך - וממש יש לך הכל, הכל מתקתק, כי זה נטו-CSS.אז הוא לקח את אותה הגישה - שאתה מסתכל, זה React, זה עדיין React - ואתה פשוט עושה Copy למה שאתה אוהב מהאתר שלואתה עובד ממש עם האתר - כל הזמן האתר פתוח, אתה עושה Copy, זה  . . . (אלון) כי הבעיה בדברים האלה, אתה אומר “אה, כבר התחלתי, אין לי איך . . .  זה רק להתחיל פרויקט מאפס”.וכשיש לך משהו כאן, אתה אומר “אני רוצה איזה גרף” . . . (דותן) ממש . . .  הוא ממש פיצח את ה-Friction של הדבר הזה.עכשיו שהוא הצטרף ל-Vercel, זה קטע מעניין - אם עכשיו עוקבים אחריו ב-Twitter, אז הוא נהיה ממש ביג -דיל כזה.ובגלל שאנחנו מדברים פה על העתקות של קוד, אז Vercel חיברו לזה כזה כמו משהו שמייצר אפליקציה - לא יודע, LLM-based, whatever, זה לא משנהאבל יש כזה דבר שלוקח את כל shadcn/ui - ויכול לייצר אפליקציות שלמות.כמובן שהכל צריך להיות Hosted ב-Vercel, והכל “Sponsored by Vercel” כזה . . . זהו, אז מי שרודף אחרי - לפחות אני הרבה זמן רדפתי אחרי ה-Holy Grail“תן לי UI-Toolkit, עזוב אותי, לא רוצה להתעניין בשום דבר, תן לי רק ליצור איזשהו Shell, להתחיל איזשהו פרויקט, ליזום איזה משהו כזה”בלי להתעסק ב-Style, בלי להתעסק להרכיב את החלקיםזה הדבר. זה מדהים.זהו.(רן) טוב. מגניב. תודה רבה. אוקיי, תרצה להוסיף עוד משהו, אדון אלון?(אלון) לא, אלון כבר מאחר . . . (רן) אוקיי אז, ובכן - אנחנו היינו אנחנו, זה היה באמפרס פרק מספר 84 - תודה רבה. המשך יום נעים, וניפגש.האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 481 של רברס עם פלטפורמה, שהוקלט ב-5 בנובמבר 2024, יום רווי אירועים פוליטיים. אורי ורן מארחים את דרור לדרמן מחברת Honeycomb לשיחה על Machine Learning בעולם הביטוח ואולי קצת מעבר.00:43 דרור ו-Honeycomb(רן) אז ברוך הבא, דרור. ספר לנו קצת על עצמך ועל Honeycomb?(דרור) דרור לדרמן, בן 49, כבר לא צעיר . . .  נשוי, שלושה ילדים, נמצא ב-Honeycomb כבר ארבע שנים.במקצועי אני בתחום הנדסת חשמל - דוקטורט בתחום הנדסת חשמל, כבר לא מעט שנים.למעשה בתעשייה מ-2007, משלב גם עם אקדמיה, הוראה.התגלגלתי בלא מעט חברות - גם Corporate כמו Intel, Citi Bank במשך מספר שנים. והצטרפתי ל-Honeycomb ב-2020 - ולמעשה כבר ארבע שנים ב-Honeycomb, הכי הרבה שהחזקתי מעמד עד היום בתעשייה . . . כבר מספר מכובד לכשלעצמו, נהנה מכל רגע, נדבר על זה.[וחזר לאוויר גם הפרק בגיקונומי - גיקונומי #542 – דרור לדרמן (עלה מחדש)](רן) מעולה, אז נחמד שאתה פה - ו-Honeycomb, במה עוסקים?(דרור) אז Honeycomb זו חברת ביטוח, חברת InsurTech, שפועלת בארצות הברית בעיקר, כלומר - אנחנו מבטחים מבני-מגורים, מתחמי-דיור למעשה, מה שנקרא Multi-families ו-Single-Houses בארצות הברית.והרעיון המרכזי בחברה שבעצם אנחנו משלבים מודלים של AI בתהליך החיתום וה-Risk Selectionכלומר, במקום - או אם נסתכל על העולם הקלאסי של ה-InsurTech, שבו יש חתמים, מה שנקרא Underwriter-ים, מושג שהוא טיפה פחות מוכר בארץ . . . (אורי) אולי שנייה נעצור, נדבר על כל הסיפור הזה של “חיתום” . . . . מה? מילה שנשמעת “עברית יפה”, אבל מה קורה שם?(דרור) אז בהחלט - תהליך החיתום זה תהליך שבו, אם אנחנו מדברים על ביטוח של מבנה מגורים, יש חיתום בתכשיטים וברכבים אפילו, אבל תהליך החיתום בהקשר של מבנה מגורים אומר, שבעצם כשאנחנו - או כל חברת ביטוח - כשהיא מקבלת איזשהו נכס או Property - בית או מתחם-דיור שרוצים לבטח אותו - בעצם אנחנו מקבלים את כל האינפורמציה שיש על אותו נכס.אם מספקים, מספקי-משנה ואם מהלקוח עצמו או מהסוכנות, זה הרבה פעמים עבודה עם סוכנויותאז הסוכן פונה, מגיש בקשה דרך נניח האתר - במקרה שלנו זה הכל דרך האתר, דרך האפליקציה שלנו.מגיש בקשה לבטח נכס בכתובת מסוימת.אנחנו מקבלים ממנו פרטים ראשוניים על הנכס, כולל תמונות של הנכס, כולל . . . כל מיני אינפורמציה, כל מה שאפשר, כמובן כתובת ומעיין Credit-History, יש איזה מושג כזה בעולם הביטוח, וכל האינפורמציה שרק אפשר להשיג.אנחנו שולפים אינפורמציה נוספת מכל מיני ספקים, כולל צילומי אוויר וכו’ וכו’ - ובעצם בתהליך החיתום, החתם, מה שהוא עושה בתהליך הקלאסיהוא מסתכל על הנכס, הוא בוחן גם את התמונות, גם מידע ויזואלי וגם מידע טאבולרי, טבלאי, על הנכס.מסתכל על זה מכל הכיוונים האפשריים, נכנס לאתרים כמו Google Maps  וכו',ובעצם מעריך את הסיכון שנובע מתוך הנכס.למשל, אם מדובר בנכס חדש, מתוחזק היטב, הגינה מטופחת והבית נראה מעולה וחדש וכו’, אז כנראה שהסיכון הביטוחי מאוד מאוד נמוך, ולכן אפשר לאשר את הנכס.לעומת זאת, אם הוא רואה שהגג למשל במצב גרוע, יש שם סימני רטיבות . . .אפילו מתמונות, הוא לא חייב לבקר בנכס - בעבר היו מבקרים בנכס, מתקופת הקורונה כבר לא עושים את זה . . . גם בגלל שעל הגג קשה לעלות פיזית ואת זה הביטוח לא מכסה, הביטוח של החתם או של הבודק לא מכסה את זה . . . (רן) גם לזה צריך ביטוח . . . .(דרור) כן, אז לא לוקחים סיכונים היום, אז מסתפקים בצילום האוויר, בוחנים - ולפי זה מתקבלת ההחלטה, באחריות החתם בעצם, האם לבטח את הנכס.ההתהליך הזה, הוא לוקח הרבה זמן . . . (אורי) אבל גם יש פה ניסיון של החתם, נכון?(דרור) נכון, בהחלט. אז תהליך החיתום - חתמים זה מקצוע שהוא במידה רבה . . . הוא לא מקצוע אקדמי, אין תואר.בטח לא בארץ אבל גם לא בארצות הברית - אין תואר שלם, אבל אתה לומד את זה תוך כדי העבודה.החתמים שיש לנו בחברה זה חתמים עם המון המון שנות ניסיון, שראו אלפי מבנים בחייהם.אז כן, יש פה הרבה מומחיות ולא משהו שבנקל . .  אתה לא יכול לקחת מישהו, אדם מן הרחוב, ולהגיד לו “בוא, תבדוק את הנכס”, זה כמובן לא יעבוד . . .ולראייה, אחד הפרמטרים שבהם נמדדת כל חברת ביטוח זה מה שנקרא Loss-ratio - שזה בעצם יחס בין הנכסים שאנחנו מקבלים ובין התביעות שאנחנו מקבלים, בדולרים.ככל שה-Loss Ratio יותר גבוה, אז החברה נמצאת בסיכון - וזה אומר שהיא לוקחת סיכונים מיותרים וגם משלמת את זה ב-Claims, בתביעות.ה-Loss Ratio אצלנו מצוין, באזור ה-30% ויורד - בין היתר כי אנחנו מסתמכים על תהליך חיתום מאוד מאוד יסודי ומסודר.ואז בעצם השאלה שאתה שואל אותי “רגע, אז אם זה דורש מומחיות, איך בכל זאת אפשר להכניס מודלים?”אז כמובן שלא כל מבנה אפשר לסמוך רק על מודלים, ובאמת בשלב ראשון לא הכנסנו ישר מודלים ו”יאללה, בואו נסמוך”, לא.אבל ראינו שיש הרבה מקרים שהנכסים במצב מצוין, מהסתכלות על התמונות או אינפורמציה שיש לנו על נכסבאמת יש לנו עשרות Feature-ים שאנחנו מקבלים על אותו נכס.אז בשני מצבים קיצוניים כבר די מהר אפשר להגיד אנחנו לא צריכים חתם - אם הבית הוא במצב מצוין מכל הבחינות האפשריותאו לחילופין אם הבית במצב גרוע, למשל - אם הגג נראה זוועה וברור שצריך להחליף אותו בשנים הקרובות, אנחנו לא ניקח את הסיכון הזה, אנחנו לא צריכים חתם . . .מספיק כשהגג נראה זוועה והמודלים עוברים מסתכלים ועושים בעצם אנליזה אוטומטית, אנחנו יכולים להיות בטוחים ורגועים שאנחנו דוחים את הנכס הזה.עם כל הכבוד ללקוח, הוא מקבל תשובה מהירה ואגב גם הוא מרוצה מזה - כי בעצם בזה שאנחנו משלבים מודלים ומאפשרים מצב שבו חלק מהנכסים לא עוברים בכלל, לא מגיעים לחתם, הלקוח יוצא בזה דווקא נשכר, כי הוא מקבל תשובה מיידית.נכון, היא שלילית, אבל הוא מקבל תשובה מהירה והוא יודע שהוא צריך ללכת לחברת ביטוח אחרת, אז זה גם בסדר מבחינתו.(אורי)  או לתקן את הגג . . .(דרור) או לתקן את הגג, בהחלט כן, זה גם אופציה שאנחנו מאפשרים . . . יש מצבים שאנחנו אומרים “הגג במצב לא טוב - אנחנו מוכנים לבטח את הנכס, אבל בוא תתקן את הגג”.(רן) רגולטורית, אין בעיה? זאת אומרת, אפשר לסרב לכל לקוח? אין איזושהי רגולציה שאמרת שצריכים לספק סיבות  וכו'?(דרור) כן, אז יש תהליך מסודר. אנחנו גם לא עצמאיים לחלוטין - יש מבטחות משנה, שבמקרה שיש לנו תביעות, הן בעצם נותנות את הגושפנקה וגם משלמות את התביעה.אז כן, יש רגולציה מאוד מאוד מורכבת בארצות הברית.אנחנו גם צריכים כמובן לקבל את האישורים והכל בכל מדינה ומדינה, כמובן שמקפידים על הכל בצורה מסודרת.אבל הרגולציה כן מאפשרת היום להיעזר במודלים - ברגע שאתה מוכיח, הלכה למעשה, ב-Production, בתהליך מאוד מאוד סדור, שהמודלים עובדים as good as חתמים, אז מבחינת הרגולציה זה בסדר גמור.כל עוד הלקוח מקבל תשובות מפורטות ומוסברות היטב, אז אין שום בעיה עם זה.07:40 על מכונות וחתמים(רן) בסדר, אז למעשה הנושא של היום, כבר פחות יותר הצגנו את זה, אבל בגדול אנחנו מדברים על איךלוקחים את עולם החיתום - את עולם הביטוח של בתים במקרה הזה, אבל אני מניח שזה גם תקף למקרים אחרים - נתונים שמגיעים בצורה טבלאית, ויזואלית, ואולי גם יש עוד דברים שנדבר עליהם בהמשך - איך לוקחים את זהומפעילים על זה Machine Learning, זאת אומרת - מחליפים את החלטת החתם, במקומות שזה אפשרי, ולומדים ומשתפרים מזה.אז ככה, דרך אגב, התחילה החברה? זאת אומרת,  זה היה ה-Claim to Fame של החברה מלכתחילה?(דרור) כן, בהחלט - זה היה המוקד וזה היה החידוש המרכזי בחברה.כי תהליך החיתום היום, דיברנו עליו, הוא תהליך קצת Old Fashion, וחתמים גם זה קצת, זה Old Fashion, כי יש להם “שטאנץ” מסוים שהם עובדים לפיו.ובאנו ובעצם רצינו לשנות את זה די מהיסוד - אבל כמובן שעשינו את זה בהדרגה, לא מיד “נכניס מודלים ותשכחו מהחתמים” זה לא . . .(רן) אז אני, תרשה לי לנחש - וגם קצת דיברנו לפני זה, אז אני יודע - אבל תרשה לנחש שככל שיש יותר חתמים, כך יש יותר דעות . . . זאת אומרת, יכול להיות שחתם מסוים יבוא ויסתכל על בית ויגיד “X”, וחתם אחר יבוא ויסתכל על ביתויגיד “Y”, ולנו, כאנשי שMachine Learning זה עושה חיים קשים, כי פתאום יש שני תיוגים שונים לאותו ה-Data . . .אז איך מתמודדים עם אתגר כזה?(דרור)  כן, זו שאלה מעניינת.אני מכיר את זה קצת גם מעולם הרפואה, אני עסקתי הרבה ועוסק הרבה בעולם הרפואה, גם במישור האקדמי וגם בעצמי כפאראמדיק מתנדב במד”א הרבה שנים, אז אני מכיר את זה גם מעולם הרפואה.אבל שם זה עוד, זה פחות חמור - ואצלנו באמת בתהליך החיתום . . . למשל, אחד הפרויקטים שאנחנו כבר עובדים עליו ומשקיעים בו הרבה, זה פרויקט שבו אנחנו רוצים להסתכל על בתים - מראה חיצוני, על ה-Front, על החזית של הבית - ולתת ציון. זה הדבר, זה ה-Holy Grail - אם נצליח להשיג את זה, אז שיחקנו אותה בגדול.וכשאתה נותן . . . דבר ראשון שעשינו זה שלקחנו שלושה חתמים בחברה, ואמרנו להם “בוא תסתכלו על נכסים, כל אחד שייתן ציון”.כל אחד לא ידע מה השני נתן.עשינו מעין תחרות כזו בחברה - ובאמת קיבלנו שלוש דעות שונות. עכשיו, זה לא מצב שבו חתם אחד אומר שהנכס הוא מצוין, “מאה מתוך מאה", והשני יגיד שזה “אפס מתוך מאה”, אבל יש Variance, ישנה שונות מסוימת בציונים.וכן, בעולם ה-Machine Learning, הדבר הכי חשוב זה אנוטציות (Annotations) מדויקות, תיוג מדויק - וכשאין לך את זה, אתה בבעיה.(אורי) או סטטיסטית . . . .(רן) . . . או שלפחות יהיה מספיק . . . (אורי) . . .  כן, או שאתה צריך משהו שהוא Significantly סטטיסטי.(רן) אבל פה, זהו - התיוג הוא יקר, אז אין כל כך הרבה תיוגים, וגם יש הרבה Variance.(אורי) נכון . . .(דרור) אז קודם, כל זה באמת אתגר משמעותי.לגבי יקר - בוא נשים את זה רגע בצד, כי זה פתירכי ברוך השם, אנחנו במצב טוב, מבחינת החברה, מבחינת הכנסות וכו’ . . . (רן) אוקיי, אבל זה לא כמו מנועי-שפה, שיש להם את כל האינטרנט ללמוד ממנו, בכל אופן - אתה צריך להעסיק אנשים, אתה צריך למצוא את התיוג.(דרור) נכון. לא רק זה, יש בעיה מסוימת בעולם החיתום - אגב, היא מתרחשת גם בעולם הרפואה - שבניגוד לעולמות אחרים, שיש Data אינסופי שמתפרסם, ו-Google ו-Microsoft וכולם, בעולם החיתום, נתוני התביעות לא מתפרסמים.אתה לא יכול לקבל . . . אנחנו גם, אין לנו גישה לנתוני התביעות, למעט התביעות שלנו כמובן.תביעות של חברות אחרות - אין “Open Source”, אנחנו לא יכולים, היינו מאוד רוצים . . .ולכן אנחנו צריכים להימדד באמצעות Data פנימי שלנו, ובאמת התחלנו לאסוף כמויות מטורפות של Data.החברה משקיעה בזה המון המון משאבים, לא רק כסף, אלא גם אנשים שעובדים ומתייגים.ואחת הדרכים - יש מספר דרכים להתמודד עם הדבר הזה - אז קודם כל אם היית שואל אותי לפני שנתיים, הייתי אומר לך “תקשיב, זו חתיכת בעיה, לא הייתי נוגע” . . .זו בעיה מאוד קשה, בעיה של סובייקטיביות, של האנוטציות והחוסר-עקביות - אפילו אם אתה נותן לאותו חתם את אותו נכס, תמונה של אותו נכס שבוע אחרי שבוע, התשובה לא תהיה זהה.(רן) כמו שופטים בבקשות Paroles . . . זאת אומרת, אם זה לפני ארוחת צהריים או אחרי ארוחת צהריים [Hungry judge effect].(דרור) כן, בהחלט. אגב, גם עולם המשפט, אפשר לדבר על זה, שיחה נפרדת, גם את זה אני קצת מכיר מקרוב.(רן) יש הרבה מקומות שבהם יש החלטות כאלה סובייקטיביות, והבעיה, כמו שאמרתי - אנחנו פה מדברים על ביטוח, אבל זו בעיה כללית למשימה . . .(דרור) בעיה כללית, בהחלט. והיום, אגב, מדברים על AI לעולם המשפט, אבל נשאיר את זה כנראה לפודקאסט אחר . . . (אורי) שאגב, גם הוא לא קונסיסטנטי (Consistent) תמיד . . .(דרור) נכון, והשאלה איך מפצחים את הדבר הזה? קודם כל, באמת אתגר שהוא . . .  אני לא יכול להגיד שפיצחנו אותו לגמרי, אבל אני חושב שאנחנו מתחילים לראות “סימני נפט”.ואיך שעשינו את זה, אז קודם כל ברור שאתה לוקח מספר חתמים, אתה לא מסתמך רק על אחד.אתה צריך שיתוף פעולה שלהם, אתה צריך שהם יקדישו לזה זמןואתה נותן להם המון תמונות - היעד שלנו להגיע למאות-אלפי תמונות שהם עוברים עליהם ומתייגים.זה לא טרויוויאלי בכלל, אבל החברה Dedicated לזה ו-Committed לזה.דבר נוסף, אתה צריך לעשות תהליך מאוד מסודר איתם, וזה דורש מחויבות מאוד גדולה, של Training מסודר.כלומר, קודם כל, עוד לפני שזה בעיה של Machine Learning - זו בעיה של החברה.כלומר, איך יכול להיות שעל אותו מקרה או על אותו בית, חתם אחד יגיד “כן, אני מאשר את זה לחיתום, אני מאשר את זה לביטוח”, ואחר יגיד שלא?בחברה מתוקנת, אסור שזה יקרה, יש פה פוטנציאל או להפסד כספי של נכס שוויתרנו עליו, או לתביעות - ואת זה אנחנו צריכים לפתור.ועושים את זה דרך תהליך שיתוף פעולה עמוק עם החתמיםלמזלנו הם בתוך החברה, הם לא חיצוניים, אז יש  להם את אותו אינטרס בדיוק כמו צוות ה-AIואתה יושב איתם, ואתה בונה Training Material מאוד מסודר, עם Guidelines מאוד מסודרים, Checklist ממשכשאתה עובר על נכס, זה לא סתם להסתכל . . .זה מזכיר לי, באקדמיה כשאתה בודק בחינות - גם בחינות, במידה מסוימת, זה סובייקטיבי.איך אתה מתמודד עם זה? אתה עושה Checklist - כמה אתה מוריד על כל שגיאה? זה אינטנסיבי, זה דורש הרבה יותר זמן פר בחינה, אבל זאת עוד הדרך להגיע לעקביות, בתהליך מסודר.(רן) זאת אומרת, הם למדו את המקצוע, הם חתמים - אבל אתה עכשיו צריך “לכייל” אותם . . . (דרור) צריך לכייל אותם . . . .(אורי)  . . .  כדי לייצר מהם Training Data . . . (דרור) . . . לייצר מהם Training Data - ולא רק Training Data, לייצר עקביות בחברה עצמה . . .זה לא רק זה. זה פתאום משליך, כשהחברה מתחילה להבין את זה, ונופלים כל האסימונים, אז אתה מבין שרגע, איך מקבלים חתם חדש לחברה? איזה תהליך Training הוא עובר?ואז אנחנו מבינים שאנחנו צריכים באמת “לכייל” את כל התהליך ה-Training, עוד לפני ה-Machine Learning, כדי שתהליך החיתום יהיה עקבי בחברה, זה דבר ראשון.(רן)  דרך אגב, חברות אחרות - יש להן אינטגרציה לזה? זאת אומרת, הן עושות נגיד Review כפול או משולש או דברים בסגנון הזה? איך מתמודדים?(דרור) אז קודם כל, עולם החיתום הוא די לא אגיד “סודי”, אבל הוא לא פתוח . . . אז קשה לי לדעת מה עושה כל חברה וחברה.אני יודע שיש כל מיני ניסיונות להתמודד - אבל אני לא מכיר פעילות כזאת שנעשתה בחברות אחרות.יכול להיות שאני לא יודע, אני מן הסתם לא יודע הכל, אבל אני לא מכיר פעילויות כאלה.הדבר הנוסף שעשינו זה בעצם לא להילחם עם זה.כלומר, יש מידה מסוימת של סובייקטיבית, “לא יעזור בית דין”.אתה יכול להגיד, לבוא למנכ״ל - איתי, המנכ״ל שלנו - ולהגיד “תקשיב, זה לא יעבוד, בוא נשכח מזה ובוא נעבוד לדברים יותר בטוחים”.ופה התעקשנו - אנחנו, הנהלה של החברה אמרה “לא, אנחנו מוכנים לקחת את הסיכון”.כן זה פרויקט בסיכון גבוה, אנחנו . . . יש תקציב, אנחנו מוכנים לקחת את הסיכון, גם זה אומר שאני צריך להשקיע הרבה מאוד משאבים ויכול להיות שבסוף זה לא יעבוד.בעיניי, זה חלק מהדברים הכי יפים שקרו לי ב-Honeycomb ואחד מהדברים שאני הכי מעריךזו המוכנות של החברה לקחת גם סיכונים, לקחת פרויקטים בסיכון גבוה.להשקיע המון כסף.15:15 אבל למה?(אורי) אבל בוא נדבר קצת על ה-Benefit . . . . כאילו, למה? למה פרויקט של להכניס Machine Learning לעולם  הזה היה להם כל כך חשוב?(דרור) אני חושב ש . . . אוקיי, אז יש פה כמה סיבותקודם כל, סיבה פרקטית - אתה לא רוצה . . . כל הרעיון של החברה זה לא עכשיו לגייס צבא שלם של חתמים, שעולים הרבה כסף וגם איטיים בתהליך החיתום שלהם, זה אחד.החברה - אין זכות קיום לחברה,  זה החידוש המרכזי בחברה. הדבר השני, והיותר חשוב בעיניי, זה החוויית משתמש - אתה רוצה שתהליך החיתום יהיה הכי מהיר שאפשר, לפחות ב-Subset של מקרים. כלומר, היעד שלנו, החזון של החברה, זה 80% מהאפליקציות לביטוח שיתקבלו ללא מעורבות של חתמים, אוקיי?איך משיגים את זה? רק באמצעות Machine Learning.והיתרון בזה שבעצם הלקוח . . . סליחה, זה יכול להיות לקוח זה יכול להיות סוכן של הלקוח,  מקבל תשובה מיידית.גם אם התשובה שלילית, הוא מקבל תשובה מיידית. בתור אחד שהיה לו בית בארצות הברית בזמנו, זה מאוד מאוד קשה עד היום, אגב, בחלק מהחברות.כש-Honeycomb לא פעלה . . .  אני, הבית שלי היה בפנסילבניה, בפיטסבורג, ו-Honeycomb בזמנו לא פעלה שם, אז היה לי ביטוח דרך Nationwide.ואחרי שנה, כשרציתי לחדש את הביטוח, פתאום אוקיי אמרתי “בוא נעשה סקר שוק”.אתה פונה - וכל חברה שאתה פונה, עד היום, אתה צריך למלא הרבה מאוד אינפורמציה על הנכס . . .לא גרתי בדירה, זו הייתה דירה להשקעה במקרה הזה.מאיפה אני יודע בכלל מה ה-Type of Wall וכל מיני פרמטרים . . . Square ft. וזה . . . התהליך הזה מאוד מאוד קשה - וגם אז כשאתה פונה, אתה צריך לחכות שבועיים-שלושה לקבל את התשובה.מה קורה אחרי שבועיים-שלושה? התאריך של הביטוח . . .  הביטוח עוד מעט פג-תוקף, ואתה מקבל תשובה  שלילית . . . אתה צריך עכשיו ללכת . . . אתה קודם כל נלחץ, ואתה צריך ללכת לחברת ביטוח אחרת.אנחנו משנים את זה מהיסוד. אנחנו נותנים תשובה מיידית ללקוח - בין אם היא חיובית, בין אם היא שליליתבין אם זה על תנאי - “בוא, תתקן את הגג ונבטח” . . .אז הלקוח מרוויח מזה, וחוויית-המשתמש הרבה יותר טובה.ואנחנו מקבלים פידבקים מאוד חיובים על זה - ורואים את זה גם כמובן בהכנסות.(רן) כן אני מניח שיש גם לקוחות שממקבלים . . . אז אולי שולחים לכמה חברות אחרות במקביל, ואם יש תשובה מכם ראשונים אז יקנו אצלכם.(דרור) בהחלט. אז באמת בהקשר הזה, יש לנו מוצר די חדש שמאפשר לסוכנים לקבל . . . להעביר רשימה של נכסים.כי הרבה פעמים סוכן מטפל עבור לקוח מסוים בעשרות דירות - המשקיעים הגדולים בארצות הברית.אז אנחנו מקבלים רשימה של דירות, ואמרו להם בוא תבדקו על כל הדירות האלה - מה האחוז מתוך הדירות שאתם תהיו מוכנים לבטח?ויש לנו אפשרות לתת להם מענה די מיידי - לעבור על הנכסים, להוציא את כל האינפורמציה, בלי שהם יכניסו, אנחנו שולפים את האינפורמציה מ-3rd Parties ומההיסטוריה שלנו ונותנים תשובה מיידית לסוכנות.(רן)  ממש מעבר על ה-Portfolio . . . .(דרור) כן, לגמרי.18:05 תלוי(רן) אוקיי, אז נעצרנו בנקודה שבה יש לך תיוגים, אולי אפילו מאות-אלפים או אולי זאת המטרה, אבל הבעיה היא שהם מאוד סובייקטיביים. אוקיי? לא יודע, תלוי בשעה של היום, תלוי ביום, תלוי במסווג כמובן, בחתם עצמו . . . איך מתמודדים את זה? אם זה בעולם ה-Machine Learning . . .(דרור) אז זה די מתחבר לעולם התוכן האקדמי שלי. במשך הרבה שנים לימדתי קורסים, למשל קורס שנקרא “אותות אקראיים”.זה קורס שבעצם מדבר על התפלגויות של נתונים. כל דבר, בעצם, שקורה בעולם האמיתי - טמפרטורה, לחות, משקעים וכו', גובה הגלים . . . זה איזשהו משתנה אקראי. ובעצם, אתה מבין שגם הציון שחתמים נותנים זה איזשהו משתנה אקראי - הוא לא לגמרי אקראי, במובן זה שכל פעם הוא ייתן ציון אחר, אבל יש פה . . . יש לו איזושהי התפלגות.כשאתה מבין את זה, וכמובן אני לא אצלול ל-Details הנקרא לזה “סודיים” של האלגוריתם וה-IP, אבל כשאתה מבין את זה, אז אתה מבין שבעצם אתה צריך לשערך איזושהי התפלגות, ולא את הציון עצמו.כלומר, יש איזשהו, בוא נניח רק לצורך הפשטות, שיש, אם אתה לוקח את כל הציונים של חתמים - ולקחנו הרבה חתמים ולא חתם אחד, אז יש להם איזושהי התפלגות לכל Property.ואם אתה תצליח לשערך טוב את ההתפלגות הזאת, אז אתה במצב טוב. כלומר, אתה תדע שיש טווח ערכים “סביר” שחתם ממוצע אמור לתת, צפוי לתת את הציון.את זה אתה משערך, את זה המודל שלך משערך - ואז אנחנו במצב...(רן) אבל אתה כן צריך להגיע למשל מנקודת הנחה של מה ההתפלגות, נכון? זאת אומרת, כדי שתוכל למדל את זה, אתה מניח שזה התפלגות לצורך עניין, נגיד, גאוסיאנית או כל אחת אחרת, ואז באמת תוכל לשערך את זה . . .(דרור) אז אנחנו לא עושים את זה - כי אנחנו לא רוצים להניח הנחות מוקדמות.אנחנו פשוט משתמשים ב-AI - ברשתות נוירונים - כדי לשערך התפלגות כללית.דיברת על גאוסיאנית - גאוסיאנית מאוד ממקד אותך, שוב, בלי לי להיכנס ל-Details היותר משעממים, אבל התפלגות גאוסיאנית היא התפלגות מאוד מאוד ספציפית, שלמעשה לא קיימת במציאות . . .(רן) נכון, נכון . . .(דרור) . .  אז אתה משערך משהו יותר כללי.(רן) חוץ מאולי חוק המספרים הגדולים [משפט הגבול המרכזי], אבל זה לא שם. (דרור) כן, בדיוק.(רן) נכון מאוד, כן. ואולי למדתי באוניברסיטה שכל דבר . . . כל תרגיל מתחיל בהתפלגות גאוסיאנית, אבל במציאות זה בדרך כלל לא.(דרור) זו אחת השאלות הראשונות שאני שואל את הסטונדטים שלי . . . הסטונדטים בדרך כלל באים אחרי קורס מבוא להסתברות, אני אומר “למדתם התפלגות גאוסיאנית ופואסונית וכו’… בואו תגידו לי . . . “קוראים לזה “התפלגות נורמלית" או “גרף פעמון”, עוד מהתיכון מכירים, מה במציאות מתפלג?אז כל פעם זורקים לי כל מיני דברים, אבל בפועל אין שום דבר שמתפלג גאוסיאנית, כי זו התפלגות שהיא סימטרית ואינסופית, לא קיים דבר כזה במציאות.(רן) אולי זה סכום כל ההתפלגויות בעולם, וזהו.20:35 ואז מגיעים לקוחות(רן) אוקיי, עכשיו - עוד בעיה שקורית די הרבה למי שמתעסק בעולם ה-Machine Learning זה שבמעבדה הכל עובד יפה, תחת אור הניאון . . .  זאת אומרת, אתה מאמן מודל, אתה בודק את הביצועים שלו, זה נראה יופי-טופי. גם אחרי שאתה פורש את זה, כנראה ביום-יומיים הראשונים הכל טוב - ואז אחרי איזשהו זמן, לפעמים אתה לא שם לב, וזה קורה בכל חברה, אורי, אז בטוח שזה שגם קרה ב-Outbrain . . .(אורי) ואחרי זה מגיעים לקוחות . . .(רן)  . . . כן, ואחרי איזשהו זמן פתאום דברים משתנים, פתאום דברים לא עובדים כמו שצריך.עכשיו, זה לא שהכנסת איזשהו באג, אולי בכלל לא שינית את הקוד. לא פרשת שום גרסה, אבל פתאום הביצועים של המודל ניהיים יותר ויותר גרועים.האם קרה לכם? אני מנחש שכן . . . ואם כן, אז איך מתמודדים?(דרור) א' - כן, קרה.ב' - זה הפחד הכי גדול שלי . . . אני, בעצם למעשה מ-97' בעולם ה-Machine Learning, עוד לפני שקרו לזה AI, לפני שהיה Deep Learning ו-LLM-ים ו-HGBT, אז אני לא מעט שנים, וכמו שאתם רואים כבר שיערות אין לי על הראש, אז אני למוד ניסיון . . . אבל זה תמיד מפחיד, כי באמת, אתה מכניס מודל, אתה עובד עליו הרבה זמן, אתה מוכיח תוצאות טובות . . .ושוב, האינטראקציה עם החתמים - החתמים צריכים, מי שבפועל, לא הייתי אומר מוביל את החברה אבל אולי  אחד התפקידים הכי משמעותיים בחברה, זה ה-Chief Underwriter [בטוח יש דמות כזו אצל Terry Pratchett], החתם הראשי.שהוא בעצם מאשר לנו כל מודל, כי האחריות היא שלו. דיברנו על רגולציה קודם, האחריות היא שלו.ובאמת, סתם, לצורך הדוגמא - יש לנו מודל שהכנסנו ל-Production כבר, לדעתי, לפני שנתיים או משהו כזה, וזה מודל שמקבל החלטות, בלי מעורבות חתם.הוא מחליט לדחות חלק מהנכסים, על סמך האינפורמציה שיש על הנכס, כמובן בלי להיכנס ל-Details ו-Feature-ים.וזה מודל שהוכיח תוצאות יפות, והראינו את זה - הצגנו להנהלת החברה, והם נתנו לנו אור ירוק. זה גם יוצר אמון - אתה בא, אתה עושה עבודה יסודית, במקרה הזה לא אני אישית, מישהו מהצוות שלי.הראה להם תוצאות, שכנע אותם שזה מודל שעובד טוב.יש לו משמעות אדירה לחברה - לטוב ולרע - כי הוא דוחה נכסים.כי אם אתה דוחה נכסים טובים, אז החברה הפסידה כסף נקי. מצד שני, הראינו שהוא - יש לו יכולת לזהות מראש נכסים שהם פוטנציאליים לתביעות.כלומר, ראינו שבשימוש במודל אנחנו מורידים דרמטית את כמות התביעות שאנחנו מקבלים, שזה מאוד דרמטי לחברה.ובזכות זה בין היתר הגענו ל- Loss Ratio המאוד מאוד נמוך שהזכרתי קודם.הכנסנו את זה ל-Production, זה רץ - רץ, חודשים, עובד טוב. ומדי פעם אנחנו מעדכנים אותו, כי אם נוסף לנו עוד Data אז אנחנו מאמנים אותו מחדש, בודקים, מנסים אותו ל-Production, כולם שמחים, הכל בסדר.יום בהיר אחד, אנחנו פתאום רואים - ואני מודה, טעות שלי, לא עקבנו יום יום, היינו רגועים, כי ראינו שזה כבר נכנס ועובד טוב - יום בהיר אחד אנחנו רואים קפיצה בדחיות שהמודל עושה, קפיצה דרמטית מאוד.קפיצה שהגיעה בעצם לאזור ה-400 אלף דולר של הפסדים רק בשבועיים.לקחנו זמן, כי לא עקבנו, כי סמכנו על המודל, וגם הנהלה סמכה עלינו - ופתאום אנחנו באמת מגלים, בודקים את זה, רואים משהו פה לא מסתדר.מיד עצרנו את זה, החזרנו את המודל הקודם - והסתבר שבאותה תקופה בדיוק הוכנס עדכון נוסף, עשינו אימון נוסף, בדקנו, אבל הסתבר שעשינו שם טעות בהערכת ביצועים.הייתה שם בעיה, בדיעבד מאוד מאוד נפוצה בעולם ה-Machine Learning, שזה באמת הפחד הכי גדול שלי, שזה שינוי בהתפלגות.המודל עובד, הוא משפיע, הוא דוחה חלק מהנכסים - אז בגלל שהוא דוחה חלק מהנכסים שהם הפחות טובים, הוא משנה את ההתפלגות שיש לנו ב-Production . . . אז פתאום, מה שקרה זה בעצם Drift בתוצאות - פתאום ההתפלגות שהמודל רואה ב-Production זו לא  ההתפלגות שאימנו אותו ב-Offline.מקבלים Drift משמעותי בתוצאות.אני מספר על זה, זה נשמע עכשיו פשוט - לקח לנו זמן להבין את זה . . .(רן) זאת אומרת שהיה פה, אני מנסה לרגע להבין - היה פה איזשהו Feedback Loop . . . זאת אומרת, בהתחלה העולם היה כמו שהיה, כמו שהכרת אותו, ואימנת את המודל לפי זה. ברגע שהמודל התחיל לפעול, הוא למעשה שינה את תמונת העולם שהוא רואה לאחר מכן - והיה פה איזשהו Feedback Loop, שזה כן, כמו שאתה אומר, זה כאילו טריוויאלי כשמספרים את זה בדיעבד, אבל זה מאוד קשה לעלות על זה בזמן אמת.(דרור) בהחלט. אז קודם כל, מה שעשינו זה שעשינו הקפאת מצב, כלומר - החזרנו את המודל הקודם, היציב  והטוב, אמרנו “בואו עכשיו, תנו לנו רגע לעשות Post Mortem ולהבין, כמו בחיל האוויר, להבין בדיוק מה קרה  פה.(רן) הנה, זאת שיטה - אז חודש מודל ישן, חודש מודל חדש . . . (דרור) כן . . . אבל יש פה בעיה הרבה יותר קשה מ . . .סתם, עזוב את ה-400 אלף דולר, “לא קרה כלום” - החברה יודעת לספוג, ואני מאוד גאה ב-Honeycomb  שיודעת להכיל גם מקרים כאלה, להגיד, לא קרה כלום.אני זוכר שאני הייתי מוטרד, לא שיפטרו אותי, אבל יגידו לי “נו- נו- נו” . . .  לא, אנחנו, המוטו של Honeycomb, ואני ארבע שנים, זה כמעט מהרגע הראשון - “בואו נטעה מהר”בואו נטעה מהר - העיקר שנלמד ונתקן.אני אישית מאוד מעריך את זה.ובאמת נתנו לנו את הזמן, קודם כל להבין, לחקור.הצגנו דוח מסודר לכל הנהלה של החברה, ול-Chief Underwriter.הם קיבלו את הדוח, ראו, קודם כל יצרנו אמון מחדש בזה - זכינו באמון מחדש בזה, שבאנו, לא התביישנו להגיד, אמרנו, “הנה, לקחנו אחריות”האחריות שלי כראש צוות - הנה התקלות, והנה ככה אנחנו מתקנים את זה.וקיבלו את זה, וזה היה יופי של דבר מבחינתי.זאת אומרת, מצד אחד, זה חתיכת פשלה שלי כראש צוות, תקלה שאסור שתקרה, עם הפסדים מאוד משמעותיים.אבל אני שמח שזה קרה - זה אולי נשמע מוזר, אני שמח שזה קרה.למדנו, תיקנו, למדנו, כשזה היה ב-Scale נמוך, היום זה היה יכול לגרום לנזק הרבה יותר גדול.אנחנו שיפרנו את התהליכים, אנחנו עושים Monitoring הרבה יותר מדוקדק, אנחנו הרבה יותר חכמים.אני בטוח לזה עוד יקרה, אבל אנחנו יודעים גם לתקן את זה מהר, בזכות זה שאנחנו עושים Monitoring שוטף.ואנחנו גם למדנו את הבעיה הזאת - יש הבדל בין להכיר את זה בתיאוריה, אני הכרתי את זה בתיאוריה, חוויתי את זה גם ב-Citi Bank -  לבין לראות את זה בשטח, כשזה משפיע על Production בצורה כזו דרמטית,אז למדנו מזה ושיפרנו את התהליכים - וגם שוב, רכשנו את האמון וזה מאוד חשובכי בעבודה עם ה-Underwriter-ים, כמו עם רופאים אגב, אתה חייב את האמון.אם לא יאמינו לך ולא יאמינו במוצר, הם לא ישתפו פעולה ואיבדת אותם - וזה לא פחות חשוב מהאמון של לקוחות.במקרה שלנו, הלקוחות שלנו, ה-Stakeholders שלנו זה כמובן החתמים - אנחנו חייבים אותם איתנו.ולמזלי זה קרה, ואפילו חזקנו את הקשר איתם, אז אני שמח שזה קרה.27:04 אתה יכול להסביר?(אורי) לי יש שאלה,  שגם נוגעת לאמון וגם נוגעת למשהו שאמרת בהתחלה: שלפעמים, יש . . . פסלתם בגלל שהגג ישן,אז אתה רוצה להחזיר פידבק - שהגג ישן או למה פסלת, או למה המודל לקח החלטה. זה קשור לאקספליינביליות (Explainability) של המודל, כמה אפשר להסביר את ההחלטות שלו. ויש סוגי מודלים שהם יותר אקספליינביליים (Explainable) וכאלה שהם פחות. וזה גם שהאקספליינביליות הזאת - היא מייצרת אמון, גם של לקוחות אבל גם של מי שאמור לאשר לך את המודל.אז איפה אתם עומדים עם זה?(דרור) אז קודם כל, יש Debate מאוד גדול בעולם האקדמי והתעשייתי על הנושא של אקספליינביליטי (Explainability).אני קצת לוקח גישה קיצונית, אני אסביר טיפה - קודם כל יש סתירה בין הרצון שלך להיות מסוגל להסביר את המודל לבין הביצועים של המודל.בעיני, ביצועים מעל הכל - כלומר, ככל שהמודל יותר טוב מבחינת ביצועים, אז הוא מן הסתם יותר מורכב.בעולם הרשתות היום, רשתות עמוקות - The Deeper The Better כמו שאומרים.ככל שהרשת יותר עמוקה, זה אומר הרבה יותר פרמטרים.אנחנו מכירים היום כולנו את ה-LLM ו-HGBT - זה מיליונים ואפילו מיליארדים של פרמטרים.ככל שהרשת יותר עמוקה, עם יותר פרמטרים, אתה לא יכול להסביר אותה - אין סיכוי.יש ניסיונות, יש Grad-CAM, יש כל מיני מודלים - הם לא עובדים טוב, זה עדיין לא בשל.לכן, אם אתה רוצה למקסם את הביצועים של המודל שלך, זה על חשבון Explainability.אנחנו, כחברה - נכון, חשוב לנו להיות מסוגלים להסביר את זה לחתמים, אבל מקבלים את זה שזה מודלים שעובדים במרחב המולטי-פרמטרי או במרחב הרב-פרמטרי, ולא נדע להסביר את זה.איפה שאפשר, אנחנו מנסים.במודלים היותר קטנים, יש לנו מודלים שעובדים על קומץ - לא  קומץ אבל כמה עשרות של פרמטרים - ושם אנחנו משתמשים בכלים שמאפשרים, Shapely וכל מיני כליםכלים שמאפשרים להסביר את המודל, וזה באמת עוזר במוצבים מסוימים להסביר.ברגע שאתה רוכש את האמון - בדם, יזע ודמעות - של ההנהלה ושל החתמים, אתה לא צריך את האקספלינביליטי (Explainability).הם סומכים עלינו - לא אגיד “בעיניים עיוורות”, הם כל הזמן מסתכלים ואנחנו כל הזמן צריכים להראות, לחדש את האמון ולזכות בו מחדש באמצעות מעבר ביחד על התוצאות ועל התהליכים אצלנו. והם חלק מהעשייה אגב, הם לא איזשהם “לקוחות-קצה”, הם חלק מה-Squad-ים, חלק מהעשייה, חלק מהפעילות שלנו.ברגע שאתה רוכש את האמון, הם לא מבקשים הסברים. זה אולי קצת שונה מעולם הרפואה, שם הרופא רוצה לדעתרגע, הוא - לא מספיק לו שיש התקף לב, אני יודע את זה כפאראמדיק, המכשיר אומר “התקף” - וזה לא מספיק לי, אני רוצה לראות איפה.בין היתר, כי לא סומך על האלגוריתם, מה לעשות?בעולם החיתום, לפחות אצלנו בחברה, ברגע שהוכחנו שהמודלים עובדים טוב . . .אגב - לא 100%, אף מודל לא עובד 100%, יודעים שיש איזשהו טווח-שגיאהאבל ברגע שקבלנו את האמון, הם לא מחפשים את “בואו תסבירו לי למה זה ככה ולמה זה ככה”.זה כן קורה עדיין במקומות מסוימים - איפה שאפשר אנחנו באמת משתמשים במודלים, ה-State if the Art, הכי מתקדמים לנסות ולהסביר.מהניסיון והידע שלי, המודלים האלה עדיין לא בשלים ולכן צריך לקבל אותם בהסתייגות.(אורי) הם בעצמם צריכים לרכוש את האמון . . .(דרור) הם בעצמם צריכים לרכוש את האמון, כן . . .זה די סתירה, כי אתה רוצה מודלים חזקים שעובדים טוב - זה מודלים עם המון פרמטרים, שה-Explainability Models לא עובדים עליהם מספיק טובולכן אני מאוד נזהר מהשימוש במודלים האלה.(רן) כן , זה אחד - ושתיים, זה גם להשקיע מאמץ, זאת אומרת כוח אדם. אם אתה רוצה Explainability, אתה צריך לפתח את זה, וגם אם המודל, עקרונית, מסוגל לתת לך את זה, אתה עדיין צריך להשקיע מאמצים כדי שזה יקרה.(דרור) בהחלט.(רן) אוקיי. אז דרך אגב, יש מקומות שבהם, מבחינה רגולטורית, אתם כן צריכים? זאת אומרת, נגיד אם אני מסתכל על עולם הבנקאות והלוואות וכל זה, אז אני יודע ששם כן, יש מקומות שבהם פשוט צריך לספק הסבר [למיטבי שמע - 476 ML Explainability and friends with Dagan from Citrusx]. זה לא מספיק שתגיד “אבל המחשב אמר לי שאסור!” . . . אצלכם, יש מקרים כאלה שצריך את זה?(דרור) אז באופן אישי, אני לא מתעסק עם רגולציה בצורה ישירה.אבל המצב אצלנו הוא שברגע שהרגולציה אישרה לחברה לעבוד במדינה  -זה פר מדינה - ברגע שאישרו לנו לעבוד, התחלנו משיקגו והתפרשנו והיום אנחנו עובדים במעל שמונה-עשרה מדינותברגע שהרגולציה אישרה, זאת אומרת ברגע שהמדינה אישרה, הם לא נכנסו לנו לקרביים, הם סומכים על ה-Chief Underwriter.הוא לוקח את האחריות למעשה - כמו בעולם הרפואה למעשה, הוא לוקח את האחריות על כל החלטה שלנו.ואיך שהוא מקבל את ההחלטה, זה כבר עניין פנימי של החברה, הם לא ביקשו לראות.אנחנו כן, למבטחות-משנה, אנחנו כן מחויבים לתת להם דין וחשבון מלא.מבטחות-משנה זה אותן חברות שמטפלות בתביעות, כשקיימות כאלה.והן כן עובדות איתנו בשיתוף פעולה, והן יודעות מה אנחנו עושיםואני הצגתי מספר פעמים לאותן חברות, אז גם שם היינו צריכים לרכוש את האמון. ברגע שרכשנו את האמון והם סומכים עלינו, מהבחינה הזאת אין מגבלות.עולם הביטוח התפתח בצורה מאוד משמעותית בשנים האחרונות ומהבחינה הזאת הם חיים בשלום עם מודלים של AI.32:13 חסמי-כניסה(רן)  אוקיי, בואו ככה לקראת הסיום, נסטה קצת הצידה. אמרת לי קודם שאתה כבר בתחום מכמה - 97’? ועולםה-Machine Learning / AI, לא חשוב איך קוראים לזה היום, נראה מאוד אחרת. אז, הרשתות לא היו עמוקות,גם לא כל כך אהבו אותן אז.והיום הדברים נראים אחרים - כל אחד יכול להרים LLM, לעשות Embedding, להשתמש במודל Computer Vision, מפלצתי ככל שירצה, וזה עולה סנטים בודדים.בואו נדבר קצת על פרספקטיבה, ככה, של חסמי-כניסה לעולם הזה. ממה שהספקת לראות לאורך השנים,איך זה נראה היום לעומת איך זה נראה פעם?(דרור) שאלה מעניינת . . .  אגב, אני אתחילו אולי מהסוף: רואים את זה יפה מאוד בצוות שליאנחנו היום עשרה אנשים, ואגב, אם מותר להגיד - מחפשים כל הזמן אנשים טובים, בתחומי ה-Machine Learning, Deep Learning, Analytics וכו’אז יש משרות פתוחות, מוזמנים להגיש.הצוות שלי הוא צוות מאוד מגוון, ואחד מהדברים היפים שלגאוותי הצלחתי להרים, או החברה הצליחה, זה לאסוף אנשים מגוונים.יש לנו מישהו מתחומי הכימיה ויש הנדסה ביו-רפואית עם דוקטורט בכימיה, הנדסה ביו-רפואית והנדסת חשמל ופיזיקה ומדע המחשבוגייסנו בדיוק שני סטודנטים גם שיעזרו . . .אז באמת, הגיוון הזה מעיד על עצמו. כלומר, אם בעבר, אם נלך אחורה ל-96-97’, זה היה פרויקט ההנדסי שלי, במסגרת תואר ראשון להנדסת חשמל באוניברסיטת בן גוריוןאז באמת התחלתי לעסוק - אז זה נקרא Signal Processing, Machine Learning . . . ה-”Classical” , כמובן לא היה “Deep”  . . . היו מודלים של פעם, מה שנקרא Gaussian Mixture Model ו-Hidden Markov Model - כל מיני מודלים כבר שאף אחד לא זוכר אותם.היית צריך לעבוד קשה כדי להיכנס לתחוםאני, בתואר ראשון, עשיתי ארבעה קורסים בתחום ופרויקט הנדסי, שחרשתי עליו כל שנה ד'המשכתי ישר לתואר שני - הייתי עתודאי, זה היה תוך כדי הצבא - עשיתי . . .  כל התואר השני שלי בעצם היה קורסים ב-Machine Learning והתזה שלי ב-Machine Learning.המשכתי לדוקטורט וכו’.כדי להגיע למצב שבו אני יוצא לתעשייה - יצאתי לתעשייה ב-2007, הסטארטאפ הראשון שעבדתי בו בעולם  הרפואי - הייתי צריך לעבוד קשה, להגיע עם כמעט דוקטורט מלא והמון קורסים והמון השקעהוהמון Coding - אז זה היה ב-MATLAB ו-C וכאלה.היום המצב שונה לחלוטין, ולמעשה אני - גם כאדם בתחום - הייתי צריך להמציא את עצמי בחדש.כי ב-2012 קרתה לנו מהפכה, בזכות איזשהו בחור יהודי נחמד בשם Alex Krizhevsky [AlexNet, עם Ilya Sutskever ו-Geoffrey Hinton, ושוב למיטבי שמע - 363 GPU @ Nvidia].עבד ב-Stanford [ב-Toronto? . . .], עשה שם את הדוקטורט שלו, לא ניכנס ל-Details אבל בעצם כל העולם הזה עבר מהפכה.היום, כדי להיכנס לתחום - אפשר לראות את זה לטובה ולשלילה - לטעמי, ואני קצת אקצין -  מספיק לעשות קורס אחד טוב של Stanfordזה CS231N למי שמתעניין - קורס בדיוק בעולם ה-Deep Learning ליישומי Visionויש קורסים מקבילים כמובן במקומות אחרים, גם אני מלמד קורס דומה באקדמיה לא מעט שנים.ובאמת, מספיק לעשות קורס אחד טוב - אבל לעשות אותו כמו שצריך, להבין טוב את התיאוריה ולתרגל אותו - ואתה יכול יפה מאוד להסתדר.עכשיו, לא רוצה להגזים - בתעשייה, בדרך כלל היום התעשייה כן מצפה עדיין לראות אנשים תואר שני, עם תזה.גם אנחנו מחפשים אנשים טובים עם ותק בתחום וכמובן תארים ותזה וכו’.אבל עדיין אתה יכול לעשות הרבה דברים אחרי קורס אחד טוב - וכמובן, שוב, אתה צריך להשקיעאתה צריך ללמוד Python טוב הכל מבוסס על Python - אבל זה בהחלט אפשרי. כלומר, החסם הוא הרבה הרבה יותר נמוךזה מאתגר, זה גם שואל את השאלה, ככה, אפשר לפתוח את זה לדיון שלם - אבל מה היתרון של אנשים כמוני, עם דוקטורט ופוסט-דוקטורט?לא סיפרנו או לא סיפרתי את כל קורות חיי, אבל פוסט-דוקטורט והרבה שנים באקדמיה ופטנטים  ומאמרים . . . אני חושב שפחות היום . . . זאת אומרת, החסם הרבה יותר הרבה . . .זה יוצר גם תופעות שליליות, אגב - הרבה אנשים נוהרים לתחום, כי “AI זה AI”, המשכורות גבוהות, התנאים טובים, כולם רוצים לעסוק בזההרבה אנשים נוהרים לתחום - ולא כולם טוביםחלקם בינוניים, חלקם עשו כל מיני הסבות מקצועיות - אני לא פוסל, חלילה, אבל זה מאוד אינדיבידואלי.אתה צריך עדיין להשקיע כדי להיות באמת טוב בתחום שלך. אז זה יוצר לא מעט בעיות. כלומר, גם אנחנו צריכים לברור טוב מאוד את האנשים, בתהליכים ובראיון מסודר  ומבחני ביתאין מה לעשות, חייבים לבדוק טוב את החבר’ה, אנחנו באמת מחפשים את האנשים הטובים.אז מצד אחד, כן - לאנשים יותר קל להיכנס לתחום, לעשות הסבה המקצועית או ללמוד במסגרת הלימודים.אנחנו רואים היום אנשים בתואר ראשון, סטודנטים אפילו או כאלה שסיימו תואר ראשון - יש להם יכולות ויכולים כבר מ-Day One לפתח מודלים ולעשות הרבה דברים, ליצור אימפקט.לא צריכים תארים מתקדמים בהכרח.ויחד עם זאת, יש הרבה נהירה של אנשים שהם גם פחות טובים, עם פחות יכולות, פחות יכולת להבין טוב את המודלים.לי אישית מאוד חשוב שאנשים שאצלי בצוות יבינו טוב את המודלים שמאחורי הדברים, ולא רק ידעו להשתמש. להשתמש זה מאוד קל, להריץ ChatGPT זה מאוד קל, כל אחד יכול.להבין מה קורה מאחורי המודלים - מתי אפשר להשתמש, מתי לא, דיברנו קודם על התפלגויות וכו’ ואמון, שינוי בהתפלגות . . . .מאוד מאוד חשוב עדיין להיות זהירים. אז בהחלט זה יוצר . . . מצד אחד החסם ירד, מצד שני - נהירה שדורשת מאיתנו להיות יותר זהירים, בטח בעולמות הביטוח.אבל זה חלק מהאתגר, זה חלק מהכיף, ואנחנו מתמודדים עם זה, למזלי, בהצלחה.37:38 ה-Waze של ה-Machine Learning(רן) כן, אני אנסה אולי להציע תיאוריה, או לפחות לשאול אותך על דעתך, למה יכול להיות שזה קרה. אז נגיד, אפשרות אחת זה אולי כי הכלים יותר “בוגרים”, הכלים יותר מוכנים. זאת אומרת, כמו שאמרת, אפשר להריץ, כל אחד  יכול להשתמש ב-GPT וגם בכלים יותר מורכבים, הם פשוט הרבה הרבה יותר נגישים ממה שהם היו פעם. אז זו, נגיד,יכולה להיות תיאוריה אחת. תיאוריה אחרת היא שאם אולי קצת לחזור לשיחה על האספלניביליות (Explainability), גם ככה אף אחד לא מבין . . .  זאת אומרת, המודלים כל כך גדולים, גם ככה “הכל שם בנפנופי-ידיים”, ככה שאין ערך-מוסף להבנה עמוקה  בסטטיסטיקה או ב-Machine Learning. זאת אומרת, יש פה קצת יותר תחושות-בטן, אולי, ככה, ניסיון הנדסי,אבל לא בהכרח הבנה מתמטית, כי גם ככה ההבנה המתמטית לא כל כך עוזרת.(אורי) . . .  גם יש הרבה דברים שהם Off the Shelf - אתה לא צריך לבנות אותם, אתה לא צריך להבין אותם מתמטית . . . (רן) כן כן, זה היה פחות או יותר הטיעון הראשון שלי. זאת אומרת, זה פשוט יותר נגיש, יש יותר כלים. כמובן, זה לא . . . הטיעונים לא סותרים, אבל יש לך איזשהו Take על מה גורם לשינוי הזה?(דרור) אז אני אקח את זה רגע, באמת עם דוגמא מהצוות שלי.אנחנו . . . אני התחלתי כאדם, כעובד יחיד בצוות ה-AI, ולאט-לאט זה התרומם, ובנינו בצוות תשתית מאוד מאוד טובה, השקענו המון בתשתיתתשתית קוד, לפני עידן ה-ChatGPT וכו'ואני כל הזמן אומר למנכ״ל ול-CTO - לאיתי ולנמרוד - אני אומר להם תקשיבו . . . נגיד דיברנו קודם על המודל של ההערכת-סיכון על בסיס תמונה, אמרתי שזה שורת קוד אחתוהם אמרו לי “מה זאת אומרת שורת קוד אחת? על זה משלמים לך?!”אמרתי “כן, זה שורת קוד אחת, בנינו תשתית טובה - ואלגוריתם היום זה שורת קוד אחת”והם לא האמינו לי . . . והראיתי להם.אז כן, יש מצבים היום שזה שורת קוד אחת, ויש לך כלים כמו GitHub Copilot ויש לך Cursor, שמאפשרים לך לכתוב.ומאפשרים לך לכתוב קוד “מאפס” וזה עושה יופי של עבודה.ועדיין, לדעתי, אתה כן צריך להבין מה אתה עושה, כי אם אתה לא תבין מה אתה עושה, אז תקלה כמו שהייתה לנו, היה לוקח חודשים להבין אותה.אני באתי עם ניסיון והכרתי וחוויתי את זה גם בעבר, אז היה לנו יחסית קל לזהות את זה.ועדיין - הרבה שיעורי-מוחות וחקירות.אני חושב שעדיין, אני מאמין גדול שאתה צרךה להבין את המתמטיקה.נכון, אפשר להצליח גם בלי זה. אני רואה הרבה אנשים שמצליחים יפה מאוד בחברות אחרות, גם בלי להבין את המתמטיקה, את הארכיטקטורה.אני אולי קצת Old Fashion, אני עדיין מצפה מאנשים בצוות שלי ובטח ממני, להבין טוב את הארכיטקטורה, את המתמטיקה מאחורי הדברים, כדי לדעת להתמודד עם בדיוק המצבים שתארתי קודם. אז בעיניי זה “יהרג ובל יעבור”. אני אתן רגע דוגמה אולי עם עולם אחר - אני מלמד קורסים של Introduction to Machine Learning כבר הרבה שנים באקדמיה, בין היתר במכון הטכנולוגי בחולון ואוניברסיטת בן גוריון.ולא מזמן הרצאתי קורס בסמסטר קיץ, ולאורך הסמסטר, הסטודנטים - יש להם מטלות, והשתמשו ב-ChatGPT, אני לא יכול למנוע.אני אפילו מעודד את זה, כי אין מה לעשות, זה מאוד עוזר, גם אני משתמש על בסיס יומיומי בכלים כמו ChatGPT. אבל אמרתי להם, מתחילת הסמסטר, “חבר'ה, אתם צריכים לדעת מה אתם עושים, אתם צריכים להבין”כי בסופו של דבר יש בחינה, ובתעשייה גם תבחנו בלי . . . אתם צריכים יכולת לקודד ולהבין מה אתם עושים. באמת הייתה בחינה, ובבחינה הם צריכים פתאום בלי ChatGPT להסתדר ולכתוב קודלא מ-0, אבל לדעת לתקן קוד, להבין למה הקוד לא עובד - אז צריכים להתמודד עם זה. אז מי שלא עשה כלום כל הסמסטר, אז באמת התקשה בבחינה, וכנראה צריך לעשות מועד ב’.ומי שכן הקשיב וכן קודד בעצמו והבין - אין בעיה להשתמש בכלים - זה חובה להשתמש - אבל עדיין זה לא פותר אותך מלהבין מה אתה עושה. (רן) כן, פעם היו מפחדים מבחינות עם Closed Books, היום הם מפחדים מבחינות עם “Closed GPT” . . . (דרור) לגמרי .  . זה כמו, אגב, Waze -  אני זוכר שנסעתי בזמנו לכנס, לפני הרבה שנים - ב-2009 נדמה לי - כנס באיזושהי מדינה בקנדה, אני לא זוכר בדיוק.ונסענו, הייתי עם המשפחה, נסענו לכנס מניו יורק, משדה התעופה לקחנו רכב, נסענו צפונה, וכיוונתי את ה-Waze.בהתחלה לא בדיוק הסתכלתי, כיוונתי לאן שכיוונתי, ובסדר.התחלנו לנסוע, ואז משהו לא מסתדר לי בדרך . . . (רן) . . . גילית שאתה במקסיקו? . . . (דרור) . . .  גיליתי שכיוונתי למדינה הלא נכונה בקנדה, עם אותו שם של עיר . . . ואם לא היינו שמים לב, אז כנראה שהיינו נוסעים הרבה יותר ממה שצריך. אז Waze לא פותר אותך משנייה להבין את המפה, את הגיאוגרפיה, ולשים לב לאיך אתה מתנהלאותו דבר גם בעולם ה-Machine Learning.(רן) . . . וגם שאנחנו פה בצפון, ולא כל יום יש GPS . . .(דרור) אתה צריך לדעת להסתדר . . .(אורי) גם הקטע של דברים שלא קורים “כמו שצריך”, וצריך לדעת גם לזהות את זה, אבל גם לתקן את זה. ופה בא המון ניסיון והבנה של ה... (דרור) לגמרי. אני חייב לקחת את זה רגע - דיברת על GPS, ולא מזמן, אני לא זוכר בדיוק את ה-Timeline, אני עושה משמרות באופן קבוע כפאראמדיק במד”א ויום שישי אחד היה את הבאג הזה, היה איזה באג עם Microsoft, עם איזשהו GPS, נכון? כל ה-GPS-ים של מד”א הפסיקו לעבוד . . .הוציאו אותנו לקריאה לאיזושהי החייאה בבית אבות, אני לא זוכר בדיוק איפה.מערכות לא עובדות, אין לך Waze, אתה לא . . .עכשיו בגלל כל הבלגן, אז גם המוקד קשה, עמוסויוצאים להחייאה, והבנאדם . . . . בקיצור, למזלנו, מד”א מספר ימים לפני זה, תרגל את זה על יבש - בדיוק את המצב הזה, אז כולם ישר פתחו פקל”אות, ידעו בדיוק איך להסתדר.עדיין הם צריכים להסתדר בלי Waze - זה לא טריוויאלי, אתה מגיע למקום, איפה זה, לא פשוט . . . גם טלפונים וחלק מהמכשירי הקשר לא עבדו . . . בקיצור, היה חתיכת בלגן, אבל באמת בגלל שמד”א נערך מראש . . .וזו בדיוק דוגמא טובה - כשאתה נערך מראש, אתה יודע להסתדר גם בלי ה-GPS.אז ברור שזה קצת פחות טוב . . . (אורי) . . . וגם בלי Microsoft . . .(דרור) . . . גם בלי Microsoft . . . אז עדיין אפשר לחיות ולהחיות, גם.באותו מקרה זה לא הצליח, אבל זה בלי קשר.(רן) נאחל להצלחות בפעם הבאה . . . .43:24 סיכום וגיוסים(רן) טוב, תודה רבה,  דרור מחברת Honeycomb. וכן,  אמרת שאתם מחפשים - אז ספר לנו על החברה: איפה נמצאים? כמה עובדים? מה עוד מחפשים?(דרור) אז החברה - קודם כל, By Far החברה הכי טובה שעבדתי בה, ולעוד שנים רבות, אני באמת אוהב את החברה.החברה היום כוללת . . .  רק אתמול הצטרפו שבעה עובדים, אז היום לדעתי זה כבר מתקרב ל-130 עובדים בכל העולם.פולין, ישראל וארצות הברית.אנחנו כרגע בהרצליה-פיתוח, אבל בראשון לדצמבר עוברים למשרדים משלנו, ב-Midtown.ומגייסים עובדים כל הזמן - אנחנו מגייסים, מפתחיםאגב, גם בארץ וגם בארצות הבריתאם נהיה טיפה יותר ספציפיים, לצוות שליקודם כל, כל הזמן מחפשים אנשים טובים בחברהאבל לצוות שלי, אנחנו מחפשים אלגוריתמאים בשלושת התחומים - גם בעולם ה-Computer Vision, גם בעולם ה-Tabular Data, דאטה-טבלאי, וגם בעולם ה-NLP.אנשים טובים - רצוי עם תארים מתקדמים: תאור שני, תזה בתחום.תגישו מועמדות - יש לנו לא מעט משרות עכשיו, אנשים שבאים באמת לעבוד בסביבה דינמית, עם אימפקט.אני - הדבר שהכי חשוב לי בחברה זה אימפקט - אגב, מתחבר למה שאני עושה במד”א. אימפקט בעיניי זה הדבר הכי חשוב, ו-Honeycomb מאפשרת את זה.היכולת לעשות שינויים - גם לטעות, לא קורה כלום, לטעות, ללמוד - זה הדבר שאני אוהב ב-Honeycombאז אני מזמין כל מי שבתחום לבוא ולהגיש מועמדות - אחלה מקום, בואו!(רן) טוב, אז תודה רבה דרור, בהצלחה ל-Honeycomb - ובהצלחה במד”א.תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 480 של רברס עם פלטפורמה, שהוקלט ב-30 באוקטובר 2024. אורי ורן מארחים בפרדס חנה - כרכור את רועי - מנהל ומפתח בחברת Hello Heart לשיחה בדיוק על המעברים האלה, שבין ניהול לפיתוח לניהול.01:05 על רועי ו-Hello Heart(רן) ספר לנו קצת עליך וקצת על החברה, שנכיר?(רועי) בשמחה - אז אני רועי, אני בן 40 גר בתל אביב, מפתח מכיתה ד' . . . .(אורי) כבר אז היה לך קול רדיופוני? או שהסיגריות התחילו אחר כך . . . .(רן) לא אמרנו מפתח-קול . . .(רועי) גם לא אמרנו סיגריות . . . אני לא מאשר ולא מכחיש, לפחות לא כשמקליטים, יום אחד הילדים יקשיבו לזה . . .אז לא - הקול לא היה רדיופוני אז, הקול של אבא שלי כן . . . . הוא עבד כמפתח, עשה תאונה בצבא - ומצאנו  את עצמנו עם מסוף של IBM בסלון.וככה בעצם אני פגשתי את עולם הפיתוח - והוא מלווה אותי מאז.ניסיתי לברוח ממנו - הלכתי ללמוד משפטים, מצאתי את עצמי סמסטר וחצי לתוך העניין, מנסה לחזות החלטות  של שופטים עם Machine Learning - וזו בעצם היתה ההבנה שלי או הפעם הראשונה שהבנתי שלהיות מפתח זה חלק משמעותי באופי שלי, בדברים שאני עושה ובהגדרה העצמית.(רן) אוקיי, ומתי פגשת את הלב שלך ואמרת לו שלום? [הפסקה מתודית מתבקשת](רועי) את הלב שלי פגשתי בשלב מאוד מוקדם בחיים שלי - את Hello Heart פגשתי לפני שנתיים . . . חברה שאני מאוד מאוד אוהב ומאוד מאוד גאה לעבוד בה - שבעצם נותנת פתרון שעוזר למשתמשים שלנו לנטר, לשמור ולשפר את בריאות הלב שלהם.עובדים בעיקר בשוק האמריקאי . . .(רן) אז זאת אומרת שלקוח הקצה הוא אותו פציינט (Patient) פוטנציאלי, אותו משתמש - או שזה רופאים ומוסדות וכאלה?(אורי)  . . . . חברות ביטוח-רפואי וכאלה . . .(רועי) אז לקוח הקצה שלנו הוא המעסיקהמשתמשים שלנו הם עובדים אצל המעסיקים - שמקבלים את האפליקציה בחינם.אנחנו יודעים לשפר את בריאות הלב ובעצם להוריד לחץ דם סיסטולי ולעזור להם לחיות יותר נכון - וזה מתורגם להחזרים ביטוחיים הרבה יותר נמוכים.בארצות הברית - מעל כמות מסוימת של עובדים, המעסיקים הם Self-Insurers, ולכן בעצם אנחנו מאפשרים להם לשלם לנו כסף.העובדים שלהם מקבלים את האפליקציה בחינם וחיים חיים בריאים יותר - והלקוח שלנו חוסך כסףאז זה מעיין “משולש-זהב" נחמד.(רן) יש בזה גם אמצעים רפואיים - כאילו, חומרה-רפואית או כאלה - או שזה הכל כזה “רק” אפליקציה-נטו ו...(אורי) שעון?(רועי) אז אין שעון - וליוזרים (Users) שלנו אין את הסביבה שתומכת בשעונים חכמים.אלו בדרך כלל עובדי צווארון-כחול, שהתלהבו מהחומרה שכן יש לנו - שהיא מוניטור לחץ דם, שיודע להתחבר Bluetooth לפלאפון.מבחינתם, ה-Connectivity הזה היא “נס” - זה משהו ששמענו באיזשהו ראיון עם אחת היוזרים.אנחנו גם מפתחים עכשיו חומרה בעצמנו - זה משהו שקורה פעם ראשונה והוא מאוד מאתגר מהאספקט של ניהול טכנולוגיה, אבל עיקר הפוקוס הוא על האפליקציה.ומשהו שקצת Unique-י בעולם הרפואי זה שהפוקוס הוא על User Experience - כי בבריאות הלב, רפואה מניעתית היא מאוד מאוד חשובה.אנחנו יודעים מה צריך לעשות כדי לשפר מאוד את הסיכויים שלנו - ופה זה פוגש את האלמנט האנושי, שלא רוצה לעשות את זה . . . . לא רוצה לרוץ, לא רוצה לאכול נכון, לא רוצה למדוד לחץ דם כל יום . . . .[“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”]ובעצם יש לנו בעיית Engagement - שמתורגמת בעצם לרווח בריאותי, זה מאוד נחמד.04:53 לב העניין - מנהל-מפתח-מנהל-מפתח-…(רן) מעניין, אז הסתקרנתי על Hello Heart - אבל זה לא בעצם הלב של השיחה, אפשר גם להגיד אולי כמה מילים על החברה בסוף, אני בטוח שאתם מחפשים אנשים טובים . . . אבל יצא לך - ואני מניח שלא רק לך בתעשייה - אבל יצא לך לעשות מספר מעברים בין להיות מפתח למנהל או IC [Individual Contributor] ושוב מנהל - וכל אחד מהמעברים האלה לימד אותך קצת - גם לעשות את התפקיד הנוכחי יותר טוב, גם אולי לנהל יותר טוב או גם לעבוד עם מנהלים בצורה יותר נכונה - וחשבנו שיהיה מעניין לדבר על זה ולשמוע את התובנות שלך, כי שוב, כאמור, זה כנראה קרה לפחות ל-50% מהעובדים בתעשייה, אז שווה גם לחשוב ולאפטם (Optimize) את הדבר הזה.אז תן לנו ככה קצת רקע לסיפור - איך זה היה מבחינת ה-Timeline פחות או יותר? אילו תפקידים עשית ואיזה מעברים קרו לך.(רועי) אז באמת, אני התחלתי את קריירת הפיתוח שלי באמצע הלימודים - עבדתי בחברת פרויקטים כג'וניור שלא מודע לג'וניורותו . . . .משם, בעצם דרכם, הקמתי את החברה הראשונה והיחידה שהקמתי - הם היו כמו חממה שלנו, ועם Title שהיום אני קצת מתפדח להגיד של “מנכ”ל”, בעצם התחלתי את כל הסיפור.אחרי בערך שנה, כשהבנתי שאני לא מתאים לתפקיד, השארתי את החברה בידיים של השותף שלי, שהמשיך איתה כמה שנים, ועברתי להיות מפתח מתחיל ב-Trusteer.בתוך Trusteer, שהפכה ל-IBM באיזשהו שלב, בעצם התקדמתי לכיוון ניהולי יחסית מהר - בערך שנה, שנה וחצי אחרי שהתחלתי שם כבר הובלתי צוות.משם עליתי ל”ראש צוות בכיר”, מה שזה לא יהיה, ואז לראש-קבוצהואחרי חמש שנים ב-IBM עברתי בעצם לתפקיד VP הראשון בחברה שנקראת CYE.ושם, בערך אחרי שנתיים, הגעתי לאיזושהי נקודה שבה הייתי צריך לחשוב מה אני עושה  . . .(אורי) כי מיצית?(רועי) וואו, זאת שאלה קשה . . . אני חושב שזה היה שילוב של הרבה גורמים.אני חושב שקודם כל, מי שבאמת באמת אוהב את התחום ומגיע מעולם של אהבת תוכנה, שזה משהו שהוא מאוד נפוץ, לשמחתי, אבל כן הולך לכיוון של הניהול - יש תמיד דיסוננס שמלווה אותך, בין הקריירה שאתה רוצה למה שאתה רוצה לעשות כשאתה רואה מחשב.כי כשאני רואה מחשב, אני רוצה להסביר לו מה לעשות - אני רוצה לכתוב שורות קוד.אין עונג בעולם הזה שמשתווה לקוד שכתבת ורץ סוף סוף.(אורי) כמו בכל יצירה, נכון? אתה יוצר מחומר משהו, אתה יוצר משורות קוד משהו, זה דומה.(רועי) זה זהה . . . אני חושב ש . . .(אורי) פשוט הכלי הוא אחר, אבל זו יצירה.(רועי) הכלי הוא אחר אבל זה מעניין . . .  זה קצת Detour מהשיחה, אבל זה מאוד מעניין להסתכל על Code Review למשל, ולראות איך אנחנו כמפתחים משתמשים בשפה שהיא מאוד אסתטית“זה קוד יפה”, “זה קוד מכוער” - זה משהו שאני חושב מראה שבסוף מדובר בתהליך של יצירה, שיש בתוכו את האיכויות האלה.כולנו יודעים שאפשר לראות קוד והוא יהיה יפה או ממש ממש לא - וזה כמעט אורטוגונלי (Orthogonal) לשאלה “האם הוא עובד”, לפעמים אפילו סותר . . . .(רן) למרות שאת יורדי-הים לימדו שקשר טוב זה קשר חזק, נכון? יש כזה משהו . . .  סליחה, קשר יפההוא קשר חזק.(אורי) אבל גם, כאילו - הקשרים הטובים, הם קשרים שאפשר להתיר אותם . . .  זה כמו שאתה מכין את הקוד שלך ל-Refactoring, כי אתה יודע שזה יבוא מתישהו, הדבר הזה, או שמישהו אחר יצטרך לפתוח את הקשר. זה כמו . . . .(רן) אבל אם אתה רואה סירה קשורה עם קשר מכוער כזה, אז אתה קצת מפחד, נכון? . . .  “אוקיי, יש פה בעיה”.(רועי) אבל לפעמים אתה יכול לראות קשר יפה שהוא לא חזק, וגם קוד - יכולות להיות חתיכות קוד מדהימות . . . (אורי) . . . אבל לא רובסטיות (Robust)(רועי) לא רובסטיות, לפעמים פשוט לא נכונות . . . . היופי שם הוא משהו שקיים, לכשלעצמו.(רן) זאת אומרת, תמיד יש לך איזשהו מתח בין האהבה שלך לקידוד, האהבה שלך ליצירה של קוד, לבין, אולי, הקריירהשהיית רוצה שתהיה לך, שזו קריירה של “מנהל בכיר”, כמו שהגעת אליה.(רועי) “כמו שאמא רצתה” . . . . אז הרקע הזה היה שם - אבל הוא לא היה מספיק.כי בסוף, קשה מאוד לקבל החלטה כזאת - הייתה שם הצטברות של נסיבות.בדיעבד, אני יודע להגיד שזה היה שילוב גם של ילדים בגילאים שהם דורשים הרבה תשומת לב וגמישות שאין לך כמנהל שצריך להיות זמין.וגם בדיעבד, Culture-fit פחות טוב עם המקום שעבדתי בו.ואני חושב שזה הוביל אותי לנקודה שבה אני אמרתי אוקיי, אני צריך משהו אחר - ו”המשהו האחר” הזה צריך להיות פיתוח.(אורי) זה מעניין, הנושא של ה-Cultural Fit . . . כאילו, זה לא גרם לך להרגיש גם בתור מפתח שאתה לא במקום עם עם -Cultural Fit נכון, ואולי פשוט עדיף לא להיות במקום?(רועי) היה לי מזל לעבור להיות מפתח במקום שאני חושב - אני מקווה, צריך לשאול אותם - שהייתי Cultural Fit מאוד מתאים . . .(רן) כלומר, בחברה אחרת . . . (אורי) בחברה האחרת, כן.(רן) אני חושב שמה שאורי שאל, ואולי אין לך את התשובה לזה, אבל האם באותה חברה, שבה הרגשת אי-התאמה בתור מנהל, האם הרגשת אחר כך כן התאמה בתור מפתח, אבל כמו שאמרנו - זה לא היה A/B Testing לזה  . . .(רועי) לעולם לא נדע, אבל אני חושב שהתשובה הייתה “לא” . . .(אורי) כי עברת מקום . . .(רועי) גם כי עברתי מקום, אבל גם כי בדיעבד, אני לא חושב שזה יעבוד שם ואני לא יודע אם זה בגלל שלא היה Cultural Fit, גם כמפתח, או בגלל שאני כרועי - עם האגו שלי והדברים שאני סוחב, לא הייתי מצליח להכיל את זה.כי כמו שלמדתי שהגעתי ל-Salto, החברה שבה כן עבדתי כ-IC [Individual Contributor] - “האפסון” הזה של האגו בצד וההפיכה שלך לסוג-של-ספוג הייתה מאוד קריטיתגם להצלחה וגם להנאה שלי בתפקיד.(אורי) ההפיכה שלך לסוג של ספוג בקטע טוב, זאת אומרת . . . (רן) “טאבולה ראסה”, מוכן לספוג דברים . . .(אורי) לבוא וללמוד . . .(רועי) לבוא ולהגיד - הניסיון שלי הוא בניהול, אבל אני מפתח.ואני מוקף באנשים שיודעים לעשות את זה יותר טוב, שעשו את זה יותר שנים, במנהלים שגם עשו את זה הרבה שנים.להבין שזה המקום שלי במערכת - ושבו אני צריך להצליח.(אורי) ותוך כמה זמן מצאת את עצמך שוב בניהול?(רועי) שנתיים וחצי . . . קצת נשלפתי . . . (אורי) האמת שזה הרבה . . . .(רועי) זה הרבה. היו שנתיים וחצי מדהימות - והרגשתי רוויה כבר בשלב הזה.זאת אומרת, כמו ש”דגדג לי לחזור לפתח”, זה כבר היה שלב, אני חושב בגלל הדרך ש-Salto עשתה.היא מאוד גדלה והתפקיד שלי כמפתח טיפה השתנה.אבל כבר הרגשתי דגדוגים של אולי לחפש לחזור לזה. ואז היה לי מזל שמיכל, ה-CTO של Hello Heart, שעבדה איתי בעבר, פנתה אליי ובעצם הציעה לי לבוא ולדבר ולראות ולהתראיין אם אני אוכל לעשות את התפקיד הנוכחי.לשמחתי זה הבשיל.12:30 התמודדויות, פינות ולמידה מחדש(רן) אז בוא רגע נדבר על הנקודה שבה סיימת להיות מנהל, עברת ל-Salto ונהיית מפתח, נגיד ג'וניור. זאת אומרת,כנראה שמבחינת קריירה במקום קצת יותר אחורי ממה שהיית לפני זה - ואתה לא חייב להסכים, אני מציע.זו חוויה של . . .  פתאום אתה צריך ללמוד, אוקיי? אתה לא מוביל, אתה צריך ללמוד. יש בזה אולי את החווייה של הלימודים, אבל אולי גם הזכרת מקודם אגו, אז מעניין איך התמודדת עם זה.וגם אני מתאר לעצמי שראית מנהלים, אולי מעליך ואולי ליד, שכאילו דגדג לך לבוא . . . כמו שאתה עושה Code Review למישהו, זאת אומרת, דגדג לך לבוא ולתקן את הקוד שלו, אז דגדג לך לבוא ולתקן את הניהול שלהם, אבל פתאום אתה בפוזיציה אחרת . . . אז איך התמודדת עם כל זה?(רועי) בצורות שונות, אבל בעיקר בלא להיכנס למקומות האלה . . .קודם כל, צריך לבוא ולהגיד שהיה לי מזל - כי הייתה שם סיטואציה שמאוד עזרה לי לעשות את המעבר.קודם כל, הייתי המפתח הראשון שחתם.המפתח השלישי שהגיע, בגלל עניינים של Notice Period.יש, עדיין, ב-Salto מנהלים מעולים - אז כמות המקרים שבהם הייתי צריך או הייתי יכול לטעות לחשוב שאני צריך לתקן אותם הייתה יחסית קטנה.(אורי) ואולי גם נהנת ללמוד מהם . . .(רועי) וגם נהנתי ללמוד מהם - וגם מהמפתחים האחרים שגויסו, שהיו יוצאים מגדר הרגיל.(אורי) אבל זה בחמישייה הראשונה של הארגון פיתוח - אין הרבה מעמדות, אין הרבה . . .(רועי) נכון - וזה עזר, כי הסיפור שסיפרתי לעצמי הוא סיפור של “אוקיי, אבל עדיין יש Impact”.ובאמת היה המון Impact,  כי מפתח - בטח מפתח, אני אגיד את זה בזהירות, “כמוני” [הקומיטים שלי טובים] - שיודע לדלבר (Deliver) מהר, יכול לעשות המון Impact בארגון קטן.(רן) זאת אומרת, זה לא רק להיות מפתח - זה גם להיות Founding Member בחברה . . . (אורי) גם מי שמנהל הוא IC, רוב הזמן . . . .(רועי) כן ולא . . . - זה נכון שהמנכ״ל כתב את האתר המרקטיאלי (Marketing) הראשון וכמובן שהסתיר בתוכו משחק של Pong . . . . (רן) גיל היה המנכ״ל?(רועי) המנכ״ל היה רמי. גיל דווקא לימד אותי את החשיבות של להיות מוכוון יותר לבניית הצוות.וגם צריך לבוא ולהגיד - שוב בדיעבד, לא הייתי מאוד מנוסה כמנהל כמו שחשבתי.ולראות אנשים עם גישה שונה ועם ותק שונה נתן לי פרספקטיבה גם בכיוון הזה.אבל יש איזה רגע אחד, שאני זוכר שאולי “קימט בתוכו”, הוא היה בדיעבד רגע מכריע, שהיה יכול ללכת לשני כיוונים מאוד מאוד שונים - שזה היה ה-Code Review הראשון שלי.ושוב, דיברנו על זה טיפה קודם - Code Review הוא משהו מאוד רגשי.זאת אומרת, מעבר לעובדה שהוא מאוד “אסתטי” באופי שלו, גם כל הקרביים שלנו נשפכים לתוך הקוד.“הקוד שלך זה אתה”.ואני זוכר שהגעתי ל-Code Review הראשון שלי, תיקתקתי עבודה, זה בעצם היה Commit שסגר מעגל פעם ראשונה והפך את המוצר למשהו שעובד.שש-שבע שנים לפני זה, אני הייתי זה שעושה את ה-Code Review אז אני הייתי זה שמכתיב את ה-Guidelines.והגשתי את מה שלעניות-דעתי היה ה-PR המושלם - בגדול, ציפיתי למחיאות כפיים. little did I know שלא תמיד זה נראה ככה.עד היום, מפתחים שמקבלים ממני . . .  אני כבר לא עושה כל כך הרבה Code Reviews, אבל כשאני עושה  אני מראה להם את ה-PR הספציפי הזה.כי אותו קוד הוא Open Source, אז זה עדיין שם ב-GitHub.אני חושב שהיו שם מעל למאה הערות . . . החל מ-Nitpicking, סטיילים שונים של קוד שאני בכלל לא הכרתי, דרישות לטסטים, באגים שפספסתי . . . באמת, כמות מאוד מאוד גדולה של הערות.ואני הרגשתי את החום הזה שעולה בגב אחרי שמבקיעים גול עצמי בטעות בשכונה . . . “מי אני? למה אני פה? מה אני עושה עכשיו?”ובנקודה הזאת החלטתי שאני סופג - שבמקום לבוא ולהתחיל להתווכח על כל הערה, אני - לפחות בתקופה הראשונה - פשוט מבצע את התיקונים.ואני חושב שזה עזר מאוד.זאת אומרת, מאותה נקודה בעצם ראיתי מה אני יכול ללמוד.ועם הזמן גם עוד פעם בניתי את הביטחון לבוא ולהגיד “רגע, זה משהו שאני יודע שהוא לא נכון”.ועברתי בעצם תהליך “סיניוריזציה” (Seniority) מאוד מאוד מזורזכי את הרקע, את המערכתיות, את ה-Design-ים - זה כבר היה לי.(רן) אז בעצם אם אני אנסה לומר אחרת את מה שאמרת - למדת איך להיות מפתח שוב. אולי לא ברמה הטכנית של קידוד בהכרח, אלא באיך להיות חבר-צוות, איך לשתף פעולה, איך לקבל פידבק, נניח גם איך לתת את הפידבק, איך ללבן סוגיות . . . אבל מה שאותי גם מעניין לשאול איך המעבר הזה ללהיות מפתח - מה הוא לימד אותך על ניהול? כלומר, לא היית מנהל באותו זמן, אבל ראית מנהלים. היית עכשיו בדיוק בפוזיציה השנייה - האם זה לימד אותך, בדיעבד, האם זה לימד אותך ניהול בצורה שאולי לא היית יכול ללמוד כמנהל?(רועי) אני חושב שכן.שוב, בעיקר - וזה משהו שאני אגיד בזהירות, מאפיין יחסית את מסלול הקריירה הישראלי, שבו הרבה אנשים עוברים לניהול בשלב יחסית מוקדם.כי היו לי המון לאקונות על חוויות של מפתחים . . . אני כן אגיד שגם אמרת קודם שלא למדתי להיות מפתח ברמה הטכנית - אני לא אסכים איתך.כשאתה מנהל שבע שנים, העולם מתקדם - סטנדרטים משתנים, תשתיות משתנות, קונספטים נכנסים . . . נגיד, אני התחלתי לנהל בתקופה ש-Manual QA היה Must - וחזרתי לפתח בתקופה ש-No QA היה בשיא ה-Hypeאת זה, אגב, לא לקחתי בשום צורה - אני אוהד מאוד גדול של QA ידני . . . וגם יש גישות שונות לפיתוח - למשל טסטים: אני למדתי לפתח בחברה שבה לא עשו טסטים.אנחנו יכולנו לעשות Deploy ל-Production מהר, Production עוד לא היה עם Container-ים אז היה VM ב-Production, שזה טוב כמו טסטים . . . ובאמת הגעתי לחברה, שבה אחד מהמפתחים הבכירים האחרים, פשוט יצר לנו את הסביבת פיתוח, שם Threshold של 99.7% Test Coverage - ופרש לחדרו . . . (רן) “ישחקו הנערים לפני” . . .(רועי) ממש . . .  וזה משהו שלקחתי איתי, כי הבנתי פתאום את ה-Benefit שלו “מהידיים”.כי פתאום הרגשתי את התחושה הזאת של לעשות שינוי כשאתה יודע שיש לך Test Coverage, ואיך זה משפיע על Velocity.דברים שכשאתה לא חווה אותם - קל לפספס.(אורי) אני חושב שיש משהו . .  אני גם עברתי את החוויה הזאת של להיות מפתח, די מהר להתקדם לניהול, לעבור חברה ועוד פעם להיות מפתח, וגם כן - אני קורא לזה כאילו “החרא צף” . . . כאילו תמיד עולה למעלה - ועוד פעם לעבור לניהול. וכל הזמן הרגשתי שזה משפר לי, בסוף, את הניהול - לא רק בשיטות או בזה, אלא גם בגישות.בדיוק היום נפגשתי עם מישהי שמנהלת בתחום החינוך, ודיברנו על המקצוע הזה שנקרא “ניהול”, ואמרתי לה “אין,זה לא איזה  . . . .”. אין מנהל טוב, כי לכל אחד יש את הגישה הניהולית שלו, ושתיהן טובות, או כל הגישות טובות - והן מאוד תלויות באופי שלך ובחוזקות שלך.אבל פתאום, ככל שאתה נתקל ביותר מנהלים, אתה סופג יותר סגנונות שונים.(רועי) נכון - וגם לפעמים זה שאתה נתקל במנהלים אחרים עוזר לך למצוא את הסגנון שלך.יש דברים שאימצתי לחלוטין, ויש דברים שראיתי ואמרתי ““זה יכול להיות טוב, אבל זה לא אני”.וזה עוזר לדייק אותך ולציוק קצת אותנטיות באיך שאתה מתנהל, ואני חושב שזו איזושהי נקודת מפתח בניהול, אני מקווה מוצלח.זה גם נותן לך לראות דברים שאתה לא רואה ממקום אחר.פרויקטים ארוכים זה דוגמה מאוד טובה - כי זה הרבה פעמים יש Friction בין הנהלה לבין המפתחים, שלקחו את הפרויקט הזה.וזה נגיד משהו שהשתנה אצלי מהותית. בתור מישהו שהוא מאוד Velocity ו-Delivery-Oriented באופי שלו, אין לי סבלנות.והיה פרויקט ספציפי, “פרויקט הדגל” שלי בעצם, שעבדתי עליו כמפתח - שהוא פרויקט שמנקודת המבט של מנהלים היה יכול לראות כישלון מוחלט - ובצדק.ומצד שני, כמפתח הוא אחד הפרויקטים שאני הכי גאה בו בחיים.טכנית, היה איזשהו משהו שיצר Limit-ביצועים די רציני במערכת, ברמת ה”אי אפשר להשתמש בה על מידע אמיתי” . . . בפועל, היינו צריכים לעשות איזשהו שינוי שהחליף לנו פונקציה מאוד בסיסת ל-Promise, וזה תורגם בעצם למשהו שהערכנו בחודש עבודה.עשינו אותו בחודש עבודה - ואז ראינו שהוא שבר את כל הטסטים בצורה שמאוד קשה להתמודד איתה  . . .והיה שם אתגר טכני מאוד קשה והתמודדנו איתו יפה - זאת אומרת, ה-Velocity של הפיתוח ופתרון הבעיות בפרויקט הזה היו בשמיים - אבל פספסנו את ה-Estimations בחודשיים.(רן) ומבחינת ההנהלה - לא עשיתם כלום . . . . כי לפני זה היה מוצר, אחרי זה היה מוצר - מה ההבדל? הם לא היו מודעים למגבלת Performance הזו, מגבלת-הביצועים הזו שהזכרת . . . (רועי) הם היו מודעים למגבלת ביצועים - בגלל זה בכלל נתנו לנו לצאת לזה.הם לא ראו את כל ההתקדמות שנעשתה בעצם “על ריק” - את כל “הריקושטים”.זה קורה תמיד ב-Refactor, זה תמיד קורה בשינוי תשתיתי - אתה משיג את המטרה, והכל נשבר . . . וכמנהל, זה פוגש אותי הרבה פעמים - רק היום יש לנו שניים או אולי שלושה פרויקטים שנמצאים במצב דומה, שהיום קל לי לראות שהם פרויקטים שמבחינת Velocity, מבחינת קצב עבודה, מתקדמים טוב מאוד - אבל הם מפספסים את ה-Deadline, וזה גורם לי להתנהל בצורה שונה.האם זה נותן לי כלים לגרום להם להיות מהירים יותר? לא . . . אני מקווה שזה עוזר לי לתקשר אותם בצורה יותר טובה קצת למעלה ולייצר את הסביבה שמאפשרת לזה לקרות.23:59 ההנהלה “מדברת MBA-ית” ואתה מדבר “Engineer-ית"(רן) דרך אגב, בדיעבד כמפתח אז ובהיותך מנהל לפני זה - אתה חושב שהיית יכול לנהל את המנהלים שלך יותר טוב? זאת אומרת, לנהל את הציפיות, לתקשר, או דרך אחרת לבוא ואתה יודע, להראות “הנה, תראו כמה אני מזיע פה - אתם תראו שזה הולך להשתלם לנו”?(רועי) אני חושב שהייתי מנהל את זה באותה צורה, כי יש פה קצת מהלך של “קורבן עצמי”.יש פרויקטים שאם אתה לא תעשה להם Under-estimation אז לא יקרו, והם צריכים לקרות.אולי . . . (רן) ודי לחכימא ברמיזה . . . (אורי) לא, אבל יש פה גם . . . אתה צודק במה שאתה אומר, יש פה הרבה דברים שזה שייך לבדידות של מנהל פיתוח, שבעצם כל שאר ההנהלה “מדברת MBA-ית” ואתה מדבר “Engineer-ית”, הארגון שלך מדבר “Engineer-ית”, והארגון, התרבות, השפה, הכל - ה-Incentives. וכמו שאמרת “מה שלי נראה פרויקט מאוד מוצלח, מבחינת ההנהלה הוא כישלון גמור” - זה חלק מהמקום הזה, הבדידות הזאת.(רועי) אני חושב שזה משהו שאפשר להרגיש גם כמפתח - שאתה חוזר הביתה ומנסה לדבר על העבודה שלך.כי יש משהו ב. . . אם אתה עורך-דין או איש מכירות, השפה שבה אתה משתמש לתאר את העבודה לך היא שפה שכולם מבינים, אתה יכול לספר סיפור.כמפתח זה לא נכון - מי שלא מפתח לא יבין למה זה שעשית עכשיו Refactor של אלפיים קבצים ב-sed זה משהו שהוא, אתה יודע, “מרגש” . . . וזה אותו דבר.פה אני חייב להגיד שאני לא מרגיש היכולות שלי לתקשר את זה מסביב השתפרו. . . .אבל אני כן פיתחתי את היכולת להגן על מאמצים כאלה.זאת אומרת, בסוף כמנהל שצריך לגשר בין ה-Business ל-Engineers, אתה לבחור איפה אתה נותן את הגב.26:22 לבחור איפה לתת את הגב(רן) זהו, בדיוק אז לנקודה הזו רציתי להגיע - אז היית מפתח עכשיו כשנתיים פלוס, ושוב ניתנה לך הזדמנות להיות מנהל ולקחת את זה, ועכשיו השאלה היא איך החוויה הזו של להיות מפתח שנתיים פלוס עשתה אותך מנהל יותר טוב? אז הזכרת נקודה אחת, אבל בוא נחשוב, בוא תוליך אותנו קצת מתודית דרך הדברים.(רועי) רק נדייק - מנהל שחושב שהוא יותר טוב, who am I to say . . . .(רן) פה אפשר לחלק קרדיטים חינם [מאות עובדי AWS מרגישים הפרעה בכוח . . . ].(רועי) הכי טוב . . . .(רן) אם אהבתם - תעשו לנו חמישה כוכבים ב-Apple ו-Spotify [גם אם לא] . . . . כן, אז באמת איך החוויה הזו, של לחזור להיות מפתח ושוב מנהל אחר כך, עשתה אותך מנהל - לכאורה - יותר טוב? אוקיי, נהיה זהירים . . . .(רועי) חשוב להיות זהירים בתקופה הזאת . . . .אני רוצה לקוות שבהרבה אופנים, אני חושב שזה עזר לי, אני חושב, להבין מה באמת קורה “בשטח” - משהו שאתה מתנתק ממנו עם הזמן.אני חושב שזה נתן לי הבנה אנקדוטלית על המון המון המון נושאים, שבסוף מצטברים לאיזושהי גישה שונה לניהולבעיקר סביב התנהלות מול מפתחים מאוד מאוד בכירים, מול Staff Engineers.ההבנה, למשל, שיש סוגים שונים של Staff Engineers, שכל אחד מהם תורם משהו אחר - וברגע שיש לך מישהוא טוב במשהו מסוים, Let him(or her) at it . . .ה-Staff שמחזיק ב-PR-ים את כל החברה, והוא לא יכול לעשות שום דבר אחר - הוא יכשל בכל משימת פיתוח שתיתן לו, כי הוא עסוק בלתת Value משוגע בלעשות PR-ים.ה-Staff Engineer כמוני, שפשוט יודע לקחת כל פרויקט ולתקתק אותו מההתחלה עד הסוף, להחזיק אצלו את הבעיות.ה-Staff שתמיד עושה תשתית, שנראית גנרית מדי שנה וחצי - עד שפתאום אתה מגלה שבדיעבד היא חסכה לך חודשי עבודה.אני חושב שזה עזר לי לשחרר, לתת לאנשים שאני יודע שהם טובים להתמודד עם בעיהולתת להם את השקט לעשות את זה, לא לשאול אותם . . . (רן) דרך אגב, הנושא הקודם  - אורי, תקן אותי אם אני טועה, זה נקרא “ניהול מתוך חוזקות” או . . . נכון? זה אחד הנושאים החביבים עליך, זאת אומרת, למצוא במה כל אחד חזק, לתת לו ולא לנסות לחזק אותו אולי בתחומים שבהםהוא פחות חזק. זה פשוט לתת לו להתפקס (Focus) במה שהוא חזק.[הפרק המעולה הזה - 443 Hiring for strength, not skill with Sahaf from Hippo והספר המעולה הזה - First, Break All the Rules ](רועי) כן, זה איזשהו Value א-סימטרי - שיש אנשים שיכולים לתת.אני חושב שבעיקר זה אולי פחות קשור לעבודה כמפתח, אלא יותר לשינוי התפקידי וההחלטה ללמודזה מאוד שיפר אותי כמישהו שמנסה - מנסה - לתת לאנשים אחרים אולי להביע דעה ולהקשיב להם.ואני מקווה שהשתפרתי בזה, כי זה לפחות משהו שחשוב לי.29:30 יש מנהלים זיג-זג גם על אוניות(רן) עכשיו, יש דרך שלישית - זאת אומרת, פה תיארנו קריירה כסוג של “זיג-זג”: מנהל, מפתח, מנהל - אבל הדרךהאחרת לעשות לזה זה אולי להיות מפתח, מנהל שהוא Hands-On, כלומר ששומר לעצמו X זמן, X אחוז, כדי להיות Hands-On, או בוחר לעצמו באגים לתקן, או בוחר לעצמו פיצ'רים לעשות. וזה גם משהו שלא מעט אנשים עושים - או לפחות מנסים לעשות - ולפעמים זה מצליח יותר ולפעמים פחות.וזהו, רציתי אולי לעשות איזשהו Brainstorming ככה, שלושתינו, של Pros and Cons, להשוות את שתי הגישותולעשות, לחשוב למי יותר מתאים מה, איפה או לאיזה גישה יש יתרונות, באילו סיטואציות - זאת אומרת, “הזיג-זג”לעומת, נקרא זה “Hybrid” - מנהל שמנסה להישאר Hands-On באיזשהו אחוז מזמנו.(אורי) אני לא חושב שיש דבר כזה . . . . למה? כי זה לא משנה. ממש לא אכפת לי מה אתה עושה - תתקן באגים, תעשה PR-ים, לא יודע, תעשה מה שאתה רוצה - השאלה היא, בהגדרת התפקיד שלך - מה האחריות שלך? האם האחריות שלך היא על הקוד של עצמך או שהאחריות שלך היא על ההצלחה של הצוות, הבנייה של הצוות. האם האחריות שלך מסתיימת בך, או שהיא מסתיימת באנשים אחרים, שצריכים לעשות בסוף משהו.ועשית את הסוויץ' הזה . . . כאילו, אם אתה מתקן באגים או לא מתקן באגים - זה לא משנה, מה אכפת לי?(רן) אבל אורי, אתה מסתכל על זה מכיוון ה-KPI - אתה אומר . . . . (אורי) לא, בסדר - אני מסתכל על זה מהגדרת התפקיד . . .(רן) כן, אתה מסתכל על זה מהצד של הניהול הארגוני - של איך הכי נכון לנהל את התפקיד, איך אנשים יהיו הכי פרוטוקטיביים. אני דווקא רוצה לסתכל על זה מהכיוון של רועי. כשהוא דיבר מקודם על ה-Passion שלו “להיות בקוד”, האהבה שלו לקודד, מצד אחד, ומצד שני גם הרצון לבוא ועדיין ולהיות מנהל ולפתח קריירה, ואני מסכים שאולי זה לא הדבר הכי נכון ל-Business - לפעמים כן, לפעמים לא - אבל אני דווקא לא מסתכל עם הפרספקטיבה הזאת. אני יותר מסתכל עם הפרספקטיבה של ה-Gen-Z - של המימוש העצמי, של איך תרגיש יותר טוב, האם תרגיש יותר טוב, או בכלל, איזשהו ניסוי מחשבתי, השוואתי, בין “קריירת זיג-זג” נקרא לזה, לבין “קריירת Hybrid”, של מנהל שהוא גם 20% מפתח. ואני גם מבין את הפרספקטיבה של, כאילו, אוקיי - זאת אולי לא דרך נכונה לנהל - אבל שוב, אני מנסה להסתכל על זה מרמת ההגשמה העצמית.(רועי) אז אני חושב שברמת ההגשמה העצמית, אי אפשר להגשים את עצמך אם אתה לא מצליח - ואתה לא יכול להצליח להיות באמת מנהל, שעושה 20% Hands-On בשביל זה.(רן) באף רמה, אגב?ז את אומרת, גם אם זה ראש צוות, או שלזה אנחנו לא קוראים “מנהל”?(רועי) זה חד-משמעית מנהל - אבל זה ניהול מסוג אחר.אני כן חושב - אם ניקח את השאלה לכיוון טיפה אחר - שבכל רמה שונה של ניהול, כן צריך להיות איזשהו אלמנט “בקיאותי””בתוכנה, שעד גודל מסוים מגיע הכי טוב מאיזושהי עבודה Hands-On-ית.אבל זה מאוד משתנה . . . אז אם אתה רוצה להגשים את עצמך - פתח כתחביב: אפשר לעשות דברים מאוד מגניבים ולהגיע למקומות מאוד מעניינים.אבל במסגרת התפקיד שלך כמנהל, שרוצה להיות אפקטיבי ולהצליח - אתה צריך להיות Hands-On-י בצורה הולמת.אם אתה ראש צוות, אתה צריך לכתוב קוד ולהכיר אותו.אם אתה מנהל ברמה בכירה יותר - עדיין יש דברים שאתה חייב לחוות, כדי שתוכל לדעת מה צריך לתקן.אם לא עשית Deploy, איך תדע את המחיר הנוראי שכל הצוות משלם כשהוא מנסה לעשות Deploy?אם לא ניסית למצוא משהו בקוד, איך תדע שהשתמשתם ב-Constant-ים, ששברו את כל ה-Auto-Navigation ב-IDE, וכל דבר לוקח פי-ארבע? . . . זאת אומרת, כדי שתוכל להקצות משאבים נכונים לפתרון בעיות בחוויית המפתח - שזה משהו שהולך ותופס יותר מקום ככל שארגון גדל - חייבים לגעת בזה.ופה אתה צריך לדעת איך לעשות את זה - בלי לייצר נזק.וזה קשה, כי כל דבר שתעשה, אם הוא חשוב למישהו, אתה במקרה הטוב תעשה אותו באיחור, ובמקרה הרע לא תעשה אותו בזמן או שתעשה אותו שגוי.(רן) זאת אומרת, אם יש סיבה טובה להיות Hands-On, זה רק כדי שתוכל להיות מנהל יותר טוב, לא בשביל הערך “השיעורי” שלך בתיקון של באג נוסף, או הוספה של פיצ'ר נוסף.(אורי) כי החלפת מקצוע - אתה עברת להיות מנהל, החלפת מקצוע. וזה לדעתי הרבה מאוד מהאנשים שעושים את הסוויץ' הזה לא מבינים. אתה לא מנהל עכשיו כי אתה מפתח ממש טוב. אתה מנהל - אתה החלפת מקצוע, וההצלחה שלך תלויה בהצלחת הצוות ולא בהצלחה האישית שלך. גם הרבה ארגונים עושים את הטעות הזאת, ומקדמים לניהול את המפתחים הכי טובים שלהם רק בגלל זה, ולא בגלל שיש להם Passion למקצוע החדש הזה, שעכשיו יש להם, שהם צריכים לראות שאנשים מתפתחים ושאנשים עומדים בהתחייבויות שלהם ושהצוות . . . ושהתרבות של הצוות היא התרבות הנכונה, ושכאילו...(רועי) מצד שני, יש יתרון מאוד מאוד מאוד מאוד גדול בלבוא עם רקע טכני חזק ולהיות מפתח טוב.כי שוב, בסוף - קבלת ההחלטות מפעפעת אליך, והקצאת המשאבים.ובסוף, אתה יודע - זו תמיד שאלה של משאבים, כשבאים ואומרים לך “חייבים לכתוב טסטים, לעשות Refactor” - אתה צריך להבין על מה אתה מדבר,או לסמוך על אנשים בצורה טוטאלית - וגם אז, קצת קשה לגייס אותם אם אתה לא מבין, וגם...(אורי) זה מאוד קשור לסגנון הניהול - וסגנון הניהול מאוד קשור לחוזקות שלך כבן אדם, ואתה לפעמים, בוא נגיד ככה, לא תמיד אתה שואב את מקור הסמכות שלך ואתה היכולת שלך לקחת החלטות מזה שאתה יודע ומכיר את הקוד הכי טוב.(רועי) נכון, ואני אגיד פה אמירה שאני אגיד בזהירות - בישראל, יותר קל לנהל עם רקע טכני, בגלל שאנחנו רגילים, בגלל הצבא, למודל שמקדם אנשים שהגיעו מאותו תחום טכני.בצבא, אתה חייב להיות מקצועי בתחום של מה שהחיילים שלך עושים, לפחות ביחידות שדה.וזה מפעפע לתעשייה - אנחנו רגילים למודל כזה של ניהול, ומאוד כזה...(רן) זה מעניין, אולי דווקא הגישה השונה של אורי בצבא דווקא מוביל אותו לנקודה אחרת, כי הרבה פעמים אתה אומר ש...(אורי) . . . זה נכון, כן . . (רן)  . . . בצבא לא למדת [אורי] “לנהוג באונייה”, נהגת לנהל את האנשים שמטפלים במנוע ובמערכת הטילים.(אורי) לעומת זאת, אף אחד לא נגע לי בהגה וב-Throttle-ים . . . ומי שנגע, קיבל מכה על היד. (רועי) אבל זה נכון שחיל הים מתנהל בצורה מאוד אמריקאית . . . הקונספט הזה, של “התגייסת להיות קצין” . . . (אורי) נכון . . . (רועי) . . .  עברתי שם, אז אני הכרתי, אני מכיר את המסלול.וזה כל הזמן היה מאוד מונגש, זה היה מאוד מוזר.(אורי) זה גם כל הזמן באוויר, כאילו... אני זוכר שאני, בתחושה שלי בתור קצין צעיר, כאילו אמרתי “מה זה המסלול  המחורבן הזה? למה אני לא יכולתי...” . . . כאילו, “אני יודע להיות מפקד טוב, אני לא יודע להיות חייל טוב - אז מה זה שווה?”(רן) . . . . אם ישאירו אותך לבד על סירה, אתה כנראה תטבע . . . (אורי) כן . . . אבל רק אחרי שנים הבנתי איזה כוח זה נתן לי - היכולת . . . זה נתן לי כוח אדיר לנהל אנשים שהם הרבה יותר טובים ממני. וכשאתה יודע לעשות את זה, אתה לא נהיה תקרת הזכוכית של הארגון שלך. אתה פתאום יכול לעבוד עם אנשים מבריקים, מאוד מאוד חזקים, להצליח להוביל אותם, ואין לך שום בעיה לעשות את זה, וזה חלק מהמסלול הזה.אני מספר שכשהגעתי, קיבלתי את הפיקוד על הספינה הראשונה. היה חורף, אז החיילים חיכו לי ב-MES של הדבור, במטבח, ואני זוכר ממש את הרגליים שלי, כשאני יורד . . .  את הנעליים, כשאני מסתכל על הנעליים כשאני יורד בסולם, וזה סולמות-לולים כאלה, אז עוד הייתי נזהר, ואני זוכר ממש את הרגליים, ואני זוכר את התחושה ש”אני החדש”. ועכשיו אני בא, ואני צריך לעשות פה איזשהו “שופוני” על הצוות, ובסוף לקחת אותם לצאת לים, לעשות משימה, לחזור בשלום - וכולם יודעים שאין לי מושג ירוק.אבל זה נותן לך כלי אדיר אחר כך לחיים - שאתה יכול להוביל צוותים של אנשים הרבה יותר חזקים ממך.(רועי) אתה מרגיש שזה עבר גם לאנשים שלא רגילים לדינמיקה כזאת? כי בחיל הים, החיילים מצפים לזה. זה ב...(אורי) נכון, הם יודעים שיהיו לך עכשיו שלושה חודשים פאדיחות נוראיות . . . (רועי) אז אני תוהה, אני לא יודע לענות על זה . . . האם זה נכון למפתחים בכירים? האם יכול להגיע מישהו שהוא בישראל, שהוא “מנהל-על", לצוות של מפתחים שרגילים לתרבות שלנו פה בישראל, ולהצליח לעשות את אותו מעבר?אני בטוח שזה אפשרי, אבל זה יהיה... זה יהיה קשה.(אורי) תראה, בסוף, מה הכלים שקיבלתי מהדבר הזה? אחד זה היכולת לשאול את השאלות החכמות, בצורה הנכונה,שאנשים -לא תהיה להם בעיה לענות לי. והיכולת השנייה זה ללמוד מאוד מאוד מהר, ללמוד את המטריה (Material) מאוד מהר, להבין את העקרונות שמאחורה. כי בסוף כל התוכנה וזה - זה בסוף “אינסטלציה”, הכל אינסטלציה. זה Data שזורם בצינורות, ולפעמים יש סתימה בצינור, ולפעמים יש נזילה בצינור, וכאילו, בסוף זה זה.אז היכולת להבין את העקרונות, ועל זה להלביש את השאלות הנכונות ומהר מהר מאוד להבין את התמונה.(רועי) אז תוך כדי שדיברת, הבנתי שזו בעצם תשובה הרבה יותר טובה לשאלה שרן שאל אותי קודם, של מה אני למדתי . . . כי זאת בעצם אותה תשובה.ותוך כדי שאתה מדבר על זה, אני חושב שזה בעצם אותו מסלול.כי להיות בקורס חובלים, כשאתה בעצם מפקד בשנה האחרונה שלך, ואז להגיע למצב שאתה חדש על הספינה, זה גם באיזשהו מקום אותה תנועת זיג-זג, של לעבור מ . . . .נכון, אתה עדיין מפקד, אתה עדיין אחראי אבל תמיד יהיה שם את ה...(אורי) אין שם . . . זה אני, החיילים, הכלי - ולך לים.(רועי) אבל החיילים יודעים . . . (אורי) הם יודעים טכנית, וזה, אבל...(רן) לא, אני חושב שאם אני מבין נכון את רועי, נניח עכשיו עברת לכלי אחר, עברת לסירה אחרת - אתה שוב הכי פחות מקצועי. אולי צברת איזושהי מקצועיות, היית שנה ומשהו על איזשהו כלי, כבר צברת איזושהי מקצועיות,אתה מכיר, אתה כבר לא הכי חדש - והנה שוב אתה הכי חדש, כי שוב הצטרפת לצוות חדש, לסירה חדשה.(אורי) כן - רק שהאחריות עליך.(רן) כן, האחריות עליך.(אורי) כאילו, הם לא יחזרו הביתה בשלום - בגלל טעות שלי.(רן) שכולם יחזורו הביתה בשלום, קודם כל. (רועי) אני חייב להגיד שחוויית הפיתוח ב-Salto הייתה פחות אינטנסיבית . . . .(רן) כן, חזרת הביתה בשלום . . .(רועי) אבל המסקנה זהה לפחות - בדיעבד,  אני יודע לבוא ולהגיד שכן, אלה הדברים שלקחתי.האחריות לא הייתה עליי, או שהייתה אחריות אחרת, אחריות של מפתח.42:32(רן) בסדר אז כיף לנו ונעים אבל אוטוטו נגמר הפקק - כבר הגענו ואנחנו לקראת הסוף. אז אולי עוד כמה מיליםלפני שאנחנו נסיים? קודם כל תודה רבה! השיחה הייתה סופר-מעניינת.כמה מילים על Hello Heart - ככה, איפה אתם נמצאים? אם אתם מגייסים אז מה אתם מחפשים? וזהו, ספר לנו קצת.(רועי) אז קצת זלגתי לזה בהתחלה, אז אני אשתדל לא לחזור, אבל שוב - חברה שקיימת כבר עשר שנים.חיפשנו - צוות המייסדים חיפש -  חיפש את ה-Product-Market-Fit הרבה מאוד זמן - ומאז אנחנו בגדילה מאוד גדולה.גם מבחינת הכנסות, גם מבחינת כוח-אדם, גם מבחינת תחומים שאנחנו מפתחים בהם פיצ'רים של המוצר.יושבים בתל אביב, מגייסים - כרגע אני מגייס משרת QA, תחום שקרוב לליבי.אשמח להוסיף, אבל נראה לי שאמרתי . . .  האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 479 של רברס עם פלטפורמה, שהוקלט ב-8 באוקטובר 2024, תאריך עצוב. אורי ורן מארחים את אריק מחברת Remitly לשיחה על Distributed Workflow Engines.00:50 אריק ו-Remitly(רן) אז קצת לפני זה - קצת ספר לנו עליך וקצת על החברה.(אורי) באיזו שפה ספרת לנו? . . . (אריק) ספרתי ברוסית.(אורי) אוקיי, אז הנה - כבר פרט Intro שלא ידענו עליך . . . (אריק) לגמרי. אני יודע רוסית - אבל אני אוקראיני.(רן) יודע, אך לא אוהב.(אורי) אמרנו שמדברים על טכנולוגיה, לא? . . . (אריק) אז אני אריק שטיבלברג - מגבעתיים, אני מתכנת מגיל 11 בערך.נגעתי במלא תחומים, למדתי תלת-למד ובניתי מערכות הפעלה וכל מיני דברים לכיף, אבל מבחינת הקריירה, אז עבדתי בכמה סטארטאפים, חברות בחו”ל.הצטרפתי לסטארט-אפ בשם Rewire, ממש חצי שנה לפני הרכישה - ואז Remitly העולמית באה וקנתה אותנו, ומאז אני כבר שנתיים וחצי בחברה.ו-Fun Fact עליי - הייתי פעם טכנאי מכונות תפירה . . .(רן) Singer?(אריק) כן, גם - אבל עבדתי ב-Bernina.(רן) אוקיי, לא היתה לי כזו - אבל Singer היה(אריק) מכיר . . . (רן) כן, אמא שלי מאוד אהבה לתפור ואני כילד קטן, הייתי השוליה שלה. ידעתי להחליף חוטים ולתקן תקלות פשוטות.אוקיי, מעולה, נחמד לשמוע. אז הזכרת פה שתי חברות, Remitly ו-Rewire. מה עושים?(אריק) אז מה ש-Remitly עושה - היא מספקת שירותים פיננסיים ללקוחות שצריכים לנהל כספים ביותר ממדינה אחת.יש לנו מיליוני משתמשים, שמעבירים עשרות-מיליארדי דולרים בשנה.היא הונפקה ב-2021, אז אם יעניין מישהו.(רן) אז בגדול זה חברות רב-לאומיות, כן? כמעט כל חברה רב-לאומית עושה את זה גם, או שהן אולי לא?(אריק) אז אני אפקס את זה, כי מה שאנחנו עושים זה בעיקר העברת כספים בינלאומית, בעיקר למהגרים, כן? אנשים.אם ראיתם את הפיליפינים שעומדים בתור בדואר? - זה שלנו.(רן) אז כמו Wise, למשל? זו הנישה?(אריק) זה בין המתחרים שלנו. Wise נועדו יותר ל-Digital Nomads, אנשים שיש להם יכולות כלכליות.אנחנו מדברים פה על מהגרי-עבודה, שפחות יש להם את היכולות הכלכליות.(רן) חתך סוציו-אקונומי שונה.(אריק) בדיוק.(רן) אוקיי, אז העברות כספים בינלאומיות זה Remitly. ו-Rewire זה גם?(אריק) Rewire זה הסטארטאפ הישראלי, שהמוצר שלו עדיין רץ מאוד חזק בארץ.אבל זה פשוט אחד מהמוצרים של החברה, והוא לאט-לאט משתלב לתוך Remitly העולמית.(רן) הבנתי. אני יכול רק לדמיין שבתהליך כזה של העברת כספים יש איזשהו Workflow, נכון? יש איזשהו תהליך שקורה - ולכן התכנסנו כאן.03:42 מה זה Workflow?אז בוא נדבר: מה זה Workflow? מה הצרכים-המוצריים שהולידו את מה שאנחנו הולכים לדבר עליו עכשיו?(אריק) אז Workflow - כעיקרון ההגדרה שלו זה פשוט “תהליך”, כן? תהליך שכאילו, זו המילה שלו בעברית, שהוא מורכב מכל מיני פעולות.אם ניקח אפילו דברים שכל אחד מכיר, לא יודע - “אתה רוצה להזמין משהו”, כי אני עבדתי בחברות eCommerce: אתה מזמין משהו, מחייבים אותך, שולחים לך הודעה, מישהו אוסף את זה במחסן, שולח . . . יש תהליך שלם.ואתה רוצה לעקוב אחרי זה ולדעת מה קורה שם.תראה, בעולם פשוט - למי אכפת? אז זה נפל . . . כאילו, בוא נראה, בעולם הכי פשוט זה לא יפול, כן?זה ירוץ, חלק - בניתי Script לוקאלית, והוא עובד.(רן) אבל האופטימים לא שורדים, זה אנחנו יודעים . . . [Only the Paranoid Survive, וגם הם מג’עג’עים לאחרונה . . . ](אריק) לא, ולא רק שלא שורדים - אם אנחנו מדברים על Scale עכשיו, על מיליונים כאלה.אם אני מסתכל על התהליך הזה, אפילו מה שתיארתי עכשיו - איפה הוא יכול ליפול?הוא יכול ליפול בהמון דרכים, בין אם זה...(רן) תהליך שבו לקוח רוצה להעביר כסף, נגיד מישראל לפיליפינים?(אריק) כן, אפשר לקחת גם את הדבר הזה. לקוח רוצה להעביר כסף, איפה תהליך כזה יכול ליפול?השרת שעליו זה רץ יכול ליפוליכול להיות שחייבת את לקוח אבל לא לא רשמת כי השרת נפל.יכול להיות שאתה ניסית לחייב, אבל הכרטיס אשראי לא נכון, אז עכשיו זה צריך לנהל גם את התהליך הזה.ניסית לשלוח הודעה, אבל זה לא עבד, או שזה הספק צד-שלישי,שפתאום לא נגיש.אנחנו עובדים אפילו לפעמים עם ספקים שיש להם שעות מסוימות שהם לא עובדים בהן. נגיד הסינים ידועים בזה שהם פשוט במהלך הלילה, השרתים שלהם כבויים לחלוטין.(רן) האמת שזה גם נכון בעולם הפיננסי בכללי, כשרוצים להעביר כסף, נגיד, מחוץ לישראל, כן? יש שעות-פעילות פיננסית, יש ימים שבהם בנקים פעילים.(אריק) לגמרי.(אריק) אז הנושא המרכזי שאנחנו שאנחנו נדבר עליו זה העניין של עמידות, כן? אמרנו שבעולם אופטימי, הכל קיים, הכל יעבוד. אבל כמו שאמרת - אופטימים לא שורדים, אז אנחנו צריכים להתחיל לחשוב טיפה על איך אנחנו מוודאים שהתהליך הזה שבנינו הוא עמיד.(רן) כן, זה תהליך שנראה פשוט - נגיד, העברת כסף ממדינה א' למדינה ב' - יכול להיות מורכב, יש נקודות כשל רבות באמצע, ואתה אומר שעמידות זה אחד מהם. הזכרת גם עוד משהו, נגיד שקיפות - להבין מה קורה עם התהליך, להבין האם זה נתקע, איפה זה נתקע, Debuggability או Whatever. זאת אומרת, היכולת גם של אנשים שלכם ואולי גם אנשי-תמיכה לבוא ואולי לתקן את התהליך אם צריך.(אורי) אנחנו מדברים גם על ה-Recoverability שלו - האם הוא יכול גם לתקן את עצמו?(אריק) כן, אז העניין הוא או שהוא מתקן את עצמו, או שאתה נותן לו - נותן את האפשרות למפתח לבוא וסוג של לעשות Upgrade. זאת אומרת, Upgrade לתהליך, בזמן שהוא רץ, כדי שאתה מתקן אותו, ואתה לא יודע, מבטל הכל, מתחיל מההתחלה.כי יש גם מערכות כאלה.אז אנחנו מדברים על כלים שנועדו להפוך את כל הניהול והעבודה עם ה-Workflow-ים בכללי למשהו שהוא הרבה יותר נגיש למתכנת, למפתח, נותן את ה-Visibility הזה.ויש, אם אנחנו נעשה Zoom-in לכלי הספציפי שאנחנו מדברים עליו, שזה Temporal - אז הוא נותן לנו הרבה מהדברים האלה, ואפילו טיפה מעבר.(רן) אוקיי, אז הפתרון שבחרתם, זה כלי בשם Temporal - אבל הוספתם אליו או מעליו עוד פונקציונליות או שכבות נוספות, או פיצ'רים שתיכף תספר לנו עליהם - שלא היו קיימים בכלי המקורי.(אורי) אני רק רציתי לשאול - רבים ממאזיננו מכירים Workflow-ים של Data: יש Workflow Engines ויש Airflow, הרבה משתמשים ב-Airflow, או Workflow אחר של ETL-ים או דברים כאלה שקשורים ל-Data. זה דומה? זה שונה?(אריק) אני חושב שזאת שאלה מעולה.נגיד, כלים כמו Airflow - הם נועדו יותר למה שנקרא ETL, כן? - Extract Transfer Load.שזה באמת, אתה מעביר Data ממקום למקום, משנה אותו טיפה בדרך.הרבה שימושים, אם זה ב-Machine Learning, אתה יודע - אתה מעביר את זה ל-Data Lakes, כדי ש-BI יוכלו לבנות על זה כל מיני אנליטיקות מגניבות . . . (אורי) אבל גם שם - מאותם אתגרים - זה יכול ליפול, ואתה לא יודע מתי זה נפל. חוץ מזה, שהסינים מכבים את השרתים, כאילו, גם שם הרבה דברים יכולים לקרות.(אריק) אז אני חושב שהשוני - כי אנחנו, הפוקוס המרכזי שלנו פה הוא מה שנקרא Business-Logic Workflows.השוני ביניהם הוא גם בצורך שלך בעמידות - כי אם אתה אומר “יש לי מיליון שורות ב-Database, שאני רוצה להעביר אותן ממקום למקום”.אם עכשיו התהליך הזה לא עובד במשך שעה, מאיזושהי סיבה, או שהצלחתי להעביר 500 אלף, אבל עוד איזה 2-4 באמצע נכשלו - איפה יותר אכפת לי מזה?האם אכפת לי מזה כשלקוח מחכה שההזמנה שלו תצא לפועל - תגיע, תתעדכן, להבין מה הסטטוס?לעומת BI - שיכול להיות ששם אנחנו, בתור עסק, נגיד “בסדר, לא נורא - מישהו יבוא, ייכנס, יתקן את זה, נריץ את כל המיליון מההתחלה” . . . .(אורי) בוא נאמר ככה - כשיש לך המון לקוחות שמחכים לדאטה, שהוא יהיה Visible ושיהיה . . .  זה כואב. זה כואב, לצורך העניין, באותה מידה כמו שלקוחות מחכים למשהו.(אריק) כן, כן,(רן) אז אני חושב, אורי, אני אנסה רגע - ואריק, תקן אותי - קודם כל, אתה צודק: זאת אומרת, יש דמיון בין כלים כמו Airflow לבין Temporal, שתכף נדבר עליו. בגדול, Workflow Engines מסוגים שונים, יש יש גם Drools, אם אתה זוכר, ויש AWS Step Functions, ויש azkaban . . .  זאת אומרת שלא חסרים כלים. אני חושב שהצורך של Remitly הוא בעצם בכלי, שהלקחות שלו הם לא מפתחים, אלא הם החברה כולה, בגדול. זה אחד. שתיים - Scale שונה לגמרי. אני מדבר על מיליוני-טרנזקציות (Transactions), או מיליוני תהליכים, שרצים במקביל. קשה לי לדמיין ש-Airflow מסוגל לסחוב דבר כזה, הוא לא נועד לזה. אולי זה אפשרי, אבל . . . .(אורי) אולי. אצלו, האתגר הוא שכל Data זה . . .  כאילו, כל Flow מריץ, פשוט.(רן) כן - אבל פה מדובר על מיליוני Workflows. ה-Workflows עצמם הם אולי “Lightweight” כאלה, זאת אומרת - הם יכולים לקחת אולי כמה ימים, כי יש דברים באמצע, אבל הם לא “Data Heavy”, אוקיי? ויש מאפיינים אחרים, נגיד של נגיד שקיפות, שהוא צריך. זאת אומרת, קשה לי לדמיין . . . לתת Airflow לאנשי התמיכה, והלגיד להם “בוא, תדבג (Debug) את הגרף”, כאילו - “תבין מה קרה”.אז כן, אז משתמש-הקצה - הוא שונה לגמרי, כנראה, באופי.(אריק) כן, אני חושב שתמיד נקודה חשובה, שאנשים מפספסים אותה, זה שגם יש לנו לקוחות פנימיים - BI, Data, זה גם עוד Interface מאוד משמעותי ונקודה טובה שאנשים מפספסים אותה.אבל, לגמרי - אנחנו, מעניין אותנו הפרט, לעומת מקרים אחרים, שלפעמים מעניין אותך ה-Batch של ה-Data.אז אנחנו באמת חייבים, ברמת הפרט, ברמת הזמנה הספציפית, ברמת ההעברה הכספית - לדעת בדיוק מה קורה שם, לדעת איפה, מה הסטטוס שזה נמצא בו, ולא לאבד את זה בשום שלב בדרך.ובמקביל, אם יש הזמנה אחרת שהיא “רצה” - אז לתת לה לרוץ.(אורי) גם בוא נודה על אמת - אתה מתעסק פה עם כסף של אנשים, אז זה חייב להיות ממש מדויק, אבל גם עם “אופי טרנזקציוני” (Transactional) יותר, שכאילו . . . (רן) כן, אולי עם יכולות Roll-back מסוימות, או - הזכרנו הרבה פעמים - אבל שקיפות, או יכולת לבוא ולתקן בעיות, כי אנחנו יודעים שתיהינה בעיות, מתישהו.(אורי) אבל גם מאוד חשוב לדעת מה ה-State - איפה ה-Flow נמצא.12:37 על כוראוגרפיה (Choreography) ואורקסטרציה (Orchestration)(רן) אוקיי, אז הזכרנו כמה פעמים את השם של הכלי - Temporal - אבל לא ממש הסברנו מה הוא. אז תן לנו ככה איזשהו “גיץ” של מה זה Temporal - מאיפה הוא הגיע ומי פיתח אותו, למה ומה אתם עושים איתו. הרבה שאלות . . . (אריק) אז אני רק אזכיר: יש בעולם הזה של ניהול Workflow-ים - Workflow-ים Business-יים - אנחנו, לרוב, יש כזה . . . לא יודעים אם “ריב”, אבל יש לנו שתי דרכים מאוד מרכזיות, שבדרך כלל מתעסקים בזה, שזה או כוראוגרפיה (Choreography) או אורקסטרציה (Orchestration).בכוריאוגרפיה (Choreography), אנחנו אומרים שיש לנו כל מיני חלקים, כל חלק מכיר את האיזור שלו - הוא יודע מה נכנס, מה יוצא - אבל לא מכיר את כל התהליך.ואז מה שאנחנו מדברים עליו, זה שאנחנו רוצים לעשות אורקסטרציה (Orchestration).וגם לנו חשוב האורקסטרציה, כי כל העניין הזה של ה-State - אז זה עוזר לנו שיש לנו כלי אחד, נקודה אחת שבה אנחנו מסתכלים על כל התהליך ויודעים בדיוק איפה הוא נמצא.ויש תמיד מישהו ש”עם היד על הדופק” - מה קורה לדבר הזה.(רן) כן, זו הפעם ראשונה שאני שומע את ההבדלה הזאת, בין כוריאוגרפיה לאורקסטרציה, אז בוא נראה האם הבנתי, בוא נראה האם הפנמתי: אז נגיד, אורקסטרציה זה באמת Workflow Engine, והזכרנו פה כמה כאלה - Airflow ו-Temporal - אז יש מנהל אחד, שהוא אחראי על כל התהליך ואתה יכול לבוא ולשאול אותו “תגיד, מה קורה עם X?” והוא ידע להגיד לך מה קורה עם X. בכוריאוגרפיה, אני מנחש, אולי microservices? זאת אומרת, כל אחד אולי מכיר אותו ואולי את השני שכנים שלו, אבל הוא לא מבין את כל המערכת, אין Service אחד, אין microservice אחד “טיפוסי”, שבאמת מכיר את כל שאר המערכת ויודע לבוא ולהגיד מה המצב בהכל.אני כמובן מוציא מהכלל נגיד שירות Monitoring, שאולי זאת העבודה שלו, אבל בגדול, microservice עצמו . . .  זאת אומרת, אין איזשהו Orchestrator ב-microservices.(אריק) אני חושב שכשאנחנו מדברים על אורקסטרציה (Orchestration), אתה עדיין יכול שיהיה לך  microservices, ואחד מהם עושה לך אורקסטרציה (Orchestration) לשאר ה-microservices, אבל ככלל . . .כאילו, גם בכוראוגרפיה (Choreography), אתה יכול לרצות לשלוח את כל המידע של הסטטוס הגלובלי לנקודה מסוימת, אבל המטרה בכוראוגרפיה (Choreography) זה שלא תיהיה לך נקודת-כשל אחת.לעומת זאת, באורקסטרציה (Orchestration), אתה יוצר - בכוונה - נקודה אחת מרכזית, שהיא . . .  כמו “מנצח על תזמורת”.(רן) אז Database מבוזר, או “האינטרנט”, יכול להיות דוגמה לכוראוגרפיה (Choreography), אני מנחש . . . אוקיי, בסדר.15:04 מי בנה אותו?(רן) אז אורקסטרציה (Orchestration) - Temporal. מי הוא?(אריק) אז כשאנחנו מדברים על אורקסטרציה (Orchestration), ואנחנו אמרנו “תהליכים” - אנחנו רוצים שהתהליכים האלה יהיו עמידים.יש מושג כזה שנקרא Durable Execution - שזו אבסטרקציה (Abstraction) של בדיוק כל הדיבור הזה על ה-State.התפקיד שלה זה לשמר את המצב של התוכנה.זאת אומרת, כל פעולה שנעשית, מבחינת האבסטרקציה - היא אומרת “אני עושה את הפעולה, ישר סיימתי אז אני לוקח את התוצאה, שומרת את זה אצלי ב-Database, הולכת לפעולה הבאה, שומרת את זה אצלי ב-Database” . . . . ותמיד יודעת איפה אני.והמטרה של זה היא שאם ה-Orchestrator שלי או משהו אצלי נפל - אני קם ואני יכול . . . .נגיד, אם אנחנו מדברים על Kubernetes ויש לי כמה Pod-ים, אז אם Pod אחד נפל, Pod אחר יכול לקום.והוא יודע באיזו נקודה זה התהליך עצר, ויכול להמשיך.(רן) כן, אז מי שמגיע מעולם ה-Database-ים, כמוני, מכיר את הקונספט של Commit Log - כל פעם לפני שכותבים ל-Database, קודם כל כותבים מה הפעולה, מתי היא התחילה ואם היא הסתיימה בהצלחה אז גם איך היא הסתיימה. ואז אפשר באמת לעשות, אם צריך להתאושש, אפשר לעשות Replay ל-Commit Log, או לדעת בדיוק איפה זה נעצר.(אריק) בדיוק, בדיוק. אז הקונספט הזה של Replay - רק ברמה של קוד.אז תדמיין . . . . ניכנס ל-Temporal יותר, כי Temporal בסופו של דבר, זו אימפלמנטציה (Implementation) של הקונספט הזה.יש כמה אימפלמנטציות, ו-Temporal היא מאוד מפורסמת, היא גם באה מ-Uber . . .(אורי) . . . היא באה ב-Uber . . . .(אריק) ל-Uber היה . . . יש כלי פנימי שקוראים לו Cadence, אז החבר'ה שיצרו את זה ב-Uber יצאו, עשו את הכלי Open Source הזה, שנקרא Temporal.(רן) אז אני יכול לדמיין שב-Uber, אז Temporal [כנראה ש-Cadence] הוא הכלי הפנימי שלהם והוא זה שנגיד מנהל את הנסיעות, וכל נסיעה זה איזשהו Task, ויש לה איזשהו Workflow מוגדר של לקוח שהזמין, ואז נהג קיבל, ואז הם נפגשו וכו' . . . .(אריק) לגמרי.(אורי) עובד - חוץ מביוון . . .(רן) טוב, את זה אפשר להגיד על הרבה דברים, אורי . . . (אורי) לא, הקונספט הזה - של נהג קיבל, הגיע, מתי, לא . . . . (רן) האנשים עובדים, חוץ מביוון . . .  אוקיי, אז זאת אומרת - Temporal צמח ב-Uber, ואחר כך יצרו גרסת Open Source שלו - ואתם מצאתם אותו ככה?(אריק) אני מכיר את Temporal עוד מהחברה הקודמת - עבדתי ב-Avo, שכבר נסגרה.עשינו גם תהליך מאוד מורכב, eCommerce וזה - ואנחנו לא השתכנענו אז ש-Temporal הייתה מספיק בשלה [לא, כי אבוקדו . . . ]וגם זה דרש שינויים מאוד גדולים.ברגע שאנחנו ב-Remitly החלטנו לבנות איזשהו מוצר חדש, הייתה לנו הזדמנות לבנות מערכת “From the Ground Up”.ב-Rewire, אנחנו ידענו את כל הצרכים האלה, וכמו כל סטארטאפ, כמו כל חברה, בנינו כלים משלנו - בדיוק לעשות את כל הדברים האלה  . . . .לנהל את ה-State, לנהל Re-Try-ים, לנהל את כל הדברים המורכבים האלה.כמובן שלא עשינו את זה טוב כמו כלי שנבנה לטובת זה כמו Temporal - אז ברגע שהייתה לנו את ההזדמנות לבנות Form Scratch, קפצנו ישר על הדבר הזה.(רן) שנייה . . .  אתה אומר “Form Scratch”, אבל למעשה זה להשתמש בכלי - להשתמש ב-Temporal, אבל “להתחיל אותו נקי”.(אריק) להתחיל “נקי” - כי התחלנו מוצר חדש.אז אני אומר - אתה מתחיל מוצר חדש, אתה יכול לבנות, לבחור את ה-Technical Stack שלך - אז זה היה מאוד No-Brainer מבחינתנו, כי פשוט זה “ישב לנו מאחורה” כבר הרבה זמן.(רן) כן, אבל אתה אומר שפעם אחת “עשיתם את הטעות הזאת” - אני עושה ככה “מרכאות באוויר” [מיתרונות הטקסט] - ושאמרתם, או אולי לא הכרתם את ה-Temporal, אבל בניתם כלי כזה בעצמכם. הבנתם מה האתגרים, ואז אמרתם “אוקיי, Never Again! אנחנו הפעם הולכים לחפש כלי שיודע “לתת לנו את ה-80%".19:20 השלמות(רן) אבל כמו שאנחנו יודעים - זה רק 80%. זאת אומרת, זה אף פעם לא הכל.אז איפה . . . או איזה השלמות הייתם צריכים לעשות?(אריק) אז אני אכניס לפה עוד אחד מהדברים שיכולים להתקשר - אנחנו מדברים הרבה על Race Conditions.יש לנו, כאילו . . . אם אנחנו מדברים למשל, אז יש לנו לקוח, שיכול לבצע כמה, נגיד, שליחות כספיים, הזמנות, כל מיני דברים כאלה.וכמו כל FinTech, מעניין אותנו להתעסק עם Risk, כן? הרי נגיד שאתה שולח עכשיו ב-bit, יש לך מגבלה יומית של כמה אתה יכול לשלוח.יומית, חודשית - לא משנה מה.(רן) אז אם המגבלה היא אלף, ואתה פעמיים שולח אלף בו-זמנית - אז אתה עלול לעבור את המגבלה.(אריק) כן, גם בתור . . . כאילו, אנחנו חברה גלובלית, וחברה שכמו כל חברה בנינו microservices . . . .אז אם זה היה Service אחד, Database אחד - אז זה No-Brainer להשתמש בטרנזקציה, ב-Database, וסגרת את העניין.אבל ברגע שאנחנו רצים בכמה microservices - איך אתה יוצר טרנזקציה, Across-Services? זה משהו שהוא קצת יותר קשה.אז מה שעשינו - בנינו מערכת Distributed Locks מעל Temporal - ככה שכל Workflow כזה שרץ, אנחנו כאילו אומרים לו “היי! תקשיב - אני רוצה לנעול את המשתמש הזה, למהלך הריצה של הפעולה הזאת”.וזה משהו שהיינו צריכים, כדי לוודא שאין מצב שיש לנו . . . שלקוחות עוברים, נגיד, את המגבלות היומיות שמותר להם לעשות.(רן) כן, אז סוג של Two-phase Commit כזה - של “אני מתחיל פעולה, תנעל”, ובסוף לעשות לזה שחרור . . . . אז למעשה זו מערכת Locking כלשהי.(אריק) כן.(רן) אוקיי, שזה משהו שלא היה קיים ב-Temporal?(אריק) Temporal - מה שהיא נותנת לך . . . היא נותנת לך הרבה גמישות.איך ש-Temporal בנויה, כמו שאמרנו, יש לנו את ה-Workflow, וה-workflow זה פשוט קוד, כן?כאילו, זה Polyglot, אז כאילו - תבחר כל שפה שאתה רוצה . . .אנחנו עובדים בעיקר עם Node.js, ויש לנו עוד כמה צוותים שעובדים עם Go.זה לא משנה, השפה - זה פשוט פונקציה. פונקציה שקורית . . .כאילו, אתה יכול פשוט לקרוא את הקוד הזה - אין שם איזשהו Boilerplateנגיד, יש Step Functions או דברים כאלה, שאתה מגדיר את ה-Workflow שלך ב-JSON, או ב-Airflow, אם אני לא טועה אז גם, אתה מגדיר את זה ב-Python, אבל מגדיר את זה באיזשהם Pipe-ים כאלה.וזה - פה אנחנו מדברים נטו-קוד: פונקציות שקוראות לפונקציות.אתה יכול לעשות שם If-ים, אתה יכול לעשות שם For-Loop, אתה יכול לעשות שם קוד . . . (רן) כן, זאת אומרת - אין DSL נוסף, זה השפה - זה Node או זה Go, אבל אין DSL נוסף “שעוטף”, ושיכול להוסיף מורכבות ושצריך קונטקסט כדי להבין אותו. זאת אומרת, faמגיע מפתח חדש לחברה, והוא פתאום צריך להבין כל מיני דברים שלא כתובים בקוד.22:22 מה עם לא-מפתחים? ועם Code Versioning?(אורי) רגע, אמרנו לפני כן שה-Workflow-ים האלה יכולים לשמש, או שיכולים להשתמש בהם, גם אנשים שהם לא מפתחים . . . (אריק) אז אני לא יכול להגיד שלא-מפתחים, אבל אני חושב שגם מפתחים ברמות מאוד התחלתיות יכולים להיכנס, ומאוד בקלות להבין מה כתוב שם.כי בסופו של דבר, זה פשוט קוד, כן? אם אתה יודע לכתוב פונקציה פשוטה, עם Loop-ים . . . אתה יודע, אתה מסיים כמה קורסים באוניברסיטה, אתה יכול לקרוא Workflow.כמובן, אתה צריך את הרמות-החשיבה היותר גבוהות, להתמודד עם דברים יותר מורכבים - אבל אני חושב שמה ש-Temporal מביא, וזה אחד מהדברים הכי חזקים לעומת המתחרים שלו, זה Mental-Model יותר קל.כי הוא לקח לעצמו הרבה מה-Heavy Lifting לתוך הפלטפורמה.הוא מנהל לך את ה-Failure-ים, הוא נותן לך Re-Try-ים, הוא נותן לך את הכל - ככה שכשאתה רץ ב-Workflow, ויש לך שורה שאומרת “תשלח לי את ההודעה” - אז זה קורה לפונקציה מאחורי הקלעים.מבחינתך, זו פשוט שורה בקוד, שאתה באמת קראת לפונקציה.והוא יודע להכניס את זה ל-Queue, לשמור את ה-State, לדאוג שאיזשהו Worker יריץ את הקוד . . . ואנחנו יכולים להיכנס בדיוק לאיך שהדברים האלה עובדים.(אורי) זאת אומרת, בכל הדברים שהם  . . . נקרא לזה “התוספות הפנימיות שלכם” - לעשות Locking, רק על זה דיברנו עכשיו . . . את כל זה אתם “מחביאים” מהמשתמש?(אריק) משתדלים, כן.אבל אני חייב להגיד שאנחנו לא היינו צריכים לבנות המון מעל Temporal.יש איזו אימפלמנטציה (Implementation) שאתה מחבר אותו למערכת Race-ים, ו-Log-ים ו-Bug-ים וכל זה.אבל הוא נותן לך המון - גם כי זה קוד, כן? אז תכניס איזה קוד שאתה רוצה.אבל בסופו שעבר אנחנו לא בנינו הרבה מעל Temporal, אלא פשוט התמקצענו באיך להשתמש ביכולות שלו.(אורי) אגב, זה מעלה לי עוד שאלה - אתם מנהלים Code Versioning של ה-Workflow-ים עצמם?(אריק) זאת נקודה מעולה, כי התחלנו להגיד . . .  הזכרנו מקודם על הנושא הזה ש(למשל) יש לנו איזושהי תקלה, ואנחנו רוצים עכשיו, בזמן אמת, לבוא ולתקן את ה-Workflow.אז Temporal נותן מערכת שנקראת Patching.הרי אמרנו, אם אנחנו  . . . נגיד, ה-Workflow נפל באמצע, והוא מקים את עצמו מחדש, ורן - אמרת שזה מאוד דומה לאיך ש-Database-ים עובדים . . .אז הוא עושה את ה-Replay הזה כל פעם.ומה שאתה יכול לעשות - אתה יכול פשוט לעשות Deploy לקוד חדש, הוא יעשה Replay מההתחלה, הוא יגיע לקוד החדש שלך - והקוד החדש שלך פשוט יתווסף בתוך ה-Workflow.(אורי)  . . . והוא גם ירוץ מה-State שבו הוא נעצר . . . (אריק) נכון. יש שם נקודה אחת, שזה אם ה-State החדש לא תואם את ה-State הישן.כי אם נגיד אתה בנקודה מסוימת שלחת SMS - אני כל פעם נופל על SMS, אבל אפשר להגיד נגיד “לחייב את הלקוח” - ופתאום אתה כבר לא מחייב את הלקוח, אלא אתה נגיד מחכה, שמת שם איזושהי נקודה ואתה מחכה שמישהו מ-Customer Support יאשר את הדבר.אז אם אתה תעשה את זה בצורה נאיבית, זה אמור להגיד לך “היי! אני לא מכיר את המצב הזה! הכנסת אותי למצב מוזר!” . . .מה שצריך להגיד לו זה “היי, אני עושה לך Patch - זאת הגרסה החדשה, הנה מה שאתה עושה אם אתה בגרסה הקודמת”.ואתה פשוט כותב קוד של if-else כזה - אם אתה בגרסה החדשה, תעשה את זה; אם אתה רצת כבר בגרסה הקודמת, אז הנה מה שאתה עושה.(רן) אז צריך אחר כך ללכת ולנקות את זה, אני מניח . . .(אריק) נכון, נכון - אבל זה כמו כל . . . יש לך API, אתה עשית...(רן) כן, זה צריך להיות Backwards-Compatible לפחות גרסה אחת אחורה - אבל אם אתה בצרות אז יש לך כמה גרסאות אחורה . . . ב-Production  אתה צריך לתחזק גם את זה, אבל מדי פעם ללכת ולנקות את “השובל” הזה.(אורי) אבל השאלה שלי היא באמת על, אתה יודע - על Code Versioning, על Code Cottrol “רגיל” - יש  ל-Workflow-ים עצמם?(אריק) יש לך בדיוק שתי אופציות: אחת אמרתי - זה ה-Patch-ים,האופציה השנייה זה שאשכרה אתה יכול לשמר את הגרסה הקודמת - בגרסאות האחרונות, Temporal אפילו יכול לשמור את הקוד שלך אצלו, בגרסה הקודמת.ואתה יכול להגיד לו “תריץ את מה ששמרת כבר אצלך”.הנקודה החשובה פה זה שאתה זה שמריץ את הקוד באמת, כן? או ה-Pod-ים שלך, ה-Worker-ים שלך - הם אלה שהם . . .אפשר לחשוב על זה כמו “Subscriber-ים” להוראות שמגיעות מהמערכת של Temporal.יש את המערכת של Temporal, והיא מחזיקה את ה-Queue-ים, היא מחזיקה את ה-State, מחזיקה את ה-Database.והיא מודיעה לך: “תריץ עכשיו את הפעולה הזאת, תריץ עכשיו את ה-Workflow הזה”.אז אתה מחליט איך אתה מנהל את הקוד שלך - אתה יכול להגיד “אוקיי, תנתב את כל האלה הישנים לגרסה הזאת, שאני שומר במקביל”.כמו שהייתי שומר Version 1 ו-Version 2 של API.או “תנתב את שניהם לאותה נקודה” - ושם אני אעשה את ה-If-Else הזה, כן? Backwards-Compatible או לא Backwards-Compatible.או אופציה שלישית, שזה להגיד ל-Temporal “היי, שמור את הגרסה הישנה אצלך במערכת, ותריץ את זה בנפרד”.אבל זה משהו די חדש, רק נכנס כדי לעזור עם הקטעים האלה.אבל לרוב, הם תמיד ממליצים לרוץ עם Patch-ים, זה הרבה יותר נוח.כי גם אתה תמיד יודע - אתה מנהל את המעבר, ואתה יכול לעשות אותו כמה חלק או כמה לא חלק שאתה רוצה.28:34 מערכות מבוזרות ובאגים מאתגרים(רן) אוקיי, אז נשמע שאנחנו מדברים על מערכות מבוזרות - ולמערכות מבוזרות תמיד תמיד יש באגים מעניינים, ומאתגרים, וקשה למצוא . . . . ולפעמים, רק שנה אחרי זה אתה מוצא אותם . . . אז אולי תספר לנו על איזשהם באגים “מאתגרים” שאולי נתקלתם בהם, או Use-Case-ים שאולי לא חשבתם שתצטרכו ופתאום גיליתם שאתם צריכים, או כל מיני ככה, שלא צפיתם בבוקר שבוא החלטתם ש”הולכים על Temporal!”, וגיליתם אחר כך ואיתגרו אתכם.(אריק) אני יכול לדבר על Use-Case-ים מעניינים, גם בהקשר של עוד Feature-ים מגניבים של Temporal.אנחנו, נגיד, עובדים עם איזשהו ספק-צד-שלישי, שהוא - אתה פונה אליו ב-API, זה אחד ממה שנקרא Activities ב-Temporal - והוא מחזיר לנו תשובה.אז הוא אומר “היי, הצלחתי לבצע את הפעולה!” או “לא הצלחתי לבצע את הפעולה” - סבבה.בנקודה מסוימת, הספק הזה, בחלק מהפעמים, הוא מחזיר לך תשובה - אבל בחלק מהפעמים הוא אומר לך “היי, אני ב-Pending, ואני אחזיר לך Webhook”.אז פתאום הוא מוציא אותך מהתהליך הרגיל הזה, שאתה רגיל להתמודד איתו.(רן) “מוציא אותך מה-Zone” . . . אוקיי.(אריק) כן, ושם הייתה לנו . . . (רן) בדרך כלל אתה אף פעם לא יכול להיות בטוח אם הוא ישלח לך את ה-Webhook הזה או לא - כי תמיד יכול להיות שגם אצלם תיהיה איזושהי תקלה . . .(אריק) לגמרי.(אריק) אז אנחנו, מה שעשינו זה מצד אחד . . .  זה גם ספק שלפעמים הוא שולח לך Webhook גם על פעולות שלא אתה ביצעת, כן?כי, לא יודע - ה-Customer Support יכול לפנות ב-UI שלהם ולעשות דברים, אז אתה לא יכול לדעת עד שהוא שולח לך.אם שתעשה לו Polling לדוגמה, משהו כזה.(רן) כן . . . .אז “סליחה, הכסף הזה שלך? אה, לא שלך? לא, שלך? לא. כן? 50 דולר . . . .”(אריק) אז מה שעשינו בהתחלה - חשבנו על לקבל את Webhook-ים, ול-Temporal יש כלי מגניב כזה, שאתה אומר לו “Workflow - חכה”“וחכה” זה יכול להיות לשעה, דקה, יום, אפילו שנה, כן?יש Use-Case-ים שאתה משתמש ב-Temporal בשביל לעשות לך את החשבונית החודשית של לא משנה איזה שירות, כן?אתה עושה כזה Loop, ואתה פשוט . . ה-“Wait” . . . .(רן) “מתעורר” פעם ב-30 יום? . . . (אריק) בדיוק.(רן) . . . או 31, או 28 . . . זה גם מעצבן, כל החודשים האלה.(רן) אוקיי, אז אתם מחכים ל-Webhook הזה?(אריק) אז אנחנו אומרים לו “תחכה” - ול-Temporal יש משהו מגניב שנקרא Signal.זה לא רק תהליך, שאתה פשוט יוצר את הגרף - אלא אתה יכול לבוא אליו מבחוץ, ולהגיד לו “היי, שומע? תעשה את הדבר הזה”.הוא יוצר API כזה, ל-Webhook, ל-Workflow, סליחה.אז כשאנחנו מקבלים את ה-Webhook, אנחנו יכולים או בדרך הרגילה, “הישנה” - כביכול “ישנה”, במרכאות - ללכת ל-Database ישירות ולשמור את זה.או להגיד שאני רוצה שכל הקוד שמנהל לי, נגיד, את הטרנזקציה הפיננסית הזאת - שיהיה בתוך Workflow, כן? Workflow אחד ארוך.שאני רואה ואני יודע בדיוק מה קורה ובין איזה שלב לאיזה שלב.ואז אני רואה שיש לי שורה של “חכה, אני קיבלתי Webhook! אני עושה Signal לתוך ה-Workflow”.ו-Signal זה פשוט כמו קריאת API, ואז מהנקודה הזאת ה-Workflow אומר “אוקיי, קיבלתי” ,וממשיך לרוץ.החלק המעניין של Signal-ים, כי אתה יכול להגיד “רגע, ואם ה-Workflow נפל?”.אז הוא זוכר והוא שומר בהיסטוריה הזאת, ב-Log שלו, שהוא קיבל את ה-Signal הזה, ומאותו רגע אתה לא צריך שה-Webhook יגיע שוב פעם או משהו כזה.ואז הוא מקבל את ה-Input הזה - ואז הוא יכול להמשיך לרוץ איתו כרגיל.מצד שני, אתה יכול לעשות גם Polling - שגם את זה לפעמים עשינו, כשבאמת לא סמכנו על ה...(רן) אז נגיד שם אתה יכול לבוא ולהגיד “אוקיי, אם ה-Webhook הזה לא מגיע אחרי” - נגיד שעה - “אז תרים לי איזשהו Exception”,“תגיד לי שמשהו פה קרה” או זאת אומרת, לטפל בכל מיני מקרים כאלה, של דברים שלא קרו. זאת אומרת, עד עכשיו דיברנו על דברים שקרו, אוקיי? אתה מחכה לדברים שיקרו, אתה עושה דברים, אתה מחכה שהסינים יתעוררו בבנקים שלהם . . . . אבל לפעמים, אתה רוצה לדעת גם כשדברים לא קרו.(אריק) אז זאת נקודה טובה, כי אם אנחנו מדברים . . . . ב-Node.js, יש לנו את ה-Sleep, אז מה שאנחנו יכולים לעשות זה להגיד לו “היי, תחכה ל-Signal הזה, שאמור להגיע מה-Webhook - או אם עברו, לא יודע, X שעות”, כן?ואז, אם עברו X שעות, אז אולי תעשה את ה-Polling בעצמך, ישירות מהספק הזה ותתחיל תהליך, כשאתה טיפה יותר אגרסיבי עם הדבר הזה.כי ציפית שזה יגיע - וזה לא מגיע.בנקודה אחרת, אתה יכול - הרי זה קוד, אז אתה יכול להגיד “אוקיי, בנקודה הזאת, תתריג (Triger) תוסיף כזה משימה ל-Customer Support או ל-Operations זה משהו כזה, שיסתכלו על זה”.ואז - אתה יודע, עוד שורה בקוד, של “תחכה לתגובה מגורם אנושי”.(רן) כן.34:01 כללי-אצבע(רן) אוקיי, אז אנחנו כבר קרובים לסוף הזמן שלנו, הזמן עובר מהר. אולי ככה לקראת סיכום, תן לנו איזה שהם כמה כללי אצבע - מתי כן ומתי לא? כלומר, עכשיו אם מישהו מקשיב לפודקאסט, ואומר “ואוואי! Temporalכלי מגניב! איזה יופי, אני רוצה להשתמש בו!” - אולי תיתן איזה כמה כללי-אצבע למתי זה כנראה נכון וכדאי להסתכל, או מתי, לחלופין, לא - זה פשוט לא הכלי שאתם מחפשים ואולי תסתכלו בכיוון אחר.(אריק) אז כמו אמרנו, דיברנו על ETL-ים - Temporal יכול לעשות ETL-ים, ויכול להיות שיש כבר Use Case-ים לזה - אבל אני חושב שיש כלים כבר שמאוד מפוקסים בדבר הזה, אז הייתי נמנע מזה.ל-Temporal, מאחורי הקלעים יש לו Queue-ים, אבל אם אנחנו מדברים על פעולה קטנה שצריכה להיות ב-Queue, אז גם - לא יודע: RabbitMQ או Pub/Sub או דברים כאלה, יש כבר את הכלים.ברגע שאנחנו מדברים על עמידות, Temporal באמת מעולה - אבל אם לא אכפת לנו מה-Data מסיבות מסוימות לזה, ו-AdTech לדוגמה, זה תחום מאוד מפורסם, ש”מאבד מידע בכוונה”, כי פשוט זה מאוד יקר לעשות  Processing . . .(רן) לא יודע אם “בכוונה”, אבל פשוט לא מתאמץ מאוד לשמור אותו . . . (אריק) בדיוק,אז ה-Temporal בא עם עלות, כמו כל כלי.ברגע שאתה שומר State, אתה שומר היסטוריה, אתה שומר הרבה הרבה דברים - הוא בא עם עלות מסוימת.לנו, ב-FinTech ב-Remitly, מאוד אכפת לנו ואנחנו מוכנים להשקיע את העלות הזאתכדי לוודא שהכל מגיע לסיום ואנחנו יודעים תמיד איפה הכל.אז אם אכפת לכם מאיפה הכל נמצא, בכל רגע נתון - יש להם כלי UI מאוד טובים, שאומרים לך בדיוק.אתה יכול לראות בדיוק את ההיסטוריה הזאת, הסתעפויות של Workflow-ים ותתי-Workflow-ים ותתי -Workflow-ים וכל הקשרים האלה, וכל ה-Re-Try-ים האלה.סאגות למיניהן, מאוד קל לעשות שם.(אורי) אגב, הוא כלי SaaS? או שהוא...(אריק) הוא גם כלי SaaS, אבל בגלל שהוא Open Source, אתה יכול פשוט להריץ אותו On-Prem או, אתה יודע, “בענן שלך”, מאוד בקלות.(רן) כן, אוקיי, אז אם Workflow זה חלק מהותי מהמוצר שלכם, אם אתם צריכים, למשל, משהו שנראה כמו  טרנזקציות (Transactions), אבל לא על Database אחד אלא על איזושהי מערכת קצת יותר מבוזרת, אם אתם צריכים לחכות שהסינים יתעוררו בבוקר כדי להריץ או מחכים לאיזשהו Webhook, זאת אומרת, כל הדברים שהם ככה יחסית א-סינכרוניים (Async) או אולי איטיים ודורשים ויזיביליות (Visibility) - אז יכול להיות ש-Temporal הוא הכלי שאתם מחפשים.36:44 סיום, סיכום ומשרות פתוחות(רן) אוקיי, אז נראה לי שכאן אנחנו מסכמים. אולי קצת לפני זה - עוד כמה מילים על Remitly: איפה אתם יושבים בישראל? או שזה כזה...(אריק) אנחנו יושבים ממש ליד מגדלי אלון - יש לנו קומת-קרקע מאוד יפה, מאוד מעוצבת . . . (רן) “תל-אביבה”. (אריק) מאוד תל-אביבה . . . (רן) טוב. מחפשים עובדים? מגייסים?(אריק) תמיד, תמיד - יש לנו איזה 12 משרות פנויות עכשיו, בכל התחומים.כמובן מלא Engineering - אבל גם לא רק Engineering.(רן) כמה פחות או יותר אתם באזור של הפיתוח בישראל?(אריק) בישראל, אם אני לא טועה, אנחנו באזור ה-80 איש; ברחבי העולם אנחנו משהו כמו 500, ב-Engineering Org.(רן) אוקיי, ויש קשר עם חברת-האם, הגדולה יותר? איפה היא נמצאת, בעצם?(אריק) כן. חברת-האם מבוססת בסיאטל.נבנתה לפני 12 שנה, ואנחנו גם עם מעל 10 Site-ים ברחבי העולם, אנחנו מאוד גלובליים.כמובן, אנחנו עובדים עם לקוחות גלובליים, אנחנו גלובליים. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 478 של רברס עם פלטפורמה, שהוקלט ב-27 באוגוסט 2024. אוטוטו מתחיל החופש הגדול של ה-1 בספטמבר - ואורי ורן מארחים (לראשונה, באורח פלא) את חיים ידיד לשיחה על, ובכן - תוכנה.Image by DALL-E(רן) חיים עשה איתנו המון דברים, כולל כנסים והרבה פרויקטים יפים - אבל מעולם מעולם לא יצא לנו להקליט פודקאסט עם חיים, אז הנה - אנחנו עושים את זה סוף סוף בפעם הראשונה.00:54 חיים, Next disclaimers והכנות למזגן בממ”ד(רן) אז לפני שנצלול לנושא של היום - רמז: “תוכנה” - אז חיים, בוא קצת ספר על עצמך ועל המקום שבו אתה נמצא כעת.(חיים) אז אני בעולם התוכנה כבר הרבה מאוד שנים, יש האומרים יותר מדי - ועדיין לא למדתי להתקרב למיקרופון . . . יצא לי לעשות הרבה דברים, אבל בתפקיד האחרון שלי אני עובד בחברה שנקראת Next Insuranceבעצם, הייתי המפתח הראשון בחברה, וראיתי איך החברה גדלה מחברה של אנשים שנכנסים בחדר אחד מאוד מאוד קטן לחברה עם אלף איש והמון המון מכירות והרבה מאוד כסף שמתגלגל.עם 1000 אנשים - 700 בחו”ל, 300 בערך בישראל - בהחלט אופרציה מרשימה.[גיקונומי #306 – אלון חורי מבטח עסקים]ויש הרבה מאוד דברים שלמדתי בדרך, ושאליהם בעצם הייתי רוצה להתייחס בפרק הזה.(רן) כן, אז למעשה הפרק הזה זה איזשהו Follow-up לפרק קודם, שאני כרגע לא זוכר את מספרו [469!] אבל לא מזמן [~4 חודשים], שהקלטנו עם שי ילין [469 Software development in early stage startups with Shai Yallin] - ובפרק הזה אנחנו גם נפגש עם שי, בקרוב, עוד מעט, אז Stay Tuned.ובפרק הזה, שי דיבר על טעויות - או לפחות הפרספקטיבה שלו - לגבי טעויות שהרבה סטארטאפים צעירים עושים בהנדסת תוכנה או בתכנון של מערכות תוכנה, שלדעתו קצת מאטים או פוגעים בהתקדמות שלהם. אז הפרק הזה למעשה מתכתב עם אותו פרק עם שי, וחיים בעצם מביא פרספקטיבה שונה על חלק מהנקודות ששי הזכיר.אז רק נזכיר כמה מהנושאים, ותיכף גם נצלול אליהם - אחד זה Microservices vs. Monolith, כן או לא?; השני זה תלויות או שימוש ב-Framework-ים - לא יודע אם נגיע לזה או לא; טסטים - איזה טסטים? מתי ואם בכלל; טיפול ב-Infrastructure ואחרים.אז חיים פה, למעשה אפשר לנחש לפי ה-Intro, מייצג את הפרספקטיבה של סטארטאפ שהתחיל קטן - וגדל, ועדיין גדול (טפו-טפו), וגם שם יש לקחים.(רן) אז במה נתחיל?(חיים) אז קודם כל, אני רוצה לתת ה-Disclaimer, כי Next Insurance שטיפה רציתי לדבר עליה, זו בעצם חברה בעולם של InsurTech. עולם הבעיה הוא עולם של ביטוח.זה בגדול אומר Scale, מבחינת טרנזקציות (Transactions) בשנייה שהוא יחסית נמוך.זה אומר - אתה יודע, אם יש “Big Data”, אז הרבה שנים הייתי אומר שאנחנו “Small Data - Big Money” , אבל זה כבר לא נכון כל כך היום . . .יש לנו כבר כמויות מאוד מאוד גדולות של Data, שעוזר לנו בעצם לתמחר את הפוליסות יותר נכון, אז זה כבר לא ממש מדויק.(רן) דרך אגב, בעולם הביטוחים - איפה אתם? יש סוגים שונים של ביטוחים . . . (חיים) אנחנו מתעסקים בעצם בביטוחים לעסקים קטנים - ביטוחים לעסקים קטנים בארצות הברית.לדוגמא, אם אתה צלם או שיש לך מסעדה - אתה צריך ביטוח, כי אחרת אם יתבעו אותך אתה תפשוט את הרגל.ו-Next Insurance בעצם פותרת את הבעיה הזאת - זה שוק מאוד מאוד גדול, אנחנו שולטים על חלק קטן ממנו ויש לנו הרבה לאן לגדול.דרך אגב, אם רוצים תיאור מלא על ה-Business של Next Insurance, יש פרק בפודקאסט גיקונומי עם  ניסים טפירו, שהוא ה-CTO של החברה.מאוד מאוד מעניין, עם הרבה מאוד היבטים עסקיים וראיית-עולם מאוד מפוקחת על איך בונים סטארטאפ מאוד מאוד גדולונראה לי שפה אני אעצור על נושא ה-Business, למרות שגם בזה יש הרבה דברים מעניינים.(רן) אז יש כמה Take-aways מעניינים . . . אחד - זו חברה בתחום הביטוח, שאני מניח שיש משמעות לתשתיות כשהולכים לתחום כזה; ושתיים - אמרת מקודם ואני אזכיר שוב, היית שם ממש מההתחלה, והחברה היום גדולה.(חיים) ואני עשיתי את הטעויות . . . אם שי אמר שאותו שונאים ב-Wix, אז אותי שונאים ב-Next Insurance על הטעויות שאני עשיתי . . . .אני רוצה להגיד עוד Disclaimer - מה שאני אומר הוא מהניסיון שלי, ושקצת כולל את השקפת-העולם שלי.לא כל הדברים הם בהכרח נכונים.אני מאוד מעריך את שי מבחינה מקצועית, ואם אתם בוחרים אם להאזין למה שאני אומר או למה שהוא אומר - אז תבחרו את שלו.אני כן רוצה לתת את הפרספקטיבה שלנו.ופה בעצם הייתי רוצה להתחיל בשני דברים: הדבר הראשון שהקפיץ אותי, המשפט הראשון שהקפיץ אותי, זה “ההכנה למזגן”.אנחנו בשנת 2024! - התחממות גלובלית! אם יש משהו שכל אחד צריך זה מזגן. צריך להחליף את האנלוגיה למשהו אחר.“הכנה לחימום”? הכנה לכל דבר אחר . . . .אבל מזגן - תמיד צריך.(רן) הכנה לממ”ד . . . (חיים) הכנה לממ”ד . . . גם ממ”ד צריך.(אורי) ממ”ד עם מזגן.06:10 מזגן מסוג Microservice ובעיית כמות המפתחים(רן) אז בואו אולי נדבר, לפני שאנחנו ככה צוללים, נצא מעולם הסיסמאות ונכנס למקום יותר… למשהו קצת יותר “תוכנתי”. אז תן דוגמה של “הכנה למזגן” שאתה חושב שצריך?(חיים) Microservices - ותיכף נגיע לזה.אני רוצה להביא איזושהי פרספקטיבה - הרבה פעמים אומרים שכשמתחילים סטארטאפ, אתה לא יודע לאן אתה  תגיע ואתה לא תדע לאן צריך, אבל יש משהו שצריך לקחת בחשבון: יש סיכוי שהחברה תצליח . . . ואם היא תצליח, הרבה מהדברים שאתה עשית בהתחלה, שהיה מאוד מאוד קל לעשות אותם, בעיקר באיזורים של תשתיות - יהיה מאוד מאוד קשה להזיז אותם אחרי זה, בהמשך.ואם אנחנו רגע ננסה להיכנס לנושא הזה של Microservices - יצא לי לראות בלא מעט מקומות Monolith-ים שהיה סיוט לפרק אותם.ויש פה שני דברים: אחד, במישור הארכיטקטוני; אבל הדבר השני הוא בכיוון של התשתיות.זאת אומרת, לעבוד כ-Monolith ולעבוד כ-Microservice זה לא רק לעשות חלוקה ארכיטקטונית לחלקים, אלא גם להצהיר שהולכת להיות חלוקה ארכיטקטונית לחלקים.זאת אומרת שלצורך העניין, יש הבדל בין חברה שמגדירה את עצמה כ-Monolith לחברה שמגדירה את עצמה עם “Microservice אחד”.(רן) בוא נהיה רגע בפוזיציה, אני אשחק את ה-Devils’ Advocate - אתה אומר “תתכוננו למצב שבו החברה תצליח  ותגדל”, ואני אומר “אם תלכו יותר מדי עם Microservices, היא לעולם לא תצליח”, כי אתם תשימו לעצמכם “מקל בגלגלים”, תסבכו יותר מדי את העניינים, תכינו יותר מדי “פתחים למזגן”, whatever הדימוי שתבחר לעצמך. ולכן, גם הקיצוניות השנייה היא כנראה לא טובה. (חיים) לגמרי. זאת אומרת, אם הייתי יכול לתת עצה לחברה שמתחילה, אז תתחילו עם שני Microservices - ואל תעלו מעל לשני Microservices הרבה מאוד זמן.למה אני חושב שזה נכון? אני חושב שזה נכון כי זה מכריח אותך “לחשוב Microservices”, זה מכריח אותך  שתהיה לך תשתית ל-Microservices.אבל להתחיל עכשיו לבנות מאות Microservices, עשרה Microservices - זו כנראה טעות.(רן) בוא נגיד שאם מפתח אחראי לעשרה Service-ים שונים, בשלב הזה - כנראה שעשית משהו מוגזם. (חיים)כן. (אורי) אז אני רוצה לתת, כאילו, משהו שמנחה אותי - גם Outbrain הייתה הפעם Monolith . . .(חיים) אני יודע . . .(אורי) . . . אבל די מהר היא יצאה מזה - ואחד הדברים שהנחו אותי הרבה מאוד זמן, זה משפט שלמדתי מספר שקשורל-Scalability: תאמין שאתה הולך להיות גדול פי אלף; תתכנן כאילו אתה הולך להיות גדול פי מאה; תקודד כאילו  אתה הולך להיות גדול פי עשר - ותעשה Deploy לפי-2 (x2).עכשיו, אפשר להזיז את זה לפה ולפה, אבל המקום הזה של “תאמין שאתה הולך להיות ממש גדול”, הוא נותן לך איזו פרספקטיבה, כי בסוף, תראו כש...(רן) אז בוא רגע נתרגם את זה [גרסת ההגדה ל-Microservices?] - ה”תאמין שאתה הולך להיות גדול” זה ההבנה ששני ה-Service-ים שחיים דיבר עליהם, יום אחד יכולים לפוך להיות אלף. זה כנראה לא בשנה הקרובה, לא בשנתיים  - אבל יום אחד זה יכול לקרות, ויש הבדל בין להתחיל עם Monolith אחד לבין להתחיל עם, נקרא זה “שני Monolith-ים”, זה אפילו לא שני Microservices, אבל שני Monolith-ים. זה State of Mind שונה.(אורי) “Two-o-Lith-ים” . . . (חיים) זה State of Mind שונה, שאומר אחד - אתה יכול לדפלט (Deploy) אותם בנפרד.יש לך איזושהי מחשבה שיש חלוקה-לוגית שאמורה לקרות.לדוגמא - אחת מהטעויות הכי גדולות שיכולים לעשות זה Database משותף, במקרה של Microservices.אני מניח שאתם ב-Outbrain מכירים את זה.היה לכם את ה-Outbrain DB - ולקח לכם שנים לפרק את זה, וזה היה פרויקט מאוד מאוד גדול.אני חושב שבכל מקום שבו עושים טעות באזור של התשתיות, במיוחד במקומות של ה-Data, זה קטסטרופה לתקן את זה אחר כך.אתה משלם פי-עשר, אם לא פי-מאה, בשביל לשכתב את המערכת.(רן) זאת אומרת, לייצר Data-Contracts ו-Database זה לא Data-Contracts, אוקיי? לצורך הבהרה . . . (חיים) נכון.ודרך אגב, Monolith זה לא רק Microservices - בעצם, כל דבר שהוא יחיד במערכת הוא Monolith.אני יכול לתת דוגמה שוב מ-Outbrain, כי כפי שאתם יודעים עבדתי ב-Outbrain, ואני רוצה לתת דוגמה ממש מקסימה.היא מתחילה ב-Commit של [אחד] רן תבורי, לפני המון זמן, שבה הוא מציג את הקונפיגורציה (Configuration) החדשה שהוא פיתח  . . .(רן) סיקרנת . . . (חיים) . . .  והוא אומר שעכשיו סוף סוף יש לנו קונפיגורציה מאוחדת, וכל ה-Service-ים יכולים לשים את הכל במקום אחד, וסוף סוף יפסיק להיות לנו בלאגן.(רן) אני זוכר שהיה לי איזושהי גירוד בראש כשכתבתי את זה . . . (חיים) 8 שנים - או 10 שנים או 12 שנה אחרי זה - חיים ידיד מגיע ל-Outbrainובמשך שנה, כל מה שהוא עושה - אחד מהפרויקטים החשובים שהצוות שלו עושה - זה לפרק את אותה קונפיגורציה, שהפכה כבר להיות מפלצת . . . .כי ברגע שמשהו הוא Monolith, הוא הופך להיות סוג של “פח זבל” - כולם זורקים לשם דברים, אף אחד לא יודע מה קורה שם.היו שם כמה עשרות-אלפי רשומות, בתוך הדבר הזה, שאף אחד . . . כולם פחדו לגעת.(רן) “אומני ה-YAML” הגדולים ביותר מפחדים לגעת בקובץ . . . (חיים) . . . ולקח מלא זמן לפרק את זה.(אורי) אבל אני חושב שה . . . . אם כולנו פה, או אם יש מישהו מהמאזינים שחושב, שהבעיה Scalability שנתקלים בה היא בעיה של כמות הטרנזקציות (Transactions) או כמות הפניות שה-Monolith שלך יקבל - לא, זאת לא הבעיה. הבעיה היא כמות המפתחים. (רן) כן, תודה אורי, וגם חיים הקדים ואמר - אנחנו היינו חברה של Small Data, Big Money [ו-Gartner יוצרים קטיגוריה סביב ה-Acronym של SDBM בעוד 3,2,1…]. נכון, הבעיה היא בדרך כלל “הבעיה האנושית”, הבעיה הארגונית - ולא באמת בעיה של Data Keys. אוקיי, אפשר בהרבה מקרים, לפחות בשלבים הראשונים, אפשר “לזרוק CPU יותר גדול” או דיסק יותר גדול, אבל לייצר Concurrency בין מפתחים זה החלק הכי מורכב.(חיים) נכון.(אורי)  . . .  או גם שהקוד שלך הוא Monolith - אבל אתה יכול לשכפל אותו, זה לא פותר את הבעיה. זאת אומרת, אתה יכול לדפלט (Deploy) כמה שאתה כמה שאתה רוצה, אבל זה לא תמיד פותר את הבעיה - כי הבעיה היא מה קורה כשיש בעיה? או כשצריך לפתח Feature חדש, וב-Monolith זה פשוט “להכניס את היד לקן נחשים” . . . (חיים) לגמרי . . . וב-Next Insurance, אנחנו דאגנו להתחיל ב-Microservices From Day 1, ובעצם . . . (רן) בלי חרטות? כלומר, לא היו נקודות שבהן אמרת לעצמך “לא . . . .”(חיים) לא נתת לי להגיע ל”אבל” . . . אז לא - בלי שום חרטות על התשתית ששמנו בשביל Microservices.ולהגיד שאנחנו נמנענו מ-Monolith? זה Wrong  . . . אנחנו נפלנו בכל מיני מקומות, שאחרי זה היה מאוד מאוד קשה לתקן אותםואני אסביר - יש משהו מאוד נחמד שעשינו: בגלל שאנחנו עובדים עם Microservices ואנחנו חברה מאוד מאוד צעירה, החלטנו לעשות משהו, שבזמן שעשינו אותו היה נשמע מאוד הגיוני - והוא גרם לקטסטרופה כמה שנים אחר כך.דיפלטנו (Deployed) את ה-Service-ים ביחד [מוזמנים להאזין ל-Soundtrack של Jaws להנאתכם]לכאורה - פעולה פשוטה. מה זה משנה? דפלט אחד, תדפלט שניים, שלושה  . . . - זה כל מה שהיה, מה זה משנה?(רן) מה זה משנה? קובץ קונפיגורציה (Configuration file) אחד, שניים, שלושה . . . .(חיים) . . .  בפועל, זו הייתה טעות אחת - והייתה עוד טעות אחת, שנוגעת דווקא לנושא של טסטים.חודש אחרי שהתחלנו לעבוד כבר עלינו ל-Production - שזה די מרשים בשביל סטארטאפ.ואני התחלתי לכתוב Framework של End-to-End Testsוה-Framework של End-to-End Tests הזה פשוט בא “ותפר” כמה שרשראות כאלה של רכישה של פוליסה של ביטוח - כל השלבים לעבור דרכם ששמתי.וזה היה בעצם התחלה של תשתית - תשתית של End-to-End Tests, שבעצם הפכה להיות מאוד מאוד מצליחה, וגרמה לכמה דברים - אחד, אנשים כמעט לא כתבו Unit Test-ים - הם התמקדו בלהרחיב ולשפר את ה-End-to-End Tests.דבר שני - ה-End-to-End Suite הזה היה רץ בתוך ה-Deployment המשותף של כל ה-Services.ובלי לשים לב, הפכנו להיות “Distributed Monolith”  . . . - כי לא היינו יכולים לדפלט (Deploy) Service אחד - היה לנו Build אחד שמשותף לכל הצוותים.וה-Build  הזה הפך להיות לא יציב ולא הגיוניובאיזשהו שלב התחלנו לשבור את זה - וזה כבר היה פרויקט כואב . . . .אני חושב שזה לקח בערך שנה לשבור את הדבר הזה לחתיכות, לגרום לזה ש...(אורי) זה בעצם, בתכל’ס, כשהצוות מתרחב - קורים דברים שהם בכלל לא הארכיטקטורה של התוכנה שלך. הםהארכיטקטורה של איך שאתה מפתח קוד - אם הקונפיגורציות (Configurations) שלך הן Monolith-יות, אם ה-Build-ים שלך, אם אתה על עץ אחד או כמה עצים . . . 16:30 מה עם “ה-Business”?(רן) אבל שוב אני אשחק את “פרקליט השטן” - כשאתה בונה את הדברים בצורה “מהונדסת נכון”, לצורך העניין אתה אומר “אוקיי, צריך איזון נכון בין End to End Tests לבין Unit Tests, צריך שכל Service יהיה Deployed באופן עצמאי ולא יהיה Coupling שם, צריך שהחוזים יהיו כמו שצריך ולא דרך ה-Database”. כל הדברים האלה נכונים - אבל האם זה לא מאט את ה-Business?ופה אני אשאל אותך, נגיד, האם היו סיטואציות שבהן . . . אתה אומר שהייתם באוויר אחרי חודש? ואולי אחר כך  רציתם, כמו כל חברה, לעשות איזשהו Pivot - קטן? גדול? ואני מניח שאחרי שנה היה עוד Pivot, ואחרי שנתיים עוד Pivot - ולפעמים זה לא כזה בינארי - “Pivot או לא?” יש Pivot לחלק מהמוצר, יש . . . .האם היו רגעים שבהם עצרת עצמך או שאנשים אחרים באו ואמרו “רגע-רגע-רגע! למה אנחנו צריכים את כל ה-t!h$ הזה?! אנחנו ‘רק שנייה’ ורק רוצים לבדוק פה איזשהו Concept, רוצים לעשות איזשהו MVP - ואחר כך נכתוב את זה ‘כמו שצריך’” . . . .?(חיים) אז בגדול זה נכון - אבל אני רוצה להדגיש שוב דבר אחד: הבדל בין Business “עסקי” לתשתיות.תשתיות מאוד מאוד קל לכתוב בהתחלהאתה כותב, אם נגיד אתה רוצה שתיהיה לך מערכת Monitoring, אז אתה בונה מערכת Monitoring עם שני Monitor-ים, ולוקח לך חמש דקות לעשות את זהואתה בונה CI/CD, אז זה לדפלט Service אחד - ולוקח לך חמש דקות לעשות את זה.ברגע שהנחת את ה-Concept-ים, זה Streamlined עם תהליך הפיתוח וההתקדמות של החברה.ואם הזנחת אספקט קריטי בתוך תהליכי הפיתוח, יהיה לך מאוד מאוד קשה לתקן את זה.ודברים שאתה לא תרגיש, שהם קצת כמו “לצחצח שיניים” - הם פתאום יהיו הפכו להיות פרויקטים מאוד מאוד גדולים ומאוד מאוד כואבים.אני יכול לתת דוגמה - ב-Service-ים של ה-Java של ה-Backend, יש לנו Service-ים של-Java של Backend, שכאילו תומכים בכל המנועים שלנו.ויש לנו Service-ים שהם יותר Frontend-oriented, שהם קצת סוג של Router-ים של דברים ומכוונים את הדברים של מפתחי Frontend.ל-Service-ים של מפתחי ה-Frontend לא היה מיגרציות אוטומטיות (Migrations) של Database, והם כל פעם בנו כאילו את השאילתות בעצמם.הריצו אותi פה ב-Staging, הריצו אותi ב-Production וכו' וכו'.לכאורה, הם חסכו זמן של לבנות את התשתית הזאת, אבל זה התנקם בהם.בסופו של דבר, להכניס את זה זה היה תהליך כואב - כי כבר אין לך את כל ההיסטוריה של כל הטרנזקציות (Transactions) שעשית על הסכמה של ה-Database.והגעת לאיזשהו מצב שבאיזשהו מצב כבר נשבר ה . . . - אבל אתה החלטת לעשות את זה.אנחנו אף פעם לא סבלנו את זה ואף פעם לא הרגשנו את זה - כי בהתחלה זה היה פשוט לבחור את התשתית, לעשות שאילתת Database אחת, כל פעם להמשיך ככה.ואתה מתקדם ואתה לא מרגיש את זה.בגלל זה אני אומר שזה שאתה תעשה Pivot-ים - אתה לא תעשה Pivot-ים כנראה בתשתית, אלא אם כן עשית  טעויות מהותיות בבחירת ה-Stack הטכנולוגי שלך.(רן) דרך אגב, זה לא בהכרח טעויות - לפעמים שינוי כיוון עסקי . . .(אורי) . . . או התפתחות של ה-Stack הטכנולוגי.(חיים) אבל אין ספק שה-Business כנראה מאוד ישתנה במשך הזמן.לדוגמה, כל הקוד שאני כתבתי - כבר נמחק.לא נשארה שורת-קוד שאני כתבתי בתחילת הדרך.וחגגנו כל פאזה (Phase) כזאת.התשתיות שאני הנחתי בתחילת הדרך עדיין קיימות היום.20:15 אנשים שהקונספט זר להם(רן) אז הפעם אני אחזק את דבריך, ואני אתן דוגמה מהעבודה שלי בחצי השנה האחרונה, באיזשהו מכון מחקר.יש שם הרבה אנשי Machine Learning, זאת אומרת חוקרים - שמעולם בחיים שלהם לא כתבו Unit Testing, אוקיי? “הקונספט זר להם”. הם יודעים מה זה, אבל זה לא חלק מההרגל.אז אמרתי, טוב - אני רוצה עכשיו לייצר איזשהו Template של פרויקט חדש, נגיד ב-Python, אוקיי? ובפרויקט הזה, אני אכתוב רק Unit Test אחד: “2+2=4”, זה הכל. סופר-סופר פשוט, בתור דוגמה לאיך כותבים Unit Test.ביקשתי מכולם להשתמש באותו Template, ופתאום ה-Unit Test-ים פרחו כמו פטריות אחרי הגשם . . . . זאת אומרת, פתאום אתה רואה חוקרים הולכים וכותבים לעצמם Unit Test-ים יפים מאוד, כן? כמובן שהייתה להם את היכולת, אבל היה רק צריך את ה-Push הזה, או את הדוגמה הזאת או את התשתית הזאת, האוטומציה הדי-פשוטה של ה-Test הראשון - ומשם כבר כולם, ככה, עוקבים אחרי הדרך.(אורי) אז אני אגיד משהו - היום, מהנדס חדש שמגיע ל-Outbrain, עושה את ה-Bootcamp - ותוך כמה ימים הוא יודע לייצר Service חדש בכמה לחיצות כפתור. אבל לייצר את הדבר . . .  זאת אומרת, אם אני רוצה לייצר מחר משהו שמייצר Service חדש בכמה לחיצות כפתור, בסטארטאפ חדש, כשה-Service הזה יודע להתחבר לכל ה-Database-ים ויש לו Self-Test ויש לו זה ויש לו זה -  הוא וואחד Undertaking . . . .(חיים) ברור, ולא הייתי נכנס לזה.אבל אני כן אומר, שאם אתה בונה את המערכת שלך ב-Mode של Microservices - אתה לא תעשה את זה.אתה תבנה את השני Microservices, יחסית Hardcoded . . . (אורי) . . .  “תאמין שיהיו לך אלף מפתחים" . . . (חיים) זה אפילו לא זה. אתה בונה את זה בצורה כזאת שאתה מדפלט (Deploy) שני Service-ים.איך תעשה את זה? כנראה הכי “רוק ודבק” - אבל הנחת איזשהו משהו, שאחרי זה אתה יכול להניח איזשהו Vision,  שבסוף תגיע אליו.לדוגמה, אנחנו התחלנו ב-Elastic Beanstalk. אני קצת מצטער שלא התחלנו ב-Kubernetes, כי להתחיל ב-Kubernetes, כמה שזו מערכת מגושמת, כשאתה מתחיל כשזה קטן אז מה קרה?להכניס Kubernetes אחרי זה, זה היה פרויקט שלקח בערך שנהאבל Once שעשינו את זה, פתאום התחלנו לעשות משהו שלא יכולנו לעשות [קודם] - התחלנו להרים סביבות דינמיות בלחיצת כפתור.ל-Production ולא ל-Production, למה שאנחנו רוצים.זה לא משהו שכנראה הייתי משקיע בו בהתחלה - אבל אם הייתי מניח Kubernetes ביום הראשון, יכול להיות שהייתי לאט לאט לוקח את המערכת לשם, ולא הייתי שם לב שזה אפילו קורה.23:19 שחק אותה ערן הראל(רן) חיים, אני חייב “לשחק אותה ערן הראל” נקרא לזה, או כל דמות אחרת שמקשיבה לך ושומעת “Kubernetes“ וקופצים להם הפיוזים . . . .(חיים) דרך אגב - הקשבתי לערן הראל, ובגלל זה לא הכנסתי Kubernetes בתחילת הדרך. . . (רן) . . . אז הוא יבוא ויגיד, וברור שהוא לא בדעת-יחיד בעניין הזה - למה אתה צריך את הסיבוך הזה על ההתחלה? Kubernetes From Day One?! אוקיי, אני מבין שאחר כך החיים יהיו יותר קלים - אבל אתה עושה היום את החיים יותר קשים, כשהמפתחים שלך עדיין גם ככה “נאבקים  ב-Pivot-ים כל שני וחמישי”, ב-Hiring, בגידול של הצוות,  במיליון צרות אחרות . . . בוא תחסוך לעצמך צרה אחת, ובסדר, נכון - תשלם את ה-Technical Debt הזה אחר כך, אבל זה ישתלם לך עשרות מונים.אני לא מדבר על האם Kubernetes זה כלי טוב או לא טוב - אני רק שואל על תזמון של האם באמת אתה מאמין שנכון להכניס, נקרא לזה “Kubernetes מ-Day One”?(חיים) אני לא הייתי אומר “מ-Day One”, אבל אני אומר שככל שדוחים את ההחלטה הזאת לשלב יותר מאוחר, זה לא ליניארי.להזיז תשתית של חברה Mature זה משהו שהוא יחסית קשה, וההכנסה של תשתית בשלב מוקדם היא משהו מאוד מאוד קל.כי זה לא באמת חייב לעבוד עד הסוף . . .(אורי) אז אני פה קצת Devil Advocate . . .(רן) יש פה הרבה שטנים בפודקאסט הזה . . . (אורי) כן . . . ההנחה, שלי לפחות, ברוב ימיי כ-CTO, היא שתמיד אנחנו נחליף תשתיות. למה? זה לא קשור בכלללדרך שבה אנחנו עושים את הארכיטקטורה, אלא פשוט כי העולם מתקדם, כי עולם התשתיות תמיד מתקדם, ותמיד יש תשתית טובה יותר שאנחנו נרצה להתקדם אליה מתישהו, וחברה צריכה להיות מסוגלת להחליף תשתיות.ואני אגיד לך עוד משהו - בשלב ש-Outbrain רצתה לפרק את ה”קובץ קונפיגורציית-רן-תבורי” - כל הקללות בהמשך - היא הייתה מוכנה לשלם את השנה שיקח לחיים ידיד לעשות את זה . . . (רן) “וצוותו!” . . . .(אורי) . . . . וכולם יקללו את רן תבורי . . . .(רן) עכשיו אני מבין מה זה המבט המזוגג הזה בעיניים . . . .(חיים) זה לא היה אני באופן אישי . . . .תראה, זה ברור שאפשר להחליף תשתיות, אבל יש כמה דברים שאתה יודע שאתה תצטרך, בהנחה שאתה יודע - יש לך קצת ניסיון בעולם התוכנה.כנראה שאם אתה חברת SaaS, אתה תרצה שיהיה CI/CD, נכון? כי זה Proven Practice של התעשייה.כנראה שאתה תרצה Monitoring.כנראה שאתה תרצה Logging - ואולי גם איזה Log Shipping לאיזשהו שירות חיצוני . . . כנראה שאתה תרצה מיגרציות אוטומטיות (Automatic Migrations) של ה-Databaseכנראה שאתה תרצה Microservices.כנראה שאתה תרצה עוד כמה דברים . . . .(רן) . . . . אתה תרצה Deployment  אוטומטי  . . . (חיים) . . . אתה תרצה CI/CD, אתה תרצה להיות מסוגל לעשות Spawning לסביבות נוספות  . . . (רן) . . . כן, אתה תרצה יכולת לבנות את ה-Database מאפס, לקחת חלקים קטנים שלו לצורך טסטים . . . .(אורי) אבל כל הדברים האלה - כשאתה אומר “תרצה”, אצלי זה ב”תאמין” . . . (חיים) אבל ה”תאמין” הזה - אם אתה לא בוחר תשתית, שתיאורטית יכולה לבנות את זה או לתמוך בזה, אז אתה כאילו הכנסת איזשהו “עז” לתוך המערכת שלך, שאתה תצטער עליה אחר כך.(רן) עכשיו זו שאלה של דירוג אשראי . . .  כמה אתה הולך לשלם על החוב הזה, שאתה מכניס עכשיו? ומתי אתה רוצה לפרוע אותו? ככל שאתה דוחה את התשלום, מה שחיים אומר זה שאז הריבית דיריבית הולכת וגדלה.(חיים) . . . זה לא “גדלה” - היא גדלה אקספונציאלית . . .(רן)  . . . גדלה אקספונציאלית - אבל אמרתי “דריבית”, דריבית זה ה-Exponent - ואתה צריך להחליט. אז עכשיו, כשהבנת את זה, תחליט האם אתה מוכן לשלם המון אחר כך, או אולי קצת פחות עכשיו - או קרוב לאפס אתמול. אוקיי? אז אני גם מזדהה עם זה.עכשיו, הקושי בדרך כלל, של אנשים שיש להם פחות ניסיון  משל חיים, זה לדעת להעריך את המחיר - וכמובן שזה לא הכי . . . . זאת אומרת, כל חברה עם כוח האדם שלה, כל חברה עם ה-Business שלה, התשתיות משתנות . . .  זאת אומרת, אין פה איזושהי נוסחת-קסם. הדבר היחיד שאני חושב שלא משתנה, זה שהריבית נצברת אקספונציאלית, כמו שאמרת, ושצריך להבין שכל מה שלא תציג היום - אתה תשלם עליו הרבה אחר כך.28:04 חיים בהכחשה עם Latin1(חיים) אני יכול לתת דוגמאות לכל מיני טעויות.הטעות הכי מטופשת, שנראה לי שאני עשיתי באופן אישי - אנחנו עובדים עם MySQL . . .(רן) הנה - אמרת . . . (חיים)  . . . ה-Default היה Latin1 לטבלאות ול-Database.(רן) “להטעין אחד”? . . . (חיים) Latin1 - זה ה-Encoding כאילו . . .  (רן) חיים, לא הייתי מאמין עליך . . . . Latin1.(חיים) ואני זוכר שהסתכלתי וזה היה לי מוזר, אבל אמרתי “אבל מה אכפת לי מזה עכשיו?”(רן) . . . “מי צריך ל-UTF?” . . . (חיים)  . . . “אז נעביר את זה בהמשך ל-UTF” . . . (רן) כן, “notescript אחד קטן וסוגרים עניין” . . . (חיים) כעבור כמה שנים הבנו את חומרת המצב - אנחנו כבר, נראה לי יותר משנה וחצי, מנסים להעביר את כל הטבלאות שלנו ל-UTF, כי ה-Latin1 הזה הוא קטסטרופה בכל פרמטר וסכנה ל-Data Corruption בכל מיני צורות.וכולה הייתי צריך לעשות מיגרציה (Migration) פשוטה ל-Database, כשעוד הייתי יכול.(רן) אז רגע, נעשה גנרליזציה (Generalization) ל-Database-ים, או Data בכלל - מאוד קשה לשנות כל דבר שקשור ב-Data, בין אם זה Database-ים, בין אם זה Pipeline-ים של Data, בין אם זה כל . . .  תמיד תמיד יהיה יותר קשה. ופה כנראה שכדאי לשלם מוקדם, כי שם החוב הולך ותופח בצורה סופר-אקספונציאלית.(אורי) אבל בוא נודה על האמת - גם ה-Data שלך מאוד קשור ל-Business שלך, ל-Business Model, למה שיהיה איתו, וזה...(חיים) נכון, נכון - אבל אתה לא רוצה טעויות של Latin1.בוא נגיד שאנחנו עשינו גם טעויות במידול, כי לא ידענו - לא ידענו את מורכבות הבעיה העסקית שלנו, והיינו צריכים לעשות פרויקטים ענקיים בשביל להחליף את המידול של ה-Data שלנו.בגדול, Level of indirection - שזה הגיוני.אבל לא להתחיל כ-UTF8 - זה סתם דבילי  . . . .(רן) כלומר, אם אתם עובדים ב-Latin1, אתם "חיים בהכחשה” - זה מה שאנחנו אומרים לכם היום.(חיים) כן . . .30:25 מפתחות זרים(רן) אוקיי, עוד כמה דוגמאות? דוגמא צבעונית, יפה . . . (חיים) אז שוב - נחזור רגע לנושא של המיגרציות (Migrations).אני מאוד הייתי גאה בזה ששמנו Flyway, ושכל המיגרציות שלנו אוטומטיות או קרוב בזה.והייתי מאוד גאה בעצמי - עד שדיברתי שוב עם שלומי נוח [388 Remote Work (Coronavirus special) With Shlomi Noach], ואז הבנתי שאנחנו עושים דברים לא כל כך טובים.שאנחנו לא כל כך מסוגלים להתמודד עם טבלאות גדולות. האמת, ידעתי את זה - אבל אם הייתי מדבר עם שלומי על איך צריך לעשות מיגרציות (Migrations), יכול להיות שהייתי בונה תהליך אחר, מוקדם בתהליך הזה, שהיה מאוד עוזר לעבור לסכמות, ששלומי יודע לעשות אותן - ושב-GitHub עשו אותן כמו שצריך.כמו לדוגמה - העובדה שיש לנו Foreign Keys דופקים את כל היכולת של כלים כמו Ghost וכל מיני כלי מיגרציה,  שיודעים להעתיק גם טבלאות תוך כדי, ולא לעשות איזשהו משהו שלא מתאים לטבלאות גדולות - פיזיבילי (Feasible).ועכשיו, לך תעיף את כל ה-Foreign Keys שדאגת לשים בשמחה ובששון . . . (רן) בוא רק נזכיר למי שלא “חי ונושם Database-ים” בעשור האחרון - Foreign Key עוזר לך לעשות ולידציה (Validation), שאם יש לך רשומה עם מפתח שהוא מתייחס לטבלה אחרת, אז זה יהיה קונסיסטנטי (Consistent).זאת אומרת, אותו המפתח יהיה קיים גם בטבלה ההיא - וזה נחמד, זה עוזר, זה סוג של וולידציה, איזשהו Test ל-Database.אבל מה הבעיה כשאתה רוצה לעשות רפליקציה (Replication)?(חיים) . . . שאתה לא באמת יכול להעביר את ה-Data -  כי אין לך את ה-Foreign Keys . . . אתה לא יכול ליצור טבלה נוספת, כאילו, שאליה אתה אמור להעתיק את הסכמה החדשה - כי אין לך את ה-Foreign Keys.(רן) כן, כי הרפליקציה (Replication) כנראה תרוץ באיזשהו Stream - ואז אתה לא יכול פשוט לקחת Snapshot של ה-Data בלי להעביר את זה, כי זה לא באמת רפליקציה. זו “רפליקציית ה-Offline” אולי, אבל זה לא מה שאתה רוצה, אתה רוצה להסטרים (To Stream) את ה-Data. אבל כשאתה מסטרים (Streamlining) את ה-Data, יכולות להיווצר - לשניות בודדות או לאיזושהי תקופה - איזשהן אינקונסיסטנטיות (Inconsistencies), ואתה כנראה מוכן לחיות עם זה, לטובת היכולת באמת לרפלק (Replicate) את ה-Data.אוקיי, אז אתה אומר “Foreign Keys זה Big No-No”? - או שאולי זה קצת...(חיים) . . . .זה בגדול “Big No-No” . . . (רן) אוקיי, אז הלכנו עד הסוף עם זה . . . (חיים) כן.(אורי) כאילו, אם אתה מאמין, שאתה תגדל . . . (חיים) כן.(אורי) ואגב - אגב, מי שמאמין לא מפחד.(רן) מי שלא מפחד - משלם . . . [מי שמאמין,  לא מתעד - חזי לפלאסיאן]32:40 לשבור את ה-Mono-Repo?(חיים) להריץ את כל הטסטים - גם של צוותים אחרים - בכל Build, זה לא Scalable-י.ולכן, אם אין לך סוויטה של טסטים (Tests Suite), של הצוות שלך, שעוזרת לך לדפלט (Deploy) את ה-Microservice שלך, אתה נמצא באיזשהו סוג של מצב, שבסופו של דבר זה יתפוצץ.ושוב, אני חוזר לאותו Framework של End-to-End Tests שהיה מאוד מאוד מוצלח - יותר מדי מוצלח - וגרם לנו לזנוח Component ו-Unit Tests, ולקח לנו הרבה מאוד זמן לתקן את זה.(אורי) זה Practice “שמגיע בחינם” אם מפצלים Repos בין הצוותים?(חיים) דרך אגב, אנחנו רצים ב-Mono-Repo, לפחות כל ה-Service-ים של ה-Backend רצים אצלנו ב-Mono-Repo.יש אנשים ששונאים את זה ומקללים אותי על זה . . . אבל יש לזה גם יתרונות.אנחנו עוד לא הגענו לנקודה ששוברים את ה-Mono-Repo - אבל יש כבר אנשים שמדברים על זה ורוצים את זה.(רן) כן, ברמה טכנולוגית, כאילו, GitHub, GitLab - זה לא חוסם אתכם?(חיים) אנחנו עובדים ב-GitHub, וזה לא חוסם אותנו ב- Mono-Repo של כמה מיליוני שורות Kotlin.ה-IDE - כאילו, יש אנשים שטיפה מתלוננים על זה, אבל רוב הזמן זה בסדראו נסבל, או שהתרגלו . . . אני בטוח שזה יכול להיות יותר טוב.ויש לנו כלים שדואגים, לדוגמה, לעשות אנליזה לבאיזה מקומות נגעו בקוד, בשביל לעשות Triggering ל-Pipeline הנכון, של ה-Service הנכון שהשתנהוכלים שמתריעים על זה, אם מישהו נגע ביותר מ-Service אחד.כי זה בגדול, למעט מקרים קיצוניים - זה לא מצב תקין.(רן) זה מאפשר לך, נגיד, לשנות קוד של ספרייה, ואחר כך לריץ את כל הטסטים שתלויים, Upstream, באותה ספרייה.(חיים) כן.(אורי) אני זוכר את הוויכוח הזה, מ-Outbrain - כשבסופו של דבר, לא יודע, אני הבנתי שזה הופך לסוג של “ויכוח דתי”. אבל כשאתה מפרק אותו, בסוף - כל דרך שיש . . . לכל דרך יש יתרונות וחסרונות, ובסוף תצטרך לבנות כלים שיתגברו על החסרונות בדרך שבחרת. אמרנו לארכיטקטים: “תבחרו דרך, ותבנו את הכלים כדי לפצות על זה”, וזהו.(רן) כן, אתה אומר “בין אם תבחרו Mono או Multi - בכל מקרה נצטרך לבנות כלים מסביב לזה”, אז יאללה, “נטיל מטבע”.34:32 בעיות בזמן, במרחב ועם Conway's law(רן) אוקיי, אנחנו ככה ממש כבר לקראת סיום. יש עוד איזה “סיפור צבעוני” אחד שהיית רוצה לחלוק?(חיים) אני חושב שהדבר אולי הכי מטופש שעשינו - והוא לא כזה דרמטי, אבל הוא עדיין מטופש - זה שבחרנו לשים את ה-Time-zone של ה-Database להיות PST.כי ה-Headquarters ב-Palo Alto, והלקוחות שלנו בארצות הברית.ואין לי מושג למה עשינו את זה - וזה מעצבן ומטריד כל פעם מחדש, כי זה לא הגיוני.זה לא הגיוני מבחינה סיסטמית (System)(רן) כן, אני אגיד לך סוד - כשאני הייתי ב-Google, וזה לפני הרבה מאוד זמן, גם שם עשו את הטעות הזאת . . . . אבל שם אולי רוב העובדים גם חיו בקליפורניה. אבל עדיין, בתור אנשים בישראל זה כאילו, “מה?! WTF?” כאילו, יש לכם . . . “יש UTC, למה שלא תשתמשו בזה? מה נסגר?” אבל כן, מבחינתם, העולם נמצא בקליפורניה - “ושכולם יתיישרו  לפינו”.(חיים) ויש עוד דבר, שלפי דעתי הוא אולי חומר לפרק שלם, אז אני אזכיר אותו רק במילה אחת . . .בעצם כאילו, מה שקורה זה שבגדול יש לנו מוצר אחד - בערך 40 Microservices, אבל שמשרתים מוצר אחד, אספקטים שונים שלו.ויש עוד Level של התייחסות של המוצר הזה, שבו יש סוגים של מוצרים.והרבה פעמים יש לנו Squd-ים Business-יים, שנועדים לקדם סוגים מסוימים של מוצרים - והם נוגעים שוב בכל ה-Service-ים האלה.וזה יוצר לנו איזו מטריצה מאוד מאוד מסובכת, בין Squad-ים ל-Team-יםכשה-Squad-ים מייצגים את הנושא ה-Business-י וה-Team-ים מייצגים את התוכן הטכני.וזה, לפי דעתי, בעיה מאוד מאוד קשה להתמודד איתה.(אורי) גם ב-Outbrain . .  .(חיים) . . . ואנחנו עושים הרבה מאוד מאמצים בשביל להצליח לשמר איזשהו Balance - אבל זה ממש ממש לא פשוט.הזנחה של כל אחד מהכיוונים - זה קטסטרופה.וזה כמו ללכת בין הטיפות - שאתה לא באמת יכול לנצח כאן.(אורי) זו בעיה שהיא בין “ארגונית” ל”תרבותית” - כי השורש של . . . מה קורה עם ה-Service? ה-Service שייך לצוות, והצוות מרגיש המון המון Ownership על ה-Service הזה - ונוצר מצב שבעצם ה-Service-ים . . .  הארכיטקטורה שומרת על חוק Conway, אוקיי? והיא נשמרת ככה עם המבנה הארגוני. ולשבור את זה - זה לשבור.וה-Squad-ים הולכים לפי ה-Business - וזה לא מתיישר, וזו בעיה.(רן) טוב, אז עשית לעצמך Build-up לפרק הבא - אז הישארו איתנו, עם ה-Cliff-hanger הזה, עד שנפתור את כל בעיות עולם התוכנה!38:55 כתוביות(רן) אז תודה רבה, חיים. אולי ככה לפני הסיום קצת על Next? מגייסים? מה יש לנו לספר?(אורי) What’s Next? . . . (חיים) אז כמובן שאנחנו מגייסים - אין תמיד המון משרות פתוחות, כי אנחנו מנסים לשמור על איזשהו Budget ולהגדיל את ה-Capacity ואת הריווחיות של החברה, על בסיס אותו Budget.אבל בתוך ה-Framework הזה, אנחנו עדיין קצת גדלים, וגם לפעמים יש אנשים שעוזבים ואז צריך לחפש אנשים במקומם.ואני מקווה שתנאי השוק יבשילו, ושנוכל להגיע למצב שרצינו ושאנחנו כל כך רוצים להגיע אליו - שזו הנפקה.(רן) מבחינה טכנולוגית, הזכרת קצת. הזכרת MySQL ו-JVM - מה עוד יש לך לספר על זה? Kotlin הזכרת  . . . (חיים) אנחנו בעצם מפתחים את ה-Service-ים של ה-Backend ב-Kotlin, מעל JVM.את הקוד ה-Frontend-י שלנו אנחנו כותבים ב-TypeScript - יש לנו Angular ויש לנו גם React.כשזה מתחלק בין סוגי האפליקציות.ויש לנו גם Stack מאוד מורכב של Data Engineering ושל BIאנחנו עושים הרבה מאוד אנליזות על ה-Data, ויש שם הרבה מאוד מרכיבים שאוספים ועושים אנליזות על כל הדברים.אני חושב שיש כרגע משרה פתוחה של ראש צוות ב-Data Engineering.(רן) אוקיי, ואמרת איפה אתם יושבים?(חיים) אה - והרבה מאוד תוכניות לגבי Machine Learning, כי כל הנושא של LLM הוא מאוד מאוד רלוונטי לעולם של ביטוח.(רן) איפה אתם בארץ? הזכרת?(חיים) אנחנו נמצאים בכפר סבא, ה-Headquarters ב-Palo Alto.יש לנו עוד מרכז ב-Waltham, שזה על יד Boston.אוקיי, טוב - אז תודה חיים! תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 477 של רברס עם פלטפורמה, שהוקלט ב-20 באוגוסט 2024. שלהי הקיץ,  עדיין חופש גדול - ואורי ורן מארחים את מושיקו מחברת upwind לשיחה על Security, חולשות וסיפורי-קרב מעניינים.Photo by DALL-E00:45 מושיקו(רן) אז לפני שנתחיל - מושיקו: קצת היכרות איתך ועל החברה שבה אתה עובד . . . (מושיקו) בשמחה. אז קודם כל - מושיקו, בן 26, עוד מעט 27, אשקלוני במקור.קצת על איך בעצם הגעתי לפה - אז באשקלון יש מגמת מחשבים אחת, ויש שני דברים שאני אוהב לעשות - אחד, זה לפתור בעיות; ושתיים זה שתמיד רציתי לצאת מאיזור-הנוחות, מהפריפריה, לצאת החוצה.וזה מוביל אותי בעצם לשירות הטכנולוגי . . . (אורי)  . . . זה דווקא “להיכנס” . . . . כאילו, מבחינת רוב האנשים, הפריפריה היא “בחוץ”. [חוץ מאסימוב . . .](מושיקו) כן, אז אתה יודע - בתור ילד באשקלון, אתה תמיד חולם לפרוץ את הגבולות, לעשות משהו מיוחד.ואני מאוד אוהב לפתור בעיות, זה אחד הדברים שאני תמיד הכי אהבתי . . .(אורי) נראה לי שאתה האשקלוני השני שמתראיין בפודקאסט . . . . (רן) כן, זהו, אני מנסה להיזכר . . . (אורי) יוסי תגורי. [Summit 2013: How To Fuckup, by Yosi Taguri](רן) לא, היה עוד מישהו, לדעתי . . . אנחנו ניזכר.(מושיקו) כן, אנחנו בונים מותג, לגמרי.אז “מתגלגל” - מגיע ליחידה טכנולוגית, מגיע לממר”מ, בצד של חטיבת-ההגנה, בעצם “איש סייבר”.קורס יחסית חדש, לא מאוד מוכר - בעיקר לא בפריפריה.מתחיל כ”רברסר” (Reverser) - Malware Analysis, עולמות של מחקר-איומים, מחקר-פוגעניםמה התוקף עושה? למה הוא עושה?עוסק ב-Low-level בעיקר - זה רוב השירות הראשוני שלי.(רן) רברס - לא עם פלטפורמה, במקרה הזה . . . (מושיקו) אמת, כן.(אורי) אבל מרפרר, מרפרר . . . (מושיקו) כן, בעצם זה Reverse Engineering - לקחת יכולת, איזה Capability טכנולוגי, ולהנדס אותו לאחור.להבין, בעצם, מי שעשה - למה עשה? איך עשה?בעצם מה המשמעות של הדבר הזה.ומשם אני מתגלגל . . . אני שואל את עצמי שאלה של “איך אני ניהיה ראש צוות? איך אני יוצר השפעה בארגון?”בארגון סייבר גדול - ממר”מ בעצם זה היום ארגון של כמעט 3,000 איש, עם יחידות התוכנה.רוצה לייצר השפעה - יוצא לקצונה, עושה מספר תפקידי ראש-צוות R&D, בעיקר בעולמות הסייבר, פיתוחי סייבר הגנתיים.ובשנת 2019 מתמנה להיות ראש צוות מחקר “הגנה בענן” הראשון בצה”ל.בעצם, פותחים משהו חדש בצה”ל - “ענן ציבורי!”.אנחנו רוצים להיות חלק בדבר הזה, יש לנו ענן On-Prem מאוד מאוד גדול.ואני נכנס ככה פעם ראשונה לעולם של הגנה בענן - מקים צוות, מקים הכל מאפס, ומתחילים להיכנס למחקר,משם מתגלגל - בגיל 23 ניהיה ראש-מדור בממר”מ45 אנשים, בעצם לנהל את כל ה-Security Pipeline “בצבא הירוק”.45 אנשים - 200 מיליון Endpoints בערך . . . Endpoints כ-"IP-יים”  נקרא להם, לא Endpoints Desktop.ושם בעצם אני נחשף להמון המון אירועים, להמון המון תקיפות - ותוך כדי אני בעצם מתאהב בנושא של סייבר-הגנתי, סייבר-מחקרי.ובעצם מפתח איזו נישה של מה הקשר בין הקוד שכתבתי למוצא האתני שלי - שזה בעצם מה שנדבר עליו, אני מניח, גם היום.מחליט להשתחרר בהפתעה, לפני השביעי לעשירי. פוגש את עמירם שחר - בעצם נפגשים ב-upwind.מה שמביא אותי למקום שאני נמצא בו היום, כראש קבוצת המחקר.כשב-upwind - אנחנו חברת הגנה בענן: מוצר פלטפורמה, CNAAP, Cloud-Native Application Protection Platform, כמו שאוהבים להרבות באותיות באנגלית . . .(רן) קצרצר . . . (מושיקו) כן, “קצר וקולע” . . . בגדול, נותנים הגנה הוליסטית על שכבת הענן.חברות בורסאיות, דברים יחסית גדולים, רציניים.ונותנים הגנה בעצם בפרספקטיבה שהיא קצת שונה - הרי בסוף, רוב המאזינים שלנו ישמעו ויגידו “אז מה זה שונה מ-WIZ ו-Orca?” ועוד מתחרים כאלו ואחרים.ובעצם, upwind הביאה גישה לפני שנתיים, שאומרת “אני מסתכל מה-Shift-Right”.מה שהיינו רגילים זה ל-Shift-Left - בעצם “מה-Runtime אחורה" לסביבת הענן.זאת אומרת, אני בא למצב נתון, מצב קיים - ואני אומר “קורה פה משהו, ואיך קרה הדבר הזה?”ולא “הולך לקרות פה משהו - ואולי הוא יקרה ואולי לא”.ואז אנחנו מאפשרים . . . .(רן) “קורה פה משהו” במובן של “התקפה כלשהי”?(מושיקו) נכון, בדיוק - בין אם זו התקפה או מיסקונפיגורציה (Misconfiguration) - אני חי במצב נתון, שאומר “הנה Production - ככה הוא נראה, ככה הוא מתנהג”.ובעצם הפאונדרים (Founders) שלנו, שבאו מ-Spot.io [גיקונומי 319 - עמירם שחר חוסך כסף בענן] מביאים גישה חדשה לעולם ה-Security, שאומרת “רגע -איך עושים שילוב ידיים בין ה-SecOps ל-DevOps?”איך בעצם מקדמים ארגון שהולך יד ביד - ולא ראש בראש.וזה בעצם מה ש-upwind באה לפתור.(רן) אוקיי, נדבר אולי עוד קצת בסוף על upwind אבל אולי כמה מילים בכל אופן - כמה עובדים היום בחברה, פחות או יותר? איפה נמצאים?(מושיקו) אז היום אנחנו מונים כ-150 עובדים, נמצאים בקו רכבת בתל אביב, Midtown.חברה ב-Hyper-growth, משקיעות בנו Cyberstarts ו-Greylock, כל מיני קרנות מאוד גדולות, קרן Craft גם.05:15 התקפות ב-Live, חמאס ב-CI/CD ושיטויי-AI(רן) אז יצא לך, פה ושם, לראות כמה התקפות - בין אם זה תוך כדי, אולי קצת אחרי. אולי נדבר על כמה מהן, לפני שככה נכליל - מה אנחנו עושים כשאנחנו רואים דברים כאלה?(מושיקו) אז לראות זה עניין של מזל - אתה יכול לעבור שירות שלם של שמונה שנים ולא לראות דבר, או לעבור שנה האחרונה של שירות ולראות המון - וזה מה שקרה לי.את הסיפור שלנו אנחנו מתחילים בעצם בסוף - אני מקבל הודעת WhatsApp מחבר: “אחי, תעזור לי רגע, יש פה כלי שאני לא יודע אם זה כלי או לא - אבל זה קפץ ב-Antivirus, סביבת Production.”אני לא רוצה להדליק את כולם - אתם מכירים אנשי SecOps, מדליקים את כל הארגון, נועלים את הדלתות, באלגן . . . . - “תבדוק את זה”.אני Reverser מהולל בעברי - “תביא!”.יושב במחשב בבית, פותח, פורק את הכלי - בעצם מרוורס (Reverse-Engineer) אותו - ואומר לו “תקשיב אחי, יש פה כלי ששוקל Executable 6Kb, עם URL Reference לעוד Stage, שבעצם התוקף יכול להביא את שאר ה-Binary שלו מחוץ לארגון”. אמרתי לו . . . והקימפול, בעצם תהליך הקומפילציה (Compile) - הוא השאיר את ה-PDB, בעצם Header כזה, שמעיד על התהליך -  מי קימפל (Compile).ורשום שם “כונן D של מוחמד” . . . .(רן) כלומר, אני אתרגם שנייה - אז אתה מקבל משהו בשפת מכונה כלשהי, של איזושהי פלטפורמה - Windows, Linux, whatever - עושה איזו די-קומפילציה (Decompile) כלשהי, ואתה מגלה שיש שם איזשהו לינק לכונן D של מוחמד כלשהו.(מושיקו) בדיוק, ו...(רן) . . . והוא בטעות השאיר את ה-PDB, אז זה מה שעזר לך - ה-PDB זה קובץ Debug - אז זה מה שעזר לך לגלות את זה.(מושיקו) . . . ואז בעצם אנחנו גם מקבלים את ה-Sense של מי הבן אדם שקימפל את זה - כי אפשר בעצם להבין לפי איכות הקובץ.(אורי) אגב, “מוחמד” זה אחד השמות הנפוצים בעולם, כן? . . .  להצביע על מוחמד ספציפי, זה . . . (מושיקו) כשזה מגיע מהשיוך הארגוני שאני השתייכתי אליו, אז זה מתבצע קצת בצורה פחות גלובאלית, מן הסתם . . .ואז בעצם אני אומר לו “תקשיב אחי - אין שום סיכוי בעולם שזו לא תקיפה” - ומאותו רגע בעצם מתחילה “יממת-זהב”.בעולמות של תקיפה, בעצם בעולמות ה-Response, אנחנו מחלקים את הזמן ל”יממות זהב" - ו-72 השעות הראשונות, שהן 72 שעות שבהן למגן יש באמת סיכוי לבצע איזושהי פעולה משמעותית בתהליך התקיפה.ואז אנחנו בעצם מגיעים לארגון . . .(אורי) זה בעצם תלוי מאיזה רגע תפסת את זה - כאילו, יכול להיות שתפסת את זה ביממה ה-96 . . .(מושיקו) נכון. אז בעצם, כשאני מסתכל על תהליך הספירה לאחור, אני מסתכל עליו בפרספקטיבה של Response ו-Mitigation.כלומר, מהרגע שאני הבנתי שקרה משהו - שיכול להיות גם לאחר שכל המידע יצא, והארגון פוסט-התקיפה, אבל בעצם...(רן) זאת אומרת, אם גילית את זה בזמן, אז יש לך כנראה 72 שעות. אם גילית את זה מאוחר מדי, אז זה מראש Game-over.(אורי) אבל השעון מבחינתך מתחיל לרוץ כשגילית?(מושיקו) נכון, כי בעצם יש לי מספר צוותים - אני ניהלתי 45 אנשים, היו לי מספר צוותי תגובה, אני יכול להחזיק כל צוות מספר שעות . . . יש פה ממש תהליך אופרטיבי שלם, של איך מנהלים צוותים, איך משמרים דופק, איך מנהלים רגע לוחמה מבצעית.ברמת ה”מתי מכניסים את הפיצות לחדר, כדי לשמור עוד שעה של משמרת” . . . .ובעצם, אנחנו מתחילים להתגלגל לתוך נוהל-קרב - מכניסים אנשים לחדר, נכנסים לרשת, ואנחנו מתחילים בעצם לפרוש את התקיפה לאחור, מה שנקרא תהליך ה-Lateral Movement, פשוט מהצד השני, של המגן.(רן) “לפרוש לאחור” - כלומר, להבין מה היו הצעדים שהביאו אותנו לאותו כונן D ו-Executable PDB? (מושיקו) נכון. בעצם, מגיע עם איזה כלי, עם איזה שרת בתוך רשת Production, שהיא מנוהלת על ידינו, כיחידה - ואנחנו צריכים רגע להבין איך הכלים בעצם נכנסו לתוך הרשת שלנו.(אורי) זאת אומרת, מה הדרך שה-Executable הזה עבר, כדי להגיע...(מושיקו) בדיוק, בדיוק.(רן) כן,  רק שאתה עושה את זה “ברוורס” - זאת אומרת, אתה יודע את הסוף, ואתה מנסה להבין איך זה התחיל.(מושיקו)  . . . וזו בדיוק הבעיה הכי גדולה . . .(אורי) כמו, סליחה על ההשוואה - לפני כמה ימים התפוצץ מחבל בתל אביב, והדרך שמצאו זה שהלכו אחורה למצלמות אבטחה. בדומה לזה?(מושיקו) אז זו הדוגמה - לא יכולתי לתת דוגמה יותר טובה למה שזה.בעצם, זו הדוגמה הכי מדויקת שאני חושב עליה.סייבר זה מרחב-לחימה - וככה אני תופס אותו.בעצם מתנהל פה קרב בין גוף שהוא מנהל מלחמת הגנה ומלחמת התקפה - יש שני גופים, אחד מול השני.ובעצם התהליך שאנחנו מגיעים - אנחנו מגיעים בעצם ל”זירת-הפיגוע" או “זירת-הפשע” ומנסים להתחקות חזרה לאחור.אז אנחנו בעצם מגיעים לאותו Executable, מבינים רגע מי שם אותו על השרת - מבינים שזה אחד מהקבלני-תוכנה שהשתמשנו בהם לטובת פיתוח מערכת די מבצעית ביחידה.ואנחנו בעצם מתחילים לאתר את אותו כלי במספר המקומות - ופה המאמץ מתפצל לשניים:המאמץ - נקרא לזה “המאמץ התקשורתי”, זאת אומרת איתור התקשורת, איתור התנועה של התוקף ברשת.והמאמץ הפרימתי-תוכנתי, שאומר “זה הכלי - מה הוא יודע לעשות? איך הוא מתנהג? מי כתב אותו?” זאת אומרת, “מוחמד” זה אחלה - אבל “מוחמד” זה השם הכי נפוץ בעולם, דיברנו על זה . . . . אז איך אני  מאתר את הבן אדם הזה? איך אני יודע למי הוא שייך בסוף?מי שהגיע לפה, רצה מאוד להגיע לפה - הוא לא הגיע סתם.(רן) נקרא לזה “פרופיל פסיכולוגי”.(מושיקו) בדיוק, בדיוק. אז בעצם, הצוותים מתפצלים לשתייםהצוות התקשורתי בעצם מבצע את הניתוח לאחור: מגיע לשרתים, מבצע מיפוי-רשתי נורא נורא איכותיואנחנו בעצם נגיע תיכף ל-Victim Number One, נקרא לו - “נדבק מספר אחת”.אבל קודם נדבר שנייה על הכלי . . . (רן) אבל בואו שנייה נעצור פה - Executable ב-PDB. איך אתה בכלל מתחיל ללכת אחורה מזה? כאילו, איך אתה . . . יש לך מושג מאיפה זה הגיע?(אורי) אתה יודע איפה מצאת אותו . . . (רן) אוקיי - מצאת אותו על איזשהו מחשב, אולי יש שניים. אבל איך אתה הולך אחורה משם? כאילו מה - איזה “חץ” יש לך אחורה?(מושיקו) אז קודם כל, אנחנו אנשי מערכת-ההפעלה. זה האלף-בית שלנו.אנחנו חיים את מערכת ההפעלה, אנחנו יודעים לזהות ממש “שריטות קטנות” ברמת מערכת ההפעלה.מ-Port-ים שנפתחים, שרתי DNS שהוא בטעות תשאל אותם, כתובות שהוא פנה אליהן, מה ה-One Drive-ים שה-Windows שלו מזהה כ-One Drive-ים “שלו”, כל User שהתחבר ובאיזו שעה . . . אנחנו בעצם בונים איזה “סיפור” - ממש תהליך מז”פ-י, אפשר לדמות את זה, תהליך מז”פ.(רן) אז “אוסף טביעות אצבע”, בודק אם “החלון הוסט” - ובסוף אתה אומר “אוקיי, כנראה שהוא הגיע מפה”, ומשם אתה ממשיך עוד שלב אחד אחורה.(מושיקו) בדיוק - ואנחנו גם בעצם, כמו שאמרתי -מחלקים את המאמץ.כחלק מבניית הפרופיל סביב אותו כלי תקיפה, אני מבין גם מה “הציפיות שלי”.אנחנו, בתור גוף בטחוני,  מכילים המון המון מידע מודיעיני סביב אותם גופים.ואז אני בעצם יודע שיש פה שיוך; אני לוקח את אותו שיוך שאומר - רגע, סתם, “זה כלי שמושיקו כתב”.לוקח את אותו כלי, נותן אותו בעצם, אומר “אוקיי, מושיקו השתמש בזה על רן” -  זאת אומרת שיש פה שיוך מזרח-תיכוני, יש פה שיוך של תוקף, שבסופו של דבר מתגלה כחמאס.ואנחנו אומרים “אוקיי, אלו היכולות, זה הבן אדם, זו הסביבה, זאת המטרה - בוא נבנה את הפרופיל”.ומפה אנחנו בעצם יוצאים למאמץ אחד, אחרי שהבנו את הכלי  - שאומר מהו היעד שהתוקף ניסה להשיג?שמפה אנחנו בעצם ממש מנהלים “קרב נכסים” - מה הנכס שהוא רוצה להחזיק? מה הנכס שהוא לא רוצה להחזיק? מה הבעיות בסביבה? מה הנתיב החדירה? . . . (רן) . . . כש”נכס” זה יכול להיות Database-ים, תחנות-קצה של עובדים . . . (מושיקו) בדיוק. אז במקרה שלנו, היה מדובר בסביבה מבצעית, Production - בעיקר שרתים, ליבות מבצעיות . . . ושרת CI/CD - “חצוף", נקרא לו - שמחובר לסביבת חברת-התוכנה, אותו בית-תוכנה, שממנו “מתחילה המסיבה”.עכשיו, פה צריך להבין שבין תוקף לתוקף, יש “תהום של ידע”.בעצם, התוקף שאנחנו התמודדנו פה, זה הגוף-תקיפה המשוקם של חמאס - אפשר לקרוא באינטרנט.סביב התקיפות הקינטיות, הפיזיות של צה”ל על גופי הסייבר של חמאס - פיזית בתוך עזה - מה שמצריך אותם כל כמה שנים לחדש את מצבת כוח האדם . . . .ובעצם מדובר בגוף תקיפה די חדש.אותה מטרה - מטרה שיודעים שחמאס מתרגט (Targets) מספר פעמים, ואנחנו בעצם מזהים את נתיב החדירה ובונים פרופיל-רשתי בתוך הרשת שלנו.ופה אני רגע צריך לחלק את המאמץ - יש מאמץ של התוקף, שבגדול זה נקרא “מאמץ שיטוי” זה נקרא בעולמות הביון - שבו תוקף בעצם מנהל ממש “שיחה קולחת" עם הנתקףממש מנהל איתו "חוויית לקוח” - מדבר איתו, שולח לו תמונות, מתכתב איתו . . . “תוריד את זה, תעשה את זה” . . . ואז יש שמונה חודשים של תקיפה - שהתוקף שלנו עושה על אותו מפתח בבית התוכנהמדביק את המחשב שלו, מדביק את הארגון, מדביק עוד חמישה Enterprise-ים ישראלים, מאוד מאוד גדולים, באותה תקיפה.והם מגיע אלינו, לשרתי ה-CI/CD.ופה המזל שלנו שיחק לטובתנו - שמדובר בחמאס.(רן) בוא נבין, זאת אומרת - מצאו איזשהו בן אדם שעובד בחברת פיתוח תוכנה כלשהי, שבצבא, כמו גם בחברות אחרות, השתמשו בתוכנה שלהם. הוא - התוקף - עשה סוג של Social Engineering, כלומר התחזה למישהו או למישהי, ואמר “בוא תוריד את התמונות, בוא נדבר, בוא תוריד את התוכנה הזאת, תתקין אצלך ונוכל לדבר” - וככה הצליח לחדור אליו, וממנו הצליח לחדור הלאה.(מושיקו) לגמרי. ואחד הדברים הכי יפים שראינו פה בתקיפה - “יפים” זה מושג שאפשר להתווכח עליו . . . - זה שבעצם יש פה שיטוי בתצורת AI.מתנהלת שיחה מלאה בעברית - פעם הראשונה שאנחנו רואים את זה - שיחה בעברית-צחה לחלוטין, שקשה לקרוא ולהבין שזה לא בן אדם - אל מול אותו עובד.זאת אומרת, ממש משטים אותו (בו) במשך 4-5 חודשים.הבנאדם עובר שיטוי שיטתי, של הודעות “בוקר טוב”, “ערב טוב”, “שלח לי תמונות” . . . .(רן) אני מניח שמי שכתב את הטקסטים בעברית - זה AI, או תרגום כלשהו . . .(מושיקו) אז לאור ההיכרות המודיעינית שלנו - כן.זאת אומרת, אנחנו מבינים רגע את היכולת של הארגון - ואנחנו לא מכירים יכולת של עברית כשפת-אם.ואנחנו מניחים שזאת הסיבה בעצם, כולל התמונות שאנחנו רואים, כ-Artifact, על אותו נתקף.וממנו מתחיל תהליך השיטוי - בעצם מתקינים עליו כלי RAT, כלי ריגול בעצם, שמאפשר הרצת קוד מרחוק.ובאמת, כמו שאמרתי - המזל משחק לטובתנו, שמדובר בגוף שלא מבין תשתיות, לא מבין אפליקציה, ולא מבין תהליכים ארגוניים.[טוב, זה מתאר גם לא מעט ארגונים לגיטמיים לכאורה . . . ](רן) כלומר, התוקף.(מושיקו) התוקף, נכון. התוקף לא מבין.ולמה זה מזל? כי הוא מבין שהוא יכול להתקדם בין מחשב למחשב רק על בסיס Username ו-Password.זאת אומרת, ההתקדמות הכי בסיסית, שכל ילד בכיתה ג' מחשב יודע - שמחשב צריך להשתמש בסיסמה.אז בעצם אנחנו רואים שלאורך זמן, הם כן מטילים את הכלים, את כלי-הריגול שלהם, הרוגלהאבל הם כן מתמשים בסיסמא ושם-משתמש בשביל לנוע ברשת - לא שימוש באקספלויטציה (Exploitation) מתקדמת . . .(רן) כן, היו יכולים לעשות את זה אוטומטית, יותר מהר - אם היו להם יכולות.(מושיקו) בדיוק. ממש רגע, חוסר הבנה טכנולוגי לחלוטין.הם מגיעים אלינו לתוך שרת, שהוא Jump-Server נורא נורא חזק בתוך הארגוןאחרי שהם בעצם משיגים את ה-CI/CD, משיגים גם את שרת ה-Jump-Server.(רן) Jump-Server - תסביר . . . (מושיקו) אז בעצם, Jump-Server זו טכנולוגיה שנהוגה ל-Trust בין ארגונים, או לעבודה מהבית.שאיתה בעצם, אותו עובד עם מחשב אישי יכול להתחבר לשרת-מרוחק ולנהל את הארגון ממנו.(רן) אוקיי, סוג של Gateway, בעברית צחה.(מושיקו) בגדול, כן. לגמרי.(אורי) מעיין VPN כזה? או . . . (מושיקו) אז VPN זה קצת גדול על מה שהיה שמה . . . “שרת מכובד”, עם איזה Firewall, לא חדש.(רן) כן, Bastion לפעמים קוראים לדבר הזה.(מושיקו) כן, Bastion זה גם גדול על מה שהיה שמה . . .אבל אני באמת אפרגן להם ואגיד ש-”Bastion” זו באמת מילה טובה.(אורי) כשאתה מדבר על הארגון - זה על הארגון הצבאי או על הקבלן?(מושיקו) זאת אומרת, יש פה “לחיצת-יד” בין הקבלן לגוף הצבאי.ופה, רגע, באמת יש טיפ נורא נורא חשוב לגופי-תוכנה וגופים שמנהלים פרויקטים נורא גדולים - שהם באינטגרציה עם ספקי-תוכנה.ה-Handshake חייב להיות מאוד הרמטי - ופה ה-Handshake לא היה הרמטיהחוזים לא היו חזקים מדי, ההתנהלות מול הספק לא הייתה מוגדרת מדי . . . וכל זה יצר המון בעיות אבטחה, שבעצם הצליחו להוביל לתקיפה הזאת.(אורי) אנחנו לא נישן בשקט אחרי מה שאתה מספר . . . .(מושיקו) אני כבר הרבה זמן לא ישן בשקט . . .  לאחרונה חזרתי, אחרי תקופה ארוכה, אז אני מרגיש בנוח להגיד שיש לנו אנשים מאוד טובים בכל מקום, זו קודם כל נקודה שצריך לזכור אותה.אז אם רגע נעשה “קפיצה לאחור" - בעצם, מגיע אותו תוקף, מגיע לאותו שרת, המון משתמשים נורא חזקים.אבל הוא לא מבין את זה - הוא לא יודע להשתמש ביכולת הזאת.הוא יושב על תהליך ה-CI/CD - הוא יכול להזריק קוד, כמו במקרה SolarWinds המוכר בתעשייה.יכול לעשות מה שהוא רוצה - אבל פשוט אין לו את ההבנה של על מה הוא יושב.ולאורך חודשים רבים הוא בעצם זז בתוך הרשת, ממשתמש למשתמש - וקורה פה משהו מעניין. שני דברים מעניינים, למען האמת . . . הוא ידע להשתמש בחולשות-לוגיות. זאת אומרת, אם יש, לצורך העניין, בעיית-הגדרה, הוא לפעמים ידע להשתמש בה.והוא מכיר בזה שיש מאמרים בקהילה - זאת אומרת, הוא “חי בקהילת-הסייבר”, הוא לא מנותק יותר.והדבר הנוסף - שהוא ידע לעבוד Cross-Platform.חוויה מעניינת בטירוף - זאת אומרת, יש פה תוקף שלא יודע לנהל תקיפת Domain, או תקיפת-רשת רגילה, שזה א'-ב' של כל קורס Ethical-Hackingאבל אשכרה יודע לנהל ארבע גרסאות ולהוריד גרסאות תוך כדי - הוא מנהל תהליך CI/CD של כלי-תקיפה. סופר מרגש . . . (רן) יש לו Continuous Deployment לכלי-תקיפה שלו . . . (מושיקו) כן. Bandwidth נמוך, אבל כן - CI/CD נהדר.והוא משתמש בטכניקות של חבריו מחיזבאללה ואיראן - בעצם מערך Polonium המשוייך לחיזבאללה, ומערך 42, שאני מקווה שנדבר עליו, מאיראן.בעצם, הוא ממש משתמש בטכניקות שלהם - בשבירות הלוגיות שהם משתמשים בהן.ואם רגע נפרט יותר לעומק - התוקף, מזה שאנחנו ארגון Enterprise גדולמשתמשים ב-Wordמי שמשתמש ב-Word משתמש ב-365משתמש ב-365 משתמש ב-FQDN-ים סופר-מתירניים של Microsoft, שמאפשרים שימוש, בגדול, בכל פלטפורמת ה-365מה שאנחנו לא היינו צריכים מסביבת-השרתים - מה שאיפשר לו בעצם לעבוד מול OneDrive בצורה חופשית  . . . .זאת אומרת, Once שהוא השיג את הנגישות לסביבה שלי, הוא אשכרה המנהל מבצע והורדת-גרסא דרך ה-OneDrive הפרטי שלושנקרא, כאילו, “live.one.drive”, משהו כזה . . . . שזו אשכרה כתובת פרטית.(רן) כלומר, URL-ים של OneDrive, אמרת של FQDN, שזה Fully Qualified Domain Name, שהם של Microsoft, ולמעשה משרתים קהל מאוד גדול של לקוחות - ואין שם סגמנטציה (Segmentation) מבחינת אבטחה מספיק חזקה . . . . אז למעשה אפשר, עם קצת הבנה, להעביר מידע מ-Drive אחד ל-Drive אחר, אחרי שהצלחת לעשות קצת פריצה. כן, זאת אומרת, זה לא...(מושיקו) לגמרי - והתוקף מבין את זה, והוא מבין שאנחנו פגיעים לבעיה-הלוגית הזאתזאת אומרת, זו חולשה-הלוגית שהיא לא כל כך גדולה, אבל היא עדיין מאפשרת לו תנועה הלוך-חזור בצורה מדהימה.ויותר מזה - הוא מבין שרכיב ה-Firewall שלנו, ספציפית מדגם 40 בגרסאות 6 ו-7, פגיע לחולשה-לוגית, שאומרת, “אם אני מעביר פרוטוקול מוצפן . . . “ סליחה, אם אני מעביר בחוק מוצפן תעבורה לא מוצפנת - זה עדיין עובר.מה שאפשר לו בעצם להעביר תעבורה מהסוג שהוא רצה להעביר - על גבי חוקים פתוחים שלנו.זאת אומרת, בעצם, אנחנו הגדרנו תקשורת שהיא ולידית (Valid) . . . (רן) זאת אומרת שה-Firewall לא יבדוק את זה, כי הוא מניח שזה מוצפן - אז הוא לא יסתכל, לא יעשה Packet-Inspection, לא “יסתכל פנימה” לתוך הפרוטוקול וינסה להבין מה קורה שם. אבל למעשה זה לא מוצפן - הוא פשוט מעביר “Free Text“ . . . (מושיקו) נכון, ואז בעצם התוקף מצליח לעשות הרבה דברים שהוא לא יכול היה לעשות, אילו הוא היה צריך לעמוד בסטנדרט של פרוטוקולים ודברים כאלה.הוא גם לא יודע לנהל בעצם תהליכים של שמירה ושל קונפיגורציה (Config) - אלו דברים שהוא לא ידע לעבוד איתם.אנחנו רואים שכל פעם שהוא מוריד גרסא של הכלי, הוא אשכרה משנה את נתיב-ההורדה שלו, כי הוא לא יודע לנהל את זה בצורה שהיא קצת יותר דינמית, באופן נורא מביך.מה שכן - מדובר בגוף שהוא נורא אסרטיבי: הוא יודע מה הוא רוצה, הוא נורא נורא אגרסיבי, הוא לא מפחד  “להתלכלך”.מה הכוונה ב”להתלכלך”? הוא עושה צעדים נורא לא שקטים, הוא “מרסס”, הוא נוגע ממש בנפגעים, הוא “חי איתם במקביל”, באותו Session.ומגיעים לנו לשרת ה-Database, ששם אנחנו בעצם - בתוך “יממת-הזהב", בתוך ה-72 שעות, 24 שעות-זהב - מבינים ש”אכלנו אותה”.אנחנו יודעים, כי חטפנו - יודעים מה הנזק, יושבים איתו על אותו שרת Database מבצעי, ואומרים “אוקיי, חוסמים או לא חוסמים?”יש פה מערכת מבצעית - מורידים או לא מורידים?וזו הדילמה מספר-אחת של ה-CISO בכל ארגוןהאם אני “מפסיד Revenue” - במקרה שלי זו יכולת מבצעית כלשהי.או האם אני רגע “הורג את התוקף”, ו”נותן תחושה טובה לבורסה".ופה רגע - מלחמה.במקרה הזה, לצערי, הפסדנו. כן היה דלף.למזלנו, עוד פעם - תוקף שלא מבין התנהלות ארגונית, מדליף Database מוצפן, בצורה חלקית.מקבל Corruption, ה-Database בגדול נשבר.והפסד לא נעים, הפסד צורם - והיינו צריכים ללכת הביתה אחר כך.22:22 דילמות, נזק והערכת סיכויים(רן) כן . . . אז אתה אומר, בוא רגע “נחייה את הדילמה”: אתה אומר שהבנתם מה הוא השיג - ועכשיו, האם להשבית את כל המערכת, שזו מערכת מבצעית ומשהו שיכול לפגוע בפעילות הצה”לית היומיומית, או לחכות רגע,ולהבין - אולי יש דרך אחרת לעקוף את זה, אולי הוא לא בדיוק השיג את מה שהוא רוצה, ויש לנו מזל, “הכל בסדר”.בסוף החלטתם “לגרוט” את זה. אוקיי? להוריד הכל.(מושיקו) אז כן. בעצם, אנחנו רואים אותו - תפסנו אותו “בזמן אמת”, על אותו השרת.צריך להגיד - זה תהליך תומך-לחימה, לא תהליך מבצעי, מה שאפשר לנו יותר מרחב תמרון.זאת אומרת, ב-Business השוטף של העסק - אבל לא ב-”Core Business” שלו, לא משהו שהוא “Zero Tolerance”.ואנחנו מחליטים בעצם להחליט על “ניתוקים כבדים” - ניתוקים של רכיבים, ניתוקים של אנשים, איפוסים כבדים, רגולציות נורא נורא כבדות.כי אנחנו מבינים שיש פה אזור שהיינו לא טובים בו - ואנחנו צריכים עכשיו לבוא “לתת בראש”.וב-Security, התוקף יכול לממש כל כך הרבה פרצות, כל כך הרבה יש Backdoor-ים בעצם, שזה משחק כמעט אבוד.אבל אם אתה מספיק יסודי, מספיק חזק - יש סיכוי לנצח.(אורי)  . . . או שהוא יעבור למטרה אחרת - שזה הרבה מההיגיון של Security: אתה לא צריך להיות הכי טוב, אתה צריך להיות יותר טוב מהשכן שלך  . . . (מושיקו) לגמרי, כן.אז פה בעצם נותרו עוד חמישה “שכנים” נורא גדולים בישראל, שהיו צריכים להתמודד עם זה אחרינו . . . וזה תלוי במזל, כן.(אורי) אבל מה שאתה מתאר זה בעצם so-called “תוקף נאיבי”, שהצליח להגיע עמוק. ובוא נאמר - אתם יודעים דרך איזה פרצות, ואם הוא היה טיפה פחות נאיבי, הוא היה יכול להיכנס. וזה מצריך “Overall” של כל שיטת ההגנה.(מושיקו) נכון. אז אנחנו בעצם מתחילים תהליך של “זיכוי-קוד” - באיזשהו שלב, התחלנו לקחת את כל ה-Codebase של כל הפרויקטים שלנו - בין אם הפרויקטים שפותחו אצלנו או אצל הספק, בסוף זה תהליך ה-CI/CD אחוד.עוברים על הקוד, סורקים שורה-שורה ["!Comb the Desert”]מחפשים שבירות לוגיות, מחפשים בעיות, מחפשים פרצות, מחפשים התנהגות שהיא חריגה ברמת-הקוד . . .זאת אומרת, זה משהו שקרה - לא הסרנו מזה אחריות.כן, תעדפנו את זה נמוך - זאת אומרת, במאמץ המלחמתי, ככה אנחנו תופסים אותו, כמאמץ-מלחמה, אנחנו בעצם מתעדפים רגע “איפה אנחנו שמים את השקל?”האם נשים אותו רגע בציר התקשורתי הישיר, שאותו תוקף מנהלהוא ממש מנהל עלינו CMD - יש לו Shell ו-Terminal ב-Live, פתוח מישראל לטורקיה.זה קורה תוך כדי שרשור של מספר VPN-ים ו-Proxy-ים - אבל הוא ממש מנהל איתנו קשר רציף, אפילו יותר טוב מ-WhatsApp . . . ואנחנו מחליטים להשקיע את המאמץ שם.25:08 ה-AI אוכל את העולם (וגם תוקף אותו)(רן) אז יש לך עוד כמה סיפורים . . . . בשיחת-הכנה שדיברנו, היו לך גם כמה סיפורים מעניינים אחרים. קודם כל, סיפרת את זה מצוין - אבל רציתי קצת להכליל.הזכרת, נגיד, שהתוקף השתמש ככל הנראה ב-AI, כדי לג'נרט (Generate) את הטקסטים בעברית, כדי להגיע בסופו של דבר לנקודת-התורפה, וכמו שאנחנו יודעים, “AI אוכל את העולם”.בוא עכשיו נסתכל נקודת-הראות של התוקף, ותוליך אותי קצת דרך וקטורי-תקיפה חדשים שאולי יצא לך להיתקל בהם, או שאולי מדוברים בתעשייה - שהיום הם אפשרים באמצעות AI וחברים, ופעם לא. [להרחבה - הפרק המופתי של Radiolab על Darkode](מושיקו) אז בואו נתחיל דווקא מהנקודה שבה סיימנו עכשיו, לפני שנייה - היכולת לייצר Content.עד לפני שנתיים, ייצור Content היה “אירוע משמעותי”.היום, ייצור Content זה הדבר הכי פשוט שיש - אתה נכנס . . .  יש היום שלושה מודלים ענקים מאוד מאוד טובים, שאתה יכול להשתמש בהם בחינם.אנחנו רואים היום תוקפים, שמשתמשים בצורה עקבית - ממש מאמצים את המונח “Disinformation 2.0” - ומייצרים “ערימות של תוכן”.“השפעת תודעה” - זה אפילו לא אירוע טכנולוגי, זה ממש אירוע של השפעת-תודעה, השפעה על קהילה, השפעה על תהליכי-בחירות.עכשיו, ממש היום או אתמול, פרסמו על קמפיין איראני, שנחסם ב-ChatGPT - כדי שהוא לא יוכל לייצר יותר תוכן כדי להשפיע על הבחירות בארצות הברית.זה נראה לי הזוי, שאשכרה האיראנים משלמים כסף ל-API של OpenAI - כדי לייצר תוכן.ואנחנו רואים שזה בעצם הוקטור הראשון שהם תוקפים בו.מיס-אינפורמציה (Misinformation), כמו Tinder-Bots, הגעה ליעדים דרך בעצם Spear-Phishing בצורה מעולה, כמו שראיתי גם בעוד אירוע נוסף בקהילה הביטחונית, שהיה באזור סוף 23-24.שממש באמצעות Spear-Phishing הגיעו לקהילות-הביטחון, בדגש על התעשייה האווירית . . . (רן) מה זה Spear-Phishing?(מושיקו) בעצם, אתה מזהה מהנתקף - אתה אומר “רגע, יש פה איזה מהנדס, שהוא נורא חובב תעופה והחלום שלו כנראה לעבוד ב-Boeing או Airbus וכו’ - ואני מאוד רוצה להגיע אליו, אז אני אדאג לפנות אליו בצורה שהוא הכי אוהב”לרוב זה בדרך כלל דברים יותר “מלוכלכים”, כמו חיבה ל-Fetish-ים ולדברים קצת יותר “פריפריאליים”, אבל במקרה שלנו זה היה באמת חברת Boeing.(רן) . . . התחזו לאנשי Boeing - וניסו לפתות אותו לדבר איתם.(מושיקו) ומה ש”נהדר” היום, זה שהם פותחים כבר פרופילים ב-LinkedIn . . . הם מייצרים תמונות, הם מייצרים Record של עבודה מזוייפת, ממש תהליך ודבר שקורה.נחזור רגע קצת לעולם אפילו הרבה יותר טכנולוגי - מה קורה בעולמות הכלים?בעצם, היום מערכות ההגנה - גם אנחנו ב-upwind - מתמודדים עם מצב שבו תוקף יכול לכתוב כלי-תקיפה בשבוע, מה שהיה לוקח פעם שלושה חודשים, ארבעה חודשים . . .טסטים, ריצות . . . הוא נכנס ל-ChatGPT, אומר לו “אני צריך Module שמבצע 1,2,3”לא נותן לו אפילו Context - לוקח את הקוד ומטמיע; לוקח עוד קוד, מטמיע . . . בעצם, זמן-פיתוח של כלי-תקיפה יורד מבין שלושה חודשים-לשנה, לרמה של שבוע-שבועיים.ואנחנו רואים את זה בעצם בשני צידי המתרס - זאת אומרת, גם היכולת לפתח מודל-הגנתי הצטמצמה דרמטית, אבל גם התוקף מסוגל לייצר פרמוטציות (Permutations) בכמויות מטורפות של כלי תקיפה.זאת אומרת, אם עד היום חתמתי, נגיד, קבצים ב-HASH-ים, וזה היה באמת סביר - היום זו כבר לא טכניקה רלוונטית.(רן) כן, כלומר, אתה אומר - “זיהיתי איך נראה איזשהו Binary, ואני אומר, אוקיי, זיהיתי את זה כאיזשהו Malware, אבל זה כבר לא רלוונטי, כי נורא קל לעשות פרמוטציות שונות של אותו קובץ”. ולא סתם “פרמוטציות נאיביות”, אלא באמת, לשונות שורות קוד - אמיתי, זה עדיין יעבוד, יעשה את העבודה, רק האלגוריתם קצת אחר - והחתימה תיהיה שונה לגמרי.(מושיקו) בדיוק. אנחנו רואים תוקף, שבאופן עקבי . . .  רואים תוקפים, שיכולים לשבת על אותו שרת, עם גרסה שהיא עובדת - ופתאום הגרסה מפסיקה לעבוד, אבל הוא השיג את אותה נגישות, אותו Backdoor.והוא בעצם מתחיל להוריד גרסאות, עד שה-Antivirus מפסיק לתפוס אותו.אנחנו רואים שהם ממש מורידים, גרסא אחרי גרסא.וכל פעם - שינוי, הזחה קטנה בקוד, שינוי של דברים בקוד, שינוי של דברים בחתימה . . .שינוי של דברים שבעצם אשכרה מייצרים Binary חדש, פרמוטציה חדשה - שמערכות-הגנה צריכות להתמודד איתה.פה מגיע עולם חדש - שבו אנחנו, כאנשי-הגנה, משחקים בו - שזה עולם ה-Behaviorשהוא גם קיים כבר המון המון שנים - רק שהפעם אנחנו משחקים קצת שונהקצת “הקשבנו לתוקף" והבנו שרגע, אתה משחק עם מה שיש לך כדי לנצח, ולא כדי רגע להיות “הוגן”.והתחלנו בעצם לאמץ הרבה מודלים, לטובת זיהוי של Bainary-ים בקצה.(רן) זאת אומרת “אם הם משתמשים במודלים, גם אנחנו יכולים להשתמש במודלים! מה החוכמה פה?” . . .(מושיקו) בדיוק, ואז אנחנו מתחילים רגע...(אורי) . . . אבל מי אמר שזה לא הוגן?(מושיקו) זה עניין של השקפה . . . כמו ששלמה ארצי אומר, “זו שאלה של השקפה”.בסוף, היום אנחנו לוקחים גישות הרבה יותר “אמיצות” בעולם ה-Security, שלא נהגנו לקחת עד היום.אני, כאיש Security שגדל “בתעשייה המסורתית” של Low-level ו-”Research קלאסי”’, הלכנו על שיטות מאוד מאוד בינאריות, מאוד “100%”גם עולם האנליזות של 2020, 2021, 2022, של Big Data - לא לקחנו בקלות, “לא לקחנו סיבוב על זה בכיף”.ואנחנו מבינים שאין ברירה . . . (רן) זאת אומרת, היום False-Positives מפחידים אותך הרבה פחות - כי פשוט המסה של התקיפות היא כל כך יותר גדולה, שאתה חייב לשלם על זה איכשהו.30:30 מחפשים צרות עם Agent (Smith?)(רן) בסדר, אז אמרת והזכרת כמה דברים. אחד זה תקיפה באמצעות תוכן - זה יכול להיות ממש תקיפה או הנדסת-הודעה, כמו שהזכרת, שזה דרך אגב אחד הדברים שמטרידים את כל העולם, לא רק אנשי ה-Security. גם לי יצא להיתקל בלא מעט מחקרים, שמדברים על ההשפעה החברתית של הסיפור הזה, אז זה לגמרי בעולם הפוליטי-חברתי והכל. דיברת על קידוד-אוטומטי, אלגוריתמי, “Copilot וחברים”, שעוזרים בעצם לתוקפים פשוט לייצר את כלי התקיפה שלהם יותר מהר.יש גם תקיפות דרך המודלים עצמם, או דברים שטכנולוגית-ספציפיים לעולם של Machine Learning?(מושיקו) אז אני אפתח סוגריים מאוד . . .  דווקא אולי לא מהר, אבל Walk me through here . . .יש עולם של תקיפה  - כלומר, אני תוקף את המודל, את הפלטפורמה.זה עולם שאנחנו ב-upwind עוסקים בו יחסית רבות.מתעסקים בעולמות של אימפלמנטציות (Implementations) של AI - מה קורה כשארגון מטמיע, איך שזה נראה.ויש את העולם של “איך אני לוקח מודל והופך אותו למרושע?”העולם של “איך אני לוקח מודל והופך אותו למרושע?” הוא עולם הרבה יותר, נקרא זה, “נסתר מהעין”.הרבה יותר “מחקרי”, היום בתעשייה.זאת אומרת, מי שמכיר אותו זה הרבה יותר CTO-ים, מחקרים שהם יותר “אקדמאיים”, שבאים ואומרים “מה יקרה ביום שבו הבינה המלאכותית תוכל לתקוף בעצמה?”.זאת אומרת, אני אקח מה שנקרא בעולם Agent-ים, בעצם רכיב שמאפשר ל-AI להריץ פונקציונליות מסוימת - ואני אגיד לו “תריץ פיקוד, תריץ את זה, תתפשט לשרת, תריץ חולשה” . . . מה יקרה ביום שנוכל לעשות את זה?(רן) לצורך העניין, בוא אני ארחיב רגע את הנקודה [כי ישנו ממש טוב עד עכשיו…] - זאת אומרת, סיפרת על התקפה שאותה חווית בשירות, ואתה אומר “ראינו את התוקף, ראינו שיש לו CMD”. לצורך העניין, אולי התוקף הזה עכשיו יתחלף באיזשהו Agent שיעשה את הכל באופן אוטומטי - והרבה יותר מהר, ואולי גם הרבה יותר טוב.(מושיקו) נכון - והוא יוכל לחשוב. הוא ישאל את עצמו, באופן תיאורטי כמובן, אבל הוא ישאל את עצמו: “אוקיי, What is the best way for a Defensive agent?”פרקטית בעברית - “איך אני מתחמק מההגנה?”ויתחיל לממש את כל שיטות ההתחמקות מההגנה - בטווח של עשר דקות . . . .זה משהו שתוקף לא יוכל לעשות - כי לא תיהיה לו את היכולת הזאת בזמן אמת, בלחץ, בהיסטרה של התקיפה. זה משהו שאתה לא עושה.ופתאום יכול לבוא מודל - שהוא לא בלחץ, הוא לא ממהר לשום מקום . . . . הוא “תריץ אותי, אני בסדר אחי, תן לי לרוץ.”וזו חווייה שונה . . . (רן) כן, זאת אומרת - אתה יכול להעסיק עשרה תוקפים, או פשוט לפרוש עשרה מודלים שונים, או עשרה Agent-ים שונים, וכל אחד עם קצת פרמוטציות שונות, וכל אחד יתקוף קצת אחרת, ואולי אחד מהם יצליח . . .(מושיקו) נכון, אבל היום אנחנו רואים מודלים מהממים שרצים ב-Edge.זאת אומרת, מודלים שלדעתי Meta ו-Google פרסמו, שיכולים לקחת החלטה בקצהזאת אומרת, ב-Compute מאוד מאוד סביר, של כמה ג'יגות (Gb) זיכרון, עם CPU סביר, על שרתים.ובעולמות ה-On-prem זה “יכול לחיות בכיף”, בלי שאף אחד יזהה אותו.33:24 שרשראות אספקה של מודלים(רן) כן . . . ההתקפה שתיארת מקודם בעצם מתחילה דרך שרשרת-האספקה של התוכנה. נכון? מגיעה דרך CI, זאת אומרת, דרך חברת תוכנה ואחר כך מגיעה ל-CI. אתה מכיר גם התקפות שרשרת-אספקה (Supply-Chain) על מודלים?(מושיקו) אז יצא לנו לראות לאחרונה המון מחקרים שיוצאים דווקא על “המעטפת של המודלים”.אני לא מדבר על המודל עצמו - זה דווקא מחקר שאנחנו מנהלים בימים אלה אצלנו בחברה, על ממש לעשות Poisoning למודל כדי שיחזיר תשובות שהן מלוכלכות.אבל ראינו המון מודלים ב-Hugging Face שקבצי הקונפיגורציה (Config files) שלהם, ה-Python-ים שלהם, כל קבצי ה-Tensor למיניהם - מודבקים במודולים מקודדים.זאת אומרת, אשכרה יש כזה “קידוד מספרי”, שבעת ההרצה ב-TensorFlow בעצם נפרק.ואז זה ליטרלי Code Execution ל-Remote Code.יצא לנו לראות הרבה, דווקא בעולמות הפלטפורמה, ש-Hugging Face...(רן) . . . זאת אומרת, זה “סוג של Macro”. אם פעם היינו מפחדים מ-Macro ב-Word, אז היום יש Macro-ים כאלה בתוך TensorFlow, שאתה מוריד אותם בלי שאתה יודע, מ-Hugging Face, כי שם נמצאים המודלים. ולמעשה אתה מריץ איזשהו “Macro” שלא התכוונת. אולי התכוונת להוריד סט של משקולות למודל - אבל אתה גם מריץ פה איזשהו Executable, בלי שאתה יודע.(מושיקו) בדיוק - ובעצם אנחנו רואים שזה מתפשט בטירוף.כי תוקפים מבינים שהם יכולים לקחת מודל קיים, לשכפל אותו, לתת לו שם מגניב, לעצב אותו קצת יפה, לפרסם אותו ב-Medium - ופתאום יש קליינטים, יש קליאנטורה  . . . הם רצים בסביבות Production - אף אחד כמעט לא מריץ מודלים במחשב האישי, “לכיף”, אלא, אתה יודע, לפיתוח, וזו הכניסה לסביבה.ורואים וקטור תקיפה משמעותי שנבנה שם.לגבי, רגע, מודל שהוא בעצמו זדוני - זאת אומרת “במהות שלו"שאתה אומר לו “תביא לי קוד Python” - ואתה מקבל בפועל קוד זדוני של Python.זה מחקר שאנחנו עובדים עליו בימים אלה - התוצאות מעורבות.בסוף, נקרא לזה ה-”Fine Tuning” או ה-”Embedding” לא מספיק איכותי בשביל לגרום לו לסטות בטירוף.אנחנו כן מצליחים לגרום לו לבצע הזרקות מאוד מינימליות, של URL-ים, של Request-ים ספציפיים, בעולמות ה”תקיפה Light”.לא מצליחים לגרום לו להוציא קוד זדוני ממש, שייתן לנו Reverse שלו, קוד Executional ללקוח.וזה באמת אירוע נורא דרמטי - כל עולמות הפלטפורמה וההרצה הם עולמות נורא חדירים, בעיקר כי הם עולמות נורא מחקריים.זאת אומרת, מי עד לפני שנה עשה “הנדסת AI”? בפועל,  אלו היו חוקרים, כנראה באקדמיה או אנשי Data Science, שהיו “בשמנת של השמנת” של הארגון.הם ו-DevOps או הם ו-Security זה בערך הדבר הכי רחוק אחד מהשני . . . ובסוף, היום אנחנו לצורך העניין מתמודדים עם מספר לקוחות שהם פלטפורמות-AIב-upwind אנחנו נותנים שירות-הגנה לספקי AI.ואנחנו רואים שבאופן עקבי, תוקפים נכנסים לפלטפורמה, באים לאמן מודל לכאורה - אבל בפועל מצליחים לחדור את תשתיות-החברה בצורה נורא נורא פשוטה, נורא מהירה.כאילו, מקבלים Shell Jupyter, ממפים אותו, מוצאים בדרך כלל חולשה לוגית כזאת או אחרת בשירות - כי כנראה שלא מידלו אותו מספיק טוב.ומתחילים בעצם להריץ Miner-ים או כלי-תקיפה על אותה סביבה.וזה וקטור-תקיפה נורא דרמטי בעולם ה-AI והפלטפורמות.36:34 סיפורים מהקופסא ו-72 שעות(רן) אוקיי . . . אז פה, בפודקאסט הזה, לקחנו בעיקר את הצד של התוקף. קודם כל - אל תדאגו, יש הרבה שמגינים, חשוב להזכיר, בצבא ובאזרחות. זאת אומרת, רצינו להתמקד על הצד של התוקף, ככה, כדי שיהיה מעניין - אבל יש לא מעט טכנולוגיות, גם כמו שרמזת קצת, בצד המגן.ובעיקרון הזמן שלנו כבר די נגמר - אבל יש עוד כמה סיפורים יפים, שחשבתי שאולי יהיה נחמד לדבר עליהם, אז בואו אולי ניקח בקטנה עוד איזשהו “סיפור קרב” אחד כזה, מהדברים שעברת? לא בהכרח AI, איך שמתאים לך - וככה נעבור אותו קצת יותר בקצרה.(מושיקו) בשמחה. אז באמת, חוזרים מהמילואים, תקופה מאתגרת . . . לדעתי, במילואים האחרונים שעשיתי, במהלך המלחמה, הגענו לקונצנזוס פעם ראשונה בצבא.“עשרה יהודים בחדר”, מה שנקרא - כולם מסכימים בפעם הראשונה . . . זו התקופה שנתקפנו בה הכי הרבה פעם, היסטורית. תקיפות Non-Stop.ובעצם, דבר אחד משותף - לא מעניין אותם שום דבר יותר. הם רוצים להגיע ליעד, הם רוצים להגיע לנכס.ואנחנו בעצם רואים . . . .הגענו לסביבת משתמשים, סביבת לקוחות, שבה ככה, בהחלטה מודעת של אותה תעשייה ביטחונית, לא בוצעו בה תהליכי-הגנה, לא בוצעו שגרות-הגנה, כתהליך מודע.ובעצם התוקף “חי” שם בסביבת-משתמשים סטנדרטית - אבל פה הפעם מדובר במערך 42מערך איראני, מערך שקצת מבין יותר התפשטות, מבין יותר רשת - והוא בעצם פה כן מנהל תקיפת-Domain ותקיפות על בסיס פלטפורמות-הגנה.אנחנו רואים אותו נע לאורך הרשת - הוא בעצם פה כן מנהל סביבנו מבצע, הוא מריץ עלינו כלי-תקיפה די “רזה”באופן מאכזב . . . זאת אומרת, ציפינו דווקא ממערך כזה לנהל כלי-תקיפה יותר משמעותי.אבל פה הוא מתמקד דווקא באנשים - באנשים שבארגון, זה מה שמעניין אותו.הוא מתמקד באנשים, הוא מתמקד ב-Active Directory, הוא בודק מי עובד בארגון, מי זה האנשים האלה . . .הוא “חוקר אותנו” - אנחנו ממש רואים אותו שולף את השמות האישיים של האנשים שיכולים להתחבר.והוא מתמקד ב-WhatsApp-ים - פעם ראשונה אנחנו רואים מישהו שאשכרה מעין אותו ה-WhatsApp Web, זה היעד שלו.עובר תיבה-תיבה, כאילו - תיבת-מייל, תיבת WhatsApp, עובר כל פלטפורמה שהוא יכול - ובעצם עושה לנו Data Mining בסביבה,ואנחנו רואים שהוא “חי שם”, לאורך סדר-גודל של שבועיים-שלושה - והפעם, רגע, יש מישהו “שמבין תוכנה”.יש תוקף שיודע מה זה תוכנה - הוא יודע לקמפרס (Compress), הוא יודע על בעיות Bandwidth, הוא ממש חי את זה.הוא מבין רגע שה-SYSVOL - בעצם תיקיית הפצת-העדכונים של Windows, נגישה לכולם.ועוד פעם, כמו במלחמה - נכנסים ל-72 שעות מאוד מאוד ארוכות . . . .אני יכול להגיד לכם בנימה אופטימית ש . . .(אורי) . . . כנראה שיכולות להיות רק 72 שעות ב-72 שעות . . . (רן) דיברנו על “דונם גדול” ו”דונם קטן”?(מושיקו) המדינה יותר קטנה בלילה, כן . . . זה טיפ חשוב.אז לדעתי המון זמן לא אכלתי 72 שעות רצוף, מה שנקרא.“נכנסים לקרב”, בעצם רצים משרת לשרת, ממכונה למכונה - ופה המזל לא משחק לנו, כי פה זו סביבה שיכולה לצאת לאינטרנט מכל Endpoint, כל Endpoint נגיש.ופה מתחיל “חתול ועכבר” . . .וכאן כמה טיפים כן טובים שאני לקחתי מהאירוע הזה.אחד - ערנות מוגברת ומודעות משתמשים הרבה יותר טובה ברוב הפעמים מכלי-הגנה נורא נורא יקרים.פה היה חוסר מודעות של משתמשים והתנהגות בעצם שהיא “Misbehaving” - התנהגות שהיא קצת לא תקינה.שימוש ברכיבים-ארגוניים לטובה צרכים אישיים.בעצם ייצרו איזושהי יכולת לתוקף להשיג מידה שהוא לא יכול היה להשיג, אלא אם היה צריך להגיע אליי הביתה.זאת אומרת הוא לא . . . אני דמות, אני בחור ממש נחמד, אני Head of Research - אבל כנראה שאת הכתובת של אמא שלי הוא לא ידע להשיג, כי זה לא הדבר הכי חשוב בעולם בשבילו.אבל פתאום, כשיש לו נגישות ל-WhatsApp שלי, לשמות של הילדים שלי, לחברים שלי מהקורס טייס, לחברים שלי מכל מיני מקומות - יש לו נכס מאוד מעניין ביד.ופה אנחנו בעצם נלחמים מלחמה שהיא בין התודעה לבין “מלחמת נוחות” - ופה אנחנו דווקא יוצאים עם ידינו על העליונה, באירוע הזה.זאת אומרת, מבצעים מיטיגציה (Mitigation) הרמטית - חוסמים את התוקף, מצליחים “לצאת מנצחים הביתה”.כן מצליחים לחסום את מרבית ה-Data שנגנב - זאת אומרת, רוב ה-Data שנגנב בעצם נאסף לתוך איחסון מרוכז, מקומפרס (Compressed), זאת אומרת הוא דוחס אותו . . .(רן) . . . עדיין אצלכם, זאת אומרת - ראיתם את זה . . .(מושיקו) כן, עדיין אצלנו. אנחנו רואים “זרזיף-תקשורת”, נקרא לו ככה, שיוצא החוצה - זאת אומרת, ממש ניסוי “העברת חוטר”, אבל לא הצלחה.ופה בעצם אנחנו אומרים “חבר'ה, הפסדנו פעם אחת לפני חצי שנה שנה - בואו ננצח הפעם”.חוסמים את התוקף בזמן, מצליחים בעצם “לצאת מנצחים”.ועוד פעם, טיפ מאוד חשוב לאירועים האלה - יש בדרך כלל באירוע Cyber, שבו יש תוקף “חי” ולא איזה מערך -Bot-ים, יש 72 שעות עד שאתה . . . בעצם, מהרגע שהחלטת לפעול ועד הרגע שבו לתוקף ולך “נגמר האוויר”.וזה זמן לקחת “החלטות אמיצות” - החלטות שיכולות להציל את הארגון.אז ככה אני הייתי מסיים, בנימה אופטימית זו, את הסיפור הזה.41:47 נימה אופטימית(רן) טוב, סיפור אופטימי לסוף זה כבר נחמד . . . נשמע מרתק.דיברנו בעיקר על הניסיון הצבאי - אבל יש, אני מניח, גם לא מעט באזרחות. אז בואו נסיים - אבל רק כמה מילים אולי שוב על upwind? אז אני מניח, ואתה אמרת, שאתם משהו כמו 150 עובדים, באזור תל אביב.מחפשים אנשים? מגייסים? מה?(מושיקו) כמובן, רגע - ה-Talent הישראלי זה לדעתי הדבר הכי מהמם שיש לנו פה במדינה שלנו.מגייסים. היום יש לנו מעל עשרה תקנים, מעל עשר משרות עם מעל עשרים תקנים.מחוקרי-חולשות וחוקרי Security עד ל-Frontend ו-Backend ו-QA ו-BDR וכל מה שצריך בתעשייה.חברה מעולה, אפילו משפחה - בשבילי זה קצת יותר משפחה לפעמים.(רן) שם אין 72 שעות . . .(מושיקו) שם כל יום הוא 72 שעות - בקטע הטוב, כמובן.(רן) תמכור קצת . . .תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 476 של רברס עם פלטפורמה, שהוקלט ב-25 ביולי 2024 (יומיים אחרי ההקלטה הקודמת). אורי ורן מארחים בשבוע ה-ML (הלא רשמי) את דגן מחברת Citrusx לשיחה על ארגונים ש-ML חשוב להם. 00:45 דגן ו-Citrusx ורברס עם פלטפורמה (באמת)(רן) אז לפני שנצלול לעסק - קצת עליך ועל החברה?(דגן) נעים מאוד, אני דגן. במקור בכלל קיבוצניק מעוטף עזה, עם לינה משותפת וכל ה . . . . (אורי) . . . . אתה בחברה טובה . . . . לא מעוטף-עזה, אבל גם אנחנו, שנינו.(דגן) . . . אז המקצוע הראשון שלי זה רפתן, ואחרי זה עבדתי עם . . . . (אורי) לא, אבל בוא נשאל את השאלה - מתי בפעם הראשונה עשית רברס עם פלטפורמה?(דגן) אז אני הייתי ברפת יותר, זה פחות. זה יותר עם הטרקטור של החלוקת-מזון, ופחות עם הרברסים עם העגלה.(אורי) . . . . חרא עד הברכיים הברכיים - קדימה . . . (דגן) זה כן . . . (רן) טוב, אז אתה בחברה טובה . . . . אוקיי, אז גדלת שם, ואחר כך?...(דגן) אז גדלתי שם, ואחר כך בצבא הגעתי ל-8200, ליחידה מאוד טכנולוגית.ושם נכנסתי לעולם הזה, של תוכנה ואלגוריתמיקה וכל הדברים “המדעיים".ומפה לאוניברסיטה, כשלמדתי מדעי המחשב ומדעי המוח, איפשהו לחבר את שני העולמות של...מדעי המחשב זה הכלי, מדעי המוח זה היעד שאליו רוצים להגיע.ולהבין אותו, לדמות אותו, ל ...(רן) . . . נשארת עם הכלי . . . (דגן) נשארתי עם הכלי - אבל תמיד איפשהו התעסקתי בדברים שקשורים.אם זה ראייה ממוחשבת, Machine Learning - זה איפשהו בעולמות האלה.אחרי התואר עבדתי גם ב-Mobileye ובעוד כל מיני סטארטאפים - תמיד סביב טכנולוגיה, דברים מוחשיים, על התפר שבין תוכנה לאלגוריתמיקה.עם הרבה מאוד התעניינות באמת בעולם הזה של ה-Machine Learning, AI - השמות השתנו עם הזמן . . . “איך המחשב חושב” ואיך לגרום לו “לחשוב יותר טוב”.(רן) כן. עוד יש כאלה שקוראים לזה אלגוריתמיקה . . . מעולה. והיום אתה נמצא בחברת CitrusX - באיזה Capacity? מה תפקידך שם?(דגן) אז היום אני ב-CitrusX כבר שנתיים וחצי, אפילו קצת יותר.בתפקיד של ה-VP R&D - בעצם מוביל את הצד הטכנולוגי, את הפיתוח של המוצרים.(רן) אוקיי. אז CitrusX - מה עושים שם?(דגן) אז CitrusX - קודם כל אנחנו סטארטאפ צעיר יחסית, היום 16 עובדים, נמצאים בתל אביב.ובעצם המטרה שלשמה החברה קמה היא לעזור לארגונים שהם בסיכון גבוה להיכנס לעולמות של Machine Learning.אם היום הטרנד זה GenAI, ואי אפשר לעשות פודקאסט טכנולוגי בלי להגיד GenAI ...(רן) הנה, עשינו “v” גם על זה . . . .(דגן) עשינו “v” גם על זה . . . . אז ארגונים רבים - כאילו, תעשיות של פיננסים וביטוח וכאלה - הם ממש לא שם.הם עוד... 30 שנה, 40 שנה אחורה - והם מנסים להיכנס לעולמות של ה-Machine Learning הקלאסי.(רן) עוד קשה להם עם הרגרסיה הלינארית . . . (דגן) הרגרסיה לינארית הם בסדר - קשה להם לעשות את הצעד הבא.(אורי) זה לא GenAI, זה Gen-היי-הג’יפ . . . .(רן) כן . . . אוקיי, אז אני מניח שרוב מי שמקשיב מבין, פחות או יותר - יש ארגונים שיש להם קושי לקחת מודל-שפה ולפרוש את זה בפני הלקוחות, נגיד כמו בנקים. אבל בואו נפרוס את זה לדברים קצת יותר פרקטיים - איזה קשיים? איזה אתגרים? איזה סכנות יש להם, שאתם בעצם עוזרים להם איתן?(דגן) אז אני חושב שמילת-המפתח פה היא “אמון” - זאת אומרת, לקבל אמון “בקופסה השחורה” הזאת.והצד ההפוך של זה זה ה-Risk, זה הסיכון - זאת אומרת, כל מיני קבוצות בארגון שמפחדות לקחת סיכונים, ומשליכות את זה על המפתחים, על האלגוריתמיקה.(רן) כן. זאת אומרת, אם יש איש Machine Learning או Data Science או אלגוריתמיקה או איך שלא נקרא על זה, שעובד בבנק, והוא פיתח מודל נהדר לחיזוי של Whatever - מניה או ריסק בהלוואה או כל דבר כזה. אפילו אם המודל, יש לו ביצועים נהדרים - יכול להיות שהבנק יימנע מלהשתמש בו, בגלל סיבות של אקספלינביליות (Explainability), סיכון . . . (דגן) אז כל הדברים האלה - אקספלינביליות (Explainability), סיכון, רגולציות, ביצועים של המודל . . .  בעצם “לסמוך על המודל".אז יש פה תסכול של שני הצדדים - ה-Data Scientist שעובד על המודל חצי שנה, תשעה חודשים, שנה . . .  כמה זמן שלוקח לפתח את המודל הנהדר שהזכרת קודם - ואז, בישורת האחרונה אומרים לו “לא, לא, לא, אתה לא יכול להתקדם”.(אורי) למה? כי אין אמון.(דגן) למה? כי אין אמון . . . “כי אני צריך שתוכיח לי שהמודל לא יפשל בזמן אמת” ו-”אני צריך שאני אוכל להסביר כל החלטה שהמודל מקבל” ו-”ויש לי רגולציות על הראש!” . . . .אולי נדבר על זה עוד מעט, אבל עד לפני שנה-שנתיים זה היה בעיקר רגולציות פנימיות, כי החברות חוששות ולא רוצים שיתבעו אותן ולא רוצים “לעשות פאדיחות” או נזקים של מיליונים, ויש דוגמאות כאלה . . .(אורי) אבל זה קצת, בוא נגיד ככה, “מובנה”. מכיוון שרוב - בוא נודה על האמת - רוב ה-Machine Learning ורוב ה-AI - בסוף הוא סטטיסטי. ובמשהו שהוא סטטיסטי, יש איזשהו סיכון. אני הייתי נוהג להגיד לאנשי Risk או כל מערכת טכנולוגית, “קחו את זה בחשבון כשאתם עולים על מטוס” . . . . אז צריך לדעת לנהל סיכונים בכל מקום.(דגן) נכון, וזו בדיוק מילת המפתח פה - “ניהול סיכונים”.צריך לדעת מתי זה בסדר לקחת את הסיכון ומתי זה לא בסדר לקחת את הסיכון.ואם המודל Machine Learning, בתפיסה של הרבה מאוד אנשים, זה “קופסה שחורה”, אז “אני לא מתעסק עם זה”.כי אני לא יודע מתי הוא יפשל, אני לא יודע איפה.וכאן אנחנו נכנסים בתמונה, בעצם.(רן) כן, אני מניח שעולם מקביל לזה זה עולם של נגיד מכוניות שנוהגות אוטונומית - שגם שם יש סיכונים, ומצד שני, אנחנו מבינים שגם לתת לבני אדם הגה בידיים זה מסוכן, ככה שזה לא . . . אין פה איזשהו משהו שהוא חד וחלק.07:35 אז איך עוזרים?(רן) אז איך אתם בעצם עוזרים לאותן חברות? נניח שפיתחתי איזשהו מודל לחיזוי של סיכון של מתן הלוואה ללקוח, אוקיי? איך אתם עוזרים לבנק לקבל ביטחון באותו מודל? (אורי) מה שבעצם זה “חיתום” . . .(דגן) נכון. אז זה באמת דוגמא למודלים שאנחנו מתעסקים איתם ביום-יום.אז בעצם אפשר להגיד שהמטרה שלנו היא להושיב סביב שולחן אחד את ה-Data Scientist ואת ה-Chief Data ואת ה-Risk Manager ואת ה-Compliance Executive.להושיב אותם סביב שולחן אחד - ושכולם ידברו באותה שפה ויבינו אחד את השני.והתפקיד שלנו זה לתרגם ביניהם - לקחת את הדאטה והסטטיסטיקות, שה-Data Scientist מפתח, ולתרגם את זה למסמך Legal שהאיש Compliance יודע להבין אותו ולהתייחס אליו.ומהמסמך הזה הוא יכול להגיד מה בסדר ומה לא בסדר, מה הוא מוכן לספוג ומה הוא לא מוכן לספוג.ואם צריך אז להחזיר את זה חזרה לשולחן השרטוטים - אבל מדויק.נגיד, “בנקודה הזאת - את זה אני לא מוכן לקבל”, זאת אומרת...(אורי) וכמה יוצא לכם, אתה יודע, כאלה שאומרים “אני לא מוכן לקבל כלום!” . . . “לא מוכן לקבל שום פאדיחה”.(דגן) אז קודם כל - יש כאלה . . . תלוי בתחומים, אבל יש תחומים שהם עוד יותר שמרניים.אבל מה שרואים היום בשוק זה שהחברות מבינות שאין להן ברירה - כי הם פשוט יישארו מאחורה.אם המודל-חיתום שלך הוא “פרימיטיבי”, אז יצוצו Digital Banks וכל מיני כאלה שיש להם מודלים יותר חכמים עם סיכון פחות “מפחיד" - ויעקפו אותך.[דניאל שרייבר מדבר כאן בגיקונומי על Lemonade ו-AI](אורי) וגם בוא נודה על האמת - יש מגבלות Scale. כאילו, אתה יכול לעשות את הכל ידנית, אבל זה פשוט יעלה לך המון.(דגן) נכון - וזו אחת הבעיות בעצם.כי לקחת מודל אחד ולעשות עליו את הוולידציה (Validation) הזאת וכל התהליך הזה - אפשר לעשות את זה, ואנחנו רואים חברות שעושות את זה.ומשיחות שלנו עם לקוחות - זה לוקח להן שישה חודשים, תשעה חודשים . . . לא הבנייה של המודל - מהרגע שהמודל הסתיים וה-Data Scientist “הניח את ההצעה שלו”, עד לרגע  שהבנק או איזה גוף שזה לא יהיה אישר את המודל ואמר “יאללה, אנחנו Good to go”.אז זה בסדר כשיש לך מודל אחד - אם יש לך 20, 40, 50 מודלים, זה כבר לא Scalable-י.10:14 איפה הטכנולוגיה?(רן) כן. אוקיי - אבל זה נשמע כמו איזשהו מוצר . . . . אפילו לא נקרא לזה “מוצר” - זה נשמע כמו “בוא נושיב את האנשים סביב השולחן”. זאת אומרת, איפה הטכנולוגיה פה? אתם בסך הכל חברה טכנולוגית, נכון? אז מה הכלים הטכנולוגיים שמשרתים אתכם?(דגן) אז אנחנו באמת חברה טכנולוגית שמייצרת מוצר - ואם תסתכל בשוק, אז השוק הזה הוא “חי”.יש כל מיני כלים, אלגוריתמים, שבאים לפתור בעיות ספציפיות - אין איזשהו כלי אחד שמאחד את הכל.כמו שאמרת - “להושיב את כולם ביחד ולדבר באותה שפה”.והדרך שלנו לעשות את זה היא הטכנולוגיה - בעצם, לקחת את המודל הזה ולעשות לו “X-ray”, להראות בדיוק איך הוא עובד ומה הוא עושה, לפרק אותו לגורמים.ולהצביע על איפה באמת יש בעיות ואיפה כדאי להסתכל - ואיפה זה לא מעניין ואפשר להמשיך הלאה.(רן) כלומר- בואו נעשה את זה רגע ציורי - נלך עם הדוגמא שלי, של מודל של “האם כדאי להלוות ללקוח כסף או לא”. מסתכלים על, נגיד, רקע, השכלה, גיל, מצב משפחתי, תעסוקה וכו’ . . . מסתכלים על כל מיני מיני פרמטרים. ויכול להיות שהמודל אומן כבר על אלף או מיליון כאלה, אז הוא פחות או יותר יודע מה התשובה.אבל אם אתה מקבל פתאום איזשהו Outlier - לצורך עניין, השכלה ממדינה שונה, שאתה לא יודע להגיד עליה כלום, או מישהו שהוא צעיר במיוחד ושמעולם לא ראית - פה למעשה יש לך איזשהו Blind-spot, נכון? אתה לא יודע מה המודל הולך לענות עליו. איך פותרים את זה?(דגן) נכון, וזו באמת אחת הבעיות - מה יקרה כשיגיע הדאטה שהמודל לא ראה?אז איך פותרים את זה? אז עכשיו אולי קצת ניכנס ונצלול קצת לטכנולוגיה, ואז נבין איך אפשר בעצם להתמודד גם עם הבעיה הזאת.(רן) אין בעיה.(דגן) אז בעצם, הדבר הראשון שהמערכת שלנו עושה, בהינתן מודל של הלקוח וה-Training Data Set של הלקוח, זה למפות את המרחב.אתה דיברת קודם על מודל שמקבל חמישה פרמטרים - במציאות יש מאות.אז למפות את זה ידנית זה לא אפשרי.אז בעצם הדבר הראשון שהמערכת עושה זה היא לפרוש את המרחב הזה, ולהבין מה לא מעניין.למפות את כל האזורים שלא קורה בהם כלום - אין לקוחות כאלה ולא מעניין אף אחד - ולצמצם את זה, קודם כל, ולהתמקד באזורים המעניינים.(רן) לצורך העניין, לקוח שנולד באוקיינוס - גם אם יש אחד כזה, זה כנראה לא מעניין את המודל הזה של הבנק. אפשר לחשוב על מרחב, סליחה על המילה, מרחב-וקטורי בגודל מאה מימדים - יש במרחב הזה הרבה מאוד אזורים לא מעניינים, שעליהם פשוט לא צריך להתעכב, בסדר.(דגן) נכון, אז זה הדבר הראשון - וכבר הורדת את החישוביות שלך בהמון.(רן) כן. לצורך העניין, ילד בן שלוש עם עשרים שנות ניסיון בעבודה - לא קיים, אז לא צריך להתייחס.(דגן) נכון. והדבר השני זה עכשיו להסתכל על החלקים היותר מעניינים - ולהתחיל לאפיין אותם, ולהתחיל בעצם לנתח אותם.ופה זה קצת דומה לעולמות של עיבוד-תמונה - כשאני בא לדחוס תמונה, אז יש אזורים בתמונה שהם . . . שקורה בהם משהו, אבל הם לא כל כך מעניינים.אם יש לי זברה שעומדת על דשא וברקע שמיים כחולים, אני יכול לייצג את השמיים הכחולים האלה במעט מאוד מידע, כי אין שם שום דבר מעניין . . .יש שם איזה גרדיאנט (Gradient) מתכלת לכחול, אבל קל מאוד לאפיין אותו - והוא משעמם.(רן) כשדוחסים את התמונה . . .(דגן) נכון.(דגן) אז בעצם, אם אני מסתכל שוב על המרחב הזה שדיברנו עליו קודם, אז אפשר להגיד שכל מי שהוא מתחת לגיל 18, אז זה טווח גילאים מאוד גדול אבל זה לא מעניין, לא קורה שם כלום.המודל יגיד לך “לא”. [“Computer says No”](רן) כן. זאת אומרת לעשות איזשהו . . . לייצר איזשהו Bucket כזה. במקום להגיד “לא!”, זה מרחב רציף - לבוא ולהגיד “יש לי פה Bucket ‘מתחת לגיל 18’, וכולם מבחינתי אותו דבר, ב-Bucket הזה”.(דגן) אותו דבר, או שקל לי לאפיין אותם באיזשהו קירוב פשוט.(רן) כן, אוקיי. אז אתה כאילו מקטין את המרחב שלו.(דגן) נכון. אז אני לוקח בעיה גדולה מאוד ומאוד מורכבת, עם המון מימדים - ואני מתחיל לפרק אותה לבעיות יותר קטנות.והחוכמה פה היא בעצם לדעת מה גודל הבעיה האופטימלי.(אורי) בעיות יותר קטנות - או בעיות, בעלות סיבוכיות קטנה יותר?(דגן) שניהם.בעצם, המודל - יש לו סיבוכיות מאוד גבוהה, כי הוא יכול להיות בצורות מאוד משונות.הוא בכל נקודה במרחב הוא נותן פרדיקציה - וזה יוצר איזושהי פונקציה מורכבת.זה היתרון שלו גם - לכן אנחנו אוהבים אותו, כי הוא יכול לתפוס ניואנסים קטנים.אבל עכשיו, מה שאנחנו בעצם באים לעשות בשלב הראשון, זה להתחיל לפרק אותו ולנסות, קודם כל, למצוא Chunk-ים כאלה כמה שיותר גדולים, אבל איפה שאי אפשר - אנחנו נצטמצם.אז אם אני חוזר עוד פעם לזברה - השמיים יהיו אזור מאוד גדול, שאני מאפיין אותו מאוד בקלות ואני יכול לתת עליו המון מידע.איפה שהזברה נמצאת אני כבר מתחיל לחלק את זה לאזורים הרבה יותר קטנים - כדי לתפוס באמת את הניואנסים האלה.(אורי) חלקם שחורים וחלקם לבנים . . . .(דגן) חלקם שחורים וחלקם לבנים - ומה שמעניין זה המעבר. בסופו של דבר זה המעבר, כמו בעיבוד תמונה.(רן) “קווי המיתאר”, ה-Contour . . . (דגן) מעניין אותי איפה שקורה השינוי.אז החוכמה בעצם היא להצליח למצוא את האזורים האלה - שהם מספיק גדולים כדי שתיהיה להם משמעות.בסוף, אני לא רוצה להגיע לקוביה שמייצגת בן אדם אחד בלבד.אבל מספיק קטנים כדי שאני אוכל לאפיין אותם.ואז בעצם מה שקורה בדרך שאנחנו עושים את זה, זה שנוצרים אזורים שהם Interpretable by Design . . .(רן) כן, אז אתה אומר כאילו שעכשיו לעשות לזה QA זה כבר הרבה יותר פיזיבילי (Feasible) - כי מקודם אם היה מרחב “אינסופי", או “אינסופי בחזקת 100”, אז עכשיו יש לך מרחב של אולי הרבה Bucket-ים, אבל זה כבר הרבה הרבה יותר פיזיבילי, ושם אתה יכול לקחת, נגיד, מייצג אחד מכל Bucket, ולבוא ולבדוק מה קורה איתו, או אולי לגלות שאין לך כיסוי ל-Bucket הזה, ואז לייצר כיסוי.(דגן) אז שם, עכשיו אני יכול לגלות המון דברים על כל Bucket כזה.אני יכול לגלות מה משפיע על המודל - בגלל שהצורה שבה בניתי את האיזור הזה, אז קל לאפיין אותו.אני יכול להגיד “אוקיי - באזורים האלה, מה שמשפיע על החלטה של המודל זה רק המשכורת והגיל של הבנאדם, וכל שאר הדברים הם יותר זניחים”.אז כבר...(אורי) אתם עושים את זה בניסוי וטעייה, או... זאת אומרת, מריצים את המודל, משנים כל מיני פרמטרים ורואים מה ההשפעה, או שמראש בהתבוננות על “ב-X-ray” הזה של המודל, אתם יודעים להגיד מה משפיע ומה לא משפיע?(דגן) אז . . . . קצת שניהם.קודם כל, אנחנו מסתכלים מראש על הצורה של המודל, וככה אנחנו מפרקים אותו לחלקים יותר ויותר קטנים.אבל לא תמיד יש מספיק מידע - זה בדיוק מה שאמרתם לפני דקה.לפעמים הגעתי לאיזשהו אזור - והוא מעניין, אני מאוד מאוד רוצה לאפיין אותו, אבל אין לי מספיק נתונים בו.ואז נכנס לחלק השני של להוסיף “Data סיננטי” - בעצם, לסמלץ (Simulate) נקודות חדשות, אבל בצורה חכמה.שהן מתאימות להתפלגות המקומית.זאת אומרת “באיזור הזה - ככה ה-Data נראה”, אז עכשיו אני אייצר עוד הרבה דוגמאות כאלה בתוך האזור הזה, ועכשיו יש לי עוד המון מידע רלוונטי בשביל להגיד איך המודל מתנהג באזור הזה.וזה עוזר גם בשביל לדעת מה הצורה של המודל - אבל גם אפשר להשתמש באותו כלי בשביל דברים מאוד ספציפיים.למשל, אם אני רוצה לדעת  . . . אחת הבעיות שמאוד מעסיקות חברות, אם זה מתן הלוואה, אז זה אולי ה-Top, זה “הוגנות”.אני צריך להוכיח שהמודל שלי “הוגן”.ואם הוא לא הוגן אז יתבעו אותי - וזה בעיה מאוד גדולה.(רן) מה שנקרא בעברית Fairness ו-Bias . . . (דגן) בדיוק.אז אחד הדברים שהכלי הזה מאפשר לנו להגיד זה, אוקיי, אם עכשיו אני מסתכל על Bucket מסוים, שזה “אנשים בגיל ארבעים ומטה שגרים באלסקה”.אין לי נשים שם . . . .ב-Database שלי אין נשים.והבעיות בתחומים האלה שאי אפשר “לייצר” . . . זה לא כמו בתחומים שאנחנו יכולים להגיד “אז לכו תאספו עוד נקודות ותעשירו את המודל”אין - אין לי מה לעשות.אז פה אנחנו כן יכולים לעשות זה, כי נגיד . . . (אורי) . . .  כי ה-Data סינטטי  . . . (דגן) נכון. אני רוצה לדעת האם באיזור הזה של אלסקה, מתחת לגיל ארבעים, יש אפליה? יש לי רק גברים, אז אני “אייצר נשים” שם.אני “אפזר נשים” במרחב הזה, ובוא נראה איך המודל מגיב - האם הוא הוגן או לא הוגן.(רן) כן, אז נזכיר, כאנקדוטה, נגיד סיפור מפורסם שהיה נגיד - כש-Amazon ניסו לפתח מודל של Hiring, ולהבין האם ה-Hire הבא מתאים או לא מתאים, אז הם למדו על Data היסטורי שלהם. שזה נשמע הגיוני, זאת אומרת - ההגיון של “אנשים שקיבלנו לחברה ונגיד החזיקו מעמד חמש שנים או עשר שנים, ואולי גם עוד הצליחו בתפקיד שלהם - אנשים עם מאפיינים דומים כנראה יהיו מועמדים טובים”. בסך הכל נשמע הגיוני. אבל ברגע שבאו להפעיל את המודל הזה, גילו שהרבה הרבה מאוד נשים מסוננות החוצה . . . עכשיו, זה לא שלמודל היה משהו נגד נשים, אלא שבמידע שעליו הוא התאמן, לצערנו - וכנראה גם לצערם - פשוט היו הרבה פחות נשים, וזה למעשה יצר איזשהו Bias, איזשהו Unfairness מאוד מאוד משמעותי, וכמובן שהם הסירו את המודל הזה ולא השתמשו בו יותר באותו רגע.אבל זו דוגמה שכבר קרתה, אולי אפילו בתום לב - ויכולה לקרות בכל בנק . . . [זה לא משהו שמודלי-AI המציאו - דוגמא של Daryl Morey, מפספס את Jeremy Lin מאחד הפרקים האחרונים של  Freakonomics - Here’s Why You’re Not an Elite Athlete](דגן)  נכון, וזו דוגמה מצוינת - והבעיה פה היא קצת יותר חריפה.כי בסוף, מודלים של Machine Learning רוצים למקסם (Maximize) - אז אם היה לי Bias קטן לטובת גברים, עכשיו המודל יכול לקבל נטייה למקסם את הדבר הזה . . . .כי בסוף הוא רוצה להוציא את התוצאות הכי טובות, ולגבר יש סיכוי יותר טוב מאשר לאישה - אז הוא “ידחוף” לשם כדי לקבל בסוף תוצאות “יותר טובות”.אז לגבי מה שדיברנו עליו קודם, על ה-Data הסינתטי - הוא בדיוק נועד בשביל, בין היתר, לטפל במקרים האלה.בשביל להחזיר את הנשים “שנעלמו”.20:37 הוגנות(רן) בוא נדבר קצת על Fairness - אילו עוד דרכים יש לבוא ולתקן הוגנות של מודל? או בוא נתחיל - לבדוק האם המודל הוגן, ואולי אחר כך גם לתקן אותו? אז אמרת - דרך אחת זה לבוא ולייצר Data סינתטי, במקומות שאנחנו רואים שיש Under-Representation. אוקיי, זו דרך אחת. יש עוד דרכים?(דגן) אז קודם כל, אנחנו מדברים כרגע, בתור שלב ראשון, על לזהות את זה.ואני אגיד גם שאיפשהו, אחד הדברים שאנחנו למדנו, הוא . . . אנחנו - מאוד בער לנו להגיד “אוקיי, אנחנו מזהים בעיה - בוא נתקן אותה.”ועצרו אותנו - כי אמרו לנו “לא לא - אתם לא יכולים גם להיות ‘ה-Validator ההוגן‘, וגם לגעת במודל” . . .(רן) . .  יש רגולציה . . . “אל תיגע לי במודל”.(דגן) רגולציה . . . אז אני אגיד - אנחנו מתעסקים בלזהות את הדברים, ומשאירים את המיטיגציה (Mitigation) ללקוחות.אבל אנחנו כן אומרים להם מה אפשר לעשות.זאת אומרת, אני לא נוגע - אבל אני יכול להגיד לך מה כדאי לך לעשות.(רן) Fair enough . . . (דגן)  ובעצם, החלוקה הזאת היא ל-Bucket-ים, שתיארנו קודם - היא מאפשרת פתרון יותר חזק מאשר הפתרון הסטנדרטי, שאתה תגיד “אוקיי, המודל מפלה נשים, אז תיתן העדפה לנשים!”.כי אז אתה בעצם פוגע בביצועים של המודל . . . ופה אתה יכול לעשות משהו שהרבה יותר גרנולרי (Granular).אני לא צריך לתת העדפה לכל הנשים באשר הן - אני אזהה את המקומות שבהם יש בעיה ואני אטפל ספציפית בנקודות האלה.זה יכול להיות שידנית מישהו מהבנק יעבור על המקרים האלה.או אוטומטית - טיפול שונה באזור אחד, טיפול שונה באזור אחר.(אורי) יש פה . . .  לתקן או להעשיר Data לאימון - זה לא בדיוק אפליה מתקנת. זה לא אותו דבר.(דגן) נכון. אז קודם כל, אני אגיד שאנחנו לא מעשירים את ה-Data של האימון - אנחנו משתמשים ב-Data הזה בשביל לבדוק את המודל.בשביל להצליח לבחון אותו בצורה יותר טובה.(אורי) . . .  כדי להצביע ש”שם יש בעיה” .  . .(דגן) נכון, כן. אחד השימושים בטכנולוגיה הזאת זה שאנחנו יכולים גם להגיד איפה חסר מידע, ודיברתם על זה גם קודם.יכול להיות שיש לי איזורים שבכלל חסר שם ייצוג.אז אני צופה - ואני יכול לבדוק את זה - שהמודל, יהיו לו ביצועים פחות טובים שם.אז אחד ה-Output-ים הנוספים שאנחנו יכולים לתת הוא איפה כדאי לך להוסיף Sample-ים, במידה וזהאפשרי.23:07 אתה יכול להסביר את זה?(רן) אוקיי, בואי נדבר רגע על נושא אחר - נושא האקספליינביליות (Explainability). לצורך העניין, אני פקיד בבנק ואני רוצה עכשיו לבחון את האם ללקוח מגיע . . . אני רוצה לתת לו הלוואה, ואני מריץ את הנתונים במחשב - והמחשב אומר לי לא. אוקיי, מה אני עושה עם זה עכשיו? . . . אני רוצה איזשהו הסבר - למה הוא אמר לי לא? קודם כל, כדי  להבין, אולי זה טעות, ודבר שני - אולי אני גם צריך לנמק את זה, מתישהו. אוקיי?עכשיו מקודם, אורי - אתה הצעת איזושהי שיטה של אולי לנסות ערכים שונים ולראות מה יצא. להזיז קצת ימינה, להזיז קצת שמאלה - לשיטה הזאת יש שם. קוראים לזה SHAP, פחות או יותר. זאת אומרת, יש שיטה ב-Machine  ,Learning שבעצם מנסה להסביר התנהגות של מודל על ידי ניסיונות. היא קצת יותר משוכללת מזה, אבלבגדול היא יודעת לעשות את זה.אבל מי שאי פעם ראה SHAP, יודע שזה לא משהו שהוא רוצה להציג לפקיד בבנק. אוקיי? . . . . השאלה היא איך כןמסבירים מודל עם 100 . . . עם וקטור באורך 100 של Input ואיזשהו Output שהוא לא יודע, איזשהו מספר Float או Whatever. איך אתה בכל אופן מנגיש אקספליינביליות (Explainability) של מודלים כאלה ללקחות-קצה, שהם לא אנשי Machine Learning או Data Science?(דגן) אז קודם כל בוא נתחיל בזה שהבנקאי - הוא לא רוצה לתת הסבר, הוא חייב לפי חוק . . .לפי רגולציה, אם ביקשת משכנתא ואמרו לך ‘לא’, הלקוח זכאי לקבל הסבר ללמה הוא לא קיבל את המשכנתא - ומה הוא יכול לעשות בנידון.זאת אומרת, הבנק מחויב לתת את המידע הזה.ואם דיברת על SHAP, אז SHAP באמת זה משהו גלובלי - הוא נותן מין הסבר על באופן כללי איך שהמודל עובד ואיזה פיצ'רים חשובים יותר וחשובים פחות.ופה, מעניין אותנו דווקא ההסבר המקומי - ספציפית במקרה הזה.(רן)  עבור הלקוח הזה -  לא באופן כללי לאוכלוסייה, עבור הלקוח הזה. (דגן) אז אם אנחנו חוזרים ל-Bucket-ים של קודם, אז אנחנו יכולים להגיד בדיוק באיזה Bucket הלקוח הזה נופל.גם אם זה לקוח חדש, שלא ראיתי אותו באימון ולא ראיתי אותו בשום שלב אחר.ואני יודע מה מאפיין את ה-Bucket הזה - אני יודע איזה פיצ'רים חשובים שם, אני יודע איזה פיצ'רים לא חשובים שם.אני גם יודע להגיד יותר מזה, כי אני בעצם אומר “אוקיי, אני רואה איפה נקודה של ה-Sample הזה, של הלקוח הנוכחי, נפל” - והוא באמת לא קיבל משכנתא.אבל אני יכול מאוד בקלות להסתכל מסביב, ולראות מה הוא צריך לשנות כדי כן לקבל את המשכנתא הזאת.זאת אומרת, מה המסלולים - מסלולים בגרף הזה - ההכי קצרים, בשביל להגיע מ”לא” ל”כן”.(רן) אם זה נגיד שינוי ברמת ההכנסה, לצורך העניין, או שינוי באזור המגורים, או הורדה קלה בערך או בעלות המשכנתא, או משהו כזה.(דגן) וזה כבר הסבר שבנק יכול להבין - ויכול להנגיש אותו ללקוח.(רן) כן - וזה גם Actionable-י. זאת אומרת, הלקוח יכול כנראה לעשות עם זה משהו . . .(אורי) . . . יש לו מה לעשות עם זה, כן. אבל אני רוצה לדבר על הנושא של ה-Auditing, בסדר? שינוי במודל, או ב-Training של המודל, יכול פתאום לגרום לבנק או לחברת ביטוח לשנות את מדיניות החיתום שלה. ובסך הכל מה קרה? אימנו מודל . . . עכשיו, בחוקים של Auditing, של בקרות - זה “Big No-No”.אז איך מתמודדים עם זה?[דגן] אז קודם כל אני אגיד שזו אחד הסיבות שהגופים האלה - הם לא יכולים לעשות, נגיד, מודלים שלומדים On” the Fly”. הם לא יכולים לעשות Online Learning משום סוג - כי אסור להם, בשורה התחתונה.אבל גם אם היה מותר להם - הם לא היו עושים את זה, בדיוק מהסיבות האלה.אני לא רוצה לגלות יום אחד שהמודל שלי טעה, והיו דוגמאות ל...(אורי) פשוט אין לי את מי להאשים . . . .(דגן) אתה מאשים את ה-Data Scientist בסוף . . . (אורי) לא, “המודל טעה”, כאילו...(דגן) נכון, וזה באמת פחד מאוד גדול של כל החברות האלה.וזה לא רק בבנקים - זה באופן כללי.הרצון לדעת איפה אני יכול לסמוך על המודל - ואיפה אני פחות יכול לסמוך על המודל.וזה מאוד חשוב.ושוב, מאותם כלים שדיברנו עליהם קודם - זה עוד מידע שאפשר להפיק אותו.הפתרון שלנו, או פתרונות דומים, “ממפים את המרחב” בעצםויכולים להגיד לך “באיזור הזה יש לך סיכון יותר גבוה”“סיכון” במובן “שהמודל יטעה”, או שהמודל יעשה את מה שלא חשבת.באיזורים אחרים, אתה יכול לסמוך על המודל.כי למרות שזה איזור מורכב - מבחינת הצורה של המודל וכו - הוא אמין באיזורים האלה.“כשהוא אומר אז הוא צודק במה שהוא אומר” עכשיו אתה שואל “אבל איך אני יודע שההסבר או הצורה שבה המודל חושב היא נכונה, ושהיא תואמת את מה שאני רוצה ואת המדיניות חיתום שלי”?ופה עוד פעם נכנס ה-Explainability הזה לתמונה - ואחד הדברים שאפשר לעשות . . . אם אתה עכשיו ממפה את כל המרחב ויש לך את ה-Explainability עבור כל נקודה במרחב, אחד הדברים שאפשר לעשות זה להסתכל עכשיו על כל ההסברים האלה ולראות האם הם הגיוניים.אז אני למשל יכול לקבץ אותם ל-Cluster-ים ולהסתכל על כל Cluster ולהגיד “אוקיי, זאת המדיניות שלי בעצם - ה-Explainability של ה-Cluster זה המדיניות”.זה אומר “ גיל מעל ככה וככה והשכלה כזאת וכזאת” - וזה מה שמשפיע על החיתום, “כן” או “לא”.זה Cluster אחר - הוא מתנהג אחרת.ואם עכשיו יש לי Sample-ים שהם לא מתאימים לזהאז א' - אני יכול לראות שה-Explainability שלהם שונה, שיש לי פה איזו אנומליה, משהו שהוא חורג ממה שאני מכיר(אורי) ואת זה גם אפשר לבדוק אוטומטית . . . (דגן) ואת זה אפשר לבדוק גם אוטומטית וגם ידנית - זאת אומרת, יש לי משהו חורג, אז א' - אני יכול להגיד “רגע רגע רגע -  בוא נעצור”, ובמקרה “הקיצוני” נקרא לזה, יבוא הבנאדם, יבוא הבנקאי, ה-Domain Expert, יסתכל על ההסבר ויגיד “הגיוני” או  “לא הגיוני”, “אני מקבל את זה” או  “אני לא מקבל את זה”(אורי) . . . או שבעצם המטרה של האימון של המודל הייתה לתקן את הבעיה הזאת והזאת - זה באמת קרה, ולא נגרם שום נזק אגבי אחר.(דגן) נכון.(דגן) ואגב, גם בדרישות של הרגולציה, והיום זה ניהיה נושא מאוד חם, הרגולציות שיוצאות - האם זה טוב לשלוט על ה-AI, האם זה לא טוב לשלוט על ה-AI - דיון סוער בכל העולם, אבל בפועל זה קורה, רגולציות קורות.אז אחד הדברים שאומרים שם ברגולציה זה לא שאסור לך לעשות שום דבר ולא שאסור לך להפלות אף אחד באוכלוסייה - אבל “אתה צריך להראות לנו את ה-Tradeoff”.אתה צריך להראות לנו “מה היה קורה אם” -  כי אם עכשיו היית מפלה אנשים פחות, כמה אתה היית מפסיד מזה? כמה העסק שלך היה נפגע מזה?ויש להם איזה כללים, למתי זה בסדר ומתי זה לא בסדר.ועכשיו אתה צריך להוכיח שזה באמת המצב . . . (רן) קודם כל שבדקת . . . (דגן)  . . . קודם כל שבדקת . . .  ופה עוד פעם, אם אני חוזר לסימולציה - פה עוד פעם נכנסת הסימולציה הזאת לתמונה - אני יכול לסמלץ (Simulate)פעם אחת את המקרה הזה ופעם אחת את המקרה הזה - ולהראות ממש סטטיסטית את ה-Tradeoff הזה.בסוף, אנחנו נותנים מספרים, נתונים . . . . כל מה שאנחנו עושים בזה בסוף זה חישובים מתמטיים, זה סטטיסטיקותואנחנו מוצאים את הדוחות האלה כפירוט-טכני, שאחר-כך אפשר לתרגם את זה לכל מיני שפותלשפה של עורך הדין, לשפה של מי שזה לא יהיה . . . .30:54 תקרת-הזכוכית והדברים היותר “Cool-יים”(רן) אני שם רגע את הכובע של איש ה-Data Science או ה-Machine Learning - ונשמע לי שהפתרון הזה יכול לעבוד בפועל על מודלים יחסית פשוטים, מה שנקרא מודלים של Machine Learning “קלאסי” - אם זה עצי-סיווגאו רגרסיה-לוגיסטית או דברים בסגנון הזה, ואולי גם לדברים קצת יותר מתוחכמים. אבל “אין מצב” שזה יעבוד עבור Deep Neural Networks או כל הדברים ה-Cool-יים שפועלים היום. זאת אומרת, אם אני בתור בנקאי, ורוצה לשים איזשהו מודל Chat שיבוא ויסביר ללקוח האם הוא זכאי או לא זכאי ומה הוא צריך לעשות כדי כן להיות זכאי למשכנתא, כנראה שהכלים שלכם לא יכולים לעזור לי שם . . . (אורי) אבל השאלה, רן, האם צריך כלים כאלה? . . . (רן) לא משנה, עזוב, אני לא איש-המוצר כרגע - אני איש ה-Machine Learning . . . (אורי) . . . אתה מחפש משהו Cool לעבוד עליו? . . . (רן) כן . . . . לא, אז מה שאני שואל בעצם זה מהי כרגע תקרת-הזכוכית שלכם? זאת אומרת, לאיזה סוג של מודלים זה יכול לעבוד ואיפה אתם יודעים שפשוט לא כדאי לנסות אפילו?(דגן) אז קודם כל אני אתחיל בזה שזה בעצם תלוי בהגדרת הבעיה ולא באיךאתה פותר את הבעיה.זאת אומרת, אם הבעיה שלך היא לקחת כמה עשרות או מאות פיצ'רים (Features), ולקבל בסוף פרדיקציה (Prediction), כמו שדיברנו קודם - אז “לא אכפת לנו” אם אתה תפתור את זה עם Deep Neural Network או עם רגרסיה-לינארית או עם “קבוצה של הודים” שידנית מהר-מהר-מהר נותנים לך תשובה [הם מריצים מודל בעצמם . . . .]מבחינתנו, יש Input, יש Output - ואנחנו נדאג לכל מה שקורה באמצע.אז במקרה הזה, הטכנולוגיה היא . . .  ה-Framework שאיתו בנית את המודל לא מעניין אותנו.אבל כמו שאמרת, יש... (רן) אז ה-Output הוא סיווג - “כן” או “לא”, או אולי איזשהו מדד Risk, מספר Float - אבל לא יותר מזה.  אבל אם ה-Output הוא רצף של Token-ים, כמו שה-LLM מוציא - אז זה כבר סיפור אחר . . .(דגן) נכון - וזה בעצם מוצר אחר לגמרי.כל מה שדיברנו עד עכשיו זה מוצר מסוג א’ - ויש גם מוצר בעולמות האלה של ה-Generative AI.ופה באמת הגדרת הבעיה ישנה וגם ההגדרת הפתרון ישנה - וגם הרגולציה ישנה . . .זאת אומרת, אנשים - במקרה הזה לא מעניין אותם להגיד איזה Feature גרם לך להגיד מילה מסוימת.האקספלנביליות (Explainability) פה היא בצורה אחרת.פה בעצם מעניין אותך דברים כמו Hallucinations - איך אני יודע שמה שהמודל הוציא עכשיו זה אמיתי וזה לא סתם איזו המצאה שהוא”הזה”?אני רוצה לדעת על מה זה מבוסס - נתת לי איזושהי תשובה בנית Chatbot או איזה דוגמה שאני לא ארצה - על מה זה מסתמך? איפה הרפרנסים (References) האמיתיים לדבר הזה?(רן) הנה, אתה רואה, אורי -  זה לא רק אני! הם בונים מוצרים, זה לא רק אני מדמיין . . . (דגן) וזה . . . בוא נגיד שאם הגופים המאוד Regulated הם עדיין בעולם של ה-Machine Learning “הקלאסי”, אז הרבה חברות אחרות הן באמת כבר מאמצות טכנולוגיות יותר מתקדמות.ויש להן סט של בעיות אחרות - והתמודדות היא גם שונה.ואגב - זה יכול להיות אותו גוף. כאילו, אותו “בנק דמיוני” שדיברנו עליו קודם - כשהוא צריך לתת הלוואה, אז הוא משתמש במודל המאוד פשוט . . . (אורי) . . . כי התשובה שם היא “כן” או “לא”.(דגן) כי התשובה שם היא “כן” או “לא”.(אורי) . . . לא צריך פה לכתוב נאום לקונגרס . . .(דגן) . . . וכשהוא מפעיל שירות-לקוחות, אז הוא רוצה איזשהו Chat Bot GenAI מתוחכם - וגם שם יש עכשיו כבר  . . .הרשת מלאה בדוגמאות של לקוח ששכנע את ה-Chatbot למכור לו רכב בדולר אחד - וברגע שה”Computer says Yes”, אז הוא מקבל את הרכב שלו בדולר אחד. (רן) יש סיפור, אני חושב שעל Air Canada, שמכרו כרטיסים בזול מדי בגלל טעות של ה-Bot. (דגן) נכון . . .אז יש - הדוגמאות הולכות ומצטברות, לדברים האלה - והחברות באמת נלחצות מזה, ובצדק.זאת אומרת, הבעיות הן אחרות, הפתרונות הם אחרים - אבל המהות היא אותה מהות: “אמון”. “איך אני יכול לסמוך על המודל הזה, ששחררתי אותו לחופשי, שלא ימכור לי כרטיס טיסה במחיר מופחת או כל מיני דברים אחרים” . . .שלא יקנה בית . . . אחת הדוגמאות המוכרות - שלא יתחיל עכשיו לקנות בתים ולגלות שאין משהו שעומד מאחורי זה ואני אפסיד מיליונים . . . (רן) איך קראו לחברה הזאת? חברת הנדל”ן הזו? שכחתי . . .  (דגן) Zillow?(רן) כן, Zillow . [ד”ש - Why the iBuying algorithms failed Zillow, and what it says about the business world’s love affair with AI]35:10 עוד סוגי חברות ו-Domains(רן)  אוקיי אנחנו ככה כבר לקראת הסוף בואו נעשה איזשהו סיכום. אז דיברת על חברות שיש להן מודל Risk גבוה,ודיברנו בעיקר על פיננסים - במקרה, סתם -  אני משכתי לשם. אבל מה עוד יש שם ב-Domain הזה? איזה עוד סוגי חברות?(דגן) אז כל חברה שיש לה סיכון גבוה, בעצם. זה יכול להיות חברות ביטוח, זה יכול להיות חברות ביטחוניות, זה יכול להיות חברות רפואיות . . . .מפעלים שהם, שוב - ב-High risk.(רן) ובשבילכם זה Same-Same? כאילו, אתם יכולים לעבוד עם כולם? אתם לא צריכים אדפטציות (Adaptions)?אתם-עצמכם לא צריכים להיות Domain-Experts בכל אחד מהם?(דגן) אז יש פה שני אספקטים. באספקט של ה-Deep Tech - מספרים.יש לי Data-set אחד עם מספרים, שקראתי לזה “מודל חיתום”, ו-Data-set אחד עם מספרים שקראתי לו . . . לא יודע מה, “Digital Health” . . .(אורי) אבל במקום הזה, ה-Domain העיקרי שהמודלים האלה מתעסקים בהם זה הערכת ריסק? או לא קשור?(דגן) לא, לא קשור. אבל אז אני אומר - מבחינת הטכנולוגיה, “מתחת למכסה-המנוע”, “לא אכפת לי” מה המודל אומר, לא אכפת לי הסמנטיקה.אני יודע מה נכנס, אני יודע מה יוצא - זה מספיק.כמוצר - זה כבר מעניין.כי בסוף, אם אתה מדבר על בנקאי - הוא רוצה לדבר בשפה של בנקאים . . . (רן) צריך להבין מי הלקוח, גם לדעת איך למכור לו .. . (דגן) נכון, ואנחנו סטרטאפ קטן, אתה לא יכול “להתפזר על כל העולם”.ופה אתה רוצה כן לעשות את הספציפיקציה (Specification) הזאת.כאילו, כמוצר אתה תגיד “אוקיי, אני עכשיו אתן אתן מוצר ל-Fair-Lending: הוא מתאים לרגולציה של Fair-Lending, הוא בודק ריסקים (Risks) של Fair-Lending, וכו’.או לחילופין, מוצר שהוא . . . לא יודע מה - ביטוח סייבר!(רן) אוקיי, והלקוחות שלכם, שאתם עובדים איתם - הם בישראל? חו”ל? מה?(דגן) בעיקר בחו”ל, בעיקר צפון אמריקה. זה ה-Go-To Market.הסיבה לזה היא כוח אדם - צריך להתמקד, שגם לנו יהיה את ה-Expertise הזה.בסוף, אני בצוות הטכנולוגי - אבל צוות של ה-Business, חוץ מהדברים הרגילים שצוותי Business עושים, הם גם צריכים להיות מאוד מאוד עם היד על הדופק.במובן של איזה רגולציות יוצאות, איזה רגולציות עומדות לצאת.ואם עכשיו פתאום בכמה חודשים אחרונים, פתאום ה-EU-AI Act, שזה “ה-GDPR החדש” - הרגולציות בעצם על Machine Learning של האיחוד האירופי - יצאו כבר, בעצם זה כבר שהמדינות חתמו עליהם.עכשיו בונים איזשהו Timeline ליישום שלהם,אז “פתאום כולם קופצים” . . .(רן)  כולם מחפשים פתרונות - ואתם מגיעים עם מוצר חם לשוק.(דגן) נכון. אז אם לפני שנה-שנתיים, אנחנו היינו צריכים להסביר מה זה, ולמה זה טוב, ולמה צריך את זה - אז עכשיו באים אלינו, ואומרים “רגע, יש לכם פתרון עבור הדבר הזה, שהולך ליפול לנו על הראש?”38:14 יש מתכנתים ברפת?(רן) אוקיי, אז אתם מגייסים? מחפשים אנשים? מחפשים עובדים?(דגן)  תמיד.(אורי) אם אתם רפתנים לשעבר, אז...(דגן) רפתנים שיודעים לתכנת . . .(רן) איפה אתם יושבים?(דגן) תל אביב, שרונה, על הרכבת.(רן) יפה. אז תודה רבה - ושיהיה בהצלחה.מי שמעניין אותו לעשות Machine Learning קצת יותר בטוח, לעולם בטוח יותר - אז דברו עם דגן.להתראות, תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 475 של רברס עם פלטפורמה, שהוקלט ב-23 ביולי 2024, שיא הקיץ. אורי ורן מארחים את חופית מחברת AI21 Labs, כדי לדבר על מודלי-שפה גדולים עם Context ממש-ממש ארוך (וגם להסביר מה זה).00:40 חופית ו-AI21(רן) אבל קצת לפני זה - עליך, חופית, ועל החברה. מי את? מה עשית עד היום? מה עושים אצלכם בחברה?(חופית) אז אני חופית, ואני כרגע חוקרת ומפתחת מודלי-שפה בחברת AI21 Labs.נולדתי וגדלתי ברמלה, אם נחזור ממש להתחלה.בגיל 14 כבר התחלתי לתכנת - בבית הספר הכניסו אותנו לזה יחסית מוקדם - והבנתי שזה מה שאני הולכת לעשות כבר אחרי יומיים.אז הגעתי למודיעין, ליחידה צבאית, יחידה מודיעינית - דווקא לא תכנתתי שם, אבל ישר אחרי הצבא התחלתי תואר במדע המחשב באוניברסיטה העברית.מהר מאוד הבנתי שאני רוצה לשלב עם מתמטיקה. התאהבתי במתמטיקה - מתמטיקה תיאורטית, חשוב לציין, כי בתיכון לא כל כך אהבתי . . . אז עשיתי תואר משולב עם מתמטיקה.(רן) אז אם אני אבקש ממך עכשיו את הנוסחא של דטרמיננטה, את לא תדעי לשלוף לי . . .(חופית) ממש לא . . . (רן) . . . אבל תורת החבורות - בכיף . . . (חופית) תורת החבורות - אני מקווה שזה יהיה הדוקטורט שלי יום אחד . . . [ד”ש לגלואה].(חופית) ולקראת סוף התואר השני התחלתי לעבוד ב-Mobileye, בתור חוקרת - אבל בעולם ה-Vision. בעצם, כל עולם הראייה ממוחשבת וזיהויים, ופיתוח המכונית האוטונומית של Mobileye.וגם החלטתי שאני ממשיכה לתואר שני.בתואר השני, בהתחלה לא הייתי בטוחה מה אני רוצה לעשות - ידעתי שזה יהיה Machine Learning, ידעתי שאני רוצה לשלב גם תיאוריה.זאת אומרת, לא רציתי להתנתק מהתיאוריה.ובעצם התחלתי את את התזה שלי אצל פרופסור אמנון שעשוע.(רן) שמענו עליו . . . (חופית) כן . .(רן) נזכיר - אחד המייסדים של Mobileye, וגם של החברה, של AI21 . . .(חופית) נכון, ועוד כמה חברות כאלה ואחרות.וביום שהגעתי, המעבדה של אמנון עד אז התעסקה יותר ב-Vision, בקוונטים, בדברים כאלה ואחרים.כן בהקשרים כמובן של Machine Learning.וביום שהגעתי, אמנון פשוט החליט שעושים העברה לטרנספורמרים (Transformers) ול-NLP, כי יצאה עכשיו הארכיטקטורה.זה היה ב-2018, כשזה עוד לא התפוצץ - אבל אמנון ראה שזה הולך להתפוצץ.(רן) ימי BERT העליזים . . . (חופית) בדיוק, ימי BERT העליזים, לגמרי - זה היה הדבר הראשון באמת שהתעסקתי איתו.וככה הגעתי לתחום - זו הייתה הפעם הראשונה שבה בעצם נחשפתי לתחום בכלל.אפילו לא לקחתי קורסים ב-NLP לפני זה - אז זה באמת היה ממש כניסה שהייתה מאוד מפתיעה מצד אחד, ומצד שני הרגשתי שלא חסר לי יותר מדי רקע.כי טרנספורמרים היה משהו מאוד חדשני ושונה מהכלים שהיו קיימים לפני זה . . .(רן) . . . כולם פחות או יותר זינקו באותו זמן, זה היה איזשהו Equator, שהשווה את הסיכויים לכולם(חופית) נכון - אבל גם אם נסתכל על זה מבחינת מודל מתמטי, זה מאוד שונה מ-RNN ומ-LSTM, מה שהיה לפני, אז לא הרגשתי שיש לי יותר מדי פער, אפשר להגיד.(אורי) כמו לכולם . . . (רן) כן . . . . אז למי שזוכר את הרובוטריקים, כן היו שם טרנספורמרים - אבל לא עליהם אנחנו מדברים . . . . Transformer זה ייצור מתמטי, שמשתמשים בו ברשתות-ניורונים. למעשה, הוא ה-Building-Block המשמעותי בתוך מנועי-שפה גדולים. והזכרנו מקודם את BERT - זה היה אחד ממנועי-השפה הראשונים שהשתמשו ב-Transformer, אם לא הראשון בכלל . . . . זה הראשון או אחד הראשונים?(חופית) אני חושבת שהוא הראשון . . . . הוא היה Encoder-Only.(רן) כן, Attention Is All You Need . . . . אוקיי, אז היית במעבדה של פרופסור אמנון שעשוע . . . (חופית) . . . . ושם נכנסתי לתחום. ביליתי שם בערך שנתיים - הוצאנו תזה שיש בה גם פן תיאורטי וגם פן טכניבעצם, דיברנו שם וחקרנו את ה-Tradeoff שבין עומק ורוחב של רשת“עומק” זה אומר כמה שכבות יש לה, וכשאנחנו מדברים על “רוחב” זה לרוב מימד-ההטלה (Projection), “הגבוה” שאנחנו מגיעים אליו כשאנחנו מטילים את הוקטורים של האינפוטים (Input vectors) שנכנסים למודל, שתיכף נדבר גם על זה יותר.בגדול, חקרנו את זה כי הבנו וראינו - גם הבנו תיאורטית, לשם אני פחות אכנס - אבל גם בעצם עשינו ניסויים ממש פרקטיים, שמראים את זה.שמה שהתרגלנו עד היום במודלי Vision, בכל הרשתות-קונבולוציה (But what is a Convolution?), זה שבעצם הרבה פעמים היא הייתה יחסית “צרה” ומאוד מאוד “עמוקה”.אנחנו מדברים על איזה 90, 120 אפילו 150 שכבות.ובטרנספורמרים (Transformers) פתאום זה קצת משתנה.אז באמת חקרנו את כל ה-Tradeoff הזה, הגענו למסקנות כאלו ואחרות ולכל מיני סוג-של-נוסחאות, שבעצם מראות מתי עדיף שרחב יותר, מתי עדיף שיהיה צר יותריותר רדוד או עמוק יותר.(רן) זאת אומרת שבאותו מספר פרמטרים, נגיד מיליארד פרמטרים - היום הרשתות, רק כדי לסבר את האוזן, הרשתות “הקטנות” זה שבעה מיליארד, בגדולות זה מאות-מיליארדים - אבל גם שם אפשר להחליט עד כמההרשת היא עמוקה או רחבה. זאת אומרת, הגעתם לאיזושהי נוסחה של מה ה-Tradeoff העדיף בהינתן Use Case.(חופית) נכון, ובעצם AI21, החברה שאז לא הכרתי בשלב הזה, אימצה את השיטה שלנו - וככה גם לראשונה נחשפתי אליהם.למה אימצה? כי AI21 מאמנת מודלי-שפה מאפס בעצם, Foundation Models, את כל שלב ה-Pre-Train, ממש ממש מאפס, משקולות מאותחלים ראנדומית (Random Initialization) לגמרי, כבר המון שנים.וזו החברה היחידה שעושה את זה בארץ.אז ככה הגעתי אליהם - כי ידעתי שזה מה שאני רוצה לעשות.(אורי) אז רגע רגע - אולי תספרי לנו שנייה מה עושה AI21? חוץ מלאמן מודלים “לצורכי שעשוע” . . . זה משחק מילים, . . .(חופית) אז באמת, כל הפן של חדשנות טכנולוגית מאוד מאוד חשוב לנו, שעל זה גם ניכנס גם עם Jamba וניגע בזה ולמה ואיך.אבל היא בעצם מנגישה מודלים לעסקים כאלה ואחרים - אם זה בתחום ה-Finance ואם זה בתחום הבריאות ודומיינים (Domains) כאלה ואחרים.זאת אומרת, הרבה פעמים זה לעסקים שצריכים ממש את ה-Domain הספציפי שלהם, ומודל שאפילו הרבה פעמים המשיכו לאמן אותו על ה-Data הספציפי שלהם.והיום, רוב התעשייה לא יודעת לעשות את זה בעצמה - היא צריכה את האנשים שיעשו את זה בשבילה, ולהתבסס על המודלים שלהם גם.(אורי) אז בא לקוח, יש לו Data, הוא יודע מה הוא רוצה להשיג מה-Data הזה - והוא בא אליכם, ואתם מאמנים לו מודל?(חופית) נכון, כן. “בין היתר”, אפשר להגיד . . . הרבה פעמים אנחנו מכוונים אותו למה הוא רוצה - כי הוא רוצה דברים מאוד גדולים,ואבליואציה (Evaluation) של מודל - זאת אומרת, השלב שבו אתה עושה לו טסט על בכלל מה אתה רוצה ממנו - זה שלב שהוא אתגר בפני עצמו.אם נשים רגע את האימון של המודל בצד, שזה האתגר שלי בצוות, אם אני כרגע בעצם בצוות של ה-Pre-Train Model ב-CTO Office, אני חוקרת שם.אז אנחנו עושים בעצם את כל השלב של ה-Pre-Train, כל השלב הראשוניויש את השלב של אבליואציה (Evaluation) של הטסטים - של איך בכלל אנחנו בוחנים אותו.(רן) האמת שהיום היו לי שלוש פגישות על זה . . . כן, זאת אומרת, יש דומיינים (Domains) שבהם אתה - יש לך איזשהו Ground Truth, זאת אומרת, אתה יודע מתי התשובה נכונה. עם LLM-ים, אין לך את זה בדרך כלל - אתה לא יודע מתי “הוא עושה עבודה טובה" או לא, וצריך לפתח גם את זה. כן, זה מורכב . . . .אוקיי, אז  את אומרת שעוזרים ללקוחות להבין מה הם רוצים - ומדלברים (Deliver) את מה שאתם יודעים בכיוון הזה. (חופית) נכון - וגם חשוב לנו לתרום לקהילה. זאת אומרת, אנחנו לא סתם שחררנו את Jamba כ-Open Source, כי רצינו באמת לראות מה הקהילה עושה,.מה היא לוקחת ומה היא עושה איתו.זה מאוד היה חשוב לנו לראות ההתפתחויות של הדבר הזה.09:13 מה Jamba?(אורי) טוב, אז זה פעם שלישית שאמרתם “Jamba” . . . (רן) . . . עכשיו צריך להסביר . . . . כן, אז מה זה Jamba? אולי אפשר גם להתחיל היסטורית מה זה Mamba,  “האימא שלו” . . . [לא קובי?](חופית) נכון, אז בטרנספורמרים קצת נגענו - ואולי ניכנס קצת לטרנספורמר לפני שאנחנו בכלל מדברים על Jamba, על בעצם למה מגיעה המוטיבציה לדבר הזה, לשילוב ארכיטקטורות.אז ה-Core העיקרי, הדבר העיקרי, “הבלוק העיקרי” בטרנספורמרים בעצם, שהביא את כל החידוש, זה בלוק שנקרא Self Attention.שזו בעצם איזושהי מטריצה, שמתארת אינטראקציות בין כל Input - לעצמו.זאת אומרת שכל Token - יש לו איזושהי . . . .ובעצם זו מכפלה-וקטורית שקורית בסוף - אבל זה איזשהו Score או . . . בעצם, כמה יש לי אינטראקציה עם ה-Token שהיה לפני בסדרה.זאת אומרת, לכל ה-Token-ים, לאורך כל ה-Context.אז בהינתן סדרה - יש את החישוב הזה שקורה, ואפשר לקרוא לו . . .(רן) . . . סליחה, אני אתן דוגמא -   . . . (חופית) כן, מעולה(רן) . . .   - “איש עומד ליד עץ - האם הוא יפה?”. “הוא” - מתייחס לאיש או מתייחס לעץ? המילה “הוא”. אני אגיד שוב את המשפט - “איש עומד ליד עץ, האם הוא יפה?”. זה דו-משמעי, נכון? האם המילה “הוא” מתייחסת לעץ או מתייחסת לאיש, שעומד לידו? אנחנו לא יודעים. המטרה של ה-Self-Attention היא למעשה למקד את ה-Attention של המילים האחרות אל הסובייקט, אל החלק במשפט, אל ה-Token במשפט שהוא למעשה הנושא שלשאליו מתייחסים - וזה משהו שהיה מאוד מאוד קשה לעשות לפני הטרנספורמרים, ובאמת מה שחופית מסבירה זהשהטרנספורמרים בעצם נותנים לנו כלי-מתמטי לעשות את זה, וזו החדשנות האמיתית.(חופית) נכון, זו אחלה דוגמה. למשל, אם נסתכל על מטריצה אחרת או על מודל שאומן כבר, אנחנו אכן נראה שכנראה “הוא” מתייחס . . .  אנחנו נראה Score יחסית גבוה של “הוא” ו”עץ” ושל “הוא” ו-”האיש”זה למשל מה שרואים בסוף המטריצה הזאת אחרי שהיא מאומנת.אחרי שכל הפרמטרים כבר מאומנים, נעשה את ה-Self-Attention וזה מה שנראה.אז מה שקורה בעצם זה שיש לנו את המטריצה הזאת בכל Block Attention . . . (רן) . . . . שזו יכולת שהייתה חסרה לפני זה - הזכרת את זה ככה ביעף: RNN-ים נתנו פתרון מאוד מאוד חלקי לסיפור  הזה, ולמעשה הטרנספורמרים נותנים פתרון מאוד יפה. אבל . . . .(חופית) אבל כמו שאמרנו - זו בעצם מטריצה שהיא אורך ה-Input על אורך ה-Inputכי כל Token - יש לו אינטראקציות עם כל שאר ה-Token-ים, זה ממש מחושב, כל ה-Score הזה, הממוצע המשוקלל הזה.וכשאנחנו מגיעים כבר לסדרות באורך 256K Token-ים למשל, שעל אורך הסדרה הזאת אימנו את Jamba בין היתר, אז אנחנו מדברים על חישוב שהוא כבר ריבועי באורך ה-Context, באורך הסדרה.ואם ניכנס לזה אפילו יותר ונדבר על זה שבזמן, ב-Inference Time, זאת אומרת שעושים Decoding, כשאנחנו מייצרים בכל פעם את ה-Token הבא, אנחנו שומרים איזשהו . . . זה נקרא KV-Cache - ל-Token-ים  הקודמים שהיו.כי אתה לא רוצה לחשב על כל פעם מחדש - זה מאוד מאט לך את האימון.אבל אז השמירה של של הוקטורים האלה, כשיש לנו קונטקסט מאוד מאוד ארוך, ולכל אחד ממנו בעצם יש וקטור כזה . . . בכל Block-Attention, לאורך כל הטרנספורמר - זה בעצם כבר תופס המון המון זיכרון.אז זה לא רק עניין של Latency - שאנחנו בעצם מחשבים הכל וזה מאט אותנו - זה גם עניין של זה שזה תופס הרבה זיכרון.(רן) וגם חשוב להגיד - זה לא רק פוגע באימון. אז נניח יש כאן “טונה כסף” באימון, אבל הצלחנו לאמן. אבל זה גם פוגע ב-Inference. זאת אומרת, כשרוצים להשתמש במודל, אז אני גם צריך “טונה של זיכרון ב-GPU” - וזה יקר . . . .(אורי) כדי לסרוק את כל המטריצה הזו . . . (רן) כן, כדי להחזיק את זה . . . . עכשיו, אם מדובר על משפט פשוט בן עשר מילים, אז אוקיי - אז מאה, עשר בריבוע זה מאה, סבבה. אבל כשאנחנו מדברים על Context מאוד ארוך, כמו נגיד ספר או סרט, אז מספר ה-Token-ים הוא ענק, מגיע למאות אלפים, כמו שאמרת 256K . . . (חופית) נכון מאוד, ואם כבר מדברים על ספר או סרט - אז למה בכלל מעניין אותנו ספר או סרט? אז לאחרונה, אנחנו בעצם מחפשים כל פעם להתאים את עצמנו לדברים החדשנים - כרגע - בתעשייה.ו-Retrieval למשל זה אחד הדברים היותר מדוברים כרגע.שמה זה אומר? זה אומר שכשאני מבקש איזשהו Output מהמודל שפה, יש לי Instruction שאני נותן לו - ואני לאו-דווקא רוצה שהוא יתבסס על הידע שלו.זאת אומרת, אני לא רוצה שהוא ייתן לי “בשלוף” פשוט פרדיקציה (Prediction) של המודל.הייתי רוצה שלפני זה, יהיה איזשהו שלב מקדים - של כלי, שמביא בעצם כל מיני מסמכים שמתאימים לשאילתה שלך, מסמכים שמגיעים ממקור שהוא אמין ובטוח.ועל בסיס זה . . .  זאת אומרת, המודל יראה את כל המסמכים האלה כ-Prompt, והוא יג'נרט (Generate) לך תשובה בהתאם למסמכים האלה.אז כשאנחנו כבר מגיעים ונכנסים לעולמות ה-Retrieval האלה, שאנחנו מגיעים ל-Context-ים שהם מאוד מאוד ארוכים.אתה יכול לקבל מסמכים, שאולי לא כל המסמך קשור, אבל חלקים בו קשורים אז אתה כן מקבל את כולו.המודל בעצמו יודע לעשות האדפטציות (Adaptations) המתאימות - אבל בסוף, ה-Context הופך להיות מאוד ארוך. (רן) בואי ניתן דוגמא - נגיד, רופא בבית חולים שרוצה להתייעץ עם מנוע-שפה: “מה הבעיה של איציק?”. אוקיי, הגיע חולה, קוראים לו איציק, והוא רוצה לשאול אותו מה הבעיה שלו [הוא חושב שהעולם יפה?]. אוקיי, נניח שהוא אומר שיש לו תסמינים, לא יודע - חום גבוה, דופק וכו’. אבל מה המנוע-שפה לא יודע? את כל ההיסטוריה הרפואית של איציק, נכון [שלא לדבר על תל אביב ב-80s]? ובלי להבין את ההיסטוריה הרפואית של איציק, אי אפשר או שקשה מאוד לתת פרוגנוזה או דיאגנוזה או איך שקוראים לזה. אבל אנחנו יכולים לעזור לו - אנחנו יכולים לשלוף מתוך ה-Database את ההיסטוריה הרפואית ולבוא ולהגיד לו ב-Prompt “הנה ההיסטוריה הרפואית של איציק”, וזה יכול להיות ספר, זאת אומרת שזה יכול להיות הרבה הרבה דברים. “בהינתן זה, עכשיו תגיד מה הבעיה של איציק”, בהינתן שיש לו לחץ דם ודופק גבוה. זה משהו שאפשר לעשות רק עם Context מאוד ארוך, נכון? כי צריך לספק אתכל ההיסטוריה הרפואית. אז זה Use Case אחד. (חופית) נכון - ויש גם את עולמות הקוד, שניהיו נורא מבוקשים, שאנחנו מדברים ב-Repo-ים שלמים, שהמודל יכול להחזיק בעצם ב-Context שלו.ויש את עולמות ה-Chat - שאתה בעצם מתחיל Chat עם איזשהו מודל-שפה כזה או אחר, השיחה מאוד מאוד מתנפחת, אתה מקבל סוג של Out of Context - “אין לי Token-ים יותר! בוא נתחיל שיחה חדשה . . . “.אז בעצם אנחנו רוצים להיתגבר על הקשיים האלה באמצעות אימון מודלי-שפה ל-Context-ים ארוכים.(רן) אז זו המוטיבציה, ואם עד עכשיו דרך אגב, מי שכן משחק עם אימון שפה והרבה פעמים מוגבל באורח ה-Context,אז החדשנות פה היא שעכשיו ה-Context הולך להיות הרבה הרבה הרבה יותר ארוך. וראינו גם עבודות מחברות אחרות על Context-ים ארוכים, ואני מניח שגם הם משתמשים בדברים כאלה. אוקיי.16:28 איך פותרים את בעיית ה-Context?(רן) אז איך פותרים את בעת ה-Context? אמרנו שבטרנספורמרים, צרכי הזיכרון גדלים ריבועית כגודל ה-Input, וזו בעיה . . .  אז איך כן פותרים את זה?(חופית) אז זה גם זיכרון וגם בעצם ה-Latency עצמו - המהירות שבה אנחנומחשבים את המטריצה הזאת, לאורך כל הטרנספורמר.אז בעצם, לאחרונה יצאו כל מיני מודלים שהם לא מבוססים Self-Attention, מודלי-שפה שהם מבוססי State-יםכמו ה-RNN-ים שאנחנו מכירים - זאת אומרת ש-Token נכנס, יש לנו איזושהי הכפלה במטריצה שקורית, ויש לנו State שמתעדכן בכל פעם שה-Token הבא נכנס.(רן) כלומר, “מה קראתי עד עכשיו במשפט?” - זה ה-State.(חופית) נכון, “מה קראתי עד עכשיו במשפט”, בדיוק.אבל ה-State הזה מתעדכן כל פעם - זאת אומרת, ה-Token לא יוצר איזושהי אינטראקציה עם כל ה-Token-ים שהיו עד עכשיו. אלא רק עם ה-State, כפי שהוא עודכן עד עכשיו.(אורי) אבל ה-State הוא בעצם ה-State של המטריצה - מעובד בצורה כלשהי . . . המטריציה שהייתה עד עכשיו.(חופית) נכון - אבל הוא כבר ראה המון Token-ים עד עכשיו . . . (רן)  זה איזשהו “סיכום”, סיכום-ביניים - “הנה זה מה שקראתי עד עכשיו”.(אורי) . . . איזשהו Inference מסוים של מה היה עד עכשיו. (חופית) כן, נכון. (רן) . . . . ואז האינטראקציה היא Order of 1, פחות או יותר, אם אני מבין אותך. או קרוב לזה . . .(חופית) כן, אפשר להגיד. אם מסתכלים על זה בהשוואה ל-Attention אז אפשר להגיד.(רן) כן, אבל רגע - אבל זאת לא בדיוק הבעיה ש-RNN נתקלו בה? זאת אומרת, גם ה-RNN-ים ניסו לסכם איזשהו  State, והם עשו את זה ביעילות אבל לא באפקטיביות אם נקרא לזה . . .  זאת אומרת, הם “לא סיכמו את זה טוב”.אז איך המודלים החדשים  . . . .?(חופית) נכון. אז הם לא סיכמו את זה טוב, היו כל מיני בעיות כאלה ואחרות.מה שקרה זה שבעצם ב-RNN זה שמהר מאוד אתה “שכחת את ה-Token-ים הראשונים שלך”, וזאת הייתה אחת הבעיות.(רן) זאת אומרת שהם לא זכרו את ההיסטוריה היותר רחוקה, אולי את השלושה-ארבעה . . . עכשיו, כשאת אומרת “Token”, אני מתרגם את זה ל”מילה” - זה פחות או יותר אותו הדבר, לא בדיוק. אבל נגיד שיש משפט מאוד מאוד ארוך - אם יש משפט קצר אין בעיה, הם מבינים אותו וסבבה - אבל אם יש משפט ארוך, הם שכחו כבר מה היה בהתחלה,כמו שקורה לי לפעמים כשמדברים אליי . . . (חופית)  נכון - זאת אומרת שאם נרצה באמת לשחזר את המשפט, הוא מצליח לשחזר את החלק השני שלו, אבל לא את החלק הראשון שלו. לא משפט - אנחנו מדברים על פיסקה או יותר מזה . . .(רן) כן - “ספר”. ו-Mamba פותר את זה? איך?(חופית) אז ה-Mamba  . . . . בעצם, יש כל מיני דברים, יש כל מיני שיטות לאתחל את המטריצה הזאת, שבעצם על בסיסה אנחנו כל פעם מעדכנים את ה-State.את ה-State הזה, שאחר כך רץ בין כל Token-ים.אז יש כל מיני שיטות כאלה ואחרות - יותר שיטות מתמטיות, שבעצם עוזרות יותר לתת משקלים גם ל-Token-ים שהיו בעבר.שיהיה להם יותר משקל, שאתה לא “שוכח” אותם, אתה כן נותן להם יותר משקל.וזה לא רק זה - ה-Mamba, בעצם החידוש שלהם היה גם שאומנם המטריצה הזאת, שמעדכנת את ה-State, היא מטריצה אחת ויחידה, אבל יש עוד כל מיני מטריצות שנכנסות לתהליך.ששם, לכל מטריצה, לכל Token, היתה מטריצה משלו.זאת אומרת, המימדים שלנו הם כבר לא היו על מימד אחד, אלא כן על מימד אורך הסדרה.אז אתה אומר לעצמך “רגע, אבל שוב אני מגיע למצב ש...”(רן) “שאני מרגיש מרומה קצת . . . .”(חופית) נכון . . .  אז איך אני עושה את זה, אם שוב יש לי משהו שתלוי באורך הסדרה? אז מה קורה פה?אז בעצם, Mamba - הגישה החדשנית שלהם הייתה ש”אנחנו עושים את זה בצורה יעילה”, וזה נכנס לרמת החומרה (Hardware) אפילו .הם ייעלו את זה ברמת ה-Copy מרכיב זיכרון אחד לרכיב זיכרון אחר ב-GPU, הרכיב הרחוק יותר והקרוב יותר.“איך אני מצמצם כמה שיותר את ה-Copy האלה, את העתקות משני הרכיבים וכו’.אני לא אכנס לזה יותר מדי . . . (רן) אוקיי, כלומר - דרישות-הזיכרון נשארו בערך אותו דבר, אבל ה-Latency פחת? או שגם דרישות-הזיכרון . . . .(חופית) יש יותר דרישות-זיכרון. לא כמו דרישות . . . . בסוף זה כן - ה-State בסוף כן נשאר ומתעדכן, ה-State עצמו כן מתעדכן ע”י מטריצה יחידה.אבל דרישות-הזיכרון הן הרבה פחות מטרנספורמרים, כמובן.הן כן יותר מ-RNN-ים - אבל שוב, הכל עניין של Tradeoffs, כי Mamba מאוד משמר את ה-Token-ים הראשונים האלה.(רן) כן אוקיי - זאת אומרת, זה איזשהו Sweet-Spot בין ה-RNN-ים, שהיו “שוכחים” הרבה, לבין הטרנספורמרים  - שהיו זוכרים “הכל”, אבל גם היו מאוד “בזבזנים” מבחינת זיכרון וגם, כמו שאמרת, מבחינת Latency.(חופית) נכון - ואנחנו חשבנו מאוד לאפטם (Optimize) את ה-Inference בעיקר, אפילו יותר מאשר את האימון.כי בסוף, הלקוח זה מה ש...21:14 מ-Mamba ל-Jamba ו-Mixture of Experts(רן) אוקיי. עכשיו: Mamba זה איזושהי שיטה וזה משהו שהוא ככה, Widespread - ואתם לקחתם ובניתם מודליםמשלכם, שקראתם להם Jamba. אז מה קורה שם?(חופית) נכון. אז קודם כל, אם נסתכל באופן כללי על טרנספורמרים, מודלי שפה, או שנקרא לזה Deep Neural Network - זה בעצם המון המון בלוקים שמקונקטים (Concatenate) אחד אחר השני.כל בלוק הזה - יש לו Input שהוא באורך הסדרה, ו-Output שהוא באורך הסדרה.אז אם נסתכל על כל בלוק הזה בנפרד, נגיד לעצמנו “זה לא מדע נורא נורא קשה או מאתגר”, לחבר את הדברים האלהכי זה כל היופי בבלוקים האלה - גם של ה-Self-Attention וגם של ה-Mambaומזה אתה בעצם יכול לבנות רשת עמוקה.אז קודם כל, יש לנו בעצם גם את ה-MLP, שזו השכבה הליניארית בעצם - שאנחנו מטילים למימד גבוה יותר, ואז  מחזירים למימד נמוך יותר, כדי תמיד להיות באותה מימד שאיתו נכנסת לרשת, לבלוק.אז זה בעצם מה שעשינו - שילבנו. הגענו לאיזושהי נקודה, שהיא גם עם Latency יחסית טוב - כרגע פי שלוש ממודל Transformer-Only, Self-Attention-Only.(רן) . . . זאת אומרת פי-שלוש יותר מהיר . . .(חופית) . . . פי-שלוש יותר מהיר - על Long-Context, על קונטקסטים ארוכים.ומצד שני - לא איבדנו מה-Accurecy של המודל, מכמה הוא “טוב”, מכמה . . . .זאת אומרת - על המון Benchmark-ים מוכרים היום, ראית איך Mamba . . .כי  לפני זה, עשינו המון המון אבלציות (Ablation) עד שהגענו לדבר הזה, בכלל לשילוב הזה.חשבנו שאנחנו נוציא בהתחלה מודל שהוא רק Mamba ומודל שהוא רק טרנספורמר - ואז ראינו של-Mamba יש את הבעיות שלושאני אתן לכם דוגמא - יש למשל את כל נושא ה-Few-Shots - זה כשאני אתן לך איזשהו From פורמט של Input ו-Output, אתן לך כמה דוגמאות, והייתי רוצה שבשאלה הבאה שלי, תוציא לי את אותו Format, אוקיי? למשל...(רן) נגיד, אם אתה זוכר ממבחן פסיכומטרי - אנולוגיות: “בית לדלת, זה כמו מטבח למקרר”, זה כמו... “עכשיו, תן לי עוד אחד!”(חופית) נכון. אז אנלוגיות זה עוד משהו קשה - אני אלך אפילו למשהו קל יותר, אני אלך לביקורות.ביקורות הכי בסיסיות - על הסרטים, של Negative ו-Positiveאז נתת לו כמה דוגמאות, ואמרת לו “תן לי עכשיו ביקורת על הדוגמא החדשה הזאת”ובמקום להשתמש ב-Positive או Negative, שממש-ממש חשוב לך שזה יהיה מדויק ל-Input של ה-User שלך, הוא יכול להגיד לך “Nice”, או “Bad”, או להשתמש לאו דווקא ב...(רן) כן, זאת אומרת - להגיד לו “הנה, תענה בסגנון של שלושת הדוגמאות הבאות” - ומעכשיו הוא עונה בסגנון של שלושת הדוגמאות שנתתי לו.(חופית) נכון - אז את זה הוא לא עשה, הוא לא השתמש בדיוק באותו פורמט, וזה מאוד מזכיר Stateכי State בעצם שומר באיזשהו מקום את “המהות” של המילה - לאו דווקא את המילה עצמה.זאת אומרת, את המשמעות שלה, או מה היא אומרת.אז זו הבעיה שנתקלנו בה, וזה אכן . . .  כל הבנצ'מרקים (Benchmarks) שהיו מבוססים למשל, על Few-Shot, או בכלל על פורמטים מסוימים של איך שאלה ותשובה אמורות להיראות - שם Mamba היה נופל.ואז, פשוט אמרנו “אז בואו נשלב!”בסוף, Sequence to Sequence - נכנסת סדרה, יוצאת סדרה, של Token-ים.אז בעצם, שילבנו את שני הדברים האלה - ביחס שהוא יחסית כל . . . .שבע שכבות, שיש בהן בלוקים של Mamba, ואז עוד שכבה אחת של Attentionכי כמו שאמרתי - ה-Attention היה מאוד “מעיק”, מבחינת זיכרון ו-Inference Time, ב-Long Context, שהיה חשוב לנו מאוד מאוד לאפטם (Optimize).(רן) זאת אומרת, אם מנועי-שפה, מתקופת BERT ועד פחות או יותר מלפני שנה, השתמשו בהרבה בלוקים של טרנספורמרים, את אומרת שהגיע המאמר של Mamba ואמר “בואו, את כל הטרנספורמרים תחליפו בבלוקים של Mamba” - ואז אתם באים ואומרים “אוקיי, נחליף כמעט את כולם, אבל נשאיר כמה טרנספורמרים”, והם עושים את העבודה, הם בעצם נותנים תוצאות יותר טובות.(חופית) נכון, כן, בדיוק.כן יצא לנו לעשות . . . בעצם, המאמרים שיצאו על Mamba, זה היה על מודלים מאוד מאוד קטנים, כל הניסויים.על מודלי מיליארד אחד, אפילו שבעה מיליארד.ואנחנו נכנסנו כבר לעולמות של  . . . . אמנם, זה ה-Jamba ששחררנו היה מודל של 12 מיליארד Active Params, שתכף אני אסביר מה זה.אבל כל המודל היה 50 מיליארד פרמטרים - שזה המון.והתחלנו גם לאפטם (Optimize) את הדברים ב-Mamba עצמוראינו שהאקטיבציות (Activations), למשל - שהגדלים של הוקטורים שהוצאנו ב-Mamba ממש “מתפוצצים”, נהיים עצומים. אתה צריך להוסיף Layer Normalization, אתה צריך כן להיכנס קצת לדברים שהם יותר “פנימה”זה לא איזשהו משהו סגור לחלוטין, שאתה לא נוגע בו.אז כן היה את האתגרים שם, שזה אתגרים באופן כללי של מודלים גדולים, כשאתה נחשף למודלים.זה היה, אני זוכרת כשעברתי מהתזה - פתאום בתזה, כשאתה מאמן מודלים קטנים, ללאמן מודלים גדוליםאתה נחשף לאתגרים אחרים לגמרי . . . (רן) האמת שזה קורה כמעט בכל מערכת גדולה . . . . כל מי שתחזק חוות-שרתים באינטרנט יודע שדברים שכמעט אף פעם לא קורים - יקרו . . . . כי יש פשוט כל כך הרבה מחשבים, כי יש כל כך הרבה דיסקים, כי יש כל כך הרבה כבלי-רשת - משהו רע יקרה, גם עם הסבירות שלו מאוד מאוד נמוכה. אז ככה זה גם רשתות מאוד מאוד גדולות - גרדיאנטים (Gradient) נעלמים או מתפוצצים, או כל מיני דברים כאלה, שאולי בלימודים זה נראה כמו משהו זניח, אבלבמציאות וברשתות כאלה גדולות זה קורה.(אורי) אבל זה גם כאילו . . . . העולם של התעשייה מתעסק בסוף במה שקורה באמת; בעולם של האקדמיה הם  מחפשים את ה-Novelty, ולא . . . (חופית) אני מסכימה . . . (אורי) . . . . העולם האמיתי הוא Outlier . . . . [באמפר סטיקר?](חופית) נכון, אני גם חושבת שאני ממש רואה את זה ככה.אני הייתי חוקרת בתזה, והפכתי להיות  . . . . נקרא לזה מ-Deep Learning Researcher, ל-Deep Learning Engineer Researcher.כי פתאום, למקבל מודל . . . כי מודל גדול - אתה חייב למקבל אותו, הוא לא ייכנס לך.גם כשאתה מגיע לשכבה היחידה שאתה כרגע מתעסק בה באימון - היא לא תיכנס לך בזיכרון. זה לא יקרה.ואז יש כבר Model Parallelism - אתה מתחיל לחלק את ה-Tensor-ים של הפרמטרים שלך בין GPU-ים  שונים.זה פתאום להתעסק עם דברים שאתה לא... זה ממש מרגיש שלא נגעתי בהם לפני זה - וזה עולם ומלואו.וזה עולם שצריך לחקור בו. אז זה...(אורי) בסוף, זה ה-Blocker-ים . . . . (חופית) נכון ,זה ה-Blocker-ים  . . . . אלו בדיוק ה-Blocker-ים.(אורי) אז רציתי לשאול כאילו... בין ה-Mamba ל-Jamba קצת התבלבלתי. הבנתי שהתוצאות ב-Jamba נהיות יותר טובות, שפתאום אנחנו מצליחים להכניס... אני לא יודע אם זה לא Context, אלא יותר...(רן) Inputs יותר?  . . . “מבין יותר טוב”?(חופית) הוא יותר “Context-aware”, בוא נקרא לזה.(אורי) כן ... הוא “מקבל טון” בתוצאות שלו. אבל כשאת אומרת “בסדר, לקחנו כמה State-ים של ה-Jamba”,והוספנו כמה... סליחה, “ . . . כמה State-ים של ה-Mamba, והוספנו עוד כמה טרנספורמרים” - בסוף, מה קרה לזיכרון?(חופית) אז הזיכרון . . . אז אתה מוצא את ה-Tradeoff, אתה מוצא את ה-Tradeoff ביניהם.אז אתה לא תהיה עם הזיכרון הכי מינימלי שתקבל רק עם Mamba-only, אבל אתה כן חסכת המון.אני יכולה להגיד לך שלפחות ב... אני אתן לך דוגמא: ב-Inference time של 256 - של Context באורך של 256K, אם ניקח מודל שהוא זהה ל-Jamba שהוצאנו, אבל Transformer-only, ה-KV Cache שלו יהיה בגודל של 32GB, על ה-Context הזה של 256K,ואם זה יהיה... וה-Jamba שלנו מגיעה ל-8GB - אז חסכנו פה לא מעט...(אורי) אז בכל מקרה זה חיסכון . . . .(רן) עכשיו, שימו לב - זה לא Disc-Space - כי Disc-Space לא חסר. מדובר פה על זיכרון ב-GPU, וזה מאוד מאוד  יקר. אוקיי? תסתכלו בטבלה של מחירים של AWS ותבינו מה המחירים של הדברים האלה. זה לא משחק ילדים - לחסוך כל כך הרבה GB של זיכרון זה מאוד מאוד משמעותי. זה יכול להיות הבדל בין “יש לנו עסק” או “אין לנו עסק”.(חופית) נכון - וגם אנחנו חושבים על זה, כשאנחנו מוציאים אותו לקהילה.בין אם זה שהם ימשיכו לעשות Fine-tuning למודל, בין אם זה “שישחקו איתו” ויעשו איתו דברים.לרוב יש לאנשים GPU אחד - זה לא ה-Resource-ים שיש לנו, שאנחנו מחזיקים בחברה.זה גם כמובן נלקח בחשבון.ול-Jamba שלנו גם הוספנו MOE - שזה נקרא Mixture of Experts, שזה גם מושג לאחרונה ששומעים אותו הרבה.שזה בעצם מה שרציתי להגיד לגבי ה-Active Params שאמרתי מקודם, וכמות הפרמטרים “האמיתית” של המודל.אז מה שקורה זה שכל שכבה שנייה . . . . Mixture of Experts זה לא משהו שאנחנו המצאנו, זה משהו שהגיע מבחוץ.אנחנו פשוט שילבנו את זה כחלק מה-Jamba, בצורה שהייתה נראית לנו נכונה, טובה, והכי יעילה לדברים שאנחנו רצינו להשיג.בכללי, מה הרעיון אומר? הרעיון אומר שאם יש לנו את השכבה הליניארית שבה אנחנו עושים הטלה שנמצאת בין כל הבלוקים של ה-Mamba וה-Attention.בין כל בלוק כזה, יש בעצם שכבה שנקראת MLP, שזו שכבה ליניארית שרובנו מכירים - היא עוד “מהרשתות הקלאסיות” . . . (רן) אם אי פעם ראיתם רשת ניורונים - זה זה . . . “עיגולים מחוברים בקווים, שמחוברים לעיגולים בשכבה הבאה” - זהמה שנקרא MLP. (חופית) נכון, זה ה-MLP.אז בגדול, לנו, עד עכשיו כל המודלים הרווחים שהיו בחוץ היו בעצם שכבת MLP אחת בין כל Attention, בין כלבלוק Attention.וה-Mixture of Experts בא ואומר שאנחנו יכולים בעצם להחזיק, למשל, בשכבה אחת, במקום להחזיק שכבת MLP אחת כזאת, אנחנו נחזיק - אנחנו, לפחות במודל של Jamba, שמנו 16 בלוקים כאלה, של MLP.ולפי ה-Token שמגיע - מגיעה הסדרה של Token-ים, ולכל Token יש איזשהו Router, כשה-Router מחליט - זה Router נלמד כמובן, כמו כל הפרמטרים - שהוא מחליט לאיזה Expert ה-Token הזה מתאים.ואז אתה לא מנצל את כל ה-Expert-ים, זאת אומרת - ה-Active Params שלך, הפרמטרים שכרגע אתה משתמש בהם, הם של Expert אחד.כי אתה מחליט שה-Token הזה הולך ל-Expert הזה.אבל כל ה-Expert-ים האלה נלמדים במהלך האימון - כי כל Token ילך ל-Expert שונה.(רן) אני אנסה רגע להסביר את זה בדרכי שלי, “הציורית” - נניח שאתם יודעים לדבר חמש שפות, ועכשיו אתם שומעים משהו בצרפתית, אז זה הולך לאיזור אחד במוח. אתם שומעים אחר כך משהו בערבית, אז זה הולך לאזור אחר של  המוח. אבל אתם אף פעם לא משתמשים בו-זמנית, בכל חמשת השפות, או שסביר להניח שלא תשתמשו בו-זמנית - ולכן חלק מהמוח שלכם כל הזמן ”במנוחה". אוקיי, אז Mixture of Experts הוא למעשה “ה-Router” שמחליט “אה, זה צרפתית! זה הולך לאזור הזה של המוח, ולכן כל השאר יכול לנוח”.איך מרוויחים מזה, בחומרה? מה זה עוזר לנו בעצם? אז למעשה, אנחנו לא צריכים להשתמש בו זמנית בכל הפרמטרים, שזה אומר אפשר לחסוך - תקני אותי אם אני טועה - אפשר לחסוך בזיכרון, אפשר לחסוך ב-Cycle-ים של GPU בזמן ה-Inference - ולמעשה, המודל, פוטנציאלית, הוא אולי 50 מיליארד פרמטרים, אבל למעשה, אני יכול להתייחס אליו, מבחינת “המשקל שלו”, כ-12 מיליארד פרמטרים.(אורי) בהנחה שאנחנו "נפספס” איזה משהו - שתלוי “בחוכמה” של ה-Router. (רן) אם ה-Router טועה, אז כן - “אכלנו אותה” . . . (חופית) אז ה-Router - הוא נלמד לאורך המון המון צעדים, אז הוא לרוב לא טועה, הוא אכן מגיע למקומות שאכן צריך להגיע אליהם. אני כן אדייק פה לגבי זיכרון - כל המודל יושב בזיכרון, כל ה-50 מיליארד פרמטרים, זה אומר שחיסכון בזיכרון אין.אבל מבחינת Latency, כמות ה-FLOP-ים והאופרציות שה-Token הזה יעבור לאורך הרשת, תהיה כמו מודל בגודל 12B, ולא כמו מודל בגודל 50B, 50 מיליארד.(רן) אז אני אתקן את האנלוגיה הציורית שלי - אז אתה כן שומע, נגיד, ערבית, ועכשיו זה עובר דרך כל המעבדים של חמשת השפות שיש לך בזיכרון. אוקיי? רק אחד מהם מוציא משהו הגיוני, כל השאר מוציאים Nonsense - ואז אתה זורק אותם. אז במקום לעשות את החישוב הזה חמש פעמים - עושים אותו רק פעם אחת, בחלק הרלוונטי של המוח, ולא בכולם, וככה חוסכים ב-Cycle-ים.(חופית) כן.(רן) אז ה-Mixture of Experts למעשה נמצא בין כל אחת מהשכבות שלכם?(חופית) אז בין כל שכבה שנייה. לא כל שכבה, אלא בכל שכבה שנייה שמנו אותו. שוב, זה עניין של . . .  בסוף אנחנו מחזיקים המון המון גם בזיכרון, והמטרה הייתה לאפטם (To Optimize).המטרה ספציפית ב-Jamba הייתה לאפטם את זה שאנחנו יכולים להחזיק בזיכרון את כל המודל שלנו על GPU אחד, עד Context של 128K.אם היו לנו עד 256K, הוא דורש כבר יותר מ-GPU אחד, של 80GB.(רן) כן. זיכרון . . . והגדלים באים בדרך כלל באופן סטנדרטי, ככה שיש את “המשבצת הנכונה” ל-80GB.34:38 תרומה לקהילה(רן) הזכרת מקודם תרומה לקהילה, ואת זה שאתם רוצים שכל אחד בקהילה יוכל לריץ את המודל. אז מה זה אומר? המודל הזה הוא פתוח?(חופית) אז הוא Open Source -  הוא פתוח ב-Hugging Face, כן.אנשים יכולים לגשת לשחק איתו, להמשיך לאמן אותו גם.ממש “להיכנס לנבכי הארכיטקטורה” שלו.ובאמת שכל אחד מוזמן - זה רק יעזור לנו לקבל פידבקים.(רן) אז כן, אז זה לידיעה כללית - יש לא מעט חברות שלהן יש מודלים חזקים ומאוד Capable, אבל מודלים סגורים. OpenAI אולי הידועה מבין כולם - אבל יש גם אחרות. ויש גם כאלה שמשחררות את המודלים שלהן בקוד פתוח או בקונפיגורציות שונות של Open Weights וכו'.אתם שיחרתם את Jamba, את הגרסה של - זה נקראת בעצם 50B או איך זה נקרא?(חופית) אז זה נקרא, זה 712B אפשר להגיד . . .  למה עברנו מ-7B? מה שעשינו, MOE, מה שהחלטנו לעשות ועוד כמה חברות עשו את זה כמובן, זה להחליט לא לקחת Expert אחד אלא לקחת שני Expert-ים לכל Token.להוסיף לו עוד אקספרסיביות (Expressiveness), עוד רמה של אקספרסיביות בעצם.מה שהפך את המודל בעצם להיות מאיזה 7-8B פרמטרים, Active Params - ל-12 מיליארד Active Params.(רן) כן, אז 7 כפול 12, זו התוצאה?(חופית) כן. זה 12 מיליארד פרמטרים - ו-50 מיליארד פרמטרים בסך הכל.(רן) אוקיי, ואפשר לקחת - בהינתן GPU מספיק גדול, וכאלה כן קיימים, כלומר כן אפשר לשלם עליהם ולקבל אותם - ואפשר לרוץ ולהשתמש במודל. אם אורך Context מאוד מאוד ארוך חשוב -  אם זה לשיחת -Chat פשוטה, אתם לא צריכים את ה-Context הזה, אבל אם זה “תקרא את כל הקוד שלי ותגיד לי איזו פונקציה אני צריך לכתוב” או “תציע לי Completion לפונקציה” או אם זה “תקרא את כל ההיסטוריה הרפואית ותן לי אנליזה” או “תראה את הסרט הזה” -  לא דיברנו כל כך על Medim-ים אחרים, אבל גם זה משהו שעובד - אז זה יכול בהחלט לעבוד עם מודל שכזה.דרך אגב - יש מודלים אחרים ששיחררתם  בקוד פתוח?(חופית) שיחררנו את זה ואת ה-Instruct שלו.אבל עוד לא - יש מודלים גדולים שמתבשלים בדרך, כן. “גדולים באמת”.(אורי) אני גם שנייה שנייה חופר ב-GPU שלי - במבצע סבתא יש בחמישה Token-ים פחות מ-128K . . . (רן) יפה, אז אפשר אפשר להשלים את הסרט.(אורי) כן, לא כולל מוטי בננה.(חופית) באמת?(אורי) לא.37:18 כתוביות(רן) טוב, וואו, מרתק. טוב, אני מקווה ש... כן אמרת בדרך אבלציות (Ablation) ורציתי להיכנס לשם, אבל מספיק עד כאן.אז היה מרתק, תודה רבה!(חופית) תודה רבה לכם - היה ממש מעניין, ומקווה שזה יפתח לאנשים את הראש.(אורי) יפתח לאנשים את המודל . . . (רן) . . . . מוזמנים להיכנס ל-Hugging Face, להוריד משם - ולהתנסות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 473 של רברס עם פלטפורמה, שהוקלט ב-27 ביוני 2024 - אורי ורן מארחים את הילה פוקס מ-Forter, כדי לדבר על “איך חושבים מוצרית” לאנשי טכנולוגיה או - איך אנשי טכנולוגיה חושבים (יכולים לחשוב? עלולים לחשוב?) מוצרית.00:40 הילה והצוות המועצם(רן) אז קצת לפני שנצלול בפנים, הילה - בואי נכיר אותך קצת . . . אז קצת עלייך?(הילה) אז אני הילה - אני מובילה טכנולוגית, עם מעל עשר שנות ניסיון.עבדתי ב-Intel וב-Fiverr, וגם בחברה בשם Augury, לפעמים קצת פחות מוכרת . . . ועכשיו אני Staff Engineer ב-Forter - כש-”Staff Engineer” זה “Tech Lead”, אפשר לומר.(רן) משום מה, חבריי ב-Augury - לא שיש לי - אבל תמיד אומרים שאתם לא מוכרים, ותמיד כולם מכירים אתכם . . . סנסורים למנועים, למכונות וכל זה.(הילה) נכון, יפה . . . . כן, זו חברה חיפאית, מי בכלל זוכר, מי יודע?(רן) אולי בגלל ה”חיפה” זה עובד . . .  אז יאללה, נרים לכולם. טוב - אז את עובדת ב-Forter עכשיו, כ-Staff Engineer. למה מעניין אותך מוצר? כאילו - את מי זה מעניין? את רק רוצה להעביר ביטים, לא?(הילה) אז לא . . .  אולי אני אביא את זה קצת גם מתוך הסיפור האישי שלי - כי בתקופה שלי ב-Augury, בעצם אני הגעתי בתור Backend, מפתחת-Backend.ולאורך התקופה שלי שם, התפתחתי גם ל-Squad-Lead - ובסופו של דבר לארכיטקטית.ואני חושבת שחלק מאוד מהותי מההתפתחות המקצועית שלי בעצם הגיע מתוך הבנה ביזנסית (Business) וחשיבה מוצרית.אז אולי זה הדבר הראשון ל”למה אכפת לי אישית מהדבר הזה” - כן, זה מאוד תרם לי לקריירה.מעבר לזה שאני מוצאת את זה מאוד מעניין - זה מאוד מחבר אותי לארגון, אני מבינה איך משפיעים.אז זה בא לי עם המוטיבציה, זה עוזר לי ל”למה אני קמה בבוקר, למה אני עושה את מה שאני עושה”.(אורי) אז רגע, רגע . . .  אני הקהל, נכון?  . . . מתי פגשתי את זה בפעם הראשונה? זאת אומרת, מתי בפעם הראשונה אמרת “אה, רגע! אני מתחילה לחשוב מוצרית! אני . . . “ . . . מה גרם לך להגיע בכלל לאיזור הזה?(רן) אני אעשה את זה תיאטרלי - “ממחר בבוקר קמים ומתחילים לחשוב מוצרית!”(הילה) אני חושבת ש . . .  קודם כל, גם ב-Fiverr עובדים כזה מאוד Oriented ללקוחות, כן?ועבדתי בצוות Web-י - והיה לנו איש מוצר שהיה ביחד עם הצוות, ואפשר להגיד ששם התהליך קצת התחיל.באמת להבין - מה משפיע על הלקוח? מתי זה משפיע על הלקוח?אבל אני חושבת שה-Ramp-up האמיתי שלי מסביב לזה היה ב-Augury.כש-Augury האמת היא קצת כזה . . . חברה שבשביל אנשי-מוצר היא קצת כזה “חלום רטוב”, כן?הם עובדים שם כזה בצורה נורא הוליסטית, יחסית לפרקטיקות של עבודה של אנשי-מוצר.אם אתם מכירים את המונח הזה, “Empowered PM” - שמגיע מתוך הדיונים והשיחות של Marty Cagan והמתודולוגיות שהוא מוביל [Product management theater | Marty Cagan (Silicon Valley Product Group)].אז בעצם בגלל שהם נורא מאמינים גם ב-”Empowered PMs” ובלתת הרבה כוח לאנשי מוצר להוביל את הצוותים שלהם, זה גם נורא התחבר לזה שהאנשים הטכנולוגיים צריכים להיות חלק מזה בסופו של דבר.(אורי) גם הם Empowered . . .(הילה) נכון . . . בסופו של דבר, מ-Empowered PM אתה עובר גם ל-Empowered Team - ואיך אתה עושה את זה?קודם כל על ידי זה שכולם ביחד יכולים לשרת את אותה מטרה, ויש להם את כל ה-Skill-set שהם יכולים.כמו שיש לנו Squad-ים - צוותים אוטונומיים, נכון? אז יש לנו גם בעצם יכולת להיות Empowered מבחינת ה-Business, נכון?(אורי) שנייה, שנייה . . .  קחי אותי מהאזור של המילים הגדולות וה-”Empowered” וזה - ביום-יום, מה קרה בפעם הראשונה שהבנת שאת “חושבת מוצר”?(הילה) אז זה . . .  היתה תקופה ב-Augury . . .(אורי) איך זה נראה ביום-יום, מה קרה?(הילה) אני אספר איפה אני התחלתי - איפה זה התחיל לפגוש אותי יותר ויותר.היתה תקופה שבה Augury בעצם עברה להיות מחברת “מוצר אחד” לחברת Portfolio - והמוצר החדש שרצו להקים הגיע אליי לצוות.והיתה לנו המון עבודה משותפת לי ולאיש-מוצר, ו...(אורי) כשאת כבר היית Squad-Lead?(הילה) הייתי Squad-Lead כבר בצוות, כן.ובעצם, אחד מהדברים שהיו הכי קריטיים לנו לעשות, כשמביאים מוצר חדש, זה לעשות MVP ו-to-Scope-it וכמה שיותר להוריד תוכן שלא רלוונטי, בשביל להתחיל ולרוץ וללמוד מהר.ושם התחיל מאוד מאוד חזק הפינג-פונג בין האתגרים הטכנולוגיים וכמה אנחנו באמת רוצים להשקיע עכשיו או לא עכשיו - איזה Requirements אנחנו באמת רוצים למלא או לא למלא, כן?ואני חושבת שפה זו נקודת החיבור הכי חזקה, בין Product ל-Engineeringוגם איפה שעולה החשיבה המוצרית ביחד.(אורי) מה שאת אומרת זה בעצם שלצורך בניית ה-MVP הזה, היינו צריכים, אני - את, כן . . . - וה-Product  Manager- כל אחד היה צריך להבין קצת ב-Domain של השני, כדי שתהיו מוכנים ותוכלו בעצם “לקלף את הבצל הזה” ולהגיע לליבה שלו, ולהבין בעצם מה אתם מקלפים . . . זאת אומרת, הוא היה צריך להבין מה קשה טכנולוגיתומה לוקח יותר זמן, ואת היית צריכה להבין מה חשוב מוצרית.(הילה) נכון, נכון - מה בעצם אנחנו מנסים לבדוק בהתחלה? מה חשוב לנו לבדוק בהתחלה? איפה אנחנו יכולים להתפשר? כן . . . והיו הרבה פשרות שעשינו ברמה המוצרית - ברמה טכנולוגית, סליחה.היו הרבה מאוד פשרות בעולם הזה, היו הרבה דברים שעשינו כזה Hot Fixes, Quick & Dirty - רק בשביל שנוכל להתחיל לראות את זה במערכת.(אורי)למשל, לא חושבים על Scale בהתחלה . . . (הילה) לא, לא חושבים על Scale . . .  זה לא היה בכיוון שלנו.אחר כך, אחרי שה-MVP הצליח, ובעצם היה לנו כזה “Pilot” - לקוח ראשון, לקוח שני, לקוח שלישי, והתחילו לדבר על איך זה משתלב באמת כ-Portfolio, שני מוצרים שנותנים ללקוחות - פתאום התחלנו לחשוב על איך אנחנו בונים לזה Vision ולאן אנחנו לוקחים את זה קדימה.ואיך זה מתחבר ב-UI, וב-Backend, מוצרית וטכנולוגית . . . (אורי) לפעמים זה מצריך בשלבים המאוחרים פשוט למחוק הכל, לכתוב מחדש . . . (הילה) כן . . . נקודתית, לא היה לנו שם בדיוק את הסיטואציה הזאת, אבל כן - תיאורטית אני מסכימה איתך.לפעמים זה יהיה כזה, נכון - אפשר לדבר על MVP ו-POC.לפעמים אנחנו עושים POC בשביל לבדוק התכנות למשהו פשוט - ואנחנו נזרוק את זה אחר כך ונבנה את זה “כמו שצריך” אחרי שאנחנו באמת מבינים, ברמה הטכנולוגית, מה אנחנו צריכים.(אורי) אבל במקרה שלך, כמו שאת אומרת, הטריגר להתחיל לחשוב מוצרית היה הנקודה הזאת שבה צריך “להפשיט את המוצר מכל מה שלא חשוב וקשה” . . .(הילה) כן, כי זו בעצם הנקודת-חיתוך שלי ושל כל הצוות - לא עשיתי את זה מתוך היותי Squad Lead - כל הצוות נמצא בדיונים, ובעצם מזה שמאתגרים אותנו כל הזמן לעשות את ה-Brainstorm ביחד עם האנשי-מוצר, זה מכניס אותנו נורא עמוק ל-Context.ובגלל שאנחנו מקבלים אתגרים נורא גדולים, אנחנו חייבים לעשות את ה-Back and Forth עם האנשי-מוצר, בשביל לדייק אותם למשהו שאפשר לדלבר (To Deliver) בזמן סביר, ושעדיין יביא את הערך.ובשביל הנקודות האלה - של היצירתיות, של איפה שאני רוצה גם להתעקש, כ-Engineering, “פה לא ופה כן” - אני צריכה להבין איפה כדאי לי דווקא לשחרר ואיפה לא.מתוך הבנה של איך המערכת בנויה - גם טכנולוגית וגם איך המוצר ומה חשוב ואיך זה מרגיש ללקוחות.ואז זה יוצר שפה משותפת וממש אינטראקציה, “חיכוך חיובי”.(רן) זהו, אני חושב שהמילה שחיפשת, אני מנסה לנחש, זה “אמון” - זה מייצר איזשהו אמון. כי תמיד בין גורמים שונים - בין נגיד אנשי האופרציה לבין הפיתוח, בין אנשי הפיתוח לבין אנשי המוצר, בין ה-Recruiting . . . . - זאת אומרת, בין כולם לכולם תמיד יש איזשהו מתח ולפעמים גם יש איזשהו חוסר-אמון, כי מה לעשות? כולם מפשלים מתישהו, או שכולם מקבלים החלטות לא נכונות מתישהו - ואז האמון הזה קצת נשבר.והחוכמה זה לבוא ולבנות את האמון הזה מחדש, או לייצר איזושהי קרקע - קרקע בטוחה יותר, שהאמון הזה לא יישבר. ולשים את עצמך בנעליים של איש-המוצר - זה מבחינתם, אני רואה את זה כצעד-בונה-אמון, גם אם זאת לא הייתה הכוונה מלכתתחילה. גם אם זה בא לך כאינסטינקט, בסופו של דבר . . .(הילה) כן, בדיעבד הבניית שפה-משותפת הזאת - כאילו, אם אנחנו, כאנשים-טכנולוגיים מדברים כזה “לא, אבל השורת-קוד פה ופה לא נכונה, או לא נחמדה, או לא יפה מספיק!”, אנשי -מוצר . . .אנחנו עכשיו עם האשת-מוצר אצלנו בצוות, צוחקים שיש לה “פרצוף-Repository” - כל פעם שאנחנו אומרים את המילה או מתחילים לדבר על טכנולוגיה, כאילו הפרצוף שלה “נכבה” . . . אז צריך לדבר כאילו מן סתם ברמה שמתאימה לשני צדדים.(אורי) כן, אבל זה גם עובד ב...נגיד, איש מוצר שמסוגל להבין את ה-Complexity של הארכיטקטורה - הדיון איתו הוא אחרת. ומהצד השני, מהנדס שמסוגל להבין את המוצר... (הילה) זה Skill-נרכש . . . (אורי) . . . זה טוב לשני הצדדים. אגב, מה זה באמת השיחה הזאת, על ה-Scope של המוצר? זה משא ומתן, נכון? . . . [Never Split the Difference: Negotiating As If Your Life Depended On It](הילה) מסכימה.(אורי) והא’-ב' של משא ומתן זה “תבין מה חשוב לצד השני” - וזו בעצם החשיבה המוצרית.(הילה) נכון, זו בעצם כאילו היכולת שלי להבין מה הצד השני צריך, וגם לנהל את המשא ומתן הזה “בגובה העיניים”, לשני הצדדים.(אורי) כן, ומשא ומתן, כשמבינים האחד את השני - יש בו הרבה אמון.(רן) יש! - חזרנו לאמון . . . 10:42 טיפים וטריקים(רן) למי שזה לא בא טבעי . . . זאת אומרת, אני מניח שאת לא תכננת, לא עשית תוכנית-עשור, לעשר שנים קדימה - “מעכשיו אני רוצה להיות Product-Focused Engineer”, אבל זה בא לך. זה “התגנב” כנראה באופן אינסטינקטיבי, או שאולי היה איזשהו מקרה, וזה איכשהו זה הצליח.אבל למי שעכשיו תופס את עצמו ואומר “רגע, רגע, זה דווקא נשמע לי רעיון טוב! אבל איך אני עושה את זה?”. כאילו,  איך אני מפתח את האמפתיה? איך אני מייצר את השפה המשותפת הזאת?תני לנו כמה טיפים וטריקים של דברים שאולי יכולים לעבוד לך - אם זה תכנון רבעוני, שיחות אחד-על-אחד או אחרים.(הילה) אז הייתי מתחילה בקודם כל בלדבר עם האיש או אשת-מוצר הכי קרובים אליכם.אני רוצה לקוות ולהאמין שאנשים יבואו ב-Good Faith, ושאם תרצו לבוא וללמוד, אז אנשים באמת גם “ישיבו את האנרגיה החיובית” ובאמת ילמדו אתכם.אפשר לבוא ולשאול שאלות מסביב למוצר עצמו, ל-Business עצמו - איך הם עושים דברים? איך אתה עושה פריוריטיזציה (Prioritization)?נגיד, הרבה פעמים אנחנו, כאנשים טכנולוגיים - לרוב האנשים זה מפתחים, מפתחות, לא מובילים,ואז בדרך כלל מגיע ה-Roadmap - וה-Roadmap כבר “אפוי”, ו”תודה - הנה, זה מה שקיבלתם”.שאלה מאוד מעניינת יכולה להיות “למה?” - למה דווקא זה קודם? למה זה בתחילת הרבעון? למה זה בכלל לא נכנס לרבעון?אז יש שאלות מאוד מעניינות, שאם נבין איך האיש-מוצר מסתכל על זה, אז כאילו . . . זה יעשה לנו גם הרבה יותר סדר, זה גם יוריד לנו תסכול.אולי לנו נורא חשובה איזושהי משימה, ואנחנו כזה “איך לא הכניסו את זה?! מה פתאום?! זה כזה קריטי!” - מתוך שיחה כזאת זה יכול להגיע.(רן) לא בקטע וכחני - פשוט כדי להגיע לסדר עדיפויות.(אורי) דרך אגב, צריך להכין את זה - “כי למה דווקא זה? למה ה-Roadmap נראה ככה?” - כשזה בא מ-Engineering, בואו נודה על האמת, זו שאלה מעצבנת . . . (הילה) אז יש פה נקודה בין-אישית מאוד רכה, שצריך לנהל - צריך לבוא מאוד ממקום של למידה.אם נבוא ונגיד “אני רוצה לבוא וללמוד - איך אתם עושים פריוריטיזציה (Prioritization)? באיזו מתודולוגיה אתם משתמשים? מעניין אותי לשמוע”.“מה הקריטריונים שאתם שמים על משימות?”לא ב”למה דווקא זה או למה דווקא זה”, כן? כאילו, מה שניסיתי לעשות זה לשקף מחשבות שיש לנו בראש.(רן) כן, יש הבדל. אני תמיד אומר לבנות שלי, הקטנות - יש הבדל בין “למה דווקא זה?!?!” ל”למה דווקא זה?” . .  . זאת אומרת, צריך לדעת להגיד את זה - ואז אם זה בא מתוך באמת אמפתיה וניסיון להבין, אז זה נשמע אחרת.(אורי) ו-Timing - אל תתפסו אותם כשהם לחוצים להציג את ה-Roadmap, בסדר? תתפסו אותם איפשהו באמצע הרבעון כזה, כשהם לא בלחץ, ו...(הילה) גם אפשר רק לשאול שאלות ולא באמת לקרוא תיגר על החלטות, כן?אם רק נשאל שאלות, לפחות במקום שבו אנחנו רק לומדים, ואולי וכנראה אין לנו משהו חכם עדיין לתת כ-Input, יהיה שווה שרק נשאל ונתעניין ונלמד.(רן) אז לבוא ולשאול, להבין את השיקולים, להבין את סדרי העדיפויות ולפי מה קובעים סדרי העדיפויות - רק מזה כנראה נלמד הרבה.(הילה) נכון.(רן) אוקיי, יש איזה-שהם Touch-points מיוחדים? זאת אומרת, אורי אמר “באמצע רבעון, לא בהתחלה ולא בסוף” - יש, נגיד, כמה נקודות יותר אסטרטגיות שאת מזהה? נקודות שבהן שווה באמת לדבר יותר קרוב עם אנשי המוצר?(הילה) אז זה קצת משתנה כנראה בתפקיד . . . לאנשי פיתוח, הייתי אומרת, אולי זה אפילו לא כזה קריטי - באמת לתפוס אותם בזמן שהם פנויים לזה, ולהתחיל להתעניין ולשאול שאלות.זה יכול להיות לפני Sprint Planning, אם זה על איזה משימות נכנסות ולמה.או אחרי שה-Roadmap מגיע - בואו נשב על זה ונבין יותר לעומק.בדרך כלל מציגים את זה, נגיד, לכל הקבוצה או לכל המחלקה - ואז זה כזה מאוד ב-High-level, אז זה מקום טוב.למובילים טכנולוגיים הייתי בכלל מציעה להבין איך הם, אפשר לומר “מסתננים” - עוד לפני שהדברים האלה אפויים.אם לבקש להיות חלק מה-Planning - לשבת בחדר, אפילו לא בשביל לקבל החלטות [למה לא?]באמת שאין לי כוח-וטו בחדר של ה-Planning, כי מי שאחראי על זה, זה לצורך העניין ה-Team-Lead והאשת-מוצר - אבל אני יכולה לבוא לתת את ה-Impact שלי ואת ה-Input  שלי, ולעשות ככה השפעה על מה שקורה, מתוך הידע שלי.(אורי) אגב, לא יודע - לפחות ב-Outbrain, הרבה פעמים ל-Spec-Review או מקומות כאלה, לא בהכרח ה-Team-Lead צריך להיות - כאילו, אם יש מפתח שהוא מספיק בכיר לקחת את זה, ולעשות את זה מול ה-PM - אחלה. אבל יכול להיות שבשלב שהוא לפני ה-Spec-Review - כבר לשבת עם ה-PM לשיחה של “למה?”: מה אמר הלקוח? מה רוצה הלקוח? דרך אגב - לא להתבייש, לפגוש לקוח.(הילה) לגמרי. כאילו, אני באמת רואה את זה בכל מיני נקודות, בתוך . . . יש לנו תכנון שנתי, תכנון רבעוני, אולי תכנון של ספרינטים - כל צוות או קבוצה, איך שהם רוצים לעבוד.אני חושבת שמובילים-טכנולוגיים חייבים להיות בתכנון שנתי ובתכנון רבעוני, בשביל באמת לבוא ולשאול את השאלות האלה, עוד לפני שהם נכנסים ל-Pipeline של הרבעון.אני חושבת שאנשי פיתוח - מפתחים - אם יש להם, נגיד, רצון להתקדם להובלת טכנולוגית וזה מתאים עם ההתפתחות המקצועית שלהם, עם ה-Skill-set שלהם - אולי גם יכולים לשבת שם.כאילו, יש הבדל בין מי שחייב לשבת שם - מתוך הגדרת-התפקיד, אפשר לומר - לבין מי שגם יכול לעשות את זה וכדאי שיעשו את זה, כי למה לא?למה לא לתת לאנשים להתפתח אם הם יכולים, ולבוא להשפיע.(אורי) אני חושב שזה לא רק זה - פשוט יצא מוצר יותר טוב.(הילה) כן, לגמרי. אם מפתח, הוא Expert לאיזשהו איזור, והוא יכול לבוא ולהשפיע על ה-Scope של המשימה - אם היא צריכה להיכנס או לא להיכנס - אז שיהיה בחדר.(רן) דרך אגב, קרה לך המצב ההפוך? שבא, נגיד, איש מוצר, ואמר “אני רואה ש-Feature מתעכב, או שיש פה איזשהו אתגר - אני רוצה להבין למה, רוצה להבין מה האתגר פה”?(הילה) בטח. כאילו, זה קורה כל הזמן . . .פחות עולה לי דוגמא  לראש, נגיד, מסביב למוצר, למשהו שהתעכב, אבל תמיד כזה, בתהליך של עשיית Design-ים, תמיד זה כזה “למה זה כל כך הרבה זמן?! למה זה כל כך הרבה שבועות?!”והפרקטיקה שאני מאוד אוהבת, זה פשוט להיות מאוד Details-Oriented, ולצאת ממש מ-Design עם פירוק משימות מאוד מאוד ברור, עם ריאליזציה (Realization) מאוד ברורה מסביב לכל דבר.לבוא ולהגיד “זה חודש” - זה לא מספיק טוב.לבוא ולהגיד “הנה כל המשימות שפרטתי - פה יש לי כן Refactor קטן, אבל הוא רק שלושה ימים, וכל שאר הדברים הם ממש . . .”“זה עונה ל-Requirement הזה, וזה עונה ל-Requirement הזה”, כאילו...(אורי) הנה טיפ לאנשי המוצר - תקשיבו על איזה חלקים ב-Spec Review ה-Engineering יותר מתעקשים . . . מה הם מתעקשים לא לעשות, או לשנות, או לבדוק להם אם אפשר לעשות אחרת . . . בדרך כלל המקומות האלה יהיו המקומות שהם יותר קשים - ויקחו יותר זמן. אז כאילו, לפי זה, אפשר לדעת מה מסובך.(הילה) אני מסכימה. אני חושבת שיש גם הרבה דברים ברמה הטכנית, שאנחנו קצת יכולים לפשט ולהסביר יותר את ההשפעה שלהם על המערכת, ופחות באמת את הדבר הטכני.נגיד, לא מזמן הגעתי לאיזושהי שיחה, ומישהו התחיל להסביר - זה לא היו אנשי מוצר, אלו היו אנליסטים בחברה - אבל כזה, “כן, הבעיה פה” . . . . אתם יכולים להגיד להם ש”הבעיה היא ב-WebSocket!” - וכאילו, מפה ועד לזה שמישהו מבין מה ההשפעה, זה כמה קפיצות, נכון?אם אפשר לבוא ולפשט את זה . . . (אורי) מה ההשפעה על הלקוח או על המוצר?(הילה) כן, על המוצר - אבל אם פתאום, נגיד, נשנה את ההסבר, ונבוא ונגיד “תראו, למערכת יש כמה חלקים נעים - בעצם זו פעולה שקורית א-סינכרונית” . . . וניסינו להסביר להם למה ה-Event לא חוזר ל-UI, כן?אז המערכת שלנו מורכבת מכמה חלקים נעים - ומה שקורה זה שחלק אחד שולח הודעה לחלק השני, אבל משום מה החלק השני לא מחזיר הודעה בחזרה לחלק הראשון,עכשיו, זה הרבה יותר פשוט, כן?עכשיו, מן הסתם שבשיחה גם הסברתי מה זה כל חלק ומה זה כל קומפוננטה (Component) כזאת, בשפה שהן גם מכירות, כן?אז זה הרבה יותר מקרב והרבה יותר מחבר - במקום לדבר בשפה שלא מבינים, ואז הם במקום כזה  של תסכול, אף אחד לא מבין את אף אחד.19:37 איש המוצר התאום(רן) יש לך איש מוצר, נגיד, שהוא “התאום שלך”? איש או אשת-מוצר, או שזה ככה מול כולם? זאת אומרת, מה ה-Working Set שלך?(הילה) אז אני יודעת שיש הרבה Setups בהרבה חברות שונות, אבל בשלוש החברות האחרונות שאני עבדתי בהן היה איש-מוצר או אשת-מוצר בתוך הצוות.זאת אומרת שזה כזה ממש ה-Go-To - ואנחנו Go-To‘s, זה אחד של השני, שזה Setup שאני אישית מאוד מאוד מאמינה בו ורואה בו את ההצלחה.אבל אולי גם אני מדברת מתוך זה שלא חוויתי גם את המשהו האחר - אולי זה טוב, אבל אני...(רן) כן, זאת אומרת, אז בדרך כלל יש איזשהו Counterpart אחד - יש איזשהו איש-מוצר ספציפי שיש... יש לך איזשהו שגרת עבודה איתן? זאת אומרת, One-on-Ones, או לא יודע - ארוחת צהריים מדי פעם? או דברים כאלה, זה הכל כזה “מה שיוצא, יוצא?”(הילה) לא, זה לא “מה שיוצא, יוצא”  . . . אנחנו - לצורך העניין, יש לנו Cadence כזה: ה-Leads של הצוות, שזה אני כמובילה טכנולוגית, ה-Team Lead וה-Product - מעבר לזה שאת ה-Sprint Planning אנחנו גם עושים ביחד, בתכנון הרבעוני יש לי גם חלק מאוד משמעותי שם.מן הסתם, כשיש כזה “בירות על הגג”, או כשעושים משהו ל-Fun - כולנו נמצאים שם, כן? אנחנו צוות אחד.(רן) כן. עכשיו, בחברות יחסית בוגרות - ואני מניח ש-Forter בקטגוריה הזאת - יש, ככה, “עניין של Title-ים וקידומים’, וכל אחד רוצה להגיע לדרגה הבאה, וצריך להגיע לכל מיני מטרות . . . ולכל אחד מהמפתחים יש, פחות או יותר, לפחות אמור לדעת, מה הוא צריך לעשות כדי להגיע ל-Level הבא.את יודעת את זה גם על איש-המוצר שלך? זאת אומרת את...(הילה) על מה הם צריכים לעשות בשביל להגיע ל-Level הבא?(רן) כן, מה הם צריכים לעשות כדי להצליח? אני מפשט את השאלה. “מה הם צריכים לעשות?”, כן. מה המדד-הצלחה שלהם ומה הם רוצים להשיג?(הילה) אז אני לא יודעת מה ה-Responsibilities שלהם, בתוך ה-Job Description בדיוק.אני כן יודעת שאנשי מוצר לרוב נוטים להיות מאוד מפוקסים על ה-Business Metrics שמגיעים אליהם, שנגזרים מתוך ה-KPIs של החברה.אז יש את המטריקות שיש לנו ברמת החברה - ובדרך כלל כל חלק בארגון גוזר את זה אליו, עד שגוזרים את זה לאט לאט לתוך כל הצוותים.או KPIs או OKRs, שזה Objectives and Key Results או Key Performance Indicatorsאז זה כאילו, זה הדבר שעליו בסופו של דבר הם נמדדים.הם צריכים לאפיין על מה הם רוצים להשפיע ואיך זה מתחבר ל-Business - ובסופו של דבר זה נמדד על זה שבאמת הצלחנו לעשות את זה.(רן) הבנתי, אז את ה-KPIs או את ה-OKRs של מנהלת המוצר שמולה את עובדת - אותם את מכירה.(הילה) אני מכירה - ומעבר “למכירה”. אנחנו צריכים - אשת המוצר אחראית על זה יותר ממני, כן? היא אחראית על זה האמת לבד, אבל אני צריכה להכיר, בעצם, איך כל משימה מתקשרת ל-KPIs האלה, כן?עכשיו אני גם אבוא ואחמיר ואומר - זה קצת לא מה ששאלת, אבל I'll go rogue - שכשאנשי המוצר עושים את זה, יש נקודה שאנחנו -כאנשים טכנולוגיים - מתי שאנחנו רוצים להשפיע ולשנות ולהביא, לא יודעת מה, אולי Refactor-ים גדולים או דברים שאמורים להשפיע על המערכת - אנחנו צריכים גם לדעת איך לקשר אותם ל-KPIs, כן?כאנשים טכנולוגיים, אם נגיד אני רוצה להכניס Refactor שעכשיו ייקח חודש או חודש וחצי, כי אני יודעת ש”וואו, איך זה חשוב, איך זה יעבוד” . . . אם אני לא אצליח להסביר בשפה של אנשי ה-Product למה זה מספיק חשוב, יהיה לי מאוד קשה לדחוף את זה קדימה.(רן) כן, למעשה הקדמת את השאלה . . .  (הילה) אה, יפה, אוקיי...23:27 דילמה, Buy-In, חשיבה מוצרית ופול-גז בניוטרל(רן) כן, אבל בעצם הרבה פעמים כמפתחים, יש לנו את הדילמה של “אנחנו יודעים שצריך לעשות פה איזשהו תיקון - איזשהו תיקון ארכיטקטוני, איזשהו Refactor - אבל אנחנו לא יודעים איך למכור את זה לאנשי המוצר”, במובן שיתעדפו את זה, שיהיה לנו מספיק זמן לעבוד על זה “בשקט” - ואולי גם לעזור לנו להבין מה חשוב מתוך זה ומה לא,כי גם בכל דבר כזה יש אולי 80% חשוב שלוקח 20% מהזמן, ו-20% שלא - ולוקח את ה-80% האחרים.אז איך באמת . . .  קצת התחלת לענות, אבל באמת - איך מקבלים את ה-Buy-In הזה - מצוות המוצר, מאנשי המוצר - כדי לעשות את “ה-Refactor הזה”, שמבחינתם זה כאילו, זה “פול-גז בניוטרל”, הרבה פעמים? . . . או שלפחות ככה הם רואים את זה, כמובן.(הילה) נכון. בגלל זה אני התחלתי בלהגיד שאנחנו צריכים . . .שוב, אם זו עבודה משמעותיתאני לא מדברת על איזה עבודה של יומיים - שאז אפשר תמיד, כנראה, לבוא ולהכניס בדרך כזו או אחרת.אבל אם זאת עבודה משמעותית - באמת לחבר את זה ל-KPIs או ל-Blocker-ים משמעותיים.לא יודעת, אולי תגידו “זה Pre-requisite למשימה מאוד משמעותית שרוצים לעשות ה-Product” - שמתקשר לדבר הזה.אולי מה שאנחנו רוצים זה ה-Enable ל-Build for Scale, שאנחנו צריכים שהמוצר שלנו יגיע לשם.אנחנו רוצים להבין איך הדברים האלה מתקשרים לצרכים Business-יים.(רן) ודרך אגב - ואם זה לא, אז אולי לא צריך את זה . . .(הילה) לגמרי - אבל אני רוצה לתת פה סייג, שככל שאני מדברת על הנושא יותר, אני חושבת ש...כאילו, אוקיי - שני סייגים . . . אחד - נושא ה-Velocity, שמאוד מאוד קשה למדוד ונורא מורכב.וכמו שאמרתי לכם - “Repository Face” על האשת-מוצר אצלנו.כמובן שכולם רוצים שהאנשים - שהמפתחים - יזוזו מהר, אבל קשה להביא Impact מאוד משמעותי בזה הרבה מהזמן.זה דבר אחד שאני רוצה לשים בצד - אז מאוד קשה להסביר את זה טוב.ויש שם את ה-DORA Metrics ויש הרבה דרכים לבוא ולנסות לפרמל (To Formalize) את זה ולהביא את זה מתוך ה-Engineering כמשהו שאנחנו רוצים לקחת קדימה.והדבר השני שרציתי להגיד שהוא Outlier - לפי דעתי להכל - זה “Developer Happiness".[בשביל זה יש את okify, לא? Your feelings are more important than production]כן? כאילו, אנחנו צריכים לבוא ולהסביר, שלפעמים יש דברים שאין מה לעשות - אנחנו לא יכולים שמפתחים ישבו מתוסכלים ויעבדו בדרכים שפשוט גורמות להם תסכול כל היום . . .זה מוריד מוטיבציה - וגם זה קשור ל-Business, כן? אף אחד לא רוצה Attrition שלילי, חיובי, איך זה נקרא? - שאנשים יעזבו את החברה.אז פה דווקא אני מוצאת את עצמי באה ואומרת “לא - אבל זה נורא חשוב, מזה ל-Developers אכפת”“פה כן לבוא ולתעדף דברים כאלה” - גם אם זה לא על KPI.(אורי) וזה עובר את “Repository Face”?(הילה) זה . . .  זה אתגר.אבל לפעמים, כן. אם מצליחים להביא טיעון טוב לאיך זה מתחבר וכמה זה משפיע - אז כן.(אורי) אז יש שני דברים להתמודד עם הדבר הזה . . . אחד - זה פשוט לפתח אמון מספיק גדול. שאוקיי - “כשאת , ה-PM, אומרת לי שמשהו מאוד מאוד חשוב, אז אני מבין את זה. תביני גם כשאני - המפתח או הראש-צוות, אומר שמשהו מאוד מאוד חשוב” . . .(הילה) לגמרי. כראש צוות, בן אדם נמדד גם על זה שלאנשים טוב בצוות, נכון?זה חלק מהעניין - ואנשי מוצר נמדדים על KPIs . . .(אורי) אבל תחשבי על דברים שהם לא רק “Happiness” או זה... החלפנו עכשיו איזשהו Infrastructure - הרבה פעמים אתה מחליף Infrastructure וזה בום! משפיע על כל הצוותים . . . אז כל אחד צריך לעשות את הדבר הקטן,שלו . . .(רן) . . . זה קודם כל משפיע לרעה - ואולי, אחר כך, גם לטובה . . .(אורי) . . . כן - אבל בסוף אנחנו עושים את זה כדי להתקדם, נכון? אז דבר אחד זה אמון . . .(הילה) מסכימה מאוד.(אורי) . . . והדבר השני הוא להגיד “קו בחול” - “20% מהזמן של המפתחים הולך לדברים שהם לא מקדמים את ה-Business”. הם מקדמים את הטכנולוגיה.(הילה) אבל גם פה - כאנשים טכנולוגיים - אנחנו צריכים פרקטיקות עם עצמנו, כדי להסביר גם לעצמנו וגם לאנשים...(אורי) מה יותר חשוב? . . .(הילה) לא, אולי לא ספציפית לאנשי-מוצר, אבל כאילו - מגיעים בסופו של דבר לנקודה הזאת, מתוך מקום שרוצים קצת להוריד את ה-Friction של “האם כן זה או לא זה” ו-”כן קשור ל-Business או לא”.ולתת ל-Engineering איזשהו Bucket כזה.זה לא כזה “תלכו תהנו, תתפרעו”, נכון? צריך גם שם לעשות ריאליזציה מאוד חזקה.ופה כבר נכנס זה שאנחנו - בתור אנשים טכנולוגיים - צריכים בכלל Skill-set של אנשי מוצר, בשביל לנהל את ה-Backlog הזה.פתאום אנחנו עושים Prioritization, פתאום אנחנו מנסים להבין מה באמת עושה Impact . . .(אורי) אני אגיד לך - זה כמו הילדים שלי וממתקים: זה אף פעם לא מספיק להם . . . (הילה) נכון - גם ל-Product לא מספיק . . .  לאף אחד לא מספיק.(אורי) נכון - אז כאילו, בסוף צריך לנהל עדיפויות בכל דבר.(הילה) נכון, אבל זה חלק מזה - לפתח את החשיבה המוצרית זה לא רק להבין את המוצר.זה להבין קצת את המתודולוגיות - וזה ישרת אותנו מאוד מאוד חזק, במקומות האלה של הניהול Technical Backlog, שאליו אנחנו רוצים.כי גם מתוך ה-Technical Backlog, אנחנו רוצים להביא את ה”הכי הרבה Impact”, מתוך איך שאנחנו מודדים את זה.ובין אם זה Refactor גדול או בין אם זה באמת להזיז גם מחט business-ית - הכל Fair.28:57 העניין הזה עם הלקוח ולקחת חשיבה מוצרית לקצה(אורי) אני רציתי להעלות עוד נקודה, שקשורה לזה - כי אנחנו כל הזמן מדברים על ה-PM, שמים אותו פה “על הגריל” . . . (הילה) אני בטוחה שהיא תשמח לשמוע שהשתמשתי ב-“Repository Face” כמה פעמים . . . (אורי)  . . . והיא לא שמעה על זה בכלל, זה רק מאחורי הגריל . . . (הילה) לא, היא יודעת שקוראים לה “Repository Face” - היא צוחקת על זה בעצמה.(רן) “מוקדש באהבה” . . . (אורי) רציתי לדבר על הלקוח - כאילו, המפגש עם הלקוח. איפה זה? זה קורה?(הילה) אז אני יכולה להגיד שנגיד ב-Augury זה היה מאוד מאוד סטנדרטי.ברמת שמפתחים טסים עם אנשי-מוצר - לעשות סיור במפעלים, לפגוש לקוחות . . . במפעלים - כי זה בעצם הלקוחות שיש ב-Augury.שיחות עם לקוחות - להבין, לראות, לא יודעת . . . . לפעמים זה גם לא אפילו לעלות לשיחה עם האנשי-מוצר - יש המון כזה הקלטות - ב-Gong או איזה כלי שלא משתמשים - אז גם אפשר משם לדלות הרבה מאוד מידע ולקבל הרגשה.וגם ב-Forter - יש לנו המון אינטרקציות עם לקוחות, אז אנחנו גם עולים עם הלקוחות לשיחות, וגם בשיחות Discovery, מתי שאפשר.אנחנו באמת מנסים כזה לבוא ולהצטרף.כן, זה תלוי ב-Ballance - אבל אישית אני מוצאת בזה הרבה מאוד ערך, כי לפעמים לקבל את הכל, כזה, בלי פילטרים - שהם אולי Biased כבר על ידי אנשים קיימים.פתאום לשאוב את זה לבד - “פעם ב-”, לא כל שיחה.לא יודעת, “פעם ברבעון” - שכל מפתח יעלה לשיחה עם לקוח, נשמע לי כמו משהו מדהים.(רן) דרך אגב - בין האיש-מוצר לבין הלקוח יש משרעת מאוד גדולה של תפקידים . . . זאת אומרת, יש אנליסטים ויש Product Marketing Managers ו. . . זאת אומרת, יש הרבה אנשים בחברה, שהם אולי לא אנשי המוצר “נטו” . . .(הילה) . . . כן, CS ו . . .  [Customer Success](רן)  . . .  כן - והם בחלק מהמקרים מייצגים את הלקוח ובחלק מהמקרים מביאים איזושהי פריזמה שונה, שהיא גם מעניינת. אז גם איתם . . .(הילה) הם Stakeholder-ים, חד-משמעית.זה כאילו - אפשר לבוא ולדבר גם קצת על ההבדל בין B2C ל-B2B . . . אבל ב-B2B הם בעצם באמת מייצגים לנו את הלקוח בצורה פנימית.וגם ב-Forter - חברת B2B - ו-CS הם Stakeholder-ים מאוד משמעותיים בשביל להבין(רן) "CS” זה “Customer Success” . . .(הילה) “CS” זה “Customer Success” ו-”B2B” זה “Business to Business”, ו-”B2C” זה “Business to Customer” . . . כן.(אורי) אני חייב להגיד שראיתי פעם אחת מישהו שכמפתח, לקח את החשיבה המוצרית לקצה.(הילה) מדי? . . .(אורי) לא . . . . וכשזה קורה, כש”הקסם” הזה קורה - “ה-KPI-ים עפים קדימה”.איך זה קורה? זה פשוט - זה כאילו, זה גם בן אדם מיוחד, אוקיי . . . . שמסוגל לקחת דברים מקצה לקצה, גם מבחינת יכולות טכניות וגם מבחינה מחשבתית. הוא עבד על איזושהי מערכת, פיתח אותה, פיתח את ה... מבין טוב מה ה-KPI-ים שלו - ועכשיו המערכת יצאה לשוק, והוא שואל את עצמו “אוקיי - למה לא מצטרפים עוד לקוחות?”.עכשיו, הוא לא הולך ל-PM . . . ובכלל, רוב המפתחים פיתחו - והם אפילו לא ישאלו את ה-PM, הם אפילו לא יסתכלו על המטריקות (Metrics), להסתכל אם הצטרפו עוד לקוחות או לא . . . מי שיש לו קצת חשיבה-מוצרית יסתכל, ישאל את השאלה “למה לא מצטרפים עוד לקוחות?”.אז הוא לא - במקרה שלו, הוא לא הלך ל-PM לשאול. הוא הלך ל-Customer Success, ל-Account Management. לקח את הכיסא, ישב לידם - חצי יום - אמר “למה אתם לא משתמשים? למה לקוחות האלה ואלה ואלה שלכם . . .” - שהם מה שנקרא “ה-Ideal Customer” למוצר שלו - “למה הם לא משתמשים?”.אז יש כל מיני תשובות . . . חלק מהתשובות לגיטימיות, חלק לא. כשהוא מגיע ושואל את השאלה "למה לא משתמשים?” אז זה מגרד למישהו בראש, והוא אומר “רגע, באמת למה לא?”. ואז הוא אומר לו “אוקיי, אז הנה, ככה תשתמש”. ואז מנסים, ומזה הוא מקבל פידבקים - והוא רץ חזרה למערכת ומתקן, וחוזר עם משהו יותר טוב . . .(הילה) אם לבן-אדם טכנולוגי - כאילו, בכללי -  זה יהיה “PM נורא טכנולוגי” או “טכנולוגי נורא מוצרי”, זה לא משנה מה . . . המולטי-דיסציפלינריות הזאת מאפשרת לנו להוריד הרבה Feedback Loops, לרוץ מאוד מהר . . .(אורי) בדיוק . . . (הילה) וגם עוד נקודה מאוד חשובה פה - זה כזה, זו עוד ולידציה (Validation), כן?כאילו, אני גם יודעת - גם הבת זוג שלי היא אשת-מוצר. כן, זה תפקיד קצת בודד בסך הכל . . .כל המשקל של הצוות על הכתפיים שלך, צריך להצליח - עם מי עושים Brainstorms? עם מי עושים זה . . .זה הופך את זה גם ליותר “ביחד” - וזה גם מקצץ הרבה מאוד מה-Feedback Loop, אם אתה בא בתור איש-טכנולוגי.ואפילו בקוד - כאילו, אתה בקוד בא ושואל את עצמך “אוקיי, פה זה אמור להיות ככה או שזה אמור להיות ככה?”אם אתה מכיר מספיק טוב את המוצר - אתה עונה לעצמך.“הורדת שאלה לאיש מוצר - פיתחת את הקוד יותר מהר”.אז יש לזה - מלמעלה ועד למטה - השלכות מאוד עמוקות.(אורי) מפתח להצלחה, או להעלות KPI, זה פשוט היכולת לטעות מספיק מהר . . .(הילה) מסכימה . . . (רן) דרך אגב - יצא לי גם לראות המקרה ההפוך, גם חיובי, כן? של איש-מוצר, שהיו חסרים לו Feature-ים ולא היה מי שעשה את זה - אז הוא עושה את זה בעצמו . . .  אז נכון, הוא עושה את זה מכוער, ב-PHP . . . אזכור לו את זה לתמיד - אבל זה עבד . . . לא חשוב.(אורי) . . .  אבל הוא קיבל ולידציה מהר . . . (הילה) היום יש לך ChatGPT . . .איש מוצר מוציא קוד ב . . אתה יודע.[כן יודע - 472 Bumpers 83 - Nostalgia](רן) כן, אז לגמרי - זאת אומרת, חציית-הקווים קורית לחיוב - משני הצדדים. ולא לשכוח את האמפתיה!(הילה) כן,35:37 תצאו מהקופסא(רן) אז אוקיי - אז זאת היתה שיחה מעניינת, ואני חושב שאולי ה-Take-Away שלי - ואני מקווה שגם של אחרים מפה - זה “תצאו רגע מהקופסא שלכם”: אתם באמת רוצים לעשות Impact, תשאלו את האיש-מוצר שעומד לידכם, תשאלו את ה-Customer Success Manager  שנמצא לידכם . . . (אורי) תעניינו - במוצר ובלקוח.(רן) . . . מה הם עושים? מה האתגרים שלהם? מה הלקוח רוצה? . . . ואתם תגלו מהר מאוד, שלכם כנראה יש יכולת מאוד מאוד גדולה להשפיע לחיוב גם על המטריקות (Metrics) שלו - אבל בסופו של דבר גם על שלכם, ולהיות Happy-Happy, כמו שמפתחים אוהבים להיות.תודה רבה! איזה כיף. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3] פרק מספר 472 של רברס עם פלטפורמה - באמפרס מספר 83, אחרי כמעט שנה של בצורת. רן, דותן ואלון עם סדרה של קצרצרים שתפסו את תשומת הלב בתקופה האחרונה - בלוגים מעניינים, כלים ב-Open Source, כל מיני Utilities למפתחים, Database-ים, שירותים, או סתם דברים שיכולים לעניין אותנו.01:10 מבוא(רן) הפעם, בגלל שהרבה הרבה זמן לא הקלטנו , חשבנו לעשות פרק קצת שונה - פרק של נוסלטגיה. פרק שבו אנחנו ככה קצת מסתכלים אחורה, ובאים ומרימים לדברים שנראה שתפסו - ואולי גם קצת מורידים לדברים שנראה לנו שלא תפסו. אז ככה, לגמרי באופן אקראי, הלכנו והסתכלנו על הפרקים הישנים יותר, וכל אחד מאיתנו דג משם דברים שנראו לו מעניינים בקטגוריות השונות.אה - ו-Kudos על האפקטים ל-Riverside . . . .02:30 רן(רן) אז ככה, הלכתי ואספתי ממש באופן די אקראי, דברים שראיתי - שאני או דותן או אלון, אני כבר לא זוכר מי המליץ  עליהם, ונראה לי שתפסו - לפחות אצלי. דברים שאני נשארתי איתם.הראשון שבחרתי זה iTerm והשימוש ב-Z shell - דבר ראשון כשאני מקבל Mac חדש זה מתקין עליו iTerm, ככה גיליתי . . . ניסיתי גם אחרים, זאת אומרת חוץ מהטרמינל ה-Default-י של Mac, שקיים שם תמיד.יש עוד אחד, על מה דיברנו? . . . דיברנו על עוד איזשהו אחד שיצא לו מזמן, שאני דווקא פחות אהבתי, זוכרים איך קוראים לו? Warp!, נזכרתי.(אלון) שכתוב ב-Rust ,יש לציין . . .(רן) . . . והוא גם הומלץ פה בפודקאסט - זאת אומרת, מה זה “הומלץ”? הבחנו בו, ואני ניסיתי אותו במשך לפחות איזה חודש, ובסוף פחות התחברתיאבל האמת היא שהגרסה האחרונה של iTerm מאמצת ממנו פיצ'רים, ככה ראיתי - התקנתי לא מזמן את iTerm, והדמיון מתחיל ככה לעלות, אז כנראה שהיו שם כמה פיצ'רים נחמדים.אז Anyway, זה iTerm ו-Z shell, ו-Oh My Zsh - זה אחד הדברים הוותיקים שאני מתקין כמעט בתור דבר ראשון ב-Mac.אבל דותן, הבחנתי שאתה דווקא מעדיף את Fish  . . . (דותן) כן . . .  אני חייב להגיד קודם כל בנושא הטרמינלים, שאני די בטוח שזו פונקציה הפוכה לגיל . . . . ככל שאתה יותר צעיר, ככה אתה אוהב טרמינלים יותר “מודרניים”, כמו Warp, וככל שאתה יותר זקן, אין לך כוח לשטויות האלה . . . (רן) כן, כן . . . . אז למשל, אחד הפיצ'רים החדשים ב-iTerm החדש שהתקנתי זה שכשאתה עושה דאבל-קליק,  אז במקום לעשות Select - כאילו, במקום לעשות Copy אוטומטית - הוא מציע לך איזשהו “משהו אינטליגנטי” . . .וזה עיצבן אותי, אז מיד כיביתי את זה  . . . אז כן, בקיצור, אני חוזר לפיצ'רים הבסיסיים, מה שאני כבר רגיל . . .  אולי זה עניין של הרגל, אולי זה סתם עניין של פשטות, אבל כן, לגמרי . . .(דותן) זה גם יכול להיות מכיל - אני למשל עכשיו עשיתי Setup ל-Mac חדש, ובפעם הראשונה לא ישבתי ועשיתי את” הטקס” של להתקין את כל התוכנות שאני רוצה, ולקחת את ה-dotfiles וכל הדברים האלה, קנפוגים על קנפוגים (Configurations) . . . פשוט לא עשיתי שום דבר מזה.לקחתי איזה שתי תוכנות בסיסיות שאני רגיל - וזהו.אמרתי ככל שזה יגיע, אני אבוא ואני אקנפג את הדברים, כאילו בשיטה “לא מתוחכמת”.כי פשוט נמאס לי . . .והאמת שזה עושה איזשהו משהו טוב, כי אז יש . . . אחד הדברים השנואים עליי דווקא במהלך עם השנים, זה Z shell - לבוא ולקנפג אותה עם Oh My Zsh וכל ה-Plug-in-ים, שזה יכול להיות טקס מייגע, למרות שיש לך כבר את כל הקונפיגורציות.ומה ששמתי לב הוא שאחרי הקונפיגורציות, ה-Terminal שלך הוא איטי . . . - בגלל שזה Z shell וכל מיני  כאלה.אז אמרתי, טוב, זה הזדמנות לתת ל-Fish ניסיון, ובגלל שלא באתי עם כל המטענים שיש לי ב-dotfiles שלי והתחלתי מחדש, זה הלך חלק. עכשיו, החיסרון ב-Fish זה שאתה לא יכול לזרוק עליו Shell-סקריפטים רגילים - אם יש לך אוסף של כל מיני “קשקושים שצברת עם השנים”, כל מיני קונפיגורציות, אז אתה לא יכול.כי השפה שלו היא קצת שונה, ואפילו ה-Command-ים הם טיפה שונים.אבל בסוף, לא יודע, אני עובד עם Fish shell, אני חושב בלי כלום - וזה 80% מכל ה-Setup שלי ב-Oh My Zsh.ואת ה-20% הנותרים אני פשוט לא עושה . . . (רן) ועם iTerm, עדיין?(דותן) כן, iTerm. ניסיתי עכשיו Alacritty, שזה טרמינל יותר Light-weight, גם מבוסס Rust, ולהגיד את האמת, אני לא רואה הבדל . . . . הרי הביצועים, זה מה שכאילו כולם אומרים - לא רואה הבדל בביצועים.(רן) אוקיי . . . . יאללה, נקסט.(רן) הדבר הבא, שלפחות אצלי תפס - וגם פה אולי זה קצת שנוי במחלוקת - זה שימוש ב-Copilot או כלים אחרים להשלמת לקוד.אני משתמש בהם המון, ואני גם רואה הרבה מאוד ביקורת על זה - אבל אני מאוד נהנה מזה.אני לא מרגיש שזה עושה אותי טיפש יותר בתור מפתח . . . . אני כן יכול לראות איך זה עלול לעשות אותי, אבל  בינתיים לפחות לא נראה לי.דווקא להפך - אני מגלה שאני לומד מזה. זאת אומרת, לעשות דברים בצורה קצת אחרת, השלמות שאולי לא חשבתי עליהן . . . נכון, מדי פעם אני מקבל דברים ואני מסתכל ואני אומר “איזה שטות!”, כאילו - “למה שמישהו יעשה דבר כזה?!” [מזה שזו ההשלמה שקיבלת, סביר שמישהו עשה את השטות הזו וגם כתב את זה במקום מספיק פומבי כדי ש-GPT התאמן עליו…]אבל דווקא ברוב המקרים אני מוצא שזה לא רק שזה עושה אותי פרודוקטיבי - דרך אגב, בעיקר בתיעוד ודברים כאלה, זאת אומרת כתיבה של טקסט - לא רק שזה עושה אותי פרודוקטיבי, אלא שזה גם מלמד אותי לפעמים דברים חדשים, שיטות שלא הכרתי.אז אני אוהב את קו Copilot. משתמשים?(אלון) אני מאוד אוהב את Copilot . . . (דותן) אני לא . . . . אבל אני עושה דבר שונה - אני לא “מתנגד AI”, אני כאילו כותב קוד, וברגע שאני מרגיש שהקוד הוא קצת “מגעיל”, או ש”הלך לי קשה” לממש משהו - אז קודם כל אני מסיים את מה שרציתי לעשות, ואז אני לוקח את כל הדבר הזה וזורק את זה ל-ChatGPT-4, ואומר לו “איך היית משפר את זה?” ו”מה היית עושה?”.והרבה פעמים יוצא לו דווקא לתת לי כל מיני זוויות מעניינות . . . . אני לוקח את זה - וחוזר חזרה.במקום של ה”לייצר קוד” נכוויתי כמה פעמים . . . היו לי ניסיונות כאלה, לייצר נגיד פונקציה או משהו כזה, וזה היה נראה ממש טוב, אמרתי “וואלה, איזה יופי! תאמין לי - הדבר הזה מדהים!” - וחודש אחרי זה אני קולט כל מיני באגים מוזרים . . . .והאפקט הפסיכולוגי הוא שדווקא החלק שיוצר על ידי AI - זה החלק שלא בדקתי ב-Codebase . . . . כי אמרתי “אה, זה יוצר, זה ‘ברזל’, זה נראה טוב זה כאילו . . . “, ובסופו של דבר היה שם איזשהו באג מאוד עדין ואיזוטרי כזה, שה-AI ייצר, בביטחון מעולה כמובן - וזה מה שהכשיל אותי.אז אחרי פעמיים-שלוש כאלה, אמרתי שאני עובר ל-Mode שבו אני כותב, נותן ל-AI לראות מה הוא חושב - ואז או לוקח הוא לא לוקח את השיפורים שלו.(רן) אלון רצה להגיד משהו . . . (אלון) כן . . . . אני קודם כל, ה-Copilot - אחד השימושים הכי טובים שלו זה טסטים.כאילו, “תכתוב לי טסטים על הקוד” - ואתה מקבל “ערימה של טסטים”, בדרך כלל סבבה.או כותב שני טסטים ואומר לו “תכתוב לי עוד כמה כאלה!” - כאילו, עוד טסטים, תבדוק עוד דברים - אז זה גם עובד מעולה.ודבר נהדר - זה לא ה-Copilot, זה דווקא ה-ChatGPT - זה ה-Boilerplate.כלומר זה לא ה-Boilerplate המעצבן של פרויקט, אלא כשאתה רוצה עכשיו לעשות איזה אלגוריתם או משהו, אז אתה אומר לו “תכתוב לי”.ואתה מתחיל ממשהו בסיסי - ואחרי זה משפר אותויצא לי מקרים שהיה לנו איזה אלגוריתם שרצינו לכתוב ואמרנו “מורכב מדי” - אז כאילו לא התעסקנו עם זה  בכלל, כי אמרנו “עכשיו איפה נבנה Complier-ים ועצים וכל מיני דברים “, אז אמרנו “בוא נסרוק את זה עם ChatGPT”.ואז איזה שעתיים שיחה איתו - והיה לנו כבר קוד עובד.זה לא עוד לא היה Production, עוד אחרי זה היה צריך כמה ימי עבודה כדי באמת לגרום . . . to” Productionize it” - אבל זה חסך, בוא נגיד, השיחה איתו חסכה Research של שבועות, שאם הייתי נותן למישהו “בוא, תתחיל לכתוב Complier, ואיך אתה מפרק עצים ומקרים וטה טה טה . . . .” - וזה עשה את זה מעולה, עם טסטים, ובאמת . . . .אז יש מקרים מדהימים.(דותן) כן כן - זה, אחד לאחד, גם אצלי.כאילו, “ה-Brainstorming יחד איתו” עובד ממש טוב.גם אם יש לך או גם אם היה לך את הפתרון בראש, ופשוט היית צריך “מישהו” במרכאות לדבר איתו - ואז להוציא את זה מהמוח שלך - זה עובד טוב.(רן) אני מוצא, דרך אגב, גם הרבה פעמים שנגיד אני מקבל איזושהי השלמת קוד - אז מה שאני פחות אוהב ב-Workflow שהזכרת, דותן, עם נגיד ChatGPT, זה שאתה צריך לעשות Copy ולהעביר - זאת אומרת, זה קצת שובר את ה-Workflow, שובר את השטף.מצד שני, אני מסכים שהאיכות היא טובה, בדרך כלל.אבל מה שאני מוצא את עצמי עושה הרבה פעמים זה עושה סוג של איטרציות - זאת אומרת, מקבל איזושהי השלמה, לא אוהב אותה, כותב נגיד איזושהי שורת-תיעוד או משנה קצת את החתימה של הפונקציה, מקבל השלמה אחרת, אולי קצת יותר טובה . . . .סוג של עושה Prompt Engineering ל-Copilot, כדי שהוא ייתן לי את הדבר הנכון.לפעמים נגיד כותב את ההתחלה של הפונקציה ואת סוף הפונקציה - ואז מנסה לקבל השלמה קצת יותר טובה . . .וזהו, ממש גיליתי שאני כאילו סוג-של מפתח לפי זה - זאת אומרת, כותב את ה-Template מסביב, ואז מחכה להשלמות ורואה מה יוצא.מחליט אם אני לוקח או לא לוקח - ועושה איזה קצת Fine-Tuning.אבל אני לגמרי מסכים ששגיאות והזיות וכאלה - זה דברים שיכולים לקרות וכואבים.במיוחד בשפות שהן Untyped - אז שם צריך להיזהר עוד יותר.אז כן - לא ללכת “על עיוור”.טוב יאללה - נמשיך.(רן) אז הכלי הבא שגיליתי שאני משתמש בו מלא, ואני גם חושב שהוזכר ממש פה בהתחלה, זה JQזה כלי CLI ש”מפרסר” (Parsing) מ-JSON, ויכול לבחור חלקים מתוך ה-JSON.סופר-פשוט, סופר-שימושי - בקיצור, נחמד.אני משתמש בו מלא ב-CLI, לפרק קבצים וככה לעבוד איתו.אני זוכר שיש גם איזושהי גרסה חדשה שלו, שנכתבה ב-Rust - זה “JQ-משהו” . . .  לא זוכר את ההמשך, שהזכרנו גם בפודקאסט [MiSawa/xq].אבל לא משנה - מבחינתי ה-Performance שלו מספיק טוב, גם אם הוא לא הכי מהיר, אבל הוא מספיק  סבבה למה שאני משתמש.אז כן - גם אחד הכלים הראשונים שאני מתקין.ובעולם אחר - נדבר רגע על ספר! אז לא הרבה ספרים נשארו איתי, אבל ספר אחד שאני מגלה שמדי פעם אני ככה חוזר אליו בשיחות ומזכיר ולוקח מנו רפרנסים זה ה-Google SRE Book.ספר שהוציאו . . . זה למעשה כמה כרכים, זה לא בדיוק ספר, ולמעשה גם יש שתי גרסאות שלו, אבל זה נקרא ככה, “The Google SRE Book”, שבא ומסביר איך עושים - או לפחות איך עשו - Site Reliability Engineering בGoogle בתקופה שבו הוא נכתב.ואחד - זה מעניין גם לדעת איך עשו, וזה גם מן הסתם דומה וזה קורה גם בחברות אחרות.אבל יותר מעניין מזה זה עולם המושגים - מושגים כמו “Budget של שגיאות”, איך מגדירים “Uptime” וכאלה.זה מושגים שהם שימושיים, שבין אם תסכים או לא תסכים עם ההגדרות שלהם - זה עדיין שימושי לבוא ולהגדיר ולכמת את הדברים האלה, ולהשתמש במושגים האלה ביום-יום.(אלון) זה אחלה ספר - שמנו פה גם לינק בעבר, לגרסה הדיגיטלית שלו, בחינם - מי שרוצה, אפשר למצוא, לשים שוב [ושוב] . . . כן, ספר מעולה - עשיתי סביבו הרצאה אפילו פעם . . . אני חושב שיש שם פשוט “עקרונות נצחיים” כאלה . . . זה מסוג הספרים שאתה יודע, “לא יתיישנו” - הם יישארו מודרניים עוד תקופה ארוכה, עד שה-AI יחליף אותנו, ואולי נצטרך ספרים . . . .אבל עד אז, נראה לי שיש פה . . . שיש שם הרבה דברים חשובים.(רן) כן, אז כל מי שנמצא בעולם של SRE מן הסתם - אבל גם מסביב, זאת אומרת, גם ראשי צוותים ובקיצור -  אנשים שיש להם “שירותים באוויר” - מומלץ לקרוא ולפחות ככה להכיר את עולם המושגים שם.(רן) הכלי הבא, שלדעתי גם הוזכר פה, האמת שקשה לזכור, אבל דיברנו לא מעט על כלים לניהול של Infrastructure as Code, והזכרנו אני בטוח הרבה פעמים את Terraform ודומיו. אני מגלה שאני דווקא יותר אוהב כלי אחר, שנקרא Pulumi, שהוא קצת יותר חדש, קצת יותר “צעיר” מ-Terraform.הוא מנהל Infrastructure, זאת אומרת - אם יש לכם Deployment ב-AWS או ב-GCP או בפלטפורמות אחרות, אז במקום להשתמש ב-Console או במקום להשתמש ב-API, אתם יכולים להשתמש ב-Pulumi - או ב-Terraform או בכלים אחרים - כדי בעצם להגדיר את ה-Infrastructure שלכם.איך נראה ה-VPC? איזה Instance-ים יש לכם? איך נראה Bucket ב-S3? - וכו'.וזה מאוד נחמד, במיוחד כי אני עכשיו בתקופה שבה אני עובד עם כמה חשבונות AWS שונים - ואני רוצה שיהיו דברים דומים שם.אז אני פשוט כל פעם עובר חשבון ועושה “Apply” - וזה עובד שם.הסיבה שאני מעדיף דווקא את Pulumi על Terraform - שלטעמי זה היתרון, אבל זה לגמרי יכול להיות גם חיסרון - זה ש-Pulumi כתוב בשפת תכנות . . . זאת אומרת, ב-Pulumi אתה יכול לכתוב ב-Python, אתה יכול לכתוב ב-JavaScript, אתה גם יכול לכתוב ב-Go - אבל אתה כותב “בשפה אמיתית”.לעומת Terraform, שהוא דקלרטיבי (Declarative) - אתה כותב במשהו שנראה ככה קצת כמו JSON או YAMLוהשפה שלהם, שהיא מצד אחד מאוד מתוחזקת ומשוכללת מצד שני היא שפה שונה, וצריך להכיר אותה.ואם אתה רוצה לעשות Whatever, נגיד Reuse - לכתוב פונקציות, לעשות אבסטרקציות וכל זה - אתה צריך ללמוד את השפה של Terraform כדי לעשות את זה “נכון".לעומת זאת, ב-Pulumi אתה לא צריך ללמוד את השפה - זאת אומרת, אם אתה יודע Python אז אתה יכול פשוט לכתוב את זה ב-Python, ולעשות אבסטרקציות כמו שאתה אוהב.אז לפחות לי זה עובד - זה נחמד.(אלון) אני רוצה להגיד על Terraform משהו - אני יודע שאני בדעת-מיעוט, אבל אני שונא Terraform. אני חושב שזה השטן.והרשימת-טקסט הזאת שאי אפשר לדבג (Debug) אותה, אי אפשר לעשות לה טסטים - ורק אחרי שאתה עושה Deploy ב-Production אתה מגלה אם שברת משהו - זה פשוט אחד הדברים הגרועים שקרו לעולם התוכנה.אני חושב ש-Pulumi כן פותר את הבעיה הזאת - אני, כאילו באמת, אני שונא את ה-Terraform הזאת, כי אי אפשר לבדוק שם דברים, ואיך אתה בודק? אתה מסתכל על ה-Plan ואז “בעיניים” ואתה בודק?כאילו, אתה שם שם את זה ב-ChatGPT ומקווה שהוא יעלה לך על מה שפספסת?אין לך איך לעשות לזה שום טסט, עד שאתה לא באמת מעלה את זה.ואז - סיפור אמיתי, למשל - בשבוע שעבר מישהו העלה קוד, בטעות העיף הרשאות מאיזה Service ב-Production, והכל נעלם . . . .עכשיו, לא הייתה שום דרך לבדוק את זה, וב-Plan לא שמו לב שהשורת-קוד נעלמה, כי היו שם כל מיני דברים - קורה, אי אפשר לתפוס הכל ב”להסתכל על קוד” - והופ! הכל הלך לפח . . . .לא הכל הלך לפח - ה-Service הפסיק לעבוד, תקנו, הכל בסדר בסוף - אבל אני ממש לא חסיד גדול של Terraform.(רן) אני חושב ששגיאות לוגיות כאלה גם ב-Pulumi קל לעשות . . .  זאת אומרת, אולי קצת יותר קל לבדוק אותן, אבל די קל לעשות גם אותן.זאת אומרת, אני חושב שהוא רגיש באותה מידה.אבל שגיאות - בוא נגיד “יותר פשוטות”, זאת אומרת, שגיאות “Python-יות”, לא שגיאות לוגיות - ב-Pulumi קל יחסית לתפוס.(אלון) לא, יש הבדל מהותי בין Pulumi ל-Terraform, שזה משהו שנתקלתי בו הרבה - נגיד, ב-Terraform אתה יוצר Database, ואז אחרי זה אתה צריך לזכור להעביר אותו ל-Service-ים שלך.ב-Pulumi זה לא יתקמפל (Compile) לך - כי יצרת Database, ולא השתמשת בו.אם אתה ב-Go נגיד, ב-Flavor של Go כותב - הוא פשוט לא יתקמפל לך, יש לך משתנה שהוא “Not used”.וב-Terraform זה לא יקרה - הוא [Pulumi] מגן עליך הרבה הרבה יותר.אז אני - קשה לי עם Terraform . . . (דותן) אבל האמת שזה הסיפור של הנושא הזה - כי אני לא יודע אם לפני Terraform, אבל לפני זה היה את Ansible.והייתה “שגעת מטורפת” על Ansible, שאני בכלל לא הבנתי אותה - שאתה בא ולוקח “ערימות של YAML-ים”, ויש לך איזשהו Server  . . . ולפני זה גם היה Chef כמובן.אז תמיד זה הסיפור של “אני בא עם “ערימה של דקלרציות” (Declarations) - שזה כאילו דבר חיובי - ואני עושה Apply, ואז נבנה לי Cloud בדמות “הקבצים המתים, היבשים” של הקונפיגורציה שהכנתי . . . .ואין פה שום לוגיקה . . . זאת אומרת, דווקא זה שזו לא שפת תכנות וזה דקלרטיבי (Declarative) - אז זה נתפס כמשהו חיובי. “אין לך לוגיקה - אז אין לך באגים!” . . . אז תמיד היה את הסיפור של הנושא הזה - ואת האמת שאני לא יודע . . . לא יודע למה זה תפס וזה לא.כאילו, Pulumi - חשבתי שהוא מת . . . . ועכשיו הפתעת אותי, רן.(רן) יכול להיות שהוא מת, יכול להיות שרק אני משתמש . . . (דותן) לא, אבל עכשיו כשאני כאילו “מעבד פנימה” את המחשבות, וחושב על HashiCorp ומה שקורה עם זה  ו-Terraform ומה שקורה עם זה - הפוליטיקה שם וכל הריצה החוצה והזניחה של הפרויקט, שגם על זה נדבר בהמשך [וגם דיברנו בהרחבה כאן - 470 Carburetor 37 Open Source שלום לתמימות].(רן) כן, אבל בוא רגע נפריד את הפוליטיקה מהטכנולוגיה. זאת אומרת, כן - יש שם הרבה עניין עסקי, פוליטי, Whatever איך שנקרא לזה, אבל נפריד את זה רק שנייה מהטכנולוגיה.למרות שאוקיי - יש  . . . (דותן) אז הטכנולוגיה - “ה-Pitch היבש” [איך עוד אין דמות כזאת בלינדקאין/טוויטר/טיקטוק? קלאסי לאיזה Fake-Investor . . . ] אומר “אתה יודע מה? אם אתה הולך על שפת תכנות, אז יש לך באגים; ואם יש לך באגים - אז אכלת אותה!”.כי שפת תכנות == באגים . . .ואם אתה הולך על שפה דקלרטיבית, כמו XML כמו YAML - כמו Terraform, שאין שם שום לוגיקה - אז אין לך באגים.אז אתה שמת תג לא נכון, או שאתה שמת חתיכה של קונפיגורציה לא נכונה - אז כאילו המעבר בין טעות לכשל ב-Production הוא פשוט . . . עכשיו כתבתי איזה For-Loop של Off by 1 Zero - ואכלתי אותה כזה . . . (רן) אז זה לא שאין לך באגים; יש לך באגים - מסוג אחר. והאמת שכמו שאלון אמר - הם הרבה יותר גרועים . . .  זאת אומרת, באגים מסוג Infrastructure.עכשיו, אף אחת מהמערכות האלה לא חסינה לזה יותר, אבל לטעמי לפחות, אם אתה כותב בשפת תכנות שאתה מכיר יותר טוב, אז יש לך יותר מיטיגציות (Mitigations) לדברים האלה.אתה עדיין צריך לעשות את המיטיגציות ולנקוט בצעדים - אבל אתה מרגיש קצת יותר “בבית” , ואז אתה עושה את זה קצת יותר טוב.(דותן) כן, אז אני אקח את הצד הנגדי - ואז אני אגיד ”אתה מכיר יותר טוב” . . . אם יש לך צוות, ו”חוליה חלשה“ שלא מכירה טוב - ושפת תכנות זה דבר גדול - אז יש לך יותר הזדמנות לא להכיר טוב. זה רק סטטיסטיקה . . . אז אם אתה לוקח שפה דיקלרטיבית, אז הגבלת את כל הצוות ל-10% יכולת, ואז ככה יצרת “מכנה משותף של כשל” גם.(רן) כן, מסכים. העולם מלא Tradeoff-ים, אין מה לעשות.(אלון) לא יודע, זה כמו שאלה קבועה של קונפיגורציה (Configuration), שאתה שם בקוד - וזה YAML או JSON או לא משנה מה - או שתכתוב קוד . . . (דותן) השאלה היא מה אפשר “לדפוק יותר ביצירתיות” - Codebase שהוא מבוסס נטו-קונפיגורציה, או Codebase שהוא Codebase של שפת-תכנות - מה אתה יכול לדפוק יותר, בצורה יותר תכופה וגם בצורה יותר חריפה . . .(אלון) אני חושב אבל שהרציונל הגיע מזה שכביכול SRE היו מתעסקים ב-Terraform פעם, או שפעם הייתה איזו אסכולה כזאת - אז הם “לא יודעים לתכנת”, כביכול.(דותן) בדיוק, אני באתי מכיוון חיובי, רגע לתת לזה פרשנות של “אתה יודע מה? אם נגביל את כולם, אז יכול להיות שזה דבר טוב, להגביל את כולם” . . . בסדר.(רן) טוב, בסדר - יאללה, בואו נמשיך, הרשימה עוד ארוכה.(רן) עוד אייטם קטן שתפס אותי - שלדעתי אלון הביא פעם [420 Bumpers 76], לפני הרבה הרבה מאוד זמן - זה איזשהו פיצ'ר קטן שבנו מעל GitHub, מעל האתר של GitHub שנקרא GitHub 1S בזמנו.פעם זה היה איזשהו פרויקט חיצוני, והיום זה למעשה Feature שהוא Built-in בתוך GitHubזאת אומרת שאם אתם נמצאים בתוך איזשהו Repo - תלחצו על נקודה (“.”) במקלדת, פשוט נקודה - וזה “פותח לכם IDE”.זה פותח לכם למעשה את VSCode בתוך הדפדפן - ואתם יכולים ככה “לטייל בקוד”, ואפילו להתקין  Plug-In-ים.ונכון שאם אין לכם הרשאות עריכה אז אתם לא תוכלו לערוך, זאת אומרת - אם אין לכם הרשאות ל-Repo אתם לא תוכלו לערוך, אתם תוכלו רק לקרוא.אבל זה עדיין מאוד נוח לקרוא ככה קוד - אפשר לדלג להגדרה, אפשר לעשות קצת . . . בקיצור, לשנות . . .זה סופר-סופר נוח, אפשר להשתמש אם אתם ב-Node או ב-Python, להתקין את ה-Plug-In וזה יצבע לכם את הדברים בצורה יפה ויהיה “אינטליגנטי”.אז אם אתם רוצים לעשות איזושהי קריאה מאסיבית של קוד - אז תלחצו על נקודה ויש לכם “IDE בתוך הדפדפן” וככה הרבה יותר קל לקרוא אותו.(אלון) קודם כל, ל-Code Discovery זה הרבה יותר נוח לעבוד עם IDE, לא רק לכתוב קוד.  Code Discovery - להתחיל לחפש, לרוץ בין פונקציות, משתנה . . .  עם הכל זה הרבה יותר נוח.בזמנו, אמרתי שזה ה-Feature הכי טוב שראיתי באינטרנט . . . (דותן)  רגע, זה בקטגוריה של “תפס” עכשיו, זה מה שאנחנו אומרים? . . . (אלון) זה בקטגוריה של “תפס” - ואני בזמנו אמרתי שהזה הדבר הכי טוב שראיתי, ו-Drop the Mic, וזהו . . . (דותן) רגע שניכם משתמשים בזה?(רן) אני משתמש בזה, כן . . .(אלון) כן, בטח . . . הקיצר, זה אחלה, זה כיף, זה נחמד.(רן) אני לא משתמש בזה כל הזמן . . . כשאני מגיע ל-Repo - שהוא לא שלי, שלא עשיתי לו Clone - ואני קורא כמה שורות, אז אני לא משתמש בזה.אבל אם אני רוצה לקרוא קצת יותר “לעומק” - אני רוצה לדלג בין פונקציות ואני רוצה לחפש דברים - אז כן, זה נוח.(דותן) רגע, אז בוא נסביר לקוראינו [מאזינינו?] איך מתקינים את זה . . . (רן) אתה רק נכנס ל-Repo ב-GitHub ולוחץ על נקודה [“.”] במקלדת . . . (דותן) אבל איך מתקינים?!(אלון) אתה מתקין את ה-Chrome שלך או Safari - בעצם בטח לא עובד ב-Safari, אז אל תתקינו Safari . . . אתה נכנס ל-Shell, תרשום . . . .(דותן) זה Extension? . . . לחפש ב-GitHub?(אלון) תרשום: “rm, רווח, מינוס rf enter” . . . (דותן) רגע . . . (אלון) . . . ו-Sudo! . . . (דותן) לחצתי - וזה נראה כאילו זה לא עובד . . .  אני לא רואה כלום.(רן) רגע, רגע, תכף תכף זה יורד, תן לזה זמן . . .(דותן) לחכות, או? . . . אתה יודע מה? - אני אריץ את זה עוד פעם!(אלון) תריץ, תריץ עוד פעם.(רן) רגע, לא עשית סלאש / בסוף, תעשה סלאש!(דותן) כן, אני אריץ את זה פעמיים -  בשני טרמינלים, ליתר ביטחון.טוב - דברים שלא תפסו! בואו . . . . בחרתי אקראית, יש מלא מלא דברים שלא תפסו, כן . . . .  אבל סתם ככה בחרתי אקראית - ונתקלתי ב-NFT . . .זוכרים שלפני כמה - איזה חמש שנים או משהו? - כולם דיברו “NFT, NFT”. . . עכשיו, כולם ידעו שזה לא יתפס, עדיין כולם דיברווהנה, אכן - זה לא תפס . . .אז כן, זה לא תכנות Proper - אבל יצאנו לדבר על זה גם גם בפודקאסט . . .  אז הנה, מצאתי אחד לקטגוריה, לעשות לו סיפתח: דברים שפחות תפסו - NFT.אלון, שלך?25:47 אלון(אלון) שלי? טוב - Flutter. דיברנו פה עליו, ה-Framework Mobile של Google.שאז היה ראש-בראש עם React Native  . . . (רן) אנחנו עכשיו בדברים שתפסו, כן? רק נתמקד . . . (דותן) יכול להיות שהוא אומר שתפסו . . . (אלון) רגע, רגע, רגע, חכה לפינה . . . [דמיינו אפקטים אקראיים של Riverside, סטייל שירים ושערים . . . ] - בקיצור, אני לא יודע, האפקטים - צריך לעבוד עליהם טיפה . . .(רן) יש להם Delay - ברגע שאני לוחץ, אז זה לוקח קצת זמן . . . (אלון) בקיצור, היה את Flutter, שהיה מחליף של React Native והכל - והאמת שאני לא יודע מה המצב היום לגמרי, אני חייב להודות . . . .מצד אחד, אני לא חושב שהוא השתלט על השוק; מצד שני, הוא לא נעלם.(דותן) תשמע, בואו נעשה לכם רגע אתגר, רוצים אתגר?(אלון) אתגר קרת או אתגר אחר?[שבוע הספר, והבנאדם הוציא ספר וקרא לו “אוטוקורקט” - לגמרי אייטם לגיטימי לבאמפרס](דותן) תנו לי Framework של Google - שתפס . . .(רן, אלון) Angular, Kubernetes . . . .(דותן) ו-Framework אפליקטיבי?(רן, אלון) או, נו - אתה מתחיל לצמצם . . .(אלון) “Framework  אפליקטיבי ב-PHP!” . . . .(דותן) לא - משהו לאפליקציות, של Google - ו-Android לא נחשב . . . (רן) זה לא של Google, זה של Android . . .(אלון) אתה מתחיל לצמצם, כן . . . .טוב, כנראה שהתשובה היא בטח שאין משהו מיוחד . . . (דותן) אני מבקש מקוראינו לשלוח - אם אתם יודעים, אם שמעתם, אם אתם משתמשים . . . .(רן) אפליקטיבי? לא יודע - נגיד, אוסף ספריות ב-Java זה נחשב?(דותן) איזה?(רן) היה Guice, לדעתי - אבל זה ישן, כן . . .(אלון) אבל זה Java . . .(דותן) היה גם את Google Widget Toolkit - זה תפס בזמנו, זה עבד.אבל מאז . . . .(רן) Google Widget Toolkit היה זוועה, עבדתי עם זה קצת . . .(דותן) אבל זה תפס - ויחסית לזמן זה גם עבד, זה עבד טוב.(רן) תפס - אבל זה היה קשוח . . . (אלון) היה להם פעם גם את ה-Design שלהם, ה-UX Design Framework הזה, איך קראו לו? עם הכפתור . . . . (רן) Flex?(דותן) לא, Flex זה Adobe.(אלון) לא, אחד אחר.(רן) לא Flex . . . . הכפתורים השטוחים האלה . . .(אלון) עם הגדולים - הכפתור הגדול, בצד ימין למטה שתמיד היה . . . היה כזה Pattern שלהם, עם Framework, אבל לא זוכר . . . טוב, לא משנה.(דותן) אוקיי . . .  Material?(אלון)Material!(דותן) נו, וזה תפס?(אלון) לתקופה . . . (דותן) הפונט אולי נשאר איתנו - Roboto - אבל לא חושב שזה תפס  . . . (אלון) בקיצור, לפי שאלתך, אני מבין מה המצבו של Flutter כיום . . . (דותן) כן, לדעתי כן - זה הסאבטקסט פה . . . .(אלון) אז אם אני שואל אותך מה המוביל ב-Cross-Mobile Development?(דותן) אני רואה את React Native, עדיין.האמת שהרבה זמן לא נגעתי, אבל אני עדיין כאילו בכל הפורומים וכל הזה.ואני נהנה לקרוא מהצד, וזה נראה שזה כלי שהפך להיות כלי עבודה.זה כבר בלי ה-Hype, אבל זה כלי עבודה - זאת אומרת, אנשים ניגשים לזה בלי יותר מדי עכשיו . . . זה כבר לא כזה “נוצץ” כמו שזה היה לפני, אבל משתמשים - וזה עובד.(אלון) זה כבר לא דת, לפחות . . .  בוא נגיד, זה עבר מרמת הדת לרמת הפרקטיקה.(דותן) נכון, זה לא דת, זה כאילו ה-Hype cycle לגמרי במקום שזה צריך להיותותשמע, זה עובד. אנשים ששואלים, אני עדיין ממליץ - למה להסתבך?(רן)) אוקיי, Next. אלון?29:40 אלון(אלון) טוב - .NET Core!יצא בהכרזה לפני זה, אני לא זוכר כבר כמה זמן - שנתיים? אני לא זוכר מה - זה היה החזרה של .NET Framework לבמה.לדעתי הוא הולך - כאילו, במגמת עלייה.זה לא שהוא עכשיו הדבר הכי פופולרי בעולם - אבל הוא כן מתחזק, הוא בטרנד הולך ועולה.וגם קצת במעקב - הוא די מרשים.מבחינת Performance, חתימות זיכרון וכל מיני כאלה.עדיין לא ברמה של Go ו-Rust ברוב המקרים, אבל הוא מרשים מאוד - ו-#C זו אחלה שפה.אז אני חושב שבסך הכל הוא בעלייה.(רן) תזכיר לנו - .NET Core זה בעצם ה-Framework שהוא Cross-Platform, שגם ב-Linux ואחרים ו . . .?(אלון) כן, ה-.NET זה ה-.NET Framework החדש - ה-.NET Framework היה רץ רק על Windows, ואז היה איזה משהו שהיה נקרא בזמנו Mono, שהיה רץ על Linux - או מנסה לרוץ על Linux, מי שעבד איתו אז זה יותר “פחות עובד” מאשר “עובד”.ואז יצא .NET Core, שזה ההבטחה שלהם של “ה-Java האמיתי”, ה-Cross Framework, ה-Cross-Platform Framework של .Net.ובגדול - נשמע שהוא אחלה ועובד להם.(רן) אתם משתמשים אצלכם בחברה?(אלון) אצלנו לא - אבל געגועי ל-#C הם קיימים, אני חייב להודות.(רן) אוקיי, אוקיי - מה הבא?(אלון) הבא - היה פעם “ריב תקשורתי גדול” בין AWS ל-Elastic, על “האם זה הסוף של Elastic או ש-AWS נוטשיםוהיה בלגן עם התביעה, ש-AWS השתמשו בשם “Elastic” בשביל ה-Elasticsearch שלהם - שלא באמת היה Elasticsearch אלא “דמוי-Elasticsearch”, או משהו כזה . . .  אני כבר לא זוכר את כל הפרטים בדיוק.[פרק 365 הקוסמי! 365 Carburetor 26 - open source politics](רן) היום קוראים לזה OpenSearch,  דרך אגב - והמוצר חי וקיים.(אלון) כן, אבל אז אמרו שזה הסוף של Elastic . . . היו דיבורים ש”הרגו אותם, אכלו אותם, אין להם עתיד”.אני חושב מאז Elastic רק עלו וגדלו משמעותית . . . אז בסוף נראה שיש מקום לכמה ביחד.אז AWS - לא יודע מה היה בסוף, ניצחו או לא ניצחו - אבל נראה ששניהם בסדר.(רן) לא, אז בסופו של דבר, אני לא עקבתי אחרי כל הסיפור, אבל נכון היום יש את OpenSearch, שזה מוצר של Elastic, שהוא סוג של Fork של Elastic - Elastic התקדמו מאוד מאז, יש להם הרבה יותר פיצ'רים.זאת אומרת, זה מוצר הרבה יותר עשיר.ומבחינת הצלחה מסחרית - Elastic לדעתי במקום טוב . . . לא קראתי את הדוחות שלהם, אבל אני חושב שהם במקום בסך כל די טוב.(דותן) כן, ו-Elastic היום זה לא רק Elasticsearch - זו כבר חברה-חברה . . . (אלון) הם נחשבים Cyber Company, Security Company . . . זהו, טוב, נראה - אולי עוד כמה שנים נבדוק מה קורה עם Redis - עכשיו שהם יצאו מה-Open Source וסגרו את הרישיון, אז יהיה מעניין לראות מה קורה איתם בעוד כמה שנים.למרות שדותן, אתה אמרת לי “למי אכפת? כבר אין מה לפתח ב-Redis, הוא עובד” . . .  כאילו, “תעזבו אותנו בשקט”.(אלון) תמיד זה עבד, כן - אבל בואו נשים פה גם כוכבית: Redis זה מצוין ו-Redis זה מעולה, שלא נחטוף איזו תביעה . . . זאת אומרת - שרן לא יחטוף תביעה . . . (אלון) אם אתם תובעים אותי - תתקשרו לרן . . . (אלון) לא, להפך - Redis עובד!(דותן) כן, הוא מעולה, הוא מצוין, הוא יפה . . . גם הצבעים של הלוגו מדהימים . . . .(אלון) הפרק בחסות Redis!, נותני שירות Cache מהיר, Database-ים ועוד . . . (רן) כן, אני חייב להגיד פה שאני לא לוקח אחריות על שום דבר שאלון אומר . . . .(אלון) גם אני לא לוקח אחריות על מה שאני אומר . . . (רן) אבל את זה כולם יודעים . . . אני הייתי צריך להגיד את זה.33:52 דותן(רן) דותן - מה באמתחתך?(דותן) טוב, אז קודם כל בחרתי לתת מקום של כבוד ל-Postgres.אני חושב שלאורך כל הפרקים - מכמה זמן זה? עשר שנים אחורה? - Postgres הוזכר בכל מיני סיטואציות . . .זאת אומרת, תמיד היה כזה “או, הנה Database חדש שעושה Geo, רק Geo וכו’ואז Postgres בא עם איזשהו Extension - ואכל אותו.וניקח נגיד לאחרונה את כל ה-Vector Databasesאז רק נגיד - בחודשים האחרונים אני רואה שה-pgvector אוכל גם את ה-Database-ים האלה.וזה פשוט מוצר-תוכנה נפלא, שאני לא יודע . . . כאילו, נגיד אם צוללים ל-Design שלו ולהכל - אם הוא כזה טוב חיצונית, אז הוא גם חייב להיות בנוי טוב פנימית.אז זה חייב . . . באמת, חבל שאין חסות, לפרסם את Postgres . . . (רן) האמת שאני חוזר ל-Postgres הרבה פעמיםרק השבוע עשיתי פרויקט קטן - הייתי צריך לעשות איזשהו חיפוש טקסטואלי ב-Corpus כזה גדול, אמרתי "יאללה, הכי פשוט Postgres”התקנתי Postgres, ארזתי - וזה באמת סופר-קל, זה ממש כאילו, בתור כלי.ניסיתי בהתחלה SQLite - לא סחב; עברתי ל-Postgres - וסחב כמו מלך.(דותן) כן, אני חושב שבמקצוע שלנו קשה למצוא את העוגן לחזור אליו, ואתה רוצה את זה.כאילו, אתה רוצה לחזור למשהו שתמיד עבד לך.אז נגיד אצלי זה Vim - Vim זה בית   . . . זה הדבר שאני חוזר אליו, והוא תמיד עובד.וגם Postgres זה בית . . . .(אלון) אתה עושה פרסומות, דותן? בחסות . . . .(דותן) אלון, אני רואה לחלוחית של דמעה בעיניים שלך . . . (אלון) ממש, ריגשת פה, עם הבית שלך . . . .(דותן) בואו תגידו - מה “בית” אצלכם? לאן אתם חוזרים שאתם מדוכאים מתוכנה?(אלון) אני מרים אליך טלפון ושואל . . . .(דותן) לא . . .  לאן בתוכנה אתה חוזר כשאתה בדיכאון מתוכנה?(אלון) לא, Postgres הוא מדהים . . .  האמת, לא מזמן היה לי איזה ריב-טוויטר קטן [קשה מצוא בין העדכונים על זחלי-משי…]שאיזשהו חברה - שמישהו רשם שהם יורדים מ-Postgres.זה סטארטאפ עם שני לקוחות - “יורדים מ-Postgres! עוברים ל-Elastic!”.ואני לא יודע, בסדר, כל כלי לשימוש שלו - אבל נראה לי שאפשר לסחוט מ-Postgres הרבה יותר שאתה עם שני לקוחות.אני אישית, הגענו למצב ש-Postgres עשה חצי מיליון Records per Second הכנסנו איתו - זה עניין של אופטימיזציות ו”לסחוט את לימון”.אבל זה כלי . . . כאילו, ה-Go-To הבסיסי כמובן זה Postgres.יש לו את התחליפי-ענן המקבילים שלו, שאמורים להיות “אותו דבר” - שזה  Aurora DB, שהוא גם Postgres בגדול אבל קצת שונה, והמקביל שלו ב-Google, שאני לא זוכר את שמו אז הוא לא יקבל חסות . . (דותן) אז רגע - המסקנה של חברות מהפודקאסט הזה זה שהם חייבים לבחור שמות שזוכרים - שמות קליטים.לא מוצרים שעובדים - שמות שהם קליטים, לנו.(אלון) לא פשוט ב-Google זה כנראה . . . כן, נכון - הם צריכים לתת לנו שמות משעשעים . . . (דותן) נגיד FlotzDB - זה קליט! (אלון) FlotzDB זה זה שם טוב ל-Database . . . מה הוא עושה, אבל? ה-FlotzDB?(דותן) זה לא משנה . . .  הוא Database רגיל, תואם Postgres והכל - אבל השם הוא זה “FlotzDB”. זה סופר -קליט . . . (אלון) תכלס כן . . . בקיצור, אז Postgres זה אחלה. אני איתך, אני עובד איתו עדיין הרבה עם ה...(דותן) Postgres זה בית! (אלון) Postgres זה בית . כן, אין ספק - Postgres זה בית .(רן) זו הסיסמה שלנו. אוקיי.(רן) אז... בתים שהתפרקו - בואו נדבר על בתים שהתפרקו.(דותן) אז ככה - דברים שלא תפסו, ואני חייב לומר שבאיזשהו מקום ראו עליהם שלא יתפסו, זה רק מהזיכרון, כן? אז זה Atom, העורך-טקסט שהזכרנו אותו הרבה - הוא תפס ולא תפס . . . .כי בלי Atom לא היה לנו את VSCode, אז חייבים פה להגיד מילה “לעורך הפורש” . . . .(רן) לגמרי. כן.(אלון) היה גם את ה... על Atom, היה פעם את הזה של Facebook, ב-React. . . (רן) Flow?(דותן) היה להם את Flow, שזה ה...(אלון) לא, לא Flow - זה Nucleus! (דותן) אוקיי, נכון.(אלון) היה ממש IDE, מבוסס Atom . . . (דותן) כן, זה לרגע תפס . . . (אלון) לרגע הוא היה הדבר הכי נוצץ בשוק . . . (דותן) נכון, נכון . . .  איזה תמימים היינו. אגב - כל הדברים שלא תפסו, ואנחנו המלצנו, אז... זה אלון!(רן) כל הדברים שלא תפסו ואנחנו המלצנו - זה אלון.(אלון) טוב, אני רוצה להגיד - Atom היה חבר טוב. באמת, אני חייב להגיד...(דותן) האמת שזה היה צריך להיות פרק עם עורך-דין פה בתוך הזה, כדי ש...(אלון) לא לוקחים אחריות. רק רן נושא באחריות . . . לא, Atom באמת היה חבר ואח - עד ש-VSCode בעט אותו החוצה . . . (דותן) כן, שזה גם סוג של הפתעה . . . אתם חייבים לומר, חייבים להודות שבאמת, VSCode - אז Microsoft עושה Code Editor בפעם ה-X, נכון? הרי הם עשו את זה כמה פעמים . . . .מצד אחד אתה אומר, Microsoft יודעת לעשות IDEs - כי זה היה מסוף שנות ה-90.מצד שני, אתה אומר, אוקיי, אבל זה Microsoft, אז... איך זה יקרה עוד פעם, כאילו?וואו, חייבים להגיד שאפו על VSCode . . . (דותן) זהו, אז שני דברים שלא תפסו, אבל אני חושב שמראש מי שחשב שיתפוס היה סופר-אופטימי, זה Storm, למי שזוכר.זה היה Event-Based Real-Time Processing, בלה בלה בלה . . . ש-Twitter קנו, והשתמשו בזה חזק ל-Analytics בתקופה שלא היה שום פתרון טכנולוגי שייתן לזה מענה.ואחרי זה, כמובן, התפתח כל העניין של ה-Real-Time, Event-Based, Lambda, Gamma, כל הארכיטקטורות האלה . . . אבל Storm, איפשהו, נעלם - הוא היה מבוסס גם Scala ו-Clojureאני מדבר מהזיכרון, אז לא לתפוס אותי במילה . . . .ו-Scala - וואו, זה אני, כאילו, אני בא, ואין שמחה-לאיד יותר מזה . . . כי אני אימצתי Scala בערך לשבוע - ואז אמרתי “אני לא נוגע בדבר הזה יותר בחיים”.ואז היה קהל שלם של פאנטי-Scala [אולטראס-Scala?], שאמרו ש-”Scala זה מדהים!” ו-”Scala זה ה-Java הבא!” ו-Scala, Scala, Scala . . . .והתעקשתי לא לגוע בזה - וזה מזל, מזל גדול.(אלון) אני שנאתי Scala מהיום הראשון, אני תמיד הייתי בצד ההייטרי של Scala, בדעת מיעוט . . . וכמו שאתה אומר - שמחה לאיד, איזה כיף. שנאתי אותם, שנאתי את השפה הזאת.(דותן) כן, אני חושב שזה שפה שגם הרסה לעצמה, עם כל ה-Scala 2, Scala 2.13, 2.14, וכל הקפיצת-מינורי בגרסאות, שזה כל כך ביג דיל ושובר . . . ואז Scala 3, ובקיצור - שיגעון.(אלון) תן לי להרחיב לך פה בשניים - קשור ל-Scala:  אחד זה שהיה את ה-Swift, שהיה לרגע Swift Server, ושחשבנו והיתה איזו הרגשה לרגע שזו תיהיה “שפת ה-Backend הבאה” - שלא הצליחה.אבל לחילופין, מה שהאמנו בו מהרגע הראשון, זה היה Kotlin - בניגוד ל-Scala - והוא כן דווקא צמח יפה.(דותן) נכון.(רן) כן. דרך אגב, אני גם מהאנשים שאהבו Scala בהתחלה ואחר כך ממש ממש לא . . .(אלון) בוז! אה, למה האפקטים אצלך? תעשה לך בוז!(רן) אין פה, יש פה רק דברים חיוביים.אבל מה שכן, יצא לי לעבוד לא מעט עם Spark בזמן האחרון - ו-Spark כידוע כתוב ב-Scala - אז עם כל זה שהשפה כאילו הולכת החוצה, יש עוד המון המון Code Base ב-Scalaויש לא מעט מפתחים שכותבים,  לפחות ל-Spark - וכותבים את זה ב-Scala.ויש גם חברות שמה לעשות? עדיין עם השפה הזו . . . (דותן) שאין להן ברירה. כן.(רן) אז היא אולי, מבחינתנו, בדרך החוצה - אבל עדיין יש לא מעט מפתחים שעובדים ב-Scala ביום יום, אני בטוח שגם חלק מהמאזינים שלנו.אז אני לא בטוח שזו המילה האחרונה של השפה, למען האמת, אבל אני מסכים שכן - המגמה היא לגמרי החוצה.(דותן) כן. טוב - אז עשיתי פה קטגוריה של “Over-Promised”, וזה בעיקר לעצבן אתכם. אז אחד זה ה-Microservices . . . .ואני חייב להגיד - בשביל להבין את מה שאני מנסה להגיד פה, צריך רגע ללעצום עיניים ולדמיין את התקופה, של Micro Services . . . ודמיינו כנסים - כשבכל כנס, 8 מתוך 10 הרצאות היו על “איך אני בניתי ארכיטקטורת Microservices!” ו”ולמה לפרק מוצר ל-100 פונקציות, שלכל פונקציה היא בכלל Microservices . . . ”(אלון) כנס רברסים 2016 . . . (דותן) אמרתי כנסים, אני לא...וככה, לפני שאתם זורקים עליי את העגבניות, אני כבר אשחיל Kubernetes - שגם זה, לדעתי, סוג של Over-Promised גדול.ואני בעיקר מתכוון לזה שבהרבה מקרים, אתה פשוט יכול לקחת כמה Service-ים ולסגור עניין, וזהו.כדוגמת ECS, Fargate, Whatever . . . לא רוצה לפרסם, אבל . . .  Keep it simple, כאילו. זה...(אלון) כבר נגמרו לנו החסויות פשוט . . . (דותן) בדיוק, לא רוצה לפרסם יתר על המידה, כי כבר כולם דופקים פה על הדלת לחסות . . . זהו, זה ה-2 cents שלי . . . (אלון) אני חושב שה-Microservices - זה בגרות של התעשייה.כאילו, היה קטע, הרי היו מונוליטים (Monolith) ענקיים - ואז, כרגיל, התעשייה הלכה לקיצון השני, שאפילו לא הייתי אומר Microservices אלא ממש Nano-Services, שכל אחד היה אומר לך על כל פונקציה קטנה “תרים איזה Service!”(דותן) לא, זה היה מוגזם, כי זה היה דת, זה כבר היה דת . . . (אלון) נכון.(דותן) אני רק זוכר את כל הספרים - כאילו, מה אתה עושה עם כל הספרים האלה עכשיו? מה אתה עושה איתם? אתה יודע איזה כמויות של ספרים יצאו על Microservices?(אלון) מה זאת אומרת “מה אתה עושה?” למה המסכים מגיעים תמיד בלי הגבהה? - כי יודעים שיש ספרי תוכנה שאין מה לעשות איתם, וזה שימוש שלהם . . .(דותן) אה, אוקיי.(אלון) אבל, תראה - Microservices היום נהיה הרבה יותר . . . עדיין יש Micro, כי קוראים לזה עדיין ככה, אבל זה נהיה הרבה יותר Services שהם הוליסטיים יותר, ולא Micro אלא “Normal-Size Services” . . . .(רן) כמו שהיה לפני זה . . . (דותן) מה שעשית כל החיים, כן . . . (אלון) לא, היו מונוליטים עצומים פעם, אם אתה חוזר קצת אחורה - היו מונוליטים עצומים, שהיה נורא קשה לתחזק אותם. ואחרי זה . . . .עכשיו יש איזושהי בגרות - לפרק דברים, לא ל... מצד אחד לא למיליונים, ומצד אחד לא Service אחד ענק.(רן) זוכרים את המושג של J2EE? התקופה הזאת של Java Beans וכל זה - זאת הייתה ההגזמה לכיוון ה-Monolith.אחר כך הייתה ההגזמה לכיוון הMicroservice.ועכשיו אנחנו איפשהו באמצע.(אלון) אבל Kubernetes - שמע, הוא תפס בטירוף, בניגוד...(דותן) כן, לא יודע . . . החשיבה שלי זה קצת פילוסופיה - אבל בוא נסתכל עשר שנים אחורה: קח $100 בכיס, ותגיד לי איזו חומרה אתה קונה ב-$100 לפני עשר שנים, ואיזו חומרה אתה קונה היום.מן הסתם, מה שאתה קונה היום זה פי כמה וכמה, מבחינת משאבים ויכולת וכו’וגם שפות התכנות השתפרו היום בביצועים שלהן.זאת אומרת - אותם $100 קונים הרבה יותר משאבים מאשר לפני עשר שנים.ואז אני בא ואומר שמוצרים - נורמליים, לא... כאילו, לא שנפלת עכשיו על איזושהי הצלחה מסחרת וכו’ - מוצרים נורמליים, SaaS, Whatever, לא משנה, eCommerce - כנראה שקצב ההתפתחות שלהם היה לינארי.זאת אומרת, אם לפני עשר שנים היו לך באופן טיפוסי 1000 User-ים, אז היום יש לך 10000 User-ים, לא משנה כאילו, בסדר גודל נורמלי.ואם לפני עשר שנים חשבת ש-100 Request-ים לשנייה זה מטורף - אז כנראה שהיום 1000 Request-ים לשנייה זה . . . אבל החומרה, לדעתי, גדלה בקצב יותר מהיר - אז כאילו, למה לי? למה לי לסבך דברים?אם לא לקחת איזה שני Server-ים ולסגור את העניין? . . . כי מבחינת ביצועים ו-Resource-ים, זה מספיק לי.(אלון) זה דותן פה מדבר, או DHH? . . . מי פה בפודקאסט איתנו?(דותן) אבל זה נכון . . . אבל זה נכון. כאילו, קחו את זה כחומר למחשבה.אם היתה לך מכונה, או בוא נעשה אחרת - אם היתה לך מכונה, שהיו מבטיחים לך שיש לה ביצועים אינסופיים, אוקיי? אז אתה לוקח שתי מכונות כאלה, בשביל Redundancy. האם היית הולך ל-Over-Engineering של Microservices, על Kubernetes וכו' - או לוקח שתי מכונות, עם הביצועים אינסופיים האלה?אני טוען שהספרים האלה לא היו נכתבים בכלל, אם זה היה המצב . . . (רן) האם הדובר כותב Framework דמוי-Rails בשפה כלשהי?(דותן) כן . . .(רן) גילוי נאות . . . כן, אז אני מסכים - אני חושב שאחד מהעניינים זה Performance והעניין השני זה העניין של המבנה הארגוני - של אחריות ושל איך עושים Deployment וחלוקה של הצוותים וכל זה.וגם זה אולי היה...(דותן) כן, המבנה הארגוני זה אנשים, אין פה . . . אני טוען שבני אדם לא עכשיו השתנו מקצה לקצה - זה תמיד היה ככה, בכל חברה.זה טרנדים, זה משתנה עם הזמן - וזה גם עוד ישתנה, המבנה הארגוני וההדרך שבה אנחנו עושים באופן טיפוסי מבנים ארגוניים בתוכנה.(רן) כן, נכון, אני אומר רק שאחת מההבטחות - אולי לא ממומשות, אבל אחת מההבטחות - של Microservices או Services באופן כללי - זה התאמה יותר טובה למבנה הארגוני,  ככה שלהגדיר ממשקים בין רכיבים ולהגדיר אחריות של מי אחראי על כל רכיב, ושהם אחראים לכל ה-life-cycle של אותו רכיב.אם זה נגיד Service של אות’נטיקציה (Authentication) או Service של Storage - אז הם יהיו אחראים עליו, כולל ה-Deployment ו-Redundancy וכל זה.(רן) עכשיו, יכול להיות שישנן דרכים אחרות לפתור את זה, מסכים - אבל בכל אופן זה בא, מן הסתם לפתור לא רק את הבעיה של הסקליביליות (Scalability) ו-Redundancy, אלא גם את הבעיה של איך אתה מנהל צוותי פיתוח, ואיך אתה נותן להם חופש.(דותן) כן אז אז יש פה קטיגוריה נוספת של . . . יש לנו ככה, “Stick, didn't Stick” וכו’, יש פה Didn't Hold Data . . . (אלון) רגע, רגע, רגע, רגע . . . רציתי שנייה לפני שאתה ממשיך הלאה, בקשר לזה, המבנה הארגוני זה - Conway Law, שאני חסיד מאוד גדול שלו.ודבר שני, על Kubernetes - אני כן חייב להגיד שאנחנו דיברנו על Istio ושיבחנו אותו די הרבה [אפילו עם פרק ייעודי - 353 Istio] - ואני חושב שאפשר לאכול את המפרש . . .(רן) Istio, רק נזכיר למאזינים, זה Service Mesh, איך זה נקרא? . . . (אלון) כן, זה Service Mesh, מקביל ל-LinkerD, לא ידוע לשמצה . . .  אבל Istio הוא ה-Service Mesh מבית Google - עוד הצלחה מסחרת שלהם, דותן, אם חיפשת מקודם . . . . - שנחשב די סיוט . . . (דותן) אבל Google זו אחלה חברה . . . כאילו, אנחנו אוהבים את Google!(אלון) Google זה חברה טובה - הם מגייסים כרגע . . .(דותן) והלוגו שלהם בצבעים! שזה דבר טוב ונעים לעין . . . אנחנו אוהבים את החברה.(אלון) אנחנו אוהבים את Google, אנחנו רצים בGoogle - ואני גם מחפש בGoogle!מדי פעם, כש-ChatGPT לא עונה לי . . .  אפילו זה.אבל Istio, ה-Service Mesh - הוא היה הבטחה מאוד גדולה, שGoogle הוציאו - והיה אמור להיות ה-Service Mesh, ל-Kubernetes או כל פתרון אחר.הוא נולד ל-Kubernetes - ובסוף די שונאים אותו, הוא די סיוט . . . (דותן) מגניב . . . .מגניב.(דותן) טוב, אז שוב - קטגוריה של Didn't Hold Data: עכשיו, אני קצת מוטרד מהחשיפה המשפטית שיש לפרק הזה [באמת מזמן לא היה פרק 1 באפריל . . . ] - אז אני לא אגיד מה לא מחזיק Data, אני פשוט אגיד שיש ארץ, או חבל - מונגוליה! . . . . (אלון) יש גם פרי דומה . . . מנגו? אתה אוהב מנגו? אגב, סתם - זו העונה עכשיו . . . (דותן) כן, אני מאוד אוהב מנגו . . . אני חושב שה-Database, שקצת מזכיר את ה... זה פרי או ירק, מנגו?(רן) מנגו זה פרי . . . (דותן) אז זה מזכיר את הפרי “מנגו” . . . (אלון) האמת שיש בו גלעין . . . (רן) יש Delay באפקטים [ויש יתרונות לגרסת הטקסט…] - אני לוחץ, וחמש שניות אחרי זה זה מגיע . . . (אלון) אז תגיד לנו, דותן! תשלח צ'אט, משהו . . . תקרוץ.(רן) הכי נחמד כשאתה מפתיע . . . (דותן) אז זהו, אז מי שהבין - לחפש Postgres . . . מי שהבין ובתחילת דרכו לשמירת Data, מה שנקרא - לחפש Postgres.(רן) טוב, אז דברים שעבדו, דברים שנשארו איתנו ? . . . (דותן) אז דברים שעבדו, קצת אמרנו - הרבה אמרנו - VSCode עבד, עובד, מעולה.באמת, אני חושב, המוצר הכי טוב של Microsoft.חייב להגיד כל הכבוד, באמת, אחלה. (דותן) React עבד . .  ופה יש לי וידוי - אני זוכר את עצמי, בפרק על React - אתם לא זוכרים, כי אם הייתם זוכרים אז הייתם יורדים עליי, אז עכשיו אני אפתח פה - אני לא הייתי בעד React!אני . .  זאת אומרת, לא הייתי נגד, לא הייתי בעד - אמרתי שזה נראה לי מוזר, השפה הזאת.אני זוכר שמה שראינו, באותו פרק, זה רק את ה-Syntax, ואמרתי “מה, זה XML חדש?” כאילו, יש פה איזשהו XSLT, לקחו אותנו לימים האלה  . . .ומה שלא ראיתי זה שזה לא ה-Syntax אלא שזה כל ה-Framework - ו-React תפס ובגדול, וזה עובד טוב.הדבר הבא זה Rust - וגם פה הייתי סקפטי לגבי Rust . . . ואלון לא היה סקפטי, ואני הייתי ממש בעד Go - ובגלל שהייתי פאנאט על Go, אז ראיתי דברים בצבעים, בצבעים של Go, בצבעים של Gopher . . . וטעיתי . . . וואו, כמה טעיתי.(אלון) דותן, מזמן לא הזכרת Rust . . . (דותן) כן, אתה רואה? . . . (אלון) כן . . . אגב, רגע, לפני ה-Rust והבדיחת-Rust שלך - בקשר ל-React: תגיד, איפה Vue.js עומד היום?כי Vue היה...(דותן) לא יודע, מבחינתי - התחלתי רק React, כי אני לא מבין למה ללכת לכל דבר אחר.חוץ מצורך כלשהו לבלות - לבלות במקומות בשביל הכיף, ללכת לטיול בכל מיני Framework-ים אחרים . . . אם אתה בא לעבוד - אני חושב שאתה צריך לקחת React, ורק React.אלא אם כן אתה רוצה הרפתקה - אז אתה הולך, מטייל בכל מיני כאלה . . . (אלון) אני אגיד לך, עוד משהו בעולם של ה-LLM-ים וה-ChatGPT - ככל ש-Framework הוא יותר גדול ובשל, יותר קל לך לעבוד איתו עם ה-ChatGPT.(דותן) כן.(אלון) כלומר, אם תלך למשהו נישתי, תקבל תשובות נישתיות, או בקושי תשובות . . .ולכן, האפקט-רשת הולך ומתחזק היום.(דותן) בדיוק - אתה רוצה להיות בסירה גדולה, אתה לא עכשיו...(רן) כן, פעם היינו בודקים כמה Tag-ים או כמה שאלות יש ב-Stack Overflow, כמה שאלות ותשובות, נגיד לטכנולוגיה מסוימת - והיום זה באמת, צריך את המדד הזה על GPT.(דותן) כן.(דותן) ואני חייב להגיד גם - הדבר הבא זה NVIDIA - NVIDIA תפס . . . מי שזוכר, ויש לו זיכרון חזק וטוב, אז אני זוכר את כל ההכרזות - ש-”NVIDIA יוצאת משוק המשחקים” . . . . מדבר על תקופה של תחילת ה-Deep Learning.וכש-Cuda שנולד - והסיפור של NVIDIA לא היה כזה בזנ”ט . . . והנה - הגענו למקום שזו החברה הכי גדולה בעולם.(רן) השנייה הכי גדולה, לא? שני טריליון דולר, משהו כזה? . . .(אלון) לא, לא - הכי גדולה, 3.3 טריליון . . . “הפרק בחסות מניות NVIDIA! קנו מניות NVIDIA וצפו לתשואה!”“אין זו המלצה או . . . .”(דותן) כן, הייתי להגיד שגם על זה את יכול לחטוף תביעה . . .(דותן) בקיצור, רן - אתה צריך עכשיו לבחור אם זה צחוק או כפיים . . . כי יש פה איזה מכפיל 60 או משהו כזה, ל-NVIDIA.כפיים . . . בחרת כפיים . . . (רן) זו אכן בחירת הקהל.(דותן) סבבה. יש לי עוד קטגוריה של...(רן) אז NVIDIA תפס, אתה אומר . . . כדאי לקנות, יופי.(דותן) וזו לא המלצה, ולא זה . . .  אני מחפה עליך, רן - אתה חייב להגיד שזו לא המלצה.(רן) לגמרי, זה לא.(אלון) אני אומר “קנו NVIDIA בסופר הקרוב לביתכם! - חלב NVIDIA, קוטג' NVIDIA, כל מוצר של NVIDIA תופס!” . . . (רן) כן - S4 של NVIDIA!(רן) טוב - דברים ש”למה הם לא משתפרים?”(דותן) כן, למה? מה קורה פה? אז Linux Desktop - אני חייב להגיד שלמרות שאני מניח שיש מלא אנשים שיגידו “וואו, זה... מה אתה מדבר שטויות?” - אני חושב שהנושא של Linux Desktop Distribution פשוט עומד ולא זז.עשר שנים אחורה, עשר שנים קדימה - אנחנו פחות או יותר באותה סיטואציה.שזה מאוד מאוד חבל - אבל זה נתון לויכוח, כאילו, לא יודע, זה...וניסיתי לחזור ל-Linux, לפני שבועיים - וזה בעסה(רן) על מה? איך אתה מתקין את זה?(דותן) איך אני מתקין Linux?(רן) לא, כאילו, על מה? על ה-Mac שלך? על...(דותן) דיסקטים . . . (רן) על מה התקנת? על מה ניסית?(דותן) ניסיתי . . . אני ב-Mac M3, אז יש לך כמה אפשרות מאוד מאוד מוגבלות, כי ווירטואליזציה (Virtualization) וכו’ - VMware Fusion Player.הוא חינם, והוא עובד.(רן) הבנתי. אז סתם בשביל המשחק ניסית?(דותן) כן, אני לא עכשיו אמחק את הכל, ו... כאילו, עכשיו אתה תגיד “זה בגלל שלא התחייבת לגמרי!”, אז...(אלון) דותן, איך אתה יודע שמישהו משתמש ב-Linux?(דותן) נו?(אלון) הוא כבר יגיד לך.(דותן) אה, נכון. איפה הצחוקים? זה בא ב-Delay . . . (רן) עשיתי טבעי בינתיים, נטורל . . .(דותן) והפינה הנראה-לי-הכי-לוהטת זה The Rise and Fall . . . . אז יש לי פה ככה: יש לי Terraform, ו-HashiCorp בכלל.שזו הפתעה מוחלטת, באמת.האמת הייתי גם צריך לשים פה Docker . . . החברה Docker.(אלון) נכון, תכל’ס . . . (דותן) Elastic - במובן של חיפוש, אבל אני חושב שזה אין מה לעשות, פשוט הטכנולוגיות השתפרו כל כך, שאתה יכול לקחת היום מוצר חיפוש כמו Elastic - והוא יהיה טוב כמו Elastic.ו-Go - שאני במחנה הנגד, אבל לא יודע האם אני נגד בשביל סתם לעצבן, אני נגד כי אני לא רואה שום Value ב-Go יותר . . . ואני עדיין בכל הפורומים של-Go, וכל ה-Reddit-ים  וכאלה - ואני רואה “ערימות של אכזבה” מתוך הקהילה”.כל מיני דברים שקורים ב-Go, שלא נכנסתי אליהם לעומק - אבל התלונות על הניהוג של השפה.אז זהו, זה מה שנקרא . . . (אלון) תראה, התלונות על Go הן בעיקר שהשפה הולכת ונהיית מסובכת ומאבדת את הפשטות שלה.זה בעיקר התלונות על הגרסה של ה-1.23, שאמורה לצאת בקרוב - שהוסיפו Syntax,  והשפה נהיית יותר מתוחכמת, וזה כבר לא כמו “אוקיי, אני עושה For-Loop - וזו הדרך היחידה”.מה שאהבו, בניגוד ל-Scala נגיד, ש-Go היה דרך אחת לעשות דברים, בכל דבר.“ככה עושים דברים ב-Go, זהו, אין לך דרך אחרת”.בדרך אחרת זה ממש יהיה קשה לך לעשות את זה - והיא מכתיבה לך דרך אחת, בניגוד ל-Scala, שהיית עושה . . . פותח אחד באמצע פונקציה, עושה לולאה בשבע דרכים שונות.אז זה היה מה שיפה.ועכשיו פתאום נהיו יותר אופציות, והשפה קצת נפתחת . . . (דותן) אז היד החזקה מתרופפת - וה-value העיקרי שזה זה, הולך וקטן . . . (אלון) מצד שני, זה עדיין שפה שנורא . . . העקומת למידה היא מאוד, מאוד קלה, נורא קל להיכנס אליה.ומבחינת Performance והכל היא . . .  מה אלטרנטיבה שלך? רק Rust, כי אתה יודע . . . מה, Kotlin?(דותן) אני אגיד לך מה - השאלה האם זה שפה שאתה נהנה לכתוב בה?ולא נהנה כי “וואו, זה מגניב!”, אלא תזכר, בגלל שאני מכיר אותך - תזכר בימים של של #C, שהיה לך משהו “שעוטף אותך”, ואתה אומר “אתה יודע מה? אני יכול ללכת עם זה כל החיים, זה עושה הכל, אני לא צריך ללמוד שום דבר אחר”.באותה תקופה, כן? כי באותה תקופה גם ה-Use Case-ים והדברים שאתה צריך לעשות היו גם מוגבלים.(אלון) תראה, #C זה #C, אתה יודע . . . אהבתי אליה -  ואי-שם ל-Ruby עוד, אתה יודע, “ישארו לנצח”.אבל יש גם איזושהי הבנה, שאתה יודע - שאי אפשר לעשות הכל עם שפה אחת, כי לצערי אני מוצא את עצמי חוזר ל-Python מדי פעםבלית-ברירה, ממש - זה ממש “בכאב לב”, לעשות דברים ב-Python, כי יש דברים שאפשר לעשות בצורה הגיונית רק ב-Python.וזה מה שמבאס אותי, תכל’ס - שבסוף . . .(דותן)  אני יכול להגיד לך שב-Rust, מצאתי את הדבר הזה שלך ב-#C - ו-Rust עושה הכל.[מה קורה עם Werner באמת בסיפור הזה?]וגם במקומות של Python, אז קורה משהו מגניב - שהרבה מהתשתיות של Python מוחלפות ב-Rust, ובגלל זה, אז נגיד אם יש לך עכשיו DataFrames, ואתה חייב להשתמש ב-Python וכו’, אז אתה הולך ל-Polars.ושם אני, במקום להשתמש ב-Python, משתמש בספרייה-נטו, בלי כל העטיפה ב-Python, נטו.זו ספרייה של Rust, אז אני משתמש בה ישירות.אז זה Heck מגניב שקרה בצורה, לא יודע - הקהילה גרמה לו לקרות.(אלון) טוב, אולי נעבור ל-Rust . . . (רן) כן, למרות שהעולם, אם אתה מסתכל, נגיד, באיזור של ה-Deep Learning, אז עדיין זה נשלט ב-Python,ומתחת זה הכל ++C, אבל... [שוב Werner . . . ](דותן) לא, אז גם שם המניות . . . תתפלא, המניות ב-Rust.כי סתם, בוא ניקח את . . . אני מסתכל הרבה על Hugging Face ומה שהם עושים - אני מאוד אוהב את הדרך שבה הם עושים כלים.ולמי שיבחין, מי שיחטט להם ב-Repositories ויחטט במה האנשים שלהם עושים - אתם תשימו לב שהם עושים Porting לכל התשתיות שלהם ב-Rust, מ-Python.(רן) כן, זהו, Hugging Face זו חברה שהתחילה ב-Rust, אם אני זוכר נכון? והם אימצו דווקא . . . אני דווקא ראיתי הפוך, אני ראיתי שהם אימצו הרבה מאוד Python מאז.אבל אולי, כמו שאתה אומר, הם אימצו כדי אחר כך לעשות לזה Port ל-Rust . . .(דותן) יכול להיות.01:01:40 סיכומים(רן)  בכל מקרה, הגענו לסימן השעה - וזה הזמן לסיכומים. אנחנו מבטיחים לחזור בעתיד עם פרקים עם חומר מעודכן וחדש.אז זה היה פרק הזה של נוסטלגיה - עשינו, ככה, Review קצר על דברים שעבדו או לא, אבל בעתיד נביא דברים חדשים.(דותן) אחוז-הפגיעה שלנו בפרקים הוא, עכשיו שאנחנו מסתכלים אחורה, זה 50% . . . (אלון) בקיצור, אז אתה אומר להקשיב לחצי-פרק?(דותן) לא - זה או שאנחנו צודקים, או שאנחנו לא צודקים . . .  או שההמלצה טובה, או שלא.(אלון) זה כמו הבדיחה ששניים משחקים שש בש - ואחד שואל את השני “מה הסיכוי שיצא לי שש-שש?”השני חושב חושב וחושב - ואומר לו “50%! - או שיצא, או שלא יצא” . . . (דותן) איך זה היה בזמן טוב? [אפקטים של מחיאות הכפיים - דמיינו סאונד של PowerPoint מ-97 . . .]האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 471 של רברס עם פלטפורמה, שהוקלט ב-30 באפריל 2024 - אורי ורן מארחים את גל ברק כדי לדבר על מלא (ממש מלא) נוטיפיקציות. גל עובד בחברת Plus500 - וגם דיבר לא מזמן בכנס רברסים האחרון {הנה ההקלטה - Real-time Market Event Notifications: Plus500's Scalable Fanout Architecture / Gal Barak).(אורי) איך הייתה החוויה של לדבר בכנס?(גל) מדהימה. רציתי גם להגיד את זה - שאם יש איזה מישהו שמאזין ומתלבט האם להגיש לשנה הבאה, אז זו לגמרי חוויה מטורפת.זה גם היה כנס ראשון שדיברתי בו, כהרצאה. מדהים.(אורי) עכשיו אתה עושה פרומו כאילו למודרטורים שלנו אין מספיק תכנים לעבור עליהם . . . .אבל הכל יתקבל בברכה.(רן) אז תודה על המחמאות ותודה על זה שהיית - ובעצם המטרה שלנו היום זה קצת להרחיב, מעבר להרצאה שהייתה שם. אז זו לא חובת צפייה אבל מומלץ לצפות בהרצאה - ואחר כך גם להקשיב, או לעשות את זה בסדר ההפוך.01:25 קצת על גל ו-Plus500(רן) אבל קצת לפני שנעשה את זה - קצת עליך, גל: ספר לנו מי אתה, מאין באת ולאן אתה הולך.(גל) אחלה. אז אני גל, עובד היום ב-Plus500, נשוי ואבא לשתיים במשרה מלאה.לפני שהתחלתי ב-Plus500, עבדתי גם קצת בתעשייה הביטחונית, אחרי שהשתחררתי מקבע.ועוד איזושהי גיחה לעולם המחקר, בעולמות של Computer Vision - קצת רחפנים אוטונומיים, שעלו לכותרות לא מעט בתקופה האחרונה, ובנסיבות פחות משמחות.ובעצם, בשלוש שנים האחרונות אני עובד ב-Plus500 ומוביל שם את תחום ה-Communication - נוטיפיקציות, כמו שאמרת.(רן) נוטיפיקציות (Notifications) . . . תיכף נברר מה זה. ו-Plus500? למי שלא מכיר - כמה מילים.(גל) אז Plus היא בעצם קבוצת FinTech גלובאלית . . .(רן) רגע . . . “Plus” זה בקיצור, או שזה כבר השם האמיתי?(גל) לא, זה בקיצור  - Plus500 זו קבוצת FinTech גלובלית, שבעצם מפתחת פלטפורמות שונות למסחר מקוון בשוק ההון.אנחנו חברת B2C, כלומר - המוצר משווק ללקוחות פרטיים.אנחנו היום עם למעלה מ-25 מיליון לקוחות, סדר גודל של חצי מיליון אקטיביים (Active Users) בכל רגע נתון.החברה עצמה הוקמה ב-2008, והיום היא בעצם חברה גלובלית - נסחרת בבורסה הראשית בלונדון, ואנחנו עם רישיון פעילות בלמעלה מ-50 מדינות, כולל אגב גם בישראל.הרגולטור, המפקח שלנו כאן בישראל, הוא הרשות לניירות ערך - ואני מניח שעוד ניגע בנושא הרגולציה בהמשך, כי זה מן הסתם משפיע גם על עולם הנוטיפיקציות (Notifications).(רן) כלומר, מי שרוצה להשקיע בשווקי-ההון - זה המקום? או שיש פה איזשהו משהו יותר ספציפי?(גל) אז בגדול, רוב קהל-הלקוחות שלנו הוא בעצם מה שנקרא “Day Traders” - זאת אומרת, זה לא בהכרח אנשים שעכשיו קונים מדדים ושוכחים מהם.אנחנו בעצם זירת המסחר שמאפשרת את הפלטפורמות.(רן) בתרגום חופשי וממש לא מהימן - “Day Traders”  הם כאלה שקונים במשך היום ומוכרים במשך היום, לא מחזיקים לאורך זמן.כלומר, כאלה שלפחות אמורים לדעת מה הם עושים - ועושים את זה מאוד במהירות. אוקיי.(אורי) רוצים לעשות את זה מאוד במהירות . . . .(רן) כן, זאת אומרת לא כאלה ש”עושים את זה מהצד", אלא כאלה שזה ממש העיסוק היומיומי שלהם, לסחור.03:39 “נוטיפיקציות בסקייל” - איפה זה פוגש אותך?(רן) אוקיי, אז בכנס דיברת - בוא נעשה אולי קצת Recap על מה דיברת בכנס: דיברת על “נוטיפיקציות בסקייל” (Notifications at scale). איפה זה פגש אותך, בפעם הראשונה?(גל) אז אולי רגע, לפני שנדבר על איפה זה פגש אותי, בעצם נדבר רגע . . . מבחינת המערכת שלנו, המערכת נוטיפיקציות שלנו - היא לא עוד איזושהי “מערכת נוטיפיקציות נחמדה”, שאיזושהי חברה מפתחת, כאיזשהו Feature-צד נחמד.בכלל, בעולמות המסחר המקוון, נוטיפיקציות זה נתיב קריטי:גם בגלל אופי הפעילות שלו, וגם מבחינת איך שהלקוחות תופסים את ה-Feature הזה, את הכלי הזה.זה יכול להיות החל מפעולות סטנדרטיות שלקוח עושה, כמו אם עכשיו הוא פותח פוזיציה או מחליט למשוך או להפקיד כסף - אז הוא מצפה לקבל מן הסתם איזושהי אסמכתא מיידית על הפעולה שהוא ביצע.אבל מעבר לזה, הלקוחות גם יכולים להגדיר לעצמם, לדוגמא, התראות שונות במערכת, עם כלי מסוים שהם עוקבים אחריו עלה מעל סף מסויםבין אם זה המחיר שלו או אחוז השינוי שלו.והם מצפים לקבל בזמן אמת את אותן נוטיפיקציות (Notifications).וזה, כמובן בלי שבכלל נגעתי בתוכן שיווקי או כל מיני דברים אחרים שאנחנו מעבירים באמצעות המערכת הזאת.(רן) כלומר, זה כלי עבודה - זה לא סתם “FYI - הגיע מייל חדש!”, אלא . . . (גל) בדיוק, זה ממש נתיב-קריטי אצלנו במערכת, ולכן גם המשמעות והחשיבות שלו אצלנו, כשאנחנו מסתכלים על כל המערכות השונות, שבעצם מרכיבות את הפלטפורמה של Plus500.(רן) כלומר, א' - שלא תתפספס נוטיפיקציה, וב' -שתגיע מהר . . .(גל) שתגיע “נכון” - אם, כלומר, רוצים להגיע עם כל מיני “Placeholder-ים” למשתנים כאלה ואחרים . . . (אורי) כלומר, קרה . . . .(גל) קרה, בהחלט קרה . . . (אורי) מקרים שקרו . . . (גל) לא אצלנו, כמובן . . . (אורי) על גבי איזה Medium הנוטיפיקציות האלה עוברות?(גל) אוקיי, אז מבחינת ה-Medium, או מה שנקרא בשפה יותר רשמית, נקרא לזה Cross-Channel Orchestration - בעצם כל המבנה שנדרש כדי לתמוך בהודעות האלו.אז אנחנו מדברים על הודעות שנשלחות במספר ערוצים - Channels, בעצםזה יכול להיות ערוצים בתוך הפלטפורמה - אם זה הודעות ה-In-App, בתוך ה-Inbox שלנו; הודעות Pop-up, שאנחנו מקפיציםאבל זה יכול להיות גם מחוץ לפלטפורמה - אם זה הודעות Push, עבור תוכן שצריך לעבור בצורה מיידית  ומהירה, או למשל ערוץ ה-Email או SMS או WhatsAppבעצם כל סוג של תוכן שאנחנו מעבירים - יש לו את הערוץ המותאם והרלוונטי ביותר עבורו.אגב - גם הרגולציה לפעמים מכתיבה לנו איזה תוכן צריך לעבור באיזה ערוץ או בכמה ערוצים שונים.זה מבחינת אופן ההפצה.מבחינת התמיכה בפועל - אז הפלטפורמה שלנו נתמכת במספר רחב של Client-ים.זה יכול להיות מכשירי Mobile ו-Tablet-ים ו-Smart Watches וגם כמובן Desktop או Web.אז גם מערכת הנוטיפיקציות בעצם צריכה לדעת לשלוח לכל אותם מכשירי-קצה את ההודעות.(אורי) ויש גם איזשהו API או SDK, שעליהם אפשר לצרוך את ההודעות?(גל) אז בעצם, הנוטיפיקציות שלנו “רוכבות” על מספר ספקים שונים, שבסוף הם אלה ששולחים בפועל את ה-Mail או את ה-SMS וכו’.בסוף, אנחנו בנינו את המערכת שלנו על בסיס אותם APIs.אבל מבחינת SDK - לא הבנתי . . . (אורי) אם אני - יש לי את האפליקציה שלי, אם אני Day Trader או שאני בנק, לצורך העניין . . .(רן) אם אתם רוצים להציג איזשהו Widget, נגיד, באתר - ורוצים לקבל משם . . .(אורי) או שיש לי מערכת מסחר, ואני מעוניין לקבל נוטיפיקציות ממך - ואני אסמוך על הנוטיפיקציות האלה לפעול.(גל) הבנתי את הכיוון  - אז לא.המערכת שלנו היא בעצם מערכת שפיתחנו עבור עצמנו - אפשר גם לדבר על הייחודיות שלה, ובעצם על  האתגרים שהיא הציבה לנו - אבל היא מערכת שמיועדת עבור הפלטפורמה של Plus500.אנחנו לא מספקים אותה כקוד פתוח או משהו כזה.(אורי) לא, לא כקוד פתוח . . .(רן) לא, אבל זה אפליקטיבי - אלו נוטיפיקציות אפליקטיביות, אם אני מבין נכון. זו לא פלטפורמה - זה לא במובן של “בוא תתחבר לפלטפורמה הזאת, ותקבל נוטיפיקציות על מה קרה בשוק” . . .(גל) לא - בדיוק כמו שכדי לסחור במנוע המסחר ש-Plus500 פיתחה, אתה צריך להיות לקוח של הפלטפורמה, אז אותו הדבר - אתה צריך להיות לקוח של הפלטפורמה, כדי לקבל נוטיפיקציות מהמערכת.(אורי) אני יכול להיות לקוח של הפלטפורמה - באמצעות אפליקציה, שלי?(גל) אפליקציה של Plus500 . . . (אורי) לא . . .  לא משנה.(רן) לא, אין פה “סינדיקציה” - זה B2C, כמו שגל אמר בהתחלה.(אורי) כן.08:18 זו לא בעיה פתורה?(רן) אוקיי, “שאלת תם” - זה לא בעיה פתורה? כלומר, SNS, חברים . . .  כאילו, אתה יודע, עושים נוטיפיקציות בעולם.(גל) אז כן, זה נכון. זאת בעיה - אני לא אגיד שהיא פתורה. זאת בעיה שנתנו לה מספר פתרונות אפשריים.בוא נדבר רגע, נשים את היסודות של מה שמייחד את המערכת נוטיפיקציות שלנו - ואז גם נבין למה היא לא באמת פתורה . . . (רן) . . .  למה הפתרונות האחרים לא מספקים פתרון מספיק טוב?(גל) בדיוק. אז קודם כל, התחלנו בזה שאמרתי קודם שאנחנו משווקים ללמעלה מחמישים מדינות, בעצם יש לנו רישיון פעילות בלמעלה מחמישים מדינות מסביב לעולם.המשמעות של זה היא קודם כל ריבוי שפות - אנחנו תומכים בעצם ב-30 שפות בפלטפורמה, וגם כמובן  שמערכת הנוטיפיקציות צריכה לתמוך באותן שפות.זה בעצם מחייב אותנו לתוכן דינמי בצורה מאוד מאוד גבוהה.גם הטקסט עצמו מן הסתם צריך להיות מתורגם לשפות-  לאותה שפה של הלקוח.אבל זה גם משפיע מעבר לזה - אפילו על הצורה שבה אנחנו רושמים את המספרים, התאריכים, השעות . . . בין תרבויות שונות גם הדבר הזה משתנה.אצלנו, אנחנו מסמנים אלפים עם פסיקים, ויש מדינות שזה עם נקודה.וזה גם משליך מעבר לזה, גם על כל נושא ה-Time-zone, שהוא מאוד מאוד שונה. אם עכשיו צוות השיווק שולח קמפיין, בנקודת זמן מסוימת - לצורך העניין חמש שעון ישראל - יש מדינות שבהן להעביר את ההודעה הזאת אפשר באותה שעה.אבל יש מקומות, למשל כמו אוסטרליה, שזו תהיה שעה קצת פחות לגיטימית להעביר בה הודעה.ולכן גם נדרש פה איזשהו מנגנון, של תזמון ההודעות בהתאם ל-Time-zone של הלקוחות.נוסיף עכשיו על הדבר הזה את סוגיית הרגולציה - שבעצם אין לנו אפשרות ל . . . (רן)  . .  אבל פה, דרך אגב, בוא רגע נפריד. זאת אומרת, זה לא רק מערכת נוטיפיקציות - זה בעצם CMS לנוטיפיקציות, נכון? מערכת ניהול תוכן לנוטיפיקציות. כלומר מתי לשלוח את הקמפיין, מתי הבן אדם מתעורר וכל זה.(אורי) . . . ואיך זה “מפורמט” . . . (גל) נכון, אז בעצם, כל עולם ה-Communication מכיל כמה מערכות שונות.בראש ובראשונה, אנחנו תומכים בהודעות מערכת - שזה בעצם כל מיני רכיבים שונים אצלנו בפלטפורמה - אם זה מערכת המסחר או מערכת ההפקדות או הכספים ודברים כאלה.שבעצם פונות אל מערכת הנוטיפיקציות - יש לנו איזשהו Client שה-Service-ים השונים במערכת הטמיעו אצלם, והם פונים ואומרים “תשלח עכשיו נוטיפיקציה ללקוח”.אלה הודעות, מה שנקרא “הודעות מערכת” - הודעות מיידיות, שצריכות לעבור ללקוחות.אבל המסה העיקרית היא בעצם הודעות - בין אם אלה קמפיינים שיווקיים, כשאגב, גם מערכת הקמפיינים היא מערכת שפיתחנו אצלנוובין אם זה קמפייני Retention או Conversion וכל העולמות האלה - כשבעצם, מחלקת השיווק בוחרים לפנות ללקוחות מסוימים.ואז יש בבת אחת מסה של הודעות שצריכה לעבור לאותם לקוחות.אבל בעצם העניין היותר מעניין ומאתגר, שעליו גם דיברתי באריכות בכנס,  הוא הנושא של “אירועי שוק”אנחנו מתמודדים בשוק ההון, והשוק הוא מאוד מאוד תנודתי.אנחנו מן הסתם לא יודעים לצפות מה יקרה למניות - כי אם כן, אז כנראה שהיינו עושים דברים אחרים לחלוטין . . .ובעצם, ברגע נתון יכול להיות לנו עכשיו איזשהו אירוע, לדוגמא מה שקרה עם Facebook או עם nVIDIA בחודשים האחרונים - כשיש איזשהו אירוע “שמטריף את כל השוק”.ואנחנו בעצם רוצים, כמערכת מסחר, לאתר, בזמן אמת, את אותם אירועיםלאתר את הלקוחות, שזה אתגר בפני עצמו - איזה לקוחות יש, שהאירוע הזה עשוי לעניין אותם?ואז - בבת אחת, ברגע אחד - להעביר אליהם את ההודעות האלה, אל הלקוחות.אנחנו מדברים פה על מיליוני הודעות, שעוברות בפרקי זמן של שניות בודדות.ברור לך, כמו שאמרנו קודם - הקהל יעד הוא Day Traders. זאת אומרת, אנשים שרוצים לקבל את ההודעה כמה שיותר מהר ולבצע פעולה כמה שיותר מהר.(רן) כן, זה לא שהם יקראו את ה-Email שנייה אחת מאוחר מדי - הם כנראה יכולים להפסיד על זה הרבה מאוד כסף, ואולי אתם תפסידו אותם בתור לקוחות . . . (גל) ולכן זה גם לא יהיה Email - זה יהיה Push, הודעת In-App, בתוך הפלטפורמה.(רן) כן, זאת אומרת - יש פה חשיבות משמעותית לדחיפות בחלק מהמקרים, כמו שאמרת. במקרים אחרים אולי קצת פחות ,בסדר.12:16 קצת יותר מתרומות לקבר רחל(רן) וכשאתה אומר “Scale” - על איזה Scale אנחנו מדברים?(גל) אז כמו שאמרתי, אנחנו מדברים על מיליוני לקוחות.מה שנקרא “הרף העליון” - הבעיה שהגדרנו לעצמנו לעמוד בה מבחינת הספים (Thresholds) - אנחנו מדברים על כ-10 מיליון נוטיפיקציות שנשלחות.כשה”נוטיפיקציות" זה לא בהכרח 10 מיליון הודעות שונות - אלא 10 מיליון הודעות שנשלחות בערוצים שונים.לדוגמה, אותה הודעת Market Event שדיברנו עליה קודם, תשלח בשני ערוצים לפחות.ואם אתה בכלל לקוח שיש לו גם Mobile וגם Web, אז אתה גם תקבל לכל אחד מה-Client-ים שלך את ההודעה הזאת.אז אנחנו מדברים פה על סדר גודל של 10 מיליון הודעות, שעוברות ברגע נתון.(רן) ברגע נתון?(גל) ברגע שמתקבלת ההחלטה לשלוח 10 מיליון הודעות ללקוחות - אז מבחינת הזמנים שעובדים בהם . . .(רן) . . . ה-Burst, אוקיי . . .(גל)  . . . אז זה ב-10 מיליון הודעות.אנחנו מדברים על סדר גודל של עד 10 שניות, בעצם של טיפול באותן הודעות.(אורי)  . . . קצת יותר מתרומות לקבר רחל . . . (גל) “קצת” . . . גם מבחינת ה-Scale שנדרש . . .(רן) זאת אומרת, Throughput של כמיליון הודעות בשנייה, בסדר - זה כשיש לך איזה Peak, אבל לא כל היום הוא כזה . . .(גל) נכון - וזה, אגב, משהו שאני גם נוגע בו בהרצאה. זה בעצם שבגלל שכמו שאמרת, רוב הזמן זה לא קורה, אבל באותם הרגעים אתה לא יכול שלא לתמוך בזה.אז בעצם גם הארכיטקטורה צריכה לתמוך בדבר הזה, ולתת מענה גם לאותם Burst-ים, אבל בלי הצורך הבזבזני עכשיו להשקיע מלא מלא חומרה או משאבים, כדי שהדבר הזה ירוץ במשך כל שעות היום.(רן) כן, שזה אתגר. זאת אומרת, אם זה כל הזמן היה מיליון בשנייה, אז היית יכול להגיד, “אוקיי זה ה-Stable State - מזה אני מרוויח כסף אז פה אני גם משקיע כסף”, אבל אתה לא יכול. אם זה קורה לך פעם ביום, אתה לא רוצה להחזיק “צי של מכונות” רק בשביל הפעם הזאת ביום.(אורי) השאלה היא האם אתה יודע מתי זה הולך לקרות, ותוך כמה זמן אתה צריך להעלות את ה-Caps? . . . .(גל) אז אני לא יודע - כי אם הייתי יודע, אז היה מצוין . . . . אבל לצערי אני לא יודע.(רן) אולי בחלק מהמקרים - נגיד, קמפיינים. זאת אומרת, דברים כאלו מתוכננים שאתה יודע, אבל באופן . . .(גל) אז קמפיינים כן - אבל קמפיינים הם אולי גם קצת פחות מעניינים, כי הם ברובם לא נדרשים להעברה מידית ללקוחות, ולכן אני יכול גם “למרוח אותם על ציר הזמן”.הבעיה שלי היא עם הודעות שהן גם מצד אחד מהירות, כמו הודעות מערכת, אבל ב-Volume-ים של קמפיינים. זו בעצם הבעיה שלי.אם אני אומר שאני מפריד עכשיו את הנוטיפיקציות לשני סוגים מרכזייםיש את הודעות המערכת - ההודעות שמצד אחד צריכות לעבור מאוד מאוד מהר, אבל בדרך כלל הכמויות שלהן יהיו הרבה יותר קטנות.בטח כי זה כאלה שמוטרגות (Triggered) מפעולות שהלקוח מבצע.ומצד השני יש לנו את הנוטיפיקציות, שהן הקמפיינים השיווקיים - שהן בעצם כמויות מאוד מאוד גדולות של בקשות, אבל שאפשר לפרוש אותן על ציר הזמן, כי הם לא דחופות לרגע אחד.אותם Market Events שדיברנו עליהם קודם, אותם אירועי שוק שאנחנו לא יודעים לצפות - הם בעצם גם וגם.הם גם מיידיים - והם גם בכמויות גדולות.15:14 “כובע המודרטור” / סיימת את ההרצאה. מה קרה אז? (רן) אוקיי. אז אחרי שהבנו את הצורך והבנו את האתגר - הרבה מהארכיטקטורה וכל הסיפור נמצא בהרצאה ואנחנו לא נחזור על כל זה. זאת אומרת, גם בווידאו זה משהו קצת שיותר קל לראות, כי יש שקפים והכול.אבל בואו נתחיל מהרגע של אחרי - אוקיי, סיימת את ההרצאה. מה קרה אז?(גל) אז קודם כל - הרגשה מטורפת. זה אני חייב להגיד.בעצם, סיימתי את ההרצאה - ולא כל כך ידעתי איך אנשים “יאכלו את זה”.בסוף, הצגתי פה את מערכת הנוטיפיקציות שלנו - שאוקיי, זה איזשהו תהליך אבולוציוני שאנחנו עברנו, אבל זה משהו שאנחנו עברנו.וכדי בעצם להמחיש אותו, אז הצגתי את אותו סיפור, על אותם “אירועי שוק”.ולא כל כך ידעתי איך אנשים “יאכלו“ את זה והאם יהיה לדבר הזה בעצם ביקוש והאם יתעניינו.ומאוד מאוד הופתעתי מכמות הפניות - גם ברגע שאחרי ההרצאה, עם חבר'ה שניגשו אליי או בהודעות שקיבלתי לאחר מכן - שבעצם הבנתי שהנושא של נוטיפיקציות, כמערכת בכלל, הוא משהו שמעסיק לא מעט חברות.אגב, גם היה מאוד נחמד לקבל גם אנשים שאמרו לי “שמעתי כמה דברים בהרצאה שלך ואנחנו נשקול לקחת את זה גם אלינו”.אבל מה שבאמת “פתח לי את הראש”, זו העובדה שהצגתי איזשהו Use Case נורא ספציפי שלנו - Market Event, שנורא ספציפי לשוק ההון ולתנודתיות שלו.ופתאום בשיחה ככה, בשיחת מסדרון אחרי ההרצאה, ניגש אליי מהנדס, שגם עובד בין היתר עם משרד הביטחון על המערכת של פיקוד העורף, של ההתראות.הוא אמר לי, כמו שאתה לא יודע להגיד מתי יהיה לכם אירוע שוק, שעכשיו יכניס את כל המערכת ל-Stress, גם אנחנו לא יודעים מתי יהיה מטח טילים, שיכניס את כל גוש-דן עכשיו למקלטים, וצריך להעביר להם הודעות Push.גם בשיחה עם חבר, שככה ראה את ההרצאה אחר כך ב-YouTube, והוא אמר לי “אה, זה אולי גם קיים בעצם בחברות ששולחות Push-ים על אירועי כדורגל, נגיד”.נגיד, עכשיו קבוצה הבקיעה גול - ועכשיו צריך לשלוח הודעות Push למלא לקוחות.פתאום, הבעיה שהצגתי - היא הרבה יותר רחבה ממה שנחשבתי שהיא...(רן) אז פה תרשה לי רגע לשים את “כובע ה-Moderator” [אוי, זה רעיון מעולה!]. הרבה פעמים באמת אנשים, כשדיברנו קודם על הכנס ועל להגיש הרצאות, הרבה פעמים אנשים מסתכלים על החוויה שלהם - על מה שהם למדו, על המוצר שהם פיתחו, על הטכנולוגיה שהם פיתחו - והם אומרים “אוקיי, אבל זה נורא ספציפי. זה אני עשיתי, כי  הייתי צריך ב-Facebook משהו, זה אני עשיתי, כי הייתי צריך ב-Plus500 משהו” . . . וברוב המקרים אנשים באמת חושבים שזה לא מעניין אף אחד.אולי יש מקרים כאלה - אבל מצד שני, יש הרבה מאוד מקרים שבהם קשה לך באמת לדמיין את מי זה הולך לעניין, ותהיה מופתע לגלות שזה באמת הרבה הרבה יותר גנרי. וזו באמת, ככה, “חוויה פותחת עיניים” - לבוא ופתאום לפגוש את האנשים עם Use Case-ים דומים, שאולי קוראים לזה אחרת. אולי זה גול, אולי זו רקטה . . . זה לא בהכרח אירוע שוק, אבל כן, העקרונות הם אותן עקרונות, וזה באמת מאוד נחמד לבוא ולהיפגש עם אותם Use Case-ים.(אורי) האמת שגם המוח שלנו רגיל הרי לחשוב בתבניות, והוא רגיל לחשוב בתבניות של דברים שאנחנו מכירים . . . (רן) . . . אבל זה בגלל שיש לך תבנית על המוח שלנו, אורי . . .(אורי) כן . . . וגם, כשאתה מדבר על נוטיפיקציות של אירועי שוק, מישהו אחר שומע את הבעיה של פיקוד העורף. כאילו, אל תניחו - אנשים באים עם התבניות שלהם, והם ייקחו את מה שאתם אומרים לתוך התבנית שלהם, וזה פתאום יהיה רלוונטי.(רן) כן, כן. אבל מעבר לזה, גם אם אי אפשר לקחת את הפתרון שלך, לצורך העניין, ופשוט להשתמש בו כ”פתרון מדף”, עדיין - הרעיונות, העקרונות, יכולים להיות אותם עקרונות: ה-Design של המערכת.אז מה קרה אחר כך? זאת אומרת, באת ואמרת, “אוקיי, אני הולך לכתוב פרויקט ב-Open Source!, אני הולך לעשות כסף מחברה ששולחת נוטיפיקציות!” . . . כאילו, מה קורה אחר כך?(גל) לא. בעצם, אחרי הרצאה, קודם כל, הרבה אנשים פנו, זה היה מאוד מאוד נחמד גם לשמוע.גם, אגב, אנשים, בין אם זה מתוך התעשייה, שעובדים בתעשייה ובאו לדבר איתי על זה - או בין אם בכלל אנשים ממקומות אחרים, שאמרו, “רגע, אולי בעצם הפתרון הזה, או הפתרון האחר . . .”.ופתאום, זה פותח לי את הראש - מן הסתם הפתרון שלי, זה מה שאני עשיתי, ולכן זה הכי טוב, ברור.אבל, כמובן שיכולים להיות אינסוף פתרונות אחרים, שאנחנו יכולנו לקחת ולממש.וצריך ככה . . .  זה באמת, גרם לי לחשוב “מחוץ לקופסא” קצת, על דברים אחרים שאפשר לעשות.ולקחת את המערכת הזאת, בעצם את העולם הזה של נוטיפיקציות, ולפתח אותו למקומות נוספים.אפילו מבחינת המעטפת של מי ואיך משתמשים במערכת הנוטיפיקציות הזאתהיום, בעצם הצרכן המרכזי שלנו במערכת אלו אותם קמפיינים שווקיים אבל, אם עכשיו בעצם הגענו למצב שבו מערכת הנוטיפיקציות יודעת ברגע אחד לטפל בהמון המון בקשות מאוד מאוד מהר, אז עכשיו אפשר לשים את הפוקוס, רגע שנייה, על צעד אחורה - על איך אנחנו משפרים את בחירת התוכן שאנחנו שולחים ללקוחות, איך אנחנו בכלל משפרים את המנגנון של בחירת הלקוחות עבור אותם קמפיינים שווקיים . . .יש פה בעצם אינסוף אפשרויות בעולם הזה - והוא גם מאוד מאוד כלכלי.אנחנו רואים את זה בניסויי A-B Testing ובהשוואות מול קבוצות ביקורת של אותם קמפיינים שווקיים, שיש פה הרבה מאוד כסף שאפשר להכניס ולשנות את זה.(רן) מה שבא ללמדנו, אולי זו לא תגלית גדולה, אבל שלפעמים טכנולוגיה היא Enabler ל-Content. זאת אומרת, אם לפני זה יכולת לשלוח, נגיד, עד 1000 נוטיפיקציות בשנייה, אז היית חוסך, ולא היית עושה שום A-B Testing או שום דבר כזה. ברגע שיש לך את הטכנולוגיה, אתה יכול בעצם לפתח תוכן, שלוקח ושמשתמש בזה.(גל) עם האוכל, בא התיאבון . . .(רן) כן.20:51 טעויות, תיקונים ו-Vicious Cycles(רן) עכשיו, שוב, אנחנו לא ניכנס לכל ה-Design וכל הדברים שהיו בהרצאה - ושוב, מוזמנים ללכת ולראות את הווידאו, אבל אולי נדבר על דברים שלא הספקת להגיע אליהם בהרצאה. למשל, איזה כיוונים ניסיתם ללכת אליהם, ובסוף התחרטתם, או איזה דברים . . . נגיד, “ה-Playbook” או “פתרון הספר”, שלכאורה נתן פתרון, אבל גיליתם שלא.(גל) אוקיי, אז בוא נדבר על הטעויות - כי היו גם כאלה, צריך להגיד בכנות.באמת, אני מתחבר לכל מה שאמרת בסוף, עם ה-Playbook - אולי בעצם הטעות הראשונה שעשינו, זה ה-Playbook solution . . . בעצם, אני קצת מדבר על זה גם בהרצאה, על הפתרון הראשון שבעצם עשינו. לא ניכנס פה עכשיו לפרטים  הטכניים, אבל בעצם יצרנו מעטפת אחת, Notifications Serviceשמכיל בתוכו את כל הלוגיקות שהיינו צריכים בשביל לתמוך בדרישות המוצר - עם כל מה שדיברנו קודם: רגולציה, בנייה של תוכן, וכן הלאה.ובנינו אותו בעצם על בסיס שני עקרונות מרכזיים:קודם כל, כמובן, תמיכה ב-Multi-instance - תצורה של Active-Activeואז בעצם, כדי לתמוך בזה,כל Instance כזה הוא בעצם Stateless.וכמובן, זה מאפשר לנו בעצם את ה-High Availability - אם עכשיו אחד ה-Instance-ים יקרוס, מכל סיבה שהיא, יהיה תמיד את ה-Service-ים האחרים.וככה אנחנו בעצם יכולים כל הזמן לוודא שהמערכת תהיה “למעלה”, שום מידע לא יאבד והכל יהיה בסדר.בפועל, כשהעלינו ל-Production והעומס התחיל לעלות ולגדול עם הזמן - בין אם זה הלקוחות, כי כמות הלקוחות גדלה, או בין אם זה כי ה-Use Case-ים השתנואז פתאום ראינו שיש סוג-של יחס ליניארי כזה, בין כמות המידע שאנחנו צריכים לתת לו מענה ברגע אחד, כמות הבקשות - לבין כמות המשאבים, שאנחנו נדרשים להקצות, כדי לעמוד באותם עומסים.ואז בעצם הגענו למצב שבו מערכת הנוטיפיציות שלנו רצה על כמות משאבים כמו של מנוע המסחרוזה כבר ממש לא Infinite-Scale וזה כבר ממש לא Cost-Effective, וזה כבר ממש לא משהו שאנחנו יכולים להרשות לעצמנו, בעצם, להמשיך לתחזק ולעבוד איתו.(רן) כלומר, זה “עומד ב-Spec”, במובן של אוקיי, זה Highly Available - אבל זה עולה המון כדי לתחזק את זה.(גל) בדיוק. עכשיו, יבואו הרי ויגידו “אוקיי, אבל בסדר - בוא נחזיק את רוב המערכת עם רוב המשאבים כל הזמן”אבל אז - בדיוק כמו שדיברנו קודם - אם האירועי-שוק האלה יהיו עכשיו במשך 10% או 20% מהזמן, אז, 80% מהזמן שילמתי המון כסף, ללא צורך.אז בעצם הבנו ש”ה-Playbook Solution” - אותו Service אחד, שעושה את העבודה כמו שחשבנו או שקיווינו שהוא יעשה - פשוט לא עשה כמו שצריך.ונדרשת פה חשיבה מחודשת על הארכיטקטורה.ואז עשינו פירוקים ודברים - וזה כבר מופיע בהרצאה.הטעות השנייה שהייתה לנו, קשורה לנושא השרידות, ה-Resiliency של המערכת. כמו שאמרתי קודם, אנחנו התבססנו בעיקר על High Availability - זאת אומרת, תמיד אמרנו לעצמנו “לא משנה, מה יקרה, המערכת תמיד תהיה למעלה”.תמיד יהיה לפחות Instance אחד שיגבה.והדבר הזה באמת היה נכון - רק שכשהגיע אותו עומס, המערכת לא קרסה וגם אף אחד מה-Instance-ים לא קרס  . .. מה שקרה בפועל, זה ש-Flow-ים מסוימים, בעיקר ה-Flow-ים הסינכרונים - אלה שצריך כדי שעכשיו ה-Service יתן עכשיו תגובה מהירה, נגיד ל-Client, ללקוח, שפותח את האפליקציה, והוא רוצה עכשיו לקרוא תוכן בתוך האפליקציה - אז ה-Service לא היה זמין, כי הוא היה עסוק בהמון בקשות אחרות . . .וה-Flow הזה בעצם נתקע. אז במקרה הזה אין לנו פה בעיה של High Availability - פשוט יש לנו Flow, איזושהי קומפננטה (Component) שלמה, שפשוט לא מגיבה מספיק מהר.והמשמעות כאן היא פגיעה אפשרית בחוויית הלקוח.(רן) כלומר, זו בעיה של Throughput? נוצר איזשהו צוואר-בקבוק במערכת הזאת?(גל) כן, בדיוק. המערכת, באופן שבו היא תוכננה בהתחלה, בעצם ברגע שהגיע עכשיו Burst של בקשות, אז המערכת התעסקה רק בזה.ואז בעצם יש איזה סוג של מעגל, Vicious Cycle כזה - שבעצם עכשיו המערכת מקבלת הבקשות האלה ושולחת אותן, נוצר בעצם עומס של כתיבות במערכת.הלקוחות מקבלים את ההודעות, נכנסים לפלטפורמה כדי לקרוא - ונוצר עכשיו עומס של קריאות.כל לקוח קורא את ההודעה - אנחנו צריכים גם לסמן שההודעה נקראה, אז נוצר עוד פעם עומס של עדכונים, . . .כשבעצם זה איזשהו מעגל כזה, שגם מזין את עצמו.(רן) דרך אגב, רואים את זה הרבה פעמים במערכות מבוזרות - אני בטוח שראיתם [אורי] את זה גם ב-Outbrain - ברגע שנוצר איזשהו Failure, אז נוצר “כדור שלג” הרבה פעמים, “Vicious Cycle”, כמו שאמרת - כי אז יש יותר עומס על נגיד Instance-ים אחרים, ולפעמים צריכים כזה, ואז אולי Instance אחד בדיוק עלה כי רצית לעשות Scale-up - ונוצר יותר עומס על ה-Database . . .  בקיצור, זה איזשהו Vicious Cycle, שלפעמים עושה יותר נזק מאשר תועלת.אז כן, לצאת ממצבים כאלה זה לגמרי לא טריוויאלי.(גל) פתאום אנחנו, אתה יודע - פתאום ממערכת ששולחת הודעות, פתאום אנחנו צריכים להגיד לעצמנו “רגע, מה קורה עכשיו?”עכשיו לקוח מבצע, נכנס לפלטפורמה, מנסה לקרוא הודעות - והוא לא מצליח. מה עושה כל לקוח טוב, שמבצע פעולה והיא לא מצליחה? עושה אותה עוד פעם, ושוב ושוב . . . .ופתאום אנחנו משפיעים על חוויית הלקוח בצורה שבכלל לא היינו אמורים להשפיע עליה.ולכן גם נושא השרידות זו בעצם איזושהי טעות בהתחלה, כשהתייחסנו בעצם ל-High Availability כאל חזות הכל - וזה ממש לא זה.אז זו עוד איזושהי טעות ככה, שלמדנו תוך כדי.(רן) דרך אגב, אם למישהו יצא לקרוא את ספר ה-SRE של Google - הם מדברים שם נגיד על Availability. ושם, אחד הדברים המעניינים שהם אומרים - אולי זה לא, שוב, לא גילוי גדול למי שמכיר - זה ש-Availability זה לא בינארי - זה לא שזה למעלה או למטה, זה באחוזים. זה יכול להיות למעלה ל-99.9% מה-USer-ים, או 99.9% מהזמן - ותמיד, להשיג עוד אחוזון קטן, זה הרבה הרבה הרבה יותר עבודה מאשר להשיג את האחוזון הקודם, ותתכננו את ה-Availability שלכם לפי זה. כלומר, אין טעם לדבר על 100% Availability, כי זה אינסוף כסף, אינסוף משאבים - אבל כן להציג איזושהי מטרה ריאלית, כי זה משהו שהוא לגמרי אפשרי, בין זה מבחינה גיאוגרפית, מבחינת מספר ה-User-ים, מבחינת אחוזי-זמן.(אורי) אם תסתכלו על ההרצאה של יונתן זוסמן מאותו הכנס [Throttling your service: the good, the bad and the ugly / Yonatan Zusman], אז הוא מדבר על מערכת של Throttling - שאתה בעצם, כדי להשיג High Availability, אתה “מוריד מהאיכות”, או לצורך העניין מההכנסות. אבל אתה יודע שאתה עושה את זה לזמן מסוים, כשאתה ב-Peak, ומוכן לוותר טיפה על הכנסה. זה עוד מנגנון לא-בינארי ל-High Availability.(רן) כן, כן, אז נגיד אני חשבתי על זה כשהזכרת ואמרת שאוקיי, יש נוטיפיקציות שצריכות “עכשיו-עכשיו” לצאת, ויש קמפיין, שזה בסדר, זה לא נורא גם אם יוצא בעוד חמש דקות. נגיד היום - המערכת שלכם יודעת לתעדף את העומסים האלה?(גל) בעצם, יש לנו “Priority-Queue כזה” - שלתוכו נכנסות כל הבקשות שמגיעות ברגע נתון, ובעצם הוא מסדר אותן לפי העדיפויות. כמובן, התוכן השיווקי מתועדף פחות מהודעות המערכת, בטח מהתוכן הרגולטורי או דברים כאלה.אז כן - אנחנו תומכים בזה.28:03 עננים וסוגיות של גידור(רן) אוקיי. דרך אגב - מבחינת Deployments: אתם, ככה, משתמשים בחומרה שלכם - ענן, Multi-region? . . . איך זה?(גל) אז זה משתנה - תלוי על איזה Component אנחנו מדברים במערכת. ספציפית על הנוטיפיקציות?אז כן - אנחנו מדברים בעצם על VM-ים שיושבים ב-GCP.אגב - אחד השיקולים, גם בגלל ה-Volume המאוד-מאוד גדול שיש על המערכות האלה, גם הפרדנו אותן, מן הסתם מה-Cluster-ים של מנוע-המסחר.כדי שלא משנה מה יקרה - מן הסתם, אנחנו לא נקריס עכשיו את מנוע המסחר.לכן הוא יושב ב-GCP - יש לו VM-ים משלו, וכל Instance כזה גם יושב על VM-ים, כל סוג של קומפוננטה (Component) שונה במערכת.אם זה ה-Write, אם זה ה-Fanout, ה-Read - אני מרחיב על זה בעיקר בהרצאה, אבל כל אחד הם יושב בתוך VM משלו.וגם ה-Cluster של ה-RabbitMQ - בעצם אותו Message Broker שאנחנו עובדים איתו - גם הוא נפרד מכלל המערכת.(רן) כלומר - יש “גידור”, במובן הזה שאם רכיב אחד נכנס לאיזשהם צרות, אחרים לא בהכרח סובלים. זאת אומרת הם עלולים, כן? אבל לפחות בניתם את זה כך שהם לא בהכרח יסבלו.29:21 ועכשיו מה? מה עכשיו?(רן) טוב, אתם עוד עובדים על זה?(גל) אז מערכת הנוטיפיקציות - אנחנו כבר פחות. היום אנחנו בעיקר ב-Mode של תחזוקה.אנחנו כן בעיקר מנטרים (Monitor) ועובדים על המערכת, מבחינת זה שאם דברים יקרו, או שפתאום אותם ספים (Threshold) שהגדרנו לעצמנו . . .(רן) . . . תקבלו נוטיפיקציה, מה הבעיה? . . .(גל) בדיוק . . . אז אנחנו כן - השקענו המון המון בתקופה האחרונה ב-Monitoring ו-Observability למערכת הזאת.כדי שאם יקרה משהו - אנחנו נדע.ועכשיו אנחנו מתעסקים באמת בעיקר במעטפת - כמו שאמרתי קודם, לנסות לאפטם (Optimize) את קהל הלקוחות ואת התוכן שאנחנו שולחים בפועל ללקוחות.ופחות את מנגנון-השליחה עצמו.29:59(רן) אוקיי - אז תודה רבה! היה מעניין.שוב נזכיר, זאת אומרת - ה-Design הטכני של המערכת זה משהו שאנחנו לא מדברים עליו פה בפודקאסט, אבל אני כן ממליץ ללכת ולראות את הוידאו - ואת כל שאר ה-Video-ים של הכנס [יש Playlist לכל שנה] מיד אחריו.אז תודה רבה גל! אולי ככה, לסיום - אז אמרנו: Plus500, בחיפה? . . .(גל) כן - אז אנחנו יושבים בחיפה, ויש גם Site בתל אביב - אבל ה--Headquarters יושבים בחיפה.ובאמת עוד פעם - כשאנחנו מסתכלים במבט של מה קורה בעתיד, אז באמת אנחנו נכנסים או שאנחנו נמצאים היום בתקופה שאנחנו נכנסים גם לשווקים חדשים - כולל, אגב, גם השוק האמריקאי.ולכן גם זה מן הסתם יביא איתו עוד אתגרים, גם  בעולמות ה-Communication שאני מוביל, אבל בכלל, בכל עולמות הפיתוח.ולכן אנחנו מגייסים המון המון משרות - בין אם זה משרות פיתוח, אבל גם בכלל משרות אחרות.אז כל מי שככה מאזין ומחפש אתגר מעניין ולהשפיע על מיליוני לקוחות במוצר שלנו - מוזמן להגיש קורות חיים ולהצטרף אלינו.אני קצת משוחד, אבל שווה . . . (רן) אתה עוד שם . . . טוב - תודה רבה! אז Plus500  גם בחיפה וגם בתל אביב. תודה רבה גל, להתראות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 470 של רברס עם פלטפורמה - קרבורטור מספר 37, שהוקלט ב-16 באפריל 2024 - 3 ימים אחרי המטח האיראני (הראשון?) ו-193 ימים למניין החטופים שעדיין בשבי. אורי ורן מארחים את נתי שלום לעוד סבב של אסקפיזם, רכילות ושלום לתמימות בעולם התשתיות.01:29 אסקפיזם, קוד פתוח, חברות גדולות והמודל של Red Hat(נתי) אז אם באסקיפיזם עסקינן, אז למה לא Open Source? הטריגר לשיחה היום הייתה תביעה של Terraform מול משהו שנקרא OpenTofu. “תקציר הפרקים הקודמים” -  . . . (אורי) רגע, אני צריך להביא את הטבעונים עכשיו? זה פרק לטבעונים? האמת שזה כבר נשמע פרק אחד באפריל, עם ה-OpenTofu הזה . . . .(נתי) לא. עוד לא . . .  בעצם,  הסיפור שהיום נדבר עליו זה באמת “קורות מעשינו בעולם ה-Open Source” . . .מן הסתם, Open Source זה משהו שמאוד קרוב לליבי כבר הרבה מאוד שנים.מי שחושב על Open source - תמיד עולה המחשבה הרומנטית, שיש קהילה שמפתחת קוד ביחד, ובסוף יוצא מזה מוצר, בדרך כלל בחינם . . . אני זוכר שאתה - אורי - היית חסיד מאוד של החינם, בצד הזה של ה-Open Source, בגדול.והתחילו לקרות הרבה מאוד דברים, שבעצם רוקנו  את כל “הרומנטיות הזאת”, נקרא לזה, מתוכן.ואני אנסה ככה, מפעת גילי, לסדר את הסדר הכרונולוגי.אז בעצם, אני חושב שהייתי . .  ההתחלה התחילה מ-Linux, בעצם, מבחינת המגמה.שהתחיל בכלל מכתיבה של Drivers ל-Printer-ים - ווככה בעצם הגענו למערכת הפעלה Open source.ואז בעצם Red Hat בנתה מודל עסקי שלם מאחורי זה.ומאחורי הדבר הזה, בעצם, נוצר הגל הזה של Open Source - לא רק כקוד פתוח לקהילה, אלא גם כמודל עסקי.מה שנקרא Fast Forward - בעצם, חברות סטארטאפ, שהן יותר VC Backed, בעצם זיהו את הפוטנציאל לעשות Disruption לשוק.זאת אומרת, גם אנחנו נניח ב-Cloudify בנינו את זה בדיוק מאותה התפיסה - שבעצם אני חברה קטנה ואני צריך להתחרות בחברה גדולה, איך אני עושה Disrupt לשוק?אז אני בעצם, במקומות שבהם יש מוצר שהוא Closed Source, שהוא Commercial, אני אבוא עם פתרון Open Sourceאכנס “מתחת לרדאר” אקבל Adoption - ועל גלי ה-Adoption אני בעצם אוכל לעשות מוניטיזציה (Monetization).(רן) זו אסטרטגית חדירה לשוק . . . .(אורי) כן, שהיא Bottom-up ולא . . .(נתי) היא Bottom-up, וזה גם “חוק המספרים הגדולים” . . . אתה בעצם בא ואומר, בחוק המספרים הגדולים, אתה אומר “אני קודם בונה Adoption”.ואז,  עם 5%, 2% . . . נניח שיש לי מיליון Download-ים בזה, אז אני צריך מספר של בין 3% -5% כדי להצליח לייצר כבר מודל עסקי עובד.(אורי) . . . שעוברים לפרימיום? . . . (נתי) שעוברים להיות לקוח משלם ואחרי זה לפרימיום.ויש גם מודל שבו אני יודע אחרי זה להגדיל את העסקה מול אותו לקוח, על ידי גידול השימוש.זה כמובן גם בעיקרון בא לידי ביטוי בזה ש . . . בצד, היית אומר “הפחות רומנטי”, אבל זה בא לידי ביטוי בזה שעלויות השיווק והמכירה אמורות להיות יותר זולותכי אתה בונה על איזשהו מנוע ויראלי כתוצאה מזה.אבל בעצם, כשכבר נכנסים VCs לתמונה, אז הרצון מן הסתם של VCs זה למקסם, כמו כל חברה מסחרית, ויש איזושהי תקרת-זכוכית למודל העסקי שתיארתי.אז א' - אמירה אחת, שאני חושב שהיא תובנה מאוד ברורה - המודל של Red Hat עובד רק ל-Red Hat . . .זאת אומרת, כל מי שניסה לחקות את זה, ראה שבעצם זה לא עובד . . .למה הוא עובד רק ל-Red Hat? כי בעצם, Red Hat שולטת בשוק מערכות ההפעלה ב-Enterprise, שולטת בכל ה-Ecosystem הזה, ומאוד מאוד מאוד קשה לחדור ל-Enterprise-ים “על הגב” של Red Hat, לצורך העניין.כי מה ש-Red Hat עושה בדרך כלל - וזו הביקורת, שלי לפחות, לגביה - זה שברגע שהיא רואה כל פרויקט Open Source שמקבל Adoption מספיק גבוה והוא מתחיל לגדול, אז היא בעצם משתלטת עליו . . . איך היא משתלטת? היא שמה מפתחים, משנים Contributor . . . . זו שיטה מאוד קלאסית שבה אתה משתלט על פרויקט Open Source . . . [זו שיטה קלאסית לעוד כל מיני דברים . . . Backdoor Discovered in XZ: The Most Advanced Supply Chain Attack Known to Date].כי מאוד מאוד מאוד קשה לתחזק Open Source לאורך זמן [דותן פותח קבוצת תמיכה, ובמקביל קמה קבוצת גמילה . . . ]וככה בעצם היא מגיעה בשלב שבו יש בעיקר את השלב של “חליבת הכסף” ופחות השקעה בפיתוח של  Innovation ויצירת Innovation אז זה יותר לבנות על הוספת יכולות - Enterprise-grade ו-Security, הקשחות . . . כל מיני דברים מהסוג הזה.ראינו את זה ב-Ansible, עכשיו אנחנו רואים את זה ב-Kubernetes ועוד כל מיני  . . . (רן) הם גם “מספקים להם חמצן” . . . .(נתי) כן - ולכן זה עובד רק ל-Red Hat, כי בעצם הם יכולים להרשות לעצמם דברים, שאם אתה בונה על המודל העסקי הזה ואין לך את ה-Umbrella הזאת - אין לך את המעטפת הזאת - אז המודל הזה לא מחזיק את עצמו, כי בעצם אתה . . . .(רן) לפחות לחלק מהפרויקטים האלה שהם נכנסו אליהם זה דווקא עשה טוב . . . . אולי בחלק זה פוגע, אבל בחלק זה עשה טוב.(נתי) כן . . . אז בוא אני אציין כמה שמות:ל-OpenStack זה עשה מאוד רע, כי זה בעצם הרג את כל ה-Ecosystem.ל-Ansible, אפשר להגיד שזה השאיר אותו באיזשהו גובה פחות או יותר כמו שהוא נקנה, עם קצת Innovation - אבל הוריד מאוד את ה-Innovation מאחורי Ansible.הוא עדיין חי, נושם, מתפתח - אבל בקצב אחר לגמרי, “קצב Enterprise” הייתי אומר . . .אם אני מסתכל על Kubernetes, אז הם הלכו יותר לכיוונים של OpenShiftאז יש כאלה שאוהבים את התרומה שלהם ויש כאלה שמאוד לא אוהבים את התרומה שלהם.מן הסתם הם תקעו את Docker - בצדק, אגב, במידה מסויימת במקרה של Docker ספציפית . . . מי שלא מכיר את הסיפור של Docker, אז הם באמת היו אלה שהביאו את מודל ה-Container-ים לעולםאבל עלו Up the stack מהר מדי, והפכו להיות איום להרבה מאוד חברות גדולות - ואז בעצם Red Hat פיתחו את OCI - פיתחו משהו שבעצם סוגר להם הייתי אומר את ה-Ecosystem, ובעצם מוריד את  התקרה למקום הרבה יותר נמוך, שיותר קל להתחרות בהםו-Docker נהיו פתאום איזה שחקן-נישה, שבקושי עכשיו אני חושב מצליח להצדיק את המוניטיזציה שלו.והתופעה האחרונה, שאני חושב שמובילה להרבה מאוד מהדברים שאנחנו רואים עכשיו, זה שהשחקני-Cloud נכנסו לתמונהוהאסטרטגיה שלהם הייתה בעצם להיכנס בלב-ליבו של מה שהפך להיות המודל העסקי היותר מוצלח של ה-Open Source - זה ה-SaaS.(רן) אז אם רק נסכם את “פרק א’” - המודל של Red Hat עובד ל-Red Hat . . . .(נתי) רק ל-Red Hat . . . לא עובד לאחרים.(רן)  . . . המודל שבו יש Open Source “במרכז”, ומורכבים מעליו שירותי פרימיום. עבד פעם אחת - מצוין, חברה  גדולה ורווחית, עם כל הביקורת עליהם - אבל זהו, זה לא עבד יותר.(נתי) נכון.“מודל ה-VCs”, לצורך העניין - כל או רוב החברות Open Source, הייתי אומר “דור 2015” וצפונה, 2014-2015 וצפונה, נבנה לכניסה ל-SaaS.“קח Open Source בחינם - אבל את הניהול שלו אני אנהל לך ב-SaaS ואני אקח לך בעצם כסף על השירות שאני נותן לך”.וזה מסביר את Redis Labs [כאן מסבירים יותר - 457 Tech Debt with Gidon from Redis] וזה מסביר כמובן את Elasticsearch [גם כאן 362 Elastic, distributed corporate with Uri Cohen וכאן גיקונומי פרק #518 – שי בנון ואלסטיק], למרות שה-SaaS אצלהם הגיע במופע מאוחר.ו-Terraform היום עם ה-Cloud שלהם - Terraform Cloud נהיה בעצם “המנוע מוניטיזציה” (Monetization).זו הסיבה ש-VCs אוהבים את זה - כי יש לזה מודל-Scale יחסית מהיראז אתה יכול בעצם לגדול ולגדול ב-Subscription שלך יחסית מהר.(אורי)  אבל גם פה יש Pitfall . . . .ה-Pitfall בא, אני חושב,  כשה-Cloud נכנסו לתמונה . . . .כשה-Cloud נכנסו לתמונה, הם בעצם שברו את המודל הזה - כי בעצם מה הם באו ועשו? הם בעצם באו והציעו“שירות מנוהל” בעצמם, בשירות ה-Cloud שלהם . . . . (רן)  . . . זה מה שהיה עם Elasticsearch [וזה מה שהיה לשי בנון להגיד על זה](נתי) בדיוק - וזה ממש זיעזע, הייתי אומר, את כל ה-VC-backed Open Source.אף VC לא אוהב לממן את Amazon, בטח לא את Microsoft . . . ובעצם, בפועל, זה מה שקרה - זאת אומרת, אומרים ש-Amazon או Microsoft עושים הרבה יותר כסף מ-Elastic מאשר Elastic עם OpenSearch . . . ויש פה גם הרבה, לכאורה, “חוסר Fair-יות”, אם כי אני אומר בצינעה - רוב ה-Open Source-ים לקחו בעצמם גם Open Source ובנו על זה שירות מנוהל . . .גם Redis זאת דוגמה מאוד טובה, Elastic לקחו את Lucene . . . זאת אומרת - זה לא עד כדי כך “הרשע” ו-”הטוב”, או “הטוב” ו”הרשע”, איך שלא נסתכל על זה.היה פה איזשהו גל שניצל Open Source מסוים כדי לבנות עליו מודל עסקי אחר, והיו Giant-ים יותר גדולים, כמו ה-Cloud-ים, שעשו את זה בצורה אפילו עוד יותר גרידית (Greedy).(רן) הדגים הגדולים אוכלים את הדגים הקטנים . . . (נתי) כן, אז נכון - אני חושב ב-Retrospect, אני לא חושב שבהכרח . . . אני בהתחלה ראיתי את ה-Cloud-ים כרשעים הגמורים, וכמובן ששחקנים כמו Elastic כצדיקים הגמורים . . .היום, אני חושב שהתמונה היא פחות הייתי אומר שחור ולבן - בהקשר הזה.[ובתזמון מעניין - הנה עוד סיפור דומה: אחרי Redis, גם Linkerd מ̶פ̶ס̶י̶ק̶י̶ם̶  מפחיתים תמיכה במוצר הקוד הפתוח שלהם]10:53 הגבלה לא בגישה לקוד, אלא ההגבלה בשימוש בקוד(רן) אז הסיפור של Elastic היה לפני כמה - חמש שנים פלוס-מינוס?(נתי) נכון - ובאותו גל הגיעו Redis ו-MongoDBלמעשה,  MongoDB היו ראשונים - ואני חושב ש-Redis היו שניים ו-Elastic אחרונים.כש-Elastic לקחו את זה למקום שבו הקוד נגיש - אני שכחתי כבר איך קוראים למושג הזה, אבל זה בעצם . . .זה לא OpenCore  . . .  אתה יכול לגשת לקוד, אבל בעצם הרישוי-שימוש הוא משתנה - זאת אומרת, אתה לא יכול לתת שירות SaaS עליו, שזה בעצם עיקר השינוי שעשו.ובעצם, הם חילקו את הקוד לחלקים שהם בעצם Apache License או License פתוח יותר, או Permissive יותר, וחלק שהוא לא.אז ההגבלה לא הייתה בגישה לקוד, אלא ההגבלה הייתה בשימוש בקוד - שזו נקודה שכשכל אחד שמשתמש ב-Open Source והיום צריך ללכת לעורכי-דין כדי להבין . . . ויש את התעשייה השלמה, אגב, שהתפתחה רק סביב נושא של ניהול רישיונות של Open Source ובקרה עליהם . . . ובעצם זה הנושא הגדול - לאו דווקא הגישה לקוד, כי הרבה מהפרויקטים כן מאפשרים גישה לקוד, אלא מה מותר לך לעשות אותו.(רן) היכולת לעשות מוניטיזציה (Monetization) היא בעיקר בסביבת קוד.(נתי) נכון. אז כמובן שאם אתה סיני, אז יכול להיות ש...(אורי) למה רק Cloud? כאילו, כל SaaS . . .(נתי) נכון, אז אני אומר שבעצם הם רצו לחסום את היכולת של מישהו בעצם לתת שירות על בסיס הפתרון Open Source שלהם - כי זה המנוע-הכנסות שלהם.אז הם רצו לגדר את זה מחוץ לרישיון שימושוזה בעצם יצר . . .  מאוד קשה לעשות את זה בלי לפגוע מאוד בכלל בגישה ל-Open Source.12:38 עלילות Facebook עם הרישיון של React ומה שקורה היום(רן) כן, וזה גם קיים בעולם התשתיות -  נגיד React, מי שמכיר, גם היה סיפור עם רשיון, שחברות שמשתמשות ב-React, לפחות פעם, לפני שנתיים-שלוש, אסור היה להן לייצר רווחים מאותו מוצר, שזה מגוחך, כי כל מה ש... זאת אומרת, זה מגוחך, בתור מי שמשתמש, כי למה אתה בונה את ה-UI אם לא כדי בסוף לייצר רווחים?אז זה קיים לא רק בעולם “התשתיות ה-Hardcore”, אלא גם בתשתיות ה-Frontend-יות  . . . (נתי) רגע, תספר לי שנייה על React, כי יכול להיות שאני צריך לדעת משהו שאני לא יודע . . . (רן) אוקיי, אז אני לא יודע מה המציאות כיום . . . לפני כמה שנים היו מגבלות די משמעותיות בשביל השימוש ב-React, בתוך מוצרים... [Relicensing React, Jest, Flow, and Immutable.js].(נתי) אופס . . . (אורי) נתי, כמו שאומרים - זה רק בינינו פה . . . (נתי) כן . . . (רן) יכול להיות - הדובר אינו עורך דין ויכול להיות שלא הבנתי כהלכה - אבל אני כן זוכר שהיה שם איזשהו אישום, וחברות מאוד נזהרו במה שאפשר לעשות. [ובאופן כללי לא קיבלו את זה בהבנה - Facebook to Re-license React after Backlash from Open Source Community]13:36 תקציר הימים האחרונים - (עוד) חדשות מטרידות וטקטיקות נלוזות(נתי) אז זהו . . . ועכשיו אנחנו מקצרים לקראת ימינו האחרונים ותקציר הדברים בימינו האחרונים.בעצם בסוף, אני חושב, שני סיפורים שאני חושב שהם הכי בעיניי בולטים ומייצגים מגמה מטרידה מאוד - שזה בעצם Open Source שמנצל את ה-Community ואת ה-Adoption, כדי באמת להגיע לגל הראשון של ההצלחה שלו - או לגל השני או השלישי, איך שלא, זה לא כל כך משנה.וברגע שטוב לו, והוא מרגיש מאוד חזק - בעצם משנה את ה-License והופך להיות Closedבצורה שהיא אפילו מאוד מאוד בוטה וברוטאלית, ואני לא יודע אפילו איך לתאר את זה בצורה . . .  אבל מאוד מאוד גסה.אז אני חושב ש-Terraform לקחו את זה למקום שבו, למרות שהם ידעו שיש Ecosystem שלם מאחורי זה, החליטו ביום בהיר אחד להגיד שלא רק שהם הופכים את זה לסוג של Closed, אלא שהם אלה שקובעים ורק הם יכולים לקבוע.זאת אומרת שלכל אחד שהם יכולים להחליט שהוא מתחרה שלהם, בעצם אסור לעשות שימוש.מי קובע מי מתחרה ומי לא? הם . . .אז אתה לא יודע אם אתה “תיפול” על התחרות למעשה . . . (אורי) אבל האם זה לא צד מגננתי, מה-Cloud-ים?(נתי) כן אבל - אם אתה חייב את ההצלחה שלך לזה שהיית ב-Community, ו-User-ים לקחו את המוצר שלך וכתוצאה מזה אתה בכלל קיים ואתה מוצלח, אז אתה לא יכול פתאום לשנות את כללי המשחק אחרי שהצלחת.אז כשלקחת את הצעד הזה ובנית על Adoption - וידעת על ה-Adoption הזה ועל הסיכון הזה, שישתמשו במוצר שלך, לצורך העניין . . .כל Open Source בנוי על הסטטיסטיקה הזאת - שיהיה “Abuse” באחוזים כאלה ואחריםולכן אתה אתה יודע שכדי להגיע ל-Adoption, אתה מניח שיש אחוז Abuseקטן או גדול - זה כבר עניין של עד כמה אתה רוצה לעשות מזה כסףוזה התנאי שלך להצליח - ולכן אתה לוקח את הסיכון הזה.אתה לא יכול - אחרי שאתה מצליח - להגיד “אה פוס! עכשיו אני כבר גדול! תודה רבה Community שעזרתם לי להגיע לגודל שאני הגעתי, עכשיו אני משנה את כללי המשחק” . . . .שביום בהיר אחד אני מודיע לכם שמעכשיו, כל מי שמשתמש במוצר שלי מהנקודה הזאת והלאה הוא בעצם עובר עבירה.ועכשיו חברות שלמות שבנו מוצרים . . . (אורי) הם לא אמרו שהוא עובר עבירה, אלא הם אמרו “אנחנו נחליט מי עובר עבירה” . . .(נתי) שזה בעצם אומר שאם אתה עורך דין או שלצורך העניין אם אתה VC שמשקיע בחברה, אתה אומר זה Open-ended . . .(אורי) נכון . . .  (נתי) . . . זו לא אפילו הגדרה שהיא “מספיק משפטית” - אני לא יכול אפילו לשים עורך-דין שיגיד לי אם עברתי את העבירה הזאת . . . (אורי) נתי, אני קצת ה-Devil Advocate פה - ממה נפשך? ממה הם רצו להתגונן?(נתי) הם רצו להתגונן מ-Amazon  . . . והם רצו להתגונן לא רק מ-Amazon, כי מ-Amazon זה דווקא היה חלק קל לדעתי עבורם להתגונן.הם רצו להתגונן כי - א' - הם מנפיקים לבורסה, וכשאתה מנפיק לבורסה עוד יותר ניהיה Greedy, כי אתה רוצה בסופו של דבר למקסם רווחואז אתה מתחיל להגיע לתקרות-זכוכית, ואתה רוצה כל הזמן לראות שאתה שובר את התקרות-זכוכית.הם אגב - בגלל קצב הגידול - הם בסוג של עדיין הפסדים למרות שהם גדלים ב-Revenue.אז המהלך שלהם היה . . .(אורי) אגב - זה כי הם ב-Cloud . . . (נתי) גם יכול להיות . . .  זה כבר דיון אחר, לא נפתח אותו עכשיו . . . אז אני אומר שכשקראתי את המהלך הזה ואמרתי “אוקיי משהו פה מאוד Fishy, זה לא נראה . . .”נראה שהם הלכו יותר מדי רחוק בצעד הזה - יותר רחוק מכל אחד אפילו שראיתי עד עכשיו.זאת אומרת - כמעט בלי התחשבות בכלל בקהילה.אז א’ - רואים שהיזם . . . לא Hashimoto, ברח לי השם שלו . . . (רן) Hashimoto הוא היזם שיצר את החברה.(נתי) נכון - והוא כבר פחות פעיל.(רן) הוא כבר יצא מהחברה.(נתי) נכון, בדיוק - ואז בעצם אתה רואה שהייתה פה איזושהי השתלטות על החברה מהצד העסקי . . .(רן) מתי זה היה, השינוי הזה שהם עשו?(נתי) אני חושב ששנתיים פחות או יותר, די בצמידות למהלך הזהואתה רואה שהרוח הזאת היא ש . . . כי Terraform, אני חושב, למשל אחד הדברים שבאמת אפיינו אותה זה באמת הליכה הזאת על Open Source בצורה מאוד, הייתי אומר כמעט כ-Role Model לאיך שבונים Open Sourceעם זה שהם באמת בנו תפיסה של One Product לכל פונקציה ולא לעשות איזשהו סוויטה (Suite) אלא ללכת על Product-ים שכל אחד הוא טוב בתחומו.ולבנות הרבה מאוד סוג כזה של מוצרים.בנו משהו לתפארת, באמת -  אני התחרתי בו בתקופות מסוימות.(רן) למי שלא מכיר את Terraform, זה כלי לתחזוקה ולניהול של Infrastructure. אותה חברה גם מייצרת את Vagrant.(נתי) יצרה את Vagrant - למעשה, Terraform צמחה מהניסיון ב-Vagrant.(רן) כן, שזה כלי לניהול של Virtual boxes, של Virtual Machines על מכונות קטנות, לטעמי. איזה עוד מוצרים יש להם אגב?(נתי) יש להם את Vault, שהרבה מכירים, שזה לעולמות ה-Security, ויש להם עוד כמה מוצרים אחרים, אבל בגדול, ה . . . (רן) סדרה של מוצרים שהם Standalone, אבל כל אחד מהם מאוד טוב.(נתי) נכון. והם בנו מודל ממש מעניין לאיך הם בעצם בונים Stack מאחורי הדבר הזה, ואיך כל אחד מהם בעצם בסופו של דבר תורם אחד לשני.יש שם מודל עסקי לכשלעצמו.כמו המודל Open Source, גם המודל עסקי שלהם היה מאוד מאוד יפה ומוצלח - אבל הם הגיעו לנקודה שבה זה גם לא הספיק . . . הם רצו להנפיק, כנראה במחיר מאוד גבוה - ופתאום גם . . .  וזה פחות או יותר הסביר את המהלך הראשון הזה, של להביא מנכ”ל שהוא יותר איש כספים ועסקי, ופחות מן הסתם רואה בקהילה . . .אני מכיר את השיח הזה מ-VCs שמגיעים לנקודה הזאת, אז אני יכול לראות את הלך-הדברים - ואני מעריך שלאותו יזם באמת היה פחות נוח כבר בסביבה הזאת, והוא הרגיש פחות . . .הוא היה מנכ”ל בתקופות האלה, ואני מרגיש שהלחץ הזה בעצם לעשות מוניטיזציה (Monetization) על חשבון Community כנראה “לא עבר לו טוב בנשמה”.וכנראה שזה עמד גם מאחורי המהלכים שהוא עשה - לקחת backseat אחרי הדבר הזה, אחרי הנפקה.וזו הייתה התגובה של ה-Community - בעצם, התגובה של ה-Community, ואני תכף אתן עוד כל מיני דוגמאות, כי יש כמה דוגמאות נוספות שמתחילות ללכת בקו הזה, זה להגיד “אוקיי, הבנו - אנחנו לא משחקים את המשחק הזה” - והם יצרו Fork.כש-Fork זה בעצם לקחת את הקוד לפני השינוי-רישיון, ובעצם לייצר פרויקט נפרד.ראינו את זה ב-MySQL, והיו עוד אי-אילו דוגמאות כאלה - לא כולן הצליחו, אבל זו תגובה מאוד לגיטימית של Community, שאומרת “זה שייך ל-Community. אתם הרווחתם את הזכות שלכם בכלל להיות במקום שאתם בזכות ה-Community, ואנחנו כ-Community נגיב וניקח את זה למקומות האלה”.הטענה, כמובן, של Terraform מהבחינה הזאת זה שמי שמממן את ה-Fork הזה אלו חברות For-Profits, . . . זאת אומרת - זה לא כזה נקי, זה לא באמת Community.זה חברות שבעצם “רוכבות” על הגל הזה . . . (רן) “מימון זר”, כמו שאומרים היום . . . (אורי) לא, חברות שאומרות “יש לנו ביזנס מספיק גדול מעל ה-Primary, מעל ה-Truck, ואנחנו רוצים לשמר לעצמנו את ה...” . . . (נתי) נכון, אז בשיח, אם אתה תראה, אז הם קוראים להם לא “Community” אלא קוראים להם “For-Profit”בכוונה מראש, כדי להגיד שזה לא באמת נקי.ובעצם משתמשים ברמה כזו או אחרת - ותכף ניגע ב-Linux Foundation ובתפקיד שלו בתוך הדבר הזה . . .אבל כמו שקרה ב-Elastic, אז בעצם חברות ה-Cloud הבינו שאם הם ייקחו Ownership על ה-Fork הזה, אז זה יצבע את זה בצורה מאוד נגטיביתאז לכן, מה שהם עושים זה בעצם מייצרים סוג של “Open Source נייטרלי” - והם בעצם עוזרים במימון שלו ובדחיפה שלו וב-Contribution אליו.וככה בעצם הם משאירים אותו עדיין Open Source - והם יכולים לעשות את המוניטיזציה (Monetization), והם מורידים מאחוריהם את האש טיפה . . .(אורי) בסוף זה שיווק . . . (נתי) בסוף זה שיווק - והם טיפה מורידים . . . לא טיפה - הם מצליחים בדרך הזאת להפוך את עצמם מ”הרשעים” של העניין להיות, הייתי אומר, “המלאכים שמצילים את ה-Community”מזה שהחברה עושה עכשיו זה תרגיל של מוניטיזציה על חשבון ה-Community וכל מיני דברים מהסוג הזה.(רן) וקודם כל - זה מוצר של Microsoft או של Amazon, מייצרים איזשהו Foundation (לא כזה, כזה), תורמים אליו כסף - והנה אתם אלה שהצלתם את הOpen Source, “ועל הדרך” גם הם מרוויחים את זה.(נתי) בדיוק - והם יכולים לשמר את זה, ומן הסתם יש עוד חברות אחרות שממשיכות לתחזק את זה, ולא רק הם.וככה, פחות או יותר, זה נובע מזה.אז הייתי אומר שזו נקודה אחת.22:42 הטופו שהגדיש את הסאה / שלום לתמימות(נתי) מה שככה הגדיש את הסאה בשבועות האחרונים זה היה תביעה של Terraform נגד OpenTofu, בחשש מ...(רן) רגע, אז OpenTofu...(נתי) OpenTofu זה ה-Fork, שנוצר על ידי ה-Community, זה באמת חברות . . . אני לא יודע כמה שחקני ה-Cloud מעורבים בזה - אני בטוח שכן, אני פחות בקיא בדיוק מי התורם וכמה.[ובכן - Linux Foundation Launches OpenTofu](רן) אז תביעה של Terraform נגד...(נתי) נגד OpenTofu - ש-env0 למשל, הם אחד מהתורמים היותר משמעותיים שם, אני חושב.ובעצם, התביעה היא ל-Infringement - זאת אומרת, להעתקה.בעצם, הם לקחו איזשהו Feature של Security, או מה שזה לא יהיה, והשווה קוד והראו שיש הרבה מאוד דמיון.ועכשיו התביעה היא בעצם להראות שהדמיון הוא לא באמת דמיון, ואין פה באמת העתקה.ראיתי תגובה של אחד מעורכי הדין שאומר שהעתקה יכולה להיות גם העתקה של רעיון, העתקה לאו דווקא של קוד, ועוד כל מיני דברים כאלה.(רן) זה מזכיר לי נספח מתחילת שנות ה-2000, נגד Java?  . . . (נתי) נכון, נכון - בין Oracle לבין Google, על אנדרואיד כאילו . . . .(רן) . . . .פונקציה אחת, עשר שורות - ושבע מהשורות היו דומות . . . .(נתי) אז לא - לעורכי דין זה מה שנקרא “אחלה ביזנס” . . . אפשר עכשיו להתפלפל פה שנים ולעשות מזה אחלה כסף.לא יודע למי יש כסף לממן את הדבר הזה . . . .(אורי) . . . את החליפות . . . (נתי) . . . אבל זה הולך להיות דיון מאוד מעניין - וכנראה שהוא ייקח זמן.וזה תלוי גם כמובן באיזה בית משפט ובאיזה אזור גיאוגרפי אתה עושה את זה - אם בקליפורניה או לא בקליפורניה.(רן) ההעתקה לכאורה קרתה אחרי ה-Fork . . . . כל מה שהועתק לפני ה-Fork זה בסדר. הם הסתכלו בקוד שכבר אחרי ה-Fork . . . .(נתי) נכון, שהוא הפך להיות “פרימיום”, שהוא בעצם חלק מהמוניטיזציה שלהם.עכשיו כשחפרתי לראות, אמרתי “אוקיי, זה מהלך שהוא עדיין, גם אם הוא נכון, הוא נראה לי אגרסיבי מדי, אפילו ל-Terraform, אפילו כקרב הגנה”.ואז אמרתי אוקיי, משהו פה מאוד Fishy . . .  צריך לנסות לראות מה קורה שם ב-Terraform, מה המצב שלהם שם, למה פתאום זה עד כדי כך מטריד אותם . . . .(רן) או, הנה זה מתחיל להיות Juicy . . . .(נתי) כן . . . ואז מצאתי שבאמת הם התחילו לעשות שופינג לרכישה.כי א' - הם בסוג של הפסדים, וב' - הם כנראה ב-Peak של ה-Evaluation שיש להם כרגע - זה 5-6 ביליון דולר, כמה שזה לא יהיה.ומישהו שם עשה את החשבון, ואמר “מה-Peak הזה אני כנראה רק יכול לרדת”.ומן הסתם אם יש Open Source Fork, שבעצם מציג Terraform בדבר הזה, זה עושה Dilution - זה מדלל לי את הווליואציה (Evaluation), ולכן זה משהו שיכול לעלות לי הרבה מאוד.כי מן הסתם, אם אני לא סופר את זה בכמה זה פוגע לי בהכנסות הרבעוניות, אלא כמה זה פוגע לי בווליואציה (Evaluation), בדרך כלל המספרים בווליואציה הם מכפילים הרבה הרבה יותר גדולים, ואתם  כולים להגיע בקלות לביליון דולר רק באחוזים של פגיעה.ואז המוטיבציה כן לעשות “תקיעת טריז” הופכת להיות הרבה יותר משמעותית והגיונית, אפילו מבחינת הצד שלהם,כי בצד העסקי זה נראה ככה.אז אני חושב שזה מספר איזשהו סיפור מסוים, כשאני אומר עוד פעם - השורה התחתונה: כל קהילת הOpen Source שמסתכלת על זה, אני חושב שה-Output מהדבר הזה זה שזה כבר לא Open Source . . .הבנו כבר שזה לא רומנטי, ושיש פה מודלים עסקיים.ושזה לא כמו שאתה חשבת, שזה רק בחינם - אז אנשים לא עובדים בחינם, הם עובדים בשביל כסף.אבל כנראה שגם אם אתה Open Source, ברגע שנכנס כסף - אז גם טוהר מידות לצורך העניין, או “טוהר הנשק”, הולך קצת לאיבוד בדרך.בטח אם אתה VC-Backed.וזה מעקר...(אורי)  . . . . התמימות . . . (נתי). . .  התמימות הולכת. אבל אני אומר - זה מעקר . . . זה כאילו לכרות את הענף שאתה יושב עליו, לדעתי, וכן יש פה משהו מאוד טיפשי בסופו של דבר.(רן) מצאתי שם לפרק - “שלום לתמימות”.(נתי) האמת יפה, אהבתי. יש שיר כזה.26:57 עולמות ה-AI הפתוחים(רן) חשבתי אולי לעבור אלו עולמות ה-AI . . .(נתי) זה בדיוק הפרק הבא . . . (רן) . . . “השפה הכי פתוחה בעולם” . . . (נתי) בדיוק. אז הפרק הבא זה מה שכבר נהיה מאוד Juicy, זה OpenAI.הביטוי “Open AI” - ואני חושב שכולם מבינים שבין “Open” ל-”AI” ולמעלה בחברה . . .(אורי) בין “Open” ל-OpenAI . . .(נתי) כן, אז היה עכשיו, לאחרונה, למה זה הפך להיות Juicy? כי הייתה תביעה של Elon Musk נגד החברה של OpenAI.כשהייתי אומר, הקוריוז שהוא עשה שם זה שהוא אמר “אני מוכן להוריד את התביעה, אם עכשיו לא תקראו לזה “Open AI” אלא תקראו לזה “Closed AI” . . . “.ואם תשנו את השם, אני אמחק את התביעה.(רן) נזכיר ש-Musk השקיע בעבר, אחד המשקיעים הראשונים של החברה . . .(נתי) נכון, ב-2018.(רן) ודאז, לפי מיטב ידיעתי, החברה אכן התכוונה להיות פתוחה - ולחכות לטענתו.(נתי) החברה הייתה באמת . . . וגם ה-Entity הזה שנקרא OpenAI הוא עדיין חברה שהיא Not for Profitהיא חברה שהיא סוג של מלכ”ר, ללא מטרות רווח.אבל בעצם העבירו - ופה יש הרבה מאוד סימני שאלה, וגם ה-Federal הולך להיכנס חזק מאוד לדבר הזה, של איך נעשתה בדיוק העברה, בין החברה שהיא Not for Profit לחברה של OpenAI היום, כי . . . (רן)  . . . העברת IP . . . (נתי) העברת IP, בדיוק - כי בעצם יש פה העברת נכס, ואז יש פה אירוע מס, למעשה.יש דרכים, אגב, לעשות את זה - אבל זה אירוע שיכול להיות מאוד מורכב.וממה ששמעתי בלא מעט פודקאסטים שמדברים על זה, כנראה שזה לא היה תפור והדוק בכל הרבדים.ויש פה חשיפה כנראה מאוד מאוד גבוהה ל-OpenAI סביב התביעה הזאת.מה שכן, אפרופו זה שאף אחד לא תמים בסרט - Elon Musk בעצמו, הוא מדבר כאילו בשם ה-Open Source, ושהוא כועס על זה שהם חרגו מה-License שלהם.אבל הם בעצם חשפו, כתגובה, את התכתובות שהיו בינם לבין Elon Musk סביב הנושא הזה.זאת אומרת, מה שהיה הרקע זה שהם הבינו שיש פה משהו מאוד מאוד גדול - ושהוא ידרוש הרבה הרבה הרבה כסף כדי להגיע למצב שאתה בונה מודל, שבעצם “מכיל את כל האינטרנט”.וכדי להגיע לדבר כזה, הבינו שצריך לעשות פה כסף מאוד גדול.ו-Elon Musk - יאמר לזכותו היה בין הראשונים שהבין את זה גם.זאת אומרת, בא ואמר להם “אוקיי, אתם, כדי ליישם את המודל העסקי שלכם, יש פה פוטנציאל מאוד גדול, אתם תצטרכו הרבה הרבה הכסף”.זה כבר לא סטארטאפ, במובן של “סטארטאפ” - זה אפילו לא 100 מיליון דולר, זה ביליוני דולרים.(רן)  פה אנחנו מדברים ב-Timeline של מה? לפני כמה - ב-5 שנים?(נתי) זה תחילת ה-GPTs . . . אני חושב GPT1 . . . (רן) כשעולם עוד לא כל כך ידע . . . (נתי) נכון - אבל הם כבר ראו את הניצנים.ושוב פעם - יאמר לזכותו של Elon Musk, שהוא היה בין הראשונים שזיהו את הפוטנציאל פה.אני חושב שאף אחד בתעשייה לא זיהה את הפוטנציאל.(רן) נתת לי עוד שם לפרק - “הראשון לזהות” . . . .(נתי) אז באמת מה שקרה שם, זה שהוא הציע להם - לטענתם, ורואים את זה בתכתובות באימיילים, אמר “אוקיי, בואו תיכנסו תחת Tesla, ו-Tesla תהיה המימון שלכם”.אבל בעצם זה הופך להיות סוג-של-בבעלות שלו . . . ואני חושב שכנראה שזו אחת מהסיבות שהם לא רצו ללכת על עסקה כזאת.במקביל, Microsoft נכנסו - השקיעו בהתחלה המאה מיליון דולר שלהם, ולאט לאט בעצם לקחו אחוזים מאוד גדולים מהחברה.ולא ברור כל כך, כבר מבחינת המבנה - גם מבנה ההון וגם מבנה השליטה . . .(אורי) ה-Cap Table . . .(נתי)  . . . איך בדיוק היחסים האלה עובדים.וזה נראה שיש פה איזה גם תרגיל לא תפור ב-100 אחוזלמרות ש-Microsoft ניסו כנראה - יותר ממה ש-OpenAI עשו - עשו הרבה יותר גידורים למהלך הזה.אבל עדיין יש פה איזושהי חשיפה.(רן) השקיעו בסוף יותר מ-100 מיליון . . . (נתי) השקיעו מיליארד דולר בסופו של דבר, כדי לקבל בעלות שהיא מעל 50 אחוז - ובאמת יש פה הרבה מאוד שאלות, למי שמסתכל על זה - לאן זה הולך ומי בעל השליטה ומה זה אומר . . . .והנזק, אני חושב שוב פעם, לדבר הזה - זה נזק / תועלת לצורך העניין, אתם לא יודעים איך מסתכלים על זה - זה שאם OpenAI היו באיזשהו מומנטום של “אנחנו כבשנו את עולם ה-AI ואנחנו עשרה צעדים לפני כולם”.אני חושב שהרבה אנשים לוקחים עכשיו טיפה צעד אחורה, להגידו “אוקיי, יש פה משהו מאוד מאוד גדול, מאוד Disruptive, אפילו Existential - משהו שיכול באמת להוות “להיות לחדול” מבחינתנו - אבל אנחנו לא יכולים להמר על משהו כזה”.ואז בעצם זה גרם להרבה לקחת גישה של “חזרה ל-Open Source” . . . ובעצם Facebook יצאו עם Llama 2, והם מפתחים אותו מאוד והוא ממש מגיע למקומות טובים.ובעצם אנחנו רואים סוג של חזרה של Open Source בעולם ה-AIכדרך להוריד את ה-Risk של מודלים סגורים ושל ה-Giant-ים האלה, שכל העולם פתאום הופך להיות תלוי בהם, והמידע של כל העולם יושב אצל שחקן אחד, והוא בעצם עושה Scanning לכל העולם.32:15 ההבדל המרכזי(אורי) כן, אבל אני חושב, אני רוצה, שנייה, להגיד בסוף את ההבדל המרכזי - להבדיל מה-Open Source-ים שדיברנו עליהם, מה שנקרא “בחלק הקודם של הפרק הזה”, פה יש Barrier to Entry שהוא מאוד מאוד Significant-י, שזה כבר לא משנה אם הקוד הוא פתוח או לא. יוכל לתת את השירות הזה רק מי יש לו את הכוח הפיננסי להרים תשתית ענקית.(נתי) אז כן ולא . . . כן ולא.(רן) לא, שנייה - זה מה שעשו Facebook עם Llama, לצורך העניין - הם הורידו את ה- Barrier to Entry בצורה מאוד מאוד משמעותית, וכמעט כל אחד יכול להריץ . . . . נכון, זה עולה קצת, אבל זה לא ברמה של מיליארדים.(נתי) אני אחדד את זה - אני חושב שאם אתה מסתכל על מודל GPT, כמו שהוא באינטרנט, שהוא בעצם General AI, והוא בעצם נועד לתת לך תשובה לכל דבר ועניין, אז באמת אתה עדיין מדבר על אופרציה מאוד מאוד יקרה.אבל יש גם מגמה של מודלים מאוד יעודיים - זאת אומרת, לבעיות מאוד ספציפית, ל-Data מאוד ספציפי.כשאתה בעצם רוצה מנוע שבמקום לעשות שאילתות או Search ב-Data, אתה רוצה משהו שיש בו קצת “לוגיקה אנושית”, שנותנת לך מעטפת.יש המון Use Case-ים כאלה - המון המון Use Case-ים, שאתה יכול לעשות אותם ב-Footprint הרבה יותר נמוךאתה יכול לעשות אותם ב-Scale הרבה יותר נמוך, בעלות מאוד נמוכה - ו-Open Source הוא קלאסי לדבר הזה.אז אנחנו ממש רואים Adoption מאוד מאוד גדול של Open Source לאזור הזה.וכמובן, זה . . .(אורי) כן, אבל זה מוצר שונה, בסוף זה מוצר שונה, זו חוויה שונה . . . (נתי) אבל א' - זה מייצר לך אלטרנטיבה, ועדיין יש לך חברה גדולה כמו Facebook, שהייתי שם כוכבית מאחורי הכוונות שלהם מאחורי הדבר הזה . . .כרגע הן נראות כוונות טהורות, אבל אפרופו ההיסטוריה שתיארנו - מתישהו הכוונות האלה יכולות להתהפך, בקלות . . . ואף אחד לא יודע אם זה לא יקרה . . . אז עדיין יש - להערה שלך - עדיין אתה רואה שמי שמוביל את הפרויקט הOpen Source, זה חברות שהן ממומנות מאוד טוב, בוא נגיד ככה.חברות שניסו באמת - וזה מחזק דווקא את הטענה שלך - שכחתי איך הם נקראים . . .(אורי) כנראה ששכחת כי הם ניסו ולא הצליחו . . . .(נתי) לא לא . . . היו חברות שניסו לבוא ולהגיד “אנחנו נהיה ה-Open Source של GPT”, ממש Head to Head . . . יש איזה Poster-Child מאוד גדול, שברח לי השם שלה עכשיו . . . (רן) ויש את Mistral . . .(נתי) . . .  והיה עוד אחד - שניסה עכשיו לגייס בשווי של איזה 4 ביליון, אחרי שהוא גייס ב-100 מיליון, ונתקע ולא הצליח לגייס, ועכשיו הוא ירד . . . .כתבתי על זה פוסט, אני אמצא את השם, אני אוסיף אותו ברפרנס בהמשך . . . (רן) המתמודדים הגדולים זה Mistral . . . (נתי) עכשיו גם Microsoft קנו את  . . ..  לא Anthropic, ברח כלל גם השם שלהם - הם קנו עכשיו חברה שבעצם, הם עשו מהלך שהוא סוג של Acqhire, במחיר מאוד גדול,כמעט ביליון דולר גם . . .בסכום מאוד מאוד גדול, שכאילו לא מסתדר עם Acqhire - וגם פה התיאוריה היא שבעצם זה מהלך שנוצר כדי לעקוף את הרגולציה . . .כי מן הסתם, אם הם היו קונים אותם, כ-IP, אז זה היה שם אותם, היות ויש היום כבר הרבה מאוד עיניים . . . ששמים עין על Microsoft בהקשר של הגבלה עסקית והאם הם הופכים להיות סוג של מונופול.אז כדי לא להגיע למקום הזה, אז הם עשו סוג של Acqhire מאוד מוזר, מן תרגיל פיננסי כזה, שאני קונה את האנשים - אבל לא את החברה . . .החברה נשארת “חברת שלד” וממשיכה לתפקד - אבל אני משלם פרימיום לאנשים, וככה אני מרצה גם את בעלי המניות, ועובר מתחת לרדאר של האירוע-מס לצורך העניין, או אירוע-רגולציה, שיכול לקרות מאחורי הדבר הזה.[מניח שהכוונה לקרקס הזה עם Inflection]36:16 תקצירים, משמעויות - והנשורת של כל התופעה הזאת(נתי) אני חושב שאם אני מחבר את זה לתקציר הפרקים הקודמים, הייתי אומר שני דברים.אחד - אנחנו רואים שמה שהיה נכון לOpen Source בעולם ה-Infrastructure נכון אפילו עוד יותר לעולם ולמגמות של Open Source בעולם ה-AI.רק שהמשמעויות של זה הן הרבה יותר מרחיקות לכת - כי AI היום הוא משהו שהוא נוגע בכל ה-Stuck.הוא משנה את כל התעשייה - מן הסתם את כל ה-workforce ואת כל ה . . . בין אם זה עורכי-דין, בין אם זה רפואה, בין אם זה IT, בין אם זה אומנות, בין אם זה שירה . . . .כל דבר כמעט שאתה נוגע בדבר הזה.לכן השאלות האלה הופכות להיות עוד יותר משמעותיות.וכשאני מסתכל על זה, ממרום גילי, על ההיסטוריה הזאת - שרוב האנשים לא מכירים אותה - אז אני יוצא מאוד מוטרד . . .כשגם הבשורה של ה-Open Source - אני לא בטוח שהיא באמת בשורה אמיתית, שתחזיק מים.כשמעורב פה מן הסתם הרבה מאוד כסף - ואנחנו רואים מה הכסף עושה לOpen Source.ולכן אני חושב שזה קצת נאיבי לחשוב שOpen Source ייתן פתרון “דמוקרטי", נקרא לזה ככה, לעולם הזה.זה החיבור שאני עושה בין שתי המגמות האלה ובין הסיפורים האלה.(רן) טוב, אולי דמוקרטיה is overrated . . .  (נתי) זה מאוד רלוונטי לימינו אנו . . .(רן) רציתי להגיד, כמו שנגיד לפני 10-15 שנים, אני רואה שלמעשה ה-Cloud ועולם התשתיות הם התשתית לכל חברה - אז היום זה AI, הוא זה הולך להיות תשתית בכל חברה. וכמו שאמרת - אנחנו רואים את זה כמעט בכל מוצר.לפעמים אולי לא בצדק - לפעמים כן, לפעמים לא - אבל ככל שה-Ecosystem הזה יתבגר, ככה כנראה נוכל למצוא מקרים שבהם זה אכן בצדק . . . (נתי) לגמרי.אני חושב שמה שהייתי לוקח מזה, בתור שומע, זה א' - את “הכוכבית אזהרה” הזאת: שקודם צריך להיות מודעים לזה, ולדעת שיש פה את הסיכון, ושלפעמים אתה לא יכול לגדר את הסיכון. לפעמים העלות של הגידור של הסיכון היא יותר גדולה מאשר לקחת את הסיכון.אבל הסיכון הזה הוא בהחלט נוכח וקיים, ואסור להיות נאיביים ולהגיד “אה, לקחתי מודל Open Source, ולכן אני גידרתי את הסיכון דרך זה שלקחתי משהו Open Source” - זה יכול להתהפך די בקלות.וגם אני חושב שיש הרבה מאוד חוסר מודעות ל-License-ים סביב הOpen Source - זה License-ים פי-מיליון יותר מורכבים, שיפרנסו פה תעשייה שלמה של עורכי דין, ומוצרים שלמים שרק יעשו Scanning כנראה ל-License-ים, כדי לראות כמה חברות כבר עשו Breach לLicense-ים האלה . . . יש חברות שאומרu, ש”מותר לך להשתמש בקוד - אבל לא בפרמטרים . . . ולא בפרמטרים מהסוג הזה, ואם ה-Data נמצא שם אז זה Liability שלך ולא שלי” . . . .זה עולם שהוא עץ סופר-מורכב - ואני חושב שרמת החוסר-מודעות או הנאיביות או החזרה על טעויות שאני רואה בתעשייה, שהולכת לקרות סביב הדבר הזה, באמת הולכת לפרנס סטארטאפים שלמים ותעשייה שלמה רק  בלהתמודד עם הנשורת של כל התופעה הזאת . . . .אז אם אני יכול לתרום במשהו למישהו - אז הנה הכוכבית אזהרה: שמנו את זה על השולחן, ובאמת תדעו את זה ותיכנסו לזה בעיניי פקוחות.זה אחלה Open Source - אבל הוא לא חף מסיכונים.(רן) טוב, ובנימה אופטימית זו - שלום לתמימות.תודה רבה, נתי. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 469 של רברס עם פלטפורמה - הוקלט ב-9 באפריל 2024. אורי ורן חוזרים לאט לקצב ומארחים את שי ילין לשיחה על איך מהנדסים תוכנה בחברות צעירות: Do & Don’ts של חברות שאולי רק עכשיו התחילו. שי מלווה לא מעט חברות כאלו - והוא גם מודרטור (בכנס האחרון) ומרצה ותיק בכנסי רברסים [How Scala promotes TDD ב-2013, Putting the 'D' in TDD ב-2015 ו-You (probably) Don't Need Global State Management ב-2022] וגם מארגן של כנסים אחרים.01:40 רקע על שי ותנועת הזמישות(רן) אז שי - כמה מילים עליך? ספר לנו עליך . . .אז אני שי. בשלוש וחצי השנים האחרונות עמצאי, כשאני מחלק את הזמן שלי בין שלושה תחומים עקריים בחיים  שלי:יש לי שני ילדים - תום ואדם.אני עושה מוזיקה, בכל מיני קונסטלציות - חלק מהן יותר וחלק מהן פחות מצליחות מבחינה מסחרית ועסקית.ורוב הפרנסה שלי מגיעה מייעוץ לסטארטאפים וחברות שהן כבר לא סטארטאפים, או שהיו סטארטאפים או בדרך להפוך מסטארטאפים למשהו יותר מסודר . . .ובעצם, אני נותן שירותים לחברות שהן סטארטאפים או חברות שהן מיושבות יותר, של איך בונים מערכות וארגונים שקל לעשות להם שינויים.בעצם, אנחנו רוצים שגם . . .  ככל שהחברה יותר צעירה, שגם נוכל לעשות שינויים לקוד, ל-Codebase, לתשתיות - וגם לארגון עצמו, בצורה יותר קלה.אנחנו רוצים גמישות, אנחנו רוצים פחות נוקשות - כי אנחנו עדין לא יודעים איך המערכת צריכה לראות, מהן הבעיות שנתמודד איתן, ואיך הארגון צריך להיראות ומה הבעיות שנתמודד איתן.וחלק ממה שמייחד את מה שאני עושה זה שאני עובד גם עם מנהלי פיתוח וגם עם מהנדסים.עם מנהלי פיתוח אני עושה יותר Mentoring וארכיטקטורה ותכנון של בניין הכוח.ועם עם המהנדסים אני עושה יותר דברים כמו Pair Programing ו ו-Code Reviews ו-Design-ים.ואז בעצם אנחנו נותנים מענה הוליסטי לאיך שאנחנו יוצרים ארגונים ומערכות שהם גמישים ושהם ניתניםלשינוי בקלות. (רן) כן, כמובן בתוך הנחה שסטארטאפ בדרך כלל “Doesn't know $h!t”, הוא לא יודע . . . כל מה שהוא יודע זה אולי שהוא גייס כסף ושהוא רוצה לייצר מוצר. אבל חוץ מזה לא הרבה, והדבר הכי חשוב זה גמישות - היכולת לבוא ולשנות כיוון . . . (אורי) אני רוצה לאתגר את זה . . . כי באמת, סטארטאפ “Doesn't know $h!t”, בעיקר לגבי העתיד שלו - המוצר יצליח, לא יצליח? נצליח לגייס את האנשים הנכונים? אולי לא, אולי כן . . . נצליח לגייס כסף? אולי כן, אולי לא . . . אבלאנשים באים לתוך הסטארטאפ עם איזשהו ניסיון חיים, בין אם הם Founder-ים פעם שנייה או . . . גם בחברות שהםעבדו בהם, הם מגיעים עם “משהו” . . . (שי) זה מאוד נכון.אני חושב שמשהו שאני ראיתי זה ש-Founder-ים שהם 2nd Timers - הם כבר יודעים שהם לא יודעים  . . . הם יודעים את הבעיות שלהם והם יודעים לחפש את הגמישות הזאת.לעומת פאונדרים שהם 1st Timers - שהרבה פעמים הם רצים מהר והם מנסים לתכנן קדימה, והם מקבעים דברים מוקדם מדי.בין אם זה לתת Title-ים מוקדם מדי, בין אם זה לפתור בעיות Scale שלא קיימות . . . כל מיני אופטימיזציות שאנשים עושים ושלדעתי הם לא הדברים הנכונים.עכשיו, גם אם אני מהנדס - הייתי מהנדס בחברה גדולה, ועכשיו אני מגיע לסטארטאפ - לא בהכרח הכלים שהשתמשתי בהם בחברה הגדולה יתאימו לסטארטאפ.ואם אני מהנדס מנוסה, אבל עדיין לא “אכלתי קרבות קשים כאלה”, אז אני עלול להיות מסוגל לעשות אופטימיזציה מוקדמת מדי - Over-Engineering - כדי לפתור בעיות, כי אני “מפחד מהלא-נודע”, כי אני לא יודע מה יקרה.(אורי) זה מעניין, כי בדרך כלל האנשים שהם לא מפחדים מהלא-נודע, זה אנשים שהם מאוד “אדפטיביים” . . . האם יש משהו במה שאתה אומר, “או! סטארטאפ חדש, קטן - עדיף שהצוות שלי, שתיהיה לו סוג של חוזקה של סתגלתנות”? [עוד רקע כאן  - פרק 443 Hiring for strength, not skill with Sahaf from Hippo](שי) ללא ספק, אני חושב  . . . מה זה סתגלתנות? זה אדפטיביות, נכון? זה בעצם Agile, נכון? מה ש-Agile בא להגיד לנו . . .(אורי) . . . אנחנו מתרגמים את זה לעברית, כאילו . . .(שי) “זמיש”, נכון? הם קוראים לזה “זמיש” . . .  אז “תנועת הזמישות”, שהופיעה לפני 20 ומשהו שנה - אני חושב שאחד הדברים שהם דיברו עליהם, זה שהמונח Agile היה פשרההם בכלל רצו לקרוא לזה “אדפטיביות” או או “אדפטיביליות” או משהו כזה.כי בעצם, אנחנו רוצים לאמן את עצמנו להתמודד בצורה יותר טובה עם דברים שאנחנו לא יודעים מה הם יהיו(אורי) . . . לחזות אותם . . .(שי) נכון - אנחנו לא יכולים לחזות את העתיד, אין לנו יכולת לחזות את העתיד.והרבה פעמים, באופן אבסורדי, בניסיון לחזות את העתיד, בניסיון לפתור בעיות שתגענה - אנחנו עושים “הכנות למזגן”, אנחנו עושים מה שנקרא “YAGNI - “You  Ain't Gonna Need It. בעברית זה “הכנה למזגן”, זה בדיוק מאוד יפה.ומה שקורה עם הכנות למזגן זה שבדרך כלל כשאתה צריך מזגן - אז ההכנה לא מתאימה לו . . . ואז יש לך שתי בעיות . . .(רן) . . . כבר יש התחממות גלובלית, צריך מזגן הרבה יותר גדול . . . כל מה שהכנת כבר לא רלוונטי . . . (שי)  . . . התשתית לא רלוונטית, השקע-חשמל לא רלוונטי, עשית חור בקיר אבל אתה מתקין מזגן מפוצל . . .06:44 מה מביא אותך לתת עצות?(רן) אז תיכף נדבר על כל מיני מקרים מאוד ספציפיים, לא נשאר ברמת ה-Abstract- אבל בוא נסיים קודם את ההקדמה.  מה מביא אותך להיות מסוגל בעצם לתת כאלה עצות? זאת אומרת, לעשות כזו חניכה? איזה ניסיון יש לך בתחום?(שי) אני . . .  קודם כל - אין לי ניסיון הרבה יותר נרחב או מיוחד מאשר הרבה אנשים אחרים.אני הצטרפתי ל-Wix ב-2010 - התמזל מזלי להכיר את Wix יחסית מוקדם.וגדלתי עם Wix, מכ-20 מהנדסים למשהו כמו 1,000, ועשיתי תפקידים של פיתוח ושל ראש צוות ושל ראש קבוצה ובניין הכוח בחברה . . .ועשיתי מלא טעויות - מלא, מלא, מלא טעויות.יש אנשים ב-Wix שמקללים את השם שלי - וזו פריבילגיה שאין להרבה אנשים . . .וזה דבר אחד שקרה לי, שהוא מיוחד.אבל מעבר לזה, אני חושב שיש לי נטייה להיות יחסית ביקורתי, ולהסתכל על תהליכים וטקסים - ולפקפק בהם, תמיד.לפעמים יותר מדי . . . אבל זה עוזר לי לפעמים לראות דברים שאנשים עושים ולשאול - למה?08:02 בואו נתחיל ב-Monolith-ים ואחר כך נדבר - מחפשים צרות עם Monolith-ים ו-microService-ים(רן) סבבה, אז בוא נהיה יותר ספציפיים עכשיו. אז אתה אומר - יש טעויות שאנשים . . . אתה יודע, בין אם זהכי יש להם אפס ניסיון או בין אם זה כי יש להם מלא ניסיון, שעושים כשהם מגיעים לסטארטאפ היחסית-צעיר שאיתו אתה עובד.בוא נמנה כמה מהם - נדבר על מונוליטים [Monolith], נדבר על microservice-ים? . . .(שי) כן, יאללה -  אני גם עשיתי על זה Blogpost לא מזמן [ - Of Rigid Microservices and Flexible Monoliths], והוא היה די שנוי במחלוקת . . .(רן) . . . To be or not to be - Monolith or microservice” - let's go”(שי) אז התשובה היא כמעט קטגורית “להתחיל מ-Monolith” . . . נתקלתי בכמה מקרים: עבדתי בסטארטאפ - בעצם, המשרת-שכיר האחרונה שלי הייתה בסטארטאפ, שבו היה CTO שהחליט שהוא בונה Design מאוד מאוד מאוד Strict לחלקים של המערכת, כדי לאפשר לרוץ מהר ולפתח כל חלק בנפרד.אז הוא בעצם יצר אוסף של Inerface-ים והגדיר היטב את הממשקים ביניהם ואיך כל אחד מתנהג …ומה שקרה זה שזה יצר קשיחות מאוד מאוד מאוד גדולה - ואי אפשר היה . . . היה מאוד קשה לעשות שינויים ב-Interface-ים האלהבגלל שהתחלנו מ . . . אפילו לא התחלנו מ-microservices - הוא רצה להתחיל מ-microservicesואז אמרנו “רגע - לא צריך Process-ים נפרדים, בוא נעשה Modular-Monolithנשים את כל אותם מימושים בתוך אותו Process, הם ידברו אחד עם השני דרך הזיכרון - כאילו, In-process ולא דרך הרשת.אבל הייתה התעקשות להשאיר את ההגדרה של ה-Interface-ים ב-Protobuf, בקבצי IDL של Protobufשזו בעצם שפה שהיא Language-Agnostic - היא לא קשורה לשפת פיתוח ספציפית, שמגדירה ממשקים של מערכות Web, מערכות אינטרנט.אז יש לנו Interface-ים, ממשקים, ויש לנו Instruct-ים  . . . (רן) כשהטכנולוגיה לכשלעצמה היא מצוינת - רק לעוד חמש שנים או עשר שנים . . . (שי) הטכנולוגיה מעולה - אם צריך microservices . . . .אבל ברגע שאתה מכניס את העובדה שצריך לעשות כל שינוי ב-Protobuf ואז לג’נרט (Generate) קוד לשפת הפיתוח שאתה משתמש בה, זה הופך כל שינוי להרבה יותר קשה ומורכב.וזה בעצם כאילו זה אומר לאנשים “רגע - יש פה גבול, אי אפשר לשנות אותו” - ואז האנשים לא מפקפקים  בגבול הזה.(רן) . . . או שהם עוקפים אותו בצורה מוזרה . . . (שי) . . . או שהם עוקפים אותו בצורה מוזרה . . . היה לי לקוח שהתחיל מ-microservices, כי היו לו מהנדסים שהגיעו מחברות שבהן עשו microservices.ואז הם התחילו את המערכת עם מספר לא קטן של microservices ב-Node - ואז אי אפשר לעקוף את זה בצורה הזאת, זה ממש כאילו “לצאת לרשת” . . . ואז אתה משלם את “המס” של בעיות Scale - לפני שיש לך בעיות Scale . . . (אורי) אני חושב שאם אנחנו מדברים על microservices, תמיד יש את הוויכוח “Monolith או microservices” וכו' . . . ל-microservices יש תכונה, שהיא טובה מאוד ב-Scale - אבל פחות ב-Scale של מערכת או של ב-Scale הטכנולוגי או ה-Performance או זה, אלא דווקא ב-Scale של ארגון הפיתוח . . .(רן) HR-י . . . . נכון, לכל צוות יהיה את ה-Service שלו - או או שניים-חמישה שלו . . . (אורי) . . . זה יוצר Decoupleing כזה “טוב” - ואז אתה אומר לעצמך “רגע, מתי אני אגיע לבעיה הזאת?” יכול להיות שהקיר הוא עוד הרבה יותר רחוק ואתה מפספס הרבה מאוד אג’יליות (Agility) שיש ב . . . (רן) כן - אבל כל אחד שמסיים עכשיו לימודים והולך קצת ללמוד על איך נראה עולם הפיתוח “האמיתי”, אז הוא לומד  שאוקיי, יש Bug Management systems ויש Git - “וצריך זה” ו”צריך microservices”, נכון? זה מה שלומדים - לצערנו. הרבה שמסיימים את הלימודים שלהם באים ואומרים “אוקיי microservice-ים! זה הדבר, את זה אני צריך להכיר וזה מה שאנחנו הולכים לעשות בחברה שלי!”. או, מצד שני - אם הייתי בחברה גדולה אחרת, ושם כולנו עשינו microservices, אז ברור שגם בסטארטאפ שלי, אני מראש אבנה אותו Robust-י עם microservices - ושי אומר שזו טעות. אתה מקדים בהרבה מאוד את מאוחר, ואתה הולך לשלם על זה מחיר מאוד כבד בזמן שאתה בכלל לא צריך. (אורי) הרבה פעמים משחררת קצת התפיסה הזאת של “הקוד הזה הולך להימחק” . . . .(שי) כל קוד הולך להימחק, נכון? כאילו, אין דבר כזה “קוד שחי לנצח” - זו חריגה אם יש לנו קוד שחי לנצח . . .(אורי) אבל בעצם, מי שמנסה לייצר סכמה או תשתית או . . . שתמשיך איתנו להרבה זמן, זאת הנחת ה . . .(שי) אני חושב שאנשים מסתכלים על תוכנה בצורה לא נכונה - אני חושב שאנשים מסתכלים על תוכנה כ”משהו שאנחנו בונים”.אבל תוכנה זה לא משהו שאנחנו בונים - זה משהו שאנחנו “מגדלים”, כמו גינה, כמו עץ.וכשהעץ צעיר, אז הוא שתיל קטן, עם גבעול רזה - והוא יכול להתכופף.וככל שהוא גדל ומזדקן, אז הגזע מתעבה ונהיה יותר עצי וקשה.ומערכות תוכנה הן אותו הדבר - הן מתחילות כמשהו מאוד קטן, ואתה רוצה לגדל אותן באופן הדרגתי.אין לך מושג מה יהיו בעיות ה-Scale שיהיו לך.אין לך מושג מה יהיו “גבולות הגזרה” - מה שנקרא ה-”Bounding Context”, ההבדלים ב-Domain-ים השונים שאתה הולך להתעסק איתם.עוד חצי שנה, עוד שנה, עוד שנתיים . . . מתי שזה לא יהיה שתזדקק - אם בכלל תזדקק ל-microservices.וכמו שאורי אמר - microservices זה פתרון לבעיה. זו לא אסטרטגיית פיתוח או אסטרטגיית ארכיטקטורה של קוד - זה פתרון לבעיה שהיא בעייה ארגונית: איך אני מאפשר לצוותים שונים לעבוד בו זמנית, לעשות Deployment בו זמנית, בלי לדרוך אחד לשני על הרגליים, בלי לעשות Coupling בין פיצ'רים (Features) שלא קשורים אחד לשני.לפעמים, microservices הם גם פתרון לבעיה ארכיטקטונית - אם יש לי שתי מערכות שונות, אחת צריכה להיות ב-High-Throughput אבל לקריאה בלבד ואחת היא ב-Throughput יותר נמוך והיא לקריאה וכתיבה, אז זה הגיוני לחלק ל-microservices, ולעשות איזשהו תהליך של להעתיק את המידע ביניהן.אבל אלו מקרים מאוד מאוד מאוד ספציפיים, ורוב החברות לא צריכות microservices.בטוח לא עכשיו - בשלב הראשון, כשאנחנו רק מגששים ומנסים להבין מה ה-Product-Market Fit שלנו.14:55 סיכום ביניים - תבנה “Monolith טוב”(רן) אז לקח מספר אחד עד כה, נעשה סיכום ביניים - אם אתם מתחילים איזשהו מוצר תוכנה צעיר, איזשהו “שתיל” כזה, שהוא עדיין גמיש - יכול Monolith-ים, זה בסדר, יש Framewrok-ים טובים . . .(אורי) . . . מה שמביא לכם את ה-Product הכי מהר . . . .(רן) . . . . כן, יש Framewrok-ים טובים גם בעולם ה-Monolith-ים, והם כנראה יאפשרו לכם את הגמישות שאתם  צריכים בשלב הזה, וזה בסדר. אחר כך יהיה זמן לעשות Refactor . . . אתם גם ככה הולכים, כמו שאורי אמר, למחוק את הקוד, אתם הולכים לעשות Refactor באיזשהו שלב, וכנראה שתייצרו איזשהם microservice-ים, אם תצטרכו. אבל תעשו זה כשאתם צריכים, כי המחיר הוא גבוה - המחיר של לשלם על microservices בשלבים המוקדמים האלה הוא מאוד מאוד גבוה.(שי) אני רוצה להוסיף ש-Monolith - יצא לו שם רע . . . .כאילו, זו נהיתה מילה גסה כזאת - “מה? Monolith?! מה זה, “קוד ספגטי”? זה Big Ball of Mud . . . .לא - זה לא חייב להיות ככה. תבנה Monolith טוב, תעשה Refactor-ים תכופים בזמן שאתה בונה את ה-Monolith.אתה תקבל Monolith מודולרי.וכשתרצה - אם תרצה - לקחת איזשהו נדבך ממנו ולהוציא אותו החוצה ל-Process נפרד, זה פשוט יהיה להרים אותו ולהעביר אותו הצידה לשתול אותו ב-Process אחר.כמו שאנחנו עושים השתלה של עץ או של שתיל מגינה לגינה.16:13 מה הסיפור של טסטים?(רן) אוקיי, עכשיו - מכיוון שאמרנו שהקוד גם ככה הולך להימחק, הוא בטח לא הולך להחזיק יותר משנה - אין טעם לבדוק אותו, נכון?  . . . כאילו, אם זה עובד - סבבה! אם זה לא עובד - גם ככה אני אמחוק.אז טסטים בטוח לא צריך בשלב הזה . . . .(שי)  . . .  (רן) כן . . . . אז  אני לא פאנט גדול של TDD או חברים. יחד עם זאת, תמיד כשאני כותב קוד יש לי באגים, וגם אם זה קוד “צעיר וחדש” - או במיוחד אם זה קוד צעיר וחדש . . .  אבל יש את התחושה של “אוקיי, אנחנו גם ככה רוצים  איזשהו Prototype, אנחנו לא יודעים מי ישתמש בזה - אנחנו נורא נורא “אג'יליים” . . . “ - איך אמרנו בעברית? “זמישים”? - אנחנו נורא נורא זמישים! אז מה, עכשיו גם טסטים?!מה הסיפור של טסטים?(שי) אז אני אגיד שקודם כל - המטרה של טסטים זה לא למצוא באגים. זאת אומרת, כשאני מוצא באג, אז אני משחזר אותו בטסט שנכשל, ואז אני יודע שהבאג הזה לא יחזור.אבל המטרה של טסטים זה להוכיח לי שהמערכת עובדת.זאת אומרת, אם עכשיו כתבתי קוד, והקוד הזה עושה משהו והוא עובד - זה מקרי שהוא עובד . . . אין לי שום הוכחה שהוא עובד.אני רוצה את היכולת לדעת, בכל רגע נתון, שהמערכת שלי עושה את מה שהיא אמורה לעשות, שהפיצ'רים עובדים.עכשיו, זה לא משנה אם אני עכשיו כותב Prototype, ואני מנסה להתכנס על Product-Market Fit,  או שאני כבר בשלב של Expansion או של Hyper-Growth, של גדילה מהירה.אני עדיין צריך לדעת שהפיצ'רים עובדים - וזה מגוחך בעיניי שאנשים לא כותבים טסטים לפיצ'רים שלהם. עכשיו, זה לא אומר שאתם צריכים לכתוב עכשיו מלא מלא מלא Unit Test-ים . . .צריך למצוא את “נתיב הזהב” שבין לכתוב יותר מידי טסטים שבודקים פרטי מימוש, ואז אנחנו בעצם מבזבזים את הזמן שלנו על שטויות, על לכתוב טסטים שאף אחד לא צריך ושרק יפריעו לנו לעשות שינויים, לבין לא  לכתוב טסטים בכלל.אז אני רוצה להציע איזושהי גישה, שהיא כמעט ממשיכה את הדרך של הגישה שהצעתי כשאמרתי “בוא נתחילמ-Monolith ולא נתחיל מ-microservice.(רן) אוקיי . . . אז מהי “גישת הטסטים” בעולם הזה? (שי) אז בגדול, אני בודק פיצ'רים.אני רוצה להתחיל - אני מתחיל מערכת, יש לי איזושהי הנחת יסוד, השערה לגבי מוצר שיכול לעבוד - אז אני כותב טסט לדבר הזה.אם אני כותב מערכת Web-ית אז אני כותב טסט במשהו כמו Playwright, או איזשהו Framework UI כזה.ואני אכתוב טסט שהוא מאוד מאוד “גס” באופי שלו.לצורך העניין, אם אני בונה חנות, אז הטסט יכול להיות “לקוח יכול לקנות מוצר” . . . (רן) כלומר, לא Unit Test, נדגיש.(שי) ההיפך . . . ההיפך הגמור - זה End-To-End Test: הוא רץ לאט, הוא רץ על דפדפן . . . וכל עוד אני מנסה להתכוונן על Product-Market Fit, אני אכתוב מעט End-To-End Tests כאלהשהם ישתנו רק כשהדרישות תשתננה - ולא כשהמימוש ישתנה.והם יהיו “רשת ביטחון" - שאני יודע שאני “עובד”, שאני תמיד עובד.(רן) זאת אומרת, אתה טוען שאפשר לשלם בחנות - והנה הטסט מוכיח לך, שניתן לשלם בחנות. אבל אתה לא הולך לבדוק כל פונקציה קטנה, כי היא גם ככה הולכת להשתנות ולהימחק.אבל מתי כן? מתי כן אתה תתחיל לעשות את זה?(שי) אז כמו שאמרנו קודם ש”המערכת שלנו היא עץ", אז כשהעץ מתחיל “להתעבות” - כשהמוצר מתחיל להתקבע ולהתקשח. זאת אומרת, כשאנחנו כבר יודעים מה אנחנו עושים - אז אנחנו רוצים להעמיק את הטסטים, לבדוק יותר מקרי קצה.אנחנו רוצים אולי לקחת חלק מה-End-To-End טסטים האלה, ולהפוך אותם לטסטים שהם רצים יותר מהר.אז אם אנחנו יכולים, אנחנו נריץ - לבדוק פיצ'רים בתוך Process בזיכרון.באמצעות משהו שנקרא Hexagonal Architecture, אנחנו נרים מערכת - עם Fake-ים במקום כל מה שיוצא החוצה מהמערכת, ואז אני לא יוצא מתוך גבולות ה-Process.ואז אני מקבל Performance של Unit Test - ורמת Scope של End-to-End Test, שבודק פיצ'רים ולא יחידות תוכנה, שהן כמעט מקריות, שהן Implementation details, שהן פרטי מימוש של המערכת שלי.(אורי) אני רוצה להגיד גם עוד משהו על טסטים - כמו שאמרתי על microservices, שהם מאפשרים פן “HR-י”, אז גם טסטים הם “זיכרון ארגוני” [זו לגמרי צריכה להיות שורה בשיר רברסים הבא . . .]. ולהבדיל מתיעוד, למשל - שאומרים על תיעוד שהוא כבר לא רלוונטי ברגע שגם אמרת לכתוב אותו - טסטים לא. טסטים כל הזמן מתעדכנים. זאת אומרת, ברגע שהטסט לא יהיה רלוונטי, הוא ישבר. כאילו, אם תשנה את הפיצ'ר בצורה שאתה רוצה לשנות אותו, והטסט כבר לא יהיה רלוונטי לפיצ'ר - הוא ישבר, ותצטרך לתקן אותו. וזה פשוט “זיכרון ארגוני”, שחי עם המוצר, הוא לא מזדקן.(רן) אני קורא לזה “תיעוד” - אבל גם זיכרון ארגוני.(שי) אנחנו קוראים לזה Executable Specifications - אלו דרישות שניתן להריץ אותן.אני קורא לזה “ראיות” - אלו הראיות שהמערכת עושה את מה שהיא אמורה לעשות.וככל שהמערכת יותר ראשונית ופחות מוגדרת היטב - ככה הטסט צריך להיות יותר גס ופחות מדויק.וככל שאני יודע יותר מה היא רוצה לעשות, אני רוצה יותר טסטים שבודקים יותר מקרי-קצה - ואז, בשלב הזה, גם יותר הגיוני להפוך אותם ליותר מהירים.כי אם אני יש לי עכשיו אלף End-to-End Tests, ייקח להם המון זמן לרוץ - וזה יהיה מאוד יקר, וזה לא הגיוני להרים כל פעם מערכת שלמה בשביל לדאוג לניואנס של איזשהו מסך.22:26 זה הולך להיות ב-Rust בוודאות(רן) אני מחר בבוקר מקים סטארטאפ [רגע - מה?], ואני לא יודע מה הולך להיות המוצר ואני לא יודע את מי אני הולך לגייס . . .(אורי) אפשר להשקיע? . . . (רן) . . . אבל אני יודע דבר אחד - זה הולך להיות ב-Rust בוודאות [דותן מרגיש הפרעה בכוח…], , כי זו שפה יפייפיה, היא Type-safe, והיא ממש מגניבה. מה דעתך?(שי) דעתי היא שאתה לוקח סיכון . . . .למה אתה לוקח סיכון? כי אתה בחור מאוד חכם ומאוד ותיק ומאוד מנוסה - ואתה יודע שהשפה הזאת טובה לך.אבל אתה לא תצליח, כנראה, לגייס צוות שמורכב מהאנשים כמוך.אתה תגייס צוות של אנשים שהם הרבה פחות מנוסים . . .עכשיו, אתה יכול ללמוד אותם Rust - אבל את הזמן שאותו אתה משקיע בללמד אותם Rust, או שהם משקיעים בללמד את עצמם Rust, הם היו יכולים להשקיע ולכתוב לך פיצ'רים ב-Go [עכשיו אלון מרגיש הפרעה בכוח…] או ב-TypeScript או בכל שפה שהיא יותר נפוצה.אז כשאני הולך לפתח מערכת ב-Rust - ואני עשיתי את הטעות הזאת . . . לא יודע אם אני קורא לזה טעות, אבל אני העברתי את Wix לפתח ב-Scala . . . ו-Scala שפה נהדרת, מדהימה - ומתקמפלת מאוד לאט, ומאוד קל לעשות בה “פשעים נגד האנושות” . . . .ועשור אחרי שהעברתי את Wix ל-Scala, או 12 שנים אחרי שהעברתי את Wix ל-Scala, אני שומע קולות מ-Wix, של אנשים שאומרים “למה אנחנו עובדים ב-Scala?!”אז בזמנו, כשהיינו חברה של 30-40 מהנדסים, זה היה איזשהו “Differentiator” - איזשהו משהו מבדל.יכולתי להגיד “אנחנו כותבים ב-Scala, ומי שרוצה לכתוב ב-Scala יבוא ויעבוד ב-Wix!”וזה היה מגניב לנו - כשאתה סטארטאפ חדש, אתה רוצה כמה שפחות לבדל את עצמך ברמה הטכנולוגית, כדי שתוכל . . . . כדי שלא לצמצם את ה-Funnel של הגיוס שלך, שתוכל לגייס אנשים בלי שהם יצטרכו לחשוב  עכשיו “האם אני רוצה להיכנס ל-Rust? מה אני צריך את הדבר הזה בחיים שלי?” . . . .(רן) כן, אז אתה מסתכל מהפן של הגיוס. מה לגבי “הצרות הרגילות” - Community Libraries, תשובות של - כולם עוד אומרים “Stack Overflow!”’ אבל “תשובות של GPT” - וכו’? האם גם זה Concern בעיניך?(שי) בוודאי.זה לא שקהילת ה-Rust היא לא קהילה ענפה ומלאה באנשים נלהבים . . . פשוט, באופן מאוד מאוד פרקטי - יש הרבה יותר אנשים שכותבים ב-TypeScript או ב-Go או ב-Javaולכן יש לך יותר סיכוי לקבל תשובות ולראות דברים שכבר עשו - פתרונות שכבר עשו לבעיות שאתה עלול להתקל בהן.גם ספריות - כאילו, יש לך הרבה יותר ספריות ב-JavaScript מאשר ספריות ב-Rustוהרבה יותר בעיות כבר פתורות בעולם של JavaScript לעומת העולם של Rust.25:21 אובססיה לטכנולוגיה - על Framework-ים  וחיות אחרות (רן) עכשיו - נניח שאני הולך לפתח משהו בעולם הLLMs, סתם ככה כי בא לי, כי זה מה שכולם עושים היום [לא סתם - Surviving the Hype - How to Not Let the Success of Your Domain Ruin You / Rachel Wities], ובא לי, ואני רואה שיש Framework ממש מגניב שנקרא LangChain, ווואלה דווקא נראה לי דווקא סבבה, אז אולי אני אאמץ אותו אליי, ונבנה את הכל ב-LangChain . . . . איזו טעות אני עושה פה?(שי) אתה לא בהכרח עושה טעות . . . . אבל מה הבעיה עם Framework-ים? הבעיה עם Framework-ים זה שלכל Framework יש דעה - והם מאוד דעתניים, והרבה פעמים זאת לא הדעה הנכונה . . . כי הדעה היא של מי שכתב את ה-Framework, וה-Framework הרבה פעמים נועד כדי לפתור, שוב, בעיות של Scale -בעיות של חברה שהיא כבר יותר בשלה שיודעת מה היא רוצה לעשות.אם אני עכשיו בונה מערכת לתוך Framework, יכול להיות מאוד שאני אגיע למצב שאני לא רואה . . . “מרוב עצים לא רואים את היער” - מרוב קוד Boilerplate שקשור ל-Framework, אני בכלל לא רואה את ה-Domain העסקי שלי . . . .מאוד קשה לי להבין מה זו המערכת שאני בונה.אז אני משלם - שוב - אני משלם הרבה מאוד “מס” על להביא Framework גדול ומורכב, שהוא באמת יכול לאפשר לי להגיע לאינסוף.אבל האם אני צריך את כל היכולות של ה-Framework הזה? כנראה שלא . . .(רן) כן, כלומר אוקיי - אז זאת אומרת שיכול מאוד להיות שמי שכתב את ה-Framework עשה עבודה מצוינת, אבל ה-Use Case שלו היה הרבה הרבה יותר מורכב מה-Use Case שלי, או לחילופין - אולי לא הרבה יותר מורכב אבל פשוט שונה, ואני אשלם “מס גדול” על להתאים את עצמי לדרך המחשבה של ה-Framework.אבל האם אין מקרים שבהם Framework דווקא יכול להיות שימושי? אני אתן אולי את הדוגמה הכי טריוויאלית: אם אני הולך לכתוב משהו ב-Web, אני לא אכתוב את הכל מאפס ב-HTML ו-JavaScript, אני כנראה אשתמשב-React או חברים . . . לגיטימי?(אורי) יש את המקום ש-Framework מקצר לך דרך. איך אני יודע להבדיל בין  Light” Framework”  לבין Framework שיש בו הרבה “שיער”, נקרא לזה, ואני אעסוק כל הזמן בלגלח את היאק?(שי) אני חושב ש-React היא דוגמה מצוינת, כי-React היא לא Framework - היא ספרייה.היא מאוד מאוד קטנה ופשוטה, וזה נכון ש-React עם Hooks זה כבר קצת Framework, ו-Next זה ממש Framework . . . .ואני אגיד לך לא להשתמש ב-Next - בשום פנים ואופן אל תשתמש ב-Next.אין לך שום סיבה להשתמש ב-Next - היא נועדה לפתור בעיות שאין לך.אבל React היא ספרייה, היא קטנה - היא לא “אולר שוויצרי”, היא “סכין קומנדו”.היא יודעת לעשות דבר אחד - וזה לרנדר (To Render) UIוזו בדיוק הדוגמה למשהו שהוא סטנדרט דה-פקטו היום בתעשייה.גם הרבה מאוד Framework-ים אחרים לקחו מ-React רעיונות או משתמשים ב-JSX כמו ש-React עושה.יהיה לך קל להביא אנשים שמכירים את זה, יש Best Practices, יש סטנדרטים . . . ועדיין - אני ממליץ לא לעשות Coupling של הקוד שלכם לספרייה או ל-Framework.אני גם לא אומר לעשות Abstraction Layers או Interaction Layers - שכבות הפשטה מעל הספרייה הזאת.אבל אני כן אומר שצריך להיזהר ממצב שבו אני מתעסק, כמו שאורי אמר, ב-Yak-Shaving, בלהתאים את עצמי לתוך ספרייה או Framework.כי אז בעצם אני מכניס את עצמי לשבלונה - ואני מגביל את עצמי ביכולת שלי לגדול ולהתפתח.(אורי) אני הכי אוהב את הסטארטאפים שיש להם שתיים-וחצי שורות קוד - מעל Kubernetes . . . כמות הזמןשתשקיע רק ב”לרכב על השור הזה” . . . (שי) אתם לא צריכים Kubernetes, אתם לא צריכים Next, אתם לא צריכים Next.js, אתם לא צריכים Kubernetes, אתם לא צריכים את Elixir, אתם לא צריכים את LangChain  . . .אתם צריכים לכתוב את הקוד הכי פשוט שפותר את הבעיה שאתם חושבים שאתם רוצים לפתור.ולהביא זה למשתמשים ולשוק ולראות איך מקבלים את הקוד שלכם, איך מקבלים את המערכת שלכם, איזה פיצ'רים צריך . . . ותפתרו את הבעיות כשהם יקרו, ולא לפני.29:40 סיכום ביניים(רן) אז סיכום ביניים לסעיף האחרון שעליו דיברנו - נקרא לו “אובססיה לטכנולוגיה” - שיכולה להיות אובססיה לשפה מסוימת, דהיינו Rust במקרה הזה - שפה מצוינת, אבל אולי אתם לא צריכים את זה, וגם אם אתם באמת רוצים את זה,יהיה לכם קשה לגייס. אז לזה קראנו “אובססיה לטכנולוגיה”.לפני זה דיברנו על Testing - האם, מתי ואיך?; וממש לפני זה דיברנו על “בואו נתחיל ב-Monolith-ים ואחר כך נדבר”30:11 איך מנהלים חוב טכנולוגי?(רן) אני רוצה להעלות עוד נושא אחד, וזה איך מנהלים חוב טכנולוגי? וזה הכי קל, כאילו בסטארטאפ, לבוא ולהגיד “אוקיי, אוקיי, את זה אני אעשה אחר כך”, “פה אני אשאיר לי עצמי To-Do”, “פה אני לא באמת אסגור את ה-Security hole הזה”, “פה אני לא באמת אטפל ב-Performance” - ולפעמים זה לגיטימי. אבל איך אחר כך מתמודדים עם זה?(שי) קודם כל בוודאי שזה לגיטימי.למעשה, כמו שאמרתי - אני, במוצרים חדשים . . .  אגב, לא בהכרח בסטארטאפ חדש - גם אם אני עכשיו בתוך  חברה גדולה ואני בונה מוצר חדש, ואנחנו עדיין לא יודעים אם למוצר הזה יש שוקאני אנסה להיות “כאילו שאני בסטארטאפ” - אני אנסה להיות הכי Lean שאני יכול, בתוך המגבלות של החברה שאני נמצא בה.אז אני לא רוצה לפתור בעיות Performance ואני לא רוצה לפתור בעיות Security עכשיו - אני כן רוצה לייצר מערכת שבה אני אוכל לעשות את זה אחרי זה בקלות.זאת אומרת, אני רוצה שהקוד שלי יהיה גמיש לשינויים.זאת אומרת שאני רוצה טסטים מספקים כדי להגן עליי.ואני רוצה רגע לדבר על המונח “חוב טכני” - המונח “חוב טכני” הוא מונח שהוא גם בעייתי . . . כי לא כל החוב הטכני הוא בעייתי באותה רמה.כי אנשים אומרים “יש לי פה Class שכתבתי - והוא מכוער! זה חוב טכני!”ואני אגיד שזה חוב טכני אם ה-Class הזה משתנה הרבה - אבל אם ה-Class הזה לא משתנה אף פעם, אם כתבתי איזה Adapter לאיזה ממשק SOAP של חברת ביטוח, שהשתנה בפעם האחרונה ב-2004 . . . וזה קוד מגעיל - אבל אף אחד לא נוגע בו אף פעם, או שפעם בשנה מישהו נכנס לשם ועושה איזה תיקוןהאם זה בסדר שהקוד הזה יהיה מגעיל? אני טוען שכן.כי אנחנו רוצים שקוד יהיה נקי כדי שנוכל לקרוא אותו - קוד שמשתנה הרבה זה קוד שקוראים הרבה.אז איפה שיש הרבה שינויים - אנחנו רוצים להשקיע ולפרוע Technical Debt, לפרוע חוב טכני.איפה שאין הרבה שינויים - זה לא חוב טכני, זה פשוט קוד מכוער.(אורי) אני רוצה לתת עוד אספקט של “חוב טכני" ו”חוב מוצרי” - יש גם דבר שנקרא “חוב מוצרי”: המוצר “לא מדויק”. זה משהו שלמדתי מהרצאה בכנס רבסים האחרון [מניח שזה - It’s time to pay off your management debt / Daniel Korn]: בטח בסטארטאפים, כשאתה בונה משהו ולא בטוח שהוא יעבוד ושהוא יעבוד טוב - ויש מצב טוב שתצטרך לזרוק את הקוד הזה - תאפשר לעצמך “תספורת” . . . זאת אומרת, לפני שאתה משלם את החוב הטכני, תראה אם באמת המוצר הזה, יש לו אורך חיים רלוונטי. כי אם לא, זרוק את הקוד. החוב מחול - פשוט זרוק את הקוד.(רן) כן . . .  “תספורת”, רק לתרגם מעולם הפיננסים, זה "להשליך לפח”, לשכוח מהחוב.(שי) כי בעצם, מה אנחנו אומרים? יש פה מדד מאוד פשוט: איפה אני רוצה לפרוע חוב טכני?אז אמרנו אחד - זה מקומות שבהם הקוד משתנה הרבה.אנחנו קוראים לזה “Hotspot”.יש מערכות שעוברות על Git ומנסות למצוא “Hotspot”. איך מוצאים Hotspot? זה קל -  זה הרבה מאוד Commit-ים [טובים!] לאותה שורת קוד, או הרבה מאוד Committers לאותה שורת קוד, או לאותן שורות קוד, או לאותם קבצים.אז יש לנו איזשהו משהו שיחסית קל לכמת אותו. יש גם מערכות, כמו למשל CodeScene, שיודעות לתת לנו את האינפורמציה הזאת.ומקום שני זה באמת מוצרים שלא משתמשים בהם, או פיצ'רים שלא משתמשים - וגם פה אפשר למדוד את זה.באמצעות מערכות Monitoring, באמצעות BI, אנליטיקות (Analytics) - אני עכשיו מכניס איזה Mixpanel ואני רואה במה משתמשים.ווואלה - אם לא משתמשים בזה, או אם משתמשים בזה מעט, ואני רואה שהפיצ'ר הזה עכשיו “נרקב” לאט לאט, או קמל לאט לאט, אז וואלה, כן, תן לו למות.(אורי) בשלב מסוים התחלנו להגדיר שלבים בפיתוח מוצר. קראנו לזה Crawl-Walk-Run - [עוד על זה ב-437 Refactoring (and Observability) with Omer van Kloeten]. ב-Crawl, אם אני עכשיו כותב קוד שהוא Crawl - לא מעניין אותי החוב הטכני. כי אם הוא לא יצליח, המטרה שלו זה ניסיון, פשוט לנסות, לראות אם המוצר עובד, תופס מים, מעניין את מישהו. אז אם אני ב-Crawl, והמוצר לא יצליח, אז ברור שלא שווה לי לעבוד יותר מדי על החוב הטכני אלא פשוט לזרוק את הקוד. אם הוא כן יצליח אז אוקיי - צריך להתחיל לתכנן אותו ל-Scale, צריך להתחיל לתכנן אותו להרבה משתמשים . . . הוא גם יכול להתפתח כ-Hotspot פתאום, אז בטח ששווה לי להתחיל לטפל בחובות הטכניים שלו.(שי) נכון - אני חושב שזה גם המשך ישיר של הקו שדיברנו עליו קודם, נכון?אנחנו רוצים להיות גמישים, אנחנו רוצים להיות אדפטיביים, אז כאשר אני אני מתחיל, כאשר אני ב-Crawl, אני בעצם אותו שתיל דק וקטן.ואז אני רוצה שיהיה לי Coverage קטן של טסטים, אני רוצה להיות Monolith שקל לעשות בו שינויים - ואני רוצה להשתמש בטכנולוגיות פשוטות ומוכחות.ואני לא רוצה להשקיע הרבה . . . וככל שהזמן חולף והמוצר מתמצק ונהיה יותר מדויק, אני אתחיל לעשות Refacr-ים אופורטוניסטיים (Opportunistic).בגלל שיש לי טסטים אז אני בטוח - אני יכול לעשות את ה-Refactor-ים האלה, ואני יודע שאני לא אשבור שום דבר, אין לי פחד משינוי.ולאורך זמן, החוב הטכני פשוט “ייפרע לבד”.ואם אני מוצא את עצמי לא נוגע במוצר הזה יותר, אז אני גם לא צריך לעשות לו Refactor-ים ואני לא צריך לפרוע את החוב הטכני.זה כאילו מין כזה משהו שהוא מאוד הוליסטי, לשיטתי ולאיך שאני מסתכל על זה.(רן) בסדר גמור.36:21 חוק Conway הדו-כיווני(אורי) לפני שאנחנו סוגרים כאילו, יש פה משהו שמתחילת הפרק הוא . . . ברמה אחרת, ברמת “הכה את מומחה” . . . (רן) תן לזה דרור, שחרר . . . (אורי) אמרת “מערכות וארגונים”, בסדר? אמרת גם בהתחלה, כשהייתה לנו פה תקלה טכנית, שארגונים זה גם מערכות - וזה עשה לי טריגר למשהו שנקרא Conway's Law - שהארכיטקטורה הטכנית תמיד תהיה שיקוף של המבנה הארגוני, וההפך.זה סבבה - אבל זה משהו שמייצר המון המון קשיחות, בסדר? כי - בטח כשיצרת כבר ארכיטקטורה מבוססת וכו’ - יש לך שיקוף במבנה הארגוני. אתה אומר פתאום “וואלה, הרבה יותר קל לי לשנות מבנה ארגוני מלשנות את הארכיטקטורה הטכנולוגית שלי” - ופתאום מתחיל להיות לך קשה, או עוצר אותך, או עוצר את השינויים שלך ברמת המבנה הארגוני - המבנה של הקוד, המבנה של הארכיטקטורה.כמה אתה נתקל בזה?(שי) אז קשה לי להגיד שנתקלתי בזה הרבה אצל לקוחות שלי.אבל ב-Wix נתקלתי בזה - שבאמת היה מאוד מאוד קשה לחלק אחריות בין צוותים שונים, בגלל שהיו מבנים מאוד נוקשים של המערכות.אבל אני יכול להגיד שהחוק ארגוני הוא דו-כיווני - נכון? המבנה הארגוני משפיע על ה-Design, וה-Design משפיע על המבנה הארגוני - ו . . .(אורי) . . . הם פשוט תמונת-מראה ברוב המקרים.(שי) נכון, נכון - אבל זה לא סטטי, זה דינמי.בעצם, הם “עוברים אבולוציה ביחד” - הם עוברים מה שנקרא “אבולוציה מקבילה”: הארגון והמערכת מתפתחים ביחד, כי גם ארגון הוא בעצם מערכת.ואפשר להגיד שאני רוצה את היכולת לעשות Refactor גם לארגון - וגם למערכת.אז אם אני יכול לעשות Refactor ולשנות את הארכיטקטורה בקלות - אז אני גם אוכל לעשות Refactor לארגון בקלות.(אורי) יש שלבים בבניית המערכת שהמערכת היא כבר כל כך רובסטית, שאז קשה לך לעשות שינויים במערכת, יותר קל לך לעשות בארגון.זה נכון שאם אתה שובר דברים ל-microservices, אז פתאום אתה יכול ברמת הגרנולריות (Granularity), שהופכת לגרנולריות של ה-microservice - אבל זה נהיה יותר קשיח.אני יכול להגיד שאני מצאתי את עצמי מייצר “Super-structure” - מבנה ארגוני שהוא מעל המבנה הארגוני שמכריח חוק Conway, רק כדי להיות מסוגל להיות הרבה יותר אדפטיבי.כאילו, “Interface על Interface” - “שכבת אבסטרקציה” . . . (רן) אתה בא לדבר עם מנהל שלך והוא אומר לך “אל תדבר איתי - דבר איתו” . . .(אורי) כן . . . (שי) אני חושב שזו נקודה מאוד מעניינת - אבל אני חושב שכמו שבמערכת, ככל שהיא יותר ותיקה וככל שהיא יותר מגובשת, ככה השינוי הוא בעצם יותר איטי.זה כמו אונייה שהרבה יותר קשה לנווט, נכון? ככל שהיא יותר כבדה ויותר גדולה, ככה יותר קשה לסובב אותה.אני מכניס את עצמי פה לבור, כשאני מדבר עם ימאים על אנייות, אבל...(רן) אורי - אנייה! אתה יודע מה זו “אנייה”?(שי) . . .  אבל זה אותו דבר גם במבנה הארגוני - אני חושב שלעשות שינוי ארגוני זה לא קל כמו שאתה אומר, אורי.כי הרבה פעמים צריך לחשוב על האנשים.זאת אומרת, אוקיי - אז לקחת צוות ולפרק אותו, ולהעביר אנשים לצוותים אחרים . . .  יכול להיות שזה אפשרי.אבל יכול להיות שיש לנו מוצר שלא צריך יותר - מה עושים עם הצוות שלו?(אורי) דיברנו על האנשים האדפטיביים? בשבילנו שינוי ארגוני זה Piece of Cake, אנחנו לא . . . אין לנו הרבה עכבות.(שי) אני חושב שאני נתקלתי הרבה בארגונים שקשה להם לפטר או שקשה להם לעשות שינויים.כי ברגע שנגיד נתת למישהו Title, אתה לא יכול לקחת לו את ה-Title הזה יותר - הוא כבר היה ראש צוות, מה - עכשיו הוא יחזור להיות מפתח?אגב, אני חושב שזה שטויות - אני עברתי שלוש פעמים בקריירה שלי מלהיות מפתח ללהיות ראש צוות ללהיות מפתח ללהיות ראש צוות - וזה בסדר, אני חושב שזה משהו שהוא . . .אגב - בתוך אותה חברה, כן? לא בחברות שונות . . . (אורי) אגב, גם לזה יש פתרונות טובים - כאילו, להצליח לנהל “מדרג”, שהוא הולך גם בציר הניהולי וגם בציר המקצועי, ומאפשר פתאום את התנועה הזאת בצורה יותר טובה.(שי) כן, זאת אומרת - יש את ה-Level שלך, איפה אתה ברמת הוותק המקצועיואז אתה יכול להיות מנהל פיתוח ב-Level מסוים או Individual Contributor ב-Level מסוים.(אורי) . . . באותו Level.(שי) אני חושב אבל שבעצם, הבעיה של ה”לעשות שינוי ארגוני” היא קצת בראש שלנו - והיא קצת אמיתית.מצד אחד, קשה לקחת לאנשים Title-ים - אבל אולי, מראש, היינו צריכים להימנע ולתת Title-ים מוקדם מדי, ואז היה לנו יותר קל לעשות שינויים.וגם פה, לפעמים זה משהו שלוקח זמן - כמו שלוקח זמן לעשות Refactor למערכת גדולה ולפרק אותה ל-microservices, אז אתה לא עושה את זה בין לילה.גם לשנות המבנה של הארגון - אתה לא עושה את זה בין לילה, אתה חותר לשם לאט לאט.אתה מציב לך איזשהו “כוכב צפון”, ואתה לאורך כמה חודשים מגיע לשם.(אורי) ולא דיברנו בכלל על אבולוציה של תרבות . . . (רן) בוא, אורי - יש הרבה דברים, יש לנו Backlog . . . (אורי) כן . . . ((רן) לא דיברנו הרבה על זה, זה נכון.  גם לא דיברנו על ברנארד, שחשבנו שאולי נגיע לזה אבל אין לנו זמן לזה.42:26 סיכום וסיום וגמישות(רן) אנחנו ממש מגיעים ככה לקראת סיום, אז רק נעשה סיכום קצרצר על מה שכן דיברנו - נסתכל על חצי הכוס המלאה.אז הסעיף האחרון בעצם היה על איך לנהל חוב טכנולוגי, ומתי הוא מעניין, החוב הטכנולוגי - ומתי הוא גם לא, מתי אפשר פשוט, כמו שאורי אמר, “לספר”, לשכוח מהחוב הזה. גם זה לפעמים...(אורי) למחול.(רן) דיברנו על “אובססיה לטכנולוגיה” - שפה מסויימת, Framework מסוים, הצמדות כזו - שבמקרים נדירים היא מועילה, ובהרבה מקרים היא מביאה יותר נזק מתועלת.לפני זה דיברנו על טסטים - איך לבדוק בשלבים המוקדמים ומתי נכון לבדוק את הקוד.ודיברנו על “בואו נתחיל ב-Monolith-ים” . . ובמטא, דיברנו על מערכות תוכנה - וגם על מערכות של אנשים, נכון? איך אפשר לעשות Refactor לא רק לתוכנה,אלא גם לצוותים ולאנשים, ככה שבסופו של דבר נהיה כמה שיותר אג'ילים (Agile). איך אמרנו בעברית? “זמישים” . . . (שי) זמישים . . . גנבתי את זה מפודקאסט אחר - “מפתחים חסרי תרבות”, זה מונח שלהם [אולי, לא בטוח…].אבל להיות . . . אני קורא לזה להיות באמת גמיש. כאילו, זה... אני מאפטם (Optimize) לגמישות - של הכלשל המערכת תוכנה, של ארגון הפיתוח, של הארגון בכלל, של האינטראקציות בין האנשים . . . אני מנסה לקבע כמה שפחות דברים בשלב מוקדם - כדי שאני אוכל להיות כמה שיותר גמיש וכמה שיותר אדפטיבי לכל שינוי שיבוא.(רן) אז תודה רבה, שי! היה מעניין - תודה רבה, והצלחה עם כל הגמישות הזו. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3] פודקאסט מספר 468 של רברס עם פלטפורמה - הוקלט ב-19 במרץ 2024, רגע לפני פורים. הפעם הקודמת הייתה לפני סוכות, והרבה דברים קרו מאז. רובם רעים מאוד, אבל היה גם כנס מאוד מוצלח. מנסים לחזור לשגרה - ומקווים לחזרתם של כולם לשגרה מבורכת במהרה.אורי ורן מארחים את אריק מחברת Fireblocks - אחרי המון פגישות לאורך המון שנים בכנסים ועוד, שחקן מאוד משמעותי בקהילה שלנו - כדי לדבר קצת על קריפטו, נושא שאיכשהו לא זכור שממש נגענו בו לעומק לאורך כמעט 470 פרקים [היה קצת בפרק עם בנצי מ-eToro - פרק 436 How to reach retirement as a software developer with Bentzy Lupu], ולהיכנס לחלק מהאיזורים המאוד מעניינים של Crypto Currencies: אלגוריתמים ועוד נושאים טכנולוגיים שאריק מביא - מילים כמו MPC ו-CMP ועוד.02:04 על אריק ו-Fireblocks(רן) ולפני הכל - אריק: כמה מילים עליך ועל מה אתה עושה היום?(אריק) כן, אז היום, כמו שאמרת, אני בעצם סמנכ”ל טכנולוגיה ב-Fireblocks, מוביל את המחקר הטכנולוגי.אני ממר”מניק - בוגר אופק של חיל האוויר בעברי. ומאז מספר מקומות - מספר שנים בעולמות ה-AI ב-HiredScore,   באזורים של AI for Recruiting.ובשנתיים וחצי האחרונות בערך צללתי לעולם הזה של Blockchain ו-Crypto Currencies - היום אפשר לדבר על ההבדלה.אם פעם הם כזה “הגיעו לעולם שלנו ביחד”, אז היום אפשר גם להבדיל בין ה-Asset Class - בעצם הסוג החדש של נכסים דיגיטליים, לבין ממש הטכנולוגיות-Blockchain שיושבות מתחתיהם.(רן) ספוילר - אנחנו לא נלמד היום איך להרוויח כסף בביטקוין . . . (אורי) אה, לא?(רן) אולי קצת . . . . אבל אנחנו כן נלמד דברים ועל נושאים טכנולוגיים מרתקים שנמצאים בתחום.אז אתה עובד היום ב-Fireblocks - כמה מילים על Fireblocks?(אריק) כן, אז Fireblocks זו חברת טכנולוגיה, קודם כל.אנחנו בונים תשתית טכנולוגית, שמעליה חברות וארגונים - הרבה מהם ארגונים פיננסיים, אבל לא רק - הם בונים ברגע שהם רוצים להשתמש בעולמות ה-Blockchain.אפשר להסתכל על זה קצת בצורה דומה ל-AWS - כשאתה בונה אפליקציית Web, אז הם נותנים לך את כל הכלים שאתה צריך כדי לבנות אפליקציה.לא רק Web, מן הסתם, המון המון use-cases שונים - אבל יש כזה את המרכז: ה-Compute שהם נותנים לך, שרתים . . .  מזה הכל התחיל, אבל זה התרחב לכל השירותים.ו-Fireblocks זה סיפור די דומה בעולם שלנו.התחלנו מלפתור איזושהי בעיה מרכזית שיש ללקוחות ברגע שהם משתמשים בכל עולמות ה-Blockchain, מה שקשור לאיך הם מתנהלים עם הארנק שלהם.והמשכנו ללתת להם מענה לכל הצרכים השונים שעולים ברגע שאתה בונה “מערכת אמיתית”.אנחנו משרתים ארגונים, כלומר - זה לא מוצר-ארנק לאנשים, זה לא משהו שאתה מחזיק את הביטקוין שלך בתוכו, אלא ארגונים מכל הסוגים.זה החל מסטארטאפים וממשיך לכל מיני חברות טכנולוגיות שבונות בעולמות האלה, Brand-ים שעושים כל מיני דברים עם NFTs וכל מיני דברים אחרים ששמעתם עליהם.וממשיך כל הדרך גם לבנקים - או בנקים מרכזיים אפילו - שעושים כל מיני דברים בעולמות ה-Blockchain.כלומר ממש שחקנים פיננסיים כבדים גם בחלק מהזמן.(רן) כן, אז אתם רוצים להיות - או אולי כבר - “ה-AWS של עולם ה-Crypto Currency”…(אריק) כמו בכל תחום, יש איזה מישהו שמתכנן להיות “ה-AWS של התחום” הזה, אז אנחנו לגמרי שחקן באזור הזה.(רן) יפה, יפה, מקום טוב.04:45 המפתחות של הצוללות(רן) סבבה, אז בואו עכשיו ניכנס לנושא אחד מאוד ספציפי ומעניין של איך מטפלים או איך מייצרים ואיך מטפלים במפתחות קריפטוגרפיים שהם חלק מלב העניין - וזה, ככה, הביא אותך גם להרפתקה שהגיעה עד ל-Blackhat בזמנו, ונגיע גם לסיפור הזה.אז בואו נדבר על מה היא בעצם הבעיה שאיתה התמודדת.(אריק) כן, אז זה כמובן לא אני פרסונלית - אנחנו מדברים על כל Fireblocks - אבל אנחנו חוזרים כמה שנים אחורה.והיה אז הרבה, כמו עכשיו, כשפתאום כשמחיר הביטקוין עולה והעיתונים כותבים הרבה - אז גם אז הייתה תקופה שבעיתונים כתבו הרבה על כל האזורים האלה של ביטקוין ו-Crypto Currencies אחרים.והרבה פעמים הכתבה התחילה ב”מישהו שנגנב לו מפתח”, נכון? זה משהו ששמענו עליו.בין אם הוא איבד מפתח ומחפש אותו באיזה מזבלה . . . וגם הרבה פעמים זה לא היה בן אדם שאיבד מפתח - כלומר, יש לך איזו בורסה, שמחזיקה כסף של אלפי אנשים, מאות אלפי אנשים, ופתאום המפתח נגנב, כולם איבדו את הכסף ויש בלאגן גדול והסכומים גבוהים . . .זאת הייתה בעיה מהותית בעצם - איך אני רגע מאבטח את ה-Private Key?(רן) כן, סוג-של “לייצר כספת”, אבל גם כזו שלא נאבדת ו...(אורי) ... ושלא מאבדים את המפתח לכספת . . . (רן) כן, אבל מיילא זה המפתח שלך באופן אישי, ואולי הפסדת כמה עשרות מיליוני דולרים [מה זה בינינו…] - אבל אם אתה עובד בארגון, ואתה הולך להפסיד את הכסף של הלקוחות שלך, אז אתה באמת בצרות.(אריק) בדיוק - זו הופכת להיות בעיה הרבה יותר גדולה.ובאמת, אחד הדברים המעניינים ש-Fireblocks זיהתה בתחום הזה, זה שהרבה מהפתרונות באותו זמן, הפתרונות לנושא הזה של “רגע, איך אני מאבטח את המפתח שלי”?רק כדי שכולם יבינו - ברגע שיש לך את המפתח בעולם ה-Blockchain - שווה שנאמר - אתה יכול לעשות הכל בשם ה-Account.בעצם, כל החשבון הוא שלך. אין שום דבר באמצע.כלומר, יש צעד מאוד קצר בין “יש לי את המפתח” לבין “אני עושה עם הכסף מה שאני רוצה”.(רן) כן, במילים אחרות - המפתח הוא Single Point of Failure באיזושהי צורה.(אריק) לגמרי, Single Point of Failure, כן - שאנחנו לא אוהבים, בטח כשה-Single Point of Failure הזה יכול, תוך שניות, להיות מנוצל כדי לקחת הכל - שזה יכול להיות גם מיליארדים.עכשיו, הפתרונות באותו זמן היו באמת ברעיון הזה - הרעיון האוטומטי של אנשים, זה “בוא נשים אותו בכספת”, נכון?הייתה אפילו חברה שהשכירה בונקרים בשוויץ - שמו בתוכם כספות, סגרו את הבונקרים, ופעם בחודש הבן אדם היה מגיע לכספת ועושה את הפעולה שאתה רוצה מול הארנק שנמצא בתוך הכספת, שנמצא בתוך הבונקר . . .שזה נחמד - אם לקחת ביטקוין ואתה רוצה להחזיק אותו עכשיו ל-20 שנה, אולי זה שימושי.אבל ברגע שאתה חברה פיננסית, אתה עושה פעולות פיננסיות כל הזמן - לפעמים עשר פעמים ביום, לפעמים מאה פעמים ביום, ולפעמים עשרת אלפים פעמים בשנייה, נכון?כאילו Visa - שישים אלף טרנזקציות, TPS, טרנזקציות בשנייה.אז בעצם זה לא עובד ל-Use Case הזה.ו-Fireblocks הייתה חברה שבאה ואמרה “אנחנו רוצים פתרון שהוא מאובטח ברמה של ‘הכספת הזאת, שנמצאת באמצע בונקר’ - אבל אנחנו רוצים שהוא יהיה שמיש כל הזמן, בתוך ארגון”.כלומר, באמת ה-Single Point of Failure זו בעיה, במיוחד כש-Single Point of Failure מקושר גם הרבה פעמים לאיזה בן אדם, שיכול לקחת את הכסף.וכמובן שה-Temptation עולה ברגע שהסכומים עולים.וזה בעצם הבעיה שבאנו לפתור.08:20 חישוב בשיתוף פעולה(רן) בסדר גמור. עכשיו, אני מניח שלא כולם מכירים את ביטקוין לעומק, אבל אחד הדברים שכולם יודעים על ביטקוין - או על כל המטבעות הקריפטוגרפיים, סליחה, בואו נכליל, נעשה אבסטרקציה לבעיה - זה שהם מורכבים מחישוב מבוזר, חישוב שנוצר על ידי שיתוף פעולה. זאת אומרת, צד אחד עושה חישוב, צד נוסף עושה חישוב נוסף - ובסופו של דבר, התוצאה של החישובים האלה - אפשר באמצעותה לייצר טרנזקציות של Crypto Currency.אבל בסיפור הזה יש גם כמה בעיות. אוקיי? אז לזה אנחנו קראנו, או הולכים לקרוא לו, Multi-Party Computation או MPC, נכון? ואתם הייתם צריכים להתמודד עם זה . . .(אריק) כן, אז בדיוק - Multi-Party Computation זה דווקא כאילו הסוג-של-הפתרון שלנו לבעיה.אז הבעיה בעצם היא שיש לי את המפתח, יש את ה... כמו שאמרתי, יש רשת - רשת כלשהי, Blockchain כלשהו.בסוף, הרשת הזאת, היא לא עושה פעולות בעצמה, כן?מה שקורה על הרשת, זה בעצם שטרנזקציות מגיעות אליה - והטרנזקציות צריכות להיות חתומות, חתומות קריפטוגרפית.ואת החתימה הזאת - יש באמת Private Public Key Signature שם, כן? כאילו יש איזשהו מפתח פרטי, אני חותם איתו, זה תקף לרוב על ה-Public Address  שלי, שזה המפתח הפומבי שמקושר אליוואז כל בן אדם ברשת ה-Blockchain יכול לוודא שהטרנזקציה הזאת, שיוצאת מה-Public Key הזה, נחתמה על ידי ה-Private Key התואם - ונחתמה בפרוטוקול הרלוונטי לאותו Blockchain, כן?לBlockchain-ים שונים יש פרוטוקולים שונים, אבל יש כמה שהם העיקריים.עכשיו, אני רוצה לייצר את החתימה הזאת - ושכל אחד יוודא חתימה וידע שהיא תקינה - אבל אני לא רוצה להחזיק מפתח אחד, אני רוצה לפתור את ה-Single Point Of Failure, וכאן נכנס MPC.כשהרעיון ב-MPC בעצם, הוא במקום שיהיה מפתח פרטי אחד - יהיו מספר חלקים למפתח.אנחנו סוג-של-נפצל רגע את המפתח לכמה חלקים . . .(רן) Sharding!(אריק) בדיוק. . . . אנחנו נעשה איזה Sharding כזהאו אם היינו ממש מפצלים מפתח בודד אז זה Secret Sharing - כשאנחנו בעצם מפצלים סוד כלשהו לכמה חלקים.ואז אנחנו נרצה לעשות את הפעולה בצורה מבוזרת - שיהיו כמה שחקנים שצריכים לעשות פעולה כלשהי.אבל אנחנו רוצים לעשות את זה בצורה מאוד מאוד מדויקת - כי אם הייתי עושה את זה כמו שאמרתי עכשיו,אז היה לי מפתח במקום אחד, שכמובן מישהו היה יכול לגנוב כבר אז, ואז פיצלתי אותו - אז זה לא מנגנון טוב עבורנו.אנחנו רוצים משהו יותר Secure, אז אנחנו אומרים “בוא מראש נייצר את המפתח בצורה מבוזרת, כשהוא מעולם לא היה מפתח בודד”.יש פה איזה קצת “קסם קריפטוגרפי” כזה . . .(אורי) הוא כן מפתח בודד - אבל הוא מורכב מכמה חלקים.(אריק) יש מפתח תיאורטי בודד, שמעולם לא היה שלם - אבל יש X שחקנים שמכילים חלקי-מפתח, שאם הם היו מחברים אותו, אז הוא היה מייצר את המפתח הזה.אבל אף אחד מעולם לא ראה את החיבור הזה.(רן) זה מזכיר לי, אתה יודע . . . אני מדמיין את נאום ה- I have a Dream - אין מישהו אחד שהחזיק בכל החלום ביחד, אבל כולם ביחד מגשימים את החלום.(אריק) יפה מאוד . . . הרעיון שנכנס לי זה “There is no Spoon” - אתה רואה כף, אבל אין כף. אין מפתח באמת.11:38 היה מפתח?(רן) אבל רגע, בוא נעצור אותך שנייה לפני שאתה דוהר קדימה. אוקיי, אז הייתה לך בעיה של Single Point Of Failure, ועכשיו יש לך בעיה של Distributed Single Point Of Failure  . . . זאת אומרת, מספיק שכל אחד מהשחקנים האלה פתאום נכשל, מאיזושהי סיבה - איבד את המפתח או whatever - אז איבדת שבריר מהמפתח, דהיינו - אין לך יותר מפתח . . .(אריק) נכון. אז דיברנו קודם על יצירת החלקים של המפתח בצורה מבוזרת בעצם - צריך לומר שגם החתימה קורית בצורה מבוזרת.ואני רק אסביר את זה לשנייה, לפני שאני ניגש לבעיה שאתה מתאר.בעצם, כשאנחנו רוצים לחתום על טרנזקציה עכשיו, הדרך הנאיבית שהיינו עושים את זה הייתה שהיינו אומרים לכולם “תחברו את המפתח ותחתמו”.אבל כמובן שזה לא טוב לנו - כי אז המפתח נחשף.אז אנחנו בעצם מייצרים איזשהו פרוטוקול, שהוא פרוטוקול אינטראקטיבי בין השחקנים השונים, שיודע לחתום על טרנזקציה בלי להוציא את המפתח הפרטי - כל אחד מהחלק שלו.אנחנו לא ניכנס ממש לקריפטוגרפיה שמייצרת את זה, אבל כל אחד חותם מהצד שלו על איזה חלקים מהטרנזקציה בצורה משותפת, וזה יוצא חתימה תקינה שכל אחד ב-Blockchain יוודא אותה.ואז באמת עולה השאלה, רגע, איך אנחנו מתמודדים עם החלקים?(רן) אם יש כישלון אחד בודד, לצורך העניין, בשרשרת הזאת - אז התנתקה שרשרת . . . (אריק) נכון. אז בעצם מה שאפשר לעשות - MPC זה כזה איזה שם כולל, ויש כמה - הוא מדבר על כל סוג של חישוב שאתה רוצה לעשות בצורה מבוזרת.בתוך העולם הזה יש את העולם של TSS, שזה בעצם Threshold Signatures - שהוא מדבר על זה שאתה יכול לייצר חתימה עם X מפתחות, “T out of N” בדרך כלל מתארים את זה.כלומר, אני יכול לבחור X חלקים של מפתח - ואני יכול גם לייצר סכמות.אני יכול לומר סכמה של 2 מ-2, 3 מ-3, 2 מ-3, 5 מ-10 - אפשר לייצר כל מיני סכמות.אז אם אני רוצה להימנע ממצב שמפתח בודד - שחלק מפתח אחד יאבד, אז זה יימנע חתימה - אני יכול לעשות את זה.לא בהכרח אני רוצה - כלומר, יש איזה Design Principles שעכשיו אני צריך להכיל על הדבר הזה.אבל מעבר לזה יש שאלה, אולי אפילו יותר קשה - מה יקרה אם אחד השחקנים הוא Compromised, הוא ינסה לרמות את האחרים?ו-MPC, בבסיס שלו - כלומר, אם אנחנו מדברים על הכי-הכי Simple-MPC - הוא מה שנקרא “Honest But Curious”, אנחנו מניחים שכולם מוגנים.ברגע שאנחנו הופכים את זה ל-Secure-MPC, אנחנו בעצם יוצרים פרוטוקול מורכב יותר וקשה יותר.אבל ב-Secure-MPC, כל אחד מהשחקנים לא סומך על השחקנים האחרים.כלומר, מספיק שיש בן אדם אחד שהוא מקיים פרוטוקול תקין - ואז אנחנו בעצם בסדר.בניגוד ל”מספיק בן אדם אחד שעושה פעולה רעה”, כן?(אורי) המודל הזה של-MPC, הוא לא ספציפית נכון לקריפטו, נכון? כשהסברת את זה, זה נשמע לי מוכר ממנגנונים של הצפנה, שעושים את אותו הדבר. נגיד, אנחנו השתמשנו בזה, כדי להימנע מדרישות של האיחוד האירופי, ש-Data  צריך להיות באיחוד האירופי, אז אמרנו, “אוקיי, אנחנו מצפינים את ה-Data, הוא יושב בארצות הברית - אבל מספיק שיש לך חלק מפתח אחד שיושב באירופה, ואי אפשר לעשות Decryption” . . .(אריק) כן, אז הרבה פעמים - אני לא יודע בדיוק מה מיממשתם שם, אבל הרבה פעמים, כשעושים דברים כאלה, אז עושים יותר, כאילו, Secret Sharing - ה-Shamir Secret Sharing, למשל - כי פחות מעניין אותך העניין של “האם היה מפתח או לא היה מפתח”, אתה פשוט רוצה לפצל אותו כדי שזה יהיה בחלקים שונים.אז יכול להיות שזה היה כזה, אבל יכול להיות שזה באמת היה MPC.ה-MPC הומצא, אני חושב, בשנות ה-80 בערך - אבל בתכלס לא היה בו שימוש מהותי עד עולמות ה-Blockchain.כלומר, ה-Killer Use Case של MPC הגיע בעצם בהגנה על ארנקים - זה היה המקום הראשון שבו זה התפוצץ.היום כל האנשים שהיו מעורבים בהולדת ה-MPC והפיתוח שלו עובדים בחברות שקשורות לעולמות ה-Blockchain, כי שם ממש קורה ה-Innovation.הרבה אנשים לא מבינים את זה, אבל כל העולם של קריפטוגרפיה מתקדמת - ו-MPC נכנס לקטגוריה הזאת, ויש עוד תחומים בעולם הזה - הם היו שקטים למדי במשך הרבה מאוד שנים, זה היה תחום לא מאוד סקסי.ומאז שה-Blockchain נכנס, ההתקדמות שם היא מטאורית - זה קצת כמו מה שאנחנו רואים עם LLM-ים ו- AI.יש התקדמות גם בעולמות ה-MPC, ה-Zero Knowledge Proof, ה-Fully homomorphic encryption (FHE)  . .  יש כזה אוסף של עולמות שהם היו תיאורטיים ונחמדים, וגיקים של הנושא התלהבו מהם - אבל אף אחד לא השתמש בהם פרקטית.והיום הם כולם מתקדמים ממש בצורה מטורפת - ויוצרים יכולות שגם כמתכנתים אנחנו יכולים להעריך אותם כאיזה Building Block בתוך משהו שאתה בונה.ועדיין, זה לא קיים כמעט מחוץ לעולמות ה-Blockchain - אבל אני חושב שזה יקרה.אנשים יכירו את הדברים האלה, שיכולים לעשות דברים שהם מרגישים באמת כמו קסם לפעמים - ואז יבינו, “רגע, גם במערכת שלי אני יכול להרוויח מהיכולת לעשות חישוב בצורה שאני לא חושף את המידע שאני עושה עליו חישוב, או חישוב שהוא מבוזר” או כל מיני דברים כאלה.אז זה משהו שהוא מתפתח.17:48 אז כמה Uncompromised צריך?(רן) אז בוא נעשה רגע Recap: אמרנו, בתור התחלה יש לנו את “בעיית הכספת בשווייץ” - זאת אומרת, אנחנו לא רוצים שתיהיה ואנחנו לא יכולים לייצר כזאת כספת, זה לא Agile-י . . . אבל אנחנו רוצים כן את הביטחון שהיא נותנת, את האבטחה שהיא נותנת, של אי אפשר פשוט לבוא למישהו ולשדוד ממנו את המפתח, או שהוא לא יכול לאבד אותו. אז בתור התחלה נפצל את המפתח, ונדאג לזה שלא באמת היה קיים איזשהו מפתח במקום אחד, אלא המפתח נוצר על ידי שיתוף פעולה.אבל אז נתקלנו בבעיה של “אוקיי, אבל מה קורה אם אחד מהשחקנים נכשל?” - ואתה אומר, אוקיי, גם לזה יש פתרון: מספיק X מתוך Y, מספיק ש-9 מתוך 10 השחקנים, יש להם את המפתח, זה בסדר. אבל זה השתמש בנקודת ההנחה שכולם משתפים פעולה וכולם טובים וכולם “בעדינו” - מה קורה אם אחד מהם הוא Evil או Compromised, או כל דבר כזה - וגם בזה אתה מטפל.(אריק) כן.(רן) אוקיי - ואז אני אשאל אותך את השאלה . . .  כמה מתוכם צריכים, גם פה יש את הסימטריה הזאת, של כמה מתוכם צריכים להיות Uncompromised כדי שזה יעבוד? האם מספיק שנגיד חמישה מתוך עשרה הם Uncompromised וגם לא איבדו את החלק שלהם של המפתח, כדי שזה יעבוד, או ש . . . זאת אומרת, איך מטפלים בסיפור הזה?(אריק) כן, אז באמת כל מה שתיארת נכון, ויש בעצם . . . מתחיל לזה Design Space, של איך אתה רוצה לתכנן את ה-MPC שלך.וזה רק החלק הראשון, ה-MPC - אנחנו ניגש עוד לעוד חלקים בעצם ב-Funnel - אבל ברגע שעשית Secure-MPC, אז אמרנו באמת - שחקנים הם שמוודאים שאחרים הם Honest, ואתה בעצם לא יכול לייצר חתימה לא טובה כל עוד יש מספיק שחקנים שהם כן Honest - ואנחנו גם לא חייבים לפצל את המפתח להמון.כלומר, ברגע שאנחנו בונים מערכת גדולה מעל הדבר הזה -אז נגיד במקרה של Fireblocks - אני יכול לדבר על חלק מהדברים - אז חלק מהמפתח יושב אצלנו, וחלק מהמפתח יושב אצל הלקוח, ואתה רוצה לייצר איזה מצב שאנחנו לא יכולים לחתום בשם הלקוח.כי אנחנו ספק טכנולוגיה - אנחנו לא בנק, אנחנו רוצים לתת להם טכנולוגיה לעבוד, אז אנחנו לא רוצים להיות במצב שאנחנו יכולים לייצר חתימות בלעדיהם.ומצד שני, אנחנו גם לא רוצים להיות במצב שאם הם - שהם לא בהכרח חברת Security ב-Level שלנו - אם הם יאבדו את החלק - לא יאבדו, יותר אם מישהו יגנוב את החלק-מפתח שלהם - אנחנו לא רוצים שהוא יוכל לחתום.אז שוב, אפשר פה לעשות איזה Design - זה לא בהכרח אפילו דורש לעשות T-out of N, הרבה פעמים זה יכול להיות גם N-out of N, כשאני מטפל בבעיית העיבוד חלקי-מפתח, בכל מיני Backup-ים שונים וכל מיני דברים כאלה.אז השאלה בעצם היא מה אנחנו מקבלים בתוך הדבר הזה - כשפיצלנו את המפתח, פתאום אם אתה רוצה לגנוב את המפתח, אז אתה צריך לפרוץ לא רק ל-Laptop של הלקוח, שיכול להיות שהוא לא שמור כל כך טוב.אלא אתה צריך לפרוץ גם לשרתים של Fireblocks - כי אנחנו לא נחתום על משהו שהוא Malicious.ואז אנחנו מתחילים כזה להתרחק, כן? אנחנו אומרים, אוקיי, אז יש לנו פרוטוקול MPC - שהוא כבר יציב, הוא בודק את עצמואבל אז יש את החלק של המפתח - צריך לאחסן גם אותו, נכון? צריך לשמור עליו.אז אתה נכנס לכל מיני טכנולוגיות של Key Management Systems וכאלה, נכון? HSMs, Secure Enclave, כל מיני דברים כאלה.אבל אם אנחנו רוצים ללכת עוד יותר קדימה בהקשר של הטכנולוגיה - כי זה לא רק מפתח, יש פה איזו פעולה.אז איך אנחנו יודעים שהפעולה - אנחנו רוצים לאשר אותה?כלומר, זה בסדר שכל החלקים משתפים פעולה - אבל יש איזו שאלה בכלל האם זאת פעולה שהיא טובה?אולי הפעולה שכולנו כרגע חותמים עליה ביחד זה גנבת-הכסף? . . . 20:15 שלב הראבק ו-Secure Enclave(רן) כן, הבנתי - זאת אומרת, אתה רוצה להכניס פה “ראבק” מה שקוראים - זאת אומרת, Role-Based Access Control (RBAC), הידוע בכינויו “ראבק” . . .(אריק) לא הכרתי את המינוח, אבל אני אוהב את זה מאוד . . .(רן) כן, אז אתה אומר, אוקיי - “אני רוצה לאפשר לו להעביר 50 Bitcoins, אני לא רוצה לאפשר לו להעביר 50 אלף Bitcoins” . . . או “אני לא רוצה לאפשר לו למשוך - אני רוצה רק לאפשר לו להפקיד”, או בקיצור, “לעשות פעולה X, לא לעשות פעולה Y”.(אריק) כן, בדיוק.וברור לנו שבארגון - ושוב, כאן אנחנו מתחילים ללכת להבדל בין “ארגון" לבין “בן אדם”, כן?בן אדם - יש לו ארנק שלו, והוא יכול לבזבז כסף.אבל אם אתה בארגון - זה שמותר לך לעשות איזו פעולה כלשהי, ששולחת 10 דולר לכתובת ספציפית במקרה ספציפי, לא אומר שיש לך את המפתחות לכספת של הבנק . . .כלומר, יש פה אנשים, יש פה תפקידים, יש פה תהליכים, יש פה דברים שמותר, אסור, מגבלות וכאלה.(רן) כן, כמו שבבנק מנהל הסניף יכול לחתום עד כך וכך, ופקיד עד כך וכך, וכו’.(אריק) נכון. אז כאן, אנחנו רוצים בעצם להוסיף איזשהו Policy, נכון? אנחנו רוצים להוסיף איזשהו משהו, שאתה בודק אותו אפילו לפני שאתה מתחיל חתימה.אולי אסור לחתום - כ-Fireblocks, אנחנו לא נחתום על משהו שלא עובר Policy.(רן) כן, אבל זה לא נשמע לי כמו אתגר כזה מסובך, סליחה . . . זאת אומרת, כאילו, נכון - יש פה מה למממש: אתה שם Database, אתה מגדיר הרשאות וזה, אבל למה זה כזה מסובך?(אריק) אז אוקיי, אז זה לא מסובך - ובהינתן אחד משני דברים: או שאנחנו לא מדברים על הרבה כסף, או שאנחנו מדברים על הרבה כסף, אבל זה שאתה תשיג את ה-Secret לא מאפשר לך אשכרה לעשות איתו משהו מיידי.ברגע שאתה ארגון שמנהל על ה-Blockchain מיליארד דולר, ויש לך איש DevOpsאז אם הוא יכול פשוט ב...אתה יודע, כי יש לו הרשאות - כן, יש Role-based Permissions, אבל יש לו Root לשרת, יש לו Root ל-KMS, יש לו ניהול של ה-AWS, יש לו את כל הדברים האלה - בתכל’ס הוא יכול לעשות מה שהוא רוצה . . . ואם אתה מתחיל לפרק ארגון מורכב כזה, אתה תמצא את עצמך עם הרבה אנשים שיכולים לעשות מה שהם רוצים - ואתה מקווה שאחד מהם לא אשכרה ירצה לעשות את זה . . וזה לא משהו שאפשר לעשות(אורי) . . . כי אי אפשר לסמוך עליו . . (אריק) בדיוק, כי אפשר להסתמך על זה - ואני חושב שקצת זה מה שהיה קורה פעם, לפני שחברות כמונו התחילו לקום.היה איזו בורסה, היה בה המון כסף - ואז הם אמרו “נגנב לנו המפתח!”, וכל בן אדם שהיה לקוח שלהם חשב לעצמו “רגע, רגע . . .  נגנב להם המפתח - או שהם גנבו את המפתח? אני קצת לא בטוח מה קרה פה” . . .אבל אנחנו רוצים לייצר איזו תשתית שהיא טובה וחזקה מספיק, ככה שאם אנחנו רגע מדברים ממש בהערכת סיכונים - גם Root בשרת לא ייתן לך לקחת את הכסף.(רן) כן, זאת אומרת, אתה רוצה לייצר RBAC - אבל אתה לא רוצה שלאף אחד תהיה את האפשרות לשנות את ה-RBAC הזה, מבלי שבאמת התכוונת לתת לו את זה. (אריק) כן, כן.(רן) אוקיי, אז איך עושים את זה? זאת אומרת, נשמע כמו עוד מפתח! עוד שכבה של אותו סיפור . . . אבל אז שוב יש לך את הבעיה, של “מי מנהל את המפתח האחרון?” . . . (אריק)  נכון . . .אז בעצם, מה שהכנסנו זה ברגע שנכנסנו לעולם הזה, Fireblocks נכנסה לעולם הזה של MPC, Secure MPC וכל הדבר הזה, אז התחילה להוסיף עוד שכבות - וזה בעצם סוג של “ללכת אחורה ב-Funnel” הזה של התהליך, עד לשלב שאנחנו יכולים לומר שהפעולה כבר לא תסכן את הכסף.וכל מה שנמצא בדרך - למשל, Policy Management - אם הוא כן פעולה שתסכן את הכסף, וכמובן ש-Policy Management זה כן - אז אנחנו מכניסים את זה למשהו שנקרא Secure Enclave [וואו, איזה פלאשבק לאינטל 2010 . . . ]. כלומר, אנחנו בעצם רצים בסביבה שהיא “מיוחדת” - אנחנו לא רצים פשוט ככה “בתוך השרת”, כי אם נרוץ בתוך השרת, יש הרבה אנשים שיכולים לשנות.אנחנו רוצים לרוץ בצורה שאי אפשר לשנות את הקוד, שאי אפשר לשנות את הזיכרון, שאי אפשר, כאילו בעצם . . .  יש המון - אי אפשר לקרוא את הזיכרון, כי שם נמצא המפתח. אי אפשר לעשות הרבה דברים שאתה בעצם רוצה למנוע.ויש טכנולוגיות בדברים האלה - כלומר, כל הטכנולוגיות האלה של Secure Compute, אלו טכנולוגיות שנבנו בדיוק לדבר הזה, ומאפשרות לך להריץ קוד בסביבה שהיא מנותקת [פיזית, ברמת ה-Hardware]בוא נגיד שהיא רואה אפילו את ה-Operating System בתור “אויב” . . .(רן)  כן, זאת אומרת, “סביבה” - למה את מתכוון? לחומרה?(אריק) אז כן - זה ממש ברמת החומרה.יש כמובן גם אופציות ב-Cloud שהן יותר מבוססות Cloud ועושות את זה ברמת אבסטרקציה גבוהה יותראבל אם אנחנו הולכים למחמירים - ואנחנו מהמחמירים - אז בעצם זה משהו שהוא ברמת החומרה.אפשר לחשוב על זה כעל חלק בזיכרון שהוא ממש מנותק ממערכת ההפעלה - כלומר, ה-CPU יכול לגשת אליה, אבל הוא ניגש אליה דרך . . . לפעמים זה אפילו איזה Chip-הצפנה בדרך, ואף אחד מחוץ למה שאמור לרוץ ב-Secure Enclave הזה לא רץ ב-Secure Enclave הזה, לא נוגע ב-Secure Enclave הזה.בטכנולוגיות הטובות ביותר, אפילו אם תנסה לקרוא את מה שרשום על הדיסק - אז הוא מוצפן, אז אתה לא יכול לקרוא את זה.כלומר, זה ממש אמור להיות מוגן ברמה הכי גבוהה. 25:04 זמן טוב לדבר על Blackhat - ו-CMP(רן) אוקיי, עכשיו זה זמן טוב לדבר על Blackhat? יש לנו מספיק Context? אז למי שלא מכיר, רק שנייה - Blackhat זה כנס שנתי מאוד מאוד גדול שקורה עדיין ב-Vegas? כן . . .  זה, אני חושב, הכנס מספר אחת בעולם ה-Security . . .(אורי) שתיים, שתיים . . . (רן) אוקיי, אחרי רברסים . . . ושם ניתן דגש גם על טכנולוגיות להגנה - אבל גם על דרכים לפריצה, זאת אומרת, כדי שנכיר את מה שנקרא “להכיר את האויב” [גם ברברסים! ד”ש לג’וזף]. הכינוי “Blackhat” ”זה מין כינוי כזה לפורצים. אז באת - אתה והצוות - והצגתם איזושהי תגלית - ספר לנו עליה קצת.(אריק) כן, אז קודם כל: אורן וניקוס - אני רוצה לתת להם את הקרדיט, הם עשו עבודה מדהימה.אז בעצם בתוך כל המנגנון הזה, אנחנו מסתכלים על כל המערכת הזאת ואנחנו חוקרים את התחומים האלה - זה מה שאנחנו עושים כחברה.כמו שהפרוטוקול MPC שלנו זה משהו שאנחנו בעצם כתבנו, שחררנו . . .שוב, אני רוצה לתת את הקרדיט לאנשים - ניקוס, אודי ורן קנטי בעצם הוציאו אלגוריתם חדש - CMP - זה ראשי תיבות של האנשים האלה [והנה המאמר - UC Non-Interactive, Proactive, Threshold ECDSA].אז בעצם אנחנו חוקרים את הנושא הזה, ובשלב מסוים אנחנו אומרים “רגע, אלגוריתם MPC, הוא בעצם מדבר באמת על זה שאף אחד לא סומך על אף אחד, וגם אם אתה תשתלט על אחד מהשחקנים, אתה לא אמור להיות מסוגל לעשות שום דבר”.ואנחנו רוצים למצוא - אולי כן אפשר?אז חקרנו אלגוריתמים שונים בתעשייה - ובעצם מצאנו בשני אלגוריתמים, שהם היו אלגוריתמים המובילים בתחום. בעצם CMP היה טיפה פחות מוכר, או קצת חדש יותר - היו כמה אלגוריתמים מובילים, ביניהם GG ו-Lindell אלו שני אלגוריתמים מאוד מוכרים, שהרבה מאוד חברות, גם בתחום שלנו, השתמשו בהם.ומה שבעצם אנחנו מצאנו זה שבאלגוריתמים האלה,  אם אתה עושה “משחק" כלשהו - והיתה שם, שוב, עבודה מתמטית-קריפטוגרפית יפיפייה של ניקוס - אם אתה עושה “משחק” כלשהו, אתה בעצם - במידה ותשתלט על אחד השחקנים - אתה תוכל לאט לאט “לדלות את הסוד” מהשחקנים האחרים.זה משהו שאסור שיהיה קיים באלגוריתם MPC - אנחנו מניחים שאף אחד לא מספר שום דבר לאף אחד אחר, זה כל הבסיס לדבר הזה.מה שבאמת הצגנו בBlackhat [הנה השקפים - Small Leaks, Billions Of Dollars: Practical Cryptographic Exploits That Undermine Leading Crypto Wallets] ו-DEFCON [לזה יש ההקלטה - EF CON 31 - Small Leaks, Billions Of Dollars - Nikolaos Makriyannis, Oren Yomtov] זה כזה השילוב היפה ב-Vegas: שני כנסים שמגיעים אחד אחרי השני . . .זה . .  אני חושב שזה היה ארבע התקפות בסופו של דבר, שתוקפות מספר פרוטוקולים שונים בהכי-קיצוני שלהם, בחתימה אחתאו יותר מזה - בסיבוב הראשון, בתוך החתימה הראשונה, כי MPC זה לרוב מורכב מסיבובים - אתה מסוגל להוציא מפתח, בעצם, משחקן אחר.וככל שהאלגוריתם שונה ואחר, אז זה יכול לקחת יותר חתימות - בחלק מאופציות ממש הרבה חתימות - אבל בעצם הצלחנו סוג-של-לשבור אלגוריתמים מסוימים של MPC.שוב, זה אלגוריתם שלנו - שהיה חשוף לזה, אבל זה כמו כל דבר ב-Security, כן? אנחנו מוצאים את החולשה הבאה, הראינו גם את הפתרונות לדברים האלה, ולאט לאט כל התעשייה מתקדמת ומוצאת פתרונות טובים וחדשים יותר.כן ראינו, בעצם, שחברות גם מאמצות את הפתרונות שהבאנו לזה וגם בעצם עוברות לאלגוריתמים קצת  חדשים יותר בחלק מהמקומותנוטשות אלגוריתמים שכבר הוכחו כלא טובים, בחלקם,  ועוברים לדברים אחרים.28:19 לתכנת אלגוריתמים קריפטוגרפיים(רן)  אז אחד מהאתגרים בלהתעסק בעולם הזה של קריפטו זה באמת האתגרים האלגוריתמיים. כמו שאמרת,שגיאה אלגוריתמית, אולי, בתכנון של הפרוטוקול - לא שזה קל לתכנן כזה פרוטוקול - אבל עם הזמן מגלים בעיות אלגוריתמיות ומשפרים את הפרוטוקול, משפרים את האלגוריתם ופותרים אותם.אבל בהינתן פרוטוקול - ובוא נניח שהוא מושלם - לבוא ולקח את הפרוטוקול הזה ולתכנת אותו, זה עולם ומלואו, אוקיי? זה לא פשוט . . . צריך לדעת איך לעשות את זה - ולכם יש הרבה מאוד ניסיון בזה.אז אולי ב . . . אין לנו הרבה זמן, אבל בדקות האחרונות שנשארו לנו, אולי כמה למידות שלכם, של מה זה אומר לקחת איזשהו Whitepaper, לקחת איזשהו פרוטוקול קריפטוגרפי - ולתכנת אותו, “לשים אותו על שרתים”.(אריק) כן, אז אני חושב שבאמת אחד הדברים ש... יש הרבה מאוד תובנות בתחום הזה, ואני חושב שאחד הדברים שחשוב להבין - וזה כזה סוג של לקח שבאמת נכתב ב . .  אולי “דם” זו לא המילה הנכונה, אבל מאמר אקדמי הוא לא Spec, אוקיי? והרבה אנשים קוראים מאמר, וזה קצת מרגיש כאילו זה Spec - כי בעצם מתארים שם פעולותלרוב זה Pseudo-code כזה - כמתכנת אפילו אתה סוג-של-מבין מה קורהאבל יש המון דברים מתחת לפני השטח, שאלא אם כן באמת יש לך את המקצועיות והידע איך לקרוא מאמר כזה, אתה פשוט תניח שהן לא הנחות נכונות, כלומר שמשמיטים שם דברים.בסוף, מאמר אקדמי זה מאמר - המטרה . . . (אורי) . . . הוא לא יביא את “מקרי הקצה” - הוא יביא את ההוכחה האקדמית שמשהו קורה, אבל . . .(אריק) אז לפעמים לגמרי, לפעמים זה מאוד תלוי מה המטרה של המאמר.לפעמים המטרה של המאמר זה לתת פרוטוקול מלא, לפעמים המטרה שלו זה שבכלל פשוט יש לו רעיון אחד חדשני, אבל הוא יודע שבשביל הרעיון הזה, הוא צריך לעטוף אותו בהמון דברים, אז הוא “עושה את העטיפה שצריך” כדי שהמאמר יתקבל לכנס הנכון . . . .ואז אתה קורא את זה, ואתה מניח שאם מה שקראת זה מה שיש אז הכל בסדר - אבל הוא בעצם מניח  שקראת עוד ארבעה מאמרים אחרים לפני זה כשתממש את זה, כן? . . . אז זה למשל משהו שממש יכול להיות מהותי.מעבר לזה, הרבה פעמים בכלל המאמר מתייחס לאיזו סיטואציה בעולם, אוקיי?כלומר, הוא מניח שזה משחק חד-פעמי, אוקיי?זה מאמר - הכל Secure, הכל טוב, הכל מעניין, הכל מוכח - כל עוד אתה משחק את זה פעם אחת. אבל אם תשחק את זה הרבה פעמים, אז כבר שום דבר פה לא עובד . . . זה לא בהכרח יהיה כתוב בצורה הברורה שאתה מניח - כלומר, יש איזה הנחות של איך המערכת עובדת.האם אתה עושה Input Validation לפני האלגוריתם הזה? יכול להיות שהוא מניח את זה, יכול להיות שהוא לא מניח את זה . . . .כלומר, יש פה עולם שלם של בכלל איך אתה נכנס לדבר הזה.אז זה למשל איזור אחד.אני חושב שאיזור אחר שהוא גם מעניין . . . (רן) כן, זאת אומרת לדעת “איך לקרוא” את המאמר, או במילים אחרות: “כבדהו וחשדהו”, זאת אומרת - יכול מאוד להיות שהנקודות שם מאוד נכונות, אבל אתה צריך לדעת שאם איך לך את “התלמוד שמבאר אותו”, אתה לא תדע להבין את המשמעות העמוקה יותר שלו.(אריק) נכון - ואתה לא תדע להבין את הדברים שלא צוינו בעצם.ולפעמים, גם זה קצת מצריק לומר את זה, אבל במאמרים . . . (אורי) לרוב, כל מה שיש מסביב ולא מצוין - זה החיים, “החיים עצמם”, מה שנקרא . . . .(אריק) נכון, לגמרי, לגמרי . . .  והרבה גם ממה שפורסם ב-Blackhat - חלק מהדברים היו שם, כלומר המאמר היה בסדר, אבל ברגע שהשתמשת בו בעולם האמיתי זה לא עבד טוב.כלומר - הייתה בעיה, שצוינה בצורה מסוימת או שלא צוינה בצורה מסוימת - אבל ראינו שהרבה בעצם לא יודעים לפתור אותה.דבר נוסף שהוא מאוד חשוב - דיברנו על Secure Enclave, דיברנו על כל הטכנולוגיה שאתה שם, על MPC, על  כל הדברים האלה.אבל נגיד שיש שאלה של Supply Chain Attacks, כן? כלומר, אתה כותב קוד ואתה, מכיוון שאין לך הרבה זמן, אתה דוחף פנימה איזה 15 ספריות שונות, שעכשיו נמצאות בתוך ה-Secure Enclave שלך . . . אז זה נחמד שאתה מאוד Secure מהתקפות מבחוץ - אבל מה אם יש לך Malware בתוך הקוד שנכנס, כן?כלומר, יש הרבה דברים שמבחינת ה-Security, פשוט  Security Practices בסיסיים, הם . . .שוב, ברגע שאתה שוב מתעסק במשהו כל כך מורכב, אתה צריך להקשיח אותם מאוד.ה-MPC שלך מקבל Input - מה אתה עושה עם ה-Input הזה? עד כמה אתה רגיש למישהו שמשחק עם ה-Input בצורה שהיא לא צפויה, כדי להתחיל לייצר התנהגות אחרת?כלומר, יש ממש הרבה דברים שאתה צריך לגעת בהם כשאתה מתכנן את המערכת הזאתהיא ממש דורשת כזה “איזורי Expert” - אתה צריך להיות Expert בקריפטוגרפיה, אתה צריך להיות Expert ב-Blockchain, אתה צריך להיות Expert ב-Security.או לאסוף את כמות האנשים האלה שבעצם מסוגלים לאסוף את כל הדברים האלה למשהו קוהרנטי,  שגם עובד טוב ביחדכי יכול להיות איש Security מדהים ואיש קריפטוגרפיה מדהים - אבל בדיוק בתווך ביניהם, זה איפה שהכל מתפרק.וגם זה דברים, שבעצם במאמר שלנו - במאמר וההרצאה ב-Blackhat - ממש נגענו במקום הזה.כלומר, בנקודה הזאת, שבה “הקריפטוגרפיה פוגשת את העולם האמיתי”.33:15 ובחזרה ל-Fireblocks(רן) אוקיי, אז נסכם - אז Fireblocks, אתה אומר - התחלתם בבעיה הנקודתית הזאת, של איך להחזיק מפתח, איך  להחזיק מפתח בצורה שהיא Secure, ואחר כך להוסיף על זה הרשאות וכו’, וגם אמרת, לא נכנסנו לשם, אבל שאתם הרחבתם את השירותים שלכם מעבר לזה, לזה לא היה לנו זמן להיכנס פה.ואז צללנו קצת פנימה, לתוך עולם הבעיות האפשרי - ואיך אפשר, ככה ממש על קצה המזלג, לפתור אותן. זזה היה סופר-מרתק!ספר לנו אולי עוד קצת על החברה - אתם כרגע מגייסים? מחפשים? איפה אתם נמצאים בכלל? אמרת? . . .(אריק) כן, אז טוב - אנחנו נמצאים בתל אביב, מגייסים . . .(רן) איפה זה תל אביב? . . . .(אריק) תל אביב בואכה רכבות למיניהן . . . .כמובן מגייסים  . . . Fireblocks, לא דיברנו על זה בכלל, אבל יש לנו כבר הרבה לקוחותחברה שהיא מאוד מצליחה.אני חושב שעד היום איבטחנו משהו כמו 4 טריליון דולר במערכת - כלומר, אנחנו מתעסקים באמת בכסף מהותי, בעיות מהותיות של לקוחות אמיתיים.וגם כל מיני אנשים - אני יודע שהרבה אנשים כזה,  “Blockchain” זה משהו שהם כזה לא בטוחים “כמה קורה שם משהו מעניין”. אנחנו באמת עובדים עם החברות הטובות בעולם - חלקן פומביות לגבי הדברים שהן עושות ב-Blockchain,  חלקן עוד לא פומביות.אבל גם בכל השנים האלה, שמאוד יכול להיות שלא - בתור “טכנולוגים” - לא התעסקתם ב-Blockchain, כי זה היה נשמע כמו משהו שכבר “עבר, קרה ולא מעניין” . . . .הרבה חברות בנו בזמן הזה - בין אם זה חברות שבונות טכנולוגיה כמונו, ובין אם זה חברות מוצר.המנכ״ל של Shopify, ה-Founder של Shopify, טובי (Tobias Lütke)- לפני איזה חצי שנה הוא היה בכנס, והוא אמר “אנחנו בונים דברים טובים בקריפטו כרגע. כרגע זה לא נשמע מגניב - עוד מעט זה יהיה מגניב, ואתם תשמעו על זה אז”. [Crypto Conversations | The future of the digital economy with Brian Armstrong & Tobi Lütke]ואני חושב שזה מייצג מאוד את התעשייה - הרבה טכנולוגיה נבנתה פה ונבנית פה, ולאט לאט היא תצא לעולם, בקצב שהרגולציה ופשוט הטבע של האנשים יאפשרו לה.(רן) כן, בעקומת ה-Hype, אנחנו עכשיו במדרון המתון העולה  . . . (אריק) נכון, לגמרי.(רן) אוקיי - ואם אני לא מבין, כלומר - אם אני מפתח, אבל מעולם לא עברתי בעולם הקריפטו ואני לא מכיר, יש לי מה לחפש אצלכם?(אריק) חלק קטן מאוד ממה שאנחנו עושים בחברה זה האזורים האלה של הקריפטוגרפיה.מעל זה, יש שכבות על גבי שכבות של מוצר - מאוד חדשני שפותר בעיות ללקוחות.כלומר, כל הדברים הרגילים שאנחנו מכירים - כשיש להם איזה “Flavor”, כאילו גם “Flavor FinTech-י”אנחנו היום הרבה יותר חברת פינטק מאשר סייבר . . . זה התחיל מאוד Security-oriented, וזה עבר לפשוט לאפשר לבנות . . . אנחנו, המטרה שלנו זה שכל עסק שרוצה לבנות - ואנחנו מאמינים שכל העסקים יגעו בעולם ה-Blockchain בעתיד - יוכל לעשות את זה, בלי להתעסק בכל הדברים שדיברנו.כלומר, שהם פשוט יקבלו מוצר טוב שהם עובדים איתו, הוא עובד כמו שצריך, הוא בטוח - והוא גם Easy to Use.אז זה לגמרי לבנות מוצר טכנולוגי לאנשים.(רן) אוקיי, אריק, תודה רבה! היה לי ממש כיף, להתראות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק 467 של רברס עם פלטפורמה - הוקלט ב-5 בספטמבר 2023 (חג ספטמבר שמח!). אורי ורן מארחים באולפן בכרכור את רולי אליעזרוב מחברת OwnID לשיחה על Passkeys ותחום ה-Identity Management, שרולי נמצא בו כבר הרבה מאוד שנים.01:20 קצת על רולי , Gigya ו-OwnID(רן) אז לפני שנצלול פנימה - כמה מילים עליך ועל החברה, רולי?(רולי) כן, אז כמו שאמרת - אני באמת Veteran של תחום ה-Identity: אני הקמתי חברה בשם Gigya ב-2007שבאיזשהו שלב, ב-2017 או 2018, נרכשה על ידי SAPובעצם, מה שגם מיוחד בגישה שלנו - כשאתה מדבר על iIdentity, בדרך כלל זה חברות, החברות שנותנות פתרונות בתחום הן עם “DNA של IT”זה בדרך כלל נתפס כאיזשהו פתרון Security לבעיה של אות’נטיקציה (Authentication) בדרך כלל של ה-Employees או B2Bואנחנו - גם בחברה הקודמת וגם בחברה הזו, ואני חושב ש-Passkeys גם מתקשר לזה - מביאים את זה לרמת ה-Consumerזאת אומרת - פתרון . . . . אנחנו בעצם היינו מהראשונים שנתנו פתרון-מוצרי, שמשרת את ה-Consumerמכרנו לחברות - אבל זה לא היה לזיהוי של העובדים, אלא ל-Identity של הלקוחות.(רן) לצורך העניין - לא זיהוי של עובדי הבנק, אלא זיהוי של לקוחות הבנק . . .(רולי) כן, והרבה פחות מבנקים, אפילו . . .  אתה יודע,  B2C הכי “Mainstream”(רן) כן, אז זה מה שהיה ב-Gigya - והיום ב-OwnID?(רולי) כן, אז ב-Gigya בעצם “ארזנו” קונספטים (Concepts) קיימים שקשורים ל-Identity,למי שלא הבינו עדיין על מה אנחנו מדברים - על Registration, Login וכל ה-Data שנשמר מאחור וה-Consent - מה אני יכול לעשות עם ה-Data, וכו'.אז פשוט ארזנו את זה ועשינו פודקטיזציה (Productization) של כאילו Plug & Play לכל חברה שרצתה להשתמש במשהו “מן המוכן”.אבל בעצם לא המצאנו שום דבר . . . מה שעשינו ב-OwnID זה שאנחנו מביאים בעצם איזושהי “בשורה” - שאפשר לעשות Identity באופן שהוא הרבה יותר “נעים למשתמש”אף אחד הרי לא אוהב - לא להירשם, לא לעשות Log-in, אף אחד לא אוהב סיסמאות . . . וזה מה שאנחנו עושים עכשיו.(רן) כן, אז אני מנסה להיזכר כמה . . .  כאילו, הייתה תקופה שבה הייתי נרשם לאיזה חמישה אתרים ביום - והיום זה כבר כמעט לא קורה. תמיד יש איזושהי אות’נטיקציה (Authentication) עם Google או GitHub, ואחרים  . . . (רולי) . . . . אבל זה אתה, כי אתה סבבה עם להירשם עם Google או GitHubיש הרבה מאוד אנשים . . . . בואו נגיד, 50% משתמשים במה שנקרא Social Login או External Identity Provider בשביל להתחבר לאתר - ו- 50% עדיין ממציאים שם משתמש עם סיסמאמסיבות של “האח הגדול” או Privacy או כל סיבה אחרת(אורי)  . . . אולי גם קצת שמרנות ולא יודע, לא הולכים על “הקל” אלא רגילים ל . . . .(רולי) נכון03:58 הצעצוע החדש - Passkeys מביא את זה לרמת ה-Web(רן) אוקיי, אז בואו נדבר על “הצעצוע החדש שהגיע לשכונה” - Passkeys: מה הם?(רולי) כן, אז קודם כל זה שיתוף פעולה יוצא דופן בין שלושת הענקיות - Google, Apple ו-Microsoft - שהבינו את הבעייתיות שישבעיקר אנחנו מדברים עכשיו על הנושא של האות’נטיקציה (Authentication), שזה ההזדהותאני חושב שזה, נכון להיום, בעיקר שם-משתמש וסיסמא - והבעיות שקשורות לסיסמאמעבר לזה שזה לא נוח, הן אינסופיות, גם מבחינת כמובן Security,שאגב - מייצר עוד Friction, בגלל הבעיות Security - הן מייצרות עוד Friction, יותר ממה שהיה קודםכי עושים את הסיסמא יותר מורכבת, מבקשים עוד Factor כמו SMS Message או Authenticator - אז בעצם הבעיה נהיית יותר ויותר חמורה עם הזמן ככל שיש יותר כלים - כלי-פריצה - בשוקוהם הבינו שצריך לעשות פה איזשהו שינויכשאומרים “Password-less” - עד היום, אם אתה תראה פתרונות של, נאמר, שליחה של SMS, שזה קוד חד-פעמי, או Magic Link,וזה דברים שהם שבורים - הם גם לא נוחים וגם לא Securedאפשר לדבר, אם אנחנו רוצים, גם קצת לצלול לצד של ה-Security . . . אבל מה שהם הכריזו . . . הם אמרו ככה: קודם כל, בכל Device כמעט היום יש - לפחות ב-Device-ים המתקדמים - יש Unlock-mechanismאם זה ב-iPhone אז יש את ה-Face ID, ב-Apple . . . . ברוב ה-Mac-ים יש את ה-Touch IDגם בWindows היום יש . . . אם זה לא ביומטרי, אז יש איזשהו Unlock, שרוב האנשים כאילו קמים מה-Desktop אז הוא ננעל.ואנשים עושים Unlock ל-Device שלהם - גם אם זה Mobile וגם אם זה ה-Desktop, כל הזמן.ולמה לא להשתמש באותו מנגנון, בשביל גם לאפשר, גם ברמת ה-Web, לעשות את האות’נטיקציה (Authentication)?(רן) כלומר ”ה-Device כבר יודע מי אתה”. אתה משתמש בטלפון, פתחת אותו - הוא זיהה אותך . . . .(רולי) כן, עכשיו זה לא שהוא מדווח “מי אתה" - הוא רק אומר “הבנאדם הצליח לעשות Unlock ל-Device שלי” . . .(אורי) אבל משתמשים בביומטרי גם כדי לפתוח אפליקציות . . . .(רולי) אוקיי . . . . עד היום, היה ממשק רק ל-Native Applications, ל-Unlock Mechanism.ומה שהוא עשה - או מה שהוא עדיין עושה - הוא בעצם שומר . . .  הוא נותן גישה לשלוף את הסיסמה מה-OS - ולשלוח אותהזאת אומרת - עדין קיימת סיסמהב' - זה רק ברמת ה-Native Apps - אני בטוח שלשניכם יש אפליקציות ולכל השומעים שלנו, הקהל, יש אפליקציה של הבנק שלהםוהם כל כך מאושרים מזה שהם יכולים עם ה-Face ID, או עם ה-Fingerprint, אם זה ב-Android, כל פעם לבצע פעולותאבל כשהם הולכים למחשב, או כשהם רוצים לעשות משהו אחר או מכל סיבה אחרת - הם צריכים את הסיסמה עוד פעם . . . .אז התשובה היא שיש את זה לרמת ה-Native Apps - והפרוטוקול הזה של Passkeys מביא את זה לרמת ה-Web.עכשיו, רק נחזור לנושא של שלושת החברות - הן אמרו “בואו נקרא לזה Passkeys”: בואו נעשה, יחסית, ממשק מבחינת API אחיד,של גם . . . למה בעצם זה “שלושת השחקנים”? כי Windows ו-Android ו-iOS של Apple - זה מכסה את רוב השוקואז, אם אתה עושה אימפלמנטציה (Implementation) אחת, בתור מתכנת - אתה מקבל את כל ה-Device-ים.יש הרבה “אבל-ים”, אבל זה ה... שוב, כאילו, “Quick”.07:30 מה פתאום הם משתפים פעולה?(רן) אבל בוא נעצור פה רגע - אני זוכר שהייתה תקופה שבה בכל אחד מהחברות האלה, רצו לקבל כמה שיותר משתמשים אצלן בפלטפורמה, ובגלל זה מאוד מאוד עודדו את ה-Social Login, אוקיי. למה הפסיקו? כאילו, מה פתאום הם משתפים פעולה עכשיו?(רולי) כן, אז בעצם זה חלקים אחרים באותן חברות . . . .אבל באמת, אני חושב שאתה מעלה נקודה נכונה - בעצם, איפה זה עומד מול ה... נקרא לזה ''Social Login''?אז ככה, ה-Social Login . . . (רן) . . . . Facebook היו שם, מן הסתם . . . .(רולי) כן, Facebook המציאו את זה - והאחרים הבינו שזה דבר מאוד חזק.הכוח העיקרי . . . . יש לזה שני יתרונות לספק - ל-Facebook או ל-Google או ל-Twitter או מי שזה לא יהיה . . .1 - זה ה-Affinity ל-Brand והקשר שלךכי בעצם, אם עכשיו אני נוטש את Facebook או סוגר את ה-Account, אז אני לא אוכל להיכנס לכל האתרים שנכנסתי אליהםאז יותר סביר שאני אשמור, שאני לא . . . שאני אשאר עם Facebook, יהיה לי יותר קשה לעזוב אותו.והדבר השני זה Data - אם אתה עושה היום Log-in ב-Facebook, כ-End-User, עכשיו Facebook יודעים, . . . .בוא נגיד באתר Travel כלשהו - טיסותאז Facebook יודעים שעכשיו אתה מחפש טיסות - וכל החבר'ה של הטיסות עושים Re-Targeting עליך . . . .שזה אחד החסרונות לאנשים, שאתרים שמוסיפים Social Log-in לא מודעים אליו.אז זה בעצם . . . .  קודם דיברנו על Down-side שקשור . . . מהצד של המשתמש - שהם מפחדים, שמרנים וכו',אז יש גם Down-side מהצד של האתר וזה שאפשר לעשות Re-Targetבעצם, שחקני ה-Data האלה יודעים  . . . (אורי) אבל אותו דבר זה Google, נכון? היא גם חברת פרסום - והאמת שגם Apple וגם . . .(רולי) אתה צודק, נכון . . . . אז אתה מחזק את מה שאני אומר. ו-Passkeys, אם אתה שואל בעצם, לחזור לשאלה שלך - אני חושב שזה Initiative שבחברות כאלה ענקיות הוא בא במקום אחרבטוח שהיה איזשהו דיבור - אבל מצורך אחר לגמרי, שהוא יותר “Device-י כזה”הוא בא פחות מהצורך ה-Business-יאז לדעתי זה פשוט Initiatives שעלו ו . . .(אורי) אבל יכול להיות שיש פה אלמנט של . . . זה לא מדבר עם Backend? או שזה כן מדבר עם Backend, של אחת מהחברות האלה?(רולי) זה לא מדבר . . . .(אורי) זאת אומרת, זה ספציפית, API לתוך המכשיר, אין . . .(רולי) “לעשות את העולם יותר טוב” . . . .09:52 הטכנולוגיה(רן) אז בואו רגע באמת נדבר על הטכנולוגיה - איך טכנית זה עובד? אז נגיד פתחתי את הטלפון, הוא זיהה את הפנים שלי - ועכשיו אני רוצה לעשות Log-in לאיזשהו עמוד אינטרנט.(רולי) . . .  אתה כבר מגיע למוצר. אני יכול לתאר אחת את ה . . . כי במוצר יש דרכים שונות לעשות אימפלמנטציה (Implementation) של זה . . . . אני אענה שנייה על הטכנולוגיה.הטכנולוגיה היא בעצם שה-OS, ברגע שהוא מקבל את הקריאה הזאתיש קריאה של Set ויש קריאה של Getכש-Set זה אומר כמו פתיחת Account, זה פעם ראשונההוא מייצר Secret Key ו-Public Key שומר את שניהם ברמת ה-OS ונותן . . . (רן)  שזה פר... פר-אתר?(רולי) פר-אתר, כן - ונותן לך את ה-Public key.עכשיו אני יכול לשמור אותו ב-Database שלי - תסתכל על זה כמו ה-Username.בפעם הבאה שה-User חוזר . . .(אורי) “ה-User” זה המתכנת של האתר?(רולי) כן.בפעם הבאה שה-User מגיע, אני אומר לו Get - ואני אומר לו מה ה-Public Keyאני אגב לא הטכנולוג - אני איש Product, אבל אני מספיק מכיר . . . .והוא הולך, בודק ורואה שיש לו באמת ה-Public Key הזה -והולך ל-Secret Key ומייצר Signature שהוא Based על ה-Secret Key הזה - ומחזיר אותו אליי.אני לוקח את ה-Signature הזה, שהוא Time-Based כך שהוא Expired, מה שהופך אותו לעוד יותר Securedומשווה אותו עם ה-Public Key שיש ליואם אני רואה שיש Match, אני אומר אוקיי - זה ה-User שבמקור עשה את ה-Setולכן אני יודע שזה הוא - זה כמו ה-Username ו-Password.(אורי) וזה - אתה אומר שזה Time-Based, אז זה, כאילו, יישאר לאורך ה-Session?(רולי) לא . . . . ה-Session - עכשיו, אתה מחליט, בתור אתר, ברגע שאני אומר לך “זה ה-User”אתה מחליט מתי הוא To Expire את ה-Sessionאתה יכול, עד שה-Cookie ימות, אתה יכול עד שהוא סוגר את ה . . . . אתה מחליט.אבל כאילו . . . . זה יעבוד - ההשוואה הזו, שאני בודק שזה באמת כמו ה-User - זה בעצם “Password זמני”,  שטוב . . . אם אני איהיה עוד 10 דקות . . . אם למשל אני אקח את הדבר הזה והקשבתי ואני אנסה, אחרי שהבנאדם הלך, לעשות עוד פעם אות’נטיקציה (Authentication) - זה כבר לא יעבוד.ורק עוד משהו קטן, כי זה גם מתקשר למשהו שאולי נגיע אליו, בהקשר של דיסנטרליזציה (Decentralization) של Identity ו-Self-Sovereign Identity, שזה קונספט מדהים, שלדעתי העולם הולך אליו והוא מרתק.תחשוב על זה שבעצם הסיסמא הזו, שאמרתי שאנחנו מקבלים - ה-Signature - הוא גם Per-  . . . לא רק שהוא Time-Based - הוא פר-אתר.אז תחשוב שזה כמו ש . . . טוב, האמת שנגיע לזה כשנגיע ל-Self-Sovereign Identity . . . (אורי) אבל זה בעצם Owned ב-Device - במערכת-הפעלה של ה-Device. . .  עכשיו אני ב-Facebook . . . .(רולי) מה קורה כשעוברים Device?(אורי) לא, יש לך Facebook וכמה Device-ים, או לא יודע . . . . עכשיו, בוא . . .(רולי) נכון, כן . . .  נגיד, פתחתי Account, אתה אומר בטלפון, פתחתי חשבון באתר בטלפון - ועכשיו אני הולך למחשב. איך אני יכול לעשות Log-in?אוקיי, אז עכשיו אנחנו מגיעים ל . . . . בוא נגיד, אני אתן קודם את התשובה הפשוטה:אם זה באותו Ecosystem - לכאורה גם שם זה לא בדיוק . . . .לפחות ב-Apple, אם אתה מחובר עם שניהם ל-iCloud - זה יעבוד.כי ה-Keys נמצאים ב-iCloud,  ואז הוא בודק ש . . .(רן) ה-Private Keys . . .(רולי) כן, וגם ה-Public Keys . . .  אבל קודם כל - אתה גם צריך לעבוד עם Safari - ומה קורה אם אתה עם Chrome? . . .  אני למשל עם Chrome עם ה-Mac, שלא לדבר על PC . . . או שלא נדבר על המחשב של . . .  לא יודע מה - של בת-הזוג שלי, או של חבר שלי, או Public Device, או ה-iPad-של-המשפחה-שמסתובב-בבית . . . .(אורי) “אינטרנט קפה”! זוכרים את הדבר הזה? . . . .(רולי) נכון! לא יודע, יש כזה עוד? בניו יורק, הענקיים כאלה . . . .אז נכון - אז זה צריך לעבוד בכל הסיטואציות האלה . . . . ומה עם Device שאין לו ביומטרי?אז עוד רגע נדבר על כל הסיטואציות האלה ומה . . . . למה בעצם אולי כדאי לעבוד עם איזשהו Vendor שנותן פתרון מלא.13:53 הפתרון ה-Product-יאבל אולי עכשיו אני יכול, אם אתה רוצה, להגיד את הפתרון ה-Product-י, שזה אומר, מה ה-Flow? איך זה נראה?(רן) בוא רגע נבין מה יש לנו פה . . . . אז אם מקודם נגיד, דיברנו על Scenario של Social Login - שנגיד הייתי Logged-in דרך Facebook או Twitter או Google, שגם, לצורך העניין, גם היה יכול להיחשב ל-Social Login - הם היו יודעים עליי המון דברים, אוקיי? . . . היו, בגדול . . .  כל מה ש-Google יודעים עליי, כל מה ש-Facebook יודעים עליי - גם הם יודעים.פה, ב-Scenario הזה, כל מה שהם יודעים עליי, זה איזשהו Public-Key, נכון? איזשהו רצף-בינרי של מספרים . . . .(רולי) “השחקן הגדול” - “ה-Google”? אפילו את זה הוא לא יודע . . . (רן) אוקיי, אז האתר . . . .(רולי) האתר מקבל רק Public-Key, כן.(רן) אז האתר מקבל איזשהו Public-Key, והוא לא יודע עליי שום דבר חוץ מזה, אוקיי? . . . .(רולי) נכון.(רן)  . . . . הדבר היחיד, שאולי תיכף נגיע אליו, זה שאם עשיתי Log-in מ-Device אחר, אז הוא יראה את אותו Public-Key והוא יבין שזה אותו המשתמש - אבל עדיין, הוא לא ידע עליי כלום: הוא לא יודע מה ה-email שלי, מה שמי - אלא אם כן בחרתי לתת להם אותו . . . .(רולי) נכון.עכשיו באמת - זה מוביל אותי לאימפלמנטציה (Implementation) של הטכנולוגיהכי בסופו של דבר, רוב האימפלמנטציות (Implementations) הן בדרך שהוא כן יודע את כל הדברים האלה, אחרת . . . . כי מה שהם עשו - Google כבר עשו אימפלמנטציה של זה, אתה היום יכול לגשת ל-Google Account שלך ולהוסיף Passkeysגם TikTok עשו את זה ואחרים . . .ומה שה . . . האימפלמנטציה היא שאתה קודם כל פותח חשבון בדרך הכי רגילה שישנותן את כל האינפורמציה על עצמך, ממציא Password . . . ואז אתה יכול או ללכת ל-My Account ולהוסיף את Passkeys כ-”Another Authentication Option”ואתה צריך בשביל זה להיות Logged-In.או שיש כאלה שעושים שאחרי שאתה עושה Log-In, הם שואלים אותך “האם אתה רוצה להוסיף Passkeys, כעוד דרך לאות’נטיקציה (Another Authentication Option).בעצם, הם די מחקים את ה-Experience שקיים ב-Nativeמה שאמרנו - שהוא פשוט לוקח את הסיסמא, מצפין אותה, ועם ה-Face ID מוציא אותה החוצה.אני יכול להגיד למה הם עושים את זה - כי זה פותר את כל השאלות שהרגע אתה אמרת . . . .זאת אומרת - כשהוא עובר Device, אז מקסימום מכניס סיסמה, וזה פותר . . . .ברגע שיש סיסמה, זה פותר את כל ה-Edge Cases . . . (רן) . . . אבל זה גם יצר בעיה של סיסמא - הנה, עכשיו צריך לזכור סיסמא, ולאבטח אותה . . . .(רולי) אבל (א) - אין סיסמה, עדיין . . . . וגם מבחינת Security . . . .הבעיה העיקרית של סיסמא זה שאנשים משתמשים באותן סיסמאות על פני הרבה אתריםואם פרצו לאתר וגנבו את ה-Username וה-Password - הפורץ עכשיו עובר אתר-אתר ומנסה את זה עד שהוא מצליח . . . אז כל עוד אפשר לעשות אות’נטיקציה (Authentication) עם סיסמא, עדיין לא פתרת את הבעיה.והדבר השני . . . .(רן) לגנוב אצבע זה יותר קשה . . . . לא שזה בלתי אפשרי, אבל זה . . . (רולי) גם לא עושים את זה  . . . . כי 90% מהפריצות זה כזה “Cross” - כשהם רצים עם רשימות של . . .  או שהם עוד משתמשים באותן סיסמאות, או כרטיסי אשראי וכאלה . . . .אבל הבעיה השנייה, זה שאחוז מזערי . . . . בעצם ברגע שה-Flow הוא כמו שאני תיארתי, שאתה עוד צריך ללכת ל-”My Account” בשביל זה . . . ומה זה Passkeys? אף אחד לא משתמש בזה . . . .אז אנחנו פשוט נצטרך . . . . אם תרצה, אנחנו נוכל לדבר על למה אנחנו עושים פתרון, שהוא לוקח את הטכנולוגיה הזאת - עד הסוף.ועושה שינוי, כאילו, באמת . . . 17:02 הלקוחות העיקריים(רן) כן, אז למעשה אתם - ב-OwnID - על מי אתם מקילים - על ה-Vendor-ים?, על בעלי אתרים? על המשתמשים? זאת אומרת, מי הלקוח העיקרי שלכם שם?(רולי) הלקוחות שלנו  . . . אגב, אנחנו עובדים רק עם חברות גדולות, זה ה-Business Model שלנו.יש לנו את Carnival Cruise ו-Nestlé ו-Bayer, שזה ענק תרופותואסותא בארץ, ו-Carrefour . . . . יש לנו הרבה לקוחות גדולים. והם משלמים לנו בשביל להוסיף - זה לא רק Passkeys - להוסיף ולהפוך גם את תהליך ה-Registration וגם ה-Log-in שלהם ל-Frictionless.וברגע שהם . . .  אני סתם אתן לך דוגמא - אנחנו בכלל לא מזכירים ב-User Experience . . .  הם מוסיפים אותנו לטפסים הקיימים שלהם, כעוד אופציה.אנחנו פשוט מראים כפתור שתלוי ב-Device - הוא מראה לך “Log-In with Face ID” או Log-In with” “Touch  ID, או מה שה-Device הזה מסוגל.ואנחנו . . . עוד פעם, אני לא יודע עד כמה אנחנו רוצים להיכנס לפרטים, אבל ה-User יכול לפתוח Account בלי להמציא סיסמאואחרי זה, אם הוא הולך ל-Device אחר, אנחנו נעשה אות’נטיקציה (Authentication) רק של ה-Device.או למשל נשלח לו רק One-Time Code, רק לאותו Device, ואז נחבר את ה-Device לאותו Account.ובאמת, מעל ל-50% מהמשתמשים של האתרים שהוסיפו אותנו - ככה עושים היום אות’נטיקציה (Authentication)במקום 2% או 3% ב-Passkeys “הרגיל”.(רן) הבנתי, כלומר אתם בעצם עוזרים “לכסות את החורים”, שעדיין קיימים בשיטה הזו . . . (רולי) . . . . כי יש הרבה חורים . . . (רן) . . . עם מינימום חשיפה. זאת אומרת, אתה יודע - לשלוח איזשהו One-Time Password זה איזושהי חשיפה, אבל היא מינימלית, לא צריך לעשות את זה כל פעם, צריך לעשות את זה רק פעם אחת, כשאתה עובר Device.(רולי) בדיוק.(רן) אוקיי, ואז למעשה, בכל Device קיים Private/Public Keys שונים, או שהם אחודים?(רולי) הם שונים . . . . (אורי) הם שונים - אבל ל-Account יכולים להיות כמה Passkeys.(רולי) נכון, לגמרי.ויש, אגב, עוד Scenario-אים - אנחנו דיברנו על ה-One-Time Code בשביל . . . . אני אתן לך סתם דוגמא - אם אתה הולך למחשב, שאתה לא רוצה עכשיו לקשר אותו ל-Account - של חבר שלך . . .אז איך תעשה עכשיו . . . איך תתחבר - אם אין Password? אתה לא רוצה עכשיו לעשות את ה-Passkeys שלו . . . אז אנחנו מציגים QR Code - ועם הטלפון שלך, בהנחה שיש לך טלפון, אתה סורק אותוהוא עושה Face ID - ואז אתר במחשב, או במה שאתה רוצה, שם הוא מתחבר.19:24 רגע . . . Lock-In?(רן) האם המודל הזה לא מייצר איזשהו Lock-In ל-Vendor-ים הגדולים? זאת אומרת, עכשיו כשיש לי iPhone, אני לא רוצה לעבור ל-Android, כי כל ה-Passkeys שלי נמצאים עכשיו ב-iPhone  . . . .וזה לא רק להתקין מערכת הפעלה חדשה ולהתרגל לממשק שונה - זה גם להתחיל לייצר Log-In-ים חדשים לכל האפליקציות . . . .(אורי) רן, ה-Lock-In הזה קיים . . . [הוא איתנו בחדר, עכשיו?]. ה-Lock-In הזה קיים בכל מקרה, אז . . . .(רן) אני עשיתי לעצמי מסורת - בכל פעם כשאני קונה טלפון, אני עובר Vendor . . . (רולי) באמת?  (רן) כן, פעמיים כבר . . . .(רולי) אז אני עוד לא עברתי . . . . כל הכבוד.(אורי) אז הנה, יש Feature בשביל רן - הוא הבנאדם היחיד שעושה את זה . . . (רן) הנה - מצאת לקוח!אז עכשיו באופן כללי, האם זה מייצר איזשהו Lock-in? גם שלי, בתור משתמש, ואולי גם של בעלי האתרים עצמם - של אסותא שהזכרת וכו'? זאת אומרת, אולי הם “שמים יותר מדי ביצים באותו מקום” . . . זאת אומרת, זה לא חשש?(רולי) אז אני חושב שזה חוזר למה שאמרתי לפני רגע - שאם אתה עושה את האימפלמנטציה (Implementation) הבסיסית, אז זה באמת Device-Specificאו שיש Password - ואז זה You're Lockedואם תיקח פתרון כמו שאנחנו נותנים, שהוא הוליסטי - אז אתה לא . . . אנחנו עושים וריפיקציה (Verification) ל-Device החדש - והוא יעבוד לך.(רן) הבנתי, אז זאת אומרת שאתם עובדים גם בין Vendor-ים שונים?(רולי) כן, בדיוק.(רן) אוקיי . . . . הרשתות החברתיות נכנסות לזה? או שזאת ממש רק חומרה, רק Device-ים?(רולי) לא, רק ברמת החומרה, כן . . . .ואם אתה רוצה, אני יכול לגשת ללאן שזה הולך, ללמה זה הולך להיות עוד יותר מדליק . . . .20:55 אז לאן זה הולך?(רן) כן, אז אני חושב בערך הבנו את הפתרון ברמה הטכנית, הבנו גם קצת מוטיבציה ללמה לעשות את זה, דיברנו גם על Security, גם על “עייפות” של המשתמשים מהצורך לבוא ולהירשם בכל פעם. גם על הסכנות של לתת את האינפורמציה שלך לרשתות החברתיות, ומה שהן עושות עם זה אחר כך - וגם על ה-Down-side של זה לאתרים עצמם: חיפשת טיסה ועכשיו תהיה מופגז בכל המתחרים . . . .אז לאן זה הולך?(רולי) אוקיי, אז מה שאנחנו רואים כאן זה הסרה של . . .  נקרא לזה Friction, בעניין של אות’נטיקציה (Authentication), וכל הקונספט של Registration ו-Log-In הם, איך שאני או אנחנו תופסים אותם, הם מאוד מיושנים. הם . . . .אנשים לא אוהבים לעבור אותם, אנשים רק מוכנים להזדהות - אבל הם לא מוכנים עכשיו להוציא את כל הזמן על למלא טפסים ולזכור סיסמאות ולמלא אותן . . . ואני מאמין שבתוך בוא נגיד “שנתיים”, כשזה יהפוך להיות סטנדרט,  לא יהיה יותר כזה דבר Registration ו-Log-In.הבנאדם, קודם כל, במקום שרק 5%-10% מהמשתמשים יהיו מזוהים, לדעתי זה יגיע לרמה של 90% עד 100%כי זה יהיה ב-One Click - פשוט, אתה תגיע לאתר ב-One Clickוזה גם יחליף את ה-Cookies - כי היום יש גם בעיה של Cookies, בגלל שה-Cookie מת וה-Browser-ים הורגים אותו, אז האתרים לא יכולים אפילו להמשיך לתת לך Consistent Experienceכי אחרי שבוע, למשל ב-Safari, ה-Cookie נמחק . . . אז אתה תיכנס לאתר, תעשה Face ID -בעשירית שנייה - ואז אתה מקבל  . . .  אתה מזוהה, אתה עובר חוויה . . . עוד רגע, אני אדבר על ה-Data שקשור ל-Registration, אבל תקבל חוויה קונסיסטנטית (Consistent), לא תצטרך לעבור איזשהו תהליך אפילו, של זיהוי מעבר לזה.ובנושא של ה-Data, כי בעצם יש פה אות’נטיקציה (Authentication) ב-Registration ואיסוף של אינפורמציה.האיסוף של האינפורמציה יתבצע לא כחלק מהקונספט הזה שנקרא “Registration” - אלא On Demand, מתי שצריך אותו.ואז גם אנשים יתנו את זה - אתה עכשיו הזמנת את המשלוח בשופרסל, אז כשאתה מגיע לשלב של ה-Shipping, אז אתה מזין את הכתובת - ומאותו רגע הוא משויך אליך כבר.ואין כזה דבר “Guest Checkout”   . . . . וכל ה-Concept-ים האלה, אני חושב, יעברו מהעולם.(רן) אז זאת אומרת שה-Benefit  המשמעותי לבעלי האתרים זה שאם עד עכשיו אחוזי הרישום היו באזור ה-10%, הזכרת מספר כזה של איזשהו Benchmark עולמי, אז ההערכה שלך שזה יהיה באזור ה-90%.דרך אגב - על מה זה נשען? זאת אומרת, יש כבר נתוני זמן-אמת לסיפור הזה? זאת אומרת, יש. . .(רולי) אז תראה, אני, מה שנכון להיום, זה שהלקוחות שלנו מוסיפים אותנו לטפסים הקיימיםהם עוד לא עשו את ה . . . עכשיו אנחנו מתחילים לדבר עם חברה, אחת מאלה שהזכרתי, ממש מהגדולות.לעשות את ה-Transition לדרך שאני תיארתי.אבל עדיין זה עוד לא קורה, אז אין לי עוד מספרים להגיד - אבל אני מאוד מאמין בזה.(רן) אוקיי, אז אתה רואה בזה הזדמנות לבעלי אתרים בעצם, להגדיל את ה-Engagement - זאת אומרת, גם להקל על ה-Onboarding, אבל גם לייצר לקוחות שהם “כבר בפנים”, שהם “רשומים”. לא יודע אם “רשומים” זאת המילה הנכונה בהקשר הזה - אבל לקוחות שהם מזוהים.(רולי) כן, יש את האנלוגיה של בנאדם שהולך למכולת השכונתית, והמוכר כבר מכיר אותו, ואומר “אה, הגיע הדבר הזה, שתמיד אתה מחפש ולא היה לי כבר חודשיים . . . .”.(רולי) זאת אומרת, ה-Relationship - וזה הבסיס, אני חושב, גם לחברה הקודמת וגם לחברה הזו שלי, שבין Consumers לבין Business, הוא הופך להיות דבר שהוא מאוד חשוב.אני חושב, שאם פעם המסר היה, שמבחינת הראייה העסקית הכל היה צריך להיות Easy, Simple - אז היום זה הופך ל-Trust, עם השינוי התרבותי שהעולם עובר.יש אובדן של אמון - ואני חושב שלקוחות יעבדו עם החברות שהם סומכים עליהן ושיש להם יחסים איתןולא בגלל שה-Experience טיפה יותר נחמד.25:06 כשזה קל, אז אתה לא שם לב(אורי) אני מכניס פה חשש לשיחה, בסדר? בעיקר כי אני מגיע מעולם הפרסום, ולא, זאת אומרת . . . . דווקא מהעולם שהוא Open Web - האימפלמנטיה (Implementation), שהיא מאוד קלה ופשוטה לעשות אות’נטיקציה (Authentication), יכולה פתאום לפתוח מקומות שלא היינו רגילים לעשות בהם אות’נטיקציה . . . .פתאום זה נהיה קל - אז עושים! . . . . אז פתאום, לא יודע מה - ל-Ynet יש את המזהה שלך, מה שהיום לא היה להם מזהה, עד היום . . . .(רולי) נכון . . . .(אורי) ופתאום זה נהיה “קל” - אולי הם צריכים פעם אחת לבקש ממך את המזהה הזה, וזהו - מעכשיו זה קל.(רולי) אתה מדבר גם על מה שנקרא PII בהקשר הזה, או בלי PII?(אורי) לא - לצורך העניין, לשחקני הOpen Web, ואני לא מדבר על Facebook, או כל האתרים, או האפליקציות שאתה נרשם אליהן, כולל Amazon. אני מדבר על אתרי-תוכן לצורך העניין, או אפילו eCommerce - שאתה נכנס בלי כוונה לקנות, אתה לא צריך לעשות Log-In . . . . החוויה הייתה אנונימית - וככה גם הפרטים האלה לא היו עוברים לרשתות הפרסום, שעומדות מאחורי האתרים האלה.(רולי) חוץ מתקופה שהיו Cookies . . . . זאת אומרת, לא הפרטים עוברים, אבל . . .  אז זה ש”המשתמש הזה, עכשיו, קרא את כתבה הזאת”, היא החברה השלישית . . . (אורי) נכון, ולכן . . . .(רולי) . . . . הרגו את ה-Cookies . . . .(אורי)  . . . ולכן הולכים ליותר ויותר 3rd-Party Cookies  שהולכים, וכל זה כאלה  . . . (רן) בעצם אורי, אתה אומר שאם לפני זה מעט אתרים ידעו עליי הרבה - אז בעתיד הרבה אתרים ידעו עליי מעט . . . אבל זו רמת הסיכון, אולי, מבחינת המשתמש, רמת הסיכון של Privacy.(אורי) זה לא כזה משנה אם זה מעט הרבה או הרבה מעט, אבל האם עכשיו . . . .  לא יודע מה, New York Times רוצים ממך שתעשה Log-In, כי אתה משלם גם עבור ה-Log-In הזה, וזה אחלה . . . . אפילו “הארץ”, אותו הדבר.אבל Ynet, לצורך העניין, לא מבקש ממך Log-In - ואם הוא יתחיל לבקש ממך Log-In, זה יהיה מסובך . . . . אוקיי, זה להכניס את ה-email שלי ואת ה . . . (רולי) אז הם לא יבקשו . . . . אם זה יהיה מסובך, אז הם כנראה לא יבקשו . . . .(אורי) עכשיו, כשמתחילים להכניס מנגנון, שהוא קל . . . .(רולי) . . . . אז אולי הם כן יעשו את זה - אני מסכים איתך, אבל אני אומר . . . .(אורי) . . . . אז אולי כן יעשו את זה - ותיפגע הפרטיות, כי כשזה קל, אז אתה לא שם לב . . . (רולי) אז קודם כל - חלקית אני מסכים איתך   . . . אני משווה את זה פשוט ל-Cookie - זה בעצם כמו להחזיר את ה-Cookie, או 1st-Party-Cookie אגב - לא 3rd-Party, בגלל שהם לא יכולים להגיד עכשיו, בניגוד ל-3rd-Party-Cookie, שעכשיו כמה אתרים יכולים לדעת על אותו משתמש דבריםפה, כיוון שה-Key הוא פר-אתר, אז Ynet לא יכולים להגיד לאתרים אחרים “הוא היה בכתבה הזאת” - כי האתרים האחרים, אין להם גישה ל-Public Key שלו . . . .אבל זה כן כמו 1st-Party-Cookie - זאת אומרת ש-Ynet יוכלו לדעת שזה אתהם חזרת אחרי חצי שנה לאתר - הם יידעו שזה אותו בנאדםהם לא יידעו את השם אם הם לא ביקשו את השםוזה כמו Cookie שהוא נשאר לנצח . . . (אורי)  זה שווה שווה (==) ל-Email Address . . . .(רולי) לא, רק שזה לא Identifiable Information - זאת אומרת, הם לא יכולים . . . .(אורי) זה כן - זה המכשיר בסוף . . . .(רולי) נכון, אבל אפשר . . . .(אורי) סליחה - זה אתה, על המכשיר . . . (רולי) נכון, אבל הם לא יכולים . . . . הם רק יכולים לתת לך חוויה קונסיסטנטית (Consistent), הם לא יכולים לעשות מעבר לזה שום דבר . . . .ורק להוסיף עוד דבר אחד, שזה . . . . אבל אני חצי-מסכים איתך - אמרתי בהתחלה, שזה עם Consentזאת אומרת, אם Cookie, איך שאני רואה את זה, זה בעצם, ב-Scenario שאתה מתאר, זה מחליף את ה-1st-Party-Cookie -  עם Consent.זאת אומרת, זה לא יעבוד . . . . הרי ה-Face ID לא יעבוד אם אני לא יעשה Face ID  . . . .הוא גם שואל אותך - הוא עושה Prompt, אתה יכול לעשות Face ID - כן?זאת אומרת שיש פה איזשהו Consent.אני מסכים איתך שהרבה מהאנשים פשוט עושים מה שאומרים להם - אז זה לא רלוונטי אם יש Consent או אין . . . אבל ב-Cookie לא היה Consent - וזה עשה בדיוק אותו דברהם היו שמים עליך Cookie - ועכשיו כל החיים יודעים שאתה זה אתה.וזה האלטרנטיבה, זה “החדש”.(אורי) עד כדי ''חיים של Cookie'', שזה . . . להבדיל מזה, זה חיים . . . (רולי) נכון, זה חיים . . . כן, זה על ה-Device ו-”Forever''.(רן) דרך אגב, מה קורה אתה מאבד את  ה-Device? כאילו, עשית Log-In לאיזה חמישה אתרים ואיבדת אותו?(רולי) אז אתה עושה Log-In עוד פעם . . . . תצטרך, ב-Device החדש.אז אנחנו חוזרים לפתרון, לדעתי השבור, שקיים בשוק, וזה . . .  שהוא לא שלנו . . . כי שם באמת אתה צריך עכשיו עם סיסמה או . . .  אתה צריך איכשהו לפתור את זה.ועם שלנו אנחנו פשוט ישר בודקים - אנחנו אפילו לא כותבים לך “Error'', אנחנו אומרים לך “אני מזהה שזה מכשיר חדש, אני שולח לך קוד, תכניס אותו” . . . . מהמכשיר.(רן) אה, יש לך את ה-email, אז ככה אתה שולח . . . .(רולי) כן.(רן) אוקיי, אז ה-Hook שלך זה ה-email, זאת אומרת . . . .(רולי) כן, כן, עדיין.30:55 טביעות-אצבעות רגליים?(רן)  אוקיי . . . מבחינה טכנולוגית, האם יש איזושהי אי-בשלות? זאת אומרת, אם נגיד, אני עכשיו רוצה להכניס את זה עכשיו לאתר, האם יש דברים שעדיין צריך להיזהר מהם, שלא הזכרת לפני זה?זאת אומרת, כן - אמרת שיש כל מיני “קצוות לא תפורים” שאתם, או אולי גם חברות אחרות, יכולים לפתור, אבל האם יש, קטגורית, עדיין אזורים שבהם לא יהיה נכון להשתמש ב-Passkeys?(רולי) לא הייתי אומר “איזורים שהם לא נכונים” . . . . אני כן הייתי אומר שאתה צריך לחשוב על Use Cases, מי . . .אז ככה - מסתבר שיש אנשים שמפחדים לעשות, שהם לא עושים Enabling ל-Biometrics על ה-Device שלהםכי הם חוששים שה-Data יעבור לאתרים, או לאפליקציות, או ל-Apple או למי שזה לא יהיה.והם פשוט לא מוכנים לעשות שום סריקה ביומטרית - אז אתה צריך אלטרנטיבה לזה.(רן) זה חייב להיות Biometrics? זאת אומרת . . . (רולי) לא, אבל בדרך כלל זה פשוט הופך להיות הסטנדרט, כי זה כל כך קל וכל כך Secured.אבל יש אנשים שעדיין מפחדים מזה.(רן) אז בכל פעם כשאני פותח את ה-Laptop שלי, אני מקליד סיסמה . . . .(רולי) נכון.(רן) אני יכול לשים את האצבע, אבל . . . .(רולי) בקרוב זה  . . . .  אנחנו רואים - הDevice-ים היותר מודרניים עוברים ל-Biometricsכי Biometrics זה באמת זה יותר קל ויותר Securedואין לו בעיית Privacy, כי ה-Data - אנחנו כולנו יודעים, אנשים טכניים יודעים שה-Data הביומטרי לא עוזב את המכשירים, אצל החברות הגדולות, שאנחנו מכירים.(אורי) לאחרונה שמעתי על סקטור של אנשים שלא יכול להשתמש ב-Biometrics, בטביעות אצבעות - וזה מטפסים . . .(רולי) וואלה . . . (אורי) . . .   הם - נשחקות להם הטביעות-אצבע . . .(רן) מה לגבי הרגליים?(רולי) . . . מעניין לנסות פעם לעשות סריקה עם הרגל . . . (רן) אבל דרך אגב - אמרת מקודם שאם אני משתמש על Apple, אז כן יש אינפורמציה שנמצאת ב-iCloud . . .(רולי) נכון - אבל היא מוצפנת, ו-Apple לא יגשו אליה . . . .זה כמו מה שיש לך ב-Google Drive - אז Google לא ניגשת לזה.(רן) אוקיי, אז יש פה איזשהו Leap-of-Faith . . .  אבל בסדר.(רולי) אני חושב שהחברות האלה - יש להן כל כך הרבה מה להפסיד, שאין להן סיבה להונות את הלקוחות שלהןכי הן יכולות להתרסק, חברות של Trillions of Dollars . . . (רן) כן, אבל טעויות יכולות לקרות . . . . אני לא חושב שיש להן סיבה, אבל טעויות יכולות לקרות, נכון?(רולי) נכון.(רן) כמו . . . עיין-ערך “המאגר הביומטרי” בישראל [הי ברזיק . . . ] - אני לא אומר שזה לא משנה שאין סיבה לבוא ולהדליף אותו, אבל טעויות יכולות לקרות.(רולי) לא רק זה - זה גם גורם-סיכון, זו נקודת-תורפה.(אורי) במיוחד כשיש ממשלות שעושות טעויות . . . .(רן) לא, לא אצלנו, לא בבית ספרנו . . . . בסדר, בסדר, אז אנחנו כבר עברנו . . . .(אורי) אמרה שרת החוץ הלובית, לא . . . (רולי) לשעבר . . . .(רן) הרבה זמן לא הייתה פוליטיקה פה, איזה כיף . . . .33:55 קצת על Mobile, קרדיטים - ופסוקו של יום(רן) אז כן, אז אנחנו ממש ככה לקראת סיום. אז הבנו בגדול איך זה נראה - למעשה, אם אני היום מפתח אפליקצית-Web, אז להבנתי, אין סיבה שלא לאפשר את זה - לפחות כאופציה, אולי אפילו אופציה-יחידה, אם אני, ככה, ממש “הרפתקן”.דרך אגב, איפה זה פוגש אותנו ב-Mobile? זאת אומרת, יש . . . ב-Mobile אני יכול לקבל חוויה זהה?(רולי) לגמרי . . . (רן) גם עם Passkeys?(רולי) כן, לגמרי.(רן) בסדר, אז כמה מילות סיכום - אולי קצת עוד כמה מילים, ככה, על החברה שלך - איפה אתם בארץ, פיזית?(רולי) אנחנו ליד רוטשילד, ליד בית הכנסת הגדול . . . בעצם, כולנו Veterans של ה . . . . אספתי איתי את השותף שלי ו”הכוכבים של Gigya”אז כולנו מכירים את התחום מאוד מאוד לעומק.ובאמת - אפילו גייסנו מאותו משקיע, העיקרי, שהשקיע ב-Gigya, אז זה היה צ'יק-צ'אק.וכן - אנחנו בעצם שמחים, עובדים בכמה . . . מתחילים לדבר גם בארץ עם חברות גדולות, ונשמח  . . . . בעיקר חברות-הטכנולוגיה שרוצות להיכנס לזה, ורוצות פתרון הוליסטי, מודרני, לאות’נטיקציה (Authentication)שידברו איתי, רולי - rooly-at-ownid.com.(אורי) אהבתי את הרפרנס לבית הכנסת הגדול . . . . אתם עושים עושים ביומטרי עם האצבע הזאת, שקוראת ב . . . (רולי) גדול . . . (אורי) האצבע של “פסוקו” . . . (רן) עכשיו צריך את המוזיקה של “פסוקו של יום” [רן אשכרה הוסיף . . . .]יאללה - יש לנו סגיר . . . תודה רבה, רולי! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 466 של רברס עם פלטפורמה, שהוקלט ב-22 באוגוסט (אוטוטו נגמר החופש הגדול?).אורי ורן שמחים ומתכבדים לארח באולפן את איתמר מחברת Codium כדי לדבר לדבר על AI (ועוד כל מיני Buzzwords, אבל במידה . . . ) ועל מוצר מדליק שחברת Codium מפתחת - אבל בעיקר על האתגרים הטכנולוגיים המעניינים שמאחורי הפיתוח של המוצר הזה, ועל למה זה צריך לעניין מפתחים, כי זה גם מוצר למפתחים. אז יש פה הרבה שאלות של איך לשלב Machine Learning ו-AI במוצרי תוכנה, וזה נושא שהוא די כללי ומעניין להרבה מאוד מהמאזינים.01:38 כמה מילים על איתמר(רן) אז לפני שנצלול פנימה - כמה מילים עליך, איתמר?(איתמר) אז קודם כל, אני אגיד שפעם הייתי שומע את המילים “AI” - וזה היה קצת מבהיל אותי להגיד את המילים האלה.היום זה יותר רגיל - כשאמרת את זה כל כך הרבה פעמים, אז חשבתי על זה, שהיום אני כבר בסדר עם זה.אז: איתמר פרידמן - נשוי פלוס 2.5, גר ברמת גן.(רן) אתה צוחק . . . (איתמר) כן, אני יודע . . . הייתי פעמיים CTO של VC-Backed Startupsאת החברה האחרונה שהיתה לי Alibaba קנתה, והיה לי את התענוג להתחיל את המרכז פיתוח של Alibaba בארץ [עד כאן], ביחד עם השותפים והשותפות. זה היה מסע מלמד ומרתק ב-Alibaba.אחרי ארבע שנים עזבתי - ואחרי חצי שנה של מנוחה ו-Ideation, ביולי 22 פתחתי את Codium.ai, ביחד עם השותף שלי, דדי קרדו, שהיה עובד הראשון שלי, אי-פעם לפני 25 שנה . . .וזהו - מאז עברה שנה, אנחנו 20 . . . זה קצת על עצמי - יש לי M.Sc. ו-B.Sc. מהטכניון, בתחום של Machine Learningוהעבודה הראשונה שלי אי פעם היתה מפתח Web בשנות ה-90'.(רן) ASP?(איתמר) זה היה PHP . . . (אורי) משהו עם “P” . . .(רן) כן, משהו עם “P” . . . מעולה, יופי, אז אחלה רקע - ובוא רגע נדבר קצת על מה זה Codium, ואחר כך “נעלה למעלה” ונדבר קצת יותר, . . .  בצורה יותר גנרית - מה המשמעות של לפתח מוצר שמכיל AI.אני מודה שגם כשאני הייתי בלימודים בטכניון, “AI” זה היה מיני סוג של דבר כזה שאף אחד לא מעיז להתקרב אליו, כי הבינו שזה לא יעבוד . . . . אז הנה - העולם השתנה לנו.נדבר אחר כך גם על מה האתגרים ואיך אפשר בעצם לשלב AI ו-Machine Learning בצורה מוצלחת בתוך מוצרי תוכנה.03:25 ו-Codium  . . .(רן) אז כמה היו מילים על Codium, לפני זה?(איתמר) אני אספר - אבל פשוט פה אני עושה לך, לא נלך על השאלה ישר . . . אז הסיבה שאני, אגב, קצת היה לי קשה להגיד “AI”, זה כי הרגשתי שזו מילה “שיווקית” מדי, למה שזה - Machine Learning.אבל אני כן מרגיש שלאחרונה כן יש כבר את ה”ניצוצות של האינטליגנציה” ומעבר ליכולת הבסיסיותשכן אני מרגיש קצת יותר בסדר להגיד עם זה.אז קודם כל, אני אציג את זה בשתי דרכים - אחת קצת יותר “עסיסית” ואז טיפה יותר טכנית.אז בצורה “העסיסית”, זה בעצם “יושב לידך” בתוך ה-IDE“מפתחת Mid-Seniority”, שמתמחה בבדיקתיות (Testability) של קוד ובלאתגר ובלעשות Reviewולוודא שהקוד שנכתב הוא ב-High Quality - ובדגש על ה-Functional, “שזה עומד ב-Spec”.אני פה עומד ליד הלוח, ורואה שכתוב פה קוד “Quick & Dirty or Detailed spec” - והמטרה של Codium.ai זה לוודא שהקוד מתאים ל-Spec, בין אם הוא Detailed או לא.ככה, לוודא שה-Intent - בין אם הוא רשום בצורה מפורשת ובין אם הוא נמצא כרגע בראש של המפתח או המפתחת שמשתמשת ב-Codium.ai - עומד בציפיות.זה ככה הדרך היותר עסיסית.טיפה יותר טכני - אז  it's an AI Coding-assistant, that's focused on generating tests, on verifying that high quality, etc. . . . (אורי) אז זה “Pair-Programming - שחוסך כיסא”?(איתמר) זה Pair-Programming שעושה את העבודה הזאת, שרוב המפתחים שונאים לעשות . . . .בואו ניקח לדוגמא Testing, שזה אחד הדברים העיקריים שאנחנו עושים,אנחנו עושים, אגב, Component ו-Unit Testing, ו-Automation, Regression.אז או שאתה שונא לעשות את זה ולכן אתה לא עושה את זה - או שאתה עושה את זה ועדיין שונא את זה . . . זה 95% . . . יש את הקיצוניים האלה, יש את ה-5% . . . (רן) תמיד יש מאזין אחד שמאוד אוהב לכתוב Test-ים - אז לא מדברים עליך . . . (איתמר) אז לכן הסתייגתי מיד בסוף, יש את ה-5% - והם רובם אצלנו בחברה, לקחנו אותם . . . (רן) או Freelancers אצלכם . . . (איתמר) אז “אנחנו באים פה להפיץ אהבה”, ולקחת - לא בדיוק “לקחת כיסאות של מפתחים”, כמו “לקחת את העבודה שמפתחים ומפתחות שונאות לעשות”, שזה הבדיקתיות של הקוד (Code Testability).אתה רוצה ליצור - ופחות עכשיו “להתעסק במיש-מש” של לבדוק את הקוד.(אורי) אני לא, כאילו, התייחסתי ל . . . אתם זוכרים את Pair-Programming?(איתמר) כן, כן, אני רק . . . (אורי) . . . זה כאילו . . . “ה-”Buddy” שלך, ל-Pair-Programming” - הוא רק לא יושב על כיסא, וכשנשענים ביחד להסתכל על קטע קוד, אז לא עוברות כינים . . . .(איתמר) כנראה שיצאה לי ככה התשובה, כי אני רגיל שחלק מהשאלות הבאות, אז אני מתחיל לקבל את ה . . . .“אז רגע - אתה בא להחליף אותנו!” ו-”אתה בא לוקחת לנו את התפקיד!”ואני ככה ישר, כנראה . . . (אורי) גם Pair-Programming אנשים לא כל כך אוהבים לעשות . . . . כאילו, יש 5% שכן אוהבים לעשות . . . .(איתמר) אז נראה לי שככה יצאה לי מיד תשובה שקצת מתגוננת . . . לא - אני לא בא לקחת את התפקיד, אבל כן, ברגע ש . . . (רן) אולי רק נחליף את ה-5% שאוהבים, ובזה נסגור עניין . . . (איתמר) כן . . .06:32 איך זה נראה בתכל’ס(רן) אז לפני שאנחנו מנתקים לאיתמר את החשמל, כי הולך להחליף את כולנו - בוא רגע נבין קצת יותר לעומק [בשביל מה שכרנו Killswitch Engineer?].אז פה אנחנו מדברים על test-ים, נכון? זאת אומרת, זה לא Code Generation “גנרי”, כמו Copilot, שבטח נדבר עליו גם בהמשך - אלא ספציפית Testing, וגם דיברת קצת על Spec.איך עושים את זה?(איתמר) טסטים הוא “המנה העיקרית” - אבל כש . . . אני חושב שזו דרך מאוד טובה לבדוק קוד.אני לא מעט פעמים שומע מנהלי ומנהלות פיתוח, שבעצם הם היו מעדיפים טסטים ורבוזיים (Verbose Tests), מבחינת דוקומנטציה (Documentation)דווקא דוקומנטציה בתוך הטסטים, מאשר Documentation של קוד.כי זו בעצם “דוקומנטציה חיה” - זה כמו כזה “Executable Spec” כזה.אז באמת, Test-ים זו דרך ממש טובה לוודא נכונות של קודאבל רק רציתי להדגיש שזה כן חלק ממה שאנחנו מציעיםלמשל, אנחנו כן נותנים, לדעתי - לפחות מה שחושבים המשתמשים שלנו - שזה אחד הפתרונות היותר טובים ל-Code Explanation,שזו עוד דרך להעלות את ה-Integrity של קוד. זאת אומרת, אם יש לך Auto-Documentation - אז עכשיו אני בא להיכנס לקוד של מי? שלך - או שלי, של עצמי מלפני חודש, זה אותו הדבר . . . ואני עכשיו מקבל, בלחיצת כפתור, דוקומנטציה (Documentation) מאוד מאוד מאוד טובההיא כנראה תהיה ב-Integrity יותר גבוה משל דוקומנטציה שנכתבה בעבר, ושאולי שונתה.אז יש מגוון של דברים  - אבל באמת ה-Testing הוא החלק העיקרי.(רן) אז איך זה נראה, תכל’ס? Plug-ins בתוך ה-IDE? מה רואים? מה זה Codium? מה זה המוצר?(איתמר) מעולה, אז בואו נגיד, “המנה העיקרית”, ה-Interface העיקרי שלנו, זה IDE Extensionזה המונח הנפוץ ב-VSCodeאו Plugins ב-JetBrainsשבעצם נפתח ויושב כ-Tab נוסף - בואו נגיד “כמראה” ל-Tab שבו אתה כותב או כותבת את הקוד.אז בזמן שהקוד נכתב, בעצם נוצרים ה-Test-ים וההסברים וה . . . .ואגב - העצות לגבי הקוד, זה חלק העיקרי.אבל, אגב, זה ה-Closed-Source - אבל יש לנו גם Open Source, שאנחנו גם עושים לו Hostingשבעצם זו אפליקציה שמתחברת ל-Source Code Hosting שלךל-Platform - אם זה GitHub או GitLab או Bitbucketויותר משמשת בשלב ה-Gateway, בשלב הכניסה - ה-Merge של הקוד שלך לתוך ה-Trunk הראשי, לתוך ה-Branch הראשיאז שם היא עושה את הבדיקתיות (Testability) ואת העצות.(אורי) אז במקום Pair-Programmer  יש לך “Pair-Reviewer” . . . .(איתמר) נכון . . . . אני כן אגיד שאנחנו באים להקל על ה-Review, בעצם to streamline itמאשר, עוד פעם . . .  . . . “אני רואה שאתה עוד פעם מתגונן” . . . .  - מאשר אשכרה להחליף את הבנאדם או את ה-Reviewer.כן היינו רוצים שכשה-Reviewer מגיע לבדוק את הקוד - יש לו את העבודה הכי קלה, או הכי ממוקדתאיפה באמת כדאי למקד את ההסתכלות - ולא דווקא להחליף לחלוטין.אז זה בא לידי ביטוי בכל מיני Feature-ים שעוזרים לזה - אני לא, תגידו לי אם Too  . . . (אורי) לא, אני אוהב את הכיוון . . . יש, סתם . . . . ב-Outbrain, נתקלנו בזה לאחרונה, יש שני דברים שמאוד קשה - בטח עם צוות מפתחים גדול - לדאוג להם ולדאוג שאתה מכוסה, עם קוד חדש שאתה מעלה: זה Security ו-Privacy.אז זה כאילו “פאולים כאלה”, ש”מחכים שמישהו יעשה אותם”.והמשמעויות של שני הדברים האלה הן מאוד קשות - אתה יכול לפתוח פירצה, אתה יכול לעשות עבירת Privacy, או דברים כאלה - ואחר כך לך תדע . . . .ולפעמים גם ה-Reviewer שעובר על הקוד - הוא בעצמו, הוא לא “מומחה-Privacy”, וזו באמת מומחיות, Privacy ו-Security זו מומחיות  . . . אז אחד הדברים שעשינו - ואנחנו עובדים עליהם ומשפרים אותם - זה להשתמש ב-AI כדי לעשות את ה-Review. כאילו, יש לך “מומחה Privacy” - שהוא אוטומטי, או Privacy או Security - והוא מסתכל על הקוד שלך ואומר “עשית פאול, לא עשית פאול” . . . .(רן) זה משהו שפיתחתם בפנים?(אורי) כן . . . . כאילו - פיתחנו [.Episode A.I].(רן) לא מוצר-מדף?(אורי) לא, פיתחנו - כן. אבל צריך להבין שזה כמו “Immune system” - כרגיל: אתה מתחיל עם משהו, עם איזושהי יכולת, וכשאתה נופל - אתה משפר ומשפר. בסך הכל משפר Prompt-ים . . .(איתמר) אז אני חושב . . . אני רושם את זה לקחת לנושא אחר . . . .אגב, אני חושב שאם אתם תשימו על זה את הקשב שלכם ואת המאמץ, אז כנראה שאתם יכולים לעשות את זה.זאת אומרת - מה קרה? למה שאנחנו, חוץ מזה שיאמנו מודלים ואנחנו מתמחים בתחום וכדומה, “באים מהליבה”אבל זה עדיין - כאילו, בסוף מישהו, אם תשימו על זה תשומת לב - אז אפשר.אני כן חושב פה, להגנתנו, שבאמת תצטרכו לשים על זה הרבה קשב.אני אתן סיפור אחר מעולם אחר - אני חושב שכמעט כל החברות Support-handling, כל ה-Intercom-ים למיניהםדבר ראשון, כשיצא כל ה-ChatGPT, אמרו “או-קיי . . . .”כאילו, זה “הכי טבעי” - שאנחנו נתחיל להשתמש בזה בשביל להציע Feature-ים יותר מתקדמיםוגם כל חברה שהשתמשה ב-Intercom וכדומה, ניסתה לפתח את זה פנימית.ובסוף זה קשה להגיע לרמה גבוהה, ולא להגיע . . . .ואגב אני אשמח לשמוע ממך [אורי], אולי - בסוף, על ה-Challenges שלך, בעיות של להטמיע מוצר AIחוסר קונסיסטנטיות (Consistency) ו-Hallucinations וכל הדברים האלה, שאולי תרצו שאני אעשה Double-Click עליהם . . . .גורם לזה שממש צריך להתמחות בתחום.וזה אחד הדברים שאנחנו ביום יום מאותגרים.אני אתן דוגמה, למשל - אפילו מישהו שבא לייצר איתנו Demo, מישהו שרוצה להדגים בתוך החברהכשאנחנו שומעים על מישהו שרוצה להדגים בתוך החברה את המוצר שלנואז הוא בא והתאמן על זה קצת לפני שהוא מציג את זה ל-CTO, למה הוא צריך להכניס Codium.aiואז הוא בא להציג את זה - וזה יוצא לו קצת אחרת . . . .טיפה - מספיק “הטיפה הזו”, וזה מבלבל.אז אנחנו מנסים להציג קונסיסטנטיות (Consistency) - אפילו לא רק קונסיסטנטיות בשביל האיכות של המוצר, אפילו קונסיסטנטיות כי אנחנו כבני אדם עדיין לא רגילים . . . אוקיי, כשאני מדבר עם Chat אז אולי זה בסדר חוסר-קונסיסטנטיות (inconsistency)אבל בשביל בדיקת בדיקתיות-מוצר (Product Testability), אתה צריך טיפה יותר יציבות . . . (רן) כשזה Midjourney, לא אכפת לקבל בכל פעם תמונה אחרת . . . (איתמר) נכון . . . (רן) . . . . אבל כשאתה מג’נרט טסטים (Tests Generation), אתה מצפה לקבל תוצאה ש . . . .(אורי) להיפך - כל הרעיון של טסטים זה קונסיסטנטיות (Testing Consistency) . . . . זה . . . (איתמר) נכון - ולכן יש פה קושי וצריך להעמיק פהעכשיו, אם אני יכול “להקליק” על מה שאמרת - אז אצלנו למשל זה נקרא -  ה-Open-Source - נקרא PR Agentאפשר לדבר למה קראנו לו Agent . . . ו-It’s Tricky,“מונח טעון” עכשיו - Buzzword . . . הנה, זרקתי את הראשון שלי עכשיו . . . .אני לא זוכר אם זה הראשון או לא . . . .(רן) אמרת “AI” . . . .(איתמר) נכון, אז זה השני . . . .אז אחד מה-Feature-ים שם זה באמת לנסות לזהות בעיית Security.עכשיו אנחנו לא ממש ממתגים את עצמנו כ”חברת Security” וגם לא מתחייבים כרגעבגלל שבאמת - צריך לעשות את זה בצורה מאוד מאוד קפדנית, כדי לטעון שה-PR Agent באמת ימנע ב-99.999 מבעיית Security לעבוראז אנחנו כרגע לא . . . .ה-Messaging שלנו לא מתמקד על העניין של Security - אבל זה קיים שם.ואגב, אפרופו ה-Privacy - אחד הדברים שזה תפס, אולי זה הכי טריוויאלי שיש, אבל אם מישהו שבטעות דחף Key, אז זה יתפוס את זה . . . .כאילו, המוצר שלנו יתפוס מישהו שדחף Key עכשיו באחד המקומות, וכל מיני דברים כאלה.שוב, אנחנו לא כרגע משווקים את זה כמוצר שהוא “ב-99.999 פותר Privacy”.14:33 אתגרים באינטגרציה של טכנולוגיות AI ו-Machine Learning בתוך מוצרי תוכנה(רן) כן, בואו נעלה “כמה רגליים למעלה” - היום בבוקר . . . בואו אספר לכם על שיחה שהייתה לי היום בבוקר: דיברתי עם חבר שלי, אילן - היי אילן! - והוא אמר לי משהו כזה: “תשמע, עם כל הטכנולוגיה שקורית היום, כל ה-GPT וכו’, נורא קל לבנות כל מיני מוצרים, ש . . . לא יודע, שעושים חיפוש וקטורי (Vector Search), שמאנדקסים דאטה (Data Indexing), בצורה שלפני זה לא היית יכול לאנדקס וכו’, ויאללה - בואו נבנה משהו כזה! בואו נעשה סטארטאפ!”ואני בטוח שכל אחד מהמאזינים של הפודקאסט שומע שלוש שיחות כאלה ביום, לפחות . . . .ומה שרציתי לשאול אותך, איתמר, בתור מישהו שנמצא בתחום של Machine Learning - והיום אתה גם יכול לקרוא לזה “AI”, כבר הרבה מאוד זמן, זה לא רק על ההזדמנויות הגדולות שיש היום - אלא גם מה האתגרים? אילו אתגרים שאתה נתקלת בהם, בדרך לעשות אינטגרציה לטכנולוגיות AI, לטכנולוגיות Machine Learning, בתוך מוצרי תוכנה.אפשר לדבר ספציפית על מה האתגרים ב-Codium, או דברים שעשית לפני זה . . . (איתמר) מעולה, אז קודם כל - אני מתרכז באתגרים הטכניים, בסדר?כי יש אתגרים היום ב-Business, וגם במובן מסוים מוצריים . . . .אני אתן דוגמה למוצרי - אפילו אנשי-Product צריכים קצת להתרגל . . . .כאילו, זה לא שאין מוצרי Machine Learning כבר מאלפיים-ו . . . לא יודע, 2010, כבר כשהם נכנסואבל בכל זאת - זה יותר ויותר הממשק, ה-Interface ללקוח, הוא נהיה לא-דטרמיניסטיוזה ממש דורש, כאילו, שיטות שונות על הצד של ה-Product.אני דווקא רוצה להתמקד בטכני - וגם שם, באמת שיש המוןואני רוצה להתמקד גם שם - על דברים קצת אולי . . . . “מגניבים / מעצבנים” . . . .אז הנה דוגמא ראשונה - נאמר ואתה עכשיו רוצה . . . מחליט שאתה רוצה להשתמש במודל - Large Language Model, כדוגמא למודל - של אחד הספקיות הגדולות, למשל OpenAI.ונוצר מצב, שהמודלים האלה מתעדכנים - ויותר מזה, הם גם “כביכול מתעדכנים”, בלי שהם באמת מתעדכנים . . . .יש הרבה שיח, נאמר ב-[רשת-שהייתה-ידועה-בשם-]Twitter, בחודש-חודשיים האחרונים, ש-GPT-4 נהיה טיפש יותר  . . . .ויש די הרבה Evidence, על הנקודות של אנשים שחקרו לפני ואחרי . . . .ואגב, ה-VP Product ו-Partnership של OpenAI כתב בפומבי ב-Twitter שהוא לא מבין למה אנשים אומרים את זה, שום דבר לא השתנה . . . .אני פה רגע שנייה אחת אשוויץ - ואגיד שהוא גם משקיע אצלנו . . . והשאלה - מאיפה הקונפליקט? יש עדויות אל מול מישהו שאומר ששום דבר לא השתנה . . . אז זה אתגר מאוד גדול.(רן) כן, זאת אומרת - ה-Backend שלך . . . אם אתה משתמש באיזשהו-Backend, אז נראה שהוא משנה התנהגות, למרות שהוא לא אמור. ולא סתם “לא משתפר”, אלא נהיה גרוע יותר, לפחות בשבילך . . .(איתמר) נכון. עכשיו אני, לשמחתי - ואתה יודע, זה כמו כזה, כשאתה אומר שאתה עובד במסעדה, ואתה יודע מאחורה מה קורה, “במאחורי-הקלעים” [איך מכינים את הנקנקיות . . . ] .  . .(רן) לא תרצה לאכול שם יותר. . . .(איתמר) אז אני, ב-Alibaba Cloud - אחד הדברים שפיתחנו זה מוצר AutoML [גם כאן - 401 AutoML at outbrain with Assaf Klein]ולפעמים היינו לוקחים מודל, שיש לו Benchmark, שכן קיים לו Benchmark . . . אבל אגב - זה מאוד קשה, ואני חושב שזה רק נהיה יותר ויותר קשה.זאת אומרת, ככל שאתה לוקח מודל, שמטרה שלו היא לעשות קלסיפיקציה (Classification), אז אתה כן יכול להצליחוגם שם יש קושי, אגב - כי מה ה-Benchmark שלך? אם הוא זהה, אם יש איזה קורלציה (Correlation) או מתאם חזק  ל-Benchmark של הלקוחאבל לפחות יש איזשהו Benchmark . . . .ואפילו זה נהיה יותר קשה - כי אתה לא עובר קלסיפיקציה (Classification), הGenerative AI כאילו מייצר תוכן . . . .אז יש איזשהו Benchmark - ועכשיו אנחנו רוצים לעדכן מודלונאמר שיש מספר אחד - נקרא לו כרגע “Accuracy“ - והוא עולה מ-81 ל-82  . . . .אז הוא עולה מ-81 ל-82 - עבור ה-Benchmark שלנו . . . ואולי עבור אחרים הוא יורד . . . .אגב, אולי יש את אותו Sample - יש שבעה Sample-ים, שעכשיו הפכו מ-Negative, כאילו משהו שה-Accuracy לא טוב, ל-Accuracy טוב - אבל יש שניים אחרים שנפגעוובסך הכל - השתפר. אז נוצר מצב, שאתה עכשיו משתמש במודל הזה שלנו, של Alibaba Cloud - ואנחנו סיפרנו לך את ה-Benchmark שהשתמשנו בהםוהשתנתה תכונה מסוימת - אולי לטובה, אולי לרעה . . . .וזה קושי מאוד מאוד גדול - הולך וגדל - בגלל התכונות של המודלים האלה.אז זה, למשל, אתגר אחד, כדוגמא.(רן) כן, דרך אגב - גם בעולם התוכנה יש את התופעה המוכרת הזאת, שעם באגים ידועים אתה יודע להתמודד, ואם תיקנו חמישה באגים ידועים - אבל הוסיפו באג חדש - אתה בבעיה . . . . כי עם הבאג החדש . . .  את הבאג החדש הזה אתה כבר לא מכיר, ואתה לא יודע איך להתמודד איתו.(איתמר) אגב, אני רוצה לספר, ותגידו לי אם זו אולי יותר מדי חפירה בנקודה הזאת - זו לא בעיה חדשה, כביכול . . . .יש מאמר, דווקא מאיזו אוניברסיטה באוסטרליה [!Oi Oi Oi] - אני אומר כי זה דווקא כזה די נדיר בתחום שלנו, למי שמכירשהם עקבו - אני לא יודע אם במכוון - אבל הם עקבו במשך שנה אחרי API-ים של Machine Learning Pre-BC, בפורצ'ארט-GPT [?]הם עקבו אחרי מודלים של Azure, של AWS ו-GCP - ועם אותו Sample לאורך זמן - והראו איך ה-Predictions משתנים . . . .עכשיו, אנחנו מדברים על מודלים עוד יותר  . . .  שיש להם Temperatures כאילו, שאפילו במרחק של שנייה אתה יכול לקבל מודל אחראז איך בכלל תמדוד, כשדברים משתנים לך מתחת לידיים?זה משהו שאתה חווה . . . .אני רק כן, כאילו, אולי לפני שנעבור, אתן עצה, כאילו מיטיגציה (Mitigation)אז כאילו, ההצעה הטריוויאלית זה קודם כל למצוא דרך למדוד את זה . . . .אבל דווקא אני רוצה לתת עצה שהיא קצת יותר כאילו, לא רק ב-Monitoring של זה, אלא זה איך להתמודד עם השינויים האלהאז בגדול, המודלים האלה - ככל שאתה שואל אותם שאלות יותר ספציפיות, ככל שהשאלות יותר ממוקדות, אז ככה גם אם עוברים שינויים, בדרך כלל השינויים בתשובה הם ב-Variance קטןאגב, גם דיברנו על זה, שגם באותו רגע, בלי שהשתנה המודל, יכולת לקבל תשובה אחרת, בגלל ה-Temperaturesאז לשאול שאלות יותר מוקדות.אז למשל, אחד השונ-אים (Differences . . . .) - אתה צריך את המילה הזאת, היא קשה לי - בין Code Generator ל-Code Integrityאנחנו ב-Codium.ai בונים את ה-Code Integrity Solution, ולא Code Generation, שנותן לך פתרון כלשהואנחנו Code Integrityאז להבדיל מ-Code Generation, כשאתה כאילו נותן לו איזשהו Prompt, והוא מוציא לך, פשוט קורא ל-LLM ומוציא תשובה כלשהיאנחנו, עבור בדיקה של איזשהו חתיכת-קוד, עושים בין 10 ל-12 קריאות למודל.וכל שאלה היא מאוד מאוד מפוקסת (Focused)עד כדי כך, שאנחנו אפילו יכולים לקרוא למודלים שונים - ועדיין לקבל תשובות די דומות, בגלל שהשאלה היא מאוד ממוקדת.(רן) סוג של גידור . . . (איתמר) כן, בדיוק.21:25 זמן וכסף(אורי) אז 12 קריאות למודל . . . (איתמר) כן - כסף . . . .(אורי) מה? לא, דווקא לא כסף - Latency  . . . (רן) ואתם משתמשים במודלים Online?  זאת אומרת, אתם מביאים מתוך . . . (איתמר) כן, אז אנחנו משתמשים במגוון של מודליםואולי, ככה, זה ישמע קצת אולי סותר את מה שאמרתי עכשיו, אם תבחינו בסתירה שעכשיו אני הולך להציג על העיצה שהרגע נתתי - אנחנו משתמשים במגוון של מודלים.בגלל ה-Properties - יש Properties למודלים האלהוכן - מודלים שיש להם יש להם חוזקות ב-Properties אחריםוזה לא ש-GPT-4, אגב, הוא הכי טוב על כל ה-Properties האלהאני אתן לכם, למשל, דוגמא אולי ל-Property שיפתיע אתכם, לפחותלאחרונה, אגב, שמעתי פחות אנשים מופתעים - כנראה זה התחיל להיות יותר מקובל, אבל אני כן מכיר שזה מפתיעשבעצם, GPT-3.5, בהרבה מאוד משימות תכנות, יותר טוב מ-GPT-4כאילו 3.5 יותר טוב מ-GPT-4 - במשימות תכנות.ואגב, זה מאוד תלוי איך אתה שואל את השאלההאם אתה שואל שאלה של תכנות שהיא על Reasoning, כשבזה נגיד GPT-4 ממש טובאו שיש לך שאלה מאוד ממוקדת - ועכשיו אתה מבקש את הקוד עבור הבעיה המאוד ממוקדתושבזה אולי 3.5 יהיה יותר טובאז אנחנו בעצם משתמשים במגוון מאוד רחב של מודלים, ועכשיו רק . . . לכל אחד ה-Properties שלוואגב - יש Properties של Obedience - כמה אתה “מסוגל להקשיב להוראות”, ולבצע אותן בדיוק, As-isזה לאו-דווקא להבין אותן - אלא לא רק להבין, אלא גם בביצוע של זה.אז זה חשוב, כי אנחנו בכל Integrity, אנחנו לא מנסים להביא לך איזה Boilerplate של קודאם ביקשת משהו - יש לך או אפשרות - ככה או ככה, ואתה תתקן לבד.אני רוצה לתת לך את הביטחון, שה-Test-ים שנתנו לך באמת בודקים את מה שהקוד שלך אמור לעשות אז חשוב לנו ה-Quality.לגבי ה-User Experience - זו באמת נקודה, הייתי רוצה להגיד “הייתה”, כי אני מרגיש שאנחנו לא שמענו הערות כבר כמה . . .  חודשיים-שלושה, על Latency, אז זה קצת בעבר.אבל כן, זו הייתה נקודה בעייתית.ובעצם, אנחנו עושים Applying לשיטה שנקראת Chain of Thought - זה לא Buzzword! אל תספור לי את זה . . . זו שיטה אמיתית, שבה אתה משרשר . . . אגב, זו אחת הסיבות שקוראים לדעתי ל-LangChain - ה-Framework המפורסם של התחום - “Chaining”, כאילו - זה משרשר סדרה של תשובות של LLM אחת אחרי השנייה.ובעצם, אנחנו משתמשים בתשובות הביניים כדי להתחיל “להתניע” - להחזיר ערכים למפתח או למפתחת[זה מזכיר במידה מסויימת מנגנון של Out-of-Order Execution במעבדים . . . .]עכשיו, אני אתן את הדוגמה הכי כאילו-בנאלית - שהיא לא מה שאנחנו עושים:גם ChatGPT, אם תחכה לסוף התשובה ואז תפלוט את זה - גם יהיה לך משעמם . . . .זו אחת הסיבות שהם גם רוצים לתת לך, לדעתי, “Intelligence” - או “הרגשה של Intelligence” וש”משהו נבנה”אבל גם כדי שתוכל להתחיל לקרוא . . .אז תחשוב על אותו דבר אצלנו - רק ברמה של “תהליך חשיבתי”זאת אומרת, שכשאני מייצר לך Test-יםדבר ראשון, אני עושה אנליזה ל-Behavior של הקודאוקיי, יש שלב של אנליזהזה כמו שפת BDD כזאת - Behavior-Driven Developmentיש כאילו . . . . אני נותן לך את התוצר-ביניים - אני אומר לך “הנה כל ה-Behavior של הקוד”ועכשיו, אני מתחיל לייצר Test-ים עבור Behavior שאני . . . .אז לא הכל - אבל את לא מעט מתוצרי-הביניים אנחנו פולטים החוצה, ונותנים למשתמש להבין איך זה פועלאבל גם לשנות - זאת אומרת למשל, אם יש Behavior מסוים שנראה שלא כוסה, אז אנחנו נותנים להשלים במהלך התהליך, וכו’.21:14 הזיות ושיפור מתמיד(רן) כן, אז דיברנו על אתגר אחד, שזה כשה-API משתנה לך או שהתוצאות יכולות להשנות לך, ככה, “מתחת לרגליים”, וטכניקה אחת שהזכרת זה . . . אני קראתי לזה “גידור”, אתה קראת לזה “תיהיה ספציפי” - תעשה הרבה קריאות ויותר “תהנדס את זה”, אל תיתן, כאילו . . . גם אם זה עבד לך פעם אחת “בפוקס” ב-Prompt, אל תסמוך על זה - תייצר הרבה Prompt-ים שונים, ,שתמש במספר מודלים, ולפעמים צריך לעשות להם Chaining וכו'. אבל זה רק אתגר אחד . . . עכשיו, אנחנו בטח לא נספיק להגיע להכל, אבל בוא נבחר עוד איזה ככה, אחד-שניים.מה האתגר הבא שאתה מכיר, מהניסיון שלך, כשרוצים לעשות אינטגרציה לטכנולוגיות-AI בתוך מוצרי-תוכנה?(איתמר) כן, אז זה אולי אתגר שהוא אולי קצת פחות מפתיע, אולי, מהקודם שדיברתי עליו . . . אני אתן לו בהתחלה כותרת, שלדעתי הרבה מכירים - זה Hallucinations  . . . (רן) הזיות . . . .(איתמר) נכון, סליחה - הזיות.זאת אומרת שכביכול יצאה תשובה - שהיא “לא אמיתית”, או לא נכונה . . . .(רן) המאמר המפורסם של Facebook [Meta!] על למה נכון לאכול זכוכית, למשל, וכו’ . . . למי שלא מכיר את הרפרנס - אז Facebook הוציאו כלי שכותב מאמרים מדעיים, ובתור ניסיון אמרו לו להסביר למה זה נכון לאכול זכוכית -והוא כתב מאמר-מדעי מדהים, על למה זה נכון לאכול זכוכית . . . . כמובן שהכל בולשיט והכל אשליות - “הזיות”, סליחה! - אז כן, זו מחלה שקיימת. [והמסקנה המתבקשת - Meta takes new AI system offline because Twitter users are mean](איתמר) מה שרציתי לשים עליו דגש - כי זה כן, כאילו, חשוב לשים לדגש - זה הזיות שיכולות לפגוע.עכשיו, “לפגוע” - יש כל מיני, ולכל מוצר הפגיעה יכולה להיות שונה.אבל כן - אני רק, בגלל שאין מה לעשות, הדלקת לי את הצורך רגע, לפטפט על . . . קצת לנסות להבין את ה-Hallucinations, ואיך יכול להיות ש . . . היה שם . . . “הוא” המציא מאמר או הסבר ללמה זה הגיוני לאכול זכוכית וכדומה . . . אז אני חושב שחשוב להבין, שבסופו של דבר, השאלה - ה-Prompt - יש בתוכה המון Knowledgeכאילו - Information, knowledge ואפילו Intelligence.בעצם, אני טוען . . . . רגע, אני אקח אפילו צעד אחורה - אני טוען, שחלק מההתלהבות שלנו מ-ChatGPTנכון? - הרגע הזה, כשהסתכלנו על “החייזר הזה” ואמרנו “איך הוא כל כך intelligent?!”אז אני חושב שלא שמנו לב, שבעצם אנחנו . . . .לא כולנו ישבנו וחשבנו על פילוסופיה, שבעצם - בשאלה יש את רוב האינטליגנציה. אני לא צוחק . . .[כן, טוב - Saint Douglas אמר את זה קודם . . . התשובה, אגב, היא 42]זאת אומרת, לא סתם, אני  . . . (רן) זה הסוף של . . .  איך קוראים לו? הקוסם הזה, ליאור . . . מנור? לא . . . [“מהנדס מחשבות” - והאמת, אני די משוכנע שכתר ראיתי משרות כאלה . . . .]עזוב, בוא נלך לאלברט איינשטיין [יאללה] . . . אני ארשה לעצמי רגע, אם היתה לי שעה, כאילו, אם היתה לי שעה לפתור בעיה, אז קודם כל, אני יושב 55 דקות להבין טוב מאוד את הבעיה [if he only had one hour to solve a problem he would spend 55 minutes defining the problem and the remaining 5 minutes solving it routinely].זאת אומרת, הרבה דברים  . . .  כאילו, אם עכשיו תשאל “תסביר לי מה ההבדל בין צפרדע לאבן”, אז זה ייתן איזשהו הסבר. זה כאילו . . . אבל אם עכשיו אתה תבוא ותגיד לו עכשיו . . . בוא נלך על משהו טיפה יותר אינטליגנטי, לא לאכול זכוכית, או לא בין צפרדע לאבן . . . אתה רוצה לדבר עם ה-ChatGPT על דברים מהותיים, כמו מה ההבדל בין אינטליגנציה ו-knowledge. אוקיי? עכשיו, אם אתה יודע לשאול את השאלה, כאילו,”בצורה טובה” - אתה תקבל תשובות “סופר-אינטליגנטיות”אבל אם אתה תשאל שאלה טיפשית - אתה תקבל תשובות טיפשיות . . . .בעצם איך ש-LLM עובד, זה בהינתן השאלה, אוקיי? בהינתן ה-Prompt - זו לא חייבת שאלה, זה יכול להיות  . . . .בהינתן ה-Prompt - מה התשובה “שהכי Likely לענות על זה?” . . . זה בעצם איך שהמודלים האלה עונים. אז יש המון Knowledge ב . . . סליחה, המון אינטליגנציה, ואפילו הרבה ממנה, לא רק ה-Knowledge.האינטליגנציה היא בשאלה. תשאל שאלות מפגרות - תקבל תשובות מפגרות.(אורי) האם הוא גם משתפר בין שאלה לשאלה? זאת אומרת, השאלה שרן שאל אותך עכשיו - השתפרת כתוצאה מהשאלה שלו? וכשאני אבוא לשאול שאלה, אתה תהיה יותר חכם?(איתמר) אחת הסברות היא ש . . . . השאלה מי - האם זה ChatGPT או לא?אבל אחת הסברות שאומרים ש-GPT נהיה Dumber, כאילו, סליחה, נהיה יותר טיפש, זה בגלל שאומרים שהוא אומן על ה-Data עכשיו שהגיע מכל האנשים שהשתמשו . . .(רן) . . . וכולנו נהינו יותר טיפשים . . . .(איתמר) . . . . וכולנו לאט לאט מתכנסים . . . . הרי, אם בסוף אתה נותן ל-Machine Learning ללמוד Data של עצמו, אז ככה אחת אפשרויות שזה Model Collapse, כאילו, לכלום . . . .[הרחבה מומלצת באחלה פרק של עושים טכנולוגיה - הבינה המלאכותית ממלאת את העולם בזבל]אבל רגע אחד - אני רוצה להסב את השאלה שלך, וזה גם יעזור לי לסיים את הפואנטה הקודמת: אתה שואל שאלה . . . אתה שואל שאלה, ואתה אומר לו “אתה בטוח שאתה צודק?” . . . .ואיזה קטע! הוא פתאום מתקן . . . .אוקיי . . .  ואתה אומר “איזה יופי! איך הוא חכם!” . . . .אבל . . .  או “זה”, או “היא” . . .אבל מה הקטע? שבעצם העובדה שאתה ערערת - אתה נתת אינפורמציה נוספת . . . .אתה שאלת - “האם אתה בטוח שאתה צודק?”כאילו, וזה בעצם כל מה ששאלת זה - יש בזה עוד אינפורמציה . . . זה כמו שאני חושף לך עוד קלף בפוקר, או . . . . וכדומה. (אורי) עירערת לו את הביטחון עצמי . . . .(איתמר) נכון, אבל בעצם נתת אינפורמציה - חשפת אינפורמציה נוספת . . . (רן) יש את החידה המפורסמת בהסתברות - של שלושה וילונות, אתה בוחר אחד, ואז אומרים לך . . . חושפים אחד -האם תחליף? [אמ;לק - כן: Monty Hall problem]. אז גם פה, נתת עוד אינפורמציה, שאלת אותו “?Are you sure“, ואז פתאום “הוא” אומר “רגע, אולי אני בעצם לא כל כך בטוח . . . .”(איתמר) כן. חידה מדהימה - Monty Python, אם אני לא . . . .? [לא, עד כמה ש”Monty Python” יכולה להיות תשובה לא נכונה, שזה לא הרבה](רן) כן. משהו עם . . .  Monty Hall, נראה לי . . . .(איתמר) כן, כן, אני צוחק - זו חידה סופר-קריטית, סופר חשובה לנקודה הזאת. היא באמת, כאילו . . . אתה - יש שלושה וילונות, ובאחד יש מכונית [!], ובשניים דחליל ועז [!!]אתה בוחר אחד - ואז חושפים לך או את העז או את הדחליל ואומרים לך “אתה רוצה להחליף?” . . . .אם אתה מחליף, אז אתה עובר מ-33% ל-50% - זה שווה ממש לחשוב על זה, אם אתם לא מכירים את החידה . . . .(רן) טיפ שלנו - תחליפו . . . [אמ;לק - נוסף כאן עוד מידע שלא היה קודם, כי מי שחשף את העז ידע שהיא שם…](איתמר) כן, ממש שווה . . . אם לא חשבתם, זה ממש . . .אז זה אותו דבר. ועכשיו, מה מעניין? נגיד שהוא, נגיד שהוא  . . .  נגיד שה-ChatGPT כן צדק, ועוד פעם תגיד לו “אתה בטוח שצדקת?” - יכול להיות שהוא יחליף את זה . . . זאת אומרת, האינטליגנציה של “לדעת לשאול את השאלה”, אם עוד פעם . . . אתה כבר ידעת לקבל את התשובה השנייה ולהגיד “זה נכון”, ולא המשכת לשאול.אבל אם לא היה לך את האינטליגנציה, והיית שואל עוד פעם “אתה בטוח שצדקת?”,  יש סיכוי ש”הוא” היה אומר “אופס! סליחה, טעיתי!” - והיה ממשיך לתת לך תשובות לא נכונות . . . .אז . . .  ב-Bottom-line, רציתי להגיד - אם אני מקפל רגע הרבה חלונות, הרבה Brackets . . . יצאנו מכל הסיפור הזה, ההבעיה של Hallucinations(אורי) . . . אתה עולה ב-Stack . . . .(רן)  . . .  אנחנו כבר לא ב-Lisp anymore . . . .(איתמר) אז אני חוזר למקור, אני מקפל הרבה כדי שנחזור חזרה . . . . אז זו היתה השאלה של, אוקיי, Hallucinations . . . .אבל Hallucinations שיכולים להזיקלפעמים אולי קוראים לזה  . . . אפשר לקרוא לזה “Mission-Critical Hallucinations”אפשר למצוא לזה כל מיני שמות מהעולמות הישנים . . . ופה, אני חושב שמאוד כן חשוב לשים Guardrails על Hallucinations מסוימים.למשל, בואו ניקח את העולמות שלנו - מה קורה אם עכשיו אני מייצר Test, שיכול לייצר נזקאו שטסט ש . . . בואו ניקח פחות, Test ש . . . (רן) . . . .שכורה Bitcoin . . . (איתמר) . . . . כן, כן . . . או Test . . .ניקח שלב אחד אחורה - Test שפשוט גורם לכל ה-Test-ים שלי לא לרוץ, ואז המוצר שלי יהיה פחות איכותי.זאת אומרת, אחד ה-Feature-ים אצלנו במוצר - זה אחד ה-Feature-ים האהובים גם עלינו, גם על ה-User-ים - זה שאחרי שה-Test-ים נוצרים, אתה בתוך המוצר שלנו יכול להריץ אותםחלקם עוברים, חלקם נכשליםאגב - בכוונה, ואני יכול להסביר למה . . . מתבצעת אנליזה אוטומטית, Agent-wise - כאילו זה Chain-of-Thought כזה - על הכישלון של ה-Testואז, על בסיס הכישלון - מתקנים את ה-Test, או מתקנים את הקוד, אוקיי? . . . אפשר לצלול על זה ל-Double-click אם אתם תגידו ליוכל הרעיון הזה הוא שאם היה Test אחד “סורר”, יכול להיות שהוא יהרוס את הכלבוא נגיד ה-Feature הזה, שכבר לא יהיה לו UI או UX - אז זה סופר קריטי.ואז יש גם את הדברים היותר חמורים - אז זה פה אני מוציא . . . . לדוגמא, אם תסתכלו על Wordtune, אז אתה לא רוצה שזה יקלל אותך, נכון?של AI21, או משהו כזהצריך ואפשר לשים כל מיני Guardrailsזה סופר-קריטי, כאילו, להילחם ב-Hallucinations [ד”ש לדון קישוט?] והדרכים האלה.(רן) כן, ופה אנחנו קצת היינו על הגבול שבין Hallucinations ל-Safety - וגם Safety זה סיפור גדול בכל הסיפור הזה, אגב ללעוס זכוכית . . . אז כן - אבל הדברים פה הם . . . . כן, לגמרי נמצאים שם על הגבול . . . 33:53 מה ההבדל?(רן) אבל אנחנו, ככה, מתקרבים לקראת יותר הסוף - ורציתי שוב להנחית את החללית [איזה תותחים ההודים!] . . . .אז היינו ככה ב-30 אלף רגל, אוקיי, לא חייבים ל . . .(אורי) . . . רציתי לשאול אותך האם אתה בטוח? . . . .(רן) אוקיי . . .  עכשיו כבר לא . . . Not anymore . . . אבל כן, זאת אומרת, רציתי רגע לחזור לדבר על המוצר - עכשיו אני מפתח, ואני שואל את עצמי האם אני רוצה להתקין את ה-Extension הזה או לא. ויכול להיות שאני מכיר כלים אחרים בעולם של Code Generation . . . והשאלה שאני שואל זה - מה ההבדל? אוקיי? . . . זאת אומרת, האם לא ניתן לייצר Test-ים באמצעות Copilot, או כלים אחרים ל-Code Generation? בעצם, איזו ייחודיות יש ל-Codium על פני הכלים האחרים, שהם יותר גנריים - שאולי לא ספציפית מייצרים Test-ים, אבל כן מייצרים קוד? זאת אומרת, אתה תמיד יכול לעבור ולכתוב Test- ואז לתת לו “להשלים את החסר” . . . אז איך Codium עובד שונה מהכלים האלה?(איתמר) מעולה - אז הייתי רוצה לחלק את התשובה לשתיים:בחלק השני, אני רוצה להשוות בין מוצר של AlphaCode של של DeepMind, אם אתם מכיריםאחד מארגוני ה-AI הכי חזקים בעולםשעל Context שנקרא CodeForces, אם אתם מכירים - הוא מגיע ל-45 Percentileזה נחשב “Mid-seniority”לעומת GPT-4, שמגיע ל-5th percentile from the bottom . . . שזה נחשב “Newbie”וההבדל ביניהם זה שב-AlphaCode -  יש להם רכיב, יש להם Agent ספציפי, שמתמקד ב-Code Integrity, ב-Testing, אוקיי?והוא שונה מהרכיב של ה-Code Generationזה החלק השני של התשובה . . . .(רן) כן . . . זאת אומרת, AlphaCode זו תחרות לכתיבת קוד?(איתמר) כן . . . לא, לא! סליחה . . . - CodeForces זו תחרות לתוכניתנים . . . .בוא נתמקד בחלק הזה, ורק בזה - בשביל המחשה של מה אנחנו עושים שונה.אז CodeForces זו תוכנית, או “תחרות לתוכניתנים”, אתם יכולים . . .  כל כמה זמן יש שם את התחרות . . . .(רן)  . . . וכל מיני אנשים מתמודדים  - ובין השאר יש גם מכונות . . . (איתמר) נכון, ויש שם Rating - כמו שיש Rating בשחמט, למי שאוהב את זה . . . .ואתה מתחרה כאילו מול המחשב יותר מאשר מול לאנשים - ובסוף יש לך איזשהו Rating.ו-OpenAI התחרו עם GPT-4 על ה-Context הזה, של CodeForces(רן) והגיעו ל-5% התחתונים . . . .(איתמר) התחתונים!להבדיל, אגב, מ-GRE ו-Medicine ו-History . . . (רן) . . . ששם ב-85% העליונים . . . (איתמר) בעליונים! כאילו, יש רק 15% יותר טובים מהם, של אנשים.ופה יש 95% . . .  איך זה יכול להיות?! הרי אנחנו נורא אוהבים להשתמש ב-Copilot וב-ChatGPTלמי שמרשה - ומי שלא - עושה את זה גם ככה, נכון? . . . .  אז איך זה יכול להיות?אז יש לנו פה . . . .(רן) אז (1) - בתחרות עצמה יש Bias - כי מי שבא להתמודד, הוא כבר כנראה ממש טוב . . . (איתמר) נכון, אבל הם עשו איזשהו . . . (רן) . . . .אבל עדיין - הם מגיעים נמוך.(איתמר) נכון, אז הם עשו איזשהו Rating . . . כאילו, ב-Rating שלהם הם נחשבים “Newbie”’, ממש ככה.אבל סבבה - גם אם לא, אז בוא נסתכל, כי הנקודת-ייחוס שלי אגב . . . . זו נקודה טובה, אבל נקודת-היחוס שלי זו מערכת אחרת, שנקראת AlphaCodeו-AlphaCode זה, למי שמכיר - DeepMind, שיצאו עם AlphaGo, שניצחה תחרויות של Go וגם את אלוף העולםוגם את AlphaFold, על כיפול פרוטאינים (חלבונים, Proteins) וכל מיני דברים כאלהועכשיו, לפני שנה או חצי שנה, הם הגישו גם כן . . . התחרו - והם עשו פי-9 יותר טוב מ-GPT-4 . . . עכשיו, יש להם פחות או יותר שני רכיבים  . . . זה לא רכיב, זה שתי תתי-מערכות במערכת שלהם - אחת שמייצרת קוד - שבנוי מאוד דומה ל-GPT-4זה מה שאתם רואים, כנראה, פחות או יותר, ב-Bardב-Codey - לפני שבועיים, כי הקראת קודם את התאריך, אז אפשר לתת נקודת-ייחוס [תכל’ס Feature חשוב בפרקים בתקופה הזו . . . .]אז יצא מודל של קוד ב-GCP, שנקרא Codey, אז משתמשים . . . אבל ממול זה יש מערכת - זה לא בדיוק מודל . . . .כמו שאמרתי לכם, גם אצלנו המערכת היא לא Per-se קריאה למודל - “תחזיר תשובה”מה ש-Code Generation עושה . . . יש שם מערכת שלמה של Analysis - גם Static וגם Dynamic וכל מיני דברים כאלה, וכמה קריאות למודליםאז יש להם מערכת כזאת.והשילוב שלהם ביחד גרם לניצחון הגדול, זה מה שאני אומר(רן) זה כמו “סיעור-מוחות” - שני אנשים יושבים בחדר: אחד נותן תשובה ראשונית, השני משפר אותו - ואז הם עושים אולי שיחה ביניהם . . .  זה מה שקורה שם.(איתמר) ממש ככה . . . אמרת לי בהתחלה, שיש פה בחוג המאזינים אולי גם כמה Data Scientists שמקשיבים לנו, חוץ ממפתחים . . . . אז ב-2016 או 2018, היתה מערכת שנקראת Generative Adversarial Network (GAN)בעצם היתה שם מערכת של Generative שמייצרת תוכן - ו-Adverse שבודק אותואחת שמדפיסה כסף - ואחת שאומרת האם זה מזויףוביחד הם מצליחים עוד לשפר אחד את השני.אז אתה חושב, שאנחנו קצת מחזירים את ה-Concept הזהלא אנחנו - AlphaCode הראו את זהשבעצם, יש מערכת שמייצרת קוד - ושנייה שבודקתוביחד, יש פה ממש “סגירה של Loop”, שגורם לקוד שהולך ומשתפר . . .(רן) סימביוזה . . . .(איתמר) בדיוק,(רן) הנה עוד Buzzword! . . . (איתמר) מדהים . . . אבל זה חלק מה-Buzzwords האלה, שלא נחשבים לגמרי Buzzwords, כי הן Program-fit . . . .(רן) כי זה מביולוגיה, זה בסדר . . . (איתמר) כן, זה כמו Program-fit, שהוא Buzzword אבל הוא גם אמיתי כזה . . . . אז סיביוזה, סבבה.אז המודלים ה-Generative-יים - אין להם, בפשטות שלהם היום - אין להם את המנגנון הזה, של “הפידבק החוזר”וזה מה שאמור . . . .אז לצורך העניין, הרבה מאוד מהלקוחות שלנו, בין אם זה מפתחים חינמיים או Enterprise Teams וכו’ - אז הם משלבים את שני הכלים האלה, ביחד.לנו לא משנה אם בנאדם כתב את הקוד או Generative Tool, כמו Copilot וכו’ כתבו את הקודאנחנו נעזור לתת את אותו Adversarial, כביכול אז זה שוני מאוד גדולב-Stack, ב-UX/UI, ב-Output-ים . . . .אגב, רק שלא ישמע - יש לנו עוד דרך ארוכה להשתפריש מקומות שאנחנו חזקים יותר, כמו ב-Backend, מאשר ב-UI Per-seויותר ב-Component Testing מאשר Integration Testing . . . רק כדי לסבר את האוזן רגע, לא . . . 39:27 סיכום - וסיפור קצר . . .(רן) כן, טוב - אז אנחנו ממש ככה לקראת הסוף, ויש מלא דברים שרצינו לדבר עליהם ולא הגענו לדבר עליהם . . .א' -יש עוד מלא אתגרים . . .(אורי) . . . ונראה לי גם חסמנו את כמות ה-Buzzwords היומית . . . (רן) הגענו ל-Cutoff שלנו, כן . . . .אז גם בנושא של איך לשלב טכנולוגיות AI בתוך מוצרי-תוכנה, לא דיברנו בכלל על איך זה לפתח כלי למפתחים, איך זה לעבוד עם IDEs שונים, והאתגרים ההנדסיים שקורים שם - אז אולי נצטרך לדבר שוב, איתמר, אבל בכל אופן, תודה רבה שבאת.ממש לפני סיום - כמה מילים על החברה: איפה אתם נמצאים, פיזית? האם אתם מחפשים לגייס? מה עוד היית רוצה שאנשים ידעו עליכם?(איתמר) מעולה, אז קודם כל אנחנו יושבים במגדלי חג'ג' ברחוב הארבעה.ואנחנו 20 איש - וגדלים.אנחנו מגייסים הרבה . . . . אני מקווה שלא ישמע יותר מדי פלצני, אבל הרבה לפי, כאילו, Talent.מחפשים כאילו אנשים חזקים, כי אנחנו מאמינים שהבנץאדם עושה את התפקיד ולא התפקיד עושה את הבנאדם.ויחד עם זאת - יש Job Descriptions שפתוחיםאבל במקום לתאר אותם, אני רוצה דווקא לספר איזה סיפור מאוד קצר:אז אור הילטש, אני לא יודע אם אתם מכירים, אני מניח שכן [אפשר להתחיל כאן - פרק #275 – אור הילטש ודאטא נדל"ני]חוץ מזה שהוא חבר אז הוא גם “אושיה”, אז אני מניח שאתם מכירים . . .אז הוא עשה לי שיתוף ב-Screenshot, שיש איזו קבוצה של CTO ו-VP R&D בישראלכאלה מוצלחים - אז אני לא שם . . . (רן) לא יודע - אני שם, אז אני לא בטוח לגבי ההצלחה . . . . . . . אז הוא עשה לי Screenshot, והראה שמישהו כתב “שמעתם על החברה הזאת, Codium.ai - החצופים האלה, שבנו מוצר שנראה שבינתיים הולך להם די טוב - ואין להם CTO ו-VP R&D! איך יכול להיות, איך זה יכול להיות? יכול להיות שאתם קצת מיותרים?” וכו’ . . . אז כן, למרות שיש לנו בצוות, לדעתי, ארבעה CTO-ים לשעבר או VP R&D לשעבראנחנו, למשל ה-Founder-ים - אני לקחתי תפקיד, עברתי מ-CTO ל-CEO, מאתגר את עצמי בזההשותף שלי הוא ה-CPO . . . .אז אין לנו כרגע למשל VP R&D - ואנחנו פתוחים . . . .זה לא משהו דחוף, אנחנו מסתדרים די טובאבל מאוד מאוד מאמינים שבסופו של דבר, למרות שעד כאן הלך לנו די טוב, אנחנו כן פתוחים למשל ל-VP R&D וגם ל-CTO.אז מי שרוצה לאתגר את עצמו איתנו - מוזמן לבוא ולהתקשר אליי.(רן) יש מי שכותב Test-ים? הכי חשוב . . . (איתמר) כן, בטח . . . קודם כל, אתה יודע - חייבים . . . אנחנו משתדלים להשתמש במוצר של עצמנוגם במוצר שהשקענו בו את רוב הזמן, שזה ה-Extension או Plugin ב-IDEאבל גם אותו מוצר שמתחבר ל-GitHub ול-GitLab, שעושה לך את ה-Gateway האחרון וכדומה(רן) . . .  שנקרא PR Agent(איתמר) שנקרא PR Agent . . . הוא Open Source, אגב - אפשר להשתמש בו ב-Hosted הזה שלנווזה עושה לך Automation של Description, של Reviewכדי שבסוף יהיה לך קל To Streamline the Process[רק אומר ש-Whisper תמלל את המשפט הזה ככה - “כדי שבסוף יהיה קל ל-Streamline את הפרוסס” . . . תחשבו על זה מה שאתם רוצים]אנחנו משתמשים בזה בעצמנוויחד עם זאת, יש לנו כן - וזה אולי נקודה מעניינת, אבל נגמר לנו הזמן - יש לנו QA, אבל הוא מפתח . . .כי ממש . . . הוא חייב להיות, כי אנחנו בונים כלי מפתחים - אז הוא ממש משמש כמפתח, אבל יש לו גם תפקיד מעניין של “להתנסות על Open Sourcing”, וככה גם לעשות קצת Dev Advocate . . .אז יש לנו - למרות שאנחנו כלי למפתחים -Automation של Testing במובן מסויםאבל עדיין יש לנו Tester . . . (רן) כמו שבחברת משחקים משלמים לך כדי לשחק -  פה משלמים לך כדי לפתח . . . .(איתמר) נכון, כן, בדיוק.תודה רבה איתמר! היה מרתק. להתראות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 465 של רברס עם פלטפורמה, הוקלט ב-15 באוגוסט 2023 (אם הטכנולוגיה השתנתה בשבוע וקצת שחלפו - ככה זה . . . זה מה שאנחנו יודעים היום).פרק נוסף בסדרת הקרבורטור, שבה אורי ורן מארחים את נתי שלום כדי לדבר (בעיקר) על תשתיות -  וספציפית היום (מעבר לשלום עולמי) על איך אפשר לעשות “Inferencing בקצה” (Inference on the Edge).01:40 רקע(נתי) אז אני חושב שאני אתן טיפה רקע אולי, על למה זה בכלל הפך להיות רלוונטי ולמה זה מענייןאז הסטטיסטיקות - אני חושב שהן די ברורות, אבל אני אגיד אותן ברמת המספרים. היום בעצם . . . . מה זה “יחידת קצה”? בואו נתחיל מזה - יחידת קצה זה יכול להיות . . . (אורי) אחרי זה תסביר מה זה Inferencing, בסדר? . . .(רן) יש לנו פה פודקאסט שלם בשביל להסביר שתי מילים . . . (נתי) אז אנחנו אומרים, קודם כל, שיחידת קצה - זה מצלמה, זה יכול להיות סנסורים (Sensors), זה יכול להיות מחשב . . . זה שנמצא ליד בבית-חולים ויושב ליד המכשיר הרפואי, זה יכול להיות ממש מיני-Data Center.(רן) . . . טלפונים, שעונים . . .[טוסטר משולשים?](נתי) . . . . טלפונים, רשת סלולרית . . .  כשאתם רואים את המכולות האלה מתחת לאנטנות? אז זה יחידת-קצה.(נתי) אז בעצם נוצרים הרבה מאוד מכשירים, שהיום עוברים איזשהו תהליך של דיקיטיזציה (Digitization)זאת אומרת שהם בעצם הופכים להיות מחומרה, שהיא  יחסית מנותקת ו”מתישהו” בא טכנאי לטפל בה - פעם בכמה שנים - ועושים להם שדרוג, מאוד יקר בדרך כלל.זה משהו שבעצם . . . הם מחוברים כל הזמן לרשת - בדרך כלל ב-Wi-Fi או ב-5G, או בכבל אופטי שמחובר ל-Base Station.וזה בעצם שינה את כל ההתייחסות לדבר הזה.אני אתן את הדוגמה שכולכם מכירים - הטלוויזיה שלכם בביתלפני כן, הייתה טלוויזיה שמחוברים אליה כבל עם איזו קופסא, והייתם קונים את הקופסא הזאת מ-HOT או מ-Yes, ומקבלים [נניח] שירותי Streaming.היום, הטלוויזיה עצמה מתעדכנת באופן אוטומטי - כמו הטלפוןכי היא בעצם מבוססת על Android, מחוברת ל-Wi-Fi - היא נהיית חלק מ . . . “עוד מכשיר” שנמצא היום ברשת.(אורי) היא נהייתה “חכמה” . . .  האנשים שרואים בפנים - פחות, הם נהיים פחות חכמים . . . .(רן) אבל בשביל זה קניתי טלוויזיה חכמה - חשבתי שזה יעזור  . . . (נתי)  . . . זה מה שקורה בטלוויזיה . . . . אבל בקיצור, זה . . . .  ממש רואים את השינוי הזה קורה . . .(רן) יש לי webOS! זוכר את webOS?(נתי) בטח . . . .(רן) אז ל-LG יש webOS - זו מערכת ההפעלה לטלוויזיות של LG.(נתי) עוד מעט תגיד לי שהם מביאים גלידות גם וכאלה . . . אז באמת, יש איזה תהליך דיגיטליזציה (Digitalization) - התהליך דיגיטליזציה התחיל כבר לפני כמה שניםבאמת בעיקר בעולמות של Consumer Business - זאת אומרת, טלוויזיות, טלפונים, וכיוצא בזה.ה-Wi-Fi שלי בבית הוא Google Wi-Fi, אז הוא גם כאילו . . .  כל הזמן אני מסתכל ואני רואה שהוא התעדכן, אני אפילו לא יודע שהוא התעדכן.דברים שבעבר הייתי צריך להוריד איזה Package מהאינטרנט, לעשות Upgrade, לחבר עם USB וכאלה דברים.(רן) לחבר USB, להקיש משהו . . . .(נתי) היום אתה פשוט סורק את ה-QR Code, מתחבר, מזהה אותו - ובעצם הטלפון שלך הופך להיות תחנת שליטה של ה-Wi-Fi, שמתחבר לאינטרנט, עושה לו את הסנכרוןואני יכול לראות את כל הנתונים של ה-Wi-Fi בבית - מי קולט יותר, מי קולט פחות, מי מחובר למה . . . .“כל ה-Mesh הזה”, מה שנקרא.05:00 תחנות הקצה יותר חכמות - אז מה?(רן) אז תחנות הקצה יותר חכמות . . . .(נתי) בדיוק, תחנות הקצה הופכות להיות חכמות - והיום זה חודר גם לעולמות של Enterprise ו-Defense, כל “התעשיות המסורתיות”.(רן) אז זה זה “ה-Enabler” שלנו . . . (נתי) זה ה-Enabler, בדיוק . . .(רן) . . . . זה מה שמאפשר את המהפך . . . .(נתי) אז זה השלב הראשון.(אורי) בכלל, כש . . . עוד לפני ה-Internet of Things, תחנות הקצה היו אנלוגיות לגמרי, לא שום דבר דיגיטלי  . . . . ה-Internet of Things הפך אותן לחיבור - לא יודע מה, IP כנראה . . . - לעולם.(נתי) בדרך כלל IP, כן . . . .(אורי) . . .  ועכשיו הן גם מתחילות להיות חכמות, ה-”Things” . . .(נתי) נכון - אז בעצם ההסתכלות ברמה . . . בוא נגיד ככה - מי שמסתכל על זה ובא מעולם ה-Cloud Infrastructure, ומסתכל על זה כ-Extension של ה-Cloud . . .זאת אומרת, ה-Cloud עד היום היה הרבה מאוד מחשבים שמרוכזים ב-Data Center-ים מאוד גדולים.בעצם, החווה של Data Center-ים האלה - זה היחידות קצה אלה.אבל בעצם הם כולם “סוג של-Cloud” - אמזון אפילו מתייחסים אליהם כ-Region.גם Azure, כשאתה מסתכל על משהו שנקרא Azure Stacksזאת אומרת שגם הענן עצמו ייצר את ה”יחידות מחשוב” האלה, שאפשר להתקין אותן באתרים מרוחקים.והם מתחברים - ומתנהגים כמו עוד יחידת מחשוב, מבחינת ה-API וה-FSLM . . . .(רן) אבל זה סוג של PoP, נכון? זה Point of Presence . . . .(נתי) זה סוג של PoP . . . .(רן) זה לא טלוויזיה.(נתי) לא, זה לא טלוויזיה . . . . אז אני אומר, זה באמת קיבל כמעט . . . לכן אמרתי - מי שבא מעולם ה-Cloud Data Center, מסתכל על זה כעל Extension של ה-Cloud.מי שבא מעולם ה-Consumer, מסתכל על זה כמכשיר חכם.זה ממש שתי זוויות ראייה שונות לאותו דבר, לאותו מגע.06:30 בסוף יש אפליקציה(אורי) אבל זה הכל שאלה . . . . בסוף יש אפליקציה, איזושהי פונקציונליות שצריכה לקרות - ותחליט אם טוב לך לעשות אותה בקצה או טוב לך לעשות אותה בשרת . . . (נתי) או, אז זו בדיוק הנקודה - עכשיו אני, ופה נכנסת המילה הזאת שאני צריך לפרש, שנקראת “Inferencing”, ותיכף נסביר גם איך AI נכנס פה לתמונה וכל מיני דברים כאלה . . . .אז בעבר, היתה לנו מצלמה שמשדרת ב-Streaming למרכז - בדרך כלל זה Cloud, איזשהו Cloud - ששם נעשה העיבוד של התמונה הזאתובסוף אנחנו מוציאים איזה תובנות אם זו מערכת Security אז האם זה אויב או לא אויב, האם יש פה איזו חדירה או פריצה למערכת . . . ואפשר, אם זו מערכות Firewall, אז סורקים Packet-ים, ובסוף מזהים אם זה Malicious Attack או לא.אבל רוב העיבוד הזה היה נעשה בדרך כלל במרכז של קבלת ההחלטות - והדבר הזה היה יחסית “טיפש”, והעביר את הנתונים האלה.פה נכנס הנושא של AI - מה ה-AI הביא לנו? הוא הביא לנו יכולת באמת לזהות אובייקטים בצורה הרבה יותר חכמהאני יכול לזהות אם זה חתול או כלב, זו הדוגמא הקלאסית.אני יכול להשתמש בזה כדי לזהות, למשל, בקווי ייצור, אם מכונה הולכת להתקלקל - כי אני מתחיל לראות שהיא  . . . או מכונית, לצורך העניין - אני רואה שפתאום ה-Log-ים שהיא מוציאה מתחילים להיראות דומה ל-Pattern-ים של תקלה.ואז אני יכול לצפות את זה מראש - וכולנו יודעים שהשבתה של קו ייצור, אם אני כבר מגיע להשבתה, אז זה עלויות מטורפותלעומת אם אני מזהה את זה לפני ועושה תיקון Pre-emptive ו . . . .(רן) מה שנקרא Predictive maintenance  . . . . (נתי) . . . . Predictive maintenance . . . (אורי) לדעתי היה לנו . . . .(נתי)  . . . . יש חברה מאוד מצליחה בארץ שעושה את זה, שנקראת Augury, בחיפה, שמתעסקת בזה.(אורי) . . .  לדעתי ראיינו . . . נכון? מישהו מ . . . . [לא חושב . . . . אבל צריך בהחלט](רן) זכור לי במעומעם . . . .(אורי)  . . . וגם מ-Lightricks  . . . [זה כן - 417 Developer Growth with Barak Yoresh from Lightricks]שעושים את כל העבודת ה-AI במכשיר, ולא בשרת . . . [כזה - Qualcomm Ventures Invests in Augury to Power Industrial Market Transformation with AI and 5G](נתי) נכון, אז תכף נגיע למה זה נהיה עכשיו יותר מגמה.אז בגדול, הסטטיסטיקות מדברות על זה שקצב הנתונים - בגלל כל מה שאמרנו כרגע - המכשירים האלה מייצרים הרבה יותר Data ממה שהם ייצרו בעבר.אנחנו מדברים על רזולוציה של תמונות שהיום היא כבר לא 4K, אני לא זוכר כבר . . . . לא 8K ואפילו יותר.אנחנו מדברים על נפחים . . . . (אורי) מה הבעיה? יש 5G - הוא “נולד בשביל הדברים האלה” . . . .(נתי) אז הסטטיסטיקה היא שקצב גידול ה-Data, לעומת קצב גידול ה-Access - ה-Access זה ה-Network - הוא כבר לא מדביק אחד את השני.זאת אומרת, ה-Data גדל בקצב של בערך פי שלוש יותר מהקצב של ה-Access.וגם ב-5G רואים שהתמונה בהתחלה, היא שבאמת 5G נותן איזשהו Capacity - ואחרי זה איזושהי ירידהכי פשוט כבר זה מגיע לאיזושהי רוויה ביכולת שלו להכיל את כמות ה-Data.אז אם מסתכלים על הגרפים, רואים בעצם איזשהו . . . ש-5G לעומת 4G נותן איזושהי קפיצה - אבל אחרי זה הוא יורדואחרי שהוא יורד, באזור 2027, הוא כבר הרבה מתחת למה שצריך מבחינת כמות ה-Data שאמורה לזרום דרכו.09:44 התחממות גלובאלית ו-Latency(אורי) בוא נוסיף לזה עוד שיקול . . . . איך קוראים לזה? התחממות הכדור . . . Emissions.(נתי) נכון, נכון . . . .אז יש באמת הרבה גורמים, שגורמים לזה שאנחנו בסופו של דבר מוצאים את זה שהגישה הקיימת, של לעבד את הכל בענן, ו-”Device-ים טיפשים” - לא מחזיקה מים.יש נושא נוסף, שהוא Latencyאז המספרים הם כאלה, כשעל המכשיר עצמו זה 2 msec; בינו לבין ה . . .  אם נניח אנחנו מדברים על ביזור גיאוגרפי, אז בינו לבין איזושהי תחנת Data Center קרוב זה יכול להיות באזור ה-5 msec.אחרי זה זה לענן - בדרך כלל ל-Data Center-ים שהם מרכזים יותר גדולים, אנחנו מגיעים כבר לאזור ה-10 msec.וכשאנחנו מדברים על ביזור שהוא יותר ספורדי, אז אנחנו יכולים לדבר על אזור ה-50 msec.עכשיו, להרבה אנשים זה לא אומר הרבה, אבל יש הרבה מאוד מערכות - בטח מערכות של בקרה ושליטה וכאלה דברים, ובטח כשאנחנו מדברים על מכוניות ו-Connected Cars, שה-Latency הזה הוא סופר-משמעותי.ולכן היתרון הנוסף של עיבוד בקצה הוא בעצם יכולת לקבל החלטות יותר קרובות ל-Real Time.(רן) . . . . וגם לפחות נקודות כשל . . . ככל שאתה עובר יותר תחנות, ככה . . . (נתי) בדיוק.עכשיו, יש פה איזו סתירה אינהרנטית (Inherent) - וזה בעצם מה שכל העולם של Inferencing בעצם מדבר עליו.הסתירה האינהרנטית היא ש-AI בעצם בא ואומר: “אני יכול באופן לא-תיאורטי, להיות הרבה יותר חכם באיך שאני מעבד את המידע הזה - אני יכול להיות אינטליגנטי, אני מפרק את ה-Data ל-Feature-ים, אני יודע לזהות אם זה איזשהו . . . שוב פעם, ‘חתול או כלב’, ‘ספינה או ספינת אויב או לא ספינת אויב’, אני יכול לקבל הרבה יותר החלטות חכמות”אבל מצד שני, AI, כמו שאנחנו יודעים, דורש משאבים - משאבי-מחשוב הרבה יותר משמעותיים.ופה האתגר הכי גדול של העיבוד בקצה - איך אני מצליח להביא יכולות עיבוד יותר, הייתי אומר, “חזקות ומשוכללות”, שבעצם AI צורךאבל עדיין שומר על עלויות.למה עלויות הן מאוד מרכזיות בזה? אז אתם תעשו את המכפילים . . . .ב-Verizon למשל, יש לך, רק על היחידות של ה-5G, יש לך בערך 30 אלף יחידותאז כל דולר שם, אם אוטומטית תוסיף אותו, תכפיל אותו ב-30 אלף - אתה מגיע למספרים מאוד גדולים.הם הראו שרק ה-Efficiency של Energy - זאת אומרת, היכולת שלי לחסוך ב-Energy שם - הוא כבר 70% מהעלות של להחזיק רשת היוםוהיכולת לחסוך שם - היא הופכת להיות מאוד משמעותית.אז המכפילים משנים את כל המודל ה-Economy של הדברים מהסוג הזהולכן האתגר פה הוא לא רק איך להעביר את העיבוד לקצה - אלא איך לעשות את זה עדיין בעלויות שהן יחסית נמוכות.וזה מייצר איזו משוואה, שהיא יותר מורכבת, בוא נגיד, מהדברים האלה - וזה גורם לאבולוציה . . . . או שלא הייתי קורא לזה אבולוציה - להתפתחות שהיא כמעט התפוצצות, במידה מסוימתשל הרבה מאוד, מצד אחד, GPU חדשים ו-CPU חדשים, ו-Hardware מסוגים שונים, שהוא מאוד Optimized ל-Workload מסוים[אוקיי, לעצור הכל ולהקשיב לזה - The GPU Song (GPUs Are Fire)]וזה מייצר הרבה מאוד פרגמנטציה (Fragmentation) בקצהזאת אומרת, אם בעולם ה-Data Center יש איזו “מוגנות” מסוימת - זאת אומרת, יש לך וריאציות, אבל אתה מגיע ל”גג”, כמה סוגים של XL, Medium וכאלה, עם קצת וריאציות.בגלל המתח הזה, שבין עלות ל-Performance, כל הזמן יוצאים עכשיו Device-ים חדשים.זה מזכיר נורא את מה שקרה ב-Mobile Phones, ב-Smartphones, בדור הראשון שלו, פחות או יותר.(רן) כל מי שמפתח אפליקציות יודע שאם הוא מפתח ל-Android, אז זה ג'ונגל . . .(נתי) נכון . . . .(רן) וב-iOS זה קצת יותר קל, אבל עדיין די מאתגר - יש המון רזולוציות, המון סוגים של Capabilities . . . לפעמים יש לך SIM, לפעמים אין לך SIM, לפעמים יש לך גישה ל-Gyro, לפעמים אין לך - אבל אתה צריך לקחת בחשבון המון המון וריאציות.וזה מאוד מאתגר, בתור מפתח אפליקציות . . . .(נתי) ואני אומר שזה רק הולך להחריף . . . כי אני אומר - המתח הזה בין להצליח להגיע לעלות וביצועים מאוד גבוהים . . . אז אני אומר - אנחנו נמצאים פחות או יותר בדור הראשון של ה-iPhone, בעולם של הקצה.ועכשיו הגל הזה מתחיל לקרות, עד שהוא יגיע לרוויה.אני חושב ש-iPhone 14, שלא יודע אם שמעתם את הסיפורים עליו, כבר מגיע - שהם מנסים לסחוט עכשיו את הכסף דרך הבטריה . . . אנחנו מאוד רחוקים מזה - ואני מעריך שבשנים הקרובות, אפשר לראות את זה במניה של nVIDIA, זה הולך להמשיך להתפוצץ, עוד הרבה הרבה שנים קדימה.14:29 רץ על הקצה(רן) רגע, אבל שנייה - לא הסברנו מה זה Inferencing . . . .(נתי) אז Inferencing זה בעצם . . . המילה הכי פשוטה בעברית לזה היא בעצם “עיבוד בקצה”יכולת לזהות אובייקטים בצורה אינטליגנטית.בסופו של דבר, אם אני אחזור חזרה למודלים של AI, אז יש ב-AI שני חלקים:יש חלק אחד של Training.ויש חלק אחד של עיבוד.החלק של ה-Training זה המערכת  . . . .אני אלך אולי צעד אחורה, למי שהמושג AI וכל המודלים האלה של Training ומודלים הרבה פעמים מבלבלים אותובסופו של דבר, התוספת - השינוי הגדול שה-AI הביא - זה במקום, לצורך העניין, לעשות שאילתא ולקבל תשובה על מה שאני שואל, אז זו יכולת לקבל “קירוב של תשובה”.והאינטליגנציה היא בדיוק במילה הזאת, “קירוב”שזה ה-Vector Database וכל מיני דבריםשבעצם מאפשרים לי להגיד “אין לי את מה שאתה מבקש - אבל אני יכול לתת לך משהו משוערך”.אז חלק מזה בכתיבת טקסט - אני עושה Prediction למילה הבאה שאתה תכתוב.חלק מזה בעיבוד תמונה - אני יודע מה הפיקסל הבא שאתה תראה.ומשם בעצם מתפתח עולם שלם של אלגוריתמים, של בעצם . . . . הם כולם צופים את מה זה ה-Next step הזה בתמונה; מה זה ה-Next step הזה בכתיבה; מה זה ה-Next step הזה . . . .והרבה פעמים ה”הסקת מסקנה” הזאת - היא בנויה על תהליך שנקרא Training או Reinforcementכל מיני תהליכים שבסופו של דבר, מאפשרים למערכת לעשות את ה-Prediction הזה בצורה יותר מדויקת, ולאפס את המשקולות.(רן) אז Inferencing עושה כמו Serving . . . (נתי) נכון, אז אני אגיד אותו - ואני אחזיר חזרה את זה לעולם של AI והחלוקה בין Training לבין Inferencingכי Inferencing, בדרך כלל, זה כבר תוצאה של Trainingזאת אומרת, לקחתי את החתול וכלב, הרצתי הרבה מאוד תמונות, אם אני עושה תהליך של Reinforcement או תהליך של Data שנכנס למערכתהרצתי הרבה מאוד תמונות כאלה, הגעתי למשקולות הנכוניםויש לי עכשיו כרגע אלגוריתם, שיודע לקבל תמונה ולהגיד אם זה חתול או כלב.עכשיו, הרבה פעמים, האתגר הבא שלי, למי שמכיר את TensorFlow - אז יש TensorFlow ויש TensorFlow Lite זה גם לקחת את המודל הזה - וגם להקטין אותו, כדי שהוא באמת יוכל לרוץ ביחידות-קצה, קטנות יותר.ואז בעצם מה שיקרה בתחנת-הקצה זה תהליך יחסית פשוט - Input שנכנס זה תמונה ו-Output שאומר: קלאסיפיקציה (Classification) -זה תמונה כזאת, זה תמונה כזאת, זה תמונה כזאת . . . . וזה נקרא Inferencing - המילה Inferencing, או “Edge Inferencing", הוא בעצם אומר “אני לא עושה את ה-Inferencing ב-Cloud, אני עושה אותו בקצה”.אז כשמו - כן הוא: זה בעצם יכולת העיבוד בקצה.כמו שאמרתי, מאחוריו מסתתר עולם שלם של טכנולוגיה - של איך מביאים את הדיוק הזהמצד אחד, של העיבוד, Cost, אנרגיה - כל הדברים הללו איכשהו  צריכים להסתדר, ויש המון המון קונפליקטים בתוך הדבר הזה.ולכן נהיה פה עולם חדש ומאוד מעניין, שמתחיל להיווצר - של סטרטאפים, של יצרני חומרה, של . . . . לא רק “nVIDIA-יות” לצורך העניין.17:32 “אחת-לשכחתי” ופרטיות בקצה(אורי) אז יש לנו באמת, לא יודע מה - Lightricks, שמזהים ועושים עיבוד של התמונה במכשיר שלנו, או Augury, שעושים את זה ב-Device-קצה, ב-Sensor בעצם . . . . .אבל קודם כל, השאלה היא  האם זה פתר לנו באמת את הבעיה? כי המודל, קודם כל, צריך “לדחוף אותו” - אז אנחנו מסתמכים על זה שאנחנו דוחפים מודל “אחת-לשכחתי” . . . .(נתי) נכון . . . (אורי) . . . כי אם אתה צריך לדחוף מודל כל הזמן, אז . . . .(נתי) אז זהו, אז הקצב עדכון מודל אמור לקטון עם הזמן, כי מתישהו הוא מתייצב, ואז בדרך כלל אתה תעדכן מודל כשאתה רוצה להוסיף אובייקטים, או שיש איזה Drift למודל  . . . .(אורי) זה נכון באפליקציות מסוימות, שבהן . . . . “חתול” ו”כלב” כנראה לא ישתנו בזמן הקרוב . . . (נתי) נכון . . . .(רן ) “אפליקציות אבולוציונית”, נקרא לזה . . . (אורי) כן - אבל למשל, מהעולם של Outbrain: עולם החדשות משתנה כל הזמן . . . .(רן) בסדר - אבל לא כל דבר, לא כל Inference נכון שיהיה בקצה . . . .(אורי) לא, לא . . . נכון, אבל אני אומר - אתה צריך להבין למה זה מתאים, וזה כנראה לא מתאים ל . . .(רן) .  . . ה-”Freshness” של מודל . . . . הFreshness של המודל זה פרמטר - בין הפרמטרים האחרים שנתי הזכיר. .  . . (אורי) נכון . . .  לצורך העניין, Outbrain . . . (נתי) האמת שאיתגרת אותי עכשיו . . . .  אני חושב עכשיו על האתגר שאמרת . . . .באמת על משהו שהוא בעצם כל הזמן . . . הקלסיפיקציה (Classification) שלו משתנה בעצם . . . . (אורי) Outbrain מלמדת מודל כל חמש דקות, אוקיי . . . .(רן) ובוא אני אוסיף לך עוד פרמטר, שאני חושב שאתה גם מכיר - Privacy : היכולת להשאיר Data של המשתמש - אצל המשתמש. זו יכולת שהיא מאוד חשובה. הצורך להביא את ה-Data של המשתמש לתוך ה-Data Center אמנם עושה את עבודת ה-Machine Learning יותר קלה - אבל גם מסכנת את ה-Privacy של המשתמש. ובאמת, יש לא מעט . . . אני ראיתי חברות עם מוצרים שממש מתעסקים בתחום הזה - של לעשות Inferencing בקצה, אך ורק לצורך שמירת Privacy.הם גם בונים את המודלים בקצה, לצורך העניין . . . .(נתי) כן . . . אה, את אומרת גם את ה-Training?!(רן) כן, גם ה-Training קורה שם, במידה מסוימת . . . .(נתי) וזה, אתה אומר, מסיבות של Privacy?(רן) כן . . . . אפשר לעשות גם Training שהוא מבוזר - זאת אומרת, חלק מה-Data כן מגיע לענן, אבל לא הכול. אבל כן . . . (נתי) זה Distributed Training . .(אורי) זה כשה-Training מתבצע על Sampling ? . . . (נתי) לא - הוא כל הזמן בעצם, “מערכת לומדת” כזאת, שבעצם . . . (רן) . . . אז או שה-Data . . . או שה-Training ממש נעשה בחלקו על ה-Device, או שאתה מעביר ל-Data Center . . . (נתי) . . . שקרוב ל-Device . . . (רן) . . . . Data שהוא אגרגטיבי (Aggregated), שהוא Anonymized וכו’ - ואז כן, ה-Training נעשה ב-Data Center. אבל עדיין - יש לך פה Risk.אז אני אומר - גם השיקול של Privacy, ובטח יש עוד שיקולים אחרים למתי לעשות את ה-Inference בקצה או לא בקצה.20:39 תשתית מודרנית של עיבוד(רן) אז כאילו, אלה השיקולים, נקרא לזה, “העסקיים” . . . (נתי) נכון.(נתי) עכשיו - אני מסתכל על זה ברמה של איך נראית, בדרך כלל, היום תשתית מודרנית של תהליך כזה של עיבוד.אז יש לך בעצם, בקצה, יש לך את ה-Deviceתמיד יש עליו איזשהו Software.היום ה-Software הוא בדרך כלל משלב יכולות AI.ו-Streaming לתוך איזשהו . . . זה מה שנקרא “Far Edge” ו-”Near Edge” - ו-”Center”.זה מתחלק לשלושה Tier-ים, שבעצם כשמם כן הם . . . אבל הם ביחס שמה-Data Center החוצה.אז Far Edge - זה אומר שהוא קרוב לקצה.זאת אומרת, זה אומר שהוא  הוא Near to the Edge - אבל רחוק מה-Data Center(אורי) . . .  מה שנקרא “The last mile” . . . (נתי) כן, בדיוק . . . אז “Last mile” זה מושג יותר, הייתי אומר, “נפוץ”, מעולם ה-Networking וכו’.והיום, בעולמות של Datacenter-ים מבוזרים, אז קוראים לזה “Far Edge” ו-”Near Edge”כש-Far Edge, בדרך כלל, מייצג יחידת עיבוד בינונית, או אפילו קטנה.ו-Near Edge הוא ממש Data Center.אם תסתכלו על זה, בדרך כלל, נניח בעולמות של TelCos, אז קוראים לזה “NFL Cities”זאת אומרת, זה מרכזים שהם Hub-ים, שיש בהם, יחסית, ריכוז גדול של אוכלוסייה.אז למשל, הרבה פעמים ה-Telcos יהיו מפוזרים . . . הסיבה שקוראים לזה “NFL cities” זה כי האיצטדיונים איכשהו פזורים באופן לא אקראי, במרכזי אוכלוסין גדולים . . .  אז יש קורלציה.אז ה-Far Edge - הוא קרוב ליחידת-קצהויש לנו את ה-Functional Edge - זה ממש ה-Device עצמו, המצלמה, או ה-Sensor . . .(רן) הטלפון, השעון, הטלווזיה . . . . [ואז זה Photo-Far-Edge? #סליחה]נתי)   . . . הוידאו . . .  בדיוק, כן.אז ה-Far Edge . . . עכשיו לפעמים יש Far Edge שהוא גם ה-Functional Edge, אבל הרבה פעמים הם שתי יחידות שונות.(רן) אז Far Edge - זה יכול להיות “המכולות” שנמצאות מתחת לאנטנת סלולר . . . (נתי) בדיוק, נכון.(רן) . . . זה יכול להיות כל איזה 70-100 קילומטרים . . . .(נתי) נכון, וזה בעיקר . . . (אורי) ה-CDN-ים מתחילים לתת שירות כזה, של Processing . . . .(נתי) זו נקודה סופר-חשובה - היום יש, מה שנקרא היום WebAssembly גםמי שלא שמע [את 351 Bumpers 52, למשל] - אז זה סוג של טכנולוגיה, שבעצם בעיקר נפוצה ב-CDN-ים מודרנייםשבעצם מאפשרת יכולת גם של הרצת קוד עם ה-Dataוזה באמת נועד לעשות איזושהי לוגיקה של Streaming, עיבוד . . . (רן) כן, נכון - רק לא WebAssembly - WebAssembly זה ממש בתוך הדפדפן . . . (נתי) כן, לא - אבל יש טכנולוגיה של Web Assembly, שהיום יודעת לרוץ, ממש ב-Storage.תיכף אני אזכר בחברה שאנחנו עובדים איתה היום ש . . .  Fastly, למשל.אז  Fastly עושים הרבה שימוש ב-WebAssembly לעיבוד בקצהכי תחשוב - כשאתה עושה Streaming ואתה אומר “אוקיי, עכשיו אני רוצה לעשות קליפ, או אני רוצה לעשות . . .  רק לסנן את התמונה, או לסנן את . . . “אני יכול לעשות הרבה מאוד מהדברים האלה - איפה שה-Data נמצאואני לא צריך לשנות ולשמור עוד Storage בשביל הדבר הזהאני פשוט יכול ב-Real-Time לשנות את התמונה - ועדיין להשאיר עותק אחד של זה.(אורי) אני חושב, אני לא יודע אם . . . . כאילו, הרבה זמן Fastly היו היחידים שנתנו את השירות הזה, של Edge Computing - וגרפו לא מעט Business.(נתי) נכון, הם הפכו את זה . . . . הם הפכו את הטכנולוגיה למשהו שהוא יחסית כבר . . . ממש יש WebAssembly ל-Edge.כאילו, ה-WebAssembly הזה - שהוא גם, מן הסתם, זו יכולת להריץ את זה ב-Footprint מאוד קטן, באנרגיה מאוד קטנה,זאת אומרת, הוא מאוד יעיל, יחסית נניח לעולם של Kubernetes, ש . . . 24:10 מערכת ניהול - Orchestration & AI - ורעיון לסטארטאפ הבא(נתי) שנייה, בואו נלך צעד אחד אחורה . . . .אז דיברנו על מושגים של Functional Edge ו-Far Edge ו-Near Edge ו-Data Center.(רן) . . . בקטגוריה הזאת . . . .(נתי) בקטגוריה הזאת . . . (רן) ו-Near Edge?(נתי) אז הם, בדרך כלל, יהיו “Near-too-Far”  . . .  זו נקודה נכונה, כי CDN-ים בדרך כלל יהיו איפשהו באמצע בין Near ל-Farכי הם כן יחסית פזורים גיאוגרפית קרוב ל-Latency של הלקוח.אבל מצד שני, הם לא “Near” - שזה מעט מאוד Data Center-ים יחסית . . . (אורי) זה הרבה Data Center-ים קטנים.(נתי)  . . . זה הרבה Data Center-ים קטנים . . . - אז הם איפשהו באמצע, אני חושב, יותר קרובים אולי ל-Far מאשר Near.(אורי) אולי PoP יותר . . . (נתי) נכון, נכון - אז בגלל זה אני אומר: הם איפשהו באמצע, אני חושב, בין Near ל-Far, אני מדמיין Far כמשהו שהוא ממש “במכולה”, מתחת לזהו-CDN הוא איפשהו באמצע.אז איפה הייתי? . . . (נתי) אז עכשיו הגדרנו את המושגים של איך נראית ארכיטקטורה End-to-End של יחידת הקצה.על זה יש לנו, בדרך כלל, מערכת ניהול, שזה Orchestrationשבעצם, עכשיו יש לי הרבה מאוד יחידות קצה - איך אני עושה Continuous Update? איך אני מעדכן את המודלים? איך אני מנהל את הדבר הזה? . . .  אז זה רכיב נוסף שיש עליו.ויש, כמובן, מערכת AI מרכזית - שהיא אחראית גם על ה-Training של המודל ועדכון שלו אחרי זה ביחידות-הקצהוגם אחרי זה - לקלוט את העיבודים מיחידות הקצה, ולהתחיל לעשות קורלציות ולזהות טרנדים שהם Cross-Devices, Cross-Regions וכאלה דברים.(אורי) זה אחד העניינים . . . כי כולם רוצים לנטר, אוקיי? ולעשות כל מיני Inferencing שהוא Cross וזה וזה - ובסוף אתה מוצא את עצמך שולח יותר Data ממה שהתכוונת . . . (נתי) אז זה האתגר . . . .אני חושב ש... (אורי) רק על ה-Monitoring ועל הדוחות . . . . (נתי) אני חושב שלכל יזם היום ששומע את זה - צריך לקפוץ לו איזשהו רעיון לסטארטאפ הבא . . . .יש פה הרבה מקום ליזמות בעולם הזה - כי באמת הוא ב-“iPhone 1”, פחות או יותר  . . . . איפה שאנחנו נמצאים היום בעולמות האלה.וזה גם שילוב של AI וזה גם שילוב של אתגר של Compute . . . בקיצור, זו צומת-דרכים שיש בה הרבה מאוד אתגרים שמשתלבים ביחד - וזה שווה-ערך להרבה מאוד הזדמנויות.וזה אני חושב ככה, מקום שאני ככה, מתעסק איתו יחסית הרבה בזמן האחרוןותיכף אני אגע באמת איפה אני מתעסק ומה אני עושה שם - אבל רציתי קודם לתת איזושהי תמונה כללית לאיך שנראה היום בעולם הזה ולמה הוא נושא שהפך להיות מעניין פתאום.26:50 קול-קורא לתשתית גנרית ו-Edge-as-a-Service(רן) בסדר, אז בואו, אולי נדבר לך על איזשהו Use Case, או שנדבר על מה שאתה עושה ביום-יום . . . (נתי) כן . . . .אז אני, בלי לציין שמות לקוחות, כי אני לא יודע אם מותר לי, או בואו נגיד רוב הסיכויים שאסור לי . . . אבל אני נמצא היום, מי שלא מכיר - הייתי ה-CTO ו-Founder של Cloudify - ו-Cloudify נרכשה על ידי חברה שקוראים לה Dell, שרובכם מכירים כבר . . . .(אורי) חברה קטנה . . . (נתי) חברה קטנה, כן . . . .אז בתור חברת חומרה, היתה להם בעבר זרוע שנקראת VMware, הם מכרו אותה בהרבה מאוד ביליונים ל-Qualcomm [אני חושב שזה היה ל-Broadcom . . . ]והם נשארו קצת בלי השכבה הזאתו-Edge הוא איזשהו Extension או Growth Engine טבעי, שאמור . . . . שהם בעצם נכנסים אליו.ואנחנו ממלאים את החלל של מערכת הניהול של יחידות הקצה האלה, וחיבור שלהן גם לשכבות של הענן.לצורך העניין, זו היכולת באמת לחבר את ה-Near ואת ה-Far ואת ה-Cloudולתת איזו מוטת-שליטה אחידה בין כל היכולות האלה.(רן) אז אתה לא מוכר Laptop-ים  . . . .(נתי) אני לא מוכר Laptop-ים, לא . . . . ממש לא.(אורי) חשבתי אולי להחליף . . . .(נתי) אז בעצם האתגר הוא . . . אם תחשבו על זה,  יש כמעט היום, בהרבה מאוד מהרצפות ייצור ומה-Datacenters ובבתי חולים, איזשהו מחשב Dell שיושב שםשמנותק כזה ומאובק  . . .ומדי פעם בא איזה טכנאי, שעושה לו איזה . . .  מכניס USB ומעדכן אותו.והאתגר הוא בעצם להעביר את זה ליחידות המודרניות האלהשזה בעצם אומר שהוא כל הזמן מחובר, הוא כל הזמן מנוהל, יש לך מוטת-שליטה מרכזית, שדרכה אתה בעצם יכול לנהל את כל הדבר הזה.אז אני מתעסק עכשיו בזה - ומן הסתם, היות ו-AI נכנס לקצה, אחרי מה שדיברנו ב-Inferencing, אז בעצם אנחנו גם מנסים לתת מענה לתוך הדבר הזה.אבל - וזו הנקודה שאני חושב, שמחברת את מה שאמרתי קודם לזה - המקום שאנחנו עוצרים, זה באמת לייצר איזשהו משהו, שאני חושב שהוא קצת חדש, בזה שאנחנו רוצים לתת תשתית גנרית, שתאפשר לכל מי שרוצה לתת “שירותי Inferencing”, לבנות אותו על התשתית הגנרית.דומה למה שה-Cloud עשו ל-Data centers.זאת אומרת, אם בעבר אמרו, בעיקר לסטארטאפים בעבר, “אתם תתרכזו בלבנות SaaS ואת ה-Business Logic שלכם - וה-Data Center עלינו” . . . (רן)  . . . . [?!Inferencing at the Edge - as a Service . . . . [IatEaaS?(נתי) כן, רק שאני לא אתן את ה-Inferencing, אלא אני נותן את התשתית, עד השלב Inferencing:כל מיני Stack-ים שהם Optimized לזה.(רן) אז Edge as a Service . . . . [אז EaaS? יותר טוב, עדיין קשוח . . . .](נתי) Edge as a Service, זה יותר קרוב לזה . . . זה שהוא “Inferencing-Enabled“, נקרא לזה ככה.(רן) לא הגיטריסט, היינו צריכים להגיד . . . . [אעפ”י שזה דווקא רעיון לא רע . . . .](אורי) אבל הרעיון הוא - נגיד, של החברה הקטנה הזאת, Dell - לתת בסוף, כאילו, Motherboard, לשים אותו בתוך ה-Edge-Device שלך?(נתי) אז הרעיון הוא, אני אומר . . . זה מאוד דומה למה שקרה בעולם ה-Datacenter-ים, לסטארטאפים.הרעיון בא ואומר כזה דבר - להפיץ את החומרהאני זוכר שדיברתי עם ה-CTO של איזו חברה, ברח לי השם שלו כרגע, ואז הוא תיאר לי את הכאב-ראש שיש בדבר הזה.(אורי) גל? זה גל?(נתי) גל! נכון, בדיוק.אז להתקין עכשיו חומרה אצל לקוח, לחבר את זה לענן, לדאוג לזה, לעשות Continuous Update לתוך הדבר הזה - זה כאב ראש  . . . מי צריך עכשיו להתעסק עם כל התהליך הזה של ה-Shipment והתקנה וכאלה דברים?(רן) “לך תתקין Datacenter חדש בקופנהגן . . . “ למה שתעשה את זה? לך תשכור  . . . . [ודווקא לשם עוד תמצא מתנדבים . . . ](נתי) בדיוק, בדיוק.אז הרעיון הוא של-Dell לצורך העניין במקרה הזה, יש כבר את הרשת Distribution, הם כבר יודעים להפיץ את החומרהועכשיו מה שאנחנו מוסיפים, דרך האינטגרציה (Integration) של Cloudify, לתוך המוצר הזה שנקרא NativeEdge, זה בעצם את ה-API ל-Developers, שיכולים עכשיו לגשת לזה כמו אל עוד יחידה בענןובעצם להתרכז בכתיבת התוכנה.(רן) כן, אבל אתה עדיין צריך מחשב בכל רצפת ייצור, אתה צריך “מחשב בכל מפעל” . . . .  (נתי) נכון . . . אז יש . . . .(אורי) לפעמים זה לא “Device” - זה יכול להיות מצלמה . . . .(נתי) נכון.אז אני אומר, יש פה שתי שכבות של Device-ים - יש שכבות שהן כבר מה שנקרא “צבועות” Dell, שהפכו אותן ל-Device-ים ל-Edgeשהן Optimized מבחינת מחיר ויכולותויש “3rd-party Device”, שזה משהו שיחסית חדש שעובדים עליושבעצם זה סוג של Bring Your Own Deviceמתוך הנחה שבגלל שיש פרגמנטציה (Fragmentation) כזאת בשוק, אז אין שחקן אחד שיהיה לו את כל ה-Portfolio של מה שלקוח צריךאו לצורך העניין, השחקן או החברת סטארטאפ שצריכה עכשיו לתת - הרבה פעמים תיהיה לה “דעה” למה “צריך” להיות בקצה - בגלל שיש פה תחרות.לצורך העניין, אם אני Mobileye, אז מאוד חשוב לי שה-Device הזה יהיה $6, קופסא קטנה כזאת שיושבת במכונית, והוא חייב להיות $6 - כי אם הוא לא יהיה $6 , אז אני לא יכול להכניס אותו לקווי-הייצור של המכוניות . . . וזה - אין “שחקן אחד שיכול לשחק על כל המגרש”.ולכן מאוד חשוב פה לבנות את זה בצורה כזאת, שהיא פתוחה ל-Ecosystemוכשה-Ecosystem מתחלק ל-3rd Party Devices ויכולת Bring Your Own Device,כאילו להביא את היכולות שלך לתוך המערכת - ועדיין שתיהיה לך את אותה מוטת-שליטה,ומצד שני, שיהיה לך המקרים הגנריים, איזשהו פתרון גנרי, שלא תצטרך בכלל לחשוב על הדבר הזה.אז אני מתחיל להתעסק עכשיו בתוך הדבר הזה, ויש פה, ובאמת - זה סוג של “קול קורא” אם תרצו, לאנשים שמתעסקים בתחום הזהאני בעיקר מעוניין לדבר, לא למכור בטוח . . . אבל בעיקר לדבר ולשמוע איך אנשים אחרים חושבים על הבעיה, מתעסקים עם הבעיה . . . באיזה חברות יש בארץ ומה שהן מתעסקות עם זה . . . (רן) בוא, תן לי רגע לחדד ולאתגר - בעצם, מה שאתה בונה, מה שאתה מתאר שאתה בונה,  זה Compute at the Edge, זה לא בהכרח Inferencing at the Edge.זאת אומרת, אתה בעצם מאפשר להריץ איזשהו Workload, כנראה סטנדרטי, כי ה-CPUs הם די פשוטים - לא בהכרח Inferencing, כי Inferencing, בדרך כלל יש לו אתגרים משלו: זה בדרך כלל, בהרבה מקרים, צורך GPUs, ו-Data . . . (נתי) נכון, אז מה שאני . . .  אתה צודק לגמרי.מה שאני כן נותן, זה למי שבונה פתרונות Inferencingזאת אומרת, (א) ה-GPU כבר Built-in, ונניח אם אנחנו באחד ה-Stack-ים באים עם Kubernetes, אז אנחנו דואגים שה-Stack של Kubernetes - בדרך כלל זה יהיה K3s[להרחבה - 394 Rancher with Lior Kesos]אבל זה יכול להיות כל Kubernetes שהוא Optimized לרוץ ב-Footprint נמוךוכבר יהיה Tuned לתוך ה . . . לעבוד עם ה-nVIDIA GPU או עם ה-Qualcomm GPU או עם כמה מהיצרנים ש . . . (אורי) אבל בעצם, מה שרן אומר זה ש-Inferencing הוא אחד ה-Use Cases של Compute at the Edge  . . . (נתי) נכון - רק שזה כבר לא . . . זה הופך להיות כמעט . . . Use Case שכמעט אי אפשר לחשוב על יחידת-קצה בלי Inferencingכי אתה רוצה את היכולת לזהות מהר דברים ואתה רוצה את ה-Latency ואתה רוצה את ה . . . (רן) . . .  זה אולי אחד - אבל הכי חשוב, ואולי גדל . . . (נתי) הכי גדל והכי חשוב - ומדברים על, אני לא זוכר אם זה 11 או 12 ביליון דולר עד 2027 . . . (אורי) אני חושב שהוא פשוט “הטריוויאלי ביותר” להעברה מה-Center ל-Edge . . . (נתי) נכון, בדיוק . . . (אורי) . . . . כי פשוט הרבה דברים אחרים עושים ב-Edge . . . (נתי) נכון לגמרי. אני חושב שסיכמת את זה מצויין . . . זה ממש מדויק - כי באמת לפני כן, תמיד הייתה את השאלה אם אני אשים Device “טיפש” ועושה את כל העיבוד בענן - או לא עושה את העיבוד בקצה.וה-Trade-Off היה לא כזה חד וברור.(אורי) אני חושב ששווה להסתכל על כל המערכות הצבאיות, לצורך העניין, שגם מסיבות של . . . אני לא יודע, בחיל הים קראנו לזה “מפ”א קשוח” - “מדיניות פליטה אלקטרונית קשוחה”: אסור לך להעביר תקשורת, אז אתה חייב לעשות את כל ה-Compute אצלך . . . (נתי) כן, אני זוכר ש . . . (רן) בצוללת יש GPU? . . . (אורי) מה?(רן) בצוללת יש GPU?(אורי) כנראה שכן . . . [ביטחון מידע!](נתי) אגב מערכות בקרת-אש - אני זוכר שדיברנו פעם בעברי, היה לנו פרויקט מול חיל הים, אז מערכת בקרת-אש - אתה יכול להבין ש-Latency שם הוא . . . אז היה לנו בעיה ש . . . נניח, עבדנו עם JVM לחלק מהדברים, אז בגלל . . . .(רן) Garbage Collection . . . .(נתי) כן, בגלל Garbage Collection, היה מדי פעם - פעם בעשרת-אלפים פעמים - היתה איזו קפיצה של Latencyוזה הרג את הפרויקט הזה בסוף . . . כי המערכת חייבת להיות גם עם Latency נמוך - אבל גם מאוד דטרמיניסטיתכי אתה לא יכול . . . אתה לא רוצה שעכשיו יהיה לך איזה Drone שרץ אליך, ופיספסת בדיוק בשנייה להפעיל את המערכת-בקרה הנכונה - ובסוף חיסלו אותך בגלל זה . . . (אורי) אני חושב שבמערכות צבאיות, כתפיסה - הן צריכות להיות לא מחוברות, Independent, וזה וזה וזה . . .  ויכול להיות ששם יש . . . (נתי) היום ספינה, למי שלא מכיר - ספינה היא חתיכת Data Center . . . בטח ספינה צבאית, אני לא מדבר בכלל משחתות וכאלה . . . וצוללות וכאלה דברים . . .זה כבר ממש Data Center חכם, עם הרבה מאוד יכולות עיבודבגלל כל הנושא של ל”א [לוחמה אלקטרונית], מערכות בקרה . . . זה כבר לא הדברים האנלוגיים שראינו.(אורי) הייתי לפני שבועיים בביקור בסער 6 - כן, זה לא . . . (רן) מה זה - סטי”ל?(אורי) כן, זה סטי”ל - מהסטי”לים האחרונים. המי”ק - המרכז ידיעות קרב - זה . . .  בוא נאמר, צריך מערכת מיזוג מאוד מאוד משמעותית כדי לקרר את הספינה הזו . . . (נתי) אז אני חושב שזה באמת דוגמאות מאוד טובות לשימוש - אבל אני בכוונה לא הלכתי למקומות האלה, כי זה קצת רחוק להרבה מהאנשיםכי זה באמת מייצר את ה-Cutting Edge, נקרא לזה ככה, אם אני אשתמש במושג Edge . . .(רן) “לחתוך את הקצה” . . . ויש הרבה יותר, כן . . . . יש הרבה יותר מקרים שהם . . . הייתי קורא לזה יותר “Mainstream”, שאנחנו חשופים אליהם היוםקחו רק בתחום ה-Manufacturing, רפואה, אנרגיה . . . אז באנרגיה יש לך היום הרבה מאוד קולטים של שמש, סולארייםועכשיו צריך לנהל את הדבר הזה . . . יש חברה אגב, SolarEdge, שנמצאת בארץ, שמייצרת את הדבר הזהאז הטרנד היה שכל חברה כזאת הייתה צריכה גם לבנות את המערכת ניהול שלה - וזה תקורות מאוד גדולות.(אורי) תאר לך ש-SolarEdge לא הייתה עושה את זה ב-Edge . . . .(רן) . . . או לא הייתה משתמשת בשמש . . . (נתי) לגמרי . . . (אורי) אבל לא נראה לי שחסר להם אנרגיה . . . (נתי) אז אני חושב שבגלל שזה הופך להיות נחלת-הכללושוב פעם, אני אתן את הדוגמא למה שקרה שה-Datacenter-ים עברו לענן - זו מגמה מאוד, לדעתי, דומה.המקרה הזה של Edge הופך להיות צורך מספיק גנרי - שעכשיו חייבים להוריד את החסמים של כניסה אליו.והדרך להוריד את החסמים זה את כל ה-Distribution הזה, וניהול של Distribution וניהול של חומרה, וניהול של זה . . . . צריך להיות מאוד דומה לאיך שאנחנו מתנהלים בענן.זו, פחות או יותר, השכבה שאני חושב שחסרה כרגע - כדי שבאמת כל יצרני ה-Inferencing וכל מי ש . . . כל סטארטאפ שעכשיו רוצה לבנות מנוע AI, שיודע להחבר Sensor לאלגוריתמים ולמודלים שלו, יוכל לעשות את זה בתקורות הרבה יותר נמוכות מזה שהיום רק יצרנים מאוד מאוד גדולים יכולים לעשות כאלה דברים.ופה אני אומר - יש פה איזה חיבור שיכול להיות מאוד מעניין,אני מאוד מקווה שאני אוכל למצוא עוד אנשים שמתעסקים בתחום הזה בארץ.(רן) אז הקול-הקורא שלך זה למעשה, לבוא ולדבר ולהכיר Use Case-ים, להכיר יזמים, להכיר אנשים שיש להם או צרכים כאלה, או שהם רוצים לבנות השתיות כאלה.(נתי) בדיוק, ממש ככה. ממש ככה, אני ממש מתעניין באמת.זה עולם חדש, אני לומד בו, אני לא . . . (אורי) עולם הרכב . . . (נתי) עולם הרכב -  ויש לנו אפילו עם Hyundai איזשהו מהלך מענייןבאמת בהקשר הזה, שהם מנסים - אני לא יודע אם זה יקרה, זה כרגע רק בדיבורים - אבל הם מנסים גם להפוך את זה לאיזשהו “Hub ל-Startup-ים” ישראלי שבעצם יקימו מרכז כזה ש-Startup-ים יוכלו להריץ את הפתרונות שלהם, ובעצם זה יהיה סוג של-Ecosystem שהם יוכלו להשתמש בזה כאיזשהו-Ecosystem, שאומר “אוקיי, זה כן מתאים לנו, לא מתאים לנו, אנחנו רוצים להשקיע בחברה הזאת, אנחנו לא רוצים להשקיע בחברה הזאת” . . .[לא מנסים - זה קיים כבר מ-2018, ד”ש לניר חן]אז ברגע שאתה מאפשר כזה דבר, אז פתאום אפשר גם להריץ פתרונות של מעבדות Innovation, ו-Ecosystem של Startup-ים  . . . 39:10 האם זו בכלל המערכת הנכונה?(רן) דרך אגב, נתי, יש משהו, פרט-טכני שקצת סקרן אותי מה שאמרת - אמרת שכדוגמא, משתמשים ב-Kubernetes כדי לשלוט על מערכות הקצה, אבל Kubernetes - יש לו את המגבלות שלו . . . .(נתי) נכון.(רן) . . . למשל, הגדלים של ה-Cluster-ים לא יעלו על . . .  לא זוכר, 5,000 Node-ים?(נתי) נכון.(רן) עכשיו טוב, בטוח שאפשר להנדס את הדברים האלה - אבל השאלה הנשאלת על זה היא האם זו בכלל המערכת הנכונה? למקרה . . . (נתי) אז (א) - בעולם של Scale - אני קורא לזה “Infinite Scale” - אתה מדבר על “פדרציה” (Kubernetes Federation) ולא על Cluster אחד שעושה הכל.אז הרעיון הוא שיש לך הרבה Cluster-ים ולא Cluster אחד.במקרה של Kubernetes, זה בעצם יש לך הרבה Cluster-ים ש . . .(רן) ועדיין - עדיין אתה צריך Pod-ים - זאת אומרת,  אתה באמת צריך את כל הסיבוך הזה של Kubernetes ש...(נתי) אז תראה - במרכז וב-Near, יש לזה עדיין . . .  היתרונות גדלים מהחסרונות.(רן) בסדר . . . .(נתי) כשאתה מתקרב ל-Far - זה כבר פתוח . . . .ואז אתה יכול . . . .  יש פתרונות כמו WebAssembly ולהריץ Functionalבטח ב-Functional Edge  זו כבר הופכת להיות שאלה מאוד מאוד פתוחה . . . .אני מעריך ששם אנחנו נראה פתרונות אחרים מ-Kubernetes, לתוך הדברים האלה.יש פתרונות שהם סוג של AWS) Lambda) ב-Edge, שמריצים רק JavaScript-ים ועוד דברים יחסית . . . שבעיקר מדברים עם החומרה ונותנים כל מיני פונקציות שעושות כל מיני קונפיגורציות (Configurations) על חומרהאבל לא צריכים לוגיקה מורכבת.(רן) אני מדבר על מערכת ה-Deployments, שתשלח את הקוד למחשב שנמצא “ברצפת הייצור” . . .. (נתי) אז כן, אז אני אומר . . .  אני חושב שבאמת באיזורים האלה של ה-Far Edge, אנחנו נראה טכנולוגיות אחרות . . .(רן) אבל זה לא משהו שאתם עובדים עליו? . . . (נתי) אנחנו כרגע כן מסתכלים על WebAssembly כאיזשהו . . . אחת מהטכנולוגיות האלה שיכולה, כנראה, לתת מענה לסיבות האלהכי ה-Footprint שלו (א') הוא מאוד נמוך והוא פורטבילי (Portable), בין הרבה מאוד Device-יםזאת אומרת, יש לו את התכונות של JVM - ומצד שני, אין לו את ה-Overhead של JVM.והוא גם מתקמפל (Compile) מאוד טוב ל-Binary, ב-Run-time ממש.אז יש לו הרבה מאוד תכונות שהופכות אותו, כנראה, למאוד אופטימלי - לא סתם Fastly בחרו ב-WebAssembly ומקדמים את זה כסוג של . . . הייתי אומר, “ה-Kubernetes ל-Edge” החדש.הוא לא דומה בכלל ל-Kubernetes כמובן, אבל בגדול זו התצורה.אז כן, אני חושב, וזו נקודה מאוד חשובה - שהיתרון של ההומוגניות של Kubernetes הוא כבר עומד בעוכריו ברגע שמגיעים לזהבגלל ההומוגניות, אנחנו משלמים הרבה מאוד מחיר על Complexityואנחנו משלמים הרבה מאוד מחיר על גמישות מאוד גבוההובקצה אנחנו כנראה נראה התפתחות של טכנולוגיות כמו WebAssemblyשהן יהיו מאוד מאוד Optimized לדבר הזה - וזה כנראה לא יהיה Kubernetesלפחות לא בתצורה שאנחנו מכירים כרגע.41:49 יש עוד יצרנים?(אורי) תגיד, נתי - חוץ מ-Dell, עוד יצרנים נכנסים לעולם הזה?(נתי) שאלה מצויינת [--> למה אתה מבאס?] . . .אז אני חושב שכמו שאני רואה את זה, אנחנו רואים את זה - אתם יכולים לדמיין שכל יצרן חומרה רואה את הדבר הזה, ומנסה לעשות עכשיו Hedging לתוך העולם הזה.(אורי) Hedging ל-Edge-ים . . . אז Hedging, אני בכוונה . . . No pun intended.אז יש לך החל מ-Intel, שבאים ומנסים לפתח Software Stack לתוך ה-Chip-ים שלהםוהיו להם הרבה מאוד ניסיונות כושלים בעבר להעלות Up the Stack . . .הם חושבים שהם יצליחו, אבל זה כיוון אחד.אז יצרני ה-Chip-ים - כולם מנסים לייצר, ליישר קו עם nVIDIA - כש-nVIDIA בעצם היו הראשונים שהלכו “Chip-to-Application”, או משהו כזה.אני לא זוכר בדיוק את הסלוגן שלהם, אבל הם עלו “Up the Stack” והם בנו ממש חבילה שהיא לא רק ה-Chip עצמו - היא ממש Optimized מהתוכנהלצורך העניין - “Kubernetes, עד ל-GPU”.ויש להם פלטפורמות שלמות - למכוניות, ל-Device-יםויש להם Ecosystem שלם שהם בונים.אז יש את יצרני ה-Chip-ים - Intel וכיוצא בזה.יש יצרני חומרה - כמו Dell, כמו HP, IBM - שמתחילים להיכנס לדבר הזהובעצם מוסיפים את ה-Layer של הניהולוכמובן אופטימיזציה (Optimization) ל-GPUוהם באים יותר למקום “ניטרלי” -  כאילו באים להגיד “אנחנו עובדים עם כולם” . . . “אנחנו נותנים לך General-Purpose Device”כמובן ששחקני ה-Cloud כבר שם מזמן, ברמה כזו או אחרתיש להם יתרון - וחיסרון.היתרון שלהם הוא שיש להם כבר את הביזור של ה-Datacenter-ים והם יודעים לעבוד עם הרבה מאוד Hardware.החיסרון הגדול הוא שיש רגישות מאוד גדולה לתחרות מהשחקני-ענן ביחידות-קצהכי זה ממש להיכנס ל-Business שלי ול-Data שלי וללקוחות שליולכן אני חושב . . .(רן) . . . הם מהווים את האיום הכי גדול . . . .(נתי) הם מהווים איום מאוד גדול - לאותם סטארטאפים ויצרניםכי באותה מידה שהם נותנים פתרון - הם גם יכולים לייצר את הפתרון בעצמם . . .ולכן אני חושב, שפה תהיה כניסה של שחקנים חדשים, שייתנו פתרון יותר ניטרלי - והניטרליות תיהיה . . . מי שייתן את המערכת היותר פתוחה - אני חושב שהוא זה שבסוף יזכה בנתח יחסית משמעותי בתוך המערכת הזאת.קצת דומה למה שקרה עם Datadog בעולם של Monitoring למשל, או Snowflake בעולם של Storageלא Storage, סליחה - בעולם של Data Warehouse.אז מי שיידע לפצח את הניטרליות הזאת ואת ה-Multi-Cloud  הזה, ולתת פתרון שהוא לא Bounded למישהו אחר - הוא כן יוכל לתפוס פה נתח משמעותי לדעתי.למרות ששחקני-Cloud, שבפירוש יהיה להם נתח לא קטן בתוך הדבר הזה . . . אבל יהיו הרבה - עדיין, בשונה מה-Datacenter-ים -יקח זמן עד שהם ישתכנעו “להישען” על ה-Cloudכיצרן - שהם ישענו עליו בתוך הפתרון-קצה שלהם.44:48 אז מה הולך בתעשייה היום?(רן) טוב, דרך אגב - אמרת שהיית בכנס בתחום, מה הכנס?(נתי) כן, אז הכנס - זה היה כנס פנימי של לקוחות, שבעצם כולם בנו פתרון כזה.אחד המעניינים בהם - אני כן אזכיר את השם שלו - Universalאתם מכירים - הוא בעצם סוג של “עולמות משחק”למי שיצא לראות - אז בעצם אתה בא לאתרים שלהם, ואתה נכנס לתוך סוג של “PlayStation מבוזר” עם הרבה שחקנים, ואיכשהו . . . (רן) זה קשור ל-Universal Studios? אוקיי . . . (נתי) כן, Universal Studios, בדיוק - ה-Entertainment Business שאנחנו מכירים.ושם, הרבה מהעיבוד הוא עיבוד-תמונה, ביחידות הקצהזאת אומרת, הם בעצם צריכים לעשות Streaming ב-Real-Time לתמונה - כדי לתת לך חוויה הוליסטית.ואז הם מייצרים סוג של חדרי-משחק כאלה, מנותקים פחות או יותר מהעולםזאת אומרת, זה ממש Air-Gapלמי שלא מכיר את המושג Air-Gap - זה אומר שהוא לא מחובר לאינטרנט, והם צריכים לתת באמת יכולת של ניהול של הרבה מאוד Device-ים מהסוג הזה.אז זו אחת הדוגמאות.היו שם כמה עשרות של לקוחות כאלה - וזה היה מאוד מעניין לראות כמה דברים:אחד, זה כמה מהם בנה את הפתרון בעצמו - מה שאומר שחסרה השכבה הגנרית הזאת שדיברתי עליה . . . כי היא איזשהו Void שקיים היום בשוקכמה לכולם התוצאה של הפתרון שהם בנו בעצמם - היא מאוד דומה . . . זאת אומרת - זה רק מחזק את זה שיש פה איזה שכבה של “80% גנרי” - ו-20% שהוא ספציפי.וכולם נתקעים בבעיות - שאני חושב שעוד לא חשבו עליהןשל איך באמת לוקחים את המשהו הזה שהם בנו - ומחברים אותו והופכים אותו למשהו שהוא מודרני Style-Cloud.אני חושב ששם אני רואה עדיין פער מאוד גדול בין סוג תעשיות מסויםלמשל, ה-Manufacturing הוא Lagging behindהאנרגיה - טיפה יותרו-eCommerce - מאוד חושב Cloud כבר, ו-DevOpsוממש אפשר לראות את ההבדלים בין התעשיות - באיך שכל אחד חושב על הבעיה ואיך הוא חושב על הפתרוןכמה הוא חושב על זה - זה נקרא  . . . .כאילו, בין אחד עם Silos ממשויש לו אנשי אופרציה, טכנאים שיושבים על הקצה ומחברים אותם ומחווטים אותם ואחראים על זה.לבין כאלה שאומרים “לא, לא - זה חלק מה-IT!”ואנחנו נמצאים באבולוציה הזאת  . . . אני חושב שדי ברור המגמה - זאת אומרת, בסוף, כמו שנתתי את הדוגמה של ה-Consumers ומה שקרה לעולם ה-Consumers, יקרה גם בעולם ה-Enterprise.בסוף, כולם יהפכו להיות Device-ים דיגיטלייםובשנייה שזה דיגיטלי ו-Software-Driven, אז אנחנו נראה . . . . אין שום סיבה שלא ננהל אותם כמו תשתיות ענן רגילות.47:30 סיכום(רן) בסדר גמור . . . אז סיכום קצר: אז דיברנו על Near Edge, Far Edge ו-Functional, נכון? . . . זה הרחוק ביותר . . . (נתי) נכון.(רן) ועל איך בעצם מביאים את התוכנה כמה שיותר קרוב ללקוח - או לפחות לנקודה שבה “נכון” להביא אותה, ולא רק ב-Data Center.ואתה מתעסק לבנות תשתיות שמאפשרות את זה . . .(נתי) נכון - ודיברנו על Cutting Edge, שזה מה שאני מקווה, רוב האנשים שמקשיבים לזה . . . .(רן) על Hedging Edge!(נתי) על Hedging Edge גם, כן . . . ונחזור ל-Living in the Edge  . . . [ובדיוק 20 שנה ל-Vulture Street ו-Rockin’ Rocks . . . .]שזה ישראל - ישראל 2023.(רן) לחזור לחיות את החלום.טוב, תודה רבה נתי! האזנה נעימה ותודה רבה לעופר פורר על התמלול!