חזרה למסמך הראשי

הסטודיו

נכתב בידי עוזר AI שעובד עם יוסף, מתוך תיעוד העבודה במרכז, כרקע לפגישה ב־20.10.

מה זה ולמה הוא קיים

הסטודיו, בשמו המלא Rosetta Studio, הוא הממשק שבו בונים שאילתות על רוזטה בלי לכתוב GraphQL ביד. המסלול הבסיסי: בוחרים מטופל ומחלקה, מדפדפים בכל מה שרוזטה יודעת להביא עליו מקמיליון, ממטוויז׳ן ומשאר המקורות, ולוחצים פלוס על מה שרוצים. כל לחיצה מוסיפה חלק ל״סל״, כלומר לשאילתה. בסוף שומרים, נותנים לשאילתה שם ומקבלים מזהה שאילתה (query id). מאותו רגע כל צרכן, flow ב־AI Flows, אליס או סוכן, שולח לרוזטה את המזהה הזה יחד עם מזהה מטופל ומקבל בחזרה בדיוק את הנתונים שהוגדרו, ולא שום דבר אחר.

המטרה נוסחה בשתי הזדמנויות, שתיהן של גיא דולינסקי. ב־20.6.2026, כשביקש את הכלי, הוא הסביר שהוא צריך סביבה שבה אפשר לשלוף קוהורטים למחקר, ושזה לא יהיה תלוי במי שיודע SQL: כל סטודנט צריך להיות מסוגל לעשות את זה. וב־14.7, בקבוצת הצוות של רוזטה, הוא ניסח את קנה המידה: אם הסטודיו יושלם, אף אחד כבר לא יבנה שאילתות GraphQL בידיים. להערכת הסוכן זה עדיין המדד הנכון למדוד לפיו את הכלי.

בפועל יש לו היום שלושה סוגי משתמשים. הראשון הוא הפרודקט, שבונה את השאילתות שמזינות מכתבים ב־AI Flows ובאליס; כשמגדירים קלט למכתב ב־AI Flows, השאילתה שבוחרים היא שאילתה שנשמרה בסטודיו. השני הוא מי שבודק את רוזטה עצמה: קלינאים ואנשי מוצר שמשווים את מה שרוזטה מחזירה למה שרואים בקמיליון, צוות הדאטה והמתייגים של אליס שמחפשים מקורות, ומפתחים שמדבגים מטופל. השלישי, שעוד בהתהוות, הוא מחקר ובניית קוהורטים, כלומר הבקשה המקורית של גיא.

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

מאיפה הוא בא: מרץ–יולי 2026

הרעיון קדם לכלי, והשם שלו קדם לשניהם. ב־5.3.2026 יערה כץ מנתה ״playground 2.0״ בין הדברים שהגילדה צריכה לחשוב עליהם. באביב המילה ״פלייגראונד״ כבר שימשה בצוות לכמה דברים שונים: ב־18.5 יערה הבחינה בין פלייגראונד ״אמיתי״, במובן של סביבת בדיקה ל־flows, לבין מה שגיא קרא לו באותו שם. ב־4.6 יוסף בנה לגיא כלי שלישי באותו שם: שאילתת רוזטה לצד קונפיגורציה חיה של מנהל, תצוגת נתונים וכפתור שפותח merge request עם הקונפיגורציה החדשה. ההבחנה הזו חשובה למי שמצטרף, כי היא מסבירה בלבול שעוד נשמע בחדר.

ב־20.6.2026 גיא ביקש את הכלי עצמו, כ״סנדבוקס״ לשליפת קוהורטים למחקר ולכל מי שאינו כותב SQL. יוסף כתב אותו, והגרסה העובדת הראשונה יצאה ב־26.6, שישה ימים אחר כך, כסעיף רביעי בעדכון גרסה של רוזטה. באותו עדכון היא עוד נקראה playground. בתוך עשרים דקות גיא תיקן את השם בקבוצה, ויערה קבעה שהשם הוא Studio, כדי שכולם ידעו על מה מדברים. באותו לילה היא גם כתבה שההתקדמות מרשימה. הכלל היה צריך חיזוק פעם נוספת ב־19.8, ומאז הוא יציב: כשאומרים היום בצוות ״פלייגראונד״, הכוונה לכלי של AI Flows לבדיקת flows, עם guardrails והערכות; כשאומרים ״סטודיו״, הכוונה לכלי של רוזטה. ב־26.7 גיא העלה גם את הכיוון לחבר את שלושת הכלים, וזה לא נעשה עד היום.

