איך בוחרים את הקו־פאונדר הנכון?

מאת: עינת דרוטין, סמנכ"לית משאבי אנוש ב-Grove Ventures.

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

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

מוזמנים גם לבדוק מי השותף הנכון לכם ב- quiz קצר של 7 שאלות.

מהן התכונות שמאפיינות יזמים ויזמות מצליחים?

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

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

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

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

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

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

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

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

אז איך בוחרים את הקו-פאונדר הנכון?

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

1. ערכים וחזון משותפים

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

2. כישורים משלימים

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

3. כימיה בינאישית

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

4. חוסן ומחויבות

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

5. הרצה משותפת - חובה

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

סימני אזהרה שלא כדאי להתעלם מהם:

• הוא תמיד "צריך לחשוב על זה", אבל אף פעם לא מחזיר תשובה.

• מדבר הרבה, עושה מעט.

• נרתע מעבודה קשה.

• מחפש את ההייפ - לא את הפתרון.

• ויש גם את זה: תחושת בטן לא טובה. תקשיבו לה, האינטואיציה שלכם חשובה.

הטעויות הנפוצות בבחירת קו-פאונד

• שותפות מתוך חברות – חשבתם על רעיון בגיל 12? תראו האם הרעיון רלוונטי היום והאם אתם מתאימים עסקית.

• מישהו שהמליצו עליו, מבלי לבדוק לעומק את ההתאמה

• פשרה - "עבר יותר מדי זמן, כבר חייבים להתחיל". לא. תמשיכו לחפש.

לסיכום: איך יודעים שמצאתם את האחד.ת שלכם?

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

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

הנה quiz קצר של 7 שאלות שיעזור לכם לבחור את השותף הנכון לכם.

איך מפתחים סוכני־על שיבצעו משימות שמודלים שפתיים לבדם לא מסוגלים להן

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

ממודלים שפתיים לפעולה יזומה

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

מה הופך מערכת לסוכן חכם?

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

הסוד הגדול: מודלים מבוססי דאטה תחומי

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

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

דוגמה מעולם הביולוגיה: סוכן שמבין את מערכת החיסון

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

לאן זה הולך?

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

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

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

לכן גם השוק מגיב מהר יותר: 

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

אבל בדיוק בגלל זה - הרבה יותר קשה לבלוט.

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

גם מבנה הסטארטאפ משתנה.

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

וכך גם תהליך ההשקעה משתנה.

שאלות כמו כמה זמן יקח לבנות MVP או מה הטכנולוגיה מאחורי המוצר הפכו (קצת) פחות רלוונטיות. במציאות שבה כל עדכון של GPT מוחק קטגוריה שלמה של סטארטאפים, משקיעים מחפשים אותות אחרים: אסטרטגיית דאטה ייחודית (מה מייחד את המידע, ואיך הוא משתבח עם הזמן), אינטגרציה עמוקה ב-workflow קיים, גישה להפצה מובנית (כזו שלא צריך לבנות מאפס אלא רוכבת על הרגלי שימוש קיימים), ומשמעת מרג׳ינים שמתמודדת עם עלויות GPU ו-Inference.

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

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

תקציר מנהלים

1. גם חלון הקשר גדול של המודל הכי מתקדם אינו פתרון קסם. ככל שהקלט מתקרב לאורך המקסימלי, מודלים מאבדים רלוונטיות והדיוק יורד.
2. לכן ניהול זיכרון פעיל הוא חיוני. סיכום מתגלגל, RAG והפרדת עובדות דינמיות מול ידע סטטי מפחיתים עומס ומשמרים הקשר.
3. שילוב כלים חיצוניים (דאטה בייס וקטורי, מטא־דאטה, פונקציות חיפוש) מאפשר איכות עקבית בלי לשלם על חלון זיכרון ענק בכל קריאה.

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

*המאמר כתוב בלשון זכר אך מתייחס לכל המינים.

הקדמה

אל תקראו את המאמר הזה בעצמכם.

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

במילים אחרות- האם הסוכן מודע להקשר הספציפי שלכם?

רקע

נכון ל-11 ביולי 2025, מטלת סיכום מאמר של כמה אלפי מילים (כמו זה שאתם קוראים כעת) היא משימה קלה מאוד עבור מרבית הסוכנים הזמינים לציבור הרחב, אפילו החינמיים שביניהם. הקושי מתעורר בשני מקרים:

(1) כאשר הקלט שמזינים להם (או הפלט המבוקש מהם) הוא ארוך, אפילו אם הוא קצר יותר מגודל חלון ההקשר המוצהר של המודלים. 1 2 3

(2) כאשר נדרש הקשר מחוץ לשיחה הנוכחית (במיוחד אם הוא ארוך מאוד) ועכשיו לכו תמצאו אותו.

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

