איך עובדים חכם יותר עם קלוד קוד?
שמונה דברים שחוסכים זמן למי שכבר בונה לבד

נתחיל מכאן, כי הבלבול הזה משפיע על כל השאר.

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

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

ולמה זה טיפ מעשי ולא רק הסבר:

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

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

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

יש לזה שתי שכבות שעובדות יחד:

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

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

ומה כדאי שייכנס לשם:

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

סקיל הוא בעצם מדריך שמור למשימה שחוזרת על עצמה.

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

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

הדוגמה הכי טובה שיש לנו היא המאמר שאתם קוראים עכשיו.

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

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

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

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

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

• Sonnet הוא מודל העבודה היומיומי. בניית פיצ'ר, תיקון, שינוי רגיל. כאן כדאי להיות רוב הזמן.
• Opus למשימות שדורשות חשיבה מורכבת. באג שלא מצליחים לאתר או שינוי שנוגע בהרבה מקומות בבת אחת.
• Fable למשימות הקשות והארוכות ביותר, אלה שרצות הרבה זמן ברצף.
• Haiku מהיר וחסכוני, למשימות פשוטות וחוזרות שבהן מהירות חשובה יותר מעומק.

ויש כפתור שני שרוב האנשים לא יודעים שקיים: רמת המאמץ. היא קובעת כמה הכלי חושב לפני שהוא פועל ואפשר להזיז אותה בין נמוכה לגבוהה מאוד בלי להחליף מודל בכלל.

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

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

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

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

יש לזה שלוש רמות ושווה להכיר את ההבדל:

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

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

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

הסבב שעובד נראה כך:

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

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

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

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

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

ככל שתסבירו את הלמה ולא רק את המה, תצטרכו פחות סבבי תיקון.

שני הרגלים קטנים שחוסכים הרבה תסכול.

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

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

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

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

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