פרק 13: על הכנת סביבת הפיתוח

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

לכן הפרק הזה יהיה קצת יותר טכני, וגם קצת יותר ארוך מהרגיל.

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

וזה לא באג של הטכנולוגיה. זה באג של התהליך.

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

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

צעד 1: תכנון דרישות עם PRD — מוצרי, לא טכני

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

איך עושים את זה בפועל: פותחים סשן חדש ב-Claude Code ונותנים לו פרומפט כזה:

אני רוצה לבנות [תיאור קצר]. תראיין אותי לעומק באמצעות AskUserQuestion. תשאל על אימפלמנטציה טכנית, UI/UX, edge cases, חששות ו-tradeoffs. אל תשאל שאלות ברורות מאליהן, תחפור בחלקים הקשים שאולי לא חשבתי עליהם. תמשיך לראיין עד שכיסינו הכל, ואז תכתוב SPEC מלא ל-docs/PRD.md.

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

למה חשוב שהתכנון יהיה ממוקד מוצר ולא טכני: המודלים החדשים כבר מספיק חזקים כדי לפתור את הצד הטכני לבד. מה שהם לא יכולים לפתור לבד זה את השאלה של מה בדיוק אתם בונים ולמה. מחקר של Stack Overflow מ-2025 מראה שכמעט שני שלישים מהמפתחים מתוסכלים מפתרונות AI שהם "כמעט נכונים אבל לא ממש" — וזו בעיה של ספציפיקציה ולא של יכולת.

צעד 2: הגדרת CLAUDE.md

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

איך עושים את זה בפועל: יוצרים קובץ CLAUDE.md בשורש הפרויקט, באותיות גדולות. בתוכו מקשרים קבצים עם תחביר @, למשל: @docs/PRD.md לדרישות, @docs/constraints.md לאילוצים שליליים. מוסיפים את הדברים שהאייג׳נט לא יכול לדעת לבד: קונבנציות קוד, פקודות build ו-test, סגנון כתיבה, כללי עבודה ספציפיים לפרויקט. לא יוצרים אותו עם /init — כי הפקודה מייצרת קובץ שמתאר את מה שכבר קיים, ולא את מה שהאייג׳נט צריך לדעת כדי לא לטעות.

הכלל שבוריס טיין, היוצר של Claude Code, עובד לפיו: כל פעם שהאייג׳נט עושה משהו לא נכון, מוסיפים כלל ל-CLAUDE.md שמונע את אותה טעות בפעם הבאה. הקובץ מתעדכן כמה פעמים בשבוע ונכנס ל-git כדי שכל הצוות נהנה ממנו.

נקודה קריטית: למודלים יש תקרה של בערך 150 עד 200 הנחיות שהם יכולים לעקוב אחריהן, וסיסטם פרומפט של Claude Code כבר תופס כ-50. נשאר מקום לעוד 100 עד 150 לפני שהאיכות יורדת. הקובץ של בוריס עצמו הוא רק כ-100 שורות — ועובד טוב יותר מרוב הקבצים של 800 שורות שאנשים כותבים. כל שורה צריכה להצדיק את קיומה.

צעד 3: חיבור סקילז, אייג׳נטים ו-MCP

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

MCPs — חיבורים לשירותים חיצוניים: Supabase לבקאנד, Playwright לטסטים ויזואליים, shadcn/ui לקומפוננטות. מריצים את פקודות ההתקנה ומוודאים שהכל מחובר לפני שמתחילים.

אייג׳נטים — סוכנים עם חלון קונטקסט עצמאי: יוצרים קבצי markdown בתיקיית .claude/agents/. אייג׳נט קומיטים לגיט מסודר עם pre-checks, אייג׳נט ריפקטורינג, אייג׳נט code review, אייג׳נט וריפיקציה שמשתמש ב-Playwright לבדוק UI.

נקודה חשובה: התוכן בקבצי האייג׳נטים הוא system prompt שמגדיר את ההתנהגות של הסוכן — לא user prompt שאומר לו מה לעשות. זו הטעות הנפוצה ביותר.

סקילז — ידע מתמחה שנטען לפי דרישה: קבצי markdown בתיקיית .claude/skills/ שנטענים אוטומטית כשהמשימה רלוונטית. בניגוד ל-CLAUDE.md שנטען בכל סשן, סקילז נטענים רק כשצריך אותם, מה ששומר על הקונטקסט רזה. למשל, סקיל front-end שמגדיר קונבנציות לקומפוננטות, או סקיל TDD שמגדיר את תהליך ה-red-green-refactor.

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

צעד 4: אילוצים שליליים

אייג׳נטים מוטים לפעולה. אם לא אמרתם להם מה לא לעשות, הם ימלאו את הפער בעצמם.

