מילון בינה מלאכותית

תווית שמשתנה, לא טכנולוגיה. «AI» אינו מציין דבר קבוע כמו model או token — הוא מצביע על מה שמחשבים מסוגלים לעשות כעת באופן חדש ומרשים. כיום הוא מצביע על מודלי שפה גדולים. בעבר הוא הצביע על דברים שונים מאוד:

המצביע מתקדם במנגנון מוכר, שנקרא לפעמים אפקט ה-AI: ברגע שטכניקה פועלת באופן אמין, משנים לה את השם — היא הופכת «רק» לחיפוש, «רק» לסטטיסטיקה — ו«AI» מתקדם אל הדבר הבא שטרם נפתר. התצפית ישנה. ברטרם רפאל ניסח זאת ב־1971 כך: «AI הוא שם כולל לבעיות שעוד איננו יודעים לפתור כראוי באמצעות מחשב.» הגרסה של לארי טסלר, מסביבות 1979: «אינטליגנציה היא כל דבר שמכונות עדיין לא עשו.»

לכן שיחות על AI מחמיצות לעיתים קרובות זו את זו. טענה כמו «AI לא מסוגל לחשוב» או «AI מופרז בהייפ» נושאת חותמת זמן נסתרת — ייתכן שהיא עוסקת במערכות מומחה, במסווגי תמונות משנות ה־2010 או ב-LLM של החודש שעבר, וכל אחת מההתייחסויות מובילה למסקנה אחרת. כשדיון על AI נתקע, הפתרון בדרך כלל הוא להחליף את המילה במונח המדויק שאליו מתכוונים: ה-model, ה-harness, ה-agent או ה-context שניתן לו.

הימנעו מ: «AI» בכל טענה טכנית — ציינו במקום זאת את הרכיב שאליו מתכוונים. «כתיבת קוד בעזרת AI» כתווית לתחום היא בסדר; «ה-AI הוזה» אינו ניסוח מתאים.

שימוש:

«המנכ״ל רוצה לדעת אם AI יכול לטפל בתור הטריאז׳.»

«תרגמו את זה לפני שתגדירו את היקף העבודה — היא מתכוונת ל-LLM בתוך harness עם גישה למערכת הכרטיסים. 'AI' לבדו אינו מפרט.»

הפרמטרים. חסר מצב — מבצע חיזוי של האסימון הבא ותו לא. ״Claude Opus 4.x״ ו-״GPT-5.x״ הם מודלים. מודל אינו יכול לפעול כסוכן בפני עצמו; צריך להפעיל אותו באמצעות רתמת עבודה.

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

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

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

שימוש:

״כדאי להחליף את המודל מ-Sonnet ל-Opus בשלב התכנון?״

״נסה — אבל רתמת העבודה עושה את רוב העבודה במשימה הזאת. החלפת המודל לא תעזור אם הנחיית המערכת והכלים שגויים.״

המספרים שבתוך מודל — לעיתים קרובות מיליארדים מהם — שמכווננים במהלך האימון. כל מה שהמודל ״יודע״ נמצא בהם. האימון קובע אותם; הסקה משתמשת בהם ללא שינוי. הם נקראים גם משקולות.

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

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

שימוש:

״אפשר לכוונן אותו על בסיס הקוד שלנו?״

״זה יעדכן את הפרמטרים — ואחר כך יהיה לך מודל אחר. בפרויקט יחיד כמעט תמיד זול יותר לטעון את בסיס הקוד כהקשר מאשר לאמן מחדש.״

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

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

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

שימוש:

״אפשר לגרום לו להכיר את ממשק ה-API הפנימי שלנו?״

״לא באמצעות אימון — זה תהליך של חודשים שמבצע ספק המודל. טען את תיעוד ה-API להקשר; זה המנוף שבאמת עומד לרשותך.״

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

חיי מודל נחלקים לשני שלבים:

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

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

שימוש:

״למה החשבון גדל עם השימוש במקום להיות רישיון בתשלום קבוע?״

״אתה משלם על הסקה — בכל בקשה לספק המודל הוא מופעל על החומרה של הספק. האימון כבר התרחש, אך עלויות ההסקה מצטברות לפי מספר הבקשות, ותור יחיד יכול להתפרס על בקשות רבות כשקוראים לכלים.״

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

מאמץ גבוה יותר עולה יותר ופועל לאט יותר. הנימוקים נפלטים כ-tokens, מחויבים כ-tokens של פלט גם כשאינכם רואים אותם ומופקים אחד־אחד — לכן הגדלת המאמץ מאריכה את ההמתנה לתשובה ומגדילה את החשבון. זו פשרה בין יותר שיקול דעת לבין מהירות ועלות.

רוב ה-harnesses חושפים את המאמץ בסולם קצר:

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

התאימו את המאמץ למשימה, לא ל-session. הגדילו אותו לחלק שבאמת קשה לנמק, והפחיתו אותו לעבודה השגרתית שמסביב.

שימוש:

«הוא ממשיך לפשל בתיקון המקביליות הזה — הסברתי אותו מחדש שלוש פעמים.»

«העלו את המאמץ. זה באג שדורש הרבה נימוקים, ובהגדרת ברירת המחדל הוא לא חושב מספיק לפני שהוא מתחייב לגישה.»

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

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

ככלל אצבע, אסימון אחד הוא בערך שלושה רבעים ממילה באנגלית, ולכן אלף אסימונים הם בערך 750 מילים. קוד פחות צפוי: מילות מפתח וביטויים נפוצים מתחלקים באופן תמציתי, ואילו מזהים שנוצרו, גיבובים, נתוני base64 ופלט ממוזער מתחלקים להרבה אסימונים בכל ״מילה״. הדפוס הוא שטקסט שהופיע לעיתים קרובות בחומר המקור של מנתח האסימונים מקבל קידוד קצר ויעיל; טקסט שלא הופיע שם נחתך להרבה חלקים קטנים. גיבוב כמו `a3f9c2e1` מעולם לא הופיע בשום מקום, ולכן הוא מתחלק לאסימונים רבים, ואילו `function` הוא אסימון אחד. לכן קובץ שנראה קטן אך מלא במחרוזות חריגות עלול לתפוס חלק מפתיע מחלון ההקשר.

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

הימנע: מ״מילה״ — גבולות האסימונים אינם תואמים לגבולות המילים, והיחידות שבאמת חשובות הן אסימונים לשנייה ואסימונים לדולר.

שימוש:

״כמה גדול הפרומפט הזה עומד להיות?״

״העבר אותו דרך מנתח האסימונים — הסכימה קומפקטית, אבל מפתחות ה-JSON משונים, ולכן הם יתחלקו ליותר אסימונים מכפי שנדמה לך.״

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

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

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

שימוש:

״איך הסוכן ׳מחליט׳ לקרוא לכלי?״

״הוא לא מחליט — הכול הוא חיזוי האסימון הבא. קריאת הכלי היא רק מחרוזת מובנית שרתמת העבודה מנתחת מתוך זרם הפלט.״

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

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

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

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

שימוש:

״Claude היה נורא היום. הם שחררו גרסה גרועה יותר?״

״כנראה שלא — הפלט של המודל אינו דטרמיניסטי. יהיו לך ימים טובים ורעים באותה משימה. נסה שוב מחר לפני שתחפש סיבה.״

מי שמספק מודל לצורך הסקה. בדרך כלל מדובר בשירות מרוחק (Anthropic, OpenAI, Google), אך הוא יכול להיות גם מקומי — Ollama, LM Studio או llama.cpp שרצים במחשב שלך. רתמת העבודה אינה מריצה את המודל בעצמה; היא מבקשת מספק להריץ אותו.

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

הספק גם קובע את התנאים המסחריים: תמחור לכל אסימון של קלט ואסימוני פלט, הנחות של מטמון קידומות, ואילו מודלים זמינים בכלל. שים לב שהספק ויוצר המודל יכולים להיות חברות שונות — Bedrock, Vertex ו-OpenRouter מספקים מודלים של חברות אחרות.

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

שימוש:

״אפשר להריץ את זה במצב לא מקוון עבור הלקוח המנותק מהרשת?״

״החלף את ספק המודל לספק מקומי — Ollama או llama.cpp במחשב שלו. לרתמת העבודה לא אכפת; היא פשוט פונה לנקודת קצה אחרת.״

כל מה שמקיף את ה-model והופך אותו ל-agent: כלים, הנחיית מערכת, ניהול חלון context, הרשאות ו-hooks. Claude.ai ו-Claude Code פועלים על אותו model אך מתנהגים אחרת משום שה-harnesses שלהם שונים.

ה-model עצמו עושה רק דבר אחד: מקבל טקסט ומפיק טקסט. הוא אינו יכול לקרוא קובץ, להריץ פקודה או לזכור את ה-תור האחרון. ה-harness מספק את כל אלה. הוא מרכיב את ה-context לכל בקשת ספק model, מבצע את קריאות הכלים שה-model מבקש, מזין בחזרה את תוצאות הכלים, שומר את היסטוריית ה-session, מבקש מכם הרשאה לפני פעולות מסוכנות ומחליט מתי לבצע compact. לולאת ה-agent — ה-model מציע, ה-harness מבצע וחוזרים על כך — מנוהלת בידי ה-harness.

הדבר חשוב לאבחון. כשההתנהגות שונה בין שני מוצרים, או בין אתמול להיום, ה-model לרוב אינו המשתנה — ה-harness הוא. הנחיית מערכת אחרת, סט כלים אחר, ברירת מחדל שונה להרשאות או אסטרטגיית ניהול context חדשה משנים את ההתנהגות בלי שינוי כלשהו ב-model. פירוש הדבר גם שרוב ההגדרות שלכם נמצאות ב-harness: קובצי AGENTS.md, הגדרות הרשאה ו-hooks הם הוראות ל-harness, לא ל-model.

דוגמאות: Claude Code, Cursor, Codex CLI — וגם Claude.ai, שהוא harness לצ'אט ולא לכתיבת קוד.

שימוש:

«אותו model — למה Claude Code עורך קבצים ו-Claude.ai רק עונה לשאלות?»

