הרבה צוותי פיתוח כבר משלמים כל חודש על Claude Code, Cursor או Codex, ומחכים שהדליברי יתקצר. אצל חלק גדול מהם זה עוד לא קרה (ואם לא יעשו את הצעדים הנכונים זה גם לא יקרה).
ראינו את זה קודם אצלנו, בצוותי הפיתוח של אקספריטי, ואחר כך גם בשני דוחות מ-2026.
בשני המקרים ה-AI עבד. מה שנשאר מאחור וגרם לעיכוב בפיתוח היה דווקא כיוון אחר שבדרך כלל לא חושבים עליו – שיטת העבודה עם הכלים.
לשיטת עבודה שבנינו קוראים AI SDLC, ואלה הדברים שלמדנו כשבנינו אותה.
מה זה AI SDLC?
AI SDLC הוא מחזור חיי פיתוח תוכנה (Software Development Life Cycle) שנבנה מראש לעבודה עם סוכני קוד כמו Claude Code, Cursor ו-Codex.
כל משימה מתחילה ב-spec מאושר, הסוכנים עובדים בסשנים מקבילים ומבודדים, ושערי איכות אוטומטיים ב-CI/CD בודקים כל שינוי לפני שהוא עולה לפרודקשן. המטרה היא דליברי מהיר יותר בלי לשלם על זה ביציבות הפרודקשן (סביבת הייצור).
למה הדליברי לא מתקצר אחרי שנותנים לצוות Claude Code או Cursor?
העבודה עם AI בצוות פיתוח נתקעת בדרך כלל באחד משני מקומות:
הסיבה הראשונה שהדליברי שלכם לא מתקצר
חברת Faros AI ניתחה נתוני עבודה של 22,000 מפתחים לאורך שנתיים, ופרסמה את הממצאים בדוח שלה מאפריל 2026.
בצוותים שעברו לאימוץ AI גבוה, הסיכוי לתקלה בפרודקשן לכל PR שמוזג גדלה פי 2.
Faros מסבירים את זה כך: מערכות הפיתוח נבנו לקצב של בני אדם, והן לא עומדות בכמות הקוד ש-AI מייצר היום.
למה הדליברי לא מתקצר בשימוש עם AI - הסיבה השנייה
הסיבה הנוספת היא שאתם אומנם משלמים על הרישיונות כל חודש, אבל הצוות ממשיך לעבוד כמו קודם.
באותו דוח של Faros, אחוז המפתחים שמחזיקים רישיון לכלי AI לא השתנה. הארגונים כבר קנו את הרישיונות.
מה שהשתנה הוא השימוש, ועדיין רק 60% מהמפתחים משתמשים בכלי AI לפחות פעם בשבוע.
גם בסקר ש-Jellyfish ערכה במרץ 2026 התמונה דומה: רק 10% מהמשיבים דיווחו על הטמעה חזקה ואימוץ גבוה של AI.
למה code review הוא צוואר בקבוק כשעובדים עם AI?
שתי הסיבות נפגשות בשלב הזה. לפי Faros, בצוותים עם אימוץ AI גבוה זמן ה-review החציוני עלה פי 5, ויש 31.3% יותר PRs שממוזגים בלי שום ביקורת.
בתחילת הדרך ראינו את זה גם אצלנו, וכתבנו על זה בלקחים שפרסמנו בפברואר: AI מגביר את תשתית האיכות של הצוות, וגם את היעדרה.
כשהקוד התחיל להיכתב מהר, עומס האימות התרכז אצל המפתחים הבכירים, שהיו צוואר הבקבוק עוד קודם.
השורות יוצאות מהר, והתור נתקע אצל מי שצריך לאשר אותן.
מה שחסר לצוותים האלה הוא שיטת פיתוח שנבנתה לעבודה עם AI. הכלי אולי חדש, אבל התהליך נשאר כמו שהיה.
רוצים להבטיח שהצוות שלכם ישתמש בAI בצורה שבאמת תוביל לקיצור זמני פיתוח?
השאירו פרטים כאן לתיאום שיחת היכרות
מילוי הפרטים לטובת יצירת קשר מהווה הסכמה למדיניות הפרטיות של האתר
מה צריך לשנות בצוות פיתוח כדי ש-AI יקצר את הדליברי?
אלה ארבעת השינויים שאנחנו מטמיעים. כולם עברו קודם את המבחן בצוותים שלנו (We eat our own dog food).
Spec driven development
Spec driven development (פיתוח מבוסס spec) פירושו שכל משימה של סוכן מתחילה במסמך שמגדיר מה בדיוק בונים. הצוות מאשר אותו, ורק אז הסוכן כותב קוד.
סשנים מקבילים עם git worktree
צוואר הבקבוק בעבודה עם סוכנים הוא המקביליות.
משתנה אחד גוזר את כל הפורטים של הסביבה, כך שכמה סשנים רצים על אותה מכונה בלי להתנגש. ה-DB משותף, וכל worktree מקבל tenant נפרד עם בידוד נתונים ב-RLS.
שערי איכות ב-CI/CD, ביקורת קוד ב-AI ו-hooks לפני commit
סוכני קוד נוטים לדלג על שלבים ולקפוץ ל-done בלי טסטים ובלי code review.
בצוות שלנו עובדים עם סקיל בקוד פתוח שאוכף כל שער לפי הסדר: הרחבת הסטורי, אישור תוכנית, טסטים קודם, אימות, code review, ורק אז ship. אנחנו קוראים לזה “CI/CD לתהליך הפיתוח עצמו”.
סיווג מידע לפני שמפיצים את הכלים
עוד לפני שהכלים מגיעים לכל הצוות, מחליטים מה אף פעם לא נכנס לסשן של סוכן. מידע של לקוחות, פרטי ארכיטקטורה ופיצ’רים שעוד לא יצאו מקבלים סיווג מראש.
רוצים לראות איפה הדליברי שלכם נתקע ואיך אתם יכולים באמת לקצר זמני פיתוח עם AI?
ספרו לנו על הצוות בטופס, ונחזור אליכם לתיאום שיחת היכרות.
מילוי הפרטים לטובת יצירת קשר מהווה הסכמה למדיניות הפרטיות של האתר
שאלות נפוצות על AI SDLC
מה ההבדל בין AI SDLC לבין לתת למפתחים רישיון ל-Cursor או ל-Claude Code?
מה זה spec driven development?
למה לא מספיק להגיד לצוות לכתוב spec לפני שעובדים עם AI?
כמה סשנים של סוכן קוד מפתח אחד יכול להריץ במקביל?
למה כדאי להגביל מראש את אורך הסשן עם סוכן קוד?
איך מונעים דליפה של קוד ומידע רגיש לכלי AI?
איך מודדים שה-AI באמת מקצר את הדליברי ולא רק ״מרגיש מהיר״?