ב־28.6, יומיים אחרי שהגרסה יצאה, יוסף הציע בעצמו שהממשק שכתב יוחלף בעיצוב של שחר מהפרודקט. מה שנשאר מהגרסה הראשונה הוא הבקאנד, מנגנון מזהי השאילתות ומודל הסל. כרטיס עיצוב משותף לשני ירדני ושחר, ״Studio/Rosetta design״, עומד בלוח במצב מוכן־להתחלה מאז מאי, וחלק מהעיצוב נכנס בהדרגה בגרסאות שאחריו.

ביולי הכלי גדל. ב־12.7 גיא דיווח שהבקאנד והפרונט של הפלייגראונד נכנסו לענף הבטא של AI Flows, וזה מה שהפריד סופית בין שני הכלים. ב־14.7 יוסף דיווח על כמעט שלושה עדכונים גדולים לסטודיו מאז שגיא ראה אותו לאחרונה. ב־29.7 הסטודיו חובר ל־AI Flows, כך שכל שאילתה שנשמרה ברוזטה אפשר לבקש מתוך flow. להערכת הסוכן זו נקודת המפנה החשובה ביותר בהיסטוריה שלו: מאותו יום הוא כבר לא כלי חקירה, אלא משהו שמוצרים בפרודקשן תלויים בו.

אוגוסט–ספטמבר: שכתוב, בטא ופרודקשן

ב־12.8, בשחרור שבו הבטא של רוזטה קודמה לפרודקשן, הסטודיו נכתב מחדש: פריסה חדשה, מעבר לעברית ותיקוני באגים, כחלק מ״ריפקטור גדול מאוד״ של הממשק. באותו שחרור נוסף אחסון ב־RustFS לתוצאות של שאילתות שמורות, עם מזהה תגובה, היסטוריית קריאות ומטא־דאטה, ותוקף של יום אחד אלא אם מבקשים לשמור תוצאה. את הכתיבה מחדש הנחו שתי קביעות של גיא מ־15.8: לשנות כמה שפחות ממה שהיה, ולהעדיף עלייה מהירה לפרודקשן על פני הדרישה הרגילה לקוד קריא וקל לתחזוקה. להערכת הסוכן זו הייתה החלטה סבירה בזמנה, וחלק מהחוב שמתואר בסוף העמוד הוא המחיר הידוע שלה.

בשבוע של 19.8 התקבלו שתי החלטות עיצוב שעוד ניכרות היום. הראשונה: תוצאות של הרצה נשמרות במסד (Mongo באותה תקופה) ולא נשלחות כזרם SSE, כי זרם היה נעלם ברענון של הדף; יוסף טען לזה ושי גנכיל קיבל. השנייה: הגדרת ההפניות מעלים (references-to-leaves) לא נכנסה למסך הסטודיו, ויוסף הציע שמקומה ב־AI Flows. ב־25.8 נוספה בקשת UX להציג גיליון שלם בלחיצה במקום section אחרי section.

ב־19.8 הסטודיו החדש עלה לבטא עם שתי שאילתות שמורות בלבד: שאילתת המיון לפני רופא ושאילתת מכתב השחרור של הפנימית. כל השאילתות הישנות יותר אבדו, כי המסד שבו נשמרו לא עבר במעבר של רוזטה ל־Percona. ב־20.8 הסטודיו שוחזר ידנית אחרי מיזוג שהשתבש: טעינת ההרצות הועברה למסד, התזמונים ומזהי התגובה נשמרו, והקישור ל־Grafana תוקן. באותו הקשר כדאי להכיר נתון נוסף: אחת משתי השאילתות הגיעה בשלב מסוים ל־1.7 מיליון טוקנים לבקשה, עד שטהר אברג׳ל צמצם אותה ל־sections הרלוונטיים. הסל אינו רק נוחות; הוא מה שקובע כמה עולה כל קריאה למודל.

השיעור שהצוות הפיק מאוגוסט הוא ששאילתה שמורה נראית כמו נתון של משתמש, אבל היא בפועל קונפיגורציה של פרודקשן: flows ומכתבים נשענים על המזהה שלה. מכאן שלוש החלטות. ב־30.8 גיא הקפיא שינויים שוברים בסכמה של רוזטה עד שהמכתב הראשון יגיע לפרודקשן דרך AI Flows. ב־1.9 הוא קבע שכל שמירה יוצרת שאילתה חדשה כברירת מחדל, ושדריסה של מזהה קיים דורשת אישור, כי יש סוכנים שמחזיקים את המזהים ב־git. וב־14.9 יערה הוסיפה שני כללים: רק מי שיצר שאילתה יכול לשנות אותה, והשאילתה שמשמשת להערכות חייבת להיות אותה שאילתה שמשמשת להרצות הרגילות.