«Harnesses שונים — ל-Claude Code יש כלי מערכת קבצים, הנחיית מערכת אחרת ושכבת הרשאות. ה-model אינו המשתנה כאן.»

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

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

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

כדאי להבחין בין בקשה לתור. תור הוא חילוף אחד איתך, ותור יחיד — ״תקן את הבדיקה שנכשלה״ — מתבצע כשרשרת בקשות:

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

שימוש:

״שאלה אחת שרפה ארבעים אלף אסימונים?״

״בדוק את קריאות הכלים — שתים-עשרה grep, שמונה קריאות קובץ וארבע עריכות. כל תוצאת כלי מפעילה בקשה נוספת לספק המודל, ובכל פעם נשלחת מחדש גם כל קידומת המפגש.״

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

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

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

שימוש:

״החשבון גבוה, אבל הסוכן כמעט לא כותב כלום.״

״אלה אסימוני הקלט — בכל תור נשלח מחדש כל המפגש. בלי מטמון הקידומות משלמים מחדש על ההיסטוריה בכל בקשה.״

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

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

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

שימוש:

״מפגש השינוי המבני שורף לי את התקציב למרות שהקלטים קטנים.״

״הסוכן משכתב קבצים שלמים במקום להחיל תיקונים. אסימוני פלט עולים בערך פי חמישה מתעריף הקלט — בקש ממנו להפיק עריכות והחשבון יקטן.״

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

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

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

שימוש:

״למה החשבון זינק באמצע המפגש?״

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

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

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

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

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

שימוש:

״מפגשים ארוכים עולים בטירוף — שמונה דולר על שינוי מבני.״

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

אינו נושא מידע קדימה. ה-model חסר מצב בין בקשות לספק ה-model — בכל בקשה נשלח מחדש כל חלון ה-context, משום של-model אין דרך לראות דבר נוסף. כברירת מחדל, agent חסר מצב בין sessions: session חדש מתחיל ריק, בלי זכר לקודמים. ההפך מ-בעל מצב.

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

המסקנה המעשית: אם רוצים שמשהו ייזכר בין sessions, צריך לכתוב אותו במקום שה-agent יקרא שוב. לשם כך נועדו קובצי AGENTS.md, מערכות זיכרון ו-מסמכי העברת עבודה — קבצים שנטענים ל-context של sessions עתידיים ומחליפים את הזיכרון שאין ל-model. כשה-agent חוזר על טעות שכבר תיקנתם, השאלה אינה מדוע לא למד — הוא אינו יכול — אלא היכן לכתוב את התיקון כדי שכל session עתידי יקרא אותו.

שימוש:

«למה הוא שוכח את המוסכמה בכל פעם שאני עושה ניקוי?»

«ל-model אין מצב — ה-session החדש מתחיל ריק. אם רוצים לשמור את המידע, כתבו אותו ב-AGENTS.md או בקובץ זיכרון שה-harness טוען בתחילת session.»

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

שלושת המונחים נבדלים בבירור:

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

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

שימוש:

״הוא כל הזמן ממציא שדות שלא קיימים בטיפוס.״

״קובץ הטיפוס לא נמצא בהקשר — הוא קורא למקומות שבהם קוראים לו ומנחש. קרא תחילה את ההגדרה.״

כל מה שה-model רואה בכל בקשת ספק model. הכמות סופית, תלויה ב-model, וזו המשטח היחיד שדרכו ה-model תופס דבר כלשהו.

זהו רצף יחיד של tokens: הנחיית המערכת, השיחה עד כה וכל תוצאת כלי שה-harness הזין בחזרה. אם משהו נמצא ברצף הזה, ה-model יכול להשתמש בו; אם לא, ה-model אינו יודע שהוא קיים — לא את בסיס הקוד שלכם, לא את הקובץ שערך אתמול ולא את ההנחיה שנתתם לפני שלושה sessions. כל דבר שנמצא מחוץ לחלון חייב להיכנס אליו, בדרך כלל באמצעות קריאת כלי, לפני שיוכל להשפיע.

הכמות הסופית פירושה שהחלון מתמלא. בכל תור מתווסף עוד — ההודעות שלכם, תשובות ה-model ותוצאות כלים — ו-session ארוך יגיע בסופו של דבר למגבלה ויכפה compaction או ניקוי. פירוש הדבר גם שכל מה שבחלון מתחרה: כל token שטענתם מפחית את המקום שנותר לאחרים, ותוכן שאין בו צורך עדיין תופס את קשב ה-model. הגישה המעשית היא להתייחס לחלון כאל תקציב — לטעון את מה שהמשימה צריכה ולהשאיר בחוץ את היתר.

הימנעו מ: «זיכרון» — חלון ה-context הוא מצב עבודה ואינו נשמר בין sessions. זיכרון הוא מושג נפרד שמונח מעליו.

שימוש:

«אפשר פשוט להדביק את כל המאגר הרב־חבילות לתוך ה-prompt?»

«חלון ה-context הוא 200k tokens — אולי חמישית מהמאגר. בחרו את הקבצים שהמשימה נוגעת בהם והשאירו את השאר מאחורי קריאת כלי.»

נושא מידע קדימה. Session הוא בעל מצב לאורך תורות — context מצטבר ככל שה-session מתקדם, ולכן sessions ארוכים נסחפים אל אזור הטיפשות. אפשר להפוך agent לבעל מצב בין sessions באמצעות הוספת מערכת זיכרון ששומרת מידע ב-סביבה וטוענת אותו מחדש בתחילת sessions עתידיים. ה-model לעולם אינו בעל מצב; כל תחושת רציפות נוצרת מכך שה-harness מזין לו מחדש context. ההפך מ-חסר מצב.

מיקום המצב בכל שכבה:

המצביות של כל שכבה נוצרת מקריאה חוזרת של דבר שנשמר בשכבה שמתחתיה: ה-session מרגיש רציף משום שה-harness שולח שוב את היסטוריית ההודעות ל-model חסר־המצב, וה-agent זוכר בין sessions משום שה-harness טוען מחדש קבצים מהסביבה. מצב לעולם אינו נשמר בתוך ה-model עצמו.

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

שימוש:

«הוא זכר את ההעדפות שלי מאתמול — האם זה אומר שה-model למד אותן?»

«לא, ה-agent בעל מצב כי ה-harness כתב אותן לקובץ זיכרון וטען אותו מחדש בתחילת ה-session. ה-model עצמו לא ראה דבר מאתמול.»

model שמותקן בו harness עם כלים, הנחיית מערכת ו-חלון context, ומנהל תורות עם משתמש. Claude Code הוא agent. Cursor הוא agent. Claude.ai הוא agent. Agent הוא הגורם שאיתו אתם באמת מדברים — ה-model בפעולה, מוגדר למטרה מסוימת.

בניגוד לרוב המונחים במילון הזה, «agent» אינו מציין רכיב מכני. ה-model הוא קובץ של פרמטרים; ה-harness הוא תוכנה שאפשר להפעיל. ה-agent אינו אף אחד מהם — הוא היחידה שאליה אתם פונים. אנשים מייחסים ל-AI תכונות אנושיות ללא הרף, וה-agent הוא היחידה האנושית־לכאורה: הדבר שאליו אתם מאצילים משימה, שקורא את הודעתכם ומשיב, ה«הוא» במשפט «הוא שוב שבר את ה-build». כשאומרים שה-agent עשה משהו, הכוונה היא שה-model יחד עם ה-harness עשה זאת, אך מתייחסים לשילוב כשחקן יחיד.

הרעיון ותיק יותר מגל ה-AI הנוכחי. Software agents — תוכניות שמאצילים להן מטרה והן פועלות מטעמכם — הם מושג ותיק כמו ה-AI עצמו.

הימנעו מ: «ה-AI», «הבוט» (מעורפלים מדי — הם מסתירים אם הכוונה לפרמטרים או לדבר שמצויד ב-harness).

שימוש:

«באיזה agent אתה משתמש להעברה?»

«Claude Code מקומית, Cursor לעבודה על הממשק — אותו model מתחת למכסה המנוע, harnesses שונים.»

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

הספק של רתמת העבודה כותב את הנחיית המערכת, לא אתה, וברתמות קידוד היא ארוכה — לעיתים קרובות עשרות אלפי אסימונים של כללי התנהגות, תיאורי כלים וטיפול במקרי קצה, שכולם מחויבים כאסימוני קלט בכל תור. גם ההוראות הקבועות שלך מצורפות אליה: קבצים כמו AGENTS.md נטענים לצד הנחיית המערכת בתחילת המפגש, כך שהמודל קורא את התדריך של הספק ואת שלך יחד לפני שהוא רואה את ההודעה שלך.

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

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

שימוש:

״שתי רתמות עבודה, אותו מודל, התנהגות שונה לחלוטין מול אותו פרומפט.״

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

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

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

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

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

שימוש:

״כמה זמן מפגש יכול להימשך לפני שהוא מתחיל להתפרק?״

״זה תלוי בעבודה — שכתוב ממוקד נשאר חד למשך זמן רב יותר ממחקר פתוח. כשההקשר מתנפח, העבר את העבודה הלאה או תמצת אותו; אל תמשיך בכוח.״

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

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

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

שימוש:

״תור אחד ארך שתי דקות?״

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

העולם שבו הסוכן פועל — כל מה שנמצא מחוץ לרתמת העבודה, שהסוכן תופס באמצעות תוצאות כלים ומשנה באמצעות קריאות לכלים. רתמת העבודה מריצה את הסוכן; הסביבה היא המקום שבו הסוכן עובד. קובץ כמו `AGENTS.md` נמצא בסביבה; רתמת העבודה היא שטוענת אותו לחלון ההקשר. מערכת קבצים היא הסביבה הנפוצה ביותר, אך לא היחידה — גם מסד נתונים, API מרוחק או הפעלת דפדפן יכולים להיות סביבות.

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

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

אתה מחליט מה גודל הסביבה. ארגז חול מצמצם אותה ומגביל למה הסוכן יכול להגיע; הוספת כלי מרחיבה אותה ומאפשרת גישה למסד נתונים או ל-API. מה שנמצא בתוך הגבול הוא מה שהסוכן יכול לתפוס ולשנות; כל מה שמחוץ לו אינו קיים עבורו. מידת ההתאמה של הסביבה לתמיכה בעבודת הסוכן היא ה-AX של בסיס הקוד.

