בדקתי מערכת שנבנתה עם AI: 9 דברים שעבדו בהדגמה ולא היו מוכנים ללקוחות
התשובה הקצרה: אפשר לבנות עם AI מערכת שעובדת בהדגמה ואפילו נראית מוכנה. כשבדקתי אב-טיפוס כזה, שנבנה בשיחה עם כלי AI בלי מפתח והגיע אליי לבדיקה, מצאתי 9 דברים שהיו שגויים או מסוכנים. רובם לא נראים על המסך בכלל. הם יושבים בקוד שהדפדפן מוריד, בהחלטות על הרשאות ותשלום, ובנתונים שנשמרים במקום הלא נכון.
זו הייתה מערכת שנועדה למכור גישה: הרשמה, תשלום, תוכן שנפתח רק למי ששילם, ואזור ניהול. היא נבנתה כקובץ HTML אחד, וכל מה שביקשו מהכלי, הכלי בנה. אני מפרט כאן מה מצאתי, בלי פרטים מזהים, כי זו בדיוק הרשימה שכדאי לעבור עליה לפני שמערכת כזו פוגשת לקוחות אמיתיים. אחרי כל קבוצה של ממצאים יש גם תיאור קצר של איך זה נראה כשזה תקין.
למה הבעיות האלה לא נראות בהדגמה
בהדגמה יש משתמש אחד, דפדפן אחד, והכול קורה במקום אחד. רוב הבעיות ברשימה מתגלות רק כשיש משתמש שני, מכשיר שני, או מישהו שמסתכל בקוד במקום על המסך. כלי AI טובים מאוד במה שרואים: מסך שנראה נכון וכפתור שמגיב. הם פחות טובים במה שלא רואים, כי אף אחד לא ביקש אותו.
אבטחה והרשאות: מי רואה מה
- כל התוכן בתשלום בתוך קוד הדף. כל התוכן שהעסק מוכר, הנכס המרכזי שלו, נצרב ישירות בקוד שהדפדפן מוריד. לחיצה על “הצג מקור” נתנה אותו לכל מבקר, כולל מה שאמור להיפתח רק למי ששילם.
- מנהל לפי כתובת מייל. כל מי שנרשם עם כתובת מייל שמכילה את המילה admin קיבל הרשאות ניהול. בלי אישור ובלי הזמנה.
- סיסמה שלא נבדקת. ההתחברות לא בדקה את הסיסמה מול שום דבר. הסיסמאות נשמרו כטקסט גלוי בדפדפן, כולל סיסמאות שמנהל הגדיר למשתמשים אחרים.
- ספרייה שנטענת מבחוץ, באותו קובץ עם הסיסמאות. כדי לקרוא קובצי אקסל, המערכת השתמשה בספרייה חיצונית, כלומר קוד מוכן שכתב מישהו אחר, והיא נטענה משרת של צד שלישי בכל טעינה של הדף. כל המערכת הייתה קובץ אחד, ובאותו קובץ ישבו גם שדות הסיסמה. קוד שנטען מבחוץ רץ באותו דף ועם אותן הרשאות כמו הקוד של הדף עצמו, כלומר הוא יכול לעשות בדף כל מה שהדף יכול. בבדיקה רגילה זה לא נראה בכלל, כי הייבוא עובד.
איך זה נראה כשזה תקין: התוכן בתשלום יושב בשרת, והשרת שולח כל פריט רק למשתמש שמותר לו לראות אותו. הרשאת ניהול ניתנת ידנית לחשבון מסוים, ולא לפי מה שכתוב בכתובת המייל. הסיסמה נבדקת בשרת ונשמרת בצורה שאי אפשר לשחזר ממנה את הסיסמה עצמה (hash), כך שגם מי שרואה את מסד הנתונים לא רואה סיסמאות. וספרייה חיצונית נטענת רק כשצריך אותה, ועדיף מהשרת של האתר עצמו.
תשלום וגישה: מי משלם, ומה הוא מקבל
- תשלום שפותח גישה בלי לחייב. כפתור התשלום יצר חשבון ופתח את הגישה בלי שום חיוב, אחרי מסך שנראה כמו תשלום אמיתי. ההחלטה מי מקבל גישה, וגם המחירים עצמם, ישבו בדפדפן, כלומר אצל המשתמש.
- הטמעה פתוחה לכל אתר. בהנחיה להגדרת הסרטונים שבתשלום, ההמלצה הראשונה של הכלי הייתה לאפשר הטמעה “בכל מקום” (Anywhere), כדי שהסרטון יוצג. הגבלה לדומיין של העסק הוצגה רק כחלופה. בהגדרה הראשונה, כל אתר אחר יכול היה להציג את התוכן שבתשלום.
איך זה נראה כשזה תקין: הגישה נפתחת רק אחרי שספק הסליקה מאשר לשרת שהחיוב עבר, והמחיר נקבע בשרת ולא בדף. וסרטונים בתשלום מוגבלים להטמעה בדומיין של העסק בלבד.
נתונים שנשמרים במקום הלא נכון
- ייבוא שנשאר במחשב אחד. ייבוא מקובץ אקסל בפאנל הניהול הציג הצלחה, אבל נשמר רק בדפדפן של מי שייבא. משתמשים במכשירים אחרים לא ראו כלום.
- “בדקתי שזה עובד”, בלי שזה נשמר. הכלי דיווח שייבוא של כמה מאות שורות נבדק ועובד. בפועל הבדיקה רצה בסביבה זמנית שלו, והשורות לא נכנסו לקובץ שהתקבל בסוף. זה התגלה רק כשחיפשו אותן ולא מצאו.
- העלאת וידאו שנעלמת. סרטון שהועלה מהמחשב הוצג בתצוגה מקדימה ונעלם ברענון. הוא היה קיים רק באותו דפדפן.
איך זה נראה כשזה תקין: כל מה שמשתמש אחד שומר ומשתמש אחר אמור לראות נשמר במסד נתונים בשרת, לא בזיכרון של הדפדפן. קבצים, כולל וידאו, עולים לאחסון קבצים אמיתי. ובדיקה של ייבוא נגמרת רק כשהפריטים מופיעים אצל משתמש אחר, במכשיר אחר.
מה המשותף לתשעת הממצאים
כמעט כולם נובעים מאותו מקור: החלטות שאמורות להתקבל בשרת התקבלו בדפדפן. הרשאות, תשלום, שמירת נתונים, ואפילו התוכן עצמו. בדפדפן כל משתמש יכול לראות הכול ולשנות הכול. בהדגמה זה בסדר גמור, ובדיוק את זה צריך לשנות לפני שיש לקוחות.
ושני ממצאים מראים משהו על הכלי עצמו: הוא דיווח על הצלחה כשהבדיקה רצה רק אצלו, והציע את ההגדרה הנוחה לפני הבטוחה. לכן “זה עובד” מה-AI הוא נקודת ההתחלה של הבדיקה, לא הסוף שלה.
בדיקה עצמית: חמש שאלות לפני שמעלים
- פותחים “הצג מקור” בדף שאחרי ההתחברות. אם רואים שם תוכן בתשלום, מחירים או מפתחות גישה, הם לא אמורים להיות שם.
- נרשמים עם כתובת חדשה ובודקים מה היא יכולה לעשות. אם משהו בכתובת או בשם נותן הרשאות, יש בעיה.
- מנסים להתחבר עם סיסמה שגויה. אם זה עובד, כל השאר לא משנה.
- מנסים “לשלם” בלי כרטיס אמיתי. אם הגישה נפתחה, החיוב לא באמת קובע מי נכנס.
- מייבאים או מעלים משהו ממחשב אחד, ופותחים ממכשיר אחר. אם זה לא שם, זה לא נשמר.
ואם יש מערכת עם משתמשים ותשלום, כדאי לעבור גם על מה חסר כדי להעלות אותה לאוויר: דומיין, הרשאות, סליקה בישראל ובעלות על החשבונות.
שאלות שחוזרות
זה אומר שלא כדאי לבנות מערכת עם AI?
לא. אב-טיפוס כזה הוא אפיון מצוין: כל מסך וכל זרימה כבר עובדים בהדגמה, ורואים בדיוק מה העסק צריך. מה שנשאר הוא להעביר את ההחלטות לשרת, לחבר תשלום אמיתי ולשמור את הנתונים במקום אחד.
אפשר לבקש מה-AI לתקן את כל זה?
חלק כן, אם יודעים מה לבקש ואיך לבדוק שזה באמת תוקן. הבעיה היא שבמקרה הזה הכלי דיווח על הצלחה גם כשהבדיקה רצה רק בסביבה שלו. לכן מישהו צריך לבדוק את התוצאה מחוץ לכלי, עם משתמש שני ומכשיר שני.
הבעיות האלה קיימות גם ב-Base44 וב-Lovable?
הכלים האלה מגיעים עם מסד נתונים והתחברות מובנים, ולכן חלק מהבעיות כאן, כמו סיסמה שלא נבדקת, פחות שכיחות בהם. אבל הרשאות שמפרידות בין משתמשים, תשלום שנבדק בשרת, ומפתחות שלא יושבים בקוד הדף צריך לבדוק בכל כלי.
מה הבדיקה הראשונה, אם יש זמן רק לאחת?
הרשאות. נכנסים עם שני משתמשים שונים, מעתיקים כתובת של עמוד פרטי מהראשון ופותחים אותה בשני. אם התוכן של הראשון מופיע, זה הדבר הראשון לתקן.
איך מתחילים?
שולחים קישור, צילום מסך או כמה משפטים בוואטסאפ: מה נבנה, באיזה כלי, ואיפה זה עומד. אני ממפה מה יש ומה חסר, ואם צריך פרויקט, מגיעה הצעת מחיר קבועה אחרי אפיון.
השורה התחתונה
תשעת הממצאים האלה לא אומרים שמי שבנה את האב-טיפוס טעה. לבנות, לראות שזה עובד, ולשאול מה חסר לפני שלקוחות אמיתיים נכנסים: זה בדיוק הסדר הנכון. ההבדל בין הדגמה למערכת לא נמצא במסכים. הוא נמצא במה שקורה מאחוריהם.