[caption id="attachment_9004111233699342" align="aligncenter" width="1156"] גודל חלונות ההקשר של מודלים מרכזיים בשנים האחרונות. מתוך מאמר של ד"ר ספנסר טורין, מייבל[/caption]

פי n יותר מילים, פי n2 יותר לאט

למה בכלל יש הגבלה על גודל חלון ההקשר?

כתבתם משפט ושלחתם ל-ChatGPT (או לכל מודל אחר*). מה הוא עושה בזמן שאתם מחכים לתשובה? המודל עסוק בעיקר במשימה אחת- להסתכל על כל מילה שהזנתם ולבדוק האם (וכיצד) היא מתייחסת לכל מילה אחרת בשיחה עד כה, כולל בתוך ההודעה עצמה. אם בשיחה נאמרו עד עכשיו n מילים, אז הוא צריך לבדוק איך כל מילה מתייחסת לכל המילים האחרות בקלט (n-1 מילים). בכמה פעולות מדובר? סה"כ n × (n-1) = n2-n פעולות. לכן, כל מילה שתכניסו לקלט לא תאריך את זמן העיבוד באופן לינארי אלא ריבועי (ואתם כבר חשבתם שהשארתם את הקורס "אלגוריתמים ומבני נתונים" מאחוריכם).

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

בואו נחזור לבעיה השנייה, שאותה כן יש לנו איך לפתור (גם אם חלקית).

הבעיה: לארוז את ההקשר הארגוני

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

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

[caption id="attachment_9004111233699345" align="aligncenter" width="675"] חשיבות הידע על תרבות ארגונית בסוכני שיחה אוטונומיים, אילוסטרציה[/caption]

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

ניהול זיכרון אקטיבי

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

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

סיכום שיחה מתגלגל

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

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

Retrieval Augmented Generation (RAG)

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

