הקוד עובד. עכשיו מתחילה הסכנה.

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

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

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

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

ההדגמה מספרת רק את מה שקל לראות

ל־Vibe Coding יש יתרון אמיתי, ולא כדאי לטשטש אותו. במחקר מבוקר של Peng ושותפים, שבו מפתחים בנו שירות JavaScript קטן, השימוש בכלי AI קיצר את זמן העבודה ב־55.8%. בשלושה ניסויי שטח שכללו 4,867 מפתחים במיקרוסופט, Accenture ויצרנית גדולה, נרשמה עלייה של 26.08% במספר המשימות שהושלמו. לא מדובר באשליה: כשמגדירים משימה מוגבלת, מקבלים תוצאה במהירות חסרת תקדים.

אבל "מספר משימות שהושלמו" אינו "מספר מערכות שאפשר לסמוך עליהן". בניסוי הארגוני הגדול, החוקרים כלל לא קיבלו גישה לקוד שנוצר. הם מדדו תפוקה, לא איכות. במחקר של METR, שבו מפתחי קוד פתוח מנוסים עבדו על מאגרים שהכירו במשך שנים, השימוש בכלי AI דווקא האריך את זמן הביצוע ב־19%. המפתחים עצמם היו משוכנעים שהכלי האיץ אותם. חשוב לומר את מה שהמעבדה עצמה אומרת: בעדכון מפברואר 2026 קבעה METR שהמדידה החדשה שלה אינה אמינה, משום שמפתחים סירבו יותר ויותר לעבוד ללא AI, והיא מעריכה כי כיום המפתחים כנראה מהירים יותר. הנתון של 19% הוא ממצא על מאגרים בוגרים בתחילת 2025, לא מדד עדכני. אבל השאלה שהוא מעלה נשארת פתוחה: תחושת המהירות אינה עדות למהירות.

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

הקוד למד לעבור את ההדגמה, לא את המתקפה

הנתון החשוב ביותר בסיפור הזה אינו שיעור האימוץ. הוא הפער בין תקינות לאבטחה. בבדיקות של Veracode על יותר מ־150 מודלים בין 2023 ל־2026, שיעור הקוד שעבר בדיקות תחביר עלה מכ־50% ליותר מ־95%. באותו זמן, שיעור המעבר של בדיקות אבטחה נשאר סביב 45%-55%.

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

מחקרים בשיטות שונות מגיעים לאותה נקודה. במחקר IEEE מוקדם, כ־40% מהתוכניות שנוצרו ב־Copilot הכילו חולשות. BaxBench, שבדק פתרונות Backend מול ניצול אמיתי, מצא שיותר מ־60% מהפתרונות היו שגויים או לא מאובטחים; כמחצית מהפתרונות שהיו תקינים מבחינה פונקציונלית עדיין היו ניתנים לניצול.

ואז הגיע המחקר הישיר ביותר על Vibe Coding. חוקרים זיהו 10,517 יישומים שאומתו ככאלה שרוב מכריע של הקוד וההיסטוריה שלהם נוצרו בידי AI. הם בחרו 200 יישומי Web פעילים ובדקו אותם באמצעות כמה סוכנים, ניסיונות ניצול מבוקרים ושני מומחי אבטחה אנושיים שנדרשו להסכים על כל ממצא.

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

המערכת אינה מסוכנת מפני שהיא לא עובדת. היא מסוכנת מפני שהיא עובדת מספיק טוב כדי שנפסיק לשאול שאלות.

שלוש חולשות, שלושה סיפורים מוכרים

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

בקרת גישה שבורה הייתה הקטגוריה הגדולה ביותר: 36% מכלל החולשות, ונוכחות ב־75.5% מהמאגרים שנבדקו. התבנית פשוטה. היישום בודק אם המשתמש מחובר ומסתיר ממנו כפתור שאינו שייך לו. אבל מסד הנתונים או ה־API אינם בודקים אם הרשומה שהוא מבקש באמת שייכת לו. הממשק נראה מוגן. הנתונים פתוחים.

