8.3 סקירה ואחריות הרצאה

יש עיקרון אחד שלא משתנה בין עידן שבו כתבתם כל שורה בעצמכם לבין עידן שבו agent כותב רוב הקוד עבורכם: כשאתם עושים merge, הקוד הוא שלכם. לא של הagent, לא של המודל שמאחוריו, לא של "ה-AI". שלכם - עם השם שלכם ב-git blame, עם התפקיד שלכם באחריות לתקלה, ועם השיחה שתצטרכו לנהל אם משהו נשבר בפרודקשן. בהרצאה הזו נדבר על מה שקורה אחרי שהagent מציע פתרון: משמעת הסקירה, מה זה אומר "להבין" קוד לפני שממזגים אותו, ולמה אחריות מקצועית לא מתחלקת עם tool.

מי אחראי כשקוד AI נכשל

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

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

The dangerous thought: "The agent wrote this confidently, it looks
like it knows what it's doing, it's probably fine."

The correct thought: "I'm about to run this for real - I need
to understand it at the same level as if I had written it myself."

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

משמעת סקירה - review discipline

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

רשימת בדיקה מעשית לסקירת קוד שנכתב על ידי agent:

שאלה	למה לבדוק
האם אני מבין כל שורה, לא רק את הכיוון הכללי?	הבנה חלקית = לא תוכלו לתקן כשזה ישבר
האם הקוד עושה בדיוק את מה שביקשתי, לא משהו "דומה"?	הנחות סמויות מהמודל עלולות להסיט את הפתרון
האם נבדקו מקרי קצה - ריק, null, גבולות, עומס?	ראינו בהרצאה 8.1 שאלה בדיוק המקומות שנשברים בשקט
האם יש בדיקות שמוכיחות שזה עובד, לא רק תיאור מילולי?	דרשו הוכחה, לא הצהרה
האם הקוד תואם את הסגנון והמוסכמות של שאר הפרויקט?	קוד לא אחיד מקשה על תחזוקה עתידית
האם יש תלות חדשה שנוספה בלי שהתכוונתי לזה?	הagents לפעמים מוסיפים ספרייה כדי "לפתור מהר"
האם משהו נמחק או שונה מעבר למה שביקשתי?	שינוי לא מכוון בקובץ אחר קל לפספס בסריקה מהירה

הגישה הנכונה היא לקרוא את ה-diff שורה-שורה, בדיוק כמו שהייתם קוראים PR של מתכנת חדש בצוות שאתם לא מכירים עדיין - עם אותה רמת חשדנות בריאה, לא פחות.

סקירה בחתיכות קטנות, לא בבת אחת

הagent אג'נטי יכול לייצר diff ענק במיוחד אם נתתם לו משימה רחבה ("תבנה לי את כל הפיצ'ר") ונתתם לו לרוץ עד הסוף בלי לעצור. הבעיה: ככל שה-diff גדול יותר, כך קל יותר לעבור עליו במעין "גלילה מהירה" במקום קריאה אמיתית - בדיוק אותה תחושת עייפות תשומת לב שמוכרת מסקירת PR ענק של בן אדם, רק שכאן היא קורית בתדירות גבוהה בהרבה כי agent מייצר קוד מהר.

הפתרון המעשי הוא לפרק את המשימה מראש, לא לנסות לסקור diff ענק בסוף:

• בקשו מהagent לעצור בין שלבים - "תממש קודם רק את שכבת הנתונים, תעצור ונסקור לפני שממשיכים ל-API". זה בדיוק העיקרון שראינו במצב תכנון בפרק 2.4.
• סקרו commit-by-commit אם הagent עובד בקומיטים קטנים ומתוארים, במקום לחכות לסוף ולסקור הכל בבת אחת.
• בקשו סיכום שינויים לפני הפירוט - "תן לי קודם רשימה של כל הקבצים ששונו ומה השתנה בכל אחד, ואז ניכנס לפרטים" עוזר למקד את הקריאה במקומות הרגישים באמת.

מה זה אומר "להבין" קוד לפני שממזגים

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

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

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

לא לשלוח מה שלא מבינים

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

Familiar scenario: deadline tomorrow, the agent produces a solution that works on
the example you tested, but you're not entirely sure why it chose
to handle this specific case this way.

The unprofessional response: merge it, because "it works and there's no time to dig deeper."

The professional response: ask the agent "explain exactly why
this choice is correct here", get an answer, and if it's not convincing -
keep investigating before merging, even if it costs another ten minutes.

עשר דקות של הבנה עכשיו זולות משמעותית משעות דיבוג בעוד שבוע על קוד שאף אחד בצוות לא זוכר למה הוא כתוב ככה.

הtools אוטומטיים כשכבת הגנה נוספת

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

