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

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

הצעד הבא במצבים כאלה הוא git log על הקובץ:

git log -- file

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

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

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

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

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

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

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

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

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

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

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

https://app.emergent.sh

קוד הפעלה: VIBEWITHRUNWAY

הי חברים,

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

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

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

הוובינר יתקיים ביום חמישי הבא ה 29.5 בשעה 10 בבוקר.

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

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

https://www.facebook.com/events/9481501425305658/

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

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

תתחילו עם פונקציות.

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

num = int(input("select a number: "))
sum = 0
x = 1

while x < num:
    if num % x == 0:
        sum += x
    x += 1

if num == sum:
    print("Perfect number")
else:
    print("Not a perfect number")

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

num = int(input("select a number: "))

if num == sum(divisors(num))
    print("Perfect number")
else:
    print("Not a perfect number")

עכשיו יש לנו שתי בעיות חדשות:

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

ועוד כמה שאלות חדשות:

1. אולי גם קלט צריך להיות פונקציה?
2. מה לגבי ה if?
3. וה print? למה אנחנו מדפיסים ולא "מחזירים" ערך? מה ההבדל בין שתי הפעולות?

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

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

אפשר לראות את קוד הדוגמה בגיטהאב: https://github.com/ynonp/docker-model-runner-demo

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

{a: 10}['b']

אבל מה שהודפס לא היה undefined אלא:

{a: 10}['b']
16:05:00.902 ['b']

נסו לראות אם אתם מבינים מה קרה כאן או גללו למטה לפיתרון.

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

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

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

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

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

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

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

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

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

1. האם אנחנו חושבים ש"ליצור" זו מיומנות חשובה ששווה לשמר (גם לבני אדם)?

2. אם מוותרים על "ליצור" ונשארים רק עם "לבחור", איך צריך לשנות את המשימות כדי שהבחירה תהיה חלק חשוב מהעבודה?

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

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

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

https://claude.ai/public/artifacts/6c4cff06-9fe6-485d-80db-b69704f191b4

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

What's clear is that we cannot afford to let creation become a lost art. In our rush to embrace the convenience of AI tools, we must ensure that students continue to experience the productive struggle and profound satisfaction of bringing something entirely new into the world—something that began not in an algorithm, but in their own minds. The blank page may be intimidating, but it remains one of our most powerful teachers.

אני לא כל כך בטוח שהוא צודק.

את הבלוק הבא ראיתי בקוד קטן ש AI יצר:

useEffect(() => {
  getWaitlistCount().then((count) => setWaitlistCount(count + 100))
}, [])

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

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

1. הוא גורם להצגה של מידע שגוי כשהעמוד רק עולה.

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

3. הוא מאט את זמן הרינדור בקלאיינט ומכריח את הקלאיינט להריץ JavaScript אפילו שאפשר היה להתספק רק ב HTML/CSS וקומפוננטת צד שרת.

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

כל מי שמכיר React ו Next ורואה את הקוד הזה אמור להיבהל כי זה פשוט לא הפיתרון הנכון כאן.

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

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

Modify useEffect(() => { getWaitlistCount().then((count) => setWaitlistCount(count + 100)) }, []) to improve performance by moving the code to run on the server in the request handling phase and stream the response to the client by passing a promise to use. Use the result as the initial value to useState

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

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

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

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