בוקר טוב.
מזה זמן רב שלא כתבתי כאן, והנה – סוף סוף חזרתי. הפעם בנושא שונה מ־GNOME. אני רוצה לשתף תובנות מתהליך פיתוח באמצעות Claude Code.
לפני חצי שנה התחלתי לפתח בזמני הפנוי מערכת ניווט מבוססת תמונות ב־Go. כיוון שהזמן הפנוי שלי מוגבל, החלטתי לפתח באופן בלעדי בסיוע AI/LLM, גם כניסוי – לראות אם זה אפשרי. כבר בתכנון הראשוני לקחתי את זה בחשבון, והחלטתי לעבוד ב־DDD עם Clean Architecture לכל דומיין. המטרה הייתה לאפשר לי למקד את ה־LLM בכל שלב במשימה קטנה עם הקשר (Context) מצומצם ככל הניתן. בדיעבד, זו הייתה החלטה נהדרת.
כמה ימים אחרי תחילת התכנון (שביצעתי ברצינות עם Claude – מסמכי ADR, תכנון ארכיטקטורה ב־C4, ישויות ולוגיקה עסקית), גיליתי את Claude Code. בתור מפתח שה־IDE שלו הוא vim עם המון הרחבות, התלהבתי מהכלי. הוא באמת מדהים. עד היום אני מפתח איתו.
שבוע של תכנון, שלושה שבועות לצד שרת, שבועיים וקצת לצד לקוח – וזהו, היה לי MVP באוויר. שם בערך עצרתי, בתחילת החגים. לפני שבועיים חזרתי לפרויקט והתחלתי לפתח שרת קטן שמבצע עיבוד תמונה (אימות, פענוח, זיהוי פנים ולוחות זיהוי, טשטוש והעלאה לשרת).
בכל הפיתוח, כמעט לא כתבתי שורת קוד אחת בעצמי. למדתי המון, עשיתי לא מעט טעויות בדרך, וכמובן למדתי גם מהן.
לפני שאמשיך, חשוב לי להתייחס לתופעת „הפיתוח האוטונומי” – להקות של סוכנים (Agents) שעובדים במקביל על משימה גדולה ובונים פרויקט לבד. אני לא מאמין בזה! מהניסיון שלי (ובאמת ניסיתי), כדי לקבל קוד איכותי, קריא וניתן לתחזוקה, כזה שלא נצטרך לשכתב כל שנה, חייבים לעבוד אחרת: בצעדים קטנים ומדודים.
לשיטתי, תפקיד המפתח הוא לתכנן, לקבל החלטות, לכוון ולאשר כל דבר. התוצאה היא קוד איכותי מאוד, במהירות מדהימה.
אני לא ממציא את הגלגל; מרבית העקרונות נמצאים בהמלצות הרשמיות של אנת׳רופיק, עם התאמות וקפדנות יתרה שלי.
לפני שנצלול לשיטה, קצת על המגבלות: ל־LLM יש מגבלת זיכרון (חלון הקשר של כ־200K טוקנים), אין לו זיכרון לטווח ארוך, הוא נוטה להזות כשמערבבים נושאים, והוא אומן על מידע לא מושלם.
כדי לקבל קוד איכותי ומדויק צריך לעבוד בצורה שיטתית:
- ניהול זיכרון – סטטי, דינמי וכלכלת הקשר: הבסיס לשיטה הוא ההבנה שלמודל אין זיכרון בין שיחות. הפתרון:
- זיכרון קבוע (CLAUDE.md): קובץ שנטען תמיד ומכיל מידע בסיסי שהמודל חייב לדעת (ארכיטקטורה, פקודות, סטנדרטים).
- זיכרון דינמי (ai-docs/): תיקייה עם מסמכים לפי נושא. אם עובדים על נושא X, טוענים רק את מסמך האפיון שלו. זה מונע „בלבול” מעודף מידע.
- ניקוי רעשים: סיימנו שלב? מוחקים היסטוריה. תוכנית הסתיימה? הקובץ נמחק (git rm) כדי לא לבלבל את המודל עם הוראות ישנות.
- סוכנים (Agents) כ„חלון זיכרון”: אחת הבעיות הגדולות היא „זיהום הקשר” – פלט של פקודות בנייה ושגיאות שממלאים את הזיכרון. הפתרון: כמעט כל משימה מתבצעת בתוך Agent משלה. הסוכן משמש מעין חלון זיכרון מבודד. צריך לחקור ספרייה? פותחים Agent מחקר. צריך לממש פונקציה? פותחים Agent מימוש. הסוכן רץ בלולאה של ניסוי וטעייה, וחוזר לשיחה הראשית רק עם השורה התחתונה: „השלמתי, הנה השינויים”. כך השיחה הראשית נשארת נקייה וממוקדת בקבלת החלטות.
- תהליך הפיתוח בתמצית: SDD (פיתוח מונחה אפיון) -> IDD (פיתוח מונחה ממשקים) -> TDD (פיתוח מונחה בדיקות).
בשילוב עם ארכיטקטורה מודולרית והפרדה קשיחה, מקבלים שיטה סדורה לייצור קוד איכותי.
התהליך בפירוט:
- מחקר ואפיון: כתיבת מסמך מפורט בזיכרון ארוך הטווח (ai-docs/research/).
- תיעוד החלטות: כתיבת מסמך ADR במידה והתקבלה החלטה במהלך המחקר (ai-docs/adr/).
- תכנון מימוש מפורט: כתיבת מסמך תכנון על בסיס מסמך המחקר (ai-docs/planning/active/).
- מימוש:
- כתיבת ממשקים (Interface): הגדרה מראש של מה רוצים לממש (חתימת פונקציה, קלט/פלט, שגיאות).
- כתיבת בדיקות (Tests): כתיבת בדיקות כושלות מול הממשק.
- מימוש הממשקים: כדי שהבדיקות יעברו.
- שיפור: תוך שמירה שהבדיקות עוברות.
הערה: בשלב המימוש אני משלב כלי קריטי – בדיקות סטטיות (Static Analysis). כל קוד חייב לעבור בדיקות קפדניות. התוצאה היא לולאת משוב שבה ה־Agent מתקן את עצמו עד שהקוד תקין לחלוטין. בנוסף, עם כל שינוי מתבצעת הרצה של כל הבדיקות של הפרויקט כולו, לוודא שלא שוברים שום דבר בדרך.
הדבר החשוב ביותר הוא שאני כמפתח מאשר כל תוצר בכל שלב לפני התקדמות לשלב הבא: מסמך מחקר, תוכנית, ממשק, בדיקות וקוד. הניסיון לימד אותי שהשקעה בקריאת התוצרים מחזירה את עצמה; איפה שחיפפתי – שילמתי ביוקר.
למעשה, התפקיד שלי השתנה לחלוטין. אני כבר לא „כותב קוד”, אלא מתכנן, מקבל החלטות ומבקר איכות.
וכדי לעשות את זה טוב, צריך ידע וניסיון רב. להבין לעומק Clean Architecture ו־DDD, להבין טיפול בשגיאות, IDD ו־TDD – דורש הבנה מעמיקה.
לסיכום, יש לי תובנה ברורה: גם עם המודלים המתקדמים ביותר (כמו Claude Opus 4.6), אנחנו עדיין צריכים מפתחים. אבל איזה מפתחים? כאלה שמבינים ארכיטקטורה, ניהול מערכת גדולה וקבלת החלטות, וכן כאלה שיכולים להכיל ולהבין כמויות מידע גדולות מאד בזמן קצר. מפתחים עם הידע הזה והכישורים האלה יכולים היום לבנות מערכות גדולות ומורכבות באיכות גבוהה ובזמן קצר. מי שאין לו את הידע הזה ולא ישכיל ללמוד אותו בהקדם, ימצא את עצמו בבעיה בשלב כזה או אחר.
מצורף קישור למסמך טכני יותר שכולו נכתב על ידי Claude Code, באנגלית.