עברית
שיחת היכרות

מאב-טיפוס שנבנה עם AI למוצר שאפשר לסמוך עליו

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

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

הקוד מתרבה במקום להתארגן

חברת GitClear ניתחה 211 מיליון שורות קוד שהשתנו בין 2020 ל-2024. שיעור השורות שהועתקו והודבקו עלה מ-8.3% ב-2021 ל-12.3% ב-2024. באותה תקופה ירד שיעור השורות שהוזזו, הסימן לכך שמישהו מארגן מחדש קוד קיים, מ-25% לפחות מ-10%. ב-2024, לראשונה, היה בפרויקטים יותר קוד מועתק מקוד שאורגן מחדש.

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

קוד שרץ הוא עדיין לא קוד בטוח

חברת האבטחה Veracode בודקת כבר ארבע שנים את הקוד שמודלי AI כותבים. בדוח שפרסמה ביולי 2026, על יותר מ-100 מודלים, כמעט כל הקוד עבר את בדיקת התחביר, כלומר רץ. בבדיקות האבטחה עבר בממוצע רק 56% ממנו. גם המודל הטוב ביותר במבחן הגיע ל-68%.

הדוגמה המוכרת מגיעה מעולם הכלים לבניית אפליקציות בלי קוד. במאי 2025 פרסם החוקר מאט פאלמר ש-170 מתוך 1,645 אפליקציות שהוצגו בגלריה של Lovable, כ-10%, חשפו מידע של משתמשים: כתובות מייל, מספרי טלפון, נתוני תשלום ומפתחות API. הסיבה הייתה הגדרת הרשאות חסרה או שגויה בבסיס הנתונים. האפליקציות עבדו מצוין, ופשוט כל אחד יכול היה לקרוא את הנתונים שלהן.

סביבת הייצור לא סולחת

ביולי 2025 תיעד ג'ייסון למקין, מייסד SaaStr, ניסוי של 12 ימים בבניית אפליקציה עם הסוכן של Replit. ביום התשיעי מחק הסוכן את בסיס הנתונים של סביבת הייצור, למרות הוראה מפורשת להקפיא שינויים. היו בו רשומות של 1,206 מנהלים ושל כ-1,200 חברות.

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

תחושת המהירות יכולה להטעות

ביולי 2025 פרסם מכון המחקר METR ניסוי מבוקר עם 16 מפתחים מנוסים ו-246 משימות אמיתיות. עם כלי AI, המשימות לקחו 19% יותר זמן. לפני הניסוי צפו המפתחים שה-AI יאיץ אותם ב-24%, וגם אחריו העריכו שהוא חסך להם 20%. בפברואר 2026 דיווח METR על ניסוי המשך עם כלים חדשים יותר, שבו התמונה כבר נוטה לכיוון של האצה, אבל המכון עצמו מגדיר את הראיות האלה כחלשות מאוד. הלקח המעשי פשוט: מודדים, ולא סומכים על תחושה.

דוח DORA של Google Cloud לשנת 2025, שנשען על כ-5,000 אנשי מקצוע, מוסיף את החלק שהכי חשוב ליזמים. שימוש ב-AI קשור לקצב מסירה גבוה יותר, אבל גם ליציבות נמוכה יותר של מה שנמסר. לפי הדוח, ה-AI מגביר את מה שכבר קיים בצוות. כשיש בדיקות אוטומטיות, ניהול גרסאות ומשוב מהיר, הוא מאיץ את העבודה. כשאין, הוא מאיץ גם את הבלגן.

אפיון שמוביל את הקוד

הכיוון שתופס היום מקום בתעשייה נקרא Spec-Driven Development: פיתוח שבו אפיון כתוב ומאושר מוביל, והקוד נגזר ממנו. בספטמבר 2025 פרסמה GitHub ערכת קוד פתוח בשם Spec Kit, שמחלקת את העבודה לארבעה שלבים: אפיון, תכנון, משימות ומימוש. במאי 2026 היא כבר עבדה עם יותר מ-30 סוכני AI שונים. ביולי 2025 השיקה AWS את Kiro, סביבת פיתוח שבנויה סביב אותו רעיון ומוצגת במפורש כגשר בין אב-טיפוס לייצור.

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

לפני שמשתמשים אמיתיים נכנסים

רשימה קצרה של מה שצריך להיות סגור לפני שמוצר עולה לאוויר:

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

לא תמיד צריך לכתוב מחדש

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

שאלות נפוצות

האם קוד שנכתב עם AI גרוע יותר מקוד שכתב מפתח?
לא בהכרח. הבעיה היא קוד שאף אחד לא בדק. לפי Veracode, כמעט כל הקוד שהמודלים כותבים רץ, אבל כמעט חצי ממנו נכשל בבדיקות אבטחה. מפתח מנוסה, בדיקות אוטומטיות ובדיקת אבטחה סוגרים את רוב הפער.
צריך להחליף את הכלי שבו נבנה האב-טיפוס?
לרוב לא. הכלי חשוב פחות מהשאלה אם יש אפיון, בדיקות והפרדה בין סביבות. את אלה אפשר להוסיף לפרויקט קיים.
מה זה Spec-Driven Development במשפט אחד?
פיתוח שבו קודם כותבים ומאשרים מה המערכת צריכה לעשות, ורק אחר כך כותבים קוד, גם כשסוכני AI כותבים אותו. האפיון הוא המקור, והקוד נבדק מולו.
כמה זמן לוקח לייצב אב-טיפוס לפני עלייה לאוויר?
זה תלוי בגודל המוצר ובמצב הקוד, ולכן מספר אמין אפשר לתת רק אחרי שמאפיינים את מה שקיים. מי שנותן מספר מחייב לפני כן, מנחש.

מקורות

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