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

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

כשסוכן ינסה לבצע אותה בעזרת תשתית ה MCP המוכרת היום הסוכן יצטרך לעשות:

1. הפעלת כלי - קח מידע מ Google Drive
2. הפעלת כלי - כתיבה ל Jira

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

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

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

// Read transcript from Google Docs and add to Salesforce prospect
import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';

const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;
await salesforce.updateRecord({
  objectType: 'SalesMeeting',
  recordId: '00Q5f000001abcXYZ',
  data: { Notes: transcript }
});

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

פתרון שאני יותר אוהב הוא פשוט לוותר על MCP ולכתוב כלים פשוטים לשורת הפקודה. אם היו כלים לשורת הפקודה לדבר עם gdrive ו salesforce הסוכן היה יכול לכתוב:

gdrive --get-document abc123 | salesforce --update-record --record-id 00Q5f00001abcXYZ

או בדוגמה של ספירת השורות בפוסט הסוכן יכל היה לכתוב:

get-post post-title | wc -l

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

באותו נושא שווה להזכיר את הפרויקט:

https://github.com/philschmid/mcp-cli

שמאפשר להפעיל שרתי MCP מתוך תוכניות CLI.

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

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

1. גיט מייצר patch לקומיט הראשון, מנסה להפעיל אותו על המצב העדכני של main.

2. יש קונפליקט, אתה מתקן את הקונפליקט ואז גיט ממשיך לקומיט הבא.

3. גיט שוב מייצר patch ומנסה להפעיל אותו, שוב יש קונפליקט ואתה צריך לתקן גם את הקונפליקט השני.

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

מזל שיש לנו AI.

המתג -p של קופיילוט מאפשר להעביר פרומפט משורת הפקודה. יחד עם --allow-all ו --autopilot יש לנו מפלצת סקריפטים. אני יוצר את הסקריפט git-llmrebase

  # ~/.git-llmrebase
  #!/usr/bin/env bash
  branch=$(git rev-parse --abbrev-ref HEAD)
  target="$1"

  ollama launch copilot --model glm-5.1:cloud -- --allow-all --autopilot --share -p \
  "Do an LLM rebase to ${target}: run git diff ${branch}...${target} review all changes from their merge-base and re-implement them on the ${target}. Move branches so ${target} won't change and ${branch} will point to the new implementation. Instead of applying the patches one by one just read the differences from ${target} and re-build the most recent changes of ${branch} there. End result: branch ${branch} is a single commit branch with the most recent changes and ${target} as its parent"

ואז מחבר אותו לגיט עם:

chmod +x ~/.git-llmrebase
git config --global alias.llmrebase '!~/.git-llmrebase'

ועכשיו נוכל להריץ:

git llmrebase foo

ולתת ל AI לשבור את הראש ולמצוא רק את השינויים הרלוונטיים.

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

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

הבעיה עם שרתי MCP היא שמאוד קשה לתאר למודל מה היכולות של השירות צד שלישי אליו ה MCP מחבר. בנוסף שרתי MCP הם ממש תוכנות ודורשים כניסה לקוד כדי לקרוא או לשנות אותם. את שני האתגרים האלה התעשייה מנסה לתקן בחודשים האחרונים בעזרת מנגנון שנקרא Skills. בואו נראה איך זה עובד באמצעות השוואה בין Skill ל MCP וכך נענה על השאלה "איך לחבר את השירות שלכם לסוכן חכם".

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

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

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

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

אם כשיש בעיה אנחנו לא בטוחים מה גרם לה.

אם העבודה עם הסוכן מתישה בהרבה מקידוד רגיל.

אם הקוד נראה לנו ממש סביר, אבל כשאנחנו מבקשים Code Review סוכן אחר מוצא דברים שאנחנו לא ראינו.

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

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

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

הנה שיחה קצרה לדוגמה עם סוכן.

הסוכן- "הודעת השגיאה אומרת שגרסאות חדשות של רובי כבר לא טוענות אוטומטית את OpenStruct. הוספתי פקודת require יזומה ועכשיו זה עובד".

