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

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

האתגר

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

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

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

למה זה כל כך מורכב? 

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

   

הכלים שבחרתי

• Lovable – פלטפורמה לבניית אפליקציות ו-UI עם AI, ללא קוד
  
  
• n8n – כלי אוטומציות גמיש וזול, קצת כמו Zapier או Make אבל מוכוון AI
  
  
• Claude – מניסיוני, במשימות פיתוח הוא קצת יותר חד מ-ChatGPT
  

   

 התהליך שלי – שלב אחר שלב 

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

    

2. פרוטוטייפ ב-Lovable
   לקחתי את כל האיפיון הטקסטואלי שבניתי ונתתי אותו ל-Lovable. הוספתי כמה שיותר קונטקסט כדי שיבין מה אנחנו הולכים לבנות יחד.
   

    

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

    

4. ללמד את Claude את n8n
   רציתי שקלוד יעזור לי ליצור את האוטומציה בn8n, כדילייעל את כל התהליך. כדי לעשות את זה יש 2 אופציות: אפשר ללכת ל-GitHub של n8n, להעתיק את הכתובת ולשים את זה ב-gitingest.com שהופך את הכול למונגש יותר ל-AI ולשלוח לקלוד.
   או לשלוח לו את הלינק של הדוקומנטציה של n8n.
   

    

5. יצירת ה-Flow בn8n
   תיארתי לקלוד מה אני רוצה שיקרה בטקסט ובעזרת ציור שציירתי ושלחתי לו כקובץ תמונה. קלוד ייצר לי את כל ה-flow, העתקתי את הקובץ שהוא סיפק לי והדבקתי אותו ב-n8n.
   התוצאה הייתה טובה באופן מפתיע, זה היה 70% מוכן.
   

    

6. שיפור הflow בn8n
   אחד היתרונות הגדולים של n8n זה שיש לו צ׳אט מובנה באוטומציה. אפשר להתייעץ בצ׳אט על התהליך שאת בונה והAI נותן תשובות רלוונטיות למה שאת מנסה לבנות. ככה הצלחתי להביא את זה למצב שהאוטומציה עובדת ואני מצליח למשוך את המידע מאחד הלקוחות שלנו.
   
   לשלוח את המידע לדשבורד שבניתי בlovable
   כדי לייצר תצוגה נוחה, השתמשתי ב webhook - דרך לגרום למערכת "להקשיב" לאירוע, וכשהוא קורה, להריץ פעולה אוטומטית (כמו "אם מישהו לוחץ על כפתור -> תשלח בקשה ל־n8n להריץ את האוטומציה").
   לא ידעתי כל כך מה לעשות משם, אז פשוט שאלתי את קלוד והוא הנחה אותי לשלוח את הכתובת webhook לlovable וזה עבד.
   הדאטה נשלח לדשבורד שבניתי ואחרי עוד כמה דיוקים הדאטה הוצג בצורה ברורה.

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

 התוצאה

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

   

מחשבות לסיום

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

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

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

פלטפורמות כמו Webflow, Bubble ו-Wix אפשרו ליזמים ולאנשי עסקים להגשים את חזונם הדיגיטלי ללא צורך בצוות מפתחים, והובילו את מהפכת ה-No Code וה-Low Code. כיום, הודות ליכולות כתיבת הקוד המתקדמות של הבינה המלאכותית הגנרטיבית, נולדים כלים חדשים שמאפשרים רמת התאמה אישית גבוהה במיוחד וקלות שימוש מפתיעה – אפילו ביצירת ממשקים ותהליכים מורכבים.

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

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

מבינה מלאכותית לבינה אוטונומית

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

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

איך זה נראה בפועל?

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

חשוב להבין שהפעלת AI ללא הקשר מלא עלולה להזיק יותר מלהועיל. לפי דו"ח של ARC, מאז כניסת כלים מבוססי GenAI, חלה עלייה של 39% ב-code churn (כלומר, קטעי קוד שנכתבים אך נדרשים להיכתב מחדש זמן קצר לאחר) כתוצאה של קוד לא עקבי או חסר הבנה מערכתית. לכן, חשוב לוודא שהסוכן מקבל את כל ההקשרים הלא-כתובים, ההעדפות והכללים הייחודיים - כדי שיוכל לכתוב קוד שמתיישר עם הדרך שבה הארגון כותב, ולא לסטות ממנה מבלי לשים לב.

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

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

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

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

פרודוקטיביות אקספוננציאלית

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

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

ההשפעה על שוק העבודה וניהול סיכונים

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

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

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

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

המודל החדש של פיתוח תוכנה

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

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

הצעד הבא

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

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

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

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

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

ביום פתיחת המלחמה שער הדולר עמד על 3.65 שקל, ואילו פחות משבועיים לאחר מכן, לאחר הפסקת האש,  הוא כבר ירד ל-3.40 שקל. המשמעות לחברות ההייטק היא אדירה - הפסד של 250 אלף שקל על כל מיליון דולר שהם החזיקו.

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

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

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

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

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

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

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

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

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

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

מה זה בעצם וייב-קודינג?

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

איך זה נראה:

