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

• בלוג-פוסט של המפתח Matt Shumer, שנקרא Something Big is Happening התפרסם בלא מעט מקומות והיכה גלים.
• מעבר מסקפטיות מוחלטת ("זה בחיים לא יעבוד") למצב שבו המודל עושה את כל עבודת הקידוד שלו.
• נתי - מה שמעניין פה זה הניתוח של שוק העבודה, ואיך נראה שוק ה-Hiring כפי שהוא היום.
• הדיבורים על "הכתובת על הקיר" זה כבר פאסה – "הכתובת היא כבר בכיס כמעט". הנתונים מראים ירידה משמעותית ב-Hiring שהתחילה כבר משנת 2025 ונמשכת לתוך 2026.
• “זה קורה עכשיו - ועכשיו אתה צריך לבחור באיזה צד אתה נמצא: הצד המרוויח או הצד הנפגע”.
• רן מדגיש שזה לא רק למפתחים – גם עורכי דין ורואי חשבון ובכל שאר המקצועות צריכים להחליט באיזה צד הם. 
• יש כאן (לפחות) שני אספקטים עיקריים - איך אנחנו רואים את שוק התוכנה, ואז זה משפיע על כל שאר שוק העבודה.
• אורי - אנחנו רואים את ההשפעה מבפנים, בתוך שוק התוכנה. האם ישנן תעשיות שלא מושפעות עדיין, או לפחות לא מרגישות את זה?
• למשל יוצאי יחידות טכנולוגיות שמאוד מבוקשים בשוק, אבל ארגונים בטחוניים לא יכולים להכניס הרבה מהטכנולוגיות Cutting-edge הללו, לפחות לא בקצב שהן יוצאות.
• מועמדים כאלה אולי פתאום לא מתאימים בדיוק לעולם שרץ “בחוץ”.
• נתי משתף סיפור אישי/מקצועי על שיר אלגום, שנדחתה ממשרה ב-HR כי לא הכירה מספיק AI, ובתגובה הפכה למומחית שמרצה ב-Amazon.
• שינוי גישה: "העולם השתנה, הבנתי, אני עכשיו באירוע".
• אורי ונתי מחפשים השוואות למהפכות קודמות, ולא בטוחים אם יש כאלו בדיוק - 
• מעבר משימוש ב-Intellect האנושי כדי לייצר יתרון - למצב בו "ה-Intellect עובר קומודיטיזציה".
• אין יותר Job security בהייטק המסורתי, וחזרה לכיוון של מקצועות יותר “מסורתיים”, פיזיים.

• נתי - קונספט של “Professional Agents”: מומחים כבר לא מוכרים את עצמם כעובדים, אלא כסוכנים, או ככאלה שמתמחים ביצירת סוכנים.
• סוכן הוא כמו ילד – צריך לגדל אותו ולשכלל אותו, דורש הרבה Nurturing.
• רן - ספציפית: מדברים על מעצבים, רואי-חשבון - מקצועות ספציפיים, שהם אולי לא חלק מהליבה של החברה, אבל נמצאים בכל חברה.
• נתי - דוגמא של Marketing: אם מישהו כבר הכין את רוב ה-Workflows מראש, זה משהו שאני מוכן לשלם עליו.
• אורי מציין שגם בגידול של ילד באיזשהו שלב עוברים ל-Outsourcing יותר ויותר . . . 
• חברות עוברות לתת שירות של סוכן יחד עם “גידול סוכנים” ושכלול שלהם: סוכן + משהו שמתחזק אותו ומתאים אותו לצרכים שלך.
• הבשורה טובה: יש לאן להתפתח - בכל פעם שחסמי-כניסה יורדים, נפתחים תחומים חדשים
• אורי ונתי קצת חלוקים על הנקודה, אבל זה דומה למה שהיה בתחילת ימי ה-SaaS, שאולי לא היה קיים אם לא היה Cloud, לפחות לא בקצב וב-Scale, שקודם לכן היה שמור לארגונים מאוד גדולים ולא לסטארטאפים.
• דוגמא דומה היא Big-Data.
• נתי אומר שהורדת חסמי-הכניסה תכניס הרבה גורמים חדשים לתחום, לאו דווקא רק מכיוון של מדעי-המחשב.
• אורי - השוני במהפכה הזו הוא שיש מצב שבו סוכן יכול לייצר סוכן יותר טוב . . . 
• נתי מפריד בין מוצרים “גנריים” - יש את המודלים של Anthropic ו-OpenAI ומשפחות המוצרים הנגזרות וכו’ - ובין ה”OpenClaw למיניהם”, שהם גרסא פשוטה יותר וזולה יותר, יחד עם קוד-פתוח ומוצרים בסגנון הזה.
• רן משווה את המאבק בין מודלים גנריים (כמו Anthropic) למודלים פתוחים (כמו OpenClaw) ל-"האנדרואיד לעומת האייפון".
• נתי מדבר על ראיון העבודה העתידי: “עובדים יבואו עם ה-10X של עצמם”: מועמדים לא יבואו עם קורות חיים, אלא עם רזומה פלוס – צוות סוכנים שבנו ושיודעים לשכלל להם את העבודה.
• בשנה-שנתיים-שלוש הקרובות, אלו שיעשו את הקפיצה ויבנו את הסוכנים וידעו להגיע עם זה לראיון עבודה - זו יכולה להיות הזדמנות לגדול ולהתבסס.
• אבל - אנחנו לא יודעים כמה ומי הולך להיפגע: “יהיה פה מצב של ירידה לטובת עלייה”.

