לעבור על הקוד שה-AI כתב.

תעברו על הקוד שה-AI כתב כמו שהייתם עוברים על pull request של מישהו שאתם לא מכירים: תניחו ששום דבר לא עובד עד שבדקתם בעצמכם. ה-AI שוטף ובטוח בעצמו, ואף אחד מהשניים לא אומר לכם שהקוד נכון, בטוח, או עושה את מה שבאמת ביקשתם. review כאן זה לא לקרוא את הקוד שוב כדי להתפעל ממנו. זה מעבר קצר שחוזר על עצמו על המקומות שה-AI טועה בהם באופן עקבי: auth, גישה לנתונים, טיפול בשגיאות, והדבר האחד שהוא דילג עליו בשקט.

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

01למה בכלל לעבור על הקוד שה-AI כתב?

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

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

02הצ'קליסט ל-review: מה לבדוק לפני שקוד של AI עולה

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

בדיקה	איפה להסתכל, מה לחפש ב-grep	השאלה לשאול
auth בצד השרת	ה-route handlers וה-API endpoints; תחפשו את בדיקת הכניסה או ה-session	זה נאכף בצד השרת, או רק מוסתר ב-UI?
בקרת גישה	ה-queries למסד הנתונים; תחפשו את ה-id של המשתמש בכל קריאה וכתיבה	חשבון A יכול להגיע לנתונים של חשבון B?
קלט ושגיאות	קלט חיצוני וקריאות API; תחפשו catch ואת אלה שחסרים	מה קורה על קלט שגוי, timeout, או כשל שלא אתם גרמתם?
סודות ו-config	מחרוזות מקודדות בקוד; תחפשו key, token, password, http	יש סוד בתוך הקוד, או כזה שהלקוח יכול לקרוא?
הוצאה והגבלות	לולאות, retries, וקריאות ל-API בתשלום או AI	מה עוצר את זה מלרוץ לנצח או להוציא בלי תקרה?

03auth וגישה לנתונים: הדבר הראשון לבדוק

תתחילו ממי מורשה לעשות מה, כי שם אפליקציות שנבנו עם AI דולפות הכי הרבה. Broken Access Control הוא הסיכון מספר אחת בOWASP Top 10 לשנת 2025, וזה בדיוק הדפוס שאנחנו מוצאים שוב ושוב בקוד שה-AI כתב.

לחור כמעט תמיד אותה צורה. ההרשאות מטופלות ברמת המשתמש, בדפדפן, בלי שום בקרה בצד השרת, אז כל מי שפותח את ה-network tab יכול לעקוף אותן. כשאתם עושים review, אל תסמכו על כפתור מוסתר או שדה אפור. תמצאו את ה-route בשרת ותוודאו שהוא בודק גם שהמשתמש מחובר וגם שהמשתמש הזה הבעלים של הרשומה הזאת. אם החוק שחשבון A לא יכול לקרוא את חשבון B חי רק במסך, הוא לא קיים. מה כל אחד מהחורים האלה עולה ואיך סוגרים אותו נמצא באבטחת אפליקציות שנבנו עם AI.

04טיפול בשגיאות ותקרת הוצאה: מה הוא דילג עליו בשקט

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

הגרסה הכי יקרה של זה היא אוטומציה בלי גבול. אפליקציה אחת שקראו לנו אליה הריצה לולאה בלי השגחה, בלי תקרת הוצאה ובלי כפתור עצירה, וצברה חשבון AI של יותר מ-1,000 דולר ביום אחד. אז כשאתם עושים review לקוד של AI שקורא ל-API בתשלום או רץ לפי לוח זמנים, השאלה היא לא אם זה עובד פעם אחת. היא מה עוצר את זה מלרוץ לנצח. תחפשו timeout, תקרת retries, ולידציה לקלט, ותקרה קשיחה על הוצאה. אם אחד מאלה חסר, זו הערת ה-review שלכם, לפני שזה החשבון.

05מה הוא דילג עליו? השאלה שצריך לשאול על כל שינוי

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

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

06איך אנחנו עושים review לקוד של AI לפני שהוא עולה

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

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

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