📌 ללמוד לראות ולהראות

אי אפשר לתקן בעיה שלא רואים.

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

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

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

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

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

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

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

📌 סיכום וובינר: סוכנים מנוהלים

היום בוובינר דיברנו על Claude Managed Agents וראינו הדגמה של הקוד ואיך ליצור את ההדגמה הזו אצלכם. אלה עיקרי הדברים שהיו שם.

✏ מה זה Managed Agents

גם אנתרופיק וגם OpenAI השיקו לאחרונה מוצר של סוכנים מנוהלים. מוצרים אלה מתחרים ב Agent Core של AWS וההסבר לכל הקטגוריה הוא פשוט - להריץ סוכנים זה מסובך. בין השאר:

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

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

✏ איך לכתוב סוכן מנוהל באנתרופיק

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

https://platform.claude.com/docs/en/managed-agents/quickstart

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

/claude-api managed-agents-onboard

קלוד קוד שאל אותי מה אני רוצה שהסוכן יעשה ואני ביקשתי סוכן של רשימת קניות שתומך בשתי פעולות, הוספת פריט לרשימה וצפיה ברשימה. נכון רשימת קניות אמיתית גם צריכה לאפשר לסמן שקנינו משהו או למחוק פריטים אבל את זה נשאיר לגרסה 2. אחרי קצת חשיבה קלוד קוד יצר שלושה קבצים: קובץ requirements.txt עם כל התלויות, קובץ app.py עם שרת API וקובץ setup.py שמקים את הסוכן באנתרופיק.

מפתח ה API שלי היה שמור בקובץ .env ובאיטרציה הראשונה קלוד קוד שכח לטעון אותו אבל אחרי תזכורת הקוד התחיל לעבוד. הקובץ הראשון setup.py מכיל את הקוד הבא:

# ONE-TIME SETUP - run once (`python setup.py`), then copy the printed lines into .env
#
# Creates the three reusable, versioned resources the runtime app needs:
#   - an environment (the cloud sandbox)
#   - a memory store (persists the shopping list across sessions)
#   - an agent (model/system/tools - references nothing session-specific)
#
# Agents/environments could also be defined as YAML and applied with the `ant` CLI
# for CI-managed configs (see shared/anthropic-cli.md) - this script also creates
# the memory store, which the CLI doesn't have a documented syntax for yet, so
# everything is grouped here for a single one-time run.
import anthropic
from dotenv import load_dotenv

load_dotenv()

client = anthropic.Anthropic()

SHOPPING_LIST_PATH = "/shopping_list.md"


def main():
    environment = client.beta.environments.create(
        name="shopping-list-env",
        config={"type": "cloud", "networking": {"type": "unrestricted"}},
    )

    store = client.beta.memory_stores.create(
        name="Shopping List",
        description="The user's shopping list: a single markdown checklist file.",
    )
    client.beta.memory_stores.memories.create(
        store.id,
        path=SHOPPING_LIST_PATH,
        content="# Shopping List\n",
    )

    agent = client.beta.agents.create(
        name="Shopping List Agent",
        model="claude-sonnet-5",
        system=(
            "You manage the user's shopping list. It lives as a single file, "
            f"shopping_list.md, inside your attached memory store - a markdown "
            "checklist with one item per line, formatted as `- item`.\n\n"
            "When asked to add an item: read the file, add the new line only if an "
            "equivalent item isn't already present (merge quantities when given, e.g. "
            "adding 'milk' when 'milk' is already there should not create a duplicate "
            "line), then write the file back. Reply with a short confirmation of what "
            "changed.\n\n"
            "When asked for the current list: read the file and reply with the items, "
            "one per line, no extra commentary. If the list is empty, say so explicitly."
        ),
        tools=[
            {
                "type": "agent_toolset_20260401",

                "default_config": {"enabled": True},
                "configs": [
                    {"name": "web_search", "enabled": False},
                    {"name": "web_fetch", "enabled": False},
                ],
            }
        ],
    )

    print("Add these lines to .env:")
    print(f"ANTHROPIC_ENV_ID={environment.id}")
    print(f"ANTHROPIC_AGENT_ID={agent.id}")
    print(f"ANTHROPIC_AGENT_VERSION={agent.version}")
    print(f"ANTHROPIC_MEMORY_STORE_ID={store.id}")


if __name__ == "__main__":
    main()

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

1. סביבה - איפה הסוכן ירוץ, איזה הרשאות יהיו לו.
2. זכרון - איזה קבצים הסוכן יחזיק, במקרה שלנו קובץ markdown של רשימת הקניות.
3. סוכן - מודל, הוראות וכלים.

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

הקובץ השני שנוצר הוא app.py, זה פשוט שרת API ב flask רגיל לגמרי שמתחבר לסוכן:

# RUNTIME - every invocation. Requires setup.py to have been run once and its
# printed IDs added to .env.
import os
import time

import anthropic
from dotenv import load_dotenv
from flask import Flask, jsonify, render_template, request

