מ־MVP שנבנה עם Claude Code או Codex למוצר שמוכן לפרודקשן

Claude Code ו־Codex יכולים לקרוא ולערוך קבצים בפרויקט, להריץ פקודות ובדיקות ולעזור לבנות תוכנה עובדת. עם הכוונה וביקורת, הם יכולים לעזור ליזם להפוך רעיון שעדיין לא גובש עד הסוף למסכים, לתהליכים שמחוברים לבסיס נתונים ולאבטיפוס שמשתמשים יכולים לנסות.

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

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

האם להעלות אותו כמו שהוא, או לכתוב הכול מחדש?

השאלה שצריך לשאול היא:

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

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

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

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

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

הסוג השני הוא מה למדנו על התשתית הטכנית:

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

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

מה אפשר לשמור

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

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

לא החלטה אחת, אלא ארבע

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

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

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

מה בודקים לפני שעולים לפרודקשן

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

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

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

בדיקה מעשית, שלב אחר שלב

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

1. עוברים על המוצר מנקודת המבט של המשתמש. מתעדים את התהליך המרכזי, החריגים והתקלות הידועות.
2. ממפים את המערכת. מזהים את בסיס הקוד, מאגרי הנתונים, השירותים החיצוניים, הסביבות והבעלות על החשבונות.
3. עוקבים אחר פעולות קריטיות. בודקים איך שינוי מצב עובר מהממשק דרך ה־API ועד לאחסון הנתונים.
4. מריצים את הבדיקות הקיימות. בודקים אם המוצר נבנה, נפרס ועובר את הבדיקות שכבר קיימות.
5. בודקים אזורים בסיכון גבוה. מתמקדים בהזדהות, בהרשאות, במידע רגיש, בתשלומים, בפעולות של סוכנים וברשומות עסקיות שקשה לשחזר.
6. מסווגים את החלקים. משאירים, מחזקים, מחליפים או בונים מחדש — עם הסבר לכל החלטה.
7. מתכננים בשלבים. קודם מגינים על ההתנהגות החשובה, ואז משפרים או מחליפים את היסודות בלי לאבד את תובנות המוצר שכבר אומתו מול משתמשים.

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

שומרים על מה שלמדנו ומצמצמים סיכון

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

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

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

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

מקורות והעמקה

• OpenAI: Codex — היכולות ותהליכי העבודה העדכניים של Codex בפיתוח תוכנה.
• Anthropic: איך Claude Code עובד — גישה לקובצי הפרויקט, לפקודות, לבדיקות ולמצב Git.
• GOV.UK: יצירת אבות־טיפוס — מדוע קוד לאבטיפוס וקוד לפרודקשן עשויים לדרוש סטנדרטים שונים.
• GOV.UK: בדיקות שימושיות מונחות — תצפית באנשים שמבצעים משימות מציאותיות.
• NIST: מסגרת לפיתוח תוכנה מאובטח — פרקטיקות פיתוח מאובטח שמותאמות לרמת הסיכון.
• OWASP: מדריך להרשאות — הרשאות מינימליות, בדיקת הרשאות, לוגים ובדיקות אוטומטיות.
• NIST: פרופיל סיכונים ל־Generative AI — דרגות סיכון, הערכה, פיקוח ובקרות לפני פריסה.
• GOV.UK: הפעלת שירות אמין — בדיקות, ניטור, תגובה לתקלות ותכנון אמינות בהתאם לרמת הסיכון.
• DORA: עבודה במנות קטנות — משוב, אימות ומסירת תוכנה במנות קטנות.

להמשך: פיתוח מערכות ווב לפי התהליך העסקי האמיתי.

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