כשה-Vibe כבר לא מספיק: מה למדתי על Context Engineering בשבוע של בניית מערכת עם AI

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

וברגע הזה, גם שיטת העבודה צריכה להשתנות.

בהתחלה הכול באמת נראה קל

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

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

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

את ההבדל הזה למדתי השבוע היטב.

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

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

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

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

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

גם PASS הוא לא תמיד סוף הסיפור

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

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

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

מאותו רגע התחלתי לחשוב על הבדיקה בכמה שכבות: בדיקות של הקוד, ה-API והנתונים; בדיקה של התהליך המלא במערכת החיה דרך הדפדפן - מה שבעולם התוכנה מוכר כ-End-to-End Testing או E2E; ולבסוף בדיקה ידנית מנקודת המבט של המשתמש. כל שכבה יכולה לחשוף משהו שהאחרות פספסו. שלושתן חשובות.

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

לא נתתי לאותו AI גם לבנות וגם לאשר לעצמו שהכול תקין

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

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

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

כאן נכנס לתמונה Context Engineering

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

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

אם Prompt Engineering עוסק בעיקר בניסוח ההוראה, Context Engineering שואל שאלה רחבה יותר: איזה הקשר ה-AI צריך לקבל כדי לדעת מה נכון לעשות עכשיו?

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

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

לא רק מה לעשות. גם מה לא לעשות

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

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

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

וגם לא כל מידע צריך להיכנס להקשר

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

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

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

מבחינתי נוצרו כאן כמה עקרונות פשוטים: לא להעביר מידע חסוי. לא לתת הרשאה רחבה יותר ממה שהמשימה דורשת, לא לבצע פעולה רגישה בלי אישור ברור, ולהפריד ככל האפשר בין סביבת הניסוי לבין המידע והמערכות החיות. זה גם מתחבר לעיקרון של Human-in-the-Loop - השארת נקודות שבהן אדם מאשר, עוצר או מקבל בחזרה את השליטה לפני פעולה רגישה וזה מתחבר שוב ל-Context Engineering. תכנון ההקשר אינו רק בחירה של מה להכניס כדי שה-AI יעבוד טוב יותר. הוא גם הבחירה המודעת של מה להשאיר בחוץ.

הקשר טוב הוא לא רק הקשר עשיר. הוא גם הקשר בטוח.

מאיפה אנחנו עובדים?

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

במילים פשוטות: מכאן עובדים. לא מתחילים בכל פעם מחדש.

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

איך נדע שסיימנו?

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

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

התחלנו לעבוד בחבילות

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

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

לכאורה אני כותבת עכשיו יותר. בפועל, המערכת קוראת פחות, מחפשת פחות וכותבת פחות קוד מיותר. וזה מביא אותי ל-Tokens.

גיליתי שחיסכון ב-Tokens הוא לא רק עניין של כסף

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

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

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

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

מה שלא עבד חשוב לא פחות

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

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

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

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

העבודה עם Stage למדה אותי למה צריך מקום שבו מותר לטעות

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

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

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

אם הייתי מתחילה את השבוע הזה מחדש...

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

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

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

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

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

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

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

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

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

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

אבל ההמלצה החשובה ביותר שלי היא אחרת.

לא לוותר על שיקול הדעת.

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

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

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

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

התפקיד שלי לא קטן. הוא פשוט עבר מקום

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

פחות אחריות על כתיבת כל שורת קוד, ויותר אחריות על שיקול הדעת, התכנון, ההקשר, הבדיקה והבחירה.

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

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

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