📌 המבורגר בלי בצל

האנלוגיה הבאה של ריץ' היקי קולעת לנקודה שהרבה אנשים מרגישים:

What you are doing while using automation, instead of learning real-world truths, is attempting to divine the details du jour of some automaton. And striving to game them - e.g. ordering a custom burger (no onions) in order to get a freshly made one. Or filling voodoo.md with just the right incantations. You are only a software update from everything you've 'learned' being rendered obsolete by the latest algorithm. (A soggy cold burger from which the onions have been removed) You have traded working with the world to working for a capricious robot.

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

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

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

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

📌 סיכום וובינר: התקנת אפליקציה על שרת שלנו

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

https://youtu.be/SN621Dk-26Y

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

https://github.com/ynonp/manypacman

להלן הנקודות המרכזיות מהוידאו.

✏ למה להתקין שרת שלכם

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

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

✏ איך זה עובד

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

1. האפליקציה שמורה על השרת בתיקיית הבית של משתמש שמתאים לה.
2. לאפליקציה יש service ב systemd שמנטר אותה ואם יש התרסקות או בעיה מפעיל מחדש.
3. האפליקציה מקשיבה על פורט 3000 אבל חיבורים חיצוניים לא מגיעים ישירות ל next. יש שרת nginx שמקבל את כל החיבורים ומעביר אותם ל next. שרת ה nginx גם יטפל בדומיינים ובתעודות.
4. כל פעם שמשנים קוד ומעלים גרסה חדשה לגיטהאב מופעל Github Action שמתחבר לשרת, מבצע pull, בונה ומפעיל מחדש את הסרביס.

אלטרנטיבה שהעלינו בוובינר היתה שימוש ב docker. ה Github Action בונה image ושירות שרץ על השרת מנטר את מאגר האימג'ים ומושך גרסה חדשה כשהיא עולה.

✏ הקמה בעידן ה AI

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

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

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

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

📌 שרת לא עלה. צ'אט ג'יפיטי להצלה

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

linode performed an emergency update on my server and now my VPS isn't responding. In its lish console I see

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.41
fsck: fsck.swap not found; ignore /dev/sda
done.
mount: mounting /dev/sda on /root failed: No such device
Failed to mount /dev/sda as root file system.


BusyBox v1.37.0 (Debian 1:1.37.0-6+b7) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

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

ניסיתי את הצ'אט וכמובן שהוא לא אכזב. התשובה:

My leading suspicion is that your VPS is trying to boot from the swap disk instead of the actual Linux filesystem.

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

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

שני דברים ChatGPT לא הזכיר והיה צריך שאני אשאל עליהם ספציפית:

1. איך יודעים מה יהיה הסדר? האם אפשר לטעון "מהדיסק עם מערכת ההפעלה" במקום "מהדיסק הראשון" ? (תשובה: כן, יש לכל דיסק UUID ואפשר לציין אותו במקום את מספר הדיסק).
2. מה לינוד ממליצים לעשות? (תשובה: להשתמש ב kernel שלהם שמותאם לעבודה בתוך הסביבה שהם יצרו ולא נשבר ככה).

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

📌 ארבעה תיקונים לפרומפט כדי לקבל קוד טוב יותר מ AI

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

1. עדכנו את הקונטקסט - הוספת קבצים, צילומי מסך, הפניות לדיונים, הפניות ללוגים, מידע מבסיס הנתונים. מיטיבי לכת יקחו צעד קדימה ויתנו לסוכן כלים באמצעותם הוא יגיע לבד למידע הרלוונטי.
2. הגבילו את כללי המשחק - הורידו גישה לדברים, מחקו tools, הגדירו קבצים מסוימים לקריאה בלבד (אפשר בהגדרות הסוכן לסמן את זה), הוסיפו הוראות שבחלקים מסוימים מהפרויקט אסור לגעת. הרחיקו את הסוכן ממקומות שאתם לא רוצים שהוא ישנה.
3. דייקו את ההוראות - במקום להגיד "תקן את X" הסבירו "תקן את X באמצעות ביטול הכפתור אחרי לחיצה כדי שמשתמשים לא ילחצו פעמיים". מיטיבי לכת יוסיפו פילוסופיית פרויקט לקובץ AGENTS.md כדי שהסוכן מראש יבחר בפתרון שמתאים למערכת שלכם.
4. תנו ל AI דרך לבדוק את עצמו - צרו בדיקות אוטומטיות, הוסיפו בדיקות, כתבו הגדרות ל Code Style, תנו לסוכן גישה לדפדפן, גישה למערכת, גישה ל DB.

📌 הצהרת כוונות

אנתרופיק פרסמו פוסט מפורט איך הם מבצעים Code Review. הקו המוביל מתואר בפתיחה:

We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest

הנה עוד כמה דרכים להצהיר כוונות שעשויות להוביל למסקנות שונות כשאתם בונים את תהליך ה Code Review אצלכם:

