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

טיפים קצרים וחדשות למתכנתים

היום למדתי: "חוץ מ" בגיט

12/05/2026

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

$ git add .
$ git reset api.js

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

$ git add . ':!api.js'

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

וכן זה עובד בכל הפקודות ב git שצריכות קבצים כמו add, rm, restore, log ועוד.

אז עדיין צריך הודעות קומיט?

11/05/2026

ב 2026 סוכני קידוד יודעים לכתוב הודעות קומיט טובות יותר מאיתנו גם בדיעבד. ניסיתי את זה - הפרומפט:

explain the commit 
1. what changed?
2. why?
3. what's still left to do for this issue?

עם הקומיט שעשיתי כאן:

https://github.com/ynonp/langlets-rails/commit/c07821619789ce2c814f9056088f0b083c7e92c7

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

ועכשיו השאלה בכותרת היא התלבטות אמיתית.

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

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

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

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

הסכנות בהרצת סוכני קידוד על המכונה שלנו

10/05/2026

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

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

המשך קריאה

טוקנים מיותרים

09/05/2026

ביקשתי מקלוד אופוס לכתוב דוגמה לאפליקציית Hello World בפלאסק. הקוד של main שהוא כתב היה:

from app import create_app

app = create_app()


if __name__ == "__main__":
    app.run(host="127.0.0.1", port=5100, debug=True)

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

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

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

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

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

נ.ב. גם המודל וגם ה Harness אחראים לטוקנים המיותרים. לפעמים יותר קל להעתיק את הפרומפט ל pi או לקופיילוט ולראות מה הם יעשו במקום לנקות קוד מנופח של קלוד קוד. המשחק הוא לא AI אלא פייתון. לדעת שלא צריך לציין host=127.0.0.1 בקריאה ל run כי זו ברירת המחדל.

הוק לקלוד עבור קומיט אחרי כל שינוי

08/05/2026

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

חלק מהמשתתפים העירו שאפשר לעשות את הקומיטים האלה אוטומטית ואז לא שוכחים. הלכתי לחקור את הרעיון ושמחתי לראות שזה עבד די בקלות. אם אתם בקלוד קוד אפשר ליצור קובץ .claude/settings.json בתיקיית הפרויקט עם התוכן הבא:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/auto-commit.sh",
            "async": true,
            "timeout": 30
          }
        ]
      }
    ]
  }
}

ואז הסקריפט auto-commit.sh ירוץ כל פעם שקלוד מסיים לכתוב תשובה. את הסקריפט עצמו נתתי לקלוד לכתוב והוא נראה כך:

#!/usr/bin/env bash
# Stop hook: auto-commit Claude's changes using the last user prompt
# as the commit message.

set -uo pipefail

INPUT=$(cat)
read -r STOP_HOOK_ACTIVE TRANSCRIPT_PATH PROJECT_DIR < <(
  printf '%s' "$INPUT" | jq -r '[.stop_hook_active // false, .transcript_path // "", .cwd // ""] | @tsv'
)

[ "$STOP_HOOK_ACTIVE" = "true" ] && exit 0

[ -n "$PROJECT_DIR" ] && cd "$PROJECT_DIR" 2>/dev/null || exit 0
git rev-parse --git-dir >/dev/null 2>&1 || exit 0
git add -A 2>/dev/null || exit 0
git diff --cached --quiet && exit 0

