מה זה וייב קודינג? הסבר פשוט ואיך מתחילים

וייב קודינג (Vibe Coding) זה לבנות תוכנה בשיחה. אתם כותבים לכלי AI מה אתם רוצים, בעברית או באנגלית, הוא כותב את הקוד ומראה לכם את התוצאה, ואתם ממשיכים לבקש תיקונים עד שזה עובד. את הקוד עצמו אתם כמעט לא רואים.

יש מי שכותבים "ווייב קודינג" ויש מי שכותבים "vibe coding". זה אותו דבר. בעברית אפשר לקרוא לזה "תכנות בשיחה", אבל אף אחד לא באמת אומר את זה.

---

מאיפה הגיע המונח וייב קודינג

ב-2 בפברואר 2025 כתב אנדריי קרפתי, ממייסדי OpenAI ולשעבר ראש תחום ה-AI בטסלה, פוסט ב-X על "סוג חדש של קידוד" שבו "נכנעים לגמרי לווייב" ושוכחים שהקוד בכלל קיים. הוא תיאר איך הוא בונה פרויקטים קטנים בלי לקרוא את הקוד: מבקש, מדביק את הודעת השגיאה כמו שהיא, ובודק אם זה עובד.

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

---

איך זה עובד בפועל

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

1. אתם כותבים: "תבנה לי מערכת תורים לקליניקה. לקוח בוחר טיפול, תאריך ושעה, ומקבל אישור במייל. אני רואה את כל התורים בלוח שנה."

2. תוך דקה או שתיים יש לכם אפליקציה שעובדת בתצוגה מקדימה. לא מושלמת, אבל אפשר ללחוץ עליה.

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

4. משהו נשבר. אתם מעתיקים את השגיאה ושולחים לכלי. הוא מתקן.

5. כשזה נראה טוב, לוחצים Publish ומחברים דומיין.

מה שקורה מאחורי הקלעים: מודל שפה (כמו Claude של Anthropic או Gemini של גוגל) מקבל את הבקשה שלכם, כותב קוד אמיתי ב-React, מקים בסיס נתונים כשצריך, ומריץ הכל בשרת. ב-Lovable, למשל, הקוד שייך לכם ואפשר לסנכרן אותו ל-GitHub.

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

---

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

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

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

---

כלי וייב קודינג: במה להשתמש

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

כלי	למי זה מתאים	איך עובדים איתו
Lovable	מי שלא מתכנת ורוצה אתר או אפליקציה מלאה	בדפדפן, כולל בסיס נתונים, התחברות ואירוח
Base44	אפליקציות פנימיות מהירות	בדפדפן, הכל בתוך הפלטפורמה
Bolt, Replit, v0	מתחילים עד מפתחים	בדפדפן
Google AI Studio	מי שרוצה לנסות אפליקציות שמבוססות על Gemini	בדפדפן
Claude Code, Cursor	מי שמכיר קצת קוד או רוצה שליטה מלאה	על המחשב, ליד קבצי הפרויקט

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

---

איך מתחילים לעשות וייב קודינג היום

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

ככה נראית בקשה ראשונה שעובדת:

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

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

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

אחרי זה:

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

• תכתבו לכלי מה הפרויקט. ב-Lovable יש Knowledge, מקום שבו כותבים פעם אחת את הכללים של הפרויקט והוא זוכר אותם בכל בקשה. הסברנו איך בKnowledge base = המוח של הפרויקט.

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

• כשמשהו נשבר, תתארו מה ראיתם. "הכפתור לא עושה כלום אחרי שאני בוחר תאריך" עובד יותר טוב מ"זה לא עובד". יש לנו מדריך שלם על דיבוג ב-Lovable.

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

---

הבעיות של וייב קודינג

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

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

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

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

---

שאלות נפוצות