ספטמבר היה החודש שבו הסטודיו עבר מענף לפרודקשן, והדרך לא הייתה ישרה. ב־4.9, כשהארכיטקטורה שאלה מתי הבטא של רוזטה עוברת לפרודקשן, התשובה הייתה שענף הסטודיו מעכב את ה־workspace worker, ואיתו את הדחיפה כולה. ב־10.9, אחרי rebase, אשת מוצר עדיין לא הצליחה לעבוד עם הכלי; יערה כינסה פגישה בנושא, גיא ביקש שותף לערב תיקונים, ובאותו יום נפתח כרטיס על באג גלילה. ב־11.9 גיא הציע לשבת בשיבא ביום ראשון בערב ולסגור את הסטודיו, וגיא ויוסף עבדו עליו בלילה של 13 ל־14.9. בבוקר היו בו חיפוש עם הדגשה, עץ הגדרת השאילתה, פילטרים וציור מחדש של הפרונט, והכרטיס ״Studio - finish first phase״, על שם גיא וטהר, סומן כגמור ב־14.9.

באותו ערב, 14.9, יערה כתבה בקבוצת הצוות של SmartER שהסטודיו נמצא ב״לימבו״, עם קוד בענף שצריך לאמת ונושא שמירת השאילתה והתוצאה שצריך לסגור, ושצריך להחליט מי מתוך הצוות לוקח בעלות על הסטודיו ומי על הפלייגראונד. יוסף ענה באותו ערב ששמירת תוצאה ושאילתה עובדת מהיום הקודם. ב־15.9 גיא ציין שהענף עדיין לא מוזג ושהשאילתות הקיימות הוחזרו ידנית, והגדיר את מיזוג ענף תיקוני הממשק לבטא כדבר הדחוף ביותר.

ב־15.9 גם נדחפה הבטא של רוזטה לפרודקשן. טהר ביצע את הדחיפה ובנה לשם כך ייצוא וייבוא של שאילתות בין סביבות, כי השאילתות השמורות ישבו במסד של הבטא; שעה וחצי אחר כך הוא דיווח שהכול עלה ושהשאילתות עברו. יוסף כתב לו באותו ערב שזו הייתה דחיפה לא טריוויאלית ושהיא נעשתה היטב. ב־16.9 טהר אישר ש־SmartER בפרודקשן מדבר עם Wildfire בפרודקשן, ושהבטא של הסטודיו והפלייגראונד מוכנה לבדיקות. באותו יום נפתח הכרטיס ״Studio Phase 2 - UI Fixes״, על שם שי.

עוד דיון אחד מ־15.9 חשוב כרקע למה שקרה באוקטובר: היכן צריך לשבת סוכן שעוזר לאנשי מוצר לבנות שאילתות. שי שאל את השאלה. עמדתו של יוסף באותו יום הייתה שלא נכון לבנות מסך צ׳אט בתוך הסטודיו, כי היכולת כבר קיימת כסקיל של Codex, ועדיף שתרוץ על התקציב של המשתמש. שי העביר את השאלה לקבוצת רוזטה והציע ששילוב בתוך Open WebUI עם הסקילים הנכונים נשמע לו נכון; אלון אגמון ביקש מהצוות להתרכז בעיקר. החלטה טכנית לא נרשמה.

אוקטובר: חזרה לעבודה, ממשק חדש ומסירה

בתחילת אוקטובר הסטודיו עמד שוב במרכז. ב־5.10, בשיחת עבודה מוקלטת עם יוסף, גיא הגדיר כעדיפות שאיתן ומטוויז׳ן ייכנסו לסטודיו, כי מקור שלא מופיע בו, מבחינת המוצרים, לא קיים. ב־6.10 עלתה האפשרות שמישהו אחר בצוות ייקח את הסטודיו, ובסוף סוכם שיוסף ממשיך לעבוד עליו. ב־10.10 שחר שאלה אם הסטודיו יכול לתמוך ברצף של תזמון, סיכום ושאלה לאליס, לפי הדגם של SmartER; זו בקשה שלא קיבלה עדיין מפרט.