למה זה קריטי: מחקר שפורסם לאחרונה מראה ש-60% מהמקרים דורשים תיקון בסביבות מורכבות בלי אילוצים שליליים. תופעה שנקראת Eager Editor מתארת איך אייג׳נט שקיבל משימה של תיקון סגנון אחד חזר עם 52 קבצי SVG מעודכנים שאף אחד לא ביקש. ותופעה נוספת שנקראת Pattern Breaker מראה שגם כשהאייג׳נט רואה קבצים סמוכים כרפרנס, הוא עלול להמציא מבנים חדשים במקום לשמור על הארכיטקטורה הקיימת.

איך עושים את זה בפועל: יוצרים קובץ docs/constraints.md ומקשרים אותו מ-CLAUDE.md עם @docs/constraints.md. בקובץ כותבים מה לא לעשות — ולכל אילוץ מוסיפים את החלופה. לא רק "אל תשתמש ב-localStorage", אלא "אל תשתמש ב-localStorage, השתמש ב-httpOnly cookies במקום". אילוצים בלי חלופה גורמים לאייג׳נט להיתקע.

צעד 5: כתיבת טסטים לפני פיתוח

טעות קלאסית שכמעט כולם עושים: כותבים טסטים רק אחרי שהפיצ׳רים מוכנים. אם האייג׳נט כותב טסטים אחרי הפיתוח, הוא מייעל אותם למה שנבנה בפועל — ולא למה שהיה צריך להיבנות לפי ה-PRD.

איך עושים את זה בפועל: בסשן נפרד לפני שמתחילים פיתוח, מבקשים מהאייג׳נט לקרוא את ה-PRD ולכתוב טסטים על בסיס הדרישות בלבד. זה reverse engineering של הפונקציונליות מתוך המסמך. הגישה של Superpowers (שבסוף הפרק) עושה את זה באופן מובנה עם TDD מלא של red-green-refactor: הטסט חייב להיכשל לפני שכותבים אימפלמנטציה. אחרי שהפיתוח מסתיים, מריצים את הטסטים כדי לוודא שהאימפלמנטציה עומדת בדרישות — ולא רק עובדת.

צעד 6: תכנית אימפלמנטציה מפורטת

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

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

למה זה כל כך חשוב: מחקר מראה שמצב הכישלון הכי יקר בפיתוח עם AI הוא לא syntax שבור או לוגיקה רעה — אלא אימפלמנטציה שעובדת בבידוד אבל שוברת את המערכת הקיימת. פונקציה שמתעלמת משכבת cache שכבר קיימת, מיגרציה שלא מתחשבת בקונבנציות ה-ORM, endpoint שמשכפל לוגיקה שכבר קיימת. שלב התכנון מונע את כל זה.

צעד 7: ביצוע עם מעקב התקדמות ולמידה

עכשיו שיש PRD, CLAUDE.md, טסטים ותכנית מאושרת — מתחילים לבנות. אבל גם כאן צריך מנגנוני מעקב.

קובצי התקדמות ולמידה: יוצרים progress.md שהאייג׳נט מעדכן אחרי כל שלב (מה הושלם, מה נשאר), ו-learnings.md שבו הוא מתעד טעויות, מה גרם להן ואיך תיקן. מוסיפים ב-CLAUDE.md הנחיה מפורשת שהאייג׳נט חייב לעדכן את שני הקבצים אחרי כל משימה. בלי ההנחיה הזו, הוא פשוט לא יעשה את זה.

git מסודר: מגדירים שהאייג׳נט עושה קומיט אחרי כל שלב עם הודעות conventional commits מפורטות. ככה יש היסטוריה נקייה ואפשר לעשות revert אם משהו נשבר. בוריס מריץ 10-15 סשנים במקביל, כל אחד על git worktree נפרד, ככה שינויים לא מתנגשים.

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

הכלים שהופכים את Claude Code למפעל

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

בסיס של הבסיס

Everything Claude Code — מערכת שלמה של הגדרות מוכנות לפרודקשן: 47 סוכנים, 181 מיומנויות, 79 פקודות, הוקים, הגדרות MCP ו-14 קונפיגורציות שרת. יצא מהאקתון של Anthropic ועבר מעל 10 חודשים של שימוש יומיומי בבנייה של מוצרים אמיתיים. מתקינים כפלאגין ישירות: /plugin marketplace add affaan-m/everything-claude-code ואז /plugin install.

claude-code-best-practice — מדריך פרקטי לפקודות, סוכנים, הוקים, סקילז ו-workflows. בלי דיבורים מיותרים, מאורגן לפי קטגוריות עם דוגמאות של קוד מוכן. כולל גם תבניות לקומיטים מסודרים, review workflows, ותיעוד של מתי להשתמש במה.

מתודולוגיות פיתוח

