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

האם העתיד של לימודי תכנות יכול להיות זהה לעבר?

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

בקורס פייתון פה באתר השעור הראשון המעניין נקרא "תוכנית ראשונה בפייתון" והוא מתחיל עם הטקסט:

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

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

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

ג'מיני יענה קוד שנראה כך:

username = input("הכנס את שמך: ")
print(f"ברוך הבא, {username}!")

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

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

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

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

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

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

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

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

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

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

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

אנתרופיק פרסמו מחקר חשוב על איך אנחנו מתקשרים עם סוכני קידוד ואיך האינטרקציה משפיעה על רמת המיומנות של מפתחים. בניסוי הם נתנו למפתחים לבנות משהו עם ספריית פייתון ואז בחנו כמה אנשים מצליחים לענות על שאלות על הקוד שהם הרגע כתבו. הם מיפו 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" זה פחד אמיתי של אנשים שרגילים ללמוד ולהבין דברים בצורה מסוימת והצורה הזאת כבר לא קורית מעצמה.

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

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