זוכרים שדיברנו לפני כמה ימים על מודל ה Premium Requests של גיטהאב ואיך זה כבר לא עובד להם יותר? אז הנה הגיעה ההודעה הרשמית

Premium request units, or PRUs, will be replaced by GitHub AI Credits which are a monthly allotment of credits consumed based on token consumption (input, output, and cached tokens) according to the listed API rates per model. This change aligns Copilot pricing with actual usage and is an important step toward a sustainable, reliable Copilot business and experience for all users.

📌 איך לחבר את השירות שלכם לסוכן חכם

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

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

✏ דוגמה: חיבור לדפדפן עם MCP

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

אני מתחיל עם שרת ה MCP והקוד שלו שזמין בריפו הזה:

https://github.com/microsoft/playwright/tree/main/packages/playwright-core/src/tools/mcp

נקודת הכניסה לשרת היא הקובץ program.ts עם השורה:

await mcpServer.start(factory, config.server);

הקובץ היותר מעניין הוא backend/tools.ts שמחזיק את רשימת הכלים:

export const browserTools: Tool<any>[] = [
  ...common,
  ...config,
  ...console,
  ...cookies,
  ...devtools,
  ...dialogs,
  ...evaluate,
  ...files,
  ...form,
  ...keyboard,
  ...mouse,
  ...navigate,
  ...network,
  ...pdf,
  ...route,
  ...runCode,
  ...screenshot,
  ...snapshot,
  ...storage,
  ...tabs,
  ...tracing,
  ...verify,
  ...video,
  ...wait,
  ...webstorage,
];

וכל כלי מוגדר על ידי הפונקציה defineTabTool לדוגמה:

const snapshot = defineTabTool({
  capability: 'core',
  schema: {
    name: 'browser_snapshot',
    title: 'Page snapshot',
    description: 'Capture accessibility snapshot of the current page, this is better than screenshot',
    inputSchema: z.object({
      target: z.string().optional().describe(elementTargetDescription),
      filename: z.string().optional().describe('Save snapshot to markdown file instead of returning it in the response.'),
      depth: z.number().optional().describe('Limit the depth of the snapshot tree'),
      boxes: z.boolean().optional().describe('Include each element\'s bounding box as [box=x,y,width,height] in the snapshot'),
    }),
    type: 'readOnly',
  },

  handle: async (tab, params, response) => {
    let resolved: { locator: playwright.Locator | undefined, resolved: string } = { locator: undefined, resolved: '' };
    if (params.target)
      resolved = await tab.targetLocator({ target: params.target });
    response.setIncludeFullSnapshot(params.filename, resolved.locator, params.depth, params.boxes);
  },
});

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

    {
      "name": "browser_snapshot",
      "description": "Capture accessibility snapshot of the current page, this is better than screenshot",
      "inputSchema": {
        "type": "object",
        "properties": {
          "filename": {
            "description": "Save snapshot to markdown file instead of returning it in the response.",
            "type": "string"
          },
          "depth": {
            "description": "Limit the depth of the snapshot tree",
            "type": "number"
          }
        },
        "$schema": "https://json-schema.org/draft/2020-12/schema",
        "additionalProperties": false
      },
      "annotations": {
        "title": "Page snapshot",
        "readOnlyHint": true,
        "destructiveHint": false,
        "openWorldHint": true
      }
    },

זה תיאור מאוד מפורט שמציג מה אפשר לעשות עם הכלי, ויש שיגידו יותר מדי מפורט. כשטענתי את שרת ה MCP הזה בתוך קופיילוט הוא הוסיף כ-3,500 טוקנים לכל בקשה (לא רק כלי ה snapshot, אלא ה MCP כולו).

מה זה אומר?

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

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

✏ אז איך זה עובד עם Skill?

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

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

1. סקיל בנוי ממספר קבצי טקסט והסוכן באופן יזום טוען את הקבצים שהוא צריך - זה אומר שאנחנו לא צריכים להעמיס את התיאור של כל אפשרויות החיבור בקונטקסט. כשהסוכן יזהה שהוא צריך מידע נוסף על אפשרות חיבור מסוימת הוא יטען את הקובץ המתאים.
2. פורמט טקסטואלי הוא פחות בזבזני מ JSON.

בדוגמה של ה snapshot שראינו קודם החלק הרלוונטי מקובץ ה Skill הוא:

  Snapshots
  After each command, playwright-cli provides a snapshot of the current browser state.
  
  > playwright-cli goto https://example.com
  ### Page
  - Page URL: https://example.com/
  - Page Title: Example Domain
  ### Snapshot
  [Snapshot](.playwright-cli/page-2026-02-14T19-22-42-679Z.yml)
  You can also take a snapshot on demand using playwright-cli snapshot command. All the options below can be combined as needed.
  
  # default - save to a file with timestamp-based name
  playwright-cli snapshot
  
  # save to file, use when snapshot is a part of the workflow result
  playwright-cli snapshot --filename=after-click.yaml
  
  # snapshot an element instead of the whole page
  playwright-cli snapshot "#main"
  
  # limit snapshot depth for efficiency, take a partial snapshot afterwards
  playwright-cli snapshot --depth=4
  playwright-cli snapshot e34
  
  # include each element's bounding box as [box=x,y,width,height]
  playwright-cli snapshot --boxes