1. מיון (פעם אחת, מראש): לוקחים את כל מאגר הידע שלנו, מפרקים אותו לחתיכות הגיוניות (לפי פסקה, לפי תוכן בנושא מסוים, לפי עמוד, קובץ, וכו'), ומעבירים כל חתיכה דרך מודל שמתרגם אותה לייצוג מספרי ייחודי (וקטור). אפשר לחשוב על הווקטור הזה כעל קואורדינטה במפה רב-ממדית. את כל הווקטורים האלה אנחנו שומרים בבסיס נתונים מיוחד, שנקרא בסיס נתונים וקטורי (ישנם פתרונות חינמיים מצוינים כגון ChromaDB ו-FAISS או אופציות בתשלום כמו Pinecone). נושאים דומים זה לזה מקבלים מספר זהות דומה (כלומר, הווקטורים שלהם קרובים זה לזה במרחב).
2. שליפה (בזמן אמת): כאשר משתמשת כמו תמי שואלת שאלה, אנחנו לא שולחים אותה ישירות למודל. קודם כל, אנחנו מתרגמים את השאלה עצמה לאותו ייצוג וקטורי. אז, אנחנו פונים לבסיס הנתונים הווקטורי ושואלים אותו: "אילו חתיכות מידע מהמאגר שלי הכי קרובות ודומות במשמעות לשאלה הזו?". שליפה מבסיס נתונים וקטורי היא מהירה מאוד. נקבל בחזרה, נגיד, את שלושת הסקריפטים הכי רלוונטיים לשאלה.

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

טבלה 1: כיצד ניתן לספק הקשר למודל? שלוש אפשרויות

הנדסת שאילתות (Prompt Engineering)

על כל מעלותיהם, טיב ביצועיהם של מודלי שפה גדולים מוגבל בהתאם לטיב השאילתות שאנחנו מזינים להם (garbage in- garbage out). זה תקף לכל הדברים שהמודל פולט- אלה הנכונים (למשל, מידת הרלוונטיות למה שאנחנו רוצים לקבל) ואלה הלא נכונים (ההזיות).

בעוד שישנם קווים מנחים כלליים המקובלים בתעשייה לגבי אופן ניסוח השאילתות שאנחנו מגישים למודל (ראו את אלה של Google, OpenAI)- ב-2025 אנחנו עדיין במערב הפרוע וכל משתמש הישר בעיניו יעשה בכל הנוגע לתקשורת עם הצ'אטבוט. לכן ראוי ומועיל שנעבור כאן על שני עקרונות אקטואליים בהנדסת שאילתות: הגדרת גבולות גזרה, והכתבה של סכמת הפלט.

גבולות גזרה

טכניקות אימון והנדסת פרומפטים חדשות של LLM מנסות לעודד את המודל להימנע מהזיות (בשפת העם- לא "לחרטט בביטחון" אלא להודות בחוסר ידע). ואכן, מאז ש-ChatGPT 3.5 פרץ לחיינו בשלהי שנת 2022, אפשר לומר שעברנו כברת דרך בכל הנוגע להפחתת הזיות של מודלים. עדיין, למרות שלפי מדדים מסוימים ישנה הפחתה ניכרת בתדירות הופעת ההזיות בפלט של מודלי שפה, עדיין לא יצאנו לחלוטין מטווח הסכנה. למשל, אפילו מודל הדגל של גוגל נכון להיום, Gemini-2.5.-Pro, עשוי לבלבל תמונה של ברקוני עם דמותו של שרגא בישגדא. אל תשאלו איך אני יודע.

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

דוגמה 1: מציאת סקריפטים לפי תיאור פונקציונלי

System Prompt:

You are "Purple Knight Assistant", an expert technical assistant for the Semperis script repository. Your rules are:

1. You MUST base your answers **exclusively** on the list of scripts provided under "Context".
2. You are FORBIDDEN from using external knowledge or making assumptions about scripts not present in the list.
3. If the answer is not found within the provided scripts, you MUST reply: "The information is not available in the scripts provided to me."

User Prompt:

# Context - Retrieved Scripts:

## Script 1

- Name: Get-RiskySPNs.ps1.

- Description: Locates Service Principal Names with weak configurations that could allow Kerberoasting attacks.

## Script 2

- Name: Get-UnconstrainedDelegation.ps1.

- Description: Finds accounts with Unconstrained Delegation permission, which is a serious security risk.

# User said: Do you have a script that finds old, unused service accounts?

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

דוגמה 2: סיווג סקריפט קיים

System Prompt:

You are a technical assistant whose job is to classify new scripts. Your answer must be one of the following three options only: 'Authentication', 'Authorization', or 'Auditing'. Do not provide any additional explanation.

User Prompt:

# Context - New Script

## New script

- Name: Check-AdminSDHolder.ps1.

- Description: Checks the Access Control List (ACL) on the AdminSDHolder object to ensure that unauthorized accounts have not been granted sensitive permissions.

# Question:

To which category does this script belong?

במציאות, ייתכן שהייתי בוחר לתת יותר הקשר כבר ב-System Prompt על מנת לוודא שהצ'אטבוט מבין את משמעות הסיווג ונותן לי את התשובה שאני מקווה לקבל, כולל דוגמאות. מתן דוגמאות בתוך השאילתה (ולא במהלך אימון המודל) נקרא Few-shot prompting. זו טכניקה חשובה שכל כותב שאילתות חייב להכיר.

שתי טכניקות הטיוב הללו הן חלק מסל הכלים שמאפשר לנו שליטה טובה יותר בפלט של המודל. בנושא הזה, אני ממליץ בחום על ההרצאה של שון גרוב ב-AIEWF 2025. גרוב מתייחס לרעיון בסיסי- האם פרומפטים הם פרדיגמת התכנות החדשה? (לפי ההרצאה הזו, התשובה היא חד משמעית- כן)

הכתבת סכמת הפלט (Structuring)

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

ספקיות LLM כמו OpenAI מאפשרות זאת באמצעות יכולת שנקראת Tool Calling או Function calling. אנחנו מגדירים להן "פונקציה" עם פרמטרים מסוימים, והמודל מחזיר JSON שתואם לחתימת הפונקציה.

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

דוגמה 1: שימוש ב-Toll calling של OpenAI

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

```bash

pip install openai pydantic

```

```python

import json

from openai import OpenAI

from pydantic import BaseModel, Field

from typing import List

# Initialize the OpenAI client

client = OpenAI()

# 1. Define the desired output schema using Pydantic, just as before.

class ScriptAnalysis(BaseModel):

    """

    Class representing the analysis of a single security script.

    """

    script_name: str = Field(..., description="The name of the script, e.g., 'Get-RiskySPNs.ps1'")

    summary: str = Field(..., description="A brief, one-sentence summary of the script's purpose.")

    is_relevant_to_kerberos: bool = Field(..., description="True if the script deals with Kerberos-related vulnerabilities.")

    attack_tags: List[str] = Field(..., description="A list of relevant attack techniques, e.g., ['Kerberoasting', 'Delegation']")

# 2. Define the tool for the OpenAI API call, using the schema from our Pydantic model.

# Pydantic's .model_json_schema() method generates the exact dictionary format OpenAI needs.

tools = [

    {

        "type": "function",

        "function": {

            "name": "analyze_script",

            "description": "Analyzes a security script and extracts its key details.",

            "parameters": ScriptAnalysis.model_json_schema()

        }

    }

]

# 3. Send the request to the model, providing the tool and forcing the model to use it.

script_text = "Description: Locates Service Principal Names (SPNs) with weak configurations that could allow Kerberoasting attacks. Name: Get-RiskySPNs.ps1"

response = client.chat.completions.create(

    model="gpt-4-turbo",

    messages=[{"role": "user", "content": f"Please analyze the following script description: {script_text}"}],

    tools=tools,

    tool_choice={"type": "function", "function": {"name": "analyze_script"}} # Force the model to use our tool

)

# 4. Extract the JSON string from the model's response.

# The arguments for our function call are located in the response message.

message = response.choices[0].message

tool_call = message.tool_calls[0]

arguments_str = tool_call.function.arguments

# 5. Parse the JSON string and validate it with our Pydantic model.

# This gives us a clean, validated Python object.

data = json.loads(arguments_str)

analysis = ScriptAnalysis(**data)

print(analysis.model_dump_json(indent=2))

```

דוגמה 2: חילוץ ג'ייסון מתוך הודעת משתמש

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

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

import json

import re

from openai import OpenAI

from pydantic import BaseModel, Field

from typing import List, Dict, Any, Type

# Initialize the OpenAI client

client = OpenAI()

def generate_pydantic_model_code(user_prompt: str) -> str:

    """

    Step 1: The Schema Extractor.

    This function asks an LLM to write Pydantic model code based on the user's prompt.

    """

    print("--- Step 1: Generating Pydantic model from prompt... ---")

    system_prompt = """

    You are an expert Python programmer. Your task is to analyze a user's prompt.

    If the user describes a desired output format (like a JSON structure or a list of objects),

    you must generate a complete Python script containing Pydantic models to represent that structure.

    - The main model should be named `DynamicResponseModel`.

    - The model should represent the entire desired output (e.g., if the user asks for a list, the model should contain a `List[...]` field).

    - Only return raw Python code. Do not add any explanations or markdown formatting.

    - If no specific structure is mentioned in the prompt, return an empty string.

    """

    response = client.chat.completions.create(

        model="gpt-4-turbo",

        messages=[

            {"role": "system", "content": system_prompt},

            {"role": "user", "content": user_prompt}

        ]

    )

    model_code = response.choices[0].message.content

    print("--- Generated Pydantic Code ---\n" + model_code)

    return model_code

def get_structured_data(user_prompt: str, response_model: Type[BaseModel]) -> BaseModel:

    """

    Step 2: The Data Fetcher.

    This function uses the dynamically generated Pydantic model as a tool to get the final answer.

    """

    print("\n--- Step 2: Fetching data with the dynamic model... ---")

    tools = [{

        "type": "function",

        "function": {

            "name": "format_user_data",

            "description": "Formats the data according to the user's specified structure.",

            "parameters": response_model.model_json_schema()

        }

    }]

    # 3. Second LLM call: Use the new, dynamic class as a tool to fetch the structured data.

    response = client.chat.completions.create(

        model="gpt-4-turbo",

        messages=[{"role": "user", "content": user_prompt}],

        tools=tools,

        tool_choice={"type": "function", "function": {"name": "format_user_data"}}

    )

    # Extract the JSON string from the tool call

    arguments_str = response.choices[0].message.tool_calls[0].function.arguments

    data = json.loads(arguments_str)

    # 4. Validate the received JSON data against our dynamic Pydantic model.

    return response_model(**data)

if __name__ == "__main__":

    # The user's prompt, which includes a natural language description of the desired structure.

    user_prompt = """

    List all 50 states in the USA, and info about them.

    Use this format for each state: {"state": <state name as string>, "capital": <capital name of that state as string>, "population": <the state's population as an integer>}.

    Return a list of all 50 states in this format.

    """

    # 1. First LLM call: Ask the model to generate Pydantic code as a string.

    model_code_string = generate_pydantic_model_code(user_prompt)

    if model_code_string:

        # 2. The magic step: Execute the generated code string to create the class in memory. DON’T USE THIS IN PRODUCTION. Further security and sanitation is required, as this is just an example.

        local_scope = {}

        This text will prevent the code from compiling, to avoid running it as copied without implementing the proper guardrails. Only remove this text if you know what you’re doing. Thank you -Omri Nardi Niri, July 2025.

        exec(model_code_string, globals(), local_scope)

        DynamicModel = local_scope.get('DynamicResponseModel')

        if DynamicModel:

            structured_response = get_structured_data(user_prompt, DynamicModel)

            print("\n--- Final Structured Output ---")

            print(structured_response.model_dump_json(indent=2))

        else:

            print("Error: Could not find 'DynamicResponseModel' in the generated code.")

    else:

        print("No specific data structure was found in the prompt.")

עונת הקציר

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

תמונה 3: "היי GPT, צור תמונה שאוכל לצרף למאמר שמכיל את הפיסקה הבאה: עונת הקציר- האמור עד כה..."

הבעיה היא שהידע האמיתי לא נמצא בוויקי. מסמכים רשמיים מתיישנים. ההחלטה האחרונה לגבי הפיצ'ר הבא התקבלה עכשיו בשיחה בערוץ #product-team בסלאק, לא בדף Confluence מלפני חצי שנה. זה לא אומר שצריך להתייחס אליה כאמת הבסיסית, אבל צריך להיות לה מקום והיא צריכה לקבל לפחות התייחסות של סוכן המתיימר להכיר את הארגון שלנו טוב מכל אחד אחר.

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

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

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

[caption id="attachment_9004111233699349" align="aligncenter" width="488"] "היי GPT, צור תמונה שאוכל לצרף למאמר שמכיל את הפיסקה הבאה: עונת הקציר- האמור עד כה..."[/caption]

לסיכום

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

1. הכתבת ההקשר בעצמנו.
2. הנדסת שאילתות.
3. תהליכים אוטומטיים לאיסוף מידע ממקורות שונים בארגון.

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

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

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

(*) האמור מתייחס לרוב המודלים הזמינים היום, שמשתמשים בטכנולוגיית Transformers. כדי להבין את המתמטיקה שמאחורי ההמצאה המופלאה הזו, אני ממליץ לצפות בהסבר הנהדר של 3Blue1Brown: Transformers, the tech behind LLMs | Deep Learning Chapter 5

עד לא מזמן, להגיע ל-ARR של כמה מיליוני דולרים היה נחשב לאבן דרך משמעותית עבור חברות B2B. זה היה לרוב סימן לכך שהחברה מצאה PMF (Product Market Fit), הוכיחה שיש ביקוש והצליחה לבנות תשתית אופרציה ראשונית.
כל אלה עדיין נכונים, אבל מהפכת ה-AI משנה את כללי המשחק. כדי להישאר רלוונטיים, אנחנו צריכים לבחון מחדש את הסימנים להצלחה ואת הדרך שבה אנחנו מפרשים את המטריקות המצביעות על צמיחה.

[caption id="attachment_9004111233699180" align="aligncenter" width="768"] Source: a16z[/caption]

סטארטאפים צומחים בקצב מהיר ביותר 

חברות Enterprise בתחום ה- Gen AI, צומחות בקצב מסחרר. הסטארטאפים שנמצאים ברבעון העליון מגיעים ל-ARR של מיליון דולר בתוך 3 עד 6 חודשים מיום ההשקה (ראו גרף), ורבים מהם מגיעים ל-ARR של 3-5 מיליון דולר כעבור שנה.
מה שבעבר נחשב לפריצת דרך משמעותית, הפך היום למחזה הרבה יותר נפוץ. זו הסיבה שהיום כבר אי אפשר להתייחס ל-ARR גבוה ומוקדם כאינדיקציה בלעדית ל-PMF או ליציבות לטווח הארוך.

איכות ההכנסות - האם ה-ARR שלכם באמת שנתי ומחזורי? 

אם נסתכל אפילו חמש שנים אחורה, סטארטאפ שהשיג ARR של 3 מיליון דולר, לרוב ייצר גם הכנסות יציבות. החוזים היו בדרך כלל שנתיים, שיעור שימור הלקוחות היה גבוה, ההתרחבות התנהלה לפי דפוס ברור, והיה אפשר לחזות בצורה סבירה מדדים כמו Net Dollar Retention) NDR) ו-Lifetime Value) LTV).
היום, סטארטאפים רבים מגיעים מהר מאוד ל-ARR של כמה מיליוני דולרים, אבל כשבוחנים את הנתונים לעומק, מגלים שלעתים קרובות זה מבוסס על תקופות ניסיון, תשלומים חודשיים, תנאים גמישים, אפשרות ביטול מנוי מהירה ואינטגרציה מינימלית - מה שמוביל לעלויות מעבר נמוכות במיוחד בשביל הלקוחות.
בתנאים כאלה, קשה מאוד להעריך באמת את איכות ה-ARR שהחברה מציגה בפועל.

