בניתי מוצר עם AI—איך לשפר בלי לשבור את מה שכבר עובד

קראו עוד על עבודה עם מודלים בתיעוד של Ailoot.

למה העבודה היקרה ביותר מתחילה אחרי ההשקה?#

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

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

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

המדריך ״העלות הנסתרת של vibe coding״ מסביר את הנתונים האלה בפירוט רב יותר. שם השאלה הייתה על מה אתם משלמים. כאן השאלה אחרת: 44 סנט מכל דולר הולכים לתיקון באגים—וכל המאמר הזה עוסק במניעת גדילתו של החלק הזה. העבודה ששומרת עליו בשליטה נקראת תחזוקה.

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

מה באמת נשבר: 5 אסונות אחרי ההשקה#

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

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

הבעיה אינה בכך שהקוד לא נכתב ביד—כך עובדים אנשים רבים. הבעיה היא שלא שואלים: ״האם מסד הנתונים מאובטח?״ בהמשך אראה לכם הנחיה ששואלת את השאלה הזאת עבורכם.

רשת הביטחון הראשונה היא git והחזרה ל״איך שזה היה אתמול״#

כש-Claude שובר משהו, אתם צריכים כפתור ״תחזיר את זה לאיך שזה היה אתמול״. מבחינה טכנית קוראים לכפתור הזה git, והוא פשוט יותר מכפי שהוא נשמע.

שלושה מונחים שאדם שאינו מתכנת צריך להבין:

1. מאגר — תיקיית הפרויקט שלכם שנשמרת בענן (בדרך כלל ב-GitHub). עותק של כל הקוד שלכם, שלא נמצא רק במחשב שלכם.
2. Commit — נקודת חזרה. למעשה, אתם אומרים לקוד: ״שמור במצב הזה״. כל commit הוא סימון שאפשר לחזור אליו.
3. פריסה (Deploy) — העברה. הקוד היה מקומי, במחשב שלכם, ועבד רק עבורכם. פריסה שולחת אותו לשרת חיצוני כדי שיעבוד עבור כולם.

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

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

שני כללים שכדאי להחיל מיד, לפני שאנשים אחרים רואים את המוצר:

• המאגר חייב להיות פרטי. לא ציבורי. אחרת, כל אחד יכול לקרוא את הקוד שלכם ואת כל מה שנמצא בו.
• הוסיפו את קובץ הסודות לרשימת ההתעלמות. מפתחות, סיסמאות ופרטי גישה למסד הנתונים נשמרים בקובץ נפרד (בדרך כלל .env), והקובץ הזה לעולם לא נכנס למאגר. הוסיפו שורה עבור .env ל-.gitignore, והסודות נשארים אצלכם.

יש מדריך נפרד לשחזור בטוח של שינויים ב-Claude Code: איך לשחזר שינויים ב-Claude Code. בלי נקודות חזרה, אתם הולכים על חבל בלי רשת ביטחון, ובמוקדם או במאוחר תיפלו.

על מה /rewind מחזיר לאחור, ועל מה לא?#

Claude Code יוצר תמונת מצב של המצב לפני כל שינוי שהוא מבצע. הפקודה /rewind (או לחיצה פעמיים על Esc) מחזירה את הקבצים ואת השיחה לנקודה שנבחרה. זה שימושי: אם שברתם תכונה לפני חמש דקות, אפשר לחזור חמש דקות אחורה.

אבל יש מלכודת שגורמת למתחילים לאבד נתונים. /rewind לא מחזיר הכול לאחור:

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

המסקנה המעשית למי שאינו מתכנת: /rewind יציל אתכם ממצב שבו ״Claude פשוט שבר תכונה״. אבל אם הוא הספיק למחוק שורה במסד הנתונים או להעלות קוד לענן, רק git וגיבוי של מסד הנתונים יכולים להחזיר אותה. לכן השאירו את שתי השכבות: תמונות מצב לשחזורים מהירים, ו-commits להיסטוריה הקבועה של הפרויקט.

איך משפרים בלי לשבור את מה שכבר עובד?#

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

הלולאה מתרחשת כי vibe coding אינו דטרמיניסטי. אותה הנחיה יכולה להפיק קוד שונה בשתי פעמים. לכן כל עריכה עלולה לשנות בשקט את הלוגיקה שמסביבה: סף ההנחה משתנה מ-10 ל-12 אחוזים, או שכלל אימות משנה את התנהגותו—בלי בדיקות מצדכם ובלי אפילו אזהרה אחת. קוראים לזה סטייה לוגית, והיא פוגעת בשקט בדיוק בדברים שמכניסים כסף: מחירים, גישה ותשלומים.

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

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

