עצרתי הכל באמצע כדי לבנות את ה-Operating System של חברת ה-AI-First. למה בעצם?

מה קרה שגרם לי לעצור

אחרי יומיים של בניית המוצר עם Claude Code, ישבתי לעשות רטרו עם עצמי. ראיתי דברים בשטח שלא אהבתי.

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

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

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

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

ההחלטה: יום Refactor לתשתיות העבודה

אינטואיטיבית, הרגשתי שזה לא הזמן לרוץ קדימה על הפיצ'ר הבא. כן, היו לי רעיונות מוכנים - כבר הכנתי בצד רשמים על ניסוי עם Sub-agents וגם יצירת Code Review אוטומטי עם API של Anthropic שעובר על PR-ים. אבל משהו לא הרגיש נכון.

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

אז מלבד הידיעה שלי שדברים כמו Claude.md, Skills, Hooks ו-Memory יתרמו לעבודה בהמשך, עשיתי עוד משהו: הרצתי את פקודת /insights ב-Claude Code. הפקודה הזו נותנת דו"ח תובנות על שימוש ב-Claude Code - מה עבד טוב, מה לא עבד מספיק טוב, והצעות קונקרטיות לשיפור.

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

שילבתי את המסקנות מהדו"ח של Claude Code ואת הרטרו שעשיתי על בסיס הידע שלי - ויצרתי יום נוסף לניסוי. יום Refactor שמטרתו לבנות אבני בסיס חזקות שיועילו בכל מה שיגיע אחר כך.

מה בנינו - ולמה כל חלק קיים

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

בואו נצלול לכל חלק.

Claude.md - ספר החוקים שתמיד פתוח

מה זה: קובץ Markdown ש-Claude קורא אוטומטית בתחילת כל סשן. לא צריך להקליד אותו כ-prompt - הוא שם תמיד כקונטקסט רקע.

שתי רמות:

ברמת הפרויקט ‏(/your-project/CLAUDE.md) - חוקים ספציפיים לפרויקט: סטאק הטכנולוגיות, חוזי API, מגבלות של Deploy, כללי ארגון Agents, סטנדרטים של קוד.

ברמה גלובלית ‏(~/.claude/CLAUDE.md) - העדפות שחוצות פרויקטים: סגנון העבודה שלי, העדפות תקשורת, שערי איכות, דברים ש-Claude לא אמור לעשות אף פעם.

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

מתי להשתמש: אם מצאתם את עצמכם מסבירים את אותו דבר שלוש פעמים - זה צריך להיות ב-Claude.md. "תשתמש ב-in-memory storage, לא PostgreSQL" - זה שם. "אף פעם אל תשתמש ב-TypeScript project references ב-Serverless" - גם.

Memory - הזיכרון שנשאר בין סשנים

מה זה: קובץ MEMORY.md שנשמר לוקאלית אצלכם (בתוך ~/.claude/projects/) ומחזיק ידע שנלמד מניסיון - דברים שהתגלו תוך כדי עבודה ושצריכים להשפיע על סשנים עתידיים. חשוב: Memory הוא לוקאלי ולא נכנס לריפו - זה הזיכרון האישי שלכם מהסשנים שלכם.

מה נכנס לשם: שיעורים מ-Deploy-ים ("NodeNext module resolution שובר את ה-bundler של Vercel - להשתמש ב-CommonJS"), דפוסי Agent שעבדו לעומת כאלה שנכשלו, Gotchas מוכרים והפתרונות שלהם, וסוג של Living Retro - לוג שרץ של הצלחות וכישלונות שמתעדכן אחרי סשנים משמעותיים.

מה ההבדל בין Claude.md ל-Memory?

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

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

בקצרה: Claude.md הוא ה-Playbook. Memory הוא ה-Retro Log.

מתי להתחיל: ברגע שפתרתם בעיה שעלתה לכם יותר מ-30 דקות - תתעדו. ה"אתם העתידי" יגידו תודה.

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

Hooks - Automated Guardrails

מה זה: פקודות Shell ש-Claude Code מריץ אוטומטית ב-Lifecycle Events - לפני או אחרי פעולות מסוימות. רצים בלי שצריך לבקש.