• רן מעלה את השאלה המפחידה: האם כל הניסיון שצברנו כמפתחים הלך לפח? השנים הקרובות כנראה הולכות להיות מבלבלות, אבל ננסה להסתכל מעבר לזה.
• האם לא יהיו יותר מתכנתים, כי לא צריך - או שיהיו הרבה יותר מתכנתים והרבה יותר תוכנה, אבל מקצוע התכנות יראה אחרת?
• נתי חוזה ירידה למען עלייה - אבל בשונה מהמעבר ל-Cloud-Native למשל, שלקח בערך 10 שנים (ולא נגמר…), כאן הקצב הרבה יותר מהיר (התעשייה השתנתה בתוך שנה).
• זוכרים את “כולם משתמשים ב-AI, אבל לא רואים את ה-ROI”? זה היה בתחילת 2025 . . .  מאז הסטטיסטיקות התחילו להשתנות.
• רן - “אם לפני שנה הייתי נותן ל-Agent משימות קידוד קטנות, ולפעמים זה מצליח ולפעעמים זה לא - היום זה עולם אחר לגמרי”.
• אז יכנסו יותר מעגלי-אוכלוסיה לתחום - אבל הצד השלילי הוא הירידה שלפני: כמות האנשים שדרושים למשימות שיש היום, עד שיווצר ה-Demand החדש, תגרום להרבה אנשים למצוא את עצמם “מחוץ למעגל”.
• מדינות תצטרכנה איכשהו לספוג את הירידה הזו - מימון הכשרות, תקופות הסתגלות וכו’ - אחרת זו בדיוק הסביבה למהפכות והתדרדרות למקומות יותר בעייתיים.
• ולא שהסדר העולמי מסביב שליו ורגוע גם ככה [נתכתב מהממ”ד במהלך מלחמה באירן…].
• אורי - כבר רואים התחלה של “כלכלת סיליקון”, ומדינות nתחילות לחשוב על מאגרי הChip-ים שלהן . . . 
• נתי מזכיר פרק של All-In, שמדבר על תחזיות מאוד אופטימיות, ועל פניו קצת מנותקות - “המון הזדמנויות והכל יהיה בסדר”, בזמן שמי שבתחום יודע שזה לא ממש ככה.
• נראה שב-Silicon Valley יש בעיקר התעלמות - חוגגים בתוך מעגל מאוד מצומצם.
• נתי מציע לחשוב על זה כמו על קורונה [במובן החיובי…] - נצטרך התערבות חיצונית כדי לעבור את הגל הזה.
• רן תוהה האם - בדומה לקורונה - גם התקופה הזו גם תיהיה קטליזטור לתאוריות קונספירציה שעוד תבואנה . . . 
• אורי - מצד שני, גם תרבות הפנאי התפתחה מאוד בתקופת הקורונה, אולי שוב מישהו אחר עושה את העבודה ואז יש יותר פנאי?
• רן - כבר היום, כשאני מפתח, אני מספיק הרבה יותר, בהרבה פחות זמן. אז אנחנו מייצרים הרבה יותר תוכנה . . .
• אורי - אבל אז ה-bottlenecks עוברים למקומות אחרים.
• רן - OpenAI הזכירו, לגבי הפיתוח של Codex 5.3 – שהמודל פותח בעזרת גרסאות קודמות של עצמו.
• "זה בערך By definition הסינגולריות" . . .
• “אל תצפו שהסינגולריות תקרה ביום אחד בודד” . . . “מי שהיה במהפכה התעשייתית לא יודע שהוא במהפכה התעשייתית".

• נתי - האם נכון לבנות סטארטאפ באי ודאות כזו? מה הסיכוי של סטארטאפ כזה לשרוד?
• נאמר על רקע שבוע מאוד לא מוצלח למניות חברות ה-SaaS . . . .
• יש הרבה תגובות-יתר - אבל קורים הרבה דברים באמת מדהימים.
• נתי מציע 5 נקודות קריטיות ליזמים (סוג של Checklist) שרוצים לשרוד בעולם שבו כל דבר גנרי נמחק (כמו IBM שצנחה כי Anthropic פרסמו בלוג-פוסט על Cobol . . . ):