אני- "עדיף להשתמש ב Data"

הסוכן- "אתה צודק! ברור שעדיף להשתמש ב Data. מיד מעדכן את הקוד"

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

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

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

https://open.spotify.com/episode/7wTqD5zwl8ZitUeplapvBG?si=f87b7e5cd4c14ff3

אלה הנקודות המרכזיות שלקחתי מהשיחה:

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

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

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

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

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

6. באותו נושא היא מאוד המליצה לכתוב Eval-ים כדי לתאם ציפיות בין מנהלי פרויקט וצוותי הפיתוח.

7. מודלים חדשים יכולים לייתר יכולות, ולפתוח פיצ'רים חדשים - כשהמודלים לא הצליחו לעשות משימות מורכבות הם הוסיפו מנגנון של Todo List בתוך קלוד קוד. המודל ממלא את רשימת ה Todo והרתמה רצה בלולאה עד שכל הסעיפים בוצעו. ככל שהמודל השתפר לכיוון אופוס או סונט 4.6 הם ראו שאפשר להעביר את כל פיצ'ר ה Todo להיות Tool והמודל מצליח להשתמש בו כדי לייצר לעצמו את הרשימות, ואופוס החדש אפילו לא צריך את זה ועובד טוב גם בלי רשימת Todo. פיצ'ר נוסף שעלה היה פיצ'ר ה Code Review, שהיה מוכן כבר תקופה אבל אף מודל לא הצליח לתת להם תוצאות טובות עד שהגיע אופוס 4.7 ולכן הם חיכו עם שילוב הפיצ'ר עד שהמודל ישתפר. הם מתמודדים עם זה באמצעות פיתוח פיצ'רים גם אם התוצאה עדיין לא מושלמת מתוך הנחה שעוד כמה חודשים תצא גרסה חדשה של המודל שכן תתמודד עם האתגר, ובמקביל כל גרסה חדשה של מודל חוזרים לבדוק אם יש פיצ'רים בסוכן שאפשר להוריד כי המודל כבר מצליח לעבוד טוב יותר בלעדיהם.

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

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

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

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

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

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

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

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

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

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

We’ve seen usage intensify for all users as they realize the value of agents and subagents in tackling complex coding problems

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

בהסתכלות קדימה אני מהמר שזה הולך להשתנות.

נורות להט ישנות צרכו 60 וואט אבל רוב החשמל הזה הפך לחום. הנורות החסכוניות היום נותנות אור דומה אבל צריכות רק 13-15. נורות לד יורדות ל 8-10 וואט בשביל אותו אור.

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

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

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

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

1. הרצת סוכנים משורת הפקודה, מהענן ומ VS Code, כולם מנוהלים מאותו מסך ורצים במקביל. הוא יודע להריץ Sub Agents כדי לבצע משימות בלי ללכלך את חלון הקונטקסט ויש מצב fleet בו הוא לבד שובר משימה לחלקים קטנים ונותן לכמה סוכנים לבצע אותה במקביל.

2. מצב טייס אוטומטי - מתוכנית לפיצ'ר ממומש ללא מגע יד אדם.

3. חיבור קופיילוט לעורכי טקסט אחרים (היוש nvim) דרך פרוטוקול ACP.

4. קופיילוט יודע להתחבר ל Ollama ולהשתמש במודלים שרצים אצלכם על המחשב או דרך מנוי Ollama cloud.

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

6. קופיילוט בתוך VS Code מגיע עם דפדפן מובנה, וגם מתחבר דרך MCP לכרום.

7. קופיילוט יודע לכתוב לכם Code Review אוטומטי.

8. קופיילוט מתחבר לסוכנים שכבר בניתם ב Claude Agents SDK ויכול לשלוח אליהם משימות.

9. קופיילוט יודע לקרוא "תיקיות קונטקסט" שאנחנו בונים בענן (נקרא Spaces), שם נוכל לשמור לדוגמה Design System שנרצה שתהיה לנו זמינה לכמה פרויקטים.

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