מאת: שי שמעוני, מפתח מובייל, MSApps
תגיות: פיתוח בעזרת בינה מלאכותית, Claude Code, React Native, iOS, Android, הנדסת מובייל, פרודוקטיביות פיתוח
אם אתם מפתחי מובייל ששואלים את עצמכם אם כלי קידוד מבוססי בינה מלאכותית שווים את התקורה — עלות ההגדרה, ניסוח ההנחיות, ניהול הטוקנים — הפוסט הזה מנסה לתת תשובה כנה. אני משתמש ב-Claude Code על מנוי Pro של $20 לחודש כחלק מהעבודה היומיומית שלי על פני שש אפליקציות בפרודקשן. עד סוף הפוסט תדעו בדיוק איך בנויה הזרימה, אילו תוספים מאריכים את תקציב הטוקנים, ואיך נראה תיקון באג אמיתי במספר סבבים כשיש בינה מלאכותית מעורבת — כולל המקומות שבהם היא טעתה לפני שהגיעה לתיקון הנכון.
ההגדרה: מה MSApps בונה
MSApps היא סוכנות פיתוח מובייל שמבוססת בישראל. בסיסי הקוד שאני עובד איתם כוללים:
- DreamCard (React Native + TypeScript) — פלטפורמת כרטיסי נאמנות והטבות עם תהליכי הזדהות, מחזורי רענון ברקע ואינטגרציות SDK של צד שלישי
- myzeekr iOS (UIKit, Alamofire, ZeekrSDK + Ituran + Au10tix, עברית ו-RTL) — פלטפורמת רכב מחובר עבור Zeekr ישראל
- myzeekr Android (Kotlin 2.2.0, Retrofit/OkHttp, ממשק מבוסס View) — המקבילה בפלטפורמת Android
- mylexus iOS ו-mygeely iOS — אפליקציות רכב מחובר עבור Lexus ישראל ו-Geely ישראל בהתאמה, כל אחת עם ה-SDK ואינטגרציית התשלומים שלה
- nerivio iOS (UIKit + Coordinator + MVVM, BLE, NFC) — אפליקציה למכשיר רפואי עבור מכשיר הטיפול במיגרנה Nerivio של Theranica
לבסיסי הקוד האלה יש מספיק חלקים נעים — שמירת נתונים ב-Keychain, הזדהות ביומטרית, מספר יעדי בנייה, פריימוורקים בינאריים של SDK — שכדי לגרום לעוזר בינה מלאכותית להיות באמת שימושי נדרשה עבודת הגדרה מקדימה.
תחילת העבודה עם Claude Code: עקומת הלמידה
הדבר הראשון שהייתי צריך ללמוד הוא ש-Claude Code אינו צ'אטבוט שמדביקים אליו קוד. זהו סוכן טרמינל עם גישה ישירה למערכת הקבצים, שימוש בכלים וזיכרון מתמשך. ההבדל משמעותי.
כשהפניתי אותו לראשונה אל myzeekr iOS, הרצתי את התוסף /learn-codebase — הוא קרא כל קובץ מקור במלואו, ואינדקס את הארכיטקטורה, את הסינגלטונים, את דפוסי שכבת הרשת ואת יעדי הבנייה וזרימות הניווט למאגר זיכרון מתמשך. ההשקעה החד-פעמית הזו מראש משמעה שכל סשן הבא התחיל עם הקשר שלא הייתי צריך להסביר מחדש.
מערכת הזיכרון (claude-mem) שומרת תצפיות בין סשנים. בכל פעם שהבינה המלאכותית מגלה משהו לא מובן מאליו — דפוס closure מיושן, סדר אתחול של SDK, race condition במצב אסינכרוני — היא כותבת אותו לאינדקס חיפוש המגובה ב-SQLite. בסשן הבא, היא מחפשת באינדקס הזה במקום לקרוא מחדש את אותם קבצים. עוד על כך בפרק על ניהול הטוקנים.
באג אמיתי: איפה הבינה המלאכותית עזרה (ואיפה נדרשו כמה סבבים)
מקרה אחד שממחיש היטב את הזרימה הוא באג מספר 12584 בקובץ UserContext.tsx של DreamCard.
התסמין
משתמשים דיווחו על קריסות כשהם חוזרים לאפליקציה מניווט חיצוני (Waze, לדוגמה). לחיצה על כפתורים לאחר הקריסה הפיקה שגיאת "Maximum call stack size exceeded". הגשר של React Native היה פגום.
הסיבה השורשית (הסבב הראשון)
הקוד המקורי זרק new Error('Error') בתוך useEffect כדי להפעיל את ה-ErrorBoundary של React. בתאוריה, זה מנתב את השגיאה למסך שגיאה שניתן להתאושש ממנו. בפועל, זריקת שגיאה בתוך useEffect ב-React Native פוגעת בגשר שבין JavaScript לשכבה הנייטיבית. ברגע שהוא פגום, שום אינטראקציה בממשק לא עובדת.
התיקון נראה מובן מאליו: להחליף את throw new Error() בקריאת ניווט בטוחה למסך שגיאה באמצעות navigationRef.navigate(ERROR). כך עץ ה-React נשאר חי.
התיקון שדרש עוד שלושה סבבים
התיקון הראשוני לא הספיק. הרצת סוכן ביקורת הקוד — שבודק באופן עצמאי, בלי ההקשר של למה השינוי נעשה — העלתה שלוש בעיות נכונות נוספות.
בעיה 1 — קיבוץ מצבים (State Batching) ב-React
הניסיון הראשון לתיקון איפס דגל useRef (isLoginFlowRef.current = false) באופן סינכרוני בתוך handleLogin, אחרי await hadleRefreshData(). ההיגיון: להעלות את הדגל ל-true לפני שינויים, ו-false אחריהם. פשוט.
מה שהביקורת תפסה: React מקבצת עדכוני מצב באופן אסינכרוני. כשמוטציה קוראת ל-setHasRedirectedToError(true) בתוך onError, זהו עדכון מצב מתוזמן — הוא לא מרנדר מחדש באופן מיידי. React משחררת את הקיבוץ אחרי שהתור הסינכרוני הנוכחי מתרוקן. אז סדר הביצוע בפועל היה:
handleLoginמעלה אתisLoginFlowRef.current = true- המוטציה נכשלת ←
onErrorקוראת ל-setHasRedirectedToError(true)(מתזמנת עדכון) hadleRefreshDataמחזירה תוצאה (בולעת את השגיאה ב-try-catch החיצוני)handleLoginמוריד אתisLoginFlowRef.current = false← הדגל מתאפס כאן- React משחררת את עדכון המצב המקובץ, ה-
useEffectמופעל - ה-effect בודק את
isLoginFlowRef.current← כברfalse← יציאה מוקדמת - מסך השגיאה אף פעם לא מוצג
התיקון: להעביר את קריאת ה-ref לתוך ה-effect, ולתפוס אותו ולאפס אותו באופן אטומי:
const shouldNavigate = isLoginFlowRef.current;
isLoginFlowRef.current = false;
if (!shouldNavigate) return;
if (navigationRef.isReady()) navigationRef.navigate(ERROR);
בעיה 2 — Race Condition בין רענוני רקע מקבילים
האפליקציה מריצה שני מנגנוני הפעלת רענון רקע עצמאיים: טיימר של 30 דקות, ומאזין AppState שמופעל כשהאפליקציה עוברת לחזית. שניהם שיתפו ref בוליאני יחיד (isBackgroundRefreshRef).
ה-race: הטיימר מופעל, מעלה את ה-ref ל-true, מתחיל רענון. המשתמש מעביר את האפליקציה לרקע וחוזר תוך כדי הרענון — גם מאזין ה-AppState מעלה את ה-ref ל-true ומתחיל רענון שני. הרענון של הטיימר מסתיים ראשון, ומוריד את ה-ref ל-false. הרענון של ה-AppState עדיין באוויר. כשה-onError של getCustomerMutation באירוע ה-AppState מופעל, ה-ref הוא false — השער פתוח — ומסך השגיאה מוצג באופן שגוי עבור כשל ברענון רקע.
התיקון: להחליף את הבוליאני במונה:
const backgroundRefreshCountRef = useRef(0);
// בכניסה:
backgroundRefreshCountRef.current += 1;
// ביציאה:
backgroundRefreshCountRef.current -= 1;
// בדיקת השער:
if (backgroundRefreshCountRef.current === 0) setHasRedirectedToError(true);
השער נפתח רק כשכל הרענונים שבאוויר מסתיימים. אם הטיימר וה-AppState חופפים, המונה מגיע ל-2; מי שמסתיים ראשון מוריד אותו ל-1; הסיום האחרון מוריד אותו ל-0.
בעיה 3 — הנווט לא מוכן באתחול קר
באתחול קר, מכולת הניווט עשויה לא להיות מורכבת (mounted) כששגיאת API מופעלת. הקוד המקורי איפס את הדגל hasRedirectedToError לפני הבדיקה של navigationRef.isReady(). אם הנווט לא היה מוכן, הדגל התאפס אבל הניווט דולג — וה-effect לעולם לא היה רץ מחדש כי התלות שלו אופסה ידנית ל-false.
התיקון: לאפס את הדגל רק אחרי ניווט מוצלח:
if (!navigationRef.isReady()) return; // הדגל נשאר true, מנסה שוב ברינדור הבא
setHasRedirectedToError(false);
navigationRef.navigate(ERROR);
זה דרש כמה מחזורי ביקורת-תיקון-ביקורת, לא סבב אחד נקי. הביקורת העצמאית (בלי היסטוריית שיחה, בלי ידע על ההיגיון שלי) היא מה שתפס את בעיות 2 ו-3 בדיוק ברגע שחשבתי שהתיקון הושלם. זו הגרסה הכנה של איך זה קרה בפועל.
אינטגרציות: CLI-ים ו-API-ים שאני משתמש בהם מדי יום
אחד הדברים המעשיים ביותר בעיצוב המבוסס-טרמינל של Claude Code הוא שהוא יכול לקרוא לכל CLI או REST API שכבר בשימוש — בלי דפדפן, בלי העתק-הדבק ובלי אינטגרציה מותאמת אישית.
Azure DevOps — REST API עם PAT
פריטי העבודה שלנו חיים ב-Azure DevOps. ההגדרה פשוטה: לשמור את טוקן ה-PAT, שם הארגון ושם הפרויקט בקובץ ~/.claude/settings.json. כשאני אומר "קח את פריט העבודה 12585", Claude Code קורא ישירות ל-REST API של Azure DevOps באמצעות curl, מפרסר את תגובת ה-JSON וקורא את תיאור המשימה — גם כשהוא בעברית, כי הצוות שלנו כותב משימות בעברית.
פריט עבודה 12585 נקרא "שינויים בSDK המוטמע של אקוסטיק". Claude קרא את התיאור בעברית, זיהה את הסיבה השורשית (בנייה ידנית של payload שעוקפת את יצירת ה-UUID האוטומטית של הסשן ב-SDK), והתווה את התיקון. בלי טאב בדפדפן, בלי העתק-הדבק.
הכלל הנוקשה כאן: תמיד REST API, אף פעם לא CLI של az. ה-CLI מוסיף תלות ושכבת הזדהות שלא נחוצה כשטוקן PAT עובד ישירות.
Monday.com — MCP דרך מחבר Claude AI
עבור Monday.com אני משתמש באינטגרציית ה-MCP המובנית שמגיעה עם מערכת המחברים (connectors) של Claude. לאחר הזדהות, Claude Code יכול לשאול לוחות, לקרוא פריטים ולשלוף פרטי כרטיס ישירות מכתובת URL של Monday.com בלי לצאת מהטרמינל. בלי עוטפן API מותאם, בלי ניהול טוקן אישי — מחבר ה-MCP מטפל בהזדהות.
בפועל זה אומר שאני יכול לומר "תביא את פריט 12345 מהלוח" ולקבל את תיאור הכרטיס המלא, את המוקצה לו ואת הסטטוס ישירות בשיחה, באותו אופן שבו פריטי העבודה מ-Azure DevOps מגיעים. שתי האינטגרציות מכסות את שני המקומות שבהם הצוות שלנו עוקב אחרי עבודה, ושתיהן נגישות מסשן טרמינל בודד.
GitHub CLI (gh)
לעבודה הקשורה ל-GitHub — יצירת PR-ים, בדיקת סטטוס CI, סקירת diff-ים, הגבת על issues — אני משתמש ב-CLI של gh. Claude Code יכול לקרוא ל-gh ישירות בטרמינל, מה שאומר שיצירת PR עוקבת אחרי אותה תבנית בכל פעם: נושא בפורמט conventional commit, רשימת נקודות של שינויים, בלי רעש מיותר בסוף. הכללים ב-CLAUDE.md מגדירים את פורמט ה-PR ו-Claude עוקב אחריו בלי צורך בהנחיה חוזרת.
gh pr create, gh pr view, gh pr checks, gh issue list — כולם ניתנים לקריאה בתוך הסשן, בלי לעבור להקשר של דפדפן. כשבדיקת CI נכשלת, gh run view יכול למשוך את יומן הכשל ישירות לתוך הסשן.
מה שלמדתי מהגישה של Andrej Karpathy
אני רוצה להיות כן לגבי המקור של חלק מהחשיבה שלי בנושא. Andrej Karpathy — חבר מייסד לשעבר ב-OpenAI, מנהל הבינה המלאכותית של Tesla, ואחד האנשים שחושבים בצורה הכי ברורה על איך מפתחים צריכים לעבוד עם מודלי שפה — כתב ודיבר הרבה על מה שמשתנה כשבינה מלאכותית הופכת לחלק ממעגל הפיתוח.
רעיון אחד שנשאר איתי הוא מה שהוא כינה "vibe coding". הניסוח שלו: הבינה המלאכותית חצתה סף שבו אפשר לבנות תוכנה אמיתית דרך אנגלית, כמעט לשכוח שיש קוד מתחת. הוא השתמש בזה כדי לכתוב טוקנייזר BPE מותאם אישית ב-Rust, לבנות אפליקציות דמו מהירות, ואפילו להקים אפליקציות זריקה שלמות רק כדי לאתר באג בודד — כי בשלב מסוים, יצירת קוד נהיית זולה מספיק כדי להיות חד-פעמית.
מה שלקחתי מזה זה לא רישיון להפסיק לחשוב על איכות קוד. זה כמעט ההפך. האתגר המעניין זז: אם יצירת קוד זולה, צוואר הבקבוק הופך להיות הידיעה מה לבקש, איך לבדוק את מה שחוזר, ואיך להקים את גדרות הבטיחות שמונעות מהבינה המלאכותית לחרוג מהתחום. Karpathy מתאר את זה היטב — vibe coding מעצים אנשי מקצוע מיומנים לכתוב תוכנה שאחרת לעולם לא הייתה נכתבת, אבל השיפוט המקצועי לגבי מה לבנות ואם זה נכון לא נעלם.
הסרטון שלו "How I use LLMs" (בערוץ היוטיוב שלו) שווה צפייה למי שמתחיל. הנקודה המעשית שהשפיעה עליי הכי הרבה: להתייחס לבינה המלאכותית כאל משהו שמכוונים ומוודאים, לא משהו שסומכים עליו בעיניים עצומות. הקוד שהיא כותבת צריך להיקרא. ההסברים שהיא נותנת צריכים להיבדק מול התנהגות בפועל. ככל שההקשר קריטי יותר לפרודקשן, כך חשוב יותר שיהיה אדם בתמונה בכל נקודת החלטה משמעותית.
זה ממופה ישירות לאיך שהגדרתי את הזרימה כאן — כללי CLAUDE.md שמצמצמים את התחום, אישור commit חובה לפני שדבר נדחף, הביקורת העצמאית שלא רואה שום הקשר מהסשן. אלה לא רק אמצעים לחיסכון בטוקנים. הם גדרות הבטיחות שהופכות את המהירות לבת-קיימא.
ניהול טוקנים: איך להישאר בתוך $20 לחודש
תוכנית ה-Pro של Claude Code ב-$20 לחודש כוללת תקציב טוקנים נדיב, אבל הוא יכול להיעלם מהר אם לא פועלים בכוונת מכוון. הנה מה שבאמת עושה הבדל.
context-mode
התוסף המשמעותי ביותר שאני משתמש בו הוא context-mode. הוא מנתב פלטי פקודה גדולים דרך תת-תהליך מבודד — במקום ש-cat UserContext.tsx ישפוך 800 שורות אל תוך הקשר השיחה, ctx_execute_file מריץ ניתוח על הקובץ בתהליך נפרד ומחזיר רק תקציר. פלט כלים גולמי שהיה עולה 30,000 טוקנים עולה פחות מ-2,000.
הפקודה ctx_batch_execute היא הסוס העובד: להריץ עשר פקודות shell, לאנדקס את הפלט אוטומטית, ולחפש בו עם עשר שאילתות — הכול בקריאת כלי אחת. זה מחליף מה שאחרת היה שלושים קריאות כלי נפרדות ואחריהן עשר חיפושי המשך.
חיסכון מדווח על פני סשן שלם: כ-94%.
caveman mode
תוסף שדוחס את התגובות של Claude עצמו — מוריד מילות יידוע, ביטויי מילוי, נימוסים, גידור. "בשמחה! אני אשמח לעזור לך עם זה. הבעיה שאתה חווה כנראה נגרמת בגלל..." הופך ל-"באג ב-auth middleware. תפוגת טוקן משתמשת ב-< ולא ב-<=. תיקון:". אותו מידע, בערך 75% פחות טוקנים בצד התגובה.
claude-mem — זיכרון מתמשך בין סשנים
בלי זיכרון מתמשך, כל סשן מתחיל מאפס. אותם 50 קבצים נקראים שוב, אותה ארכיטקטורה מוסברת שוב. claude-mem כותבת גילויים למאגר תצפיות המגובה ב-SQLite ששורד בין גבולות סשנים. סשנים חדשים מחפשים בזיכרון קודם; קבצים נקראים מחדש רק כשהזיכרון דו-משמעי או פוטנציאלית מיושן.
אחרי שהרצתי /learn-codebase על כל שישה הפרויקטים בישיבה אחת בהתחלה, כל סשן הבא יכול היה להתייחס לפרטי ארכיטקטורה, סדרי אתחול SDK ודפוסי ניווט בלי לקרוא מחדש קבצי מקור. במספרים: 116 סשנים מתועדים על פני חודש, 697 תצפיות שמורות, 4.67 מיליון טוקני גילוי מתועדים — המייצגים את כל העבודה שהבינה המלאכותית עשתה שהזיכרון כעת מונע חזרה עליה.
תוסף Codex — האצלת עבודה כבדה
תוסף Codex (codex:rescue) שימושי כשהסשן הראשי צריך להעביר חקירה או יישום גדול בלי לשרוף הקשר. במקום שהשיחה הראשית עם Claude תתרחב כדי לקרוא 20 קבצים ולעקוב אחרי 5 שרשראות קריאה, תת-סוכן Codex מטפל בחקירה בחלון ההקשר שלו ומחזיר תקציר דחוס.
מקרה השימוש המעשי: כשחקירת באג דורשת קריאת קבצים על פני מספר מודולים, או כשמשימת יישום כוללת שינויים על פני 4+ קבצים, האצלה ל-Codex שומרת על הסשן הראשי רזה. השיחה הראשית נשארת ממוקדת בהחלטות וסקירה; Codex מטפל בקריאה והכתיבה המכניות.
זה גם עוזר במשימות שבהן זוג עיניים טרי חשוב — דומה לעיקרון של סוכן ביקורת הקוד, סוכן Codex שלא היה עסוק בחשיבה על הבעיה 20 תורות אחרונים לפעמים חושף גישה פשוטה יותר.
האצלה לסוכנים
לחקירה רחבה בבסיס הקוד, אני מאציל לתת-סוכנים דרך סוג הסוכן Explore — רץ בחלון הקשר נפרד, מחזיר תקציר דחוס, השיחה הראשית לעולם לא רואה את תוכן הקבצים הגולמי.
לביקורת קוד, סוכן ה-code-reviewer רץ בלי היסטוריית שיחה. הוא רואה רק את ה-diff ואת הקוד, לא את ההיגיון שלי לשינוי. העצמאות הזו היא מה שגורם לו לתפוס דברים.
תחום ממושמע
בור הטוקנים הגדול ביותר הוא סחיפת הקשר — לבקש מ-Claude לחקור דברים שקשורים באופן משיקי למשימה. הכללים ב-CLAUDE.md אוכפים: משימה אחת בכל פעם, בלי ריפקטורינג לא מבוקש, בלי ניקיון של קוד לא קשור. זה מונע מהבינה המלאכותית לחקור קבצים שאין צורך לקרוא.
איכות הפלט: מה באמת עובד
מה שמצאתי אותו שימושי בשבילו:
- מעקב אחרי באגים לאורך מצב אסינכרוני. בעיית הקיבוץ ב-React למעלה כללה הבנה מדויקת של מתי React משחררת עדכוני מצב ביחס לקוד סינכרוני. מיפוי סדר הביצוע צעד אחר צעד, במקום להסתמך על מודל מנטלי של הפנימיות של React, עזר — למרות שזה עדיין דרש כמה סבבים.
- ניתוח השפעה חוצה-קבצים. משנים חתימת פונקציה? Claude בודק את כל מקומות הקריאה לפני שמאשר שהשינוי בטוח. מסירים feature flag? הוא מוודא ששום דבר אחר לא מפנה אליו. הבדיקה המכנית הזו קל לדלג עליה תחת לחץ זמן, והיא תופסת טעויות אמיתיות.
- ביקורת קוד מנקודת מבט עצמאית. סוכן שלא ראה את החלטות היישום שלי לפעמים מסמן דברים שהצדקתי לעצמי בזמן כתיבת הקוד. לא תמיד, אבל מספיק פעמים כדי שיהיה שווה להריץ.
- התמצאות בבסיס קוד לא מוכר. התוסף
/learn-codebaseקורא את כל קבצי המקור ושומר את מה שהוא לומד. כשאני עובד על פרויקט שלא נגעתי בו זמן מה, אני יכול לשאול שאלות על ארכיטקטורה בלי לעקוב ידנית דרך קבצים — למרות שאני תמיד מוודא מול המקור לפני שפועלים לפי הזיכרון.
איפה נדרשת הכוונה:
- הוא יעצב-יתר אם נותנים לו. הנטייה הדיפולטיבית היא להוסיף הפשטות, לטפל במקרי קצה וליצור פונקציות עזר. הכללים ב-
CLAUDE.mdדוחפים נגד זה במפורש: בלי ספרייה למשהו שאפשר לעשות בכמה שורות, בלי ריפקטורינג מעבר למשימה הנוכחית, בלי פיצ'רים שלא התבקשו. - הוא לא יכול לבדוק ממשק משתמש. ב-React Native, הוא יכול לוודא נכונות טיפוסי TypeScript ולהריץ linters, אבל הוא לא יכול להפעיל סימולטור ולוודא שמסך השגיאה באמת מופיע. בדיקת ממשק המשתמש עדיין ידנית, והכללים דורשים הודאה מפורשת כשבדיקת UI לא נעשתה.
- זיכרון מיושן הוא דבר אמיתי. זיכרון שאומר "הפונקציה X נמצאת בשורה 157" היה מדויק כשנכתב. שלושה שבועות וריפקטור אחר כך, הוא עשוי להיות שגוי. הזיכרון הוא נקודת פתיחה, לא מקור אמת.
הזרימה בפועל
סשן טיפוסי:
- הפעלת Claude Code בתיקיית הפרויקט
- הזיכרון נטען אוטומטית (אינדקס MEMORY.md תמיד בהקשר)
- תיאור המשימה או מתן מספר פריט עבודה
- Claude שולף את פריט העבודה ממערכת המעקב, או שאני מתאר את הבאג ישירות
- שלב חקירה: קריאת קבצים רלוונטיים, מיפוי נתיבי קוד מושפעים (דרך Codex או סוכן Explore בהיקף גדול)
- קריאה ל-
advisor()לפני כתיבת כל דבר — מנתבת את השיחה המלאה למודל חזק יותר לחוות דעת שנייה - מימוש התיקון, הרצת linter/בודק טיפוסים
- האצלה לסוכן ביקורת הקוד לביקורת עצמאית
- הצגת הודעת commit לאישור לפני commit
- אני מוודא ידנית אם מעורב ממשק משתמש;
gh pr createכשמוכן לדחוף
שווה להריץ את הקריאה ל-advisor() בשלב 6 על כל דבר בעל מצב או אסינכרוני. בבאג של UserContext, היא סימנה את בעיית הקיבוץ ב-React עוד לפני ניסיון היישום הראשון. זה סוג התפיסה שחוסך סבב הלוך-חזור.
כמה מספרים
המספרים למטה מגיעים ישירות ממסד הנתונים SQLite של claude-mem — לא הערכות. הם מייצגים חודש קלנדרי אחד של עבודה על פני שש אפליקציות.
| מדד | ערך |
|---|---|
| סשנים מתועדים | 116 |
| תצפיות שמורות | 697 |
| סה"כ טוקני גילוי מתועדים | 4,674,038 |
| חיסכון טוקנים ב-context-mode | כ-94% לסשן |
| פרויקטים בשימוש פעיל | 6 אפליקציות (iOS + Android) |
| עלות מנוי | $20 לחודש, Claude Pro |
4.67 מיליון טוקני הגילוי מייצגים את העלות בפועל של כל העבודה שנעשתה — ניתוח ארכיטקטוני, חקירות באגים, יצירת קוד, ביקורות. הזיכרון מונע חזרה על העבודה הזו בסשנים עתידיים. תיקון race condition הרענון המבוסס-מונה, ניתוח הקיבוץ ב-React, ארכיטקטורת ה-widget של ZeekrPower — כולם שמורים, כולם ניתנים לחיפוש, אף אחד מהם לא צריך להיגזר מחדש.
לאן זה מוביל
הסיכום הכן: Claude Code על תוכנית של $20 לחודש הוא כלי שימושי באמת לפיתוח מובייל, אבל הוא דורש הגדרה מכוונת כדי להישאר כזה. התוספים (context-mode, caveman, claude-mem, האצלה ל-Codex) הם מה ששומר אותו בתוך התקציב. הכללים ב-CLAUDE.md הם מה ששומר אותו ממוקד. ביקורת הקוד העצמאית היא מה שתופס את הדברים שמצדיקים לעצמכם.
הדבר המרכזי ש-Karpathy צודק בו הוא שצוואר הבקבוק זז — לא ליצירת קוד, אלא לידיעה מה לבקש ואם מה שחוזר נכון. השיפוט הזה לא הופך לאוטומטי. הוא רק נעשה חשוב יותר.