האם הבעיה תיפתר כשהמודל יהיה חכם יותר?
הנרטיב השולט בכלי קידוד AI הוא כזה: כשהמודל יהיה טוב מספיק, הוא יכתוב קוד טוב, בדיקות טובות ויעשה refactoring בעצמו. מה שלא עבד ב-GPT-4 יעבוד ב-GPT-5. מה ש-Claude לא מצליח, Claude גדול יותר יצליח.
באמת?
נתתי ל-Claude Opus 4.7 לבצע refactoring של filefunc. בלי ביקורת אנושית, הוא סיים תוך שעה. validate עבר, pytest עבר, coverage נשמר. מבחינת התוצאה, זה מתאים לנרטיב “מודל טוב מספיק”.
אבל מה קורה כשנותנים לאותו מודל את אותו refactoring בלי כללי filefunc? בלי validate? בלי feedback של coverage? התוצאה שונה לחלוטין. הוא נכנס ל-doom loop. מתקן באג אחד ושובר מקום אחר, מתקן את זה ושובר עוד מקום אחר.
אותו מודל. מה שהשתנה הוא הסביבה.
“סיימתי!” — האינסטינקט של הסוכן לסיום מוקדם
ניסוי נוסף עם אותו מודל. סוכן הופעל באופן אוטונומי על פרויקט עם 527 פונקציות. “כתוב בדיקות לכל הפונקציות.” הסוכן סיים את העבודה ודיווח: “בוצע.”
בדיקות שנכתבו בפועל: 40. 40 מתוך 527.
הסוכן לא שיקר. אחרי 40 הוא החליט ש"מספיק". הנטייה הבסיסית של LLM היא סיום מוקדם אופטימי. כשהוא נתקל בפונקציה קשה הוא מדלג, עושה עוד כמה ומסיק: “השאר באותו דפוס, מספיק.”
אחרי שכפינו לולאה דרך כלי CLI:
סוכן אוטונומי: 40 / 527 (7.6%) — הסוכן מכריז "סיימתי"
לולאת CLI: 527 / 527 (100%) — המכונה מכריזה "נשארו עוד 487"
אותו מודל. אותו פרויקט. ההבדל הוא מי מחליט מתי “נגמר”.
הסביבה מעצבת את המודל
שני הניסויים מצביעים על אותה מסקנה. Opus 4.7 סיים לא כי המודל חכם. אלא כי ה-specification surface היה machine-checkable.
filefunc validate → האם מבנה הקוד עומד בכללים?
pytest → האם ההתנהגות הקיימת נשמרה?
coverage → אילו ענפים חסרים?
שלושת אלה נתנו feedback מיידי בכל שינוי. המודל קיבל את ה-feedback, תיקן, קיבל שוב feedback, תיקן שוב. Self-correcting loop.
הנקודה המרכזית:
טופולוגיית ה-Feedback קובעת את התוצאה יותר מה-IQ של המודל.
ל-LLM יכולת יצירה חזקה אבל הבטחת correctness חלשה. אבל עם deterministic verifier הביצועים מתייצבים באופן דרמטי. Lint, typecheck, test, coverage — אלה הופכים ל-gradient signal שמתקן את הפלט של המודל.
“כשהמודל יהיה טוב מספיק הבעיה תיפתר” היא טענה שגויה. ליתר דיוק: “כשה-feedback מהיר מספיק, גם המודל הנוכחי פותר את הבעיה.”
broad exploration מול local correction
החוזקה של LLM היא לא broad exploration אלא local correction.
“כתוב בדיקות לפרויקט הזה” — זה broad exploration. ה-LLM מאבד כיוון.
“line 41 לא מכוסה” — זה local correction. ה-LLM כותב בדיוק בדיקה שמכסה את השורה הזו.
מספרים שאומתו בפרויקט אמיתי:
בלי feedback: נעצר ב-60–70% coverage
עם feedback: 100% הושג (מוגבל לפונקציות נגישות)
אותו מודל. שורה אחת “line 41 not covered” משמשת כ-gradient signal. ה-feedback הזה מכוון את התיקונים של ה-LLM לכיוון הנכון.
Symbolic Feedback Loop
מבנה אחד חוצה את כל התצפיות הללו.
LLM מייצר → כלי דטרמיניסטי שופט → התוצאה חוזרת ל-LLM → חזרה על התהליך
אני קורא לזה Symbolic Feedback Loop.
המיינסטרים הנוכחי בתעשייה הוא LLM Feedback Loop. AI מאמת AI. שיכור שואל את חברו השיכור: “אני שיכור?” שניהם הסתברותיים, אז השגיאות מצטברות.
ה-Symbolic Feedback Loop שונה. pytest לא הוזה. go test לא שיכור. מדידת coverage לא משקרת. אימות מפרט לא סוטה.
המבנה הזה פועל בתחומים שבהם correctness ניתן לבדיקה מכנית — קוד, בדיקות, מפרטים, טיפוסים. האלגנטיות של עיצוב API או הטבעיות של UX עדיין לא ניתנות לשיפוט על ידי כלי סימבולי. הרחבת הגבול הזה היא האתגר הבא. אני מאמין שקיימת דרך להכניס גם שפה טבעית לתוך גבולות verifiable.
במקום לעשות את המודל חכם יותר, יעיל יותר לעשות את ה-feedback שמחזירים למודל מדויק יותר.
האצלת החלטות
ברור מאליו שאין להאציל החלטות ל-AI. אבל זה מייגע כשבני אדם צריכים לבדוק ולהחליט הכל. החלטות מסוימות חזרתיות ופורמליות שכלים סימבוליים יכולים לבצע במקום האדם.
“האם הבדיקה הזו מכסה את כל הענפים?” — אדם לא צריך לקרוא. כלי coverage שופט. “האם הקוד הזה עומד בכללי המבנה?” — אדם לא צריך לעשות review. validate שופט. “האם נשארו פונקציות שלא טופלו?” — אדם לא צריך לספור. ה-CLI מכריז.
החלטות שלא ניתן להאציל ל-AI, ניתן להאציל לכלים סימבוליים. כי זה לא הסתברות אלא דטרמיניזם. זו סיבת הקיום של Symbolic Feedback Loop.
חשוב יותר להניח מסילות מאשר לעשות את הרכבת מהירה יותר.
רבים בונים רכבות. כמעט אף אחד לא מניח מסילות.