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

פרוטוקול 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.

שאלה אמיתית - אתם מרגישים שאתם מרגישים יותר מדי או פחות מדי ב AI? ואם פחות מדי, למה אתם לא משתמשים בו יותר? הנה רשימת המקרים בהם אני משתמש ב AI במהלך הפיתוח ו Best Practices שמצאתי לכל מקרה:

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

2. כשאני כותב קוד ויודע מה אני רוצה - אם אני בונה סכימה לדריזל ואני יודע איזה טבלה אני רוצה ואיזה עמודות זה זמן מושלם ללחוץ Command I ב VS Code ולבקש מ Copilot לכתוב את הבלוק שמוסיף את הטבלה לסכימה, וכך חוסך לי לבדוק מה השם המדויק של הפונקציה.

3. כשאני צריך לשנות פורמט של מידע או אם יש לי JSON וצריך לבנות ממנו ממשק לטייפסקריפט, או כשצריך לעטוף API בקוד שלי ולהוסיף טיפוסים.

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

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

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

7. כתיבת תיעוד, בדיקות והודעות קומיט.

8. קבלת Code Review - לפני קומיט אני מפעיל git diff ושולח את הפלט ל AI כדי לקבל סיכום מסודר של מה שעשיתי והצעות לשיפור או תיקונים.

ומה אתכם? באיזה מצבים אתם משתמשים או לא משתמשים ב AI? ואם הייתם רוצים להשתמש יותר, מה הסיבות המרכזיות בגללן אתם עדיין מקודדים בלעדיו?

נ.ב. הג'מיני החדש באמת מטורף.