הימנע: משימוש ב״סביבה״ כדי להתייחס לזמן הריצה או לרתמת העבודה עצמה — רתמת העבודה היא העוטפת, והסביבה היא סביבת העבודה.

שימוש:

״הסוכן לא יכול לראות את סכימת מסד הנתונים של staging.״

״חבר אותו לסביבה — תן לו כלי `psql` שמוגבל לקריאה בלבד ב-staging. רתמת העבודה בסדר; פשוט אין לה שום דבר לפעול עליו.״

עץ של קבצים ותיקיות שה-agent קורא, כותב ומריץ בתוכו — סוג ברירת המחדל של סביבה עבור agent לכתיבת קוד. AGENTS.md, skills, קוד מקור, סקריפטי build והגדרות כלים נמצאים כולם במערכת קבצים. כש-harness «מתחיל בפרויקט שלכם», הוא מכוון את ה-agent למערכת קבצים.

ה-agent נוגע בה רק דרך קריאות כלים — קריאת קובץ, כתיבתו או הרצת פקודת shell. שום דבר בדיסק אינו בחלון ה-context עד שקריאת כלי טוענת אותו, ולכן ה-agent יכול לעבוד במאגר גדול בהרבה מהחלון: מערכת הקבצים מכילה הכול, וה-context מכיל רק את מה שהמשימה הנוכחית כבר קראה. יש harnesses שטוענים כברירת מחדל את שמות הקבצים בתיקייה הנוכחית לחלון ה-context — לא את התוכן, רק את העץ — והם משמשים כ-מצביעי context: ה-agent רואה מה קיים וקורא את הקבצים הדרושים לו.

המערכת משותפת גם לכם. הקבצים שה-agent עורך הם אותם קבצים שאתם פותחים בעורך ומשווים ב-git — מערכת הקבצים היא סביבת העבודה המשותפת שבה אתם בודקים את עבודתו.

שימוש:

«למה הוא לא מזהה את AGENTS.md שלי?»

«הוא פועל מול מערכת קבצים אחרת — ה-sandbox חיבר את תיקיית האב, לא את שורש הפרויקט. כוונו מחדש את ה-harness.»

פונקציה שה-harness חושף כדי שה-agent יוכל להפעיל — Read, Write, Bash, Search. כך agent תופס ופועל על ה-סביבה: הוא אינו יכול לראות את הסביבה אלא דרך תוצאות כלים, ואינו יכול לשנותה אלא באמצעות קריאות כלים. כל קריאת כלי עולה בקשת ספק model נוספת, מפני שהתוצאה צריכה לחזור ל-model לפני שיוכל להחליט מה לעשות הלאה.

כלים שמגיעים עם רוב agents לכתיבת קוד:

כלי מוגדר באמצעות שלושה דברים: שם, תיאור של פעולתו וסכמה לפרמטרים שלו. ה-harness שולח את ההגדרות האלה ל-model בכל בקשה, וה-model בוחר כלי כפי שהוא מפיק כל דבר אחר — באמצעות כתיבת tokens, במקרה הזה קריאה מובנית עם ארגומנטים. ה-model עצמו לעולם אינו מריץ דבר; ה-harness קורא את הקריאה, מפעיל את הפונקציה ומחזיר את התוצאה.

רשימת הכלים קובעת מה ה-agent יכול לעשות. Model מסוגל עם סט כלים מצומצם הוא agent מצומצם: הוא ינתב הכול דרך מה שיש לו, ולכן agents נשענים כל כך על Bash — shell הוא כלי יחיד שמגיע לרוב המערכת. כדי לתת ל-agent יכולת באופן נקי, הוסיפו לה כלי; MCP הוא התקן לחיבור כלים שמחוץ ל-harness.

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

שימוש:

«האם ה-agent יכול לשאול ישירות את staging?»

«הוסיפו ל-harness כלי `psql`, עם הרשאת קריאה בלבד ב-staging. בלי כלי כזה, ה-agent עיוור לכל מה שמחוץ למערכת הקבצים.»

הפלט של המודל שמציין כלי ואת הארגומנטים שלו — טקסט מובנה בלבד. הוא אינו עושה דבר בפני עצמו; רתמת העבודה צריכה לקרוא אותו ולבצע אותו. המודל מפיק אותו בבקשה אחת לספק המודל.

מחזור החיים של קריאה לכלי:

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

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

שימוש:

״הוא אמר שהריץ את הבדיקות, אבל חותמות הזמן של הקבצים לא השתנו.״

״בדוק את התמליל — האם הוא באמת פלט קריאה לכלי, או רק תיאר הרצה שלהן? המודל יוצר את הקריאה, אבל אם רתמת העבודה לא ביצעה אותה, לא קרה דבר.״

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

מחזור החיים של תוצאת כלי:

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

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

שימוש:

״הוא מנתח את הקובץ כאילו הוא ריק.״

״תוצאת הכלי הייתה סירוב הרשאה, לא תוכן הקובץ. המודל ראה רק את מחרוזת השגיאה — אין לו דרך אחרת לראות את הקובץ.״

Model Context Protocol. פרוטוקול לחיבור שרתי כלים חיצוניים ל-harness — כך agent מקבל tools מעבר למה שמגיע עם ה-harness. ה-agent אף פעם לא «קורא ל-MCP»; הוא קורא לכלי, ובמקרה ה-harness קיבל את הכלי משרת MCP. הפרוטוקול חושף גם משאבים (נתונים לקריאה בלבד) ו-prompts (תבניות לשימוש חוזר), אך אספקת כלים היא השימוש העיקרי.

הפרוטוקול פותר בעיית אינטגרציה. בלי תקן, כל harness היה צריך אינטגרציה משלו ל-Linear, ל-Slack ולמסד נתונים — כל אחת נכתבת ומתוחזקת בנפרד. עם MCP, כותבים את האינטגרציה פעם אחת כשרת, וכל harness תואם MCP יכול להשתמש בה. ה-harness מתחבר לשרת, השרת מפרסם אילו כלים הוא מציע, והם נעשים זמינים ל-agent לצד הכלים המובנים.

המחיר משולם ב-context. כל כלי ששרת מפרסם מגיע כהגדרה — שם, תיאור וסכמת פרמטרים — וה-model יכול לקרוא רק לכלים שהוא מכיר. הגישה הפשוטה טוענת מראש כל הגדרה לתוך חלון ה-context: מתקינים כמה שרתים נדיבים ומתחילים session עם אלפי tokens של סכמות כלים לפני שהקלדתם דבר, ומבזבזים תקציב קשב על כלים שהמשימה לעולם לא תשתמש בהם.

כיום, harnesses רבים מצמצמים זאת בעזרת חיפוש כלים: במקום ההגדרות המלאות, ה-context מכיל מצביע context לכלים הזמינים — ה-agent מחפש כלי לפי שם או מטרה וטוען את הגדרתו רק כשצריך אותו. אם ה-harness שלכם אינו עושה זאת, העלות המוקדמת עדיין חלה, וכדאי להפעיל רק את השרתים שהפרויקט באמת זקוק להם.

שימוש:

«ה-agent צריך לקרוא כרטיסים מ-Linear.»

«הגדירו את ה-harness להשתמש בשרת Linear MCP — הוא חושף את ה-API של Linear ככלים שה-agent יכול לקרוא להם. כך נחסכת כתיבת עטיפות כלים מותאמות.»

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

מחזור החיים של בקשת הרשאה:

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

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

שימוש:

״הוא תקוע על בקשת הרשאה כבר עשר דקות — הייתי בפגישה.״

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

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

רתמות עבודה מציעות מדרג של מצבים כאלה:

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

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

שימוש:

״הוא נעצר בכל grep — זה הרס לגמרי את ההרצה ללא השגחה.״

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

תצורה קבועה מראש שמעצבת כיצד agent פועל בזמן ריצה — היא משלבת מצב הרשאות עם הוראות התנהגות שמוזרקות אל הנחיית המערכת. לדוגמה: ברירת מחדל שמבקשת אישור לפעולות מסוכנות, מצב plan שחוסם עריכות ומכוון את ה-agent למחקר, מצב accept-edits שמאשר עריכות אוטומטית, או מצב bypass permissions (המכונה בשיחה מצב YOLO) שמאשר הכול אוטומטית. אפשר לעבור מצב גם באמצע session.

השילוב הוא שמבדיל מצב מהגדרת הרשאה חשופה. מצב הרשאות הוא רק שער: הוא קובע אילו קריאות כלים עוברות. שער לבדו יוצר agent שרוצה לערוך אך אינו יכול — הוא מציע כתיבה, נחסם ומנסה דרך אחרת. ההוראות המוזרקות מסירות את הרצון: מצב plan אינו רק חוסם עריכות, הוא אומר ל-agent שהוא בשלב תכנון, ולכן הוא קורא, שואל ומציע במקום להתאמץ לעקוף את השער. השער וההכוונה פועלים לאותו כיוון.

בפועל משנים מצב כשהאמון משתנה לאורך המשימה. אותה משימה עשויה לעבור כמה מצבים: מצב plan כל עוד הגישה מתעצבת, ברירת המחדל ששואלת לפני העריכות העדינות הראשונות, accept-edits לאחר שה-agent הראה שהוא מבין את השינוי, ו-bypass להרצת AFK בתוך sandbox. שינוי מצב אינו עולה דבר: השיחה נמשכת בדיוק מאותה נקודה, עם הרשאות והוראות חדשות. אם אתם מאשרים כל הנחיה בלי לקרוא אותה, המצב מחמיר יותר מרמת האמון בפועל; אם אתם דוחים שוב ושוב עריכות, הוא מקל מדי.

מונחים של ספקים: Claude Code קורא להם «מצבי הרשאה», ו-Codex קורא להם «מצבי אישור» — שניהם קדמו לשילוב הוראות התנהגות.

שימוש:

«הוא ממשיך לערוך קבצים כשאני רק רוצה תוכנית.»

«עברו למצב plan — הוא יחסום כתיבות ויישאר במחקר.»

«ומה לגבי הרצת AFK מאוחר יותר?»

