דיבוג עם AI: איך למצוא באגים מהר יותר

למי המדריך הזה: למפתחים ולבעלי מוצר שכבר עובדים עם Claude Code, Cursor או כלי AI אחר, ומרגישים שהעוזר ״מנחש״ תיקונים במקום לפתור את הבעיה האמיתית. אחרי המדריך תדעו לבנות פרומפט דיבוג שמצמצם ניחושים ומגיע לשורש התקלה בסבב אחד או שניים.

דיבוג עם AI נכשל בדרך כלל לא בגלל שהמודל ״טיפש״, אלא בגלל שהוא מקבל הקשר חלקי: הודעת שגיאה בודדת, בלי stack trace מלא, בלי הצעד שגרם לתקלה ובלי הקוד הרלוונטי. התוצאה המוכרת: המודל מציע תיקון שנראה סביר, אתם מדביקים אותו, הבאג נעלם לרגע וחוזר במקום אחר. הפתרון הוא לא ״פרומפט קסם״ אלא תהליך: שחזור, איסוף הקשר, ואז שאלה ממוקדת.

למה AI מתקן סימפטום ולא שורש

מודלי שפה עובדים על סבירות סטטיסטית, לא על הרצה בפועל של הקוד (אלא אם הענקתם להם כלי הרצה, כמו אצבע ריצה של Claude Code). כשאתם שולחים רק את שורת השגיאה - למשל TypeError: Cannot read properties of undefined (reading 'map') - המודל מנחש היכן ה-undefined נוצר, בהתבסס על תבניות נפוצות בקוד שהוא ראה באימון. לרוב זה נכון בכ-60%-70% מהמקרים בבאגים פשוטים, אבל בבאגים שתלויי-מצב (race condition, cache stale, טעות בסדר קריאות async) שיעור ההצלחה בניחוש צונח משמעותית.

הדרך לשפר את זה היא לתת למודל את מה שמפתח אנושי היה מבקש: reproduction steps, stack trace מלא, הקוד הרלוונטי (לא רק הקובץ שקרס - גם הקורא לו), ותוצאה צפויה מול תוצאה בפועל.

שלב 1: שחזור לפני שכותבים פרומפט

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

מה אתם צריכים לפני שאתם שואלים

• הטריגר המדויק - איזו פעולה, איזה קלט, איזה מסך.
• התדירות - קורה תמיד? רק בפעם השלישית? רק ב-production?
• הסביבה - Node version, דפדפן, מצב רשת (offline/slow 3G משנה הרבה בבאגי async).
• מה השתנה לאחרונה - git log --oneline -10 על הקבצים הרלוונטיים לפעמים חושף את זה מיד.

טיפ: אם התקלה לא משוחזרת ב-100% מהניסיונות, אל תשלחו אותה ל-AI עדיין. תעדו קודם 3-4 ניסיונות עם התוצאה של כל אחד. חוסר עקביות הוא לרוב הרמז החשוב ביותר (state משותף, timing, cache).

שלב 2: קריאת stack trace נכונה - לפני שהמודל בכלל נכנס לתמונה

הרבה מפתחים מדביקים stack trace שלם ל-AI בלי לקרוא אותו בעצמם קודם. זה מבזבז context בחינם.

מה לחפש בעצמכם קודם

1. השורה העליונה שהיא קוד שלכם - לא node_modules, לא framework internals. ב-stack trace של React למשל, לרוב יש 5-10 frames של הפריימוורק לפני שמגיעים לקומפוננטה שלכם.
2. הפער בין throw למקור - לפעמים ה-error נזרק בפונקציה גנרית (fetchJSON, validate) אבל השורש הוא הקורא שהעביר ארגומנט שגוי.
3. Async gaps - at async ב-Node מציין שה-stack ״נקטע״ ונמשך. אם חסר frame באמצע, זה סימן ש-promise rejection לא טופל כראוי (unhandled rejection).

TypeError: Cannot read properties of undefined (reading 'id')
    at formatUser (src/lib/users.js:42:19)
    at async getDashboardData (src/api/dashboard.js:18:22)
    at async handler (src/routes/dashboard.js:9:5)

