בעידן שבו מפתחים פשוט יכולים לדבר בקולם עם כלים כמו 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, אלא ביכולת לתרגם חזון למבנה, ולהכניס את המודל לתוך ההקשר האסטרטגי של המוצר. פרומפט ראשון טוב הוא לא רק שאלה טכנית - הוא החלטה מוצרית; סטארטאפים שבונים עם הכלים האלה צריכים לפתח שריר חדש: לנסח כוונה מדויקת ולתכנן תרחישים מראש כדי לשמר הקשר, ולחזור כל הזמן לשאלה הפשוטה: מה אנחנו בונים, ולמה?

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