📌 היציאה של שופיפיי מריאקט נייטיב והאם זה צריך להשפיע עלינו?

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

https://shopify.engineering/back-to-native

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

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

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

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

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

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

📌 מ"טוב" ל"מעולה"

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

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

I fixed both issues. The service is running, and all 183 tests pass.

ובאמת הנושא תוקן והפיצ'ר החדש עובד.

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

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

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

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

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

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

📌 הזמנה לקורס מובילי AI בפיתוח תוכנה

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

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

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

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

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

לפני החפירות על הסילבוס זה הלינק לדף הקורס:

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

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

✏ למי הקורס מיועד

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

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

✏ מטרת הקורס

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

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

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

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

✏ איך זה עובד

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

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

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

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

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

סילבוס מפורט, מחיר, תאריך פתיחה ובוט ייעוץ מוטמע מחכים לכם בדף הקורס בקישור:

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

📌 האמת של פיתוח תוכנה (זה לקח שבוע)

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

אחרי שבוע התחילו הבאגים.

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

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

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

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

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

📌 היום למדתי: Cache וקלוד

אנתרופיק שלחו לי אימייל לגבי סוכן שאני בונה:

"שמנו לב שהסוכן שלך לא מנצל מספיק את האפשרות לשמור פרומפטים ב Cache. אם תשמור Cache טוב יותר תוכל לחסוך 43% מהוצאות הטוקנים של הסוכן שלך"

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

איפה הקאץ'? אנתרופיק שומרת את המטמון ל-5 דקות וגובה מחיר גבוה יותר לטוקן בשביל להשתמש בשירות הנפלא. שווה אם הסוכן שלכם מנהל שיחות ארוכות עם לקוחות במסגרת חלון זמן של 5 דקות. אופוס למשל יעלה 5$ למיליון טוקנים או 6.25$ לאותם מיליון טוקנים כשמשתמשים ב cache של 5 דקות. מתקדמים יכולים להשתמש ב cache של שעה במחיר של 10$ לאותם מיליון טוקנים.

ההסבר המלא עם כל המחירים והקוד הרלוונטי זמין בדף שלהם כאן:

https://platform.claude.com/docs/en/build-with-claude/prompt-caching

ודוגמת קוד עם cache נראית כך:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    messages=[
        {
            "role": "user",
            "content": "Analyze the major themes in 'Pride and Prejudice'.",
        }
    ],
)
print(response.usage.model_dump_json())

📌 ללמוד לראות ולהראות

אי אפשר לתקן בעיה שלא רואים.

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

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

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

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

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

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

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

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

היום בוובינר דיברנו על Claude Managed Agents וראינו הדגמה של הקוד ואיך ליצור את ההדגמה הזו אצלכם. אלה עיקרי הדברים שהיו שם.

✏ מה זה Managed Agents

גם אנתרופיק וגם OpenAI השיקו לאחרונה מוצר של סוכנים מנוהלים. מוצרים אלה מתחרים ב Agent Core של AWS וההסבר לכל הקטגוריה הוא פשוט - להריץ סוכנים זה מסובך. בין השאר:

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

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

✏ איך לכתוב סוכן מנוהל באנתרופיק

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

https://platform.claude.com/docs/en/managed-agents/quickstart

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

/claude-api managed-agents-onboard

קלוד קוד שאל אותי מה אני רוצה שהסוכן יעשה ואני ביקשתי סוכן של רשימת קניות שתומך בשתי פעולות, הוספת פריט לרשימה וצפיה ברשימה. נכון רשימת קניות אמיתית גם צריכה לאפשר לסמן שקנינו משהו או למחוק פריטים אבל את זה נשאיר לגרסה 2. אחרי קצת חשיבה קלוד קוד יצר שלושה קבצים: קובץ requirements.txt עם כל התלויות, קובץ app.py עם שרת API וקובץ setup.py שמקים את הסוכן באנתרופיק.

מפתח ה API שלי היה שמור בקובץ .env ובאיטרציה הראשונה קלוד קוד שכח לטעון אותו אבל אחרי תזכורת הקוד התחיל לעבוד. הקובץ הראשון setup.py מכיל את הקוד הבא:

# ONE-TIME SETUP - run once (`python setup.py`), then copy the printed lines into .env
#
# Creates the three reusable, versioned resources the runtime app needs:
#   - an environment (the cloud sandbox)
#   - a memory store (persists the shopping list across sessions)
#   - an agent (model/system/tools - references nothing session-specific)
#
# Agents/environments could also be defined as YAML and applied with the `ant` CLI
# for CI-managed configs (see shared/anthropic-cli.md) - this script also creates
# the memory store, which the CLI doesn't have a documented syntax for yet, so
# everything is grouped here for a single one-time run.
import anthropic
from dotenv import load_dotenv

load_dotenv()

client = anthropic.Anthropic()