שינוי במודלי התמחור

מודלי התמחור עברו שינוי ממודלים מבוססי משתמשים בלבד (Seat-Based) למודלים היברידיים שמשלבים בין מספר המשתמשים לבין השימוש במוצר בפועל.
לדוגמה:
– קרדיטים (כמו ב-monday.com)
– משימות או תהליכי עבודה (כמו ב-Zapier)
– כמות בקשות שטופלו (כמו תוספי ה-AI של Zendesk)
– טוקנים, קריאות API או תוצאות בפלטפורמות מבוססות AI (כמו OpenAI)

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

מלך ומלכת הכיתה: יתרון תחרותי (Moat) ואסטרטגיית GTM

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

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

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

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

אם החברה שלכם נמצאת בשלבי צמיחה, אלו הדברים שכדאי לכם להתמקד בהם: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

״יש סוג חדש של פיתוח קוד, שאני קורא לו ״וייב קודינג״, אתה נכנס לתוך הגל של הקוד, ונותן לו לסחוף אותך, תוך שאתה נטמע בתוך הקומפוננטות של הקוד, ושוכח שהקוד בכלל קיים. אני בונה פרויקטים, אבל אני לא באמת מקודד, אני רואה דברים, מדבר עם הקוד, מריץ דברים, ועושה קופי-פייסט, וזה עובד״ (אנדריי קרפטי, לשעבר בכיר ב-OpenAI, פברואר 2025). 

