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

1. מה זה בכלל קוד ידידותי ל AI

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

1. כל פיצ'ר או תיקון באג עולה פחות טוקנים.

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

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

מה שהופך פרויקט לידידותי ל AI היום זה:

1. מבנה קוד מסודר, קבצים קטנים, חלוקה נכונה לקומפוננטות

2. קבצי תיעוד טובים עם אינדקס שעוזר ל AI להבין איזה קבצים מהפרויקט צריך לטעון (זה יכול להיות Skill או קבצים פשוטים בתיקיית docs).

3. בדיקות אוטומטיות, בהן ה AI יוכל להשתמש כדי לבדוק את עצמו.

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

2. איך נראה התהליך

בוובינר הצגתי שתי דוגמאות - אחת מפרויקט langlets ושניה מפרויקט maigret.

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

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

Fix bug in user menu
Open user menu -> Enter "Profile" page -> Hit back
User menu stays open, but it should be closed.

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

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

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

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

בדוגמה שניה הראיתי את פרויקט maigret והצגתי באג ספציפי במערכת הדוחות של הפרויקט. שם ראינו איך הסוכנים צריכים לסרוק את הפרויקט כדי למצוא את מערכת הדוחות ואיפה בדיוק הבאג. הניסוי שם היה ליצור קובץ CLAUDE.md שמסביר פשוט איפה נמצאת מערכת הדוחות ואיך היא עובדת (4 שורות). זה הספיק כדי לצמצם משמעותית את כמות הטוקנים ואת זמן התגובה של הסוכן.

בשני המקרים התהליך הוא איטרטיבי:

1. בוחרים משימה שאני יודע איך היא צריכה להסתיים
2. מפעילים כמה סוכנים במקביל לחקור, זה יכול להיות מאותה תיקיה של הפרויקט או באמצעות worktree ממספר עותקים (עדיף להשתמש ב worktree כאן כדי שלא ידרכו אחד לשני על הרגליים כשהם מנסים לפתור את אותה משימה).
3. קוראים ממש את השיחות כולל כל הפעלות הכלים שביצעו הסוכנים ומנסים להבין על מה התבזבז הזמן ואיזה כיוונים הסוכן לקח שבסוף לא היו נכונים.
4. מנסים תיקון - או שינוי בקוד או שינוי בקבצי prompt ואז מפעילים מחדש את הסוכנים ורואים מה קורה.

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

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

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