חבר שואל - "נתתי לקרסר לסדר דברים בפרויקט שלי והוא לא הצליח לעשות כלום. איך כולם מתלהבים מה AI הזה כשאצלי בקוד הוא כמעט חסר ערך?"

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

1. איתור קוד רלוונטי

הפעילו את קרסר (או קלוד קוד, או קופיילוט, או לא משנה מה), בקשו שיעשה משהו ואז הסתכלו איזה קבצים הוא קורא בשביל להצליח לבצע את הפעולה או לענות על השאלה שלכם. שאלו את עצמכם - האם ה AI בכלל מסתכל במקום הנכון?

אם ה AI לא מצליח למצוא את הקבצים בהם נדרש השינוי ברור שאין לו סיכוי להבין את הבעיה ולבצע את התיקון או השינוי שלכם. הנה כמה דברים שכדאי לעשות כדי לעזור ל AI למצוא את הקבצים הנכונים:

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

2. כתבו קובץ אינדקס שמסביר איזה קבצים רלוונטים לכל משימה. הוסיפו את קובץ האינדקס הזה לפרומפט (ידנית או בצורה אוטומטית באמצעות Rule בקרסר).

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

4. אם ה AI טוען קבצים שנראים נכונים אבל הם לא, למשל כי יש שני קבצי CSS למערכת אחד ישן ואחד חדש וה AI מוצא את הישן שכבר לא נמצא בשימוש - מחקו את הקובץ הישן שכבר לא בשימוש.

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

2. כמה קל לעשות את השינוי

אחרי שהגענו לקוד הרלוונטי נרצה לשאול כמה קל לעשות את השינוי שאנחנו מצפים שה AI יעשה. אם יש לי קובץ CSS שמגדיר שמרחק בין שני כפתורים הוא 10 פיקסלים ואני מבקש לשנות את המרחק הזה ל 20 פיקסלים יהיה ל AI מאוד קל לעשות את השינוי. אם קובץ ה CSS מגדיר את כל הגדלים בפיקסלים ואני צריך שהאתר יהיה ריספוסיבי זה כבר שינוי שיהיה ל AI הרבה יותר קשה.

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

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

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

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

1. אם גילינו שפרומפט אחר גורם לקרסר לעשות את השינוי טוב יותר נוכל להוסיף Rule שיצורף אוטומטית לכל פרומפט.

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

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

3. הכנסת הנחות עבודה רלוונטיות

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

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

4. חיבור למידע רלוונטי

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

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

2. חברו את קרסר לשירותי רשת מהם אתם מושכים מידע.

3. אם יש פעולות שאתם יודעים לעשות באמצעות סקריפטים, הגדירו Skills כדי לאפשר לקרסר להפעיל סקריפטים אלה בעצמו.

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

5. בדיקת העבודה של הסוכן

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

1. הגדירו סט בדיקות אוטומטיות שסוכן קידוד יכול להריץ ולהבין בזמן סביר אם הקוד שהוא כתב נכון ולא שובר דברים קיימים.

2. חברו את הסוכן לדפדפן כדי שהוא יוכל ממש להשתמש במערכת ולראות מה עובד.

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