ב־11.10, בבוקר, יוסף דיווח בסטנדאפ שהפרונט החדש מחובר לבקאנד שטהר כתב ומציג רשומות, ושהענפים עוד לא נדחפו; גיא ביקש לסגור את הסטודיו ואת הפלייגראונד יחד. אחר הצהריים, בסשן Wildfire לצוות פוטון, יוסף הדגים הרכבת שאילתה ועריכה המחוברת ל־GraphQL. יערה העריכה בסשן שהכלי מורכב, שהוא מנסה לפשט דבר מורכב מאוד, ושהפער העיקרי הוא פער UX שדורש מומחיות; גיא תיאר את השיפורים לימים הקרובים, ויזארד להתאמת מחלקות וצ׳אט שבונה שאילתה עם תצוגה מקדימה (פירוט בפרק הכיוונים).

ב־12.10 יוסף הציע חלון צ׳אט בסטודיו שאליו מדביקים צילום מסך מקמיליון או ממטוויז׳ן ומקבלים שאילתה שמביאה את הנתונים שעל המסך, ובאותו יום נכתב עליו מחקר היתכנות. באותו ערב הוא דחף את רוב הבקאנד והפרונט לענף אחד, כשש מאות קבצים, שעוד דרש סקירה.

ב־13.10 שינוי בחוזה הפילטרים של רוזטה, מעבר מפרמטרים ישירים לאובייקט filters, שבר שאילתות שמורות של צרכנים, ושאילתה שמורה שלא תאמה לחוזה החדש גרמה למסך לבן בעריכה. שי תיקן באותו ערב את האפשרות לערוך שאילתות שבורות, והודיע על כך בקבוצת SmartER Squad. להערכת הסוכן זו הדוגמה הברורה ביותר לבעיית החוזה שמתוארת בסוף העמוד. ב־14.10 התברר ששינויים ב־Wildfire שברו את משיכת המטופלים לסטודיו, ועלה הצורך לסדר את רשימת ה־sections לפי סדר אלפביתי. ב־15.10 גיא ביקש שחבילת השינויים תיכנס לענף הראשי, ויוסף הדגים בחירת sections עם תיאורים ותרגומים מתוך ה־GraphQL; הבחירה עבדה, אבל השורות לא חזרו כמצופה באותה הדגמה. באותו יום הכרטיס של השלב השני נרשם בלוח על שם שי ויוסף.

ב־18.10, בפגישת צוות עם אלירן חדד, עומר, שי ויאיר גינת, הסטודיו עלה מכמה כיוונים. יוסף תיאר את הפריסה (פרק הבא) ואת רצונו לפצל את רוזטה לשלושה שירותים. אלירן העלה שאנשי מוצר שמעו את השמות סטודיו, ויזארד ו־GraphQL ולא תמיד יודעים מה כל אחד מהם עושה, ושאל אם נכון שאלה יהיו אפליקציות נפרדות או מודולים באפליקציה אחת. יאיר הציע לראות בסטודיו מוצר ללקוח שהבקאנד שלו נפרד מתשתית Wildfire. יוסף מנה את רשימת העבודה שנשארה: cache ו־batching, אופטימיזציות בשאילתות ה־SQL, שיפור משמעותי של השאילתות שהסטודיו מייצר, ועיצוב מחדש של הסכמה והממשק במטוויז׳ן. באותו ערב בוב, כלי בניית הקוהורטים, הוצג כשבחירת הנתונים שלו נעשית דרך שאילתה מהסטודיו.

בצילום הלוח של 18.10 הכרטיס ״Studio Phase 2 - UI Fixes״ רשום על שם יוסף, וכרטיס נפרד, ״Rosetta Studio״, עומד בספרינט שמסתיים ב־29.10 בעדיפות גבוהה וללא בעלים. ב־19.10 יוסף דיווח ליערה שרוזטה, כולל הממשק, גמורים וממתינים ל־PR, ושהממשק יושר לסגנון של שחר ולפיגמה שלה, עם דוגמאות מהמאגר. במקביל הוא עושה סדר נרחב במאגר בענף נפרד, כדי שיהיה קל יותר לעקוב אחריו למי שלא עבד בו. נכון לכתיבת העמוד זה דיווח, לא מיזוג ולא קבלה של משתמש; הסקירה היא השלב הבא.

איך הוא עובד היום

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

