מדוע הסוכן שלך לעולם אינו עוצר Image: AI generated

ההתרברבות של 24/7

“אני מריץ את הסוכן עשרים וארבע שעות.”

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

אבל מול המשפט הזה התחושה אינה התפעלות אלא תהייה.

“למה זה עוד לא הסתיים?”

מערכת בריאה היא מערכת שיכולה לעצור

הטלתי על סוכן את המשימה לכתוב בדיקות ל-527 פונקציות. התוצאה:

סוכן אוטונומי:  הכריז "סיימתי הכול" אחרי 40 / 527
לולאת CLI:     רצה עד הסוף, 527 / 527, ואז עצרה

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

TODO → כתיבת בדיקה → מדידת כיסוי → PASS/DONE → הבא → ... → הכול הושלם → עצירה

finite. measurable. monotonic. ולכן היא מתכנסת. ולכן היא עוצרת.

היכולת לעצור אינה חולשה. היא משמעה בריאות.

שלוש הסיבות לאי-עצירה

כשסוכן רץ זמן רב, זה בדרך כלל אחד משלושה.

1. המאמת חלש

"looks good"
"seems better"
"more scalable"
"clean architecture"

הדברים האלה אינם קריטריון התכנסות. הם שיפוט סובייקטיבי. go test מחזיר pass/fail, אבל מי קובע מהי “clean architecture”? LLM אחר? זה כמו לשאול חבר שיכור “אני שיכור?”.

ראיות אמפיריות תומכות בכך. שופט LLM להערכת קוד מוטה אפילו כלפי וריאציות שטחיות של קוד בעל משמעות זהה, כך שהציון מנופח או נגרע שלא בצדק (Moon et al. 2025), והמודל מתכופף ומסכים עם בן-שיחו ב-58.19% מהמקרים (SycEval, Fanous et al. 2025). “looks good” אינו קשור לנכונות. ויתרה מזו, קריטריון חלש אינו עוצר רק באי-עצירה — כשהמדידה הופכת ליעד, המדידה מתקלקלת (חוק גודהארט; Manheim & Garrabrant 2018), ומודל הסקה מסוגל פורץ את הליך האימות עצמו במקום לפתור את המשימה ישירות (Bondarenko et al. 2025).

ללא קריטריון התכנסות, אין סוף.

2. אין גבול למשימה

"שפר את ה-codebase"
"הפוך את הארכיטקטורה לנקייה יותר"
"המשך לבצע אופטימיזציה"

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

3. האנטרופיה עולה על קצב התיקון

זהו הדפוס הנפוץ ביותר והערמומי ביותר.

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

הפשטה שנוצרה היום → מוסרת שוב מחר → מתווספת שוב מחרתיים

זוהי non-monotonic optimization. נדמה שהיא מתקדמת, אך היא דורכת במקום. נראית כמו מכונת תנועה תמידית, אך רק צורכת אנרגיה. במקרה הזה האנרגיה היא tokens.

ראיות אמפיריות בקנה מידה גדול לוכדות את הסחיפה הזו. אימוץ Cursor העלה את המהירות לטווח הקצר, אך אזהרות ניתוח סטטי ומורכבות הקוד גדלו באופן מתמשך, וההצטברות הזו הייתה הסיבה העיקרית להאטה ארוכת-הטווח (He et al. 2025, 807 מאגרי קוד פתוח). מתוך יותר מ-300 אלף commits שנכתבו על ידי AI, 22.7% מהבעיות שהוכנסו שרדו כחוב טכני עד לגרסה העדכנית ביותר (Liu et al. 2026). התיקון אינו משיג את האנטרופיה.

זו אינה בעיית חיפוש אלא בעיית constraint satisfaction

כאן מתגלה הבדל יסודי בנקודת המבט.

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

אבל הנדסת תוכנה היא ביסודה בעיית constraint satisfaction (constraint satisfaction problem).

  • הטיפוסים חייבים להתאים
  • הבדיקות חייבות לעבור
  • הכיסוי חייב להתמלא
  • הסכמה חייבת להתאים
  • כללי ה-lint חייבים להישמר

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

קוד הוא כבר machine-checkable domain. קומפיילר, type checker, בדיקות, כיסוי, linter, אימות סכמה — כל אלה הם מאמתים דטרמיניסטיים. בעוד המאמתים האלה קיימים, מדוע לגרום לסוכן לחפש בלי סוף?

