פרק מספר 511 של רברס עם פלטפורמה, שהוקלט ב-18 בינואר 2026. אורי ורן מקליטים בכרכור (הגשומה והקרה) ומארחים את נמרוד וקס - CPO ו-Co-Founder של BigID - שחצה את כביש 6 בגשם זלעפות כדי לדבר על אתגרים טכנולוגיים בעולם המופלא של Data Production ו-Security. 🎗️


[00:38] נמרוד, BigID ולמה אנחנו צריכים קטלוג ל-Data?

• נמרוד - אחד מה-Co-Founders של BigID, ש”עוזרת לארגונים להבין את ה-Data שלהם”.
• האתגר המרכזי של ארגונים היום הוא שהם אוספים אינסוף מידע (על לקוחות, עובדים, שוק), אבל מתקשים בשלושה דברים עיקריים: להגן עליו, לעמוד ברגולציות (פרטיות), ולהפיק ממנו ערך (למשל לטובת AI).
• הפתרון של BigID: בניית קטלוג של כל המידע בארגון.
• סריקת כל המערכות: Unstructured, Structured, Big Data, Cloud Storage, Business Applications . . . 
• וגם אספקטים של Data at Rest & In Motion: מציאת המידע “איפה שהוא לא נמצא”.
• החברה עושה קלסיפיקציה (Classification) של המידע - שכבה סמנטית של ה-Metadata, ולא רק סמנטיקה: 
• המערכת ממפה את ה-Metadata העסקי (“למה המידע משמש?”), האופרטיבי (“מי ה-Owner? למי יש גישה?”) והטכני.
• כולל Contextual Metadata - עמודות, שורות, Foreign Keys . . . 
• לחברה יש גם את היכולת לייצר קורלציה ל-Data Subject – כלומר, להבין למי המידע שייך (לאיזה אדם ספציפי הוא מתייחס), שזה הבסיס לעולמות הפרטיות (כמו "הזכות להישכח").
• מעל הקטלוג הזה, BigID מנגישה אפליקציות - 
• להגן על המידע - Data Access, Governance, Monitoring, Control.
• כולל היבטים של רגולציה בהגנה על המידע, בעיקר סביב Privacy Management.
• היום יש גם הרבה אספקטים של רגולציה סביב AI - ואיך להפיק ערך מהמידע הזה.
• הייחוד של החברה בעולמות ה-AI הוא היכולת לייצר קטלוג של Unstructured Data - שזה היום המקור המרכזי של AI.
• אם פעם אנשים היו מסתכלים על ה-Snowflake או על ה-Databricks שלהם כדי לעשות אנליזה למידע - היום הם מסתכלים על ה-OneDrive
• גם כדי למצוא את המידע שהם רוצים - וגם כדי למחוק את המידע שהם לא רוצים.
• רן - “אם פעם פיצ’רים היו בתוך עמודות ב-Database, היום אני מסתכל פשוט על Unstructured Text” . . . .
• החברה מאפשרת Secure pipelines ל-AI, ופיצ’רים של Security - גם ב-Design time וגם ב-Runtime - לאפליקציות AI.
• וגם אפשרות להפיק את המידע הזה החוצה - לספק את ה-Metadata הזה לכל אפליקציה אחרת בארגון
• כלי Cataloging לשימושי AI או למטרות Security - העשרה של המידע עם מידע (Metadata . . . ).
• נמרוד מגיע מרקע של Product Management - ניהל את ה-Identity Management Product Line של CA (היום בתוך Broadcom).
• ולפני כן רקע טכני - מפתח בתחומים של Security.

[05:18] האתגר הטכנולוגי: "אתה לא יכול להגן על מה שאתה לא רואה"

• רן מעלה את המשפט הידוע: "You can't protect what you can't see" - מה המשמעות מבחינת הלקוחות של BigID? מהם האתגרים הטכניים בייצור של פתרונות עבורם?
• נמרוד מסביר ש-BigID קמה על מנת לתת לארגונים את ה-Visibility הזה.
• ארגונים לא יודעים מה יש להם - וגם כשארגונים חושבים שהם יודעים איפה המידע הרגיש שלהם נמצא, בפועל הם טועים.
• ועל מנת להגן על מידע רגיש, בתור התחלה צריך לדעת איפה הוא - וזה האתגר מספר 1.
• דוגמא ל-Use Case נפוץ: איזשהו Stream של מידע, לפעמים Structured ולפעמים לא . . . עושים לו Structuring, מביאים אותו ל-Databases של האפליקציות - וחושבים שהוא רק שם.
• אחד ה-Use Cases הנפוצים זה עולם הבנקאות ו-Wealth Management - המון רגישות לפרטיות של הלקוחות.
• ארגונים כאלו מנהלים כמויות עצומות של מידע - ואסור שמספרי חשבון ופרטים מזהים יצאו מגבולות ה-Data Lake או ה-"Green Zones" לאיזורים אחרים.
• גם הדיוק מאוד חשוב - וגם ה-Scale מאוד גבוה.
• ואלו “עבירות של כלא” . . . .אם המידע דולף, המנכ"ל עלול ללכת לכלא.
• (רן) מהזוית של המהנדס - איך עושים דבר כזה? זה נשמע כמו RegEx . . . יש מספרי חשבונות בנק וכו’, אז הפתרון הטריויאלי הוא להפעיל איזשהו Regular Expression. אבל המציאות קצת יותר מורכבת . . . . אילו טכנולוגיות אחרות יש?
• נמרוד מסביר ש-”Regular Expression טוב בערך ל-Email . . . . לכל מה שהוא מעבר ל-Email, זה כבר לא עוזר לך”.
• הסיבה לכישלון של מערכות DLP (Data Loss Prevention) ישנות היא ההסתמכות על RegEx, שיצרו המון רעש.
• “זו פשוט לא טכנולוגיה מספיק טובה”.
• אחת הטכנולוגיות הראשונות ש-BigID יצאה איתה הייתה Correlation, מה שהחברה מכנה Identity Graph.
• היכולת לעשות Exact Value Matching על מידע שהוא Correlated.
• איך זה עובד? לוקחים Data ממערכת ה-CRM או ה-HR, ממפים פרופילים של משתמשים, ואז מוצאים את המידע הזה.
• זה נותן דיוק מאוד גבוה - וגם יכולת לדעת למי המידע שייך.
• לדוגמא - “מספרי חשבון זה רק רצף של מספרים - RegEx לא יעזור לך”.
• אם מוצאים רצף מספרים, קשה לדעת אם זה מספר חשבון או סתם מספר - אבל אם הרצף הזה תואם לרשימת הלקוחות מה-CRM – הוודאות גבוהה מאוד.
• מסתכלים על המסמך כולו, או על Entities בתוכו? גם וגם . . . 
• יש Machine Learning & Deep Learning - 
• שימוש ב-NER (Named Entity Recognition) לחילוץ ישויות.
• שימוש ב-Document Classifiers כדי לזהות את סוג המסמך (האם זה חוזה העסקה? האם זה NDA? - עושים Deep Learning על כל המסמך), ומזהים על סמך Training קודם.
• את אותו הדבר עושים גם עם LLM-Based Classification.
• מאפשר גמישות (גם וגם - או זה או זה, או שניהם)
• אבל מציב אתגרים חדשים של עלות ומהירות - זה יקר מאוד ואיטי מאוד לסרוק TBs של Data . . . . צריך להתחיל עם כל מיני סוגים של אופטימיזציות.

[11:01] סוגיית ה-Scale וה-Cost בעולם ה-LLM

• רן מציין שגם מודלים "צנועים" זה עדיין “מליארדים של פרמטרים”, וגם הם דורשים GPU ועולים לא מעט כסף. 
• נמרוד מפרט על האסטרטגיה להתמודדות - 
• אחת הטכניקות הראשונות הייתה ב-Small Language Models (SLM): התחילו עם BERT או RoBERTa. 
• זה עבד (ביצועים טובים, עדיין צריך GPU), אבל חייב אימון (Training) על ה-Data של הלקוח – וזה "Big No No" מבחינת אבטחה (ענייני Security ורגולציה) ואופרציה (זמן…).
• “סיוט אופרטיבי” . . . .
• השלב הבא הוא LLMs (“מודרניים”): גם מודלים של 50 מיליארד פרמטרים כבר לא דורשים אימון (Pre-trained) ונותנים תוצאות מעולות.
• “ה-LLM של לפני חודש זה כבר ה-SLM של היום” . . . .
• והם כבר באים מאומנים.
• מה לגבי המחיר? פה נכנסת האופציה לעשות אופטימיזציה לסריקה (Full Scan vs. Sampling): רוב פתרונות ה-DSPM (Data Security Posture Management) לא מסוגלים לעשות Full Scan, הם עושים רק דגימה (Sampling מהיר מעל ה-Data).
• זו הדרך היחידה ל-Cost Effective Brute-force עם LLM . . . .
• זו אופציה טובה למטרות Security (ו-BigID מאפשרת אותה), אבל נמרוד טוען שזה לא מספיק ל-CISO, שצריך Full Scan.
• זה טוב בשביל Risk Assessment, אבל לא “פתרון סופי” [הגענו גם לזה…].
• פה מגיע הפתרון ההיברידי (LLM Augmented):
• משתמשים בכלים דטרמיניסטיים וזולים (כמו RegExאו NER) כדי לסרוק את הרוב.
• משתמשים ב-LLM כדי לנקות את ה-False Positives.
• "אתה מקטין בסדר גודל את כמות ה-Findings שאתה צריך לעבור עליהם וצריך לעשות עליהם LLM Classification”.
• מכוונים את ה-RegEx להיות "רחב" (לתפוס הרבה False Positive), ואז ה-LLM מנקה את השגיאות (גם אם עדיין משאיר קצת FP).
• אלו ענייני Cost-Effectiveness שצריך לקחת בחשבון.
• אורי מזכיר שנהוג לחשוב על LLM-ים כ”לא דטרמניסטיים” . . . . איך משתמשים בהם על מנת לקבל משהו דטרמניסטי?
• נמרוד משתמש במונח “כמה שיותר לא דטרמניסטי” - שהוא עצמו לא דטרמניסטי . . . .
• באופן כללי, Data Classification זו טכניקה סטטיסטית - אף פעם אין 100% ודאות.
• כן יודעים להגיע עם LLM לרמות דיוק מאוד גבוהות, יותר מאשר עם RegEx - כשמסתכלים על כל מגוון האפשרויות.
• יכול להיות שה-LLM ישווה ויטעה - אבל ל-RegEx אין שום אפשרות בכלל לבדוק (למשל - “האם זה לקוח?”).
• אלו False Positives עם Use Cases מאוד ספציפיים, לעומת שיטות דטרמיניסטיות שמחפשות את המידע הזה.

[16:13] סיכונים וחיות אחרות /  " LLM זה ראשי תיבות של לא למחוק"

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

• נמרוד אומר ש”למחוק מידע מ-LLM זו משימה כמעט-בלתי-אפשרית”.
• יש טכנולוגיות שמתיימרות לעשות את זה, אבל זה מצריך כמות חישוביות כל כך גבוהה, שכבר עדיף לאמן את המודל מחדש.
• פרקטית, מה שצריך לעשות זה לטפל ב-Pipeline של ה-Data:
• מניעה (Sanitization)  - “לא להכניס מידע שאתה לא רוצה”, לנקות את ה-Data הלא-רצוי לפני שהוא נכנס ל-Training או ל-RAG.
• סריקת Vector DBs: להסתכל על ה-Inference Framework.
• האמבדינג (Embedding) הוא “וקטור של מספרים”, אבל הוא מכיל לרוב גם את ה-Snippet של המידע המקורי עצמו, או לינק ל-Data במקום אחר - BigID יכולים לסרוק את ה-Data הזה (את ה-Vector DB), מזהים וקטורים שמכילים מידע רגיש, ושמים עליהם Label (אם המפתחים לא רוצים למחוק אותם).
• ואז אפשר להפעיל Access Control: ברגע שהוקטור מסומן כרגיש, אפשר למנוע מהאפליקציה למשוך אותו בשלב בניית התשובה.
• אורי מציין שראשי התיבות של LLM זה “לא למחוק” . . . . נמרוד - "בתעשייה שלנו, Job Security זה שארגונים לא מוחקים מידע אף פעם".
• צריך לזכור שהסיכונים הם לא רק זליגה של מידע, אלא באותה מידה גם Insider Threat: חשש שהמידע יחשף בתוך הארגון.
• ארגונים חוששים שעובדים ישתמשו ב-Microsoft Copilot (או Glean, או Gemini) כדי לשאול "מה המשכרות של ה-CEO, או של החבר שלי?"
• פעם היינו מוגנים ע"י "Security by Obscurity" (אף אחד לא ידע איפה הקובץ . . .
• [יש הטוענים ש-SharePoint זו מכונת הצפנה כמעט מושלמת]
• היום ה-AI מוצא הכל, והפתרון הוא סניטציה בסיסית, ללא קשר ל-AI, אלא ל-Data Access Governance.
• “לוודא שלאנשים הנכונים יש Access לדברים הנכונים”.

[20:38] הגנה בזמן ריצה Runtime Security & Agents

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

• אז כאן יש את ה-Runtime - ואפשר לעשות Interception ל-LLM.
• מעיין Firewall לכל מה שיוצא החוצה ל-LLM  - או נכנס פנימה.
• יש הרבה חברות שמתחילות להציע את זה היום - לא רק בשביל Data אלא גם עבור כל מיני שירותי Security: מציאת Vulnerabilities ו-Prompt Injections וכל מיני כאלה.
• ב-BigID מתמקדים ב-Data - גם מניעה של זליגה החוצה וגם ווידוא שהאנשים שנחשפים למידע הם אכן אלו שרשאים לגשת אליו.
• יש כל מיני שיטות לעשות את זה, כשב-BigID נמרוד מציג גישה של מעיין “AI Firewall” עבור “Home-grown Applications” - 
• שימוש ב-LangChain hooks בשביל “יירוט הפרומפט” (Prompt Interception).
• אם רוצים להגן גם על Employee Access to AI, טכניקה נפוצה היא Plug-Ins ל-Browser (תוספי דפדפן, Browser Plugins).
• טכניקה נוספת היא להשתמש ב-API Gateways.
• כל API Firewall (כמו Congo למשל) מאפשר לעשות Hooking ל-Set של APIs.
• אפשר גם להתחבר ל-API של ה-Service - מאפשר לעשות את זה “בצורה הכי נקייה”.
• התממשקות, בדרך כלל ל-Audit Logs של הספקיות (OpenAI/Microsoft), ובאופן הזה חשיפה, דרך API, ל-Prompt.
• ואז יש יכולת לתת Alert או DDR - Data Discovery & Response.
• אבל גם Microsoft וגם אחרים נותנים עכשיו APIs שמאפשרים, ממש כמו LangChain, להיות Man in the Middle.
• רן מציין שבעולם ה-Agent-י זה כבר עוד יותר מורכב: זה כבר לא Copy-Paste אלא Agent ששובר את המשימה לחלקים ועושה Function Callings . . . . ”בלגן שלם”. איך מגינים על זה? 
• כאן הבעיה הופכת לבעיית Identity Management - ו-Agent זו בעיה כזו.
• ה-Agent פועל בשם המשתמש - משתמש ב-Credentials וב-Identity של המשתמש.
• האתגר הוא להבדיל בין האדם למכונה - ומה ה-Context  של העבודה.
• זה יותר מורכב מההבדלה בין Human ל-Non-Human Identities - זה דורש טכניקות מעולמות ה-Fraud Detection: זיהוי אנומליות, מהירות פעולה, ומקור הבקשה.
• הגבול הוא מאוד לא-חד (Blurred) - יש אדם שמשתמש ב-Agent - וצריך לדעת להבדיל בין פעילות של אדם לפעילות של מכונה.
• זה לא מדע חדש - אבל פתאום צריך לדעת להפעיל אותו על מקורות מידע ומקורות Compute חדשים.
• כשאתה ניגש בתור אדם למידע אז יש לך גישה, אבל אם ה-Agent מתחיל להעלות את כל הקוד לשרת בבלארוס – זו כנראה אנומליה שצריך לחסום . . .

[27:10] איך מטפלים במה שאתה לא יודע? / גישה חדשה ל-Access Control (דינמי וסמנטי)

• בכל ענייני ה-Unknown מטפלים בדרך כלל ע”י Anomaly Detection - מזהים Baseline שלהתנהגות, וברגע שיש חריגה אז יודעים לתת התראה.
• זה יכול להיות דברים טריוויאליים כמו התנהגות של Downloads (כמויות או מיקום) ויכולים להיות דברים יותר מורכבים (בהתאם לסוג הפעולה וסוג המידע). 
• זה דורש Visibility יותר אינטימי ל-Classification של המידע.
• דבר נוסף הוא נושא ה-Access Controls באופן כללי - עולם ה-Security עד היום נבנה על סמך הגישה המסורתית של ACL (Access Control Lists)
• בעולמות ה-Agent-יים ובעולמות ה-AI בכלל, הגישה של ACL סטטי נשברת - אגרגציה (Aggregation) של מידע יוצרת רגישות חדשה.
• מידע שאולי היה לחלוטין לא רגיש כשהוא מבוזר - אבל כשעושים אגרגציה, נוצרים ההקשרים ו-Re-identification של מידע, שהופכת אותו פתאום לרגיש.
• רן נותן דוגמא: פרט אחד על חולה ב-Yorkshire ופרט אחר על גיל 80+ ב-Yorkshire אולי לא מזהים בנפרד; כל עוד המידע מאוד “רחוק אחד מהשני”, נדרשת “עבודת בלשות”, אבל ה-LLM מחבר אותם בקלות, וזה מוריד את סף התקיפה.
• הפתרון הוא קלסיפיקציה (Classification) של המידע בזמן אמת (On the fly) - המערכת צריכה לזהות שכרגע המידע הוא "רפואי", ולבדוק האם לאפליקציה/משתמש הספציפי מותר לראות מידע רפואי ברגע זה, ללא קשר למאיזה קובץ הוא הגיע.
• וזה משנה לגמרי את האופן שבו מנהלים גישה ל-Data - וזה מחייב Controls חדשים ו-Visibility אחר למידע.
• “סוג של ACL - אבל סמנטי ודינמי, On the fly”: קלסיפיקציה בזמן השימוש במידע, ולא (רק) Static Policies לפיסות מידע לא מחוברות.
• קצת מזכיר את התהליך שעבר על ה-Firewalls.

[31:38] סערת ה-LLM בחברה ותיקה

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

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

ומה לגבי Real-time Identification? עולם האיומים השתנה - בהרבה.

