הבלוג של ינון פרק

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

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

2. מתחילים בבירור פרטים ואז מעבירים ל AI את המושכות.

3. מתחילים לבד ונותנים ל AI לדבג ולתקן את הטעויות שהם עשו.

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

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

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

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

ובאיזה קבוצה אתם?

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

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

גרסה 25 של node.js הוסיפה פיצ'ר כיפי לאנשים שכותבים כלי שורת פקודה שנקרא Single Executable Application. בקצרה הוא מאפשר להטמיע תוכנית node בתוך קובץ ההפעלה של node.js עצמו ואז להפיץ את הקובץ הזה בתור אפליקציית קובץ יחיד, כלומר לקוח מקבל קובץ הפעלה אחד שאיך שמפעילים אותו מבצע את הקוד בסקריפט שהוטמע.

בואו נראה איך זה עובד דרך 3 דוגמאות.

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

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

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

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

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

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

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

name = payload[:name] || payload['name']

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

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

אלכס קונדוב כותב:

Writing code by hand gave me the pace of thought I needed to understand a problem deeply. After a couple of years at a company, I knew the codebase by heart, every corner of it, every service, and every script.

I find it difficult to say the same thing now.

ומביא אותנו לשאלה מהכותרת: "מה צריך בשביל להבין"?

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

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

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

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

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

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

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

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

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

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

אחד השימושים למנגנון ה Embedding נקרא RAG או Retrieval-augmented generation. הרעיון הוא שאחרי שיצרנו וקטורי Embedding מכל הפוסטים נוכל ליצור וקטור כזה גם משאלה של משתמש ואז נוסיף את הפוסטים הרלוונטים לפרומפט בצורה אוטומטית.

בואו נראה איך זה עובד בעזרת פרויקט לדוגמה.

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

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

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

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

1. ג'וניורים נותנים ל AI לכתוב קוד ושולחים PR בלי להבין מה בוצע.

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

3. ג'וניורים לא עצרו לחפש פתרונות יעילים יותר ולא השוו בין מספר אופציות.

4. ג'וניורים לא ראו את בעיות האבטחה שהם הכניסו למערכת.

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

דוגמה קטנה מעולם שיפור ביצועי מערכת Full Stack - הרבה יותר חשוב להבין לעומק מה גורם לאיטיות ומה ה Trade Offs הרלוונטים מאשר להבין איך לחבר את לייטהאוס ב MCP כדי שקלוד ישפר ביצועים באוטומט.