וייב קודינג

Vibe Coding

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

את המונח טבע Andrej Karpathy, לשעבר מנהל ה-AI בטסלה וחוקר ב-OpenAI, ב-2 בפברואר 2025. הניסוח המקורי שלו היה: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." כדאי לשים לב לטון - קרפתי תיאר את זה כמשהו משועשע וקצת פזיז, לא כמתודולוגיה הנדסית. חלק מהבלבול בשוק נובע מכך שהתעשייה לקחה ניסוח קליל והפכה אותו לקטגוריה.

איך זה נראה בפועל

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

"הוסף התחברות עם Google. שמור את המשתמש בטבלת users עם השדות id, email, created_at. אחרי התחברות מוצלחת העבר ל-/dashboard. אם ההתחברות נכשלת הצג שגיאה בעברית ואל תחשוף את הודעת השגיאה המקורית."

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

במה זה שונה מהשלמה אוטומטית ומ-No-Code

שלושת המונחים מתערבבים כל הזמן, וההבדל מעשי:

• השלמה אוטומטית (GitHub Copilot בשימוש הקלאסי): אתם כותבים, הכלי משלים את השורה הבאה. אתם עדיין המחברים.
• וייב קודינג: אתם מתארים מטרה, הסוכן מייצר קבצים שלמים. אתם המבקרים.
• No-Code (Wix, Bubble): אין קוד לראות. אתם מוגבלים למה שהפלטפורמה מאפשרת, אבל גם לא יכולים לשבור את מה שמתחת.

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

למי זה מתאים, ולמי פחות

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

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

כמה זה עולה וכמה זמן זה לוקח

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

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

איפה זה נשבר

הכשלים חוזרים על עצמם ומסודרים לפי כמה קשה לגלות אותם:

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

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

הערה למי שעובד בעברית

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

הביקורת על המונח

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

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