1. ורטיקליזציה (Verticalization): אל תהיו גנריים. Google ו-Anthropic ו-OpenAI שולטים ביד רמה.
• תהיו הכי טובים במשהו ספציפי - עריכת דין או חינוך וכו’.
2. שליטה במידע (Proprietary Data): דאטה שה-LLM הגדולים והמודלים הגנריים לא ראו, כמו מגמות ספציפיות בתוך נתוני לקוחות.
3. יעילות (Efficiency): שימוש ב-SLM (Small Language Models) למשל, כדי לחסוך ב-Token-ים וב-Latency (קריטי ברובוטיקה וב-Security, למשל).
• רן - מודל גדול יקבל את ההחלטה הנכונה, אבל אולי מאוחר מדי.
4. חווית משתתמש (UX ייחודי): חווית משתמש שפותרת בעיה נקודתית ונותנת ערך מהיר (Time to Value).
• ה-Chat של המודלים הגדולים מאוד גנרי.
• סטארטאפים צריכים להתמקד ביכולת לייצר חוויית משתמש מאוד מותאמת לחווייה נקודתית.
• רן - האם בכלל עוד יהיה UI (או שהצרכנים הם גם Agents . . . .)? בהקשר של פיקסלים . . . .
• נתי, אורי - בסוף , אתה רוצה לייצר ערך לאדם.
• בסוף זה עניין של Time to Value: אני אולי יכול לייצר את זה לבד, השאלה האם לא יותר מהיר ויעיל להשתמש במשהו שמישהו אחר כבר ייצר.
5. ואחרון (אם כי נתי אמר ש "החמישי הוא לא לשידור…”) - Disruption: ה-Disruption האמיתי הוא לעשות קניבליזציה לקטגוריות ישנות.
• אפשר לעשות את אותם הדברים שעשינו בעבר, אבל בצורה אחרת לגמרי.
• הרבה דברים קודמים נעשו בגלל מגבלות של עולם שהוא Pre-Agentic, ועכשיו לא רלוונטיות - מה שמאפשר מודל עסקי אחר לחלוטין.
• ואז ה-Price-point יכול להיות מאוד שונה מכזה שהוכתב ע”י תעשיות מאוד גדולות ומבנה עלויות מאוד יקר לתפעול.

• אורי מתזכר את ה-Moats של Warren Buffet, ונתי מספר שהוא לא חושב שפגש חברה אחת שבאמת עושה את כל הדברים הללו, יזמים עדיין לא חושבים ככה.
• במיוחד בארץ, עדיין מתייחסים מאוד לבידול הטכנולוגי ופחות למובן של UX או מודל עסקי.

• נתי אומר שמשקיעים בהרבה מקרים לא יודעים לנתח הזדמנויות ולעשות Evaluation שלא על סמך טרנד צמיחה של ARR.
• אורי - עולם ההשקעות לא הולך לכיוון של SaaS, כי מצד אחד יש המון Disruption risk ומצד שני נראה שהצורך במגמת ירידה.
• נתי - יש כמה סוגי-Exist
  
  s שונים שמשקיעים מחפשים, מעבר למודל הקלאסי של “תבנה חברה, תגדל איתה, תייצר מספיק כסף . . . .”.
• קנייה של טכנולוגיות ואנשים - חברות צריכות “להזריק לעצמן DNA חדש”, ואז מסתכלים על הסטראטאפ לא רק כטכנולוגיה אלא גם כמנוע לטרנספורציה.
• חברות במצוקה מנסות למצוא אנשים שיעזרו להן לעשות את הטרנספורמציה, לפחות בחלון הזמן הנוכחי (3 שנים בערך).
• נתי מזכיר דוגמא שעלתה בעבר - Google: לפני שנה כולם הספידו אותם, ואז הם קנו את Character.AI, ובעצם את נועם שזיר (Noam Shazeer) ב-2 ביליון דולר, כי הם הבינו שהם במצוקה.
• נתי טוען שלחברות במצוקה יהיה מאוד קשה לעשות כזה שינוי רק על ידי צמיחה אורגנית.
• אורי מדבר על חברות שעושות קניבליזציה-מוצרית לעצמן - מתחרים במוצר המסורתי הקודם שלהן.
• נתי טוען שבמקרה של Google זה השתלם להם עם  Search Generative Experience (SGE).

• רן ממליץ לכולם לקרוא את הבלוג-פוסט של Matt Shumer (או לבקש מ-Agent לתקצר אותו).
• נתי חותם עם המלצה אופטימית-מעשית: "למדו את עצמכם... תחשבו שאתם באים למקום העבודה הבא שלכם כבר לא אתם-עצמכם... זה רזומה + צוות עובדים שאתם מביאים איתכם, שזה הסוכנים".
• אורי כבר מכין את הקרקע לפרק הבא: מהפכת ה-Quantum Computing.
• "שיעורי הבית שלכם יכולים להיות 0, 1 או שניהם ביחד" . . . 

פרק מספר 512 (חזקה תשיעית!) של רברס עם פלטפורמה - קרבורטור מספר 40, שהוקלט ב-24 בפברואר 2026. נכון למועד ההקלטה עדיין אין מלחמה [לא התיישן טוב…], ואורי ורן מארחים את הנביא האורח נתי שלום לשיחה, דיונים, וויכוחים ותחזיות (דיסטופיות ברובן) על עולם שבו ה-AI כבר לא רק כותב קוד, אלא מחליף את המציאות כפי שהכרנו אותה.

[01:58] "משהו גדול קורה": הניתוח של Matt Shumer

[10:17] עידן ה-Agents וה-+Resume

[17:03] "אז מה יכול לקרות?": הסינגולריות והמתכנת האחרון

[27:57] חמשת ה-Moats של 2026

[39:26] הזרקת DNA ומהלכי ה-M&A החדשים

[46:00] סיכום וסגירה

תודה לעופר על התמלול!

• נמרוד - אחד מה-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.

• רן מעלה את המשפט הידוע: "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 . . . . צריך להתחיל עם כל מיני סוגים של אופטימיזציות.

• רן מציין שגם מודלים "צנועים" זה עדיין “מליארדים של פרמטרים”, וגם הם דורשים 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 מאוד ספציפיים, לעומת שיטות דטרמיניסטיות שמחפשות את המידע הזה.

• נמרוד אומר ש”למחוק מידע מ-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 לדברים הנכונים”.

• אז כאן יש את ה-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 מתחיל להעלות את כל הקוד לשרת בבלארוס – זו כנראה אנומליה שצריך לחסום . . .

• בכל ענייני ה-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.

• זה תהליך טבעי של חברה ושל אימוץ של טכנולוגיות חדשות.
• נמרוד משתף ש-BigID לא התחילה מ-RegEx, אלא מטכנולוגיה אלטרנטיבית חדשה ל-Data Classification - ורק אז השלימה את ה-RegEx, “כשהלקוחות רצו משהו מוכר”.
• “כשהגיעו המודלים של ה-NER וה-Deep Learning אז הכנסנו אותם”.
• אימוץ ה-LLM בחברה היה תהליך טבעי ומהיר (התחיל בהאקתון), כי קלסיפיקציה מבוססת-LLM זה משהו שקל יותר להטמעה מאשר בניית מודלים של NER מאפס.

• ה-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.

• החברה מונה כ-600 עובדים, מרכז הפיתוח (R&D, Product, Design) נמצא בתל אביב.
• מגייסים בכל התחומים - גם Product, גם פיתוח, גם Design. 
• הארגון בינלאומי - אבל מובילים את המוצר מהארץ.

• טל טיאנו-עינת - מתכנת, בוגר 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) מדבר על אוסף של שיטות, טכניקות ואלגוריתמים, שעוזרים להשתמש במידע הזה - אבל לעשות את זה באופן שמשמר פרטיות.