כך נולד לו הטרנד, בפברואר 2025, בפוסט שמתאר את הפליאה של קרפטי, לשעבר חבר צוות מייסד בחברה שהביאה לעולם את ChatGPT. גם קרפטי, לא שיער, שהמונח שטבע, יהפוך למטבע לשון בעולמות הבינה המלאכותית היוצרת, מונח שיופיע באינספור מצגות, יכוסה מכל זווית אפשרית בכל פודקאסט שמכבד את עצמו, ויהפוך לקטגורית מוצרים, שאפשר למנות בתוכה את Claude , Cursor, Replit, Windsurf, Loveable, וכמובן, איך לא, המוצר כחול-לבן Base44, שנמכרה אך לאחרונה ל-Wix. 

אבל מאחר ואנחנו עוסקים בשיווק, הההתפחות הישירה והטבעית של ה-"Vibe Coding״ של קרפטי, גלשה ישירות לסביבת העבודה החדשה של אנשי השיווק, בסביבה היברידית שכוללת גם ניהול אנושי, אבל מכילה גם סביבת סוכני בינה מלאכותית. 

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

מי שעשה את ההקבלה המרתקת בין הוייב קודינג וטבע את המונח ״Vibe Marketing״ הוא גרג אייזנברג, מאנשי השיווק הבולטים בשיח סביב החיבור בין הוייב קוד לעולמות השיווק, ופרסם פוסט אינטרפטציה משלו לעולמות המרקטינג שמשווה בין עולם השיווק החדש לישן: ״העולם הישן - צוותי מחלקת שיווק עם 10 ויותר מומחים - הכוללים קופירייטרים, מעצבים, מומחי אנליזה, מומחי מדיה, עובדים בתאים נפרדים, נשאבים לתוך פגישות, ומבזבזים אלפי דולרים? העולם החדש - איש שיווק אחד - One Man Show, שמנהל צוות של סוכנים - שעושים בו-זמנים אלפי משימות, תוך ימים, ולא שבועות״,

