אמ;לק

עבודה עם כלי AI כמו Cursor על פרויקטים קטנים זה קל. אבל מה קורה כשיש לכם Monorepo מורכב, ספריות משותפות וזמני קומפילציה ארוכים? בפוסט הזה אשתף איך עברתי משימוש בסיסי ל-Workflow היברידי שמשלב Git Worktrees, VS Code Workspace ושימוש חכם ב-Cursor Rules (״דמויות״) כדי לנהל פיתוח, דיזיין ומחקר במקביל בלי לאבד את הראש (או את הקונטקסט).

---

רקע: האתגר הארכיטקטוני

כדי להבין למה ה-Workflow הסטנדרטי נשבר אצלנו ב-Tufin, צריך להבין את הטופולוגיה של הקוד. אני מאמין שאין ״פתרון קסם״ אחד, וצורת העבודה חייבת להיגזר מהארכיטקטורה. אצלנו, הקוד מפוזר בעיקר על שני Repositories גדולים שמכילים את רוב הסרביסים וה-UI, ועוד מספר Repos קטנים שמחזיקים ספריות משותפות (Common Libraries).

המשמעות? פיצ׳ר אחד יכול לדרוש נגיעה בשלושה מקומות שונים, והקשרים ביניהם (Dependencies) הם קריטיים להבנה של המערכת

---

שלב 1: הגישה הנאיבית (וכישלונה)

בהתחלה, ניגשתי ל-Cursor כמו שניגשתי ל-IntelliJ כל השנים: פתחתי כל פרויקט בחלון נפרד. השקעתי לא מעט זמן בלנסות לגרות -Gradle לעבוד חלק בתוך ה-VS Code Engine (ספוילר: זו הייתה השקעה לחינם, ה-LSP של ג׳אווה שם עדיין לא ברמה של IntelliJ).

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

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

---

שלב 2: איחוד הכוחות (Workspaces )

הפתרון הראשון היה פיצ׳ר ותיק של VS Code שנקרא Multi-root Workspaces. בגדול, זה קובץ קונפיגורציה שאומר ל-ide: ״תתייחס לתיקיות X, Y ו-Z כאילו הן פרויקט אחד גדול״.

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

זמני הקומפיליציה אצלנו ארוכים (לפעמים 30 דקות ומעלה לבדיקה בסביבה). בעבר, הייתי עושה git clone נוסף לריפו בנתיב חדש כדי לעבוד על משהו אחר בזמן שהראשון מתקמפל. אבל לשכפל Repo ענק זה כבד, תופס מקום בדיסק ומסרבל את העבודה.

---

שלב 3: ה-Game Changer (Git Worktree & Personas)

כאן נכנסו לתמונה שני שינויים שהפכו את ה-Workflow שלי למכונה משומנת.

Git Worktree

במקום לשכפל את ה-Repo (פעולת Clone), אני משתמש ב-git worktree. זה מאפשר לי ליצור עותקים של תיקיית העבודה שמצביעים לאותו ה-Git Object Database, אבל נמצאים על Branch שונים. זה מהיר, ויעיל (רן בר-זיק כתב על זה פוסט מצוין, מומלץ לקרוא)

הסוד האמיתי - Cursor Rules & Personas

הבנתי שאני לא ״סתם מתכנת״. ביום עבודה אני מחליף כובעים: כותב קוד, מתכנן ארכיטקטורה (כותב High Level Design), עושה Code Review, או חוקר באגים. לכל אחד מהמצבים האלה יצרתי ״דמות״ בקרסר באמצעות קבצי .mdc בתיקיית .cursor/rules

הדמויות שלי כוללות:

• מתכנת: ממוקד בסינטקס, Clean Code, TDD וקונבנציות של Tufin.

• כתיבת software design: מתמקד בכתיבת מסמכים של software design שמיועדים למימוש על ידי agent אחרים.

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

• ה-Reviewer: מבצע code review

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

---

ה-workflow הנוכחי: הלכה למעשה

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

תהליך פיתוח פיצ׳ר מקצה לקצה:

1. שלב הדרישות: אני פותח את התיקייה הראשית ומפעיל את דמות החוקר. אני מזין לו את הדרישות מהפרודקט.

2. שלב הדיזיין: יש לנו ריפו שמיועד למסמכי דיזיין. אני מבקש מקרסר לייצר software design. היתרון הוא שהדיזיין נשמר, עובר pr על ידי מפתח אחר ובעתיד ישמש כקונטקסט ל-agent אחר שיפתח.

3. שלב הפיתוח:

   1. אני פותח git worktree חדש עבור הפיצ׳ר.

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

   3. אני נותן ל-agent את ה-design ואת המשימות, והוא מתחיל לממש אותן אחת-אחת.

למה agent בטרמינל?

זה משאיר את ה-ui הראשי שלי פנוי למחקר, בדיקות וניהול, בזמן שה-agents עובדים בטרמינלים נפרדים על Worktrees שונים.

---

סיכום ומסקנות

המעבר לעבודה עם AI בסקייל דורש שינוי מחשבתי. זה כבר לא רק ״השלמה אוטומטית חכמה״, אלא ניהול של Context ו-Agent.

היתרונות:

• יכולת להריץ מספר פרויקטים במקביל בצורה יעילה

• הפרדה ברורה בין ״חשיבה/תכנון״ לבין ״כתיבת קוד״

• תיעוד חי ונושם שמשמש גם בני אדם וגם את ה-AI.

חסרונות:

• דורש משמעת קונטקסט גבוהה. קל מאוד להתבלבל בין ה-Worktrees אם לא עובדים מסודר.

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