אפשר למצוא את קובץ הסקיל המלא בגיטהאב שלהם:

https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/SKILL.md

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

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

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

📌 איך (ולמה) לתת ל AI לטפל בריבייסים

שנים סיפרו לנו שריבייס זה אחלה מנגנון כי הוא שומר על היסטוריית גיט לינארית. הם לא סיפרו על הקונפליקטים כשמנסים לעשות ריבייס על 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 כשיש הרבה קונפליקטים. נו כמו שאומרים הסוכנים, חיים רק פעם אחת.

📌 חמש דוגמאות ל Type Hints מעניינים בפייתון

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

✏ העברת פרמטרים As-Is

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

def retry_on_failure(func):
    def wrapper(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except Exception:
            print("Retrying...")
            return func(*args, **kwargs)
    return wrapper

@retry_on_failure
def say_my_name(name: str):
    print(name)

say_my_name('demo')

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

בשביל שזה יעבוד wrapper צריכה להגדיר את אותו Type Hint כמו הפונקציה say_my_name, אבל הדקורטור הוא גנרי, איך יודעים מה הפרמטרים שהוא צפוי לקבל?

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

from typing import Callable, TypeVar, ParamSpec

P = ParamSpec('P')
T = TypeVar('T')

# ParamSpec captures the exact arguments (*args, **kwargs) of the wrapped function.
def retry_on_failure(func: Callable[P, T]) -> Callable[P, T]:
    def wrapper(*args: P.args, **kwargs: P.kwargs) -> T:
        try:
            return func(*args, **kwargs)
        except Exception:
            print("Retrying...")
            return func(*args, **kwargs)
    return wrapper

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

@retry_on_failure
def say_my_name(name: str):
    print(name)

say_my_name(10)

✏ בדיקת קיום פונקציה בלי לחייב ירושה

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

class ItemA:
    def __init__(self):
        self.price = 10

class ItemB:
    def __init__(self):
        self.price = 5

def total_price(items):
    return sum(item.price for item in items) * 1.18

print(total_price([ItemB(), ItemA(), ItemA(), ItemA()]))

אבל מה עושים כשרוצים להוסיף כאן Type Hints? לא נרצה להגדיר בצורה מפורשת בפונקציה שהיא מקבלת רק דברים מסוג ItemA או ItemB כי מחר מישהו יוסיף קלאס חדש עם מאפיין price. גם לא נרצה לשנות את ההגדרה של ItemA או ItemB ולהתחיל להגדיר עבורם היררכיית ירושה חדשה. אנחנו רוצים פשוט להגדיר שהפונקציה מקבלת רשימה של דברים שיש להם מאפיין price.

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

from typing import Protocol

class ItemA:
    def __init__(self):
        self.price = 10

class ItemB:
    def __init__(self):
        self.price = 5

class HasPrice(Protocol):
    @property
    def price(self) -> float:
        ...

def total_price(items: list[HasPrice]):
    return sum(item.price for item in items) * 1.18

print(total_price([ItemB(), ItemA(), ItemA(), ItemA()]))

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

✏ ערכי החזר מסוגים שונים

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

def same(x):
    return x

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

x = same("hello")
print(x + 5)

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

G = TypeVar("G")
def same(x: G) -> G:
    return x

x = same("hello")
print(x + 5)

עכשיו בודק הטיפוסים של פייתון כבר ידע להגיד ש x שחוזר מ same("hello") הוא מטיפוס מחרוזת ולכן אי אפשר לחבר לו 5.

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

T = TypeVar("T")

def add_item(item: T, args):
    return (item, *args)

v = add_item(4, [1, 'a', 'b'])
print(len(v[0]))

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

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

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

from typing import TypeVarTuple, TypeVar, Any

Ts = TypeVarTuple("Ts")
T = TypeVar("T")

def add_item(item: T, *args: *Ts) -> tuple[T, *Ts]:
    return (item, *args)

v = add_item(4, 1, 'a', 'b')
print(len(v[0]))

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

עכשיו בודק הטיפוסים מזהה את הבעיה בהדפסת האורך של v[0] אבל יתן לי להדפיס את האורך של v[2].

✏ שרשור מתודות על אוביקט בירושה

נמשיך לדוגמה הבאה ונכתוב מחשבון:

class Calc:
    def __init__(self):
        self.value = 0

    def add(self, n: int):
        self.value += n
        return self

c = Calc()
c.add(10).add(20).add(30)
print(c.value)

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

    def add(self, n: int) -> Calc:
        self.value += n
        return self

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

class Calc:
    def __init__(self):
        self.value = 0

    def add(self, n: int) -> Calc:
        self.value += n
        return self

class AdvancedCalc(Calc):
    def sub(self, n: int) -> AdvancedCalc:
        self.value -= n
        return self

c = AdvancedCalc()
c.add(10).sub(15).add(30)
print(c.value)

הקריאה ל add הפכה את המשתנה מ AdvancedCalc ל Calc עבור בודק הטיפוסים כיוון שזה מה ש add מחזירה. גישה טובה יותר תגיד לפייתון שהפונקציה add מחזירה את אותו טיפוס של self - אם התחלנו עם Calc זה מה שנחזיר, ואם התחלנו עם AdvancedCalc נחזיר את AdvancedCalc. הקוד משתמש בטיפוס בשם Self, עוד חידוש של פייתון 3.11:

from typing import Self

class Calc:
    def __init__(self):
        self.value = 0

    def add(self, n: int) -> Self:
        self.value += n
        return self

class AdvancedCalc(Calc):
    def sub(self, n: int) -> Self:
        self.value -= n
        return self

c = AdvancedCalc()
c.add(10).sub(15).add(30)
print(c.value)

✏ טיפוסים רקורסיביים

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

JsonValue = Union[int, float, str, bool, None, Dict[str, 'JsonValue'], List['JsonValue']]

def parse_api_response(payload: JsonValue):
    pass

גרסאות חדשות יותר של פייתון מאפשרות לוותר על המרכאות באמצעות הגדרת Type Alias:

type JsonValue = Union[int, float, str, bool, None, Dict[str, JsonValue], List[JsonValue]]

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

📌 למי אכפת מ MCP Composability

את הדוגמה הבא להרכבת 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.

📌 מה למדתי על Code Review מהסוכנים של Qt

החברים ב Qt שחררו מסמך סקיל שמלמד את קלוד קוד איך לעשות Code Review לקוד Qt. אפשר לקרוא כאן ואני ממליץ:

https://github.com/TheQtCompanyRnD/agent-skills/blob/main/skills/qt-cpp-review/SKILL.md

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

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

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

Check for:

    Structs/classes with raw pointers where new is visible and no corresponding delete/deleteLater/smart-pointer wrapping exists (Rule of Five violation)
    
    Missing deleteLater() on QNetworkReply in finished handlers
    
    Q_ASSERT wrapping side-effectful expressions (compiled out in release builds — the side effect disappears)
    
    Q_ASSERT as the sole null guard (crashes in release)
    
    Polymorphic QObject subclasses missing Q_DISABLE_COPY_MOVE
    
    Polymorphic classes missing virtual destructor
    
    QTimer/QObject created with new but no parent and no other lifecycle management (scope, smart pointer, explicit delete)
    
    QObject::connect() called with potentially null sender/receiver outside a null guard (runtime warning)
    
    m_recentlyAccessed-style tracking lists that maintain pointers to objects that may be deleted elsewhere (dangling)
    
    Unbounded container growth (append without cap or trim)
    
    Destructor not cleaning up owned children recursively
    
    Abstract interfaces with no implementations beyond one class (YAGNI violation — codebase scope only)
References: references/qt-review-checklist.md § Ownership & Lifecycle, § Polymorphic Classes, § RAII Classes

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

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

Missing const on methods that don't modify state

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

Expensive operation before cheap early-exit check (wasted allocation)
Missing re-entrancy guard on methods that emit signals which could trigger re-entry

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

1. לקרוא בצורה ביקורתית את הנקודות שהמודל מחזיר, להבין מה אמיתי ומה False Positive.
2. לקרוא בצורה ביקורתית את הקוד עצמו כדי למצוא נקודות שלא נמצאות ברשימה או שהמודל פספס.
3. לעדכן את הרשימה מדי פעם ככל שמגלים נקודות שלא עלו ב Code Reviews או נקודות שמעודדות False Positives. מוחקים מה שיצר טעויות ומוסיפים את מה שלא עלה.

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

📌 למה בכלל לקרוא את הקוד

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

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

The problem with agents is that they make errors. Which is fine, humans also make errors
There's a much more important difference between clanker and human. A human is a bottleneck. A human cannot shit out 20,000 lines of code in a few hours. Even if the human creates such booboos at high frequency, there's only so many booboos the human can introduce in a codebase per day.
You have removed yourself from the loop, so you don't even know that all the innocent booboos have formed a monster of a codebase. You only feel the pain when it's too late.

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

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

Spend 40% of your time on code health, or else you’ll wind up spending >60%
Basically the agent will always find problems, often shocking ones, e.g. where you discover you have two or even three completely redundant systems (databases, logging, telemetry, whatever) that need consolidating.

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

We are entering a surprising new phase of software development, in which rewriting things is often easier (and smarter) than trying to fix them.

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

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

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

📌 חמש מיומנויות קריטיות למפתחים בעידן ה AI

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

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

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

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

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

מלבד שלושת המיומנויות האלה שהן ייחודיות ל AI אני מזהה עוד שתי מיומנויות שתמיד היו חשובות ומקבלות חיזוק משמעותי בעידן החדש:

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

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

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

ונ.ב. סופר קריטי לפוסט הזה ששכחתי בזמן הכתיבה - קריאה ביקורתית

לא לקבל קוד ש AI כותב בלי שאני מבין את זה כאילו זה קוד שאני כתבתי

📌 מתכנת עם מברג בכיס

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

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

השנים הקרובות לא יאירו פנים למתכנתי המברג.

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

הבעיה שלהם היא הגישה.

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

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

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