שכבה	מה היא תופסת	מתי רצה
Linter	סגנון לא עקבי, קוד מת, שימוש שגוי במבנה שפה	בכל שמירה, אוטומטית
בדיקת טיפוסים - type checking	חוסר התאמה בין טיפוסים, ארגומנטים חסרים	לפני commit או ב-CI
בדיקות אוטומטיות - tests	רגרסיה בהתנהגות קיימת, מקרי קצה שכבר תועדו בעבר	לפני מיזוג
סורק אבטחה - SAST	דפוסים מסוכנים כמו הזרקת SQL או סודות בקוד	ב-CI, על כל PR
הagent סקירה אוטומטי	הערות על diff שלם, כולל הצעות שיפור	לפני סקירה אנושית סופית

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

אחריות - accountability

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

ראשית, בעלות מלאה על התוצר. כשאתם עושים commit או merge, אתם חותמים בפועל על הקוד, גם אם לא כתבתם כל שורה בעצמכם. זה לא שונה עקרונית מהעברת אחריות שכבר קיימת כשמדביקים קוד מ-Stack Overflow או מספרייה חיצונית - רק שקנה המידה גדול בהרבה, כי agent יכול לייצר מאות שורות בדקה.

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

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

Example PR description:

## Changes
Implemented a new endpoint for returning a user's order history.

## Transparency
Implemented with Claude Code. I reviewed the entire code line by line,
tested manually with a user with 0 orders and a user with hundreds of orders.
Haven't yet tested performance under load - flagging for follow-up before releasing to production.

התיאור הזה לא "מודה בחולשה" - הוא בדיוק ההפך: הוא מראה סקירה אחראית ומאפשר לצוות לדעת בדיוק כמה לסמוך על ה-PR הזה.

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

מתי לעצור ולא לסמוך על הפלט

יש רגעים שבהם התשובה הנכונה היא לעצור לגמרי ולא להמשיך עם מה שהagent הציע, גם אם זה אומר להתחיל שוב:

• כשההסבר של הagent משתנה בין שאלות - אם שאלתם פעמיים "למה זה עובד ככה" וקיבלתם שני נימוקים שונים, זה סימן שאין הבנה אמיתית מאחורי הקוד, אצל הagent ואצלכם כאחד.
• כשהתיקון ה-N-י לאותה בעיה - אם הagent כבר ניסה כמה תיקונים לאותה תקלה בלי שהיא נפתרה באמת, כנראה שהאבחון הבסיסי שגוי. הפתרון הוא לעצור, לחזור לאבחון מהתחלה (ראינו את התהליך הזה בפרק 3.3 על דיבוג שיטתי), לא להמשיך לנחש.
• כשמדובר בקוד שנוגע בכסף, נתוני משתמשים או אבטחה - ברגעים האלה, הרף להבנה מלאה לפני מיזוג צריך להיות הגבוה ביותר בפרויקט, בלי קשר ללחץ זמן.
• כשאתם לא יכולים לנסח את מה שהקוד עושה במשפט אחד ברור - אם הניסוח יוצא מסורבל או מתחמק, כנראה שההבנה עדיין לא מספיקה.

סיכום

• האחריות תמיד עליכם - כשמיזגתם קוד, הוא שלכם, בלי קשר למי כתב אותו. "ה-AI כתב את זה" אינו הסבר מקצועי לתקלה.
• משמעת סקירה על קוד שנכתב על ידי agent דורשת קריאה שורה-שורה, בדיקת מקרי קצה, ודרישת הוכחה - לא הצהרה - שהקוד עובד. עדיף לפרק משימות ולסקור בחתיכות קטנות מאשר לגלול מהר על diff ענק בסוף.
• הtools אוטומטיים (linter, בדיקת טיפוסים, בדיקות, סורקי אבטחה) הם שכבת הגנה משלימה, לא תחליף לסקירה אנושית - הם תופסים בעיות טכניות, לא שיפוט אם הפתרון נכון עסקית.
• "להבין" קוד נבדק במבחני הסבר, שינוי, כישלון ו"למה לא אחרת" - לא בתחושה כללית ש"זה נשמע הגיוני".
• הכלל המנחה: אם אינכם יכולים להסביר קוד, אינכם רשאים למזג אותו - גם תחת לחץ זמן.
• אחריות מקצועית כוללת בעלות מלאה על התוצר, שקיפות כלפי הצוות לגבי מידת המעורבות של הagent, ומוכנות לתקן בעצמכם כשמשהו נשבר.
• דעו מתי לעצור לגמרי: הסברים סותרים, תיקונים חוזרים שלא פותרים את השורש, קוד שנוגע בכסף או באבטחה, או חוסר יכולת לנסח מה הקוד עושה במשפט ברור.