הבלוג של ינון פרק

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

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

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

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

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

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

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

בפרוטוקול MCP אנחנו מגדירים יכולות לפי קטגוריות:

1. כלים - יכולות שגורמות לשינוי כלשהו בעולם

2. משאבים - יכולות שקשורות למשיכת מידע לקריאה בלבד

3. פרומפטים - יכולות שקשורות לקיצורי דרך ב UI

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

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

אל מול גלי ה AI אני מרגיש שחובה להזכיר:

1. אני אוהב לקרוא קוד ולהבין אותו.

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

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

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

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

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

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

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

כדאי לשים לב:

1. עולם ה AI הוא חדש ובכל עולם חדש יש אינסוף בעיות אבטחת מידע. זה ש Cursor שמים מצב "פרטיות" לא אומר שהקוד שלכם נשאר על המחשב שלכם (זה בסך הכל אומר שקרסר לא שומרים אצלם את הקוד שלכם).

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

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

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

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

יום 7 של Advent Of Code לא היה מסובך והזכיר לי כמה כיף שאפשר ברובי לשנות את המחלקות המובנות בשפה. בואו נראה מה היה שם.

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

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

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

אבל ה AI לא כתב. זה אתה כתבת. ובכל מקרה ה AI לא יצליח לתחזק את זה.

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

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

מה כן?

1. מתכננים בעצמנו איך דברים צריכים להיראות ולעבוד (הארכיטקט זה אתה).

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

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

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

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

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

מקור בטוויטר https://x.com/mjackson/status/1904977249918705853

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

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

2. יכול להיות שיש אתגר טכני בשילוב Server Components ב Remix. יכול להיות שיש מקור אחר להתנגדות. בכל מקרה ככל שהם יפתחו פרדיגמת עבודה שלהם אנחנו כמפתחים נצטרך ללמוד את שתי שיטות העבודה לפחות בעתיד הקרוב.

3. יכול להיות שיהיו דרכים לחבר בין Server Components ל React Router. דוגמה אחת שמצאתי היא הפוסט הזה:

https://www.buszewski.com/writings/2024-12-23-react-router-7-has-server-components/

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

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

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

https://convospanish.com/spanish-expressions-with-leche/#SerlaLeche

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

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

מה עושים?

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

Are you sure you want to change the base?

רגע, מה? לא שיניתי כלום רק בחרתי את מה שכבר היה מסומן לא? לא בדיוק. ברגע שיוצרים Pull Request גיטהאב מדביק את ה PR שלכם לקומיט מסוים, אפילו שבחרתם לשלב את ה PR לתוך ענף. כשגיטהאב מראה בממשק שאתם מנסים לשלב את ה PR לתוך base: main הוא בעצם מתכוון שאתם מנסים לשלב לתוך ענף main בקומיט מסוים (וקצת ישן). שינוי מ main ל main הוא בעצם שינוי הקומיט שביחס אליו נוצר ה PR לקומיט העדכני ביותר בענף main. בצורה כזאת רשימת הקומיטים והשינויים תתחיל בקומיט האחרון ב main ולא בקומיט המקורי ממנו נוצר ה PR.