📌 איך לקודד עם AI בלי לאבד שליטה על הקוד

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

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

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

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

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

✏ מה זה אומר לאבד שליטה על הקוד

מה זה אומר שמישהו "מאבד שליטה על הקוד"? הנה דוגמה מפוסט שעלה לרדיט:

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

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

כשאני כותב תוכנית JavaScript כזו:

let smallest = Infinity;

for (let i = 0; i < 10; i++) {
  let num = Number(prompt("Enter number " + (i + 1) + ":"));

  if (num < smallest) {
    smallest = num;
  }
}

console.log("The smallest number is: " + smallest);

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

אבל מה עם AI? כתבו את הפרומפט:

implement a javascript program that reads 10 numbers and print the smallest one

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

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

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

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

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

✏ למה הבן אדם שבלופ הכרחי (עדיין)

להסתכל על קוד ולהסביר אותו? זה קלאסי AI לא?

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

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

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

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

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

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

✏ טיפ 1 - מבינים את השינוי לפני כל מיזוג

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

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

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

✏ טיפ 2 - בועטים ואז חוקרים

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

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

1. באיזה קומיט זה נכנס?
2. איך לא שמנו לב?
3. מה ההשפעה של התקלה הזו? האם יש מקומות במערכת אליהם היא דווקא תורמת?
4. איך אפשר לשנות את הארכיטקטורה או מבנה המערכת כדי שתקלה כזו בכלל לא תוכל לקרות?
5. האם AI היה יכול לפתור אותה אוטומטית רק מתיאור התקלה? אם לא איזה מנגנונים חסרים לו כדי שכן יוכל?
6. יש עוד דרכים לפתור את זה?
7. האם תקלה דומה נמצאת במקומות נוספים בקוד?

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

✏ טיפ 3 - מכרסמים בפרטים בקצב שלכם

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

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

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

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

✏ טיפ 4 - מחלקים אזורים בקוד ולא פיצ'רים

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

בעולם ה AI אני לא חושב שזה רעיון טוב.

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

כשמשהו מוזר קורה ב DB יש בן אדם אחד שהוא אלוף בבסיסי נתונים ושווה לתת לו להסתכל. כשמשהו נשבר ב Front end אני אעדיף להתייעץ עם חבר צוות שמכיר טוב ריאקט במקום עם קלוד. בצורה כזאת אנחנו מחזקים את הצוות ולוקחים בחזרה את השליטה.

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

📌 את כל הקוד כותב AI אבל...

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

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

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

📌 למה לבנות לעצמכם מערכת לפיתוח סוכנים

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

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

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

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

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

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

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

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

📌 התהיות בעקבות הרצאת הפתיחה של DHH

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

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

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

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

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

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

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

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

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

📌 להצביע על הבעיה

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

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

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

📌 בואו נזהה באגים בקוד פייתון אסינכרוני

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

✏ באג 1

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

async def dashboard(user_id):
    user     = await get_user(user_id)
    orders   = await get_orders(user_id)
    invoices = await get_invoices(user_id)

רואים איפה זה שבור?

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

async def dashboard(user_id):
    user, orders, invoices = await asyncio.gather(
        get_user(user_id),
        get_orders(user_id),
        get_invoices(user_id),
    )

    return user, orders, invoices

✏ באג 2

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

async def user_orders(uid):
    return [await get_order(uid, i) for i in range(3)]

await asyncio.gather(*(user_orders(u) for u in users))

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

async def user_orders(uid):
    return await asyncio.gather(
        *(get_order(uid, i) for i in range(3))
    )

results = await asyncio.gather(
    *(user_orders(u) for u in users)
)

✏ באג 3

אוקיי אוקיי עכשיו ה gather מתאים למספר הלולאות:

for i in range(0, len(urls), 10):
    await asyncio.gather(*(fetch(u) for u in urls[i:i+10]))

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

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

sem = asyncio.Semaphore(10)

async def limited_fetch(url):
    async with sem:
        return await fetch(url)