בדוגמה הזו, השורש הכי סביר הוא לא formatUser - הוא getDashboardData, ששלח אובייקט user ריק. פרומפט טוב יכוון את המודל לבדוק שם, לא רק לתקן את formatUser עם user?.id.

שלב 3: הפרומפט - מבנה שעובד

פרומפט דיבוג עם AI טוב תמיד כולל חמישה רכיבים, בסדר הזה:

1. מה ציפיתי שיקרה
2. מה קרה בפועל (כולל stack trace מלא, לא מקוצר)
3. reproduction steps מדויקים
4. מה כבר ניסיתי (וזה חשוב - חוסך למודל לחזור על ניחושים כושלים)
5. הקוד הרלוונטי - לא רק הקובץ שקרס, גם קבצים שקוראים לו

דוגמה בפועל:

ציפיתי: לחיצה על "שמור" שולחת POST ל-/api/leads ומציגה toast הצלחה.
בפועל: הבקשה נשלחת פעמיים (רואה ב-Network), והטופס לפעמים נשמר כפול ב-DB.
משחזר: תמיד קורה כשלוחצים "שמור" ואז Tab מהר.
כבר ניסיתי: הוספתי disabled={loading} על הכפתור - לא עזר, עדיין כפול.
קבצים מצורפים: LeadForm.jsx, useSubmitLead.js, api/leads.js

פרומפט כזה כמעט תמיד יוביל את המודל ישר לחשד הנכון: debounce חסר על אירוע ה-keydown, או שה-state של loading מתעדכן אחרי ה-render הראשון (stale closure ב-useEffect).

אזהרה: אל תבקשו ״תקן את זה״ לפני שהמודל הסביר לכם למה זה קורה. אם התשובה היא רק דיף בלי הסבר, בקשו ״תסביר קודם את מנגנון התקלה, ואז נתקן״. זה מכריח את המודל להראות את ה-reasoning ולא רק לירות תיקון.

שלב 4: לתת ל-AI כלי הרצה, לא רק טקסט

ההבדל הגדול ביותר בין דיבוג בצ׳אט רגיל לדיבוג ב-Claude Code הוא הרשאת ריצה. כשלמודל יש גישה ל-terminal, הוא לא מנחש - הוא מריץ console.log, בודק ערך אמיתי, ומתקן על סמך תצפית.

אם אתם עובדים עם Claude Code לעסקים שאינם דוברי קוד, הדגישו לצוות: השווי האמיתי הוא לא ה-autocomplete, הוא היכולת להריץ ולבדוק בעצמו. זה גם המקום שבו סוכני משנה (subagents) ב-Claude Code עוזרים - אפשר להריץ סוכן דיבוג נפרד שרק חוקר, בלי לגעת בקוד production.

שלב 5: מתי לעצור ולחזור אחורה

לפעמים המודל נתקע בלולאת תיקונים - מציע תיקון א׳, זה שובר משהו אחר, מציע תיקון ב׳ שמחזיר את הבעיה המקורית. זה סימן שה-context חסר משהו מהותי, לא שצריך עוד ניסיון.

מתי לאפס את השיחה

• אחרי 3 סבבי תיקון כושלים באותה שיחה - ה-context מלא בניחושים שגויים שממשיכים להטות את התשובה הבאה.
• כשהמודל מתחיל ״להמציא״ API שלא קיים בפרויקט שלכם (hallucination קלאסי בדיבוג).
• כשההסבר משתנה בכל סבב - סימן שאין לו תיאוריה יציבה, רק ניחושים.

טיפ: פתחו שיחה חדשה, סכמו ב-3-4 שורות מה כבר ידוע (לא מה שלא עבד - רק עובדות מאומתות), וצרפו שוב את הקבצים הרלוונטיים. שיחה נקייה עם תקציר ממוקד עדיפה על המשך שיחה עמוסה.

איסוף context: מה לצרף ומה לא

טעות נפוצה היא לצרף את כל הריפו, בתקווה שהמודל ״ימצא לבד״. זה מבזבז tokens ולעיתים דווקא מוריד דיוק כי מידע לא רלוונטי מתחרה על תשומת הלב של המודל.