SHOPPING_LIST_PATH = "/shopping_list.md"


def main():
    environment = client.beta.environments.create(
        name="shopping-list-env",
        config={"type": "cloud", "networking": {"type": "unrestricted"}},
    )

    store = client.beta.memory_stores.create(
        name="Shopping List",
        description="The user's shopping list: a single markdown checklist file.",
    )
    client.beta.memory_stores.memories.create(
        store.id,
        path=SHOPPING_LIST_PATH,
        content="# Shopping List\n",
    )

    agent = client.beta.agents.create(
        name="Shopping List Agent",
        model="claude-sonnet-5",
        system=(
            "You manage the user's shopping list. It lives as a single file, "
            f"shopping_list.md, inside your attached memory store - a markdown "
            "checklist with one item per line, formatted as `- item`.\n\n"
            "When asked to add an item: read the file, add the new line only if an "
            "equivalent item isn't already present (merge quantities when given, e.g. "
            "adding 'milk' when 'milk' is already there should not create a duplicate "
            "line), then write the file back. Reply with a short confirmation of what "
            "changed.\n\n"
            "When asked for the current list: read the file and reply with the items, "
            "one per line, no extra commentary. If the list is empty, say so explicitly."
        ),
        tools=[
            {
                "type": "agent_toolset_20260401",

                "default_config": {"enabled": True},
                "configs": [
                    {"name": "web_search", "enabled": False},
                    {"name": "web_fetch", "enabled": False},
                ],
            }
        ],
    )

    print("Add these lines to .env:")
    print(f"ANTHROPIC_ENV_ID={environment.id}")
    print(f"ANTHROPIC_AGENT_ID={agent.id}")
    print(f"ANTHROPIC_AGENT_VERSION={agent.version}")
    print(f"ANTHROPIC_MEMORY_STORE_ID={store.id}")


if __name__ == "__main__":
    main()

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

1. סביבה - איפה הסוכן ירוץ, איזה הרשאות יהיו לו.
2. זכרון - איזה קבצים הסוכן יחזיק, במקרה שלנו קובץ markdown של רשימת הקניות.
3. סוכן - מודל, הוראות וכלים.

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

הקובץ השני שנוצר הוא app.py, זה פשוט שרת API ב flask רגיל לגמרי שמתחבר לסוכן:

# RUNTIME - every invocation. Requires setup.py to have been run once and its
# printed IDs added to .env.
import os
import time

import anthropic
from dotenv import load_dotenv
from flask import Flask, jsonify, render_template, request

load_dotenv()

client = anthropic.Anthropic()

AGENT_ID = os.environ["ANTHROPIC_AGENT_ID"]
AGENT_VERSION = os.environ["ANTHROPIC_AGENT_VERSION"]
ENV_ID = os.environ["ANTHROPIC_ENV_ID"]
STORE_ID = os.environ["ANTHROPIC_MEMORY_STORE_ID"]

MEMORY_INSTRUCTIONS = (
    "This store holds one file, shopping_list.md - a markdown checklist, one item "
    "per line as `- item`. Read it before answering and write it back after any change."
)

app = Flask(__name__)


def run_single_turn(message: str) -> str:
    """Create a short-lived session, send one message, return the agent's reply text."""
    session = client.beta.sessions.create(
        agent={"type": "agent", "id": AGENT_ID, "version": AGENT_VERSION},
        environment_id=ENV_ID,
        resources=[
            {
                "type": "memory_store",
                "memory_store_id": STORE_ID,
                "access": "read_write",
                "instructions": MEMORY_INSTRUCTIONS,
            }
        ],
    )
    print(f"session: https://platform.claude.com/workspaces/default/sessions/{session.id}", flush=True)

    reply_parts: list[str] = []
    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": message}]}],
        )
        for event in stream:
            if event.type == "agent.message":
                for block in event.content:
                    if block.type == "text":
                        reply_parts.append(block.text)
            elif event.type == "session.status_terminated":
                break
            elif event.type == "session.status_idle":
                if event.stop_reason.type == "requires_action":
                    continue  # waiting on a tool confirmation/result we don't send here
                break  # end_turn, retries_exhausted, or budget_reached

    # This session is one-shot - nothing else will use it, so archive it instead
    # of leaving it sitting `idle` forever. The stream's `status_idle` event can
    # arrive slightly before the session's queryable status catches up, so a
    # fresh archive call can 400 with "cannot archive while running" - retry briefly.
    for attempt in range(3):
        try:
            client.beta.sessions.archive(session_id=session.id)
            break
        except anthropic.APIStatusError as e:
            if e.status_code == 400 and attempt < 2:
                time.sleep(1)
                continue
            print(f"warning: could not archive session {session.id}: {e}", flush=True)

    return "".join(reply_parts).strip()


@app.get("/")
def index():
    return render_template("index.html")