results = await asyncio.gather(
    *(limited_fetch(u) for u in urls)
)

והאמת גם הקוד כולו יצא יותר קריא.

✏ באג 4

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

lock = asyncio.Lock()
cache = {}

async def get_cached(key):
    async with lock:
        if key not in cache:
            cache[key] = await complex_calculation(key)
        return cache[key]

# the caller
await asyncio.gather(*(get_cached(k) for k in ["a", "b", "c", "d", "e", "a", "a"]))

המטרה היא ש complex_calculation תופעל רק על הערכים השונים וכל ה a-ים יחכו לחישוב שפועל, כלומר שהיא לא תופעל 3 פעמים עבור שלושת המופעים של a.

אבל זה לא מה שקורה.

בגלל שהנעילה מכסה גם את הכתיבה למילון וגם את הפעלת החישוב כל אחד מהערכים מחושב בנפרד בצורה סדרתית. החישוב של a חוסם גם את b, c, d ו e.

מה עושים? משתמשים ב task ומפרידים בין החישוב לבין הנעילה:

lock = asyncio.Lock()
cache = {}

async def get_cached(key):
    async with lock:
        task = cache.get(key)

        if task is None:
            task = asyncio.create_task(complex_calculation(key))
            cache[key] = task

    return await task

📌 כמה מסובך להריץ את הבדיקות

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

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

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

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

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

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

📌 סיכום וובינר: סוכנים מנוהלים Claude Managed Agents

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

✏ איפה מוצאים סוכנים מנוהלים

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

סוכן מנוהל נותן לכם את השירות הבא:

1. קוד שלכם יכול ליצור מכונה וירטואלית חדשה בענן או להפעיל אחת שמורה.
2. על המכונה הוירטואלית רץ סוכן. קוד שלכם יכול לשלוח הודעה לסוכן הזה ולחכות לתשובה ממנו. אותו סוכן יכול להיות מחובר לשרתי MCP, ל Tools, למערכת קבצים וכל זה קורה על אותה מכונה וירטואלית מנותקת מהאפליקציה שלכם.
3. אתם משלמים על הטוקנים ועל הזמן שהמכונות הוירטואליות באוויר. לא צריך לשלם כשהמכונה ב idle. המכונות הוירטואליות נשארות במצב idle אחרי שהסוכן סיים לענות להודעה וכך אפשר לקבל סוכנים קבועים, סוכן שתמיד ממשיך מהמקום הקודם בו הוא עצר.

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

✏ בואו ניצור סוכן מנוהל כדי לראות איך זה עובד

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

/claude-api managed-agents-onboard

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

❯ /claude-api managed-agents-onboard

  Listed 1 directory

⏺ Managed Agents is hosted. Anthropic runs the agent loop, the sandbox and the infrastructure, and you just define the
  agent. We'll set it up in three steps: the agent, the environment it runs in, and then a live test session.

  To start, describe the agent you want:

  - What should it do? For example, "triage new Linear issues and draft fixes as PRs" or "research competitors and
    produce a weekly xlsx summary".
  - What starts it? A person chatting with it, an event from your app or a webhook, or a schedule such as every night.

  Mention any services it has to work with, like GitHub, Slack or your own API, and anything it should produce, like a
  report, a PR or files. I'll use that to write a draft config for you to react to.

✻ Sautéed for 9s · done 18:21

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

create a shopping list agent.
  the agent handles "add item" and "show items"
  users should get to it via a python web app (fastapi)
  and create a simple HTML/JS/CSS UI for it

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

1. מי המודל?
2. צריך איזה פרומפט מערכת מיוחד?
3. איזה כלים?
4. איפה הרשימה תישמר?
5. מאיפה לוקחים מפתח API?
6. האם כל המשתמשים מקבלים את אותה רשימה?

אני עונה שימשיך עם ברירות המחדל, שאת המפתח אכתוב ישירות לקובץ .env בהמשך ושלכולם יש את אותה רשימה:

continue with the defaults; everyone has the same list; I'll put the API key in a .env file after you finish

