לפני הפרומפט הראשון ב-Lovable: המפרט שמגדיר מה מותר למערכת לעשות

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

אפיון עסקי ל-vibe coding בארגון מתחיל בהחלטות, לא במסכים

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

במאמר של GitHub מ־2 באוקטובר 2026 מוצגות הגדרה ברורה של הבעיה, מסירת הקשר, הערכת קוד שנוצר ב-AI והחלטה מה מוכן למסירה כמיומנויות חשובות בהכוונת AI [1]. לצורך העבודה הארגונית, מומלץ לתרגם את הדגש הזה לחלוקת אחריות: מנהלי התהליך מגדירים את המשמעות העסקית; צוותי הפיתוח בוחרים כיצד לממש ולאכוף אותה; ושני הצדדים מסכימים מראש כיצד תיראה הוכחה שהדרישה התקיימה.

הגדירו תוצאה עסקית — וגבול ברור להיקף

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

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

נסחו כללים עסקיים שאפשר להפוך לבדיקות

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

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

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

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

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

בפרסום GitHub מ־1 באוקטובר 2026 מובאת הדרישה ״לפתוח בקשת משיכה, אך לא למזג אותה״ כדוגמה לגבול שרצוי לאכוף בהרשאות, ולא להסתפק בכתיבתו בקובץ הנחיות [2]. ברוח ההבחנה הזאת, מומלץ להפריד באפיון בין התנהגות מבוקשת לבין סמכות מותרת. אם יתווסף לתהליך סוכן AI, הגדירו בנפרד מה מותר לו להציע, מה מותר לו להכין ומה הוא רשאי לבצע ללא אישור אנושי.

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

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

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

תבנית עבודה משותפת למנהלי תהליכים ולצוותי פיתוח

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

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

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

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

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

מהמפרט להנחיות ב-Lovable — ומן ההנחיות לבחינת התוצאה

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

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

המלצות לארגון: הגדירו מראש מי מאשרים מה

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

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

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

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