• זה בדרך כלל תהליך איטרטיבי (Iterative) - מתחילים מנקודת התחלה משותפת של המשקולות ושולחים לכל מיני אתרים שיש בהם את ה-Data.
• בכל אתר עושים אימון מקומי נפרד - ואז שולחים עדכונים למשקולות (מכל אתר).
• עושים אגרגציה (Aggregation) של הנתונים המעודכנים - ושוב.
• רן (בתפקיד הפרקליט השטן): למה לסבך? למה לא לעשות אנונימיזציה (למחוק ת.ז ושם), לשלוח הכל לשרת מרכזי אחד ולאמן שם? נשמע הרבה יותר פשוט . . .
• טל ציין כמה סיבות - 
1. רגולציה: מקשה מאוד . . . . לפעמים החוק פשוט אוסר את זה.
2. בירוקרטיה: צריך לחתום על חוזים להוצאת Data מבית החולים, וזה יכול לקחת חודשים ואפילו שנים (להגדיר למי ספציפית מותר לגעת במה וכו’).
1. וגם אז - זה יהיה עבור פרויקט אחד ספציפי . . . 
3. פרטיות: אנונימיזציה זה לא מספיק - הצלבת מידע (Re-identification) היא קלה מדי היום.
• מקרה לדוגמא - נניח למשל חוקר באיזשהו מוסד רפואי, שלא מעוניין להקים לבד את כל התשתיות האלה (בשום מקרה, וגם לא במקרה הזה…) - וצריך איזשהו Orchestrator שיעבוד עם 5 (או 500) בתי חולים אחרים. מה נוסע לאן? אילו אבטחות (והבטחות) פרטיות יכול אותו חוקר לקבל? “מי מנהל את כל גן החיות הזה?”
• השאלה היא האם אתה עובד עם Rhino או לא . . . 
• בדרך כלל מתחילים עם כל מיני כלי Open Source ועושים כל מיני חישובים
• מגלים כמה זה קשה - ואז מגיעים ל-Rhino . . . 
• ואז נשאלת השאלה - מי מחבר את כל האחרים? איך כל הקהילה נוצרת?
• לאורי כל זה נשמע כמו “מסיבת מנמ”רים” . . . . צריך להגיע לכל CISO ולכל מנהל מערכות מידע של כל מוסד ולשכנע אותו (ואז לעבור את כל הבדיקות…).
• טל אמר שההתקנה של ה-Client היא מאוד קלה (“תוך שעה” במקרה מסוים, לעומת “כמה שבועות” אצל מתחרים אחרים).

• אילו סוגי מודלים הלקוחות בדר”כ רוצים לחשב?
• כמעט כולם עושים 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 וכל התקשורת מדמים מצב אמיתי - אבל בפועל זה רק באתר אחד או שניים.
• עם איזה מידע שהמשתמש רוצה - דמה או אמיתי.

• חוסר-איזון בכמויות ה-Data זה תרחיש נפוץ יחסית, ויש אמצעים שונים שניתן להפעיל כדי לשמר פרטיות, בהתאם לסוג החישוב.
• שימוש ב-K-anonymization: מוודאים שתשובה לא מתבססת על מעט מדי פרטים, ולא מחזירים תשובה אם הקבוצה קטנה מדי (למשל, פחות מ-10 אנשים).
• "מי הם כל הגברים בני 30-40 ממוצא ספרדי שחלו בשפעת השנה? אם יש פחות מ-10, אל תחזיר תשובה”
• אפשר לקנפג (Configure) את זה פר-פרויקט.
• השותפים בפרויקט יכולים לתאם ביניהם ולהחליט להקטין או להגדיל את הקבוע שאיתו עובדים - זה פיצ’ר מאוד חשוב בפלטפורמה, שמאפשר לקבל החלטה, כל מקרה לגופו.
• (רן) מה לגבי “להמציא Data”? - טל אומר שזה משהו שקורה ויש חברות שמוסיפות מידע סינטטי.
• בעולמות ש-Rhino עובדת בהם ההעדפה היא למידע אמיתי.
• “הרעשה מכוונת” - Differential Privacy: הוספת "רעש" (Noise) אקראי מתמטי מכוון ל-Data או למשקולות, כדי למנוע הסקה על פריט בודד.
• לפי גישה ספציפית של “כמה רעש להוסיף?” - התפלגות וקבוע לעוצמת הרעש (ביחס למידע האמיתי עצמו), כדי להבטיח אינפורמציה על המידע המקורי.
• ה-”Differential” בשם מתייחס לכוונה למנוע התקפות שעלולת לחשוף מידע ספציפי מדי על הפריט ה-”N+1” במאגר (ע”י הצלבה של תת-קבוצות) - Re-Identification.

• בשביל זה צריך פלטפורמה . . . . לפני כן, כל העבודה הזו הייתה מתבצעת בכל אתר בנפרד - לא יעיל, מסורבל, בכל פעם צריך לשלוח גרסא חדשה לכולם כדי שיריצו וישלחו בחזרה . . . 
• כשזה 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, או באחד מהאתרים שהשתתף בתהליך - בהתאם להגדרות של המשתמש הספציפי.

• אז לא רק Python . . . הרבה משתמשים ב-R.
• כן צריך להתחשב בצריכה של CPU ושל RAM - ואם רוצים לעבוד עם GPU אז זה גם משהו שצריך לוודא ולהגדיר שיהיה זמין בכל אחד מהאתרים.
• אבל בגדול - כן: כל עוד זה רץ בתוך Container, זה בסדר.

