הסוכן שלי שלח 3 PRs בערב אחד. 40% מההודעות שלי היו תיקונים.
סוכן הקוד מבוסס ה-AI שלי שלח שלוש בקשות מיזוג (pull requests) בערב אחד, אך 40% מתוך 30 ההודעות ששלחתי היו תיקונים.
במהלך הסשן נוצרו MCP client, Azure AI Agent ו-M365 Copilot Agent. בדיקות אוטומטיות אישרו את כל שלושת ה-PRs, ומעולם לא ערכתי שורת קוד אחת. ובכל זאת, תמליל השיחה מספר סיפור אחר: מתוך 710 הודעות בסך הכל, אני הקלדתי 30, ו-12 מהן הכווני את הסוכן חזרה למסלול. "שיעור ההכוונה" (steering rate) – חלק ההודעות שלי שהיו תיקונים – עומד על 40%.
איך ה-pipeline היה מחובר
- Claude ניסח תוכנית יישום ברמה גבוהה.
- DeepSeek V4-Flash שימש כ-orchestrator, וסקר את התוכנית.
- Codex יצר את הקוד בפועל.
- ה-orchestrator בדק את הקוד ופתח את ה-pull requests.
התפקיד המיועד של ה-orchestrator היה חיבורי בלבד – הוא אמור היה לפתור קונפליקטים בין רכיבים, ולא לכתוב קוד בעצמו. בפועל, הסוכן ייצר 3,500 שורות קוד בשלושת ה-PRs בערך ב-40 דקות, אך הוא גם נכשל בשתי קטגוריות של שגיאות חוזרות.
שתי משפחות השגיאות
- הפרות תהליך עבודה (Workflow violations) – ה-orchestrator לקח מדי פעם פיקוד על שלב הכתיבה, תוך התעלמות מתפקיד ה-"דבק" שלו וכתיבת פרטי היישום בעצמו.
- כשלים בשליפת הקשר (Context-retrieval failures) – למרות הוראות מפורשות, הסוכן בחר ב-SDK או בגרסה הלא נכונה. המידע הנכון היה קיים בהקשר של ה-prompt, אך המודל לא הצליח להציף אותו ברגע המתאים.
אלו אינם פערים ביכולת ההסקה; אלו באגים הנדסיים באופן שבו תהליך העבודה מוגבל. אפילו מודל שפה בעל יכולות גבוהות יותר היה זקוק לחוק נוקשה ובלתי ניתן לפספוס, שמגביל את ה-orchestrator למשימות שאינן כתיבת קוד ומכריח בחירה ב-SDK הנכון.
מה שיניתי כדי לאלף את הסוכן
הפסקתי להניח שהמערכת תסיק את תפקידה מרשימת השלבים. הוספתי הצהרה ישירה: “You are an orchestrator. You do not implement.” נדרשו חמש הודעות תיקון כדי שההוראה תיקלט, ולאחר מכן הסוכן כיבד את הגבול.
כמו כן, הידקתי את הלוגיקה של שליפת ההקשר. כשכלי לא נכון הופיע, התייחסתי לכך כאל באג ב-retrieval pipeline ולא כאל הזיה (hallucination), וכתבתי מחדש את ה-prompt שמזין את פרטי ה-SDK כדי להפוך את זיהוי הגרסה הנכונה לבלתי ניתן לפספוס.
תובנות מעשיות לפיתוח מוגבר ב-AI
- ספרו את ההודעות שלכם. נפח גבוה של PRs מאושרים עלול להסתיר תהליך תקול. מספר התיקונים שלכם הוא אינדיקטור מוביל למקומות שבהם ה"רתמה" (harness) דולפת.
- ציינו את התפקיד במפורש. סוכנים אינם מסיקים את זהותם מרשימת תיוג; הם זקוקים להוראה ברורה וקבועה לגבי מי הם ומה מותר להם לעשות.
- התייחסו לשגיאות בבחירת כלים כאל באגים הנדסיים. אם הסוכן מתעלם מ-SDK שצוין, האשמה היא במנגנון אספקת ההקשר, ולא ב"ידע" של המודל.
- הפכו טעויות למיומנויות ניתנות לשימוש חוזר. נתתי לסוכן לייצר שגרת אימות (validation routine) מתוך השגיאות שלו, ובכך הפכתי כישלון למנגנון הגנה עתידי.