קלוד ב-Block: פייבל מתכנן, מודלים זולים מבצעים, ושני אנשים מאשרים

מי זו Block ולמה דווקא הסיפור הזה

Block היא החברה האמריקאית שמאחורי Square, מערכת התשלומים לעסקים, ו-Cash App, אפליקציית הכסף לצרכנים. ב-8 באוקטובר 2026 פרסמה אנתרופיק ראיון עם Bradley Axen, ראש יכולות ה-AI ב-Block, שמוביל את הצוות שבונה מוצרי AI מקצה לקצה ומשתף פעולה עם הצוותים של Square ו-Cash App.

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

איך נראית מיגרציה כשפייבל מתזמר אותה?

מיגרציה ב-Block, לפי Axen, היא מאות או אלפי בקשות מיזוג על פני כמה מאגרים ומיליוני שורות קוד. בעבר אנשים תיאמו את העבודה הזאת, ומודל לקח על עצמו בקשת מיזוג אחת או כמה בכל פעם. עם פייבל 5 החלוקה השתנתה:

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

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

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

למה זה משתלם, ולא רק עובד?

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

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

רמת מאמץ היא לא מחוון, היא ציר נוסף

זה החלק המפתיע ביותר בראיון. לדברי Axen, מודל ברמת xhigh הוא כמעט מודל אחר מאותו מודל ברמת medium, ו״פייבל על low עשוי להיות פשוט טוב יותר ממודל אחר על xhigh״. לכן Block לא בוחרת מודל ואחר כך מכוונת מאמץ. היא בודקת כל מודל בכל רמת מאמץ, לכל שימוש שהיא מודדת, ומחפשת המלצה פשוטה בסגנון ״המודל הזה על high כברירת מחדל למשימה מהסוג הזה״.

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

איפה הסוכן עוצר?

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

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

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

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

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

מה זה Buzz, ולמה Block בנתה אותו?

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

לפי הפוסט של Block מ-21 ביולי 2026, Buzz בנוי על הפרוטוקול Nostr, כך שלכל סוכן יש מפתח משלו: הבעלים חותם על הרשאה תחומה, והסוכן חותם על העבודה שלו בזהות שלו, במקום להתחפש לבעלים שלו עם הסיסמאות שלו. קלוד קוד, קודקס, goose וכל סוכן שמדבר בפרוטוקול ACP יכולים לעבוד בו, וכשמחליפים מודל הפרויקט שומר על הזהות, ההרשאות וההיסטוריה. הקוד ב-GitHub כתוב ב-Rust ומופץ ברישיון Apache 2.0.

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

והחוב הטכני?

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

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

ממה כדאי להיזהר כשקוראים את הסיפור

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

איך עושים את זה בקטן עם קלוד קוד?

את הדפוס של Block אפשר להעתיק בלי שום תשתית מיוחדת. השיחה הראשית רצה על מודל חזק ומתכננת, וסוכני משנה עם מודל זול יותר מבצעים. כך נראה סוכן כזה, בקובץ בתיקייה ‎.claude/agents‎:

---
name: migration-worker
description: מבצע משימת מיגרציה אחת שהוגדרה מראש. עורך את הקבצים ומריץ את הבדיקות.
tools: Read, Edit, Bash
model: sonnet
effort: medium
---

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

לפי התיעוד של קלוד קוד, השדה model מקבל sonnet, opus, haiku, fable, מזהה מלא או inherit, והשדה effort קובע את רמת המאמץ של הסוכן בנפרד מהשיחה. מי שרוצה מודל אחד לכל סוכני המשנה בלי לגעת בכל קובץ מגדיר את משתנה הסביבה CLAUDE_CODE_SUBAGENT_MODEL. פירוט מלא: המדריך לסוכני משנה, ולעבודה ארוכה יותר עם הרבה סוכנים, workflows.

ושני המעקות של Block עוברים גם הם כמו שהם:

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

שורה תחתונה

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

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