מדריכים · בנייה עם AI
מדריכים · בנייה עם AI
טוטוריאלים מלמדים את המסלול שבו הכול עובד: משתמש אחד, קלט נקי, המחשב שלכם, הרצה אחת מתחילתה לסופה. פרויקט אמיתי נשבר בדיוק על חמשת הדברים שהמסלול הזה אף פעם לא מראה לכם, state, כניסה, הנתונים של אנשים אחרים, deployment, ושגיאות שלא אתם גרמתם. המעבר מלעקוב אחרי מדריך לשלוח משהו אמיתי הוא לא עוד קוד. הוא ללמוד לטפל בחלקים שהטוטוריאל דילג עליהם בשקט, כדי שהתוצאה תחזיק מעמד ברגע שזר ראשון משתמש בה לא נכון.
זה פרק הגשר במדריך שלנו לבניית אפליקציה עם AI ב-2026, השלב בין לסיים בילד לבין לשלוח קוד שאנשים אחרים תלויים בו. אם עוד לא שלחתם כלום, המסלול שלב אחרי שלב נמצא באיך בונים את האפליקציה הראשונה שלכם עם AI. הדף הזה הוא לרגע שבו הטוטוריאל נגמר והעבודה האמיתית מתחילה.
כי טוטוריאל בנוי כדי להצליח. הוא מזין לאפליקציה את הקלט האחד שהכותב בחר, רץ פעם אחת, על מחשב אחד, בשביל משתמש ידידותי אחד, ונעצר לפני שמשהו יכול להשתבש. לפרויקט אמיתי אין אף אחת מההבטחות האלה. משתמשים מגיעים בסדר הלא נכון, מקלידים דברים שלא ציפיתם להם, פותחים שני טאבים, מאבדים חיבור, וחוזרים שעה אחר כך ומצפים שהנתונים שלהם עדיין יהיו שם.
הקוד מהטוטוריאל בדרך כלל בסדר. מה שחסר זה כל מה שסביבו: ה-state שצריך לשרוד רענון, הבדיקה שחשבון A לא יכול לקרוא את חשבון B, ה-config ששונה בין הלפטופ שלכם לשרת, והטיפול בשגיאה שלא אתם כתבתם אבל עדיין תואשמו בה. השכבה החסרה הזאת היא הפער, והוא כמעט אותו פער בכל פרויקט ראשון.
הנה חמשת הפערים, מה הטוטוריאל בדרך כלל מדלג עליו בכל אחד, ומה ללמוד כדי לסגור אותו. עברו על הרשימה הזאת לפני שאתם קוראים לאפליקציה ראשונה אמיתית.
| פער | על מה הטוטוריאל דילג | מה ללמוד |
|---|---|---|
| State | הרצה אחת, בלי רענון, בלי טאב שני | איך ה-framework שלכם שומר ומשחזר state, ומה נאבד ברענון |
| כניסה והרשאות | משתמש מחובר אחד, או אף אחד | auth ו-sessions בצד השרת, לא בדיקה בדפדפן |
| הנתונים של אנשים אחרים | תמיד רק הרשומות של משתמש אחד | בקרת גישה במסד הנתונים, כך שחשבון A לא יקרא את חשבון B |
| Deployment ו-config | רץ על localhost | environment variables ו-deploy שחוזר על עצמו, לא ערכים מקודדים בקוד |
| שגיאות שלא אתם גרמתם | קלט נקי, רק המסלול שבו הכול עובד | ולידציה לקלט, timeouts, retries, הודעת שגיאה אמיתית, ותקרת הוצאה |
state זה מה שהאפליקציה שלכם זוכרת בין פעולה אחת לבאה, וזה הדבר הראשון שנשבר מחוץ לטוטוריאל. השיעור עובד כי אתם מריצים אותו פעם אחת, מההתחלה לסוף, בסדר שהכותב ציפה לו. משתמש אמיתי מרענן באמצע טופס, פותח את האפליקציה בשני טאבים, או חוזר אחרי שה-session שלו פג, והאפליקציה עדיין צריכה לדעת מה נכון.
מה שצריך ללמוד זה איך ה-framework שלכם באמת מחזיק state ומה נעלם ברענון. עגלת קניות שחיה רק בזיכרון ריקה אחרי רענון. שני טאבים שכותבים לאותה רשומה צריכים חוק מי מנצח. שום דבר מזה לא מופיע כשהבודק היחיד הוא אתם, לוחצים פעם אחת, בסדר האחד שהטוטוריאל תכנן.
הפער הכי נפוץ באפליקציה אמיתית הוא בקרת גישה: לתת למשתמש להגיע לנתונים או לפעולות שאמורים להיות סגורים בפניו. Broken Access Control הוא הסיכון מספר אחת בOWASP Top 10 לשנת 2025, וזה בדיוק החלק שטוטוריאל משאיר בחוץ, כי לטוטוריאל יש משתמש אחד, אז אין את מי להפריד ממי.
אפליקציה אמיתית צריכה שני דברים שדמו אף פעם לא צריך. כניסה חייבת להיאכף בצד השרת, לא עם בדיקה בדפדפן שכל משתמש יכול לעקוף. והחוק שחשבון A לעולם לא יקרא את חשבון B חייב לחיות במסד הנתונים, לא במסך שסתם מסתיר כפתור. אנחנו רואים את אותו חור שוב ושוב באפליקציות שנבנו עם AI: הרשאות שמטופלות ברמת המשתמש, בלי בקרה בצד השרת, קל לעקוף.
deployment הוא השלב שרוב הטוטוריאלים נגמרים ממש לפניו, וזה המקום שבו פרויקטים ראשונים נתקעים לימים. קוד שרץ על הלפטופ שלכם תלוי בשקט בדברים שאין לשרת: הנתיבים שלכם, הכלים שהתקנתם, וסודות שהקלדתם ביד. תעבירו אותו כמו שהוא והוא יישבר.
מה שצריך ללמוד זה להוציא את ה-config מהקוד. הכלל של Twelve-Factor App הוא הפרדה מוחלטת של config מקוד: כתובות של מסד נתונים, API keys, וכל מה ששונה בין המחשב שלכם לבין production, חיים ב-environment variables, לא בתוך הקוד. תעשו את זה נכון ו-deploy הופך לדבר שחוזר על עצמו במקום לדבר שאתם מגלים מחדש בכל פעם.
הפער האחרון הוא כל מה שמשתבש בלי שעשיתם טעות. API של תשלומים נתקע ב-timeout, מישהו מעלה קובץ פי עשרה גדול ממה שתכננתם, שירות צד שלישי מחזיר שטויות, אוטומציה רצה בלולאה כל הלילה. טוטוריאלים מזינים קלט נקי ואף פעם לא נתקלים בזה, אז לקוד אין טיפול בזה והאפליקציה או קורסת או עושה בשקט את הדבר הלא נכון.
שני חלקים הכי חשובים. תטפלו בכשל בכוונה: ולידציה לקלט, timeouts, retry למה שבטוח לנסות שוב, והצגת הודעה אמיתית במקום מסך ריק. ותגבילו כמה האפליקציה יכולה להוציא. אפליקציה אחת שקראו לנו אליה הריצה אוטומציה בלי השגחה, בלי תקרת הוצאה ובלי כפתור עצירה, וצברה חשבון AI של יותר מ-1,000 דולר ביום אחד. אפליקציה אחרת שבנינו מחדש עבדה מצוין בדמו אבל כל הזמן נשברה בשימוש אמיתי, כמה פיצ'רים נפלו כל הזמן, כי היא הייתה קובץ אחד ארוך בלי שום טיפול כזה סביבו. להוסיף את השכבה הזאת זה רוב מה שהופך תוצאה של טוטוריאל למשהו אמיתי.
הפער בין טוטוריאל לאפליקציה אמיתית הוא לא קוד קשה יותר. הוא החלקים ששום שיעור לא מכריח אתכם לטפל בהם: state ששורד רענון, בקרת גישה ששומרת על הפרדה בין משתמשים, config שעובר לשרת, וכשל שתכננתם מראש. תסגרו את אלה, ושלחתם, לא רק עקבתם אחרי מדריך.
כשסגרתם את הפערים האלה ואתם רוצים לדעת אם הפרויקט שלכם באמת מוכן למשתמשים, הבדיקה העצמית נמצאת בהאם האפליקציה שלכם מוכנה לפרודקשן, הצ'קליסט שמכריע. ואם אתם מעדיפים שמישהו יעבור על זה איתכם לפני השקה, הזמינו בדיקת מוכנות ל-production ונגיד לכם בכנות מה מחזיק ומה עדיין דולף. מסרנו 15 אפליקציות ככה, ועוד 2 בעבודה עכשיו, כל אחת עם בדיקות חדירה לפני שעלתה לאוויר, ואפליקציה קטנה בדרך כלל מוכנה תוך שבועיים עד ארבעה שבועות.
מייסד והמפתח הראשי של Zyntari. בונה אפליקציות ופתרונות AI מאז 2024; לפני כן, 12 שנים במכירות וניהול תיקי לקוחות ושותף‑מייסד בשתי חברות. עוד על הצוות · LinkedIn