נקודת מבט של מפתח פרונטאנד על תהליך העבודה החדש בין מוצר להנדסה בעידן הבינה המלאכותית
מספר שלא אמור להיות הגיוני
12 ימים. שני אנשים: מעצבת מוצר ומהנדס פרונטאנד. בנייה מחדש של פלטפורמה שלמה.
לא אבטיפוס. לא MVP. החלפה מלאה של אפליקציה בפרודקשן, שהסתיימה ב-PR אחד שמחק 26,000 שורות קוד ישנות. כל עמוד, כל מסלול, כל אינטראקציה – נבנו מחדש מהיסוד והושקו למשתמשים אמיתיים.
בכל תהליך פיתוח מוצר מסורתי, לוח הזמנים הזה לא הגיוני. פרויקט בהיקף כזה היה לוקח בדרך כלל חודשים: שבועות של חקר עיצוב ב-Figma, סבבי סקירה עם בעלי עניין, טקס העברת מקל, תכנון ספרינט, ואז עבודה איטית של יישום מדויק. מה שקרה כאן היה שונה מהותית. לא כי עבדנו קשה יותר, אלא כי הדרך שבה עבדנו יחד השתנתה.
זו הסיפור של איך השקנו את פלטפורמת Zero ב-VM0, ומה שלמדתי על עתיד שיתוף הפעולה בין מוצר להנדסה.
צוואר הבקבוק הישן
כל מפתח פרונטאנד מכיר את הצינור המסורתי:
- המעצבת יוצרת מוקאפים ב-Figma
- סקירת עיצוב, איטרציה, אישור
- מפרטים עם מרווחים, צבעים, נקודות שבירה
- המהנדס מתרגם את המפרט הוויזואלי לקוד
- הלוך ושוב: "אפשר להזיז את זה 4px שמאלה?"
- לבסוף, חיבור לשכבת ה-API
- בדיקות אינטגרציה, עוד הלוך ושוב
הצוואר בקבוק לא היה באף שלב בודד. הוא היה במרווחים בין השלבים: ההמתנה, אובדן התרגום, המעבר בין הקשרים. המודל המנטלי של המעצבת לגבי אינטראקציה, ברגע שהוא הופך לפריים סטטי ב-Figma עם הערות, מגיע למהנדס כבר במצב ירוד. המהנדס בונה גרסה של מה שהמעצבת דמיינה, אבל זו תמיד העתקה עם אובדן מידע.
התרגלנו כל כך לחיכוך הזה, שהפסקנו לשים לב אליו. זה פשוט היה "איך שזה עובד".
הניסוי: מה אם המעצבת כותבת קוד?
ב-5 במרץ, 2026, מינג, מעצבת המוצר שלנו, פתחה PR #3685: feat(platform): add zero app with shell, pages and polish. הוא הוסיף 4,146 שורות קוד React עובדות.
לא קובץ Figma. לא ייצוא של design tokens. אפליקציה רצה.
ה-PR כלל מעטפת אפליקציה שלמה: ניווט צדדי, מבנה ראוטינג, שלדים לעמודי צ'אט, לוח זמנים, פעילות, ניהול צוות והגדרות – כולם מעוצבים עם מערכת העיצוב שלנו, כולם מוצגים בדפדפן. הנתונים היו מדומים, אבל ה-UI היה אמיתי. אפשר היה npm run dev וללחוץ דרך כל עמוד.
מינג לא כתבה את הקוד הזה מאפס במובן המסורתי. היא השתמשה בכלי קידוד מבוססי בינה מלאכותית (בהתחלה Cursor, אחר כך Claude Code) כדי לתרגם את החזון העיצובי שלה ישירות לרכיבי React. הבינה המלאכותית טיפלה בתרגום המכני (מבנה JSX, תכונות CSS, קומפוזיציית רכיבים), בעוד מינג קיבלה את ההחלטות הוויזואליות והאינטראקטיביות שאף בינה מלאכותית לא יכולה להחליף: הקצב של הפריסה, היררכיית המידע, התחושה של המעברים.
בארבעת הימים הבאים, נחתו עוד שלושה PRים:
| תאריך | PR | מה מינג העלתה |
|---|---|---|
| מרץ 5 | #3685 | מעטפת אפליקציה, סיידבר, כל שלדי העמודים (+4,146 שורות) |
| מרץ 6 | #3825 | עמודי לוח זמנים, ליטוש UI (+2,650 שורות) |
| מרץ 9 | #3993 | תהליך קליטה, דיאלוג קונפיגורציית Slack (+1,146 שורות) |
| מרץ 9 | #4050 | עמוד אודות, כרטיס ניווט צף |
עד מרץ 9, כל ממשק הפרונטאנד של הפלטפורמה החדשה שלנו היה קיים כקוד רץ. כל עמוד שעתיד היה להופיע בפרודקשן כבר היה ניתן ללחיצה בסביבת פיתוח. הוא פשוט עדיין לא עשה שום דבר אמיתי.
פה נכנסתי לתמונה.
התפקיד החדש שלי: להכניס את הנשמה
כשפתחתי את בסיס הקוד ב-9 במרץ, לא עמדתי בפני האתגר הרגיל של תרגום עיצוב שטוח לקוד. הקוד כבר היה שם. התפקיד שלי היה להחליף כל דמה במציאות, לחבר כל ממשק מעוצב יפה אל הבקאנד החי שמתחתיו.
זה שינה את העבודה שלי מהותית. במקום לחשוב על פיקסלים, חשבתי על זרימות נתונים. במקום לשאול "האם זה תואם את המוקאפ?", שאלתי "איזה קריאת API העמוד הזה צריך, ומה קורה כשזה נכשל?"
כך נראה השבוע הראשון שלי:
יום 1 (9 במרץ): אימות והחלפת ארגונים. חיברתי את המעטפת של מינג לאימות Clerk, הוספתי הפניות דומיין, והפכתי את מחליף הארגונים לפעיל. שני PRים, שניהם מוזגו באותו יום.
יום 2 (10 במרץ): מחברים ולוח זמנים. החלפתי את רשת המחברים המדומה בנתוני API אמיתיים, חיברתי את טאב הלוח זמנים ל-cron jobs אמיתיים, וחיברתי את עורך ההוראות לבקאנד. ארבעה PRים.
יום 3 (11 במרץ): יום החיבור הגדול. עמוד הצוות קיבל נתוני תת-סוכנים אמיתיים (+3,271 שורות). עמוד הפעילות קיבל לוגים אמיתיים. וגולת הכותרת: עמוד הצ'אט חובר לצינור הרצת הסוכן האמיתי, והחליף כ-1,200 שורות קוד דמו בממשק שיחה עם בינה מלאכותית. באותו יום, הוספתי את FeatureSwitchKey.Zero, דגל פיצ'ר שאפשר להריץ את הפלטפורמות הישנה והחדשה זו לצד זו.
ימים 4-5 (12-13 במרץ): קבצים מצורפים, ניהול סשנים, צ'אט רב-סוכנים, התמדה של הגדרות. כל עמוד שמינג בנתה עשה עכשיו עבודה אמיתית.
הקצב היה כמעט מוזיקלי. כל בוקר בחרתי עמוד מהשלד של מינג, למדתי את מבנה הרכיבים שלו, זיהיתי איזה נתונים הוא צריך, בניתי את האינטגרציה ל-API, טיפלתי במצבי שגיאה, ודחפתי. עד הצהריים, עוד עמוד קם לתחייה.
מתג הפיצ'ר: עולמות מקבילים
דגל הפיצ'ר FeatureSwitchKey.Zero ראוי לאזכור מיוחד, כי הוא מה שהפך את המעבר הזה לבטוח ולא פזיז.
החל מ-11 במרץ, האפליקציה בפרודקשן הריצה שתי ממשקי משתמש מלאים במקביל. משתמשים במערכת הישנה ראו את המסלולים הישנים. בודקים פנימיים במערכת החדשה ראו את Zero. כל עמוד שחיברתי היה ניתן לבדיקה בהקשר פרודקשן בלי לסכן אף משתמש.
זה לא מהפכני. דגלי פיצ'ר הם פרקטיקה סטנדרטית. אבל השילוב של דגלי פיצ'ר עם תהליך design-as-code יצר משהו מיוחד: יכולנו לאמת את כל חוויית המשתמש של הפלטפורמה החדשה (כי מינג בנתה UI שלם וניתן לגלישה), תוך כדי הפיכת כל עמוד לפונקציונלי (כי אני חיברתי אותם אחד אחד). בכל רגע, אם משהו השתבש, אפשר היה להחזיר את המתג.
שום דבר לא השתבש.
יום 12: המתג הגדול
ב-17 במרץ, פתחתי PR #5095: refactor: remove all non-zero platform pages and feature flag.
ההבדל: +456 שורות, -26,041 שורות.
לפני: פלטפורמת VM0 הישנה. טבלאות, מזהי הרצות, ונתוני סשן גולמיים.
אחרי: Zero החדשה. סביבת עבודה שיחתית עם סוכני בינה מלאכותית מוצמדים וכרטיסי מקרי שימוש.
במיזוג אחד, כל המסלולים הישנים נמחקו. דגל הפיצ'ר הוסר. Zero כבר לא הייתה אופציה – זו הייתה המצב היחיד. PR המשך (#5155) הסיר את קידומת ה-URL /zero לחלוטין: מה שהיה /zero/chat הפך פשוט ל-/chat.
למה הרגשתי בטוח לבצע את החיתוך הזה? כי:
- כל עמוד רץ תחת דגל הפיצ'ר לפחות 5 ימים
- כל אינטגרציית API נבדקה מול נתוני פרודקשן
- המערכות הישנה והחדשה חלקו את אותו בקאנד. זה היה החלפת פרונטאנד, לא מיגרציית נתונים
- היו לנו משתמשים אמיתיים במערכת החדשה שסיפקו משוב לאורך כל הדרך
26,000 השורות לא נמחקו בדאגה. הן נמחקו בהקלה.
הדפוס חוזר
מה שהפתיע אותי יותר מהמעבר עצמו היה שהשיטה שמצאנו הפכה לברירת המחדל שלנו לכל פיצ'ר חדש. מינג בונה את מעטפת ה-UI עם עזרת בינה מלאכותית, אני מחבר את הלוגיקה ומרחיב את הארכיטקטורה. אותו דפוס design-as-code, בקנה מידה של פיצ'ר:
מערכת הרשאות (מרץ 19 → אפריל 7)
מינג העלתה PR #5467, ממשק מגירת הרשאות עם רכיבי Sheet ובקרות טוגל. שלושה קומיטים, UI נקי.
אני הוספתי 13 קומיטים לאותו PR: מיגרציית מסד נתונים ל-firewall_access_requests, נקודות קצה API, בדיקות אינטגרציה, תיקוני lint. ואז בשבועיים הבאים, 10+ PRים המשיכו לבנות את שכבת ההרשאות: עיצוב מחדש לכרטיסי אישור, התראות Slack לבקשות גישה, פקודות CLI doctor לאבחון בעיות הרשאה, ולבסוף שינוי שם המושג כולו מ-"firewall" ל-"permission" בכל בסיס הקוד.
המגירה של מינג הייתה הזרע. מערכת ההרשאות הייתה העץ.
מערכת לוח זמנים (מרץ 23 → אפריל 13)
מינג עיצבה את מסלול פרטי הלוח זמנים וחוויית לוח השנה (#6155). שלושה קומיטים של עבודת UI נקייה.
אני הוספתי 14 קומיטים: עריכת תיאור עם יצירה אוטומטית, בחירת ערוץ Slack להתראות, דיאלוגי אישור לשינויים לא שמורים, איחוד תצוגת לוח שנה/רשימה, ובדיקות מקיפות. ואז 15+ PRים המשיכו להרחיב את זה למערכת משימות מחזוריות מלאה עם היסטוריית הרצות, טיפול באזורי זמן ותמיכה בביטויי cron.
אינטגרציית טלגרם (אפריל 27 → אפריל 28)
בשלב הזה, הדפוס היה כל כך מתורגל, שהשקנו אינטגרציה לפלטפורמה שלמה ב-48 שעות. מינג בנתה את ממשק ההגדרות (#11196) ותהליך הקליטה (#11399). אני בניתי את ה-API הרב-בוטי, שליחת/קבלת הודעות, העלאה/הורדת קבצים, הקשר הודעות עשיר, עדכוני real-time עם Ably, ובדיקות E2E. למחרת, זה היה זמין לכל המשתמשים.
איפה הבינה המלאכותית משתלבת
אני רוצה לדייק לגבי תפקידה של הבינה המלאכותית כאן, כי קל להפריז או להמעיט בערכה.
הבינה המלאכותית אפשרה למעצבת לכתוב קוד. מינג היא מעצבת מוצר, לא מהנדסת תוכנה. היא חושבת בפריסות, היררכיות ואינטראקציות, לא ב-hooks של React ו-generics של TypeScript. כלי הבינה המלאכותית (Cursor, ואז Claude Code) גישרו על הפער בכך שטיפלו בתרגום המכני מהכוונה העיצובית לקוד עובד. מינג ניהלה; הבינה המלאכותית הקלידה. התוצאה הייתה קוד שמעצב יצר ומהנדס יכול להמשיך לבנות עליו.
הבינה המלאכותית האיצה את לולאת הסקירה. ב-PRים משותפים, הסוכן הבינה המלאכותית שלי סקר את הקוד של מינג, סיווג בעיות לפי עדיפות (P0/P1/P2), ודחף תיקונים ישירות. PR #5060 עבר חמישה סבבי סקירה ב-38 דקות. PR #5467 השלים שלושה סבבים ב-20 דקות. זה לא "בינה מלאכותית מחליפה סקירת קוד". אני עדיין קורא כל שינוי. אבל העבודה המכאנית של זיהוי בעיות lint, טיפוסים חסרים ופערי בדיקות – הופקדה לאוטומציה.
הבינה המלאכותית לא קיבלה את החלטות העיצוב. הארכיטקטורה של כל עמוד, דפוסי האינטראקציה, ההיררכיה הוויזואלית – כל אלה הגיעו מאינסטינקט המוצר של מינג, מגובה במחקר משתמשים ומומחיות דומיין. בינה מלאכותית יכולה לייצר עמוד הגדרות, אבל היא לא תחליט מה צריך להיות טוגל ומה דרופדאון, או מתי דיאלוג אישור מוצדק לעומת חיכוך מיותר.
הבינה המלאכותית לא קיבלה את החלטות הארכיטקטורה. הבחירה להשתמש בדגל פיצ'ר לפריסה מקבילה, אסטרטגיית הפרדת שכבת ה-API, ההחלטה לחבר עמודים בהדרגה ולא בבת אחת – כל אלה היו החלטות הנדסיות. הבינה המלאכותית עזרה לי לכתוב קוד מהר יותר, אבל הסדר והניהול סיכונים היו אנושיים.
סיכום כן: הבינה המלאכותית ביטלה את שכבת התרגום בין עיצוב להנדסה. היא לא החליפה אף תחום – היא הסירה את הפער ביניהם.
מה השתנה בתפקיד שלי
אחרי שלושה חודשים בתהליך הזה, אני רואה את תפקידי כמהנדס פרונטאנד אחרת.
אני כבר לא מתרגם ויזואלי. ימי קבלת קובץ Figma ובזבוז שעות על התאמת מרווחים נגמרו. לא כי אני מהיר יותר, אלא כי זה כבר לא התפקיד שלי. הכוונה של המעצבת מגיעה כקוד, לא כתמונה של קוד.
אני מרחיב ארכיטקטורה. הערך העיקרי שלי הוא לקחת ממשק עובד ולבנות את התשתית הבלתי נראית מתחת: אינטגרציות API, ולידציית נתונים, טיפול בשגיאות, בדיקות הרשאות, עדכונים בזמן אמת, בדיקות. היחס ברוב ה-PRים המשותפים מספר את הסיפור. מינג תורמת 3 קומיטים של UI, אני תורם 13 קומיטים של כל השאר.
אני שומר סף איכות. עם לולאות סקירה מסייעות בינה מלאכותית, אני יכול לשמור על איכות קוד בשטח הרבה יותר רחב. הסקירה האוטומטית תופסת את הבעיות המכאניות; אני מתמקד בארכיטקטורה, מקרי קצה, ולוודא שהפיצ'ר באמת עובד מקצה לקצה.
אני אסטרטג משלוח. דגלי פיצ'ר, חיבור הדרגתי, פריסות מקבילות – הסדר שבו פיצ'ר עובר מקוד לפרודקשן הוא עכשיו חלק מרכזי בעבודה שלי, לא מחשבה מאוחרת.
המספרים
שלושה חודשים. שני אנשים. בינה מלאכותית לאורך כל הדרך.
- 914 PRים מוזגים (679 שלי, 235 של מינג)
- 12 ימים מהשלד הראשון להחלפת פלטפורמה מלאה
- 48 שעות לאינטגרציית טלגרם שלמה (הפיצ'ר הכי מהיר שלנו)
- 26,000 שורות נמחקו במיזוג אחד בביטחון
- 88% מה-PRים שלי ו-66% של מינג כוללים מחבר-שותף בינה מלאכותית
אלו לא מדדי חריצות. אף אחד מאיתנו לא עבד בסופי שבוע או עשה לילות לבנים. המהירות נובעת מהסרת הזמן המת: פגישות העברה, אי-הבנות במפרט, הלוך ושוב של "אפשר להזיז את זה 4px". כשהכוונה העיצובית זורמת ישירות לקוד, וההנדסה מרחיבה את הקוד במקום, פשוט יש פחות בזבוז.
מה זה אומר לצוותים
אני לא טוען שכל צוות צריך לעבוד כך. התהליך הזה נולד מההקשר שלנו: צוות קטן, הזדמנות לבנייה מחדש מאפס, וגישה מוקדמת לכלי קידוד בינה מלאכותית מתקדמים. התוצאות שלכם עשויות להשתנות.
אבל אני כן מאמין שהשינוי הבסיסי הוא אוניברסלי: הגבול בין עיצוב להנדסה מיטשטש, והבינה המלאכותית היא הממס. ככל שכלי הבינה המלאכותית משתפרים בתרגום כוונה לקוד, יותר מעצבים יכתבו קוד ישירות. כשזה יקרה, מהנדסים יבזבזו פחות זמן על תרגום ויותר על ארכיטקטורה, איכות ומשלוח.
התפקיד של מהנדס הפרונטאנד לא נעלם. הוא משנה צורה. ובכנות? הצורה החדשה מעניינת יותר.
יומה הוא מהנדס פרונטאנד ב-VM0, שם הוא בונה את הפלטפורמה שמפעילה את Zero, מערכת הפעלה לסוכני בינה מלאכותית. הוא מחק יותר קוד ישן ממה שהיה רוצה להודות.
