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

1. עקרון 1: שיפור הפיתוח בעזרת AI קורה בשכבות

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

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

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

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

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

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

2. שאלה: מהירות פיתוח לעומת תשתית

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

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

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

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

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

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

רק קריאת הקוד והבנה מלאה שלו מבטיחים שאנחנו מבינים מה בנינו, ובלי לדעת מה בנינו איך נוכל לדבר על זה ולקבל החלטות?

4. שאלה: כמה שווה להשקיע היום בעבודה מול AI, לפני שמתייאשים ועוברים לכתוב לבד?

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

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

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

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

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

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

5. מסקנות ומחשבות קדימה

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

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

2. תיקון בשכבה השניה - ראינו היום איך סוכן הקידוד לפעמים יוצר בעיית ביצועים (N+1 Query) ולפעמים לא. ראינו איך להתמודד עם זה באמצעות תיקון בשכבה השלישית כלומר הוספת הוראה ב AGENTS.md אבל האמת שזה לא תיקון מספיק טוב ובחלק מהמקרים למרות שיש הוראה מפורשת לסוכן לשים לב לבעיות מסוג זה הוא עדיין מפספס. פעם הבאה אראה איך אני מתקין כלי אוטומטי לזיהוי בעיות ביצועים מסוג זה ומחייב את הסוכן להשתמש בו לפני שהוא מסיים לעבוד.

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

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