זה מה שנמצא באפליקציות שנבנו בפלטפורמת Lovable. חוקרים סרקו 1,645 יישומים בשוק של החברה וגילו 170 אפליקציות שחשפו נתונים דרך 303 נקודות קצה שניתן היה לקרוא ללא אימות מתאים. במקרים רבים, האפליקציה "ידעה" מי מחובר בצד של הדפדפן, אך מדיניות Row-Level Security ב־Supabase הייתה חסרה או שגויה. אימות אינו הרשאה; מסך כניסה אינו גבול אבטחה. הפגיעות רשומה כ־CVE-2025-48757 בדירוג חומרה 9.3. Lovable חולקת על הרישום וטוענת שכל לקוח אחראי להגנת הנתונים של היישום שלו. המחלוקת הזו היא בדיוק הנקודה שמנכ"ל צריך לשים לב אליה: הפלטפורמה מייצרת את שכבת הנתונים, והאחריות נשארת אצלכם.

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

בפרשת Tea נחשפו כ־72 אלף תמונות ובהמשך 1.1 מיליון הודעות פרטיות עקב הגדרות Firebase לקויות. הייחוס של כתיבת האפליקציה ל־Vibe Coding לא אומת, ולכן אסור להציג אותו כעובדה. אבל הכשל עצמו חשוב: מסלול שאינו מופיע בממשק עדיין קיים; כתובת שקשה לנחש אינה הרשאה; ברירת מחדל אינה מדיניות אבטחה.

האדם שאמור לבדוק הוא לעיתים האדם שפחות מסוגל לבדוק

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

במחקר מבוקר על כתיבת קוד מאובטח, משתתפים שקיבלו עוזר AI כתבו קוד פחות מאובטח - ובמקביל נטו יותר להאמין שהקוד שלהם מאובטח. במחקר של Microsoft Research ו־Carnegie Mellon, ביטחון גבוה יותר ב־AI ניבא פחות חשיבה ביקורתית. סקר Stack Overflow מצא שהבעיה הנפוצה ביותר, שעליה דיווחו 66% מהמפתחים, היא פתרונות ש"כמעט נכונים, אבל לא לגמרי". כמעט מחצית דיווחו שהניפוי של קוד AI גוזל יותר זמן.

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

לא לעצור את השימוש. לעצור את הקפיצה

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

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

גם ניסוח ההנחיה משפיע, אבל אסור לבלבל אותו עם בקרה. בניסוי מבוקר, המשפט "הפוך את זה למוכן לייצור" הוריד את שיעור החזרת החולשות מ־40% ל־13%, ובקשה מהמודל לבדוק את הקוד של עצמו הורידה אותו ל־18%. לעומת זאת, מפרט "מקצועי" מפורט העלה את שיעור החולשות ל־56%. יותר מילים אינן בהכרח יותר בטיחות. ואף אחת מהשיטות לא הורידה את הסיכון לאפס.

חמש שאלות לחדר ההנהלה

לפני שההדגמה מקבלת משתמש אמיתי ראשון, הנהלה אינה צריכה לקרוא קוד. היא כן צריכה לדרוש תשובות שאינן ניתנות להחלפה בהבטחה כללית ש"ה־AI בדק".

מי בעל הבית ההנדסי?

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

איזה מידע אמיתי המערכת יכולה לראות?

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

כיצד נבדקה הרשאה?

הבדיקה החשובה ביותר: להתחבר כמשתמש א׳, לבקש ישירות דרך ה־API את הרשומה של משתמש ב׳, ולוודא שלא מתקבל דבר. לחזור על כך לכל טבלה ומשאב.

מה הסוכן אינו רשאי לעשות?

לסוכן פיתוח לא צריכה להיות גישה לאישורי ייצור, יכולת לעקוף הגנת ענף או רשות לבצע פעולה הרסנית ללא אישור.

מי בדק באופן בלתי תלוי?

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

החלטה על קצב היא החלטה על סיכון

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

לכן השאלה למנכ״ל אינה "האם להשתמש ב־Vibe Coding?" אלא "היכן מסתיימת המהירות ומתחילה המשמעת?" אפשר לבנות במהירות. אפשר לבדוק רעיונות בזול. אפשר לתת לצוותים כוח שלא היה להם בעבר. אבל ברגע שהמערכת נוגעת בלקוח, בכסף, בזהות או במוניטין של החברה, היא חייבת לעבור מבעלות של מי שהדגים אותה לבעלות של מי שמסוגל להגן עליה.

AI הפך את יצירת הקוד למשאב שופע. המשאב הנדיר החדש הוא אימות שאפשר לבטוח בו.

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