קריאת קוד ידנית היא רעיון יפה עד שמכונה מתחילה להקליד במקומכם. במונורפו הראשי של אנתרופיק נרשם זינוק מ-2,500 שינויים ביום במאי ליותר מ-30,000 שינויים ביום בספטמבר האחרון. Claude כותב כ-90% מקוד המקור של הכלי Claude Code. אם מישהו באמת היה יושב לקרוא את כל השורות האלה בעיניים, המוצר פשוט היה קופא.
בפוסט טכני שפרסם צוות הפיתוח של Claude Code ב-15 באוקטובר 2026, החברה חשפה את שיטת סקירת הקוד שלה. המסקנה העיקרית שלהם חדה: לנסות להכריח מהנדס לקרוא כל שורת קוד שסוכן מייצר זה בזבוז זמן מסוכן. במקום שער בדיקה ידני בסוף התהליך, אנתרופיק עברה למערך בדיקות רב-שכבות שבו רוב הקוד מתמזג בלי שום מגע יד אדם.
לקרוא כל שורה זה מתכון לקריסה
סקירת קוד מסורתית נועדה לשני דברים: למצוא באגים ולבנות הבנה משותפת של המערכת בצוות. אלא שבעבודה מול סוכנים אוטונומיים, בדיקה אנושית יסודית הופכת לפקק תנועה בלתי אפשרי. כשהסוכן פולט עשרות שינויים בשעה, בני אדם הופכים במהירות לחותמת גומי או פשוט מתעלמים מהפרטים החשובים.
באנתרופיק החליטו להגדיר מחדש את המטרה. סקירת קוד היא ניהול סיכונים סטטיסטי: מה עלול להישבר כאן, ואיזו מכונה יכולה לתפוס את זה במקום מתכנת. המשאב היקר ביותר הוא תשומת הלב של המהנדסים, ואותה שומרים רק למקומות שבהם מודל שפה עיוור להקשר המערכתי הרחב.
לא הייתי ממהר לבטל בדיקות אנושיות לפני שיש תשתית כזאת.
לפני שפותחים בכלל PR
השינוי המהותי ביותר מתרחש עוד במחשב של המפתח, לפני שמישהו פותח בקשת מיזוג (PR). באנתרופיק לא סומכים על הצהרות של הסוכן שהוא סיים. לתת לקלוד דרך לאמת את העבודה שלו זה ככל הנראה הדבר החשוב ביותר כדי להגיע לתוצאות טובות, כתב בוריס צ'רני (Boris Cherny), יוצר הכלי, ולפי הערכתו זה משפר את התוצאה הסופית פי שניים עד שלושה.
לפי מסמכי Best practices של Claude Code, ההמלצה המרכזית היא לספק לסוכן בדיקה שהוא יכול להריץ בעצמו: להריץ טסטים, לנסות לקמפל, או להשוות צילומי מסך לעיצוב המקורי, ולהציג את הפלט המלא. רק אחרי שהבדיקות עברו, סוכן משני נכנס לפעולה עם חלון הקשר נקי כדי לסקור את ה-diff באופן עצמאי. כללי המשחק מוגדרים בשני קובצי Markdown קצרים: CLAUDE.md שמגדיר את הקונבנציות והטכנולוגיות של הפרויקט, ו-REVIEW.md שנכתב על ידי מובילי הקוד וקובע אילו שגיאות נחשבות קריטיות באותו מאגר.
חלוקה לפי רמת הסיכון
ברגע שה-PR נפתח, מנגנון סיווג אוטומטי קובע את רמת הסיכון של השינוי. הוא בודק אילו קבצים נגעו ואיך. שינויי תיעוד, עדכוני טקסט, פיצ'רים פנימיים או שינויים מוסתרים מאחורי דגלי פיצ'ר מסווגים כסיכון נמוך. אם כל הבדיקות האוטומטיות והסריקות של Code Review for Claude Code עברו, הם יתמזגו בלי שום אישור אנושי.
קוד מוצר רגיל או שינויים במנגנונים רגישים כמו Caching, עדכוני מערכת או פרומפטים מסווגים כסיכון בינוני ודורשים אישור אנושי אחד. כאן מגיע הכלל המעניין של אנתרופיק: מי שהפעיל את הסוכן ונתן לו את הפרומפט נחשב למאשר הראשון. שינויים בסיכון גבוה ביותר, או כאלה שנוגעים בקובצי תשתית ו-CI, דורשים שני מאשרים אנושיים נפרדים. סוכן AI לעולם אינו נספר כמאשר אנושי.
| רמת סיכון | דוגמאות לסוג שינוי | אישור אנושי נדרש | תנאי סף למעבר |
|---|---|---|---|
| נמוך (Low) | תיעוד, קופי, פיצ'רים פנימיים, שינויים תוספתיים תחת Feature Flag | ללא צורך באדם | בדיקות CI ירוקות וסריקות AI ואבטחה שעברו ללא ממצאים פתוחים |
| בינוני (Medium) | שינויי מוצר רגילים, מטמון, מנגנון עדכון אוטומטי, פרומפטים של המערכת | אדם אחד (מפעיל הסוכן נספר כמאשר) | אישור אדם אחד |
| גבוה (High) | קוד בעל השפעה רוחבית, קובצי הגדרות CI ונתיבים שהוגדרו רגישים | שני בני אדם | אישור שני אנשים |
הזווית הזו כבר מעסיקה צוותים מקומיים. בישראל, מפתחים בונים עטיפות עצמאיות סביב Claude Code, כמו כלי הקוד הפתוח Claude Duet של מהנדסים בוויקס או התאמות לממשקי VS Code בעברית.
מלכודת הלולאה האינסופית
כאשר מפגישים סוכן שכותב קוד עם סוכן שסוקר אותו, המערכת עלולה להיכנס למלכודת מסחררת. באנתרופיק מתארים מקרה שבו בקשת מיזוג של כלי ה-CLI עברה יותר מ-50 סבבים של תיקונים והערות במהלך לילה אחד, כשהסוכנים מתווכחים ביניהם בלי סוף עד שמחבר השינוי עצר את התהליך.
כשבדקו באנתרופיק באמצעות git blame על מה הסוקר המשיך להעיר, כ-59% מההערות היו על קוד שהיה שם עוד מהסבב הראשון שלו. הסוקר כמעט ולא מצא באגים חדשים, הוא פשוט מצא עוד כמה באגים ישנים בכל סיבוב.צוות ההנדסה של Claude Code בפוסט המקורי
כדי להתגבר על הרעש, החברה הכניסה מנגנון סינון קפדני: מספר סוכנים בודקים באגים במקביל, וסוכנים אחרים מצביעים האם הממצא אמיתי. הערות עיצוב או סגנון נמחקות אוטומטית. מעבר לכך, מפתחים נדרשים להגביל מראש את כמות הסבבים המותרת של הסוכן או לעצור ידנית ריצות שמתבדרות.
הנתונים היפים והשאלות שנשארו פתוחות
לפי החברה, המערך החדש הכפיל את כמות ה-PRs שהתמזגו בין יוני לספטמבר, בעוד ששיעור הביטולים (reverts) ירד ביותר מ-40%. מדובר במדידה פנימית בלבד ללא ביקורת חיצונית, בארגון שבונה בעצמו את המודל ולכן מניעיו ברורים.
מעבר לכך, יש שתי בעיות עמוקות שהפוסט של אנתרופיק עוקף באלגנטיות. הראשונה היא שחיקה ארכיטקטונית (Architectural Decay). כשאיש אינו קורא פיצ'רים שלמים מקצה לקצה, קשה לזהות כפילויות לוגיות או החלטות עיצוביות עקומות שמצטברות לאורך חודשים. הבעיה השנייה היא הדור הבא: אם מפתחים צעירים לא מבצעים סקירות קוד בסיסיות, לא ברור איך הם ירכשו את הראייה המערכתית הדרושה כדי לקבל החלטות מורכבות בעוד שלוש שנים.
זה שווה רק אם יש לכם תקציב ענן בלתי מוגבל.
עלויות הטוקנים הן הפיל שבחדר. הרצת בדיקות מרובות וסוכני שיפוט על כל commit דורשת תקציב API לא מבוטל. עבור אנתרופיק הטוקנים הם בחינם; עבור סטארט-אפ ישראלי ממוצע, חשבון ה-CI עשוי לתפוח לממדים שימחקו את החיסכון בשעות הפיתוח.
מה כדאי לאמץ מחר בבוקר
גם בלי להקים מערכות ענק, צוותי פיתוח יכולים ליישם את העקרונות האלה מיד. הצעד הראשון הוא להפסיק לבדוק בעיניים שינויי מלל ותיעוד. אם יש לכם טסטים ולינטר תקינים, אין שום סיבה שמהנדס ישרוף עשר דקות על אישור של תיקון שגיאת כתיב.
הצעד השני הוא לחייב את הסוכן להריץ בדיקות לפני יצירת ה-diff ולהוסיף קובץ הנחיות קצר לסביבת העבודה. הדגש בתעשייה עובר מקריאת קוד איטית ליכולת ביטול מהירה (Fast Rollback) ושימוש ב-Feature Flags. עדיף להשקיע במנגנון שמבטל תקלה בשתי שניות מאשר לקוות שמהנדס עייף יתפוס אותה בחצות. בינתיים, כפתור ה-Revert עדיין עובד מצוין.
מקורות
- How the Claude Code team does code reviewhttps://claude.dev/blog/solving-code-review-at-anthropic/
- Best practices for Claude Code - Claude Code Docshttps://code.claude.com/docs/en/best-practices
- Code Review for Claude Codehttps://code.claude.com/docs/en/code-review
- Claude Codehttps://weba.co.il/tools/claude-code/
הידיעה נכתבה מהמקורות שלמעלה בתאריך הפרסום, וכל טענה בה נבדקה מולם. מצאתם טעות? כתבו.