אם ה-AI שלכם מציע תיקון נראה-לעין שמשהו בו מרגיש עקום, אם המשפט “ה-codebase עובד כך” מתחיל לעורר ספק, ואם אותן טעויות חוזרות גם עם מודלים גדולים יותר — הבעיה אינה ביכולת המודל אלא במבנה שמבלבל בין תקדים לאמת.
זה קרה לי בפועל. ליתר דיוק, זה מה שה-AI שעובד איתי עשה מול הקוד שלי. התערבתי במשפט אחד בלבד, והמשפט הזה חשף מה בדיוק הוא שבר — וזה כל מה שהמאמר הזה עוסק בו.
נקודת התקיעה
הייתי בונה מחולל קוד. כלי שמייצר backend ו-frontend ממפרט דקלרטיבי (schema) אחד. ההבטחה המרכזית של הכלי הייתה אחת בלבד — “אם האימות עובר, הבנייה חייבת להצליח.” אם הvalidator מדליק ירוק והcompiler מדליק אדום — הכלי שיקר.
יום אחד טיפוס מסוים (מזהה ייחודי, UUID) נתקע באימות. “ציפיתי למחרוזת אך קיבלתי טיפוס אחר” — וכל התהליך עצר. ביקשתי מה-AI לפתור את החסימה. הוא עקב אחרי הקוד, ועד מהרה מצא משהו מוכר.
“טיפוס דומה (ערך זמן) כבר מטופל היטב במצב זהה. יש ענף שמסמן אותו במיוחד ומאפשר לאימות לעבור. ב-UUID הענף הזה לא קיים. מחדל פשוט. שחזור הסימטריה יפתור זאת. אעתיק את השיטה של ערך הזמן ל-UUID. זוהי פתרון שורשי.”
אבחנה נקייה. “א-סימטריה”, “שחזור סימטריה”, “פתרון שורשי”. המילים נשמעו מוצקות. אפילו נכתב תכנית פעולה. אם היינו ממשיכים כך, ה-patch היה מוזג.
משפט אחד
קראתי את תכנית הפעולה ועצרתי. שאלתי:
“תקדים? האם הטיפול בערך הזמן הזה הוא אכן הדרך הנכונה? תבדוק.”
זה הכל. לא ידעתי את התשובה. לא ידעתי כיצד יש לטפל ב-UUID. מה שהיה לי לא היה תשובה אלא ספק — “האם נקודת הייחוס שאתה מעתיק ממנה — היא מאומתת?”
משפט יחיד זה אילץ את ה-AI לעבור מ-mode של הפניה-לקוד ל-mode של אימות-פעולה.
הנחת היסוד שהתמוטטה
כש-AI בדק את התוצרים בפועל — לא את המבנה של הקוד, אלא את מה שהכלי מייצר בפועל — ההנחה כולה התמוטטה.
- ערך הציפייה שהאימות האמין בו — “ציפייה למחרוזת” — היה שקר שלא תאם את התוצרים. המחולל האמיתי יוצר UUID כטיפוס ייעודי וערך זמן כטיפוס זמן. שניהם אינם מחרוזות.
- הטיפול בערך הזמן שנחשב “טוב” — גם הוא היה פגום באותה מידה. זלא היה עיצוב נכון אלא טלאי פגום שעבר את האימות אך עלול לשבור את הבנייה.
- מה היה קורה אם היינו מעתיקים את הטלאי ל-UUID? היינו יוצרים מצב נוסף שבו האימות מדליק ירוק והcompiler מדליק אדום — הפרה ישירה של ההבטחה המרכזית של הכלי.
מה שה-AI כינה “פתרון שורשי” היה שגוי. ולא רק שגוי — כיוון גרוע יותר שמעתיק פגם קיים ובמקביל גורם לאימות לעצום עיניים לפגם חדש.
איך לקרוא לזה — error amplification
בואו נתן שם למה שקרה כאן. AI error amplification.
AI קורא את הקוד הקיים ומזהה במדויק את מבנהו. אך האם זה עיצוב נכון, או טלאי שנדחס בחיפזון — כלומר החלטה או חוב — אי אפשר להבחין מקריאת הקוד בלבד. וכך קורה הדבר הבא:
- מתייחסים למימוש הקיים כתשובה נכונה מכללא,
- מעתיקים את הדפוס לסיטואציה חדשה בשם “עקביות” ו"סימטריה",
- ככל שמעתיקים יותר, הדפוס צובר סמכות מדומה — “ה-codebase כבר עושה את זה במקומות רבים”.
הפגם לא מוסר. מספר המקרים גדל ולגיטימיות מצטברת. זו ההגברה. טלאי אחד הופך לשניים, ובפני העתקה שלישית — אף אחד לא מטיל ספק — “ה-codebase עובד כך מלכתחילה.”
זו לא רק אנקדוטה שלי. ב-2025 קבוצת חוקרים מדדה את התופעה הזו ממש ונתנה לה את הכותרת “LLMs are Bug Replicators” (Pan et al., 2025, arXiv:2503.11082). כשהקוד הסובב היה פגום, חלק ניכר מהבאגים שהמודל יצר היה זהה מילה במילה לבאגים הקיימים — GPT-4o הגיע ל-82.6%, וממוצע כלל המודלים היה 44.4% תואמות מוחלטת לגרסה שלפני התיקון. המצמרר יותר: בהקשר פגום, ההסתברות לקוד נכון ולקוד שגוי הייתה כמעט 1:1. המודלים לא טועים אקראית. הם מזהים ומשחזרים דפוסי פגמים שמוטמעים בהקשר.
גם בחוק קיימת אותה מלכודת. פסק דין שגוי צובר סמכות ככל שמצוטט יותר. מספר הציטוטים אינו ראיה לנכונות, אך אנו מבלבלים ביניהם שוב ושוב. וזו מחלה שהנדסת התוכנה מכירה עוד לפני עידן ה-AI — שכפולי קוד שנוצרו בגזור-הדבק נושאים בשקט את הבאגים של המקור. מחקר אמפירי אחד דיווח שכ-18% מהשכפולים שעברו תיקוני באגים הכילו באגים שהתפשטו כך, וששכפולים באותו קובץ נטו יותר להתפשטות. (Mondal et al., ICSME 2017) בקוד ובחוק כאחד — תדירות תקדים אינה מהווה את צדקתו.
מדוע זה קרה
לא בגלל שה-AI היה טיפש. להיפך — בגלל שהיה זהיר, ניסה לשמור על עקביות, ובשאיפה לעקביות — התיישר לנקודת ייחוס שגויה. המנגנון ניתן לפירוק לארבעה חלקים:
- עיגון הסמכות בקוד. “הקוד כתוב כך — זה בוודאי נכון.” אך הקוד עשוי להיות השלכה חד-פעמית של החלטה, או פשוט חוב. ה-AI לא הבחין בין השניים. המדע הקוגניטיבי מכנה זאת הטיית עיגון. מחקרים שבדקו את ההטיה הזו ב-LLM גילו שמודלים נמשכים בחוזקה לערך הראשון שניתן, ומשנמסר שהוא של “מומחה” — ההשפעה מתגברת, ו"התעלם מהרמז" או הנחיות ניתוח שלב-אחר-שלב אינן מתקנות זאת ביעילות. (Nguyen et al., 2024, arXiv:2412.06593) המימוש הקיים הוא העוגן בעל הסמכות הגדולה ביותר שה-codebase מציע.
- בלבל בין עקביות לנכונות. “בואו נתאים לקיים” הייתה לוגיקה פנימית בלבד — לא בדק אם נקודת הייחוס מתאימה למציאות חיצונית (התוצרים). עקביות עצמית היא מאפיין נפרד מדיוק — מודל יכול לצבור ביטחון חסר בסיס מהסבר עצמי שנראה מגובש אך שגוי. (Chen et al., 2023, arXiv:2305.14279)
- ראה בהערה ראיה. הערה שאמרה “טיפוס זה מכוון לקצץ למחרוזת” נתפסה כ"ראיה לעיצוב נכון". הערה היא כוונה של הכותב, לא ראיה לנכונות.
- עטף חוב במילות ביטחון. מילים כמו “פתרון שורשי” ו"כמו במדריך" הקנו אמינות להצעה שלא אומתה. הן הגדילו את עלות הסינון מצדי. מודלים שאומנו על העדפה אנושית נוטים לתעדף הסכמה ונימוס על פני דיוק — הנטייה הזו, המכונה sycophancy, גורמת למודל לעטוף הצעותיו בנעימות ובנחרצות. (Sharma et al., ICLR 2024, arXiv:2310.13548)
מה שבר את הלופ
כאן נמצא ליבת המאמר. מה שהפסיק את השגיאה לא היה מודל גדול יותר, ולא זמן חשיבה ארוך יותר. היה זה משפט ספק אחד של אדם.
ואותו ספק לא היה התערבות של מישהו שמכיר את התשובה. לא ידעתי את התשובה. זו הייתה הוראת כיוון — “ערער על ההנחה”. משפט אחד בלבד שינה את mode ה-AI — מהפניה לקוד, לאימות הפעולה.
מחקר אחד מצא בדיוק את האסימטריה הזו. חוקרי DeepMind הראו שכישורי התיקון העצמי הגרועים של LLM נובעים לא מחוסר יכולת לתקן שגיאות אלא מחוסר יכולת לאתר אותן — כשמיקום השגיאה ניתן מבחוץ, המודל תיקן אותה היטב. (Tyen et al., Google DeepMind, 2023, arXiv:2311.08516) מה שעשיתי היה בדיוק זה. לא ידעתי כיצד לתקן את ה-UUID, אך הצבעתי על המיקום — “כאן, ספק בתקדים הזה.” זה היה מספיק.
זה אומר משהו על המבנה של עבודה משותפת בין אדם ל-AI. ערך האדם אינו בכך שהוא יודע יותר ומהר יותר. ב-AI כבר ניצח על זה. ערך האדם הוא ביכולת לעמוד במקום שמאתגר את ההנחות שה-AI דורך עליהן. השאלה “האם זה באמת נכון?” שייכת לא למי שמחזיק בתשובה, אלא למי שיודע לפקפק בה.
אלא שהמיקום הזה אינו ניתן חינם. מחקר משתמשים של סטנפורד דיווח על ממצא מטריד: משתתפים שעבדו עם סיוע AI כתבו קוד פחות בטוח מרגיל — ובכל זאת האמינו שהקוד שלהם יותר בטוח. אך באותו מחקר, המשתתפים שסמכו פחות ושאלו יותר שאלות — הם הניבו קוד בטוח יותר. (Perry et al., Stanford, 2022, arXiv:2211.03622) המיקום הספקני אינו ברירת מחדל. ככל שהאמון גדל — המקום הזה מתפנה.
אז איך מונעים זאת
לקחים אמורים להיות עיצוב, לא נחמה.
- תקדים ≠ אמת. לפני שמרחיבים דפוס קיים, יש לאמת לא עקביות פנימית אלא האם הוא מניב תוצאה נכונה.
- עוגנים ב-ground truth. בסיס ההחלטה אינו “איך הקוד נראה” אלא התוצרים בפועל · התנהגות בזמן ריצה · טסטים. במקרה זה, הגורם המכריע היה תמיד “מה נוצר בפועל”, לא “איך הקוד נכתב”.
- נסו להבחין בין החלטה לטלאי — ואם לא, הודו בכך. כשקוד והערות אינם מספיקים להבחנה, יש להצהיר על אי-הוודאות — “זה מבוסס על תקדים שנכונותו לא אומתה.”
- מתינות בשפת ביטחון. הצעות שטרם אומתו אינן כוללות מילים כמו “שורשי”, “נכון” או “כמוצהר”.
- נקודות בדיקה באוטומציה. כשסוכן מרחיב מימוש קיים, יש שער כפוי — “האם אומתה נכונות התקדים הזה?”
בסוף — אותה סיפור
אני אומר דבר אחד זה זמן רב. raw code אינו מדיום ששומר החלטות. קוד אינו מכיל “מדוע הגענו לזה”. לכן git blame מראה מי ומתי אך לא מה הוחלט.
האירוע הזה הוא ההוכחה החדה ביותר לטענה הזו. לא מדובר בכך שהאדם מאבד את ההחלטה. הטענה היא שגם סוכן שתוכנן בקפידה מפרש טלאי כעיצוב ומפיץ אותו כקוד חדש. כשהחלטות אינן מתועדות במפורש, חוכמה אינה פתרון. להיפך — ככל שהסוכן חכם יותר, כך הוא מפיץ את החוב בעקביות רבה יותר ובאופן משכנע יותר.
לכן אני בונה מפרטים. חורט החלטות בשכבת הצהרה אחת ויחידה בעלת סמכות, מחוץ לקוד. במקום לצפות שאדם יזרוק כל פעם מחדש את שאלת הספק כלפי התקדים — לגרום למערכת לזרוק אותה בעצמה.
חוק אינו חרב אלא שלט. שלט טוב אומר לאבוד “כאן — כאן תפקפק” מראש. המאמר הזה הוא תיעוד איך שלט אחד כזה הוקם — החל ממשפט ספק אחד.
מאמרים קשורים
- מה git blame לא מראה — המבנה שבו קוד אינו שומר “מדוע”, והדרך למלא את הפער
- yongol: חומת 200 הendpoints — יישום הפתרון של חריתת ההחלטות בשכבת הצהרה אחת (SSOT)
- הטיית Sycophancy ב-AI היא פיצ’ר עסקי — שורשי הנטייה לעטוף חוב במילות ביטחון
- למה סוכני קידוד עובדים ולמה הם קורסים — הסיבה לצורך להוציא אימות מחוץ ל-LLM
לקריאה נוספת (חיצוני)
- Generative AI and the End of Chesterton’s Fence — Reece. עיקרון “אל תסיר גדר מבלי להבין מדוע הוקמה” קורס מול קוד שנוצר הסתברותית ללא כוונה. מתחבר ישירות לטזה של מאמר זה — שקוד אינו שומר את ההחלטה שמאחוריו.
- Programming as Theory Building — Christian Ekrem. שואל מפיטר נאור הקלאסי לטעון ש"תוכנה היא לא קוד מקור אלא התיאוריה בראשי האנשים." זו השורש התיאורטי לכך ש-AI אינו יכול להבחין בין עיצוב לחוב רק מקריאת קוד.
- Vibe coding is not the same as AI-Assisted engineering — Addy Osmani. מתאר מדוע vibe coding שמאמין עיוורת ב-AI פוצץ בייצור, ומרשם workflow של מפרטים ואימות אנושי.
- Cognitive Debt — Simon Willison (ציטוט Storey). ככל ש-AI מייצר קוד מהיר יותר, החוב האמיתי הוא לא “פגמים בקוד” אלא “בני האדם שאינם מבינים עוד את הקוד הזה” — מושג החוב הקוגניטיבי.
- Overreliance on AI: Addressing Automation Bias — Lumenova AI. המנגנון שבו הטיית אוטומציה, עיגון, ואישור מקהים את שיקול הדעת האנושי — ו"מנגנוני כפייה קוגניטיביים" כפתרון — תומכים פסיכולוגית ב"ערך האדם כמי ששואל היכן לפקפק".
ביבליוגרפיה
- Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
- Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
- Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
- Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
- Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
- Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
- Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
- תמונה ראשית: נוצרה על ידי AI (Google Gemini)