1. אנחנו לא יכולים להרשות לעצמנו בעיות בתוכנה ומוכנים לשחרר רק קוד שנבדק לעומק.
2. אנחנו רוצים לבנות סביבה בה המכונה תנתח את הקוד ואת המערכת שרצה ותייצר תיקונים בזמן אמת, כמו מכונית שנוסעת לבד.
3. חשוב לנו שלכל מוצר יהיה מוביל טכני שיכיר את כל ההיבטים של המוצר ויהיה אחראי על המוצר, איכותו ועמידתו בתקנים. אנחנו משתמשים ב Code Review כדי שהמובילים הטכניים יכירו את המוצר.
4. שיתוף פעולה בין מפתחים בצוות הוא ההיבט הכי חשוב של העבודה אצלנו. אנחנו מאמינים שרק סיעור מוחות של בני אדם על Pull Request יכול להוביל ליצירתיות וחשיבה ביקורתית.
5. אנחנו מוכנים לקחת סיכונים אבל לאורך זמן קוד איכותי הוא ייתרון תחרותי. מפתחים אצלנו לא קוראים PR-ים אלא מנטרים את המערכות הרצות וכשדברים נשברים צוללים לקוד של אותם מנגנונים כדי לשפר ולבנות אותם מחדש.

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

📌 שלושה דולרים ושבעה סנט

היום בשעה טובה התחלתי חודש חדש במנוי Ollama, בדיוק בזמן לקראת הוובינר מודלים פתוחים שמתוכנן לחמישי. בחודש שעבר Ollama עברו למודל של חיוב חודשי בו אני משלם 20$ לחודש על מנוי ומקבל טוקנים בשווי 60. מודל זה לדעתי משמעותית פחות טוב מההצעה הקודמת שלהם שהיתה מנוי של 20 בחודש, מגבלת "האטה" אם אתה לוקח יותר מדי טוקנים והגבלת Session של 4 שעות בלי הגבלה חודשית. שיטת ה 60$ אומנם פוטרת אותנו מהגבלת ה Session שזה כיף אבל היא גם גורמת לכל העסק של מנוי להישמע יותר קר ורוב הזמן יותר יקר מ Deepinfra.

את הטוקנים של חודש שעבר גמרתי על לולאת רלף כושלת. ניסיתי לכתוב סוכן שיכתוב פוסטים לבלוג וישייף אותם והלכתי על ארכיטקטורה של LLM As a judge, כלומר סוכן אחד כותב, שני משפר ושלישי בודק אם זה מספיק טוב ואם הפוסט לא מספיק מעניין מחזירים אחורה. נושא אחד שלא היה מספיק מעניין טחן את הלולאה. לא עזר כלום הסוכן לא הצליח לכתוב פוסט טוב על הנושא ושלושתם רק אכלו טוקנים עד שגמרו את התקציב החודשי. בבוקר מצאתי את הארנק ריק והסוכנים מעוכים על הרצפה אז נתתי להם עוד 20$, תנאי עצירה יותר טובים וסגרתי את הניסוי כי גם הפוסטים הטובים שיצאו מהמערכת ההיא לא היו מספיק מעניינים. מה שכן יצא ממנה זה סוכן חוקר שסורק את האינטרנט ושולח כל בוקר תקציר חדשות תכנות יומי (בהמשך כשהוא יהיה מספיק טוב אפתח אותו שתוכלו גם לקבל אל דאגה). המשכתי בבניית עוד מספר סוכנים והיום כשהגיע החודש החדש של מנוי ה Ollama קיבלתי תמונה טובה של ההוצאות:

1. הסוכן החוקר התחיל את הבוקר בקריאת אתרי חדשות ושלח לי סיכום חדשות יומי של דברים שמעניינים אותי.
2. בונה הוובינרים זיהה שיש לו טוקנים ושהוובינר הקרוב יהיה ממש ביום חמישי אז הוא קפץ על ההזדמנות וכתב לי פוסט מבוא (תוכנית) לוובינר וגם פוסט סיכום לוובינר. הוא חמוד שהוא כותב פוסט סיכום לוובינר שלא קרה רק לפי הפורמט.
למתעניינים זה הסיכום מחר נגלה אם הוא צדק.
3. הסוכנת האוטומטית "נועה מטוקוד" שיושבת בפינה של קורס AI פה באתר ענתה לפניות שלכם. רובכם שאלתם אותה כמה הקורס עולה (למרות שזה כתוב בדף) או ביקשתם הנחה אבל לא השארתם פרטים אז אפילו אם היא היתה רוצה לתת הנחה לא היה לה איך. בכל מקרה אני חושב שהיא ענתה בנימוס המתבקש ממודל סיני.
4. סוכן הטיולים שלי התחיל לתכנן לי את הטיול לאוגוסט הבא ושלח לי גם הבוקר טיפ קטן על היעד וגם יצר רשימת משימות לביצוע לקראת הנסיעה, כל זה בעזרת סקיל של מתכנן טיול לחו"ל שמצאתי ב skills.il.
5. סוכן בתי הספר קרא 5 קבוצות ווטסאפ של 3 ילדים וריכז לי את כל המשימות לביצוע בתוכנת המשימות שלי.

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

📌 האם יש טעם להתאמן על פתרון בעיות ביצועים במערכת?

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

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

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

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

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

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

📌 לא תחרות

סת׳ גודין כותב:

AI gives bosses a cheaper (and often more compliant) alternative to hiring humans to do some tasks.

סת׳ רואה מה שאני רואה ומה שאתם רואים. המשימה שלנו היא לא להיות יותר מהירים מ AI, לא יותר זולים מ AI, לא יותר צייתנים מ AI ולא יותר מדויקים מ AI.

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

זה כבר לא נשמע כל כך מסובך.