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

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

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

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

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

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

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

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

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

· הדגמה למשקיע או ללקוח. פרוטוטייפ שנועד להראות רעיון, לא להריץ עסק.

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

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

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

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

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

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

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

זו אחת מהסיבות שבעתיין נאמר שאפליקציה שנבנתה ב-vibe coding היא לא MVP אלא היא בעצם פרוטוטייפ (אב-טיפוס).
MVP הוא מוצר מינימלי שאפשר להמשיך לבנות עליו; פרוטוטייפ הוא משהו שזורקים.
חשוב להבין שיש אפליקציות ובייחוד סוגים של אתרים שבהם כלים כאלו מעבר למספקים את התוצר, אבל אם פניכם מועדות לפיתוח של מערכת מורכבת ורבת משתמשים יתכן ו VIBE CODING הוא לא הפיתרון הנכון עבורכם.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עדיין מתלבטים? צריכים עוד מידע? קראו מתי לבנות מערכת לעסק עם AI ומתי לעבוד עם חברת פיתוח.