ניסיתי כל מערכת פרודוקטיביות שמוכרת לאנושות. Notion, Planner, משימות ב-Outlook, אפליקציות To-Do שונות ומשונות, פגישות קבועות עם עצמי. שום דבר לא החזיק מעבר לשבועיים.
הדפוס תמיד חזר על עצמו. הכלי לא היה הבעיה — אני הייתי הבעיה. אני צריך לזכור לבדוק את המערכת, לזכור לעדכן משימות, לזכור לעקוב אחרי טקסים. כל מערכת בסוף מפסידה בקרב של 30 שניות מול האנטרופיה של יום עמוס.
ואז הבנתי משהו מובן מאליו: AI לא שוכח. AI לא צריך כוח רצון.
אז בניתי Squad. לא עוזר AI אחד כללי. צוות שלם: שבעה סוכנים מתמחים (Picard, B’Elanna, Worf, Data, Seven, Podcaster, Neelix) ועוד שני עובדי רקע (Ralph, Scribe). לכל אחד מהם תפקיד מוגדר, גבולות תחום ברורים, ואחריות אישית.
Ralph מתעורר כל 5 דקות ועוקב אחרי תור ה-issues ב-GitHub. בלי תזכורות. בלי כוח רצון. רק תצפית רציפה ואוטומטית. כשאני מתעורר בבוקר, 14 PRs מוזגו, 6 ממצאי אבטחה מתועדים, 3 שיפורי תשתית מוצעים — הכל בזמן שישנתי.
תוך 48 שעות: 14 PRs מוזגו. 6 ממצאי אבטחה. 3 שיפורי תשתית. ~50K שורות קוד נותחו. אפס פרומפטים ידניים ממני.
זה לא קסם. זה עיצוב מערכות.
המבנה
שבעה סוכנים מתמחים. לכל אחד charter — מסמך שמגדיר את התחום שלו ומונע חריגה:
- Picard (Lead): ארכיטקטורה, אורקסטרציה של ריפוים, החלטות. מחליט מהר כשההקשר ברור. חוזר לעניין כשהנחות משתנות.
- B’Elanna (Infrastructure): Kubernetes, ענן, CI/CD, הקצאת DevBox. מביאה דברים לעבודה ושומרת שימשיכו לעבוד.
- Worf (Security & Cloud): ניתוח אבטחה, compliance, שרשרת אספקה. תופסת בעיות לפני שהן מתפוצצות.
- Data (Code Expert): code review מעמיק, C#, Go, .NET internals. מי שבאמת קורא את הקוד.
- Seven (Research & Docs): תיעוד, סינתזה, ניתוח. אם התיעוד שגוי, המוצר שגוי.
- Podcaster (Audio): סיכומי אודיו, בסגנון שיחה דו-קולית. לא כל החלטה צריכה מסמך של 40 עמודים.
- Neelix (News): אירועים חיצוניים, הזדמנויות אינטגרציה, דפוסים מהאקוסיסטם.
ועוד שני עובדי רקע:
- Ralph: עוקב אחרי תור ה-issues כל 5 דקות (בלי polling ידני). ממזג PRs כשטסטים עוברים. פותח issues חדשים כשמגלה עבודה. לא ישן אף פעם, לא שוכח אף פעם.
- Scribe: רושם שקט. מתעד כל החלטה ב-
.squad/decisions.mdלזיכרון מוסדי. כשחברי צוות מתחלפים, הידע לא מתאדה.
למה המבנה הזה? בהירות מונעת קונפליקטים. כש-Data מוצא בעיית אבטחה, הוא מנתב אותה ל-Worf — זה התחום שלה. כש-Worf מציעה שינויי תשתית, B’Elanna מאמתת אותם. בעלות ברורה פירושה פחות פגישות, פחות שיחות “תן לי לבדוק עם הצוות”.
תהליך עבודה: GitHub Issues כרשומה הקבועה
אני לא משתמש ב-Slack להחלטות טכניות. לא בדוא”ל. אני משתמש ב-GitHub issues.
Issue הוא קבוע. הקשר מלא. כל תגובה מראה את ההיגיון, לא רק מסקנות. כשאני יוצר issue, סוכנים מגיבים, מנתחים, מתווכחים, מציעים פתרונות — הכל מתועד, הכל גלוי. כשאני מתעורר בבוקר, ההחלטה מתועדת עם הסבר מלא.
זה חשוב כי:
- אין אובדן מידע. מחר אוכל לקשר להחלטה. חברי צוות חדשים יורשים את ההקשר.
- ההיגיון שקוף. אפשר לראות למה התקבלה החלטה, לא רק מה הוחלט.
- אין overhead של פגישות. החלטות מתקבלות באופן אסינכרוני. בלי טטריס יומנים.
- תגובות הופכות לרשומות קבועות. בניגוד להודעות Slack (שנעלמות כשגוללים), תגובות ב-issues ניתנות לחיפוש, לקישור ולשליפה גם אחרי שנים.
דוגמה אמיתית: הבלוג פוסט הזה (Issue #41)
כתבתי: “בלוג על מה שבנינו. סיפור אישי על כלי פרודוקטיביות שנכשלים. מערכת Squad, מה שלחנו, למה זה עובד, רעיונות לשמות.”
Seven פרסמה מתווה. נתתי פידבק. היא כתבה טיוטה. הכל בתוך thread אחד ב-GitHub. בלי פגישות סטטוס. בלי שרשרות מיילים. התוצאה: בלוג פוסט מלוטש עם שביל מלא של הנמקות.
אותה מערכת עובדת להחלטות ארכיטקטוניות, ממצאי אבטחה, בעיות תשתית, הצעות לפיצ’רים — כל דבר שדורש דיון אסינכרוני ותיעוד קבוע.
Ralph: תצפית אוטונומית רציפה
הנה פריצת הדרך הארכיטקטונית: אני לא עושה polling לתור העבודה. Ralph עושה. אוטומטית. כל 5 דקות.
1
2
3
4
5
6
while ($true) {
git fetch && git pull
agency copilot --agent squad \
-p 'Ralph: Check all open issues, review PR queue, merge when tests pass, handle new comments, open issues for discovered work, update status labels.'
Start-Sleep -Seconds 300
}
Ralph מתעורר כל 5 דקות. שולף את הקוד האחרון. סוקר כל issue פתוח. בודק סטטוס PRs. ממזג כשטסטים עוברים. מטפל בתגובות חדשות. פותח issues חדשים לעבודה שהתגלתה במהלך הסינון.
אני לא רואה את הלולאה. אני רואה רק: PRs מוזגו, issues נסגרו, ממצאי אבטחה תועדו, הצעות תשתית פורסמו — הכל בזמן שישנתי או הייתי בפגישה.
מצב נוכחי מול מצב עתידי:
בנינו את Ralph כלולאת PowerShell מותאמת אישית כי ל-squad-cli watch (שעדיין בפיתוח) יש פערים:
- הרצה מקבילית: אנחנו צריכים 5 סוכנים שרצים בו-זמנית על 5 issues שונים, לא עיבוד סדרתי
- ניתוב גמיש: prompting מותאם אישית מתאים התנהגות. לוגיקה hardcoded לא
- observability של כשלונות: Ralph מדווח ל-Teams כשנתקל ב-3+ כשלונות רצופים
- אוטומציה של GitHub Project: תוויות סטטוס, מעקב milestones, עדכוני בורד אוטומטיים
Ralph פותר את כל ארבע הבעיות. כש-squad-cli watch יתפתח להתאים לזה, Ralph יהפוך לקוד legacy. עד אז, הוא היתרון התחרותי שלנו: תצפית אוטונומית ללא התערבות ידנית.
החלטות: זיכרון מוסדי
כל החלטה משמעותית נרשמת ב-.squad/decisions.md. לא “התקיימו פגישות”, אלא רשומת ההחלטה עצמה:
class="highlight">1
2
3
4
5
6
7
8
9
10
11
12
13
14
## Decision: Async-First Issue-Based Workflows
**Date:** 2026-03-02
**Author:** Picard (Lead)
**Status:** ✅ Adopted
**Scope:** Team Process
**Problem:** Meetings + Slack cause decision drift. Information scatters. Reasoning disappears.
**Solution:** All technical decisions happen in GitHub issues. Full comment threads preserved. Reasoning documented. Searchable forever.
**Consequence:** No calendar overhead. Context persists. New team members inherit decisions + reasoning.
**Related:** Issue #41 (blog decision), Issue #109 (process directive), Issue #122 (user feedback loop)
הנה הקסם: סוכנים חדשים קוראים את .squad/decisions.md לפני שמתחילים לעבוד. הקשר מיידי. בלי פגישה. כשחבר צוות חדש מצטרף, הוא קורא את ההחלטות ומבין למה הדברים הם כמו שהם — לא רק מה הכללים.
החלטות גם עוקבות אחרי סטטוס: “Adopted”, “Proposed”, “Blocked”, “Superseded”. זה מונע את הבעיה שבה מתקבלת החלטה ואז מתהפכת בשקט שלושה שבועות אחר כך כי מישהו שכח.
מה בנינו בפועל (48 השעות האחרונות)
Podcaster Agent
ממיר מסמכי מחקר לסיכומי אודיו. סגנון שיחה דו-קולי למעורבות. מאוחסן בענן, לא ב-GitHub (לא כל פלט צריך להיות טקסט). תובנה מרכזית: צוותים צריכים תדרוכי אודיו של 10 דקות, לא מסמכים של 40 עמודים. מדיום שונה לדפוסי צריכה שונים.
PRs: #237 (פורמט שיחה), #236 (אחסון ענן), #232 (יצירת דגימות)
אינטגרציית Teams ודוא”ל
סוכנים עכשיו מנטרים ערוצי Teams ותיבות דוא”ל. מסווגים הודעות אוטומטית. מנתבים לסוכן הנכון. מגיבים אוטומטית כשמתאים. סקירה שקטה מתוזמנת לפריטים לא דחופים. שומר על עבודה אסינכרונית מלטבוע ברעש של Slack.
PR: #216 (מוניטור Teams), דפוסי אינטגרציית דוא”ל שונים ב-skills
Squad Monitor (Standalone)
observability חי לסוכנים מבוזרים. פאנל פעילות מראה מה כל סוכן עושה בזמן אמת. מעקב כשלונות. מטריקות עיבוד. דשבורד שניתן לשתף בין squads מרובים. מאפשר ל-Ralph לדווח כשלונות ל-Teams אוטומטית.
PR: #231
DevBox Infrastructure-as-Code
מדריך הקצאה להרצת סוכני Squad ב-DevBoxes בענן במקום מכונות מקומיות. תמיכה ב-auto-scaling. הגדרות רשת. דפוסי תקשורת בין סוכנים. מאפשר ל-Squad לשרוד תקלות לפטופ.
PR: #219
אורקסטרציה בין squads
פרוטוקול לתיאום עבודה בין squads מרובים ללא תשתית מרכזית. מודל federation. נבדק עם dk8s-platform-squad. כל Squad עצמאי אבל יכול להעביר עבודה ל-squads אחרים.
PR: #223
תזמון Provider-Agnostic
Squad מנותק ממתזמן ספציפי. שכבת הפשטה גנרית. אפשר להחליף מימושים בלי לשכתב קוד. תומך במתזמנים חיצוניים (Azure Container Apps, Kubernetes CronJobs) או בלולאות Ralph פנימיות.
PR: #220
אבטחה ו-Compliance
הערכת FedRAMP מקיפה (6 ממצאים). זיהוי drift בתשתית. ניתוח אבטחת שרשרת אספקה. הכל מתועד ב-GitHub issues עם שבילי החלטות וצעדי תיקון.
למה זה עובד
1. התמחות מונעת שיתוק החלטות. כל סוכן מחזיק תחום. כש-Data סוקר קוד, היא יודעת ש-Worf אחראית על אבטחה. כש-Worf מציעה שינויי תשתית, היא יודעת ש-B’Elanna אחראית על פריסות. בעלות ברורה = פחות עיכובי “תן לי לבדוק עם הצוות”. החלטות זזות מקומית.
2. אסינכרוני-ראשון מבטל overhead של פגישות. לא צריך יומנים. לא צריך לתזמן פגישות כדי לתזמן פגישות. עבודה לא נעצרת כי מישהו בפגישה אחרת. Ralph בודק את התור בזמן שאנשים ישנים. החלטות מצטברות בלילה.
3. הנמקה מתועדת, לא רק החלטות. כל החלטה רושמת למה, לא רק מה. “בחרנו ב-Kubernetes בגלל סקייל” זה שימושי. “בחרנו ב-Kubernetes בגלל סקייל כי אנחנו צריכים horizontal pod autoscaling ל-batch workloads, ו-Kubernetes מנוהל בענן עולה 40% פחות מתשתית on-premises שמנהלים לבד, תוך מתן observability טוב יותר” — זה לא יסולא בפז. אתם-של-העתיד תבינו את אתם-של-העבר.
4. תצפית אוטונומית רציפה. Ralph לא צריך תשומת לב אנושית. לא צריך שתזכרו לבדוק. לא צריך כוח רצון. רץ כל 5 דקות, לנצח, ערים או ישנים. זה ההבדל בין רשימת משימות (דורשת זכירה) לבין AI שצופה (לא דורש כלום).
5. זיכרון מוסדי שורד החלפות צוות. החלטות חיות ב-.squad/decisions.md. כשחבר צוות עוזב, ההחלטות שלו נשארות. כשחבר חדש מצטרף, הוא קורא החלטות קודם — בלי אובדן ידע. זה קריטי. רוב הצוותים מאבדים ידע מוסדי כל 18 חודשים כשאנשים מחליפים תפקידים או עוזבים. ה-Squad הזה לא.
מה למדתי
1. תייעלו לאוטומציה, לא לכוח רצון. מערכת הפרודוקטיביות הכי טובה היא כזו שלא צריך לזכור להשתמש בה. כוח רצון הוא משאב סופי. אוטומציה היא אינסופית. הפסקתי לנסות להיות מסודר. בניתי מערכת שלא צריכה שאהיה.
2. תכתבו החלטות, לא רק מסקנות. “בחרנו ב-Kubernetes” → שימושי. “בחרנו ב-Kubernetes כי horizontal pod autoscaling מאפשר scaling חסכוני של batch workloads” → מאפשר החלטות עתידיות. תתעדו את ההיגיון. אתם-של-העתיד תודו לאתם-של-ההווה.
3. אסינכרוני מנצח סינכרוני בעבודת ידע. אם הצוות שלכם מחכה ליומנים, עשיתם משהו לא נכון. GitHub issues + לולאת ה-watch של Ralph נותנים לעבודה לקרות בזמן שאנשים ישנים. זה לא אפשרי עם פגישות סינכרוניות.
4. בעלות ברורה מפזרת החלטות ומונעת צווארי בקבוק. כשכל החלטה עוברת דרך ליד אחד, הליד הופך לצוואר בקבוק. התמחות פירושה שהחלטות יכולות להתקבל במקביל. Data סוקר קוד. Worf סוקרת אבטחה. B’Elanna סוקרת תשתית. הכל בו-זמנית. בלי המתנה.
5. תנו למכונה לזכור. אתם תטפלו בשיקול דעת. אתם מביאים הקשר ושיקול דעת. אתם מחליטים על כיוון. תנו ל-AI לזכור משימות, לעקוב אחרי התקדמות, לזהות דפוסים, לצפות בתור, למזג PRs, לטפל בטקסים. השותפות הזאת היא מקור הפרודוקטיביות: שיקול דעת אנושי + זיכרון מכונה.
איך להתחיל
אם אתם טובעים ברשימות משימות והתראות:
- הגדירו תפקידים. כתבו charters לכל חבר צוות או סוכן. היו ספציפיים לגבי גבולות תחום.
- השתמשו ב-GitHub issues להחלטות. הכל במקום אחד. הקשר מלא. ניתן לחיפוש.
- תאטמטו את התצפית. מה שזה לא יהיה ה-“Ralph” שלכם (בדיקה מתוזמנת, worker ברקע, בוט), הוא צריך לרוץ ללא התערבות אנושית.
- תתעדו החלטות בקובץ אחד. מקור אמת יחיד. קראו אותו לפני שמתחילים לעבוד.
- תנו לעבודה אסינכרונית לקרות. אל תחכו לפגישות. Issues ותגובות — ככה עושים את זה.
זה לא בהכרח קשור ל-AI ספציפית. צוות של בני אדם יכול לעשות בדיוק את אותו הדבר עם בדיוק אותו מבנה. ההבדל הוא שסוכני AI לא צריכים חופשה, לא שוכחים, ולא צריכים כוח רצון. אבל עיצוב המערכת — התמחות, תהליכים אסינכרוניים, החלטות מתועדות, תצפית רציפה — עובד לכל צוות.
התוצאה
סוף סוף מצאתי מערכת פרודוקטיביות שעובדת. לא כי היא מושלמת. אלא כי היא לא צריכה שאני אהיה.
במשך 20 שנה ניסיתי לייעל את עצמי: יותר משמעת, כלים טובים יותר, כוח רצון חזק יותר. שום דבר לא החזיק. הבעיה לא הייתה הכלים. הבעיה הייתה ההנחה שאני יכול לשמור על מאמץ עקבי בכל ממד של פרויקט.
ואז הבנתי את התובנה האמיתית: תפסיקו לבקש מעצמכם לזכור. תבנו מערכות שלא דורשות זכירה.
Ralph צופה בתור. Scribe מתעד החלטות. Picard חושב על ארכיטקטורה. Worf תופסת בעיות אבטחה. Data סוקר קוד. Seven כותבת תיעוד ברור. Podcaster מייצר סיכומי אודיו. Neelix מזהה דפוסים חיצוניים. אני לא צריך לזכור שום דבר מזה.
אני פשוט מתעורר לצוות שעבד בזמן שישנתי. PRs מוזגו. החלטות תועדו. שיפורים הוצעו. עבודה הושלמה.
ככה מרגישה פרודוקטיביות כשהיא לא נלחמת באנטרופיה. לא נלחמת בך. פשוט עובדת.
זה לא קסם. זה עיצוב מערכות. גם אתם יכולים לעשות את זה.