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

בראיון ל-Root Access של Y Combinator נשאל בוריס צ’רני, יוצר קלוד קוד ומי שמוביל אותו באנתרופיק, מה אנשים לא עושים נכון בעבודה עם הכלי. התשובה שלו לא הייתה על ניסוח: “האימות הוא כנראה הדבר החשוב ביותר שאנשים לא עושים נכון.”

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

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

מה בכלל נחשב בדיקה?

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

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

ארבע דרגות, מהקלה לחזקה

• בתוך הפרומפט: מבקשים באותה הודעה להריץ את הבדיקה ולתקן עד שהיא עוברת. עובד על כל משימה, היום, בלי שום הגדרה מוקדמת
• כתנאי לסשן: הפקודה ‎/goal‎ מגדירה קריטריון הצלחה שמוערך מחדש אחרי כל תור, וקלוד ממשיך לעבוד עד שהוא מתקיים
• כשער דטרמיניסטי: hook מסוג Stop מריץ את הבדיקה כסקריפט וחוסם את סיום התור עד שהיא עוברת. קלוד קוד גובר עליו ומסיים את התור אחרי שמונה חסימות רצופות
• כדעה שנייה: סוכן משנה או workflow שבודק את התוצאה, כך שמודל טרי מנסה להפריך אותה — ומי שעשה את העבודה אינו מי שנותן לה ציון

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

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

ומה שחשוב לומר ביושר

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

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

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

שורה תחתונה

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

המדריך המלא — איך כותבים תנאי סיום שמחזיק, מה המעריך של ‎/goal‎ באמת רואה, ואיפה אימות הופך להנדסת יתר — נמצא באימות בקלוד קוד.

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