חשוב - לוקאלי או משותף? Hooks מוגדרים בקבצי Settings, ופה יש הפרדה קריטית:

• קובץ משותף (.claude/settings.json) - נכנס ל-source control. כל מפתח שעובד על הריפו מקבל את אותם Hooks. מתאים לדברים שהצוות כולו צריך - כמו בדיקות TypeScript לפני Push.
• קובץ אישי (.claude/settings.local.json) - לוקאלי בלבד, Claude Code מגדיר ל-git להתעלם ממנו אוטומטית. מתאים להעדפות אישיות או ניסויים שלכם.

אני בחרתי לשים את רוב ה-Hooks ב-settings.json (המשותף) כי הם רלבנטיים לכל מי שעובד על הפרויקט.

מה הקמנו:

אחרי כל כתיבת/עריכת קובץ TypeScript - רץ tsc --noEmit אוטומטית. תופס שגיאות Type מיד, לא בזמן Deploy.

לפני כל git push - רץ TypeScript Check + סוויטת טסטים מלאה. שום דבר שבור לא עובר.

לפני כל vercel deploy - רץ npm run build. נופל מקומית, לא על השרתים של Vercel.

מה ההבדל בין Hooks לחוקים ב-Claude.md?

Hooks הם אכיפה אוטומטית - רצים כקוד בכל פעם שהאירוע שלהם מתרחש. הם מתאימים ל-Guardrails ו-Quality Gates.

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

כלל אצבע: אם אפשר לבטא את הבדיקה כפקודת Shell - זה צריך להיות Hook. אם זה יותר כיווני - זה Claude.md.

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

Custom Skills - תהליכי עבודה שאפשר לעשות שוב ושוב

מה זה: קבצי .claude/skills/<name>/SKILL.md שמגדירים Workflows חוזרים. אפשר להפעיל אותם עם /skill-name או ש-Claude מפעיל אותם לבד כשזה רלבנטי.

מה יצרנו:

סקיל Deploy - /deploy - צ'קליסט Deploy מלא ל-Vercel: TypeScript Check → Build → סיווג שגיאות → Deploy → Health Check. כל ה-Constraints המוכרים אפויים בפנים.

סקיל Agents - /agents - ניהול צוות Agents: קריאת team.json, רשימת כל שדות הקונפיגורציה, אישור תאימות, הפעלת Agents עם פרוטוקולים של ניטור והתערבות.

סקיל Review - /review - Pipeline של Code Review עם 4 Agents: קריאה → ניתוח → תיקון בעיות קריטיות → הרצת טסטים → דו"ח.

סקיל Phase - /phase - ביצוע מדורג למשימות מורכבות: Scaffold → Implement → Test → Deploy, עם Checkpoints בין כל שלב.

מתי ליצור Skill: כשרצתם את אותו Workflow שלוש פעמים ומצאתם את עצמכם מקלידים את אותו Prompt Structure. אם יש Pattern - קודדו אותו פעם אחת.

למה זה משנה: Workflow שלוקח 5 דקות של Prompt Crafting הופך לפקודה אחת. חיסכון בטוקנים כי תיאור ה-Skill קומפקטי והתוכן נטען רק כשצריך. והכי חשוב - הגרסה הכי טובה של ה-Workflow שלכם מקודדת פעם אחת ומשוכפלת בצורה מושלמת בכל פעם.

Skills מהקהילה - Best Practices מוכנים

מה זה: skills.sh הוא ספריית Skills פתוחה של Vercel, עם Directory ו-Leaderboard של Skills שנבנו על ידי הקהילה - כולל חברות כמו Vercel עצמן ומפתחים עצמאיים. התקנה עם npx skills add owner/repo --skill skill-name. חשוב לציין: skills.sh הוא כלי שמתקין Skills מריפואים בגיטהאב, לא Marketplace סגור.

