צוות Agents בנה לי מוצר עובד. אני בקושי נגעתי בקוד.

תזכורת קצרה - מאיפה באנו

בפוסט הקודם סיפרתי איך תכננתי חברת AI-First מדומה עם מוצר אמיתי - BridgeBoard, שמחבר בין Sales ל-Engineering ומראה כמה הכנסה בסיכון בגלל פערים ב-Roadmap. עברנו על ארבעה שלבים של תכנון: תכנון הניסוי עצמו, בניית PRD בשיח, ארכיטקטורה עם שיקולי AI-First, וחלוקת עבודה ל-Agent Teams.

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

עכשיו? הגיע הזמן לבנות.

הרגע שהצוות מתחיל לרוץ

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

פתחתי את Claude Code ונתתי לו את כל ה-Context - PRD, ארכיטקטורה, Work Tracks. ואז ביקשתי ממנו לייצר צוות עבודה. מה שקרה אחר כך הפתיע אותי.

Claude Code בחר מעצמו לעבוד עם Agent Teams - כלומר לפצל את העבודה בין כמה Agents שרצים במקביל. הוא לא חיכה שאגיד לו לעשות את זה. הוא ראה את מסמך ה-Work Tracks, הבין את החלוקה לשלושה Tracks (Backend, Frontend, Tests) ופשוט התחיל לארגן.

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

איך בניתי את הצוות בפועל

Context משותף - Agent-Context.md

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

קובץ Markdown לכל Agent

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

פשוט אמרתי ל-Claude Code: ״תייצר צוות, לכל אחד יש הנחיות ברורות ויש Context משותף.״ ומלבד כמה רגעים שהוא עצר לשאול אותי שאלות על תלויות או תכנון - הכל רץ.

מה קרה כשהם רצו לבד

בואו נדבר על מה שבאמת מעניין - מה עבד ומה לא.

מה עבד

Work Planning שווה זהב. מכיוון שהיה תכנון מראש עם הנחיות ברורות לעבוד עם כמה שפחות תלויות, הצוות יכול היה לעבוד במקביל בלי להתנגש. הם שיתפו Context אבל לא חיכו אחד לשני. זה בדיוק מה שתכננתי בשלב ה-Work Tracks - ועכשיו ראיתי את זה קורה בפועל.

הנחיות מפורטות = תוצר מדויק יותר. כל Agent ידע בדיוק מה לעשות. לא היה "תבנה לי בקאנד" סתם - היה "תבנה Route X עם Schema Y לפי הארכיטקטורה שב-Context." ברגע שהמשימות מפורטות ברמה שמשאירה פחות מקום לפרשנות, התוצר חוזר מדויק יותר. וזה גם חוסך טוקנים כי ה-Agent מבזבז פחות זמן על ניחושים.

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

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

מה פחות עבד

שימוש גבוה בטוקנים. כשעובדים עם Agent Teams, השימוש בטוקנים גבוה משמעותית (פי כמה!). כל Agent צורך Context בנפרד, וה-Orchestrator (ראש הצוות) צורך עוד על התיאום ביניהם. בדיעבד, אם הייתי משקיע עוד שעה בהתחלה בהכנת Claude.md, Skills ו-Hooks - כנראה הייתי חוסך הרבה מאוד טוקנים בהמשך.

Claude בחר Skills בעצמו. נתתי ל-Agents הגדרות מדויקות על מה לעשות, אבל לא הגדרתי לקלוד קוד עצמו אילו Skills להשתמש. הוא בחר מה שנראה לו נכון - ולא תמיד זה מה שהייתי בוחר. למשל, אם הייתי מגדיר מראש Skills של React ו-Node שמתאימות לסביבת Vercel, ייתכן שהקוד שנוצר היה מותאם טוב יותר מההתחלה.

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

אחרי שהצוות סיים - מה יש על הרצפה?

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

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

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

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

הלקח של הסטארטאפ - למה חשוב לעצור ולהשקיע

אפשר לטעון שבשביל לרוץ מהר ולא להתעכב, דילגתי על דברים כמו Claude.md, Skills, Hooks ו-MCP Tools - וזה נכון. זה היה הרעיון: ניסוי מהיר, להרגיש מה חסר.

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

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

שורות תחתונות

1. תכנון מפורט = צוות Agent שרץ חלק

ה-Work Tracks, ה-Shared Context, הגדרות ברורות לכל Agent - כל זה יחד אפשר לצוות לרוץ במקביל בלי שאני אצטרך להתערב בכל רגע. ההשקעה בשלב הקודם (תכנון) החזירה את עצמה ביום הזה.

2. Agent Teams לא מושלמים - וזה בסדר

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

3. Agent של טסטים = QA Agent שעובד 24/7

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

4. התפקיד שלך משתנה - ולא מפסיק להיות חשוב

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

5. חובות טכניים קיימים גם בעולם AI-First

דילגתי על Claude.md, Skills ו-Hooks. שילמתי על זה בטוקנים ובדיוק. בדיוק כמו חברה שדוחה Technical Debt כי "אין זמן" - ואז משלמת אחרי כן פי עשר.

מה הלאה?

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

Deploy - צריך להעלות את המוצר. המחשבה שלי היא Vercel כי אני כבר מכיר את הסביבה, עם Supabase לדאטהבייס. ושם כבר יש שאלה חדשה: האם לבחור פלטפורמת Deploy מראש היה חוסך לי בעיות?

צוות Reviewers - לפני שממשיכים להוסיף פיצ׳רים, אני רוצה להריץ סבב של Sub-agents מתמחים: Security Agent, Performance Agent, Test Coverage Agent ו-Code Quality Agent. כולם יעבדו כ-Reviewers, יוציאו ממצאים, ואני אחליט מה חשוב ומה ממתין. זו גישה שבחברה קלאסית דורשת כמה אנשים עם מומחיות שונה - כאן אפשר להריץ את כולם במקביל.

PR ו-Code Review - לראות מה אני כ-Human ארצה לבדוק בקוד, ומה Agent או כלי אחר יכול לעשות בשבילי. שאלה פתוחה שמעניינת אותי מאוד: כמה מהקוד באמת צריך לקרוא כשהוא נוצר על ידי AI? אנחנו צריכים לבחור בין 100% ביקורת לבין אמון בכלים עם טסטים טובים - ואני עדיין מגבש את הגישה שלי לזה.

תסריטים אמיתיים - איש Sales שמגיע עם עסקה של 2M$ ARR ולוחץ על פיצ׳ר שלא קיים, Incidents בפרודקשן שצריך לטפל בהם, טיקטים מ-Support, בקשות מפרודקט. בדיוק כמו חברה אמיתית שרצה ומגלה שהעולם האמיתי מתנהג אחרת ממה שתכנן.

דברים שהייתי עושה אחרת (רטרו יום 2)

Claude.md מוכן לפני שמתחילים לבנות. זה כבר הפעם השנייה שאני כותב את זה. בסבב הבא זה קורה ראשון.

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

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

MCP Tools. לא התייחסתי לזה כדרישה כי רציתי לרוץ מהר, אבל MCP כבר סטנדרט. שווה לבדוק מה קיים ולהכניס את זה בשיקולים מההתחלה.

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

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

הפוסט הזה הוא חלק מסדרת ניסוי AI-First Company שאני מריץ ומתעד תוך כדי תנועה. הפוסט הקודם - שלב התכנון. עוקבים אחריי כאן וב-chenfeldman.io לפירוט מלא - בעברית שיהיה הכי נגיש שיש.