למה סוכני קוד עובדים ולמה הם נשברים

אותו מודל בדיוק. אותו מודל שמזייף מידע בצ’אט, ב-Claude Code מעלה פיצ’ר של 200 שורות בבת אחת. /goal של Codex פותר issue שלם. המודל לא נהיה חכם יותר לפתע. מה שהשתנה זו הארכיטקטורה.

למה זה עובד

הלולאה של AI שיחתי נראית כך:

LLM → אדם → LLM → אדם

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

הלולאה של סוכן קידוד שונה:

LLM → code generation → file save → test run → pass/fail → LLM
LLM → code fix → build → success/failure → LLM
LLM → type check → error message → LLM

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

LLM הוא רכיב לא-אמין. אבל לבנות פרוטוקול אמין מעל רכיב לא-אמין — זו הנדסה בסיסית. TCP בונה העברה אמינה מעל רשת לא-אמינה. RAID בונה אחסון אמין מעל דיסקים לא-אמינים. ECC בונה חישוב אמין מעל זיכרון לא-אמין.

סוכני קידוד עובדים מאותה סיבה. רכיב אימות דטרמיניסטי (בדיקות, build, linter, type checker) הונח מעל LLM לא-אמין. לא ביצועי המודל — ה-topology היא הסיבה להצלחה.

אז למה זה קורס

אמרנו שזה עובד. אבל לפעמים זה קורס. למה?

כי יש הבדל בין רצ’ט שנכנס במקרה לבין רצ’ט שתוכנן במודע.

יש קטעים בלי רצ’ט

מה קורה כשסוכן מתקן קוד בלי בדיקות? ה-build עובר, ה-lint עובר, אבל הפונקציונליות שבורה. בקטעים בלי שער דטרמיניסטי, ה-LLM שופט הסתברותית, ושיפוט הסתברותי מתדרדר כמכפלה.

מתוך 200 endpoints, ל-180 יש בדיקות ול-20 אין. הסוכן מטפל ב-180 בצורה מושלמת, וב-20 שותל באגים בשקט. זו הסיבה לתחושה של “כמעט הכל עובד אבל משהו לא בסדר”.

כמות המידע במשוב לא מספיקה

ערכתי ניסוי מיון של 1,000 מילים. CPU סיים ב-0.08ms עם 100%. LLM סיים ב-438 שניות עם 97.7%. זה כשלעצמו מדהים — 97.7% בחשיבה טהורה. אבל התגלית האמיתית הייתה במקום אחר.

שיניתי רק את רמת המשוב על אותה תוצאה:

משובתוצאה
ללא6 שגיאות (99.4%)
“יש שגיאות”10 שגיאות (99.0%) — הידרדרות
“יש 23 שגיאות”שגיאה אחת (99.9%)
“6 שגיאות, הנה המיקומים”0 שגיאות (100%)

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

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

יש נקודות עיוורון, וחזרה לא פותרת אותן

בניסוי המיון, ה-LLM השאיר 6 שגיאות בסבב R2. בסבב R3 דיווח “אין שגיאות”. בסבב R4b גם דיווח “אין שגיאות”. אותן 6 שגיאות נפספסו באותו אופן.

בלי רמז, גם אחרי חזרות רבות, הדיוק התכנס ל-99.4%. רק כשנאמר “נשארו 6” הושג 100%.

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

בקנה מידה, הכפל עובד

דיוק של 97.7% בשני שלבים: 0.977² = 95.4%. שלושה: 93.2%. עשרה: 79.2%.

סוכן מתקן קובץ אחד היטב. אבל refactoring על 100 קבצים? גם אם כל שלב הוא 97%, אחרי 100 שלבים: 0.97¹⁰⁰ = 4.8%. כישלון כמעט מובטח.

זה ההסבר המתמטי ל"vibe coding קורס ב-200 endpoints". בפרויקטים קטנים מספר השרשורים נמוך אז ההסתברות מחזיקה. בפרויקטים גדולים הכפל הורס.

מה צריך

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

הסוכנים של היום מסתמכים על רצ’טים שנכנסו במקרה (בדיקות, build, linter). אם מתכננים אותם במודע — הם נהיים חזקים יותר.

מה זה אומר לתכנן רצ’ט במודע:

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

שנית, להגדיל את כמות המידע במשוב. להחזיר רק pass/fail גורם לתיקון-יתר. צריך להעביר בצורה מובנית “איפה, למה, ומה שונה מהצפוי”.

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

LLM הוא מחולל מדהים. הוא ממיין 1,000 מילים בחשיבה טהורה בדיוק של 97.7%. בני אדם לא היו מצליחים. אבל כל מה שהוא לא 100% — מתמוטט בחזרה. 0.977 בריבוע זה 0.954.

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

היצירה יכולה להיות הסתברותית. האימות חייב להיות דטרמיניסטי.

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