load_dotenv()

client = anthropic.Anthropic()

AGENT_ID = os.environ["ANTHROPIC_AGENT_ID"]
AGENT_VERSION = os.environ["ANTHROPIC_AGENT_VERSION"]
ENV_ID = os.environ["ANTHROPIC_ENV_ID"]
STORE_ID = os.environ["ANTHROPIC_MEMORY_STORE_ID"]

MEMORY_INSTRUCTIONS = (
    "This store holds one file, shopping_list.md - a markdown checklist, one item "
    "per line as `- item`. Read it before answering and write it back after any change."
)

app = Flask(__name__)


def run_single_turn(message: str) -> str:
    """Create a short-lived session, send one message, return the agent's reply text."""
    session = client.beta.sessions.create(
        agent={"type": "agent", "id": AGENT_ID, "version": AGENT_VERSION},
        environment_id=ENV_ID,
        resources=[
            {
                "type": "memory_store",
                "memory_store_id": STORE_ID,
                "access": "read_write",
                "instructions": MEMORY_INSTRUCTIONS,
            }
        ],
    )
    print(f"session: https://platform.claude.com/workspaces/default/sessions/{session.id}", flush=True)

    reply_parts: list[str] = []
    with client.beta.sessions.events.stream(session_id=session.id) as stream:
        client.beta.sessions.events.send(
            session_id=session.id,
            events=[{"type": "user.message", "content": [{"type": "text", "text": message}]}],
        )
        for event in stream:
            if event.type == "agent.message":
                for block in event.content:
                    if block.type == "text":
                        reply_parts.append(block.text)
            elif event.type == "session.status_terminated":
                break
            elif event.type == "session.status_idle":
                if event.stop_reason.type == "requires_action":
                    continue  # waiting on a tool confirmation/result we don't send here
                break  # end_turn, retries_exhausted, or budget_reached

    # This session is one-shot - nothing else will use it, so archive it instead
    # of leaving it sitting `idle` forever. The stream's `status_idle` event can
    # arrive slightly before the session's queryable status catches up, so a
    # fresh archive call can 400 with "cannot archive while running" - retry briefly.
    for attempt in range(3):
        try:
            client.beta.sessions.archive(session_id=session.id)
            break
        except anthropic.APIStatusError as e:
            if e.status_code == 400 and attempt < 2:
                time.sleep(1)
                continue
            print(f"warning: could not archive session {session.id}: {e}", flush=True)

    return "".join(reply_parts).strip()


@app.get("/")
def index():
    return render_template("index.html")


@app.get("/shopping-list")

def get_list():
    reply = run_single_turn(
        "List everything currently on the shopping list. Reply with one item per "
        "line, each line formatted as `- item`, and nothing else. If it's empty, "
        "just say so in plain text instead."
    )
    items = [
        line.strip()[1:].strip()
        for line in reply.splitlines()
        if line.strip().startswith("-")
    ]
    return jsonify({"items": items, "raw": reply})


@app.post("/shopping-list")
def add_item():
    item = (request.get_json(force=True) or {}).get("item", "").strip()
    if not item:
        return jsonify({"error": "missing 'item'"}), 400
    reply = run_single_turn(f"Add '{item}' to the shopping list.")
    return jsonify({"result": reply})


if __name__ == "__main__":
    app.run(port=8000, debug=True)

הפונקציה המעניינת כאן היא run_single_turn והיא פונה לסוכן עם בקשה ומחזירה את התשובה. הפניה לסוכן מבוצעת דרך קריאת הספריה client.beta.sessions.create כדי ליצור session ולאחריה client.beta.sessions.events.stream כדי לשלוח הודעה.

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

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

סך הכל מבחינת נוחות עבודה Claude Managed Agents לדעתי יותר נוח מ Agent Core, במיוחד אם ממילא אתם רוצים לעבוד רק עם הסוכנים שלהם.

📌 שומר סף

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

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

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

וגם פה AI יכול לעזור.

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

📌 ארבע טעויות של AI ואיך לתפוס אותן בלי לקרוא את הקוד

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

✏ מספרים קסומים והגבלות מלאכותיות

את הקוד הזה כתב GPT 5.6 כחלק ממימוש פיצ'ר שביקשתי:

@messages = Array(client.messages_index(limit: 50, order: "-modified", search_key: @search_query)["data"])
  .select { ...}

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

בגלל שלא ציינתי גבול ולא ביקשתי מנגנון Pagination הסוכן החליט להגביל את השליפה ל-50 תוצאות.

הנה עוד אחד מתיאור כלי ל MCP:

limit: int("Maximum number of characters to return per part. Defaults to 4000."),

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

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

✏ מימוש מנגנון כפול

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

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

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

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

✏ קוד חדש ששובר קוד או עיצוב קיים

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

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

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

✏ רציתי לונדון וקיבלתי מלחמה

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

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

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

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

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

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

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

