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

כשקלוד בנה לי צוות: מה למדתי על ניהול מעבודה עם Agent Teams

8 בבוקר. הורדתי את לביא הבן הגדול שלי לבית הספר, שתיתי את הקפה הראשון של היום, ונכנסתי לחדר עם מטרה ברורה: להתנסות בפעם הראשונה עם הפיצ׳ר החדש של Claude תחת Opus 4.6 שמאפשר לבנות צוותים של אייג׳נטים.

מה שלא ידעתי זה שבשלוש השעות הבאות אני אלמד על כמה זה דומה לניהול צוותים אמיתי ואיך זה הולך לשנות את איך שמנהלים בעולם החדש בעידן הAI.

הניסוי: לבנות את אותו הדבר שלוש פעמים (עם יכולות שונות)

ההחלטה הייתה פשוטה: לבנות landing page למוצר SaaS דמיוני בשם "FlowState" - כלי לניהול פרויקטים לצוותים מבוזרים. אבל לבנות את זה שלוש פעמים:

v1: Single agent

v2: צוות של 5 ללא תכנון מוקדם

v3: צוות של 6 עם תכנון, סטנדרטים, ו-delegation מדויקת

הגדרת צוות ב-Claude Code עובדת דרך פרומפטים בשפה טבעית - מתארים את הצוות הרצוי וקלוד בונה אותו. אבל רציתי משהו יותר מובנה וחזיר, אז בניתי תבנית עבודה משלי: קובץ בפורמט ג׳ייסון שמגדיר את כל מבנה הצוות, בשילוב עם הוראות בקובץ ההגדרות של הפרויקט שמתרגמות את ההגדרה להתנהגות אמיתית של האייג׳נטים. לדוגמה - כש-plan_mode מוגדר כתמיד דלוק, כל אייג׳נט מתחיל במצב plan. כש-hook מוגדר עם טקסט שרץ לפני משימה, הוא מתווסף לפרומפט של כל אייג׳נט. ורמות ה-delegation שולטות בכמה עצמאות כל אחד מקבל. חשוב להדגיש - זה לא פיצ׳ר מובנה של קלוד קוד. זו שכבת הפשטה שבניתי מעליו. אם תרצו להשתמש בזה, תצטרכו גם את קובץ ההגדרות וגם את ההוראות המתאימות בקובץ הפרויקט (הכל זמין בריפו).

ככה זה נראה ברמת הסקשן להוספה ב-Claude.md

## Team Config (team.json)

When a team.json file exists, treat it as an executable spec:

- **plan_mode: "always"** → spawn every agent with `mode: "plan"`
  and approve their plans before they implement
- **hooks.before_task** → prepend this text to every agent's prompt
- **hooks.quality_standards** → append this to every agent's prompt
- **delegation: "none"** → use `mode: "plan"` (must get approval)
- **delegation: "limited"** → use `mode: "default"`
- **delegation: "moderate"** → use `mode: "acceptEdits"`

{
"plan_mode": "always",
"hooks": {
  "before_task": "Before starting, research 3 successful SaaS landing pages (like Notion, Linear, or Asana). Identify: (1) How they position their value prop, (2) What social proof they use, (3) How they structure their features, (4) Their CTA strategy",
  "quality_standards": "Every page MUST have: (1) Clear value proposition above the fold, (2) At least one specific metric or proof point, (3) Mobile-responsive design, (4) Semantic HTML with proper headings, (5) At least one compelling CTA that creates urgency"
},
"agents": [
  {
    "name": "market_researcher",
    "role": "Research competitor landing pages and document winning patterns for remote team tools",
    "delegation": "none"
  },
  {
    "name": "product_strategist",
    "role": "Use research insights to define positioning that differentiates FlowState",
    "delegation": "limited"
  },
  {
    "name": "conversion_copywriter",
    "role": "Write copy based on research findings, using proven patterns but with unique voice",
    "delegation": "none"
  },
  {
    "name": "ui_designer",
    "role": "Design layout informed by what works on competitor pages, adapted for FlowState brand",
    "delegation": "limited"
  },
  {
    "name": "frontend_developer",
    "role": "Implement with attention to quality standards: semantic HTML, accessibility, performance",
    "delegation": "moderate"
  },
  {
    "name": "qa_specialist",
    "role": "Review final output against quality standards, test on multiple devices, verify all requirements met",
    "delegation": "moderate"
  }
]
}

