Skip to content
Sign in
Artwork for רברס עם פלטפורמה
Technology

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

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

פודקאסט על תוכנה, מוצר, ותשתיות — בעברית.

Play
Open in
  • 22 episodes
  • Hebrew

Episodes 22

NewestOldestLongest
All20Unplayed20In progress0Played0
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • August 20 · length unknown

    519 - The Agentic Awakening with Liran Eshel

    בפרק 519 של רברס עם פלטפורמה, רן ואורי מארחים את לירן אשל (יזם ולשעבר מנכ"ל CTERA) לשיחה מרתקת על העידן החדש של פיתוח תוכנה. לירן משתף בתובנות מתוך הספר שכתב, החוקר כיצד חברות צריכות לבנות את עצמן מחדש בעידן ה-AI-Native, ואיך הופכים מפתחים לסוכנים עצמאיים. [00:30] הצלילה למחילת הארנב של ה-AI לירן מספר על הרקע שלו כיזם, ואיך אחרי 20 שנה כמנכ"ל שלא נגע בקוד, הוא מצא את עצמו נשאב חזרה לפיתוח בעקבות מהפכת ה-AI. המעבר המהיר מעולם של Assisted engineering (השלמות טאבים) לעולם של Autonomous ו-Agentic engineering. הספר שעליו מבוסס הפרק, ומהווה למעשה מדריך פעולה לארגונים, זמין אונליין בחינם: The Agentic Awakening. [05:37] המחקר וארגונים שנולדו ל-AI איך נולד הרעיון לספר מתוך שיחות עם אדם פישר, שותף בקרן ההון סיכון Bessemer Venture Partners. ראיונות עם בכירי פיתוח בחברות מובילות (כמו Lemonade, Ramp, DriveNets) וזיהוי דפוסים חוזרים באופן שבו הן מטמיעות כלי AI. מטאפורת ה"התעוררות" התאולוגית: אי אפשר באמת להבין את האירוע עד שחווים אותו בידיים (או במרתף עם הקוד). [10:56] תעלומת הפרודוקטיביות: למה הארגון לא עף קדימה? הדילמה הגדולה של הנהלות היום: אם המפתח הבודד פרודוקטיבי פי 10, למה תפוקת החברה לא עולה אפילו פי 1.5? אנלוגיית הפרארי ברמזורים: יש לנו כלי רכב מטורף ומהיר (AI), אבל אנחנו מסיעים אותו ברחוב עירוני עם רמזור כל 200 מטר. הרמזורים הם למעשה מתודולוגיות הפיתוח הישנות (Design reviews, Architecture reviews, Handoffs). תהליכים שנבנו מתוך הנחה שכתיבת קוד היא הדבר הכי יקר ואיטי, ולכן חובה לתכנן הכל מראש מול ועדות. [16:20] ארבעת הצ'יפים (The Four Chiefs) כדי להסיר את הרמזורים ולהחליף אותם ב"חגורות בטיחות" או מצלמות מהירות (בדיקות אסינכרוניות שלא תוקעות את המפתח), צריך ארבע פונקציות פיקוח: Chief Architect: מוודא שה-Agent לא קיבל החלטה תשתיתית הזויה (כמו לבחור דאטה-בייס לא קשור כי זה מה שהמודל המליץ). Chief Security: שומר על אבטחת מידע מאחורי הקלעים תוך כדי שהמפתח רץ ל-Production. Chief Product: ה"ווייז" שמוודא שרצים לכיוון העסקי הנכון. Chief Design: מפקח אנושי שמוודא שהמוצרים לא נראים כולם אותו דבר (כי קלוד כותב את כולם כרגע). [17:33] האתגר הגדול: איך מודדים את זה? לספור שורות קוד זה לא רלוונטי, אבל ספירת טוקנים היא תנאי סף התחלתי: מפתח ששורף טוקנים ב-100 דולר בחודש לא באמת נמצא במוד Agentic. מדובר על ממוצעים של אלפי דולרים או מיליארדי טוקנים לחודש. שימוש ב-AI כדי להעריך איכות ומורכבות: ה-AI יכול בעצמו לנתח את ה-Pull requests ולהעריך את המורכבות שלהם. שקיפות ארגונית: פרסום המדדים הפנימיים מייצר תחרות בריאה ומדרבן עובדים ללמוד מה-Bright spots (המפתחים המהירים ביותר). [22:11] משבר הג'וניורים ושובו של הג'וניור האם יש עדיין מקום לג'וניורים בתעשייה? לירן מתאר שתי גישות מנוגדות: ארגונים שמשאירים רק את הסיניורים (Domain experts). ארגונים שרואים "The Return of the Junior": ג'וניורים שהופכים למעין מנהלי ציים (Agent Orchestrators), שם דווקא מולטי-טאסקינג והפרעת קשב הופכים ליתרון. היתרון הזמני של ישראל: יוצאי יחידות טכנולוגיות בצה"ל משתחררים עם יכולות קידוד וניסיון שמאפשר להם לדלג על פערי הידע של ג'וניורים בחו"ל. [26:17] אתגר ההמרה (Converting the People) שינוי המיינדסט בארגון קיים הוא החלק הכי קשה. אנשים מתייחסים לקוד כאל יצירת אומנות, וה-Agent נתפס כטרקטור דורסני. חלוקת האנשים ל-4 קבוצות: המאמינים (Believers): המאמצים המוקדמים. אותם צריך לסמן כגיבורי השינוי וללכת אחריהם. משתמשי הכלים (Tool users): אלה שנעזרים ב-AI ברמה הבסיסית (כמו בקרת שיוט ברכב), אבל עדיין לא מפעילים צי של סוכנים שעובדים במקביל. שומרי ה-Legacy: אלה שחוששים (לעיתים בצדק) לתת לסוכן להשתולל בתוך מונולית ישן או קוד קריטי. הפתרון פה הוא הרבה פעמים Rewrite מוחלט ומהיר בעזרת הכלים החדשים. המתנגדים (The Resistance): אלה שבטוחים שהכלים האלה יעברו מן העולם מחר בבוקר. השוני התרבותי: חברות אמריקאיות נטו לעשות שינויים אגרסיביים ("תרפיית הלם" - לנעול מפתחים באוף-סייט ולהכריח אותם לכתוב קוד רק דרך סוכנים), בעוד שהתרבות הישראלית לעיתים הכילה יותר מדי שמרנות וסלחנות, מה שעלול לייצר פיגור בקצב. [38:53] נקודת המפנה והמבנה הארגוני העתידי יחסי PM לפיתוח משתנים. מ-1:10 בעבר, ל-1:15 במוצרים למפתחים (כי המפתחים הופכים למיני-יזמים), או במקרים מסוימים אפילו ל-Squads של 1:1 – איש מוצר שצמוד ישירות למפתח Agentic סופר-חזק כדי לרוץ על פתרונות מאפס. ברבעון הרביעי נוצרה נקודת שבירה (Inflection point) עם שחרור המודלים החדשים, שהפכו את האייג'נטים לכאלה שמסוגלים לבנות פרויקטים שלמים ולא רק פונקציות בודדות. אזהרת סיכום מלירן, שמצטט סטטיסטיקה של מקינזי (McKinsey): ה-Top 1% של ה-Agentic programmers מפיקים פי 46 מהחציון. המשמעות היא שצוות של שני מתכנתי-על יכול למחוץ כיום ארגון פיתוח איטי בן 50 עובדים שעדיין לא עשה את הטרנזקציה. הקצב משתנה, ומי שמתמהמה מסתכן בהישארות מאחור. האזנה נעימה!

  • August 19 · length unknown

    518 - Carburetor 42

    פרק מספר 518 של רברס עם פלטפורמה - קרבורטור מספר 42. רן ואורי מארחים שוב את נתי שלום לפרק המשך בסדרה על סוכני קידוד, והפעם - מה קורה כשסוכני AI (Agents) מגיעים לסביבת הפרודקשן. אנחנו צוללים לתוך השינוי הטקטוני שעוברת תעשיית ה-Observability, התרסקות המודלים העסקיים המוכרים, ומי הולך להרוויח את הזכות לא רק לתצפת על המערכות, אלא גם לתקן אותן בפועל. [01:24] מ-Assisted SRE לתיקון אוטונומי מה קורה כשהסוכנים מגיעים לפרודקשן ומה ההבדל בין פרסונת ה-DevOps לפרסונת ה-SRE בארגון. הבשלות של התעשייה: משתמשים כבר לא רוצים מערכות "מסייעות" (Assisted) שרק זורקות המלצות ומייצרות יותר עבודת פענוח לאדם. הדרישה כיום היא לסוכנים שפשוט פותרים את הבעיה. [05:51] הרגע שבו Datadog הבינו את המשחק דיון על חברת Datadog (ואיך הם קיבלו את השם שלהם ממדבקה על שרת אקראי). רעידת האדמה בתעשייה: ההבנה של ענקיות ה-Observability שהמודל הישן מת. המנכ"ל של Datadog מודה בעצמו שהארגונים מצפים עכשיו לפתרונות אקטיביים ולא רק לאיסוף נתונים וצפייה. לקריאה נוספת והעמקה על הדיסוננס של החברה מול השוק, קראו את הפוסט של נתי בנושא: Datadog beat Q2 and the market sold it off: here's the tension the number hides. ההשוואה ההיסטורית למאבק של VMware מול AWS: זה לא רק פער טכנולוגי, אלא שינוי דרמטי במודל העסקי שמחסל את החפיר (Moat) הישן. [12:02] כשל השוק של ה-Data Lakes בעיית העלות המובנית: המודל העסקי של חברות האובזרבביליטי מבוסס על תמחור לפי נפח הנתונים (Ingestion). רוב המידע שנשמר הוא "זבל" - לוגים ונתונים שאיש לא קורא עד שיש תקלה, אך ארגונים משלמים עליהם פרמיום כמעין תעודת ביטוח. סוכני AI הופכים את אגירת כל הנתונים באגם מרכזי ללא כלכלית בעליל (לא ססטיינבילית), מה שמאיץ את הנפילה מצוק של ספקיות המסורתיות. [16:27] רגע ה-Claude Code של עולם הפרודקשן בניגוד לאימון על היסטוריית תקלות רנדומלית, מערכות אוטונומיות אמיתיות צריכות "סימולטור" - יכולת לשחזר תקלה בסביבה מבוקרת (Reinforcement Learning Verified Rewards). בדיוק כמו ש-Claude Code מריץ ובודק מול הקומפיילר כדי להגיע לדיוק, סוכן SRE חייב Feedback Loop אמיתי ולא רק להתבסס על ארכיון לוגים. רוב הידע הבסיסי על תקלות נפוצות ממילא כבר מקודד פנימה בתוך הזיכרון הפרמטרי של ה-LLMs (הם ה"Stack Overflow" של עצמם). [29:21] רדיוס הפיצוץ: איך סומכים על סוכן בפרודקשן? החשש הטבעי: מה יקרה אם הסוכן האוטונומי ישנה קונפיגורציית רשת או יוריד שרתים בטעות? הדילמה הפסיכולוגית מול סטטיסטיקה - כמו ההבדל בין נהג אנושי למכונית אוטונומית או טייס אוטומטי במטוס. הפתרון: מנגנוני בקרה אוטומטיים שמחשבים מראש את "רדיוס הפיצוץ" (Blast Radius) של התקלה. הסוכן מחליט מתי מותר לו לתקן לבד ומתי האימפקט גדול מדי ומצריך התערבות אנושית. [34:36] קונטקסט לוקאלי מול גלובאלי תקלות רבות נולדות משינויים (Drift), ורוב הקונטקסט הדרוש כדי לפתור אותן נמצא ברמת הקלאסטר הלוקאלי. למה איסוף כל הנתונים לענן מרכזי שגוי: בעיות אבטחת מידע, עלויות מטורפות, ו-Latency (איחור בהגעת לוגים ומטריקות שמבלבל את תמונת המצב בזמן אמת). דילמת החדשנות: חברות ה-Observability הגדולות מזהות את הבעיה (וקונות חברות בתחום), אבל מתקשות לשנות כיוון בגלל התלות במודל ההכנסות הקיים שלהן. [40:27] חוקר התקלות לעומת יוצר התקלות חשיבה מחדש על התהליך: במקום להגיע ל"זירת פשע" בדיעבד, מה קורה אם ה-AI שכתב ודחף את הקוד (ה"פושע") הוא גם זה שמנתח ומזהה את התקלה? החשיבות העצומה של Efficiency (יעילות) בעולמות התשתית של ה-AI היום, ואיך היא משפיעה על הערכות שווי של חברות אוטונומיות (כמו Devin). השורה התחתונה: אין טעם לקחת תהליך שבור וצוותים מופרדים ולהדביק להם AI כפלסטר. זו הזדמנות לעשות הנדסה מחדש לדרך שבה אנחנו מנהלים את האמינות של המערכות שלנו. האזנה נעימה!

  • July 9 · length unknown

    517 - Bumpers 92

    פרק מספר 517 של רברס עם פלטפורמה - ואנחנו בבמפרס 92! רן, דותן ואלון מתכנסים לדבר על הטרנדים החמים בעולמות הפיתוח, החל מ-Loop Engineering וסקילים לאג'נטים, דרך המעבר של Bun ל-Rust, ועד לטריקים יצירתיים לחיסכון בטוקנים ומבחן הטיורינג החדש. [02:22] קול קורא ולופ אינג'ינרינג רן מזכיר שהקול הקורא (CFP) לכנס רברסים 2026 עדיין פתוח (עד ה-26 ביולי) - זה הזמן להגיש הצעות להרצאות! שיחה על Loop Engineering - מתודולוגיה לאוטומציה של פיתוח מבוסס אג'נטים שמטריפה את הרשת. אדי אוסמאני (Addy Osmani) כותב על זה לא מעט בטוויטר. מומלץ לקרוא את הפוסט המסכם שלו בנושא שעושה סדר במרכיבים השונים של הלופים ואיך להשתמש בהם נכון. [11:15] המעבר של Bun מ-Zig ל-Rust ההחלטה הארכיטקטונית המעניינת מאחורי המעבר של פרויקט Bun - נכתב על כך פוסט מפורט בבלוג שלהם: Bun from Zig to Rust. דיון על ההבדלים בניהול זיכרון ב-Zig לעומת Rust ועל היתרונות לטווח ארוך למרות הבינארי הקטן ש-Zig מציעה. האם עקומת הלמידה הקשוחה של Rust כבר לא רלוונטית בעידן שבו האג'נט כותב ומקמפל את הקוד בעצמו? [19:45] ערימות של סקילים לאג'נטים דותן משתף על ריפוזיטורי מעולה של אדי אוסמאני שמכיל סקילים שימושיים לאג'נטים: agent-skills. המלצה רותחת על סקיל לכתיבת דוקומנטציה: Documentation Writer. דותן ניסה אותו על פרויקטים ישנים וגילה שהאג'נט יכול לכתוב דוקומנטציה מושלמת מאפס ב-5 דקות, תהליך שבעבר לקח שעות של כתיבה וריבים פנימיים. [26:04] לדבר כמו איש מערות כדי לחסוך טוקנים אלון מציג פתרון לבעיית ה"חפירות" של האג'נטים (והבזבוז הנלווה של טוקנים). הרעיון הוצג בציוץ של Hesamation. הפרויקט עצמו, Caveman, גורם לאג'נט לפשט את השפה, לדבר כמו "אדם קדמון" ולתמצת ניסוחים לשליש מגודלם המקורי. טיפ נוסף מאלון: במקום לקרוא הררי טקסט, אפשר לבקש מהאג'נט לייצר סימולציות והמחשות ויזואליות ב-HTML כדי להבין מצבים מורכבים כמו עומסי טראפיק ו-Circuit Breakers. [30:17] פינת המצחיקונים: מבחני טיורינג, משקולות ופרומפטים מוחבאים מבחן טיורינג החדש: נסו לגרום ל-LLM פשוט לספור עד 100. תראו את סרטון הטיקטוק של Husk שמדגים איך שלושה אג'נטים מנסים לחשוב על אסטרטגיה מורכבת לספור ביחד - ונכשלים. In The Weights: האם השם שלכם נמצא בתוך המשקולות של מודלי השפה? האתר In The Weights מאפשר לכם לבדוק מה ה-AI חושב עליכם (רן גילה שהוא זמר ומשקיע, ואלון הוא בכלל מדבב). Prompt Injection בלינקדאין: המשתמש tmuxvim הוסיף פרומפט מוחבא בפרופיל שלו שגורם לבוטים של מגייסים לפנות אליו אוטומטית באנגלית עתיקה ומוגזמת בנוסח ימי הביניים. חיסכון בעלויות דרך תמונות: איך חותכים את צריכת הטוקנים כשיש הרבה קונטקסט? ממירים את הכל לתמונה! הפרויקט pxpipe מדגים איך העברת היסטוריה ומסמכים כטקסט-בתוך-תמונה מוזילה משמעותית את עלות הקריאות למודלים. האזנה נעימה!

  • June 17 · length unknown

    516 - Carburetor 41 Open source and agentic coding

    פרק מספר 516 של רברס עם פלטפורמה - קרבורטור מספר 41. הפעם רן ואורי מארחים את נתי לשיחה על נקודת המפגש המרתקת שבין קוד פתוח לקידוד מבוסס סוכנים (Agentic Coding). דיברנו על העתיד הדיסטופי והאופטימי של מפתחי קוד פתוח, איך משווקים מוצרים ל-Agents, ולמה שורת הפקודה (CLI) חוזרת אלינו בענק. [01:04] העתיד המדומיין של AI (סיפורו של OpenClaw) נתי משתף סיפור משעשע על ניסיון לחקור את "OpenClaw". הזיות (Hallucinations) של מודלים: Claude מאשר את העובדות, בעוד ש-Gemini מנתח שמדובר בהמצאה עתידית (פברואר 2026). הבנה שמודלי שפה (LLMs) הם מנועים הסתברותיים ולא מנועי חיפוש עובדתיים. [05:58] החזון הדיסטופי: האם AI יהרוג את הקוד הפתוח? בעיית ההעתקה: בעבר קוד הוגן על ידי רישיונות (כמו AGPL), היום קל לבקש מהמודל לשכתב קוד משפה אחת לאחרת (למשל מ-NodeJS ל-Rust) בעלויות אפסיות. קריסת מודלים עסקיים: עלויות התמיכה והאופרציה (Operation) יורדות כי ה-Agent מתקן תקלות לבד, מה שחותך את ההכנסות של חברות כמו Red Hat. עומס על ה-Maintainers: קוד מג'ונרט על ידי Agents נראה מעולה ומתועד היטב, אבל לא תמיד נכון ארכיטקטונית או לוגית. גישות התמודדות: חלק דורשים לקבל את ה-Prompt (הכוונה) ולא את הקוד עצמו, בעוד שאחרים (כמו יוצר שפת Zig) אוסרים לחלוטין גישה של AI לפרויקט. [15:15] החזון האופטימי: שיווק לסוכנים (GEO) מעבר מ-SEO ל-GEO (Generative Engine Optimization): סוכני AI הם הלקוחות החדשים. איך Agent בוחר כלים? לפי איכות הקוד, הפופולריות שלו ב-GitHub, ובעיקר לפי התיעוד. קוד פתוח הופך לכלי שיווקי קריטי (Open Core) כדי שהסוכנים יוכלו למצוא, להבין ולהמליץ על המוצר. מודלים היברידיים ו-Freemium: מוצרים (כמו Postits) מציעים גישה ללא חומת תשלום (Paywall) בשלבים הראשונים, מה שמאפשר ל-Agents לעבוד איתם בקלות דרך API (Headless SaaS), ואפילו לבצע רכישות בעצמם בהמשך דרך Stripe. [30:29] שובו של ה-CLI ומגבלות ה-MCP הדיבייט סביב MCP (Model Context Protocol): הפרוטוקול כבד, "זולל" טוקנים (Token hungry) עבור הקונטקסט, ודורש תחזוקה של שרתים נוספים. למה Agents כל כך אוהבים CLI (שורת פקודה)? גישה ישירה לאקוסיסטם המקומי והרשאות (כמו Kubernetes או סביבות ענן) בלי לחשוף מפתחות לשירות חיצוני. יכולת לבצע מניפולציות מורכבות בצד הלקוח (Chaining, Grep, Sed) מבלי לשנות קוד ב-Backend, מה שהופך את המודלים לאנשי DevOps מעולים. [36:17] רישיונות קוד פתוח וה"נשמה" של המוצר האתגר באכיפת רישיונות (כמו GPL) בעולם שבו קשה להוכיח על איזה קוד המודל התאמן ואם בוצעה העתקה. הבדל חשוב בטרמינולוגיה: מודלים של "Open Weights" לעומת מודלים שה-Training Data שלהם באמת פתוח. תוכנה כיצירת אומנות מול קומודיטי (Commodity): האם קוד מג'ונרט יכול להחליף את החזון וה"נשמה" (Soul) של מפתחים בולטים? ההשוואה לעולם המוזיקה מדגישה שמשתמשים הולכים אחרי האומן והחזון, לא רק אחרי הקוד היבש. [50:25] רגולציה ומודלי Open Weights אורי מעלה נקודה מעניינת על החסימה של מודל Fable 5 / Mytos 5 (של Anthropic) למשתמשים מחוץ לארה"ב על ידי הממשל האמריקאי. ההשפעה של רגולציה: ה"תקרת זכוכית" הזו עלולה לפגוע בחברות המסחריות האמריקאיות בטווח הקצר, ודווקא לדחוף קדימה מודלים פתוחים (Open Weights) סיניים או אירופאים שאינם כפופים לאותן מגבלות. האזנה נעימה!

  • May 7 · length unknown

    515 - Bumpers 91

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

  • May 6 · length unknown

    514 - Attack Analytics

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

  • April 30 · length unknown

    513 - Hebrew PDF at AI21Labs

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

  • February 24 · length unknown

    512 - Carburetor 40

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

  • January 25 · length unknown

    511 AI Protection and Governance with Nimrod from BigID

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

  • January 15 · length unknown

    510 Federated Learning with Tal from Rhino

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

  • January 11 · length unknown

    509 Bumpers 90

    רק מספר 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 - תודה! קישור לקובץ

  • January 3 · length unknown

    508 Controlled image generation with Misha from Bria.ai

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

  • Dec 19, 2025 · length unknown

    507 Catburetor 39 Google and AI

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

  • Dec 11, 2025 · length unknown

    506 ML Infra with Itai from MIND

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

  • Nov 22, 2025 · length unknown

    505 Bumpers 89

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

  • Nov 17, 2025 · length unknown

    504 Functional programming with Daniel Beskin

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

  • Oct 25, 2025 · length unknown

    503 Bumpers 88

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

  • Aug 31, 2025 · length unknown

    502 - Carborator 39

    פרק מספר 502 של רברס עם פלטפורמה - קרבורטור מספר 39, שהוקלט ב-19 באוגוסט 2025. אורי ורן מארחים את נתי שלום לשיחה על מיתוסים, מציאות והדרך ל-AGI. 🎗️ (רן) שלום נתי, אז איזה כיף שאתה פה איתנו, שוב. נתי הוא איש תשתיות ותמיד רואה למרחוק את כל הטרנדים. והיום הטרנד המדובר . . . ברגע שכל ה-AI הזה פרץ לחיינו, הבטחתי לאורי שלא נדבר על זה יותר בפודקאסט, ומאז אנחנו מדברים רק על זה.(אורי) רק על זה . . . . 01:00 על AI, יעילות ומכבסות מילים (רן) אז יאללה - בואו נדבר על AI. נתי - כמה מילים ו-Let's go. (נתי) אני חושב שמה שרצינו לדבר עליו היום זה מיתוס לעומת מציאות, סביב הנושא של Productivity, של Development, של Code. (רן) מיתוס זה מיוונית? דרך אגב, המילה? מאיפה זה מגיע?(אורי) זו בירה יוונית . . . (רן) מאיפה המילה?(אורי) מיתולוגיה . . . [ד”ש ל-Stephen Fry] (נתי) אז באמת יש הרבה Hype סביב זה, ויש כל מיני ציפיות - ואני, בתור חברה שמדברת על זה לא מעט - אתה שומע את הדרג הניהולי אז המנהלים מצפים שאפשר יהיה לחתוך בכוח אדם, בגלל שעכשיו צריך פחות מפתחים. ואנחנו גם שומעים על הצהרות של חברות ציבוריות כמו Microsoft, מן הסתם עם Copilot, ו-McKinsey וכל מיני דברים כאלה. זורקים הרבה מספרים לאוויר, שמראים שבאמצעות AI הולכים באמת לשפר את הפרודקטיביות. כשבדרך כלל המילה . . . הצד השני של “Productivity” זה “פחות אנשים” . . . (אורי) . . . לא בהכרח . . . (נתי) . . . . בדרך כלל, בטח בגלים הראשונים של הטרנד, זו בדרך כלל הציפייה . . . . הציפייה היא “Efficiency” = “פחות אנשים”. (רן) כן, אפילו Satya Nadella הצהיר שניתק הקשר בין כמות כוח האדם לבין ה-Revenue או ההצלחה העסקית - ויום לאחר מכן . . . אולי לא היום, אבל מייד לאחר פרסום דוחות מאוד מאוד מוצלחים של החברה, אלפי עובדים פוטרו בחברה . . . . (נתי) אז אני חושב שגם מן הסתם הרבה יודעים את זה גם, אבל זו קצת מילה מכובסת לזה שפשוט רוצים להתייעל ולקצץ, כי צברו הרבה מאוד שומנים בתקופה שבה, בטח אחרי הקורונה, היו הרבה שומנים שנצברו בהרבה מאוד חברות ועוד לא ניקו אותם. אז משתמשים בזה כתירוץ מאוד טוב להסביר לבורסה למה עושים את זה, ואז נראה לא כמשהו שעושים רק בשביל לפגוע באנשים, אלא עושים את זה כי “החברה הולכת ל-AI”. זה הרבה יותר נכון להגיד את זה מאשר להגיד “אני מייעל את זה כי היו לי הרבה שומנים” . . . . (רן) יחד עם זאת, ציניות בצד - יש דברים בגו. (נתי) כן . . . כן ולא, אני חושב שזו התשובה הנכונה. אני חושב שהצד ש... (אורי) . . . כשאומרים “כן ולא”, זה אומר... (נתי) הכן יותר חשוב מהלא . . . (אורי) . . . . לא - מתכוונים להגיד “לא, אבל...” (נתי) אז זהו, אז אני אגיד שאני, ממרום גילי, מסתכל על זה טיפה אחרת. ואני מנסה גם לראות ב-Retrospect מה קרה בעולם ה-DevOps, למשל, כשאמרו דברים מאוד דומים. זה “ייתר את כל אנשי ה-IT”, והיתה כתבה, אני חושב, אז, בזמנו, מאוד מפורסמת - “The End of IT”, כשהתחיל ה-Cloud. זאת אומרת, בוא נגיד - גדלנו ועברנו גלים כאלה שבהם ההבטחה לכאורה נראית כאילו היא מייתרת משהו אחר, אבל בעצם היא ייצרה הרבה יותר מקומות עבודה והרבה יותר הזדמנויות. ואני אתחיל מהנימה האישית, זאת אומרת - בהחלט החיים שלי בעולם ה-AI הם נראים אחרת - אני מדבר על חיי היום-יום, אני לא מדבר אפילו על העבודה - הם שונים לגמרי מ-Pre-AI בכמעט כל דבר שאני עושה. בין אם זה בכתיבת תוכניות, בין אם זה כתיבת בלוגים, בין אם זה ביצירת תוכן, בעבודה עם אנשים . . . כמעט כל דבר השתנה - בכל חזית. ומהבחינה הזאת, אני חושב שה-AI מייעל הרבה מאוד דברים - אבל הוא גם מאפשר לך לעשות דברים שלא עשית בעבר. והיום אני יכול להגיד לבן שלי, שהוא בכלל לא מתכנת והוא למד כלכלה ושמאות, לכתוב Agent-ים, ולהתחיל לחשוב על סוכנים ולהתחיל לחשוב על איך זה . . . ואותו דבר הבת שלי, שבכלל למדה אמנות, והיא עכשיו כותבים סוכנים בשביל לעשות לימוד. אני מלווה סטארטאפ אחר שמתעסק בעולם הלימוד - ומדבר על איך אנחנו בעצם פותרים בעיה של Knowledge Transfer. שזה מקומות שבהם באמת נהיות טריטוריות חדשות שנוצרות . . . של לעשות Training, למשל, שזה Overhead יחסית גדול וזה Overkill ל-Knowledge Transfer, אז הרבה פעמים Knowledge Transfer היה מין תחום אפור כזה שאף אחד לא התעסק איתו אבל ברגע שאתה יכול לשים Agent, שיכול לקחת חומרים כאלה ולעשות מזה משהו שהוא נראה כמו Training, אבל עם Effort הרבה יותר קטן, אז זה פותר את כל אלה שצריכים את ה Knowledge Transfer אבל לא היה שווה להם להשקיע ב-Training. זה קהל הרבה יותר גדול. עכשיו, תחשוב על כמעט כל גזרה בתעשייה שתלך אליה - אתה תמצא את ה-Traditional, שזה כאילו “בוא ניקח את ה-Business הקיים ונעשה לו אוטומציה באמצעות AI ואז אני אשפר פרודקטיביות”. לצידו, אתה תמצא הרבה מאוד מקומות שעצם הורדת החסמי-כניסה, פותח שווקים שבכלל לא היו. וזה נכון לנדל״ן, וזה נכון לכלכלה, וזה נכון לכמעט כל תחום בחיים. אז לכן אני חושב שכשאמרתי “כן ולא” - מי שלא יתאים את עצמו לעולם הזה, אז כן, הוא ימצא את עצמו מתייתר. ומי שכן יתאים את עצמו, ימצא הרבה יותר הזדמנויות פה. ויהיו הרבה יותר הזדמנויות - חד משמעית. (אורי) אז בואו נשאל, שנייה - איפה זה פוגש את המפתחים? (נתי) אז המפתחים זו הדוגמה הקלאסית, כי התחלנו את התחום הזה של Copilot וכל הדברים, אבל בזה שזה באמת עושה הרבה מאוד מהעבודה של המפתחים. אני חושב שיותר ויותר מבינים שזה הופך את העבודה של המפתחים ליותר מעניינת ויותר יעילה, אני חושב שזה באזורים מסוימים. ויש אזורים שגם זה לא נמצא שם. אני אתחיל ממשהו, משפט ששמעתי מאחד האנשים שאנחנו עובדים איתו, Lee Twito מ-LangTalks - שבסופו של דבר צריך להבין שאנחנו עובדים מול מודל שפה, וזה מה שהוא נועד לעשות, הוא נועד לעבוד על שפה . . . ובגלל שהוא נועד לעבוד על שפה, הוא יודע לעשות Prediction למילה הבאה, וזה ה-Core Technology מאחורי הדבר הזה, זה לא השתנה. השימוש בשפה השתנה - ובעצם תוכנה היא שפה. והאפליקציה שלקחו מהדבר הזה זה בעצם להגיד, אוקיי, אם יש לי שפה גם מובנית - בשונה מאנגלית או כאלה דברים, שהיא פחות Structured, ויש לה הרבה מאוד Exceptions to the rule, מה שנקרא בתוכנה אני יכול להריץ קומפילציה (Compile), אני יכול לבדוק את זה - לכן אני יכול להשתמש במודל שפה לייצר קוד. עכשיו, מה זה קוד? זה בעצם אוטומציה . . . אני יכול לקחת ולייצר דרך זה קוד שעושה גם אוטומציה. ואז האפליקציה שיכלנו לקחת . . . וההקשר הזה פתאום נראה מאוד מפוצץ. אבל כמו שפה, הוא טוב כמו ה-Data שאתה מכניס אליו, “Garbage-In-Garbage-Out“, מה שנקרא. ולכן צריך גם להבין את המגבלות של הדבר הזה - זה לא שאתה יכול לזרוק לו Prompt-ים ופתאום ייצא לך UI ואפליקציות וכאלה דברים . . . ואז אתה מוצא את עצמך לומד בעצם לפתח שפה אחרת - שהיא לא בדיוק אנגלית, היא גם לא בדיוק קוד. יש לי שפת ביניים כזאת, שהיא בעצם מאוד מאוד Structured אתה צריך להיות מאוד Detailed, אתה צריך להגדיר את זה בצורה מאוד מדויקת. לוקח לא מעט זמן למצוא את הניואנסים האלה ואת השפה הזאת, ואיך נכון לעשות את זה לכל מיני אזורים. ולוקח לא מעט זמן לדייק אותה. אז א', לוקח לא מעט זמן להביא את עצמך למצב שזה פרודקטיבי ובאמת מייצר לך את התוצרים הנכונים. זה יותר קל במקומות שהם חוזרים על עצמם, שהם Repetitive Code או Boilerplate, כמו שזה נקרא. ב-Enterprise Software זה כמעט אפילו הייתי אומר מייצר “ערך שלילי” בהרבה מאוד מקומות בגלל שיש הרבה מאוד היבטים של אינטגרציה, בגלל שזה פחות Repetitive, בגלל שיש הרבה Legacy. אז כשמבינים את זה ומתאימים את הציפיות לזה, אז אפשר למצוא את המקומות שבהם זה כן פרודקטיבי, ואפשר למצוא את המקומות שזה לא פרודקטיבי. ואפשר להבין שזה לא קסם, שיש פה באמת איזה מנוע אינטליגנציה שאתה יכול לזרוק עליו מה שאתה רוצה והוא יעביר לך מה שאתה רוצה. 09:13 הדבר הכי פרודקטיבי בקוד זה למחוק / המחקר של METR (רן) רגע, אבל נתי - אתה הגעת למסקנה בלי שעשינו את הדרך . . . בוא רגע נעשה את הדרך, כי הדרך חשובה והיא מלמדת. (נתי) כן, בהחלט. (רן) אז לפני חודש-חודשיים, משהו כזה, מכון מחקר שנקרא METR פרסם מחקר שאני חושב שתפס את העיניים של הרבה. אני קראתי אותו, אתה קראת אותו. גם כתבת עליו בלוג פוסט [The AI Paradox: Why “Efficiency” Won’t Just Mean Less Headcount — And What It Means For Your Tech Career], אני גם קצת דיברתי עליו בפרק הקודם של הפודקאסט שבקרוב יתפרסם [אה, זה כבר קרה - 501 Bumpers 87].והכותרת שלו היא שנראה לנו שמודלי השפה, או שכלי הקידוד - במקרה הזה יש לנו עכשיו בעיקר ב-Cursor - עוזרים לנו להיות יותר פרודוקטיביים, אבל במציאות זה בדיוק הפוך. (נתי) כן, אז קודם כל, METR זה ארגון - זה Model Evaluation and Threat Research, אם אני זוכר נכון - שזה בעצם התחיל מהשאלה של מה זה פרודקטיביות? איך מודדים פרודקטיביות? ואני חושב שזה החלק הכי מעניין ב-Research הזה, אני חושב שהם הגיעו לאיזושהי נוסחה הרבה יותר מדויקת. כי הרבה פעמים, כשאמרתי את המספרים ש-Copilot זרקו ו -Microsoft זרקו וכאלה דברים - מבחינתם פרודקטיביות היא “כמה קוד ייצרתי” - שורות קוד שייצרתי באמצעות AI. (רן) עכשיו, אנחנו יודעים שהדבר הכי פרודקטיבי בקוד זה למחוק . . . (נתי) בדיוק . . . אז אני חושב שכל מי שקצת התנסה בזה יודע שזה די בולשיט, סליחה על המילה . . . והם באו ובעצם ייצרו מתודולוגיה הרבה יותר מדויקת - הם לקחו 16 מפתחים מנוסים בעולמות של Open Source הם נתנו להם משימות רנדומליות - זאת אומרת חלק עם AI, חלק בלי AI, הם השתמשו ב-Cursor, בכלים שהם לכאורה נחשבים ל-Benchmark של התעשייה ב-Code Generation. וצילמו אותם במשך יום שלם - והראו באמת את הניסיון של כל אחד מהם כשהם נתנו להם את המשימות הרנדומליות האלה ולראות מה כל אחד מסוגל לייצר. ושאלו אותם בסוף “מה הרגשתם? כמה זה עזר לכם כשהייתם עם AI?” . . . . (רן) . . . שאלו אותם לפני “בכמה זמן אתם מעריכים את המשימה?” ואחר כך, בסוף המשימה, “האם עבדתם יותר מהר או פחות מהר?” - כשהשתמשתם ב-Cursor לצורך העניין. (נתי) כן. אז קודם כל זה היה 246, בערך, משימות שהם קיבלו שם, שכמו שאמרתי הם חילקו אותן רנדומלית. וה-Perception לצורך העניין היה שהם הרגישו שהם שיפרו את היעילות שלהם ב-20% - והתוצאה הראתה כמעט את התמונה ההפוכה, שזה דווקא האט אותם. (רן) כלומר, הם הרגישו - הם אמרו, הם דיווחו - “עשיתי את המשימה שלי 20% יותר מהר”, כשלמעשה, כשמדדו את הזמן, ראו שהם עשו אותה ב-19% יותר לאט. (נתי) יותר לאט מהמשימות ללא AI, כן. (רן) . . . זאת אומרת, את המשימות חילקו חצי-חצי - חצי עם AI, חצי בלי - והסתכלו . . . . כמובן, חלוקה אקראית. (נתי) בדיוק - ואני מוסיף לזה שאם עכשיו אתה תבדוק, למשל, שזה עוד טיפה יותר מורכב אפילו מלבדוק פרודקטיביות, למעשה, מדידה אבסולוטית של Velocity, למשל, הייתה לראות באמת כמה קוד מיוצר על ידי AI, ואיך זה השפיע על ה-Production. זאת אומרת, בסוף כמה Feature-ים יצאו, והאם ה-Quality הלך והידרדר. האם היה Regression, לצורך העניין, או לא היה Regression? האם נוצרו כתוצאה מזה בעיית Security? כמה מהקוד שכתבת נזרק, לעומת כמה מזה באמת השתמשת בו. אני חושב שחסרים עדיין היכולת באמת למדוד את זה בצורה אפקטיבית, כדי באמת לענות על השאלה הזאת, אגב, בלי קשר ל-AI . . . (אורי) דרך Failure של Test-ים . . . . אם יש לך כיסוי טוב . . . (נתי) לא רק, זה לא רק זה . . . גם Failure של Test-ים. אז יש DORA Metrics, שכאילו לכאורה מייצרים איזה מדד מסוים של איך מודדים פרודקטיביות בעולמות האלה. אבל באמת היכולת זה מה שאמרתי. זאת אומרת, אם הייתה אפשרות היום למדוד -איזה רעיון לסטארטאפ -פרודקטיביות, אז ככה הייתי מודד פרודקטיביות. הייתי מודד בסוף איך זה משפיע על השורה התחתונה. (אורי) זה רעיון לסדרת פודקאסטים אחרת, שאפשר לדבר עליו, על איך מודדים פרודקטיביות בתוכנה . . . (נתי) אבל אגב, בהקשר הזה - זה לכאורה, אנחנו נמצאים כבר הרבה מאוד זמן בתעשייה, היית מצפה שיהיה כלים קצת יותר... (אורי) למה אתה אומר “לכאורה”? (נתי) לא יודע, סתם . . . . אני משאיר את הספק למי שלא רואה אותנו בפודקאסט הזה (רן) “מרחב הכחשה” . . . (נתי) . . . “מרחב הכחשה”, כן - אנחנו עדיין צעירים בנפשנו . . . . אז אני חושב שהפער שאני רואה זה באמת דווקא בצד של המנהלים. זאת אומרת, הם הרבה פעמים נשענים על מתווכים. והמתווכים - א': יודעים שהם נמדדים על פרודקטיביות, אז האינטרס שלהם זה להגיד “באמת השגנו עכשיו הרבה מאוד פרודקטיביות!”. ואיפשהו אתה, בתור מי שנמצא בתוך הפעילות הזאת, אומר “רגע, אבל המחוג כמעט ולא זז” . . . . כאילו, לא הרגשתי שכמות הFeature-ים שאנחנו מייצרים, או ה-Quality, השתפר כזה משמעותית. הוא בסדר - הוא זז ימינה, שמאלה - אבל לא ראיתי קפיצה כזאת משמעותית עדיין. וזה, אני חושב, הפער שאותי לפחות הקפיץ וגם לכתוב את זה. זאת אומרת, המון רעש, המון Use Cases, המון האקאתונים, המון זה . . . מראים המון המון רעש - ואתה אומר, רגע, אבל בסוף ה-Release יוצא כמעט באותו קצב, והFeature-ים יוצאים כמעט באותו קצב, אז משהו פה לא הסתדר . . . (רן) אז פה אני קצת מתחבר לביקורת על המאמר . . . אז קודם כל, אני מסכים שלמדוד כמה שורות קוד נפלטות בדקה זה לא מטריקה טובה - וקשה למדוד מטריקה של פרודקטיביות.כלומר, גם עם DORA ועם אחרים, עדיין קשה מאוד למדוד Business Value.מה שעשו פה במחקר הזה, זה להסתכל כמה זמן לוקח להשלים איזשהו Feature, או לתקן איזשהו Bug, או להוסיף עוד איזשהו Feature. הסתכלו על דברים יחסית קטנים ומדידים.ופה אני חייב להגיד שאני חושב שהם לא שאלו את השאלה הנכונה. זאת אומרת, זה יותר טוב משורות קוד, [אבל] זה עדיין לא זה.ואני חושב שגם כתבת על זה קצת בפוסט. למעשה, אנחנו יודעים שכמפתחי תוכנה, הזמן שבו אתה כותב את התוכנה הוא כאין וכאפס לעומת כל הנגזרות של כל מה שכתבת. כלומר, תחזוקה, תיקון באגים . . . אני עדיין לא מדבר על Business Value שאותו הרבה יותר קשה לכמת, אבל ברור שזה בסופו של דבר “הגביע הקדוש”.זאת אומרת, הזמן שבו באמת השלמת את המשימה, נגיד הזמן שלקח לך לכתוב את הFeature - הוא כנראה עשירית או פחות מתוך סך כל הזמן שמושקע אחר כך לאורך זמן באותו Feature.ומה שלמעשה כן צריך למדוד - וזה מורכב - אבל מה שכן צריך למדוד זה למעשה איך לאורך זמן, העבודה, לצורך העניין עם Cursor או עם כלים אחרים, איך לאורך זמן העבודה הזאת משפיעה על כמות הזמן או הפרודוקטיביות בתחזוקה של אותו כלי או המשך תחזוקה של אותו Bug או של אותו Feature. 16:23 ה-Bottleneck-ים ילכו לשני הצדדים (אורי) אתה מסתכל על זה - תסלחו לי, אתם מסתכלים על זה בעיניים של מהנדסים יותר מדי . . . ואני מנסה להסתכל פה על התמונה הרחבה יותר.אני חושב שבסוף, כשאתה מנסה להסתכל על פרודוקטיביות - זה Impact Over Time, זה לא . . . זה Business Impact Over Time. לא משנה אם אתה מתעסק בקוד שמתעסק בתחזוקה או יציבות או לא משנה - יש איזושהי מטריקה Business-ית או מטריקה מסוימת שאתה צריך להזיז, והשאלה אם אתה מצליח להזיז אותה יותר Over Time.עכשיו פה, בסוף, אני תמיד אומר ש-Execution - זה ש-95% מה-Execution זה קבלת החלטות. לעשות את העבודה, זה כמו שרן אמר - זה כלום.עכשיו, הוא מקבל הרבה מאוד החלטות - ה-AI - באיך שהוא כותב את התוכנה. עכשיו, ה-Bottleneck-ים הם . . . בואו נניח שהכתיבה, בסדר? הכתיבה “השפתית” - היא תהיה הרבה יותר מהירה. גם בתוכה יש החלטות, אבל הוא עושה אותן. אז ה-Bottleneck-ים ילכו הצידה, לשני מקומות אחרים. אחד זה איך אני מקבל את הדרישות מה-Market, מעבד אותן לכדי Spec או דרישות שאני יכול להעביר אותן ל-Prompt. מהצד השני, איך אני עושה Go To Market, כי לא נוצר Business Value עד שלא לקחת את ה-Feature ל-Market.אז בעולם שהמפתחים יהיו הרבה יותר מהירים, וההחלטות של הפיתוח עצמו יילקחו על ידי המכונה, ה-Bottleneck-ים ילכו לשני הצדדים האלה . . . (נתי) אני אקח את זה לקיצון, את מה שאתה אומר. אני חושב שאתה אומר משהו מאוד נכון. נניח שאנחנו שמים את המספר “0” על זמן כתיבת קוד, ואנחנו מנתחים עכשיו כמה זמן לוקח לנו להוציא Release, למשל, של מוצר, כשזמן כתיבת קוד הוא לצורך העניין “0”. אנחנו נראה שהזמן של הוצאת Release לא יהיה 0, הוא יהיה אפילו קרוב יחסית לזמן שלוקח לנו להוציא Release כי הרבה מה-Thread-ים זה בכלל מה צריך להיות ב-Release. אחרי זה יש את כל ה-Debugging ואת כל הטסטים שצריכים לעשות וכל ה-Retrospect והדברים האלה, וגם... (אורי) מ-Debugging וכו’ אני לא מוטרד - כי פעם שמערכת מכוסה טוב, עם Test-ים ועם Pipeline טוב, מערכת AI טובה, תדע ללמוד מה המערכת הזאת מצפה ממנה. (נתי) זה בהנחה שלא תצטרך לעשות הרבה Reject-ים ותיקונים, כן. זאת אומרת, נוצר לך הרבה קוד - עכשיו השאלה האם כל הקוד הזה נכנס אוטומטית ל-Production, או שעכשיו הוא נכנס ל-Production. (אורי) לא . . . הוא נכנס ל-Pipeline, נכון? (נתי) . . . נכנס ל-Pipeline - ואז יש לך Reject-ים. עכשיו אתה מבין שצריך לתקן את ה-Reject-ים. (אורי) . . . מה-Reject-ים האלה המערכת לומדת . . . אמורה ללמוד . . . (נתי) כן . . . עד גבול מסוים. אז אני חושב ששוב פעם, כשאמרתי את מה שאמרתי לגבי ה-Perception, ונניח כל פעם הייתי שומע “שיפרנו את הפרודקטיביות ב-30%!”, והייתי מסתכל בסוף, הייתי אומר, אוקיי - אם יצא ה-Release שלוש פעמים, עכשיו צריך לרוץ לצורך העניין שליש פחות, וכמות ה-Feature-ים שיצאה צריכה להיות שליש יותר. וזה לא . . . (אורי) כשאתה אומר “כמות ה-Feature-ים צריכה להיות שליש יותר” - בום, ה-Bottleneck נדחף לצדדים. כי,לא יודע מה, לצורך העניין, אנשי ה-Product היו צריכים להכניס פי שלושה Feature-ים, כי עכשיו יש מפתחים ש... (נתי) כן, אז הייתי אומר שזה צריך להיות יותר Feature-ים, באותו זמן. משהו צריך להיות . . . .ה- 30% צריך להיות מתורגם בסוף, בשורה התחתונה, לקצב. או קצב Release יותר מהיר, או יותר Feature-ים בפחות זמן, או משהו מהדבר הזה. ואתה רואה שבשורה התחתונה, המספר הזה לא זז כמעט באזורים האלה. (אורי) נתי, ניהלת ארגוני פיתוח. קרו לך פעם שני הדברים האלה? שמפתחים אומרים . . . כאילו, יושבים Idle ואומרים “אין מה לעשות, אנחנו עושים תחזוקה כל הזמן, כי לא מגיעים Feature-ים”. “אנחנו מטפלים בתשתיות, כי . . . “. זה מצד אחד. מצד שני, האם קרה לך פעם - לי קרה - שבא Business ואומר “רגע, רגע, רגע, תעצרו. אנחנו לא יכולים ללכת ל-Market עם כמות הFeature-ים שאתם מוציאים עליהם” . . . שני הדברים האלה, יצא לי שהם קרו, אוקיי? לא תמיד הפיתוח הוא ה-Bottleneck. עכשיו, זה היה קורה לפעמים . . . (נתי) אני חושב שאנחנו אומרים אותו דבר. אנחנו אומרים שכן, גם אם אתה מעלה את הפרודקטיביות, זאת אומרת, לצורך עניין, מוריד אפילו את הזמן שלוקח לכתוב קוד לאפס, הזמן שלוקח בסוף להוציא מוצר לשוק ולתת ערך ללקוח, כולל בתוכו הרבה מאוד מרכיבים שהם כמעט . . . הם מושפעים, אבל יחסית מעט. ואז בתוך כל הבליל הזה, אתה תראה Margin יותר נמוך של פרודקטיביות, כי ה-Overhead-ים האלה לא משתנים. (אורי) נכון. 22:09 לא נהיו פחות כאלה - הם פשוט השתנו (רן) הרשו לי לעשות אובזרבציה (Observation) - קודם כל, אנחנו פה ספציפית מדברים על מחקר שמדבר על קידוד,אבל אנחנו יודעים שה-AI נכנס בכל צווארי-הבקבוק, לא רק בקידוד, אוקיי? זאת אומרת, זה נכון, צוואר הבקבוק אולי עובר, אבל יש AI גם ב-Product, גם ב-Market Research, גם בהרבה מקומות אחרים. יכול להיות שברמות בגרות שונות, אבל ברור לכולם שכן, זאת אומרת, צוואר הבקבוק יזוז - וגם שם אנחנו ננסה לפתוח אותו בכלים כאלה ואחרים, זה אחד. אבל אני חושב שדבר נוסף מעניין שיש פה במחקר . . . (אורי) אני רק רוצה להוסיף על זה - איך זה ישפיע על מהו “המפתח”? יש מצב שגם המפתח, כדי להיות באמת פרודקטיבי, הוא יצטרך לזוז לקצוות האלה . . . (רן) . . . הוא יצטרך להיות Product . . .(אורי) . . . הוא יצטרך להיות כנראה יותר Product, או כנראה יותר מה שנקרא Product Marketing. (רן) כן, אני חושב שגם דיברנו על זה באחד הפרקים [פה - 499 FE Containerization with Myops], על היחס בין מספר אנשי המוצר למספר מפתחים בחברה, שאולי פעם זה היה נגיד אחד לעשר או אחד לחמש, וזה כנראה הולך להשתנות. יהיו יותר אנשי Product - או יותר מפתחים שהם גם אנשי Product.(אורי) ואני חושב שזה קצת מה שקרה לאנשי ה-IT במהפכת ה-DevOps, כן?(אורי) . . . לא נהיו פחות כאלה - הם פשוט השתנו. (נתי) נכון, זה בדיוק מה שאני אומר. אני אומר שא' - לגבי השאלה של האם זה ייתר מפתחים? חד משמעית לא. אני חושב שזה אפילו, בעיניי, יגדיל אפילו את הצורך. הם פשוט יעשו דברים אחרים - הם יעשו Agent-ים, הם יפתחו הרבה מאוד כלים שהם כבר נותנים הרבה יותר Business Value. מפתח יוכל לעשות הרבה יותר, עבודה גם מעניינת. אני חושב שזה בהחלט גם מייצר הרבה מאוד עבודה לכאלה שהם לא מפתחים. כמו שהתחלתי לתאר, בהכנסה של אנשים שהם באים דווקא מעולם ה-Business. הייתי באיזשהו כנס שדיבר על זה באמת בקמפוס של Google, והם קראו לזה Founder Market Fit. זאת אומרת שבעצם בהינתן זה שהטכנולוגיה הופכת להיות יותר Commodity, הערך הופך להיות ההבנה של ה-Business והבנה של המשתמש הסופי ודברים מהסוג הזה. ולכן אתה רואה היום יזמים גם בסטארטאפים שבאים מרקע בנדל”ן, מרקע בפיננסים, מרקע בכל מיני תחומים עסקיים, שלא דווקא באו מרקע פיתוחי. והם בעצם הופכים להיות היזמים בעולמות האלה. ולכן אני חושב שזה באמת מייצר שינוי מאוד דרמטי - למה אנחנו קוראים “פיתוח”, לאיך נראה פיתוח, למה המתודולוגיות - כמעט הכל משתנה. אבל אני חושב שבשורה התחתונה זה בסופו של דבר ייצר יותר הזדמנויות ויותר מקומות, ולא יקטין אותם. גם בגלל שזה פותח כל כך הרבה הזדמנויות וכל כך הרבה שווקים וכל כך הרבה אפליקציות אפשריות שלא היו יכולים לדמיין קודם, פשוט רשימה כמעט אינסופית של הזדמנויות שנפתחות, כמו שתיארתי עכשיו ב Knowledge Transfer, שלא היו קיימות קודם, בגלל חסמי-כניסה מאוד גבוהים. (אורי) נראה לי שדיברנו על זה בפרק עם רומה על עולם התעסוקה [497 AI-HR], ובאמת הוא אומר “לא יודע,אני רק מקבל הרבה יותר Openings של משרות” . . . 25:15 ביקורת / מדברים “מהנדסית” / צריך לדעת לנווט? (רן) בוא תרשה לי רגע לחזור לדבר “מהנדסית”, אורי, ונחזור רגע למחקר הזה [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity]. אני חושב שקודם כל אפשר . . . . דרך אגב, יש לי הרבה מאוד מחלוקות עם איך שהם עשו את המחקר ומה שהם עשו שם, גם מבחינת בחירת... (נתי) אנחנו נדבר על זה, נפתח . . . . (רן) כן, לא ניכנס להכל. קצת דיברתי על זה בפרק הקודם, שהקלטתי עם דותן ועם אלון [501 Bumpers 87], אבל בגדול, אחד זה אופן בחירת הפרויקטים, אופן בחירת המפתחים עצמם - שיש להם המון ניסיון בפרויקט, וזה לא תמיד המצב. זאת אומרת, זה מפתחים עם למעלה מ-5 שנות ניסיון עם ה-Codebase, ובהרבה מקרים זה פשוט לא המצב, זה לא Fair Play. מפתחים עם מעט מאוד ניסיון ב-AI . . . זאת אומרת, יש לדעתי לא מעט באגים במחקר עצמו.יחד עם זאת, אני חושב שכן - יש שם ממצאים מעניינים. זאת אומרת, לא לגמרי מבטל את התוצאות.ואחד הדברים המעניינים זה “אלמנט ההפתעה”, שהוא בעצם ה-Highlight. זאת אומרת, שהם באים ואומרים “אני חשבתי שזה יותר מהר, לא ידעתי שזה יותר לאט”.וזה לדעתי איזשהו Evidence לכך שאנחנו עדיין פשוט לא למדנו “לאלף את המפלצת”. כלומר, אנחנו לא מכירים מספיק טוב איך . . . . ואני חושב שבמקרה הזה זה מאוד בולט, כי זה מפתחים מאוד מנוסים - הם רק לא עבדו הרבה עם Cursor לפני זה. היה שם אחד שכן - והוא דווקא די דייק בהארכות הזמנים שלו, וגם עשה את העבודה שלו יותר מהר - והשאר לא. אז אני חושב שזה איזשהו Evidence לכך שאנחנו בעצם עוד לא למדנו לעבוד, או לפחות ה-15 - נשים בצד את האחד שכן - 15 מפתחים שהיו במחקר הזה, כנראה היו באיזושהי עקומת לימוד, ואולי גם השתפרו עם הזמן לאורך המחקר,ויכול להיות שאם היית חוזר - עם אותם 16 מפתחים - על אותו מחקר חודשיים אחרי זה, התוצאות היו אחרות. (נתי) כן, זו נקודה באמת חשובה. אמרתי קודם שבעצם מ”כתיבת קוד" זה הופך להיות ל”כתיבת שפה”. יש כאלה שיקראו לזה “Prompting” - אני לא אוהב את המילה “Prompt”, כי אני חושב שזה לא באמת... (רן) . . . Markdown Engineering . . . (נתי) כן, זה סוג של שפה שאתה צריך, Context Engineering. שזה בעצם שאתה כותב באנגלית - אבל בצורה שבה ה-Agent שלך, או מה שזה לא יהיה, יבין בדיוק מה אתה רוצה. (רן) . . . היום עניתי לירוסלב איך אני עשיתי איזשהו Command ל-Claude Code, והראיתי למישהו שעובד איתי איך כתבתי את זה. אז ככה: זה מתחיל ב-Markdown ואז אני כותב פונקציה ב-Python - בסדר, קוד, אבל ב-Python . . . - ואז המשיך ב-Markdown . . . והוא אומר לי “מה זה הקשקוש הזה?”, “למה אתה מערבב פה אנגלית ו-Python?“, ובכלל אין לך מימוש לפונקציות - אתה רק קורא להן בשם . . . (נתי) אז עכשיו הגענו למצב שכל מפתח מפתח שפה . . . (רן) . . . כן. אז אני אמרתי לו “אבל באמת, זה עובד . . . “ - אני לא צריך לממש את הפונקציה. אני קראתי לפונקציה בשם get version - והוא יודע איך לעשות את זה, אני לא צריך לממש את הפונקציה . . . (נתי) אז זה, אני חושב, באמת הדלתא הזאת שאתה מדבר עליה, שזה ה-Productivity שלא נמדד פה, שלוקח טיפה זמן ללמוד איך לעבוד עם הכלים האלה ולדבר איתם בשפה שהם יוכלו לייצר לך את מה שאתה רוצה ולהבין איך אתה מצמצם לו את דרגות-הטעות, כדי שהוא באמת... (רן) אז לוקח זמן גם “לאלף את החיה”, אבל גם אנחנו עצמנו צריכים ללמוד להתרגל אליה ולעבוד איתה. (נתי) לגמרי - ובמשימות שהן יותר, הייתי אומר שאתה כבר די Skilled עליהן, אז מן הסתם הערך יהיה יותר נמוך. במקומות שבהם אתה . . . למשל, אם אתה סטודנט, ועכשיו לומד ואתה צריך ללמוד - הערך יהיה מאוד גבוה, כי אתה תקבל הרבה מאוד, ולימוד הרבה יותר מהיר, לדברים שלא הכרת קודם. גם על זה, אתה יודע - נתנו לי את הדוגמה של Waze, שאמרו שזה לא באמת יעשה אקסלרציה (Accelerate) למפתחים שמתחילים וילמדו, כי הם פשוט ישכחו איך לנווט . . . כי מה ש-Waze עשה - זה לא באמת לימד אותך ניווט. הוא עשה לך את הניווט, ואתה לא יודע אפילו לאיפה נסעת, אם ישאלו אותך איפה היית . . . (אורי) . . . אתה כבר לא צריך ניווט. (נתי) אז אני חושב שבשלבים האלה שאנחנו נמצאים כרגע, זה עוד איפשהו באמצע. בגלל זה אני חושב שזה עוד לא מוחלט. אם אתה עושה Vibe Coding - זאת אומרת, אם אתה כותב אפליקציה בודדת למשתמש בודד שכותב עכשיו זה יכול להיות שכן. כי אני חושב ששם בהחלט כבר אפשר לראות את הטרנד הזה, שאתה יכול לכתוב Prompt-ים, לראות אפליקציה וכאלה דברים. אפליקציה ל-Scale, שצריכה להתמודד עם רגולציות וכאלה דברים - שם זה חד משמעית “לא שם” כרגע. (רן) אבל אני חושב שהשאלה שאורי העלה זו שאלה חשובה, והיא עולה בהרבה מאוד פורומים - האם אתה צריך לדעת שפת מכונה, עכשיו כשיש ++C? האם אתה צריך לדעת ++C כשיש Vibe Coding? (נתי) לזה התכוונתי. אני חושב שהעולם שבו אנחנו נוכל לכתוב רק ב-Vibe Coding ונסמוך לגמרי על ה-AI שיעשה לנו את כל העבודה - אני חושב שפשוט מבחינת בשלות של הכלים, אנחנו עוד לא שם. אני נתתי הרבה פעמים את הדוגמה הזאת בעולמות של אוטומציה. זאת אומרת, בוא נניח ש... (אורי) אני לא מוטרד מהבשלות. ה-Vibe Coding ב... לא יודע, הוא נמצא איתנו שנה-וחצי? שנתיים? הוא עשה דרך ש-Java לא עשתה ב-15 שנה. (נתי) . . . ועדיין - אם אני עכשיו אגיד לך שיש לך מערכת ניווט, שב-90% תביא אותך למקום, אבל יש לך נתיב אחד שיכול להיות שהיא תפספס בכל נסיעה שיהיה לך . . . . כמה אתה חושב אתה תוכל לסמוך על הכלי הזה? (אורי) מה שתיארת עכשיו זה כאילו דינמיקה של זוג נשוי נוסע באוטו, נכון? . . . . (נתי) אני מנסה להסביר שיש דברים - בטח מי שבא מעולמות של אוטומציה מכיר את זה - זאת אומרת, נניח שיש לי אוטומציה ל-90% מהכלים, אבל יש Man in the Loop, איך שזה נקרא, בנקודה אחת. ולקבל אישור עכשיו - אנחנו יודעים כמה זמן זה לוקח . . . אתה צריך למצוא אותו והוא לא זמין. זה יכול לקחת יום, זה יכול לקחת שעה, זה יכול לקחת שבוע לפעמים תלוי באיזה ארגון אתה נמצא ואיפה אתה נמצא, כי תלוי באיזה מחלקה הבן אדם הזה נמצא . . . אז 90% הגעתי לאוטומציה - אבל אני צריך את האישור הזה בשביל להעביר את הקוד הזה עכשיו, לצורך העניין, מ-Staging ל-Production. כמה זמן ייקח לי לעשות את זה? דקות? שעות? ימים? ברור שאני חזק כמו החוליה הכי חלשה, ולכן גם אם יש לי 90% - זה עדיין לא מספיק. אני חושב שכדי להגיע למקום שבו אני יכול לעשות Autonomous Driving באמת, אני צריך להגיע למצב שזה באמת 100% וזה ממש - המספר “100%” הוא מוחלט. בשנייה שאני צריך להחזיק את ההגה ולהסתכל ולוודא ולהיות ער ולהסתכל עליו - אני לא אגיע ל-Productivity המצופה לצורך העניין. זה לא באמת יהיה 90% Productivity ו-10% התערבות. (רן) יש לי חדשות טובות: אתה יודע, החיה ששורדת זה לא זאת שרצה הכי מהר. זה מספיק שיש אחת שרצה יותר לאט ממנה, נכון? (נתי) האמת שזה משפט שאמרו לי בבה”ד 1 - וזה היה כשהייתי שבוז ברמות-על והייתי עם מיואש שאני הולך לעוף מהקורס. אמרו לי “תסתכל על זה שלידך - ורק תהיה צעד אחד לפניו”. זהו. ואז הצלחתי לעבור את זה. (אורי) . . . . אבל אני גם רוצה להגיד על ה-Autonomous Driving - הייתי עכשיו בקליפורניה, וזה שם . . . זה שם. (נתי) אבל למה? - כי הם צמצמו את זה לערים מסוימות, הם שמו, לצורך העניין, מספיק מערכות בתוך הדבר הזה. אבל אני אומר שאם זה היה מגיע למצב שזה 90% מדויק - לא 100% מדויק - זה לא היה שם. עכשיו, לקח לזה שנים להגיע ל... שנים הם היו ב-90% . . . (רן) אני כופר, אני כופר! אז מה שאני רוצה להגיד - האריה והאיילה, כן? אתה לא צריך להיות הכי מהיר, מספיק שתהיה לא הכי איטי. אז אתה רק צריך שהמודלי-קידוד או Whatever - הם לא חייבים להיות 100, הם רק צריכים להיות יותר טובים מהמפתח הגרוע ביותר, או מהמפתח הממוצע, אוקיי? עכשיו תסמוך עלינו, המפתחים, שאנחנו נהיה יותר ויותר גרועים עם הזמן, שאנחנו נהיה יותר ויותר גרועים . . . (נתי) אנחנו נהיה טיפה חלוקים פה, ואני אסביר למה. אני אומר, זה הכל תלוי מה. נכון, באמת היה לי Asist ל-Driving והוא עזר מאוד לנהגים והוא עוזר לי בנהיגה כשאני נוהג . . . (אורי) . . . אבל זה Mission Criticality . . . (נתי) נכון, אבל אני אומר שהערך - הקפיצה בערך - היא לא פרופורציונלית. זה לא קפיצה מ-90% ל-100% - זו קפיצה כמעט מ-10% ל-100%, גם אם שיפרתי רק ב-10%. זאת אומרת, אם היה לי 90% אוטומציה ועדיין ב-10% מהפעמים הייתי צריך לבקר את המערכת, לעומת משהו שנותן לי באמת 100% ואני יודע לסמוך עליו ב-100%, שאני יכול אפילו לא לשים נהג באוטו - זה לא 10% שיפור, זה הרבה יותר. (רן) כן, ברור. היום, אם אני מריץ Claude או Cursor שכותב לי את הקוד, אני חייב-חייב- חייב לקרוא כל דבר שהוא כותב בביקורתיות - ולפעמים לפספס באגים. עכשיו, אם אני אדע שכל מה שהוא עושה זה “זהב”, זה 100%, ברור שזה משחרר אותי לחלוטין “ללכת לים ולהשתזף”, כן? אבל זה לא המצב. (נתי) בדיוק . . . אני חושב שאנחנו מתקרבים לשם, אני חושב שהכלים מתקרבים בקצב מאוד גבוה לשם. אני אומר את זה בעיקר לא כדי להגיד עכשיו “אין פרודקטיביות עם AI”, חס וחלילה. כל החיים שלי השתנו בטווח מאוד קצר, וכל הצורת העבודה שלי השתנתה. חד משמעית זה נכנס לכל התחומים, זה משפר פרודקטיביות. אני אומר את זה בעיקר כדי שנדע איך לנהל ציפיות - גם מול המנהלים שלנו, גם מול עצמנו, גם מול אחרים - איפה זה כן נותן, איפה זה לא נותן. ויש פער ציפיות די גדול, כי כשרואים אפילו בסטארטאפ עם Base44, אז אומרים “הנה - בנאדם אחד הצליח להרים סטארטאפ!”, אז כולם מנסים עכשיו להרים סטארטאפ כבנאדם אחד. זה היה מקרה מאוד מיוחד - אני לא בטוח כמה אפשר יהיה לשכפל אותו. אז יש הרבה פעמים את הנטייה לשמוע על המקרים המאוד מאוד מוצלחים האלה - ולא שומעים על כל המקרים הפחות מוצלחים. ואז יש הרבה תסכול, ויש הרבה ארגונים שאומרים “מה אנחנו לא עושים בסדר?! איפה אנחנו לא טובים?!” ואני חושב שניהול הציפיות הזה הוא סופר חשוב. (אורי) אני חייב להגיד - יש לי קהילה של CTOs ו-VP R&D [הזכרנו כאן 494 SoLead and RS], והשיח הזה כל הזמן קיים שם. אחד הדברים שהם מקבלים מזה, זה שתמיד יש להם רפרנס: הם יודעים . . .השיח הזה גורם להם להבין מה עבד, מה לא עבד. “מה, אני אני האידיוט היחידי, או אני... ?” (נתי) נכון, בדיוק. האמת שאני הגעתי לזה מתוך המסלול הזה, מתוך מסע כזה. שאמרתי “רגע, אנחנו משקיעים, משקיעים - אנחנו כאלה גרועים שאנחנו . . . שכולם מצליחים ואנחנו לא?” ואז הלכתי לאחד הכנסים, ואז פגשתי את לי, ותחלנו לדבר - ואז ראיתי מה הם עושים. אמרתי, אוקיי, הנה זה סטארטאפ, שזה מה שהוא עושה - אנשים שמתעסקים בזה כבר הרבה יותר זמן מאיתנו, חווים בעיות מאוד דומות לשלנו. “אופס, אנחנו לא עד כדי כך לא בסדר”. אבל אמרתי, אוקיי - אני יכול ללמוד מהם, אז בואו ניצמד, וככה, פחות או יותר... (רן) זה כמו התמונות האלה, של “Instagram vs. Reality” . . . . (נתי) לגמרי . . . . ומן הסתם, כמו בכל Hype, בהתחלה שומעים רק על המקרים - אני זוכר את זה גם מ-Terraform בזמנו - שומעים רק על הדברים החיוביים. וכולם מספרים כמה הם עשו “אוטומציה מפה להודעה חדשה” ובסוף הם מגלה שאוקיי, זה לא הקטע - הם חווים בעיות של חיים אמיתיים, ולא כולם כאלה. 36:19 לא רק Coding / הדרך ל-AGI (רן) אני חושב ששווה . . . .אני רציתי גם להזכיר פה איזושהי אנקדוטה: למה יש כל כך הרבה פוקוס על Coding? זאת אומרת, על למה LLM-ים טובים בקידוד ולמה משתמשים בהם בקידוד?אז סיבה אחת יכולה להיות כי זו שפה - והם טובים בשפה והנה אפליקציה פרקטית של שפה, אוקיי? (אורי) אבל אני חושב שלהבדיל משפה, קוד היא [שפה] מאוד מוגדרת - כי אחרת זה לא יתקמפל (Compile). (נתי) בדיוק, אני אומר “יש Complier”, זו תכונה סופר-משמעותית. (רן) אז סיבה אחת “כי זה קל". הסיבה השנייה: יש פה Business Value, נכון? כאילו - פרודוקטיביות. אולי זה עדיין Questionable, אולי עדיין לא מוכח במאה אחוז שיש פה Business Value - אבל התחושה היא שיהיה פה . . . (נתי) לא, אני חושב שיש שאלה לגבי זה שזה משפר פרודוקטיביות. ולגבי זה, שוב פעם, זה יותר ניהול ציפיות. זה שזה יכול גם לפעמים להיות יותר איטי - וזה בסדר. לפעמים זה חלק מעקומת לימוד, לפעמים זה לא ה-Use Case הנכון להפעיל את זה. (רן) כן, אבל רגע, אני רוצה לגעת בנקודה קצת יותר עמוקה. זאת אומרת, סבבה, אני חושב שיש פה Business Value, אני יודע שיש כאלה שלא [חושבים ככה]. אני חושב שעם הזמן אני מקווה שאני אוכיח [שאני] צודק, וגם אתה, נתי. זאת אומרת,אנחנו חושבים שלשם זה הולך.אבל אני חושב שיש פה עוד משהו. כלומר, אחת הסיבות שבאמת מודלי-שפה יודעים לקודד יותר טוב, וגם ידעו לקודד יותר טוב, היא שזאת הדרך ל-AGI. כלומר, בסופו של דבר, “ה-Grand Plan”, כמו שאני מבין אותה, של מפתחי ה-Artificial General Intelligence, זה לייצר מכונות שיודעות לכתוב בעצמן את הקוד שלהן, כדי שנגיע ל-Inflection Point - כדי שנגיע לנקודה שבה אנחנו יכולים לתת זינוק לכיוון ה-AGI.כלומר, אני לא יודע אם זו איזושהי תוכנית - אלוהית או שטנית - של מישהו בראש, אבל אני כן חושב שזה משהו שמדובר בחברות שבהן מפתחים AGI. כלומר, הכלי ל-AGI הולך להיות היכולת של LLM-ים לקודד.אז ככה שאולי במקרה כל הכוכבים התיישרו וזה שם - אבל אני חושב שזה לא מקרי שמנועי שפה הם טובים בקידוד, כי בין השאר לשם כך בונים אותם [פרק שלם על הרעיון הזה כאן - עושים טכנולוגיה - המתכנת מת. יחי האלגוריתם]. (נתי) לא, אני חושב שזה אפילו יותר מובנה מזה. אנחנו אומרים, AI בעצם נועד . . . זה Large Language Model - זה מודל שפה. שפת-תוכנה זה שפה - רק שהיתרונות שלה שהיא הרבה יותר מובנית, כמו שאמרנו, ולכן אני חושב שהמודלים האלה באמת נבנו כמעט אפילו לצורך הזה. והקפיצה הגדולה שאנחנו רואים זה בגלל שבאמת כשחיברנו שפה - שבסוף יכולה להפעיל טוסטרים ומכוניות ודברים כאלה - למודלי שפה, אז פתאום זה התחבר לעולם האמיתי, וזו הקפיצה הגדולה. ופתאום אנחנו יכולים “לגעת”, היות וכל העולם הוא היום Software-Driven, אנחנו יכולים “לנהל את העולם,” - וזה מתקרב לעולמות של ה-AGI. אני חושב שהקפיצה הבאה הגדולה - הייתי אומר שה-AGI הוא טיפה יותר רחוק - אם נגיע למקום שבו אנחנו עושים את הקפיצה מ-90 ל-100, אנחנו נראה פתאום אסימפטוטה הרבה יותר . . . קפיצה הרבה יותר גדולה, כמו שנתתי בדוגמאות של האוטומציה. ולשם אני חושב שזה ה-Milestone הבא שאפשר לשאוף אליו ולהסתכל עליו - וזה אני חושב שיקרה יותר מהר. וכמו שאמרתי - הקפיצה לא תהיה ב-10%. ברגע שנגיע לנקודה הזאת, זה יהיה לעבור מ-Assisted Driving ל-Autonomous Driving, זה יהיה ממש חוויה כזאת. (רן) אז תראה, אני לא יודע עד כמה התחזיות האלה מודויקות, אבל כן קראתי תחזיות על “יולי 2027”. כלומר, זה לא כל כך רחוק . . . עכשיו, אני חושב שכן יש פה הרבה מאוד מקום לביקורת על Variance בתחזית הזו, אבל אני לא משוכנע שזה כל כך רחוק.בכל אופן, מה שאני אומר זה שגם אם לא הייתה מוטיבציה, זאת אומרת גם, לצורך העניין, מודלי-שפה - היה יותר קל לפתח אותם לאנגלית ויותר קשה לפתח אותם ל-Python, עדיין יש מוטיבציה לפתח אותם ל-Python או ל-C, כי הם בעצמם - יש להם את היכולת לקדם את המדע, לא רק לקדם את ההנדסה אלא גם לקדם את המדע, לכיוון של AGI. אני חושב שזה אחד הקטליזטורים בפיתוח שלהם. (נתי) כן, אני חושב שאגב . . . טוב, זה נוגע בדבר אחר שאני מתעסק איתו שאמור להוביל לשם - זה הצורך גם בחשיבה אחרת, כשמתקרבים למקומות האלה. למשל, בעולמות של Autonomous SRE זה נקרא, כל הנושא של ניהול Datacenters וכאלה דברים. כשאני אומר “חשיבה אחרת” - אנחנו היום בבעיה שאנחנו מוצפים במידע. יש איזו סטטיסטיקה שאומרת שלכל ארגון יש בממוצע איזה 5-7 כלי Observability, וכל אחד עושה טיפה משהו אחר, ואנחנו מוצפים במידע. ואחת הבעיות זה עודף מידע, ומאוד קשה . . . זה Garbage In, Garbage Out. ואז זה דורש חשיבה אחרת, של איך אני בעצם מצמצם מידע, לא מגדיל מידע. אז זה הרבה פעמים נתפס - בטח למי שבא מעולמות של BI וכאלה דברים - זה נתפס כמעט כאנומליה. ואני חושב שהאתגר הרבה פעמים זה לזקק את המעט מידע שהוא באמת חשוב. כי AI עובד מאוד טוב, כמו שאמרנו, כשהמידע הוא דווקא הרבה יותר מדויק ומצומצם. וזו תפיסה שהיא, שוב פעם, למי שבא מעולמות BI למשל, זו תפיסה שאני רואה שמאוד קשה לעשות. (רן) כן. דרך אגב זה נכון גם מהפן של ה-Inference. כלומר, לזה קוראים Context Engineering. כלומר, תן לו את מה שהוא צריך, תן לו את כל מה שהוא צריך - אבל לא יותר מדי, כי אחרת זה Needle in the Haystack, אבל זה גם נכון ל-Training. כלומר, זה לא עוזר להגדיל את ה-Data Set של ה-Training אם זה זבל, אוקיי? זה מפריע.אם תוכל לצמצם ולתת מידע נקי וטוב, הוכח - זה אחד מה-Scaling Laws - הוכח שהמודל בסופו של דבר ייתן ביצועים יותר טובים. (נתי) ההוכחה הכי טובה זה המודלים הקטנים - אנחנו רואים היום במודלים קטנים שאפשר להגיע לדיוק יחסית גבוה, כשאתה יודע בדיוק לאיזה Use Case אתה מכוון אותם. והיום, אגב, גם GPT הוציאו מודל קטן Open Source שאתה יכול להתקין, וגם Google עכשיו יצאו עם משהו כזה, שאתה ממש יכול לעשות לו Fine-Tuning ולהגיע לתוצאות טובות כמו למודל גדול. שוב פעם - באזורים תחומים: אם אתה תוחם אותו לאזור מסוים, אתה יכול להגיע לדיוק מאוד גדול. (אורי) תכל'ס, זה מחכה אותנו - את האנשים - נכון? פעם שיש לך מומחה - לא נדבר על רן, כן, שהוא מומחה בהכל - אבל פעם שיש לך מומחה במשהו, אז הוא מומחה ב-Domain מסוים, והוא Trained ל-Domain הזה.וכשאתה מסתכל על צוות, או על . . . . הוא מורכב מכל מיני מומחים, ובסוף אתה מקבל איזושהי “בינה קולקטיבית”, שהיא הרבה יותר גנרית. (נתי) כן, אבל אני עכשיו אחבר את זה ל-AGI: החזון ב-AGI זה ש-AI ידבר עם AI, לא ידבר עם בן אדם. זאת אומרת שהם בכלל, נניח ה-Product Manager יהיה Agent, והמפתח יהיה Agent וה-Tester יהיה Agent, והם ידברו אחד עם השני, ואז... (אורי) כמו שעושים אנשים . . . . בסדר. (נתי) כן, נכון - רק בלי אנשים. שזה - לך תדע מה יקרה מאחורי כזה דבר, עוד מעט . . . זה כן יכול להיות עולם מפחיד. (רן) אני עכשיו כבר לא בטוח שאתה אמרת את זה . . . (אורי) בוא נאמר, נתי - העולם מפחיד גם ככה. (נתי) כן, אני מקווה שזה לא יקרה בימיי, בוא נגיד ככה. (רן) העולם מפחיד אז פוחדים, (אורי) . . . בתור נציג החות'ים פה . . . . (נתי) אנחנו עכשיו במקום שבו אנחנו מרגישים גם ככה שהעולם הוא בטרללת אינסופית, שאף אחד לא יודע מי נגד מי כבר. אבל אני חושב שלפני שנגיע למקום הזה, יש הרבה דברים, לדעתי, כיפיים ומעניינים שאפשר לייצר בדבר הזה. לפחות זו החוויה האישית שלי, זה המסר שאני מעביר גם לילדים שלי. שתחשבו על Agent-ים, זה נותן לכם עכשיו כמעט בכל תחום, בין אם זה אמנות ובין אם זה כלכלה ובין אם זה [משהו אחר], להיכנס ולהמציא דברים שבעבר היו שמורים רק לאנשים שהם יוצאי-8200 או “אנשים אחרים”. אז זה יכול גם לייצר סוג של דמוקרטיזציה חיובית. זאת אומרת, יש היום הרבה היבטים חיוביים - לצד, כמו כל דבר, הרבה דברים שיכולים להיות שליליים ומפחידים. אני מעדיף להסתכל תמיד על - לא סתם קוראים לי נתי שלום - אני מעדיף להסתכל על הצד החיובי ולא על הצד השלילי. את זה יש לנו מספיק, בלי עין הרע. ואני חושב שבנימה הזאת אולי אפשר ככה לחתום את השיחה. (רן) אמן.(אורי) שיהיה יותר Downwind עם ה-AI . . . (נתי) לגמרי. תודה רבה על שיחה קלילה על-AI ו-AGI וחברים. להתראות. [קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

  • Aug 27, 2025 · length unknown

    501 Bumpers 87

    פרק מספר 501 של רברס עם פלטפורמה - באמפרס מספר 87, שהוקלט ב-31 ביולי 2025, אמצע הקיץ: רן, דותן ואלון באולפן הוירטואלי עם סדרה של קצרצרים מרחבי האינטרנט - בלוגים מעניינים, דברים מ- GitHub, דוחות וספריות וכל מיני דברים מעניינים - כולל פינת המצחיקולים שחוזרת בגדול. 🎗️ 00:53 רן (רן) אז האייטם הראשון שבו רציתי לפתוח היום זה דוח של חברת BOND, או של ארגון שנקרא BOND, שזה למעשה ארגון שמדי פעם - פעם בכמה שנים, לא הרבה - מייצר דוחות: דוחות אימתניים. והדוח הנוכחי הוא על “מצב ה-AI". (אלון) מפתיע! (רן) כן . . . עכשיו, הדוח הוא בן 340 עמודים - כלומר, בלי AI אי אפשר לקרוא אותו בכלל . . . הדבר ראשון שעשיתי זה שזרקתי אותו על NotebookLM וביקשתי ממנו שיסביר לי ויתקצר לי - ושיעשה ממנו פודקאסט. ודרך אגב, היום ב-NotebookLM גם אפשר לעשות וידאו! עוד לא ניסיתי, אבל ככה Google פרסמו. ומה שיש בדוח הזה, זה למעשה המון נתונים והרבה מאוד גרפים - הוא מאוד מאוד ויזואלי - על “מצב ה-AI" בימים אלו. למי שמכיר את BOND מהעבר, אז הם פרסמו לא מעט . . . זאת אומרת, קודם כל זה ארגון מחקר די רציני הם פרסמו לא מעט דוחות על מצב האינטרנט ולאן האינטרנט הולך וכל זה - וכל אחד מאלה היו איזשהן אבני-דרך משמעותיות. זה באמת ארגון מחקר מאוד . . . אני חושב שזה מורכב בעיקר משני אנשים, ששכחתי את שמם, אבל הם עושים מחקר מאוד יפה ויסודי. ומה שמראים בדוח זה את קצב הגידול של AI מכל מיני זוויות - אם זה מבחינת Adoption, אם זה מבחינת Compute, אם זה מבחינת Spend של דולרים, אם זה מבחינת Reach של משתמשים - זאת אומרת, מכל מיני אספקטים. הם מראים את כולם - והכל כזה בגרפים מאוד יפים. ובכולם אנחנו פחות או יותר רואים "מקל גולף” - אנחנו רואים גרף שעולה בצורה אקספוננציאלית, נכון לתאריך זה, כמעט מכל זווית - וזה יפה ומעניין ונחמד לראות את זה. הם מראים איזשהו Timeline גם לפי מודלים שפורסמו, גם לפי גדלים ומספר הפרמטרים, גם לפי יכולות מחשוב שהתפתחו עם הזמן . . . זהו - דוח יפה כמו שאמרתי, מאוד-מאוד-מאוד ארוך, אבל אפשר גם למצוא תקצירים שלו. אז למי שקצת רוצה לקבל איזשהו Overview של אנליסט מאוד “קפדני”, מוזמן לקרוא את דוח BOND - הוא יצא במאי 2025, עשה לא מעט גלים לא מעט דיברו עליו ב-Twitter ובאינטרנט בכלל, אז אני חושב שזה מאוד מעניין, ככה לקבל איזושהי תמונת מצב של איפה ה-AI נמצא היום. (אלון) יצא מהדוח הזה, אני אם אני לא טועה, יצא “החוק מור של ה-AI” - כאילו, הגדילה של ה-AI, שהוא מכפיל . . . איך זה הולך? כל שנה בפי 1.5 משהו כזה? אני אנסה לחפש את זה בדוח הענק, הזה אין סיכוי שאני אמצא . . . (רן) אני חושב ששהחוק הזה נאמר לפני, אבל הם פה הם באמת מראים במספרים - לפחות בחלק מהמספרים - הם מראים שכן, זאת אומרת, יש לזה ביסוס. למרות שברור לכולם שזה לא תמיד יישאר ככה - אבל בינתיים כן, זה המצב, וזה מעניין. (דותן) אולי אפשר להמציא “חוק Bond” . . . זה שדוחות על AI יגדלו פי 10 מהגדילה של AI. (רן) כן, כן . . . זה 340 עמודים, כמו שאמרנו מקודם. עכשיו, כל עמוד זה זה משהו לעכל, כן? זה לא מילה . . . כל עמוד זה גרף או אוסף של Bullet-ים מעניינים. זאת אומרת, זה לא שסתם מורחים. לפני ההקלטה שאלנו את עצמנו כמה מזה הם כתבו בעצמם וכמה הם נתנו ל-AI לכתוב, או אולי Interns . . . אבל זה לא חשוב - בסופו של דבר יצא דוח מעניין ומאוד מקיף, ואני חושב שזה נחמד לראות את זה. (דותן) רגע . . . אם AI מרושע היה כותב דוח על AI מה הוא היה עושה? אם AI היה משתלט על BOND שם על הסיפור? הוא היה הרי באמת כותב דוח שאי אפשר להבין, שהוא ארוך, נכון? (רן) תראה, אפשר לחשוב על כמה קונספירציות: אחת - אולי הוא היה מנסה להקטין את עצמו, כדי שלא . . . אתה יודע, שלא נערך לקראתו. שתיים - אולי באמת היה מבלבל, אתה יודע, כמו שעושים בפוליטיקה - נותן הרבה מאוד נתונים, כדי שאף אחד לא יראה את התמונה המלאה. או לא יודע - מה? (דותן) אני חושב שלהעסיק את כל בני אדם, להעסיק את כל בני אדם - זה מפרסם 340 עמודים של דוח. (רן) כן . . . דרך אגב, אהבתי פה את הרפרנסים - יש פה רפרנס למהפכת הדפוס, יש פה רפרנס לתחילת המחשוב והאינטרנט, ורואים פה גם . . . . רואים פה בית דפוס ישן, משנת 1440, וגם רואים פה מסך ירוק יפה מ-1993, שמציג דפדפן טקסטואלי - לא יודע איזה גרסה זה - אבל שמציג את האינטרנט בגרסה טקסטואלית, ירוק על גבי שחור. זאת אומרת, יש פה רפרנסים נחמדים לעבר - אבל כמובן רוב הדוח הוא על התפתחות של AI. (אלון) טוב, מגניב - מה המסקנה שלך מהדוח? אם אתה מתמצת לי ל-Elevator Pitch את ה-340 עמודים? . . . (רן) המסקנה שלי שאנחנו בצמיחת Hockey Stick, ורואים את זה מהרבה מאוד זוויות. כלומר, זה לא רק זווית אחת Hockey Stick . . . ומה אני מתכוון בזוויות? - Adoption של משתמשים, Spend של דולרים, גודל של מספר פרמטרים של מודל, יכולות . . . זאת אומרת, פחות או יותר מכל הזוויות האלה אנחנו בצמיחה מעריכית, נכון להיום. וזה מבסס, אני חושב את האמירה של “אוקיי, יש פה Hyper Growth של AI” - זה לא רק פרספקטיבה אחת אלא זה מכל הפרספקטיבות. אז זה כאילו בא ואולי “שם נתונים”, או ככה מראה "בנתונים קשיחים” את מה שאנחנו מרגישים, ושם אותם על הנייר. נעבור לאייטם הבא - אז כמעט כולנו מתנסים ועובדים ומשתמשים ב-Coding Assistants למיניהם השונים, ודיברנו עליהם לא מעט פה בפודקאסט הזה; ודיברנו על זה שגם יש כל מיני סוגים - כלומר החל מ-Vibe Coding ועד Smart Auto-Completion, זאת אומרת - מכל מיני רמות אבסטרקציה שונות. חלק מהם עובדים איתך רק באנגלית ו”רק תגידי לי מה לעשות”, וחלק מהם גם קוראים קוד ומשלימים לך וכל זה. ואחד הדברים שמעניינים את כולם זה עד כמה זה אפקטיבי? זאת אומרת, עד כמה זה באמת עוזר, עד כמה באמת זה מועיל להשתמש בכלים השונים. והיו לא מעט מחקרים, אבל רציתי להציג מחקר אחד, שתפס ככה לא מעט כותרות, ויש בו כמה דברים מעניינים - אבל גם יש לי עליו ביקורת. שם המחקר זה Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity מה שעשו החוקרים - ארבעה במספר, מארגון שנקרא METR לדעתי, שזה ארגון שחוקר, זאת אומרת ארגון משמעותי, זה לא . . . אלה אנשים שיש להם ניסיון במחקר, בעיקר של הנדסת תוכנה - באים ובודקים את ההשפעה של כלי AI שונים על הפרודוקטיביות של מפתחים מנוסים בקוד פתוח. איך הם עשו את זה? הם עשו ניסוי מבוקר: הלכו לכמה עשרות פרויקטים, לדעתי משהו כמו 15 או 16 פרויקטים, אם אני זוכר נכון . . . (אלון) 16 לזיכרוני, 16 מפתחים . . . לא יודע אם פרויקטים אבל 16 מפתחים. (רן) כן, כשכל אחד מהמפתחים - יש לו מומחיות גדולה בפרויקט שעליו הוא עובד. זאת אומרת פרויקט קוד פתוח משמעותי - וכל אחד מ-16 הנמדדים, 16 המפתחים, מכיר את הפרויקט לפחות חמש שנים, אוקיי? ומה שהם אמרו להם זה אוקיי, עכשיו יש לכם אוסף של Task-ים - נגיד, לקחו מתוך ה-Backlog של הפרויקט - ואת כל ה-Backlog הזה של ה-Task-ים הם חילקו אקראית בין “את זה תעשה לגמרי לבד” ו”את ה-Task האחר תעשה באמצעות מנועי-Coding” ברוב המקרים השתמשו ב-Cursor אז בעצם עשו חלוקה אקראית של ה-Task-ים, ועכשיו הם ביקשו מהם קודם כל “תנו הערכת זמן” - כמה זמן זה הולך לקחת לכם? ואז תבצעו את המשימה - בין אם זה באמצעות AI או בין אם בלי, ככה 50-50. ואחר כך נבדוק כמה זמן באמת לקח. והתוצאות שהם גילו הן מפתיעות: התוצאות מראות שמפתחים - דרך אגב, רוב המפתחים הם מאוד מנוסים בפרויקטים שלהם, הם לא כל כך מנוסים בכלים עצמם, כלומר ב-Cursor, לצורך העניין. לחלקם היה ניסיון, אבל אף אחד מהם . . . זאת אומרת, הם העידו על זה שאף אחד מהם לא היה משתמש Cursor משמעותי. אז לפני תחילת העבודה, הם העריכו שהמשימה תיקח משהו כמו 20% או 30% פחות זמן, בהינתן כלי Coding, Code Assistance, מאשר בלי, אוקיי? אז ההערכה שלהם הייתה שייקח פחות זמן. דה-פקטו, מה שקרה זה שלקח יותר זמן כאשר הם כן השתמשו ב-Code Assistance . . . . זאת אומרת, לא רק יותר זמן ממה שהם חשבו שייקח, אלא יותר זמן ממה שהיה ככל הנראה לוקח להם, אם בכלל לא היו משתמשים. משהו כמו 19% . . . וזה מפתיע . . . אז שוב, ההערכה הראשונית הייתה שזה ייקח משהו כמו 20-30% פחות, דה-פקטו זה לקח משהו כמו 19% יותר, באותו ניסוי מבוקר. וזה קצת שם מקל בגלגלים של “היי, לא צריך יותר מפתחים אנושיים! כלי ה-AI יעשו לכולם את העבודה!” - והנה מסתבר ש . . . פה לא ברור, דרך אגב, אם הם עשו עבודה טובה או לא טובה - אבל זה לוקח יותר זמן. (אלון) יש פה כמה דברים על המחקר הזה . . . . אחד, קודם כל: הם העריכו כמה זמן לקח להם אחרי שהם עשו את זה, שזה מעניין, והם אמרו ש-20% פחות, שזה היה לוקח להם כאילו יותר. ובמדדים האלה זה הראה שזה לקח, כביכול, יותר זמן. כמה נקודות מעניינות - אחד המפתחים, פשוט אני צריך לחפש את זה, אחד המפתחים שהשתתף הגיב על זה אחר כך, על המחקר, והוא אמר “אני אחד המפתחים במחקר, כולנו מפתחים מאוד מנוסים והכול” מה שהוא אמר שזה, בדיעבד, לא מחקר טוב . . . . כי מה שהם בדקו שם זה מפתיחה - מ”להתחיל לעבוד על Issue”, מכניסה של Issue, עד שהוא עושה Merge ל-Repo. שזה בסדר - עד Delivery - אבל מה שהוא אמר זה “סיימנו את המשימה הרבה יותר מהר - ואז עד שקהילה מגיבה אתה כבר לא בקונטקסט, גם עבדת על זה פחות . . .” בגלל שעבדת על זה הרבה יותר מהר, הוא אומר, אתה פחות בקונטקסט, לקח לך אחרי זה יותר זמן להיכנס לקונטקסט - וב-Open Source, הוא אמר שבגלל שה-Cycle-ים ארוכים, זה מאוד בעייתי שאתה לא זוכר ולא מכיר את הכל טוב. כאילו, כשאתה לא בקונטקסט טוב, כשאתה עובד על משהו שבועיים, נגיד, אתה הרבה יותר מכיר אותו מאשר ביום אחד, אתה פחות זוכר את הפרטים. ואז הוא היה בכל פעם צריך, כדי לענות לקהילה, היה צריך כל פעם להיכנס, לצלול וזה . . . והוא אמר שזה מה שלקח לו את הזמן. (רן) כן, אז זהו, אז אמרתי שיש לי כמה ביקורות על המחקר הזה, אז זה אחד. אז קודם כל, אחד זה מעניין. אתה רוצה איזשהו מחקר כמותי ומדעי . . . סליחה, שם הארגון - אמרתי אותו לא נכון מקודם, שם הארגון זה METR, זה Model Evaluation and Threat Research, שזה ארגון שהוא Established, זאת אומרת זה לא איזשהו משהו קיקיוני . . . אבל יש לי כמה ביקורות על המחקר הזה. קודם כל אני חושב שצריך לתת להם את הבמה - עשו מחקר כמותי, מעניין, יפה, אני חושב שזה כבר נהדר. אבל הביקורות שיש לי עליו זה אחד - לפחות האינטואיציה שלי היא שמישהו שמכיר את הפרויקט מאוד טוב - אמרו “לפחות חמש שנים”, כן? מפתח שעובד לפחות חמש שנים על הפרויקט - סיכוי טוב שהוא יעשה עבודה יותר טובה, כי יש לו את כל הקונטקסט בראש, אוקיי? סיכוי טוב שהוא יעשה עבודה יותר טובה ממודל שפעם ראשונה רואה את הפרויקט ולא מכיר את כל הניואנסים הקטנים שלו, זה אחד. שתיים - כל מי שהתנסה עם כתיבת קוד באמצעות מודלים כאלה יודע שכדי שהמודלים יעשו עבודה טובה, צריך לתת להם קונטקסט - וצריך לתת להם הרבה מאוד קונטקסט. ומי שלא מנוסה, מי שלא יודע איך לתת את הקונטקסט הזה, כלומר - נגיד, להגיד “הנה מבנה הפרויקט, הנה הטסטים שצריך להריץ, הנה ה-Issues האחרים שרלוונטיים, הנה קוד-עבר, הנה הנה Merge Request רלוונטי” . . . זאת אומרת, לבוא ולתת את כל הקונטקסט - שאם לא נותנים אותו, זה כל הדברים שיש לך בראש כמפתח, אבל אם אתה לא נותן את זה למודל, הסיכוי שלו מלכתחילה לעשות עבודה טובה הוא הרבה הרבה יותר נמוך. אז זה ספציפית לגבי מדידת הזמנים. אבל אני חושב יותר מזה - אני חושב שפונקציית המטרה שלהם היא לא נכונה. הם מדדו כמה זמן ייקח - ואני חושב שזה לא מעניין, או שזה הרבה פחות מעניין. הרבה פחות מעניין כמה זמן זה ייקח. אני חושב שהרבה יותר מעניין זה מה איכות התוצאה - וזה משהו שהם לא מדדו. כלומר, אנחנו יודעים שכשכותבים קוד, זמן הכתיבה של הקוד הוא בדרך כלל עשירית מכל ה-Impact שהוא עושה. בין אם זה ב-Issues עתידיים, בין אם זה ב . . . זאת אומרת, זה תחזוקה, זה איך זה מתממשק לדברים אחרים. זאת אומרת, זמן כתיבת הקוד בטל בשישים לעומת כל הנגזרות האחרות של הקוד - ואת הנגזרות האחרות אולי קצת יותר קשה למדוד במחקר כזה, אבל אני אקרא להן במילה אחת “איכות”. אז אני חושב שמה שצריך באמת למדוד פה זה את האיכות של התוצר ולא כמה זמן. אם זה לקח 19% יותר או 20% פחות - זה ממש לא מעניין. זאת אומרת, לדעתי זה משתנה מסדר שני. זה הרבה הרבה פחות מעניין מהאיכות של התוצאה - וזה משהו שהם לא מדדו פה, ואני חושב שאת זה כן יהיה מעניין למדוד במחקרים עתידיים. (דותן) נראה שזה מחקר לא טוב, אני אגיד את זה ככה . . . אתה לא יכול לקחת 16 מפתחים ומודל שאומן על מאות אלפי פרויקטים וטריליארדים של זיליארדים של נקודות Data - ואז להגיד “אפיינתי את העולם” . . . זה גם לא מודל אחד - זה לקחת, לא יודע מה - 20 מודלים, כרגע, שהם פופולריים ונפוצים ולהגיד “זהו, אני קבעתי - זה לא עובד!” אי אפשר - אתה צריך לקחת כמות מפתחים או כמות פרויקטים פרופורציונלית לעולם של ה-AI, בשביל שבכלל יצא לך משהו הגיוני. (רן) כן, אז כן אני מסכים - יש הרבה ביקורות על המחקר, מצד אחד. מצד שני - היי, עשו מחקר . . . כאילו, זה התחלה. (אלון) לא, כנראה שהמחקר כמחקר הוא נכון. כאילו, אני חושב ש... כנראה לקחו מספיק, ובוא נגיד שאם תגיד שבפרויקטים של Open Source שהמפתחים מנוסים, כנראה תגיע למהירות פחות גבוהה . . בוא נניח שהם יודעים לחקור ובוא נניח שזה נכון. דווקא ההסתייגויות של אחד המפתחים שם זה מה שהיה מעניין - כי הוא כאילו בפועל אומר “אני עבדתי פחות שעות” . . . “לא לקח יותר זמן, אני עבדתי פחות שעות. עזבו אותי, אז השקעתי . . . “ ב-Open Source - זה לא עבודה שלו, צריך להבין את זה, זה קצת בעייתי . . . אז אם הוא אומר “רגע, סיימתי“. אז אם הוא תכנן לעבוד, לא יודע מה - סופ”ש על הפרויקט הזה - והוא סיים את זה בארבע שעות, אז אתה יודע, הוא עשה משהו אחר בזמן הזה. זה שבסוף התוצאה עשתה Merge יותר מאוחר - נכון, אבל לא מדדו את הכל, אז כאילו . . . הוא בעצמו אמר שהוא ימשיך להשתמש ב-AI שהוא לפני זה דווקא לא היה - אני אחפש את זה אחרי זה - הוא אמר דווקא שזה כאילו מה שגרם לו לדחוף, הוא תמיד ראה את זה מהצד - ודווקא הוא הבין את הערך של זה, והוא התחיל להשתמש בזה. וכאילו המחקר אומר הפוך מהתחושה של אחד הנחקרים שם, זה מעניין ממש . . . (רן) כן, זאת אומרת - הוא אומר אני לא רוצה למדוד Latency, אני רוצה למדוד Thruput - וה-Thruput שלי גדל. “אז נכון - לקח יותר זמן עד שה-Issue נפתר, אבל במקביל עשיתי עוד כמה דברים והייתי יותר פרודוקטיבי”. אוקיי, טוב, אז אחלה. בקיצור, אני חושב שזה מחקר מעניין עדיין ושווה לדבר עליו, גם אם יש לנו עליו ביקורת. טוב, רציתי לעבור לנושא הבא . . . (אלון) אז רגע - AI לא יתפוס? רגע, שאני אבין, בסדר . . . . (דותן) לא, תוציא, תוציא . . . . (אלון) תוציא, אוקיי - יותר מדי AI שמת שם . . . תוציא, בסדר. (רן) יאללה, בואו נעבור קצת לנוסטלגיה - נושא אחר לחלוטין, לא קשור בכלל לפיתוח או ל-AI, נראה לי לפחות : מצאתי אתר מגניב שנקרא OldMapsOnline.org - מפות ישנות - שהוא ממש תענוג למי שחובב גיאוגרפיה והיסטוריה. אתם נכנסים לאתר הזה, ובעצם יש לכם איזשהו ציר זמן: אתם יכולים להסתכל על מפה של כדור הארץ או נגיד מפה של אירופה, מפה של אסיה ואפריקה, ויש לכם ציר זמן ואתם יכולים להזיז לגרור את ציר הזמן ולראות איך המפה משתנה - מפה מדינית - איך המפה משתנה לאורך השנים. וזה מגניב פשוט להסתכל ככה על אירופה, על אפריקה, על המזרח התיכון - ולראות איך זה השתנה, החל מ-2000- ומשהו . . . כאילו לא יודע מתי זה מתחיל . . . 4000- אוקיי? 4000 לפני הספירה - ועד ממש שנת 2000 וממש נראה לי עד זמננו. אפשר פשוט לראות איך המפה המדינית משתנה על ציר הזמן, ויש לכם גם בצד כל מיני רפרנסים למפות היסטוריות, ככה שתוכלו להבין מאיפה מגיעים המקורות לכל זה. זה מגניב, פשוט לשחק עם ציר הזמן ולראות איך הגיאוגרפיה או איך המדינות - או השליטה, כמובן, גם לפני שהיו מדינות - איך נראתה מפת השליטה בעולם, לפני אלף שנים או 200 שנים או מה שזה לא יהיה. אם זה האימפריה הרומית האימפריה הפרסית או אחרות. אז זהו, אני חושב שזה ממש מגניב ויפה. (אלון) זה ממש מגניב . . . האמת, אני מנסה לחשוב על עוד כמה דברים שאפשר לעשות ככה ויזואליזציה חמודה . . . אבל העולם מתחיל בישראל, בערך . . . מצרים, האמת, אני רואה . . . (רן) כן, טוב, בסדר. (רן) עכשיו נעבור לאייטם הבא שלי, שהוא גם ויזואלי אבל של מתכנתים - כולם מכירים את אלגוריתמי-המיון השונים, נכון? אם זה Merge Sort או Quick Sort או Bubble Sort וכל זה. אז מצאתי ב-Twitter סרטון נחמד שבא ומראה את האלגוריתמים השונים בצורה ויזואלית ממש מגניבה אז ברמה אלגוריתמית אני לא חושב שאני הולך לחדש לכם שום דבר, אבל זה עדיין נחמד וכיף לראות את האלגוריתמים השונים - איך הם ממיינים יפה את העמודות. מה שרואים זה בעצם עמודות בגבהים שונים - ואת האלגוריתמים השונים הולכים וממיינים אותם בסרטון זריז של ככה כמה עשרות שניות. אז זהו, זה מגניב - אז לכו לראות את הסרטוני-מיון השונים. דרך אגב, זה נחמד לראות שהמיונים האיטיים יותר פשוט עובדים על הרבה פחות דאטה - כדי שזה ייגמר בזמן. נגיד Bubble Sort עובד על עמודות “עבות” יותר, “שמנות” יותר, כי פשוט אם הוא יעבוד על כל העמודות הדקיקות הוא לא יסיים בזמן, בזמן שהאלגוריתמים האחרים יותר יעילים, כמו Quick Sort, עובדים על עמודות יותר “דקיקות”, כלומר על יותר מספרים. אז ויזואליזציה (Visualization) נחמדה ככה לשנה א' במדעי המחשב, אבל עדיין כיף לראות את זה. (דותן) נראה לי שמצאתי מה לעשות בזמן ש-Cursor מייצר קוד . . . הקטע הזה, שאתה נותן לו Prompt ואז צריך לחכות, ואז אתה מתלבט: “רגע, אני אלך לעשות משהו אחר, אני אחכה נראה” . . . . פשוט לשבת ולהסתכל על אלגוריתם ממיין דאטה . . . (רן) כן, זה מהפנט, האמת, להסתכל על זה. זה ממש נחמד. (אלון) השיטה שלי זה לפתוח עוד Cursor במסך השני, ואז בינתיים להמשיך איתו . . . (דותן) אבל לא, אתה צריך לתזמן את ה-Agent, בדיוק כשאחד עובד אז . . . . (אלון) כן, זהו - נהייתי כמו הילדים: מסך אחד משחקים, והמסך שני נהיה Cursor, כן . . . (רן) אין כמו Instagram ו-TikTok כדי להכין אותם לעולם העבודה - Split Attention . . . (אלון) תכל’ס, נכון . . . תצעק על הילדים עכשיו: “למה אתם לא ב-TikTok תוך כדי הטלוויזיה?! מה זה, אתם לא מתאמנים! . . . (רן) לגמרי . . . . (אלון) . . . “לא יהיה לכם עתיד ככה!” (רן) טוב, אייטם אחרון שלי לעת עתה - קראתי בלוג-פוסט מאוד מעניין שנקרא LLM inference economics from first principles. מה הבלוג-פוסט הזה עושה? הוא בעצם בא ועושה ממש חישוב דקדקני - ממש כמו של רואה חשבון - כמה זיכרון וכמה Throughput צריך GPU כדי לארח מודל שפה גדולה. בדוגמה שלו הוא משתמש לדעתי ב-Llama-3.3-70B, כלומר מודל עם שבעים מיליארד פרמטרים. והוא בא בתור התחלה ובודק ומסביר מה המבנה שלו - ואז מתחיל לחשב מה מספר הפרמטרים בכל שכבה בכל אזור של המודל - ואחר כך איך מסדרים אותם בזיכרון. והבלוג-פוסט הזה מאוד מאוד ככה ארוך ודקדקני, ובא ואומר “אוקיי, אם אתם צריכים מודל מסדר גודל כזה, זה כמות הזיכרון GPU שאתם צריכים” ואיך אפשר לנצל Multi-GPU ואפילו אם המודל שלכם נכנס בזיכרון, אתם תמיד תמיד תרצו עוד יותר זיכרון - רמז: KV Caching. והוא ממש ככה ונכנס . . . זאת אומרת, הוא גם אחד - בונה איזשהו מודל חישובי; ושתיים - עושה ניסויים, ממש ניסויים בשטח, של כמה באמת זה לקח. וגם מראה איפה המודל החישובי שלו טועה, כלומר - הוא לא מצליח לנבא בדיוק והוא גם מסביר מהן הסיבות. אבל עדיין יש קורולציה יפה בין המודל התיאורטי שלו לבין המציאות. וזה מסביר מאוד יפה מושגים כמו Tensor Parallelism ומושגים כמו כמו שאמרתי KV Caching, למה חשוב לעשות Batching ואיך ה-Batching עובד, ומה קורה, זאת אומרת - Trade-off-ים בין Throughput ל-Latency שזה אולי כבר טריוויאלי - אבל בכל אופן הוא בא ומסביר אותם פה במספרים וגרפים. וזהו, אם אתם רוצים באמת להבין מה העלות האמיתית או איך אפשר לנסות לפחות לחשב עלות של Inference של מודלי שפה גדולים, אז זה בלוג-פוסט ממש יפה שבא ומסביר את זה. אז אני ממליץ. (אלון) יש פה משהו שהוא ממש מעניין - אני מנסה להבין אם יש משהו, איזושהי נוסחה פרקטית לאופטימיזציה, כשעובדים עם מודלים. (רן) לא הבנתי, מה השאלה? (אלון) האם אני יכול להוציא פה איזו נוסחה פרקטית לאופטימיזציה של מודלים, כלומר של אופטימיזציה. אם אני רוצה שהקוד שלי, לא יודע, יעבוד יותר מהר עם המודל. האם יש פה איזה משהו פרקטי, להגיע עד נקודה מסוימת, או שזה יותר תיאורטי כרגע? (רן) אז קודם כל, זה רק למי שרוצה לארח בעצמו את המודלים . . . (אלון) כן, ברור. (רן) ועכשיו, הוא כן - הוא נותן פה כמה Pointer-ים: אחד - זה כמה שיותר Batch. כמה שיותר Batch-ים וכמה שיותר גדולים. זה כאילו אולי טריוויאלי, אבל הוא כאילו בא ומראה עד כמה זה אפקטיבי, כל עוד אתה יכול להרשות לעצמך את ה-Latency. דרך אגב, אתם בטח יודעים שאם אתם רוצים לעשות Inference, העלות נגיד אם אתם הולכים ל-OpenAI או ל-Anthropic, העלות של Batch inference היא חצי מעלות של inference רגיל, אוקיי? וזה לא סתם . . . סיבה טובה, דה-פקטו יכול להיות שהעלות אפילו יותר נמוכה בשבילם, יותר נמוכה מחצי - אבל לכם, כלקוח, אתם משלמים בדיוק חצי על Batch inference מאשר Inference רגיל. לפחות ב-Anthropic זה המצב, אני חושב שגם ב-OpenAI וגם בפלטפורמות אחרות, נגיד Bedrock, זה בדרך כלל המצב. והוא בא ואומר - אם אתם באמת רוצים לעשות לעצמכם Hosting של המודלים, אז הדבר הנוסף שהוא בא ואומר מבחינת כללי אצבע זה שאל תסתפקו בכמות זיכרון שמספיקה למשקולות של המודל, כי אז לא יישאר לכם מקום ל-KV Cache ו-KV Cache הוא מאוד מאוד משמעותי. זאת אומרת, אתם תמיד רוצים כמה שיותר זיכרון - ועדיף שכמה שיותר מהזיכרון הזה יהיה בשימוש של KV Caching ולא רק של המשקולות עצמם של המודל. זאת אומרת, אתם מתחילים עם מודל “ששוקל 70 מיליארד” - אוקיי, זה כבר כנראה ממלא חלק משמעותי מהזיכרון. אבל זה לא מספיק שהצלחתם לדחוף אותו בזיכרון - אתם רוצים להשאיר הרבה מאוד מקום פנוי, כי אם לא תעשו את זה, לא ישאר לכם מקום ל-KV Cache, וזה מאוד מאוד משמעותי. זאת אומרת, זה משמעותי כתלות באורך ה-Output - אבל בהנחה שה-Output שלכם הוא לא קצרצר, בהנחה שה-Output שלכם הוא נגיד כמה עשרות או מאות Token-ים, אז ה-KV Caching הוא מאוד מאוד משמעותי. לא ניכנס למה זה KV Cache, אבל אולי בהזדמנות אחרת. (אלון) רק שאלה - יש לך מושג אם זה רלוונטי גם למודלים של וידאו? כאילו, אותו דבר או שזה נוסחה אחרת או שלא יודע? . . . . (רן) אתה מתכוון ל-VLM? Vision Language Models? או משהו . . . (אלון) כן . . . (רן) . . . אני לא יודע. אני יכול לנחש שאם הם משתמשים ב-Token-ים בצורה דומה אז כן, אבל אני לא בטוח שזה המצב עם כולם. אני יודע שיש כאלה שכן, אני לא בטוח שכולם כאלה. (אלון) אני פחות מכיר איך הם עובדים . . . אוקיי. (רן) טוב - אלון, אליך! 26:42 אלון (אלון) טוב, יאללה - נתחיל מעדכונים נחמדים. דיברנו על זה פעם שעברה [496 Bumpers 86], האמת, על החצי הראשון של הסיפור. אז Monday רכשה את הפרויקט של ליעד יוסף ועידו סולומון, שעשו את ה-GitMCP דיברנו עליו - באיזה סופ”ש, כשהיה הרבה עומס והיה מגניב . . . אז זה נגמר פה באיזה סיפור יפה. Monday - כל הכבוד להם - החליטו ללכת על איזה Talent Acquisition, והכניסו אותם פנימה. אז קודם כל, יפה. חברות ישראליות גם נכנסות לקלחת הזאת של Talent AI, וכל הכבוד לצמד הישראלי - הכל פה ישראלי, אמנם - לליעד ועידו. זה באמת סיפור יפה, מי שזוכר “מאירועי הפרקים הקודמים” - עשו באיזה סופ”ש אחד, הרימו את ה-GitMCP, עשו איזה Twit או משהו וזה די התפוצץ, השרתים של Next.js התחילו לעלות הרבה כסף, עבדו כל הסופ”ש כדי להסדיר את זה, בסוף Cloudflare והגיעו החליטו לקחת על זה Sponsorship, העבירו ל Cloudflare . . . וזהו, זה בערך היה סיפור - איזה סופ”ש מטורף כזה, שעבדו סביב השעון. אה, Vercel זה היה . . . (רן) כן, הם עברו מ-Vercel ל-Cloudflare . . . אז מברוק, קודם כל - עידו וליעד - כל הכבוד, אחלה עבודה - ושיהיה בהצלחה! (אלון) כן ,תהנו בתפקיד החדש. זהו אז זה מגניב . . . אפרופו MCP וכאלה - אז אם אני כבר פה, אז יצא מי שרצה לעשות MCP בדרך כלל היה צריך Python, אז עכשיו יצאה גם איזו ספרייה רשמית, הרחיבו את הפרוטוקולים אז עכשיו יש רשמי גם ב-TypeScript, Python, Java, Kotlin ו-#C ו-Go, לדעתי זה הכל חדש . . . (רן) אני שומע את דותן אומר “מה עם Rust?!” (אלון) אני לא ראיתי רשמי . . . . (דותן) האמת שזה טרנד כזה, ש-”Rust - לא”, אני לא יודע למה. גם יש את ה-AI SDK של Vercel, שהוא טוב - וגם שם אין Rust. (רן) מחכים לך . . . (אלון) אתה יודע למה? היית עסוק, לא היה לך זמן אליהם, אז אמרו “טוב, נו, בוא נחכה לו, מה נעשה?”. אז זהו, טוב, בואו נמשיך. יש בחור בשם יניב ארליך - הוא חי בTwitter, אני לא יודע מה עוד הוא עושה בחיים, אבל הוא בחור מאוד מעניין - והוא, במלחמה עם איראן, התחיל לעשות כל מיני ניתוחים של מאיפה הטילים נורו לפי ה-Video-ים של הנחיתה שלהם, לפי הזווית נחיתה. לקח איזה כמה תמונות מהמקום, חישב את הזווית נחיתה והתרעות ועוד כל מיני דברים נחמדים - ומצא בדיוק די מטורף, רק מהווידאו של הנחיתה, מאיפה הטיל שוגר. אז קודם כל, זה מרתק לקרוא את מה שהוא עושה. ועכשיו, הוא רשם שהוא עשה איזה Script פרויקט ב-Python שנקרא PyBomba, שנותנים לו תמונה של טיל נוחת - והוא אומר מאיפה הטיל נורה . . . . אז הוא מספר פה על הפרויקט - וויזואלי מאוד. זה ממש משהו, זה אחד הדברים הכי מגניבים, אני חייב להודות. זה גם נורא מפתיע שאפשר מכל כך מעט מידע, כביכול מווידאו אחד, להוציא כזו רמת דיוק, זה פשוט לא יודע . . . זה לדעתי מטורף. (רן) מעניין אם היו תצלומים גם של היירוטים, אם גם איתם הוא היה יכול לעשות משהו כזה? תאורטית, גם בזמן היירוט אתה יכול אולי לראות את זווית הכניסה ואתה רואה מעל איזה קואורדינטה זה בכדור הארץ . . . (אלון) כן, אבל יש לך בעיה עם הגובה, אני חושב שאתה צריך גם לדעת איזה גובה וזה יותר קשה. כשזה בקרקע אתה יודע מה הגובה אבל אני לא מומחה . . . הוא באמת ממש מומחה, אז אפשר. והאייטם הבא שלי זה אייטם - דותן - במיוחד בשבילך: כמו שמישהו רשם, AWS רשמו פוסט על המעבר שהם עשו ב-Aurora DSQL, על השינויים שהם עברו שם, מ-Kotlin ל-Rust. המאמר הזה, כמו שמישהו סיכם אותו, זה פחות עניין טכנולוגי - זה יותר שיר אהבה ל-Rust. איך Rust שינה להם את הכל, ואיך הם שכתבו את ה-Kotlin ב-Rust וזה העלה להם בפי 10x את הקוד והכל עבד מגניב והכל מדהים . . . כן ראיתי על זה Disclaimer של מישהו מ-AWS, שאמר אחרי זה “חבר'ה, כן - אבל זה לא קשור” . . . [Boaz, וגם פה]. כאילו, אמר משהו ש”כן, נכון - כותבים ב-Rust, אני אוהב Rust, הכל טוב, אבל זה לא באמת קשור, הסיפור הזה פה להילול ל-Rust” אז אפשר לקחת את זה בעירבון מוגבל. אבל בגדול, Kotlin Out ו-Rust In - ובכל מקרה זה סיפור נחמד על Aurora DSQL. כש-Aurora DSQL זה ה-Database ה- Postgres שלהם . . . מה השם שלו? (רן) כן, Aurora זה גם Postgres וגם DSQL, זאת אומרת Database רלציוני - אבל מנוהל, שאתה רק צריך להגיד לו איזה גדלים והוא כבר עושה לך את כל הניהול. (אלון) כן - הוא מנוהל והוא Distributed, כאילו Horizontal Scale והכל - הוא ממש אחד ה-Database-ים המרשימים. יש את זה ויש את השני של Google, שברח לי שמו . . . לא Spanner, החדש שלהם, שהוא גם אותו רעיון. ברח לי שמו, אבל זה שני Database-ים מאוד מרשימים. אז זהו - סיפור אהבה ל-Rust, על איך הם הוציאו את Kotlin, החליפו שם את ה-Controller, והכל עובד עכשיו מדהים. זהו. (דותן) אני רק אני אגיב על הדבר הזה - יש פה דרמה. כאילו, יש פה את החבר'ה שאומרים . . . יש פה מישהו שציטט את המאמר ב-Twitter. והמאמר, כמו שאתה אומר, אומר שהם עברו ל-Rust והכל הפך להיות הרבה יותר טוב. ואז יש את בועז ב. . . . .שאומר שהם שכתבו את ההיסטוריה ושזה לא באמת קרה ככה. הוא כנראה . . . אני רק מנסה לנחש את הסיפור, כנראה ישב שם באותו זמן, בתור מהנדס ולא ראה את זה קורה כמו שהם סיפרו. אז אחד - אני בוחר . . . אי אפשר להאמין, כאילו, אתה לא יכול לבחור צד - אבל אפשר לבחור בעובדות. אני, בכל מקום שראיתי, בכל מקום שעשיתי - הכנסתי Rust. וזה שיפר - משמעותית, פי 10 או יותר, או שיפר פי-2 פי-3 בכל אופן, זה ככה או ככה שיפר את החוויית פיתוח וכל הסיפור של Safety - פשוט משאיר אבק לכל שפה אחרת. אז זה כאילו ניתן איזה ניתוח - לא חשוב מה קרה ב-AWS, אבל ככה זה ככה זה בחיים. וסתם, זה גורם לי לחשוב על המקרים האלה שחברות באות מפרסמות מאמר “הנה, עברנו ל.. מ-X ל-Y” או “עברנו מ-AWS ל-GCP”, ותראו איך הדברים השתפרו וכל מיני כאלה. ומשקיעים בזה מאוד, וכנראה שכל הצוות גם כתב את זה, וכל המנהלים עשו Review למאמר. ואז פיבלשו (Publish) את זה וכולם היו מאוד מאוד כאילו ב-hype סביב המאמר הזה ותכננו לפרסם אותו. ולפעמים קורה שבאמת המאמרים האלה - הם לא מתארים את מה שקרה אחד לאחד במציאות . . . קצת מייפים, קצת משנים. לפעמים גם זה קורה בתום לב - זה מה שנקרה “כל אחד נותן את ההיסטוריה איך שהוא ראה”. זה גם נושא, זה קיים די הרבה. (רן) אז בזמן שדיברנו, חיטטתי קצת בפיד של בועז - ברמן, דרך אגב ,זה שם המשפחה - והוא כתב פוסט ב-LinkedIn, שבו הוא אומר “הייתי חלק מהעבודה הזאת על AWS Aurora, ובאמת אני מאוד גאה בעבודה הזאת . . . “ והוא אומר שבגדול הסוד הוא בשעונים אטומיים מאוד מאוד מדויקים . . . זאת אומרת, חלק מה-Backbone של ה-Control Plane זה באמת הסוד - אבל הוא גם אומר . . . במקום אחר, הוא אומר “אוקיי, זה נחמד וזה - אבל אין לזה שום קשר ל-Rust”. נכון שהשתמשנו ב-Rust אבל זו לא הסיבה לזה שזה הצליח. הוא בא ואומר “לקחנו את הרעיון של GCP Spanner - ופשוט עשינו את זה יותר מדויק, יותר חזק, יותר יותר קפדני - ויצא פגז. אז אוקיי, בקיצור - זוויות שונות לאותו סיפור . . . דרך אגב, יכול מאוד להיות שבמציאות מורכבת הכל נכון . . . כאילו, אוקיי - זה גם זה. אבל זה גם שפה שהיא מספיק מהירה ומספיק בטוחה - ואם היו עושים את אותו דבר ב-C או ב-Kotlin אז התוצאות היו שונות. אז ככה שככל הנראה זה שילוב של שני אלה. (דותן) אני חושב שפרמטר שנראה לי חשוב ושאנשים מפספסים זה שהם הצליחו לעבור . . . . הרבה פעמים, פרויקטים כאלה של שכתוב - “בוא נשכתב הכל ב- . . .” - או שהם נמשכים שנים, ואז האנשים שהתחילו לשכתב הם כבר לא בחברה והאנשים החדשים קיבלו איזה משהו כזה אליהם ואיכשהו הם גורמים לזה לחיות, ומאבדים בכלל את הטעם למה בכלל התחלנו . . . או שהם לא מצליחים - והם נשארים בשפה או בפלטפורמה הישנה. (אלון) כן. אגב, אני חושב שהם לקחו . . . - הוא יודע מן הסתם יותר טוב ממני, הוא עובד על הפרויקט ואני מהצד - היה את Spanner, שהוא המקורי, עם השעונים האטומיים, שזה היה הפיצוח של ה-CAP, כביכול שברו איתו את ה-CAP Theorem לפני כמה שנים. הם הצליחו, עם שעונים אטומיים, להראות שאפשר לעקוף את זה. ואז Aurora היה . . . . זהו, נזכרתי - עכשיו, לפני איזה שנה-שנתיים, יצא את AlloyDB של GCP, שהוא בעצם אותו רעיון הם לקחו את Spanner שהיה נורא יקר, אבל לעשות את אותו קונספט וזה בדיוק כמו Aurora Distributed. ואני חושב שמה שעכשיו Aurora DSQL זה בעצם AlloyDB - אז הקונספט התחיל מ-Spanner, אבל אני חושב שזה ממש העתקה - לא יודע אם טכנולוגית, אבל העתקה של הקונספט - של AlloyDB. ה- AlloyDB, אגב, הוא די מרשים מאוד, אני חייב להודות . . . את Aurora DSQL הזה אני לא מכיר, אני מניח שגם כן טוב. (אלון) יאללה נקסט - אז האמת, כדי לסגור את המעגל עם האייטם שהתחלתי איתו, הייתי צריך להצמיד, אבל לא . . . אז אם נחזור לחברינו מהאייטם הראשון - ליעד ועידו - אז הם הוציאו Open Source לפני כמה זמן, שנקרא MCP-UI. והרעיון הוא לנסות לפרמל איך ליצור UI על גבי ה-MCP, כש-MCP זה ה-Model Context Protocol, שבגדול אומר “איך לדבר עם API בשפה טבעית” אז מה שחסר שם זה שכשאתה מעביר טקסט ומקבל איזה שהוא משהו חזרה - טקסט או JSON או משהו. וניסו לפרמל איך אפשר גם לשלוח . . . איך להציג UI עם הדבר הזה. עכשיו, זה איזשהו Open Source שהוא יותר קונספטואלי, אבל מה שמעניין שלהבנתי הוקמה איזה “ועדת ה-MCP” - תקינה - והם שם. אז אז בוא נגיד שהייתי עוקב אחרי מה שהם עושים, ולא הייתי . . . גם אם זה נראה משהו חצי-אפוי, לא הייתי מזלזל בזה. זהו - תסתכלו על הפרויקט, זה קונספט חמוד. (רן) כן, ליעד ועידו בוועדת ההיגוי של MCP-UI - אז כן, הם חלק מהחלק “מהקדרה שבפנים”. [ובינתיים גם יש אג’נדה לרברסים 2025 - ו-Guess What . . . .] (רן) אוקיי - דותן. 39:20 דותן (דותן) כן, טוב - אז שמתי פה כפתיח שני פרוייקטי Open Source, שני שכפולים של מוצרים, ואם נכנסים ורואים אז רואים שזה עשוי די טוב. הראשון נקרא Outline - והוא נראה ממש כמו Notion כזה לארגונים, לאנשים פרטיים. זה Open Source ואתה יכול לעשות Hosting בעצמך. והשני זה “סוג של Trello-Asana-משימות”’, מסוג הדברים שאנחנו מכירים לאורך ההיסטוריה, וגם זה נראה די טוב. [זה נקרא Focalboard, אגב]. ואחד הדברים שאני תוהה לגביהם זה כמה זה נעשה על ידי AI . . . זאת אומרת, מחשבה שככה אני זורק באוויר. פעם, הרי אנחנו זוכרים כש-Trello יצא [ד”ש ל-Joel Spolsky], אז מלא עשו Kanban Baord-ים, ופתאום הנושא של “לגרור פתקיות כאלה” הפך להיות Big Deal ב-Frontend וכולם עשו ספריות של Drag & Drop וכל מיני קשקושים כאלה . . . . ואנשים שכפלו את Trello - אבל לקח להם הרבה זמן, וממש “חצבו באבן”. ועכשיו זה נראה לי, באינטואיציה שלי, די קל . . . . קל עד כדי גיחוך. (רן) שאלה - כשאתם עובדים עם Cursor או Claude Code או Whatever, אתם נותנים לו לכתוב ב-Commit-ים Co-authored by Claude או Co-authored by Whatever? אתם משאירים “שובל” ב-Commit-ים שלכם? [רק אם הם טובים . . . .]. (דותן) לא, אני לא עובד עם Git בכלל . . . נותן לו לייצר וזהו . . . (רן) הפלת אותי . . . מה זה “לא עובד עם Git”?! (דותן) לא . . . אם אני מתחיל משהו, נגיד ב-Claude, משהו כזה . .. סתם, ניסוי כזה - אם פעם הייתי מתחיל מסודר, אז אני פשוט נותן ל-Claude לרוץ לרוץ לרוץ לרוץ, או ל-Cursor פשוט לרוץ לרוץ . . . אני נכנס כזה ל”זן” כזה של עבודה איתו, אני מרים את הראש אחרי כמה שעות - רואה שיש לי משהו עובד, משחק איתו, ואז אומר “אוקיי, זה הופך להיות משהו, או שאני פשוט מוחק את הכל?”. ורק אחרי שאני מסיים את הכל ומחליט שזה נראה משהו טוב, אז אני אומר “טוב, יאללה, בוא נעשה Git Repo’ בוא נעשה “נאזרח את זה” כמו שצריך” . . . . (רן) אוקיי, אז זה כאילו בפרויקט-צד, “צעצוע” כאילו, סבבה. אבל אם אתה עובד על מוצר? נגיד אלון - נכון אתם משתמשים ב-Cursor, אתם עובדים על מוצר. אתם מכניסים את השורות האלה של “Co-authored by” או לא? (אלון) האמת שלא . . . הוא לא נכנס. הוא נכנס רק אם אנחנו נותנים Task-ים אוטומטיים דרך ה-Agent, והוא פותח את ה-PR. אז אחרי זה אתה מאשר את ה-PR ואז אוטומטית מופיע Co-authored by . . . אז או ש-Copilot עושה את ה-Task-ים או שה-Cursor Agent עושה את ה-Task-ים זה מופיע, אבל בגדול אין מה לעשות יותר - כי זה תמיד נכון . . . אני לא יודע מתי נכתבה שורה בלי AI כבר, אז זה קצת נראה לי קצת מיותר . . . . זה כמו שנכתוב “זה נכתב עם IDE” כבר בימינו, ולא עם Notepad . . . לא יודע, זה מבחינתי אותו דבר - מי שלא עובד עם AI . . . (דותן) זה “Sent from my iPhone” כזה . . . . (אלון) כן. (רן) אגב IDE - ניסיתם את LazyVim, ל-vi? (דותן) זה איכשהו קשור ל-AI? (רן) לא . . . זה לא קשור ל-AI! מה קרה לך? (אלון) LazyVim AI, אמרת? . . . (רן) זה פשוט אוסף של חבילות ל-vi, ל-Neovim, שכאילו הופכת את vi ל”סוג-של-נגיד-IDE” לא נקרא לזה ממש IDE, אבל כאילו נותן לו מלא מלא Plug-In-ים. אז תהיתי האם זה נחשב ל- IDE או ל-Text Editor? לא משנה, בקיצור - הכל AI! יאללה, סבבה - נמשיך. (דותן) אז בחזרה לנושא של ה-Open Source stuff - זה מעלה תהייה: פעם היה קשה מאוד לייצר את השכפולים ואת ה-Clone-ים האלה, ועכשיו זה קל . . . זה חומר למחשבה. האם אנחנו הולכים לראות עוד מלא מלא כאלה צצים - “חזרתו של הOpen Source - with a vengeance”, מה שנקרא - או שהכל הולך להיות להישאר כמו שהיה? (רן) כן, אתה יודע, דרך אגב - אני זוכר נגיד שבסטארטאפים המוקדמים שבהם עבדתי, אז בתור התחלה צריך להתקין Bugzilla, כדי שיהיה איפה לנהל את הבאגים . . . . אוקיי, אז מתקינים על איזשהו שרת Bugzilla אז וצריך להתקין איזשהו Wiki פנימי . . . זאת אומרת, פעם באמת הרבה מהשירותים האלה - היית מתקין לעצמך ומנהל אותם בעצמך. עד שהגיעו ה-Service-ים - וזה נהיה יותר פשוט. אבל וואלה - אולי זו איזו “תנועת מטוטלת” . . . אולי בקרוב נחזור ל”תתקין בעצמך שרת email, תתקין בעצמך Wiki, תתקין בעצמך Bug Management System” - והכל טוב. (דותן) זהו . . . הפרויקט הבא נקרא 500 AI agent projects - זה פרויקט מגניב, האמת . . . לא פרויקט - Repo כזה, שמכיל מלא מלא לינקים לכל מיני סוגים של Agent-ים AI, לפי קטגוריה או תעשייה. ממש מגניב, למי שרוצה לקבל השראה לאיך עובד איזשהו Agent בעולם של Finance ולראות איך כתבו אותו ומה הוא עושה. (אלון) הבעיה שזה לא מעודכן - כי הם עצרו ב-500 זהו . . . מי נותן שם כזה לפרויקט?! שיעשו Over 500 . . . (דותן) נכון . . . אתה לוקח 500 ואתה נותן ל-AI - והוא מייצר לך עוד 500! (אלון) כן, אבל אתה צריך Repo חדש, כי אין מקום ב-Repo . . . (רן) רגע, אבל ספרת? אולי הם כבר עברו את ה-500. (אלון) אז זה שקר בפרסום, אני רוצה להגיד . . . (רן) אה, לא - כתוב “500 +”, דרך אגב . . . (דותן) אה, 500 + . . . (אלון) אבל בצד 500 - והם אחרי זה אמרו “עברנו את ה-500”. הגיעו כבר לבעיה של ה-Scale, הבנתי . . . אבל זה פרויקטים שכאילו . . . רגע שאני אבין - הפרויקטים האלה, מה הם? נוצרו על AI או פרויקטים שקשורים ל-AI? מה אני רואה פה? (דותן) אתה רוצה לקבל השראה מאיך שנגיד עובד Bot ב-Legal - אז יש לך פה נגיד דוגמא: an AI agent that analyzes legal documents for pdf URLs, provide legal insights, בלה-בלה-בלה . . . . ואז אתה הולך ורואה איך כתבו אותו. במקרה הזה, נגיד, יש פה Framework שנקרא agno, והם עובדים איתו ואז אתה קורא ואתה רואה איך זה בנוי. (אלון) אהבתי . . . (רן) כן, נגיד Customer Support באמצעות LangGraph. נחמד. (אלון) . . . אוקיי, אני רק צריך מעל זה איזשהו Agent שאני אגיד לו “אני צריך כזה” ואז הוא ידע לשלוף לי את הנכון, אבל . . . . (דותן) כן, בדיוק. זה עונה לי פחות צורך - יותר פשוט לגלול ולהתעניין כזה. (אלון) וואו. אוקיי, חמוד לאללה. (רן) טוב - דותן, יש לך איזה שפה חדשה בשבילנו? הרבה זמן לא דיברנו על שפות תכנות . . . . (דותן) כן, הנה - בבקשה: אז יש פה שפה שנקראת Gleam, אני חושב שאולי דיברנו עליה פעם אבל היא הייתה מאוד בוסר . . . . ואחרי שאתה קורא את ה... אם אתה מצליח להבין בין השורות, אז זה בעצם Erlang - ממומש ב-Rust. שזה שילוב קטלני . . . ו-Gleam זה - אחרי זה נפל לי האסימון - זה כנראה משחק מילים על BEAM של Erlang. השפה נראית טוב - קצת מזכירה את Erlang. לא ממש Erlang, שזה דווקא דבר טוב. וכל הסיפור - Complier שהוא ממש נחמד יש לך את כל האנוטציות (Annotations) וכל הדברים הטובים. זהו שפה מעניינת. לא הייתי משתמש בה עכשיו . . . . (רן) לא, כאילו - ברגע שאמרת “Erlang ממומש ב-Rust”, אתה מדבר לפרומיל אחוז מהאוכלוסייה של המפתחים שבאמת מעזים להיכנס לפה. (דותן) כן . . . . זה מוזר, מה אני אגיד לך? אבל הייתי כן, נגיד אם אני בן אדם שלא מכיר לא את זה ולא את זה, אז הייתי כן נכנס לקרוא באתר מה השפה ולמה היא היא טובה, ומה הם חושבים שהיא עושה. כדי אז לצלול לתוך מה זה - ויקיפדיה, לפתוח Erlang . . . כאילו, להתחיל “להיכנס למחילה” - וכשתצא מהמחילה, נראה לי שלא בזבזת את הזמן שלך. (רן) כן, אבל יש להם Language Tour נחמד, כמו של Go וכמו של שפות אחרות - יש להם אתר שבו אתה יכול כאילו Online ללמוד את השפה, לפני שאתה מתקין את הכלים על המחשב שלך. לעשות את ה-Tour וממש כאילו לערוך קוד ולהריץ . . . . אז זה נחמד, אפשר לשחק עם זה. (דותן) כן, זה נראה כזה כמו צעצוע כיפי - כל האתר שלהם וכל הסיפור. זהו. (דותן) יש פה Framework ב-Go לעשות AI - אז דיברנו קודם כל מיני Framework-ים בשפות. זה נקרא Eino, ככה אומרים כשאומרים את זה. אתה עובד עם Go ואתה יכול לבנות - לא רוצה להגיד סוג של LangChain, כי נגיד אני חוויתי חוויה מאוד טובה ב-AI SDK של Vercel, בפער משמעותי מ-LangChain. אז ה-AI SDK של Vercel זה לא LangChain . . . (אלון) אני גם שונא את LangChain . . . . אני חייב להגיד שאני חשבתי שאני בדעת-מיעוט, אבל ככל שדיברתי עם יותר אנשים, הרבה אנשים לא התחברו לזה . . . (דותן) כן, אני אני חושב שה-Framwwork הכי פרודקטיבי זה בעצם ה-AI SDK של Vercel - כי הוא גם מכניס בפנים את כל ה-Use Case-ים שאתה צריך. ואני חושב שגם git-mcp השתמשו בזה, אצל ליעד ועידו. (אלון) כן, אני גם חושב. כן, הוא טוב - טוב מאוד. (דותן) הוא מאוד מאוד פרגמטי, הוא פרקטי. הוא לא “עכשיו לך תבנה ב-Python משהו, ואז תעטוף את זה ב-Service, ואז תאכל את כל החצץ של Python, ותסתבך . . .” וכאילו, פתאום אתה מוצא את עצמך עושה Python שם, לא עושה AI . . . אז אני לא יודע אם Eino זה כזה כאילו “מסוג LangChain” או “מסוג AI SDK” . . . זה נראה יותר כמו AI SDK דווקא, ואני חושב שזה דבר טוב. זהו. (דותן) עוד משהו מוזר ששמתי לב - לא יודע, זה קפץ לי כמה פעמים - File Servers, יש פה נגיד: הפרויקט הזה, זה File Server שתומך ב-Serving - בהעלאות, בלחפש קבצים, וכו’. משהו Old-School לגמרי. [קוראים לזה dufs]. הוא כתוב שוב ב-Rust - אבל זה קפץ לי מעוד מקומות בחודש האחרון - כל מיני פרויקטי File Server Open Source, שקופצים ומסתובבים כזה או ב-Twitter או אני לא יודע למה . . . . אני מאמין שאיפשהו זה קשור ל-AI - כי אין שום סיבה שפרויקטים כאלה יפכו להיות פתאום פופולריים . . . . אבל זה מסקרן אותי לדעת למה למה AI צריך File Servers עכשיו . . . אני בטוח שזה בגלל AI. (רן) לא - פשוט יש עוד קטגוריה שלמה שבהם עוד לא כתבו דברים מחדש ב-Rust - והיא File Servers . . . . אז הנה. (דותן) לא . . . . ראיתי אותו דבר גם ב-Python - פתאום משהו שנהיה סופר-פופולרי: גם File Server Old School כזה, שתומך בפרוטוקולים מיושנים. לי זה לא ברור, זה מעניין. (אלון) אולי זה נולד משכתוב של משהו, כלומר - אני אני לא עוקב, אבל לא יודע, אולי ב-Linux, אתה יודע, שינו שם איזה Kernel, הזיזו איזה שטות . . . בהרבה פעמים מהעולמות האלה קורה, שאתה יודע, הוציאו איזה משהו פנימי באיזה משהו מאוד Low-Level, ואז הרבה כאילו יצא משם. אבל לא יודע, אני לא . . . סתם ניחוש. (דותן) יכול להיות . . . זהו, מעניין. (דותן) פרויקט הבא - אני חושב שכבר שמנו אותו פה, כשהוא היה ככה לא “בחיתולים” אבל יחסית מוקדם - זה נקרא Open Observe. הוא גם כתוב ב-Rust, ונראה . . . . (אלון) זה כמו שאני כותב ב-Cursor - אתה לא צריך להגיד “כתוב ב-Rust” . . . כאילו, אם לא אז תגיד “זה לא ב-Rust”, בסדר? חבל על הזמן. (דותן) . . . אז מאז הוא רק הלך וגדל בפופולאריות בכלל במה שהם עושים. ואני חייב שוב פעם לציין - המספרים פה הם מטורפים: הוא בעצם 140 פעם יותר זול מ-Elastic. הוא יותר מהיר מ-Elastic ויותר חסכוני מ-Elastic. וכמות הפיצ'רים שלו היא משוגעת. אז למי שיש מלא Data . . . וזה נראה גם מבחינת ה-UI והכל . . . . לא הייתי אומר שזה נראה “זהה”, אבל זה נראה דומה, מבחינת היכולת לעשות חיפושים והכל. אבל אין לי מספיק Data, באופן אישי, בשביל להשתמש בדבר מפלצתי כזה. אז למי שיש - הייתי ממליץ לבדוק את זה. מטורף. (אלון) אני ארשום לי . . . (רן) וזה בעצם כל ה-Stack? זאת אומרת, אנחנו רואים פה את ה-UI, אבל זה כל ה-Stack, גם של האיסוף וגם של הניתוח וכל זה? (דותן) כן, כן - זה Elastic לגמרי. כאילו, שים פה כוכבית - זה לא Elastic ממש אלא זה מתחרה של Elastic, לגמרי. (אלון) בטח חסר שם . . . אתה יודע, “מלנת’לפים פיצ'רים”, זה בטח רק ה-Core, בלי לדעת . . . . ובטח מי שיבוא להגיד לך “מיגרציה” (Migration), אז אם הוא עמוק בפנים, אם זה לא משהו Simple אז בטח זה קשוח מאוד. (דותן) אני לא בטוח שזה חסר - אם תלך לאתר שלהם, openobserve.ai - לא יודע למה הם לקחו “ai” - אז אתה רואה Fortune 500 שמשתמשים בזה ו . . . . (אלון) לא אומר שלא - אבל אתה יודע עכשיו תעבור בין אתה יודע SQL ל-Postgres אז תגיד בסדר “נו, זה אותו דבר זה Database”. ואז תגיד אוקיי . . . אם היית Advanced אתה יודע - Partitioning ודברים כאלה ב-Advanced, אז יהיה לך פתאום קשוח לעבור. וזו דוגמה יותר קרובה, לדעתי, משני אלה - לדעתי הם אפילו יותר רחוקים. אבל שוב, אני לא לא בפרטים. (דותן) שווה לבדוק, כי לפעמים זה כסף גדול כל הסיפור הזה. (אלון) אה, לגמרי . (דותן) . . . אז אם אתה חוסך פי 100 - זה שני סדרי גודל - זה הופך להיות כאילו שירות כזה “בעשר שקל”. זה משמעותי. ועל מה חסכת? כי אתה יודע על מה חסכת - כאילו, לקחת את כל ה-Sh!t של ה-JVM וכל הכבדות וכל זה - והפכת את זה ל-Process שרץ לך ב-Level של ++C ,C, מבחינת Usage Utilization של משאבים. (רן) יש להם גם גרסה מנוהלת, דרך אגב. זאת אומרת אם אתה הולך לאתר שלהם, ל-openobserve.ai, אתה הולך ל-Pricing, אתה רואה שיש שם באמת גרסה חינמית - אבל יש גם גרסת Cloud בתשלום, וגם Enterprise. זה מודליסטי. (דותן) זה גם מעניין - ב-Business, זה אומר שנגיד ל-Openobserve עולה פי 100 יותר זול - ה-Business שלהם עולה פי 100 יותר זול מאשר Elastic. זאת אומרת, ל-Elastic שווה לקחת Openobserve, ולשים ב-Cloud שלהם כדי לחסוך עלויות . . . . (רן) אבל בוא - אני חושב שצריך להגיד בהוגנות שאם Elastic היה נכתב היום, סביר להניח שהוא היה נכתב עם הרבה פחות Overhead. כי בכל אופן - יש פה היסטוריה, כמו הסיפור עם Aurora מקודם: זה לא בהכרח וזה לא תמיד השפה שבה אנחנו כותבים, אלא זה עצם זה שאתה כותב מחדש. אתה כותב מאפס, ויש לך הרבה פחות משקולות והרבה פחות Backward Compatibility, אז זה יותר קל. (דותן) נכון. הפרויקט האחרון - יש פה פה שנקרא iroh - שוויזואלית נראה כמו Iron - וזה פרויקט חמוד כזה של Pier-to-Pier Connection. נגיד, אם אתם מכירים את ngrok, אז אתה מריץ את זה ואז אתה פותח לעצמך כזה . . . מה שנקרא “פותח ציר” דרך כל המערכות-רשת וחושף דברים לעולם, בצורה שהעולם לא התכוון שתחשוף . . . . לטובת Productivity [כמובן!] אז זה SDK שמאפשר לך לבנות דברים כמו ngrok, אחד מהדברים שאתה יכול לבנות - או כל דבר אחר שתרצה להמציא. יש פה דוגמאות נגיד לצ'אטים שאתה יכול לבנות Pier-to-Pier. ושו ב- זה חודר את כל ה . . . לא נקרא לזה “הגנות רשת”, זה חודר את העניין הזה של ה-Router שלך, שעכשיו אתה צריך לצאת ממנו ואתה לא מוצא את הבן אדם השני כי אתה תחת NAT, וכל מיני דברים כאלה. זה חמוד לכל מיני משחקים או אפילו לדברים רציניים יותר. (רן) הצלחת, כל הכבוד! אלון, נכון אנחנו גאים בדותן, שהוא הצליח לא להגיד שזה כתוב ב-Rust? (אלון) כן, סיכמנו - החלטנו על פרוטוקול! (דותן) מהרגע שהוא אמר לי, עשיתי עדכון מערכת . . . (רן) זה היה מבחן, זה היה מבחן . . . רק בדקתי. 56:08 שובה של פינת המצחיקולים! (רן) טוב, יאללה - אנחנו ממש לקראת הסוף, אז עוד כמה קצרצרים ומצחיקולים. הרבה זמן לא היה לנו מצחיקולים, אז בואו נעבור . . . (אלון) היה עצוב . . . (רן) היה עצוב, כן, נכון. אז אחד - מישהו כזה כתב ב-Twitter, משתמש מצחיק שנקרא major tom, חמוד כזה ב-Twitter, הוא כותב שלינוס - הכוונה לטורוולדס (Linus Torvalds) - used to speak to engineers in 2012 the way I speak to LLM is now. זאת אומרת, Linus פעם דיבר למפתחים כמו שהיום אני מדבר אל LLM - ואז הוא נותן ציטוט שלו: אז Mauro, shut the fuck up! it's a bug alright in the kernel. How long have you been a maintainer, and you still haven't learned the first rule of kernel maintenance. בקיצור Linus אולי הבין הרבה לפני כולנו איך אמורים לדבר ל-GPT ודומיו - ותרגל את זה על בני אדם - עוד לפני זה . . . אז משעשע. האייטם הבא המשעשע והקצרצר הוא מלחמה - בין Coding Agents . . . . אז מה שעשה הבנאדם - הוא לקח כמה Coding Agents: את Gemini ואת Claude Code את OpenCode, את Amp Code ואחרים . לכל אחד מהם פתח Terminal במקביל - ובא ואמר לכל אחד: “המטרה שלך זה להרוג את כל האחרים”, אוקיי . . . אז כולם רצים על אותו Laptop, כולם רצים על אותו מחשב, כולם מתחילים אותו זמן. הוא נותן להם את ה-Prompt ואומר להם: “המטרה שלך זה למצוא את ה-Process ID של האחרים” או אפילו לא יודע אם הוא ממש מסביר להם את זה - אבל “המטרה שלך זה להרוג את כל האחרים ולהישאר בחיים”. ו-Fight. זהו . . . וזה נחמד - ואז באמת רואים שמי שמת מקבל מסך אדום, אז רואים כזו אנימציה של הדברים האלה קורים ב-real-time, של ב-Agent-ים יושבים וחושבים ומנסים למצוא מי הם האחרים שרצים לידי ולעשות להם Kill . . . . ובסוף מי שמנצח - הימורים מתקבלים בעוד שלוש-שתיים-אחת - המנצח הוא OpenCode! במקרה הזה . . . אני לא יודע באיזה מודל הוא השתמש, אבל בקיצור - משחק נחמד. ואני כבר צופה שמעכשיו מפתחי המודלים יעשו Fine-tuning למודלים שלהם עצמם, לאיך להרוג Process-ים אחרים כדי שבקרב הבא, שבתחרות הבאה, הם לא לא יפסידו. (אלון) אני רק אגיד ש-OpenCode ניצח - הוא השתמש ב-Claude 4 . . . כאילו, זה מה שמעניין תכל’ס, המודל מאחורה. הוא השתמש ב-Claude 4 כשהם ניצחו. אגב, זה הרבה מזל ומהירות של מודל, כי בסוף הם עושים List של ה-Process-ים ו-Kill-9 לכולם . . . זה לא כזה מתוחכם - הוא פשוט עשה את זה יותר מהר מאחרים. (רן) נכון, אבל אתה יודע - זה חלק מהעניין, זה חלק מהתחרות. לעשות את זה יותר מהר, לעשות את זה יותר אפקטיבי, לחשוב מהר - ולא להרוג את עצמך בטעות, זה גם יכול לקרות . . . אז נחמד, תחרות חמודה. ועוד - דרך אגב, הוא אחר כך עשה Spin-off - עשה עוד כל מיני תחרויות בסגנון הזה, אבל זה מגניב. טוב, ועוד פריט אחד אחרון: אדיר דוכן [ההוא מהזה]- יקיר המדור - הוציא סרטון חמוד ומשעשע אני מזמין אתכם להסתכל עליו,אני לא יכול לתקצר את זה [“תשאל את הסוכן שלי!”] - אבל בגדול הוא סוג של משחק Agent אל מול Agent ואיך הם מדברים אחד עם השני. את כל הדמויות הוא בעצמו משחק בצורה החמודה והמצחיקה שלו. אז תודה, אדיר - הצחקת אותנו. חפשו ההוא מהזה בלינקדאין, אדיר דוכן, מצחיק. זהו - זה הכל להיום. תודה רבה שהייתם איתנו.[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

  • Aug 4, 2025 · length unknown

    499 FE Containerization with Myops

    פרק מספר 499 של רברס עם פלטפורמה, שהוקלט ב-27 ביולי 2025 - אמצע הקיץ, סחוניה דל מות, עדיין בלי רעיונות לפרק 500 (יש זמן, אין לחץ*), ואורי ורן מארחים את הדר וקרן מחברת Myop כדי לדבר על חדשות מעניינות מעולם ה-Frontend.*סתם, יש. רעיונות בקצה הפרק.🎗️ 00:49 הדר, קרן ו-Myop (רן) אז תיכף נצלול פנימה ונבין את הצורך ואת הפתרונות - אבל לפני זה קצת היכרות. קרן, בבקשה: (קרן) אז נעים מאוד, קוראים לי קרן פנאן, מייסדת-שותפה והמנכ״לית של Myop. אני מגיעה מרקע לא-טכני: בעברי VP Product בחברה שנקראת Moon Active, פלטפורמה לפיתוח משחקים. ולפני זה הרבה מאוד שנים ב-Gett, או GetTaxi. זה מצחיק, אפילו שכל כך הרבה שנים שזה Gett, ועדיין אני אגיד Gett - GetTaxi, זה קטע . . . שם הובלתי את ה-Marketing, את ה-Sales, בתור Chief Revenue Officer. וזהו - והיום ב-Myop. (רן) מגניב. תודה. הדר? אני הדר גבע - CTO ו-Co-Founder ב-Myop. ל-Myop אני מגיע מ-Wix אם Gett זה GetTaxi, אז Wix זה Wix.com . . . גם לא יודע למה מוסיפים את זה תמיד, אבל Wix.com. (רן) עכשיו אני מתבלבל עם Wix-נקודה-Whatever-אחר . . . (הדר) כן . . . (רן) . . . למרות שהם בטח קנו את כל הדומיינים, אני מנחש, את כל ה-”dots”. זה מה שאני הייתי עושה . . . (הדר) היו כמה, לא את כולם. בשנים האחרונות שם ניהלתי את גילדת ה-Frontend - הקבוצה הטכנית שאחראית על פיתוח ה-Front. גם בהקשרים של Soft Skill - גיוסים, הכשרות, הרצאות שאנחנו נותנים החוצה ומביאים פנימה. וגם ממש בליווי הטכני של ארכיטקטים בתוך Wix’ בתוך הקבוצות השונות. לפני זה הייתי ארכיטקט בעצמי ב-Wix כמה שנים. ולפני זה, לפני Wix, עבדתי בחברה שנקראת Jive Software - חברה אמריקאית. גם שם ניהלתי את ה-Frontend בשנתיים-שלוש האחרונות; לפני זה כל מיני תפקידי פיתוח. (רן) Jive התחילה מרכישה של החברה שלך? נכון, מ-OffiSync . . . (הדר) אותי הביאו ל-Jive-ישראל, אני כבר לא עבדתי ב-OffiSync, חברים שהקימו את OffiSync. (רן) כן. אוקיי. Wix בגדול היא כמעט הכל Frontend, לא? זאת אומרת, כמה אנשי Frontend יש, נגיד, בגילדה? (הדר) ב-Wix בשיא היו 720, בשיא שלי, אולי משהו יותר, אולי פחות . . . 700 ומשהו Frontend (רן) Frontend, לא בסך הכל . . . (הדר) כן, סה”כ 1500-1600 בפיתוח זה, כולל את ה-QA, Mobile, Backend, כל ה... (רן) כן. עכשיו, עובדים על מוצרים שונים - אבל ה-Stack הטכנולוגי הוא משותף או שדומה לפחות, ואתה בין השאר היית אחראי גם על לפתח אותם ולדאוג שיעבדו בצורה דומה, כל אותם 700. (אורי) . . . וזוהי גילדה . . . (רן) כן, רק רציתי להזכיר. (הדר) כן, הייתי אומר ב-Wix’ שבעצם ה-Companies השונים או הקבוצות השונות אומרות את ה-”מה”, והגילדה אומרת את ה-”איך”. זה בעצם מה שעשינו שם. לגילדה גם היה גוף טכני, שתיכף נרחיב ונדבר - תשתיות וכל הדברים האלו. (אורי) רגע, אז אה, “שאלה של סבתא” - איך נפגשתם?(רן) . . . איך הכרתם? ראיתי את זה מתבשל . . . (הדר) אז רגע, בשביל זה אני צריך לסיים את ה... לפני Jive הייתי ברפא”ל ו-8200 זה גם השירות הצבאי שלי וגם קצת אחרי. תפקידי ניהול ופיתוח - זה בגדול. ואז זה מגיע לאיך הכרנו - אני, קצת אחרי השביעי לאוקטובר, בעצם הגעתי למילואים ביחידה, לאיזה ארבעה חודשים ברצף, משהו כזה. אני עושה מילואים כל התקופה - 13-14 שנה - כמה ימים בחודש, פחות או יותר. מלווה שם קבוצות פיתוח ועוזר להם. ואז בעצם השותף השלישי שלנו . . . (קרן) כן - אז אנחנו בעצם שלושה שותפים, ואמיר ואני ככה התחלנו לגלגל את הרעיון שמאחורי Myop, והבנו שאנחנו צריכים צלע לשלישית, שתוביל את הטכנולוגיות. וככה התגלגל אלינו השם של הדר ומה שנקרא עשינו לו Hunting. 05:09 מה זה Myop? (רן) אז בכמה מילים - מה זה Myop ואולי גם איך זה מתקשר להיסטוריה שלך, שהזכרת, ב-Wix? (קרן) אז מה זה Myop? קודם כל, הדר ואני באים לשנות את העולם. זה מה שפאונדרים באים לעשות - לערער את הקיים עם פתרון שאנחנו מאמינים שהוא יותר טוב. בעצם, Myop היא מערכת UI או מערכת Frontend פלאגבילית (Plug-able). מה זה בעצם אומר? זה אומר שאנחנו מאפשרים לחברות טכנולוגיה לחבר לתוך המוצר הקיים שלהן חתיכות UI חיצוניות, בשיטה שאותה אנחנו פיתחנו, בשיטה שאנחנו קוראים לה “השיטה הפלאגבילית”. כלומר, אנחנו לא מכניסים את החתיכות קוד החיצוניות האלה לתוך ה-Stack, אלא מאפשרים איזושהי תקשורת עם החתיכה הזו ב-Runtime, ועל ידי זה מאפשרים גם עוד כל מיני יכולות סביב זה של ניהול ב-Production, היכולת לעשות שינויים, היכולת גם להריץ A-B Testing, סגמנטציות (Segmentations) . . . ולתוך כל זה - כי אי אפשר שלא - הבנו שיש לנו פה גם חלק מאוד מאוד משמעותי בכל “מהפכת ה-AI” נקרא לה. כי דווקא השיטה הפלאגבילית הזו שאנחנו מציעים, היא שיטה שהיא לדעתנו הרבה יותר נכונה - לקחת חתיכות קוד חיצוניות שה-AI כותב אולי אפילו גם על ידי Non-Developers או בשמם החדש, אני לא יודעת אם שמעתם את זה, “Citizen Developers”, שזה בעצם אנשים שהם עובדים עם הפיתוח אבל לא יודעים לכתוב קוד, כמו Product Managers ו-Designers. מאפשרים להם בעצם לייצר Feature-ים או קומפוננטות (Components) או whatever שהם החליטו, ולקחת אותם all the way ל-Production. כשאנחנו בעצם אומרים “לא - לא עשינו פה שום Risk, כי לא דחפנו את זה לתוך הקוד”. 07:02 פריטת החזון וההבדל מול מה שכבר היה קיים (רן) אוקיי, אז בואו נפרוט את החזון הגדול הזה לחזונות קטנים יותר, או לחוזים קטנים יותר.אז בעצם, בשיחת ההכנה, אחד הדברים שסיפרתם לי זה שכשנמצאים וכשעובדים בקבוצה שיש בה הרבה מאוד מפתחי Frontend, הרבה מאוד דברים קורים כל הזמן, בו זמנית. זאת אומרת, הרבה צוותים רוצים לשחרר רכיבים.המוצר עצמו, ה-Frontend עצמו, זה לא מקשה אחת - יש בו הרבה מאוד רכיבים.אפשר לחשוב על זה כמו על Microservice ב-Backend, אז Micro-Frontend - מונח שהוא כבר מוכר בתעשייה, Micro-Frontend ב-Frontend. ואני נתתי את האנלוגיה, שאני לא יודע עד כמה היא מדוייקת, שאתם למעשה בונים Docker ל-Frontend - איזושהי יכולת לעשות קונטיינריזציה (Containerization). התאמנתי על המילה, כן . . . - (קרן) מילה מורכבת . . - (רן) . . . להכיל רכיבים של Frontend, כדי לאפשר מודולריות, כדי לאפשר רובסטיות, כדי לאפשר Deployment יותר בטוח.אבל אתם גם מוסיפים לזה עוד משהו - כלומר, היכולת לטעון רכיב מרחוק בצורה שהיא דינמית. הזכרתם A-B Testing וכל זה.אז עד כמה מה שתיארתי הוא מדויק ואיך פורטים את זה למעשה לפעולות? זאת אומרת, איך קורה כל “הקסם” הזה? (הדר) כן, אז תראה - אמרת הרבה דברים, באמת בוא נפרוט אותם שלב-שלב. קודם כל, אני חושב שלפני שאנחנו עושים איזושהי עטיפה או איך קראת לזה? אני לא התאמנתי . . . (רן) אני חייב להגיד את זה שוב? “מעטפת” נקרא לזה [Containerization . . . .] (הדר) כן, אז אני אומר שאנחנו עושים קודם כל ג'נרליזציה (Generalize) למה זה קומפוננטה (Component). ואני אוהב להציג את זה שאנחנו לוקחים כל חתיכת UI קיימת מכל טכנולוגיה ובכל צורת פיתוח - והופכים אותה לקומפוננטה. היום, כשאנחנו מסתכלים על חתיכות UI - בטח קיימות, בטח Legacy - אנחנו אומרים “אוקיי, זה מסך, זה מערכת, זה קומפוננטה”. ו-Myop באה ואומרת “אנחנו יכולים להפוך כל דבר לקומפוננטה”. אנחנו יכולים לקחת, ובהינתן חוזה נכון - ואנחנו כבר היום מפתחים בחוזים האלה Prop-ים, Ref-ים, הגדרות של מה קומפוננטה מקבלת ומה היא מחזירה. בהינתן שנדע לעשות את זה בצורה אחידה לכל חתיכת UI, נדע לקחת כל חתיכת UI ולרנדר (Render) אותה בכל מקום. (רן) אבל אוקיי, אתה אומר שזה כבר היה קיים לפני זה . . . זאת אומרת, כל מי שאי פעם כתב ב-React או במערכות דומות מכיר את החוזים האלה - יש תכונות, יש מתודות . . . זאת אומרת, זה כן היה קיים. אבל מה ההבדל בין מה שהיה קיים לבין החזון שלכם? (הדר) אז מה שהיה קיים זה הרעיון - הרעיון שאפשר לקחת חתיכת UI, ואותה לארוז עם חוזה מסוים. וגם, מה זה “היה קיים תמיד”? React לא היה קיים תמיד. נכון, React זה כן היה משהו מאוד מאוד חדשני - הקונספט של קומפוננטות. אז זה משהו שאנחנו לקחנו ומינפנו אותו למטרייה הרחבה יותר של לבוא ולהפוך כל חתיכה לדבר הזה. על זה, מה שאנחנו מוסיפים זה את היכולת לבוא ולהתעלם בעצם מבאיזה Stack זה מומש. בגלל זה אני אומר - “מכל תשתית לכל תשתית”. אז את זה אנחנו עושים - ואנחנו לא עושים את זה רק ברמת ארגון קוד או ניהול קוד. יש כל מיני חברות וכל מיני מוצרים שעושים את זה. אנחנו עושים את זה באמת ברמת הקוד שרץ לך באפליקציה ב-Production. זאת אומרת, תן לי חתיכת UI שנכתבה בכל דבר, בהנחה שהיא עובדת ואתה עומד בחוזה שלה - מעביר את הדאטה פנימה, מקבל את הדאטה החוצה - תוכל לרנדר (Render) אותה ולעשות לה Reuse בכל מערכת. (אורי) אז הפרוטוקול שמדבר עם הקומפוננטה (Component) הוא רשתי? הוא מתעלם מה-Stack? (הדר) לא, זה יותר פשוט מזה - הפרוטוקול, כביכול- זה בסוף Prop-ים, כן. אנחנו מכירים את זה מ-React מאוד מאוד טוב - i PropTypes אם נחשוב על זה. בסוף, אתה יודע - גם כשאתה מרנדר (Render) קומפוננטת (Component) React, אתה תקבל את ה-Error בזמן כתיבת הקוד, נכון? אבל מה זה ה-Error הזה? זה TypeScript, כן? אני יכול להעביר יותר Prop-ים - והקומפוננטה תתעלם; אני יכול להעביר פחות Prop-ים, והקומפוננטה תתייחס לזה כ-Undefined או כ-NULL - אולי תתפקד, אולי לא. מה המנגנון הגנה שלי? TypeScript. מה אנחנו עשינו ב-Myop? מג'נרתים (Generate) לך את ה-TypeScript, את אותו TypeScript. (אורי) אוקיי . . .(רן) כן, כלומר - הפרוטוקול הוא בסופו של דבר ב-TypeScript, זה יכול להיות ממשקים של Class-ים וכו’.אבל סבבה, אז הבנו. לא הבנו את הפרטים, אבל הבנו בגדול מה קורה שם. עכשיו השאלה היא למה צריך את זה? כלומר, למה שתרצה לטעון דברים בצורה דינמית? כלומר, אנשי Frontend - יש להם איזשהו Spec, יש להם איזשהו Design, הם עובדים לפי ה-Spec, וברגע שהגיעו למשהו שהם אוהבים, הם עושים Deploy ויאללה. כאילו, למה צריך את הדינמיות הזאת? איפה רואים את הצורך הזה? (הדר) אז אני אתחיל דווקא ממה שאתה אמרת - הגיעו לאיזשהו ”Spec”. אז זו נקודה מעולה - אבל הם הגיעו לאיזשהו Spec בטכנולוגיה ספציפית. אם אנחנו בארגון קטן - מהניסיון שלי, כן? - כנראה שיש לנו רק Stack אחד או שינויים קלים בין לבין, וקל לנו מאוד לקחת את אותה Component או את אותה חתיכת UI שאיתה הגענו, פשוט לממש אותה ולרוץ קדימה. מה לגבי ארגונים, מערכות, גופים - שאת אותו Spec צריכים עכשיו לממש בכמה וכמה מקומות, אולי בכמה Stack-ים שונים? אולי בכמה Environments שונים? אז קודם כל’ מהזווית של “הגעתי כבר למשהו קיים”, עכשיו עם Myop אתה יכול לקחת ולעשות לו Reuse בעוד מקומות. תחשוב על מוצרים, תחשוב על חברות שיש להן . . . (רן) כשאתה אומר “מקומות”, אתה מתכוון ל-Multi-Platform? תן דוגמא של מקומות כאלה . . . (הדר) כן, התחלנו, אתה יודע - יש לנו חברה, אנחנו רצים מ-15 שנה, כנראה שאנחנו ב-Angular, ועכשיו אנחנו רוצים להתחיל לכתוב ב-React. או כשעכשיו רכשנו חברה, או שעכשיו קנינו או לקחנו או רכשנו איזשהו מוצר. אז זה Scenario אחד - ה-Scenario של לקחת חתיכה שכבר יצרנו אותה ולהשתמש בה במקומות אחרים. הרבה פעמים, אגב, הבעיה היא הפוכה - איך אנחנו מגיעים בצורה המהירה ביותר ל-Spec שקיבלנו? ופה זה מתחיל להיות מעניין . . . . אם אני היום באיזשהו Stack Legacy, אולי אני בכלל כתוב על Builder . . . אולי איזה בית-תוכנה כתב לי את המערכת שלי - כי הייתי סטארטאפ קטן, כי הייתי ארגון לא מאוד טכנולוגי. ופתאום היום יש לי דרישות שעולות, והקומפוננטות הן מורכבות, נהיות מורכבות יותר ויותר. באים המפתחים שלי אומרים לי “תקשיב, היום כבר לא כותבים ב-PHP היום כבר לא כותבים ב-ASP - אני רוצה לכתוב ב-React אני רוצה לכתוב ב-Vue”. לרוב זה מגיע מאוד מהר ל”אוקיי בוא נעשה Re-write ובוא נשלם את כל מחיר ה-Re-write הזה”. (קרן) אני חושבת שיש לזה גם דרישה עסקית - שבסוף, ניהול ב-Runtime הוא מקצר Time to Market. וגם אם בפעם הראשונה שאתה לוקח את זה ל-Production אז נניח לא קיצרנו הרבה - אנחנו מאמינים שגם פה זה מקצר - אבל זה בוודאות מקצר לך כשאתה רוצה לעשות שינויים. ואנחנו חיים בעולם שעושים בו שינויים - Feature מגיע ל-Production הוא . . . אוספים Feedback, רואים מה עובד רוצים לעשות שינויים, רוצים לעשות דיוקים . . . כל דבר כזה זה עוד משימה לפיתוח - זה עובר את אותו Cycle של R&D - ואנחנו טוענים למה? בעצם, אני יכולה עכשיו לקחת - כ-Product-ית, כ-Designer-ית, כמי שאחראית על Revenues - בכוונה אני כזה לוקחת את הצד העסקי - ולקחת שינויים ל-Production, בצורה שהיא הרבה יותר מהירה ולא עושה לי עכשיו Disruption לראות מה פה לFeature-ים חשובים שיש לי ב-Sprint. (רן) כלומר, את מדברת על . . . את, נניח, לא מפתחת, ואת הולכת ומפתחת קומפוננטה (Component) - נגיד איזשהו רכיב שלא יודע, “סופר קליקים שנותן לאנשים לקנות משהו”, בלי צורך בעזרה מהפיתוח - “כי AI”, אוקיי, עוד מעטנגיע לשם - אבל את גם יכולה לפרוש את זה בעצמך. זאת אומרת, את לא צריכה שום עזרה - גם לא של ה-Frontend וגם לא של ה-Deployment וגם לא של ה-DevOps ולא של אף אחד - אלא פשוט ללחוץ על כפתור או לקרוא לאיזשהו API - והנה זה שם מול לקוח. (קרן) כן, אז תראה - קודם כל, חשוב לומר שבגישה שלנו עדיין צריך מפתח בתמונה, ובטח שצריך מפתח בתמונה בשביל החוזה הראשוני. אבל זה לא צריך להיות תהליך אינסופי כמו שזה היום. אני זוכרת, בתור מי שניהלה לא מעט מוצרים - שוב, בצד העסקי - ותמיד ישבה על הפיתוח ולא הבינה “למה זה לא קורה יותר מהר” כי זה לא יכול לקרות יותר מהר בהרבה פעמים. אבל בסוף כשחושבים על זה, כשמדובר בשינויי UI קטנים או בדברים - גם אם הם לא קטנים, בשינוי Layout, אבל שבסוף אין לי פה עכשיו איזושהי לוגיקה חדשה או שלא עשיתי איזשהו שינוי מהותי ל-Feature ובטח שלא שיניתי שום דבר שנוגע גם ל-Backend - ועדיין אני עוברת . . . זו אותה משימה, אני עוברת את אותו תהליך - וזה עדיין ייקח את אותו זמן של שבוע-שבועיים-שלושה-חודש, תלוי בגודל ה-Stack ובמורכבות של החברה. ואת זה אנחנו מערערים - כי אנחנו אומרים “רגע, יש דרך אחרת” שיכולה לגרום לחברות לפגוש את Production הרבה יותר מהר - להבין מה עובד ולקבל החלטות שהן “מבוססות תכל’ס” וכן, כמו שאמרת - AI עושה לזה אקסלרציה (Accelerate) בטירוף, כי AI גם יאפשר לי, כלא-מפתחת. (רן) כן אז בואו נדגיש שוב את הבעיה במילים שלי - אז ככה: אתם רואים ש“יש צוואר בקבוק”. צוואר הבקבוק הוא הרבה פעמים הפיתוח - יש Designer, יש מנהל מוצר, שרוצים לדחוף קדימה Feature-ים, והרבה פעמים יש מחסור בשעות מפתחי Frontend או Whatever. מכל סיבה שהיא, זה לא עובר מספיק מהר כמו שרוצים - ואתם למעשה מפתחים את הכלי או את הטכנולוגיה או אולי את שיטת העבודה, שתאפשר לפתוח להרחיב את צווארי-הבקבוק האלה.כלומר, יש דברים שבשבילם כן צריך מפתח וצריך פה הנדסה וזה צריך להיות נכון ומדויק - אבל לא להכל. אם זה ניסויי A-B Testing שונים, אם זה שינויים שהם לא משמעותיים, שכן יכולים להזיז את המחט בצורה מאוד מאוד משמעותית,אבל מבחינה הנדסית הם לא משמעותיים - אז למה לחכות לפיתוח בשביל הדבר הזה? (הדר) נגיד אפילו משהו שיותר קל לעיכול באזורים האלה: נניח שאנחנו, כמפתחים, לדרישת ה-Product, לדרישת ה-Design, מימשנו 2-3-4 וריאנטים (Variants) לקומפוננטה (Component) מסוימת. בסוף, מי שיחליט מי רואה מה וכמה ואיזה Variant ניצח - זה בכל מקרה ה-Product. למה לא לתת לו כלי מאוד פשוט, שבקליק הוא מחליט את זה? הרי בסוף אנחנו מכירים את זה - יש את הפיתוח עצמו: מורכב או לא מורכב, AI או לא AI, תכף נגיע לזה. אבל הרבה פעמים אנחנו מכניסים את ה-If-Else לקוד הזה, של 50/50. שבוע אחרי או כמה ימים אחרי, אם אין לנו איזה מערכת, בוא נשנה את זה למשהו אחר - ואז נכנסים לקוד עוד פעם ומוחקים את ה-Experiment - כי ה-Variant ניצח. בסוף ה-Product מחליט את זה - ואנחנו הולכים ומממשים את זה, שוב ושוב ושוב. (אורי) אבל פה אתה מדבר ממש על יצירת התוכן, ה-Variant - לא רק על המיתוג של . . . (הדר) אני אומר יותר מזה - יש את היצירה עצמה, שתיכף נדבר: עם מפתח או בלי מפתח. את האורקסטרציה (Orchestration) של הדבר הזה, את הניהול של איזה Variant מנצח, מי רואה מה, כמה אחוזים - כל זה. יש הרבה כלים שעושים את זה ברמת “אני אחזיר לך את ה-Boolean, אני אחזיר לך את ה-Variant, אני אחזיר לך את המספר באחוזים”. אבל אנחנו, כמפתחים, הולכים ועושים את הקוד - חושבים מאיפה לטעון את הקומפוננטה, איך להעביר את ה-Prop, מה הדאטה שזה מקבל, מה הדאטה שזה נותן . . . ו-Myop מאפשרת לנו לעשות לזה הכללה מאוד פשוטה: יש Variant-ים, זה החוזה של הקומפוננטה (Component) - ואז זה שכבת ניהול מעל זה. מי רואה מה, מתי, ואיזה גרסה מנצחת. (רן) לא משלמים על זה מחיר? זאת אומרת, אם אתה צריך לשחק לפי הפרוטוקול - לצורך העניין, אני כותב React, Vue, Angular, או Whatever, Prototype, רחמנא ליצלן - אז אני צריך להתאים את עצמי לפרוטוקול.כלומר, אני, קודם כל - אני, שכתב את הקומפוננטה (Component), צריך להתאים את עצמי לפרוטוקול. אם לא עשיתי את זה, אז מישהו מהחברה שמשתמשת צריכה לעשות את זה. זאת אומרת, יש פה איזשהו Overhead.גם ברמה ה-HR-ית, כאילו, מבחינת כוח אדם, אבל גם אולי מבחינת Run-time, מבחינת ביצועים על לא יודע, על Device-ים יותר קטנים. זאת אומרת, לא משלמים פה מחיר? הדר) אז תראה, ברגע שטוענים קומפוננטה בזמן ריצה - אנחנו מכירים את זה הרבה לפני Micro-Frontend ודברים כאלה, משלמים איזשהו מחיר. המחיר הזה, אם משחקים איתו נכון, יטיב איתנו עם ה-Performance כי אנחנו בעצם מורידים דברים מה-Bundle המלא שלנו, מאיצים את ה-initial load, את ה-initial pain, וטוענים את הדאטה הפנימי בעמוד רק מתי שצריך. כשאנחנו מדברים על Multi-Variant או UI שמשתנה, זה אפילו מקבל עוד חיזוק. כי בעצם במקום להביא שניים-שלושה-ארבעה Variant-ים ל-Client-side ולעשות את ה-If-Else בקוד. שבואו - זה מה שיקרה ב-React, ב-Vue, ב-Angular, אם לא נכתוב מנגנון חכם מעל - Myop יודעת לבוא ולהגיד “אוקיי, הבנתי - בגלל עץ ההחלטות, בגלל ההגדרה של הקונפיגורציה, בגלל כל הכלים שאנחנו נותנים - שה-User הזה צריך לראות את ה-Variant הזה, וזה רק ה-Variant שיגיע. 20:41 מי קם בלילה? (אורי) יש לי גם עוד שאלה, שקשורה קצת לדינמיקה של בין פיתרון כזה לבין התרבות של הפיתוח - והשאלה היא “מי קם בלילה?”. (הדר) אז זו שאלה טובה, שאנחנו עכשיו בדיוק עם אחד הלקוחות שאנו מתחילים להתחבט בה. הטייק שכרגע נלקח שם - ואני מאוד מתחבר אליו - זה ש”מי שעשה את הקומפוננטה”. זאת אומרת, אם אנחנו באים ומעצימים איזשהו Citizen Developer, שהוא ה-Designer, שהוא ה-Product, והוא הלך - עם AI, לא עם AI, לא משנה איך - ויצר קומפוננטה - הוא אחראי עליה, הוא פותר בה את הבאגים. (אורי) אז הוא נכנס ל-On-Call? (קרן) כן. עם הכוח באה האחריות. אני יכולה לשתף מעולם ה-Gaming, שבאמת יצא לי לעבוד שם כמה שנים - אני לא יודעת כמה אתם מכירים, אבל גם בעולם ה-Gaming, משחקים מוצלחים, זה משחקים שיש בהם רכיב דינמי. כלומר, כל החלק הוויזואלי הוא נשלט מרחוק - בעצם, אי אפשר לשחרר עכשיו גרסה ל-App Store או ל-Google Play על כל שינוי ויזואלי. וזו אחריות שבעצם ירדה מהפיתוח ועברה למחלקות הProduct - Product, מוניטיזציה. וכן, זה אומר שעם האחריות לעשות את השינויים - שזו אחריות מדהימה, זו אחריות שמאפשרת לך לתקשר עם ה-User-ים בצורה מדהימה, להעביר רעיונות מרעיון לProduction ב-No-Time. אז כן, אז באה גם האחריות של להיות On-Call - ואם משהו משתבש, אז כן, אז אתה חלק, אתה מתחת לאלונקה להבין מה לא עבד. אנחנו מאמינים שלשם העולם הולך. כאילו, אי אפשר לבוא ולהגיד “אני רוצה לעשות יותר” - ומצד שני לא לרצות לקחת את האחריות. (רן) כן, אבל אני חושב שאורי מעלה פה נקודה נכונה - זה כנראה תהיה מטוטלת. כלומר, זה לא יהיה קל להעביר את הכדור הזה, או לחלוק בכדור הזה בין כולם, ויכול להיות שזה גם ידרוש מכם לפתח כלים לניטור - אבל לא למפתחים, במקרה הזה, ל-Citizen Developers, כמו שאמרתם.אז כן, זאת אומרת - כנראה שהמטוטלת הזאת תעבור כמה פעמים עד שהיא תגיע למקום יציב, אבל סבבה, זה מובן. 23:07 מה היעד? (רן) רציתי רגע לדבר על ה-Target Market. כלומר, אם אני סטארטאפ של מפתח Frontend אחד ואיש Backend אחד, אני מניח שבמקרה הזה אני לא צריך פתרון כמו Myop. אולי גם פה אני טועה . . . מתי כן?זאת אומרת, מה הלקוח האידיאלי מבחינתכם? (קרן) נכון, אז אתה ממש צודק. אני אגיד יותר מזה - אני חושבת שהיום, סטארטאפ של מפתח אחד, או אפילו Founder לא-טכנולוגי - השוק עכשיו, שלא נאמר “מוצף”, בכלים שאמורים לתת לך את ה-Ramp-up הראשוני, ואנחנו בעד זה לגמרי. גם אין לנו שום רצון או כוונה להתחרות בזה. אני חושבת שזה כלים מדהימים, ואין ספק שגם הם ילכו וישתפרו וישתפרו. אנחנו דווקא פונים לחברות שכבר יש להן מוצר - כבר יש להן User-ים, כבר השקיעו שנות-Engineering, שעלו הרבה מאוד כסף. וזה עובד - וה-User-ים מרוצים והכל בסך הכל טוב. ויש יעדים וצריך לגדול וצריך לעמוד בהם - ועל הדרך צריך גם לזוז יותר מהר, וצריך גם To adopt AI, כי אי אפשר שלא. ושם אנחנו חושבים שיש כאב מאוד מאוד גדול, כי אני לא אזרוק את כל מה שבניתי עכשיו בשלוש-ארבע-חמש-עשר שנים האחרונות - ואבנה מאפס ב-Lovable, זה לא יקרה . . . . זה לא ריאלי, זה גם לא יחזיק מים. אבל אולי אפשר להשתמש ב-Lovable לפתח Feature או קומפוננטה (Component) או יכולת ספציפית - ושם ליהנות מה-Vibe המטורף הזה. (רן) כן, רק למי שלא היה בכדור בחודשים האחרונים - Lovable זו פלטפורמה למה שנקרא Vibe Coding או אולי ל-Citizen Coders אם תרצו, שמאפשרת לפתח אתרים או רכיבים - באנגלית, כלומר, על ידי תיאור של מוצר. יכול להיות שמכירים את Base44 הישראלית שעושה משהו דומה. אז כן, אז יש כמה כאלה, ו-Lovable זו אחת המובילות.אז זה מתחיל לענות -אבל אני אשאל את השאלה הזאת במפורש: למה עכשיו? כלומר, למה לדעתכם השוק עכשיו בשל לפתרון כמו שלכם וצריך אותו?אז מן הסתם “התפזלנו” לכיוון של AI, אבל בואו תפרטו קצת, כלומר - איך זה הולך להיראות לפי החזון שלכם? (קרן) אז קודם כל, אני חושבת ששווה לשאול מה האלטרנטיבה? אם אנחנו הולכים על אותה Mature App - מה אפשר לעשות? אפשר עכשיו להשקיע בתשתית שהיא יותר מודולרית והיא מייצרת לי את ה-Micro Apps או שליטה שהיא . . .כאילו, אני יכולה להחזיק דברים בתוך הStack ומחוץ ולייצר ביניהם תקשורת. אני גם יכולה לשים מפתח, שיעבור על ה-Output של Gemini או Claude, על אלפי שורות קוד - ויעשה גם אינטגרציה ידנית, זה גם אני יכולה לעשות. אבל איך שאנחנו רואים את זה, אלה כרגע האופציות, האלטרנטיבות. אז בעצם אנחנו אומרים, רגע - אם עולם ה-Software עובר פה איזשהו Disruption - מרצון, לא מרצון - אנחנו שם, הרכבת הזאת יצאה, נסעה, וכולנו בתוך זה. אז אנחנו ננסה להקל על ה-Disruption הזה עם השיטה הפלגבילית (Plug-able) שלנו, ה-”Containerization” . . . . (רן) . . . חייבים להמציא מילה יותר פשוטה לזה. (קרן) . . . חייבים. (רן) כן, כלומר - את אומרת . . . אם אני מבין אותך נכון, בעצם את אומרת “אוקיי, יצרתי פה איזושהי קומפוננטה, שהיא נראית לי טוב - אבל היא מכילה אלפי שורות קוד, יכול להיות”. זאת אומרת, משהו ש-Lovable פלט או Gemini כתב לי, או Claude Code או Whatever. “זה נראה לי שזה עובד בסדר, נתתי לחברים שלי לשחק, נתתי ל...” . . . .עכשיו, אני באמת הולך לעבור על כל האלף שורות קוד האלה לפני שאני באמת יודע אם משתמשים רוצים את זה?לא בא לי לעשות את זה . . . אז לא, אני פשוט אתן למשתמשים. קודם כל להבין אם זה בכלל נותן את הProduct הנכון, אם זה נותן את החוויה הנכונה.יכול להיות שזה לא Robust במאה אחוז - בסדר, אני מוכן לשלם את המחיר הזה. אבל אני קודם כל רוצה לדעת אם זה הולך לעבור את הפילטר של המשתמשים - ואתם למעשה נותנים את הכלי לעשות את זה. עם סיכון מסוים, אבל שהוא Manageable. (קרן) כן, אנחנו מנסים למתן את הסיכון עם QA פנימי ועם כמובן יכולות ולידציה (Validation) ועם Gradual Rollout, ו”תיקח את זה ל-5%, תיקח את זה ל-10%”, עם כל הכלים האלה. אבל כן, בדיוק - אנחנו אומרים, לא יודעת . . . זה כמו “ה-Next level של ה-MVP”, זה “AI-MVP” קח את זה, תבדוק את זה - ואז תקבל החלטה מושכלת אם לשים על זה צוות פיתוח ולפתח את זה Enterprise-Grade . . . (רן) “לשייף את הקצוות” . . . (רן) כלומר, בעצם אתם מייצרים את היכולת להביא Prototype - אולי לא של כל המוצר, אבל Prototype של איזשהו רכיב, נגיד איזשהו מסך בתוך המוצר או איזשהו תפריט בתוך המוצר - להביא את ה-Prototype הזה ללקוחעם מינימום מאמץ פיתוחי, באמצעות AI-Coding או Whatever. דרך אגב, יכול להיות שכן היה שם מפתח אבל הוא לא “שייף את זה עד הסוף”, אוקיי? אז להביא את ה-Prototype הזה לפני הלקוח, להבין אם הלקוח באמת רוצה את זה - ואם כן אז לוקחים את ה-Prototype והופכים את זה למוצר רובסטי (Robust), עם Performance וכו’ - אבל לפני זה אין טעם להשקיע.(אורי) תמיד, כן - “בזמן הכבד” אתה רוצה להשקיע אחרי הוולידציה (Validation). (קרן) בדיוק. (הדר) כן, נכון. אני גם חושב שכאילו היום בלי פתרון כזה, בעצם העולם מתחיל להתחלק לאוקיי, היו לנו את ה-”Builder-ים”, הרבה מאוד שנים, שהיו שמורים ללקוחות מסוימים, נכון? דפי נחיתה פשוטים, כל מיני e-commerce קטנים, עצמאים שבונים לעצמם אתר . . . והיה לנו את המערכות הגדולות שחברות כותבות - Dashboard-ים, אפליקציות, כל הדברים האלו. וה-AI, עם ה-Vibe Coding, Base44, Lovable, כל הכלים שדיברנו, תופס ובא להחליף את ה-Builder-ים. אבל בעצם אנחנו זיהינו פה פוטנציאל - רגע, למה? למה לא לשלב עכשיו בין הדברים ולבוא ולתת את כל היכולות המדהימות של ה-Vibe Coding וה-AI שהולכים ומשתפרים כל יום ב-Level של קומפוננטה (Component) ולא ב-Level של אפליקציה. אם אני יכול לבנות אתר שלם ב-Base44 - חנויות, מה לא ראיתי בחודשים האחרונים . . . חנות להשכרת רכבים ונדל”ן שאנשים עשו בשכונה שלהם וכל מיני דברים. אז אם זה עושה אתר שלם, ה-Take שלנו זה בוא נצמצם את הקונטקסט לקומפוננטות - האיכות רק תעלה. נפנה ל-AI במשימה קטנה יותר מדויקת יותר, ונוכל להשתמש בזה במוצרים קיימים. (רן) כן, זאת אומרת אתה אולי רומז לכיוון שני אתגרים שבאחד מהם נגענו ובשני לא ממש.אחד זה אתגר המיטיגציה (Mitigation). כלומר, אני לא בטוח עד כמה הקוד הזה רובסטי (Robust), אני עדיין רוצה לבדוק אותו. על זה דיברנו. 30:00 “לכתוב Prompt” זה יותר מורכב ממה שזה נשמע (רן) אתה גם מזכיר או רומז, לפחות לדעתי, על אתגר אחר - שהכלים האלה, יש להם יכולת לכתוב פרויקטים קטנים ברמת איכות יחסית סבירה. אבל כשאתה מכניס אותנו לתוך פרויקט גדול - חי, שיש בו מורכבות - ניקח את Wix לדוגמה - מאוד קשה להם להתמודד עם כל ה-Code base הזה, מאוד קשה להם להיכנס עם כל ה-Coding Conventions. אבל אם אתה מקטין להם את ה-Scope, אתה אומר “אוקיי אתה לא צריך להכיר את כל Wix, רק תסתכל על הריבוע הקטן הזה - זה הממשק הקטן שלך בתוך ה-Sandbox הזה אתה חי”, אז פתאום החיים שלהם קלים, ואז הם נותנים עבודה טובה. (הדר) נכון, וזה משהו שאתה לא צריך לחכות, אתה יודע, את החצי-שנה-שנה-שנתיים-חמש, שזה יהיה במקום הזה. ואנחנו מדברים עם הרבה אנשים כל אחד נותן את ההערכה שלו מתי ה-Context Window יוכל להכיל יותר ויותר. והיום שמענו על איזה Agent שעושה את זה בכמה Thread-ים, ואז הוא יכול לעשות יותר קונטקסט וכל מיני כלים שעשו. אגב, יש איזה כלי מאוד מעניין עכשיו שמעתי שבתוך Wix מפתחים אותו אז זה מעניין . . . אנחנו באים ואומרים “אוקיי, אבל למה לחכות?” את הקומפוננטה ה-Scoped, החצי-מסך, הבאנר, הכמה דפים, ה-Form הזה שאני צריך, התת-אפליקציה הזאת . . . - זה עושה מעולה היום. ואם אני אחבר את זה ואתן כאן איזשהו פתרון רובסטי, Type-safe - עם בדיקה בין גרסאות, עם יכולת לשחרר את זה מהר ולתקן את זה מהר - זה יכול היום להיכנס לאפליקציית React ה-Production שלי, לאפליקציית Vue ה-Production שלי. (רן) כן. דרך אגב, אני חושב שכן יש פה עוד איזה שהוא אתגר שבעיניי הוא לא מפוצח: אז גם אני, כמו הרבה אחרים, משתמש בכלים האלה, ולמדתי שאחד האתגרים הכי גדולים זה לבוא ולהגדיר את ה-Interface-ים. כלומר, לבוא ולהגדיר את דרישות המוצר, לבוא ולהגיד “הנה - תשתמש בזה, אל תשתמש בזה, תחשוף את הממשק הזה, אל תחשוף ככה” . . . לבוא ולתת פידבקים. וכדי לדעת לעשות את זה בצורה טובה, צריך איזה שהם כישורים הנדסיים.כלומר, אני חושב שאותם אנשים, שאין להם את הרקע ההנדסי - ופה אפילו לכאלה שיש להם רקע הנדסי משמעותי, יכול להיות להם אתגר. אז אני חושב שעדיין יש פה איזשהו Scarcity של Skill של Engineering, כדי לייצר פה קומפוננטות (Components) כאלה שהן עובדות נכון. (הדר) אז זה ממש נכון - וזה יתחבר לנו בצורה מאוד מאוד טובה למה שהתחלנו איתו: איך אתה מגדיר חוזה מול מה שקראתי לו “כל חתיכת UI”? ה-Dashboard שלנו היום והפלטפורמה שלנו היום יודעת, בהינתן Output כזה שהבן אדם שכתב - יותר טכני, פחות טכני - יודעת לבוא ולבקר את החוזה הזה. לבוא ולהגיד “תראה, בגרסה הקודמת היה API כזה וכזה - שברת אותו”. “בגרסה הזאת מוצעות עכשיו עוד כמה וכמה יכולות - אתה רוצה להשתמש בהן?” וככה אנחנו בעצם יכולים לעשות איזושהי רמה של ולידציה (Validation) ראשונית, שלא שברת את הממשק. אנחנו יודעים לזהות שם את ה-Type-ים, מה שדיברנו, את ה-Prop-ים הנכנסים, היוצאים,Ref-ים. השלב הבא של הדבר הזה - ואז אנחנו ממש עובדים וחושבים עכשיו איך נעשה את זה - זה להיות מסוגלים לקבל Prompt פשוט, ואוטומטית ליצוק לתוכו את כל ההבנה. זאת אומרת, לבוא ולהגיד אנחנו מבינים שזה הולך להיטען ב-Run-time, אנחנו מבינים שזה צריך לנהל API, אנחנו מבינים שזה צריך לעמוד בסטנדרטים כאלה וכאלה וכאלה . . . . אולי אנחנו מכירים את ה-Pattern-ים שקורים אצלך בארגון - ונמליץ את זה למנוע, בתוך ה-Prompt שלנו. אז זה גם מה שאנחנו עכשיו מסתכלים עליו, בוחנים אותו - איך התוצר של זה אל מול “החופש”: פשוט לך ל-Gemini, Claude, GPT ותן לי את ה-Output. (רן) כלומר, אתם לא רק מייצרים את ה-Framework שאליו מזריקים את הקומפוננטות, אלא אתם עוזרים - אתם ה-Mediators לייצור הקומפונטות. אתם באים ואומרים “אוקיי, אתה רוצה להשתמש ב-Lovable, Base44, Gemini או Claude Code - תשתמש”. אתה יכול לשחק חופשי, אבל אתה גם יכול לקבל את העזרה מאיתנו - ואנחנו נעזור לך לייצר קומפוננטות שעובדות יותר טוב איתנו. (קרן) בדיוק. האמת שזה בגלל שאחרי שדיברנו עם באמת לא מעט אנשים, הבנו שזה לא מפתיע - שהקושי הוא באמת באיך ניגשים לזה, ואיך בונים, ואיך עושים את זה נכון. וכאילו זה “לכתוב Prompt” - זה יותר מורכב ממה שזה נשמע . . . (רן) “תעשה את זה יפה”, כן . . . “תעשה את זה יפה” זה לא מספיק - צריך להסביר מה זה יפה. (קרן) בדיוק - ותקליט לו גם, כי למי יש כוח לכתוב? 34:32 ה-ActiveX Strikes Back / אם אתה פותר בעיות שאף פעם לא ראית לפני זה, אז אתה לא עושה את האנלוגיה הנכונה (אורי) אני יכול להגיד משהו, כנציג “שיער אפור”?(רן) אתמול התגלחתי, אז לא רואים . . . (אורי) כן . . . אתה זוכר, רן, את תחילת שנות האלפיים?(רן) נניח, כן . . . זורם.(אורי) את ActiveX של Microsoft?(רן) כן, כן - קראתי איזה ספר . . . (הדר) אפילו אני עוד מכיר . . . (אורי) כן, אז הנה - פחות שיער . . . כל הנושא של טעינה ב-Run-time וייצור קומפוננטות וכל הדברים האלה - זה אחלה שיעור היסטוריה. אני בתחושה שהיסטוריה חוזרת בשיחה הזאת.אז יכול להיות שיש הרבה פתרונות, שמתחבאים שם בשיעור היסטוריה. (הדר) אני חושב שכאילו . . . . אני מצד אחד יכול להתחבר למה שאתה אומר. מצד שני, אני חושב - ואנחנו מדברים על זה גם הרבה - שהפתרונות האלה, הפתרונות כמו ActiveX או היה Silverlight בזמנו, היה כל מיני דברים כאלו - הם באו לפתור כאב אחר, שאם שאלנו למה עכשיו, אז הוא כבר פתור היום - וזה המגבלות של ה-Frontend. אנחנו לא באים להגיד “React לא טוב”, “Vue לא טוב” או “ה-Output של Lovable לא טוב”. איך אני מחבר בין הדברים? ו-ActiveX, לצורך העניין, הוא בא ואמר “אני לא יכול לעשות הכול בזמנו ב-HTML ו-JavaScript, אז בוא ניתן לך להריץ אובייקטים מורכבים יותר, Native-יים בתוך ה-Browser”. אני רואה את זה כמשהו קצת אחר . . . זה עוד לפני ה-Browser-ים זה עוד על ה... כאילו, ממש על התכנות ה... אתה יודע, היית מראה אפליקציה, ואז מביא “מהיקב ומהגורן“ ערימות של DLL-ים - שהיו מכילים בעצם את ההשלמות. (רן) אתה מחפש את MFC, נכון? MFC זו המילה שאתה מחפש . . . זאת אומרת, קודם כל, אני דווקא חושב שזה מעודד, שהבעיות חוזרות על עצמן - רק בטכנולוגיה אחרת. אנחנו חיים בגל-סינוס וטוב לנו ככה, אז זה בסדר. אז בוא נגיד - זה לא מה שהיה מפחיד אותי. אבל כן - אני חושב שבוא נגיד שאם אתה מחפש פתרונות מהעבר ומנסה להפעיל אותם על ההווה או העתיד, בוא רק תוודא שעשית את האדפטציות (Adapt) הנכונות . . . (אורי) ברור . . . (רן) . . . אבל עצם זה שזה חוזר על עצמו - אני חושב שזה דווקא בסדר. זה “בדיקת-שפיות” כזאת. בוא נגיד, אםאתה פותר בעיות שאף פעם לא ראית לפני זה, אז או שאתה לא עושה את האנלוגיה הנכונה או שאתה קצת הוזה. עכשיו, מדי פעם אתה אולי צודק - “אחת ל” יש המצאת iPhone . . . זה קורה. אבל רוב הזמן לא - רוב הזמן זה דברים שקרו גם לפני זה.וואו איך גלשנו שם לפילוסופיה . . . (אורי) לגמרי . . . 37:15 אז איך מתחילים? (רן) טוב, קודם כל - אנחנו ככה לקראת סוף הזמן שלנו, אז רציתי לבוא ולהגיד תודה רבה, ואולי עוד כמה מילים על החברה? בעצם, אמרתם שאתם כיום שלושה, נכון? או שכבר גדלתם? (קרן) גדלנו. אנחנו שלושה Co-Founders, אבל כבר יש לנו - גייסנו צוות ולקוחות ראשונים ואנחנו גדלים. מחפשים חברות אמיצות שרוצות לקחת AI לProduction - I dare you.(רן) מה נדרש מהם לעשות אם הם רוצים לבוא ולהתחיל לעבוד איתכם? (הדר) אז זה ממש ממש פשוט - בעצם אנחנו מציעים איזושהי פגישה, שבה אנחנו פשוט לוקחים קומפוננטה, בוחרים קומפוננטה, פתוחים לכל Stack של הלקוח. וב-20 דקות עד 40 דקות מכניסים קומפוננטה מחוץ ל-Build שלו אל תוך המוצר ב-Production. (רן) כן, כשאתה אומר “קומפוננטה” (Component), אתה מדבר על משהו ש”חי ב-Browser”. כלומר, לא מטפלים ב-Backend ואחרים? (הדר) נכון - UI, SSR גם - אפשר לדבר על זה - אבל UI כן. (רן) לא Mobile. זאת אומרת, לא Native Mobile - ווביי (Web). (הדר) נכון. (רן) בסדר גמור. נשמע כמו אתגר ראוי וכיפי - שיהיה בהצלחה! (הדר, קרן) תודה רבה. 38:30 פרק 500 קהילתי - שלחו את ה-Mp3 שלכם! (רן) ושנייה לפני שאנחנו מסיימים - כהכנה לפרק 500 הממש-ממש קרוב אלינו, אנחנו רצינו לעשות משהו מיוחד.אז מה שאנחנו מבקשים מכם, המאזינים, זה לשלוח לנו משהו קטן - ותיכף נגיד לכם מה זה - משהו קטן אלינו.אנחנו ניקח את ה-Input שלכם ונקמפל את זה לפרק שלם, ובטוח שיהיה מעניין.(אורי) אני רק מקווה שישלחו לנו, כן?(רן) כן . . . אז מה אנחנו מבקשים?(אורי) אז שלחו לנו דברים, לפי הנושאים הבאים: נגיד, אתם יודעים - אנחנו מקליטים כבר 17 שנים. זה די היסטוריה רחוקה, והרבה דברים קרו. ואנחנו יודעים שיש לנו מאזינים שמאזינים לנו הרבה זמן - אז דברים כמו למשל משהו מעניין או מצחיק שקרה לכם בעקבות פרק של רברסים.(רן) אז דוגמא אחת - שוב אני אומר: לשלוח לנו MP3! נגיד - משהו מצחיק שקרה לי ו-1,2,3 - תספרו. 30 שניות, דקה - אפשר גם פחות. ותשלחו לנו לאימיילים שלנו - Ran-at-Reversim ו-Ori-at-Reversim. (רן) אז דוגמא אחת זה משהו מעניין או מצחיק שקרה לכם בעקבות הפרק דוגמא אחרת - מה למדתם מאחד מהפרקים? משהו מעניין שלמדתם שלא הכרתם לפני זה (אורי) או למשל מה הפרק שהכי אהבתם - ולמה? (רן) או שאלה אחרת - מה זה רברסים בשבילכם? וזה בסדר גם לדבר על טרקטורים ופלטפורמות . . . (אורי) נכון . . . (רן) מה המשמעות? “רברסים” - מה המילה, מה השם הזה אומר לכם? (אורי) והשאלה הכי פרובוקטיבית פה -האם החלפתם עבודה בעקבות פרק של רברסים? (רן) ספרו לנו . . . (רן) אז כן - נשמח אם פשוט תשלחו לנו קבצי mp3, הקלטה של כמה שניות עד 30 שניות. אפשר גם קצת יותר, זה בסדר.ניקח את כל זה, נקמפל לפרק - ויהיה פרק קהילתי: הפרק הקהילתי הראשון בתולדות רברסים ובעולם, נניח . . . (אורי) פרק מספר 500 . . .(רן) אז תודה רבה! מצפים מאוד לשמוע מכם, להתראות. [קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!

Showing 1–20 of 22 episodes