ואחרי 45 יום שבהם מיזגנו 263 בקשות משיכה (Pull Requests), אני מגייס בן אדם אחד. לא, זו לא סתירה. כן, גם אני הופתעתי.
הדבר הראשון שאני פותח בבוקר הוא לא עורך קוד. זו רשימה של חמש עבודות שרצות במקביל, כל אחת בעותק נפרד של הקוד, כל אחת בידיים של מהנדס אחר. אחת בונה מסך אירועים, שנייה חופרת בזמני טעינה איטיים בפיד, שלישית כותבת מסמך אפיון. אני עובר ביניהן, קורא דיווח, מאשר, מחזיר הערה, ממשיך.
זה נשמע כמו בוקר של ראש צוות. זה באמת בוקר של ראש צוות. רק שאף אחד מהמהנדסים שלי הוא לא בן אדם.
אני ה־CTO של ג'וזי — פלטפורמה חדשנית לאוצרות מוזיקה שבה יוצרים, אמנים ואנשי תקשורת, וגם מאות אוהבי מוזיקה רגילים, כבר מפרסמים המלצות מנומקות, ועשרות אלפי אוהבי מוזיקה מגלים דרכם מוזיקה חדשה ומאזינים לה בג'וזי. אני גם, נכון לרגע זה, כל מחלקת הפיתוח שלה. שאר הצוות — שלושה־עשר סוכני AI — חי בתוך הריפוזיטורי עצמו. לכל אחד תיאור תפקיד, גבולות אחריות, וזיכרון ארוך־טווח ששמור ב־git ונטען אליו אוטומטית בכל פעם שהוא מתעורר.
בחודשים האחרונים יצא לי לקרוא לא מעט כתבות על אימוץ אייג'נטים בסטארטאפים וחברות, וכולן מתארות את אותו דפוס: מפתח ותיק מריץ חמישה־שישה סוכנים במקביל, מתדרך אותם, ומבקש מהם גם לבדוק זה את זה. מנהל פיתוח באחת החברות ניסח את זה יפה: "אין ממש מפתחים יותר. כולנו ראשי צוותים".
קראתי את זה והנהנתי, כי ככה בדיוק עבדתי. מה שהעסיק אותי הייתה השאלה מה קורה אם לוקחים את הכיוון הזה עד הסוף.
כי להריץ חמישה סוכנים במקביל זה כבר שינוי אמיתי — אבל מהר מאוד נתקלתי בתקרה. כל אחד מהם מתחיל מאפס. אתה מסביר לו את אותו דבר בפעם השלושים, והוא עושה את אותה טעות בפעם השלושים ואחת. זה לא צוות. אלה פרילנסרים מצוינים עם אמנזיה.
עד יולי הצוות שלי היה בערך הסרט "ממנטו", רק עם TypeScript
מה שפתר את זה לא היה עוד סוכנים, אלא מבנה. ב־2 ביולי 2026 הפסקתי להפעיל סוכנים והתחלתי לנהל ארגון: ראש צוות שמנתב כל משימה למי שאחראי עליה; שלושה יועצים — ארכיטקט, מומחה UX ומוצר, ומעצב; שני מהנדסי פלטפורמה שמחזיקים את התשתית של האתר ושל אפליקציית המובייל; ושבעה מהנדסי דומיין שבונים ומשלחים בפועל.
הכלל הכי נוקשה במערכת הוא כלל הבעלות: לכל נושא משותף יש בעלים אחד ויחיד, ושני סוכנים לעולם לא נוגעים באותו קוד. משימה שחוצה דומיינים לא מתפצלת מעצמה — היא עוברת קודם דרך הארכיטקט, שכותב מסמך תכנון קצר, ורק אז מתפצלת לעבודה מקבילה.
אם תיקחו ממני דבר אחד מהפוסט הזה, שיהיה זה: ההיררכיה היא לא החלק המעניין. החלק המעניין הוא מה שנשאר אחריה.
בסוף כל משימה, כל סוכן כותב לעצמו רשומת לקחים — לא תיאור של מה שהוא עשה, אלא מה שהוא למד. הרשומות נשמרות כקבצים בגיט ונטענות אוטומטית בפעם הבאה שהוא מתעורר. כרגע יש לנו 188 רשומות כאלה, ו־957 שורות של זיכרון מזוקק ומתוחזק.
התוכן שם פרוזאי עד כדי שעמום, ובדיוק בגלל זה הוא יקר: ששאילתה מסוימת במסד הנתונים לא מתנהגת כמו שהתיעוד מבטיח. ששרתי סביבת הייצור נושאים שם שנשמע כמו סביבת פיתוח, ואסור להסיק מהשם כלום. שתהליך רקע מסוים עלול, בכיבוי לא מסודר, להשתיק בשקט את כל מיילי ההתראות של המערכת.
כל שורה שם היא באג שכבר שילמנו עליו פעם אחת. בלי הזיכרון — משלמים עליו כל שבוע מחדש
זה ההבדל בין צוות שמצטבר לצוות שמתאפס. וזה, אגב, גם ההבדל בין עובד ותיק לעובד ביום הראשון שלו — רק שכאן אפשר לעשות לזה git commit.
אני נשאל הרבה אם המהירות באה על חשבון הבקרה. התשובה היא שהיא באה בזכותה. כל שינוי, בלי יוצא מן הכלל, עובר את אותו מסלול:
הקוד נכתב על ידי מודל אחד ונסקר על ידי מודל אחר — הפרדה שהנהגתי עוד בסוף 2025, לפני שהיה לזה שם. לצד זה רצות על כל שינוי בדיקות אוטומטיות, בדיקות טיפוסים וניתוח סטטי. ובקצה יש שער אחד שלא זז: הסוכן לא ממזג לעצמו. אף פעם. בן אדם אומר כן, אחרת זה לא נכנס לייצור.
הקפיצה של יולי לא נולדה ביולי. ג'וזי קמה בינואר 2025 והשתמשה בכלי AI מהיום הראשון. בהתחלה הבשלות פשוט לא הספיקה, ונעזרנו בפרילנסרים אנושיים — בעיקר לקראת היציאה עם הגרסה הראשונה לאוויר והוצאת גרסת המובייל. מקיץ 2025 הפיתוח עבר להיות AI בלבד, ומסוף אותה שנה כל שורת קוד בחברה נכתבת על ידי AI ונסקרת על ידי מודל אחר.
נקודת המפנה האמיתית הייתה אפריל 2026 — החודש שבו בניתי את Eager, מערכת לניהול העבודה של הסוכנים: משימות, יוזמות, וקישור בין כל בקשת משיכה למשימה שהיא סוגרת.
אם הייתם מסתכלים אז על גרף הקומיטים שלי, הייתם שולחים לי הודעה פרטית לשאול אם הכל בסדר בבית. אפריל עד יוני נראים כמו שלושה חודשים של דיכאון קליני. ביוני נגעתי בשלושים ואחד קומיטים. שלושים ואחד.
אבל מה שקרה שם זו לא הייתה האטה — זו הייתה בנייה של תשתית. Eager, חוקי הבעלות, פרוטוקול הזיכרון, הגבולות בין הדומיינים. ב־2 ביולי רק לחצתי על המתג.
| מדד | חצי שנה לפני182 יום · 1.1—1.7.2026 | אחרי הקמת הצוות45 יום · מ־2.7.2026 | שינוי |
|---|---|---|---|
| בקשות משיכה (PR) שמוזגו | 69 | 263 | — |
| קצב שבועי של בקשות משיכה | 2.7 | 40.9 | ×15.1 |
| קומיטים | 383 | 553 | — |
| קומיטים ליום | 2.1 | 12.3 | ×5.9 |
| שורות קוד מקור שהשתנו | 98,600 | 192,200 | — |
| שורות קוד ליום | 542 | 4,271 | ×7.9 |
שיטת המדידה: ספירה ישירה מהריפוזיטורי של ג'וזי (ה־monorepo של הווב), 9 באוגוסט 2026. "שורות קוד מקור" = הוספות ומחיקות בקבצי TypeScript, JavaScript, CSS וסכימת מסד הנתונים בלבד — ללא קבצים שנוצרים אוטומטית וללא קובצי נעילה של תלויות. הסכומים נספרו עד ליום המדידה והקצבים היומיים חושבו על פני 45 יום, ולכן הם שמרניים.
ולמען ההגינות, כי מישהו יבדוק: תהליך העבודה מבוסס בקשות משיכה נכנס לשימוש רק באפריל 2026, יחד עם Eager, ולכן קצב ה־PR של המחצית הראשונה מוטה כלפי מטה. השוואה הוגנת יותר היא מול אפריל—יוני בלבד, שבהם כבר עבדנו בשיטה: 5.2 בקשות משיכה בשבוע מול 40.9 — פי שמונה. אותו יחס בדיוק שמתקבל ממדידת שורות הקוד ליום.
הנפח לבדו הוא מספר משעמם. הפיזור הוא הסיפור: 263 בקשות המשיכה נגעו כמעט בכל שטח המוצר במקביל.
מערכת האירועים החיים נבנתה מקצה לקצה: כרטוס, קופונים, שאלות ותשובות, הקלטות, ולראשונה בהיסטוריה של המוצר — עמודים בעברית עם תמיכה מלאה בכיווניות RTL. במקביל רצה תוכנית הפיד המותאם אישית: שכבת אותות טעם, מנוע דירוג והמלצות, ושכתוב יסודי של מסלול הטעינה של הפיד אחרי שזיהינו צוואר בקבוק בייצור. בערוץ שלישי נבנתה שכבת ישויות מוזיקליות ניטרלית לספק — תשתית שמנתקת אותנו מתלות בשירות מוזיקה יחיד. פרופילים פרטיים למשתמשים שאינם מפרסמים עלו לייצור. ואפליקציית המובייל קיבלה בו־זמנית את התאמות הפלטפורמה שלה.
בצוות אנושי בגודל שלנו היינו בוחרים אחד מהשלושה ודוחים את השאר לרבעון הבא
היום כבר אין לי רשימת "לרבעון הבא". לא כי הפסקתי לתעדף — אלא כי כשהביצוע מפסיק להיות המחסום, פשוט אין מה לדחות.
זו השאלה שאני מקבל בכל פעם שאני מספר את הסיפור הזה, ואני אוהב אותה, כי התשובה שלה הפוכה בדיוק ממה שהיא נשמעת.
הסוכנים ביטלו את המחסום של הידיים. מה שנשאר הוא שיקול דעת — והדבר היחיד שאי אפשר להקביל על ידי הוספת עוד סוכן הוא בדיוק שיקול דעת.
ראשית, קצב. ב־41 בקשות משיכה בשבוע, החלטה ארכיטקטונית שגויה לא נשארת מקומית. היא משכפלת את עצמה לתוך עשרות שינויים לפני שמישהו בכלל שם לב. ככל שהביצוע מהיר יותר, מחירה של החלטה גרועה עולה. הוא לא יורד.
שנית, רוחב פס. אני מכריע היום בשאלות ארכיטקטורה, בשאלות מוצר ובשאלות חוויית משתמש — לעיתים קרובות באותה שעה. הסוכנים מייצרים אפשרויות מצוינות. מי שבוחר ביניהן זה אני, ואני איטי בהרבה מהם.
ושלישית, וזה הפשוט מכולם: כל ההקשר של יכולת ההנדסה של החברה עובר דרך ראש אחד. שלי. זה סיכון תפעולי שאני לא אוהב להסתכל עליו ישר בעיניים.
אני לא מחפש עוד זוג ידיים. אני מחפש דעה שנייה שאפשר לסמוך עליה
אני לא חושב שהמבנה שבניתי הוא סופי, ואני גם לא מתיימר. הסוכנים הם קבצי טקסט, הזיכרון שלהם הם קבצים בגיט. לפצל דומיין או למזג שניים זו עבודה של שעה, לא של רבעון ארגוני עם סדנת יישור קו במלון.
זה, בעיניי, היתרון האמיתי: מבנה ארגוני שאפשר לשנות ביום שני בבוקר.
ומה שאני מחפש עכשיו הוא לא להגדיל את הצוות. הצוות בסדר גמור, תודה. אני מחפש להגדיל את מספר האנשים שמסוגלים להגיד לי "לא". בקצב הנוכחי, זו כנראה ההשקעה הכי זולה שהחברה יכולה לעשות.