• במידה מסויימת - יש הרבה מודלים של “עד כמה סומכים ועל מי”.
• לקוחות יכולים להצפין את הקוד ו/או את המשקולות שלהם - ואז ל-Rhino אין גישה.
• יש תמיכה שליפה של המפתחות רק מתוך Vault ורק בזמן ריצה, באמצעות Token שהלקוח מספק בצורה מאובטחת.
• יש שיטות כמו Homomorphic Encryption - ואז גם ה-Orchestrator שעושה את האגרגציה (Aggregation) לא רואה אתהמשקולות עצמם (שהוא עושה להם את האגרגציה…)
• מדובר בהצפנה ששני הצדדים עושים - ואף אחד מהם לא יכול לקרוא את התוצאה אם אין לו את המפתח של הצד השני.
• מה שמייחד את ה-Homomorphic Encryption זה שכל אחד מהצדדים, על אף שהוא עובד עם מידע מוצפן, עדיין יכול לבצע עליו חישובים (לרוב מאוד פשוטים - חיבור/חיסור, אולי כפל) - ולהחזיר לצד השני, שיכול לפענח ולקבל את התוצאות של הפעולות.
• מדובר באוסף של אלגוריתמים מאוד מעניינים מתימטית [להרחבה - נגיד כאן: #47 Fully Homomorphic Encryption | Part 1 | Quantum Algorithms & Cryptography - YouTube]

• גם היום עושים את זה - פשוט ל-Bitcoin  . . . [הי - ?But how does bitcoin actually work]
• ההבדל: טל מדייק – שם זה היה חישוב מקבילי: החלק של ה-Distributed - כל אחד מחשב משהו נפרד, ואין קשר בין החישובים שמתבצעים באתרים השונים.
• ב-Federated Learning יש אגרגציה ושיתוף מידע בין הצמתים והמשקולות מהאתרים השונים, כדי לשפר מודל משותף.
• אז יש חיזרים או אין? [?Where is everyone]
• ואגב פיצול וענייני Trust - : רן שואל אם יש מערכות שהן ממש Zero Trust, ולא צריך לסמוך על אף אחד (כולם Peers, כמו Bitcoin, ואין Orchestrator)?
• טל מודה שבעולם ה-Federated Learning כרגע תמיד צריך לסמוך על מישהו (לפחות חלקית), ואין עדיין פתרון קסם של Zero Trust מלא.
• זה יותר “משחקים של על מי אני סומך ומתי”.

• אז Rhino היא סטרטאפ בן 5; החברה גייסה לאחרונה 15 מיליון דולר (Round A). 
• מה מחפשים? מפתחי Backend מנוסים, Frontend, DevOps ו-Product. 
• ה-R&D יושב בארץ - בשרונה, תל אביב (הנהלה בבוסטון), 3 ימים בשבוע במשרד.
• מחפשים אנשים מנוסים שיודעים להתמודד עם Backend מורכב ולא קונבנציונלי - ומספיק ניסיון ב-Python (כי זה ה-Backend).

• מתקפת הסייבר על 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 (“עלה ספרייה אחת למעלה ותממש את אותו הדבר”).

• פרויקט שנקרא 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” נותן להם זויות שיווקית מעניינת.

• תקלת הענק ב-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].

• (מישה) אז אני מישה, כיף להיות פה. בן 38, מתל אביב, נשוי, אב לשובב אחד קטן בן שנה ושמונה.
• בגדול מתעסק בתחום, כמו הרבה בתעשייה שלנו, מגיל 18. 
• זה כבר 20 שנה, יותר ממחצית-חיים . . . . 
• ובעשר השנים האחרונות מתעסק בכל מה שמתחיל לנוע לכיוון מה שהיום אנחנו קוראים “AI” - זה Machine Learning, Deep Learning, Computer Vision.
• ובחמש השנים האחרונות Generative AI ב-Bria.
• שתי מילים אולי על Bria . . . .

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

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

• (מישה) איזה Data - ולחוקרים מסוימים זה מתפרש גם כדת . . . 

• (מישה) בדיוק . . . . אז פורמלית, אין לי שום השכלה ב-Computer Vision.
• פרקטית, בעשר השנים האחרונות אני עובד בחברות שהמהות שלהן, ה-Core שלהן, הוא Computer Vision.
• ולמרות שהגעתי מהצד ההנדסי, יצא לי ברבות השנים גם לפתח, גם לנהל צוותי חוקרים.
• אני אוהב לקרוא לעצמי “Practical Researcher”
• אני עובד עם ה-Common Sense, עם הידיים.
• לעשות באמת אימון ומחקר אני לא יודע, אבל להוביל את העסק, אני איכשהו . . . . אני מקווה שאני מצליח.

• (מישה) אז ב-Bria אני ה-CTO - אני בעצם מוביל את המחקר והפיתוח.
• אני אולי גם אגיד מה Bria עושה, אני מניח שזה מעניין - Bria (בריאה) בגדול מנסה לייצר עולם שבו...
• (אורי) “לברוא” . . . . 
• (מישה) לברוא עולם, נכון . . . 
• (אורי) . . . בחדשות היום בוראים מציאות . . . . 
• (מישה) אחדים מבין מאזינינו הבינו, כנראה, שזה מקור השם Bria (בריאה) . . . 
• (מישה) אנחנו מנסים לברוא עולם שבו מה שאנחנו קוראים “Creativity מקצועי”, יכול לפגוש Innovation של AI. 
• אנחנו בעצם מנסים לאפשר לאנשי Creative מהצד היותר מקצועי - בעולמות של Commercial, בעולמות של Media, בעולמות של Marketing שהוא יותר מקצועי - להשתמש ב-Gen AI.
• תוך כדי זה שאנחנו בעצם מאפשרים לצוותי פיתוח ומוצר של אותן חברות לפתח מעל המודלים שלנו ומעל הפלטפורמה שלנו את המוצרים שיתאימו ל-Use Case-ים שלהם.
• זה מאוד ב-High-Level, אפשר לצלול לזה קצת.

• (מישה) נכון.

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

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

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

• (מישה) זה דימוי שאני יכול להתחבר אליו. אני חושב שיש משהו באנשים שעובדים עם Creative, שהופך את זה לאפילו יותר מסובך.
• בסוף, אנשי תוכנה הם אנשים שבמובנים מסוימים . . .  הם אנשים, בלי להעליב אף אחד, הם אנשים יותר Structured.
• יש הבניה של איך המקצוע הזה . . .  איך שפות-תכנות נולדו ואיך הן התפתחו ואיך הפורמט שלהן נראה וקומפילציה (Compile) וכל מיני דברים כאלה.
• אנשים שעובדים ב-Creative זה שונה לחלוטין: הם פשוט חושבים על משהו, יש להם בראש תמונה - “ויתהפך העולם, זה מה שצריך להשיג”.
• אני יכול לספר סיפור שהיה לנו - פרויקט שעשינו עם במאי הוליוודי מוכר.
• ועבדנו בעצם עם הצוות לעשות איזשהו קמפיין Marketing לסרט - ל-Beetlejuice Beetlejuice, אם אתם מכירים [נא להשלים את קודם כל את Beetlejuice (1988)].
• ובעצם כל הצוות, למרות שכל ה-Spec היה מאוד מוגדר - איך אמור להיות הקמפיין ואיזה סגנון והכל - הם כולם היו בחיל ורעדה עד הנקודה שבה צריך ללכת לבמאי ולאשר שזה באמת פגש את הדמיון שלו.
• ואף אחד לא יודע - כולם היו בטוחים שזה יכול בכל רגע להיות Blocker ו-No Go.
• (רן) כן . . .  והוא, אני מקווה, אישר? . . . 
• (מישה) כן, לשמחתינו הוא אישר . . . .

