‏Vibe Coding הפר את הבטחתו

Albert Santalo avatar
Albert Santalo 7 דקות קריאה
‏Vibe Coding הפר את הבטחתו

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

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

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

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

האבחנה השגויה

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

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

אני לא מאמין בזה. ואני לא מאמין בזה כי אופן הכשל שאני רואה שוב ושוב לא קשור בכלל לאיכות הקוד.

מיקרוסופט דיווחה בשיחת הרווחים שלה ל־2025 שכ־46% מכל הקוד שנדחף על ידי משתמשים פעילים של GitHub Copilot הוא כיום קוד שנוצר בבינה מלאכותית. בסמוך לאותו מועד פרסמה חברת אבטחת היישומים Veracode מחקר שמצא שקוד שנוצר בבינה מלאכותית הכניס פרצות אבטחה בכ־45% מהדגימות שנבדקו. המספרים האלה יחמירו לפני שישתפרו, ומודל חכם יותר לא יתקן אותם.

המודל הוא לא הבעיה. התהליך הוא הבעיה.

מה באמת חסר

תארו לי איך אפליקציה שנבנתה ב־vibe coding נבנית, ותגידו לי באיזה שלב מתקבלת החלטת הארכיטקטורה.

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

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

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

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

שלוש ההחלטות שמעולם לא התקבלו

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

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

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

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

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

לבעיית ה־70% יש שם עכשיו

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

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

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

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

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

הכלל שהבינה המלאכותית לא שינתה

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

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

הבינה המלאכותית לא שינתה את הכלל הזה. היא הפכה אותו לחשוב יותר, לא פחות.

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

זה גם החלק שהדור הנוכחי של הכלים דילג עליו.

לאן זה הולך באמת

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

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

מסך עובד מעולם לא היה אותו דבר כמו מערכת עובדת. כולנו עומדים להיזכר למה.

קריאה נוספת

מה החליף את זה: פיתוח מונחה מפרט. איך הכלים משתווים כיום: בוני יישומי הבינה המלאכותית הטובים ביותר ב־2026.

שאלות נפוצות

מה המשמעות של “vibe coding”? ‏Vibe coding הוא כתיבת תוכנה על ידי תיאור מה שאתם רוצים בשפה פשוטה וקבלת מה שהבינה המלאכותית מייצרת, בלי לציין את הארכיטקטורה, מודל הנתונים או החוזים שמתחת. אנדריי קרפתי טבע את המונח בתחילת 2025. הוא מתאר תהליך עבודה, לא קטגוריית כלים — אפשר לעשות vibe coding כמעט בכל בונה בינה מלאכותית.

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

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

האם קוד שנוצר בבינה מלאכותית פחות מאובטח? העדויות הנוכחיות אומרות שהוא דורש סקירה. מחקר של Veracode מצא שקוד שנוצר בבינה מלאכותית הכניס פרצות אבטחה בכ־45% מהדגימות שנבדקו, בנקודת זמן שבה מיקרוסופט דיווחה שכ־46% מהקוד שנדחף על ידי משתמשים פעילים של GitHub Copilot נוצר בבינה מלאכותית. הנפח עולה מהר יותר מהאימות.

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

פוסטים קשורים