📌 השוואת מימושים - רובי מול פייתון

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

פרומפט ראשון בפייתון:

create a python function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

והמימוש:

import csv


def load_customers(csv_path):
    customers = []
    seen_emails = set()

    with open(csv_path, mode="r", newline="", encoding="utf-8") as file:
        reader = csv.DictReader(file)

        if "email" not in reader.fieldnames:
            raise ValueError("CSV must contain an 'email' column")

        for row in reader:
            # Normalize email so casing/whitespace doesn't create duplicates
            email = row["email"].strip().lower()

            if email not in seen_emails:
                seen_emails.add(email)
                row["email"] = email
                customers.append(dict(row))

    return customers

כמה דברים בולטים:

1. אין טיפול ב BOM, שהוא תו נסתר בתחילת הקובץ שמציין את סדר הבתים. בלי טיפול זה אם עמודת email היא הראשונה אנחנו עלולים לקבל את הטקסט \uFEFFemail בתור שם העמודה במקום רק email וכך ההשוואה תכשל.
2. ערך email חסר בשורה מסוימת מפעיל strip על None, נכשל ומרסק את כל הפונקציה במקום לדלג על הערך החסר.
3. אם יש מספר שורות עם אותה כתובת מייל המימוש שומר רק את הראשון ולא ממזג את הנתונים.
4. אין וולידציה או אורך מינימלי על כתובת מייל כך שעמודת email ריקה גורמת לשמירה של הנמען.

עכשיו אני מנסה פרומפט כמעט זהה, רק מחליף את השפה:

create a ruby function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

התוצאה:

require "csv"

def load_customers(csv_path)
  customers_by_email = {}

  CSV.foreach(csv_path, headers: true) do |row|
    customer = row.to_h
    email = customer["email"]&.strip&.downcase

    next if email.nil? || email.empty?

    # Keep the first customer found for each email
    customers_by_email[email] ||= customer
  end

  customers_by_email.values
end

כמה מאפיינים בולטים:

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

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

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

📌 מה קשה לתת ל AI לכתוב פוסט?

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

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

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

1. ביקשתי מ AI משהו
2. התוצאה לא היתה טובה
3. שיניתי את הפרומפט למשהו יותר ספציפי
4. קיבלתי תוצאה טובה יותר

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

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

https://gist.github.com/ynonp/62e0ac7eab67033bbbb14a8ed149d47d

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

📌 איך לקודד עם AI בלי לאבד שליטה על הקוד

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

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

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

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

https://www.tocode.co.il/talking_ai

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

מה זה אומר שמישהו "מאבד שליטה על הקוד"? הנה דוגמה מפוסט שעלה לרדיט:

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

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

כשאני כותב תוכנית JavaScript כזו:

let smallest = Infinity;

for (let i = 0; i < 10; i++) {
  let num = Number(prompt("Enter number " + (i + 1) + ":"));

  if (num < smallest) {
    smallest = num;
  }
}

console.log("The smallest number is: " + smallest);

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

אבל מה עם AI? כתבו את הפרומפט:

implement a javascript program that reads 10 numbers and print the smallest one

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

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

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

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

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

✏ למה הבן אדם שבלופ הכרחי (עדיין)

להסתכל על קוד ולהסביר אותו? זה קלאסי AI לא?

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

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

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

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

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

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

✏ טיפ 1 - מבינים את השינוי לפני כל מיזוג

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

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

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

✏ טיפ 2 - בועטים ואז חוקרים

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

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

1. באיזה קומיט זה נכנס?
2. איך לא שמנו לב?
3. מה ההשפעה של התקלה הזו? האם יש מקומות במערכת אליהם היא דווקא תורמת?
4. איך אפשר לשנות את הארכיטקטורה או מבנה המערכת כדי שתקלה כזו בכלל לא תוכל לקרות?
5. האם AI היה יכול לפתור אותה אוטומטית רק מתיאור התקלה? אם לא איזה מנגנונים חסרים לו כדי שכן יוכל?
6. יש עוד דרכים לפתור את זה?
7. האם תקלה דומה נמצאת במקומות נוספים בקוד?

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

✏ טיפ 3 - מכרסמים בפרטים בקצב שלכם

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

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

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

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

✏ טיפ 4 - מחלקים אזורים בקוד ולא פיצ'רים

אם המערכת מעניינת אתם לא עובדים עליה לבד. שיטת ה Agile לימדה אותנו שמפתחים צריכים לקחת אחריות על פיצ'רים מקצה לקצה וכדאי ליצור Ownership כך שמפתחים אחראים על המוצר שהם בונים.

בעולם ה AI אני לא חושב שזה רעיון טוב.

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

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

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

📌 את כל הקוד כותב AI אבל...

אצלנו 100% מהקוד נכתב על ידי AI, אבל-

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

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

📌 למה לבנות לעצמכם מערכת לפיתוח סוכנים

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

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

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

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

ועכשיו תנסו קצת Use Cases:

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

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

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