ביקורת קוד אוטומטית על כל Pull Request עם Claude Code

מאת צוות מדיה דיל · 08.08.2026 · AI · 8 דק׳

איך Claude Code סורק כל Pull Request ב-GitHub באופן אוטומטי, מאתר באגים ופרצות אבטחה, ומפרסם ממצאים כתגובות inline - בלי לחסום merge ובלי להחליף את הצוות.

כל צוות פיתוח מכיר את הרגע הזה: Pull Request נפתח, כולם עסוקים, וה-review נדחה ליום המחר. יום המחר הופך לשבוע, הבאג המשמעותי ששכב שם מתחת לשינוי הקטן מגיע ל-production, ורק אז מגלים שהוא היה שם כל הזמן. Claude Code מציעה פתרון שממוקד בדיוק בפער הזה: Code Review אוטומטי שרץ על כל Pull Request ב-GitHub, בלי שאף אחד יצטרך לבקש את זה, לזכור את זה או להריץ פקודה. זה לא כלי CI כללי וזה גם לא הרצה ידנית מהטרמינל - זו שכבת ביקורת שיושבת קבועה מעל ה-repository ומגיבה לכל שינוי קוד תוך דקות.

מה זה ביקורת קוד אוטומטית ואיזו בעיה היא פותרת

Code Review של Claude Code הוא פיצ'ר שמנתח Pull Requests ב-GitHub ומפרסם את הממצאים שלו כתגובות inline, ישירות על השורות הרלוונטיות בקוד. מאחורי הקלעים פועל צי של agents ייעודיים שבודקים את השינויים בהקשר של כל ה-codebase, לא רק את ה-diff המבודד. כל agent מתמקד בסוג אחר של בעיה, ואז שלב אימות נוסף בודק כל ממצא מול ההתנהגות בפועל של הקוד כדי לסנן false positives לפני שהם בכלל מגיעים לתגובה.

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

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

איך מפעילים את הביקורת האוטומטית

הפעלת הפיצ'ר היא פעולה חד-פעמית ברמת הארגון, ומי שמבצע אותה צריך להיות בעל תפקיד Owner או Primary Owner בארגון ה-Claude, וכן הרשאה להתקין GitHub Apps בארגון ה-GitHub הרלוונטי. התהליך המעשי נראה כך:

נכנסים להגדרות הניהול בכתובת claude.ai/admin-settings/claude-code ומאתרים את אזור ה-Code Review.
לוחצים על Setup, מה שפותח את תהליך התקנת ה-Claude GitHub App.
בוחרים את ארגון ה-GitHub ואת ה-repositories שהאפליקציה תקבל אליהם גישה, ומאשרים את ההרשאות המבוקשות - קריאת תוכן ה-repository וכתיבת תגובות ו-check runs על Pull Requests.
בוחרים אילו repositories מופעלים בפועל עבור Code Review, אפשר להוסיף עוד בהמשך.
עבור כל repository קובעים את "Review Behavior" - מתי הביקורת תרוץ.

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

Once after PR creation - ביקורת אחת בלבד, כשה-PR נפתח או מסומן כמוכן לסקירה.
After every push - ביקורת חדשה על כל push לענף ה-PR, כך שבעיות חדשות נתפסות תוך כדי התפתחות ה-PR, ותגובות שנפתרו נסגרות אוטומטית כשהתיקון עולה.
Manual - הביקורת רצה רק כשמישהו כותב תגובת @claude review על ה-PR.

אחרי ההגדרה כדאי לפתוח PR לבדיקה: אם נבחר מצב אוטומטי, אמור להופיע תוך דקות check run בשם "Claude Code Review". אם נבחר Manual, כותבים @claude review כתגובה עליונה (לא inline) כדי להתחיל את הביקורת הראשונה.

איך נראית התגובה בפועל

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

Important (סימון אדום) - באג שכדאי לתקן לפני מיזוג.
Nit (סימון צהוב) - בעיה מינורית, שווה לתקן אך לא חוסמת.
Pre-existing (סימון סגול) - באג שקיים כבר ב-codebase ולא נוצר בעקבות ה-PR הנוכחי.

כל ממצא כולל גם קטע reasoning שאפשר להרחיב, שמסביר למה הוא סומן ואיך אומת מול הקוד בפועל. חשוב מאוד: הממצאים לא מאשרים ולא חוסמים את ה-PR. ה-check run "Claude Code Review" תמיד מסתיים במסקנה neutral, כך שהוא לעולם לא עוצר merge דרך branch protection rules, גם אם נמצאו בעיות Important. אם רוצים לגייט מיזוג לפי ממצאים, צריך לקרוא את פילוח החומרה מתוך פלט ה-check run בתוך ה-CI העצמי, כולל שורת סיכום שניתנת לפירוק אוטומטי (machine-readable).