• (מישה) זה נכון, ויש  . .  . בעצם, האתגר ש-Bria באה לפתור, חוץ מלתת את השליטה, זה גם לתת את האפשרות לאותו איש Creative מקצוען, ללמד את המודל גם את השפה שלו.
• ללמד אותו את ה-Structure המיוחד שמעניין אותו.
• “אותי מעניינת הקומפוזיציה”  . . .
• (אורי) . . . שזה בעצם ה-Codebase ההיסטורי . . . .
• (מישה) זאת ההשוואה, כן, זאת ההשוואה.
• (אורי) אבל כשיש משהו חדש לגמרי? זאת אומרת, עוברים מקמפיין לקמפיין: פעם עשינו קמפיין לסודה, עכשיו אנחנו עושים קמפיין לדבח בשרים [דוגמא מעניינת…], זה שני דברים אחרים.
• (מישה) אז צריך ללמד את זה, נכון. אז צריך לעשות איזשהו Tunning קטן, ולהתאים את זה
• לסגנון, לקמפיין, ל-Structure - למה שצריך.

• (מישה) מה שמשנה פה זה לא בזמן הרצת המודל, מה “נותנים למודל” - אלא בעצם איך מאמנים את המודל.
• ברגע שהמודל התאמן על Data שהוא Structured ו-Data שהוא מאוד Aligned אחד לשני, ובעצם מתאר את הקומפוננטות (Components) השונות הוויזואליות בתמונה, אז המודל, חוץ מללמוד לייצר תמונות יפות, הוא בעצם לומד מה כל קומפוננטה - מה כל Key ב-JSON שלנו, ב-Structure JSON שנכנס כ-Prompt - על מה כל קומפוננטה שולטת.
• ואז זה מייצר איזשהו Disentanglement כזה בין הפיצ'רים, שמאפשר אחר כך למי שמשתמש במודל להגיד “בעצם, אני רוצה לשנות רק את ה-Lighting, ולהזיז אותו מ”שקיעה” ללא יודע מה . . . “דמדומים”, ולא לגעת בשום דבר אחר”.
• וזאת שליטה שהם מאוד מאוד צריכים.

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

• (מישה) אז אנחנו מאמנים מודלים - יחסית לתעשייה - קטנים.
• וזה מתחבר, אולי . . . אנחנו דיברנו המון על ה-Creative Persona, על ה-End User - אבל ה-End User הוא בעצם לא ה-Customer של Bria, זה לא ה-User שלוקח את הפלטפורמה של Bria.
• אמרתי את זה בהתחלה במשפט - אנחנו מנסים לעשות איזשהו שילוב: אנחנו בעצם נותנים לצוותי פיתוח ולצוותי Research לקחת את המודלים האלה, ולהמשיך להתאים אותם ל-Use Case.
• אנחנו לא מתיימרים שה-Structured Prompt שלנו, או איך שאנחנו חשבנו על המבנה הנכון לתמונה, יפתור את כל הבעיות ויתאים לכל ה-Use-Case-ים.
• אנחנו רוצים שהלקוחות שלנו ימשיכו לעבוד עם ה-JSON הזה, ולאמן את המודל לצרכים שלהם ול-Brand שלהם ולמה שהם צריכים בסוף להביא ל-Production.

• (מישה) נכון, נכון. לא חייבים, אבל הרבה מהלקוחות שלנו עושים - ולכן המודלים שלנו הם יחסית קטנים.
• “יחסית קטנים” זה . . .  - המודל האחרון שלנו הוא 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 של מישהו אחר. פשוט הוא לא ראה אותו אף פעם.

• (מישה) אז Cycle של אימון כזה זה משהו שהוא לא בינארי - מאוד קשה להגדיר מה זה “Cycle של אימון”.

• (מישה) אז בעצם צוות המחקר שלנו - הוא עובד כל הזמן. הוא בעצם במסע מתגלגל כל הזמן לאמן את המודל הבא והמודל היותר-טוב שלנו.
• וזה מתחיל מתהליכי 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 - כאלה.

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

• (מישה) שאלה טובה . . .  לגבי פיקאסו, אפשר להגיד עליו שהוא מקצוען, אז אולי הוא איזה End User כזה שהיה יכול להשתמש . . .
• זאת שאלה מעולה. אבליואציה (Evaluation) במודלים כאלה, ובמובן מסוים השיטה ש-Bria עובדת בה קצת עשתה מהפכה באיך שעושים אבליואציה (Evaluation) למודלים האלה.
• כי בעצם הבאנו לשולחן שיטת אבליואציה (Evaluation) חדשה.
• אנחנו גם עושים את האבליואציות שכל שאר המודלים עושים - זאת אומרת, אבליואציות, בין אם זה בעזרת Crowd ובין אם זה בעזרת כל מיני מודלים סטטיסטיים על אסתטיקה ועל Prompt Alignment, זה דברים שהם יותר קלאסיים.
• יש עולמות של Image Arena או Video Arena - כל מיני אתרים כמו Artificial Analysis, שפשוט מעלים לשם מודלים ו-Crowd מצביע, הצבעה בינארית, Blind Test, בין תמונות על איזשהו Preference.
• אבל זה בעצם, כל השיטות האלה - הן מראות את הפער שבעצם המודל של Bria ניסה לפתור.
• (מישה) הבעיה בשיטות מדידה האלה, שהן בסוף עושות איזשהו מיצוע ל-Preference מאוד רחב, אנושי.
• שזה אחלה - ל-B2C, לכל מיני יוצרים מזדמנים כמו אשתך מתחילת השיחה - זה ממש אחלה, יוצאות תמונות ממש ממש יפות.

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