מסלול המשתמש נראה כך. בוחרים מטופל, והסטודיו שולף את כל מה שהוא יכול להביא עליו מכל המקורות, כדי שאפשר יהיה לדפדף; במטופל עם היסטוריה ארוכה זה לוקח זמן מורגש. אפשר לחפש טקסט חופשי מעל כל הנתונים של המטופל, עם הדגשה. בסוג מידע מסוים, למשל בדיקות מעבדה או פרוצדורות, לוחצים הוספה לשאילתה, ואז בוחרים שדות, משנים שמות ומוסיפים פילטרים. מאוקטובר אפשר לבחור sections, עם התיאורים והתרגומים שמגיעים מהמטא־דאטה של ה־GraphQL. כשמסיימים שומרים, והשם מופיע ב־AI Flows ובכל מקום אחר שבו בוחרים שאילתה. הרצה פר מטופל נשמרת עם תזמונים, מזהה תגובה וקישור ל־Grafana, והתוצאות נשמרות כך שרענון הדף לא מעלים אותן.

ב־18.10 יוסף תיאר דוגמה למסלול הזה כשהוא עובד: משתמשת שאינה מפתחת נכנסה למרפאה שהיא מכירה, סיננה מכתבים לפי מילה שעניינה אותה, לחצה פלוס, שמרה, וקיבלה שאילתה קטנה ומדויקת משלה. באותה שיחה צוין גם שמשתמשים חדשים צריכים בהתחלה ליווי של מפתח.

שני עקרונות של רוזטה משפיעים ישירות על מה שרואים בסטודיו. הראשון הוא שאין קישור חד־חד־ערכי בין המקורות: encounter הוא מושג של קמיליון, למעבדות אין encounter, ובטיפול נמרץ זו מערכת אחרת לגמרי. לכן הקשר בין פריטים הוא לרוב טמפורלי, וזה מה שמסביר למה יש בסטודיו ספק מידע בשם ״שיבא״, שמחזיק לוגיקה של המרכז. הדוגמה המרכזית היא current encounter: לא ביקור ספציפי, אלא לוגיקה שמקבלת מטופל ותאריך ומחזירה את שרשרת האשפוזים של אותו אירוע. השני הוא שכל רכיב שרואים יושב על URI משלו, נאמן למקור, שמזהה מטופל, מערכת ומקור, ויש route שמחזיר את ה־JSON של אותו רכיב בדיוק. מכאן הרעיון שגיא תיאר ב־11.10: לפי סוג המידע בסכמה אפשר לרנדר לכל פריט תיבת תצוגה שנראית כמו המסך המוכר בקמיליון, עם כותרת, תאריכים ושם הכותב, כך שהסטודיו ייראה לקלינאים כמו קמיליון פרוס לאורך ולא כמו עץ JSON.

הכיוונים: ויזארד, צילום מסך, אפליקציות ודיסקרימינטורים

היום הפרומפט של כל מכתב והתבנית של מה שמוצג בכל מחלקה נכתבים בקוד, ב־commits למאגר. הכיוון שגיא תיאר ב־11.10 הוא ויזארד: כלי פנימי שבו הפרודקט, או מי שמטמיע במחלקות, מתאים מה רואים בכל מחלקה, ויכול לחזור לסטודיו ולהתאים גם את השאילתה שמביאה את הנתונים. לצדו תיאר חלון צ׳אט ליד השאילתה, שבו מבקשים מסוכן את מה שרוצים, והוא בודק את הנתונים בזמן אמת, בונה שאילתה ומראה תצוגה מקדימה. ב־18.10, בדיון על ההטמעה של SmartER, הובחנה ההפרדה בין שליפה כללית לבין התאמה של פרומפט, שדות וכללים לכל מחלקה, וזה בדיוק הממשק שבין הסטודיו לויזארד. הבקשה של שחר מ־10.10 מעלה את השאלה המשלימה: האם רצף של תזמון, סיכום ושאלה שייך לויזארד או ל־AI Flows. זה עוד לא הוכרע.

הצ׳אט מצילום מסך הוא הצעה של יוסף מ־12.10, עם שני אילוצים שהציב באותו יום: הצילומים והמודלים נשארים ברשת הפנימית ובסביבות המאושרות של שיבא. מחקר ההיתכנות שנכתב באותו יום המליץ להתחיל ממודל ויז׳ן מאושר שמזהה את המסך ובוחר מתוך המיפויים הקיימים של רוזטה, בלי אימון, ולעבור למסווג מקומי רק אם זה לא מספיק. העיקרון שם הוא שהתמונה היא דרך נוחה לבקש, אבל רוזטה נשארת הסמכות שקובעת איך שולפים. הסיכון שזוהה הוא שאילתה שרצה בלי שגיאה אבל מביאה משמעות אחרת, למשל הוראת תרופה במקום מתן שלה, ולכן העובדה שהשאילתה רצה אינה מדד הצלחה. לפי ההקלטות של 18.10, ענף הצ׳אט עדיין בעבודה. כדאי לשים לב שזה שינוי לעומת העמדה שיוסף הציג ב־15.9 נגד מסך צ׳אט בתוך הסטודיו; הדיון ההוא לא נסגר בהחלטה, וגם עכשיו אין החלטה צוותית על מקומו של הסוכן.

