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

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

1. שכבת ההוראות - שזה הדברים שאנחנו כותבים בשפה טבעית.

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

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

אז איך יודעים אם לזרוק או לשמור? מסתכלים באיזו שכבה היתה הבעיה.

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

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

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

export const setAuthCredentials = response => {
  const expiryDate = getHeaderExpiry(response);
  const now = new Date();
  const diffMs = expiryDate.getTime() - now.getTime();
  const diffDays = diffMs / (1000 * 60 * 60 * 24);
  Cookies.set('cw_d_session_info', JSON.stringify(response.headers), {
    expires: diffDays > 0 ? diffDays : 1, // fallback to 1 day minimum
  });
  setUser(response.data.data);
};

ולמה זה מגושם? כי expiryDate הוא תאריך ו expires יכול לקבל או ערך מסוג תאריך או ערך מספרי שמייצג מספר ימים. מה עושה אופוס? הופך את התאריך לערך מספר (שמייצג מספר ימים) רק בשביל להעביר אותו ל expires של Cookies.set, בלי לשים לב שבתוך Cookies.set הערך הזה יומר חזרה מימים לתאריך.

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

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

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