למה דמו שנבנה מהר עם AI עדיין רחוק ממוצר שאפשר לסמוך עליו.
המשפט הכי מטעה היום בעולם ה-AI הוא: "בנינו את המוצר".
יכול להיות שבאמת בניתם מסך יפה. יכול להיות שגם חיברתם backend שעובד. יכול להיות שאפילו העליתם דמו שנראה מרשים בטירוף.
זה עדיין לא אותו דבר כמו מוצר שאפשר לסמוך עליו.
AI קיצר דרמטית את המרחק בין רעיון לבין אבטיפוס. הוא לא ביטל את המרחק בין אבטיפוס לבין מערכת אמיתית.
"The hottest new programming language is English"
— Andrej Karpathy
המשפט הזה נכון. והוא גם מסוכן אם מבינים אותו לא נכון.
כן, שפה טבעית הפכה לכלי פיתוח אמיתי. אפשר לבקש, לדייק, לשכתב, לדבג ולהרים הרבה יותר מהר ממה שהיה אפשר לפני שנה.
אבל ברגע שמתרגמים את זה ל"אז prompting זה בעצם software delivery", מתחילה הבעיה.
כי מוצר אמיתי לא נמדד לפי היכולת לגרום למשהו לעבוד פעם אחת. מוצר אמיתי נמדד לפי היכולת להפעיל אותו גם מחר, לעדכן אותו בלי לשבור, להבין מה התקלקל, ולהחזיק עליו לקוחות בלי לפחד.
מה AI באמת שינה
AI שינה את שכבת הייצור. הוא לא ביטל את שכבת האחריות.
היום אפשר:
- להרים שלד ראשוני מהר מאוד
- לייצר flow עובד תוך שעות במקום ימים
- לכתוב boilerplate בלחיצת כפתור
- לחבר מודלים לפיצ'רים
- להאיץ דיבוג, refactoring ותיעוד
זה כוח אמיתי.
אבל הוא עונה רק על שאלה אחת: האם אפשר לגרום לזה לעבוד?
מוצר אמיתי חייב לענות גם על השאלות האחרות:
- האם אפשר לסמוך על זה?
- האם אפשר לעדכן את זה בלי לשבור production?
- האם אפשר להבין למה זה נפל?
- האם אפשר להתאושש מהר?
- האם אפשר לגדול בלי לאבד שליטה?
מהירות פיתוח היא לא תחליף לאמינות. היא רק מקצרת את הדרך עד הרגע שבו האמינות נבחנת.
התמונה שמסבירה את כל הבלבול
בצד שמאל יש את הפנטזיה:
- frontend
- backend
בצד ימין יש את מה שבאמת מחזיק מוצר:
- APIs & backend logic
- database & storage
- auth & permissions
- hosting & deployment
- cloud & compute
- CI/CD & version control
- security & RLS
- rate limiting
- caching & CDN
- load balancing & scaling
- error tracking & logs
- availability & recovery
זאת לא קטנוניות של מפתחים. זה ההבדל בין משהו שנראה עובד, לבין משהו ששורד שימוש אמיתי.
הסטאק האמיתי שרוב האנשים לא רואים
דמו מראה surface. מוצר אמיתי חי מהשכבות שמתחתיו.
1. הגדרת מוצר
לפני קוד צריך החלטה. מה בונים, למי, באיזה סדר, ובאיזה מצב זה בכלל נחשב הצלחה. AI יכול להציע וריאציות. הוא לא מחליף judgment.
2. ארכיטקטורה
מה מחובר למה, איפה נשמר state, מה synchronous ומה async, מה קורה אם רכיב נופל, ואיפה מחכים צווארי בקבוק. ארכיטקטורה לא נראית בדמו, אבל היא קובעת איך המערכת תתנהג בלחץ.
3. דאטה ומיגרציות
מודל נתונים רע יכול לעבור שבוע ראשון בלי רעש, ואז להפוך למפעל של כפילויות, inconsistencies, pain ומיגרציות מסוכנות. מי ששובר דאטה, שובר עסק.
4. Auth והרשאות
מי רואה מה, מי עורך מה, מי מפעיל מה, ומה קורה כשיש משתמשים, לקוחות, צוותים, admin ופעולות רגישות. פרוטוטייפים דוחים את זה. פרודקשן משלם על זה.
5. אינטגרציות
ברגע שמוצר נוגע בתשלומים, CRM, WhatsApp, אימייל, APIs חיצוניים או ספקים צד שלישי, מתחיל העולם האמיתי: retries, timeouts, rate limits, tokens שפג תוקף, failures חלקיים וסנכרונים שנשברים בשקט.
6. תהליכי רקע
queues, workers, webhooks, polling, retries, dead letters. דמו בקושי מראה אותם. פרודקשן בנוי עליהם.
7. בדיקות
לא רק "זה רץ". אלא "זה נשבר בתנאי קצה?", "מישהו אחר יכול לשחרר גרסה בלי לפחד?", "יש לנו דרך לדעת מהר אם refactor שבר משהו?".
8. CI/CD
שחרור אמיתי הוא לא upload. הוא תהליך: מה נבדק, מי מאשר, מה נבנה, מה נפרס, ואיך חוזרים אחורה כשצריך.
9. אבטחה
מפתחות, הרשאות, ולידציות, הפרדה בין סביבות, גישה לנתונים, misuse, audit. AI לא מעלים את השכבה הזאת. לפעמים הוא דווקא גורם להזניח אותה בגלל תחושת מהירות מדומה.
10. ניטור ולוגים
אם אין observability, אין שליטה. אם משהו נשבר ואתה לא יודע איפה, מתי ולמה, אין לך מערכת בוגרת. יש לך ניחוש יקר.
11. התאוששות וזמינות
התקלה לא שואלת אם נוח לך. השאלה היא לא אם תהיה תקלה, אלא איך המערכת מתנהגת כשהיא מגיעה.
דמו טוב מוכר אפשרות. מערכת טובה שורדת מציאות.
גם מי שמוביל את ההייפ מודה איפה צוואר הבקבוק האמיתי
דאריו אמודיי אמר:
"I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code"
— Dario Amodei
יכול להיות שהוא צודק לגבי הקוד. אבל גם אם AI יכתוב 90% מהקוד, הוא עדיין לא יישא אוטומטית ב-90% מהאחריות.
כי ככל שהקוד נהיה זול יותר, מה שנהיה יקר יותר הוא:
- החלטה מוצרית
- ארכיטקטורה נכונה
- איכות data
- אמינות תפעולית
- ownership אחרי העלייה לאוויר
במילים אחרות, ככל שקל יותר לייצר קוד, כך חשוב יותר להבין מה אסור לבנות רשלני.
מה זה אומר לבעלי עסקים
אם מישהו אומר לכם "בנינו עם AI", זאת לא השאלה הנכונה.
השאלות הנכונות הן:
- איך המערכת הזאת מתמודדת עם failure?
- מה קורה אם integration נופל?
- איך עוקבים אחרי errors?
- איך מעדכנים גרסה בלי לשבור לקוחות?
- איפה נשמר הדאטה, ואיך מגבים אותו?
- מי אחראי כשהדמו פוגש מציאות?
הערך האמיתי היום הוא לא רק לבנות מהר. הערך האמיתי הוא לבנות מהר בלי להעמיד פנים שהחלק הקשה נעלם.
השורה התחתונה
AI לא ביטל software engineering. הוא רק שינה איפה מתחיל היתרון התחרותי.
מי שיודע לייצר דמו מהר, יזוז מהר. מי שיודע להפוך דמו למערכת יציבה, יבנה את מה שנשאר.