@app.get("/shopping-list")

def get_list():
    reply = run_single_turn(
        "List everything currently on the shopping list. Reply with one item per "
        "line, each line formatted as `- item`, and nothing else. If it's empty, "
        "just say so in plain text instead."
    )
    items = [
        line.strip()[1:].strip()
        for line in reply.splitlines()
        if line.strip().startswith("-")
    ]
    return jsonify({"items": items, "raw": reply})


@app.post("/shopping-list")
def add_item():
    item = (request.get_json(force=True) or {}).get("item", "").strip()
    if not item:
        return jsonify({"error": "missing 'item'"}), 400
    reply = run_single_turn(f"Add '{item}' to the shopping list.")
    return jsonify({"result": reply})


if __name__ == "__main__":
    app.run(port=8000, debug=True)

הפונקציה המעניינת כאן היא run_single_turn והיא פונה לסוכן עם בקשה ומחזירה את התשובה. הפניה לסוכן מבוצעת דרך קריאת הספריה client.beta.sessions.create כדי ליצור session ולאחריה client.beta.sessions.events.stream כדי לשלוח הודעה.

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

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

סך הכל מבחינת נוחות עבודה Claude Managed Agents לדעתי יותר נוח מ Agent Core, במיוחד אם ממילא אתם רוצים לעבוד רק עם הסוכנים שלהם.

📌 שומר סף

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

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

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

וגם פה AI יכול לעזור.

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

📌 ארבע טעויות של AI ואיך לתפוס אותן בלי לקרוא את הקוד

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

✏ מספרים קסומים והגבלות מלאכותיות

את הקוד הזה כתב GPT 5.6 כחלק ממימוש פיצ'ר שביקשתי:

@messages = Array(client.messages_index(limit: 50, order: "-modified", search_key: @search_query)["data"])
  .select { ...}

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

בגלל שלא ציינתי גבול ולא ביקשתי מנגנון Pagination הסוכן החליט להגביל את השליפה ל-50 תוצאות.

הנה עוד אחד מתיאור כלי ל MCP:

limit: int("Maximum number of characters to return per part. Defaults to 4000."),

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

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

✏ מימוש מנגנון כפול

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

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

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

טיפ 2 - הריצו Code Review נוסף עם שאלה ספציפית: איזה מנגנונים נבנו בשביל הפיצ'ר ולאיזה מהם יש כבר מנגנונים מקבילים במערכת. לפעמים המנגנונים הקיימים לא מתאימים בדיוק ולכן הסוכן בחר לא להשתמש בהם; לפעמים הסוכן פשוט פספס. בכל מקרה זה משהו שכדאי להחליט בעצמכם.

✏ קוד חדש ששובר קוד או עיצוב קיים

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

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

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

✏ רציתי לונדון וקיבלתי מלחמה

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

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

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

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

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

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

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

📌 השוואת מימושים - רובי מול פייתון

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

פרומפט ראשון בפייתון:

create a python function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

והמימוש:

import csv


def load_customers(csv_path):
    customers = []
    seen_emails = set()

    with open(csv_path, mode="r", newline="", encoding="utf-8") as file:
        reader = csv.DictReader(file)

        if "email" not in reader.fieldnames:
            raise ValueError("CSV must contain an 'email' column")

        for row in reader:
            # Normalize email so casing/whitespace doesn't create duplicates
            email = row["email"].strip().lower()

            if email not in seen_emails:
                seen_emails.add(email)
                row["email"] = email
                customers.append(dict(row))

    return customers

כמה דברים בולטים:

1. אין טיפול ב BOM, שהוא תו נסתר בתחילת הקובץ שמציין את סדר הבתים. בלי טיפול זה אם עמודת email היא הראשונה אנחנו עלולים לקבל את הטקסט \uFEFFemail בתור שם העמודה במקום רק email וכך ההשוואה תכשל.
2. ערך email חסר בשורה מסוימת מפעיל strip על None, נכשל ומרסק את כל הפונקציה במקום לדלג על הערך החסר.
3. אם יש מספר שורות עם אותה כתובת מייל המימוש שומר רק את הראשון ולא ממזג את הנתונים.
4. אין וולידציה או אורך מינימלי על כתובת מייל כך שעמודת email ריקה גורמת לשמירה של הנמען.

עכשיו אני מנסה פרומפט כמעט זהה, רק מחליף את השפה:

create a ruby function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

התוצאה:

require "csv"

def load_customers(csv_path)
  customers_by_email = {}

  CSV.foreach(csv_path, headers: true) do |row|
    customer = row.to_h
    email = customer["email"]&.strip&.downcase

    next if email.nil? || email.empty?

    # Keep the first customer found for each email
    customers_by_email[email] ||= customer
  end

  customers_by_email.values
end

כמה מאפיינים בולטים:

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

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

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