לצד התגובות ה-inline, ה-check run עצמו מציג טבלת סיכום של כל הממצאים ממוינת לפי חומרה, וגם בלשונית Files changed מופיעות אנוטציות ישירות על שורות ה-diff. זה שימושי כי לפעמים GitHub דוחה תגובת inline על שורה שזזה בין פושים, ואז הממצא עדיין נגיש דרך ה-check run או תחת כותרת "Additional findings" בגוף הביקורת.

כל תגובת ביקורת מגיעה עם כפתורי 👍 ו-👎 מוכנים מראש. לחיצה עליהם לא גורמת לביקורת חוזרת ולא משנה משהו ב-PR - היא רק עוזרת ל-Anthropic לכייל את המנוע. אם רוצים ביקורת חדשה בעקבות תיקון, פשוט דוחפים commit נוסף (אם ה-PR מנוי לביקורת על כל push), או כותבים שוב @claude review.

איך זה שונה מהרצת /code-review מקומית

ל-Claude Code יש גם פקודה מקומית, /code-review, שרצה בתוך session בטרמינל ומדווחת על באגי correctness וגם על הזדמנויות reuse, simplification ויעילות. ההבדלים בין שני המסלולים משמעותיים:

הביקורת האוטומטית ב-GitHub דורשת התקנת Claude GitHub App וזמינה בתוכניות Team ו-Enterprise (research preview, לא זמין לארגונים עם Zero Data Retention). לעומת זאת, /code-review זמין בכל התוכניות ורץ בלי להתקין כלום, ישירות מתוך session קיים.
הביקורת האוטומטית פועלת על Pull Request שלם ב-GitHub ומפרסמת תגובות ציבוריות שם. /code-review בודק את ה-commits של הענף הנוכחי ביחס ל-upstream, בתוספת שינויים לא committed, או יעד שמציינים במפורש - קובץ, מספר PR, ענף, או טווח refs.
/code-review לא קורא את קובץ REVIEW.md (שמותאם רק לביקורת האוטומטית), אבל כן פועל לפי CLAUDE.md כמו כל session רגיל.
/code-review רץ כברירת מחדל כ-subagent ברקע עם חלון הקשר משלו, כך שהוא לא ממלא את השיחה הפעילה, והממצאים חוזרים כשההרצה מסתיימת. יש לו גם דגלים ייעודיים: --fix שמיישם את הממצאים על ה-working tree, ו---comment שמפרסם אותם כתגובות inline על PR - כלומר גם המסלול המקומי יכול "לדבר" עם GitHub, אבל ביוזמת המפתח ולא באופן קבוע.
ניתן גם לכוון effort level ל-/code-review (low עד max, ואפילו ultra שמריץ ultrareview בענן), משהו שלא רלוונטי לביקורת האוטומטית - שם רמת העומק קבועה ומנוהלת מרכזית.

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

התאמה אישית עם CLAUDE.md ו-REVIEW.md

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

CLAUDE.md - קובץ ההוראות הכללי שמלווה כל שימוש ב-Claude Code, לא רק ביקורות. הביקורת קוראת אותו כהקשר פרויקט, ומסמנת הפרות חדשות שנוצרות ב-PR כממצאי Nit. זה עובד גם בכיוון ההפוך: אם השינוי בקוד הופך משפט ב-CLAUDE.md ללא מעודכן, הביקורת תסמן שגם התיעוד צריך עדכון.
REVIEW.md - קובץ ייעודי לביקורת בלבד, בשורש ה-repository, שמוזרק כמעט מילה במילה לתוך ה-prompt של כל agent בצינור הביקורת, בעדיפות הגבוהה ביותר - מעל ברירת המחדל. כאן אפשר לקבוע מחדש מה נחשב Important בהקשר של הריפו הספציפי, להגביל את כמות ה-Nits שמתפרסמים בביקורת אחת, לציין נתיבים או ענפים לדילוג (כמו קוד generated או ספריות vendored), להוסיף בדיקות ספציפיות לריפו (למשל "כל route חדש חייב טסט אינטגרציה"), לדרוש רף אימות מחמיר יותר לפני שממצא מתפרסם, ואפילו לקבוע איך הביקורת מתנהגת בסבב חוזר על אותו PR.

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

תרחיש שימוש בצוות אמיתי