«מצב bypass, אבל רק בתוך ה-sandbox.»

סביבה מבודדת שבה ה-agent פועל — container, VM, מערכת קבצים זמנית או shell עם הרשאות מוגבלות. היא מצמצמת את רדיוס הנזק של פעולות agent: גם אם הוא מריץ פקודות הרסניות או מוריד דבר זדוני, הנזק נשאר תחום. זהו תשתית הבטיחות שהופכת עבודה AFK למעשית.

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

לבידוד יש דרגות:

מה ששום sandbox אינו מכיל: פעולות שיוצאות ממנו באופן לגיטימי. Agent עם פרטי git שלכם יכול לבצע push; אחד עם גישה לרשת יכול לקרוא ל-API של ייצור. החליטו מה חוצה את הגבול לפני שתחליטו כמה עבה לבנות אותו.

שימוש:

«אני רוצה לתת לו לפעול עם bypass-permissions במשך הלילה, אבל עדיין אינני מוכן לכך.»

«הכניסו אותו ל-sandbox — container חדש, בלי אישורים ובלי רשת יוצאת. בתרחיש הגרוע הוא הורס את מערכת הקבצים של עצמו ואתם משליכים את ה-container.»

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

מתבטא כך:

• כניעה ללחץ — חוזר בו מתשובה נכונה כשאומרים «אתה בטוח?».
• שבח לקלט גרוע — מסכים שהתוכנית השבורה שלכם מבריקה עוד לפני שניתח אותה.
• מסגור מוטה — הסקירה נוטה לחיוב כשאתם מציינים שכתבתם את הדבר, ולשלילה כשאתם אומרים שמישהו אחר כתב אותו. אותו תוצר, פסק דין שונה.
• חיקוי — מחזיר לכם את הטעויות שלכם כאישור.

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

תיקון: הסתירו את העדפותיכם. נסחו prompts באופן ניטרלי — «סקור את הקוד הזה», לא «האם הקוד הזה טוב?».

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

שימוש:

«הוא אמר שתוכנית השכתוב שלי נראית נהדר, ואז שאלתי 'אתה בטוח?' והוא חזר בו לחלוטין.»

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

פלט model שבטוח בעצמו אך טועה. יש שני סוגים עם סיבות ופתרונות שונים:

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

צריך לדעת באיזה סוג מדובר, כי התיקון לאחד מחמיר את האחר. נכונות עובדתית משמעה שחסר ידע: הפתרון הוא הוספת context — תיעוד, הגדרות טיפוסים או הקובץ. נאמנות משמעה שהידע קיים אך מפסיד בתחרות על הקשב: הפתרון הוא הסרת context. אם מאבחנים בטעות בעיית נאמנות כבעיית נכונות עובדתית, מדביקים עוד תיעוד, שמגדיל את ה-context ומחמיר את הסטייה. כשה-agent טועה, בדקו אם המידע הנכון כבר היה ב-context לפני שתחליטו באיזו בעיה מדובר.

הימנעו מ: שימוש ב«הזיה» כמילה נרדפת סתמית ל«טעות» — בלי לציין את הסוג, למונח אין ערך אבחוני.

שימוש:

«הוא המציא שיטת `parseAsync` בסכמה.»

«נכונות עובדתית או נאמנות?»

«השיטה קיימת בתיעוד שהדבקתי — הוא פשוט הפסיק לקרוא אותו אחרי תור ארבעים.»

«אז זו בעיית נאמנות. בצעו compaction וטענו מחדש; אל תוסיפו עוד תיעוד.»

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

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

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

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

שימוש:

״הוא כותב React ללא רבב אבל ממציא שיטות ב-SDK הפנימי שלנו.״

״React צפופה בידע הפרמטרי — מיליוני דוגמאות אימון. ה-SDK שלך אינו כזה, ולכן המודל משלים צורות שנראות סבירות. טען את תיעוד ה-SDK להקשר.״

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

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

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

שימוש:

״הוא ממשיך לכתוב תחביר של SDK v3 — אנחנו ב-v5.״

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

עובדות שה-agent יכול לקרוא ישירות מתוך ה-context כרגע — משימת המשתמש, קבצים שה-agent קרא, תוצאות כלים ותוכן AGENTS.md שנטען בתחילת session. המקביל של ידע פרמטרי: ידע פרמטרי נשלף מהזיכרון מתוך הפרמטרים; ידע הקשרי נקרא מתוך ה-חלון. הזיות נדירות הרבה יותר כשה-agent עובד מתוך ידע הקשרי — התשובה נמצאת מולו, לא נשלפת מזיכרון מטושטש.

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

כשידע הקשרי וידע פרמטרי מתנגשים, הידע ההקשרי בדרך כלל מנצח. הדביקו את תיעוד ה-API הנוכחי וה-model פועל לפיו במקום לפי הזיכרון המיושן שלו על ה-API הישן — אף שהגרסה הישנה עדיין עלולה לחלחל, במיוחד עמוק בתוך session ארוך. אם ה-agent ממשיך לחזור לדפוס מיושן למרות שהתיעוד נטען, פירוש הדבר שהידע הפרמטרי דולף מעבר לידע ההקשרי; חזרה על התיקון או קירובו לעבודה עוזרים.

בניגוד לידע פרמטרי, שימוש בידע הקשרי עולה משהו. כל דבר שנטען לחלון צורך tokens ומתחרה על תקציב הקשב של ה-model, ולכן טעינה של עוד אינה בהכרח טובה יותר — המטרה היא העובדות הרלוונטיות בחלון, לא כל העובדות.

השתמשו במונח הזה רק כשמשווים אותו לידע פרמטרי; אחרת פשוט אמרו context.

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

שימוש:

«למה הוא מדייק ב-API כשאני מדביק את התיעוד, אבל ממציא אותו כשאינני עושה זאת?»

«כשהתיעוד בפנים, זה ידע הקשרי — הוא קורא מהדף. בלעדיו, הידע פרמטרי ונקודות הקצה הנדירות מיטשטשות.»

בעת חיזוי כל אסימון, המודל מביא בחשבון כל אסימון אחר בהקשר — חלקם במידה רבה, ואחרים בקושי. הקשר בין שני אסימונים הוא יחס קשב, וזוגות משמעותיים (״her״ עם ״Sarah״, או קריאה ל-`getUser()` עם ההגדרה `function getUser`) משפיעים זה על זה יותר מאשר אסימונים שאינם קשורים. בהקשר של N אסימונים יש בערך N² יחסים.

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

כדאי להתעכב על הנתון N², משום שהוא גדל מהר יותר מכפי שהאינטואיציה מצפה:

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

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

שימוש:

״הוא כל הזמן מבלבל בין שני סמלי `user` בהבדלים — נשמע שאנחנו באזור הטיפשות.״

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

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

חשבו על כך במונחי אות ורעש. ההנחיה שלכם היא אות בעוצמה קבועה; כל token אחר ב-חלון ה-context הוא צליל מתחרה. ההנחיה לעולם אינה נחלשת — היא עדיין שם, תו אחר תו — אבל ככל שה-context גדל, החדר סביבה נעשה רועש יותר ויחס האות לרעש יורד. הנחיה שהייתה הדבר החזק ביותר ב-10k tokens של context הופכת לזמזום רקע ב-150k. זהו המנגנון שמאחורי התדרדרות קשב: ה-model אינו שוכח; האות הולך לאיבוד בתוך הרעש.

התסמין נראה כאי־ציות — ה-agent הסכים למגבלה בתחילת הדרך ואחר כך סוטה ממנה, והדבקה מחדש של המגבלה מועילה רק לזמן קצר. הסיבה אינה ההנחיה; היא כל שאר הדברים בחלון שמתחרים איתה.

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

שימוש:

«למה הוא ממשיך להתעלם מהסכמה שהדבקתי בראש המסמך?»

«אנחנו עמוק בתוך אזור הטיפשות — תקציב הקשב של כל token קבוע, אבל ה-context המשיך לגדול. האות של הסכמה מתחרה עכשיו באלפי tokens חדשים יותר.»

ככל ש-session גדל, תקציב הקשב של כל token מתחלק בין יותר מתחרים. האות של כל קשר משמעותי נחלש; רעש מ-context לא רלוונטי מצטבר. אותו model, אותם פרמטרים — פשוט יותר פיות להאכיל מאותה צלחת. זו הסיבה לאפקט אזור היעילות/אזור הטיפשות של אזור.

הדבר נראה כאילו ה-model נעשה גרוע באמצע ה-session: מגבלות ששמר עליהן במשך שעה מתחילות להתפספס, הוא שואל שוב דברים שכבר נאמרו לו וכותב קוד שמתעלם מקובץ שקרא קודם. שום דבר ב-model לא השתנה — המשתנה היחיד הוא כמות ה-context שהוא קשוב לה כעת.

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

מתאוששים באמצעות הסרת context, לא הוספת עוד. הדבקה מחדש של ההנחיה שהוזנחה מוסיפה מתחרה נוסף לאותו חלון צפוף ומועילה רק לזמן קצר. מה כן עובד: לבצע ניקוי ולטעון רק את מה שהמשימה צריכה, או לבצע compact, או להעביר ל-session חדש. התייחסו לירידה בציות להנחיות כסימן לאורך ה-context, לא לבעיה ב-model.

שימוש:

«הוא עמוק באזור הטיפשות — ממציא generics שלא קיימים בקובץ הטיפוסים.»

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

בתחילת session, ה-agent נמצא ב«אזור חכם» — חד, ממוקד וזוכר היטב. ככל שה-session מתארך, הוא נסחף ל«אזור טיפשי»: מרושל יותר, שוכח יותר, טועה יותר — וגם מייצר יותר הזיות נאמנות. אותו model, אותו harness — פשוט יותר context. זו התחושה של התדרדרות קשב. במודלים המתקדמים, אזור הטיפשות מתחיל לעיתים קרובות סביב 125K–150K tokens, אם כי על כך יש ויכוח. בצעו ניקוי או compaction כשה-session מתנפח; אל תנסו לדחוף הלאה.

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

