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

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

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

מה קורה?

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

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

"תמנעי הזמנה כפולה" זו לא הוראה אחת

אז אתם חוזרים ל-AI ואומרים: תמנעי הזמנה כפולה. סבבה. אבל רגע.

מתי בדיוק המקום נחשב תפוס?

כשהלקוח בחר תאריך? אז מי שרק הסתכל תופס מקום למישהו אחר.

כשהוא התחיל לשלם? ולכמה זמן שומרים לו? חמש דקות? עשר?

רק כשהתשלום עבר? אז שניים יכולים לשלם על אותו מקום.

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

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

והנה תרחיש שקורה יותר ממה שנעים לחשוב

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

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

מה עושים?

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

מבטלים את החיוב? מי מבצע את הזיכוי, ותוך כמה זמן?

מסמנים לבדיקה ידנית? ומי בודק, ומתי, ואיך הוא יודע?

שולחים התראה? למי – ללקוח, לכם, לשניהם?

ארבע אפשרויות, ארבע התנהגויות שונות לגמרי. ואם לא בחרתם – מישהו בחר בשבילכם.

רוב השאלות האלה בכלל לא טכניות

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

מתי מקום נחשב תפוס? החלטה עסקית.

עד מתי מותר לבטל בלי קנס? החלטה עסקית.

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

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

הקוד הוא רק מה שאוכף את ההחלטות האלה. הוא לא מקבל אותן במקומכם – הוא מיישם אותן. השאלה היא רק מי קיבל אותן.

הקוד לא מקבל החלטות עסקיות. הוא רק אוכף את מה שמישהו החליט – בין אם זה אתם או המודל.

למה AI חייב לבחור משהו

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

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

וזה לא באג. זה בדיוק מה שהוא אמור לעשות.

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

וזה בדיוק מה שהופך את זה למסוכן

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

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

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

קוד טוב זו לא אותה שאלה כמו מערכת טובה

יש כאן שתי שאלות שונות לגמרי, ואנשים מבלבלים ביניהן כל הזמן:

האם ה-AI כתב קוד טוב? שאלה טכנית. התשובה כבר היום היא לרוב כן.

האם בנינו מערכת טובה? שאלה של שיפוט. ועליה AI לא עונה.

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

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

אלה כבר לא שאלות של פרומפט. אלה שאלות של אפיון.

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

השאלה ששווה לשאול על כל מערכת

רוב האנשים שואלים "האם זה עובד?" וזו שאלה טובה – אבל היא לא מספיקה.

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

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

ולמה זה לא נגמר במפתח אחד

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

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

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

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

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

איך אנחנו עובדים עם זה

אנחנו משתמשים בכלי AI בכל פרויקט. הם מאיצים את הפיתוח בצורה שלא הייתה אפשרית לפני שנתיים. אבל הם נכנסים לתמונה אחרי האפיון – לא במקומו.

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

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

בונים מערכת? בואו נגדיר את החוקים לפני שהקוד יגדיר אותם – שיחת אפיון חינם ←

שאלות נפוצות

מה זה וייב קודינג?

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

אז לא כדאי לבנות מערכות עם AI?

להפך. כדאי מאוד. השאלה היא רק מה עושים לפני. מערכת שנבנתה עם AI ואפיון טוב תהיה טובה יותר ומהירה יותר ממערכת שנבנתה ידנית. מערכת שנבנתה עם AI בלי אפיון – תעבוד, עד שהיא לא.

איך יודעים אילו החלטות התקבלו בלי שהחלטתי?

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

זה רלוונטי גם למערכות קטנות?

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

מה ההבדל בין אפיון לפרומפט?

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

כמה זמן לוקח אפיון כזה?

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