v1: הגישה הנאיבית

זמן: 3 דקות | תוצאה: דף נחמד, copy גנרי

הבעיה? הדף לא באמת דיבר לעומק לקהל היעד. הכאב האמיתי של צוותים מבוזרים (timezones, async communication) - לא היה שם מספיק. כמו לבקש ממפתח junior לבנות פיצ׳ר בלי context ובלי הנחיה מתאימה. זה נראה טוב ומהיר אבל שצריכים להחליט אם מתאים לפרודקשן צריך עוד עבודה והכוונה (מכירים את חוק ה80/20 הידוע?)

לפני שנעבור לצוותים שווה שנבין נקודה קטנה.

כאן עבדתי עם Teams אבל יש יכולת קיימת להפעיל Sub-Agents לפני המודל Opus 4.6 שיש מקרים שבהם היא גם רלבנטים ככה שכרגע בעיקר שווה לציין אותה.

🔍 Sub-Agents vs Teams - כמה הבדלים?

למה זה משנה? צוות טוב הוא לא רק "אנשים שמבצעים הוראות". זה אנשים שמדברים ביניהם, רואים את התמונה הרחבה, ולוקחים ownership.

v2: הכאוס המאורגן

הוספתי צוות עם roles מוגדרים:

{
"agents": [
  {"name": "product_strategist", "role": "Define value prop and differentiation"},
  {"name": "copywriter", "role": "Write conversion-focused copy"},
  {"name": "ui_designer", "role": "Design layout and hierarchy"},
  {"name": "frontend_developer", "role": "Build clean HTML/CSS"}
]
}

זמן: 12 דקות | תוצאה: הרבה יותר טוב, אבל...

הנה מה שעשוי לקרות וקצת קרה בתהליך גם:

[product_strategist → copywriter]
"המסר צריך להיות על async communication"

[copywriter → ui_designer]
"כתבתי copy על collaboration בזמן אמיתי"

[ui_designer → developer]
"עיצבתי hero עם וידאו של video call"

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

זה בדיוק מה שקורה בצוותים אמיתיים ללא alignment ברור והנחיה.

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

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

v3: הגילוי

הוספתי שלושה דברים קריטיים:

1. Plan Mode - תכנון לפני ביצוע

{
"plan_mode": "always"
}

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

## Target Audience
- Distributed teams (5+ members)
- Pain: timezone coordination, async communication

## Differentiation
Focus on async-first workflow (not real-time collaboration)

## Positioning
"The project management tool that works when your team doesn't"

כל agent קרא את זה לפני שהתחיל. אין יותר miscommunication.

2. Hooks - הסטנדרטים שלא מתפשרים עליהם

Hooks הם בעצם "נקודות התערבות" שמאפשרות לך להגדיר מה קורה בשלבים קריטיים בעבודת הצוות - לפני שמתחילים משימה (before_task) או איך לבדוק איכות (quality_standards). זה כמו להגיד "לפני שאתה כותב קוד, תעשה code review על עצמך" או "כל PR חייב לעבור 2 reviewers".

{
"hooks": {
  "before_task": "Research 3 successful SaaS landing pages (Notion, Linear, Asana)",
  "quality_standards": "MUST have: value prop above fold, specific metrics, mobile-responsive, semantic HTML, compelling CTA"
}
}

למה זה עובד?