• (מישה) . . . . שהיא אחלה, היא באמת אחלה, באמת יוצאות תמונות מדהימות - Nano Banana, תמונה מדהימה.
• זה לא מה שהבמאי או ה-Art-Director של הסרט רצה להשיג.
• הוא לא רוצה את התמונה הגנרית היפה - הוא רוצה את התמונה שיש לו בראש.
• ולכן אנחנו הגינו איזשהו מדד כזה, שאנחנו קוראים לו  Text-as-a-Bottleneck [Reconstruction] (TaBR).
• כשבעצם אנחנו אומרים . . . אנחנו לוקחים תמונות אמיתיות - תמונות שקיימות במציאות.
• אנחנו נותנים ל-LLM-ים שונים לתאר אותן בצורה הכי טובה שיש
• אנחנו אומרים ל-LLM “תתאר כל דבר שאתה יודע על התמונה הזאת”.
• ואז אנחנו אומרים “זה ה-Prompt שעכשיו ייכנס לכל אחד מהמודלים”.
• ובעצם, מה שאנחנו רוצים לראות זה השוואה ויזואלית - מרחק, בעצם - בין התמונה שג'ונרטה (Generated) לתמונה המקורית.
• כשהמודל שג'ינרט (Generated) לא ראה תמונה - הוא ראה רק טקסט, הוא לא קיבל כ-Input את תמונת המקור.

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

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

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

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

• (מישה) אתה תמיד יכול להבדיל בין המקור ללא . . . .
• (מישה) המקומות שבהם אתה ממש יכול לראות את ההבדל, זה דברים שפשוט שום תיאור טקסטואלי לא יכול לתאר, שזה זהות של בן אדם.
• בסוף, זה יהיה בן אדם שכל הפרמטרים שלו הם אותו דבר - אבל הפנים הן לא אותן פנים.
• מה שכן רואים זה שבמודל של Bria, ב-Fibo - לעומת המודלים המובילים בשוק, Nano Banana, FLUX, Qwen, כל החבר'ה האלה - התמונה פשוט יוצאת אותו דבר בכל דבר שהוא לא ID, לעומת המודלים ההם, שנותנים איזושהי אווירה כוללת שהיא מאוד מאוד דומה, אבל התמונה היא לא אותה תמונה.

• (מישה) אז זה קצת יותר מורכב מזה.
• יש 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” - אז אתה משנה עכשיו רק את התאורה, אתה משנה רק את האובייקט, אתה מוסיף אובייקט, אתה מוריד אובייקט . . . אבל זה כבר אלמנט מתקדם.

• (מישה) אז אנחנו בעצם קבענו מה ה-Entries שיש ב-JSON, קבענו איזשהו סט.
• ישבנו עם חבר'ה שהם מה שאנחנו קוראים להם “Professional Creatives”, קבענו את Set ה-Entries לגרסה הראשונה שלנו, שאנחנו מאמינים שמתאר טוב תמונה.
• אני אעשה Spoiler - אני אגיד שבינואר יצא ה-Version הבא שלנו, המודל הבא.
• (רן) “ינואר” זה “היום”, כשמשתחררת ההקלטה . . .
• (מישה) אז רוצו לחנויות הקרובות לביתכם . . . סתם. 
• (מישה) ושם [ב-Version הבא] יהיו יותר.
• אתה נוגע בנקודה, בעיניי, החשובה פה - זה שבסוף אנחנו לא יודעים להגיד מה כל ה-Entries שצריך לכל Use case.
• אנחנו נותנים את ה-Entries הגנריים, שאנחנו מאמינים שהם חשובים לתמונות באופן כללי.

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

• (מישה) בגדול - כן.

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

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

• (מישה) Uncanny Valley

• (מישה) אני מאמין שכן - לא קשור ל-Bria.
• אני חושב שיש היום בהמון תעשיות, בהמון Use Case-ים, אנשים שמשתמשים בתמונות ג'נרטיביות (Generated) לחלוטין - לא רק בתמונות, גם בסרטים -ואני חושב שאנחנו מעבר לנקודה הזאת.
• אני חושב שיש . . . . אולי יש מקצוענים שיודעים לזהות.
• בוודאות יש מערכות שיודעות לזהות.
• אני חושב שרוב האנשים כבר לא מזהים, בטח במודלים הטובים.
• אני כן אגיד שקצת נוצרה תופעה הפוכה - חברות התחילו לסמן שתמונות הן מג’ונרטות (AI Generated).
• (מישה) Bria הייתה מהחלוצות בתחום הזה - זה חלק מזה שאנחנו גם מאמנים על Data שהוא Licensed.
• אבל אנחנו לא מנסים “לעבוד” על הקהל שלנו, אנחנו לא מנסים להגיד שהתמונה היא אותנטית.
• אנחנו ממש מסמנים היא ג'ונרטה על ידי AI, וזה סטנדרט שתופס מאוד חזק.
• גם Google כבר עושים את זה, גם OpenAI עושים את זה.

• (מישה) היהלום זה Watermark וויזבילי (Visible) - אבל יש גם ב-Meta Data של התמונה.
• אם יצא לכם לעלות תמונות מג'ונרטות לכל מיני Facebook, LinkedIn וכאלה - אז מופיע מין CR למעלה קטן כזה
• שאם לוחצים עליו ממש מקבלים איפה התמונה נוצרה, באיזה כלי, מתי . . . .
• אז ממש כולם מייצרים את הדברים האלה.

• (מישה) אז 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 - הוא יצטרך משקולות, הוא יצטרך להבין קצת מתחת למכסה-מנוע מה קורה - ולשלוט בזה.

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