# Last user text message from this turn's transcript.
# Skips tool_result entries and slash-commands (which start with '<').
USER_PROMPT=""
if [ -f "$TRANSCRIPT_PATH" ]; then
  USER_PROMPT=$(jq -r '
    select(.type == "user") | .message.content
    | if type == "string" then .
      elif type == "array" then (map(select(.type == "text")) | .[0].text // "")
      else "" end
    | select(. != "" and (startswith("<") | not))
  ' "$TRANSCRIPT_PATH" 2>/dev/null | tail -1)
fi

# Use the user prompt as the commit message; first line as subject (capped at
# 72 chars), remaining lines as the body.
if [ -n "$USER_PROMPT" ]; then
  SUBJECT=$(printf '%s' "$USER_PROMPT" | head -1 | cut -c1-72)
  BODY=$(printf '%s' "$USER_PROMPT" | tail -n +2)
else
  SUBJECT="checkpoint: $(date +%H:%M)"
  BODY=""
fi

if [ -n "$BODY" ]; then
  git commit --no-verify -m "$SUBJECT" -m "$BODY" >/dev/null 2>&1 || true
else
  git commit --no-verify -m "$SUBJECT" >/dev/null 2>&1 || true
fi
exit 0

קלוד מפעיל את הסקריפט עם JSON של מידע על השיחה האחרונה. מה שמעניין אותנו מתוך ה JSON הזה הוא ההודעה של המשתמש, כי אני אוהב שהפרומפט שלי הופך להודעת הקומיט (אם צריך הודעה יותר מתוחכמת אפשר להשתמש ב git commit --amend כדי לתקן). ליתר בטחון קלוד הוסיף --no-verify לפקודת הקומיט כדי לדלג על קומיט הוקס. אני חושב שזה הוגן וממילא לא משתמש בקומיט הוקס. יש גם בדיקה בהתחלה שמדלגת על כל הסקריפט אם אנחנו לא בתוך ריפו.

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

איטרציות מהירות, פיצ'רים איטיים

07/05/2026

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

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

ההזדמנות היא לייצר את הקוד הנכון.

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

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

קריאה מודרכת בלולאת הסוכן של פאי

06/05/2026

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

הריפו של פאי נמצא כאן:

https://github.com/badlogic/pi-mono/

ובשביל להבין איך עובדת לולאת סוכן נסתכל על הקובץ:

https://github.com/badlogic/pi-mono/blob/main/packages/agent/src/agent-loop.ts

ונחפש את הפונקציה runLoop. זה המימוש כמו שהוא - סופר קריא ומתועד:

async function runLoop(
    currentContext: AgentContext,
    newMessages: AgentMessage[],
    config: AgentLoopConfig,
    signal: AbortSignal | undefined,
    emit: AgentEventSink,
    streamFn?: StreamFn,
): Promise<void> {
    let firstTurn = true;
    // Check for steering messages at start (user may have typed while waiting)
    let pendingMessages: AgentMessage[] = (await config.getSteeringMessages?.()) || [];

    // Outer loop: continues when queued follow-up messages arrive after agent would stop
    while (true) {
        let hasMoreToolCalls = true;

        // Inner loop: process tool calls and steering messages
        while (hasMoreToolCalls || pendingMessages.length > 0) {
            if (!firstTurn) {
                await emit({ type: "turn_start" });
            } else {
                firstTurn = false;
            }

            // Process pending messages (inject before next assistant response)
            if (pendingMessages.length > 0) {
                for (const message of pendingMessages) {
                    await emit({ type: "message_start", message });
                    await emit({ type: "message_end", message });
                    currentContext.messages.push(message);
                    newMessages.push(message);
                }
                pendingMessages = [];
            }

            // Stream assistant response
            const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);
            newMessages.push(message);

            if (message.stopReason === "error" || message.stopReason === "aborted") {
                await emit({ type: "turn_end", message, toolResults: [] });
                await emit({ type: "agent_end", messages: newMessages });
                return;
            }

            // Check for tool calls
            const toolCalls = message.content.filter((c) => c.type === "toolCall");

            const toolResults: ToolResultMessage[] = [];
            hasMoreToolCalls = false;
            if (toolCalls.length > 0) {
                const executedToolBatch = await executeToolCalls(currentContext, message, config, signal, emit);
                toolResults.push(...executedToolBatch.messages);
                hasMoreToolCalls = !executedToolBatch.terminate;

                for (const result of toolResults) {
                    currentContext.messages.push(result);
                    newMessages.push(result);
                }
            }

            await emit({ type: "turn_end", message, toolResults });

            if (
                await config.shouldStopAfterTurn?.({
                    message,
                    toolResults,
                    context: currentContext,
                    newMessages,
                })
            ) {
                await emit({ type: "agent_end", messages: newMessages });
                return;
            }

            pendingMessages = (await config.getSteeringMessages?.()) || [];
        }

        // Agent would stop here. Check for follow-up messages.
        const followUpMessages = (await config.getFollowUpMessages?.()) || [];
        if (followUpMessages.length > 0) {
            // Set as pending so inner loop processes them
            pendingMessages = followUpMessages;
            continue;
        }

        // No more messages, exit
        break;
    }

    await emit({ type: "agent_end", messages: newMessages });
}

אלה החלקים המרכזיים:

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

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

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

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

  5. אם יש הודעות ניווט ממתינות נוסיף אותן לרשימת ההודעות של השיחה.

עכשיו מגיעה השורה הכי חשובה של הפונקציה:

const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);

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

const toolCalls = message.content.filter((c) => c.type === "toolCall");

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

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

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

המשך קריאה

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

05/05/2026

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

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

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

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

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

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

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

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

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

04/05/2026

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

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

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

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

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

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

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

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

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

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

03/05/2026

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

מריו זכנר כתב סוכן קידוד בשם 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, השתכנעו ב"למה לקרוא את הקוד" ועכשיו צריכים להבין את ה"איך". זה לא יהיה קל.

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