איך משתמשים ב־Jev:לנסות ב־Playground, לשלוח בקשת API ולחבר לאוטומציה

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

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

לכן יש שלושה מקומות לעבוד איתו. ב־Playground של TypeSafe בודקים שאלה ביד. דרך ה־API המערכת שואלת בעצמה. ובכלי אוטומציה כמו n8n הוא נכנס כצעד אחד בתהליך שכבר קיים.

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

הדבר הכי קרוב לצ׳אט הוא ה־Playground שבקונסול של TypeSafe. נכנסים עם חשבון, מדביקים טקסט בתור ה־state, כלומר המידע שהמודל מעריך, ומוסיפים שאלה. אפשר לשלב באותה הרצה שאלות Choice, Score ו־Noul ולראות את כל התשובות יחד. מדריך ההתחלה של TypeSafe מראה את זה צעד אחר צעד.

בדוגמה שלנו מדביקים את הודעת החיוב הכפול, ומוסיפים שאלת Choice עם שלושה צוותים ותיאור קצר לכל אחד. חוזרים הצוות שנבחר, ההסתברות שקיבל כל צוות וה־confidence, מספר שמסכם עד כמה ההסתברויות מרוכזות. אין שאלת המשך ואין הסבר במילים, רק תשובה במבנה שהוגדר מראש.

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

ומילה על עברית. לפי עמוד המודלים של TypeSafe, אנגלית היא שפת האימון העיקרית של Jev, ובשפות אחרות הדיוק כרגע נמוך יותר. לכן מדביקים ב־Playground פניות אמיתיות בעברית, עם קיצורים ושגיאות כתיב, ושמים לב במיוחד ל־confidence.

מי שחיפש את Jev כמודל חדש ל־Claude Code, ל־Cursor או לעוזר קוד אחר, לא ימצא אותו שם. TypeSafe כותבת ש־Jev לא מחליף את המודל שמאחורי הכלים האלה, ושאין הגדרה שהופכת עוזר קוד לסוכן AI שמבוסס עליו.

מה שכן קיים לעוזרי קוד הוא skill: חבילת הקשר שמלמדת את Claude Code, את Codex וסוכני AI דומים את ה־API ואת סוגי השאלות. ב־Claude Code מתקינים אותה בשתי פקודות, claude plugin marketplace add typesafe-ai/skills ואחריה claude plugin install typesafe@typesafe-ai. מכאן עוזר הקוד כותב את החיבור, ו־Jev הוא מה שהקוד הזה קורא לו.

בתוך החלון של ChatGPT או של Claude לא מצאנו אפליקציה רשמית של TypeSafe. יש מחברי MCP שבנו צדדים שלישיים, למשל AnythingMCP, שמאפשרים למודל הצ׳אט לקרוא ל־Jev ככלי. ב־ChatGPT זה דורש מצב מפתחים בתוכנית בתשלום, ואת מפתח ה־API של TypeSafe שומרים אצל אותו צד שלישי.

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

במערכת עצמה, Jev הוא בקשת POST אחת לכתובת https://api.typesafe.ai/v1/systemone. את מפתח ה־API מנפיקים בקונסול של TypeSafe ושולחים בכותרת Authorization. גוף הבקשה הוא JSON עם שלושה שדות:

• state: המידע להערכה. מחרוזת טקסט, או אובייקט JSON עם שדות בעלי שם, כמו ההודעה ומספר ההזמנה.
• model: שם המודל. jev-latest מצביע על הגרסה הרשמית האחרונה.
• questions: השאלות, כל אחת תחת שם שבוחרים. לכל שאלה יש type ו־instructions עם השאלה עצמה, וב־Choice וב־Score גם criteria עם האפשרויות או הדרגות.

לפי מדריך ה־API, התשובה חוזרת תחת אותם שמות. השם עצמו, למשל team, לא נשלח למודל, ולכן כל מה שהמודל צריך לדעת נכתב בשאלה ובאפשרויות. שאלת Choice מחזירה שלושה שדות:

• choice: האפשרות שקיבלה את ההסתברות הגבוהה ביותר.
• probabilities: ההסתברות של כל אפשרות, וסכומן 1.
• confidence: מספר בין 0 ל־1 שנגזר מההסתברויות. ב־Score מקבלים גם score, וב־Noul מקבלים רק noul.

בדוגמה ממדריך ההתחלה, הודעה על חיבור ל־Stripe שנכשל כבר שלושה ימים נותבה ל־technical בהסתברות 0.85, עם confidence של 0.78. שני המספרים שונים בכוונה: ההסתברות שייכת לאפשרות אחת, וה־confidence מסכם את כל ההתפלגות. בפרק השלישי נראה למה זה משנה כשקובעים רף.

בראש התשובה, השדה model מציין איזו גרסה ענתה בפועל, למשל jev-1.13.0, וכדאי לשמור אותו לצד כל תשובה. כשמשהו משתבש מקבלים סטטוס HTTP רגיל: 401 למפתח חסר או שגוי, 422 לבקשה שלא עברה בדיקה, ו־429 או 529 כשצריך לחכות ולנסות שוב. ה־SDK הרשמיים ל־Python ול־JavaScript מנסים שוב לבד, במרווחים שהולכים וגדלים.

רוב העסקים לא יכתבו אפליקציה רק כדי לנסות את Jev. אם התהליך כבר רץ בכלי אוטומציה, Jev נכנס כצעד HTTP אחד: הכלי שולח את אותה בקשת POST, מקבל JSON ומעביר אותו הלאה. אחריו בא צעד תנאי, שקורא את הבחירה ואת ה־confidence ומחליט לאן הפנייה ממשיכה.

בספריית התבניות של n8n יש תבנית שבנה משתמש מהקהילה, לא TypeSafe, שממיינת מיילים ב־Gmail. היא קוראת ל־Jev דרך רכיב ה־HTTP Request המובנה, עם פרטי התחברות מסוג Bearer שמחזיקים את מפתח ה־API. רף confidence קובע איזו תווית מודבקת, ומייל שהתשובה עליו לא ברורה מספיק מקבל תווית ״Needs Review״.

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

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

הדרך הקצרה לדעת אם Jev מתאים לתהליך מסוים היא לא עוד קריאה בתיעוד. פותחים את ה־Playground עם מדגם של פניות אמיתיות, מנסחים שאלה אחת ומגדירים אפשרויות עם תיאור. אחר כך בודקים איפה התשובות מסכימות עם מה שאנשי הצוות היו עושים, ואיפה לא.

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

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