תארו לעצמכם צוות פיתוח בינוני שעובד בסטארטאפ SaaS. יש שם שני מפתחי backend בכירים ושלושה מפתחים יותר ג'וניורים, וכולם דוחפים PRs במקביל. עד היום, כל PR חיכה ל-review של אחד הבכירים, ולפעמים זה לקח יום-יומיים כי הם עסוקים בפיצ'רים שלהם. עם הביקורת האוטומטית מוגדרת במצב "After every push" על ה-repository הראשי, כל PR מקבל תוך דקות ביקורת ראשונית שתופסת שגיאות לוגיות בסיסיות, בעיות security כמו שאילתות לא מסוננות לפי tenant, ו-edge cases שנשכחו. הבכיר שמבצע את ה-review האנושי כבר לא צריך לחפש את הבאגים הברורים - הם מסומנים באדום עם הסבר, ולפעמים גם תוקנו לפני שהוא בכלל פתח את ה-PR. הוא מתפנה להתמקד בדברים שבאמת דורשים שיקול דעת אנושי: ארכיטקטורה, החלטות מוצר, קריאות קוד ברמה גבוהה. הצוות גם הוסיף REVIEW.md קצר שאומר לביקורת להתעלם מקבצים ב-src/gen ומקבצי lock, ולהתייחס לכל הפרה של הרשאות multi-tenant כ-Important ולא כ-Nit ברירת המחדל. התוצאה בפועל: פחות זמן המתנה ל-review אנושי, פחות באגים שמגיעים ל-production, ותחושת בטחון גבוהה יותר גם אצל המפתחים הצעירים בצוות, שיודעים שיש שכבת ביקורת עקבית שלא תלויה בזמינות של מישהו. חשוב לציין שהמנגנון לא מחליף review אנושי - ה-check run תמיד ניטרלי ולא חוסם merge, אז ההחלטה הסופית עדיין אנושית.

עלות ומעקב שימוש

הביקורת האוטומטית מחויבת לפי צריכת טוקנים, וכל ביקורת עולה בממוצע 15 עד 25 דולר, בהתאם לגודל ה-PR, מורכבות ה-codebase וכמות הממצאים שדרשו אימות. החיוב נעשה דרך usage credits בנפרד מהשימוש הכלול בתוכנית, ולכן שווה להגדיר תקרת הוצאה חודשית בהגדרות claude.ai/admin-settings/usage לשירות "Claude Code Review" הספציפי. מצב ההפעלה שנבחר לכל repository משפיע ישירות על העלות: Once after PR creation רץ פעם אחת לכל PR, After every push מכפיל את העלות במספר הפושים, ו-Manual לא מייצר עלות עד שמישהו מבקש ביקורת בפירוש. הארגון יכול לעקוב אחרי הפעילות והעלות בלוח האנליטיקס בכתובת claude.ai/analytics/code-review, שמציג כמות PRs שנסקרו לאורך זמן, עלות שבועית, וכמה תגובות נפתרו אוטומטית בעקבות תיקון.

שאלות נפוצות

האם הביקורת האוטומטית יכולה לחסום merge של PR?

לא. ה-check run "Claude Code Review" תמיד מסתיים במסקנה neutral, כך שהוא לעולם לא חוסם מיזוג דרך branch protection rules, גם כשנמצאו ממצאים ברמת Important. אם רוצים לגייט מיזוג לפי הממצאים, צריך לקרוא את פילוח החומרה מתוך פלט ה-check run בתוך ה-CI העצמי.

מה קורה אם אני עונה לתגובה של הביקורת?

תשובה על תגובת inline לא גורמת לביקורת לענות או לעדכן את ה-PR. כדי לפעול על ממצא צריך לתקן את הקוד ולדחוף אותו. אם ה-PR מנוי לביקורת על כל push, ההרצה הבאה תסגור את ה-thread אוטומטית ברגע שהבעיה תוקנה. כדי לבקש ביקורת רעננה בלי push, כותבים @claude review כתגובה עליונה.

איזה הבדל בין @claude review ל-@claude review always?

@claude review (וגם @claude review once, שמתנהג אותו דבר) מפעיל ביקורת חד-פעמית בלי לרשום את ה-PR למנוי עתידי. @claude review always מפעיל ביקורת ומנוי גם את ה-PR לביקורות שיופעלו אוטומטית בכל push עתידי - שימושי כשרוצים ליזום מעקב צמוד על PR ספציפי בריפו שמוגדר במצב Manual.

האם הביקורת קוראת את REVIEW.md גם כשמריצים /code-review מקומית?

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

מה קורה אם הביקורת נכשלת או חורגת מזמן?

ריצות ביקורת הן best-effort. אם התשתית נתקלת בשגיאה פנימית או חורגת ממגבלת הזמן, ה-check run מסתיים עם כותרת שמציינת שגיאה או timeout, המסקנה עדיין neutral כך שכלום לא נחסם, אבל שום ממצא לא מתפרסם ואין ניסיון חוזר אוטומטי. כדי להריץ מחדש, כותבים @claude review כתגובה על ה-PR - כפתור Re-run בלשונית Checks של GitHub לא מפעיל את הביקורת מחדש.

האם הפיצ'ר זמין לכל תוכנית של Claude?

הביקורת האוטומטית נמצאת ב-research preview וזמינה רק לתוכניות Team ו-Enterprise, ואינה זמינה לארגונים עם Zero Data Retention מופעל. בתוכניות אחרות עדיין אפשר לקבל ביקורת קוד דרך הפקודה המקומית /code-review, שזמינה לכל משתמשי Claude Code.

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

תגיות: Claude Code Review · ביקורת קוד אוטומטית · Pull Request review · GitHub App Claude · REVIEW.md · code review AI · Claude Code GitHub

← חזרה לבלוג · צור קשר