גרג אייזנברג מגדיר את Vibe Marketing כהתפתחות ישירה של “vibe coding, תוך שימוש ב‑AI agents וכוחם של כלי אוטומציה כדי לבצע באופן עצמאי את מרבית פעילות השיווק. לטענתו, בעוד איש השיווק, מתווה את הדרך לסוכנים, הם אלה שמבצעים את המשימות, והמנהל מחבר את הסוכנים לגבולות הגזרה של המותג, והיעדים השיווקיים - קובע אווירה, קווים מנחים והטון הכללי.

לדבריו, היתרונות המרכזיים של וייב מרקטינג - ״העולם החדש של השיווק״:

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

בדוגמאות לכלים שמאפשרים ״Vibe Marketing״, מונה אייזנברג, את הסוכנים הבאים - Manus הסיני, המאפשר בניית סוכנים לכל מטרה, n8n - כלי האוטומציות, שזוכה לפופולריות רבה - ואפילו לקהילה ישראלית של משתמשים הדוקים, Make הוותיקה, Taskade ועוד. 

מאחר ואנחנו גאים בתעשייה המקומית, אנחנו בחרנו להתמקד בכלים ומוצרים כחול-לבן, שנמצאים תחת הקטגוריה של Vibe Marketing ובהם - Marketeam.ai, Toffu.ai, sushilab.ai, הנמצאים תחת מטריית המונח ״וייב מרקטינג״ ומאפשרים לכם למקסם את עבודת השיווק, בסביבה היברידית, בה אתם, מנהלי השיווק, מנהלים צבא של סוכנים, שמבצעים מאות, אם לא אלפי משימות במקביל, בגל של הוייב מרקטינג.

מה הדמיון בין טופו לסושי? וייב מרקטינג

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