סוף סוף קלוד התחיל לכתוב קוד. התוצאה היא עץ הקבצים הבא:

.
├── agents
│   └── shopping-list.md
├── app
│   ├── __pycache__
│   │   └── main.cpython-314.pyc
│   └── main.py
├── environments
│   └── shopping-list.yaml
├── pyproject.toml
├── README.md
├── static
│   ├── app.js
│   ├── index.html
│   └── style.css
└── uv.lock

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

1. השתמש ב uv לנהל את הפרויקט
2. השתמש ב Type Hints בכל הפונקציות, לדוגמה:

def add_item(name: str, quantity: int = 1) -> dict:

def get_items() -> list[dict]:

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

בצד השלילי שמתי לב שבדרך כלל קוד fastapi יהיה אסינכרוני. כאן יש לנו קוד סינכרוני שמשתמש ב thread pool ובגלל זה הנעילה. החלפה מקוד סינכרוני לקוד אסינכרוני דורשת שינוי משמעותי בקובץ. זו אחת הבעיות בעבודה עם Coding Agent שמצד אחד אנחנו מקבלים קוד משמעותי עובד אבל מצד שני לפעמים מדלגים על החלטות חשובות. ברור שאפשר לחזור אחורה ולתקן את הפרומפט או לבקש מהסוכן עכשיו לעשות את השינוי אבל אף אחד מהאופציות לא מלהיבה.

הרשימה עצמה נשמרת בקובץ שזו גם החלטה סבירה בהתחשב בנסיבות.

הקוד הכי חשוב ב main.py הוא הפונקציה run_turn שמפעילה את הסוכן המנוהל:

def run_turn(session_id: str, text: str) -> list[str]:
    """Send one user message and drive the session until the agent's turn ends."""
    replies: list[str] = []
    # Stream-first: open the stream before sending so no early events are missed.
    with client.beta.sessions.events.stream(session_id=session_id) as stream:
        client.beta.sessions.events.send(
            session_id=session_id,
            events=[{"type": "user.message", "content": [{"type": "text", "text": text}]}],
        )
        for event in stream:
            if event.type == "agent.message":
                replies.extend(b.text for b in event.content if b.type == "text")
            elif event.type == "agent.custom_tool_use":
                result, is_error = run_custom_tool(event.name, event.input or {})
                client.beta.sessions.events.send(
                    session_id=session_id,
                    events=[
                        {
                            "type": "user.custom_tool_result",
                            "custom_tool_use_id": event.id,
                            "content": [{"type": "text", "text": result}],
                            "is_error": is_error,
                        }
                    ],
                )
            elif event.type == "session.status_terminated":
                break
            elif event.type == "session.status_idle":
                # requires_action = waiting on a tool result we are sending; keep going.
                if event.stop_reason.type == "requires_action":
                    continue
                if event.stop_reason.type == "retries_exhausted":
                    raise HTTPException(502, "The agent failed to finish this turn.")
                break
    return replies

✏ הפעלת הסוכן

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

    if not session_id:
        session = client.beta.sessions.create(
            agent=AGENT_ID, environment_id=ENVIRONMENT_ID, title="Shopping list chat"
        )
        session_id = session.id
        print(f"New session: https://platform.claude.com/workspaces/default/sessions/{session_id}")

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

ant apply agents/shopping-list.md environments/shopping-list.yaml

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

✏ מה קיבלנו

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

1. המערכת מנהלת רשימת קניות בקובץ JSON מקומי.
2. כל הודעה נשלחת לסוכן שרץ על סוכן במכונה וירטואלית בענן של אנתרופיק.
3. הסוכן מבין מתוך ההודעה איזה פריטים להוסיף לרשימה או אם צריך להציג את הפריטים ברשימה ומפעיל את הפונקציות המתאימות בפייתון שנכתבו ב main.py.
4. אנתרופיק מבטיחה שכל סוכן רץ בסביבה מבודדת ומקבל את המשאבים להגיב מהר.

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

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