האזורים אינם קשורים למגבלת חלון ה-context. Session יכול להיות עמוק באזור הטיפשות כשרוב החלון עדיין פנוי: המגבלה היא הנקודה שבה ה-harness מסרב להמשיך, אך האיכות יורדת הרבה קודם. תכננו סביב האזור החכם, לא סביב החלון — התקציב המעשי למשימה הוא כמות ה-tokens שבתוכה ה-agent עובד היטב, לא כמות ה-tokens שהוא יכול להחזיק טכנית.

האזור החכם הוא תקציב, ועבודה שאינה קשורה למשימה צורכת ממנו. כל משימה ב-session משתמשת ב-tokens, ולכן התחלת משימה שנייה באותו session מתחילה קרוב יותר לאזור הטיפשות. משימה אחת בכל session מעניקה לכל משימה את החלק החד ביותר של ה-session. אם משימה אחת גדולה מאזור חכם אחד, חלקו אותה: בצעו העברת עבודה או compaction בגבול טבעי, ותנו ל-session חדש לבצע את החלק הבא.

שימוש:

«הוא הצליח בשלושת הרכיבים הראשונים ופשוט הרס את הרביעי.»

«יצאת מאזור היעילות — אותו model, פשוט עמוק עכשיו באזור הטיפשות. בצע compaction וטען מחדש את התוכנית; הרכיב הבא יצליח.»

סיום ה-session הנוכחי והתחלת חדש. ההודעה הבאה מתחילה session ריק עם חלון context ריק. בדרך כלל המשתמש יוזם זאת.

ניקוי הוא התרופה ל-context מזוהם. Session צובר הכול: ניסיונות שנכשלו, פניות שגויות, תוצאות כלים מיושנות ותוכניות שנזנחו. ה-model קורא את הכול מחדש בכל תור, והיסטוריה גרועה מכבידה על עבודה חדשה. עמוק בתוך session ארוך, ה-agent נעשה מעורפל ופחות צייתן — מתעלמים מהוראות שנתתם בבירור, האיכות יורדת ועידוד לעשות טוב יותר אינו עוזר, כי הרעש שבו הוא מתבוסס עדיין נמצא ב-context שלו. ניקוי מסיר את הרעש.

ניקוי אינו מוחק את השיחה. רוב ה-harnesses שומרים את היסטוריית session במחשב שלכם, ולכן עדיין אפשר לקרוא את התמליל או להמשיך ממנו. מה שנעלם הוא מצב העבודה של ה-agent: ה-model חסר מצב, ולכן ה-session החדש אינו יודע דבר ממה שהישן ידע. אם ה-session מכיל החלטות או התקדמות שהבא יצטרך, בקשו מה-agent לכתוב תחילה מסמך העברת עבודה, ואז התחילו את ה-session החדש בהפניה אליו.

השוו ל-compaction, שמסכם את ה-session לתוך ה-context החדש במקום להתחיל ריק. ניקוי הוא הכלי הגס יותר: דבר אינו עובר הלאה, כולל הזבל.

שימוש:

«הוא תקוע בלולאה על הבדיקה שנכשלת.»

«פשוט נקו — התחילו session חדש עם מסמך התוכנית וקובץ הבדיקה. אין טעם להילחם ב-context הקיים.»

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

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

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

שימוש:

״מפגש התכנון נעשה עמוס — כדאי פשוט להמשיך?״

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

מקור אמת בצורתו המקורית — הקוד, תמליל השיחה, יומן גולמי או תגובת API בפועל. לא תיאור של הדבר; הדבר עצמו. מקבילו הוא מקור משני.

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

העלות היא מה שמונע ממקורות ראשוניים להיות ברירת המחדל. טעינת אחד מהם ל-חלון ה-context יקרה — כל הקובץ, כל התמליל, כל token מחויב כ-קלט ומתחרה על תקציב קשב. מה שמקבלים בתמורה הוא שלמות: איש לא סינן מראש פרטים לפי שיקול דעתו לגבי מה חשוב. תקציר שנכתב בחודש שעבר אינו יכול להכיל פרט שהתברר כחשוב היום; המקור הראשוני עדיין מכיל אותו.

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

שימוש:

«ה-agent אומר שלוגיקת הניסיונות החוזרים נסוגה באופן מעריכי, אבל אני רואה אותה מפציצה את ה-endpoint.»

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

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

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

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

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

שימוש:

«מסמך ההעברה אומר שהאימות הושלם, אבל ה-session החדש ממשיך למצוא רענון token שבור.»

«המסמך הוא מקור משני — ה-session האחרון כתב את מה שהאמין בו, לא את מה שנכון. בקשו מה-session החדש להריץ את בדיקות האימות ולהסתמך על המקור הראשוני.»

מסמך שמשמש כאמצעי להעברת עבודה handoff — נכתב אל ה-סביבה בידי session אחד כדי ש-session אחר יקרא אותו. מפרטים, כרטיסים ומסמכי תוכנית הם כולם מסמכי העברת עבודה.

הסיבה לכתיבתו: ה-model הוא חסר מצב, ולכן שום דבר ב-session אינו שורד את ניקויו. החלטות, מגבלות ותוכניות לא גמורות — הכול נעלם יחד עם ה-context שהכיל אותן. הסביבה נשארת. כתיבת המצב החשוב לקובץ מעבירה אותו למקום שממנו ה-session הבא יכול לקרוא אותו.

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

מסמך טוב נכתב עבור session שנכנס ללא כל context. נתיבי קבצים מדויקים במקום «הקובץ שדיברנו עליו». מה הוחלט ולמה, כדי שה-session הבא לא יפתח את ההחלטה מחדש. מה הושלם ומה נותר. כדאי לומר ל-session הכותב לאן המסמך מיועד: «כתבו מסמך העברת עבודה ל-session חדש שאינו יודע דבר על העבודה הזאת».

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

שימוש:

«איך לחלק זאת בין ה-agent שמתכנן לבין זה שמיישם?»

«בקשו מהמתכנן לכתוב מסמך העברת עבודה — נתיבי קבצים, החלטות ומגבלות. ה-session של המיישם מתחיל עם מצביע למסמך ועובד לפיו.»

מסמך העברת עבודה שמתאר עבודה הנמשכת על פני כמה sessions — מה בונים, ולא כיצד כל session מבצע את חלקו. המסמך משתנה ככל שהעבודה מתקדמת. הוא מורכב מ-כרטיסים.

המפרט קיים משום ש-sessions הם בני חלוף, בעוד שעבודה גדולה אינה כזו. כל דבר שדורש יותר מחלון context אחד צריך מקום מחוץ ל-context — מקום ב-סביבה של ה-agent ששורד ניקוי, בין אם זה קובץ במאגר, issue ב-GitHub או מערכת מעקב משימות שה-agent יכול לגשת אליה. המפרט הוא המקום הזה: המטרה, המגבלות, ההחלטות שהתקבלו עד כה ורשימת הכרטיסים עם מצבם. כל session חדש יכול לקרוא אותו ולהבין היכן הדברים עומדים בלי לרשת את הרעש שהצטבר ב-session הקודם.

למפרטים יש סגנונות מוכרים, שרובם שאולים מהאופן שבו צוותים כבר מתעדים דברים. מסמך דרישות מוצר (PRD) מתמקד במה ולמה מנקודת מבט המשתמש — תכונות, התנהגות וקריטריוני קבלה. מסמך תכנון או RFC מתמקד בהיבטים הטכניים — הגישה שנבחרה, החלופות שנדחו והפשרות. בקצה הקטן, קובץ `plan.md` פשוט עם רשימת כרטיסים מסודרת מספק אותה תועלת לתכונה הנפרשת על פני כמה sessions. הסגנון חשוב פחות מהתפקיד: עבור agent, כל אלה הם אותו הדבר — הצהרת כוונות עמידה שהוא קורא בתחילת כל session.

שימוש:

«האם כל זה צריך להיות session אחד?»

«לא, כתבו מפרט — חלקו אותו לכרטיסים, והריצו כל אחד ב-session נפרד. ניסיון לעשות הכול ב-context אחד יגיע ל-אזור הטיפשות עוד לפני שתהיו באמצע.»

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

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

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

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

שימוש:

"מאיפה להתחיל במפרט ההעברה?"

"בדקו את גרף הכרטיסים — שינוי הסכמה חוסם את מילוי הנתונים, שממנו חסומה החלפת ה-API. בחרו עלה והפעילו עליו session."

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

המנגנון: חלון ה-context סופי, ו-session ארוך ממלא אותו — כל תוצאת כלי, כל קובץ שנקרא וכל פנייה שגויה נשארים בהיסטוריה. כשהוא מתמלא, ה-harness מבקש מה-model לתמצת את ה-session, משליך את ההיסטוריה המקורית ופותח session חדש שמתחיל מהתקציר. כל מה שלא נכנס לתקציר נעלם מה-context. יש harnesses שמרככים זאת בכך שהם שומרים את התמליל הישן בדיסק ומשאירים בתקציר מצביע context אליו — המקור המשני מקשר למקור הראשוני, ולכן אפשר לשחזר פרט שהתקציר השמיט באמצעות קריאה מחדש של המקור.

ה-model כותב את התקציר, ולכן אפשר להנחות אותו. «שמרו על החלטות הסכמה» הופך את התוצר שנוצר למכוון יותר. גם העיתוי חשוב — בצעו compaction בגבול של שלב, לאחר שהתוכנית התייצבה, ולא באמצע משימה.

השוו ל-clearing, שמפיל הכול ומתחיל מאפס: compaction מנסה להעביר את העיקר; clearing מניח שהוא כבר נכתב במקום טוב יותר.

שימוש:

«ה-context מתמלא ואני עדיין צריך להעביר את הבדיקות.»

«בצעו compaction לפני שמתחילים — כתבו בהנחיית התקציר מה חייב לשרוד, כדי שה-session החדש ישמור על החלטות הסכמה וישליך את החקירה.»

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

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

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

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

שימוש:

״נראה שהוא לא זוכר מה החלטנו קודם לגבי הסכימה.״

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

מערכת שמנסה להפוך agent ל-בעל מצב בין sessions. היא שומרת מידע ב-סביבה במהלך session וטוענת אותו מחדש אל חלון ה-context בתחילת sessions עתידיים, כך שה-agent שומר על רציפות גם לאחר שהמשתמש מבצע ניקוי ל-session.