הפלטפורמה מאפשרת מודל מנויים, עם מודל חינמי עם 100 קרדיטים יומיים, ורמות מנויים מודולריות לעסקים, סוכנויות ואנטרפרייז. כששאלנו את אור ארבל מהו עבורו "Vibe Marketing״ - הוא סיפר לנו את הסיפור ההקמה שעמד מאחורי המיזם - אור התערב עם אשתו תום, סמנכ״לית שיווק בחברת הייטק, שיצליח עם כלי וייב קוד, לייצר לה אוטומציות חכמות שיחסכו לה את מרבית המשימות בשיווק. ״אם יש Cursor למפתחים, למה שלא יהיה לאנשי שיווק? וזו בדיוק הסיבה למה הקמנו את Toffu.ai״.

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

 Marketeam.ai הוקמה ב-2021 והיא מביאה גישה של Integrated Marketing Environment IME - עם צוות מודולרי של סוכנים אוטונמים - הפועלים כחלק אינטגרלי מהמותג ומבצעים יחידות עבודה שלמות - החל ממחקר ואיסוף דאטה, דרך גיבוש אסטרטגיה, יצירת תוכן והפצתו. למי זה מתאים? למותגים ועסקים קטנים ובינוניים שרוצים להפעיל שיווק חכם, מקיף ומבוסס דאטה - בלי להגדיל צוות ובלי להיכנס לתלות בסוכנויות חיצוניות.

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

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

דוגמא שלישית ואחרונה של מוצר חדש שעתיד לצאת ממש בקרוב לשוק הוא Sushilab.ai של היזם הסדרתי טל פלורנטין - פלטפורמה שיווקית עם מטרה לשפר את מערכת היחסים והתקשורת בין המותג לצרכן, דרך בניית סוכנים מבוססי בינה מלאכותית, תוך שימוש במעטפת רחבה של מודלי שפה Text To speech, Text to Image, Text to Video ועוד. 

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

**גילוי נאות: אמיר שניידר הצטרף לאחרונה כיועץ שיווק לחברת Toffu.ai.

ה-AI הופך את היכולת של עובדים למלא מגוון רחב של תפקידים לקלה מאי פעם

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

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

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

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

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

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

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

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

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

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

מדריך הכלים והאסטרטגיה לבניית מכונת למידה יעילה

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

class YaddaDemo