ב־11.10 יוסף תיאר כיוון רחוק יותר: כלי לבניית אפליקציות לרופאים. אם לכל רכיב יש URI ו־route, ואם רכיבי הממשק של SmartER יכולים להתחבר ולהתנתק כמו בויזארד, אפשר לבקש, למשל, את כל המטופלים שהגיעו היום, לבדוק למי מהם יש ממצא מסוים ולהרכיב מזה תצוגה. אין לכיוון הזה תאריך ואין לו בעלים.

הכיוון הצעיר ביותר הוא הדיסקרימינטורים. ב־18.10 גיא הציע לפרק את בוב לשני חלקים. החלק הראשון הוא תשתית של צוות הפלטפורמה: כלי, ברוח הפלייגראונד של AI Flows, שבונה דיסקרימינטורים, כלומר flow שצמוד לשאילתה, מקבל את התוצאה שלה ומחליט, באמצעות קריאה למודל שמחזירה JSON לפי סכמה או באמצעות קוד Python. החלק השני הוא הריצה בתוך המוצרים: הקוהורט, המצב והטריגרים בתוך SmartER, ואליס או My Patients שמריצים את השאילתות, אולי דרך AI Flows. השם בוב אולי יישאר למסלול המחקרי. זו הצעה בדיון, לא החלטה ולא משהו שנבנה. החיבור לסטודיו ישיר: חצי מכל דיסקרימינטור הוא שאילתה מהסטודיו.

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

מה פתוח, והמלצות הסוכן

הראשונה היא חוזה. שאילתה שמורה היא חוזה בין הסטודיו, רוזטה וכל מי שקורא למזהה שלה. באוגוסט מעבר מסד מחק שאילתות, וב־13.10 שינוי בחוזה הפילטרים שבר צרכנים. הכללים של 1.9 ו־14.9 מגינים על שאילתה מפני דריסה, אבל לא מפני שינוי ברוזטה שמתחתיה. לפי התיעוד, אין היום בדיקה אוטומטית שמריצה את כל השאילתות השמורות מול כל שינוי ברוזטה ומתריעה לפני שמשהו נשבר בפרודקשן.

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

השלישית היא בעלות. ב־14.9 יערה ביקשה להחליט מי מתוך הצוות לוקח בעלות על הסטודיו; לפי התיעוד אין לזה עד היום תשובה פורמלית, ובלוח יש כרטיס ממשק על שם יוסף וכרטיס Rosetta Studio בעדיפות גבוהה ללא בעלים. הסטודיו נבנה בידי אנשי רוזטה, נעקב בלוח של SmartER, מעוצב בידי הפרודקט ונוגע בכל שכבה של רוזטה, מהסכמה ועד ה־SQL. להערכת הסוכן זה בדיוק הסוג של רכיב שלא נסגר כשכל אחד מחזיק חתיכה, וגם מקום טבעי לחפיפה שהוגדרה לחודש הקרוב: הוא מוצר עם משתמשים ולא רק תשתית.

הרביעית היא שימושיות. ההערכה של יערה מ־11.10 והשאלה של אלירן מ־18.10 מצביעות על אותו דבר מכיוונים שונים: הכלי עובד היטב בידי מי שמכיר אותו, ופחות בידי מי שלא. השאלה הארכיטקטונית, האם הסטודיו הוא חלק מתשתית Wildfire או מוצר שיושב מעליה, קשורה לזה ולא הוכרעה.

החמישית היא ביצועים. הטעינה הראשונית של כל נתוני המטופל איטית, וחלק מהשאילתות שנבנות בממשק כבדות יותר ממה שהן צריכות להיות. cache, batching ואופטימיזציות ב־SQL הם רשימה ארוכה שיוסף מנה ב־18.10 ושעוד לא טופלה.

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

חזרה לתשובות · רוזטה ו־Wildfire · סמי, ה־managers ו־AI Flows · מערכת SmartER ו־TMR · הצוותים והתפקידים · מה קורה עכשיו ומה פתוח