לתכנת בלי לדעת לתכנת: בניית אפליקציה ראשונה עם Vibe Coding

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

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

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

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

מה זה Vibe Coding באמת (ומה זה לא)

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

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

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

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

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

הכלים: מה באמת צריך

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

• Claude — יש לו מצב “Artifacts” שמציג את האפליקציה שנבנתה בחלון לצד השיחה. אתם רואים את התוצאה, לוחצים עליה, ומבקשים שינויים. לדעתי הנוח ביותר להתחיל איתו.
• ChatGPT — יש לו “Canvas” שעובד בצורה דומה: הקוד נפתח בחלון עריכה ואפשר להריץ תצוגה מקדימה של דפי HTML.
• Gemini — יודע לייצר קוד ולהציג תצוגה מקדימה של דפי ווב פשוטים ישירות בשיחה.

בשלב הראשון תעבדו עם אחד מהם, בלי שום דבר נוסף. רק כשהאפליקציה תגדל מעבר לקובץ אחד (נגיע לזה) יהיה שווה לעבור לכלי ייעודי כמו Cursor, Replit, Lovable או Bolt — כלים שבנויים בדיוק לאנשים כמוכם ומטפלים בעצמם בהתקנות, בשמירה ובפרסום האפליקציה לאינטרנט.

טיפ שחוסך כאב ראש: בקשו מה-AI לבנות הכול ב“קובץ HTML אחד” (single file). זה אומר שכל הקוד — עיצוב, לוגיקה, תצוגה — יושב בקובץ אחד שאפשר לשמור על המחשב, לפתוח בדפדפן בדאבל-קליק, ולשלוח לחבר בוואטסאפ. בלי התקנות, בלי שרתים, בלי תלויות. לרוב הפרויקטים הראשונים זה כל מה שצריך.

שלב 1: לכתוב את התיאור לפני שכותבים פרומפט

הטעות הכי גדולה של מתחילים היא לפתוח את הצ’אט ולכתוב “תבנה לי אפליקציה למעקב הוצאות”. התוצאה תהיה משהו גנרי שתבזבזו שעה על לשנות אותו.

במקום זה, פתחו קובץ טקסט וענו על חמש שאלות:

1. מי משתמש בזה? (אני לבד / הצוות שלי / לקוחות)
2. מה הפעולה המרכזית? אחת. לא חמש. (להוסיף הוצאה ולראות סיכום חודשי)
3. איזה מידע נשמר? (סכום, קטגוריה, תאריך, הערה)
4. מה צריך לראות במסך הראשי? (רשימת ההוצאות האחרונות + סכום החודש)
5. מה במפורש לא צריך בגרסה הראשונה? (לא צריך התחברות, לא צריך גרפים, לא צריך ייצוא לאקסל)

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

עכשיו הפרומפט הראשון כותב את עצמו:

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

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

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

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

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

שלב 2: לבנות בשכבות, לא בבת אחת

קיבלתם גרסה ראשונה. היא כנראה עובדת ב-80%. עכשיו מגיע החלק שרוב האנשים עושים לא נכון: הם מבקשים חמישה שינויים בהודעה אחת.

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

סדר עבודה שעובד:

1. קודם שהפעולה המרכזית תעבוד. להוסיף הוצאה ולראות אותה ברשימה. לא משנה איך זה נראה.
2. אחר כך שהנתונים ישרדו רענון. סגרו את הדף, פתחו מחדש. ההוצאות עדיין שם? יופי.
3. רק אז עיצוב. צבעים, רווחים, גופנים.
4. ובסוף תוספות. כל פיצ’ר מרשימת ה“לא עכשיו”.

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

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

ה“אל תשנה שום דבר אחר” בסוף הוא לא נימוס. בלעדיו, ה-AI לפעמים “משפר” דברים שלא ביקשתם ושובר משהו שעבד.

טיפ שלא מוצאים בכל מקום: אחרי כל שלב שעובד, בקשו מה-AI “תן לי את הקובץ המלא והעדכני” ושמרו אותו במחשב עם מספר גרסה: expenses-v1.html, expenses-v2.html וכן הלאה. זו מערכת הגיבוי הפרימיטיבית שלכם. כשגרסה 7 נשברת ואתם לא מצליחים לתקן, פותחים את גרסה 6 ומתחילים משם. מתכנתים משתמשים ב-Git בשביל זה; אתם יכולים להתחיל עם תיקייה.

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

משהו לא עובד. אתם לא יודעים למה. מה כותבים?

הפרומפט הגרוע: “זה לא עובד, תתקן.”

הפרומפט הטוב מתאר מה עשיתם, מה ציפיתם, ומה קרה בפועל:

יש באג. הנה מה שקורה:
1. פתחתי את הדף, הוספתי הוצאה של 50 ש"ח בקטגוריה "אוכל".
2. ציפיתי לראות אותה ברשימה ושהסכום למעלה יתעדכן ל-50.
3. בפועל: השורה נוספה לרשימה, אבל הסכום למעלה נשאר 0.
4. אם אני מרענן את הדף, הסכום פתאום מראה 50.

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

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

עוד כלי סודי: קונסולת הדפדפן. בכל דפדפן, לחיצה על F12 (או Cmd+Option+I במק) פותחת חלון של כלי מפתחים. יש שם לשונית בשם Console. כשמשהו נשבר, לרוב מופיעה שם שורה אדומה. אתם לא צריכים להבין אותה. פשוט העתיקו אותה כמו שהיא והדביקו בשיחה עם המילים “זו השגיאה שמופיעה בקונסול”. זה בדרך כלל פותר את הבעיה בסבב אחד במקום ארבעה.