• (מישה) הם מריצים איך שהם רוצים - אנחנו גם יכולים לעשות, יש לנו בסוף גם Inference שרץ אצלנו.
• יש לקוחות שבאופן מעניין, גם ה-Out-of-the-Box שלנו - בלי לעשות Tune, בלי לשחק איתו - גם הוא מאוד פופולרי.
• אנחנו גם עושים Inference - אנחנו גם עושים Inference ללקוחות שעשו Tune, אנחנו גם תומכים בלקוחות שעושים Inference ב-Cloud שלהם, On-prem.

• (מישה) יש לנו 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 שלי לא מתאים להם.

• (מישה) אז אנחנו יושבים בתל אביב, איך אוהבים להגיד? “קו רכבת”  . . .  סתם, אנחנו יושבים ליד השלום, בתל אביב.
•  אנחנו באזור ה-60+ אנשים גלובלית; רוב ה-R&D בישראל, 35 אנשים בערך.
• לאחרונה התחלנו להיות קצת יותר גלובליים, לגייס Talent-ים בתחום גלובלית . . . .

• (מישה) אנחנו אחרי B.
• אנחנו תמיד מגייסים . . .  אנחנו מאוד מאוד “Talent-Oriented”, נקרא לזה.
• אנחנו פחות מגייסים - והנה יש לנו משרה באתר, אנחנו מחפשים Full Stack Developer או Researcher.
• אנחנו יותר מנסים בפינצטה to Outreach או לקבל Inbound-ים של אנשים שפשוט יודעים מה אנחנו עושים, ואומרים “זה התחום שאני רוצה להתעסק בו”.

• (מישה) גם חוקרים שיש להם ניסיון ב-GenAI, גם מהנדסי Backend ו-ML חזקים - וגם בסוף יש לנו המון מפתחי Full Stack
• אנחנו בסוף חברה ויזואלית - למרות שאנחנו לא מוכרים אפליקציה, יש Front, ואנחנו רוצים להראות את מה שאנחנו עושים, אנחנו רוצים להדגים איך ה-JSON עובד, אנחנו רוצים להראות איך הדבר הזה - איך אפשר להשתמש בו.

• DLP היא תוכנית קריטית במניעת דליפת מידע רגיש.
• AI יכול לשפר את יכולות ה-DLP בצורה משמעותית.
• האתגרים בתחום הסייבר סקיוריטי הולכים ומתרבים עם הזמן.
• החלטות טכנולוגיות צריכות להתבסס על צרכי הלקוח והסביבה.
• אימון מודלים הוא תהליך מתמשך שדורש פידבק מתמיד.
• שימוש בכלים קיימים יכול לחסוך זמן ומשאבים.
• הבנת סוגי המידע הרגיש היא קריטית לפיתוח פתרונות DLP.
• הבחירה בין AI in-house לבין צד שלישי היא קריטית.
• הכנת דאטה איכותי היא שלב חשוב בפיתוח מודלים.
• היכולת של מודלים קטנים לזהות מידע רגיש יכולה להיות גבוהה. עשינו מחקר גדול על איך עושים AI בפרודקשן.
• בחרנו להריץ את המודלים מעל NVIDIA Triton.
• Triton יודע להריץ סוגים שונים של מודלים.
• היתרון של Triton הוא ניהול מודלים שונים בסביבת פרודקשן.
• הוספנו שכבה של מודל RNN לשיפור הביצועים.
• יש לנו תהליכים של סריקה בריל טיים.
• האתגרים שלנו כוללים ניהול משאבים בצורה יעילה.
• השתמשנו בטכנולוגיות לניהול תהליכים כמו Temporal.
• השתמשנו בוקטור סימילריטי לזיהוי סוגי מסמכים.

• (אלון) טוב, אז אני ראיתי את האייטם הזה - וישר נזכרתי בהרצאה של שלומי נוח מהרברסים הראשון [זו מ-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. לתשומת ליבך.
• טוב, תודה רבה. איזה יופי, שלומי - שומעים את הציפורים! איזה כיף.
• (שלומי) יאללה, תודה. 
• (רן) בואו, אנחנו נמשיך לאייטם הבא.

• (רן) אז כמה אייטמים ממני. אחד - 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 ומעניין. 
• (אלון) יש במקרה הזה משהו אנקדוטלי? מאמר אנקדוטלי שמעניין? שאתה יכול להסביר לי כאילו אני בן חמש?
• (רן) האמת היא שעברתי על כמה, אבל אני לא זוכר כרגע. 
• (אלון) זיכרון של בן חמש, בסדר . . . 
• (רן) כן . . . אבל חבר של אחיינית שלי גם הגיש - ואחד המאמרים שלו נמצאים שם, (רן) אז תודה איתי!
• זהו, לאייטם הבא. אלון - שלך.
• (אלון) שלי? טוב . . . 

• (אלון) אז 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 שלכם לכתוב קוד, מה כבר יכול להיות רע?
• (רן) ואיפה שמעתם את זה לראשונה! אוקיי, דותן, עשית סיכום יפה.

• (דותן) אז את האמת שעכשיו עשיתי משהו שקצת מזכיר את הדבר הזה . . . . לקחתי את כל הלינקים שלי, שמתי אותם ב-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 חדש.
• (אלון) כן . . . “תשכח מזה”.

• (רן) אבל יש לי שאלה - אתם ממשיכים לעשות 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, לדעתי.
• היו לנו כבר את כל היסודות במקום הנכון, אז זה לא שינוי ממש קיצוני.
• כאילו, זה להמשיך את היותר חזק על הפרדיגמה שכבר הייתה, בוא נגיד את זה ככה. 
• (רן) כן, אוקיי - אחלה, תודה!

• (רן) עכשיו, יש פיל אחד בחדר שעליו לא דיברנו, ולמי שהיה על הפלנטה בחודש האחרון ומשתמש ב-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, מזמינים הרבה . . .
• (רן) תקלות קורות לכולם . . . 
• (אלון) החסות! נו, וזה . . . . הם משלמים לנו על חסות? כי אם כן, אני יכול להרים להם פה עכשיו . . . 
• (רן) . . .  וזה היה פינת המצחיקולים שלנו . . .