הresearcher יצר דוח ניתוח מתחרים. הcopywriter השתמש בpatterns שעובדים (לא המציא מהראש). הQA בדק שכל סטנדרט התקיים ואם גילה משהו הר״צ ביקש מאיש הצוות המתאים שיתקן או תכנן אם כדאי.

בדיוק כמו code review guidelines או definition of done בצוות אמיתי.

3. Delegation Levels - מי צריך עצמאות?

Delegation קובעת עד כמה agent יכול "לשכור עוזרים" כדי לפרק משימות גדולות לקטנות. רמות: none (עובד לבד), limited (יכול לבקש עזרה מינימלית), moderate (יכול לפרק משימות באופן משמעותי). זה כמו להחליט מי בצוות יכול להקים task force זמני ומי צריך לעבוד focused.

לא כל agent צריך אותה רמת עצמאות:

מה זה נותן בפועל?

המפתח פירק את העבודה שלו:

[frontend_developer creates subtasks]
├─ Build HTML structure
├─ Implement responsive CSS
├─ Run accessibility audit
└─ Optimize performance

הcopywriter עבד ברצף אחד - כי פיצול יגרום ל-5 סגנונות שונים.

4. העברת מידע ותוצרים - אפשר לקרוא לזה בעצם תקשורת בריאה ותיעוד

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

למה זה חכם?

1. Async collaboration אמיתי - agents אחרים קוראים את הקבצים כשצריך, לא צריכים להיות "אונליין" ביחד.

2. Context control - המעצב קורא רק את התכנון האסטרטגי והcopy, לא צריך לעבור על כל המחקר המפורט.

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

4. Documentation by default - בסוף יש לך לא רק landing page, אלא גם את כל תהליך החשיבה והבחירות שנעשו בדרך.

זה בדיוק איך צוותים טובים עובדים: לא הכל בצ'אט. יש RFCs, design docs, decision logs שנשארים לאורך זמן.

התוצאה

זמן: 29 דקות | איכות: 🚀

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

כלים נוספים שכדאי להכיר

Skills — מומחיויות ספציפיות לכל אייג׳נט

Skills בקלוד קוד הם קבצי מארקדאון שנמצאים בתיקיית הפרויקט תחת claude/skills/ וכל אחד מהם מכיל ידע מקצועי לתחום מסוים. העיקרון שעומד מאחוריהם הוא progressive disclosure — קלוד טוען בהתחלה רק את השם והתיאור של כל skill, ורק כשמשימה רלוונטית מגיעה, הוא קורא את ההוראות המלאות. ככה אפשר להתקין עשרות skills בלי לבזבז context.

למה זה חשוב?

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

• אייג׳נט שכותב קופי ← skill עם קווים מנחים למותג, טון דיבור, ודוגמאות של כתיבה טובה
• אייג׳נט שבונה פרונטאנד ← skill עם ה-design system, קונבנציות קוד, ודרישות נגישות
• אייג׳נט שעושה ריסרץ׳ ← skill עם הנחיות איך לתעד ממצאים ובאיזה פורמט

דוגמה לקובץ skill:

---
name: brand-copywriter
description: Writes conversion-focused copy following FlowState brand guidelines
allowed-tools: Read, Grep, Write
---

# FlowState Brand Copy Guidelines

## Tone
- Direct, clear, no jargon
- Focus on async-first messaging

## Structure
- Value prop above the fold
- Every headline must address a specific pain point
- CTAs create urgency without pressure

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

Claude.md - ה-Team Playbook

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

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

# FlowState Engineering Team Standards

## Code Quality Non-Negotiables
- Every function/component must have a single, clear responsibility
- No file over 250 lines - if longer, refactor
- All user-facing text goes through i18n, even if we only support English today
- Performance budget: TTI < 3s on 3G, Lighthouse > 90

## Security Gates
- Never commit API keys, tokens, or secrets (use env vars)
- All user input must be sanitized before DB/display
- Authentication checks on every protected route
- Dependencies: run npm audit before every PR

