AI-SDLC
פיתוח תוכנה מבוסס AI ומתודולוגיית Spec-Driven Development
Spec Kit מאפשר ליישם עקרונות של Spec-Driven Development גם בפיתוח מערכות חדשות וגם בתהליכי הרחבה ומודרניזציה של מערכות קיימות.
כך ניתן לשלב AI גם בפרויקטים קיימים, ולא רק במערכות שנבנות מאפס.
פיתוח תוכנה באמצעות AI כבר אינו מסתכם בשימוש בכלי שמציע למפתח את שורת הקוד הבאה.
כלי AI מסוגלים כיום להשתתף באפיון, לנתח דרישות, להציע ארכיטקטורה, לפרק פיתוח למשימות, לייצר קוד, לסייע בבדיקות, לאתר חוסר עקביות ולתמוך בתהליכי תחזוקה ושיפור של מערכות קיימות.
אבל היכולת לייצר יותר קוד ובמהירות גבוהה יותר אינה בהכרח הדרך לבנות מערכת טובה יותר.
למעשה, ככל שיכולת היישום באמצעות AI משתפרת, כך עולה החשיבות של השאלה שמגיעה לפניה:
האם הגדרנו בצורה מספיק מדויקת מה אנחנו רוצים שהמערכת תעשה?
ב-Dogma אנחנו משלבים AI כחלק מתהליך ה-Software Development Life Cycle, בגישה שאנחנו מיישמים כ-AI-SDLC.
המטרה אינה להחליף את אנשי המוצר, הארכיטקטים והמפתחים ב-AI.
המטרה היא להשתמש ב-AI כדי להאיץ את מחזור הפיתוח כולו, תוך שמירה על Specification, החלטות אנושיות, בקרת איכות והבנה עסקית כמנגנונים שמכוונים את התהליך.
אחד הכלים שאנחנו משלבים בגישה זו הוא Spec Kit, המבוסס על עקרונות של Spec-Driven Development.
מהו AI-SDLC?
SDLC הוא מחזור החיים של פיתוח תוכנה.
בפרויקט תוכנה מקצועי, הקוד הוא רק חלק מהתהליך.
לפניו קיימים שלבים של הבנת הצורך העסקי, הגדרת דרישות, אפיון המוצר, תכנון חוויית המשתמש וארכיטקטורה.
לאחריו מגיעים בדיקות, תיקונים, Deployment, ניטור, תחזוקה והמשך פיתוח.
AI-SDLC מכניס יכולות AI לתוך השלבים האלה במקום להתייחס ל-AI רק ככלי Coding.
המשמעות היא שניתן להשתמש בסוכני AI כדי לסייע בניתוח דרישות, איתור פערים, בניית תכנית טכנולוגית, פירוק למשימות, יישום, בדיקות ובקרת עקביות.
אבל יש לכך תנאי חשוב.
ה-AI צריך לעבוד מתוך הקשר מובנה ומוגדר, ולא מתוך אוסף Prompts חד-פעמיים.
וזה בדיוק המקום שבו Spec-Driven Development הופך למשמעותי.
האנשים שמחברים בין Product Design, מערכות מורכבות ו-AI-SDLC
מאחורי תהליכי ה-AI-SDLC של חברת Dogma (דוגמה בע״מ) עומד צוות מנוסה המשלב הבנה עמוקה של Product Design, אפיון מערכות, UX, ארכיטקטורה ופיתוח של מערכות מורכבות.
בני אובלנדר, דור בן משה ויפעת רוזנברג מביאים לתהליך ניסיון רב שנים בעבודה על מוצרים ומערכות שבהם אי אפשר להסתפק ב-Prompt טוב או בפיתוח מהיר.
מערכות עבור משרדי ממשלה, גופים ציבוריים ותעשיות ביטחוניות מחייבות להבין תהליכים עסקיים ותפעוליים מורכבים, משתמשים מסוגים שונים, הרשאות, אינטגרציות, מערכות Legacy, אבטחת מידע, עומסים ומקרי קצה.
הניסיון של הצוות ב-Product Design למערכות מורכבות הוא חלק משמעותי מהאופן שבו Dogma מיישמת AI-SDLC. לפני שמפעילים AI כדי לתכנן או לייצר קוד, צריך לדעת לשאול את השאלות הנכונות, לפרק תהליך מורכב לדרישות ברורות, לזהות פערים ולהפוך צורך עסקי ל-Specification שניתן באמת לפתח ממנו.
לאורך השנים צוות Dogma היה מעורב בפרויקטים עבור גופים כגון Campus IL, משרד החינוך, רשות הכבאות וההצלה והתעשייה האווירית, לצד מערכות ופרויקטים מורכבים נוספים במגזר הציבורי, הממשלתי והביטחוני.
החיבור הזה בין ניסיון מעשי במערכות מורכבות לבין כלי AI ומתודולוגיות כמו Spec-Driven Development ו-Spec Kit הוא מבחינתנו אחד היתרונות המרכזיים של AI-SDLC: הטכנולוגיה יכולה להאיץ את העבודה, אבל הניסיון האנושי הוא זה שמגדיר מה נכון לבנות, איך נכון לבנות אותו ואילו שאלות חייבים לפתור לפני שה-Agent מתחיל לכתוב קוד.
התוצאה
התוצאה היא תהליך פיתוח מדויק, מהיר ומבוקר יותר, שבו AI אינו מחליף את הניסיון המקצועי אלא מעצים אותו.
השילוב בין Product Design, אפיון מוקדם, Spec-Driven Development וכלי AI מאפשר לצמצם פערים בין הדרישה העסקית לבין המוצר שמפותח בפועל, לזהות בעיות מוקדם יותר ולהפחית עבודה חוזרת ושינויים יקרים בשלבים מתקדמים.
עבור הלקוח המשמעות היא Time to Market מהיר יותר, ניצול יעיל יותר של תקציב הפיתוח, שקיפות גבוהה יותר לאורך התהליך ומערכת שנבנית מלכתחילה על בסיס הבנה עמוקה של הצורך העסקי והטכנולוגי.
AI מאפשר לנו לנוע מהר יותר. הניסיון של הצוות מאפשר לנו לוודא שאנחנו נעים בכיוון הנכון.
מ-Prompt-Driven Development ל-Spec-Driven Development
אחת הבעיות בפיתוח באמצעות AI מתחילה כאשר העבודה מתנהלת כרצף של הוראות.
- "בנה לי מסך הרשמה."
- "תוסיף אפשרות לעריכת משתמש."
- "תוסיף הרשאות למנהל."
- "עכשיו תחבר את זה ל-API."
כל בקשה יכולה להיות הגיונית בפני עצמה.
אבל ככל שהמערכת גדלה, ה-AI צריך להבין הרבה יותר מהמשימה הנקודתית.
- מהם חוקי המערכת.
- אילו סוגי משתמשים קיימים.
- מי רשאי לבצע כל פעולה.
- מה קורה במקרה של כשל.
- איזה מידע נשמר.
- מה קורה לתהליך קיים כאשר משנים דרישה.
- אילו אינטגרציות מושפעות מהשינוי.
במערכת עסקית מורכבת, אלו אינם פרטים שוליים.
זו המערכת.
Spec-Driven Development משנה את נקודת המוצא.
במקום להתחיל מהשאלה "איזה קוד צריך לכתוב?", מתחילים מהשאלה "מה בדיוק אנחנו רוצים לבנות?"
GitHub מתארת את Spec Kit ככלי שמאפשר להגדיר את מה שרוצים לבנות לפני שמתחילים לבנות אותו באמצעות AI Coding Agent.
מהו Spec Kit?
GitHub Spec Kit הוא פרויקט Open Source שמספק תהליך מובנה ל-Spec-Driven Development באמצעות AI Coding Agents.
בבסיס התהליך נמצאים ארבעה שלבים מרכזיים:
Specify → Plan → Tasks → Implement
כל שלב מייצר Artifact מובנה שמספק הקשר לשלב הבא, במקום להסתמך בכל פעם מחדש על Prompt חופשי.
בגרסה הנוכחית קיימים גם שלבים נוספים כמו Constitution, Clarify, Checklist, Analyze ו-Converge, שמאפשרים להוסיף עקרונות לפרויקט, לפתור עמימויות, לבדוק איכות ועקביות ולבחון את היישום מול ה-Specification והתכנית.
עבורנו, החשיבות אינה בשימוש בפקודה כזו או אחרת.
החשיבות היא במתודולוגיה שמאחוריה.
שלב 1 – מתחילים מהבעיה העסקית
לפני AI ולפני קוד צריך להבין את העסק.
- מי המשתמש.
- איזו בעיה אנחנו פותרים.
- מהו התהליך העסקי.
- מהו ה-MVP.
- אילו דרישות הן Must Have.
- מהם מקרי הקצה.
- אילו מגבלות קיימות.
- ואילו החלטות עלולות להשפיע בהמשך על הארכיטקטורה.
AI יכול לסייע בשלב הזה, אבל הוא אינו בעל המוצר.
החלטות עסקיות נשארות בידי בני אדם.
זו גם הסיבה שאנחנו מחברים את AI-SDLC ל-Product Design ול-FDE ולא מתייחסים אליו כתהליך פיתוח מבודד.
שלב 2 – Specification כ-Source of Truth
לאחר שהצורך ברור, הוא הופך ל-Specification מובנה.
ה-Specification מגדיר מה המערכת אמורה לעשות, כיצד משתמשים פועלים בה, מהם התרחישים המרכזיים ומהם התנאים להצלחה.
ב-Spec Kit, שלב /speckit.specify יוצר או מעדכן Feature Specification מתוך תיאור בשפה טבעית.
אבל בפרויקטים מורכבים לא מספיק לייצר מסמך ולהמשיך הלאה.
ה-Specification צריך להיות מקור הייחוס של תהליך הפיתוח.
אם קיימת עמימות, לא רוצים שה-Agent פשוט "יחליט".
רוצים לזהות את העמימות, לפתור אותה ורק אז להמשיך.
שלב 3 – מהדרישה לתכנית טכנולוגית
לאחר שהוגדר ה-"מה", מגיע ה-"איך".
כאן נכנסות החלטות כמו ארכיטקטורה, בסיסי נתונים, APIs, אבטחה, הרשאות, אינטגרציות, Cloud, מערכות Legacy, ביצועים ו-Scalability.
Spec Kit מפריד בין שלב ה-Specification לבין שלב ה-Plan בדיוק מהסיבה הזאת:
הדרישה העסקית והתכנון הטכנולוגי אינם אותו דבר.
ההפרדה חשובה במיוחד בעבודה עם AI.
אנחנו לא רוצים שהמודל ישנה דרישה עסקית רק משום שפתרון אחר קל יותר עבורו ליישום.
שלב 4 – פירוק למשימות שה-AI יכול לבצע
אחד היתרונות הגדולים של AI בפיתוח מגיע כאשר בעיה גדולה מפורקת ליחידות עבודה ברורות.
במקום לבקש מסוכן AI "לבנות את המערכת", התכנית מפורקת למשימות שנגזרות מה-Specification ומהתכנון הטכנולוגי.
Spec Kit כולל שלב Tasks בדיוק למטרה הזאת.
כך אפשר ליצור קשר ברור יותר בין דרישה, תכנית, משימת פיתוח והיישום בפועל.
מבחינת צוות פיתוח, זה הבדל משמעותי.
AI אינו מקבל חופש בלתי מוגבל לבנות "משהו שנראה נכון".
הוא מקבל משימה בתוך Context מוגדר.
שלב 5 – AI מאיץ את ה-Implementation
רק עכשיו מגיעים לקוד.
כאן AI יכול לייצר מינוף משמעותי.
יצירת Components, APIs, Tests, Models, Validation, Migrations, Documentation וקוד אינטגרציה יכולה להתבצע במהירות גבוהה משמעותית כאשר ה-Agent כבר מחזיק את ההקשר הנכון.
אבל מבחינתנו, מהירות אינה המדד היחיד.
המטרה היא להגיע מהר יותר ל-קוד שתואם את הדרישות.
זה הבדל מהותי.
שלב 6 – לא רק Generate, גם Analyze
אחד השימושים החשובים ביותר ב-AI אינו יצירת קוד אלא ביקורת עליו ועל התהליך שהוביל אליו.
האם המשימות מכסות את הדרישות.
האם קיימת סתירה בין ה-Specification לתכנית.
האם Requirement מסוים נעלם בדרך.
האם היישום בפועל עדיין תואם למה שהוגדר.
Spec Kit כולל Quality Gates כמו Clarify, Checklist ו-Analyze, ובתהליך הנוכחי גם Converge, שמטרתו לבחון את ה-Codebase מול ה-Artifacts ולהמשיך עד להתכנסות.
עבור מערכות מורכבות זה משמעותי במיוחד.
AI לא צריך להיות רק העובד המהיר ביותר בצוות.
הוא יכול להיות גם שכבת בדיקה נוספת.
ומה קורה כאשר הדרישות משתנות?
הן ישתנו.
לקוחות משנים תהליכים.
משתמשים מלמדים אותנו דברים חדשים.
רגולציה משתנה.
אינטגרציות מתחלפות.
פיצ'רים חדשים מתווספים.
Spec-Driven Development אינו מיועד רק ל-Greenfield.
Spec Kit מתאר גם שימוש ב-Iterative Enhancement עבור Brownfield – הוספת יכולות ומודרניזציה של מערכות קיימות – לצד פיתוח מערכות חדשות ו-Creative Exploration.
מבחינת AI-SDLC, זו נקודה קריטית.
אם ה-Specification נשאר חלק חי ממחזור החיים, שינוי יכול להתחיל מעדכון הדרישה ולהמשיך באופן מסודר אל ההשפעות על התכנון, המשימות והקוד.
AI-SDLC אינו "Vibe Coding"
אפשר לבנות היום Prototype מרשים באמצעות כמה Prompts.
וזה מצוין כאשר המטרה היא לבדוק רעיון במהירות.
אבל מערכת Enterprise, מערכת SaaS, מערכת Mission-Critical או מוצר עם אינטגרציות, הרשאות, מידע רגיש ותהליכים עסקיים מורכבים דורשים יותר.
הם דורשים Traceability.
הם דורשים החלטות ארכיטקטוניות.
הם דורשים בדיקות.
והם דורשים יכולת להבין מדוע משהו נבנה כפי שנבנה.
AI-SDLC מאפשר ליהנות מהמהירות של Generative AI מבלי להפוך את תהליך הפיתוח לסדרה של החלטות לא מתועדות.
איפה בני האדם נמצאים בתהליך?
במרכז.
AI יכול להציע ארבע ארכיטקטורות.
מישהו עדיין צריך להחליט איזו מתאימה למודל העסקי, לתקציב, ל-Team Skills, ל-Time to Market ולמערכת שתצטרך להתקיים בעוד שלוש שנים.
AI יכול לזהות שחסרה דרישה.
מישהו צריך להחליט מה הדרישה הנכונה.
AI יכול לייצר קוד.
Architect או Developer עדיין צריכים להבין את ההשלכות שלו.
לכן מבחינת Dogma, AI-SDLC אינו תהליך שמוציא את האדם ממחזור הפיתוח.
הוא משנה את המקום שבו הערך האנושי נדרש.
פחות זמן מושקע בעבודה מכנית.
יותר זמן מושקע בהחלטות.
החיבור בין AI-SDLC ל-FDE
זו גם הסיבה שאנחנו רואים חיבור טבעי בין AI-SDLC לבין Forward Deployed Engineer – FDE.
FDE מתחיל קרוב לבעיה העסקית.
הוא עובד עם הארגון כדי להבין את התהליכים, הנתונים, המערכות הקיימות והיעדים, ומחבר בין הצורך העסקי לבין היכולת הטכנולוגית והאפשרויות החדשות ש-AI יוצר.
כאשר משלבים FDE בתחילת התהליך, אפשר להגדיר בצורה מדויקת יותר מה נכון לבנות עוד לפני שה-AI מתחיל להאיץ את הפיתוח.
לא כל בעיה צריכה Agent.
לא כל תהליך צריך מודל AI.
ולא כל דרישה צריכה להפוך לפיצ'ר.
לפעמים הערך הגדול ביותר מגיע דווקא מהחלטה לא לפתח משהו.
AI-SDLC ב-Dogma
Dogma משלבת ניסיון בפיתוח מערכות מורכבות, Product Design, UX, ארכיטקטורה ופיתוח תוכנה עם כלי AI ומתודולוגיות Spec-Driven Development.
אנחנו משתמשים ב-AI לא כדי לוותר על תהליך הפיתוח המקצועי, אלא כדי לשפר אותו.
האפיון מגדיר את הכוונה.
הארכיטקטורה מגדירה את הדרך.
AI מסייע לנתח, לתכנן, לפרק, ליישם ולבדוק.
והצוות המקצועי נשאר אחראי על ההחלטות ועל התוצאה.
זהו מבחינתנו המעבר האמיתי מפיתוח תוכנה עם AI ל-AI-SDLC.
לא רק לכתוב קוד מהר יותר, אלא לנהל את כל הדרך מהבעיה העסקית ועד למערכת עובדת באמצעות תהליך שבו בני אדם ו-AI עובדים יחד.
מדברים מוצר, ארכיטקטורה ו-AI שבאמת עובד בשטח
בין אם אתם מתכננים מערכת חדשה, מחפשים ליישם מתודולוגיית AI-SDLC או צריכים ללוות תהליך אפיון ופיתוח מורכב — הצוות שלנו ב-Dogma כאן כדי לוודא שאתם נעים בכיוון הנכון.
