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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

✏ שאלות למיטיבי לכת

קראו את הקוד ונסו לחשוב:

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

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

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

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

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

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

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

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

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

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

ביקשתי מקלוד אופוס לכתוב דוגמה לאפליקציית 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 כי זו ברירת המחדל.

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

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

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

✏ הרעלת מודלי שפה

מקור:

https://ron.stoner.com/how-i-won-a-championship-that-doesnt-exist/

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

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

✏ באג בסוכן יוצר חיוב מוגזם

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

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

https://github.com/anthropics/claude-code/issues/53262

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

https://github.com/anomalyco/opencode/issues/16937

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

מקור:

https://x.com/lifeof_jer/status/2048103471019434248?s=46

ג'ר קריין, המייסד של PocketOS חיבור את קלוד אופוס לסביבת הפיתוח שלו ב Cursor. הוא שכח שבאיזשהו קובץ טקסט בתיקיית הפרויקט היה כתוב טוקן הגישה לסביבת הפרודקשן - כדי להריץ תהליך תחזוקה שגרתי.

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

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

✏ הזרקת פרומפט מובילה להשתלטות על מכונות

מקור:

https://neciudan.dev/cline-ci-got-compromised-here-is-how

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

allowed_non_write_users: "*"
claude_args: >-
  --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"
prompt: |
  **Issue:** #${{ github.event.issue.number }}
  **Title:** ${{ github.event.issue.title }}

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

סיפור דומה קרה עם Coderabbit, סביבה ל Code Review ואפשר לקרוא עליו כאן:

https://kudelskisecurity.com/research/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories

✏ קידוד מהיר מוביל ליותר באגים

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

כנראה שמיזוג מהיר של פיצ'רים הוא אחד הגורמים לבאג הזה באופןקוד:

https://github.com/anomalyco/opencode/security/advisories/GHSA-vxw4-wv6m-9hhh

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

✏ סיכום

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

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

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

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

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

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

ב 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 של מי שישב ליד ההגה והחליט שזה מוכן.

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

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

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

$ 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 ועוד.

📌 האם שפת התכנות עדיין חשובה?

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

1. שפת תכנות = אקוסיסטם. בגלל זה כולם כותבים GUI בשפות מבוססות ווב וכלי למידת מכונה בפייתון. אבל מה קורה כשאין אקוסיסטם? למה לנגגרף כתובה בפייתון ולא ב rust? למה אנחנו לא מתחילים לכתוב שרתים באליקסיר?
2. גם אם אני לא מתכנן לקרוא כל שורה בקוד עדיין אני שמח שאני יכול להכנס ולהבין בלוקים של קוד. כשאני בוחר שפה שאני מכיר אני יכול לתקשר עם הסוכן בשפה שלי ומרגיש בנוח בתוך השיחה. מצד שני כלי שורת פקודה ב Rust יכול להיות משמעותית יותר מהיר מאותו כלי ב JavaScript, ואולי זה שווה את המאמץ להבין שפה שאני פחות מכיר.
3. מהירות פיתוח עדיין חשובה גם בעידן ה AI. סוכן AI עובד באיטרציות וניסויים לכן שלב קומפילציה ארוך עובד לרעתי.
4. כלים אוטומטיים חשובים. כלי אוטומטי שבודק טעויות נפוצות בקוד, בעיות סגנון, קוד כפול או קוד שלא נמצא בשימוש שווה זהב כשסוכני קידוד כותבים את הקוד.

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

מה דעתכם?