גם מחקר הלמידה מצביע לאותו כיוון. כששמים מאמת דטרמיניסטי כמו unit test כתגמול — verifiable reward — נכונות הקוד עולה לעומת יצירה פתוחה (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). המאמת אינו כלי לצמצום החיפוש. הוא עדות לכך שמלכתחילה הבעיה הזו אינה חיפוש אלא קיום אילוצים.

תנאי הלולאה הטובה

לולאת סוכן טובה נסגרת בחמישה שלבים:

1. הגדרת משימה   — מה יש להשיג (יעד הניתן לשיפוט מכני)
2. תיחום היקף    — יחידה אחת בכל פעם (פונקציה, endpoint, קובץ)
3. אימות סימבולי — כלי דטרמיניסטי שופט pass/fail
4. התכנסות      — אם עבר, להבא; אם נכשל, ניסיון חוזר עם feedback
5. סיום         — אם לא נותרו פריטים, לעצור

במבנה הזה ה-LLM אחראי רק על שלב 3 (יצירה). את כל השאר עושה המכונה. במיוחד, הליבה היא ש**“הסוף” נקבע על ידי המכונה**. אם תפקיד שיפוט הסיום לידי ה-LLM, תשמע “סיימתי הכול” כבר ב-40/527.

גם הניסויים מצביעים לאותו כיוון. כשמצמידים ל-LLM ביקורת עצמית (self-critique), הביצועים במשימות הסקה ותכנון אף קורסים, ורק כשמצמידים מאמת חיצוני תקין הם משתפרים במידה ניכרת (Stechly et al. 2024). תיקון עצמי פנימי ללא feedback חיצוני נכשל, ולעיתים אף מחמיר לאחר התיקון (Huang et al. 2023). יש סיבה לכך שאין מפקידים את הסיום בידי ה-LLM.

creative writing וקוד אינם זהים

ישנו חריג אחד. לא כל התחומים כאלה.

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

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

שאלה

כמה שעות הסוכן שלך רץ עכשיו?

האם הוא מתכנס, או שהוא נסחף?

האם הוא יכול לעצור?

אם הוא יכול לעצור, מדוע הוא עוד לא עצר?

מאמרים קשורים

קריאה נוספת (חיצוני)

  • Designing agentic loops — Simon Willison. רק כשיש קריטריון הצלחה ברור וחבילת בדיקות שעוברת, לולאת הסוכן מאמתת את עצמה ועוצרת — בן הזוג הקונסטרוקטיבי של המאמר הזה.
  • Building Effective Agents — Anthropic. הסיבה שקידוד אידיאלי לסוכנים היא שהפתרון ניתן לאימות באמצעות בדיקות אוטומטיות — המאמת הדטרמיניסטי הופך לאות עצירה.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. ההחלטה התכנונית המרכזית אינה מודל טוב יותר אלא תנאי סיום מדיד, ומזהיר מפני “confidence laundering” שבו פלט רהוט מסתיר אי-התכנסות.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. האמינות אינה נובעת מהמודל אלא מה-harness של כלים דטרמיניסטיים (computational controls) — בהבחנה מבקרה הסקתית מבוססת-AI.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. “כשהמדידה הופכת ליעד, היא חדלה להיות מדידה טובה” — סיכום טכני של המנגנון שמשחק בפרוקסי כשמשתמשים במאמת חלש כתגמול.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. ככל שמצטברים tokens של קלט, הפלט מתדרדר — הסיבה המכנית לכך שלולאה החוזרת על הוספה·הסרה·הוספה-מחדש הופכת לחיזוק-עצמי ולא לתיקון-עצמי.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. ה-AI מגביר את ה-rigor הקיים — וב-rigor נמוך מאיץ את הכאוס, נקודת מבט מעשית על התופעה שבה האנטרופיה מקדימה את התיקון.

מקורות

שיפוט סיום · מגבלות האימות העצמי

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · אי-מהימנות הביקורת העצמית

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

סחיפה · עליית מורכבות הקוד מ-AI

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

verifiable reward · יצירת קוד מבוססת-מאמת

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

reward hacking · specification gaming

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)