Vibe coding ו-base44: מתי זה מספיק, ומתי זה נגמר בכתיבה מחדש

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

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

חברת אבטחת התוכנה Veracode בדקה ב-2025 קוד שנוצר על ידי יותר מ-100 מודלי שפה, בארבע שפות תכנות. התוצאה: ב-45% מהמקרים הקוד שנוצר נכשל בבדיקות אבטחה והכניס פגיעויות מרשימת OWASP Top 10.

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

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

מתי vibe coding הוא הבחירה הנכונה

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

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

בשלושת המקרים האלה vibe coding הוא לא פשרה. הוא הכלי הנכון.

השאלה מתחילה כשהדבר הזה מצליח.

למה דווקא הצלחה היא הבעיה

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

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

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

זו הסיבה שאנחנו אומרים שאפליקציה שנבנתה ב-vibe coding היא לא MVP. היא פרוטוטייפ. MVP הוא מוצר מינימלי שאפשר להמשיך לבנות עליו; פרוטוטייפ הוא משהו שזורקים.

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

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

מה מצאנו כשפתחנו אפליקציות כאלה

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

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

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

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

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

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

מה שלא מספרים לכם על העלויות

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

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

בפרויקטים שהגיעו אלינו חזרו שלושה דברים:

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

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

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

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

איך אנחנו עובדים עם AI

אנחנו עובדים עם מודלים כל יום. ההבדל הוא לא אם משתמשים ב-AI — הוא איך.

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

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

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

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

ראו פיתוח ואינטגרציית AI.

כבר בניתם משהו — מה עכשיו?

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