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

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

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

לטענתם חבילת הבדיקות גדלה כמעט פי 4 מאז תחילת השנה עם קצב גידול בדיקות של 2,000 בדיקות חדשות בשבוע.

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

השאלות של פיתוח תוכנה היום הן לא איך לכתוב לולאת for או מה ה API של AWS. את כל אלה ה AI פתר ואני שמח להשתמש בכוחות העל החדשים שלנו. לעומתן השאלות האלה לא קרובות אפילו לפתרון:

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

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

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

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

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

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

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

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

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

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

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

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

עכשיו לסיפור בואו נראה מה הבעיות בו:

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

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

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

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

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

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

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

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

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

ריילסוולרלד נפתח עם הרצאת פתיחה מעוררת השראה ומפתיעה של DHH אני ממליץ לצפות בה:

https://www.youtube.com/watch?v=vDjW_dRyKXY

ואני ממליץ גם על מאמר התגובה המקיף של Jardo כאן:

https://jardo.dev/what-about-rails

עיקרי הדברים של DHH:

1. כתיבת קוד בצורה ידנית (הקלדת התווים) כבר לא כלכלית באופן גורף.

2. הרבה יותר קוד נוצר היום מאשר אי פעם בעבר. גם DHH עצמו יוצר היום (בעזרת סוכני קידוד) משמעותית יותר קוד ממה שיצר פעם.

3. המהפכה שעבר עולם התוכנה מזכירה את מהפכת הציור-צילום עם המצאת המצלמה.

4. קוד שנוצר רק בשביל שיהיה נוח למתכנתים הולך להיעלם. ב 37signals הם הולכים בדרך של שופיפיי ומחליפים את אפליקציות ה Mobile Web שלהם באפליקציות נייטיב מלאות. הוא לא רואה עתיד לפריימוורקים כמו React Native או אפילו Hotwire Native.

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

6. גם בצד השרת יש סימן שאלה גדול לגבי ספריות שכל מטרתן להקל על המתכנתים על חשבון הביצועים של המערכת. טיעון הפרודקטיביות מפסיק להיות רלוונטי כשאנחנו בונים מערכות עם AI. את Hey הם משכתבים להשתמש ב Rust API Backend במקום Rails.

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

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

אני חושב ש DHH כמו DHH עוד ישנה את דעתו לגבי חלק מהסעיפים שם. במיוחד הסיפור של ארכיטקטורת תוכנה וחוסר היכרות עם הטכנולוגיה, שני סעיפים שבניסיון שלי בעבודה הרגשתי בדיוק את ההיפך, כלומר שככל שיש לי יותר היכרות עם הכלים, עולם התוכן והיכולות אני מצליח לקבל עבודה יותר טובה ויותר פיצ'רים מהסוכן. צריך לזכור שהתחרות שלנו היא לא מול מפתחים של לפני 5 שנים אלא מול מפתחים של היום, להם יש גישה לאותם הכלים ולאותן היכולות. מישהו צריך לשים לב ש Rust ייתן Backend יעיל יותר מ Rails ועם פחות שגיאות מ C++, מישהו צריך לשים לב לצריכת הטוקנים וליחס בין טוקנים למוצר, מישהו צריך לשים לב מה קורה כשדברים נשברים והכי חשוב לקבל החלטות טכניות שקשורות לאופן העבודה של המערכת. עד היום לא ראיתי שמודלי שפה מאוד טובים בקבלת החלטות.

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

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

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

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

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

ועכשיו תנסו קצת Use Cases:

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

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

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

4. סוכן שיושב לבד על הלינקדאין ואוסף לידים (ובאמת מביא לידים איכותיים שממירים ללקוחות).

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

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

אצלנו 100% מהקוד נכתב על ידי AI, אבל-

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

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

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

4. בעיקרון AI כותב את כל הקוד אבל חייבים לתת לו הוראות מאוד מדויקות אחרת הוא כותב שטויות.

5. ברור ש AI חוסך לי המון זמן אבל כל הזמן הזה הולך על לקרוא ולהבין מה הוא עשה שם.

6. רגע לא לסגור את המסך של הלפטופ ה AI כותב שם קוד!

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

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

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

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

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

https://www.tocode.co.il/talking_ai

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

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

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

1. ביקשתי מ AI משהו
2. התוצאה לא היתה טובה
3. שיניתי את הפרומפט למשהו יותר ספציפי
4. קיבלתי תוצאה טובה יותר

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

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

https://gist.github.com/ynonp/62e0ac7eab67033bbbb14a8ed149d47d

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