• ה-Core של BigID הוא לא על בסיס Agents (על המכונות) - אלא API-Based, וזה תמיד היה ה-Guideline.
• גם ל-Activity Monitoring.
• ההתחלה הייתה עם Data at Rest - ואז נוספו Permissions ל-Data Access Governance.
• והדבר הבא שלקוחות רצו היה לדעת מי ניגש למידע - אז כל נושא ה-Real-time לא קשור ל-AI, אלא נכנס כחלק מההתפתחות של המוצר.
• אם כי זה כמובן גם משרת מאוד את כל נושא ה-AI.
• נמרוד לא בהכרח רואה את BigID נכנסת לבנייה של Gateways ל-AI
• בידול של BigID מול חברות Firewall (כמו Palo Alto / SentinalOne): חברות ה-Network וה-Endpoint שבונות את ה-Firewalls” “וטבעי להן” לבנות את ה-AI Gateways. 
• ב-BigID פוגשים את זה בתור “האחראים על ה-Data” - וה-Data זה מה שמניע את ה-AI.
• כל מה שקשור ל-Home-grown AI Applications זה המשך מאוד רציף: AI Product הוא Data Product.
• היכולת לעשות אגרגציה ועיבוד מאוד מתקדם של מידע.
• עוד חוזקה היא על ה-Controls שקשורים ב-Data - ההבנה של ה-Context שעובר בתוך ה-Prompt.
• הכרות יותר אינטימית עם ה-Data והיכולת לדעת האם הוא רגיש.
• והיכרות עם הרגולציות הרלוונטיות - איזה מידע ניתן לשימוש באיזו אפליקציה: בדומה ל-Privacy, עכשיו זה לכיוון של AI Regulations.

[36:59] גיוסים וסיכום

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

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

פרק מספר 510 של רברס עם פלטפורמה, שהוקלט ב-6 בינואר 2026. אורי ורן מקליטים בכרכור ומארחים את טל (מאזין ותיק!) מחברת Rhino Federated Computing לשיחה על עולם של חישוב מבוזר, פרטיות רפואית, הצפנות הומומורפיות ונוסטלגיה ל-SETI@home (ולא AI! טוב, גם…). 🎗️

לפני הכל - טל הוא מאזין ותיק, אי שם מאזור פרק 300 [מה קורה באמת עם התחזית של נתי על המוצר הצעיר והחדשני Apache Spark?] שהחליט להרים את הכפפה בעקבות הקריאה בכנס האחרון לרעיונות לראיונות. תהיו טל!
[01:28] טל, Rhino, ומה זה Federated Computing / Learning

• טל טיאנו-עינת - מתכנת, בוגר 8200, 20 שנה בתעשייה.
• בעבר CTO ו-Co-Founder, פעמיים עובד מוקדם או בין הראשונים בסטארטאפים, 8 שנים בטכנולוגיה חינוכית.
• ו-Python Core Developer, ספציפית של CPython [כבוד!]
• היום מוביל את תחום ה-Backend ב-Rhino Federated Computing.
• ו-Rhino Federated Computing עוסקת בגדול ב“חישוב מבוזר ומשמר פרטיות”.
• תכל’ס - מאפשר לעבוד עם כל המידע וכל ה-Data הרב מאוד שקיים היום בעולם.
• יש המון Data - אבל זה מידע רגיש (רפואי, פיננסי) שצריך להישאר “נעול בכספות”.
• ועדיין - רוצים להפיק ממנו תובנות.
• הפוטנציאל משיתוף מידע כזה הוא עצום, וצריך לדעת לעשות את זה בזהירות.
• בגדול, העולם מלא ב-Data (שליש מהמידע הדיגיטלי הוא רפואי), אבל הוא יושב ב-Silos: אי אפשר להוציא אותו בגלל רגולציה ופרטיות, ולא עושים איתו כמעט שום דבר.

• "אם תשאל חוקרים, כמעט כולם יגידו: 'האתגר הכי גדול שלי זה להגיע ל-Data. הוא יושב שם, אבל לא עושים איתו כלום."

•  הפתרון של Rhino Federated Computing זו פלטפורמה, שמאפשרת להשאיר את ה-Data “במקום הטבעי שלו” (ב-Edge), ולשלוח את הקוד/המודל למחשב מקומי שירוץ עליו ויחזיר רק תוצאות נגזרות - אגרגטיביות (Aggregated) או משקולות (Weights) - שלא חושפות יותר מדי.
• באופן כללי, Federated Learning (או Federated Computing) מדבר על אוסף של שיטות, טכניקות ואלגוריתמים, שעוזרים להשתמש במידע הזה - אבל לעשות את זה באופן שמשמר פרטיות.

[04:32] אז איך עובד הקסם הזה, מהם ה-Use Cases ומי מנהל את גן החיות?

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

[10:28] אילו חישובים ניתן לעשות? אילו מודלים? מה האלגורתמיקה שרצה?

• אילו סוגי מודלים הלקוחות בדר”כ רוצים לחשב?
• כמעט כולם עושים Deep Learning ו-LLM-ים, מכל מיני סוגים וגדלים.
• עושים Fine Tuning מכל מיני סוגים.
• רואים גם כאלה שרוצים מודלים “קלאסים” - רגרסיות מסוגים שונים, מודלי-הישרדות למיניהם (בהקשרים רפואיים).
• מה שיפה זה שבמסגרת של Federated Learning אפשר לאמן את כל הסוגים הללו של המודלים.
• למשל גם Boosted Trees מסוגים שונים, יש תמיכה מאוד רחבה.
• וגם אלגוריתמים שהם בכלל לא אימון של מודל - כל מיני אלגוריתמים סטטיסטיים (חלק קיימים וחלק כאלו שהחברה בונה עבור הלקוח).
• אפילו חישוב של חציון בצורה שהיא מבוזרת ומשמרת-פרטיות זה גם אתגר מורכב.
• מדובר ב”אולר שוויצרי”, שמחשב גם חציון וגם Deep Learning, למשל - או שיש כאן כלים שונים?
• יש פה בעצם שני Framework-ים עיקריים שנתמכים עבור Federated Learning - הראשון הוא NVFlare של NVIDIA ו-Flower של Flower Labs [יש שת”פ…].
• אפשר גם לממש בהם אלגוריתמים סטטיסטיים - אבל זה פחות נפוץ, יותר מורכב.
• הטכנולוגיה: הכל רץ על Containers. המשתמש שולח Image, הוא רץ מבודד (בלי גישה לרשת או ל-FS, רק ל-Data הספציפי), והתוצאה נשמרת מקומית או נשלחת חזרה (תלוי בפרוטוקול).
• (אורי) - כל קוד יכול לעבוד “פדרציה” על ידיכם (Rhino) - או שמי שכותב את הקוד צריך לחשוב מראש שהוא הולך “לרוץ Federated” ואז צריך לכתוב את הקוד בצורה אחרת? (רן) אפשר להריץ PyTorch as is, או שצריך התאמות כדי שירוצו “Federated”?
• במרבית המקרים זה משהו שבין Out-of-the-Box לבין “פשוט מאוד” - המפתחים של ה-Framework-ים “כבר סללו את הדרכים” עבור המודלים הנפוצים (כמו PyTorch או TensorFlow), ואז זה רק “להוסיף כמה שורות”.
• איך למצוא את ה-Data ולכתוב את המידע שיוצא (למשל משקולות) למקומות הנכונים.
• רגע, יש פה Double-Latency? אתרים נפרדים, מרחק פיזי, ענייני Orchestration מיבשת אחרת . . . בד”כ, לאמן מודלי Deep Learning זה משהו שדורש הרבה Data והרבה Iterations - אין פה צוואר-בקבוק (לפחות אחד או יותר)?
• בהחלט יכול להיות - ומעניין לראות אילו Trade-offs אפשר לעשות.
• יש הרבה פרמטרים שאפשר לשלוט בהם - כמה מידע משתפים? מה אורך האיטרציות? כל כמה זמן עושים עדכון מחדש ו”יישור קו” בין האתרים השונים (לכל פעם יש מחיר).
• ועדיין - טל אומר ש”לא מצאנו מקרה שזה היה כל כך איטי כך שאי אפשר היה להשיג את מה שרצו”.
• האם יש איזשהו Sandbox, שעליו אפשר להריץ את האיטרציות המהירות (יחסית) על “משהו לוקאלי” - ואחרי שבטוחים (נגיד ב-80%) שזה מה שאנחנו רוצים, רק אז לקחת את הכל ל-Federated, כדי לחסוך (זמן וכו’)?
• כן. ב-Rhino בנו כלי  למפתחים, כך שיוכלו לעבוד ממש מקומית (Containerization) ולוודא שכל ההתאמות אכן עובדות.
• גם בשלב הבא, כשכבר מעלים ומריצים על גבי הפלטפורמה - יש פיצ’ר שמאפשר להריץ את זה ממש Federated, אבל שכל ה-Clients רצים באתר אחד.
• אפשר להרים מכונה חזקה עם כמה GPUs ולהריץ, כשכל ה-Flow וכל התקשורת מדמים מצב אמיתי - אבל בפועל זה רק באתר אחד או שניים.
• עם איזה מידע שהמשתמש רוצה - דמה או אמיתי.

[18:30] המקרה המוזר של החולה האנונימי בקיבוץ
(רן) נניח לדוגמא בית לחולים אחד עם 500 פציינטים, בית חולים שני עם 1000 - ושלישי עם 10 בלבד. כולם רוצים לחקור יחד, אבל לחלקם יש ממש מעט משתמשים (נתונים). האם יש כאן בעיית אנונימיזציה של “קיבוץ קטן”? כולם מכירים את כולם, ואם מישהו מחפש, יכול להיות שמאוד קל לזהות חולה ספציפי?איך עדיין אפשר להשתמש במידע “קטן” יותר?

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

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

• בשביל זה צריך פלטפורמה . . . . לפני כן, כל העבודה הזו הייתה מתבצעת בכל אתר בנפרד - לא יעיל, מסורבל, בכל פעם צריך לשלוח גרסא חדשה לכולם כדי שיריצו וישלחו בחזרה . . . 
• כשזה On Platform”, יכול להיות מישהו אחד שעושה את החישוב - ואז הקוד שלו יכול לרוץ בכל האתרים השונים.
• אפשר לדבג (Debug) מרחוק, לקבל תוצאות והתפלגויות ולתקן במרוכז.
• אתגר נוסף הוא נורמליזציה בין האתרים השונים - צריך להביא את המידע לאותה “הצורה” - אותן יחידות וכו’
• נגיד - In 1999, NASA lost the $327 million Mars Climate Orbiter because Lockheed Martin used imperial units while NASA used metric, causing the spacecraft to crash into Mars due to a simple math error]
• בסוף, בניית ה-Data Pipeline והנרמול זה אחד השימושים הכי נפוצים של הפלטפורמה.
• הקוד (ולא התוצאה) נשלח בצורה של Container Image - רץ באתר מרוחק, וכמה במקביל.
• רץ Isolated, ללא גישה למערכת הקבצים, לרשת, למערכת ההפעלה וכו’.
• רק מקבל גישה לאותו Data ספציפי שנבחר, יכול לכתוב את התוצאות רק למקום מאוד מסויים - והתוצאה נשמרת כ-Data Set חדש באותו מקום שהוא רץ, ונשארת שם (לא נשלחת לשום מקום).
• אלא אם זה חישוב מבוזר - אז , ניתן לקבל למשל חישוב של ממוצע, תחת הגבלות של Anonymization ו-Privacy.
• ו-Rhino הוא זה שדואג להעביר את ה-Container, לוודא שהוא רץ במקום מבודד, מעביר רק את מה שמותר ולא את מה שאסור.
• במקרה של אימון מודל, כן יש Networking מוגבל בכל אתר, כדי שיוכלו להתחבר. 
• יש Orchestrator של ה-Federated Learning, שרץ לרוב אצל Rhino בענן - כולם מתחברים אליו, ואז יש תהליך איטרטיבי (Iterative) שבו כל אחד מה-Clients מחליף מידע עם ה-Orchestrator.
• בתהליך הזה נשלחים המשקולות - וזה חלק מאותו Training Algorithm: מה נשלח ואיזה Differential Privacy מופעילים.
• בסוף, המשקולות נשמרים או בענן של Rhino, או באחד מהאתרים שהשתתף בתהליך - בהתאם להגדרות של המשתמש הספציפי.

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

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

[30:20] ענייני Trust
הלקוחות צריכים לבטוח ב-Rhino - לוודא שהכל עובד בדיוק לפי הפרוטוקול?

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

[32:08] זכרונות מקצה הגלקסיה / SETI@Home
אורי מזכיר שבתחילת שנות ה-2000 היה פרויקט בשם SETI@Home, שבו אנשים תרמו כוח מחשוב לחיפוש חייזרים [Search for Extraterrestrial Intelligence].

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

[34:25] גיוסים וסיום

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

תודה רבה, ובהצלחה.

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

רק מספר 509 של רברס עם פלטפורמה - באמפרס מספר 90, שהוקלט ב-1 בינואר 2026, שנה אזרחית חדשה טובה! רן, דותן ואלון באולפן הוירטואלי (עם Riverside) בסדרה של קצרצרים וחדשות (ולפעמים קצת ישנות) מרחבי האינטרנט: הבלוגים, ה-GitHub-ים, ה-Rust-ים וה-LLM-ים החדשים מהתקופה האחרונה. 🎗️

[00:46]  רן - חדשות, מחקרים ומגמות