למערכת זיכרון יש שני חצאים. נתיב הכתיבה: במהלך session, ה-agent מתעד את מה שלמד — העדפה שציינתם, עובדה על הפרויקט — בקבצים בסביבה. נתיב הקריאה: בתחילת session, ה-harness טוען את הקבצים האלה, או אינדקס שלהם, בחזרה לחלון ה-context. Harnesses רבים מגיעים עם מערכת זיכרון משלהם — `/memory` של Claude Code היא דוגמה אחת — אך אפשר גם לבנות מערכת כזאת לבד: תיקיית הערות והנחיה ב-AGENTS.md לעיין בה.

אותן פשרות כמו בכל תוכן שנטען תמיד חלות גם כאן. זיכרונות מצטברים, ולכן רוב המערכות טוענות אינדקס בן שורה אחת ומשאירות את התוכן מאחורי מצביעי context, במקום להטמיע הכול. זיכרונות הם גם מקורות משניים, ולכן הם מתיישנים: עובדה שתועדה במרץ נטענת באותה רמת ביטחון ביוני, אחרי שהפרויקט כבר התקדם. מערכת זיכרון דורשת ניקוי תקופתי, כמו AGENTS.md.

שימוש:

«אני צריך להזכיר לו שוב ושוב שאנחנו ב-Postgres, לא ב-MySQL.»

«חברו מערכת זיכרון — כתבו את מה שהיא לומדת ל-מערכת הקבצים בתור הראשון של session, וטענו זאת מחדש בתחילת session. ה-model עצמו חסר מצב; שכבת הזיכרון מדמה רציפות.»

קובץ ב-סביבה שה-harness טוען לתוך חלון ה-context בתחילת session — התדריך הקבוע של הפרויקט ל-agent. זו מוסכמה החוצה harnesses; לחלקם יש גם גרסה משלהם (זו של Claude Code נקראת CLAUDE.md).

מכיוון שהקובץ נטען אוטומטית, הוא דרך להימנע מחזרה על עצמכם בין sessions. ה-model הוא חסר מצב — תיקון שנתתם ב-session אחד נעלם באחר, ואתם מוצאים את עצמכם מספרים לכל session חדש שהפרויקט משתמש ב-pnpm, שהבדיקות רצות עם דגל מסוים ושספרייה מסוימת נוצרת ואין לגעת בה. אם תיקנתם את ה-agent על אותו עניין פעמיים, התיקון מועמד להיכלל ב-AGENTS.md.

תוכן מתאים הוא כל מה שה-agent אינו יכול להסיק מהקוד: פקודות build ובדיקות, מוסכמות שאינן מובנות מאליהן בקוד, ומגבלות קשיחות («לעולם אל תערכו את הלקוח שנוצר»). קצר והצהרתי — זהו תדריך, לא תיעוד.

הפשרה היא שכל מה שבקובץ נטען תמיד. ההנחיות מצטברות ורובן אינן רלוונטיות למשימה מסוימת, ו-AGENTS.md ארוך גם צורך tokens וגם מדלל את עצמו — ככל שיש יותר הנחיות ב-context, כך ה-model פועל לפי כל אחת מהן פחות בעקביות.

הימנעו מ: שימוש ב-AGENTS.md לתוכן שצריך לחשוף בהדרגה — כל דבר שמופיע בו עולה token בכל תור, בכל session, גם אם אין בו צורך. אפשר לשים מדריך סגנון מאחורי skill או מצביע context; שמרו את AGENTS.md לכללים שחלים בכל מקום.

שימוש:

«למה כל session מתחיל כשכבר נשרפו 4k tokens?»

«בדקו את AGENTS.md — מישהו הדביק שם את כל מדריך הסגנון במקום לשים אותו מאחורי skill.»

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

השיטה קיימת משום של-context יש עלות כפולה. כל token שנטען מראש מחויב כ-טוקן קלט בכל תור, וכל token צורך תקציב קשב גם כשה-agent אינו זקוק לו. קובץ AGENTS.md שדחסו לתוכו את מדריך הסגנון המלא, מדריך הפריסה ומוסכמות מסד הנתונים מחליש את יכולת ה-agent לעמוד בכולם — ההנחיות החשובות למשימה הנוכחית נמהלות בהנחיות שאינן רלוונטיות. הסימן לכך הוא agent שמתעלם מכללים שאתם יודעים שנמצאים ב-context שלו: הם שם, אבל קבורים.

חשיפה הדרגתית הופכת זאת. השאירו את השכבה שנטענת תמיד קטנה — משפט אחד לכל נושא ומצביע למקום שבו נמצאים הפרטים. ה-agent קורא את מדריך הסגנון כשהוא כותב רכיב, את מדריך הפריסה בזמן פריסה ואף אחד מהם כשהוא מתקן בדיקה. Skills הם הדפוס המובנה ב-harness: תיאור קצר שנטען בכל session, ואת ההוראות המלאות טוענים רק כשהן מופעלות.

שימוש:

«להדביק את כל מדריך הסגנון ב-AGENTS.md?»

«לא — חשיפה הדרגתית. הפנו למדריך הסגנון כ-skill שה-agent טוען כשהוא באמת צריך לכתוב רכיב. AGENTS.md גובה את עלות ה-token בכל תור.»

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

הסיבה להשתמש במצביע במקום להטמיע את התוכן היא העלות. מצביע תופס שורה אחת בחלון ה-context. המסמך שמאחוריו עשוי להכיל אלפי tokens, אבל הם אינם עולים דבר עד שה-agent עוקב בפועל אחר המצביע. אם מטמיעים מדריך פריסה בן 2,000 tokens ב-AGENTS.md, כל session משלם על כך; אם מחליפים אותו ב-«תהליך פריסה: ראו `internal/deploy.md`», רק sessions שמבצעים פריסה יטענו אותו. כשהמשימה מתאימה, ה-agent עוקב אחר המצביע באמצעות קריאת כלי.

כדי שמצביע יפעל דרושים שני דברים: נתיב יציב ותיאור מספיק כדי שה-agent יידע מתי כדאי לעקוב אחריו. נתיב עירום הוא מצביע שאין ל-agent סיבה לעקוב אחריו; «ראו `internal/deploy.md`» ללא רמז לתוכן עלול להישמט מ-session שזקוק לו. כתבו את השורה באופן שמתאים לאופן שבו משימות מנוסחות: «שחרור, פריסה או החזרה לאחור — קראו קודם את `internal/deploy.md`».

מצביעים נמצאים בכל מקום כשמחפשים: שורות ב-AGENTS.md, תיאורי skills (ה-harness טוען את התיאור וגוף ה-skill ממתין מאחוריו), שמות קבצים ברשימת ספרייה וקישורים בין מסמכים.

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

הימנעו מ: «reference» — יבש מדי; אינו מעביר את התחושה שהמעקב אחריו מכניס עוד context. «Portal» — מליצי מדי.

שימוש:

«AGENTS.md נעשה עצום.»

«רובו צריך להיות מצביעי context, לא תוכן. השאירו את הכללים שפועלים תמיד בתוך הקובץ; הפכו את מדריך הפריסה ואת מדריך הסגנון ל-skills והשאירו מאחוריהם מצביע context.»

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

Skills הם תקן פתוח המוגדר ב-agentskills.io — פותח במקור בידי Anthropic ומאז אומץ בידי רוב ה-harnesses הגדולים, כך ש-skill שנכתב פעם אחת עובד בכולם. הפורמט הוא תיקייה שמכילה:

• קובץ `SKILL.md` — מטא־נתונים (שם ותיאור לפחות) וגם את ההוראות עצמן
• לפי הצורך, סקריפטים שה-agent יכול להריץ
• לפי הצורך, תבניות וחומר עזר שאליו מפנות ההוראות

כברירת מחדל, רק השם והתיאור נמצאים ב-context. כשהמשימה של ה-agent מתאימה, הוא טוען את היתר. עד אז ה-skill תופס כמעט אפס מקום — משפט או שניים של tokens, בלי קשר לאורך ההוראות המלאות.

כך skills נבדלים מ-AGENTS.md, שנטען לכל session בלי קשר למשימה. קוראים skill כשעולה סוג עבודה מסוים — שחרור, יצירת שירות חדש או כתיבת migration — ומתעלמים ממנו בשאר הזמן.

הימנעו מ: «כלי» — agent מפעיל כלי; skill הוא הוראות שהוא קורא.

שימוש:

«איפה לשים את מדריך הפריסה?»

«כ-skill — ה-agent טוען אותו רק כשהמשימה קשורה לפריסה. אם יופיע ב-AGENTS.md, הוא יצרוך tokens בכל תור עבור משהו שמשתמשים בו פעם בשבוע.»

Agent שמופעל בידי agent אחר באמצעות קריאת כלי. הוא פועל ב-session משלו עם חלון context משלו ומחזיר תוצאת כלי יחידה. הוא שונה מ-handoff — ההורה מצפה במפורש לתשובה; ל-handoff אין מסלול חזרה. הוא אינו יכול להפעיל subagents נוספים — לעץ יש רמה אחת בלבד. Subagents נועדו לבודד context, לא לבנות היררכיות.

המטרה היא להרחיק עבודה רועשת מה-context של ההורה. חיפוש רחב או מסע ארוך בקריאת קבצים מייצרים עמודים של תוצאות כלים, שרובן חשובות רק עד שנמצאת התשובה. אם מריצים זאת בתוך ההורה, הכול נשאר ב-context שלו למשך שאר ה-session. אם מריצים בתוך subagent, הרעש ממלא חלון זמני במקום זאת — רק הדוח הסופי נכנס ל-context של ההורה. הדוח הוא מקור משני: ההורה מקבל את תיאורו של ה-subagent לגבי מה שמצא, לא את התוצאות הגולמיות, ולכן כל מה שהדוח משמיט נעלם מעיני ההורה.

Subagents פועלים גם במקביל — הורה יכול להפעיל כמה מהם בבת אחת על חלקים עצמאיים.

שימוש:

«תוצאות grep מפוצצות לי את ה-context.»

«הפעילו subagent לחיפוש — הוא יבזבז את חלון ה-context שלו על הרעש ויחזיר את שני נתיבי הקבצים שאתם באמת צריכים.»

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