Get Shit Done (GSD) — מערכת הנדסת קונטקסט ופיתוח מונחה ספציפיקציה. זה הרבה יותר מקבצי progress, זו מערכת שלמה שמנהלת את כל הוורקפלואו: מתכנון ועד ביצוע ועד וריפיקציה. מתקינים עם npx get-shit-done-cc --claude --local ומתחילים עם /gsd-init. המערכת כוללת quality gates מובנים שתופסים בעיות אמיתיות: גילוי schema drift שמזהה שינויים ב-ORM בלי מיגרציות, אכיפת אבטחה מעוגנת ב-threat models, וגילוי צמצום scope שמונע מהאייג׳נט לדלג בשקט על דרישות. כל plan הוא XML מובנה עם הוראות מדויקות ושלבי verify — לא ניחושים. GSD מתאים במיוחד למי שרוצה שהמורכבות תהיה במערכת ולא בוורקפלואו שלכם.

Superpowers — פריימוורק מתודולוגי שלם לפיתוח תוכנה עם אייג׳נטים. בניגוד ל-GSD שמתמקד בהנדסת קונטקסט, Superpowers מגדיר תהליך עבודה שלם שמופעל אוטומטית: ברגע שהאייג׳נט מזהה שאתם רוצים לבנות משהו, הוא לא קופץ לכתוב קוד. במקום זה, הוא עוצר ומתחיל brainstorming מובנה שבו הוא שואל אתכם מה אתם באמת מנסים לעשות. אחרי שאישרתם את העיצוב, הוא מייצר תכנית אימפלמנטציה ברמה שמתאימה ל"מפתח ג׳וניור נלהב עם טעם גרוע, בלי judgment, בלי הקשר של הפרויקט, ועם סלידה מטסטים" — ככה הם מתארים את זה. אז הוא מפעיל subagent-driven-development שבו כל משימה עוברת code review דו-שלבי: עמידה במפרט ואז איכות קוד. מתקינים עם /plugin install superpowers@claude-plugins-official. הסקילז מופעלים אוטומטית לפי הקשר: brainstorming לפני קוד, TDD כשמממשים פיצ׳רים, debugging שיטתי כשיש באגים.

זיכרון והקשר

Obsidian עם MCP — חיבור של Claude Code ל-vault של Obsidian דרך פלאגין MCP ייעודי. מתקינים את הפלאגין Obsidian Claude Code מתוך Community Plugins, והוא הופך את ה-vault לשרת MCP ש-Claude Code מגלה אוטומטית דרך WebSocket. האייג׳נט יכול לקרוא ולכתוב נוטים, לחפש לפי תגיות וקישורים, ולשלוף קונטקסט ממאגר ידע מרכזי שחי מחוץ לפרויקט. הכוח של Obsidian הוא שהידע חוצה פרויקטים — מה שלמדתם בפרויקט אחד זמין בהמשך, ויש גרף קשרים שמאפשר לאייג׳נט למצוא מידע רלוונטי גם כשהוא לא יודע בדיוק מה לחפש.

claude-mem — תוסף שמשפר את הזיכרון של Claude Code בין סשנים.

Karpathy-Inspired Guidelines — מערכת המלצות לניהול קונטקסט בהשראת Andrej Karpathy.

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

כלי עבודה

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

Prompt Engineering Guide — מדריך מלא ליצירת פרומפטים עבור Claude, עוזר להבין את ההבדל בין פרומפט שמוציא תוצאה בינונית לבין כזה שמוציא בדיוק מה שרצית.

אוספים וקטלוגים

Awesome Claude Code — ריכוז מסוקר של סקילז, הוקים, פלאגינים, אייג׳נטים וכלים. המקום הראשון לחפש בו כשצריכים משהו ספציפי.

Agent Skills by Anthropic — מאגר הסקילז הרשמי, כולל /simplify ל-code review, /batch לריפקטורינג מקבילי, /debug לניפוי שגיאות, /loop למוניטורינג.

Awesome Claude Code Subagents — יותר מ-100 סוכני משנה מוכנים למשימות ספציפיות, חוסך שעות של כתיבה ידנית.

Awesome DESIGN.md — מערכות עיצוב שחיות בתוך הפרויקט. הסוכן מייצר UI בסגנון Stripe, Notion או Linear — במקום הדיפולט הסגלגל שכולנו כבר מכירים.

לסיכום

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

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

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

והדמות שבחזית הפוסט יושבת מול חדר שלם של מסכים זוהרים — זה מה שסביבת פיתוח מוכנה מרגישה מבחוץ: רגוע, מסודר, וכל המסכים עובדים בשבילכם.

רוצים לא לפספס? הצטרפו לקהילת הבילדרים בווצאפ ועקבו אחרי סדרת "אני בונה אייג׳נטים".

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