## Team Config (team.json)
When a team.json file exists, treat it as an executable spec:

- **plan_mode: "always"** → spawn every agent with `mode: "plan"`
  and approve their plans before they implement
- **hooks.before_task** → prepend this text to every agent's prompt
- **hooks.quality_standards** → append this to every agent's prompt
- **delegation: "none"** → use `mode: "plan"` (must get approval)
- **delegation: "limited"** → use `mode: "default"`
- **delegation: "moderate"** → use `mode: "acceptEdits"`

## Collaboration Protocols
- Breaking changes? Create RFC document first, get 2+ team approvals
- Stuck for >2 hours? Post in #engineering-help with context
- Found a bug? Create ticket immediately, don't "fix it quick"
- Deploying? Announce in #releases with rollback plan

## Documentation Requirement
- Every new feature needs: README update, API docs (if applicable), changelog entry
- Complex logic? Inline comments explaining "why", not "what"
- Architecture decisions? Add to /docs/decisions with rationale

## Testing Standards
- Unit tests: Cover edge cases, not just happy path
- Integration tests: Test actual user workflows
- E2E tests: Critical paths only (login, checkout, etc.)
- Before pushing: All tests green + lint passes

ההבדל:

• Hooks = ספציפי למשימה ("מה לעשות לפני task X")
• Claude.md = תרבות כללית ("איך אנחנו עובדים תמיד")

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

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

מתי לא להשתמש ב-Teams?

Single Agent עדיף כש:

1. משימות עם scope ברור ומוגדר היטב

✅ Single: "הוסף validation לשדה email בטופס ההרשמה"
❌ Teams: "שפר את חוויית ההרשמה" (רחב מדי, צריך פרספקטיבות שונות)

2. עבודה חקרנית/איטרטיבית שדורשת feedback loops

✅ Single: "בוא נבדוק ביחד למה הבאג הזה קורה" (צריך אינטראקציה)
❌ Teams: "תחקור את הבאג, תתקן, ותכתוב post-mortem" (מוגדר, יכול לעבוד עם צוות)

3. כשהתקציב של tokens קריטי

Teams צורכים הרבה יותר tokens מ-single agent — אם התקציב קריטי, עדיף single agent.

4. משימות שדורשות "קול אחד" עקבי

✅ Single: כתיבת אימייל, מכתב, blog post קצר (צריך tone עקבי)
❌ Teams: כתיבת whitepaper ארוך (צריך research, writing, editing, review)

5. כשהמשימה פשוטה אבל דורשת context רב

✅ Single: "תסכם את ה-30 עמודים האלה לנקודות עיקריות" → Agent אחד קורא הכל, מסכם
❌ Teams: פיצול ל-3 readers יגרום לפספוס connections בין עמודים

Sub-Agents עדיף כש:

דוגמאות קונקרטיות:

Sub-Agents מתאים:

"כתוב לי מאמר על Kubernetes. תחקור בGoogle אם צריך נתונים עדכניים"
→ Agent ראשי כותב, קורא ל-sub לחקור פרט ספציפי, ממשיך לכתוב

Teams מתאים:

"צור מדריך מקיף על Kubernetes: מחקר, כתיבה, דיאגרמות, code examples, review טכני"
→ Researcher, Writer, Designer, Code-reviewer עובדים ביחד עם handoffs

מתי Teams הוא must?

צריך Teams כשיש:

1. מספר domains של expertise שאי אפשר לצמצם לאחד

• דוגמה: פרויקט שצריך גם backend, גם frontend, גם UX, גם security review

2. צורך בהפרדת context (כל agent צריך "ראש נפרד")

• דוגמה: Data analyst שקורא CSVs גדולים + copywriter שכותב marketing copy
• אם זה agent אחד, ה-CSV "יזהם" את ה-context של הכתיבה

3. Quality gates מרובים