הניגוד הוא לעבודה AFK, שבה ה-agent פועל ללא השגחה ואתם שופטים את התוצאה לאחר מכן. Human-in-the-loop פירושו לתפוס בעיות כשהתיקון שלהן עדיין זול: רואים את ה-agent פונה לקובץ הלא נכון, מפרש דרישה באופן שגוי או מתחיל בכיוון ללא מוצא, ומכוונים אותו במשפט אחד — במקום לגלות אחרי עשרים דקות של עבודה בטוחה בעצמה שנשענה על הטעות. Agents אינם יודעים באופן אמין מתי הם סוטים מהמסלול; כשמשאירים אותם לבד, הם נוטים להמשיך קדימה במקום לעצור ולשאול.

הדפוס המתאים תלוי בעבודה. משימות שמוגדרות היטב, בעלות סיכון נמוך וקלות לאימות מתאימות ל-AFK. משימות עמומות, בלתי הפיכות או כאלה שיהיה קשה לכם לסקור בסיום — migration של סכמה, החלטת תכנון מסובכת או כל דבר שנוגע לייצור — מתאימות להישאר בלולאה. ההכרעה היא בעצם: כמה יקרה תהיה טעות בכיוון, וכמה מאוחר תתפסו אותה?

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

להישאר בלולאה צורך את תשומת הלב שלכם, שהיא המשאב הנדיר. חלק מההתקדמות בעבודה עם agents הוא להוציא בבטחה עוד עבודה מהלולאה — בעזרת תוכניות, בדיקות אוטומטיות ו-סקירה אנושית בסוף במקום השגחה לאורך כל הדרך. מפעל תוכנה לוקח זאת צעד נוסף ומתחיל sessions בעקבות טריגרים, כך שאפילו התחלת העבודה אינה דורשת אתכם.

שימוש:

«להריץ את זה AFK במהלך הלילה?»

«לא, זה migration של סכמה — להשאיר אדם בלולאה. אני רוצה לראות כל שלב ולכוון אם הוא בוחר בעמודה הלא נכונה למילוי הנתונים.»

הרחק מהמקלדת. דפוס עבודה שבו המשתמש מתחיל session ומשאיר את ה-agent לפעול ללא השגחה. זהו מכפיל התפוקה של כתיבת קוד בעזרת AI — sessions רבים במצב AFK יכולים לפעול במקביל בזמן שאתם ישנים, אוכלים או עובדים על משהו אחר. כדי לעשות זאת בבטחה נדרשים בדרך כלל מצב הרשאות מתירני ו-בידוד sandbox.

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

מכיוון שאינכם יכולים להזין מידע במהלך ההרצה, ספקו אותו לפני ואחריה. לפני: פתרו מראש את העמימות — באמצעות session של Grilling או מפרט כתוב — כדי להשאיר פחות פערים שה-agent יצטרך למלא לבד. במהלך ההרצה: בדיקות אוטומטיות ו-סקירה אוטומטית מחליפות את תשומת הלב שאינכם נותנים, ונכשלות במהירות על דברים שאפשר לתפוס באופן מכני. לאחר ההרצה: התוצר צריך להיות ניתן לסקירה — PR, לא שינויים שכבר מוזגו. AFK אינו מבטל סקירה אנושית; הוא דוחה את כולה לסוף, ולכן מה שמגיע בסוף חייב להיות ראוי לסקירה. גם משום כך AX חשוב במיוחד בהרצות AFK — כשאיש אינו צופה, הסביבה היא התמיכה היחידה של ה-agent.

הימנעו מ: «agent ברקע» — הניסוח מתמקד במכונה («פועל ברקע») במקום בדפוס האנושי («המשתמש התרחק»). AFK מציין את העובדה החשובה: המשתמש אינו צופה.

שימוש:

«אני מריץ זאת AFK — שלושה agents מבודדים עובדים על השכתוב, ואני סוקר את ה-PRs בבוקר.»

«עקיפת הרשאות?»

«כן, מערכת קבצים לקריאה בלבד, בלי רשת.»

אימות דטרמיניסטי שפועל ב-סביבה — בדיקות, בדיקות טיפוסים, lints, build ו-hooks שלפני commit. עובר/נכשל, ללא שיקול דעת. זהו אות ש-agent יכול לתקן את עצמו על פיו בלי לערב אף אחד אחר. בדיקה לא יציבה היא בדיקה שבורה, לא בדיקה שאינה בדיקה; מעצם התכנון, בדיקות אוטומטיות הן דטרמיניסטיות.

תיקון עצמי פועל כלולאה. ה-agent מבצע שינוי, מריץ את הבדיקה כ-קריאת כלי, ופלט הכישלון נכנס ל-חלון ה-context שלו — שגיאת טיפוס עם קובץ ושורה, או טענה שנכשלה עם הערכים הצפוי והמתקבל. זה מספיק ל-agent כדי לתקן את הבעיה ולהריץ שוב את הבדיקה, שוב ושוב עד שהיא עוברת, בלי אדם בלולאה. הדטרמיניזם הוא שמאפשר לסמוך על הלולאה: אותו קוד תמיד מניב אותה הכרעה, ולכן למעבר יש משמעות. בדיקה לא יציבה מרעילה את התהליך — ה-agent «מתקן» קוד שהיה תקין או מנסה שוב עד שהוא עוקף כישלון אמיתי.

לכן בדיקות טובות הן חלק גדול מ-AX של בסיס קוד. Agent במאגר עם טיפוסים מחמירים, חבילת בדיקות מהירה ו-linter תופס את רוב הטעויות של עצמו לפני שתראו אותן; agent במאגר שאין בו כל אלה משחרר כל מה שהוא מפיק. ההבדל חשוב במיוחד בהרצות AFK, שבהן הבדיקות הן האימות היחיד שמתרחש במהלך ההרצה. אבל בדיקה תופסת רק את מה שהיא טוענת — בדיקות ירוקות פירושן שהתכונות שנטענו מתקיימות, לא שהקוד נכון. הפערים שדורשים שיקול דעת הם הסיבה ל-סקירה אוטומטית ול-סקירה אנושית.

הימנעו מ: «feedback loop» / «backpressure» — שניהם מערבבים בדיקות עם סקירה. הימנעו מ: «test» — בדיקות הן בדיקות אוטומטיות, אך לא כל בדיקה אוטומטית היא test.

שימוש:

«ה-agent ממשיך לשחרר קוד שבור בהרצות AFK.»

«אילו בדיקות אוטומטיות מחוברות ל-sandbox?»

«רק בדיקות יחידה.»

«הוסיפו בדיקת טיפוסים ו-lint — הוא יתקן את עצמו על פיהן לפני שה-PR בכלל יגיע.»

Agent שסוקר עבודה של agent אחר, לעיתים עם model או הנחיית מערכת אחרים. הוא אינו דטרמיניסטי: הוא מגבש שיקול דעת. אפשר להפעיל אותו בכל מקום — לפני מיזוג PR, בדיעבד על היסטוריית commits או באמצע session כ-subagent. LLM כשופט ב-CI הוא סקירה אוטומטית, לא בדיקה אוטומטית; הקטגוריה נקבעת לפי מה שהטענה בודקת, לא לפי המקום שבו היא רצה.

ההפרדה מה-agent העובד היא שמאפשרת זאת. בקשה מה-agent שכתב את הקוד לסקור את עבודתו שלו מניבה מעט מאוד — ה-session שיצר את הבאג מכיל גם את הנימוקים שהובילו אליו, וה-agent קורא שוב את מסקנותיו שלו כאישור. לסוקר עם חלון context חדש אין את ההיקשרות הזאת: הוא רואה את ה-diff כפי שאדם זר היה רואה אותו, וזה מה שסקירה דורשת. Model אחר או הנחיית מערכת ייעודית לסקירה מחדדים זאת עוד יותר — נקודות עיוורון שונות והנחיית מערכת שממוקדת במה שבאמת חשוב לכם (אבטחה, חוזי API, ביצועים) במקום ב«חפשו בעיות» המעורפל.

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

הימנעו מ: «סקירת AI» / «סקירת agent» — מעורפלים מכדי להבחין בין הסוקר לבין ה-agent העובד עצמו.

שימוש:

«אנחנו מקבלים יותר מדי PRs גרועים מהרצות AFK.»

«הוסיפו שלב סקירה אוטומטית לפני המיזוג — model אחר, הנחיית מערכת נפרדת, ממוקדת באבטחה ובשינויים לחוזים.»

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

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

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

הימנע: מ״סקירת קוד״ בלבד — הביטוי עמום בין סקירה אנושית לאוטומטית.

שימוש:

״עברתי על הפלט של הרצת AFK בעצמי.״

״קראת את ההבדלים או רק את הסיכום?״

״את ההבדלים. הסיכום אמר שהוא מחק קוד מת, והתברר שהפונקציה נקראה מקובץ שנוצר אוטומטית.״

דפוס עבודה שבו המשתמש מקבל את הקוד של ה-agent בלי סקירה אנושית. מתייחסים ל-diff כאל קופסה אטומה — חשוב אם התוכנית מתנהגת כראוי, לא מה יש בתוכה. ייתכן שעדיין ירוצו סקירה אוטומטית ו-בדיקות אוטומטיות; vibe coding אינו נוקט עמדה לגבי אף אחת מהן.

המונח מגיע מאנדריי קרפתי, שטבע אותו בתחילת 2025: אתם «נכנעים לגמרי לווייב» ו«שוכחים שהקוד בכלל קיים» — מתארים מה אתם רוצים, מקבלים את מה שחוזר ושופטים לפי הרצה.

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

המחיר מגיע מאוחר יותר. שינויים שנוצרו ב-vibe coding מצטברים לבסיס קוד שאיש לא קרא, וההתנהגות הייתה הדבר היחיד שנבדק — לכן כל דבר שאינו מתבטא בהתנהגות, כמו סוד שנכתב ליומנים, מקרה קצה חסר או טיפול נתונים שגוי אך שקט, נשלח בלי שאיש יבחין. הפעם הראשונה שמישהו מנפה באגים במערכת היא הפעם הראשונה שמישהו קורא את הקוד. לאחר שהוסרה הסקירה האנושית, כל אימות אוטומטי שנותר — בדיקות, טיפוסים וסקירה אוטומטית — הוא השער היחיד שהקוד עובר. אותה גישה, כשהיא חלה על בסיס קוד שלם או על חלק ממנו והשינויים מגיעים מ-מפעל תוכנה, היא dark factory.