איך זה עובד: Skills מותקנים לתוך .claude/skills/ (ברמת הפרויקט) או ~/.claude/skills/ (גלובלי) ו-Claude Code מזהה אותם אוטומטית. ברגע שמותקנים, הם זהים ל-Custom Skills - רק שמישהו אחר כתב אותם. Claude קורא את התיאורים של כל ה-Skills ומחליט מתי להפעיל אותם אוטומטית. Skills שמותקנים ברמת הפרויקט יכולים להיכנס ל-source control ולהיות משותפים לצוות.

מה התקנתי (15 Skills):

Vercel Labs - React/Next.js Best Practices מצוות ההנדסה של Vercel, ודפוסי ארכיטקטורת קומפוננטות.

obra/superpowers - ניהול Agents מקביליים, אימות לפני סיום (פותר ישירות את הבעיה של "Claude אמר שזה עובד אבל זה לא"), Debugging שיטתי, כתיבת תכניות לפני קוד, וביצוע תכניות עם Checkpoints.

wshobson/agents - דפוסי Next.js App Router, Design System ב-Tailwind, עקרונות עיצוב API, Code Reviews מקביליים, פיתוח פיצ'רים במקביל עם מניעת קונפליקטים, אסטרטגיות תיאום משימות, פרוטוקולי תקשורת בין Agents, ודפוסי הרכבת צוותים.

מתי להשתמש ב-skills.sh לעומת Custom Skills: השתמשו ב-skills.sh ל-Best Practices אוניברסליים - React Patterns, מתודולוגיית Debugging, TypeScript. כתבו Custom Skills ל-Workflows ספציפיים לפרויקט שלכם - ה-Deploy Pipeline שלכם, מבנה צוות ה-Agents שלכם, תהליך ה-Review שלכם.

⚠️ הערה חשובה על אבטחה: כמו עם כל ספריית קוד פתוח (חשבו על npm packages), אל תתקינו Skills בעיניים עצומות. בדקו את הקוד, השתמשו בכלים חיצוניים לסריקת אבטחה, ואל תסמכו על דבר מבלי לבחון אותו. ובקרוב צפויים להגיע גם כלים שיעזרו לעשות את זה בצורה יותר אוטומטית. בדיוק אותו עיקרון שאתם כבר מכירים מעבודה עם ספריות npm - רק שכאן הסיכון הוא ב-Context שמגיע ל-Agent שלכם.

התמונה המלאה - מה יש עכשיו

משותף דרך הריפו (כל מפתח בצוות מקבל):

אישי/לוקאלי בלבד (רק אצלי):

Skills מהקהילה (מותקנים בפרויקט, אפשר לבחור אם לקמט לריפו):

15 Skills מ-Vercel, obra, wshobson

שימו לב להפרדה הזו - היא קריטית. ה-Claude.md ברמת הפרויקט, ה-Hooks ב-settings.json (בלי .local), וה-Custom Skills - כולם נכנסים ל-source control. כל מפתח שעושה git pull מקבל אותם אוטומטית. ה-Claude.md הגלובלי, ה-settings.local.json וה-Memory נשארים רק אצלכם - ההעדפות האישיות שלכם, הניסויים שלכם, והזיכרון של הסשנים שלכם.

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

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

Claude מתחיל כל סשן כשהוא כבר יודע את הפרויקט, את האילוצים, ואת ההעדפות שלכם. בדיקות איכות רצות אוטומטית - שגיאות TypeScript, כשלונות טסטים, ו-Builds שבורים נתפסים לפני שהם מבזבזים לכם זמן. Workflows חוזרים הם פקודה אחת במקום חמש דקות של Prompt Engineering. Best Practices מהקהילה מופעלים אוטומטית בלי שצריך לבקש. ושיעורים שנלמדו בסשן אחד אוטומטית משפיעים על הבא.

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

התשואה: כל סשן מכאן והלאה מתחיל חכם יותר, רץ נקי יותר, ועולה פחות.

למה זה רלבנטי לחברה שלכם ולא רק לניסוי שלי

נעצור לרגע מהטכני ונחשוב על זה כתהליך ארגוני.

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

