להפוך ידע שבעל פה למידע שנמצא בפרויקט
אם רק מפתח אחד יודע איך להריץ את המערכת, גם מפתח חדש וגם כלי AI יתחילו בניחושים. התחילו מקובץ קצר שמסביר מה הפרויקט עושה, איפה נמצא כל חלק ואיך מריצים מסלול שימוש בסיסי.
כתבו את הפקודות המדויקות להתקנה, להרצה ולבדיקה. ציינו גרסאות נדרשות, שמות משתני סביבה ודוגמאות בטוחות. ערכים סודיים נשארים מחוץ לתיעוד ולקוד.
הוראות קצרות שאפשר לפעול לפיהן
הוראות טובות לסוכן מתארות החלטות אמיתיות של הצוות. למשל: היכן להוסיף endpoint, איזו בדיקה נדרשת לשינוי הרשאות, ואילו קבצים נוצרים אוטומטית. הימנעו מרשימות ארוכות של כללים כלליים שלא אפשר להכריע לפיהם.
GitHub Copilot תומך בהוראות לפרויקט ובהוראות לפי נתיבים. בחרו את מנגנון ההוראות של הכלי שבו הצוות משתמש ושמרו את הידע המרכזי קרוב לקוד. התמיכה המדויקת תלויה בסביבת העבודה ובכלי.
- מה צריך לקרוא לפני שינוי ברכיב?
- איך מאמתים שינוי בלי לפרוס אותו?
- באילו פעולות צריך לעצור לקבלת החלטה אנושית?
לולאת משוב שאפשר לסמוך עליה
פקודת בדיקה אחת, מהירה וברורה, נותנת למפתח ולסוכן דרך לקבל משוב. היא צריכה לבדוק את החוזים המרכזיים של המערכת. שגיאה שקשה להבין יוצרת עוד ניסיונות; שגיאה שמצביעה על התנהגות שנשברה מקדמת את העבודה.
בחרו שינוי קטן ובצעו אותו בשני שלבים: תחילה הבנת הקוד והצעת שינוי, ואז מימוש ואימות. עברו על התוצאה כמו על כל שינוי אחר. גם קוד שנוצר במהירות צריך להתאים לאילוצים של המערכת.
סקירת מוכנות לפני שינוי רחב
אפשר להשתמש בסריקה סטטית כדי לאתר סימנים כמו תיעוד חסר, פקודות בדיקה לא ברורות וגבולות שדורשים תשומת לב. כדאי לתעד ממצאים שאפשר לפעול לפיהם ולחבר אותם בחזרה לקבצים הרלוונטיים.
ממצא מסריקה הוא נקודת פתיחה לשיחה ולבדיקה. הוא אינו הוכחה לאיכות המוצר או להצלחת סוכן. בחרו שלושה חסמים שמשפיעים על העבודה היום, טפלו בהם ובדקו שוב באמצעות משימה אמיתית.