הימנעו מ: שימוש ב-«vibe coding» כמילה נרדפת ל«כתיבת AI באיכות נמוכה» — המונח מציין את גישת הסקירה, לא את איכות הקוד שנוצר.

שימוש:

«קראת מה הוא שינה בזרימת האימות?»

«עשיתי vibe coding — הכניסה עדיין עובדת, זה כל מה שבדקתי.»

«קרא את ה-diff לפני הדחיפה; התלהבות בלי בדיקה בזרימת אימות היא הדרך שבה סודות דולפים ליומנים.»

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

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

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

שימוש:

״הוא כותב בדיוק את מה שביקשתי וזה עדיין שגוי.״

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

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

השיטה קיימת משום ש-agents ממלאים פערים בשקט. כשמבקשים מהם לכתוב מפרט מתוך prompt בן שתי שורות, הם אינם עוצרים בהחלטות שלא קיבלתם — הם בוחרים ברירות מחדל וכותבים אותן פנימה. התוצאה נראית שלמה, ואי אפשר להבדיל בין הניחושים לבין הבחירות, ולכן מגלים אותם מאוחר: בסקירה או כשהתכונה שנבנתה מטפלת במקרה קצה באופן שלא בחרתם. Grilling הופך את הכיוון — במקום לנחש, ה-agent חייב לשאול.

זו שיטת human-in-the-loop: התשובות שלכם הן הקלט. כשאי אפשר לענות על שאלה בשיחה — צריך לראות את הדבר — עוברים ל-יצירת אבטיפוס.

שימוש:

«הוא עבר מיד לכתיבת המפרט וטעה בלוגיקת הביטול.»

«תחקרו אותו קודם — בקשו שישאל על ביטולים חלקיים, החזרים ותזמון לפני שהוא מתחייב למשהו במסמך. זול יותר לפתור זאת בשיחה מאשר בקוד.»

ה-agent בונה גרסה מהירה וגסה של דבר כלשהו, כששיחה אינה מדויקת מספיק ונדרש תוצר ממשי שאפשר לדון בו.

Grilling פותר החלטות תכנון בשיחה. שיחה זולה, אך רמת הדיוק שלה נמוכה: על חלק מהשאלות אי אפשר לענות במילים — איך מרגישה אינטראקציה, האם צורת API נוחה לשימוש בקוד אמיתי או האם הפריסה עובדת בגדלי נתונים אמיתיים. הראיון מגיע לשאלה והתשובה הכנה שלכם היא «אינני יודע, צריך לראות את זה». מכאן הדיון מסתובב במעגלים. במקום זאת, בקשו מה-agent לבנות את הדבר, בחנו אותו וחזרו לשיחה עם תשובה.

Agents מוזילים את הבנייה, וזה מה שהופך את הגישה למעשית. גרסה גסה שבעבר דרשה יום להכנה כ-mockup נבנית כעת בתוך דקות, ולכן כדאי לעשות זאת בקביעות. זו שיטת human-in-the-loop: האבטיפוס קיים כדי שתוכלו להגיב אליו.

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

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

שימוש:

«אנחנו מתווכחים כבר חצי שעה אם האשף צריך להיות עמוד אחד או שלושה שלבים.»

«מילים לא יכריעו את זה — בקשו מה-agent ליצור אבטיפוס של שתי האפשרויות. נעבור עליהן ונבין תוך חמש דקות.»

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

DX היא האינטראקציה בין האדם לבסיס הקוד — ולא יותר. ההבדל העיקרי בין שני הקהלים הוא שבני אדם הם בעלי מצב ו-agents הם חסרי מצב. אדם לומד את בסיס הקוד פעם אחת ונושא את הידע הזה לכל יום שאחר כך, ולכן אפשר לשרוד DX גרועה: עוקפים CI איטי באמצעות קיבוץ ה-pushes, תיעוד חסר באמצעות שאלה חד־פעמית ב-Slack ומבנה מבלבל באמצעות זכירת מיקומי הדברים. דרכי העקיפה מצטברות, והצוות נעשה פרודוקטיבי בבסיס קוד שנאבק בו.

Agents פוגשים את אותו בסיס קוד בלי שום הצטברות כזאת. Agent חסר מצב בין sessions, ולכן לומד מחדש את בסיס הקוד מאפס בכל פעם — הוא נהנה מחבילת בדיקות מהירה ומהודעות שגיאה ברורות, אך כל דבר שהבין אתמול נעלם אלא אם נכתב ב-סביבה, שה-agent תופס רק באמצעות תוצאות כלים. זהו הפער ש-AX מכנה בשם: החלקים של DX ששורדים כשהמפתח הוא agent, ובנוסף חששות שאין לבני אדם, כמו שמירת חלון ה-context פנוי.

החפיפה פירושה שהשקעה ב-DX משפרת לעיתים קרובות גם את AX ללא עלות נוספת — טיפוסים מחמירים, בדיקות מהירות ומבנה צפוי עוזרים לשניהם. ההבדל פירושו שלא תמיד: מסמך קליטה יפה עוזר לאדם במשך שבוע, אך אינו עוזר כלל ל-agent אלא אם אפשר להגיע אליו דרך AGENTS.md.

שימוש:

«ה-DX שלנו בסדר — עובדים חדשים נעשים פרודוקטיביים בתוך שבוע.»

«הם פרודוקטיביים כי מישהו יושב איתם במשך השבוע הזה. ל-agent אין את השבוע הזה; בדקו את ה-AX בנפרד.»

חוויית agent — מידת ההתאמה של הסביבה לעבודה איכותית של agent בבסיס קוד. זהו המקביל הממוקד ב-agent ל-DX. כשה-agent עצמו מצליח במאגר אחד ונכשל באחר — אותו model, אותו harness — ההבדל הוא בדרך כלל AX. האינסטינקט הוא להאשים את ה-model או לשכתב את ה-prompt; לרוב, הפתרון נמצא במאגר.

לחוויית AX טובה יש שלושה ממדים עיקריים:

AX ו-DX חופפים — בדיקות טובות וארכיטקטורה נקייה עוזרות לשני הקהלים — אך גם נפרדים. בני אדם מסתדרים עם ידע שבעל פה, CI איטי ו«שאלו את שרה על מודול החיוב»; agents אינם יכולים. Agents אינם מפיקים תועלת מהסברים קופצים ב-IDE או מלוחות מחוונים יפים; הם זקוקים לכשלים כטקסט ב-תוצאת כלי. לבסיס קוד יכולה להיות DX טובה ו-AX גרועה.

הימנעו מ: התייחסות ל-AX כמילה נרדפת ל-DX — הקהלים זקוקים להשקעות שונות.

שימוש:

«ה-agent כותב קוד מצוין במאגר ה-API וזבל ב-frontend.»

«במאגר ה-API יש טיפוסים מחמירים וחבילת בדיקות מהירה; ב-frontend אין לא את זה ולא את זה, ויש ארבעים skills שנטענים תמיד. זה פער AX, לא בעיית model.»

מערכת עבודה שבה sessions של agents מתחילים בעקבות טריגרים — פתיחת issue, לוח זמנים, כשל CI או סיום session אחר — ולא ביוזמת אדם, כך שיותר עבודה מתבצעת AFK ותשומת הלב האנושית מוקדשת להחלטות human-in-the-loop שנותרו.

בלי מפעל, כל session מתחיל כי מישהו התחיל אותו. אפילו עבודה שמתבצעת כולה AFK ממתינה לאדם שיפתח את ה-session, יצביע על כרטיס ויתניע אותו. צוותים רוצים לשחרר יותר ממה שזה מאפשר. מפעל מסיר את האדם משלב התחלת ה-sessions, ולא בהכרח מכל דבר אחר.

טריגרים נפוצים וה-sessions שהם מתחילים:

מפעל אינו חייב לכסות את כל תהליך התוכנה. משימת cron אחת שמריצה סוג session אחד ופותחת PR יחיד שאפשר לסקור היא מפעל. כדאי להתחיל כך: לולאה צרה מפיקה PRs קטנים ודומים, והסקירה שלהם מראה עד כמה אפשר לסמוך על הלולאה לפני שמרחיבים אותה.

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

שימוש:

«מי תיקן את כל ההפרות של `no-floating-promises`?»

«המפעל. משימת cron בוחרת כלל lint אחד בלילה ופותחת PR. אני רק סוקר אותו בבוקר.»

בסיס קוד, או חלק ממנו, שבו מפעל תוכנה כותב את הקוד ואף אדם אינו קורא אותו. אין סקירה אנושית. בני אדם עדיין יכולים לכתוב את ה-issues שמתחילים את העבודה, אבל איש אינו קורא את הקוד שנוצר. השם מגיע ממפעלי «lights-out» שמייצרים מוצרים ללא אנשים ברצפת הייצור.

Dark factory היא vibe coding של אזור קוד, לא של שינוי יחיד. כשעושים vibe coding, בוחרים לא לקרוא שינוי שביקשתם. אבל ידוע לכם שהשינוי קיים. ב-dark factory, הצוות מקבל את ההחלטה הזאת פעם אחת עבור האזור כולו. מכאן ואילך איש אינו מבקש כל שינוי בנפרד או רואה אותו. שינויים מגיעים מהר ככל שהטריגרים מתחילים עבודה חדשה.

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

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

הימנעו מ: לקרוא לבסיס קוד «dark» רק משום שהמפעל שלו פועל בלי שמישהו צופה. אם sessions של agent פועלים AFK ואדם סוקר את ה-PR שלהם, זהו מפעל תוכנה. זו אינה dark factory.

שימוש:

«מי שינה את לוגיקת הניסיון החוזר בשירות החיוב? איש בצוות לא זוכר.»

«שירות החיוב הוא dark factory. ה-agents ממזגים את כל השינויים שעוברים CI. איש לא קרא את השינוי הזה.»