📌 לכתוב או לחשוב

הנה מטריקה טובה כדי להבין אם אתם משתמשים נכון ב AI לקידוד. רשמו בסוף היום:

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

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

📌 אף אחד לא התלהב מאיכות הקוד

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

https://news.ycombinator.com/item?id=48406174

התשובות באמת מדהימות-

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

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

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

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

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

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

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

שאלתי גם את קלוד בשביל המשחק שיחפש ברשת וזו התשובה שקיבלתי:

When people praise AI coding on HN, the praise is almost always about capability, speed, and unblocking — "I shipped an iOS app in two weeks," "10–20x more features," "it found the bug in five minutes." The code-as-craft dimension, when it shows up at all, tends to show up as criticism: the recurring argument that AI code is "always good enough and never great" because great code requires taste and judgment about what's appropriate, what's overkill, what's elegant for this specific codebase.

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

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

📌 איך אני מתחיל היום פרויקט חדש

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

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

1. תיעוד לסוכן - מוודא שיש את כל התיעוד של הספריות הרלוונטיות זמין לסוכן בקבצי Markdown. אם אין אני תמיד יכול להפנות את קלוד לתיעוד ולבקש שיבנה לעצמו Skill ממה שיש שם.
2. בחירת שפה וטכנולוגיה - הרבה פחות חשוב ממה שהיה פעם. טייפסקריפט? פייתון? רובי? ראסט? כל עוד אני יודע לקרוא את זה יהיה בסדר. מה שחשוב זה שהאקוסיסטם יהיה בשל.
3. שולח את הסוכן לבנות דף קונספט. עמוד אחד רק לראות שהכלים עובדים.
4. מסדר את כל מנגנון ה Deployment לגרסה הראשונה. הדבר האחרון שאני רוצה זה שהסוכן יחליט לשמור את המפתחות בקוד כי "זה רק MVP" או משהו כזה.
5. מתקן את מבנה הפרויקט שהסוכן יצר כדי להתאים לפרויקט שאני רוצה וכותב קובץ AGENTS.md עם תיאור הפרויקט וקווים כלליים לפיתוח.
6. מחבר דפדפן (וכלים נוספים לפי הצורך) ב MCP כדי שהסוכן יוכל לבדוק את עצמו.

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

📌 ארבעה פתרונות

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

מתוך ארבעת הפתרונות שלושה עבדו ואחד לא.

השלושה שעבדו היו כולם טובים, כל אחד בדרך אחרת.

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

מי שהיה משתמש בפרומפט השני היה חושב שקלוד לא רואה את התמונה הגדולה.

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

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

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

חבל לעצור בפתרון הראשון שעובד.

(נ.ב. זה אפילו לא מסובך ליצור עוד פתרונות - פעם אחת נתנו למודל לרוץ לבד, פעם שניה הפעלנו Plan Mode, פעם שלישית בכלל הפעלנו מתוך VS Code ובנינו את הפרומפט שלב שלב תוך כדי שאנחנו שואלים את קלוד שאלות על הקוד ואת הרעיון לרביעי קיבלנו אחרי ששלחנו אותו לעשות לעצמו Code Review. יש די הרבה מיץ בלימון הזה שנקרא קלוד).

📌 שלוש תובנות על פיתוח בעידן ה AI מהיוצר של Open Code

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

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

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

https://github.com/ynonp/langlets-rails/commit/24f9d380e593a2886f8163cbf989c9405cbc7402

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

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

📌 המודל החדש של אנטרופיק מוכיח שוב את מה שכולם רוצים לשכוח

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

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

בדוגמה אחרת ביקשתי ממנו לכתוב קוד פייתון שמשתמש ב Multi Threads כדי לספור כמה מספרים ראשוניים יש בין 1 למיליון. פייבל מימש ואפילו דאג להזהיר אותי ששימוש ב Threads למשימה זו הוא לא אידאלי בגלל ה GIL בפייתון ואולי אני רוצה לשדרג ל multiprocessing.

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

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