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

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

📌 ניסוי paseo - הפעלת סוכנים ב Docker Sandbox

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

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

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

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

1. מתוך paseo כל פעם שרוצים סביבה מקבילית נוספת לוחצים על יצירת סביבה.
2. פסאו יוצר worktree חדש.
3. נכנסים לסוכן בתוך הסביבה החדשה ומבקשים מ paseo שהסוכן הזה ירוץ בתוך Docker Sandbox.

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

מה צריך? בסך הכל לא הרבה.

מתקינים Docker Sandbox מכאן:
https://docs.docker.com/ai/sandboxes/

מתקינים paseo מכאן:
https://paseo.sh/

ומוסיפים לקובץ ההגדרות של paseo שנקרא ~/.paseo/config.json את הבלוק הבא שמגדיר סוכן שרץ בתוך ארגז חול של דוקר:

  "agents": {
    "providers": {
      "sandbox-codex": {
        "extends": "codex",
        "label": "Codex in sandbox",
        "command": [
          "bash",
          "-c",
          "set -eu; if [ -z \"${PASEO_AGENT_CWD:-}\" ]; then exec sbx exec -i paseo-codex-discovery codex \"$@\"; fi; workspace=\"$PASEO_AGENT_CWD\"; sandbox=\"paseo-$(printf '%s' \"$workspace\" | cksum | awk '{print $1}')\"; sbx run --detached --name \"$sandbox\" codex \"$workspace\" >&2; exec sbx exec -i --workdir \"$workspace\" \"$sandbox\" codex \"$@\"",
          "paseo-sandbox-codex"       
        ]
      }
    }
  }

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

חסרונות? גם יש:

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

📌 האם הסוכן הבודק שלכם הוא רק התחמקות מהחלטה?

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

מנגנון אחד משתמש בכלים דטרמניסטיים - מריצים בדיקת אבטחה סטטית על הקוד, Linter, בדיקות אוטומטיות, מטריקות של איכות קוד, תקציב לגודל ה JavaScript, ונותנים לסוכן לרוץ בלולאה עד שה CI עובר. סוכנים אוהבים לולאות ואחרי כמה שעות יש סיכוי טוב שתקבלו קוד שעובר את כל הכללים שהגדרתם. מיטיבי לכת יגבילו את מספר הנסיונות של הסוכן כדי שלא יגמור לכם את המנוי על פיצ'ר אחד שהוא לא יודע לבנות.

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

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

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

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

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

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

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

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

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

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

✏ לנהוג במכונית

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

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

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

✏ לתקן את הכביש

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

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

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

✏ לכוון את התנועה

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

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

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

✏ לבנות מכוניות

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

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

✏ איך ממשיכים

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

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

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

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