חיסכון בכסף: טוקנים זה כסף. סשנים שרצים פחות זמן בגלל Hooks ו-Skills שמונעים לולאות מיותרות - זה חיסכון ישיר. Agents שלא נתקעים על אותה בעיה שלוש פעמים - עוד חיסכון. כמה בדיוק? זה ישתנה בין פרויקט לפרויקט ובין צוות לצוות, אבל כל מי שעבד עם Claude Code לכמה סשנים מכיר את הכאב של חזרתיות מיותרת.

שמירה על איכות: הסכנה הכי גדולה ב-AI Coding היא לרוץ מהר בלי בדיקות. Hooks פותרים את זה - בדיקות רצות אוטומטית, בלי שום אפשרות לדלג. ה-Quality לא נפגע מהמהירות.

סקיילביליות: וזה אולי החלק הכי חשוב. במידה ואני חברה ויש לי Repo משותף עם עוד מפתחים - אני יכול לשתף חלק ממה שבניתי דרך הריפו: ה-Claude.md ברמת הפרויקט, ה-Hooks ב-settings.json, וה-Custom Skills. כל מפתח שעושה git pull מקבל את הסטנדרטים האלה. ההעדפות האישיות (Claude.md הגלובלי, Memory, settings.local.json) נשארות לוקאליות. ההפרדה הזו חשובה - סטנדרטים משותפים לצוות, גמישות אישית לכל מפתח. כמו שבכל חברה טובה יש Coding Standards ו-Linter Rules שכולם עובדים לפיהם, אבל לכל מפתח יש את ה-IDE Settings שלו.

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

הדבר שמהדהד לי מהחוויה הזו - חשיבותו של ניסיון

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

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

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

איך נראית עבודה בצוות שעובד על אותו Repo ורץ במקביל על משימות? איך מנהלים את זה ובונים את זה נכון? איך נראית תקלת Production? איך מזהים אותה? איך מייצרים כלים שמזהים אותה מראש? איך בונים מערכת שיודעת להגיע ל-Scale? איך יודעים מתי צריך Scale? מתי לכתוב עוד טסטים? מתי לדאוג לאבטחה?

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

אז מה המסר?

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

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

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

גם אם התשובה תהיה "לא" - לפחות תדעו שבדקתם ולא התעלמתם.

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

1. לעצור לבנות תשתית זה לא בזבוז זמן - זה השקעה

כשעתיים למי שמכיר (עד חצי יום-יום למי שלומד תוך כדי) של עבודה על Claude.md, Memory, Hooks ו-Skills - וכל סשן מכאן והלאה חכם יותר. ה-ROI מצטבר כל יום.

2. AI צריך Onboarding בדיוק כמו מפתח חדש

אף אחד לא מצפה ממפתח חדש לדעת את כל ה-Conventions של החברה ביום הראשון. אז למה לצפות את זה מ-Claude? Claude.md הוא ה-Onboarding Document. Memory הוא ה-Tribal Knowledge. Skills הם ה-Standard Operating Procedures.

3. מה שעבד לבד - עובד פי כמה בצוות

חלק ממה שבניתי היום - Claude.md ברמת הפרויקט, Skills, Hooks ב-settings.json - נכנס ל-source control ומשותף לכל הצוות. כל מפתח שעושה git pull, כל Agent חדש שרץ - מרוויחים מהסטנדרטים שנקבעו. העדפות אישיות נשארות אישיות דרך settings.local.json. זה ה-Compound Effect האמיתי.

4. הניסיון שלכם הוא Edge - אבל רק אם הוא מחובר ל-AI

מתכנתים מנוסים שלומדים AI - זה הצירוף הכי חזק שיש. הידע שלהם על ארכיטקטורה, Scale, Production ועבודת צוות - בשילוב עם היכולות החדשות - שווה הרבה יותר מכל אחד מהם לבד.

5. Feedback Loop הוא ההשקעה הכי טובה שיש

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

מה הלאה?

בפוסט הבא - חוזרים לקוד. רק שעכשיו, עם כל התשתית הזו, העבודה צריכה להיות שונה. אני סקרן לראות כמה. Sub-agents, Code Review אוטומטי עם API של Anthropic, ועוד - עם Agents שסוף סוף יודעים מי הם, מה הפרויקט, ומה קרה בסשנים הקודמים.

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