אמא, שוב נגמר לי הקלוד

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

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

אז ישבתי לבדוק איך אנחנו עובדים.

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

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

מה זה בכלל טוקן

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

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

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

למה הקלוד נגמר

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

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

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

מה צורך הכי הרבה טוקנים

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

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

מה שקרה לנו בפועל

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

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

השנייה, שיחה יקרה. אזור אישי IEC, מסכי שירותים. השיחה כללה בניית mockup אינטראקטיבי עם חמישה מסכים ב-HTML, ואז סדרה של סיבובי עדכון: החלפת קומפוננטות מ-bubbles לכרטיסים, הוספת accordion, הוצאת פעולות, הוספת toggle לשבת, שינוי ניווט. כל סיבוב כזה אומר שקלוד קורא את כל הקובץ, חמש-מאות עד שמונה-מאות שורות, מוצא את המקום הנכון, כותב את השינוי, ובמקביל קורא את כל היסטוריית השיחה שהצטברה. שיחה אחת כזו שווה בעלותה לעשרים עד שלושים שיחות קופי.

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

כמה זה עולה, בסדרי גודל

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

סוג שיחה	עלות יחסית
שאלת ניסוח או קופי קצר	x1
עריכת טקסט עם הערות	x3-5
בניית mockup ב-HTML או React	x20-30
בניית mockup ועוד חמישה סיבובי תיקון	x50-80
מסמך שלם מודבק, עריכה, והמרה ל-docx	x30-50

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

חמישה הרגלים

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

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

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

מה לעשות ומה לא

לעשות:

• לפתוח שיחה חדשה לכל נושא
• להעלות קבצים במקום להדביק חתיכות
• לדון לפני שבונים
• לעבוד ב-markdown עד שסוגרים
• להעביר עבודה כבדה לקלוד קוד או קו וורק

לא לעשות:

• שיחה אחת ארוכה עם שלושים סיבובים על כמה נושאים
• בניית docx ואז "תשנה מילה"
• עבודה כבדה על מוקאפים וקוד בצ'אט, כשאפשר בכלי שנבנה לזה

מה שיצא מזה

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

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

הכלי יודע להסביר את עצמו. רק צריך לבקש ממנו.