איך צוות הפיתוח של קלוד קוד בודק את הקוד של קלוד

ב-15 באוקטובר 2026 פרסמו שלושה אנשים מאנתרופיק פוסט ארוך על האופן שבו צוות קלוד קוד בודק קוד. נקודת המוצא שלהם: קלוד כותב כ-90% מהקוד של קלוד קוד עצמו. כשהמכונה כותבת את רוב הקוד, אדם שקורא כל שורה הופך לצוואר הבקבוק.

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

מה יצא מזה, לפי אנתרופיק?

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

מה עובר על שינוי לפני שאדם מאשר אותו?

הפוסט מתאר שבע שכבות. רובן לא דורשות אדם בכלל:

1. אימות לפני ה-PR: קלוד מריץ טסטים, בנייה ו-linter ומציג את הפלט, לא רק מודיע שסיים. סוכן משנה בקונטקסט נקי עובר על הדיף
2. CI חובה: אדום חוסם מיזוג
3. בדיקת AI על כל PR: כמה סוכנים מחפשים באגים במקביל, קבוצה נפרדת מצביעה על כל ממצא, ורק מה שמספיק מהם מסכימים שהוא אמיתי מתפרסם. הערות סגנון נזרקות. כל ממצא צריך תיקון או סגירה עם סיבה
4. בדיקת אבטחה שחוסמת: PR לא נכנס כל עוד יש ממצא פתוח
5. אישור אנושי לפי רמת סיכון: פירוט בהמשך
6. merge queue, דגלים ושחרור מדורג: פיצ’ר חדש נפתח קודם לעובדי אנתרופיק, והגרסה יוצאת לערוץ latest לפני stable
7. זיהוי מהיר וחזרה אחורה: דגל נכבה בלי פריסה חדשה

מי מחליט כמה אנשים צריכים לאשר?

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

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

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

מה עושים כשהבודק האוטומטי לא מרפה?

זו בעיה שכל מי שהפעיל בודק AI על הדיפים שלו פגש. PR אחד בקלוד קוד עבר יותר מחמישים סבבי בדיקה ותיקון בלילה אחד, עד שהכותב עצר אותו. כשהם הריצו git blame על מה שהבודק המשיך לסמן, כ-59% מזה היה קוד שהיה שם כבר בסבב הראשון.

התיקונים שלהם פשוטים להעתקה:

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

התוצאה, על PRs פנימיים: שיעור ה-PRs שעוברים אחרי סבב בדיקה ותיקון אחד עלה מ-65% ל-78%, ואלה שצריכים חמישה סבבים ומעלה ירדו מ-8.9% ל-1.5%.

איך משפרים את הבודק עצמו?

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

מה זה REVIEW.md, ולמה כדאי לכתוב אחד?

בשירות Code Review יש שני קבצי הוראות. ‎CLAUDE.md‎ מתאר את הפרויקט, וכל בדיקה קוראת אותו. ‎REVIEW.md‎, לפי התיעוד, הוא הוראות לבדיקה בלבד: מה לסמן, באיזו חומרה, ומה לדלג. הוא יושב בשורש המאגר, ואפשר להוסיף עוד אחד בתת-תיקייה, עם כללים נוספים לנתיב הזה.

לפי הפוסט, קובץ טוב הוא קצר, ועושה ארבעה דברים:

• אומר איך נראה כישלון במאגר הזה: במאגר תיעוד זה ״הוא משקר״, במאגר קונפיגורציה זה ״הוא מנתב לא נכון״
• מגביל את כמות ה-nits
• מפרט נתיבים לדלג עליהם: קבצים שנוצרים אוטומטית, lockfiles, מה שה-CI כבר בודק
• דורש קובץ ושורה כראיה, לא ניחוש מתוך שם של פונקציה

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

שימו לב לפער אחד: ‎/code-review‎ המקומית קוראת רק את ‎CLAUDE.md‎, לא את ‎REVIEW.md‎. הנחיה שצריכה לחול בשני המקומות שייכת ל-‎CLAUDE.md‎. פירוט בטיפ על הפקודה.

איפה אנשים עדיין חייבים להיות?

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

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

מה מעתיקים מחר בבוקר?

מתוך רשימת האימוץ שבסוף הפוסט, אלה הצעדים שלא דורשים שום מוצר בתשלום:

• בדיקות שהסוכן יכול להריץ, ברשימה קצרה ב-‎CLAUDE.md‎, ו-hooks שמריצים formatter ו-linter
• בדיקה מקומית לפני PR: ‎/code-review‎ ו-‎/security-review‎, או סוכן משנה בקונטקסט נקי
• תבנית PR עם שלושה שדות: טסטים, סיכון, ואיך מחזירים אחורה
• רמות סיכון כתובות שנקבעות לפי השינוי ולא לפי הכותב. מתחילים מחמיר ומקלים עם ראיות
• CODEOWNERS והגנת ענפים על אימות, חיוב, workflows של CI ושחרורים
• ומדד אחד: הזמן שאנשים משקיעים בבדיקה, עם reverts ותקלות כקו אדום

שורה תחתונה

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