בדקו שינויי קוד שנוצרו ב־AI לפני קבלת התוצאה

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

Mono Code מאפשר לפתוח קובצי פרויקט, לעבוד עם סוכני קוד ולראות שינויי Git ישירות בעורך. המדריך עוסק בבדיקה של שינוי קטן שהסתיים; מדריך הקוד מרחוק מסביר איך להתחבר. המאגר והפקודות תמיד נשארים במחשב שלכם, המחשב המארח. Mono עדיין לא זמין; אפשר להצטרף לרשימת ההמתנה.

1. הגדירו מחדש את תנאי הקבלה

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

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

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

2. בררו את מצב המאגר

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

במסוף במארח הנכון, פקודות הקריאה האלה יכולות לעזור:

git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file

החליפו את הנתיב לדוגמה. git diff רגיל מציג שינויים שטרם הוכנו ל־commit; ‏--cached מציג שינויים מוכנים ביחס ל־commit. קבצים שאינם במעקב דורשים בדיקה נפרדת. תיעוד Git diff מסביר את ההשוואות. עץ עבודה נקי אינו מגלה אם הסוכן כבר ביצע commit; אם זה קרה, בדקו את ההיסטוריה המתאימה.

3. קראו את התיקון ואת הקוד שסביבו

בעורך של Mono, השוליים מסמנים שורות שנוספו או שונו, והקשה על סימון פותחת את ההבדלים של אותו חלק. זו דרך נוחה לראות שינוי אחד, לא הוכחה שבדקתם את כולם. סימון חסר או לא מעודכן לא אומר שהקובץ לא השתנה.

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

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

4. התאימו את הבדיקות להתנהגות

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

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

5. טפלו בממצאים בלי לאבד עבודה לא קשורה

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

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

הרשאה לפקודה וקבלת הקוד הן החלטות נפרדות. אישור פקודת בדיקה אינו אישור לבצע commit, למזג או לפרוס. השתמשו במדריך בדיקת ההרשאות להערכת הפעולה עצמה.

6. השאירו סיכום שאפשר לבדוק

תעדו את המסקנה ברשומה קצרה:

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

השאירו החלטות commit ושחרור מפורשות. אם צריך לשמור את השיחה, ייצאו אותה ל־Markdown, אך שמרו גם את קובצי הפרויקט עצמם. התמליל מתעד דיון; המאגר והבדיקות המאומתות קובעים מה השתנה.