שלב 4: כשהשיחה מתארכת — לאפס בלי לאבד את הפרויקט

אחרי 30-40 הודעות תשימו לב שה-AI מתחיל “לשכוח” דברים: מחזיר פיצ’ר שביקשתם להוריד, משנה שמות, מתבלבל בין גרסאות. זה קורה כי השיחה נהיית ארוכה מדי לחלון ההקשר שלו.

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

אנחנו עומדים לעבור לשיחה חדשה. תכתוב לי מסמך קצר שאני אדביק שם, שכולל:
1. מה האפליקציה עושה, בשלוש שורות.
2. רשימת כל הפיצ'רים שכבר עובדים.
3. החלטות עיצוב ומבנה שקיבלנו ושחשוב לשמור עליהן (למשל: קובץ אחד, RTL, localStorage).
4. מה הדבר הבא שרציתי לעשות.
בלי קוד — רק תיאור.

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

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

שלב 5: מקובץ אחד לאפליקציה אמיתית

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

כלים כמו Lovable, Bolt ו-Replit עובדים באותו עיקרון של שיחה, אבל הם גם:

• שומרים את הפרויקט בענן עם היסטוריית גרסאות (כך שלא צריך את התיקייה עם v1, v2, v3).
• מפרסמים את האפליקציה לכתובת אינטרנט בלחיצה.
• מחברים מסד נתונים אמיתי כשצריך שהמידע יהיה משותף בין משתמשים.

איך עוברים? פשוט: פותחים פרויקט חדש בכלי, מדביקים את מסמך ההקשר משלב 4 ואת הקובץ שלכם, וכותבים:

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

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

על נתונים ומשתמשים: ברגע שאתם רוצים התחברות (login) או נתונים שמשותפים בין אנשים, אתם נכנסים לטריטוריה שבה טעות יכולה לחשוף מידע של אחרים. בקשו מה-AI במפורש: “תסביר לי מה קורה עם הנתונים של משתמש אחד — האם משתמש אחר יכול לראות אותם? מה מונע את זה?” אם התשובה לא ברורה לכם, זה הזמן להתייעץ עם מישהו שמבין, לפני שמעלים לאוויר.

טעויות נפוצות

1. לבקש הכול בהודעה הראשונה. “תבנה אפליקציה עם התחברות, גרפים, ייצוא, התראות ומצב כהה.” תקבלו משהו ענק שחצי ממנו לא עובד ולא תדעו מאיפה להתחיל לתקן. פיצ’ר אחד בכל פעם.

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

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

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

5. להכניס סיסמאות ומפתחות לתוך הקוד. אם ה-AI מציע לחבר שירות חיצוני ומבקש “מפתח API”, אל תדביקו אותו בתוך קובץ HTML שאתם שולחים לאנשים. כל מי שפותח את הקובץ רואה אותו. זה בדיוק השלב שבו עוברים לכלי שיודע לשמור סודות בצורה מאובטחת (שלב 5).

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

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

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

• בקשו “מצב בדיקה”. “תוסיף כפתור נסתר שממלא את האפליקציה ב-20 הוצאות לדוגמה.” ככה אתם רואים איך האפליקציה נראית כשיש בה נתונים אמיתיים, ולא רק עם שתי שורות.
• בקשו רשימת בדיקות. “תכתוב לי 10 דברים שאני צריך לבדוק ידנית כדי לוודא שהגרסה הזו עובדת.” ה-AI יודע איפה הוא עלול לטעות, ויגיד לכם.
• שאלו שאלות “מה אם”. “מה קורה אם אני מכניס סכום שלילי? מה אם אני משאיר את הקטגוריה ריקה? מה אם יש 5,000 הוצאות?” זה מוצא באגים לפני שהמשתמשים מוצאים אותם.
• השוו בין כלים. תקועים על באג ב-ChatGPT? הדביקו את הקוד ואת תיאור הבעיה ב-Claude או ב-Gemini. עיניים טריות (גם מלאכותיות) מוצאות דברים.
• תבקשו “ניקיון” לפני שממשיכים. אחרי 10 סבבי שינויים הקוד נהיה מבולגן. “תעבור על הקוד, תסיר דברים שכבר לא בשימוש, ותסדר אותו — בלי לשנות שום התנהגות.” זה מקטין את הסיכוי לבאגים בהמשך.

סיכום וצ’קליסט התחלה

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

צ’קליסט להתחלה:

• בחרתי רעיון שאם הוא נשבר, אף אחד לא נפגע.
• עניתי בכתב על חמש השאלות: מי, מה הפעולה המרכזית, איזה מידע, מה במסך הראשי, מה לא בגרסה הראשונה.
• כתבתי פרומפט פתיחה שכולל “אני לא מתכנת”, “קובץ HTML אחד”, “עברית ו-RTL”, ו“תשאל לפני שאתה כותב”.
• פתחתי תיקייה במחשב לשמירת גרסאות (v1, v2, v3…).
• הפעולה המרכזית עובדת לפני שנגעתי בעיצוב.
• כל בקשת שינוי היא דבר אחד ומסתיימת ב“אל תשנה שום דבר אחר”.
• אני יודע/ת לפתוח את הקונסול (F12) ולהעתיק שגיאות.
• כשהשיחה עוברת 30-40 הודעות, אני מבקש/ת מסמך הקשר ופותח/ת שיחה חדשה.
• בדקתי בעצמי כל תיקון, כולל הפעולה המרכזית, לפני שהמשכתי.
• אין סיסמאות או מפתחות בתוך הקובץ.

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