• דוגמה: code → security review → accessibility check → legal compliance
• צריך שכל reviewer יראה רק את החלק שלו, לא את כל ההיסטוריה

4. משימות עם dependencies מורכבות

• דוגמה: "לא מתחילים לכתוב קוד עד שהעיצוב מאושר"
• Teams יכול לאכוף זאת עם planning + hooks

עץ החלטות שאפשר לשדרג ויכול לעזור להחליט כהתחלה

משימה פשוטה עם תשובה ברורה?
├─ כן → Single Agent
└─ לא → צריך מספר expertise areas?
  ├─ לא → Single Agent
  └─ כן → חד-פעמית או מתמשכת?
      ├─ חד-פעמית → Sub-Agents
      └─ מתמשכת → Teams
          └─ מורכב/לא ברור? → Teams + plan_mode
              └─ צריך standards? → + hooks
                  └─ צריך פירוק משימות? → + delegation

הלקח האמיתי

הדבר הכי מעניין: הדילמות של Agent Teams זהות לדילמות של ניהול צוותים אנושיים.

השאלות שכל מנהל שואל:

• כמה אנשים צריך? (יותר מדי = overhead, פחות מדי = burnout)
• מתי לתכנן ומתי לזוז? (תכנון מדי = paralysis, בלי = rework)
• כמה עצמאות לתת? (Senior = high, Junior = limited, Creative = low)
• איך לבנות תרבות? (Hooks = process, Claude.md = values)

אם אתם מתקשים עם האיזונים האלה - אתם לא לבד.

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

זה לא "בעיה של בני אדם". זה בעיה של ניהול מערכות מורכבות.

איך אתם יכולים להתחיל ״מחר בבוקר״?

קחו 5 דקות עם הקפה של הבוקר או התה של הלילה

# 1. התקינו Claude Code
# 2. הפעילו experimental teams בsettings.json
# 3. עשו Claim ל-$50 credits

15 דקות - התחילו פשוט:

{
"agents": [
  {"name": "researcher", "role": "Gather information"},
  {"name": "writer", "role": "Write based on research"}
]
}

אחר כך: הוסיפו plan_mode, hooks, delegation בהדרגה.

דוגמאות מלאות + templates ב-repo שלי של הצוותים שבניתי.

מחשבה אחרונה

התחלתי עם סקרנות טכנית: "בואו נראה איך Teams עובד"

סיימתי עם insight על ניהול: Good leadership isn't about being smart. It's about enabling others to be smart.

ואם זה נכון עבור Agents, זה בטח נכון עבור בני אדם.

שאתם בונים צוותים אתם צריכים לבנות אותם נכון למשימה וגם לחזון כי המשימה משתנה לעתים, אז למה שאתם בונים צוותי אייג׳נטים זה אמור להשתנות?

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

רוצים לשלב AI בארגון שלכם - נכון?

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

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

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

לא מוכר מוצרים. לא מציע "פתרונות קסם".

במקום זה - עובד ביחד עם הצוות שלכם:

• להבין את האתגרים הספציפיים שלכם והבעיות האמיתיות שיש לכם
• לנסות בסביבה בטוחה ומבוקרת (כמו שעשיתי כאן)
• ללמד את הצוות איך לחשוב על AI כעל teammate, לא כעל תחליף כדי להגביר את הVelocity
• לבנות workflows ו-best practices שמשתלבים עם הדרך שבה אתם עובדים היום

אם אתם:

• 👨‍💼 CTO/VP R&D/Director שרוצה להבין איך להוביל את המעבר ל-AI בארגון
• 👥 צוות פיתוח או מוצר שרוצה ללמוד איך להשתמש ב-AI בצורה אפקטיבית
• 🚀 חברה שרוצה ליישם AI אבל לא יודעת מאיפה להתחיל

בואו נדבר.

📧 chenfeldmn@gmail.com

💼 LinkedIn

נכתב בסיוע צוות של agents (כמובן 😄)

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