אל תכתבו את מערכת הניהול שלכם ב-vibe coding. כתבו את מה שמסביב לה

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

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

במה vibe coding באמת טוב

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

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

למה מערכת הניהול שלכם היא היעד הלא נכון

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

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

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

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

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

נכונות סטטוטורית אינה משהו שבודקים בעין

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

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

ואז זה עוד צריך לשרוד

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

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

המבחן שבאמת מכריע

שכחו מקטגוריות של תוכנה. שאלו שאלה אחת על כל דבר שאתם עומדים לבנות:

אם זה שגוי, איך אגלה?

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

אז מה כן כדאי לכתוב לבד?

הרבה. זה אינו טיעון לעשות פחות מזה — זה טיעון לכוון את זה למקום מועיל.

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

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

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

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

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

האפשרות שרוב האנשים מפספסים

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

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

איפה Capitán נכנסת

‏Capitán בנויה כאפשרות השלישית הזו. סוגי רשומה חדשים מוגדרים, לא מפותחים — והם מקבלים טבלאות בסיס נתונים אמיתיות, אילוצים אמיתיים ותיחום חברה אמיתי, ולא שק של שדות מותאמים שהוברג למשהו אחר. כללים ואישורים מוגדרים. הנהלת החשבונות והדיווח הסטטוטורי כבר בנויים וכבר מתוחזקים, וזה בדיוק החלק שלעולם אסור לכם לייצר מפרומפט.

ו-Capitán כוללת שרת Model Context Protocol, כך שעוזר ה-AI שלכם יכול לעבוד בתוכה ישירות — לשאול נתונים, להריץ דוחות, ליצור רשומות. הוא מתחבר כמשתמש בשם ועובר את אותן ולידציות, טריגרים ותיחום חברה כמו העובדים שלכם. העוזר עובד דרך הכללים ולא סביבם, וזה ההבדל בין עמית מועיל לבין סקריפט לא מבוקר עם גישה לבסיס הנתונים.

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

הגרסה הקצרה

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