איך צוות Claude Code עורך סקירת קוד: שבעה שלבים וללא מפסקי מעגל

ב-15 באוקטובר 2026 פרסם צוות Claude Code את התיאור שלו עצמו כיצד הוא סוקר קוד, פוסט הנדסי בן ארבע עשרה דקות המיוחס ל-Addy Osmani, Morgan Westlee Lunt ו-Qing Wang. המשפט שמסביר מדוע מישהו בכלל מחפש את זה מופיע מוקדם: Claude כותב כ-90 אחוז מהקוד של Claude Code עצמו. הפוסט אינו הגנה על המספר הזה אלא תיאור של המכונות שהיו חייבות להתקיים מתחתיו לפני שאפשר היה לשרוד אותו, והחלקים שכדאי לקרוא מקרוב הם דווקא אלה שעדיין חסרים.

רוב הסיכומים עוצרים בשני מספרי הכותרת: בקשות מיזוג (pull requests) למאגר הקוד של Claude Code יותר מהוכפלו בין יוני לספטמבר 2026, בעוד ששיעור אלה שנאלצו לבטל (revert) ירד ביותר מ־40 אחוז. שניהם מגיעים מהצוות עצמו, ושניהם יכולים להיווצר בכמה הסדרים שונים, כולל זה שאנשים מניחים — שריוויו הוסר בשקט. הפוסט אומר שזה לא קרה. הם העבירו את רוב הקריאה למכונות, עשו אופטימיזציה לזמן ולקשב של בני האדם, והשקיעו בכך שטעויות יהיו מהירות וקלות לביטול. כל השאר הוא הפרטים של איך.

למה הסקירה הפכה מלכתחילה לצוואר הבקבוק

הלחץ לא נבע מהחלטת מדיניות. הוא נבע מנפח. במונורפו של Anthropic, כך מדווח הפוסט, מספר השינויים שנקלטו מדי יום עלה מכ-2,500 במאי ליותר מ-30,000 בספטמבר 2026. Claude Code נמצא במאגר משלו, נפרד מאותו מונורפו, אך הוא נתון לאותו לחץ בהיקף קטן יותר.

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

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

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

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

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

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

שבעה שלבים, לא שער אחד

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

• אימות לפני שה-pull request קיים. Claude מריץ את הבדיקות, את הבנייה ואת ה-linter, וסוכן שני סוקר את ה-diff בהקשר חדש. מהנדסים רבים מריצים גם מיומנויות פנימיות: אחד מחפש באגים, אחד מפשט את ה-diff, ואחד בודק התנהגות מקצה לקצה. Boris Cherny, שיצר את Claude Code, כינה את מתן הדרך ל-Claude לאמת את עבודתו בעצמו ככנראה הדבר החשוב ביותר לתוצאות טובות, ומעריך שזה משפר את התוצאה הסופית פי שניים עד שלושה.

• סקירת AI בכל בקשת משיכה. סקירה של Claude קוראת את ה-diff מול כל המאגר ואת הכוונה המוצהרת של בקשת המשיכה. כמה סוכנים מחפשים באגים במקביל, ואז קבוצה נפרדת מצביעה על כל ממצא, והוא מפורסם רק אם מספיק מסכימים שהוא אמיתי. ממצאים לגבי סגנון, אבחון או ניקוי נזרקים. מה ששורד מופיע כהערות מוטבעות המסומנות Important, Nit או Pre-existing. כשתצוגת המחקר הושקה, שיעור בקשות המשיכה הפנימיות שזכו להערות סקירה מהותיות עלה מ-16 אחוז ל-54 אחוז. מנהלים מגדירים כל מאגר כ-Quick, Standard או Deep.

• סקירת אבטחה. מעבר אוטומטי נפרד. לא ניתן למזג בקשת משיכה כל עוד ממצא מאחת הסקירות פתוח; מתקנים אותו או סוגרים את השרשור עם נימוק קצר. אותה בדיקה זמינה לציבור בתור GitHub Action לסקירת אבטחה בקוד פתוח או בתור הפקודה /security-review.

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

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

• תור מיזוג, דגלים ושחרור הדרגתי. התור מריץ מחדש כל בדיקה מול main כשהשינוי מיושם, כך ששני pull requests שכל אחד מהם עובר לא יכולים להשתלב ל-main שבור. התנהגות חדשה נשלחת מאחורי דגל קודם לעובדי Anthropic, ואז לערוץ latest, כאשר stable מפגר אחריו.

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

השינוי קובע את הרמה, לא את המחבר

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

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

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

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

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

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

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

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

השכבה שטרם נבנתה

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

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

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

התפקיד השני של Review, שאותו הפוסט ברובו מניח בצד

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

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

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

היכן נתב מתאים, והיכן לא

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

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

הגבול הזה חשוב. אנחנו מארחים מודלים. אנחנו לא מארחים את Claude Code, אנחנו לא מריצים Code Review for Claude Code, ואין לנו גישה ל-pipeline שעליו המאמר הזה מדבר. Code Review for Claude Code הוא מוצר של Anthropic, הזמין באופן כללי בתוכניות Team ו-Enterprise, עם גרסה קלה יותר הזמינה באופן מקומי בתור ‎/code-review. אם מה שאתם רוצים הוא ה-pipeline הזה, שם הוא נמצא; בגרסה שלו אצל הצוות שלכם, router הוא החלטת תשתית ולא החלטת סקירה.

מה שצוות קטן יותר יכול למעשה להעתיק

רשום את כללי הביקורת במקום שבו הסוקר יכול לקרוא אותם: קובץ CLAUDE.md קצר לפרויקט, ו-REVIEW.md לכל אזור שמפרט איך נראה כשל ודורש קובץ ושורה במקום ניחוש. העלה את דרגות הסיכון על הכתב, הפוך אותן לתכונה של השינוי ולא של המחבר, התחל בקפדנות ורפה רק עם ראיות. הגבל מה שביקורת אוטומטית רשאית לאשר, ולעולם אל תיתן לאישור של סוכן להיחשב כאישור של אדם. קשר אישורים לקומיטים. הרץ את תור המיזוג. הפוך תקלות והחזרות אחורה (reverts) למקרי בדיקה, ותן ציון מחדש לסוקר בכל פעם שאתה משנה אותו, כי סוקר שאינו נמדד הוא linter עם שיווק טוב יותר.

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