רשימת בדיקה לפני שליחה

• [ ] הקובץ שבו נזרקה השגיאה
• [ ] הקובץ שקורא לו (ה-caller) - כמעט תמיד רלוונטי
• [ ] קובץ הטיפוסים/interface אם יש (מונע ניחוש שגוי על shape של אובייקט)
• [ ] כל hook או state management שנוגע בנתונים האלה
• [ ] גרסת החבילות הרלוונטיות אם החשד הוא breaking change (package.json)

מודלים כמו Claude מנצלים context caching היטב - אם אתם מריצים כמה סבבי דיבוג על אותו קובץ גדול, שווה להכיר את prompt caching כדי לא לשלם על אותו הקשר שוב ושוב.

דיבוג בקוד שנוצר ב-vibe coding

אם הקוד עצמו נוצר במקור על ידי AI (Cursor, Bolt, Lovable וכו׳), יש שכבת מורכבות נוספת: לפעמים אין לוגיקה עקבית כי חלקים שונים נכתבו בזמנים שונים עם הנחות סותרות. במקרה כזה, לפני שמבקשים תיקון נקודתי, שווה לבקש מהמודל מיפוי קצר: ״תמפה לי את כל המקומות שבהם user.subscription נקרא, ותסמן איפה הפורמט לא עקבי״. זה חוסך סבב דיבוג נוסף. הרחבה על זה יש בטעויות נפוצות במעבר מ-prompt לאפליקציה ובסיכוני אבטחה בקוד vibe coding - חלק לא קטן מ״באגים״ בקוד AI הם בעצם חורי אבטחה שמתגלים כשגיאת runtime.

Code review כדי לתפוס באגים לפני שהם קורים

דיבוג טוב הוא תגובתי; code review טוב הוא מונע. שילוב של כלי code review מבוססי AI בתהליך ה-PR תופס בעיות טיפוסיות (null checks חסרים, טיפול שגוי ב-async) עוד לפני שהן מגיעות ל-production ולסבב דיבוג. זה לא מחליף דיבוג ידני, אבל מקטין את הכמות.

שאלות נפוצות

איך מנסחים פרומפט דיבוג עם AI שמביא תוצאה מדויקת?

כללו חמישה רכיבים: התנהגות צפויה, התנהגות בפועל עם stack trace מלא, צעדי שחזור מדויקים, מה כבר ניסיתם (כדי שלא יחזור על ניחושים כושלים), והקוד הרלוונטי כולל את הקורא (caller), לא רק הקובץ שקרס.

מה עדיף לדיבוג - ChatGPT, Claude או Cursor?

זה תלוי בגישה לריצה בפועל. כלים שיכולים להריץ קוד ולבדוק תוצאה בפועל (כמו Claude Code או Cursor עם terminal) עדיפים משמעותית על צ׳אט טקסטואלי גרידא, כי הם מוודאים השערה במקום לנחש. השוו את הגישות בClaude Code מול Cursor.

למה AI ״מתקן״ באג אבל הוא חוזר במקום אחר?

לרוב כי המודל תיקן את הסימפטום (למשל הוסיף ?. כדי למנוע קריסה) ולא את השורש (למה הערך היה undefined מלכתחילה). בקשו הסבר מנגנון לפני תיקון, ולא רק דיף.

כמה context כדאי לצרף כדי לא לבזבז טוקנים?

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

איך מוודאים שה-AI לא ״ממציא״ API שלא קיים בפרויקט?

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

בואו נדבר

אם צוות הפיתוח שלכם נתקע בלולאות דיבוג ארוכות עם AI, או שאתם רוצים לבנות תהליך עבודה שבו סוכן AI פותר תקלות עוד לפני שהן מגיעות אליכם - קבעו שיחת ייעוץ חינם של 30 דקות או כתבו בוואטסאפ.

מקורות

• Anthropic Docs - Claude Code
• MDN - Stack Trace Debugging
• Node.js Debugging Guide
• Chrome DevTools Debugging