זה לא היה כי שכחנו לשנות- פשוט זה אף פעם לא היה מספיק חשוב. השם הראשוני Yadda (מי אמר סיינפלד ולא קיבל, אבל הדומיין לא היה פנוי) נשאר שם, וגם ה־“Demo” נשאר שם גם, כי זה כל מה שהקוד הזה היה אמור להיות כשהוא נכתב- דמו.  עבורנו, זאת גם היתה תזכורת חשובה, מה חשוב, ומה פחות חשוב. כי מה שחשוב הוא כלי שנמצא בחוץ, שאנשים משתמשים בו, ואתם לומדים ממנו על מה חשוב להם. ה־(MVP  (Minimum Viable Product שלנו פעל מהרגע הראשון, צבר משתמשים, ,תובנות ותוכן, עד שהפך ל AOL Answers.

למה MVP היום הוא לא מה שהיה פעם?

השוק של היום שונה מהותית מאותה תקופה פרהיסטורית. רק בישראל, לפי נתוני IVC, קמו כ-1,200 סטארט-אפים חדשים ב-2024, ולא בכדי, כ-47% מההשקעות שהגיעו אליהם הופנו ישירות לתחום ה-AI. אם אתם יזמים בתחום, אתם לא מתחרים בוואקום.

אין יותר מקום ל"פחות מדי":

• המשתמשים היום מצפים לחוויית משתמש (UX) ברמה אליה הורגלו ע״י Apple ו-Netflix. הם לא יסלחו על פחות.
• התחרות קיצונית – אם חווית השימוש הראשונית לא תייצר "וואו" מיידי, הם פשוט יעברו למתחרה הבא.
• סטארט‑אפ בלי הבנה מהירה של מה עובד/ לא עובד ולמה – יתקשה לשרוד את החודשים הראשונים.

היום, MVP צריך להיות אחד מאלה:

• MLP – Minimum Lovable Product – קטן בהיקף, אבל עצום בחוויה ובאהבה שהוא מייצר. כפי שאמרו ב-Y Combinator: "עדיף שיהיו לך 100 לקוחות שמאוהבים במוצר שלך מאשר 100,000 שחושבים שהוא 'בסדר'."
• MVE – Minimum Viable Experience – התמקדות בחוויה שלמה, מהשנייה שהמשתמש שומע עליכם ועד לקבלת הערך.
• RAT – Riskiest Assumption Test – מבחן מהיר וממוקד לבדיקת ההנחה הכי מסוכנת שלכם, לפני שכותבים שורת קוד אחת.

מה צריכה להכיל מכונת למידה של MVP?

טכנולוגיית LLM (כמו ChatGPT): הכוונה היא לא רק ליצירת טקסט שיווקי או תשובות למיילים של משקיעים (או עזרה בלהבין מה הם רוצים). מדובר בשימוש מוחשי ב-AI בתוך המוצר – תהליכים כמו תמיכת משתמשים, סינון מידע, ניתוח ומתן מענה אוטומטי שמשתלבים בממשק, בבסיס הנתונים ובאוטומציות שלכם.

ארגז כלים אפקטיבי ל־MVP מודרני

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

1. Frontend – No‑Code: הכלים לבניית הממשק וחווית המשתמש (לדוגמה: Bubble, Webflow, FlutterFlow).
2. AI Co-Founder: השותף (הדיגיטלי) שלכם, שמייצר תוכן, תובנות וקוד (לדוגמה: ChatGPT, Claude, Gemini).
3. Workflows: הדבק שמחבר בין כל השירותים באופן אוטומטי (לדוגמה: Zapier, Make, n8n ).

סיפור הצלחה לדוגמה: Formula Bot של David Bressler נבנה בסוף שבוע אחד עם Bubble ו-API של OpenAI, הפך ויראלי והגיע להכנסה שנתית של $500k. העלות הראשונית? $35 לחודש. זה הכוח של הכלים האלה.

הדור הבא: פלטפורמות All-in-One מבוססות AI

הטרנד המתקדם ביותר הוא פלטפורמות שמאחדות את כל הכלים הללו למקום אחד. חברת Base44 היא דוגמה מובילה למגמה הזו. הרעיון הוא פשוט מהפכני: אתם מתארים את האפליקציה שלכם בשפה טבעית, וה-AI בונה עבורכם את התשתית כולה – Frontend, Backend, בסיס נתונים, ואימות משתמשים. זו גישה שמקצרת את הדרך מרעיון ל-MVP פועל בתוך מספר שעות.

מקרה מאסטר‑קלאס: Feed‑Forward ב־48 שעות

דוגמא לפלטפורמה שמסייעת למנהלים לנסח משוב בונה לעובדיהם:

1. Webflow - בניית דף נחיתה פשוט שמסביר את הערך.
2. Typeform - הטמעת טופס עם 3 שאלות קלות: למי מיועד המשוב? מהי נקודת חוזק מרכזית? מהי נקודה אחת לשיפור?
3. Make Automation:
   • עם קבלת הטופס ← שליחת פרומפט ל‑GPT-4:
     "You are an experienced and empathetic manager. Write constructive, positive, and inspiring feedback based on these points..."
   • עם קבלת התשובה מ-GPT ← שמירה ב‑Airtable ושליחת התוצאה למשתמש בדוא״ל.
4. Day 1: המוצר באוויר, הקמפיין הראשון נשלח ל-10 מנהלים רלוונטיים.
5. Day 2 (בוקר): ניתוח שימוש ראשוני – כמה השתמשו? כמה המשיכו את התהליך?
6. Day 2 (צהריים): שיחות עומק עם 3 מנהלים שהתנסו כדי להבין את החוויה.
7. Day 2 (ערב): החלטה מבוססת דאטה – האם ממשיכים בכיוון הזה או מבצעים Pivot?

בתוך 48 שעות יש לכם MVP עובד, פידבק אמיתי, ולמידה משמעותית. פלטפורמות מהדור החדש כמו Base44 שואפות לקצר את התהליך הזה עוד יותר, על ידי איחוד שלבים רבים לפלטפורמה אחת.

אימפלמנטציה: מתי לעבור לקוד?

זו שאלת מיליון הדולר, והתשובה צריכה להיות מבוססת דאטה.

טריגרים אפשריים למעבר:

• משתמשים פעילים חודשיים (MAU) > 1,000
• זמן תגובה (Latency) קבוע > 1 שנייה
• עלות שימוש ב-API (Token cost) > $500 לחודש

→ אם אחד מאלה קורה, זה הזמן לתכנן מעבר ל-microservices ב-Node/Python, עם תשתית ייעודית.

כך נשארים Lean כשהשוק עדיין לא הוכיח את עצמו, ועוברים ל-Code רק כשצריך לתמוך ב-Scale אמיתי.

הצ'ק‑ליסט שלך ל־48 השעות הקרובות

1. הגדירו את ה‑RAT שלכם: מהי הנחת הבסיס הכי מסוכנת שלכם כרגע?
2. צאו לדרך ב־48 שעות – בנו את הניסוי המהיר ביותר לבדיקת ההנחה הזו.
3. השתמשו בכלי אחד מכל קטגוריה: No-Code + AI + Workflow, או נסו פלטפורמת All-in-One.
4. קבעו יעד ברור: להגיע ל-15 משתמשים ולקבל מהם פידבק משמעותי.
5. תתחילו עכשיו – אל תחכו לרגע ה"מושלם".

לסיכום

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

אז קדימה, בחרו השבוע את הנחת ה‑RAT שלכם, בנו אותה, ושתפו אותנו בתגובות – איך הלך?