• אפשר לדבר בשפה חופשית עם כלים כמו Cursor, Lovable, base44. 
• מקבלים את רוב ההצעות שהמערכת מציעה בלי לבדוק. נוצר UI או קוד וממשיכים הלאה לפרומפט הבא. 
• נותנים למערכת לטפל בעצמה בבאגים שהיא יוצרת או מעתיקים לה והיא פותרת. 
• איטרציות קצרות עם המערכת עד שמשהו עובד.

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

למה זה קורה עכשיו?

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

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

המשקל הכבד-כבד של הפרומפט הראשון

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

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

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

הדייג ודג הזהב  - יותר מדי בקשות - סופן בבקתה עלובה.

איך כותבים פרומפט ראשון הכי טוב שיש

הבנו כי הפרומפט הראשון הוא השלד של המוצר שנבנה - הוא מקרקע את ה-AI בהקשר ברור ומשפר דרמטית את איכות הפלט כבר מהשאלה הראשונה. פרומפט טוב עונה על שש שאלות ברורות:

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

דוגמא לפרומפט שיצרתי שעונה על השאלות לעיל:

You're helping me develop a blood pressure management app for adults aged 30–70 who have hypertension or want to proactively manage heart health. These users range from moderately tech-savvy to older adults who value simplicity and clarity.

The app should help them log blood pressure and medications, track trends, receive personalized insights, get reminders, and share data securely with doctors. It must feel reassuring and easy to use, with accessible visuals, offline support, and Bluetooth integration. The app must also be HIPAA-compliant and run on both iOS and Android, even on older devices.

Position this app as a reliable, empowering companion for long-term heart health. Give me ideas for the product’s name, value proposition, emotional benefit, functional benefits, and possible brand tone.

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

כלים שיכולים לעזור בprompt engineering

כלים כמו (Teleprompt (get-teleprompt.com מתחברים לדפדפן שלכם, וגם לכלים כמו ChatGPT, Lovable, base44 וכבר משורת הפרומפט אתם יכולים לעשות שיפורים לפרומפט שייצרתם – שיפורים המותאמים לאותם הכלים.

דוג' לשיפור הפרומפט:

"You are tasked with developing a blood pressure management app specifically designed for adults aged 30–70 who have hypertension or wish to proactively manage their heart health. The app must cater to a diverse user base with varying levels of tech-savviness, from moderately skilled users to older adults who prefer simplicity and clarity.

The app should include the following features:

- Log blood pressure and medication intake.

- Track health trends over time.

- Provide personalized insights

- Send reminders for medication and appointments

- Facilitate secure data sharing with healthcare providers

Design considerations are crucial:

- Ensure a user-friendly interface that feels reassuring and is easy to navigate

- Utilize accessible visuals that cater to all ages, with focus on the elderly

- Incorporate offline support for logging and tracking

- Enable Bluetooth integration for device connectivity

- Adhere to HIPAA regulations for data security

- Ensure compatibility with both iOS and Android platforms, including older devices

Deliverables

- Value Proposition: Outline the unique features and benefits that set this app apart and make it valuable to users.

- Emotional Benefits: Describe how the app supports users and empowers them to take control of their health.

- Functional Benefits: Enumerate the practical advantages users will experience by utilizing the app.

- Possible Brand Tone: Recommend a brand tone that aligns with the app's purpose and appeals to the target demographic. Add more icons for clarity. 

Output Format: Present your ideas in a structured format, using bullet points or short paragraphs for clarity."

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

התוצר החדש, קצת יותר תוסס ומתאים לקריאה של קהל היעד היותר מבוגר:

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

• תחזרו לעוגן: כל הזמן תזכירו למודל מה אתם בונים ולמה - גם באמצעות הוספת פרומפט הבסיס שוב ושוב ושוב.
• חלקו את העבודה לבלוקים: כל פיצ'ר גדול = פרומפט חדש עם פרומפט הבסיס שוב כקונטקסט.
• השתמשו בתבנית: כמו בתבנית שיצרנו Teleprompt, יש לשמור על מבנה קבוע ולהפחית בלבול של המודל. 
• תכתבו הערות פנימיות: המודל מבין שפה טבעית בתוך הקוד - נצלו את זה.
• טרגטו מקומות ספציפיים בUI: בכלי פרוטוטייפינג, אפשר ללחוץ על כפתור טרגט ספציפי ולטרגט רק בלוק ספציפי שעליו רוצים ליישם שינויים.
• דסקסו: בכלים השונים יש אפשרות לדסקס (chat) עם הכלי את השינויים שרוצים לעשות ולקבל החלטות ביחד לפני שרצים ממש לשנות את הקוד. הם גם לרוב נותנים את האופציה אחרי השיחה להכניס את התוכנית של השינויים ישירות לקוד ובצורה שהכלי עצמו אוהב.
• AI controls: בכלים השונים (עוד לא בכולם, אולי עד לפרסום שורות אלה…) אפשר לתת הוראות סטטיות, נגיד אותו פרומפט בסיס, שילקח בחשבון בכל אינטראקציה. או "להקפיא" קבצים או מסכים מסויימים משינויים שלא כל מה שעשינו עד לאותו רגע ילך פייפן. 
• אל תפחדו לעשות rollback: עשינו שינויים והמערכת השתגעה? לא לפחד לחזור אחורה.

לסיכום: לבנות עם כוונה, להאיץ עם וייב

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

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

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