לפני שתשנה את הקוד, בצע את הפעולות הבאות:

שמור את המצב הנוכחי שבו הכול עובד כנקודת שחזור נפרדת (commit).

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

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

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

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

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

איך בודקים שינוי לפני שמפרסמים אותו?#

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

1. בנו ובדקו את השינוי בעצמכם (פיתוח).
2. פרסו אותו ל-staging—עותק של סביבת הייצור, אך ללא משתמשים אמיתיים.
3. הריצו את התרחישים המרכזיים וודאו ששום דבר לא השתנה.
4. רק עכשיו פרסו לסביבת הייצור.

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

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

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

רישום משתמש חדש וכניסה לחשבון.

תשלום ומתן גישה לאחר התשלום.

הרשאות גישה—משתמש רגיל לא יכול לראות נתונים של מישהו אחר או את אזור הניהול.

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

איפה נמצאים הסודות שלכם? הפרצה הגדולה ביותר למתחילים#

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

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

בדוק את הפרויקט כולו וודא שאף מפתח סודי לא מגיע לדפדפן:

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

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

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

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

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

עבור על הפרויקט כמו תוקף ומצא פרצות אבטחה:

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

האם אבטחה ברמת שורה (RLS) מופעלת בכל טבלה במסד הנתונים, והאם הרשאות הגישה נבדקות בשרת ולא רק בדפדפן?

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

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

יש מדריך מלא ונפרד לאבטחת vibe coding: איך לאבטח אפליקציה שנבנתה ב-vibe coding. הכלל פשוט: התייחסו לכל דבר ש-AI עשה כברירת מחדל כאל דבר שאינו מאובטח, עד שתבדקו אחרת.

איפה לארח את המוצר: מדרג אפשרויות האירוח#

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

1. אירוח בחינם (למשל Vercel)—לשימוש אישי, בדיקות ופרויקטים קטנים. הוא מתאים אם הפלטפורמה זמינה לקהל שלכם ואתם לא מאחסנים מידע אישי של אנשים.
2. פלטפורמה עם פריסה בפקודה אחת (Railway)—כשיש לכם backend ומסד נתונים. פורסים בפקודה אחת ואין צורך להגדיר שרת. חסם הכניסה מינימלי.
3. שרת ייעודי משלכם—כשהעומס גבוה ואתם זקוקים לשליטה מלאה. עברו אליו מאוחר יותר, כשתגיעו למגבלה של הפלטפורמה.

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

מתי להפריד בין האפליקציה, מסד הנתונים והגיבויים?#

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

• העבירו את האפליקציה ואת מסד הנתונים למכונות שונות. הסימן: בעומס שיא, השימוש במעבד ובזיכרון נשאר מעל 70–80 אחוז, הבקשות מאטות, והאפליקציה ומסד הנתונים נאבקים על אותם משאבים. אחרי שמפרידים ביניהם, אפשר לחזק את מסד הנתונים בלי לגעת באפליקציה, ולהפך.
• פעלו לפי כלל הגיבוי 3-2-1. שלושה עותקים של הנתונים, בשני סוגי מדיה שונים, כאשר אחד נמצא מחוץ לאתר. כך מתגוננים מפני כשל חומרה ותוכנות כופר. העיקר הוא שהגיבויים יהיו אוטומטיים.

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

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

מה העומס על המעבד והזיכרון בשעות השיא—האם השימוש נשאר מעל 70–80 אחוז או לא?

האם מסד הנתונים והאפליקציה נמצאים באותה מכונה או במכונות שונות?

האם מוגדר גיבוי אוטומטי למסד הנתונים, והאם בדקתי את השחזור ממנו?

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

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

איך מעבירים את התחזוקה לטייס אוטומטי?#

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

הניטור משתמש בשני כלים שונים לשתי משימות שונות:

1. ״האם האתר פעיל?״—כלי לניטור זמינות (למשל UptimeRobot). הוא שולח בקשת בדיקה למוצר מדי כמה דקות ומתריע אם הוא נופל. יש מסלול בחינם.
2. ״מה בדיוק נשבר?״—כלי למעקב אחר שגיאות (למשל Sentry). הוא אוסף שגיאות בתוך האפליקציה ומראה איפה ולמה משהו נכשל.

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

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

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

מתי הגיע הזמן לסגור מוצר?#

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

ספי זמן שאפשר להשתמש בהם כדי להחליט:

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

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

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

בניית מוצר עם AI בערב אחד היא חצי מהעבודה. לשמור עליו חי ומאובטח בזמן שהוא גדל—זה מה שפירושו vibe coding למבוגרים.

לצעד הבא שלכם—Ailoot.