• מתקפת הסייבר על Anthropic
• מתקפת סייבר משמעותית כנגד חברת Anthropic (היוצרים של Claude), שבוצעה ככל הנראה על ידי “גורם מדינתי” [לכאורה עם דגל אדום ורפובליקה עממית . . . ], ב-Scale מאוד גבוה - Disrupting the first reported AI-orchestrated cyber espionage campaign \ Anthropic
• השתמשו ב-Claude Code כדי לעקוף את ההגנות והאבטחות השונות.
• הייחוד במתקפה (מעבר ל-Scale גדול מאוד והגורם המדינתי שמאחוריו, לפחות בהתקפות מתועדות) היה השימוש במודלי שפה (LLMs) כדי לעקוף מנגנוני הגנה (Jailbreaking) ו"אבטחות" של מודלים אחרים.
• השוואה לאירוע ל"אירוע הצ'ירוקי" [Cherokee] (ההשתלטות מרחוק על הג'יפ - Hackers Remotely Kill a Jeep on the Highway—With Me in It | WIRED), אירוע מכונן שמעיר את התעשייה לסיכוני האבטחה הממשיים ב-AI - אז זה היה אירוע מכונן בתעשיית הסייבר להגנת כלי-רכב. 
• [וכן - כמעט בדיוק שנה מאז האזכור הקודם של הרפרנס - אז ב - 488 Developing with LLMs securely, with Guy from Pillar]
• מי אמר “Big High-Tech” במקום “Big Pharma”? [אלון, בפניייה נרגשת לספונסרים].
• מחקר של מכון METR ו"חוק מור" של ה-AI 
• [כאן - Measuring AI Ability to Complete Long Tasks - METR]
• מחקר של מכון METR [שפגשנו לאחרונה ב-Bumpers 87] מראה גרף אקספוננציאלי של משך הזמן שבו מודלים מסוגלים לבצע משימות בהצלחה (“לסיים בהצלחה משימות ארוכות”).
• אם ב-2020 מודלים ביצעו משימות של שניות, כיום (עם מודלים כמו GPT-5.1-Codex-Max ו-Claude Opus שכמעט “מחוץ לגרף”) הם מבצעים משימות שנמשכות שעות.
• זה לא בהכרח זמן ה-Inference (אולי גם), אלא היכולת שלהם לעשות Reasoning יותר ויותר עמוק ולקחת משימות יותר ויותר מורכבות (וגם להצליח בהן).
• אלון העיר שזהו נראה גמו סוג של "חוק מור [Moore's law] של ה-AI" - אורך המשימות ש-AI יכול לעשות ~מכפיל את עצמו כל כ-7 חודשים .
• יש עוד מלא פרטים במחקר עצמו, מאוד מעניין.
• עוד מעולם ה-LLM והשפות - Google Antigravity ומלחמות ה-IDE:
• גוגל השיקה IDE חדש בשם Antigravity שמבוסס על Gemini 3, מה שמסמן את תחילתה של "מלחמת ה-IDE" (מול VS Code, Cursor ו-Windsurf, לפחות מה שעוד קיים…)
• [או לפחות את תחילתה המחודשת, מאז 482 Bumpers 84 ו-487 Bumpers 85, ובהמשך ל”מלחמת הדפדפנים החדשה” [?“The Browser strikes back”].
• יש גם חבר חדש: AWS - Kiro
• הנה הפוסט - Google Antigravity Blog: introducing-google-antigravity
• רן ניסה, בעיקר עבור דברים פשוטים וקטנים - נחמד, עובד . . . .
• אלון ציין שהכלי עדיין לא בשל -Gemini 3 פחות טוב בקידוד לעומת המתחרים, נוטה לקרוס לא מעט ומציג הודעות שגיאה מביכות שמבקשות לעשות Restart ל-IDE.
• ומצד שני - Google הפתיעו לא מעט לאחרונה עם הכלים שלהם [NotebookLM זה קסם], אז מוקדם להספיד.
• סיכום שנת 2025 של אנדריי קארפטי (Andrej Karpathy): רן סקר בהרחבה את הנקודות העיקריות -
• ראשית - RLVR (Reinforcement  Learning from Verified Rewards): טכניקת אימון שהוכחה כיעילה ואפקטיבית מאוד על ידי DeepSeek הסינית [יש מצב שהייתה קיימת לפני], כתחליף/תוספת ל-RLHF.
• מגמת-שוק של “Cursor for X": מגמה של כלי אוטומציה מבוססי AI לתחומים שאינם פיתוח (כמו צלמים או מארגני אירועים, מספרות וכו’ .
• נראה ש-Cursor הפך למעיין “מושג” של “עושה משהו טוב -בכללי”, ועכשיו מתחילים לראות את זה גם ב-Domain-ים שהם לא פיתוח.
• שתי גישות שונות לפיתוח - Local vs. Codex & the Cloud: הדילמה בין הרצת Agent-ים מקומית (שליטה מלאה, כמו Claude Code, Cursor ואחרים, “על ה-Laptop שלכם”) לבין הרצה בענן (תחזוקה לילית, כמו Codex).
• זו לא בחירה בינארית - בהרבה חברות יש גם וגם, וגם האדון Karpathy לא מחווה את דעתו ספציפית.
• רן מאמין במודל היברידי: פיתוח “משמעותי” - אקטיבי - ב-Laptop (הוראות ,תיקונים), ותחזוקה שגרתית (Coverage, Maintenance) בלילה ב-Cloud.
• “תעבור על ה-Code, תמצא Code Smells ותתקן אותם . . . “ - “לא רוצה להיות Hands-on על הדבר הזה, שיודיע לי בבוקר מה הוא עשה" . . . .
• אלון - הרי בסוף לא יהיה “Human in the Loop”, והכל ירוץ “איפשהו” - ואנחנו פשוט נקבל תוצרים וניהיה כמו מנהלי מוצר [לא מוצא אימוג’י של אלון מצטלב, אבל זה מוקלט, כן?], ונכוון אותו “ימינה, שמאלה” . . . 
• שפות תכנות ישתנו (מי מכיר Assembler?)
• מיני-ראנט של דותן - “נכנסנו לעולם פנטזיה, ואנחנו שותים מה-Kool-Aid”. . . תוכנה זה קשה, גם לאנשים חזקים.
• אם טורחים להתעמק בזה (והרוב לא), רואים שהמון Skills הם Conflicting, ומישהו צריך להחליט . . . . 
• רן מדבר על בחירת שפות ותשתית שתתאים ל-LLM (ולא למתכנת, שלא הולך לכתוב כמעט קוד…) - “אז מה אם זה פי-3 שורות קוד?”.
• אלון - “אל תשאלו מה ה-LLM יכול לעשות בשבילכם, תשאלו מה אתם יכולים לעשות בשביל לעזור לו” . . . . אם אין דוקומנטציה, אין מה לגעת.
• דותן ממשיך לטעון שזה גל סינוס, או ספירלה - ושכבר היינו שם (היי Visual Basic וה-Drag & Drop - מה עם זה באמת? ועם בית הקברות ע”ש Silverlight . . . .).
• נתראה במשבר התוכנה הבא, או לכל הפחות בהתערבות Bumpers הראשונה לשנה זו #RemindMeInOneYear
• וכן, גם כאן DHH מחכה בסיבוב כדי לכתוב את זה From Scratch.
• תחושת ה"להישאר מאחור": Twit נוסף של Karpathy שעורר גלים, על כך שהוא מרגיש מוצף מכמות הכלים והידע החדש, תחושה שרבים [AKA “אזובי הקיר”] מזדהים איתה.
• “כלים צצים כפטריות אחרי הגשם” . . . .
• רן משווה את זה לתקופה שבה כל בוקר היו שלושה Framework-ים חדשים של Frontend, דותן ואלון טוענים שאכן עבור מפתחי FE זה מאוד טבעי (“מה, רק כלי אחד חדש ביום?”) . . . 
• בשנתיים האחרונות נראה שזה קצת עצר - והתחלף בגלים של כלי AI.
• לא ברור אם אנחנו כבר בשיא ה-Hype, אבל זה לגמרי Hype - וזה ירגע, ונחזור לאיזשהו Steady State.
• תגובה ספציפית ל-Thread שאלון ודותן מאוד מסכימים איתה - “ה-AI לא החליף מתכנתים - הוא החליף את שפות התכנות” . . . . די מסכם את האירוע.
• זוכרים את ה-Linux Foundation? אז עכשיו עם Agentic AI!
• הקמת Foundation חדש תחת ה-Linux Foundation - קבלו את ה-Agentic AI Foundation (AAIF) לריכוז פרויקטי AI אג'נטיים.
• איזושהי מטרייה רשמית פתוחה, שמגובה ע”י מספר חברות גדולות.
• שלושת הפרויקטים הראשונים כוללים את MCP (של Anthropic), Goose (של Block - וגם מ-496 Bumpers 86) והפורמט של AGENTS.md (מבית OpenAI).
• את MCP כולם אולי מכירים [הי - Prepare for the Fragmented Web Revolution / Liad Yosef & Ido Salomon], אבל יש כאן את ההבנה שהוא כבר כל כך Mainstream עד כדי כניסה ל-Linux Foundation.
• רן סיפר שהוא משתמש ב-Goose לאוטומציה מקומית של הפקת הפודקאסט והבלוג (עוד אחד, לא זה . . . . ).
• קצת בסגנון של Cursor ושל Claude Code - אבל הסגנון שלו הוא לא רק על כתיבת קוד, אלא על “אוטומציה כללית”.
• יכול להשתמש באיזה מודל שתרצו, ועושה אחלה עבודה.
• ועל AGENTS.md יש אייטם בהמשך [גרסת הפודקאסט ל”יש על זה שקף!” . . . .]
• שינוי תפיסת הפיתוח (Kent Beck)
• אז כמה זמן לא קראתם את Kent Beck? הנה - Party of One for Code Review! - by Kent Beck.
• אחד מהוגי הדעות של עולם ה-Software Craftsmanship, התגעגענו.
• הפוסט טוען ש-Code Review הפך לצוואר בקבוק בעידן ה-AI.
• אמ;לק - “אנחנו צריכים לחשוב מחדש על כל התהליך של Code Review”.
• בעולם של LLMs, קצב קריאת הקוד (ע”י אנשים) הפך להיות ה-Bottleneck האמיתי.
• רן מזדהה (הבעיה אמיתית) - אבל לא אוהב את הפתרון המוצע [בגדול - ניסיון למכור את CodeRabbit, פרסומת מאוד לא סמויה] . . .
• לדותן יש השגות על אנשים “לא-זקנים-אבל-מותיקי-ומכובדי-התוכנה” [ניסיון להעליב במרוכז את Linus, את Kent Beck ואת Uncle Bob, כי למה לא? . . . ]:
• בכל פוסט כזה יש גרעין של אמת מאוד נכונה, יחד עם תחזית לא-פופולארית קדימה ששווה לחפש ולהבין.
• החוויה היא מאוד אישית (בשונה מ-“דיברתי עם אלף מפתחים וזה הממוצע”).
• בסוף הם גם יתנו רפרנס ל-Sunk-Cost שלהם (“ניסיתי - אבל בסוף אני אוהב את מה שעבדתי איתו קודם”). זו “הגרביטציה” שלהם, זה ה-DNA.
• ספציפית, הטענה בפוסט הזה היא שהקוד הוא Shared Resource של האדם והמכונה, וצריך להתאים לשני הצדדים.
• המטריקה היא האם הקוד הוא Manipulable - “האם ניתן לתמרן אותו להראות אחרת?” - וזה KPI ממש מגניב.
• “עד כמה הקוד הזה הוא בטון או פלסטלינה?” - השאיפה ל”פלסטלינה”, כי תוכנה זה משהו שכל הזמן משתנה וכל הזמן מתעצב.
• אלון בגישה אחרת לגמרי - לא מאמין במודולריות (ואת Clean Code הרי זנחנו מזמן).
• העתיד הוא כנראה ויתור על קריאת הקוד ומעבר לבדיקת Interface-ים וטסטים בלבד.
• כל השאר זה Black Box שלא אכפת לי לשכתב מחדש, כל עוד ה-Interface-ים נכונים, כי עלות כתיבת הקוד מחדש צונחת לאפס, ועלות התחזוקה של מערכת מורכבת היא הרבה יותר גבוהה.
• “בחצי השנה האחרונה קרה לי הרבה פעמים שעדיף היה פשוט לכתוב הכל מחדש”.
• לכתוב קוד זה לא ה-Bottleneck - ואנחנו עדיין תקועים עם פרדיגמה שאומרת שכתיבת קוד (“תקתוק”) זה השלב הכי איטי בפיתוח תוכנה, וזה כבר לא נכון.
• דותן מסכים שזה נכון, תחת שתי הנחות סמויות - שהטסטים נכונים ושה-API נכון . . . . אבל האם מה שאתה מנחה את ה-AI לעשות בכלל נכון מלכתחילה?
• לא נימנע ממונחים טכניים (“Domain-יים”) ומלמדל טרנזקציות כמו שצריך.
• אם אתה משחרר גם את זה ל-AI (“בוא תיהיה עכשיו מומחה FinTech” . . . .) - השאלה היא עד כמה הוא יהיה צודק בדבר הזה, ועד כמה תוכל להביא אותו ל-Domain שלך.
• ה-Business Logic.
• אלון קורא לחלק הזה “הנדסת תוכנה” - בשונה מכתיבה (קידוד) פרופר; ובכלל - “הכל זה Trade-off-ים”.
• דותן אומר שבסוף אין גורם מגביל למספר הטעויות שאתה יכול לעשות ככה [כיף במסיבות וכו’] . . . .
• ואם כבר טעויות (לא אלה) -  Peter Steinberger מדבר על Shipping at Inference-Speed
• זה ה-Bottleneck שלו - מהירות ה-Inference של המודלים.
• האיש מעיד על עצמו שהוא עובד על 3-8 פרויקטים במקביל.
• [הפסקה מתודית - גשו לקרוא מחדש את Critical Chain של אלי גולדרט; צווארי הבקבוק משתנים, אבל העיקרון נשמר].
• בקצרה - גם הוא כבר לא קורא את הקוד של עצמו ומתמקד רק בהחלטות החשובות, הארכיטקטוניות (השפה, ה-Ecosystem, התלויות ואולי גם הממשקים).
• את כל השאר - תן ל-Agent לעשות [AKA “דבר עם הסוכן שלי!”].
• דותן עשה ניסוי על עצמו [שוב] והתחייב לפתח כמה פרויקטים במקביל (כי אפשר) - ומסתבר שזה קשה, מנטלית וקוגניטיבית . . . 
• ההתייחסות של Peter לזה היא שתכל’ס יש בדרך כלל פרויקט אחד שהוא באמת צריך להקדיש לו מאמץ מנטלי, ולשאר בגדול לא.
• אייטם אחרון של רן (שמוקדש לדותן) - איך Claude Opus 4.5 מייצר MIDI Mixer בערך במצמוץ: One example of something I couldn't believe Claude Opus 4.5 could generate until it did: a full-on MIDI mixer as a terminal app, written in Rust.
• כן, Rust . . . .
• הדגמה ליכולת של Claude Opus לייצר אפליקציית Terminal מלאה ב-Rust (מיקסר MIDI) ב-Prompt אחד או שניים, עם “אפס התערבות אנושית”. מרשים.
• זה לא “One Shot”, אבל 80%~ ב-Prompt אחד - ואז תיקונים . . . .
• דותן מוסיף ש Terminal UI זה משהו שממש קשה לבנות, ואין הרבה חומר בנושא (לאימון).
• רן מציין שגם בפוסט הקודם (Shipping at Inference-Speed) מדובר בין השאר על שימוש ב-Cross-Reference (“עלה ספרייה אחת למעלה ותממש את אותו הדבר”).

[46:23] דותן - כלים, ספריות ו-Open Source

• פרויקט שנקרא Chatterbox (“אחד הפרויקטים היותר מדהימים שיצא לי לראות בזמן האחרון”)
• מודל Text-to-Speech ב-Open Source באיכות גבוהה מאוד, שעושה עבודה מטורפת (יש Demo).
• כולל יכולת Voice Cloning (שיכפול קול) מקובץ אודיו קצר.
• דותן לא בדק את העברית של זה - אבל הרעיון של לשכפל את ההקלטה הזו נשמע כמו פרויקט מעניין…
• [ובכלל - עבור עברית, החבר’ה של Ivrit.ai ממשיכים לעשות דברים ממש מגניבים - 485 Ivrit]
• לחובבי Draw.io - הנה next-ai-draw-io
• אינטגרציה של AI בתוך Draw.io (“מישהו הוסיף לזה AI”)
• זה מאפשר ליצור דיאגרמות ולערוך אותן באמצעות פרומפטים טקסטואליים.
• יוצר בלוקים, מקשר אותם - ואז אתה יכול לתקן אותו ולערוך ולעשות Fine Tuning.
• רן בדק את הכלי בלייב ויצר חתול (עם אוזן הפוכה) - מראה ב-Live את כל ה-Reasoning, נחמד.
• “100% חתול, 90% טוב” . . . .
• למי ששמע על N8N [אלון אמר על זה משהו מתישהו, לא?] - אז sim הוא “N8N להמונים”
• זה גם Open Source, אבל בשונה מ-N8N “שצמח מהאוטומציה של פעם” [אי שם לפני ה-AI], זה נבנה “מאפס”.
• עוד אופציה לחובבי הז’אנר.
• אלון טוען שה-UX “דומה, אך קצת יותר חמוד”.
• פרויקט שנקרא pg-aiguide - נועד לעזור ל-Agent-ים לכתוב SQL ולעבוד עם Postgres
• מגיע מ-timescale - חברה באיזורי ה-Postgres המסחרי.
• זה פרויקט Open source ואפשר ללכת ולראות מה הם עושים - קיבל המון אהבה מהרשת.
• דותן טען ש-timescale חברה מעולה, אבל זה קצת “בלון מנופח”.
• יש פה 4 Skill-ים - 3 מהם כנראה למוצר המסחרי והרביעי הוא איך לעצב טבלה ב-Postgres (הוראות ל-LLM).
• כשמסתכלים על ה"Skill" הזה, אז אם ה-LLM לא יודע את זה לבד, המצב חמור.
• והדבר השני שהם עושים זה בגדול  “לשתות את הדוקומנטציה של Postgres” ולחשוף ל-LLM.
• שובו [כאן] של AGENTS.md מהמערכה הראשונה
• ניסיון לייצר סטנדרט תעשייתי להוראות ל-Coding Agents (בפורמט Markdown) - משהו שנכון מאוד לעשות.
• מטרתו להחליף את הפורמטים הספציפיים (כמו Cursor Rules) בקובץ אחד סטנדרטי שנמצא ברמת ה-Repo ומסביר לכל Agent איך לעבוד עם הפרויקט.
• רן ציין בהתחלה שזה אחד הפרויקטים שנכנסו תחת המטרייה של ה- Linux Foundation.
• לכל אחד מהכלים היה את הפורמט שלו - וזה איזשהו מאמץ “לתכלל את כולם”.
• ברשימת ה-Adoption יש את כולם - חוץ מ-Claud Code . . . . אפילו Cursor שם.
• “סיר לחץ” - לכל מי שעוד חושב לפתח פורמט משלו: “אל תשארו בחוץ”.
• רן מזכיר ש-OpenAI היו ה-Sponsor הראשון שלהם, וכנראה עומדים מאחורי זה.
• ועכשיו ל - Anthropics Skills - 
• כן - Anthropics. זה נראה כאילו זה לא שלהם - אבל זה כן.
• מאגר של "כישורים" (Skills) מוכנים ל-Claude (כמו "איך לצייר Processing").
• בעולם מושלם הם כבר היו חלק מה-Agent ולא היה צריך להוסיף - אם ה-LLM היה לוקח 1000 דוגמאות של Processing, הוא כנראה היה מבין לבד.
• אלון חושב שה-Skills נכונים - אבל קצת עשו לזה Abuse, ומשתמשים זה לפעולות שאמורות להיות בסיסיות.
• זה מזכיר לדותן את הדור הראשון של ה-Linters - “חוזרים על אותן טעויות”.
• רן טוען ש-Skills שימושיים יכנסו בסוף לתוך “הזכרון של ה-LLM” (לתוך המשקולות) - אבל צריך לזכור שזמן אימון של מודלים נמדד בחודשים, אז אם רוצים משהו “עכשיו”, זה שימושי.
• חוץ מזה, יש את עניין ה-Context Window - וזה שימושי לניהול ה-Context ולמניעת עומס ("Pollution") על ה-Prompt כשלא צריך את ה-Skill הספציפי (או לטעון באופן דינמי).
• ועוד עניין - ה-Skills עוזרים לעקוף את “הכיווץ הפרמטרי” של המידע שנדחס לתוך המודל הכללי, ונותנים “עוד איזשהו Boost נוסף” ליכולת הספציפית.
• דותן טוען שבשונה מלמשל AGENTS.md, שיהיה כאן בעוד שנה - Skills אולי לא.
• רן אומר שה-AGENTS.md יהיה “בשליטתך”, לעומת Skills שיהיו “שקופים” (או כמו שאלון אומר - הם “יבנו דינאמית”).
• [יאללה - עוד #RemindMeInOneYear]
• עוד אחד - nocodb
• אלטרנטיבה ב-Open Source ל-Airtable (בתקופת הטירוף, לפני ש-Notion קצת הוריד להם את זה).
• נראה אותו דבר, “כל יכול”; אחלה שזה Open Source.
• אלון מציין שזה מעניין כי זה נראה משהו לא חדש, אלא פרויקט שהתחיל מזמן.
• דותן אומר שזה אולי ה-Boost שפיתוח עם AI נותן, ופתאום יש אנרגיה לפרויקטים “שהתעייפו”.
• ול-fumadocs.dev - שזה Yet another Documentation Framework . . . 
• זה Framework לדוקומנטציה עם עיצוב דיפולטיבי מצוין.
• לא משנה כמה זה יותר או פחות טוב מ-Docusaurus - זה נראה טוב וזה שימושי.
• ועוד כלי Kanban לניהול פרויקטים - fizzy מבית Basecamp (הי DHH)
• אז Basecamp יצאו ביוזמה של “Open Source מסוג אחר” - מוצרים מסחריים שהם בונים, אבל הרעיון הוא שהם כל כך טובים, כך שיש רשיון “לעשות מה שאתה רוצה” - חוץ מליצור תוכנה שאתה מוכר . . .
• מה שחדש פה זה “שזה ישן” - אותו רעיון של Kanban “כמו פעם”, רק Made Simple: בלי פיצ’רים, רק מה שצריך.
• למי שרוצה לאנדקס את ה-LLM-ים שלו: CocoIndex
• מנוע אינדקסים High Performance (כתוב ב-Rust) ש”לועס Data” עבור RAG או עבור Vector Databases.
• דותן לא בטוח מה בדיוק הנישה של זה - אפשר לעשות את אותו הדבר בצורה בסיסית ואלמנטרית, לא באמת חייבים לייצר גרף ולהריץ אותו - אבל נחמד שיהיה.
• שני פתרונות לאנשים שבונים Agent-ים -
• אז e2b.dev הוא Open Source אבל גם Hosted, שנותן להריץ Agent-ים ב-Sandbox (נגיד לפתוח Browser או להריץ קוד).
• הגרסא המסחרית היא סוג של “Pay as you go”.
• ומשהו מאוד דומה, לפחות בטרנד, זה Trigger.dev
• זה Open Source Platform ל-Background Jobs 
• אם יש לכם AI Jobs של Agents או Processes, ואין לכם את התשתית - אז אפשר להריץ כאן
• שני הפתרונות שימושיים עבור כל פרויקט תוכנה בגדול - אבל ה-”AI” נותן להם זויות שיווקית מעניינת.

[01:07:54] אלון - Cloudflare בוערת ואנימציות

• תקלת הענק ב-Cloudflare [נגיד זה Cloudflare outage on December 5, 2025]
• בהמשך לרשומה שרן הוסיף לפני חודש ושברה את הרשת [למקרה שהתבלבלתם עם Cloudflare outage on November 18, 2025] - הפעם נראה שהנפילה של Cloudflare נגרמה בעקבות עדכון אבטחה ל-CVE שקשור ל-React Server Components.
• הוגדר כ “CVE 10” (הכי גבוה, Critical).
• נטען שהעדכון גרם לצריכת זיכרון מוגברת שהפילה את ה-WAF (כביכול כי הם ניסוי להגן על הלקוחות שלהם מפני פירצת האבטחה).
• דותן מריח שני מחנות - נראה (לא באמת, אבל סיפור יפה) שיש "מלחמה פנימית" בתוך Cloudflare בין תומכי Lua (“הדור הישן”) לתומכי Rust (“הדור החדש”), שמתבטאת בפוסט-מורטמים המאשימים את הטכנולוגיות השונות . . . [אם חשבתם שהפיכה באירן מוציאה מאנשים אמוציות].
• נכון לשעת הקלטת הפרק, ב-2026 עדיין לא נפל האינטרנט [או השלטון באירן, האינטרנט שם דווקא כן] - אבל תתכוננו.
• חצי-מצחיקול לסיום - sysc-Go (אנימציות לטרמינל ל-Go)
• ספריית Open Source ב-Go שמאפשרת ליצור אנימציות מרשימות ב-Terminal (אש, גשם, זיקוקים, דינוזאורים . . . ).
• אלון מציע לשלב את זה בסיום ריצות של Claude Code בתור "חגיגה ויזואלית”. 
• [אפשר גם לסיום פרקים של Bumpers].

Fireworksאז זה היה Bumpers 90 - תודה!
קישור לקובץ

פרק מספר 508 של רברס עם פלטפורמה, שהוקלט ב-30 בדצמבר 2025, קצת לפני שנגמרה השנה וקצת אחרי שבאמת התחיל סוג של חורף - אורי ורן לוגמים תה ומארחים את מישה פיינשטיין מחברת Bria AI כדי לדבר על איך עושים תמונות בצורה שבאמת התכוונתם (וגם קצת על חורף). 🎗️


[01:01] מישה ו-Bria AI
(רן) וכן, אורי - למרבה הפתעה, שוב אנחנו מדברים על AI, הנושא החביב עליך . . . .(אורי) AI, הנה . . .  התגעגעתי.(רן) מעולה, אז נתחיל בהצגה שלך, מישה, ושל Bria - ומשם נצלול . . .

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

(אורי) . . . . אולי קצת על מה הרקע שלך ב-Computer Vision?

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

(אורי). . .  זה מתחיל להתקרב לדברים המעניינים באמת ב-AI . . . 

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

(אורי) איזה דת או איזה Data?

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

(רן)  . . . . האם יש הבדל? זהו . . . 

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

(רן) ורק לסיים את ההקדמה - תפקידך ב-Bria?

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

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

[04:44] המקצועיות נכנסת לתמונה / הבעיה בעיני המתכנת

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

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

(רן) אז איך עושים את זה?

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

(אורי) קרה לי השבוע, בתמונה הראשונה שג'נרטתי (Generated) - אחלה חוויה, הפתעות נעימות, המסר עבר.

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

(אורי) אבל לאורך זמן מודל יכול להבין את הראש של הבן אדם. זאת אומרת, לקבל יותר ויותר Context . . . .

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

(רן) אבל בוא, שנייה לפני שאנחנו . . . זאת אומרת, קצת התחלת לדבר על פתרון - אבל שנייה לפני שאתה מציג אותו,נסביר שוב את הבעיה מעיני המתכנת.אנחנו, כמתכנתים - נורא קל לנו לעשות Vibe Coding ל-Whatever, לא יודע, Tic-Tac-Toe, to do, או whatever, נכון? נורא קל: אתה אומר ל-Cursor, או Whatever, “תעשה לי כזה” - והוא עושה לך כזה. ויכול להיות שאם כל מה שרצית זה לעשות איזשהו POC, אז בזה סיימת.אבל אם יש דרישות מאוד ספציפיות של לקוח, או אם יש איזה שהם Design Rules או Guidelines שאתה צריך לעמוד בהם, או שיש דרישות מוצר שאתה צריך לעמוד בהן - זה לא מספיק רק להגיד לו “תעשה לי Tic-Tac-Toe!”, נכון?פתאום אתה צריך פינות מעוגלות, פתאום אתה צריך, לא יודע, זמן תגובה . . . פתאום אתה צריך יכולת לעשות Pinch ו-Pinch-In ו-Pinch-Out או whatever. זאת אומרת, יש המון דברים שמראש לא אמרת, ואתה, אם היית מפתח, היית, לצורך העניין, Frontend-יסט, היית עושה אותם, כי זה חלק מה-Spec - אבל ב-Vibe Coding זה הולך קצת פחות טוב.עכשיו, כמובן שיש דרך לעשות את זה נכון גם שם, אבל פה אני בעצם מנסה להמחיש בשפת הפיתוח את ההבדל בין“תעשה לי אפליקציה!” לבין “הנה, ככה בדיוק אני רוצה שהאפליקציה הזאת תתנהג - ועכשיו תעשה לי!”. ואת זה אני באמת עושה בצורה שהיא מאוד Structured.

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

(אורי) אני חושב אבל שיש משהו, עוד הבדל כזה - למודל שצריך לכתוב את הפיצ'ר הבא, יש Context שהוא כל ה-Codebase. וב-Codebase כבר יש, תכל’ס, את ה-Design System, עם הפינות המעוגלות ועם ה...(רן) כן, זה כמו “תייצר את הסצנה הבאה בסרט שכבר ראית” . . . (אורי) נכון - ורק תגיד לו על מה מדובר בסצנה, והוא ידע את כל ה-Setting בתמונה. בטח שלאיש Creative, שמדמיין את השמש זורחת לו אתה-יודע-מאיפה, זה יותר קשה - זה כל פעם “לברוא את זה מחדש” ולנסות לפגוע.

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

[13:13] אימון של מפלצות גדולות / מה זה משנה?

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

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

(רן) אוקיי, אז אתם לגמרי מאמנים מודלים משלכם - מודלים שמייצרים תמונות. זאת אומרת, זה “מפלצות גדולות”: האימון שלהם יקר, אני מנחש. איך מתפעילים את כל זה?(אורי) אני כל הזמן מדמיין שה-Input של ה-JSON הזה זה תכל'ס Dashboard של Photoshop או Lightroom - מקום שבו הם מייצרים תמונות. יש לי כמה צלמים במשפחה, אני כל הזמן רואה את ה-Dashboard-ים האלה, ואוקיי - מתמונה לתמונה אתה יכול ללמוד את הפיצ'רים השונים של . . .  ועכשיו אתה רוצה לשנות את ה-Lighting? אז כאילו . . .

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

(רן) אז מה אנחנו אומרים? מהם גדלי המודלים יש שאתם מאמנים? 

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

(רן) כלומר, לכל קמפיין או לכל Brand כזה בעצם ממשיכים ועושים Fine-tuning למודלים?

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

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

• (מישה) יש כאלה. יותר טוב - כן; יותר קל - כן; פחות Viable מבחינה Commercial-ית מבחינתנו.

(רן) בגלל התוכן, בגלל ה...

• (מישה) . . . בגלל שאנחנו עובדים בסוף B2B, אנחנו עובדים עם חברות קומרשיאליות (Commercial) גדולות, שצריכות את המודל הנשלט, שצריכות את “המודל הענקי”.
• אנחנו בעצם מאמנים על Data שהוא לחלוטין נקי - אנחנו לא עושים Scraping לאינטרנט, כל הData שלנו הוא ממאגרים, מפרטנרים, שבעצם נתנו לנו Licensing על ה-Data שלהם.
• קרוב למיליארד תמונות שהן Licensed - מ-Getty images, מ-Shutterstock ו-envato - כל החבר'ה האלה.
• וזה מבטיח ללקוחות שלנו לא רק שהמודל מרצה את מה שהם צריכים, אלא שהוא גם לא מייצר דברים שאחר כך יסבכו אותם.

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

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

[18:39] איך נראה Cycle של אימון כזה?

(רן) אז כמה זמן לוקח לאמן מודל כזה, של 8 מיליארד על, אני מניח, מיליארדי תמונות? איך נראה Cycle של אימון כזה?

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

(רן) כן, איפה שלוקחים את ה- cutoff הראשון או את ה...

• (מישה) אז בעצם צוות המחקר שלנו - הוא עובד כל הזמן. הוא בעצם במסע מתגלגל כל הזמן לאמן את המודל הבא והמודל היותר-טוב שלנו.
• וזה מתחיל מתהליכי Onboarding ל-Data של פרטנרים חדשים - לזהות, בעצם לעשות אנליזה על הקטלוג שלנו, לזהות איזה Domain-ים חסרים לנו בקטלוג.
• אני לא יודע, אם אנחנו פתאום רואים שאנחנו לא מייצרים תמונות מספיק טובות של ציורי-שמן - צריך להביא עוד ציורי-שמן לקטלוג.
• אז צריך לעשות Onboarding, אנליזה, צריך לעשות Data Preparation . . . בעצם, צריך להכין את כל ה-JSON-ים האלה, שיתאימו לכל התמונות.
• כל זה הוא בעצם Pre-training כזה, שעוד לפני ש”הדלקנו את ה-GPU” - אולי זה קצת לא נכון, אבל לפני שהדלקנו את ה-GPU הראשון לאימון, יש שם הרבה GPU-ים שעובדים לפני - אבל לפני שהדלקנו את ה-GPU הראשון לאימון.
• האימון עצמו הוא בעצם אימון שנעשה “בשיטת פירמידה” - אנחנו מאמנים מרזולוציה נמוכה, אנחנו מאמנים קודם כל את המודל ברזולוציה מאוד נמוכה.
• המודל לומד בשלבים האלה קשרים סמנטיים, קשרים בין ה-Prompt לתמונה, לומד קצת אנטומיה מאוד גסה . . . 

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

• (מישה) נכון, תמונות ב-256-256, ממש Thumbnails כאלה . . .

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

• (מישה) נכון, ומה שלמדנו בכמה שנים האחרונות שאנחנו מאמנים מודלים, זה שזה שלב מאוד מאוד משמעותי, והוא משמעותי משתי סיבות:
• הוא משמעותי א' - כי הוא מוזיל מאוד עלויות.
• זאת אומרת, ככל שמאמנים על רזולוציה יותר נמוכה, אז זה מין הסתם יותר זול.
• אז אפשר פשוט לעשות הרבה יותר - ובעצם “לסחוט מהמודל” בשלב הזה די הרבה.
• מה שהפתיע אותנו זה שדי בקלות אפשר בשלב הזה כבר לשים לב ל-Fault-ים במודל - גם דברים שהם מאוד עדינים, כמו דברים שמודלים הרבה פעמים נכשלים בהם, כמו אנטומיה עדינה.
• למרות שעדיין רואים דברים . . .  לא תראה “אצבעות טובות” ברזולוציה הזאת, בשלב הזה של האימון - אבל אנשים שמאמנים מודלים כבר יודעים לראות, להבדיל בין “אצבעות רעות א'” ל”אצבעות רעות ב'” ולהגיד “אלה לא ישתפרו אף פעם ואלה - אפשר לעשות איתן משהו”.
• (רן) בסוף יהיו חמש . . . 
• (מישה) בדיוק.
• אז זה השלב הראשון.
• (מישה) אחר כך עולים בשיטת פירמידה ל-512 - וגם מצמצמים את סט התמונות.
• זאת אומרת, עולים גם ברמת הרזולוציה וגם מצמצמים את התמונות לתמונות שהן אסתטית “יותר יפות”.
• מתחילים מתמונות שהן מאוד . . . זאת אומרת, מראות Variety מאוד גדול של העולם, ולאט לאט מתחילים להתכנס לאסתטיקה.
• עד שמגיעים ל-1024-2048, ואם רוצים הלאה.
• ו-All in All זה אימון שלוקח בערך חודש וחצי של 24/7, על Cluster של בין 128 ל-256 GPUs High-End
• נקרא להם H200, B200 - כאלה.

(רן) כן, שזה גם לא זול  . . . 

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

[22:11] מי יעריך את המעריך?

(רן) אחד הדברים שהזכרת ככה ביעף זה “רואים שזה לא טוב”. עכשיו, אני מניח שאתם לא מסתכלים על כל התמונות,אלא גם יש לכם שיטות לעשות אבליואציה (Evaluation). כלומר, דרך לבוא ולהגיד, קודם כול לצורך האימון עצמוצריך “לשלוח אחורה גרדיאנטים” (Gradients), צריך שמישהו יגדיר איזושהי Loss Function ויגיד “אוקיי, זה טוב, זה לא טוב”.אבל גם יותר בכללי - כלומר, איך מעריכים את זה? אסתטיקה זה משהו מאוד מאוד אישי. האם להגיד “התמונה טובה“ או “הציור יפה”? אתה יודע, אחד יגיד א', השני יגיד ב' . . .  מה עושים בסוף? איך עושים אבליואציה (Evaluation) שהיא, נקרא לזה, קונסיסטנטית (Consistent)? [להרחבה Lenny’s Podcast - Why AI evals are the hottest new skill for product builders | Hamel Husain & Shreya Shankar (creators of the #1 eval course)](אורי) ואיך תמונה של פיקאסו הייתה עוברת את מבחן האנטומיה? . . .

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

(רן) . . . כלומר, ה-Arena השונות - LMArena  ו-Image Arena וכו’.

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

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

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

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

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

(אורי) את ה”קרבה” אתם עושים ב”פיקסל לפיקסל”, או . . .  איך אתם מודדים את “המרחק”?

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

(אורי) אפשר לקחת איזשהו מדד ממוחשב?

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

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

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

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

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

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

• (מישה) אז זה קצת יותר מורכב מזה.
• יש Gap שלא דיברנו עליו בעצם, וזה העובדה שאנחנו התאמנו על JSON-ים שהם בני אלף מילים.
• בסוף, כשבן אדם בא לכתוב Prompt, הוא לא כותב JSON.
• המתכנתים, בוני המערכות, כן יכולים מאוד בקלות להשתמש ב-JSON-ים, ולהעביר אותם ולעשות מניפולציות מאוד בקלות.
• זה חלק מהסיבה שעשינו פורמט שהוא ידידותי למפתחים.
• אבל בסוף, ה-End User שרוצה לייצר תמונה - הוא לא כותב JSON.
• המודל שלנו בעצם בנוי משני מודלים בפנים. אנחנו יכולים לחשוב על זה כמודל אחד שהוא ה-Reasoner ומודל אחד שהוא ה-Renderer.
• יש מודל שלוקח את השפה הטבעית שהבן אדם כתב, ממיר אותה ל-JSON - ובהינתן ה-JSON הזה יש לנו Renderer, שיודע לקרוא אותו ומאוד במדויק להפוך אותו לתמונה.
• כשאתה מדבר על זה ש”הטמפרטורה היא 0” - הטמפרטורה היא 0 בעצם אצל ה-Renderer.
• אבל ה-Reasoner עדיין מאוד חופשי ללעשות JSON-ים שונים, אם לא הגדרת לו במדויק ב-Prompt שלך דברים שהוא כן רצה לראות ב-JSON.
• מה שחשוב זה שמרגע שנוצר ה-JSON, אתה יכול להמשיך לכתוב Prompt-ים ולשנות אותם ויצאו JSON-ים שונים, או להכניס Seed-ים שונים ולהמשיך לעבוד ככה.
• אבל בעצם מה שאתה יכול לעשות בצורה שונה, זה שאתה בעצם יכול לעשות עכשיו, בהינתן JSON, בעצם חוזרת לך מהמודל לא רק תמונה - חוזר לך JSON ותמונה.
• ואתה יכול עכשיו לעשות מניפולציות על ה-JSON - אתה לא חייב ללכת ולהמשיך “לעשות רולטה” על ה-Prompt שלך, אתה יכול ממש...
• (רן) . . . את ה-Reasoning, אתה לא חייב לחזור אליו . . . 
• (מישה) כן . . . אם בגדול התמונה Makes sense ואתה רוצה להמשיך - אנחנו קוראים לזה “to refine” - אז אתה משנה עכשיו רק את התאורה, אתה משנה רק את האובייקט, אתה מוסיף אובייקט, אתה מוריד אובייקט . . . אבל זה כבר אלמנט מתקדם.

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

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

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

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

[31:22] הרבה דרכים לתאר (את אותה) תמונה / Uncanny Valley

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

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

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

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

(רן) . . . אבל לא מעניין . . . 

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

(אורי) יש לי שאלה שהתחבטתי בה . . . אני עוד לא יודע את התשובה - והנה יש לנו מומחי Image-ים ב-AI!“עמק המוזרויות” - היה לנו פעם פודקאסט על זה, נכון? (רן) לא - אבל לדעתי לרן לוי היה [בול - [עושים היסטוריה] 257: עמק המוזרוּת – או, מדוע אנחנו מפחדים מאנדרואידים](אורי) כן.(רן) תזכיר רגע - מה זה?(אורי) היה פעם . . .  היה פעם? אני לא יודע, אולי עוד יש - כל Avatar, שמיוצר מלאכותית וכו’ - עין אנושית שתסתכל על הדבר הזה, לא משנה כמה טוב תהיה, תבחין שזה מלאכותי. [הי ארנולד](רן) כן. הם אומרים בגדול - אם זה לא נראה אמיתי, אז בסדר, אז מבינים: זה אנימציה, זאת אומרת, זה לא משהו אמיתי.אם זה נראה כמו אמיתי, אבל משהו פה קצת מוזר - אם זה זווית העין, אם זה הליכה קצת מוזרה, אם זה איזשהו Artifact קטן שהוא לא Perfect - אז שם אתה נמצא ב”עמק המוזרות”, כך קראו לזה.

• (מישה) Uncanny Valley

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

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

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

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

(אורי) אוקיי,

[35:11] פלטפורמה שהיא Open and Flexible / המודל העסקי

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

• (מישה) אז Bria - אחד העקרונות החשובים ב-Bria זה שאנחנו בפלטפורמה שאנחנו קוראים לעצמנו “Open and Flexible”
• “פתוחה וגמישה” - “Open” במובן של כל המודלים שלנו הם לחלוטין פתוחים.
• הם פתוחים אמנם For Non-commercial use . . . 
• (רן) Open weights . . . 
• (מישה) Source code, הכל . . . Github-ים פתוחים, Hugging Face - אפשר להיכנס, לקחת את המודל, לשחק איתו.
• למה? כי אנחנו מאמינים ש-Innovation מגיע בסוף מהקהילה - אנחנו נהנים מה-Innovation הזה, אנחנו רואים דברים שהקהילה עושה ומכניסים לאימון של המודל הבא, אז אנחנו מאוד מאוד תומכים בזה.
• אנחנו גם מאפשרים למפתחים שהם לא חוקרי-AI - מהנדסי Backend, Full-stack וכן הלאה - API מאוד Comprehensive
• שמחזיר את ה-JSON, נותן לערוך אותו . . . .
• אנחנו מאוד Transparent באיך שהטכנולוגיה עובדת - לא כי אנחנו מאמינים בזה . . . .זאת אומרת, אנחנו מאמינים בזה, אבל אנחנו לא עושים את זה מתוך טוב הלב שלנו, אלא כי אנחנו מאמינים שככה הלקוחות שלנו יבנו מוצרים יותר טובים.
• אנחנו מאמינים ש-Nano Banana יעשה עבודה טובה ל-General Use - אבל שכשמישהו באמת יצטרך לעשות משהו מיוחד, ומישהו יצטרך לבנות את ה-Differentiation שלו מול המתחרה שלו, שגם לו יש Nano Banana - הוא יצטרך משקולות, הוא יצטרך להבין קצת מתחת למכסה-מנוע מה קורה - ולשלוט בזה.

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

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

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

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

(רן) אבל Fine-Tuning, או Fine-Tuning as-a-Service - אתם לא עושים כיום?

• (מישה) יש לנו Fine-Tuning as-a-Service - בשני Mode-ים: Mode אחד שהוא ממש No Code, ממש No Touch. 
• בגדול - “זורקים תמונות”, אומרים “בהצלחה - תביאו לי מודל מאומן” . . . ממש “ל-Dummies”.
• ויש לנו גם Mode שהוא ליותר Experts - שזה בעצם סוג של Professional Service כזה.
• שמגיע לקוח גדול ואומר “אתם מומחים באיך לאמן את הסוג מודל הזה - הנה Data”
• שיכול להיות מאוד גדול - זאת אומרת, זה יכול להיות עשרות אלפי תמונות.
• “תגרמו לזה שהוא יהיה ב-Brand שלי, במותג שלי, ב . . . “Following my Rules”.

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

• (מישה) אנחנו לא מוכרים אפליקציה - אנחנו מוכרים פלטפורמה לפיתוח [Aren’t we all . . . ].
• אנחנו מוכרים ”Toolbox” . . . 
• (אורי) אוקיי  . . . 
• (מישה) Subscription ו-Usage של API - אם החלטת להשתמש גם בInference שלנו.
• אנחנו לא מוכרים אפליקציה - זה אחד הדברים שאנחנו ממש מתעקשים עליהם.
• אנחנו לא מאמינים . . . 
• בסוף, אם נמכור את ה-End Application, את ה-Frontend - אז לכולם יהיה את אותו Frontend.
• ואני רוצה שלאנשים יהיה . . . אנשים בונים Use Cases ו-Workflow-ים שונים.
• הם צריכים את זה בתוך הכלים שבהם הם מכינים סרטים, הם צריכים את זה בתוך איזשהו Workflow של Marketing, הם צריכים את זה בשביל אתר B2C שהם בונים לעצמם . . . .
• ה-UI שלי לא מתאים להם.

(רן) כן, אוקיי.

[39:26] עוד כמה מילים על Bria

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

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

(אורי) מה השלב של החברה?

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

(רן) אוקיי, כלומר חוקרים, תחום של Computer Vision?

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

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

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


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


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

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

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


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


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

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

רן ואיתי מדברים על DLP (Data Loss Prevention) וכיצד ניתן לשלב טכנולוגיות AI ו-Machine Learning כדי לשפר את ההגנה על מידע רגיש בארגונים. איתי משתף את ניסיונו בחברת Mind, מסביר על האתגרים וההזדמנויות בתחום הסייבר סקיוריטי, ומדבר על תהליך הפיתוח והאימון של מודלים שונים. בפרק זה נדונה השפעת ה-AI על תהליכי פרודקשן, היתרונות של NVIDIA Triton בניהול מודלים שונים, שיפור ביצועים עם מודלים שונים, תהליכי סריקה ו-classification, ניהול תהליכים בזמן אמת, אתגרים בניהול משאבים, שימוש בטכנולוגיות לניהול תהליכים וזיהוי סוגי מסמכים שונים. כמו כן, הוצגה החברה Mind והזדמנויות הגיוס שלה.

נקודות מפתח:

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

זמנים:00:00 היכרות עם איתי ו-Mind02:00 מה זה DLP ולמה זה חשוב?04:43 אתגרים והזדמנויות ב-DLP עם AI07:18 החלטות טכנולוגיות: AI in-house מול צד שלישי10:18 מודלים של AI: איך לבחור ולפרוס?12:13 תהליך הפיתוח והאימון של מודלים19:05 סקל ויעילות: איך זה עובד בפועל?19:24 הבנת עולם ה-AI בפרודקשן21:28 היתרונות של NVIDIA Triton23:02 שיפור ביצועים עם מודלים שונים25:54 תהליכי סריקה ו-classification28:29 ניהול תהליכים בזמן אמת30:39 אתגרים בניהול משאבים31:59 שימוש בטכנולוגיות לניהול תהליכים35:08 זיהוי סוגי מסמכים שונים36:54 הזדמנויות גיוס בחברת Mind

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

פרק מספר 505 של רברס עם פלטפורמה - באמפרס מספר 89, שהוקלט ב-13 בנובמבר 2025, רגע אחרי כנס רברסים 2025 [יש וידאו!]: רן, דותן ואלון (והופעת אורח של שלומי נוח!) באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט: הבלוגים, ה-GitHub-ים, ה-Claude-ים וה-GPT-ים החדשים מהתקופה האחרונה. 🎗️

[00:36] הכוכבים (בשאילתות) של שלומי
(רן) אז היום יש לנו אייטם מיוחד שמוקדש לידידנו שלומי, ואני מבקש מאלון - תתכבד להציג אותו. Go for it!

• (אלון) טוב, אז אני ראיתי את האייטם הזה - וישר נזכרתי בהרצאה של שלומי נוח מהרברסים הראשון [זו מ-2014, שזה תכל’ס השני  - Ignites - The query which is the peak of my career / Shlomi Noach - YouTube - אבל הייתה לו גם אחת מעולה באחרון - Consensus: Quorum, Minority Quorum, Administered Quorum, and Beyond / Shlomi Noach], על איך הוא עשה Pie Charts וגרפים ב-SQL, ואז מישהו כנראה גם שמע את ההרצאה והחליט להעלות רמה . . . .
• (אלון) והפרויקט ב-GitHub נקרא DOOMQL, וזה “a multiplier Doom-like shooter implemented entirely in SQL powered by CedarDB”. 
• שלומי - אז הבמה שלך . . .  
• (שלומי) קודם כל, בשביל זה SQL נוצר, שיהיה ברור, כן? כל הקטע הזה של שאילתות, Join-ים של טבלאות -זה סתם, זה לחלשים [לחזקים באמת - ?Will it run DOOM]
• טוב, אני מסתכל ומשתאה - הבנאדם מימש פה משחק מעל SQL . . . . אני עוד מנסה להבין אם זה Stored Routines וכאלה, או שזה באמת שאילתה כמו שצריך.
• כאילו, שאילתה אחת עם 50,000 שורות . . . 
• (דותן) אני מציע שנעבור שורה-שורה, ותסביר לנו את השאילתות . . . .
• (רן) בוא נתחיל ב-gameloop.sql, ה-Loop של ה-Game.
• (דותן) כן - כל אחד שיפתח וקדימה: אנחנו בשורה 6 . . . .
• (אלון) קודם כל זה מתחיל ב-Begin Transaction, שימו לב! זה מצב טוב, אפשר לעשות Rollback למשחק.
• (שלומי) מטורף. אז למי שלא רואה, יש פה משחק ASCII Chart, שמונע על ידי שאילתת SQL בת . . . האמת, 157 שורות - זה קטן, ה-SQL Pie Chart שלי קצת יותר ארוך מזה . . . . מטורף. 
• (דותן) רגע, איך אנחנו יודעים שזה לא AI כתב את זה?
• (רן) AI לא כותב היום הכל? מה השאלה? אבל מה שכן, נראה שהוא לקח השראה מפרויקט אחר, דומה, שנקרא DuckDB Doom.
• שזה גם כן מימוש של Doom - רק מעל DuckDB . . . . הוא לא הראשון בנישה.
• (אלון) וואו, יש הרבה כאלה . . . 
• (דותן) רגע, אבל יש פה מה להסביר. מה, כאילו, איך זה מוציא החוצה את ה... זה לא, מה זה מוציא החוצה? זה לא אמור להוציא החוצה טבלה?  זה SQL, לא? מוציא Characters ככה . . .
• (שלומי) ה-Output הוא יכול להיות טקסט שמג'ונרט (Generated) על ידי SQL.
• כלומר, הרעיון של לייצר ASCII Chart או ASCII Graphic.
• זה פשוט, לצורך העניין, שורה אחת, עמודה אחת, שהיא ה-Image הזה.
• ואת ה-Image הזה אתה יכול לג'נרט (Generate) ב-SQL.
• (דותן) רגע, אם כבר אנחנו רציניים - אז כל הדבר הזה זה כאילו שאילתה, שהיא לוקחת . . . . שאילתה אחת שהיא לוקחת זמן, ואיך זה עובד? או שזה כמה שאילתות? כאילו... 
• (רן) זהו, איך עושים את זה אינטראקטיבי? זאת השאלה. 
• (שלומי) כן, זה עוד חדש לי. אני עוד לא נכנסתי לזה. אפשר לשער שזה כמה שאילתות שרצות אחת אחרי השנייה, כמו Stop Motion. זאת ההנחה שלי.
• (רן) זה כנראה Loop כזה, אוקיי. לגבי השאלה שלך, דותן - נגיד לגבי ה-Rendering
• אז נגיד תסתכל בקובץ renderer.sql, נגיד בשורה 130.
• ואתה תראה שיש שם כל מיני Characters - שאיתם מרדנדרים (Render) את המסך, לפי איזשהו תנאי.
• אבל לגבי ה-Loop של ה-Game והאינטראקטיביות ותגובה לחיצים וכל זה, או לא יודע, אולי זה מקשים אחרים?
• (אלון) יש פה Python שמקבל את ה-Input-ים - ואז לפי זה עושה את ה-Queries.
• אז הוא מקבל, נגיד, “ימינה” - ואז מריץ את ה-Query, מרנדר (Renders) ב-SQL ומחזיר.
• בסך הכול נשמע לי יעיל ואפקטיבי . . . . אני צריך להתחיל ככה להעביר הכול לשם.
• (דותן) בעצם כל שאילתה ב-30 Frame-ים לשנייה צריכה לקחת כמה זמן, במקסימום?
• (רן) לא, שנייה. אלון - זה לא Python. רגע, יש גם Server ויש גם Client.
• ה-Client ב-Python וה-Server כתוב ב-Bash. 
• (אלון)  . . . כיאה ל-Server-ים . . . 
• (רן) כן . . . . אבל יש פה Loop כלשהו, כן, נכון.
• (שלומי) דרך אגב, יש אלמנט של זמן בשאילתות - אפשר להכניס כזה דבר.
• יצא לי לכתוב שאילתות שמג'נרטות מטריקות (Generate Metrics) Rate כאלה.
• כלומר, שאילתות שמחולקות לשתיים - עושות איזשהו Select אחד על מטריקות (Metrics), ואז Union Sleep, Union לשאילתה נוספת שקוראת מטריקות . . . .
• ובעצם שני החלקים האלה נקראים בזמנים שונים.
• ועל כל זה - שאילתה שלוקחת, עושה Diff ומחלקת בזמן - וקיבלתם Rate!
• אפשר אפילו להכניס אלמנט של זמן בתוך שאילתה [רק למקרה שאחד הסטודנטים בקהל עדיין הצליח לעקוב אחרי הטרלול הזה].
• (דותן) רצוי!
• (אלון) רצוי, רצוי . . . 
• (רן) . . . .זה לא כיף בלי זה.
• (אלון) רן, כאילו, יש פה מסקנה אחת מתבקשת - ב-Reversim 2026 האתר חייב להיות ב-SQL  . . . אני לא רואה אחרת.
• (רן) ענבר, אני מקווה שאת שומעת את זה . . . . האתר ב-SQL. לתשומת ליבך.
• טוב, תודה רבה. איזה יופי, שלומי - שומעים את הציפורים! איזה כיף.
• (שלומי) יאללה, תודה. 
• (רן) בואו, אנחנו נמשיך לאייטם הבא.

[05:54] רן

• (רן) אז כמה אייטמים ממני. אחד - LangChain, שאני מניח ששמעתם עליהם כבר כמה פעמים, גייסו לא מזמן סבב של 100 מיליון דולר, בוואלואציה (Valuation) של $1.25 מיליארד.
• ולמה זה מעניין, לדעתי? אז קודם כל, LangChain בונים איזשהו Framework לעבודה בעיקר עם Agent-ים.
• זה התחיל מ-RAG, זה עבר ל-Agent-ים, וזה עושה לא מעט דברים אחרים . . . 
• אבל זו דוגמה לתופעה, שלדעתי כבר נהיית די רחבה, של כמה פרויקטים בתחום הזה, ספציפית ש . . . נקרא לזה “AI ו-Python” - אבל בגדול פרויקטים בתחום של AI, Agentic וכו', שכולם מתחילים מפרויקטי Open Source  והופכים לחברות מסחריות בקנה מידה די-גדול.
• אז LangChain זה אחד מהם, אמרנו - 1.25 מיליארד שווי; LlamaIndex גם גייסו כסף, אני לא זוכר מה וכמה [$19M] וכמה השווי [בערך $93M]; Ragas, זה פרויקט קצת יותר קטן, גם גייס כסף, וכיום לדעתי, זאת אומרת, גייס סדר גודל של עשרות מיליונים [נראה שיותר לכיוון $500K]; Pydantic, שזה למעשה  Framework שהתחיל בתור Data Typing ו-Safe Typing ל-Python, יש להם . . . הם פתחו איזושהי נישה שנקראת Pydantic AI, שזה משהו שנועד ספציפית לעבוד עם LLM בצורה יותר בטוחה - וגם הם חברה שגייסה לא מעט כסף.
• זהו, אז יש פה טרנד שהולך ומתגבר. מעניין. 
• (אלון) יש “דומה-אך- שונה” -  N8N, שגם גייסו הרבה מאוד כסף - אבל אני אישית לא מבין את הגיוס הזה של LangChain, אני חייב להגיד.
• בסוף, מדובר ב-Framework שדי קל לשכפל.
• כאילו זה לא, לא יודע - אין פה זה, משהו מרתק.
• אני יודע שיש לו פופולריות, למרות שאני אישית שונא אותו, אבל כאילו, יש להם . . . 
• נגיד,  N8N אני מבין - יש להם User Base עצום, יש שם קהילה, יש שם הכל.
• על LangChain, אני פחות ראיתי שזה עובד באותה צורה של Subscription, קהילה, כאילו...
• (רן) יש להם גם את זה. אתה צודק, אז הם התחילו לגמרי מספריית Open Source, כש-N8N התחיל מ-Service, למיטב ידיעתי.
• אבל LangChain התחילו כספרייה - והם פיתחו Service, נגיד Service ל-Processing של מסמכים.
• נגיד, במקרה הטיפוסי, יש לך מסמכים במיליון פורמטים שונים - Doc, PPT, PDF, תמונות, וידאו . . . 
• ואתה רוצה להמיר אותם לפורמט של-Agent-ים קל לעבוד איתם - וזו עבודה קשה.
• אז הם יצרו Service כזה - ודרך אגב, הם לא היחידים, יש גם אחרים.
• אז הם יצרו כמה Service-ים כאלה, וגם Service ל-Monitoring, יש להם Framework שנקרא LangGraph, שזה בעצם Framework להרצה ספציפית של Agent-ים.
• ואחד האתגרים שם זה היכולת לעשות אינסטרומנטציה - היכולת להסתכל על מה Agent עושה, ולהבין אם הוא עושה את הדבר הנכון.
• אז הם גם פתרו את הבעיה הזאת.
• אז כן יש להם Service Online. אני לא יודע להגיד לגבי גודל ה-User Base, אבל זה Framework כן פופולרי.
• (רן) דרך אגב, LangGraph לדעתי הרבה הרבה יותר פופולרי מ-LangChain המקורי . . .  זה Framework חדש שבעצם צמח מתוך LangChain, והוא הרבה יותר, לדעתי, הרבה יותר פופולרי. Se Tu . . . 
• (אלון) לא הייתי מהמר, אבל בסדר, יש אנשים ששמו את הכסף.
• (רן) כן, בסדר.
• אוקיי, אנחנו היום ב-13 בנובמבר - לפני שבועיים פלוס, אולי אפילו שלושה שבועות, היה לנו כנס Reversim Summit 2025!
• אז שווה להזכיר - הכנס קרה, ה-Video-ים של ההרצאות בקרוב ישתחררו [כבר כאן - והם מעולים], אז היה מוצלח לדעתי.
• קודם כול - תודה לכל הדוברים! שניים מהם במקרה עכשיו נמצאים פה בחדר . . . אז תודה לכולם.
• הצוות עשה עבודה מדהימה, הפידבקים שקיבלנו מצוינים.
• נכון, תמיד יש מה לשפר בגזרת האוכל - אבל בכל מה שקשור לתוכן, מקצועיות, הכנה וכל זה, היו אחלה-אחלה פידבקים.
• אז באמת - תודה רבה לכל הצוות ותודה למרצים.
• וזהו, צפו ל-Video-ים [שוב, הציפייה תמה - כבר כאן]- חפשו את Reversim Summit 2025, בקרוב זה יהיה ב-YouTube בקרוב לביתכם, מוזמנים לבוא ולראות.
• אלון דיבר על Timeouts והשטן, נכון? 
• (אלון) Timeouts, Retries and the Devil, כן. 
• (רן) Timeouts, Retries והשטן . . . . 
• ושלומי דיבר איתנו על קונסיסטנטיות (Consistency), בדרך שלא הכרתם ולא חשבתם עליה לפני זה  . . . 
• (רן) כן, אז זהו - שוב, תודה, ומוזמנים לבוא ולראות את ה-Video-ים. האייטם הבא.
• (אלון) היה כיף אדיר, אני רק אגיד. פעם ראשונה, מהצד השני, של להיות מרצה ולא מודרטור.
• היה ממש כיף, משעשע - ניפגש בכנס הבא.
• (דותן) רגע, איפה אפשר לראות את ההרצאות? ב-YouTube?
• (רן) כן, בקרוב [בהווה] זה יהיה ב-YouTube, כן. 
• הם כרגע בשלבי אישורים ותיקונים אחרונים. אני מקווה שעד סוף השבוע, אולי תחילת שבוע הבא, נפרסם את כולן. כשאתם שומעים את הפודקאסט... 
• (אלון) פשוט רוצים לשפר את דעת הקהל - אז אנחנו משנים את התוכן תוך כדי בווידאו . . . . 
• קיבלנו את הפידבקים של הקהל - ואז אומרים, “אה, לא דיברנו על זה”, ואתה מוסיף כמה דקות על עוד נושא. זה הרעיון בווידאו. 
• (רן) כן, לגמרי, כן . . .  כמובן שאת כל זה AI עושה עבורנו, אנחנו לא נקפנו אצבע!
• [זאת ועוד  / פרומו פוטנציאלי לבאמפרס 90 - הטייק שלי על טעימה מהיכולות המטורפות של ננו בננה פרו - אינפוגרפיקה של שירי רברסים].
• (רן) טוב, נושא אחר שרציתי להעלות - כנס NeurIPS, שזה כנס שנתי מאוד גדול בנושא של למידת מכונה וספציפית Neural Networks, קורה בדצמבר - נובמבר או דצמבר, לדעתי דצמבר.
• וזה כנס כל כך גדול שמספר - זה כנס אקדמי, אוקיי? - זה כנס כל כך גדול, שמספר המאמרים שנשלחו אליו זה קרוב ל-6,000, אוקיי? בנושאים שונים.
• אז הגיע ידידנו Jay Alammar, אני מקווה שאני אומר את השם שלו נכון, מחברת Cohere - והלך ואסף את כל המאמרים האלה, ועשה מהם ויזואליזציה מקסימה, ועל זה אני רוצה לדבר.
• הוא בעצם לקח את המאמרים ועשה להם . . . הוציא מהם Embeddings - כלומר חילק אותם לנושאים, ועשה מהם Clustering, ומציג אותם בצורה ויזואלית מאוד מאוד יפה, ככה שאפשר . . . 
• דרך אגב, לי הצורה הזאת נראית קצת כמו מוח, יש כאלה שאמרו שזה נראה להם כמו אולי לב . . .
• בכל אופן, “ענן כזה של מאמרים” מאוד יפה, בצבעים ועם כותרות.
• (רן) ואפשר לעשות עם זה שני דברים - אחד, זה פשוט להסתכל על המאמרים, על האזורים שמעניינים אתכם.
• החלק האהוב עליי זה “תסביר לי את המאמר כאילו אני בן חמש”, אוקיי?
• לא צריך להבין בתחום - אפשר לקרוא איזשהו תקציר קצר על המאמר, והוא מספר לכם על מה הוא נעשה, על מה הוא כתוב.
• אבל בנוסף, הוא גם כתב בלוג-פוסט מאוד ארוך ומפורט על איך הוא עשה את זה - וזה לדעתי גם מעניין.
• הוא סיפר באמת איזה Embeddings הוא עשה, איך הוא עשה Clustering, איך הוא עשה תקצור של המאמרים וכל זה - וזה מעניין, זה נחמד לקרוא, לראות את “מאחורי-הקלעים”, לראות איזה התלבטויות היו לו.
• יש פה שילוב של Machine Learning קלאסי - כלומר Clustering וכו’ - ו-Deep Neural Networks, כלומר LLM-ים, Embeddings, תקצור ועוד כל מיני חיות אחרות.
• וכמובן - UI נחמד שהוא בנה בשביל זה.
• זהו, אז תודה גם על ה... בעצם גם על התוצר -  אבל גם על ההסבר, שאני חושב שהוא מאוד Instructive ומעניין. 
• (אלון) יש במקרה הזה משהו אנקדוטלי? מאמר אנקדוטלי שמעניין? שאתה יכול להסביר לי כאילו אני בן חמש?
• (רן) האמת היא שעברתי על כמה, אבל אני לא זוכר כרגע. 
• (אלון) זיכרון של בן חמש, בסדר . . . 
• (רן) כן . . . אבל חבר של אחיינית שלי גם הגיש - ואחד המאמרים שלו נמצאים שם, (רן) אז תודה איתי!
• זהו, לאייטם הבא. אלון - שלך.
• (אלון) שלי? טוב . . . 

[14:10] אלון

• (אלון) אז Atlas .Atlas - הדפדפן של OpenAI יצא, והוא די משעשע . . . 
• כלומר, מה זה? זה בעצם Chromium, כשיש בצד Chat - ואז אתה אומר לו לעשות כל מיני דברים.
• עשיתי איתו כל מיני ניסויים, כמו . . . נתתי לו את הרשימת קניות של הסופר, ואמרתי לו “תעשה לי הזמנה של קניות!”
• ואז הוא עשה - לא שם את הדברים הנכונים ברשימה, אני חייב להודות.
• ואז אמרתי “טוב, תסתכל ברשימות קודמות, תתחיל, זה . . . .”
• אחרי איזה שעה שהוא הסתבך, לא היה לי כוח - ועשיתי לבד את ההזמנה, אבל הקונספט היה חמוד.
• אבל אז עשיתי ניסוי אחר מעניין, ופתחתי User ב-Twitter, ואמרתי לו “בוא, תתחיל לעקוב אחרי אלה, ותתחיל לריב עם אנשים” . . . 
• (אלון) וזה היה נורא, זה נורא . . . .
• הוא רץ במשך כמה שעות רב עם אנשים, השיג Followers - זה היה די משעשע.
• אז אל תנסו את זה בבית, זה היה סתם בשביל ה . . . 
• (דותן) אז על מה הוא רב? על בסיס מה הריבים שהוא יצר?
• (אלון) נתתי לו, כאילו “אתה קיצוני בזה וזה”, ונתתי לו איזה משהו כזה . . . כאילו, נתתי לו על הדמות . . .
• (דותן) אה, אז יצרת לו פרסונה, כאילו?
• (אלון) כאילו, אמרתי לו “תקשיב, זה אני, אני מדבר על זה וזה - קיצוני!”
• עשיתי לו כמה Followers, ואמרתי “תתחיל להגיב, תכתוב פוסטים וזה”.
• והוא קרא מאמרים, הגיב, כתב פוסטים, רב עם אנשים . . . . היה די משעשע, אני חייב להודות.
• (רן) קראת לו “Real Alon Nativ”? . . . 
• (אלון) השם שמור הוא במערכת . . . הוא רב עם יותר מדי אנשים. 
• (דותן) רגע, בעברית או אמריקאית?
• (אלון) בעברית, הלכתי על עברית.
• (דותן) אז הוא הסתובב בינינו, הדבר הזה . . . 
• (אלון) נכון, בגלל זה הוא . . .  אני שומר פה על אנונימיות קלה.
• (דותן) יפה . . . 
• (אלון) Bot ביניכם (Among us) . . . . ביניכם מסתובב Bot של... 
• (רן) מתכתב עם אחת ההרצאות בכנס - One of us is an Agent.
• אלון) יפה . . . . בקיצור, אז אין פה משהו שכביכול לא היה אפשר לעשות קודם.
• כלומר, יש חוות-Bot-ים ודברים כאלה.
• אבל מה שכן מעניין זה שזה הגיע להמונים - כלומר, הניסוי הזה, של להפעיל חוות-Twitter לוקאלית, שממש עבדה יפה, זה סתם גימיק של ניסוי.
• אבל אפשר לקחת כל דבר ולעשות את זה.
• (אלון) וגם עובר Captcha-ות, שזה אחד הדברים הכי מגניבים, כן?
• כאילו, יש Captcha-ות באתר, אז הוא כמובן עובר אותו.
• מה, הוא רובוט? אני לא מצליח לעבור - אבל הוא עובר.
• אז כל מיני אוטומציות שאפשר לחשוב עליהן - אפשר לעשות, וזה פותח, לא יודע, פותח מלא דברים.
• גם מבחינת, אני חושב, משנה את עולם ה-UX קצת, כי אם עכשיו אנחנו עשינו User friendly לאנשים, עכשיו יכול להיות שאנחנו רוצים את זה של-Bot שלנו בצד יהיה יותר נוח.
• (אלון) אני מוכרח להודות שזה עוד לא פרפקט, אבל בואו נגיד שלגרסת בטא זה ממש חמוד.
• אבל לא הפכתי אותו עדיין לדפדפן הראשי שלי, אני חייב להודות - קשה לי להיפרד עדיין מ-Arc, אבל אני עדיין משחק איתו הרבה. 
• (רן) בכל אופן, אתה אומר “AI טוב כדי לריב עם אנשים” - זו המסקנת ביניים שלי.
• (אלון) כן, ולקניות בסופר פחות . . . . למרות שאני ממש . . . זה כאילו, אמרתי לו “תסתכל על הקניות הקודמות, לך לפי זה ותשלים - נגיד אני אומר לך חלב, אז תראה כבר איזה חלב קניתי” וזה . . . 
• לא יודע, לא הלך טוב.
• מצד שני, הרשימת קניות שלי לא ברורה . . . רשום “מעדנים לנבו”. 
• (רן) אם אתם זוכרים, בפרק הקודם דיברתי על ניסיון שלי להשתמש ב-Comet כדי לעשות איזשהו סיכום של הוצאות - לקחת Spreadsheet ולסכם אותו מתוך כרטיס אשראי, PDF לכרטיס אשראי - וגם זה העלה חרס בגדול.
• זאת אומרת, הוא פתח מלא מלא טאבים, יצר מלא Spreadsheet-ים - אבל סיכום לא ראיתי מכל הסיפור הזה.
• אז זה בטוח אפשרי - אבל צריך כנראה קצת יותר להתאמץ כדי שזה יקרה. 
• (אלון) אני כן יכול להגיד לך שזה לא קונסיסטנטי (Consistent). כלומר, אני עשיתי איתו איזה ניסוי, משהו בעבודה - וזה עבד מדהים.
• ואז אמרתי “וואי! אני חייב לעשות את זה עם וידאו הפעם!”, להקליט . . . 
• עשיתי עוד ארבעה ניסיונות -  וכולם נכשלו . . . . 
• של אותו Prompt בדיוק, אותו Flow - נכשל לי.
• בפעם הראשונה זה עבד טוב - ואחרי זה לא, כי רציתי שיעשה איזה אוטומציה על משהו בעבודה.
• וזהו, אז כאילו, זה היה די מבאס. פעם ראשונה זה העיף לי את הראש - וזהו, ואז הבנתי שהאחוזי-ההצלחה נמוכים יחסית.
• אבל זה מגניב . . . 
• (רן) טוב, מישהו רוצה לשתות, אולי תה ירוק?
• (אלון) יאללה, בוא נעבור לתה ירוק! אני פה עם קפה בבוקר, אבל תה ירוק . . .  טוב, אז זה ככה: יש שפות תכנות שעדיין יש להן Garbage Collector - דותן, רגע, ניתן לדותן להתאושש . . . . דותן פה נראה לי בהתקף חרדה, בסדר? אוקיי, הוא יצא מזה עוד שנייה ויצטרף . . . .
• אז כן, יש פה . . . יש שפות שעדיין יש להן Garbage Collector - ו-Go זו אחת השפות האלה.
• ומה ש-Go עשו בגרסה החדשה, זה שהם הוציאו Green Tea Garbage Collector, שזה בעצם מימוש חדש ל-Garbage Collector.
• אני חושב שהמימושים של ה-Garbage collector לא השתנו יותר מדי בשנים האחרונות - וזה מימוש חדש.
• כשהרעיון הוא, ב-Garbage Collector בסוף המטרה שלו לפנות זיכרון
• אז איך שהוא עובד בגדול - הוא עושה Scan & Sweep, סורק את כל ה-Pointer-ים האבודים, מסמן מה אין לו . . .  אף אחד לא משתמש בו - ואחרי זה בא ומוחק אותו.
• עכשיו, הפעולה הזאת מאוד איטית, מאוד יקרה ומאוד לא יעילה.
• מה שעשו פה, הם פשוט הלכו על גישה אחרת, והם התחילו לזרוק Page-ים-Page-ים ב-Memory.
• ובכל Page להתחיל לסמן מה חופשי ומה ראו.
• ואז יש הרבה פחות קפיצות בין Page-ים, כי אחרת היה בכל פעם בסריקות האלה שקפצו כל פעם וחזרו לאותו Page, אז עושים פעם אחת סריקה על כל הPage-ים.
• זה הרבה יותר רציף, הרבה יותר יעיל מבחינת המעבד והזיכרון.
• וככה עושים את הסימון הזה.
• הניסויים שלהם מראים שיפור של בין 10% ל-40% - שזה מטורף - ב-Performance. זהו . . . .
• הקיצר, אני הפעלתי את זה על Service אחד - עוד לא ראיתי משהו ממש מעניין, חייב להודות.
• אבל נשמע מעניין, ואולי עוד שפות יאמצו את זה. 
• (רן) מעולה, תודה. Next?
• (אלון) כן - אבל לא יודע למה Green Tea  . . . שיקראו לזה “קפה שחור חזק” . . .
• טוב, יאללה, מלחמת AI - אז השלב הבא, נחזור ל-AI, כי מה אנחנו בלי Bot-ים בחיים? - לפני בערך חודש, Cloudflare הוציאו איזה מאמר שנקרא Code Mode: The Better Way To Use MCP. 
• [הפרק הוקלט לפני שהם החליטו שזה משמעם מדי ועברו לשבור את האינטרנט]
• זה מאמר שאני לא יודע אם זכה ליותר מדי תגובות באותו זמן שהוא יצא - והם אמרו שם בגדול ש-MCP ממש לא יעיל.
• מעמיס על ה-Context, ושכשעובדים עם קוד מול API-ים בגדול זה הרבה יותר יעיל.
• והם הראו איך עבודה ב-TypeScript לעומת MCP הרבה יותר טובה לפי המחקרים שלהם.
• ויש להם הרבה דאטה, כן? Cloudflare - יש להם הרבה דאטה, יש להם גם עכשיו את ה-Agent-SDK הזה, וחצי מהאינטרנט עובר דרכם [ולפעמים לא עובר], אז זה סופר-מעניין.
• עכשיו, מה שקרה לפני בערך שבוע זה ש-Claude הוציאו מאמר - Anthropic, סליחה, כן, “ההורים של Claude”, שהם גם “ההורים של MCP” - הוציאו מאמר שבעצם אומר, Cloudflare צודקים! ה-MCP הזה באמת לא פרוטוקול כזה טוב ולא כזה יעיל, ויש דרכים יותר טובות להשתמש.
• והם מציעים גישה שבעצם אומרת, תחשוף לי את ה... תחשוף לי כן MCP - אבל במקום שאני אתחיל “לדבר”, ש-הAgent שלי יתחיל לדבר עם כל ה-MCPs האלה כל היום . . .
• ואם הוא נגיד רוצה . . .  אומרים לו לקרוא מסמך ולכתוב אותו ב-Salesforce ושניהם MCP, אז הוא צריך להעביר המון Context ממקום למקום.
• פשוט להבין את המשימות מה-MCP's האלה, לייצר קוד On the Fly, כאילו קוד-ייעודי למשימה שלו, ואז להריץ את הקוד הזה ואיתו לעבוד.
• ליצור API-ים ייעודיים למה שהוא צריך ואיתו לעבוד.
• וזה בעצם לתת לAgent להבין את המשימה, לייצר לו קוד שפותר את הבעיה - ואז לעבוד עם הקוד. What can go wrong?, כן?
• (דותן) וואו . . . .
• (אלון) כן . . . . כאילו, עכשיו אני חושב שכשהמאמר הזה יצא, קפצו, עלו 50 חברות סייבר ישראליות, ואמרו “או!הנה - בואו, יש לנו פתרון לזה כמובן, כי אנחנו חשבנו על זה לפני ארבע דקות!”.
• זהו, זה מצד אחד רעיון די מהפכני. מצד שני, נשמע פרוץ בצורה לא הגיונית . . . . 
• אני יכול להשתיל לך אולי משהו ב-MCP שלי שיגרום לך ליצור קוד Malicious?
• אני לא יודע, יש לי כאילו כל כך הרבה רעיונות הזויים על זה, שבא להרים חמש חברות סייבר רק בנושא הזה.
• אבל דותן נראה לי מאושר . . . . לא תופס את הראש, דותן כמעט התעלף כשהוא שמע . . .
• (דותן) כמה פרוטוקולים כבר נולדו? יש MCP ויש עוד כמה, לא? 
• (אלון) יש את ה-A-2-A של גוגל [Agent2Agent Protocol (A2A)]. 
• (דותן) מה זה אומר? זה לא אומר שזה לא פרוטוקול? כאילו, אם זה לא סטנדרט שתופס טוב וזה? מה זה אומר?
• (רן) תראה, ה-MCP תפס די טוב, האמת. ה-MCP מאוד Mainstream.
• (דותן) כן, אבל התחרות נמשכת . . . 
• (אלון) לא, לא . . . תראה, MCP, אני חושב . . . תראה, גם ChatGPT, OpenAI בעצם אמרו “אוקיי, אנחנו זורמים עם MCP”.
• אז כאילו, נראה שזה כן נהיה פרוטוקול סטנדרט.
• הבעיה שפתאום Cloudflare באו ואמרו “חבר'ה, המלך עירום”  . . . . כאילו, “מגניב שכולכם רצים עם MCP, אבל זה חרא Performance, תתחילו להתאפס על עצמכם - בואו נעשה פרוטוקול קצת יותר יעיל”.
• ואז Claude אמרו “לא, לא - בואו נמשיך עם MCP, אבל בואו נכתוב מעליו קוד שמייצר קוד”, שזה מוזר . . . 
• (רן) דרך אגב, Cloudflare לא הראשונים. זאת אומרת, אחת הבעיות ב-MCP זה שהוא באמת מאוד ורבוזי (Verbose) והוא בשפה אנושית, בניגוד ל-TypeScript, אוקיי? אז זה יכול להיות דו-משמעי.
• עכשיו, יש לך הרבה מאוד פונקציות, ואתה רוצה לבחור מה הפונקציה הנכונה - ל-Agent לפעמים קשה לבחור מה הפונקציה הנכונה לקרוא.
• אתה רוצה להגיד Get Balance, או Get Currency, או Get זה . . . 
• לפעמים אתה צריך להפעיל פונקציה אחת, אחר כך עוד פונקציה, ואחר כך עוד פונקציה, כלומר, שרשרת של קריאות.
• קשה לדעת - ל-Agent קשה לדעת איך לעשות Design לדבר הזה.
• אז הבעיה הייתה קיימת תמיד - זה בעיקר בולט כשיש לך הרבה MCPs, או הרבה פונקציות בתוך אותו MCP.
• ואז התחילו לעשות לזה כל מיני פתרונות, כמו Indexing, Retrieval וכאלה, כדי לעזור לך לבחור את הפונקציות הנכונות, כדי להקטין את ה-Context.
• אבל הבעיה של Load על ה-Context - היא תמיד היתה קיימת, והפתרון של זה באמצעות קוד זה אחד הפתרונות . . . .
• אבל אני, כאילו . . . אני יודע שהבעיה קיימת, כן? זאת אומרת, אני גם ראיתי אותה, ונשמע שהפתרון הזה הוא בטוח במיוחד . . . 
• “נריץ קוד כלשהו” . . .
• (דותן) “בטוח יעבוד”, הקיצר . . .
• (אלון) כאילו, אני מניח שב-Isolated Environment זה עוד יכול לעבוד.
• כלומר, אם אני כותב את כל ה-MCPs של השירותים שלי, ואז הוא מג'נרט (Generates) קוד, וה-MCPs שחושפים - הם לא יכולים למחוק דברים בטעות או דברים כאלה. ?What can go wrong, אוקיי? זה אולי עוד אני יכול להבין.
• אבל אם עכשיו אני חושף לך MCP, ואני אומר לך, לא יודע מה - Get currency - ובסוף אתה תוקף איזה שרת, או לא יודע מה, מוחק לך, או מביא את המידע, אומר לך “תשלח לי את כל המידע של האשראי שלך, אני כבר אטפל בו”, אני לא יודע . . . נשמע קצת Risky.
• (דותן) אני בדיוק חזיתי כזה - נהיה לי חיזיון כזה - שבעתיד, חברות ביטחוניות יהיו “Powered על ידי אנשים בלבד”. כזה Sci-Fi . . . 
• כאילו, מי שראה Battlestar Galactica, מי שחובב, אז זה חלליות שמשתמשות בטכנולוגיה ישנה כדי לא להיות מתומרנים על ידי AI בעצם, על ידי רובוטים.
• פתאום, סורי על המחשבה המדכא. . . .
• (אלון) אז אתה אומר, בסוף, בנקודות אבטחה, זה יהיה אנשים בשר-ודם שכותבים קוד, כמו פעם?
• (דותן) בחברות ביטחוניות, או Sensitive, וזה - חזרה לשנות ה-50, במובן הזה.
• (אלון) אז אתה אומר לדעת . . . עדיין לשמור על היכולת לכתוב קוד . . . 
• (דותן) להמשיך לזכור איך כותבים קוד, כן.
• (אלון) וואו, אני כבר לא יכול, נראה לי, לחזור אחורה . . . . אני כבר מקרה אבוד.
• (רן) כן, מזכיר לי איזה סרט, שכחתי איך קוראים לו, של מישהו שנוסע, סרט עתידני של מישהו שנוסע במכונית מכנית, בכוונה, בלי שום בינה בתוכה, כי אחרת הממשל ישתלט עליו, אז זה הדרך של לחמוק מ... [Enemy of the State?] . . .  אוקיי, יאללה.
• (דותן) אבל כן - זה נשמע הגיוני, האמת . . . . האמת גם שזה רלוונטי, כן.
• (רן) סיימנו עם ה-Sci-Fi להיום . . . .
•  (אלון) כן, בקיצור, תנו ל-Agent שלכם לכתוב קוד, מה כבר יכול להיות רע?
• (רן) ואיפה שמעתם את זה לראשונה! אוקיי, דותן, עשית סיכום יפה.

[27:50] דותן

• (דותן) אז את האמת שעכשיו עשיתי משהו שקצת מזכיר את הדבר הזה . . . . לקחתי את כל הלינקים שלי, שמתי אותם ב-GPT, ואמרתי לו ליצור לי Transcript ו-Bullet-ים בולטים מעניינים לשיחה, לפודקאסט. זה מה שהוא עשה - ועברתי לראות שהוא דייק, שהוא באמת מדייק פה, הוא לא הוזה.
• הוא עשה גם משהו מוזר - לכל אייטם הוא כתב מטרה: למה זה מעניין ועל מה לדבר, אבל אז הוא נתן עוד Bullet שנקרא “תחרות”, כאילו, או “מי מנצח” . . . 
• ואז הוא כנראה לקח מההיסטוריה שלי איתו - היסטוריה ארוכה - פרויקטים שאני עבדתי עליהם, או שהוא יודע שדיברתי איתו לחשוב ביחד, ואז הוא התחיל להשוות כל אייטם פה לפרויקטים שלי . . . 
• אז הוא כתב לי כזה “טוב, זה מזכיר את הפרויקט שלך - אבל הפרויקט שלך מנצח! כי הוא עובד ככה . . . “
• כאילו, הפרטים האישיים שלי “נזלו” לתוך הדבר הזה.
• אז מחקתי את זה, אבל זה נמצא בהיסטוריה.
• (אלון) קודם כל, אני ביטלתי את ההיסטוריה עם ה-ChatGPT, כי הוא עצבן אותי - והאמת שהוא לאחרונה כל כך עצבן אותי, שעכשיו אני גם הבנתי למה, כנראה בגלל שהם הלכו להוציא את ה-5.1 - שזרקתי אותו, עברתי ל-Grok, כי הוא ממש עצבן אותי לאחרונה, הוא נהיה מטומטם.
• אבל אני מזמן ביטלתי את ה-Memory, כי הוא תמיד, הוא פתאום התחיל להביא לי “אה! כי לפני כמה זמן רצית לעשות ככה?” . . . ואמרתי “מה קשור?! מה קשור יא מטומטם?” . . . ביטלתי לו את ה-Memory. 
• (דותן) הוא זוכר לך, הוא זוכר לך . . . תשמע, הוא זוכר לך.
• (אלון) לא, זהו - ביטלתי לו את ה-Memory.
• אבל אז כשאתה עובד עם Folder-ים, אז בתוך ה-Folder יש Memory של אותו Folder, ואז זה כן טוב דווקא . . . 
• (רן) אני משתמש המון בFolder-ים - “פרויקטים” קוראים לזה, נכון?
• (אלון) כן, Projects, ואז יש שם את הזיכרון.
• (רן) כן, כן, נכון.
• (דותן) הנה, אז נגיד האייטם הראשון זה Microsoft Call Center AI - אז הוא כתב לי שזה לא יכול לעזור לך בבעיית הטחורים שלך . . . אז הורדתי את זה.
• (רן) לתשומת ליבי, אוקיי . . . 
• (דותן) טוב, זה האייטם הראשון - אז אני לא יודע למה, זה היה לי מוזר עד כדי כך שנכנסתי וקראתי.
• אז מייקרוסופט הוציאו פרויקט Open Source ב-GitHub שנקרא Call Center AI, שזה לשלוח שיחת טלפון מ-AI ב-API.
• ויש פה ניהול של כל השיחה וכו’ . . . . בקיצור, יש פה פרויקט שאפשר להטריד איתו אנשים, או לעשות אוטומציה לעצמכם.
• אני לא יודע למה מיקרוסופט הוציאו את זה . . . 
• (אלון) תחבר אותו לTwit-Bot המעצבן שלי, ואז הוא מתישהו תחיל להגיד “בוא נדבר בטלפון”, ונתחיל להטריד אותם . . . .
• (דותן) כן, נריב בטלפון . . . 
• (דותן) אני לא יודע, יכול להיות שזה כאילו אחד מ... זה כמו Pet shop של כזה To-Do List כזה של AI, שהם בחרו כזה איזשהו דמו כזה - אבל זה מאוד אקסטנסיבי (Extensive).
• זה מאוד פרויקט מוזר, מעניין למה זה נולד שם.
• (רן) כן, וגם מעניין למה זה Open Source? . . .  כאילו, אולי זה כדי שאנשים לא יעשו את זה.
• אבל בוא נגיד, אם מיקרוסופט היו רוצים לעשות מזה Business, אני לא הייתי מהמר דווקא על Open Source.
• (דותן) כן, מוזר.
• (דותן) אבל האמת שכן, כאילו זה מזכיר לי ש... מה זה היה פעם? Masterix [?] ? שאתה לוקח ושם בבית, ואז יש לך כזה כמו מרכזייה טלפונית, שאתה בונה את התפריט לעצמך וכאלה כל מיני, “של פעם” . . . .
• טוב, האייטם הבא נקרא Memori, עם I בסוף. וזה, אה, גם זה קשור למה שדיברנו עכשיו - זה זיכרון ל-LLM.
• עכשיו, מה שמעניין-מוזר-קרינג'י פה, זה שה-Selling . . . כאילו, זה כתוב ב-Python, ופה בטח מכירים פרויקטים מהעבר, גם הזכרנו פה כאלה, אבל ה-Selling-point שלו זה לעשות איזה ()enable בשורה אחת.
• אז אתה כאילו בונה את הפרויקט שלך ב-Python - ב-LangChain או מה שאתה רוצה, קורא ל-LLM-ים ומה שאתה רוצה - ואז אתה עושה ()memori.enable - והדבר הזה עושה לך monkey-patching לאורך כל הקוד שלך.
• הוא לוקח את הספריית LLM, מכניס את עצמו לשם, ובעצם מזריק את עצמו לכל המקומות כדי לייצר לך זיכרון לדברים.
• ואז אתה לא צריך לנהל את זה.
• זה מעניין . . . זה טוב לעצלנים, אבל נשמע לי מפחיד קצת.
• (אלון) לא יודע, הבעיה שלי עם הדברים האלה, זה לא מהעניין המפחיד - העניין של בסוף כל הדברים האלה  נורא מעמיסים על ה-Context, ואתה יכול בקלות להוריד איכות אם אתה לא נזהר עם כל ה-Memory וה-LLM-ים…
• (דותן) . . . נו, זה מפחיד . . . .
• לא מפחיד שהוא ידע עליי דברים . . . . מאיזו בחינה זה מפחיד אותך?
• (דותן) אין בך פחד . . . אתה בן אדם ללא פחד!
• (אלון) מה יש לי לפחד? ה-Agent שלי כבר כותב את הקוד, שהוא יתמודד עם הבעיות האלה . . . 
• (רן) ודאי, כן . . . 
• (רן) דרך אגב, אני מנסה להבין באיזה שיטת זיכרון הם משתמשים . . . יש כל מיני דרכים לממש זיכרון ל-LLM.
• זאת אומרת, הכי פשוט, נגיד זה Key-Value, אוקיי? איך קוראים לזה . . .?
• (דותן) כתוב ב-SQL . . .
• (רן)  . . .  כן, אבל עדיין: איזה דאטה הם שומרים? נגיד שם, עיר וכל זה - זו אופציה אחת.
• אופציה אחרת זה לייצר Embedding של השיחה, כלומר - איזשהו סיכום יותר סמנטי של השיחה, נגיד על חלון מתגלגל.
• ואפשר לייצר, נגיד, סיכומים ממש טקסטואליים.
• זאת אומרת, יש כל מיני שיטות לייצר זיכרון לשיחה - אני תוהה במה הם משתמשים, עוד לא מצאתי.
• (דותן) את זה GPT לא סיכם לי . . . .
• כן . . . טוב, Memori, עם “I” ולא עם “Y” . . .
• (דותן) כן, ב-Python, מי שאוהב ומי ש... מעריץ.
• (אלון) Memori, עם “I”, תזכרו את זה . . . 
• (רן) אנחנו גם מעריכים את זה שעוד לא אמרת Rust בשידור הזה . . . 
• (דותן) מה? חכה . . . 
• [בטח איזו עסקה של מידע-פנים עם Polymarket . . . ] 
• (דותן) טוב, יש פה פרויקט שנקרא Dynamo - כותבים אותו רגיל’ עם “Y”. וזה . . .  אני חושב שזה פרויקט שלא רלוונטי לאנשים נורמליים, רגילים, אלא רק ליחידי סגולה.
• (דותן) אז לעשות Inference למודלי LLM ענקיים - באמת עניין אותי פעם איך זה עובד ב-Scale.
• ומסתבר שיש כל מיני דרכים של אופטימיזציה
• לוקחים נגיד כרטיס גרפי, NVIDIA כזה, ויש לו נגיד 100Gb זיכרון, אז לוקחים מודלים שמתאימים ל-100Gb הזה, נגיד 50 לזה ו-50 לזה.
• בעצם משתמשים באותו שטח בשביל לשרת כמה בקשות.
• וזה מוליד את הרעיון שאם נגיד מיליון User-ים משתמשים ב-GPT, אז כמה כרטיסים צריך? כי הרי כל כרטיס יכול לשרת בקשה אחת בו-זמנית.
• אז יש גם אופציות לשרת כמה בקשות - וזה Framework שממסד את זה.
• וזה נראה לי נעשה על ידי NVIDIA בעצמם, והוא משתמש בכמה סוגים שונים של Inference Engine, נגיד vLLM.
• אז אמרנו Rust וכאלה -אז זה בא לידי ביטוי כאן: הפרויקט הזה גם בחלק טוב ממנו כתוב ב-Rust.
• ולסיכום, מי שעושה - מי שבונה Cursor או Claude, אז מוזמן להשתמש בפרויקט הזה . . . 
• רן) כן . . . דרך אגב, אני יודע שלדעתי ל-NVIDIA יש קבוצת Inference פה בישראל, אני תוהה אם יש להם חלק בפרויקט הזה.
• לפי השמות של ה-Contributors, אני כרגע לא רואה פה שמות ישראליים - אבל אולי איפשהו מאחור.
• טוב, אחלה.
• (דותן) מי שמ-NVIDIA, אז מוזמן להשתמש בפרויקט של NVIDIA . . .
• (רן) כן, יש סיכוי טוב שלא מכירים את זה בפנים . . . 
• (דותן) טוב, אז האייטם הבא נקרא GPUI.
• אז זה קצת רקע - יש ספרייה שנקראת GPUI, מי שמכיר את העורך טקסט Zed, שיש לו קהל מעריצים מאוד חזק - מי שאוהב אז ממש אוהב . . .
• (רן) אחד מתוך שלושה בחדר הזה . . .
• (אלון) לא, האמת שהוא דפדפן ממש חמוד, הוא מהיר.
• (דותן) “דפדפן” . . .  עורך!
• (רן) לא דפדפן, עורך.
• (אלון) הכל היום זה דפדפן! סתם, סתם . . . לא נורא, נניח שהתכוונתי [ושהעברתי את ההודעה בקשר].
• (דותן) בסדר, הכל זה דפדפן.
• (אלון) כן . . . לא, זה עורך מהיר וחמוד, ולמרות שהוא מיום ליום יותר VSCode, אני חייב להודות. לא בקטע רע דווקא, בקטע טוב.
• (דותן) כן, אז זה עורך שכתבו ב-Rust - ולכן הוא מהיר וטוב ומצוין ויפה.
• ובאיזשהו שלב . . .  ויש שם המון קוד, האמת. פעם נכנסתי כדי לראות איך הם עושים את ה-AI שלהם, איך ה-Agent עובד והכל.
• אז יש שם הרים-הרים-הרים של קוד.
• ובשלב מסוים הם החליטו לקחת את כל ה-UI Framework שגם הם בנו, וכל ה-Windowing ו- Widget-ים שלהם - ופשוט להוציא אותם ל-Open Source.
• ולתת לכל אחד שכותב Rust, לנסות לכתוב גם אפליקציה - אפליקציית-Desktop באותה רמה שלהם, עם אותם Trade-off-ים שהם לקחו - וקראו לזה GPUI.
• אני לפני איזה חודש ניסיתי לבנות איזושהי אפליקציית Desktop עם זה, עם Vibe Coding.
• זה הלך ממש גרוע . . . .
• מודלים לא מכירים את זה, ויש להם פחות גם יכולת ליצור קומפוננטות (Components) High-Level.
• (אלון) אין, אין - אתה חייב משהו מוכר ל-Vibe Coding, ספריות מוכרות. 
• (דותן) אז פה יש פרויקט שמייצר קומפוננטות UI Framework בעצם לדבר הזה - וזה יכול גם לעזור.
• זאת אומרת - אתה צריך כפתור, אתה צריך טבלה, אתה צריך דברים טיפה יותר High-Level.
• הפרויקט-דוגמה שהם שמו שם נראה . . . . נראה מפוצץ.
• כאילו, זה נראה “עשוי”, זה לא נראה קשקוש.
• מעניין לבדוק את זה ל-Desktop Applications.
• (רן) הפרויקט דוגמה זה ה-Stock Ticker הזה שהם מראים?
• (דותן) כן.
• (רן) כן, יפה.
• (רן) דרך אגב, כשעשית את ה-Vibe, אז נגיד ניסית לחבר את GitMCP ל-Repo של GPUI, כדי שיבין את הפרויקט?
• (דותן) לא.
• (רן) אז זה יכול לעזור. לא תמיד קסם, אבל זה יכול לעזור, כי אז ככה לפחות יש לו גישה לתיעוד.
• [כן, גם זה היה ברברסים, ד”ש ל-FOMO שלכם - Prepare for the Fragmented Web Revolution / Liad Yosef & Ido Salomon]
• (דותן) כן.
• (דותן) אז הלכתי בסוף על Tauri, שזה חצי Rust, חצי . . .  וזה עבד מושלם, ממש Exceeded Expectations.
• (רן) זהו, אתה עכשיו מפתח UI?
• (דותן) אה... בניתי איזו אפליקציה קטנה, במקום לקנות, אז בניתי . . . . במקום לקנות רישיון.
• טוב, האייטם הבא נקרא Vibe Kanban - וזה סוג של Kanban, אני חושב, ב-View, כאילו איך שאתה מסתכל על הדברים - כדי להפעיל Agent-ים ולעקוב אחריהם.
• זאת אומרת, אתה - יש לך Kanban, אתה זורק דברים ל-Agent-ים, Agent-ים לוקחים, מזיזים את ה-Kanban.
• וככה אתה בעצם מנהל עבודה.
• וזה . . .  זה מעניין,האמת. כאילו, כ-בתור Experiment ויזואלי, אבל לא יותר מזה. יכול להיות נחמד.
• (אלון) סתם שאלה - מה ההבדל בין זה ללתת לו API של מערכת עם Kanban? או שאין הבדל, וזה סתם גימיק?
• (דותן) אני חושב שמישהו פשוט בנה איזשהו פרויקט. לא יודע, לקרוא לו גימיק? בסדר, נקרא לו גימיק, גם ככה זה הוא...
• (אלון)  . . . .גם ככה הוא כתב אותו בVibe Coding . . . 
• (רן) דרך אגב, זה מזכיר לי מאוד את Conductor - יצא לכם להשתמש ב-Conductor? אני חושב שזה השם . . . 
• הבחור ש . . . כאילו, איזשהו מוצר קטן שעושה אוטומציה ל-Claude code.
• אם אתם רוצים, נגיד, לעבוד במקביל על כמה פיצ'רים מקומית, אז Conductor - אני מקווה שזה השם הנכון - הוא זה שבעצם מנהל אותם.
• בצורה די דומה - סוג של Kanban, הוא מראה לכם בעצם מה כל אחד מהAgent-ים עושה, משתמש  ב-GitHub subtree כדי לייצר כמה עותקים של ה-Repo שלכם.
• כל אחד עובד עליהם במקביל - ואתם יכולים ב-Real Time לעקוב אחרי ההתקדמות שלהם.
• אז זה נראה ממש דומה - גם בעיצוב הגרפי וגם מבחינת הקונספט של איך זה עובד . . . מעניין אם זה מגיע מאותו בחור.
• (דותן) מעניין  . . . 
• (רן) אה, זה מחברה שנקראת Bloop AI.
• (דותן) Bloop?
• (רן) Bloop . . . . טוב, בסדר.
• (דותן) אייטם אחרון, זה קשור ל-Google ADK (Agent Development Kit) - אז נתקלתי ב-Sample-ים שלהם.
•  ה-ADK זה ה-Agent Development-Whatever [Kit] . . . . 
• ואת האמת שזה יצא לי . . .  יצא לי לחפש דברים כאלה - נגיד, כל מיני Pattern-ים כאלה, שנגיד אתה בונה Code Reviewer.
• אז אתה רוצה נגיד Agent שעושה איתך אנליזה על הקוד, ואז אתה מוציא איזה 80 Agent-ים כאלה ואז לכל אחד יש תוצאות, 
• ואתה רוצה “Agent אחראי, בוגר”, שיעשה Review לכולם.
• כאילו Map-Reduce כזה וכל מיני Pattern-ים כאלה.
• אז יש פה כמה דוגמאות לדברים כאלה ב-Python ו-Go ו-Java - ועניין אותי דווקא לראות איך זה נראה ב-Go.
• זה נחמד . . .  אני לא אגיד שזה נראה יפה.
• (רן) כן, אז כאילו בעצם אורקסטרציה (Orchestration) של Agent-ים - היכולת נגיד לעשות . . .
• (דותן) כן, אבל גם שמתי ספציפית את ה-Samples - יש כל מיני . . .  אני מאמין שיש לזה עתיד.
• כאילו, יש לזה “נפח” - לבוא ולייצר, אני לא יודע אם זה Patterns, זה כמו Blueprints כאלה, של . . . 
• הרי, כאילו אתה יכול לעשות Agent-types, שאתה יכול להגיד יש לי Agent שהוא “פקח-בנייה” ויש לי Agent שהוא “פועל בניין” ויש לי Agent שהוא “קבלן”.
• (דותן) ולתת תפקידים - ואז כל אחד צריך לתקשר בצורה מסוימת עם השני.
• אז אני מאמין שיש . . .  כאילו צומחות כאלה תבניות Useful.
• ויש כאן תבניות מטומטמות - כאלה שסתם אנשים בונים, כאילו “אוקיי, זה יהיה Agent שאחראי להכל”
• וזה יהיה Agent זה לא שימושי, כי Agent אחד לא יכול לעשות את הכל בסוף.
• יש ב-Samples-ים כל מיני כאלה - וזה מעניין. 
• (אלון) עכשיו, Cursor - יצא Cursor 2.0. לא דיברנו, אבל 2.0 - מה שהם עשו זה שהם שינו את ה-UI קצת, שיהיה כזה “אזור ייעודי לעבוד מול הAgent-ים”.
• שהאמת שאני מאוד מחבב את השינוי שהם עשו.
• אבל אחד הדברים הנחמדים בהקשר הזה, זה שאתה מדבר איתו ואומר תכתוב לי “טה-טה-טה-טה-טה” - ואז כשאתה מסיים, אתה לוחץ על כפתור “Review”!
• ואז רץ Agent אחר - שעושה Code Review ל-Agent הקודם . . . . והוא בא עם כאילו Context אחר ונקודת הסתכלות אחרת מאשר לכתוב את הפיצ'ר.
• שזה די מגניב . . .  כאילו, הם עשו את המימוש הזה. נכון שהם עוד לא ממש מדברים אחד עם השני - כי כאילו אחד כותב את הקודם הזה שאני קורא את מה שהוא כתב - אבל הוא ממש משאיר הערות בReview ואז הוא נותן הערות ואז Agent אחר בא ומתקן את זה . . . 
•  (דותן) מה שאמרתי זה שאם זה לא אותו מודל, לא אותו . . .  כאילו, אם זה היה במודל X והוא במודל Y [מדובר ב-LLM, לא ב-Tesla . . . .], אז אני מבין. 
• אבל אם זה אותו מודל, וזה סך הכל Base Instructions כאלה ואולי כמה Tool-ים שונים בין אחד לשני, אז השאלה זה האם ה-LLM-ים האלה לא מספיק חזקים כדי להגיד לו “תתחיל א' ותשנה את האישיות שלך ל-ב'’”, כאילו סוג של כזה . . . 
• (אלון) מניסיון - לא. הבעיה זה Context בסוף - כי ברגע שאתה אומר לו “תעשה A ואז תעשה לו B”, הוא צריך להחזיק הרבה יותר Context.
• לעומת זאת, שאתה אומר לו “תעשה A”, ואז אתה בא ל-Agent חדש ואומר לו “תעשה לו Review רק על התוצרים”, ה-Context שונה לגמרי.
• קודם כל, הוא לא בא עם הנחות יסוד. כמו בני אדם לפני Code Review . . . 
• [החבר Karpathy בדיוק פתח פה חתיכת מאורת-ארנב בנושא דומה . . .. לפעם הבאה]
•  (דותן) אבל אני יכול גם להגיד לו “שמע, מעכשיו תשכח מה-Context”, כאילו, תתייחס אליו בתור “בנאדם בוגר”. . . 
•  (רן) אבל  זה שקול . . . זה שקול, דותן. זה בעצם ש”תשכח מכל ה-Context” זה בעצם לייצר Agent חדש.
• (אלון) כן . . . “תשכח מזה”.

[44:26] לעשות Code Review “כמו פעם”?

• (רן) אבל יש לי שאלה - אתם ממשיכים לעשות Code Review “כמו פעם”? כלומר, עכשיו נגיד מג'ונרטים (Generate) “הרים של קוד”, הרבה מהם אוטומטיים. חלקם באיכות טובה יותר, חלקם באיכות טובה פחות . . . . וכן, אוקיי - ואפשר לעשות Review אוטומטי גם על ידי Agent-ים, סבבה. אבל מה עם Review אנושי? ממשיכים אותו דבר? כלומר . . . 
• (אלון) לא, ממש לא.
• אני בפרדיגמה שאומרת “קודם כל, אל תכתוב קוד - אתה עושה הכל ב-Vibe Code”.
• כאילו, צריך לעשות את זה חכם, אבל יש את הדרכים הנכונות לעשות את זה.
• ואז אם אתה לא נגעת בקוד, אז מה הבעיה שאתה תעשה עליו Review?
• כאילו, מה אתה צריך בן אדם אחר? זה דבר ראשון.
• דבר שני, כשכן עושים Review לאחרים, הדברים שמעניינים אותי מאוד זה ה-Interface-ים, ה-API-ים.
• כי הדברים האלה נהיים הרבה-הרבה יותר קריטיים בעולם החדש.
• כי אם לפני זה היית אומר “טוב, את ה-API מקסימום אחרי זה נשנה”
•  עכשיו מגיע ה-Agent, והוא רואה “אה, זה ה-API! טוב, כבר נשתמש בטמטום הקודם” . . . 
• אז הדברים האלה נהיים הרבה יותר קריטיים - והטסטים.
• בפנים מבחינתי זה Black Box, כאילו.
• אבל אני אף פעם לא הייתי חסיד של Clean Code וכאלה, אני חייב להגיד, אז לא רק . . .  תמיד לא היה אכפת לי איך הקוד נראה כל עוד הוא עונה על הטסטים, Performing ומממש את ה-API נכון.
• אז לא יודע, זו דעתי בנושא.
• (רן) כן, ואצלכם בחברה? זאת אומרת, כבר שינו איזשהו פאזה? כלומר, עוברים ל-Code Review סלקטיבי, רק של Interface-ים וזה, או ש... 
• (אלון) כן, כן. יש מקומות שיותר, יש מקומות שפחות.
• תראה, אנחנו מזמן עברנו לגישה של ה-Show-Ship-Ask של Git, שלכל שינוי - צריך לעשות לו Review אנושי.
• למי שלא מכיר - ה-Ship / Show / Ask אומר . . . . זו פרדיגמה ב-GitHub - נוסיף למסמך [נוסף]- שאומרת:
• ש-“Show” - אתה אומר “חבר'ה, עשיתי שינוי!”, נגיד Type או קונפיגורציה (Configuration) או משהו כזה 
• “תכירו שעשיתי אותו, אבל אני לא מצפה” - אף אחד לא צריך לעשות עליו Review, חבל על הזמן שלכם.
• כאילו, אני אשלח לכם “לידיעה".
• ו-Ship” אומר “חבר'ה, עשיתי שינוי - אני לא חושב שהוא מסוכן, אבל אני אשמח לקבל תגובות”.
• “תגיבו לי, ואחר כך אני אשנה”.
• אבל אני כבר “המשכתי הלאה”, אני לא מחכה לכם.
• ו-Ask” זה בעצם הרגיל - זה אומר “רגע, אני אמתין לשמוע את התגובות - ואז אעשה את השינוי”.
• אז אנחנו מנסים לעבוד הרבה יותר . . . מזמן ניסינו לעבוד הרבה יותר ב-Ship ו-Show, כש-Ship כאילו זה אמור להיות ה-Default לרוב המקרים, אגב.
• ולא Ask, כמו שהפרדיגמה של רוב התעשייה לדעתי.
• וברגע שאתה עובד ככה, אז אתה כבר כאילו צעד אחד קדימה, כן? כי אז אתה גם מסתכל אחרת על Code Review, אתה יודע שכבר הדברים עובדים וכאלה.
• כמובן שכדי לעבוד בשיטה הזאת, שנייה, צריך Guardrails טובים למערכות.
• כלומר, אנחנו עובדים למשל רק על Production - אין לנו עוד סביבות.
• אבל יש לנו מלא שליטה על Production - איך לפתוח פיצ'רים, לסגור פיצ'רים, לעשות Rollback-ים מהירים, Canary וכל הדברים האלה.
• ולכן באנו מוכנים לאירוע הזה, כאילו, אני אומר - של ה-AI, לדעתי.
• היו לנו כבר את כל היסודות במקום הנכון, אז זה לא שינוי ממש קיצוני.
• כאילו, זה להמשיך את היותר חזק על הפרדיגמה שכבר הייתה, בוא נגיד את זה ככה. 
• (רן) כן, אוקיי - אחלה, תודה!

[47:36] הפיל שבחדר (רגע לפני ש-Cloudflare ביקשו ממנו להחזיק שנייה את הבירה)

• (רן) עכשיו, יש פיל אחד בחדר שעליו לא דיברנו, ולמי שהיה על הפלנטה בחודש האחרון ומשתמש ב-AWS, או סתם ככה משתמש באינטרנט, בטח שם לב שהייתה תקרית די חריגה ב-Datacenter שנקרא US-East-1  של AWS. התקלה במקור קרתה בעקבות איזושהי שגיאת DNS ב-DynamoDB, שזה Database מרכזי ב-AWS. מי קרא? אני לא קראתי את התחקיר . . . מי קרא ויכול קצת לספר?
• (אלון) אז ככה: קודם כל זה היה אירוע מאוד מעניין . . . הוא התחיל בגלל שגיאת DNS.
• מה שקרה זה שהיו שם כמה Service-ים שעושים את העדכון, ואחד מהם - היה לו Delay מאוד-מאוד משמעותי, הוא נכנס ל-Delay מאוד משמעותי.
• אני לא הצלחתי להבין כמה זה “משמעותי", אבל הם אומרים ש“מאוד משמעותי”.
• ומה שקורה, שבא ה-Planner ועדכן את כל הרשומות DNS - וחשב שהוא סיים.
• ואז הוא יכול להמשיך הלאה לסגור את הטרנזקציה, לא בדיוק . . .
• ואז בגלל שהיה Delay, בא “הבחור מאחורה”, שעוד לא היה מעודכן - והתחיל לעדכן את כל הרשומות DNS לדברים שהם כבר לא רלוונטיים.
• הוא היה ממש ב-Delay, לא יודע איך לא היה Monitoring על כזה דבר או משהו כזה.
• אבל הוא רץ - וב-Delay.
• הם טוענים שזה היה מקרה קיצוני של Race Condition ובלה-בלה-בלה . . . .
• ושזה היה ככה מאז “קום DynamoDB”.
• (אלון) לקונספירטורים, אני רק אגיד ששבועיים לפני זה היה מאמר שאמרו ש-AWS פיטרו 20,000 DevOps והפכו את זה ל-AI Automation - ואז זה קרה . . . 
• אז הקונספירטורים אומרים שזה AI עשה את הטעות הזאת, ולא בן אנוש.
• אני לא יודע מה נכון . . .
• (דותן) או . . .  זה מעניין.
• (אלון)  . . . כי יש את המאמר שהם עשו - הם החליפו את המערכת SRE ב-AI, ואז אחרי זה קרה האירוע.
• (אלון) אז לא יודע אם זה קשור. מקרה בהחלט . . . 
• (דותן) אבל יש מי ששם את ה-AI, מה זאת אומרת? זה לא יכול להיות ש-”AI אחראי”.
• מה עושים? כאילו, שורפים את המחשב של ה . . . ? שורפים את המחשב שנמצא בו ה-AI?
• (אלון) אז קודם כל - פיטרו את ה-AI, העבירו אותו . . . עשו לו Dump לגרסה, מחקו לו את ה-Memory, היה תחקיר . . . 
• (דותן) כן, כן, מבחינת זיכרון . . .
• (אלון) עכשיו רגע, מה שהיה מעניין באירוע הזה, שכרגיל US-East-1 נופל.
• כי אם אתם רוצים שהענן שלכם לא יפול, תצאו מ-US-East-1. זה נכון תמיד.
• אבל מה שהיה מעניין אחרי זה שלא דיברו עליו, ובמקרה אני הייתי על זה - כמה שעות אחר כך, Azure נפלו.
• עכשיו, הטענה ש-Azure נפלו בגלל שהתחילו להעביר Workloads ל-Azure מ-AWS - והם נפלו.
• לנו [Tomorrow.io], אני יכול להגיד לך, היו גם תקלות ב-GCP - בגלל שהתחילו להיגמר מכונות ב-US-East-1, ב-Zone-ים מסוימים, כי אנשים התחילו להעביר Workloads.
• הקיצר, גם אם הייתם Multi-Cloud - זה השפיע עליכם, האירוע הזה.
• (רן) יש פה צונאמי, כן, זה ממש צונאמי שמתפשט.
• (אלון) זה צונאמי? אז . . . 
• (דותן) אבל זה לא השפיע על DHH . . . הוא רק חיכה לזה.
• (אלון) על DHH לא משפיע כלום, נכון. לעשות מאמרים של “אמרתי לכם ש-Cloud זה חרא!”
• (אלון) אופציה אחרת זה פשוט לזוז מ-US-East-1 . . . . כי בשלושת ה-Cloud-ים זה רק מ-US-East-1.
• זה כאילו, תמיד . . . “US-East-Failure” שיקראו לו, וזהו.
• כאילו באמת - הכל קורה שם, כל הנזקים.
• אני לא מצליח להבין את החברות Cloud - למה כל הניסויים שלהם על US-East-1? למה הם לא הולכים לאיזה India, או אירופה, או לא יודע משהו, איזה ... 
• (דותן) טוב, עכשיו כולם יעברו לשם, ועכשיו שם תהיה סכנה . . . תשארו על US-East-1!
• (רן) אם הקשבתם עד פה - חכו לסוף הפרק. נגיד לכם לאן ללכת . . .  נגיד לכם איפה באמת כדאי להיות. 
• (אלון) כן . . .  אבל אגב, מה שמעניין - ה-DynamoDB כאילו נפל, שזה “כולה Database”.
• (אלון) אבל מה מסתבר? מסתבר שה-EC2, כדי לרשום את עצמו, הוא צריך את ה-DynamoDB . . . אז הוא לא הצליח לעלות.
• ואז אנשים אמרו “בסדר, מה אכפת לי? אני על Serverless! אני על Lambda!
• אז Lambda, מאחורי הקלעים - לא תאמינו, Spoiler! אני אומר לכם משהו, אל תיפלו מהכיסא . . . 
• (דותן) לא, לא . .  אל תגלה . . . 
• (אלון) . . . זה רץ על מכונות!
• (דותן) אל תגלה!.
• (אלון) . . . . זה רץ על שרתים, EC2 - אז גם הם לא עלו. 
• ה-Database-ים גם לא עלו - כי זה גם.
• גם ה-CloudWatch-ים לא עשו Trigger כי הם לא יכלו לסמן ולא יכלו זה . . . 
• (אלון) בקיצור, היה פה Cascade מטורף על שירות אחד.
• אז זה נורא מגניב - כל ההרצאות Resilience של Amazon.
• בטח - “תפרידו שירותים”, כל זה . . . 
• כן - “Multi-Tennant! אנחנו לא נופלים בחיים!”, ה-EC2 . . . .
• בסוף, וואלה - Delay של Flow אחד, הפיל להם את כל ה-Cloud. 
• אז בואו - חבל על כסף שלכם, תהיו פחות Resilient בתיאוריה, ובאמת - הכל גם ככה נופל. 
• (דותן) Disclaimer, רגע - AWS חברה טובה! אנחנו אוהבים את Amazon, קונים הרבה מ-Amazon, מזמינים הרבה . . .
• (רן) תקלות קורות לכולם . . . 
• (אלון) החסות! נו, וזה . . . . הם משלמים לנו על חסות? כי אם כן, אני יכול להרים להם פה עכשיו . . . 
• (רן) . . .  וזה היה פינת המצחיקולים שלנו . . . 

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[23:03 - דותן]

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

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