בקצרה: בפרויקט שסוכן AI כתב, החוב הוא לא "קוד מכוער". הוא מצב שבו הקוד עובד אבל השינוי הבא הפך לבלתי צפוי - כל תיקון שובר משהו אחר, וכל פרומפט מחזיר תוצאה קצת שונה. ארבעה סוגים חוזרים על עצמם, שניים מהם משפיעים על אבטחה ולא רק על תחזוקה, ורק אחד מהם מצדיק לעצור פיתוח.
ההגדרה, ולמה היא לא באמת השאלה
את המונח טבע ורד קנינגהם ב-1992, והמטאפורה שלו מדויקת: פתרון מהיר הוא הלוואה. הריבית היא המאמץ הנוסף שכל שינוי עתידי דורש, והקרן היא העבודה שמסירה את הסיבה. מרטין פאולר מוסיף לזה הבחנה שימושית: השאלה איננה רק כמה חוב יש, אלא אם הוא נלקח במכוון ואם הוא נבון. הלוואה מחושבת כדי להגיע לשוק היא החלטה עסקית. הלוואה שאיש לא ידע שנלקחה היא בעיה.
ההגדרה המלאה, כולל איך מודדים ומה נחשב חוב בריא, נמצאת במונח חוב טכנולוגי במילון. המאמר הזה עוסק במשהו צר יותר: מה קורה כשהקוד נכתב על ידי סוכן, ואף אחד לא לקח את ההלוואה במכוון.
למה חוב בפרויקט AI מתנהג אחרת
בפיתוח קלאסי, החוב הוא בדרך כלל מודע. מישהו כתב הערה, פתח כרטיס, או לפחות זכר שהמקום הזה שביר.
בפרויקט שנבנה בפרומפטים, אין את הזיכרון הזה. הסוכן מקבל בקשה, מייצר קוד שעונה עליה, ולא משאיר סימן לכך שהיה כאן פשרה. התוצאה איננה קוד גרוע - הקוד לרוב תקין וקריא. התוצאה היא שאין מפה.
וזה משנה את התסמין. חוב קלאסי מרגיש כמו איטיות: לוקח יותר זמן לשנות דברים. חוב בפרויקט AI מרגיש כמו חוסר יציבות: אותה בקשה מחזירה שתי תוצאות שונות בשני נסיונות, תיקון בפינה אחת שובר פינה אחרת, ובשלב מסוים כל שינוי מתחיל להרגיש כמו הימור.
ארבעה סוגים שחוזרים על עצמם
נדידת ארכיטקטורה
הסוכן פותר כל בקשה בנפרד ובאופן שנראה סביר בהקשר שלה. אחרי שלושים בקשות יש בפרויקט שלוש דרכים לקרוא מהמסד, שתי שיטות לניהול מצב, ושתי גישות לטיפול בשגיאות - כולן עובדות, אף אחת לא מוסכמת.
זה הסוג שהכי קל למנוע ובדיעבד הכי קשה לתקן. המניעה היא לכתוב את הכללים פעם אחת במקום שהסוכן קורא, ולא לחזור עליהם בכל פרומפט - זה בדיוק מה שקובץ cursorrules מהונדס עושה.
קבצים שגדלו מעבר לחלון ההקשר
כשקובץ נעשה ארוך מדי, הסוכן מפסיק לראות אותו במלואו. אז הוא כותב פונקציה שכבר קיימת, או מוחק קוד שלא הבין למה הוא שם. זה נראה כמו "ה-AI השתגע", אבל זה פשוט מודל שעובד עם חלק מהתמונה.
הסימן: אותו סוכן שהיה מדויק בתחילת הפרויקט נעשה לא אמין באותו פרויקט בדיוק כשהוא גדל.
תלויות שאף אחד לא ביקש
סוכן שנתקל בבעיה מוסיף לפעמים ספרייה כדי לפתור אותה. הספרייה נשארת גם אחרי שהקוד שהשתמש בה נמחק. כל אחת מהן היא שטח תקיפה, קוד שמישהו אחר מתחזק, ועוד גרסה שצריך לעדכן.
זה הסוג הזול ביותר לתיקון: לעבור על רשימת התלויות ולשאול על כל אחת מה משתמש בה בפועל.
הרשאות שנשארו פתוחות
זהו הסוג היחיד שאיננו באמת חוב תחזוקה. פרומפט כמעט אף פעם לא מציין מי רשאי לקרוא מה, ולכן הסוכן בוחר ברירת מחדל - ולרוב היא פתוחה. המערכת עובדת מצוין בהדגמה ודולפת ביום שיש בה שני משתמשים.
מבחינת סדר עדיפויות זה לא נמצא באותה רשימה עם השאר. הפירוט המלא נמצא במדריך RLS ל-Supabase ול-Base44, וסריקה חיצונית של פרויקטי Lovable מצאה שזה הכשל השכיח ביותר, לא נדיר.
איך מזהים בלי שום כלי
הסימנים הבאים הם אינדיקציות, לא מדידה. הם שווים משהו כי אתם יכולים לבדוק אותם היום.
- שינוי קטן דורש הרבה נסיונות. אם שינוי ויזואלי פשוט לוקח סדרה של פרומפטים, הסוכן לא מצליח לאתר את המקום הנכון - כלומר המבנה לא ברור גם לו.
- תיקון אחד שובר משהו אחר. זה הסימן המובהק לנדידת ארכיטקטורה: אין גבול בין החלקים.
- אותה בקשה מחזירה תוצאות שונות. סימן שהקובץ גדול מדי או שההקשר לא מספיק.
- אף אחד לא יכול להסביר איפה נשמר משהו. אם התשובה לשאלה "איפה מוגדרות ההרשאות" היא חיפוש בקוד, אין מפה.
- אתם מגלים תקלות מלקוחות. זה לא סימן לחוב בקוד אלא להיעדר ניטור, ומערך ניטור לסטארטאפ הוא התיקון הזול ביותר בכל הרשימה.
מה לא שווה לתקן
זה החלק שרוב הכתיבה על חוב טכנולוגי מדלגת עליו, והוא זה שחוסך את הכי הרבה כסף.
- קוד מכוער שעובד ולא נוגעים בו. אם אזור בקוד לא השתנה חצי שנה ואין בו מידע רגיש, הריבית עליו היא אפס. לכתוב אותו מחדש זה לשלם קרן על הלוואה שלא גובה ריבית.
- אחידות לשמה. שלוש דרכים לעשות אותו דבר הן בעיה כשהן באזור שמשתנה תדיר. באזור קפוא זו הערת טעם.
- אופטימיזציה לעומס שאין. לפני שיש נתוני שימוש, כל החלטת ביצועים היא ניחוש. היוצא מן הכלל היחיד הוא שאילתות N+1, כי הן נשברות בדיוק ברגע שמגיעים המשתמשים הראשונים שכן חשובים.
- מיגרציה לתשתית אחרת כדי לצאת מהכלי שבו נבנה הפרויקט. זו לא הסרת חוב, זו העברה שלו לסביבה שאתם מכירים פחות.
סדר תיקון שלא עוצר את הפיתוח
הפתרון איננו לעצור הכל ולשכתב. הסדר הזה עובד כי כל שלב מצמצם את הסיכון של הבא אחריו.
- הרשאות. לפני כל דבר אחר, כי זה הסוג שכבר עלול לעלות בנתונים ולא רק בזמן.
- ניטור. אחריו, כי בלעדיו לא תדעו אם התיקונים הבאים שיפרו או שברו.
- כללים לסוכן. לפני שמנקים, לקבע איך נראה קוד תקין בפרויקט הזה - אחרת התיקון עצמו ייצר נדידה חדשה.
- פיצול הקבצים שהסוכן מפסיק לראות. זה מחזיר את האמינות לכלי שאתם עובדים איתו יום-יום.
- תלויות מיותרות. מהיר, זול, ומקטין שטח תקיפה.
- האזור שמשתנה תדיר. רק כאן שווה להשקיע בסידור מבני, כי כאן הריבית משולמת בפועל.
הצעד השישי הוא גם המקום שבו סוכן AI כן עוזר: ריפקטורינג ממוקד באזור מוגדר, עם כללים כתובים ובדיקה אחרי כל שינוי, הוא בדיוק העבודה שהוא טוב בה. מה שהוא לא יעשה בשבילכם הוא להחליט מה חשוב.
מתי זה כבר לא חוב אלא שכתוב
יש נקודה שבה החישוב מתהפך, ושווה להכיר אותה כדי לא להגיע אליה בלי לשים לב. היא איננה "הקוד גרוע" - היא כשאי אפשר לבצע שינוי ולדעת מה הוא שינה. אם אין דרך לבדוק מה נשבר, כל תיקון הוא הימור, ובשלב הזה בנייה מחדש של אזור מוגדר עשויה להיות זולה יותר מתחזוקתו.
גם אז מדובר באזור, לא בפרויקט. הפירוט של איך זה נראה בפועל נמצא במדריך המלא ל-Vibe Coding Rescue, ואם אתם רוצים לתרגם את התמונה למספרים לפני שמחליטים, מחשבון החוב הטכנולוגי עושה את זה בכמה שאלות.
