אני מנהל צוות למידה ופיתוח. חלק מהתפקיד שלי הוא לשבת עם אנשים לשיחות משוב, להסתכל יחד על תקופה שלמה של עבודה, ולשים על השולחן גם את מה שעובד וגם את מה שדורש שיפור. תהליך כזה דורש המון אומץ, אפס שיפוטיות וגם רפליקציה על התפקוד שלי, ואיך הוא השפיע על הביצועים של הצוות. וזה מובן מאליו שכעובד גם אני עובר שיחת הערכה עם המנהלת שלי ומקבל פידבקים לשיפור ולשימור.
הפעם ביקשתי מקלוד קוד לעשות לי הערכת ביצועים. הרצתי את הפקודה /insights וקיבלתי דו״ח מלא על איך אני משתמש ב-Claude Code ואיך אני יכול להשתפר.
לא מדובר בציון כללי או בסיכום מחמיא של השיחות. קיבלתי דוח HTML שמחבר בין עשרות סשנים, מזהה דפוסים חוזרים ומביא דוגמאות ספציפיות. היה בו גם סקשן בשם “Where Things Go Wrong”, שגרם לי להתכווץ קצת בכיסא.
תחשבו על זה כמו שעון כושר לעבודה עם AI. הוא לא מסתפק בתחושה שהייתם יעילים. הוא מראה מה עשיתם בפועל, איפה נעצרתם, ומה חזר על עצמו מספיק פעמים כדי להפוך לדפוס.
מה הפקודה /insights עושה?
לפי התיעוד הרשמי, /insights מייצרת דוח שמנתח את סשני Claude Code שלכם ומציג את תחומי העבודה, דפוסי האינטראקציה ונקודות החיכוך. בפועל, הדוח שקיבלתי הלך רחוק יותר מספירת הודעות.
הוא ניסה להבין מה רציתי להשיג בכל סשן, מה הושלם, איפה Claude עזר במיוחד, ומה גרם לעבודה להיתקע או לחזור לסבב נוסף. אחר כך הוא חיבר בין המקרים והציע פעולות שאפשר להפוך לכללים ב-CLAUDE.md, ל-skills או לתהליכי אימות.
זה ההבדל החשוב: הדוח לא רק אומר כמה השתמשתם ב-Claude Code. הוא בוחן את שיטת העבודה המשותפת שלכם עם הכלי.
מה נשמר, ומה כדאי לדעת לפני שמריצים
Claude Code שומר כברירת מחדל תמלילי סשנים מקומיים תחת ~/.claude/projects/. התיעוד מציין שהקבצים נשמרים כטקסט גלוי ושכל דבר שעבר דרך כלי, כולל תוכן של קובץ שנקרא או פלט של פקודה, עלול להופיע בתמליל.
לכן אני לא מניח ש-/insights רואה “רק מטא-דאטה”. לפני שמריצים אותה על סביבת עבודה רגישה, כדאי להכיר את מדיניות שמירת הנתונים של סוג החשבון שלכם, לבדוק את cleanupPeriodDays, ולהבין מה נשמר מקומית. הדוח שימושי מאוד, אבל שימושיות אינה תחליף למדיניות מידע.
מה הדוח גילה עליי
קודם החלק הנעים: מה אני עושה טוב
הדוח זיהה שלושה דפוסים שחזרו בסשנים שונים.
לרדוף אחרי שורש הבעיה
אני לא מוותר על השאלה “למה זה קרה” גם כשיש תיקון מהיר על השולחן. הדוח מצא 12 סשנים עם תוצאות דיבאגינג טובות, כולל מקרה שבו מדדנו פיקסלים כדי להיפטר מאפקט זוהר עיקש.
להצליב נתונים מול המקור
במצגות ובדשבורדים דרשתי מזהים, שעות והתאמה לבסיס הנתונים. הדוח קרא לתוצאה “audited, defensible numbers”: מספרים שאפשר להסביר ולהגן עליהם.
לעבוד לאורך כל מחזור החיים
לא לעצור בקוד, אלא להגיע לפריסה, לאמת את התוצאה ולשייף אותה למשתמשים אמיתיים. זו הייתה הכוונה שלי; עוד רגע תראו איפה הביצוע לא תמיד עמד בה.
עכשיו החלקים שפחות נעים לקרוא
החיכוך הגדול ביותר היה פער בין “המשימה הסתיימה” לבין “התוצאה באמת עובדת”.
הדוח סיווג 19 מופעי חיכוך כ-Buggy Code. זה לא אומר שב-19 סשנים נפרדים קיבלתי בדיוק אותו באג, אלא שהקטגוריה הזו הופיעה 19 פעמים בדאטה. במקרים הבולטים, ה-build עבר והבדיקה ברמת הקוד נראתה תקינה, אבל בדפדפן האמיתי הבעיה נשארה.
במקרה אחר, סקריפט פריסה דיווח הצלחה בזמן שהאתר החי כלל לא התעדכן. הפריסה רצה מול scope לא נכון ב-Vercel. על הנייר הכול היה ירוק; המשתמשים עדיין ראו את הגרסה הישנה.
אימות חלקי ודיווחי הצלחה מוקדמים
בדיקת build או bundle החליפה בדיקה של הממשק האמיתי, ולכן תיקונים שנראו מושלמים בקוד נכשלו ברינדור.
הגדרת model ו-effort שחסמה סשנים
שילוב לא נתמך בין רמת מאמץ למצב thinking גרם לשגיאות API. כמה סשנים נעצרו לפני שהעבודה בכלל התחילה.
פקודות רחבות מדי בסביבה מקבילית
פקודת `pkill` רחבה מסשן אחד סגרה שרת של סשן אחר. הדוח תיאר את זה כ-“accidentally assassinated”, ניסוח דרמטי אבל מדויק למדי.
הנקודה הכי מעניינת הייתה הסתירה: הדוח זיהה שאני נוטה לסגור מעגל עד האתר החי, ובאותו זמן הראה שהאימות הזה לא היה עקבי מספיק. זאת בדיוק הסיבה שדוח כזה שימושי. חוזקה שאינה הופכת לכלל עבודה עלולה להישאר רק כוונה טובה.
מה עשיתי עם ההמלצות באותו יום
הערכת ביצועים שלא משנה התנהגות היא רק מסמך יפה. לכן לקחתי את ההמלצות והפכתי אותן לארבעה שינויים במערכת.
כללי אימות ב-CLAUDE.md
תיקון frontend נחשב גמור רק אחרי בדיקה בדפדפן. פריסה נחשבת גמורה רק כשהכתובת החיה מציגה את השינוי.
חיזוק ה-skill לאימות פריסות
הוספתי בדיקה של חשבון ו-scope לפני הפריסה, ואימות מפורש של השינוי באתר החי אחריה.
תיקון הגדרת החשיבה
שיניתי את ההגדרה שיצרה את ההתנגשות בין effort ל-thinking, כדי שסשנים לא ימותו עוד לפני הבקשה הראשונה.
כלל בטיחות לתהליכים
עוצרים תהליך רק לפי פורט או PID מדויק. לא משתמשים ב-`pkill` רחב שעלול לפגוע בסשנים מקבילים.
שימו לב למכנה המשותף: כל תיקון הוא שינוי במערכת. לא “אני אשתדל לזכור”, אלא כלל כתוב, הגדרה, skill או שלב קבוע בתהליך.
זה גם העיקרון מאחורי skills לסוכני AI: אם יש פעולה שאתם רוצים שהסוכן יבצע שוב ושוב באותה רמה, אל תשאירו אותה כהערה אקראית בצ׳אט. הפכו אותה להוראה חוזרת שאפשר לבדוק.
למה זה חשוב גם אם אתם לא מתכנתים
אני מגיע מעולם הלמידה הארגונית, ובעיניים שלי הדוח הזה מלמד משהו רחב יותר מ-Claude Code.
כולנו בונים עכשיו שיטות עבודה עם AI. חלק לומדים מניסוי וטעייה, חלק מחיקוי, ורבים מסתמכים על תחושת בטן: “מרגיש לי שזה עוזר” או “נראה לי שהתייעלתי”.
הבעיה היא שתחושה טובה לא מספרת איפה העבודה נשברה. הדוח הראה לי שהייתי בטוח שאני מסיים משימות בצורה מלאה יותר ממה שהדאטה הראתה בפועל. הוא גם הראה שהבעיה אינה רק ביכולת של המודל, אלא בהגדרות, בהרשאות, בתהליכי האימות ובהוראות שנתתי לו.
זו המשמעות הפרקטית של Agentic Engineering: לא רק לבחור מודל טוב, אלא לבנות סביבו מערכת שמגדירה מה נחשב הצלחה, באילו כלים משתמשים ואיך יודעים שהתוצאה אמיתית.
עוד פקודות שכדאי להכיר ב-Claude Code
/insights מסתכלת על דפוסים בין סשנים. הפקודות הבאות עוזרות לנהל את הסשן הנוכחי ולתפוס בעיות מוקדם יותר.
/doctor- כשמשהו בסביבה לא עובד. מאבחנת בעיות התקנה ותצורה ב-Claude Code. אני מריץ אותה כשיש התנהגות חריגה לפני שאני מתחיל לשנות את הפרויקט.
/context- כשהשיחה מתארכת. מציגה מה תופס את חלון ההקשר. היא משלימה את [המדריך שלי לניהול חלון ההקשר](/blog/manage-claude-code-context-window/) והופכת את הבעיה לנתון שאפשר לפעול לפיו.
/usage- כשרוצים להבין את מגבלות השימוש. מציגה את ניצול מכסת חמש השעות והמכסה השבועית, כדי להחליט אם להמשיך באותו מודל או לשנות את אופי העבודה.
/compact- כשצריך לפנות מקום בלי לאבד את חוט העבודה. אפשר להוסיף הוראות למה חשוב לשמור בסיכום, למשל החלטות עיצוב ובאגים פתוחים.
/rewind- כשכיוון גדול השתבש. מחזירה את הקוד או את השיחה לנקודת ביקורת קודמת, במקום לתקן שוב ושוב שינוי שלא היה נכון מלכתחילה.
/memory- כשהערה חוזרת על עצמה. פותחת את ניהול קובצי הזיכרון וה-auto-memory. אם נתתי את אותה הנחיה שלוש פעמים, כנראה הגיע הזמן להפוך אותה לכלל קבוע.
/review- לפני שמפרסמים שינוי משמעותי. מבצעת סקירה ממוקדת של השינויים. לבדיקת חולשות אבטחה יש גם את
/security-review.
לא צריך לזכור את כולן. התחילו מ-/insights, ותנו לדוח להראות איזה חלק בשיטת העבודה שלכם דורש כלי נוסף.
שאלות נפוצות על Claude Code Insights
מה זה Claude Code Insights?
Claude Code Insights הוא דוח אישי שנוצר באמצעות הפקודה /insights. הוא מסכם דפוסים בין סשנים, מציג חוזקות ונקודות חיכוך, ומציע פעולות שיכולות לשפר את שיטת העבודה עם Claude Code.
האם /insights מחליפה בדיקה ידנית של העבודה?
לא. הדוח מזהה דפוסים ומצביע על מקרים שכדאי לבדוק, אבל הוא אינו מוכיח שתיקון עובד בדפדפן או שפריסה הגיעה לאתר החי. את התוצאה עדיין צריך לאמת בכלים ובסביבה שבה המשתמשים פוגשים אותה.
מה עושים עם ההמלצות של הדוח?
בוחרים את ההמלצות שחזרו ביותר ממקרה אחד והופכים אותן לשינוי שאפשר לבדוק: כלל ב-CLAUDE.md, skill, הגדרה או שלב אימות קבוע. המטרה היא לשנות את המערכת, לא רק לזכור להשתפר בפעם הבאה.
השורה התחתונה: עכשיו תורכם
אם אתם עובדים עם Claude Code באופן קבוע, נסו השבוע תהליך קצר:
אני עדיין לומד את שיטת העבודה הנכונה עם הכלים האלה. דבר אחד כבר ברור לי: מי שעובד עם AI כל יום צריך מדי פעם לעצור ולבדוק לא רק מה הוא בנה, אלא איך הוא וה-AI הגיעו לשם.
אני אשמח לשמוע מה הדוח גילה עליכם. במיוחד את החלקים שהוא הציע לשפר.
מקורות והמשך קריאה
- Claude Code Commands: התיעוד הרשמי של
/insightsושל שאר הפקודות המובנות. - Claude Code Data Usage: מדיניות השימוש והאחסון לפי סוג החשבון.
- Explore the .claude directory: מה נשמר מקומית, לכמה זמן ואיך משנים את תקופת הניקוי.