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

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

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

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

https://www.tocode.co.il/talking_ai

1. מה זה אומר לאבד שליטה על הקוד

מה זה אומר שמישהו "מאבד שליטה על הקוד"? הנה דוגמה מפוסט שעלה לרדיט:

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

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

כשאני כותב תוכנית JavaScript כזו:

let smallest = Infinity;

for (let i = 0; i < 10; i++) {
  let num = Number(prompt("Enter number " + (i + 1) + ":"));

  if (num < smallest) {
    smallest = num;
  }
}

console.log("The smallest number is: " + smallest);

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

אבל מה עם AI? כתבו את הפרומפט:

implement a javascript program that reads 10 numbers and print the smallest one

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

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

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

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

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

3. חושבים שעשינו משהו אחד ובפועל קרה משהו אחר.

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

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

2. למה הבן אדם שבלופ הכרחי (עדיין)

להסתכל על קוד ולהסביר אותו? זה קלאסי AI לא?

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

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

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

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

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

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

3. טיפ 1 - מבינים את השינוי לפני כל מיזוג

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

איזה טבלאות הוא הוסיף? איזה קלאסים הוא יצר (או לא יצר)? איזה חיבורים חדשים נוצרו? מה ההשפעה של השינוי על הביצועים? איזה מנגנונים עלול להיות קשה יותר לשנות אחרי השינוי?

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

4. טיפ 2 - בועטים ואז חוקרים

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

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

1. באיזה קומיט זה נכנס?
2. איך לא שמנו לב?
3. מה ההשפעה של התקלה הזו? האם יש מקומות במערכת אליהם היא דווקא תורמת?
4. איך אפשר לשנות את הארכיטקטורה או מבנה המערכת כדי שתקלה כזו בכלל לא תוכל לקרות?
5. האם AI היה יכול לפתור אותה אוטומטית רק מתיאור התקלה? אם לא איזה מנגנונים חסרים לו כדי שכן יוכל?
6. יש עוד דרכים לפתור את זה?
7. האם תקלה דומה נמצאת במקומות נוספים בקוד?

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

5. טיפ 3 - מכרסמים בפרטים בקצב שלכם

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

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

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

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

6. טיפ 4 - מחלקים אזורים בקוד ולא פיצ'רים

אם המערכת מעניינת אתם לא עובדים עליה לבד. שיטת ה Agile לימדה אותנו שמפתחים צריכים לקחת אחריות על פיצ'רים מקצה לקצה וכדאי ליצור Ownership כך שמפתחים אחראים על המוצר שהם בונים.

בעולם ה AI אני לא חושב שזה רעיון טוב.

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

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

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